From nobody Wed Jul 1 02:30: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 D41D13A0CE1 for ; Wed, 1 Jul 2020 02:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 Lo2k8LVlcXba for ; Wed, 1 Jul 2020 02:30:29 -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 3DD883A0CE0 for ; Wed, 1 Jul 2020 02:30:28 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d09 with ME id xlWM2200L4FMSmm03lWNB0; Wed, 01 Jul 2020 11:30:26 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 01 Jul 2020 11:30:26 +0200 X-ME-IP: 86.238.65.197 To: Benjamin Kaduk , Justin Richer Cc: "rdd@cert.org" , "txauth@ietf.org" , The IESG , "gnap-chairs@ietf.org" References: <159305522436.11733.15198171728373227965@ietfa.amsl.com> <559FF73B-38D4-4D49-8827-0958613912C0@mit.edu> <20200630193602.GT58278@kduck.mit.edu> <20200630200848.GU58278@kduck.mit.edu> From: Denis Message-ID: <87b22764-f541-cde5-cc02-5d8fb7e80f03@free.fr> Date: Wed, 1 Jul 2020 11:30:25 +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: <20200630200848.GU58278@kduck.mit.edu> Content-Type: multipart/alternative; boundary="------------9F2174EF91AC504FFFAFD6FF" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 01 Jul 2020 09:30:31 -0000 This is a multi-part message in MIME format. --------------9F2174EF91AC504FFFAFD6FF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I jump into this discussion with a one day delay because we are not in the same time zone. Justin and myself had a discussion on the mailing list and we came into the following agreement which is not reflected in the current draft. [Denis]  Would this mean that we strongly agree together that the model should not assume a closely-tied connection between an RS and any single AS ? [Justin] Correct, *we shouldn’t assume it, but we should also not preclude it*. I think a lot of the internet is going keep with that model for some time to come, even if it’s not universal. I noticed the following exchange: [Ben] Would "AS-directed dispatch to the appropriate RS" (or similar) be a useful way to describe this? [Justin] I think that works, as it’s basically about the AS telling the client what to do next. The RS (i.e. not the AS) should tell the client what to do next. Since an AS has not necessarily a close relationship with RSs, it is unable to do it. The close relationship between ASs and RSs should only be considered for some kind of backward compatibility with OAuth 2.0. Denis > Hi Justin, > > On Tue, Jun 30, 2020 at 03:59:17PM -0400, Justin Richer wrote: >> Hi Ben, >> >>> On Jun 30, 2020, at 3:36 PM, Benjamin Kaduk wrote: >>> >>> Hi Justin! >>> >>> On Thu, Jun 25, 2020 at 03:29:36PM -0400, Justin Richer wrote: >>>> Hi Ben, >>>> >>>> Thanks for the thorough read through, as always. >>>> >>>> Some of my own thoughts the TODO items inline below. >>>> >>>>>> This group is chartered to develop a fine-grained delegation protocol >>>>>> for authorization and API access, as well as requesting and providing >>>>>> user identifiers and claims. >>>>>> >>>>>> nit: this appears to parse as "providing user claims", and I'm not sure what that >>>>>> means. >>>>> TODO >>>> Yes, the is intended to parse as “providing user claims”. The idea here is that the client should be able to send claims that it has to the AS that will identify the user in a fashion that the AS can verify. In these cases, the AS can make a policy decision without directly involving the user for interaction. This is largely a gap in the OAuth 2 world, though the Resource Owner Password grant and the Assertions grant kind go in this direction, but there’s a desire in the community for a general mechanism for doing this. To be clear, GNAP is going to defer the details of these kinds of assertions to other specifications, like W3C’s Verifiable Credentials. >>> Let me play this back to check that I've got it right: the idea is that the >>> client might have some existing assertion or something that is evidence >>> that the user has already consented to something, and the protocol is going >>> to include a way for the client to convey this artifact to the AS so that >>> the AS can validate it and skip bothering the user directly? I think we'd >>> probably want some additional adjective here to clarify ("user-consent >>> claims", "user verification claims", etc.) -- my original best-guess >>> reading was that this was "user-supplied claims", e.g., "I'd like my token >>> to include this arbitrary claim I just made up, please". (The latter's >>> intermingling of user-supplied and trusted-source data is a recipe for >>> security issues, of course.) >> Ah, I see the confusion now; right, the idea is not about the user putting claims into something that the AS echoes back to the client. We want the AS to be able to send stuff back that it knows about the user, but the client should be able to send it to the AS as well. For stuff from the client, there are two categories of information people are interested in: identifiers that aren’t proven yet (so it’s just a hint to the AS about who the client :thinks: the user is, like a username) and provable claim sets that the AS can verify independently (and the protocol doesn’t care how that gets validated). Most likely these latter ones will be formatted as assertions. I didn’t want the charter language to limit the format, but I might be overthinking it. I wanted to make sure the charter captured the intent of user information not being a one-way flow in the protocol. How about this: >> >> … for authorization, API access, user identifiers, and identity assertions. The protocol will also allow the client to present unverified identifiers and verifiable assertions to the AS as part of its request. >> >> It’s much, much longer, but hopefully it avoids the garden path and hopefully gets at capturing the intent. > I think it looks good, thanks. > >>>>>> The protocol will decouple the interaction channels, such as the end >>>>>> user’s browser [...] >>>>>> >>>>>> "interaction channels" might be a term of art that needs clarification? >>>>> TODO >>>> I don’t think it’s a specific term of art. I think we really meant “different ways to interact with the user”. One of OAuth 2’s limitations is that it, for the most part, assumes the user’s in a browser, and the core of the protocol is built around that. One of the goals of GNAP is to get away from that as a base assumption. >>> Perhaps "decouple the channels by which the protocol participants >>> communicate"? >> That can work. >> >>>>>> The client and Authorization Server (AS) will involve a user to make >>>>>> an authorization decision as necessary through interaction mechanisms >>>>>> indicated by the protocol. >>>>>> >>>>>>> From a privacy perspective, will all of the information to be made >>>>>> available from the AS to the RS be visible to the user as they make this >>>>>> authorization decision? >>>>> TODO >>>> Ultimately I don’t think we can fully specify the AS behavior here, but this is a good pillar for privacy considerations. >>>> >>>>>> The group will define interoperability for this protocol between different >>>>>> parties, including >>>>>> - client and authorization server; >>>>>> - client and resource server; and >>>>>> - authorization server and resource server. >>>>>> >>>>>> [obligatory note that just because we define an AS/RS channel doesn't mean it >>>>>> will be required to use one at runtime, given the potential for self-contained >>>>>> tokens?] >>>>> Are you thinking that clarification would be explicitly stated? >>>> Note that a self-contained token is one of the communication channels that the group had in mind for AS/RS. We tried to write the requirements in such a way as to allow for self-contained messages, service-based stuff (like introspection), or even all-in-one-box solutions that don’t need “communication” apart from both reading the same database. This is an architectural pillar borrowed from OAuth 2. >>>> >>>>>> - Support for directed, audience-restricted access tokens >>>>>> >>>>>> I think we need to clarify what "directed" is intended to mean here (if it's not >>>>>> just a synonym for "audience-restricted" in which case it should just be >>>>>> removed). >>>>> TODO >>>> This one is my fault — the concept we’re talking about here is one where the AS can effectively tell the client where and how it should use the token. There are a couple different WG participants who have expressed explicit interest in this, and I’ve started a thread on that topic recently: >>>> >>>> https://mailarchive.ietf.org/arch/msg/txauth/eP162P235OU0_JksY515FgmHFj0/ >>> I think I read that one :) >>> >>> Would "AS-directed dispatch to the appropriate RS" (or similar) be a useful >>> way to describe this? >> I think that works, as it’s basically about the AS telling the client what to do next. >> >>>>>> - A variety of client applications, including Web, mobile, >>>>>> single-page, and interaction-constrained applications >>>>>> >>>>>> side note: this one feels like it would be easier to phrase as "the WG will seek >>>>>> to minimize assumptions about the form of client applications, allowing for >>>>>> [...]" >>>>> TODO >>>> That seems reasonable to me, and it goes hand-in-hand with the changes to interaction mentioned above. >>>> >>>>>> Additionally, the group will provide mechanisms for management of the >>>>>> protocol lifecycle including: >>>>>> [...] >>>>>> - Mechanisms for the AS and RS to communicate the access granted by an >>>>>> access token >>>>>> >>>>>> Maybe I'm just confused, but isn't "the access granted by an access token" >>>>>> exactly the set of authorizations conveyed by that token, i.e., the core point of >>>>>> the protocol? I'm not sure what kind "protocol lifecycle management" this >>>>>> item is intending to indicate. >>>>> TODO >>>> This ties into what’s above: the idea is to have a standard model for what an access token represents, and this says we’re going to standardize ways for the AS and RS to communicate that. This could be inside the token, through an introspection style service, or some other thing we haven’t figured out yet. But the thing is, all of these mechanisms should be communicating the same set of information. This is something the OAuth WG didn’t address, and so we ended up with some disparity in the handful of de-facto access token data models there. The goal was to avoid that. >>> Ah, okay. So is the key point that these mechanisms/data-models are >>> "consistent across the entire set of protocol flows"? >>> >> Yes, exactly. We want the different pieces to have a consistent model, without turning the spec into an “abstract data model” spec itself (because we want it to be a concrete protocol). So how about: >> >> - Data model for granted access and mechanisms for the AS and RS to communicate the granted access model. > Works for me. > > Thanks again! > > -Ben > --------------9F2174EF91AC504FFFAFD6FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi,

I jump into this discussion with a one day delay because we are not in the same time zone.

Justin and myself had a discussion on the mailing list and we came into the following agreement which is not reflected in the current draft.

[Denis]  Would this mean that we strongly agree together that the model should not assume a closely-tied connection between an RS and any single AS ?

[Justin] Correct, we shouldn’t assume it, but we should also not preclude it. I think a lot of the internet is going keep with that model for some time to come,
even if it’s not universal.
I noticed the following exchange:
[Ben] Would "AS-directed dispatch to the appropriate RS" (or similar) be a useful way to describe this?

[Justin] I think that works, as it’s basically about the AS telling the client what to do next.
The RS (i.e. not the AS) should tell the client what to do next. Since an AS has not necessarily a close relationship with RSs, it is unable to do it.

The close relationship between ASs and RSs should only be considered for some kind of backward compatibility with OAuth 2.0.

Denis

Hi Justin,

On Tue, Jun 30, 2020 at 03:59:17PM -0400, Justin Richer wrote:

Hi Ben,


On Jun 30, 2020, at 3:36 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi Justin!

On Thu, Jun 25, 2020 at 03:29:36PM -0400, Justin Richer wrote:

Hi Ben,

Thanks for the thorough read through, as always.

Some of my own thoughts the TODO items inline below.


This group is chartered to develop a fine-grained delegation protocol
for authorization and API access, as well as requesting and providing
user identifiers and claims.

nit: this appears to parse as "providing user claims", and I'm not sure what that
means.

TODO

Yes, the is intended to parse as “providing user claims”. The idea here is that the client should be able to send claims that it has to the AS that will identify the user in a fashion that the AS can verify. In these cases, the AS can make a policy decision without directly involving the user for interaction. This is largely a gap in the OAuth 2 world, though the Resource Owner Password grant and the Assertions grant kind go in this direction, but there’s a desire in the community for a general mechanism for doing this. To be clear, GNAP is going to defer the details of these kinds of assertions to other specifications, like W3C’s Verifiable Credentials. 

Let me play this back to check that I've got it right: the idea is that the
client might have some existing assertion or something that is evidence
that the user has already consented to something, and the protocol is going
to include a way for the client to convey this artifact to the AS so that
the AS can validate it and skip bothering the user directly?  I think we'd
probably want some additional adjective here to clarify ("user-consent
claims", "user verification claims", etc.) -- my original best-guess
reading was that this was "user-supplied claims", e.g., "I'd like my token
to include this arbitrary claim I just made up, please".  (The latter's
intermingling of user-supplied and trusted-source data is a recipe for
security issues, of course.)

Ah, I see the confusion now; right, the idea is not about the user putting claims into something that the AS echoes back to the client. We want the AS to be able to send stuff back that it knows about the user, but the client should be able to send it to the AS as well. For stuff from the client, there are two categories of information people are interested in: identifiers that aren’t proven yet (so it’s just a hint to the AS about who the client :thinks: the user is, like a username) and provable claim sets that the AS can verify independently (and the protocol doesn’t care how that gets validated). Most likely these latter ones will be formatted as assertions. I didn’t want the charter language to limit the format, but I might be overthinking it. I wanted to make sure the charter captured the intent of user information not being a one-way flow in the protocol. How about this:

	… for authorization, API access, user identifiers, and identity assertions. The protocol will also allow the client to present unverified identifiers and verifiable assertions to the AS as part of its request.

It’s much, much longer, but hopefully it avoids the garden path and hopefully gets at capturing the intent.

I think it looks good, thanks.



          

            

            

              

              

                
The protocol will decouple the interaction channels, such as the end
user’s browser [...]

"interaction channels" might be a term of art that needs clarification?


              

              
TODO


            

            
I don’t think it’s a specific term of art. I think we really meant “different ways to interact with the user”. One of OAuth 2’s limitations is that it, for the most part, assumes the user’s in a browser, and the core of the protocol is built around that. One of the goals of GNAP is to get away from that as a base assumption.


          

          
Perhaps "decouple the channels by which the protocol participants
communicate"?


        

        
That can work.



        

          

          

            

              

              

                
The client and Authorization Server (AS) will involve a user to make
an authorization decision as necessary through interaction mechanisms
indicated by the protocol.



                

                  
From a privacy perspective, will all of the information to be made


                

                
available from the AS to the RS be visible to the user as they make this
authorization decision?


              

              
TODO


            

            
Ultimately I don’t think we can fully specify the AS behavior here, but this is a good pillar for privacy considerations.



            

              

              

                
The group will define interoperability for this protocol between different
parties, including
 - client and authorization server;
 - client and resource server; and
 - authorization server and resource server.

[obligatory note that just because we define an AS/RS channel doesn't mean it
will be required to use one at runtime, given the potential for self-contained
tokens?]


              

              
Are you thinking that clarification would be explicitly stated?


            

            
Note that a self-contained token is one of the communication channels that the group had in mind for AS/RS. We tried to write the requirements in such a way as to allow for self-contained messages, service-based stuff (like introspection), or even all-in-one-box solutions that don’t need “communication” apart from both reading the same database. This is an architectural pillar borrowed from OAuth 2.



            

              

              

                
- Support for directed, audience-restricted access tokens

I think we need to clarify what "directed" is intended to mean here (if it's not
just a synonym for "audience-restricted" in which case it should just be
removed).


              

              
TODO


            

            
This one is my fault — the concept we’re talking about here is one where the AS can effectively tell the client where and how it should use the token. There are a couple different WG participants who have expressed explicit interest in this, and I’ve started a thread on that topic recently:

https://mailarchive.ietf.org/arch/msg/txauth/eP162P235OU0_JksY515FgmHFj0/


          

          
I think I read that one :)

Would "AS-directed dispatch to the appropriate RS" (or similar) be a useful
way to describe this?


        

        
I think that works, as it’s basically about the AS telling the client what to do next. 



        

          

          

            

              

              

                
- A variety of client applications, including Web, mobile,
  single-page, and interaction-constrained applications

side note: this one feels like it would be easier to phrase as "the WG will seek
to minimize assumptions about the form of client applications, allowing for
[...]"


              

              
TODO


            

            
That seems reasonable to me, and it goes hand-in-hand with the changes to interaction mentioned above. 



            

              

                
Additionally, the group will provide mechanisms for management of the
protocol lifecycle including:
[...]
- Mechanisms for the AS and RS to communicate the access granted by an
  access token

Maybe I'm just confused, but isn't "the access granted by an access token"
exactly the set of authorizations conveyed by that token, i.e., the core point of
the protocol?  I'm not sure what kind "protocol lifecycle management" this
item is intending to indicate.


              

              
TODO


            

            
This ties into what’s above: the idea is to have a standard model for what an access token represents, and this says we’re going to standardize ways for the AS and RS to communicate that. This could be inside the token, through an introspection style service, or some other thing we haven’t figured out yet. But the thing is, all of these mechanisms should be communicating the same set of information. This is something the OAuth WG didn’t address, and so we ended up with some disparity in the handful of de-facto access token data models there. The goal was to avoid that.


          

          
Ah, okay.  So is the key point that these mechanisms/data-models are
"consistent across the entire set of protocol flows"?



        

        
Yes, exactly. We want the different pieces to have a consistent model, without turning the spec into an “abstract data model” spec itself (because we want it to be a concrete protocol). So how about:

	- Data model for granted access and mechanisms for the AS and RS to communicate the granted access model.


      

      
Works for me.

Thanks again!

-Ben



    

    


    

  


--------------9F2174EF91AC504FFFAFD6FF--


From nobody Wed Jul  1 19:58: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 8152F3A0964; Wed,  1 Jul 2020 19:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 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] 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 jMhKRozfYECk; Wed,  1 Jul 2020 19:58:05 -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 132A13A0983; Wed,  1 Jul 2020 19:58:04 -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 0622vvwG027483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 Jul 2020 22:58:00 -0400
Date: Wed, 1 Jul 2020 19:57:57 -0700
From: Benjamin Kaduk 
To: Denis 
Cc: Justin Richer , "rdd@cert.org" , "txauth@ietf.org" , The IESG , "gnap-chairs@ietf.org" 
Message-ID: <20200702025757.GM58278@kduck.mit.edu>
References: <159305522436.11733.15198171728373227965@ietfa.amsl.com>  <559FF73B-38D4-4D49-8827-0958613912C0@mit.edu> <20200630193602.GT58278@kduck.mit.edu>  <20200630200848.GU58278@kduck.mit.edu> <87b22764-f541-cde5-cc02-5d8fb7e80f03@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87b22764-f541-cde5-cc02-5d8fb7e80f03@free.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT)
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, 02 Jul 2020 02:58:07 -0000

Hi Denis,

On Wed, Jul 01, 2020 at 11:30:25AM +0200, Denis wrote:
> Hi,
> 
> I jump into this discussion with a one day delay because we are not in 
> the same time zone.

Okay.

> Justin and myself had a discussion on the mailing list and we came into 
> the following agreement which is not reflected in the current draft.
> 
>     [Denis]  Would this mean that we strongly agree together that the
>     model should not assume a closely-tied connection between an RS and
>     any single AS ?
> 
>     [Justin] Correct, *we shouldn’t assume it, but we should also not
>     preclude it*. I think a lot of the internet is going keep with that

Note that "should not preclude it" means that we should allow it in some
cases, even though we don't require it.

>     model for some time to come,
>     even if it’s not universal.
> 
> I noticed the following exchange:
> 
>     [Ben] Would "AS-directed dispatch to the appropriate RS" (or
>     similar) be a useful way to describe this?
> 
>     [Justin] I think that works, as it’s basically about the AS telling
>     the client what to do next.
> 
> The RS (i.e. not the AS) should tell the client what to do next. Since 
> an AS has not necessarily a close relationship with RSs, it is unable to 
> do it.

My understanding is that this "AS-directed dispatch to the appropriate RS"
functionality is intended to be an optional, not required, feature of the
protocol.  I do not see strong justification for us to force any single
workflow on the protocol at this time, whether RS-directed or AS-directed.

> The close relationship between ASs and RSs should only be considered for 
> some kind of backward compatibility with OAuth 2.0.

I understand that this is your belief.  I do not see much indication that
it is the WG consensus, at this time.

-Ben


From nobody Thu Jul  2 08:29: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 31F813A095F for ; Thu,  2 Jul 2020 08:29:16 -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_REMOTE_IMAGE=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=readycomputing.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 fuRspzUtIAep for ; Thu,  2 Jul 2020 08:29:14 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 EA6213A0954 for ; Thu,  2 Jul 2020 08:29:13 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id b185so15394412qkg.1 for ; Thu, 02 Jul 2020 08:29:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=readycomputing.com; s=google; h=from:to:subject:message-id:date:user-agent:mime-version :content-language; bh=tELw5DiuYL+fJJUUoM6CYG4KnF0gb9xxfBgzVZlWnpo=; b=k5bHeSbej5OcNcMkTyETGvRqN05X9TAsASi0gNpZEfmlFbIwuMh903B2rLgdKmFgi5 Xie5vcQdsvKvrTKIJk0XwKY87ZtYyxOr0mHvwoeE2akDPR1q1wlJNuVdZG2r5pGD2HOE BufdgFT7Z4/V2jCuoT/ddZBPf2No1i3huX///q5nPG+8anQxr2d54O4PNM9D/izmjzQL 9lPNlw/mz9Soa6oqRjkH49ekUGEAnpPQAVZ+yRxcLJjRA8ChsQOYbd1U2JUd/baz2uj/ YGB9kM2Q+WwJttNtO096G8ueExtZgO6wcSPb4MJR/eI62gouBWwSjOhLvvi9tL96qGKl rXsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language; bh=tELw5DiuYL+fJJUUoM6CYG4KnF0gb9xxfBgzVZlWnpo=; b=kKO/XdWn64s24BVV53zH8IyVg6o1gNIQ7BKS1skZcyRPzq9/NItNwAfN3Ei3WTbuxM +jnOW/q8WJxyGIjV5cZaqrQ1lMca7sl+6trx6IdyHz8W/EdhW2bUBBcU1iMEEeS4k8vc hwv+0GjTDNK1/rHvIyl5oAjAPkg0Ktl5JXzF91+gIQvXQsC9IwLwy/IH9WeV5F7laUKA Nt6OpP2RaKXJZNcEapslySPMsnDJe9FXd4gfeJhvovGufumwG+0sOLUbp3L1GiDKckQf SVUBlGGtdTN/hD21Ju3ROLNqJlaY6u05fjTmx4cVcX7uoMdZDCbPbsTvjFF56ajF2LH+ pvSg==
X-Gm-Message-State: AOAM530APMG9wP5C7IQW8HtZGGzUQtGus6VR7FskAuP2NW+hUn0X6j7Q foxiTXoMcxlRX+iA4CnDQliSp85QqD9808FHvr5JtfaYQIWIGNyfeoaCKljapeJDfINAjpiQ0St 4OpB9z+TtFvA39iNoMAxn/I3OAezdwXEOv1mfVB+mk6inrpU0q5DV1qlairBWnk+x+C9p81ifmg ==
X-Google-Smtp-Source: ABdhPJzdBCLWj0qi5Mw6IGrDItY6030sByF/aPICh/Iuc7uPnQ4kf/pGvR6nlL9OPZ0GIv+tNrm1Xw==
X-Received: by 2002:a05:620a:1273:: with SMTP id b19mr30447578qkl.10.1593703752486;  Thu, 02 Jul 2020 08:29:12 -0700 (PDT)
Received: from ?IPv6:2607:fea8:aa20:59d:5d63:582a:1f1:b908? ([2607:fea8:aa20:59d:5d63:582a:1f1:b908]) by smtp.googlemail.com with ESMTPSA id m7sm8644603qti.6.2020.07.02.08.29.11 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jul 2020 08:29:11 -0700 (PDT)
From: David Pyke 
X-Google-Original-From: David Pyke 
To: txauth@ietf.org
Message-ID: 
Date: Thu, 2 Jul 2020 11:29:11 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------99F1EA6E925260DDB0E062E6"
Content-Language: en-CA
Archived-At: 
Subject: [Txauth] Possible Use Case for GNAP
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, 02 Jul 2020 15:29:24 -0000

This is a multi-part message in MIME format.
--------------99F1EA6E925260DDB0E062E6
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

I am working on a Healthcare IT project that requires multi-hop=20
transmission of REST based (FHIR: fhir.hl7.org) resources.=C2=A0 The=20
established protocol uses OAuth2 which doens't lend itself to multi-hop=20
relay.

I saw a presentation on XYZ/GNAP and thought it might be early enough to=20
get on the train to consider how it might address that structure.=C2=A0 The=
=20
system I'm working on is from the US Office of the National Coordinator=20
for Healthcare IT (ONC) called TEFCA.=C2=A0 At minimum there would be 4 hop=
s,=20
at maximum, could be 8-10 and no bypassing of the network can be done.=C2=
=A0=20
As I said, OAuth2 doesn't handle that without significant issues.

If this is not a use case that can be considered, please accept my=20
apologies.

Thanks

Dave Pyke

--=20

*David Pyke*

Manager, Strategic Consulting

---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------

Logo 

LinkedIn icon  Twitter=20
icon  Youtbue icon=20


=09

Office: +1 212 877 3307 x5001

_david.pyke@readycomputing.com _

_www.readycomputing.com _

150 Beekman Street, Floor 3, New York, NY 10038


The information in this e-mail communication together with any=20
attachments is intended only for the person or entity to which it is=20
addressed and may contain confidential and/or privileged material. If=20
you are not the intended recipient of this communication, please notify=20
us immediately. Any views expressed in this communication are those of=20
the sender, unless otherwise specifically stated. Ready Computing does=20
not represent, warrant or guarantee that the integrity of this=20
communication has been maintained or the communication is free of=20
errors, virus or interference.


--=20
This is not a secure transmission. The information contained in this=20

transmission is highly prohibited from containing privileged and=20

confidential information, including patient information protected by=20

federal and state privacy laws. It is intended only for the use of the=20

person(s) named above. If you are not the intended recipient, you are=20

hereby notified that any review, dissemination, distribution, or=20

duplication of this communication is strictly prohibited. If you are not
=20
the intended recipient, please contact the sender by reply email and=20

destroy all copies of the original message.
                       =20

--------------99F1EA6E925260DDB0E062E6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


  

    
  
  
    
I am working on a Healthcare IT project that
        requires multi-hop transmission of REST based (FHIR:
        fhir.hl7.org) resources.=C2=A0 The established protocol uses OAuth2
        which doens't lend itself to multi-hop relay.

    
I saw a presentation on XYZ/GNAP and thought it
        might be early enough to get on the train to consider how it
        might address that structure.=C2=A0 The system I'm working on is fr=
om
        the US Office of the National Coordinator for Healthcare IT
        (ONC) called TEFCA.=C2=A0 At minimum there would be 4 hops, at
        maximum, could be 8-10 and no bypassing of the network can be
        done.=C2=A0 As I said, OAuth2 doesn't handle that without significa=
nt
        issues.

      

    
If this is not a use case that can be considered, please accept
      my apologies.

    
Thanks

    
Dave Pyke

    

    
-- 

      
      
      
      
      

        

          
            

              
                

                  David Pyke
              

            

            

              
                

                  Manager,
                    Strategic Consulting

              		
            

            

              
                
 ---------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------------------------------------------------------------------<=
/p>
              

            

            

              
                

                  3D"Logo"

                

                  3D"LinkedIn 3D"Twitter 3D"Youtbue

              		
              
                
Offi=
ce:
                    +1 212 877 3307 x5001

                

                  
                    

                      
                        

                          
                                david.pyke@readycomputing.com

                        

                          
                                www.readycomputing.com

                      		
                    

                    

                      
                        
150
                            Beekman Street, Floor 3, New York, NY 10038

                      		
                    

                    

                      

                      		
                    

                  
                

              		
            

            

              
                

                  The
                    information in this e-mail communication together
                    with any attachments is intended only for the person
                    or entity to which it is addressed and may contain
                    confidential and/or privileged material. If you are
                    not the intended recipient of this communication,
                    please notify us immediately. Any views expressed in
                    this communication are those of the sender, unless
                    otherwise specifically stated. Ready Computing does
                    not represent, warrant or guarantee that the
                    integrity of this communication has been maintained
                    or the communication is free of errors, virus or
                    interference.

              		
            

          
        

      

    

  




This is not a secure transmission. The information contained in this=20
transmission is highly prohibited from containing privileged and=20
confidential information, including patient information protected by=20
federal and state privacy laws. It is intended only for the use of the=20
person(s) named above. If you are not the intended recipient, you are=20
hereby notified that any review, dissemination, distribution, or=20
duplication of this communication is strictly prohibited. If you are not
 the intended recipient, please contact the sender by reply email and=20
destroy all copies of the original message.
                       
--------------99F1EA6E925260DDB0E062E6--


From nobody Thu Jul  2 09:27: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 DAB9A3A0A78 for ; Thu,  2 Jul 2020 09:27:10 -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_REMOTE_IMAGE=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 qemF4OtxUVBw for ; Thu,  2 Jul 2020 09:27:09 -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 EED8B3A0A73 for ; Thu,  2 Jul 2020 09:27:08 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id g37so826057otb.9 for ; Thu, 02 Jul 2020 09:27: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=33tKroyE2JrbSAnKcBWQgJx0+mwiJwAoiiZWamEpK4o=; b=SxHtVtMyfcUl4UZNFENtyydICZ/1keDDH47dIwZMIy1cqUyd07rGMcccUTZ6mW46Dc IBjCMj1UKbAFzXeTM8I9mTj85hhcQvzRo8hM3f90crGJQCTxcXgBEKiCFzKZOCv3aCUY nhOjtJkaEZzTila4wSbTADDEn7yWLBUHI82Glvivy9nzpeBHgJWMP1RrD7VJ9j7+28tv 8wkqizUOm/B7F7zWMFFM+JDLZcNgkZZ42dxmnx/qlICzzZL/fOKMfNM69nDPUTphVtw6 vKb35q+At8C8w1srgbeiO1s6Ni8DIg+5fh0hZj/3BCozQB6F9Cw8nmfsNjsPAMSvwNmP cA7Q==
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=33tKroyE2JrbSAnKcBWQgJx0+mwiJwAoiiZWamEpK4o=; b=ZdYdV+AsKC6v/oGaYo4cno9He5vNxPPsJjjf3tL6m6a9J9RFFWMGuiUlhK/RImvQur GCTnpmuIx6GQQmDtP4fT06DQnJP0BF1qTlp3BzfFnTb2fWMb3Df644Z1aWhzmhcUFEox vnO1t13R1hxvDQoJY1D5jGJOwmh9gW9u5Q0N7rnFlKfoAa1ZAo+NfWqz9tiKmEBQgmZk n2HWtJ/fbE7Owlr7jXn62pEC0MhtRNb2VrfRcmnRibZibUH1a9pb1za4sgOsVlUQu0G7 z/YasrQ4ZcT8OkTPYUZYeDahrH65RIWwgli5Aqx44DCnjskjbyEIgiFHjPfsmOxrzivO iw3A==
X-Gm-Message-State: AOAM533z7UytHD5uOwdglBNlACF+6csuGmir2+rj9oNjQbmwpjHHv1zu HONCAQj9auPVxE97f3VF9wo3JUYryi7C/8cqeb9a+ovd
X-Google-Smtp-Source: ABdhPJwd1Fax1gRSD7J6MTsxCCUyoGhrWZjs/BwXexswMoC2CxIjZtSZcCPefVLX4R048bk2sg5IIZqavlme7P8rlEk=
X-Received: by 2002:a05:6830:3151:: with SMTP id c17mr28769439ots.143.1593707228015;  Thu, 02 Jul 2020 09:27:08 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Tom Jones 
Date: Thu, 2 Jul 2020 09:26:54 -0700
Message-ID: 
To: David Pyke 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000033af8c05a977e1fd"
Archived-At: 
Subject: Re: [Txauth] Possible Use Case for GNAP
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, 02 Jul 2020 16:27:11 -0000

--00000000000033af8c05a977e1fd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

We discussed that use case this morning in OIDC. A proposal has been made
for a new endpoint that I would like to see working from the EHR endpoints.
Did you have other concerns besides the source and destination endpoints
for the data?
Peace ..tom


On Thu, Jul 2, 2020 at 8:30 AM David Pyke  wrote:

> I am working on a Healthcare IT project that requires multi-hop
> transmission of REST based (FHIR: fhir.hl7.org) resources.  The
> established protocol uses OAuth2 which doens't lend itself to multi-hop
> relay.
>
> I saw a presentation on XYZ/GNAP and thought it might be early enough to
> get on the train to consider how it might address that structure.  The
> system I'm working on is from the US Office of the National Coordinator f=
or
> Healthcare IT (ONC) called TEFCA.  At minimum there would be 4 hops, at
> maximum, could be 8-10 and no bypassing of the network can be done.  As I
> said, OAuth2 doesn't handle that without significant issues.
>
> If this is not a use case that can be considered, please accept my
> apologies.
>
> Thanks
>
> Dave Pyke
> --
>
> *David Pyke*
>
> Manager, Strategic Consulting
>
>
> -------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------
>
> [image: Logo] 
>
> [image: LinkedIn icon] =
 [image:
> Twitter icon]  [image:
> Youtbue icon] 
>
> Office: +1 212 877 3307 x5001
>
> * david.pyke@readycomputing.com *
>
> * www.readycomputing.com *
>
> 150 Beekman Street, Floor 3, New York, NY 10038
>
> The information in this e-mail communication together with any attachment=
s
> is intended only for the person or entity to which it is addressed and ma=
y
> contain confidential and/or privileged material. If you are not the
> intended recipient of this communication, please notify us immediately. A=
ny
> views expressed in this communication are those of the sender, unless
> otherwise specifically stated. Ready Computing does not represent, warran=
t
> or guarantee that the integrity of this communication has been maintained
> or the communication is free of errors, virus or interference.
>
> This is not a secure transmission. The information contained in this
> transmission is highly prohibited from containing privileged and
> confidential information, including patient information protected by
> federal and state privacy laws. It is intended only for the use of the
> person(s) named above. If you are not the intended recipient, you are
> hereby notified that any review, dissemination, distribution, or
> duplication of this communication is strictly prohibited. If you are not
> the intended recipient, please contact the sender by reply email and
> destroy all copies of the original message. --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--00000000000033af8c05a977e1fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


We discussed that use case this morning in OIDC. A proposa=
l has been made for a new endpoint that I would like to see working from th=
e EHR endpoints. Did you have other concerns besides the source and destina=
tion=C2=A0endpoints for the data?
Peace ..tom


On Thu, Jul 2, 2020 at 8:30 AM=
 David Pyke <david.pyke=3D40readycomputing.com@dmarc.ietf.org> wrote:

 =20

   =20
 =20
  

    
I am working on a Healthcare IT project that
        requires multi-hop transmission of REST based (FHIR:
        fhir.hl7.org)=
 resources.=C2=A0 The established protocol uses OAuth2
        which doens't lend itself to multi-hop relay.

    
I saw a presentation on XYZ/GNAP and thought it
        might be early enough to get on the train to consider how it
        might address that structure.=C2=A0 The system I'm working on i=
s from
        the US Office of the National Coordinator for Healthcare IT
        (ONC) called TEFCA.=C2=A0 At minimum there would be 4 hops, at
        maximum, could be 8-10 and no bypassing of the network can be
        done.=C2=A0 As I said, OAuth2 doesn't handle that without signi=
ficant
        issues.

      

    
If this is not a use case that can be considered, please accept
      my apologies.

    
Thanks

    
Dave Pyke

    

    
-- 

     =20
     =20
     =20
     =20
      

        

          
            

              
                

                  David Pyke<=
/b>

              		
            

            

              
                

                  Manag=
er,
                    Strategic Consulting

              		
            

            

              
                
 ----------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
------------------------------------------------

              		
            

            

              
                

                  3D"Logo"

                

                  3D"LinkedIn 3D"= 3D"Youtbue

              		
              
                
Office=
:
                    +1 212 877 3307 x5001

                

                  
                    

                      
                        

                          
                                david.pyke@readycomputing.com

                        

                          
                                www.readycomputing.com

                      		
                    

                    

                      
                        
150
                            Beekman Street, Floor 3, New York, NY 10038

                      		
                    

                    

                      

                      		
                    

                  
                

              		
            

            

              
                

                  The
                    information in this e-mail communication together
                    with any attachments is intended only for the person
                    or entity to which it is addressed and may contain
                    confidential and/or privileged material. If you are
                    not the intended recipient of this communication,
                    please notify us immediately. Any views expressed in
                    this communication are those of the sender, unless
                    otherwise specifically stated. Ready Computing does
                    not represent, warrant or guarantee that the
                    integrity of this communication has been maintained
                    or the communication is free of errors, virus or
                    interference.

              		
            

          
        

      

    

  





This is not a secure transmission. The information contained in this=20
transmission is highly prohibited from containing privileged and=20
confidential information, including patient information protected by=20
federal and state privacy laws. It is intended only for the use of the=20
person(s) named above. If you are not the intended recipient, you are=20
hereby notified that any review, dissemination, distribution, or=20
duplication of this communication is strictly prohibited. If you are not
 the intended recipient, please contact the sender by reply email and=20
destroy all copies of the original message.
                       -- 

Txauth mailing list

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




--00000000000033af8c05a977e1fd--


From nobody Thu Jul  2 09:40: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 68CC13A0ACE for ; Thu,  2 Jul 2020 09:40:56 -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_REMOTE_IMAGE=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=readycomputing.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 pgaa4uC-2EnY for ; Thu,  2 Jul 2020 09:40:52 -0700 (PDT)
Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 43D083A0AE5 for ; Thu,  2 Jul 2020 09:40:52 -0700 (PDT)
Received: by mail-qk1-x743.google.com with SMTP id j80so26247758qke.0 for ; Thu, 02 Jul 2020 09:40:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=readycomputing.com; s=google; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ffY2QJ8+99GD4dDaEBf4DKUzPLEprV05lpDX1Cw9aGw=; b=c7+C2HkYlW/bJP1d148du5OGk/X8DQv1Aq/tf9y5KkA2Eq0AJM9Li4NcBo/9l63LP8 NnEtoj8FhFRKEFulxFUlYzByuru9sRao8ARklbEr0vzkBPmApSrnq6C3TfljFkYOdKrf 4Y31r8PS35ljbcM4Edf4X9tjkmbxfk46aMH7M3d4ZxLA6/nFS9TJugDM8QmJHiLF/ko/ AufIcquU3aPd5CyAhCdQJPI/LF9/kevVD/z1i07yT/244+aqjJDgZOVT5TV5dkG/HR3x mQuKtyj1NFbnZWGXzSiUmEhzkXG1dPtqsif0athsUDnAudvvsxlMgElibT9WnH++858v n6dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ffY2QJ8+99GD4dDaEBf4DKUzPLEprV05lpDX1Cw9aGw=; b=ocHfxwUH2GxkOaHFkydRxSZBJKzGrU5pfUwnOAMs1zQlMrteXcuUa3NVfhLAl95PU+ pPQHcLlO0i82dwDEaUWuBWSW/J0aiQNk7TLBV1goEjWSTU1TjfnfisE0bWMg3y94UPDW lk1TOGNSEmwbm/0rs0ZRVzh11hTpMCECOPeRzeFriJFy2DfyhfKt4EE5I1Ag7zuTiORB IUooNVqY+PXCxaPLqx5X68La4UaPAx7yampp1V9wXFFJZdM7j90weJVg4euyvi2MhZPN 1SgDXXsMPPG34XSpekNoKzJDQ1Bju06HzwtUW3zMSMsq6l5So1UOuocSRG5KRB30pm+n VjiA==
X-Gm-Message-State: AOAM531bom/zHV9v0M+WouPhllxNS4dVthhaWER08AlfB4XLBa/sPeme yZc7332IoQ72/ZKBCwHAM0xG3uzM8ItBXFLTPk1pzhzaXGmT2/EWJ0YuXk/eTWMVyJD59mnxlXV jkmfOxvrvmR6axm6soLM5G1tZv8LqN9tGyJqk0WZDPbQHdt2vccRs07wxnwOnrp7/yO3hlVL2HA ==
X-Google-Smtp-Source: ABdhPJyI+kjwrNxrtv7GySb2TigjHGZtphgbCOiy7nd8zfrPDQlW8Aog1ofzf13VY000qHFFdUks8w==
X-Received: by 2002:a37:40e:: with SMTP id 14mr30860594qke.493.1593708050878;  Thu, 02 Jul 2020 09:40:50 -0700 (PDT)
Received: from ?IPv6:2607:fea8:aa20:59d:5d63:582a:1f1:b908? ([2607:fea8:aa20:59d:5d63:582a:1f1:b908]) by smtp.googlemail.com with ESMTPSA id i22sm8093443qki.4.2020.07.02.09.40.50 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jul 2020 09:40:50 -0700 (PDT)
From: David Pyke 
X-Google-Original-From: David Pyke 
To: txauth@ietf.org
References:  
Message-ID: <3b8d3690-47e2-ff00-1065-29647d18555b@readycomputing.com>
Date: Thu, 2 Jul 2020 12:40:49 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------65AB9332BE4B7E907FE29033"
Content-Language: en-CA
Archived-At: 
Subject: Re: [Txauth] Possible Use Case for GNAP
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, 02 Jul 2020 16:40:57 -0000

This is a multi-part message in MIME format.
--------------65AB9332BE4B7E907FE29033
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Great to hear!

My main concern is that the cert use may be an issue as it's passed=20
through the hops.=C2=A0 A hop may want to have their predecessor=C2=A0 use =
the=20
predecessor's cert coming in but may swap out their own cert for the=20
next connection (and the same happening on the way back).=C2=A0 So, the=20
ability to trace certs through the relaying would be an issue so that=20
trust is maintained even when those certs aren't chained together.=C2=A0 It=
=20
would be good if there was one cert or a set of chained certs used for=20
the two traversal but that's not likely to be the case.

Thanks!

On 2020-07-02 12:26 p.m., Tom Jones wrote:

> We discussed that use case this morning in OIDC. A proposal has been=20
> made for a new endpoint that I would like to see working from the EHR=20
> endpoints. Did you have other concerns besides the source and=20
> destination=C2=A0endpoints for the data?
> Peace ..tom
>
>
> On Thu, Jul 2, 2020 at 8:30 AM David Pyke=20
>  > wrote:
>
>     I am working on a Healthcare IT project that requires multi-hop
>     transmission of REST based (FHIR: fhir.hl7.org
>     ) resources. The established protocol uses
>     OAuth2 which doens't lend itself to multi-hop relay.
>
>     I saw a presentation on XYZ/GNAP and thought it might be early
>     enough to get on the train to consider how it might address that
>     structure.=C2=A0 The system I'm working on is from the US Office of t=
he
>     National Coordinator for Healthcare IT (ONC) called TEFCA.=C2=A0 At
>     minimum there would be 4 hops, at maximum, could be 8-10 and no
>     bypassing of the network can be done.=C2=A0 As I said, OAuth2 doesn't
>     handle that without significant issues.
>
>     If this is not a use case that can be considered, please accept my
>     apologies.
>
>     Thanks
>
>     Dave Pyke
>
>     --=20
>
>     *David Pyke*
>
>     Manager, Strategic Consulting
>
>     ---------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------------
>
>     Logo 
>
>     LinkedIn icon 
>     Twitter icon  Youtbue
>     icon 
>
>     =09
>
>     Office: +1 212 877 3307 x5001
>
>     _david.pyke@readycomputing.com =
_
>
>     _www.readycomputing.com _
>
>     150 Beekman Street, Floor 3, New York, NY 10038
>
>
>     The information in this e-mail communication together with any
>     attachments is intended only for the person or entity to which it
>     is addressed and may contain confidential and/or privileged
>     material. If you are not the intended recipient of this
>     communication, please notify us immediately. Any views expressed
>     in this communication are those of the sender, unless otherwise
>     specifically stated. Ready Computing does not represent, warrant
>     or guarantee that the integrity of this communication has been
>     maintained or the communication is free of errors, virus or
>     interference.
>
>
>     This is not a secure transmission. The information contained in
>     this transmission is highly prohibited from containing privileged
>     and confidential information, including patient information
>     protected by federal and state privacy laws. It is intended only
>     for the use of the person(s) named above. If you are not the
>     intended recipient, you are hereby notified that any review,
>     dissemination, distribution, or duplication of this communication
>     is strictly prohibited. If you are not the intended recipient,
>     please contact the sender by reply email and destroy all copies of
>     the original message. --
>     Txauth mailing list
>     Txauth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/txauth
>
>
--=20

*David Pyke*

Manager, Strategic Consulting

---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------

Logo 

LinkedIn icon  Twitter=20
icon  Youtbue icon=20


=09

Office: +1 212 877 3307 x5001

_david.pyke@readycomputing.com _

_www.readycomputing.com _

150 Beekman Street, Floor 3, New York, NY 10038


The information in this e-mail communication together with any=20
attachments is intended only for the person or entity to which it is=20
addressed and may contain confidential and/or privileged material. If=20
you are not the intended recipient of this communication, please notify=20
us immediately. Any views expressed in this communication are those of=20
the sender, unless otherwise specifically stated. Ready Computing does=20
not represent, warrant or guarantee that the integrity of this=20
communication has been maintained or the communication is free of=20
errors, virus or interference.


--=20
This is not a secure transmission. The information contained in this=20

transmission is highly prohibited from containing privileged and=20

confidential information, including patient information protected by=20

federal and state privacy laws. It is intended only for the use of the=20

person(s) named above. If you are not the intended recipient, you are=20

hereby notified that any review, dissemination, distribution, or=20

duplication of this communication is strictly prohibited. If you are not
=20
the intended recipient, please contact the sender by reply email and=20

destroy all copies of the original message.
                       =20

--------------65AB9332BE4B7E907FE29033
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Great to hear!

    
My main concern is that the cert use may be an
        issue as it's passed through the hops.=C2=A0 A hop may want to have
        their predecessor=C2=A0 use the predecessor's cert coming in but ma=
y
        swap out their own cert for the next connection (and the same
        happening on the way back).=C2=A0 So, the ability to trace certs
        through the relaying would be an issue so that trust is
        maintained even when those certs aren't chained together.=C2=A0 It
        would be good if there was one cert or a set of chained certs
        used for the two traversal but that's not likely to be the case.

    
Thanks!

    

    
On 2020-07-02 12:26 p.m., Tom Jones
      wrote:

    


    

    

      
      
We discussed that use case this morning in OIDC. A
        proposal has been made for a new endpoint that I would like to
        see working from the EHR endpoints. Did you have other concerns
        besides the source and destination=C2=A0endpoints for the data?

        

          

            

              
Peace ..tom

            

          

        

        

      

      

      

        
On Thu, Jul 2, 2020 at 8:30 A=
M
          David Pyke <david.pyke=3D40readycomputing.com@dmarc.ietf.org>
          wrote:

        

        

          

            
I am working on a Healthcare IT project
                that requires multi-hop transmission of REST based
                (FHIR: fhir.hl7.org) resources.=C2=
=A0
                The established protocol uses OAuth2 which doens't lend
                itself to multi-hop relay.

            
I saw a presentation on XYZ/GNAP and
                thought it might be early enough to get on the train to
                consider how it might address that structure.=C2=A0 The
                system I'm working on is from the US Office of the
                National Coordinator for Healthcare IT (ONC) called
                TEFCA.=C2=A0 At minimum there would be 4 hops, at maximum,
                could be 8-10 and no bypassing of the network can be
                done.=C2=A0 As I said, OAuth2 doesn't handle that without
                significant issues.

              

            
If this is not a use case that can be considered, please
              accept my apologies.

            
Thanks

            
Dave Pyke

            

            
-- 

              

                

                  
                    

                      
                        
 <=
b>David Pyke

                      		
                    

                    

                      
                        
 =
M=
anager,
                            Strategic Consulting

                      		
                    

                    

                      
                        
 <=
span
                            style=3D"font-size:2pt;color:rgb(68,68,68)">---=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
----

                      		
                    

                    

                      
                        
 3D"Logo"

                        
 3D"LinkedIn 3D"Twitter 3D"Youtbue

                      		
                      
                        
Office:
                            +1 212 877 3307 x5001

                        

                          
                            

                              
                                

                                  
                                        david.pyke@readycomputing.com

                                

                                  
                                        www.readycomputing.com

                              		
                            

                            

                              
                                
150
                                    Beekman Street, Floor 3, New York,
                                    NY 10038

                              		
                            

                            

                              
                              
                            

                          
                        

                      		
                    

                    

                      
                        

                          The
                            information in this e-mail communication
                            together with any attachments is intended
                            only for the person or entity to which it is
                            addressed and may contain confidential
                            and/or privileged material. If you are not
                            the intended recipient of this
                            communication, please notify us immediately.
                            Any views expressed in this communication
                            are those of the sender, unless otherwise
                            specifically stated. Ready Computing does
                            not represent, warrant or guarantee that the
                            integrity of this communication has been
                            maintained or the communication is free of
                            errors, virus or interference.

                      		
                    

                  
                

              

            

          

          

          This is not a secure transmission. The information contained
          in this transmission is highly prohibited from containing
          privileged and confidential information, including patient
          information protected by federal and state privacy laws. It is
          intended only for the use of the person(s) named above. If you
          are not the intended recipient, you are hereby notified that
          any review, dissemination, distribution, or duplication of
          this communication is strictly prohibited. If you are not the
          intended recipient, please contact the sender by reply email
          and destroy all copies of the original message. -- 

          Txauth mailing list

          Txauth@ietf.org

          h=
ttps://www.ietf.org/mailman/listinfo/txauth

        

      

      

      

    

    
-- 

      
      
      
      
      

        

          
            

              
                

                  David Pyke
              

            

            

              
                

                  Manager,
                    Strategic Consulting

              		
            

            

              
                
 ---------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------------------------------------------------------------------<=
/p>
              

            

            

              
                

                  3D"Logo"

                

                  3D"LinkedIn 3D"Twitter 3D"Youtbue

              		
              
                
Offi=
ce:
                    +1 212 877 3307 x5001

                

                  
                    

                      
                        

                          
                                david.pyke@readycomputing.com

                        

                          
                                www.readycomputing.com

                      		
                    

                    

                      
                        
150
                            Beekman Street, Floor 3, New York, NY 10038

                      		
                    

                    

                      

                      		
                    

                  
                

              		
            

            

              
                

                  The
                    information in this e-mail communication together
                    with any attachments is intended only for the person
                    or entity to which it is addressed and may contain
                    confidential and/or privileged material. If you are
                    not the intended recipient of this communication,
                    please notify us immediately. Any views expressed in
                    this communication are those of the sender, unless
                    otherwise specifically stated. Ready Computing does
                    not represent, warrant or guarantee that the
                    integrity of this communication has been maintained
                    or the communication is free of errors, virus or
                    interference.

              		
            

          
        

      

    

  




This is not a secure transmission. The information contained in this=20
transmission is highly prohibited from containing privileged and=20
confidential information, including patient information protected by=20
federal and state privacy laws. It is intended only for the use of the=20
person(s) named above. If you are not the intended recipient, you are=20
hereby notified that any review, dissemination, distribution, or=20
duplication of this communication is strictly prohibited. If you are not
 the intended recipient, please contact the sender by reply email and=20
destroy all copies of the original message.
                       
--------------65AB9332BE4B7E907FE29033--


From nobody Thu Jul  2 09:46: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 37AC43A0BFB for ; Thu,  2 Jul 2020 09:46:03 -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_REMOTE_IMAGE=0.01, 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 7my60jITV0oO for ; Thu,  2 Jul 2020 09:45:59 -0700 (PDT)
Received: from mail-oo1-xc44.google.com (mail-oo1-xc44.google.com [IPv6:2607:f8b0:4864:20::c44]) (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 E6ABE3A0B6A for ; Thu,  2 Jul 2020 09:45:58 -0700 (PDT)
Received: by mail-oo1-xc44.google.com with SMTP id i4so2142819ooj.10 for ; Thu, 02 Jul 2020 09:45:58 -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=mhyj0iM9Zw4vdAxza6R0J699IEZ9HcUN2I7PmOeG37g=; b=qUBkNrzJf0HclSiOkTMtMOMu9O5YoMItj5+WVkQwiuSBmI8aXzeIVEuOP47fk2Dixy Lx6LRO4/hcQ2ugJ7rNU3odFxth6wtShMwvEae167bSG01k3hCheNLRGImhnCbXLrRzO4 t673kO7ezlsQOVAYBPp6cdJPPo/iqqpzAUNgOjBwBNKagzJC13GVoG+uGwVhznOoQ4Df CT1UONJTRScPG8WXEAt+qdYVY20yL+mwtN1LRjoKPyws5U9ETydR/F/M3oZ9JibDpcUN VcjMG6bfLhxjDFd63chqjAeWpjsAAi3DOQk/Z7o7u28eZ3d4Y/UdX0ASJ1H+9nF+Yopt gL6A==
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=mhyj0iM9Zw4vdAxza6R0J699IEZ9HcUN2I7PmOeG37g=; b=OJ4Afl+mZ0Gevie3Id1Ny5IjEkYFRc7f4rYCgtSY3Nribz9dxnt/hBy3RUWshkS/wi e+2puvPfbtq5A5GclImcgOL61mFHGYf1irASspHxSP47/RJvCLx/eUbW9xaOZvpuUU8l YKPPenH/i9SjbA//sPMw9UAPG575Ec6I1fzXS5ybn7BTCdWSzdUuYq9EdaKMwVGFMKJV kfHvZIAQsDK2ymCGez6lkXFKBcTNPknJyk5pz6ZrItsBikJbU/bXU33UGDWlwZBoREbV 3xb98w2IjXHbzSw4Citq/3NtARGnkTMSE7wYfQAglJBDhr5hPxJUOVIaQjjEIUh/MW2P Xftw==
X-Gm-Message-State: AOAM530SIKoo5aoCVL9GHUSDmfN5BTNzcb38F8r+9de2BWU4NXHgw41J 91n2tnyXm/3CNxBjv0f31Q2CDhaqrqUKJTcD1cI=
X-Google-Smtp-Source: ABdhPJxtb1q8AFJCvbcMAhK4XFNvBub73DXCEdwtlVFg93lfS2QyvtnWBr1+YOw4j7w6MWuLFxSwOyyrY0Mgvz8sWyQ=
X-Received: by 2002:a4a:dfb5:: with SMTP id k21mr19960775ook.27.1593708357797;  Thu, 02 Jul 2020 09:45:57 -0700 (PDT)
MIME-Version: 1.0
References:   <3b8d3690-47e2-ff00-1065-29647d18555b@readycomputing.com>
In-Reply-To: <3b8d3690-47e2-ff00-1065-29647d18555b@readycomputing.com>
From: Tom Jones 
Date: Thu, 2 Jul 2020 09:45:44 -0700
Message-ID: 
To: David Pyke 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008accd105a97824cc"
Archived-At: 
Subject: Re: [Txauth] Possible Use Case for GNAP
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, 02 Jul 2020 16:46:10 -0000

--0000000000008accd105a97824cc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

without a better understanding of the "hop" it is hard to say. Does each
"hop" archive the PHI in FHIR format? if so each would need to notify the
user of access, as i see the problem. That sounds like something that would
scare the patient. If the "hop" just handled (for example) an encrypted
packet, that would not be a problem. OTOH if a federation were involved,
the federation could notify the user. Less scary perhaps.
Peace ..tom


On Thu, Jul 2, 2020 at 9:41 AM David Pyke  wrote:

> Great to hear!
>
> My main concern is that the cert use may be an issue as it's passed
> through the hops.  A hop may want to have their predecessor  use the
> predecessor's cert coming in but may swap out their own cert for the next
> connection (and the same happening on the way back).  So, the ability to
> trace certs through the relaying would be an issue so that trust is
> maintained even when those certs aren't chained together.  It would be go=
od
> if there was one cert or a set of chained certs used for the two traversa=
l
> but that's not likely to be the case.
>
> Thanks!
> On 2020-07-02 12:26 p.m., Tom Jones wrote:
>
> We discussed that use case this morning in OIDC. A proposal has been made
> for a new endpoint that I would like to see working from the EHR endpoint=
s.
> Did you have other concerns besides the source and destination endpoints
> for the data?
> Peace ..tom
>
>
> On Thu, Jul 2, 2020 at 8:30 AM David Pyke  40readycomputing.com@dmarc.ietf.org> wrote:
>
>> I am working on a Healthcare IT project that requires multi-hop
>> transmission of REST based (FHIR: fhir.hl7.org) resources.  The
>> established protocol uses OAuth2 which doens't lend itself to multi-hop
>> relay.
>>
>> I saw a presentation on XYZ/GNAP and thought it might be early enough to
>> get on the train to consider how it might address that structure.  The
>> system I'm working on is from the US Office of the National Coordinator =
for
>> Healthcare IT (ONC) called TEFCA.  At minimum there would be 4 hops, at
>> maximum, could be 8-10 and no bypassing of the network can be done.  As =
I
>> said, OAuth2 doesn't handle that without significant issues.
>>
>> If this is not a use case that can be considered, please accept my
>> apologies.
>>
>> Thanks
>>
>> Dave Pyke
>> --
>>
>> *David Pyke*
>>
>> Manager, Strategic Consulting
>>
>>
>> ------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
----------
>>
>> [image: Logo] 
>>
>> [image: LinkedIn icon]  [image:
>> Twitter icon]  [image:
>> Youtbue icon] 
>>
>> Office: +1 212 877 3307 x5001
>>
>> * david.pyke@readycomputing.com *
>>
>> * www.readycomputing.com *
>>
>> 150 Beekman Street, Floor 3, New York, NY 10038
>>
>> The information in this e-mail communication together with any
>> attachments is intended only for the person or entity to which it is
>> addressed and may contain confidential and/or privileged material. If yo=
u
>> are not the intended recipient of this communication, please notify us
>> immediately. Any views expressed in this communication are those of the
>> sender, unless otherwise specifically stated. Ready Computing does not
>> represent, warrant or guarantee that the integrity of this communication
>> has been maintained or the communication is free of errors, virus or
>> interference.
>>
>> This is not a secure transmission. The information contained in this
>> transmission is highly prohibited from containing privileged and
>> confidential information, including patient information protected by
>> federal and state privacy laws. It is intended only for the use of the
>> person(s) named above. If you are not the intended recipient, you are
>> hereby notified that any review, dissemination, distribution, or
>> duplication of this communication is strictly prohibited. If you are not
>> the intended recipient, please contact the sender by reply email and
>> destroy all copies of the original message. --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
> --
>
> *David Pyke*
>
> Manager, Strategic Consulting
>
>
> -------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------
>
> [image: Logo] 
>
> [image: LinkedIn icon] =
 [image:
> Twitter icon]  [image:
> Youtbue icon] 
>
> Office: +1 212 877 3307 x5001
>
> * david.pyke@readycomputing.com *
>
> * www.readycomputing.com *
>
> 150 Beekman Street, Floor 3, New York, NY 10038
>
> The information in this e-mail communication together with any attachment=
s
> is intended only for the person or entity to which it is addressed and ma=
y
> contain confidential and/or privileged material. If you are not the
> intended recipient of this communication, please notify us immediately. A=
ny
> views expressed in this communication are those of the sender, unless
> otherwise specifically stated. Ready Computing does not represent, warran=
t
> or guarantee that the integrity of this communication has been maintained
> or the communication is free of errors, virus or interference.
>
> This is not a secure transmission. The information contained in this
> transmission is highly prohibited from containing privileged and
> confidential information, including patient information protected by
> federal and state privacy laws. It is intended only for the use of the
> person(s) named above. If you are not the intended recipient, you are
> hereby notified that any review, dissemination, distribution, or
> duplication of this communication is strictly prohibited. If you are not
> the intended recipient, please contact the sender by reply email and
> destroy all copies of the original message. --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--0000000000008accd105a97824cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


without a better understanding of the "hop" it i=
s hard to say. Does each "hop" archive the PHI in FHIR format? if=
 so each would need to notify the user of access, as i see the problem. Tha=
t sounds like something that would scare the patient. If the "hop"=
; just handled (for example) an=C2=A0encrypted packet, that would not be a =
problem. OTOH if a federation were involved, the federation could notify th=
e user. Less scary perhaps.
=
Peace ..tom


On Thu, Jul 2, 2020 at 9:41 AM David=
 Pyke <david.pyke=3D40readycomputing.com@dmarc.ietf.org> wrote:

 =20
   =20
 =20
  

    
Great to hear!

    
My main concern is that the cert use may be an
        issue as it's passed through the hops.=C2=A0 A hop may want to =
have
        their predecessor=C2=A0 use the predecessor's cert coming in bu=
t may
        swap out their own cert for the next connection (and the same
        happening on the way back).=C2=A0 So, the ability to trace certs
        through the relaying would be an issue so that trust is
        maintained even when those certs aren't chained together.=C2=A0=
 It
        would be good if there was one cert or a set of chained certs
        used for the two traversal but that's not likely to be the case=
.

    
Thanks!

    

    
On 2020-07-02 12:26 p.m., Tom Jones
      wrote:

    


    

    

     =20
      
We discussed that use case this morning in OIDC. A
        proposal has been made for a new endpoint that I would like to
        see working from the EHR endpoints. Did you have other concerns
        besides the source and destination=C2=A0endpoints for the data?

        

          

            

              
Peace ..tom

            

          

        

        

      

      

      

        
On Thu, Jul 2, 2020 at 8:30 A=
M
          David Pyke <david.pyke=3D40readycomputing.com@dmarc.ietf.org=
>
          wrote:

        

        

          

            
I am working on a Healthcare IT project
                that requires multi-hop transmission of REST based
                (FHIR: fh=
ir.hl7.org) resources.=C2=A0
                The established protocol uses OAuth2 which doens't lend
                itself to multi-hop relay.

            
I saw a presentation on XYZ/GNAP and
                thought it might be early enough to get on the train to
                consider how it might address that structure.=C2=A0 The
                system I'm working on is from the US Office of the
                National Coordinator for Healthcare IT (ONC) called
                TEFCA.=C2=A0 At minimum there would be 4 hops, at maximum,
                could be 8-10 and no bypassing of the network can be
                done.=C2=A0 As I said, OAuth2 doesn't handle that witho=
ut
                significant issues.

              

            
If this is not a use case that can be considered, please
              accept my apologies.

            
Thanks

            
Dave Pyke

            

            
-- 

              

                

                  
                    

                      
                        
 <=
b>David Pyke

                      		
                    

                    

                      
                        
 =
Manager,
                            Strategic Consulting

                      		
                    

                    

                      
                        
 <=
span style=3D"font-size:2pt;color:rgb(68,68,68)">--------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
--------------------------------------------------------

                      		
                    

                    

                      
                        
 3D"Logo"

                        
 3D"LinkedIn  =


                      		
                      
                        
Office:
                            +1 212 877 3307 x5001

                        

                          
                            

                              
                                

                                  
                                        david.pyke@readycomputing.com

                                

                                  
                                        www.readycomputing.com

                              		
                            

                            

                              
                                
150
                                    Beekman Street, Floor 3, New York,
                                    NY 10038

                              		
                            

                            

                              
                              
                            

                          
                        

                      		
                    

                    

                      
                        

                          The
                            information in this e-mail communication
                            together with any attachments is intended
                            only for the person or entity to which it is
                            addressed and may contain confidential
                            and/or privileged material. If you are not
                            the intended recipient of this
                            communication, please notify us immediately.
                            Any views expressed in this communication
                            are those of the sender, unless otherwise
                            specifically stated. Ready Computing does
                            not represent, warrant or guarantee that the
                            integrity of this communication has been
                            maintained or the communication is free of
                            errors, virus or interference.

                      		
                    

                  
                

              

            

          

          

          This is not a secure transmission. The information contained
          in this transmission is highly prohibited from containing
          privileged and confidential information, including patient
          information protected by federal and state privacy laws. It is
          intended only for the use of the person(s) named above. If you
          are not the intended recipient, you are hereby notified that
          any review, dissemination, distribution, or duplication of
          this communication is strictly prohibited. If you are not the
          intended recipient, please contact the sender by reply email
          and destroy all copies of the original message. -- 

          Txauth mailing list

          Txauth@ietf.=
org

          https://www.ietf.org/mailman/listinfo/txauth

        

      

      

      

    

    
-- 

     =20
     =20
     =20
     =20
      

        

          
            

              
                

                  David Pyke<=
/b>

              		
            

            

              
                

                  Manag=
er,
                    Strategic Consulting

              		
            

            

              
                
 ----------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
------------------------------------------------

              		
            

            

              
                

                  3D"Logo"

                

                  3D"LinkedIn 3D"= 3D"Youtbue

              		
              
                
Office=
:
                    +1 212 877 3307 x5001

                

                  
                    

                      
                        

                          
                                david.pyke@readycomputing.com

                        

                          
                                www.readycomputing.com

                      		
                    

                    

                      
                        
150
                            Beekman Street, Floor 3, New York, NY 10038

                      		
                    

                    

                      

                      		
                    

                  
                

              		
            

            

              
                

                  The
                    information in this e-mail communication together
                    with any attachments is intended only for the person
                    or entity to which it is addressed and may contain
                    confidential and/or privileged material. If you are
                    not the intended recipient of this communication,
                    please notify us immediately. Any views expressed in
                    this communication are those of the sender, unless
                    otherwise specifically stated. Ready Computing does
                    not represent, warrant or guarantee that the
                    integrity of this communication has been maintained
                    or the communication is free of errors, virus or
                    interference.

              		
            

          
        

      

    

  





This is not a secure transmission. The information contained in this=20
transmission is highly prohibited from containing privileged and=20
confidential information, including patient information protected by=20
federal and state privacy laws. It is intended only for the use of the=20
person(s) named above. If you are not the intended recipient, you are=20
hereby notified that any review, dissemination, distribution, or=20
duplication of this communication is strictly prohibited. If you are not
 the intended recipient, please contact the sender by reply email and=20
destroy all copies of the original message.
                       -- 

Txauth mailing list

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




--0000000000008accd105a97824cc--


From nobody Thu Jul  2 10:02: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 E02313A0C40 for ; Thu,  2 Jul 2020 10:02:26 -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_REMOTE_IMAGE=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=readycomputing.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 an-MOMql-euK for ; Thu,  2 Jul 2020 10:02:24 -0700 (PDT)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 28C1C3A0C3F for ; Thu,  2 Jul 2020 10:02:23 -0700 (PDT)
Received: by mail-qv1-xf2b.google.com with SMTP id dm12so12992935qvb.9 for ; Thu, 02 Jul 2020 10:02:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=readycomputing.com; s=google; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=2KbS98B65f/9NpNMkMDFnhT+bsTdnR/XX3q0R43Wljw=; b=wbmdmfykwEaBm8W47QrjTML46kqiWD+xO4jrXpabO0If6X+Pt0db0nDMBAuNtnP0Zm ZmXSb5/D16ea+0/+qr96K+M9qaqm0RVk86FbHgXIXIinotw/hNgBiNNvDLn8elVae+QQ ElBcl5ekPOTKJwrvJhOuvnCJSdgBDzm5QxLVVI028lyW0qATjejd0M3s+WV15oJKqfdI +Vz+XQXeL4TnJGjxJ7Or/cEGDJJ1d1m7cWuyy2Mc23awgga1+W3P+GDwKeu4GFuNmRiC J2PdNysBDSldREq9JX1RdhAQTFvxFnrplP1c/w3+O6JmxyK49fWJOgMbx/px9VDhAcfG lH1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=2KbS98B65f/9NpNMkMDFnhT+bsTdnR/XX3q0R43Wljw=; b=hOJH1J4+8AWT1lB/2wmFvupQiYd7wa265WuYXt70sU2qeaHnGm1GRgShkOEw/+Opc6 nVjAwkMySs1yLSBKoP2v5kAn4+UTLoSoVY3gX5MDNh9+P98eobQN7oowtW2joC9p9OQA CS7QvmDE08zDH9FTBMe1vT4AbSqXQOqf47FOEXeUgbP2uqgCh4M7lpQQjMMqasJuQnNX +TzR4FSvOk4/bvqHG5LLJZ2AC5PN8JzQIkSFUaUox+ZLZ193zmJvlVBxwyq2r8xT8VB4 Wl2H92pTJbcfg97QZ1oeq0AfI6hnN3S0TJtgUoDX7FyvMvA6l+ugVftaqFzDH12U5te4 38iA==
X-Gm-Message-State: AOAM532EvoNN9VOl2QH7z3gtXX/yqXco0pYE96kAfIazI5UP27ct44My w+m981qiq1pOBikEhz0tGhaqsrkGcxNuZyuYzHM5Gd/vtAdge0RsO9Sn+XW2cRQ9yOE3vvde7BC xl6LNaTK9Hitx+qm0sXnHZQdXyWPv70bNnsSVbXIkbTv/naFPSPOzXyQ1vT8ZYi2brlPL2ZqHGA ==
X-Google-Smtp-Source: ABdhPJx36O3emjnkCnPSXFhnEZU5ydyt3n/R9LEDWpLIiKstjoAos4kf9v8VL38A0hS4xaSWIzkZ2g==
X-Received: by 2002:a0c:e008:: with SMTP id j8mr27960633qvk.87.1593709342509;  Thu, 02 Jul 2020 10:02:22 -0700 (PDT)
Received: from ?IPv6:2607:fea8:aa20:59d:5d63:582a:1f1:b908? ([2607:fea8:aa20:59d:5d63:582a:1f1:b908]) by smtp.googlemail.com with ESMTPSA id p186sm8697813qkf.33.2020.07.02.10.02.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jul 2020 10:02:22 -0700 (PDT)
From: David Pyke 
X-Google-Original-From: David Pyke 
To: Tom Jones 
Cc: txauth@ietf.org
References:   <3b8d3690-47e2-ff00-1065-29647d18555b@readycomputing.com> 
Message-ID: <00827624-7361-4c5f-b34f-0edc8f7493dc@readycomputing.com>
Date: Thu, 2 Jul 2020 13:02:20 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C9B6ED3A905631ED5B2A6A5D"
Content-Language: en-CA
Archived-At: 
Subject: Re: [Txauth] Possible Use Case for GNAP
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, 02 Jul 2020 17:02:27 -0000

This is a multi-part message in MIME format.
--------------C9B6ED3A905631ED5B2A6A5D
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Each hop relays the information but may have to do a transform on the=20
data on the way through.=C2=A0 So, the data shouldn't be archived as the=20
network is designed purely to route request and responses from=20
originator to=C2=A0 responder.=C2=A0 As such, there's no need for individua=
l=20
access notifications.=C2=A0 However, the data is not necessarily encrypted =
as=20
this is designed as a trusted network. The FHIR query would be routed=20
through to the responder, and the results routed back to the query=20
originator.

Notifications to the user would be not needed as to the originator=20
system the network is (should be) transparent. However, to maintain the=20
trust of the authorization/authentication, each hop will have to=20
capture, and forward to one or more responders in the network.

For example

 1. EHR A sends out a patient record discovery request to it's upstream
    actor, that is forwarded to it's upstream HIN.
 2. The HIN sends that request to all other HINs who forward it
    (depending on the capabilities of the HIN) to the various actors.=C2=A0
    The originating user needs to be identified to the responders for
    audit and access consent. However, the cert that is used may (and
    likely will) change for each hop and be different the org that was
    the query source, which will still need to be identified to the
    responders
 3. Some of those actors' EHRs respond saying they have data on that
    patient.
 4. The responding HINs aggregates the responses and sends on bundle to
    the initiating HIN who forwards it via it's network to the query source
 5. That source sends out a requests to saying "Send me the data from
    all the sources", that goes out, and results are aggregated on the
    way back into one bundle.=C2=A0 Same requirements as 2

All of that needs to be managed from a=20
trust/authentication/authorization point of view. Simple, right?


On 2020-07-02 12:45 p.m., Tom Jones wrote:
> without a better understanding of the "hop" it is hard to say. Does=20
> each "hop" archive the PHI in FHIR format? if so each would need to=20
> notify the user of access, as i see the problem. That sounds like=20
> something that would scare the patient. If the "hop" just handled (for=20
> example) an=C2=A0encrypted packet, that would not be a problem. OTOH if a=
=20
> federation were involved, the federation could notify the user. Less=20
> scary perhaps.
> Peace ..tom
>
>
> On Thu, Jul 2, 2020 at 9:41 AM David Pyke=20
>  > wrote:
>
>     Great to hear!
>
>     My main concern is that the cert use may be an issue as it's
>     passed through the hops.=C2=A0 A hop may want to have their
>     predecessor=C2=A0 use the predecessor's cert coming in but may swap o=
ut
>     their own cert for the next connection (and the same happening on
>     the way back).=C2=A0 So, the ability to trace certs through the
>     relaying would be an issue so that trust is maintained even when
>     those certs aren't chained together.=C2=A0 It would be good if there
>     was one cert or a set of chained certs used for the two traversal
>     but that's not likely to be the case..
>
>     Thanks!
>
>     On 2020-07-02 12:26 p.m., Tom Jones wrote:
>
>>     We discussed that use case this morning in OIDC. A proposal has
>>     been made for a new endpoint that I would like to see working
>>     from the EHR endpoints. Did you have other concerns besides the
>>     source and destination=C2=A0endpoints for the data?
>>     Peace ..tom
>>
>>
>>     On Thu, Jul 2, 2020 at 8:30 AM David Pyke
>>     >     > wrote:
>>
>>         I am working on a Healthcare IT project that requires
>>         multi-hop transmission of REST based (FHIR: fhir.hl7.org
>>         ) resources.=C2=A0 The established protocol
>>         uses OAuth2 which doens't lend itself to multi-hop relay.
>>
>>         I saw a presentation on XYZ/GNAP and thought it might be
>>         early enough to get on the train to consider how it might
>>         address that structure.=C2=A0 The system I'm working on is from
>>         the US Office of the National Coordinator for Healthcare IT
>>         (ONC) called TEFCA.=C2=A0 At minimum there would be 4 hops, at
>>         maximum, could be 8-10 and no bypassing of the network can be
>>         done.=C2=A0 As I said, OAuth2 doesn't handle that without
>>         significant issues.
>>
>>         If this is not a use case that can be considered, please
>>         accept my apologies.
>>
>>         Thanks
>>
>>         Dave Pyke
>>
>>         --=20
>>
>>         *David Pyke*
>>
>>         Manager, Strategic Consulting
>>
>>         ----------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
------------------
>>
>>         Logo 
>>
>>         LinkedIn icon
>>          Twitter
>>         icon  Youtbue
>>         icon 
>>
>>         =09
>>
>>         Office: +1 212 877 3307 x5001
>>
>>         _david.pyke@readycomputing.com
>>         _
>>
>>         _www.readycomputing.com _
>>
>>         150 Beekman Street, Floor 3, New York, NY 10038
>>
>>
>>         The information in this e-mail communication together with
>>         any attachments is intended only for the person or entity to
>>         which it is addressed and may contain confidential and/or
>>         privileged material. If you are not the intended recipient of
>>         this communication, please notify us immediately. Any views
>>         expressed in this communication are those of the sender,
>>         unless otherwise specifically stated. Ready Computing does
>>         not represent, warrant or guarantee that the integrity of
>>         this communication has been maintained or the communication
>>         is free of errors, virus or interference.
>>
>>
>>         This is not a secure transmission. The information contained
>>         in this transmission is highly prohibited from containing
>>         privileged and confidential information, including patient
>>         information protected by federal and state privacy laws. It
>>         is intended only for the use of the person(s) named above. If
>>         you are not the intended recipient, you are hereby notified
>>         that any review, dissemination, distribution, or duplication
>>         of this communication is strictly prohibited. If you are not
>>         the intended recipient, please contact the sender by reply
>>         email and destroy all copies of the original message. --
>>         Txauth mailing list
>>         Txauth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>     --=20
>
>     *David Pyke*
>
>     Manager, Strategic Consulting
>
>     ---------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------------
>
>     Logo 
>
>     LinkedIn icon 
>     Twitter icon  Youtbue
>     icon 
>
>     =09
>
>     Office: +1 212 877 3307 x5001
>
>     _david.pyke@readycomputing.com =
_
>
>     _www.readycomputing.com _
>
>     150 Beekman Street, Floor 3, New York, NY 10038
>
>
>     The information in this e-mail communication together with any
>     attachments is intended only for the person or entity to which it
>     is addressed and may contain confidential and/or privileged
>     material. If you are not the intended recipient of this
>     communication, please notify us immediately. Any views expressed
>     in this communication are those of the sender, unless otherwise
>     specifically stated. Ready Computing does not represent, warrant
>     or guarantee that the integrity of this communication has been
>     maintained or the communication is free of errors, virus or
>     interference.
>
>
>     This is not a secure transmission. The information contained in
>     this transmission is highly prohibited from containing privileged
>     and confidential information, including patient information
>     protected by federal and state privacy laws. It is intended only
>     for the use of the person(s) named above. If you are not the
>     intended recipient, you are hereby notified that any review,
>     dissemination, distribution, or duplication of this communication
>     is strictly prohibited. If you are not the intended recipient,
>     please contact the sender by reply email and destroy all copies of
>     the original message. --
>     Txauth mailing list
>     Txauth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/txauth
>
--=20

*David Pyke*

Manager, Strategic Consulting

---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------

Logo 

LinkedIn icon  Twitter=20
icon  Youtbue icon=20


=09

Office: +1 212 877 3307 x5001

_david.pyke@readycomputing.com _

_www.readycomputing.com _

150 Beekman Street, Floor 3, New York, NY 10038


The information in this e-mail communication together with any=20
attachments is intended only for the person or entity to which it is=20
addressed and may contain confidential and/or privileged material. If=20
you are not the intended recipient of this communication, please notify=20
us immediately. Any views expressed in this communication are those of=20
the sender, unless otherwise specifically stated. Ready Computing does=20
not represent, warrant or guarantee that the integrity of this=20
communication has been maintained or the communication is free of=20
errors, virus or interference.


--=20
This is not a secure transmission. The information contained in this=20

transmission is highly prohibited from containing privileged and=20

confidential information, including patient information protected by=20

federal and state privacy laws. It is intended only for the use of the=20

person(s) named above. If you are not the intended recipient, you are=20

hereby notified that any review, dissemination, distribution, or=20

duplication of this communication is strictly prohibited. If you are not
=20
the intended recipient, please contact the sender by reply email and=20

destroy all copies of the original message.
                       =20

--------------C9B6ED3A905631ED5B2A6A5D
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Each hop relays the information but may have to do a transform on
      the data on the way through.=C2=A0 So, the data shouldn't be archived
      as the network is designed purely to route request and responses
      from originator to=C2=A0 responder.=C2=A0 As such, there's no need fo=
r
      individual access notifications.=C2=A0 However, the data is not
      necessarily encrypted as this is designed as a trusted network.=C2=A0
      The FHIR query would be routed through to the responder, and the
      results routed back to the query originator. 

    

    
Notifications to the user would be not needed as to the
      originator system the network is (should be) transparent.=C2=A0
      However, to maintain the trust of the
      authorization/authentication, each hop will have to capture, and
      forward to one or more responders in the network.

    
For example

    
    
      
  1. EHR A sends out a patient record discovery request to it's
        upstream actor, that is forwarded to it's upstream HIN.
    2. 
      
  2. The HIN sends that request to all other HINs who forward it
        (depending on the capabilities of the HIN) to the various
        actors.=C2=A0 The originating user needs to be identified to the
        responders for audit and access consent. However, the cert that
        is used may (and likely will) change for each hop and be
        different the org that was the query source, which will still
        need to be identified to the responders
    
      
    3. 
      
  3. Some of those actors' EHRs respond saying they have data on
        that patient.
    4. 
      
  4. The responding HINs aggregates the responses and sends on
        bundle to the initiating HIN who forwards it via it's network to
        the query source
    5. 
      
  5. That source sends out a requests to saying "Send me the data
        from all the sources", that goes out, and results are aggregated
        on the way back into one bundle.=C2=A0 Same requirements as 2 
    
      
    6. 
    

    
All of that needs to be managed from a
      trust/authentication/authorization point of view. Simple, right?

    

    


    

    
On 2020-07-02 12:45 p.m., Tom Jones
      wrote:

    

    

      
      
without a better understanding of the "hop" it is
        hard to say. Does each "hop" archive the PHI in FHIR format? if
        so each would need to notify the user of access, as i see the
        problem. That sounds like something that would scare the
        patient. If the "hop" just handled (for example) an=C2=A0encrypted
        packet, that would not be a problem. OTOH if a federation were
        involved, the federation could notify the user. Less scary
        perhaps.

        

          

            

              
Peace ..tom

            

          

        

        

      

      

      

        
On Thu, Jul 2, 2020 at 9:41 A=
M
          David Pyke <david.pyke=3D40readycomputing.com@dmarc.ietf.org>
          wrote:

        

        

          

            
Great to hear!

            
My main concern is that the cert use may
                be an issue as it's passed through the hops.=C2=A0 A hop ma=
y
                want to have their predecessor=C2=A0 use the predecessor's
                cert coming in but may swap out their own cert for the
                next connection (and the same happening on the way
                back).=C2=A0 So, the ability to trace certs through the
                relaying would be an issue so that trust is maintained
                even when those certs aren't chained together.=C2=A0 It wou=
ld
                be good if there was one cert or a set of chained certs
                used for the two traversal but that's not likely to be
                the case..

            
Thanks!

            

            
On 2020-07-02 12:26 p.m., Tom Jones wrote:

            


            

            

              
We discussed that use case this morning in
                OIDC. A proposal has been made for a new endpoint that I
                would like to see working from the EHR endpoints. Did
                you have other concerns besides the source and
                destination=C2=A0endpoints for the data?

                

                  

                    

                      
Peace ..tom

                    

                  

                

                

              

              

              

                
On Thu, Jul 2, 2020 a=
t
                  8:30 AM David Pyke <david.pyke=3D40readycompu=
ting.com@dmarc.ietf.org>
                  wrote:

                

                

                  

                    
I am working on a Healthcare IT
                        project that requires multi-hop transmission of
                        REST based (FHIR: fhir.h=
l7.org)
                        resources.=C2=A0 The established protocol uses OAut=
h2
                        which doens't lend itself to multi-hop relay.

                    
I saw a presentation on XYZ/GNAP
                        and thought it might be early enough to get on
                        the train to consider how it might address that
                        structure.=C2=A0 The system I'm working on is from
                        the US Office of the National Coordinator for
                        Healthcare IT (ONC) called TEFCA.=C2=A0 At minimum
                        there would be 4 hops, at maximum, could be 8-10
                        and no bypassing of the network can be done.=C2=A0 =
As
                        I said, OAuth2 doesn't handle that without
                        significant issues.

                      

                    
If this is not a use case that can be considered,
                      please accept my apologies.

                    
Thanks

                    
Dave Pyke

                    

                    
-- 

                      

                        

                          
                            

                              
                                
 David
                                      Pyke

                              		
                            

                            

                              
                                
 Manager,
                                    Strategic Consulting

                              		
                            

                            

                              
                                
 ----------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
------------

                              		
                            

                            

                              
                                
 3D"Logo"

                                
 3D"LinkedIn 3D"Twitter 3D"Youtbue

                              		
                              
                                
Office: +1 212
                                    877 3307 x5001

                                

                                  
                                    

                                      
                                        

                                          
david.pyke@readycomputing.com

                                        

                                          
                                                www.readycomputing.com<=
/span>

                                      		
                                    

                                    

                                      
                                        
150
                                            Beekman Street, Floor 3, New
                                            York, NY 10038

                                      		
                                    

                                    

                                      

                                      		
                                    

                                  
                                

                              		
                            

                            

                              
                                

                                  The
                                    information in this e-mail
                                    communication together with any
                                    attachments is intended only for the
                                    person or entity to which it is
                                    addressed and may contain
                                    confidential and/or privileged
                                    material. If you are not the
                                    intended recipient of this
                                    communication, please notify us
                                    immediately. Any views expressed in
                                    this communication are those of the
                                    sender, unless otherwise
                                    specifically stated. Ready Computing
                                    does not represent, warrant or
                                    guarantee that the integrity of this
                                    communication has been maintained or
                                    the communication is free of errors,
                                    virus or interference.

                              		
                            

                          
                        

                      

                    

                  

                  

                  This is not a secure transmission. The information
                  contained in this transmission is highly prohibited
                  from containing privileged and confidential
                  information, including patient information protected
                  by federal and state privacy laws. It is intended only
                  for the use of the person(s) named above. If you are
                  not the intended recipient, you are hereby notified
                  that any review, dissemination, distribution, or
                  duplication of this communication is strictly
                  prohibited. If you are not the intended recipient,
                  please contact the sender by reply email and destroy
                  all copies of the original message. -- 

                  Txauth mailing list

                  Txauth@ietf.org

                  https://www.ietf.org/mailman/l=
istinfo/txauth

                

              

              

              

            

            
-- 

              

                

                  
                    

                      
                        
 <=
b>David Pyke

                      		
                    

                    

                      
                        
 =
M=
anager,
                            Strategic Consulting

                      		
                    

                    

                      
                        
 <=
span
                            style=3D"font-size:2pt;color:rgb(68,68,68)">---=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
----

                      		
                    

                    

                      
                        
 3D"Logo"

                        
 3D"LinkedIn 3D"Twitter 3D"Youtbue

                      		
                      
                        
Office:
                            +1 212 877 3307 x5001

                        

                          
                            

                              
                                

                                  
                                        david.pyke@readycomputing.com

                                

                                  
                                        www.readycomputing.com

                              		
                            

                            

                              
                                
150
                                    Beekman Street, Floor 3, New York,
                                    NY 10038

                              		
                            

                            

                              
                              
                            

                          
                        

                      		
                    

                    

                      
                        

                          The
                            information in this e-mail communication
                            together with any attachments is intended
                            only for the person or entity to which it is
                            addressed and may contain confidential
                            and/or privileged material. If you are not
                            the intended recipient of this
                            communication, please notify us immediately.
                            Any views expressed in this communication
                            are those of the sender, unless otherwise
                            specifically stated. Ready Computing does
                            not represent, warrant or guarantee that the
                            integrity of this communication has been
                            maintained or the communication is free of
                            errors, virus or interference.

                      		
                    

                  
                

              

            

          

          

          This is not a secure transmission. The information contained
          in this transmission is highly prohibited from containing
          privileged and confidential information, including patient
          information protected by federal and state privacy laws. It is
          intended only for the use of the person(s) named above. If you
          are not the intended recipient, you are hereby notified that
          any review, dissemination, distribution, or duplication of
          this communication is strictly prohibited. If you are not the
          intended recipient, please contact the sender by reply email
          and destroy all copies of the original message. -- 

          Txauth mailing list

          Txauth@ietf.org

          h=
ttps://www.ietf.org/mailman/listinfo/txauth

        

      

    

    
-- 

      
      
      
      
      

        

          
            

              
                

                  David Pyke
              

            

            

              
                

                  Manager,
                    Strategic Consulting

              		
            

            

              
                
 ---------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------------------------------------------------------------------<=
/p>
              

            

            

              
                

                  3D"Logo"

                

                  3D"LinkedIn 3D"Twitter 3D"Youtbue

              		
              
                
Offi=
ce:
                    +1 212 877 3307 x5001

                

                  
                    

                      
                        

                          
                                david.pyke@readycomputing.com

                        

                          
                                www.readycomputing.com

                      		
                    

                    

                      
                        
150
                            Beekman Street, Floor 3, New York, NY 10038

                      		
                    

                    

                      

                      		
                    

                  
                

              		
            

            

              
                

                  The
                    information in this e-mail communication together
                    with any attachments is intended only for the person
                    or entity to which it is addressed and may contain
                    confidential and/or privileged material. If you are
                    not the intended recipient of this communication,
                    please notify us immediately. Any views expressed in
                    this communication are those of the sender, unless
                    otherwise specifically stated. Ready Computing does
                    not represent, warrant or guarantee that the
                    integrity of this communication has been maintained
                    or the communication is free of errors, virus or
                    interference.

              		
            

          
        

      

    

  




This is not a secure transmission. The information contained in this=20
transmission is highly prohibited from containing privileged and=20
confidential information, including patient information protected by=20
federal and state privacy laws. It is intended only for the use of the=20
person(s) named above. If you are not the intended recipient, you are=20
hereby notified that any review, dissemination, distribution, or=20
duplication of this communication is strictly prohibited. If you are not
 the intended recipient, please contact the sender by reply email and=20
destroy all copies of the original message.
                       
--------------C9B6ED3A905631ED5B2A6A5D--


From nobody Thu Jul  2 10:34: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 4C2923A0B12 for ; Thu,  2 Jul 2020 10:34: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, 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 k5GC64ejha7m for ; Thu,  2 Jul 2020 10:34:02 -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 57A163A0B0E for ; Thu,  2 Jul 2020 10:34:02 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id o4so16733601lfi.7 for ; Thu, 02 Jul 2020 10:34: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=DE8mjb1UnbuX3sFxnGZboJfS1LwAavXEiU9c99IqBMY=; b=R4qfk/eAyXf5dS+PDjQR152UPAdMSBwBD1jh8lCN8BoEsWHCnuK4xm9/nZdspqiAum QyL+5mkp0vxOmv1e945bSiTc2YCvHHHmFY1UyLgHDv7chmHE0a2hDZHHtdDcE/EWVoCS D8Waxq9R0nX2mjF3iHkCaHnG4vHv32SgGZ4NVscutPkNJShvlJhDZvSKxkMKxp/o/hC8 KaasEq5Xxx39T32yiC6bKvav1l2PrzvMVMh7d7N9J7g4yafQW5GivpPCjuTjRwNYkZfL ui1pbaQ7XWvwoj8P6xVowDflbj3+cOWYG00N75ZIegxnwVdoVjF8fmywAP2kJ6s/4MNd kfcQ==
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=DE8mjb1UnbuX3sFxnGZboJfS1LwAavXEiU9c99IqBMY=; b=Mc4fuTF8UlX1bN1QnZQ23Za1TXBQzZ07XxV7+UIu/c7QtowZ+6TuhOpdBCDqkvedhd T2cSFMS8EKkA4foPtLol/dYOdghEMUlnDLtvsfFitMAt1mu3Dmbr3Q6IBmuBtL4li2pa GNj/sdGE+Qnc8eCodwJJocXFLEAjwS8y5HuJkBueKtw4OLOqquymdOPlxbgJ+bohTTuF FZXOeIzLSubFc4AdU2WqZu4Ji3DkQr/CxekAPIscwrQbx1lHhTMjlMv2qT2sgr/ZDCWW 7X7v7obKtzMip0umpAROPFRamskld00MY23FPx3i9E8kJlukTgZb2Ov3zcpWHpWeJJqD b+Ng==
X-Gm-Message-State: AOAM530/yKrQD6JVa9jgQ3RKfM1GJjL26MuDe0bRHnibjcw50n7M+6AD QxNg7hbxdVQkemwJWsSxnPm2UwAGlcvaMkcGyo8=
X-Google-Smtp-Source: ABdhPJzV1y0naxspd9n2wX6tfhVILOJ6iTdmsG/gLdFkYGmknq+Vn1wZEeGQDZBQe7c/tBS7cyigho7XN0COU+rpoc4=
X-Received: by 2002:a19:c8a:: with SMTP id 132mr18933460lfm.23.1593711239940;  Thu, 02 Jul 2020 10:33:59 -0700 (PDT)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 2 Jul 2020 10:33:24 -0700
Message-ID: 
To: Fabien Imbault 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000054e83405a978d076"
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 02 Jul 2020 17:34:04 -0000

--00000000000054e83405a978d076
Content-Type: text/plain; charset="UTF-8"

Hi Fabien, sorry for the late reply

Comments and questions inserted ...

On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault 
wrote:


>
> Beyond what I said on the redirect, we could probably benefit from a more
> formal definition of the flows (a bit different between the 2 proposals),
> as proposed recently by Francis Pouatcha for instance
> (interact/decoupled/embedded flows, TBD).
>

Which proposal was that?


>
> What I'm missing in both proposals (personal opinion):
>
> - I know that JSON is the usual format, but it would be really useful to
> complement the schemas with some JSON-LD descriptions as well. It would
> ease extensions and interoperability (by avoiding conflicting schemas), and
> could even provide a more generic way of representing verifiable
> presentations (challenge/nonce associated to a domain for instance). While
> most of this work on linked data has been done at W3C, it would add value
> to the current proposal so I think we should consider it.
>

I'm not understanding how JSON-LD would fit in. Would you provide an
example?


>
> - from an extensibility point of view, I'm not sure it's very useful to
> list all possibilities. For instance, as of now, it wouldn't be possible to
> use the protocol for constrained devices, so there's no real value in
> saying that it could be extended with CoAP (then we need a separate
> document, that references the current GNAP rfc). What's more useful to know
> if the context of the current document, when you're implementing it, is
> what behaviour can really be extended in a fairly straightforward
> way, without changing anything in the core spec. For instance, what can I
> do with other types of tokens than JWT? Neither proposal is very clear as
> to how we would implement extensions in practice.
>

In XAuth I refer to CoAP not as an extension, but as an one example of
other client authentication mechanisms. While it only applies to CoAP, I
think it is useful to call out how we intend GNAP to be extended.

Just like OAuth 2.0, the access token is opaque to the client, and it is
not specified, so I'm confused what you mean by "other types of tokens than
JWT"?




>
> - from an implementation perspective, it would make sense to decompose the
> flow between the Grant Server (GS) and the login/consent part (as done for
> instance by ory.sh). This way you would separate the concerns: on one side
> you have the HTTP flows (managed by the GS, which can be very optimized
> from a backend perspective), but you can delegate/customize the interaction
> UI to some agreed dedicated endpoint (typically a JS site). Maybe that's
> just a detail which doesn't have its place in the spec, but since it would
> change the flow, it might be important to consider, at least as a
> possibility/extension.
>

Is the interaction UI not part of the GS though? I agree that an
implementation can decompose those, but that sounds like an implementation
choice of the GS, and not something that requires standardization. I agree
that we want to anticipate the decomposition.* Is there a change in the
flow that would make that easier?

*One of the reasons I favor using URIs and methods for the different
functionality of the GS API is that it is easy for a router to route a
request to different components of the GS.

/Dick

>

--00000000000054e83405a978d076
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Fabien, sorry for the late reply
<=
br>
Comments and questions=C2=A0inserted ...=C2=A0
On Wed, J=
un 17, 2020 at 3:47 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
<snip>
=


Beyond what I said on the redirect, we=
 could probably benefit from a more formal definition of the flows (a bit d=
ifferent between the 2 proposals), as proposed recently by Francis Pouatcha=
 for instance (interact/decoupled/embedded flows, TBD).

Which proposal was that?
=C2=A0

What I'm missing in both proposals (personal op=
inion):=C2=A0

- I know that JSON is the usual form=
at, but it would be really useful to complement the schemas with some JSON-=
LD descriptions as well. It would ease extensions and interoperability (by =
avoiding conflicting schemas), and could even provide a more generic way of=
 representing verifiable presentations (challenge/nonce associated to a dom=
ain for instance). While most of this work on linked data has been done at =
W3C, it would add value to the current proposal so=C2=A0I think we should c=
onsider it.=C2=A0

I'm not u=
nderstanding how JSON-LD would fit in. Would you provide an example?
<=
div>=C2=A0

- from an extensibility point of view, I'm=
 not sure it's very useful to list all possibilities. For instance, as =
of now, it wouldn't be possible to use the protocol for constrained dev=
ices, so there's no real value in saying that it could be extended with=
 CoAP (then we need a separate document, that references the current GNAP r=
fc). What's more useful to know if the context of the current document,=
 when you're implementing it, is what behaviour can really be extended =
in a fairly straightforward way,=C2=A0without changing anything in the core=
 spec. For instance, what can I do with other types of tokens than JWT? Nei=
ther proposal is very clear as to how we would implement extensions in prac=
tice.

In XAuth I refer to CoAP =
not as an extension, but as an one example of other client authentication m=
echanisms. While it only applies to CoAP, I think it is useful to call out =
how we intend GNAP to be extended.=C2=A0

Just like=
 OAuth 2.0, the access token is opaque to the client, and it is not specifi=
ed, so I'm confused what you mean by "other types of tokens than J=
WT"?


=C2=A0

-=
 from an implementation perspective, it would make sense to decompose the f=
low between the Grant Server (GS) and the login/consent part (as done for i=
nstance by ory.sh). This way you would separate the concerns: on one side y=
ou have the HTTP flows (managed by the GS, which can be very optimized from=
 a backend perspective), but you can delegate/customize the interaction UI =
to some agreed dedicated endpoint (typically a JS site). Maybe that's j=
ust a detail which doesn't have its place in the spec, but since it wou=
ld change the flow, it might be important to consider,=C2=A0at least as a p=
ossibility/extension.

Is the in=
teraction UI not part of the GS though? I agree that an implementation can =
decompose those, but that sounds like an implementation choice of the GS, a=
nd not something that requires standardization. I agree that we want to ant=
icipate the decomposition.* Is there a change in the flow that would make t=
hat easier?

*One of the reasons I favor using URIs=
 and methods for the different functionality=C2=A0of the GS API is that it =
is easy for a router to route a request to different components of the GS.<=
/div>
=C2=A0
/Dick










--00000000000054e83405a978d076--


From nobody Thu Jul  2 10:44: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 BDD393A079A for ; Thu,  2 Jul 2020 10:44:12 -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 X1oPtM3p1vTO for ; Thu,  2 Jul 2020 10:44:11 -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 30D5C3A0798 for ; Thu,  2 Jul 2020 10:44:11 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id s1so33323905ljo.0 for ; Thu, 02 Jul 2020 10:44: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=CPuV9Jiz3gT21OWoQNOe2Wk8HdRXdybdQWthVR46RgY=; b=aGzz9ANQaoyVB8nkCnNRYJRNSJNpLP/swMeTXXzNwnD3LuWJLAt2EP2oK0262Dlxds +cInzgZl5r3eR3yDQt75Ao+IUwc+57bx9NN5UMyP7YDYU2asP4u2cCvtLM+O6l5O8IUA XJbC2gOOCLXQ5WltGGtjpBLB4bVbH99zbYF4eA7LhWaQCRYoxOceZKQ4E5sLEuF3QVoi iDVi3LZWLHQ2fNC9FUqjCKD1JZtSoAZv2Tt7erlWDI2H7cffSdcPYbiq7IN4f3kWQ/DH 8GLuAY6atLrgH6Oa4qaPnVPCoNyfdNrBeNmBtHPkhkfUc2wCMxPKH7yYGFR2gF9tPn1x Kr5Q==
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=CPuV9Jiz3gT21OWoQNOe2Wk8HdRXdybdQWthVR46RgY=; b=f2drSC6KuacupLxy/herUuPXuAv7J+TZA1XvR+dffNPHeK3jJFPxPAPspgWvUleYqv VffYOUmpUYD4Hq3zI/So9NnQYHs/pXk/ol06OjJ8Fw+3qBIAGgRAN2YNe5vt3vT/1/h0 2LTYngNyj+Tw9DJxa9uQpkVmfFnVpp6rzdHhTiGiLTCFeuEMrwvNtkpyrBeJ2hdGdQTT wSfJI4xcqIodjFPF0vXvUp61Hd6FSMhtraCiwrm5Ulcu6cw/AZKGYD5Qj69WwGJVGImF jI4fOYgA3guda1Wj1PWd0+H7aQJ18LMRfCZ+i+o6E7sM+iQIc76k8hTX1YS6bOOSgOPc xwSg==
X-Gm-Message-State: AOAM530BzfuClkbE4iDPbKLVb2+Ulu6gI8wn0+ol2yPspzQoctDbsjBN 3ffbwbZPm0DSqndhxM0DQgHfzCCQJ17rNcRC2iY=
X-Google-Smtp-Source: ABdhPJxd63LznzzZUqpWAiSIrs5sUcVfexsLBTddElez3ZZUNt+zXdBww35v7xYYOn4P4jLvIAifVkFqNHy5tesjNCA=
X-Received: by 2002:a2e:b5d0:: with SMTP id g16mr16202284ljn.246.1593711849163;  Thu, 02 Jul 2020 10:44:09 -0700 (PDT)
MIME-Version: 1.0
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu>  <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr>
In-Reply-To: <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr>
From: Dick Hardt 
Date: Thu, 2 Jul 2020 10:43:32 -0700
Message-ID: 
To: Denis 
Cc: Tom Jones , Justin Richer ,  txauth@ietf.org, Tobias Looker 
Content-Type: multipart/alternative; boundary="000000000000a4d00a05a978f455"
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 02 Jul 2020 17:44:13 -0000

--000000000000a4d00a05a978f455
Content-Type: text/plain; charset="UTF-8"

Apologies for the delayed response:

On Fri, Jun 26, 2020 at 9:04 AM Denis  wrote:

> The principle where a RS would only have relationships with one AS would
> make the model non scalable.
> It would prevent to get attributes from two different ASs,  for example:
> identity attributes from a bank and a master degree diploma from a
> university.
>

Where do you see that the RS can have a relationship with only one AS?


>
> For privacy reasons, every AS should know as little as possible about the
> interactions between a client and multiple RSs.
> It is even possible that this goes as little as knowing *nothing at all*.
>

OAuth 2.0 works this way now.


>
> The OAuth 2.0 assumption where the AS is in a position to know all the
> interactions of a given user has with all the RSs
> that an AS server has a relationship with should not be re-iterated.
>

I am still confused why you think the AS knows anything abou the
interactions a given use has with all the RSs. The AS knows which clients
the user is using, but does not need to have any knowledge of which RSs a
client is accessing.


The AS does not need to know anything about the RS. The RS clearly needs to
trust the AS, as it is trusting the access granted by the AS to the client,
but it is unidirectional trust between the RS and the AS.

/Dick

--000000000000a4d00a05a978f455
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Apologies for the delayed response:

On Fri, Jun 26, 20=
20 at 9:04 AM Denis <denis.ietf@fr=
ee.fr> wrote:

 =20
   =20
 =20
  

    
The principle where a RS would only
      have relationships with one AS would make the model non scalable.
=


      It would prevent to get attributes from two different ASs,=C2=A0 for
      example:=C2=A0 

      identity attributes from a bank and a master degree diploma from a
      university.

Where do =
you see that the RS can have a relationship with only one AS?
=C2=
=A0

    

    


    

    For privacy reasons, every AS should know as little as possible
    about the interactions between a client and multiple RSs.

    
It is even possible that this goes as
      little as knowing nothing at all.

OAuth 2.0 works this way now.=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">

    


    

    

      
The OAuth 2.0 assumption where the AS
        is in a position to know all the interactions of a given user
        has with all the RSs 

        that an AS server has a relationship with should not be
        re-iterated.

I am=
 still confused why you think the AS knows anything abou the interactions a=
 given use has with all the RSs. The AS knows which clients the user is usi=
ng, but does not need to have any knowledge of which RSs a client is access=
ing.
=C2=A0
=C2=A0
The AS does not need to kn=
ow anything about the RS. The RS clearly needs to trust the AS, as it is tr=
usting the access granted by the AS to the client, but it is unidirectional=
 trust between the RS and the AS.

/Dick


--000000000000a4d00a05a978f455--


From nobody Thu Jul  2 10:47: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 D1C093A060A for ; Thu,  2 Jul 2020 10:47:00 -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_REMOTE_IMAGE=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 kte-LyYWbprC for ; Thu,  2 Jul 2020 10:46:58 -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 CA8FE3A0602 for ; Thu,  2 Jul 2020 10:46:57 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id d4so24785885otk.2 for ; Thu, 02 Jul 2020 10:46: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=GI6VJfDd3B5I7XERu/5HjEHvmbMWXJR5M7Mg9stlFOk=; b=fkMZDDa9067U3KWIYuISwVOO+B9PoVFK7N4lTiy+sALGGP2Bfjv7PWqXKZZSb0bhnS ZyPyaVOjKmVp9zHne2+mR1llKTpg7kO/2PGnA08JPrroRXjg8kXuz51erUnXjVkVh/Iw urLHG2fYpkHDI3qOnIras4ItwXLnIhe8Vns5zA3jdMkHXO8hNSoP5yglUD9Le4COzHOU HNOY+dMtJC/ll91NjTxLxZ6f+C/y0zHyoXcPvskLbSa1oHFf5Zddr0Wv+0G8OdbnXGRt txyAWLdhobyjGVOZBOmZR5FP3iw+cSh0WVCRJI1cJbVtq+XngsxXvAp/g5I74hCSQV+j 6JGw==
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=GI6VJfDd3B5I7XERu/5HjEHvmbMWXJR5M7Mg9stlFOk=; b=fNLHzoKSA8v2TuXSK9hUoKgt7hTmXoDun+aKGzFCBLfaoT3PLyNR4cT6FIwoa6U29T Eb2tROW1zRtfW/Af/ZHIP7bkHSdZyeLbZkosS6zakS2DJm5SCaN+mG832CFRkvFkBrDI UaQHdpVpYmhX/zHXuiIidmxaO9Mpd1s/2LgvEnLjwCjcGcyD5uuK/r6WltZn+Rl1foCu eC9CBvxSVWg+Eypbmg28AH7jYM0LlCNeot90sXfT809hvfTCpzmMdFBZ/IUkqZk5yUIP V7iQE0AI9thoLEOdebBMFr5CFg8GRG7fLOrPV+5R+8+tBRLs/8KvuxWNSq5BCyNyJ3qS 8K0Q==
X-Gm-Message-State: AOAM533J8d4njEM5m+kdiTgHA51sPDW5ihHAISjRYsTaCxugsx0kZSyO kWL8k/0UJcTwG9W8kpTzeqVVkFIRI2IuAq5+dDbDKskOcuM=
X-Google-Smtp-Source: ABdhPJymPSG7jIgSdloxdKguQwCC3tHWUBwRLdmgDmV33Q4CzSq3ia+GaxqRppeOmwUGEr5JryE7Eb8mrye0oY9m06c=
X-Received: by 2002:a9d:66ca:: with SMTP id t10mr11790676otm.358.1593712016598;  Thu, 02 Jul 2020 10:46:56 -0700 (PDT)
MIME-Version: 1.0
References:   <3b8d3690-47e2-ff00-1065-29647d18555b@readycomputing.com>  <00827624-7361-4c5f-b34f-0edc8f7493dc@readycomputing.com>
In-Reply-To: <00827624-7361-4c5f-b34f-0edc8f7493dc@readycomputing.com>
From: Tom Jones 
Date: Thu, 2 Jul 2020 10:46:44 -0700
Message-ID: 
To: David Pyke 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009faa4905a978fe35"
Archived-At: 
Subject: Re: [Txauth] Possible Use Case for GNAP
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, 02 Jul 2020 17:47:01 -0000

--0000000000009faa4905a978fe35
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

My guess is that txauth is only concerned with the link between the user
(indirectly to get consent) the destination EHR, which is perversely called
the client of the user, and the RS which is the combined HIE in its
entirety. The RCE should work out the hop x hop stuff. This link (which i
sent out previously) is intended to address the patient as the AS with a
self issued ID. The interesting problem from health care is that the AS
consent will need to be in terms that the user understands, which is not
defined, and not the FHIR claims detail. The HIAWG of Kantara has taken on
the challenge of healthcare identity assurance semantics. A different
Kantara WG is working on the syntax of these messages.
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
Peace ..tom


On Thu, Jul 2, 2020 at 10:02 AM David Pyke 
wrote:

> Each hop relays the information but may have to do a transform on the dat=
a
> on the way through.  So, the data shouldn't be archived as the network is
> designed purely to route request and responses from originator to
> responder.  As such, there's no need for individual access notifications.
> However, the data is not necessarily encrypted as this is designed as a
> trusted network.  The FHIR query would be routed through to the responder=
,
> and the results routed back to the query originator.
>
> Notifications to the user would be not needed as to the originator system
> the network is (should be) transparent.  However, to maintain the trust o=
f
> the authorization/authentication, each hop will have to capture, and
> forward to one or more responders in the network.
>
> For example
>
>    1. EHR A sends out a patient record discovery request to it's upstream
>    actor, that is forwarded to it's upstream HIN.
>    2. The HIN sends that request to all other HINs who forward it
>    (depending on the capabilities of the HIN) to the various actors.  The
>    originating user needs to be identified to the responders for audit an=
d
>    access consent. However, the cert that is used may (and likely will) c=
hange
>    for each hop and be different the org that was the query source, which=
 will
>    still need to be identified to the responders
>    3. Some of those actors' EHRs respond saying they have data on that
>    patient.
>    4. The responding HINs aggregates the responses and sends on bundle to
>    the initiating HIN who forwards it via it's network to the query sourc=
e
>    5. That source sends out a requests to saying "Send me the data from
>    all the sources", that goes out, and results are aggregated on the way=
 back
>    into one bundle.  Same requirements as 2
>
> All of that needs to be managed from a trust/authentication/authorization
> point of view. Simple, right?
>
>
> On 2020-07-02 12:45 p.m., Tom Jones wrote:
>
> without a better understanding of the "hop" it is hard to say. Does each
> "hop" archive the PHI in FHIR format? if so each would need to notify the
> user of access, as i see the problem. That sounds like something that wou=
ld
> scare the patient. If the "hop" just handled (for example) an encrypted
> packet, that would not be a problem. OTOH if a federation were involved,
> the federation could notify the user. Less scary perhaps.
> Peace ..tom
>
>
> On Thu, Jul 2, 2020 at 9:41 AM David Pyke  40readycomputing.com@dmarc.ietf.org> wrote:
>
>> Great to hear!
>>
>> My main concern is that the cert use may be an issue as it's passed
>> through the hops.  A hop may want to have their predecessor  use the
>> predecessor's cert coming in but may swap out their own cert for the nex=
t
>> connection (and the same happening on the way back).  So, the ability to
>> trace certs through the relaying would be an issue so that trust is
>> maintained even when those certs aren't chained together.  It would be g=
ood
>> if there was one cert or a set of chained certs used for the two travers=
al
>> but that's not likely to be the case..
>>
>> Thanks!
>> On 2020-07-02 12:26 p.m., Tom Jones wrote:
>>
>> We discussed that use case this morning in OIDC. A proposal has been mad=
e
>> for a new endpoint that I would like to see working from the EHR endpoin=
ts.
>> Did you have other concerns besides the source and destination endpoints
>> for the data?
>> Peace ..tom
>>
>>
>> On Thu, Jul 2, 2020 at 8:30 AM David Pyke > 40readycomputing.com@dmarc.ietf.org> wrote:
>>
>>> I am working on a Healthcare IT project that requires multi-hop
>>> transmission of REST based (FHIR: fhir.hl7.org) resources.  The
>>> established protocol uses OAuth2 which doens't lend itself to multi-hop
>>> relay.
>>>
>>> I saw a presentation on XYZ/GNAP and thought it might be early enough t=
o
>>> get on the train to consider how it might address that structure.  The
>>> system I'm working on is from the US Office of the National Coordinator=
 for
>>> Healthcare IT (ONC) called TEFCA.  At minimum there would be 4 hops, at
>>> maximum, could be 8-10 and no bypassing of the network can be done.  As=
 I
>>> said, OAuth2 doesn't handle that without significant issues.
>>>
>>> If this is not a use case that can be considered, please accept my
>>> apologies.
>>>
>>> Thanks
>>>
>>> Dave Pyke
>>> --
>>>
>>> *David Pyke*
>>>
>>> Manager, Strategic Consulting
>>>
>>>
>>> -----------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-----------
>>>
>>> [image: Logo] 
>>>
>>> [image: LinkedIn icon]
>>>  [image: Twitter icon=
]
>>>  [image: Youtbue icon]
>>> 
>>>
>>> Office: +1 212 877 3307 x5001
>>>
>>> * david.pyke@readycomputing.com *
>>>
>>> * www.readycomputing.com *
>>>
>>> 150 Beekman Street, Floor 3, New York, NY 10038
>>>
>>> The information in this e-mail communication together with any
>>> attachments is intended only for the person or entity to which it is
>>> addressed and may contain confidential and/or privileged material. If y=
ou
>>> are not the intended recipient of this communication, please notify us
>>> immediately. Any views expressed in this communication are those of the
>>> sender, unless otherwise specifically stated. Ready Computing does not
>>> represent, warrant or guarantee that the integrity of this communicatio=
n
>>> has been maintained or the communication is free of errors, virus or
>>> interference.
>>>
>>> This is not a secure transmission. The information contained in this
>>> transmission is highly prohibited from containing privileged and
>>> confidential information, including patient information protected by
>>> federal and state privacy laws. It is intended only for the use of the
>>> person(s) named above. If you are not the intended recipient, you are
>>> hereby notified that any review, dissemination, distribution, or
>>> duplication of this communication is strictly prohibited. If you are no=
t
>>> the intended recipient, please contact the sender by reply email and
>>> destroy all copies of the original message. --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>> --
>>
>> *David Pyke*
>>
>> Manager, Strategic Consulting
>>
>>
>> ------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
----------
>>
>> [image: Logo] 
>>
>> [image: LinkedIn icon]  [image:
>> Twitter icon]  [image:
>> Youtbue icon] 
>>
>> Office: +1 212 877 3307 x5001
>>
>> * david.pyke@readycomputing.com *
>>
>> * www.readycomputing.com *
>>
>> 150 Beekman Street, Floor 3, New York, NY 10038
>>
>> The information in this e-mail communication together with any
>> attachments is intended only for the person or entity to which it is
>> addressed and may contain confidential and/or privileged material. If yo=
u
>> are not the intended recipient of this communication, please notify us
>> immediately. Any views expressed in this communication are those of the
>> sender, unless otherwise specifically stated. Ready Computing does not
>> represent, warrant or guarantee that the integrity of this communication
>> has been maintained or the communication is free of errors, virus or
>> interference.
>>
>> This is not a secure transmission. The information contained in this
>> transmission is highly prohibited from containing privileged and
>> confidential information, including patient information protected by
>> federal and state privacy laws. It is intended only for the use of the
>> person(s) named above. If you are not the intended recipient, you are
>> hereby notified that any review, dissemination, distribution, or
>> duplication of this communication is strictly prohibited. If you are not
>> the intended recipient, please contact the sender by reply email and
>> destroy all copies of the original message. --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> --
>
> *David Pyke*
>
> Manager, Strategic Consulting
>
>
> -------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------
>
> [image: Logo] 
>
> [image: LinkedIn icon] =
 [image:
> Twitter icon]  [image:
> Youtbue icon] 
>
> Office: +1 212 877 3307 x5001
>
> * david.pyke@readycomputing.com *
>
> * www.readycomputing.com *
>
> 150 Beekman Street, Floor 3, New York, NY 10038
>
> The information in this e-mail communication together with any attachment=
s
> is intended only for the person or entity to which it is addressed and ma=
y
> contain confidential and/or privileged material. If you are not the
> intended recipient of this communication, please notify us immediately. A=
ny
> views expressed in this communication are those of the sender, unless
> otherwise specifically stated. Ready Computing does not represent, warran=
t
> or guarantee that the integrity of this communication has been maintained
> or the communication is free of errors, virus or interference.
>
> This is not a secure transmission. The information contained in this
> transmission is highly prohibited from containing privileged and
> confidential information, including patient information protected by
> federal and state privacy laws. It is intended only for the use of the
> person(s) named above. If you are not the intended recipient, you are
> hereby notified that any review, dissemination, distribution, or
> duplication of this communication is strictly prohibited. If you are not
> the intended recipient, please contact the sender by reply email and
> destroy all copies of the original message.

--0000000000009faa4905a978fe35
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


My guess is that txauth is only concerned with the link be=
tween=C2=A0the user (indirectly to get consent) the destination EHR, which =
is perversely=C2=A0called the client of the user, and the RS which is the c=
ombined HIE in its entirety. The RCE should work out the hop x hop stuff. T=
his link (which i sent out previously) is intended to address the patient a=
s the AS with a self issued ID. The interesting problem from health care is=
 that the AS consent will need to be in terms that the user understands, wh=
ich is not defined, and not the FHIR claims detail. The HIAWG of Kantara ha=
s taken on the challenge of healthcare=C2=A0identity assurance=C2=A0semanti=
cs. A different Kantara WG is working on the syntax of these messages.=C2=
=A0=C2=A0
On Thu, Jul 2, 2020 at 10:02 AM David Pyke=
 <david.pyke@readycompu=
ting.com> wrote:

 =20
   =20
 =20
  

    
Each hop relays the information but may have to do a transform on
      the data on the way through.=C2=A0 So, the data shouldn't be arch=
ived
      as the network is designed purely to route request and responses
      from originator to=C2=A0 responder.=C2=A0 As such, there's no nee=
d for
      individual access notifications.=C2=A0 However, the data is not
      necessarily encrypted as this is designed as a trusted network.=C2=A0
      The FHIR query would be routed through to the responder, and the
      results routed back to the query originator. 

    

    
Notifications to the user would be not needed as to the
      originator system the network is (should be) transparent.=C2=A0
      However, to maintain the trust of the
      authorization/authentication, each hop will have to capture, and
      forward to one or more responders in the network.

    
For example

    
    
      
  1. EHR A sends out a patient record discovery request to it's
        upstream actor, that is forwarded to it's upstream HIN.
    2. 
      
  2. The HIN sends that request to all other HINs who forward it
        (depending on the capabilities of the HIN) to the various
        actors.=C2=A0 The originating user needs to be identified to the
        responders for audit and access consent. However, the cert that
        is used may (and likely will) change for each hop and be
        different the org that was the query source, which will still
        need to be identified to the responders
    
      
    3. 
      
  3. Some of those actors' EHRs respond saying they have data on
        that patient.
    4. 
      
  4. The responding HINs aggregates the responses and sends on
        bundle to the initiating HIN who forwards it via it's network t=
o
        the query source
    5. 
      
  5. That source sends out a requests to saying "Send me the data
        from all the sources", that goes out, and results are aggregat=
ed
        on the way back into one bundle.=C2=A0 Same requirements as 2 
    
      
    6. 
    

    
All of that needs to be managed from a
      trust/authentication/authorization point of view. Simple, right?

    

    


    

    
On 2020-07-02 12:45 p.m., Tom Jones
      wrote:

    

    

     =20
      
without a better understanding of the "hop"=
; it is
        hard to say. Does each "hop" archive the PHI in FHIR form=
at? if
        so each would need to notify the user of access, as i see the
        problem. That sounds like something that would scare the
        patient. If the "hop" just handled (for example) an=C2=A0=
encrypted
        packet, that would not be a problem. OTOH if a federation were
        involved, the federation could notify the user. Less scary
        perhaps.

        

          

            

              
Peace ..tom

            

          

        

        

      

      

      

        
On Thu, Jul 2, 2020 at 9:41 A=
M
          David Pyke <david.pyke=3D40readycomputing.com@dmarc.ietf.org=
>
          wrote:

        

        

          

            
Great to hear!

            
My main concern is that the cert use may
                be an issue as it's passed through the hops.=C2=A0 A ho=
p may
                want to have their predecessor=C2=A0 use the predecessor=
9;s
                cert coming in but may swap out their own cert for the
                next connection (and the same happening on the way
                back).=C2=A0 So, the ability to trace certs through the
                relaying would be an issue so that trust is maintained
                even when those certs aren't chained together.=C2=A0 It=
 would
                be good if there was one cert or a set of chained certs
                used for the two traversal but that's not likely to be
                the case..

            
Thanks!

            

            
On 2020-07-02 12:26 p.m., Tom Jones wrote:

            


            

            

              
We discussed that use case this morning in
                OIDC. A proposal has been made for a new endpoint that I
                would like to see working from the EHR endpoints. Did
                you have other concerns besides the source and
                destination=C2=A0endpoints for the data?

                

                  

                    

                      
Peace ..tom

                    

                  

                

                

              

              

              

                
On Thu, Jul 2, 2020 a=
t
                  8:30 AM David Pyke <david.pyke=3D40readycomputing.com@dm=
arc.ietf.org>
                  wrote:

                

                

                  

                    
I am working on a Healthcare IT
                        project that requires multi-hop transmission of
                        REST based (FHIR: fhir.hl7.org)
                        resources.=C2=A0 The established protocol uses OAut=
h2
                        which doens't lend itself to multi-hop relay.

                    
I saw a presentation on XYZ/GNAP
                        and thought it might be early enough to get on
                        the train to consider how it might address that
                        structure.=C2=A0 The system I'm working on is f=
rom
                        the US Office of the National Coordinator for
                        Healthcare IT (ONC) called TEFCA.=C2=A0 At minimum
                        there would be 4 hops, at maximum, could be 8-10
                        and no bypassing of the network can be done.=C2=A0 =
As
                        I said, OAuth2 doesn't handle that without
                        significant issues.

                      

                    
If this is not a use case that can be considered,
                      please accept my apologies.

                    
Thanks

                    
Dave Pyke

                    

                    
-- 

                      

                        

                          
                            

                              
                                
 David
                                      Pyke

                              		
                            

                            

                              
                                
 Manager,
                                    Strategic Consulting

                              		
                            

                            

                              
                                
 ------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
----------------------------------------------------------------

                              		
                            

                            

                              
                                
 3D"Logo"

                                
 3D"LinkedIn 3D"Twitter 3D"Youtbue

                              		
                              
                                
Office: +1 212
                                    877 3307 x5001

                                

                                  
                                    

                                      
                                        

                                          
david.pyke@readycomputing.com

                                        

                                          
                                                www.readycomputing.com<=
/span>

                                      		
                                    

                                    

                                      
                                        
150
                                            Beekman Street, Floor 3, New
                                            York, NY 10038

                                      		
                                    

                                    

                                      

                                      		
                                    

                                  
                                

                              		
                            

                            

                              
                                

                                  The
                                    information in this e-mail
                                    communication together with any
                                    attachments is intended only for the
                                    person or entity to which it is
                                    addressed and may contain
                                    confidential and/or privileged
                                    material. If you are not the
                                    intended recipient of this
                                    communication, please notify us
                                    immediately. Any views expressed in
                                    this communication are those of the
                                    sender, unless otherwise
                                    specifically stated. Ready Computing
                                    does not represent, warrant or
                                    guarantee that the integrity of this
                                    communication has been maintained or
                                    the communication is free of errors,
                                    virus or interference.

                              		
                            

                          
                        

                      

                    

                  

                  

                  This is not a secure transmission. The information
                  contained in this transmission is highly prohibited
                  from containing privileged and confidential
                  information, including patient information protected
                  by federal and state privacy laws. It is intended only
                  for the use of the person(s) named above. If you are
                  not the intended recipient, you are hereby notified
                  that any review, dissemination, distribution, or
                  duplication of this communication is strictly
                  prohibited. If you are not the intended recipient,
                  please contact the sender by reply email and destroy
                  all copies of the original message. -- 

                  Txauth mailing list

                  Txau=
th@ietf.org

                  https://www.ietf.org/mailman/listinfo/=
txauth

                

              

              

              

            

            
-- 

              

                

                  
                    

                      
                        
 <=
b>David Pyke

                      		
                    

                    

                      
                        
 =
Manager,
                            Strategic Consulting

                      		
                    

                    

                      
                        
 <=
span style=3D"font-size:2pt;color:rgb(68,68,68)">--------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
--------------------------------------------------------

                      		
                    

                    

                      
                        
 3D"Logo"

                        
 3D"LinkedIn 3D"Twitter 

                      		
                      
                        
Office:
                            +1 212 877 3307 x5001

                        

                          
                            

                              
                                

                                  
                                        david.pyke@readycomputing.com

                                

                                  
                                        www.readycomputing.com

                              		
                            

                            

                              
                                
150
                                    Beekman Street, Floor 3, New York,
                                    NY 10038

                              		
                            

                            

                              
                              
                            

                          
                        

                      		
                    

                    

                      
                        

                          The
                            information in this e-mail communication
                            together with any attachments is intended
                            only for the person or entity to which it is
                            addressed and may contain confidential
                            and/or privileged material. If you are not
                            the intended recipient of this
                            communication, please notify us immediately.
                            Any views expressed in this communication
                            are those of the sender, unless otherwise
                            specifically stated. Ready Computing does
                            not represent, warrant or guarantee that the
                            integrity of this communication has been
                            maintained or the communication is free of
                            errors, virus or interference.

                      		
                    

                  
                

              

            

          

          

          This is not a secure transmission. The information contained
          in this transmission is highly prohibited from containing
          privileged and confidential information, including patient
          information protected by federal and state privacy laws. It is
          intended only for the use of the person(s) named above. If you
          are not the intended recipient, you are hereby notified that
          any review, dissemination, distribution, or duplication of
          this communication is strictly prohibited. If you are not the
          intended recipient, please contact the sender by reply email
          and destroy all copies of the original message. -- 

          Txauth mailing list

          Txauth@ietf.=
org

          https://www.ietf.org/mailman/listinfo/txauth

        

      

    

    
-- 

     =20
     =20
     =20
     =20
      

        

          
            

              
                

                  David Pyke<=
/b>

              		
            

            

              
                

                  Manag=
er,
                    Strategic Consulting

              		
            

            

              
                
 ----------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
------------------------------------------------

              		
            

            

              
                

                  3D"Logo"

                

                  3D"LinkedIn =3D"Twitter 3D"Youtbue

              		
              
                
Office=
:
                    +1 212 877 3307 x5001

                

                  
                    

                      
                        

                          
                                david.pyke@readycomputing.com

                        

                          
                                www.readycomputing.com

                      		
                    

                    

                      
                        
150
                            Beekman Street, Floor 3, New York, NY 10038

                      		
                    

                    

                      

                      		
                    

                  
                

              		
            

            

              
                

                  The
                    information in this e-mail communication together
                    with any attachments is intended only for the person
                    or entity to which it is addressed and may contain
                    confidential and/or privileged material. If you are
                    not the intended recipient of this communication,
                    please notify us immediately. Any views expressed in
                    this communication are those of the sender, unless
                    otherwise specifically stated. Ready Computing does
                    not represent, warrant or guarantee that the
                    integrity of this communication has been maintained
                    or the communication is free of errors, virus or
                    interference.

              		
            

          
        

      

    

  





This is not a secure transmission. The information contained in this=20
transmission is highly prohibited from containing privileged and=20
confidential information, including patient information protected by=20
federal and state privacy laws. It is intended only for the use of the=20
person(s) named above. If you are not the intended recipient, you are=20
hereby notified that any review, dissemination, distribution, or=20
duplication of this communication is strictly prohibited. If you are not
 the intended recipient, please contact the sender by reply email and=20
destroy all copies of the original message.
                       


--0000000000009faa4905a978fe35--


From nobody Thu Jul  2 10:56: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 A6F1E3A078F for ; Thu,  2 Jul 2020 10:56:08 -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 JtZNTs4Lv6-I for ; Thu,  2 Jul 2020 10:56:07 -0700 (PDT)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0: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 326343A078C for ; Thu,  2 Jul 2020 10:56:07 -0700 (PDT)
Received: by mail-oi1-x233.google.com with SMTP id t4so6548014oij.9 for ; Thu, 02 Jul 2020 10:56: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=f/wcJ91dA375XbEP6ATBvZ9VovGkkb87EQA6DAUAtYw=; b=TtLUyKUro9GcQiOGynI1oBVxnloO6LmNQMqZ0Z3gduw0OzFbDIJbb8gqRpCXL9YC/j j+46GU3YTW/nFVF2kHS+rytVnq9uhzNT2wISYXVoXDx0u6nHsPZmadfwmoMqmSSZojTP JmGIypBESNbhhuUqbBf5nDKt7AtZ/aXQVJa6oFogee+QyCtdvX75nHds5wM31wLfXmod 1M4ZExqPRq1OklmOQ6e6zmrQIktL3KYk57M6fdVxBD/iSzFT3cPacdyRiDmBgo9Ni2DJ NoOf6hLUBVaKyXknX+ARrrJnP8ehqOtDY8Hq1AKb7N5aXjqLngAhiKK5ua2JbVtt7J6q 2q7g==
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=f/wcJ91dA375XbEP6ATBvZ9VovGkkb87EQA6DAUAtYw=; b=FJNG4rDtTGH+DTlT4y1iwY50LYxxlKqNyv3lL+SvqpG3KYQX3pyGltTA+a4j+U8mFP z1xXHbAp5dpI3khx6fED3B6BppBQq1i+s9QcqGJsXWxitmU27JiQKLWkuoM4L7xCaUlo gr00tNWK4P05IsF7AbMQ6skcAZ7Xf78ntBNVjU8Sce7HwQkx0QZ2ToLhDorUYGsXXKk8 fSxRsiAa3/UzLVAJRUu1pOAAq09m6Rt1leaDBy8nK2Mm/bgBupKAGjZ9tQbOn6No2nlN xAupv3QdBonWO4bBuyY/00TiL2vXtaVBQ1gOyiku6kT1Ktb9PliBubayDDewSZHjVRYF P9pA==
X-Gm-Message-State: AOAM531ik3Uo6lkdq/6U1oU3v6SpigGd7bakUavqj5iTQDotk4+rGk0B hAz2FJ1hja/2mu2ZCBwqZURiCsJTANeBX4TD37Q=
X-Google-Smtp-Source: ABdhPJy/C9ckP7nZUOS2U9zDPuEO8s15A7L8fP1klcF967lQ1O5fXsWkEU6nc0zqrE0rf5HYUR9qKYJPpZFmtMGURbE=
X-Received: by 2002:aca:43c6:: with SMTP id q189mr24578036oia.63.1593712566478;  Thu, 02 Jul 2020 10:56:06 -0700 (PDT)
MIME-Version: 1.0
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu>  <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr> 
In-Reply-To: 
From: Tom Jones 
Date: Thu, 2 Jul 2020 10:55:55 -0700
Message-ID: 
To: Dick Hardt 
Cc: Denis , Justin Richer , txauth@ietf.org, Tobias Looker 
Content-Type: multipart/alternative; boundary="000000000000662aa405a9791ff6"
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 02 Jul 2020 17:56:09 -0000

--000000000000662aa405a9791ff6
Content-Type: text/plain; charset="UTF-8"

Dick, the statement about the AS and RS is not always true. In federations
we are always concerned that information is not leaked outside the approved
parties and the AS messages will likely be encrypted for the sole use of
the RS.
Peace ..tom


On Thu, Jul 2, 2020 at 10:44 AM Dick Hardt  wrote:

> Apologies for the delayed response:
>
> On Fri, Jun 26, 2020 at 9:04 AM Denis  wrote:
>
>> The principle where a RS would only have relationships with one AS would
>> make the model non scalable.
>> It would prevent to get attributes from two different ASs,  for example:
>> identity attributes from a bank and a master degree diploma from a
>> university.
>>
>
> Where do you see that the RS can have a relationship with only one AS?
>
>
>>
>> For privacy reasons, every AS should know as little as possible about the
>> interactions between a client and multiple RSs.
>> It is even possible that this goes as little as knowing *nothing at all*.
>>
>
> OAuth 2.0 works this way now.
>
>
>>
>> The OAuth 2.0 assumption where the AS is in a position to know all the
>> interactions of a given user has with all the RSs
>> that an AS server has a relationship with should not be re-iterated.
>>
>
> I am still confused why you think the AS knows anything abou the
> interactions a given use has with all the RSs. The AS knows which clients
> the user is using, but does not need to have any knowledge of which RSs a
> client is accessing.
>
>
> The AS does not need to know anything about the RS. The RS clearly needs
> to trust the AS, as it is trusting the access granted by the AS to the
> client, but it is unidirectional trust between the RS and the AS.
>
> /Dick
>

--000000000000662aa405a9791ff6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dick, the statement about the AS and RS is not always true=
. In federations we are always concerned that information is not leaked out=
side the approved parties and the AS messages will likely be encrypted for =
the sole use of the RS.
Peac=
e ..tom


On Thu, Jul 2, 2020 at 10:44 AM Dick Har=
dt <dick.hardt@gmail.com>=
 wrote:
Apologies for the delayed response:

On Fri, Jun 26, 2020 at 9:=
04 AM Denis <den=
is.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
The principle where a RS would only
      have relationships with one AS would make the model non scalable.
=


      It would prevent to get attributes from two different ASs,=C2=A0 for
      example:=C2=A0 

      identity attributes from a bank and a master degree diploma from a
      university.

Where do =
you see that the RS can have a relationship with only one AS?
=C2=
=A0

    

    


    

    For privacy reasons, every AS should know as little as possible
    about the interactions between a client and multiple RSs.

    
It is even possible that this goes as
      little as knowing nothing at all.

OAuth 2.0 works this way now.=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">

    


    

    

      
The OAuth 2.0 assumption where the AS
        is in a position to know all the interactions of a given user
        has with all the RSs 

        that an AS server has a relationship with should not be
        re-iterated.

I am=
 still confused why you think the AS knows anything abou the interactions a=
 given use has with all the RSs. The AS knows which clients the user is usi=
ng, but does not need to have any knowledge of which RSs a client is access=
ing.
=C2=A0
=C2=A0
The AS does not need to kn=
ow anything about the RS. The RS clearly needs to trust the AS, as it is tr=
usting the access granted by the AS to the client, but it is unidirectional=
 trust between the RS and the AS.

/Dick




--000000000000662aa405a9791ff6--


From nobody Thu Jul  2 11:00: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 9C0E43A0BA0; Thu,  2 Jul 2020 11:00: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 8ix1gOcoplzU; Thu,  2 Jul 2020 11:00:19 -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 EFF363A0B98; Thu,  2 Jul 2020 11:00:18 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id f8so21090083ljc.2; Thu, 02 Jul 2020 11:00: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=JOdI2dJ4jzn7evDlBonp7raM68ORHTKndz01df/1Mqs=; b=UanBJWs5IsMYsQVLcmKsAuLAc/TmJzSQwKYQrei/CHfIf6IQV5NLy5LAXlxo3Q9rTn k17npC5B7Bg1EpDiJj+9ovpGwFoQK8Lb9AOWhHtOlkfD1Suc3H4D1D4mRGwOyes/kzFo clep4i+K+2hP91yrzv5/R3etyaZkBQxd368WqThfPWczxngDY+jgK/RyqW+ViKFdgISd kEj3UhtoOTzFrRixrVmTS5KeWTHwdP2MhoZeOB1x709zJYfk65+/9gO28uDsigo1VmKN WN4DDidPO9A09UudSG+HdViJhfJvNuXV7wyFhWaBitGxDu7Kn5fBw2WbMw1d4Pi3b4R5 0URw==
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=JOdI2dJ4jzn7evDlBonp7raM68ORHTKndz01df/1Mqs=; b=bDBvQabUv8aG6CR2LGCyhb5It81TCIjzofiC5dVvDwmygOKFBrFW4nYRQfurs+HlnI kIf4eNnvx7QfRO1aEV4htf8V7sbJk4j2Gbfg62+9rdPoGEzjjsw2U9I1uOtvusvBmGUK 1y8OSCEbueJ46w9KBMxi+LI+BFk0bmKUJwI0eMItyo8SjdxAhv9zjDNp0VFkF0exmSbw KHc2IslwrvMacs9m6/wLOyLJFNjIm6OeOEkEMKDAxXo3tc53l52CVflKrlYoH/lY/GKK Q8cSsQs2uZSWOgQ1Am2urlbaVXNFynd4O0SfnRVj8B3XWPoNSK78JfpfsDS3RI/pBZll +gaA==
X-Gm-Message-State: AOAM530WzpaougmEVT2uxQwl1QnFNoJ/C7WcL6HR2gBlA3eJLEjZcw5x XkHOyCzrJADosjk1yvHSCY83c53AitOEsiqCLTtPyYb0ZXo=
X-Google-Smtp-Source: ABdhPJyjBr2Nob5S6KIdpPVND1qsxvNG+YeTyJIiuxzWM4mf0arfeNwzJYUl6JZMLnSyd/LW2xxrzOIEdWbZmmeoWow=
X-Received: by 2002:a2e:b70b:: with SMTP id j11mr2803950ljo.142.1593712816833;  Thu, 02 Jul 2020 11:00:16 -0700 (PDT)
MIME-Version: 1.0
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com>   
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 2 Jul 2020 10:59:40 -0700
Message-ID: 
To: Denis 
Cc: iesg@ietf.org, txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000524ba505a9792ebb"
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 02 Jul 2020 18:00:22 -0000

--000000000000524ba505a9792ebb
Content-Type: text/plain; charset="UTF-8"

Catching up on this email ... comments inserted ...

On Mon, Jun 29, 2020 at 12:06 AM Denis  wrote:

> Hello Dick,
>
> Denis, thanks for sharing your thoughts, some clarifications on your
> statements inserted:
>
> On Fri, Jun 26, 2020 at 9:42 AM Denis  wrote:
> 
>
>> *New proposed charter*
>>
>> 
>
>>
>> Resource servers inform their clients about which access token formats
>> are acceptable and depending upon the king of operation
>> that is requested, which kind of attributes are needed and from which ASs
>> that my be obtained.
>>
>> While at times this may be appropriate, at other times disclosing the
> attributes the RS requires is not needed by the client.
> For example, an enterprise client accessing a resource does not need to
> know which groups a user belongs to,
> but the RS may require that to determine if the user running the client
> has access.
>
> As soon as there is a desire to implement privacy by default, the client
> should not provide more attributes than strictly necessary.
> Even after three readings of your example, I failed to understand it.
>
>
>> A major difference with OAuth 2.0 is that there is no bilateral trust
>> relationship between an authorization server and a resource server:
>> for a given category of attributes, a resource server may trust one or
>> more authorization servers. Another major difference with OAuth 2.0.
>> is that the content of an attributes token is meant to be accessible to
>> the client.
>>
>> This is not how OAuth 2.0 works. See slides 7 and 8 from my original IETF
> presentation on what became OAuth 2.0
>
> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation
>
> I looked at the two slides.
>
> Unfortunately slide 7 has just one arrow with the word "trust". This is
> insufficient to understand what is meant unless being present
> at the presentation. Does it mean that the PR (RS) trusts one AS or that
> it may trust multiple ASs ?
>
Unfortunately slide 8 has just one arrow between the PR and the AS which is
> red-crossed but no text at all. This is insufficient to understand
> what is meant unless being present at the presentation. Does it mean that
> the PR and the AS never communicate directly ?
> Does it mean that they have no relationships at all, besides the one way
> trust relationship mentioned in slide 7 ?
>
> So it hard to say whether these two slides are indeed meaning that there
> is no bilateral relationship between an authorization server and a resource
> server.
>
Apologies for not providing an explanation on the slides.

Slide 7 shows that trust between the AS and PR (now RS) was unidirectional,
from the RS to the AS.
Slide 8 indicates that trust is not bidirectional.

There is no limit on how many ASs an RS may trust.


> On June 12, Nat Sakimura recently answered to an email with the following
> topic:
>
> Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
> Authorization Framework: JWT Secured Authorization Request))
>
> My arguments were:
>
>      The original model for OAuth was making the assumption that the AS
> and the RS had a strong bilateral relationship.
>
>       *A key question is whether such strong relationship will be
> maintained for ever *or
>      whether it will be allowed to perform some evolutions of this
> relationship.
>
>      In order to respect the privacy of the users, there is the need to
> encompass other scenarios. One of these scenarios is that the AS and the RS
>      do not need any longer to have such a strong relationship. In terms
> of trust relationships, a RS simply needs to trust the access tokens issued
> by an AS.
>      The AS does have any more a "need to know" of all the RSs that are
> accepting its access tokens. This would be a major simplification of the
> current global architecture.
>
> Nat's position was:
>
> "My take is that the basic assumption of OAuth 2.0 Framework is that there
> is a strong relationship between AS and RS.
> I feel that it is quite unrealistic that an RS would trust the access
> token issued by an AS that it has no strong relationship with".
>
> There are indeed different positions on this topic.
>

I don't think Nat and I have different opinions, but I will let Nat clarify.
Just because there is a strong relationship between the AS and RS, does not
mean it is bidirectional. I would understand

"I feel that it is quite unrealistic that an RS would trust the access
token issued by an AS that it has no strong relationship with"

to indicate Nat is expecting the trust to be from the RS to the AS.



>
> The AS may not even know who the RS (or PR in the slides) is.
>
> 
>
>>
>> I got rid of the word "delegation": the client does not delegate anything
>> to an authorization server. If it would, this would mean that the
>> authorization server
>> would be able to act as the client and could know everything that the
>> client will do, which comes into contradiction with the user's privacy.
>>
>
> The above is not true.
>
> The Resource Owner is delegating access control to the AS in authorization
> use cases.
>
> The OAuth 2.0 model does not mandate any more the presence of a Resource
> Owner.
>

Why do you say that? The RO is who owns the RS. Your statement does not
make sense.


>
> The client is may be delegating user authentication to the AS in identity
> claim use cases.
>
> Delegating user authentication to the AS is different from delegating
> access control to the AS.
>

Agreed. Your statement was there was no delegation. I'm explaining there
are potentially two delegations.

>
> The AS can act as the client in many OAuth deployments, as the access
> token is a bearer token.
>
> A bearer token is rather insecure.
>
Cookies are also bearer tokens. But we use them all the time in web apps
for storing session state and prior authentication! :)



> That does not mean the AS knows what the client is doing.
>
> There are currently two attempts in the OAuth WG to let know to the AS
> what the client is doing:
>
>    - draft-ietf-oauth-jwsreq-22   (The OAuth 2.0 Authorization Framework:
>    JWT Secured Authorization Request)
>    - draft-ietf-oauth-rar-01         (OAuth 2.0 Rich Authorization
>    Requests)
>
> Those are optional, and in some situations are a desired property.

/Dick

--000000000000524ba505a9792ebb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Ca=
tching up on this email ... comments inserted ...

On Mon, Jun 29, 2020 at 12=
:06 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hello Dick,

    


      

    

     =20
      

        
Denis, thanks for sharing you=
r
            thoughts, some clarifications on your statements inserted:

        

        
        

          
On Fri=
,
              Jun 26, 2020 at 9:42 AM Denis <denis.ietf@free.fr>
              wrote:

          
<snip>

          

            

              

                

                  
New proposed charter

                

              

            

          

          
<snip>=C2=A0

          

            

              

                
 

                            Resource servers inform their clients about
                            which access token formats are acceptable
                            and depending upon the king of operation=


                            that is requested, which kind of attributes
                            are needed and from which ASs that my be
                            obtained.<=
span lang=3D"EN-US">

                              

                      

              

            

          

          
While at times this may be
              appropriate, at other times disclosing the attributes the
              RS requires is not needed by the client. 

              For example, an enterprise client accessing a resource
              does not need to know which groups a user belongs to, 

              but the RS may require that to determine if the user
              running the client has access.

            

        

      

    

    
As soon as there is a desire to implement
        privacy by default, the client should not provide more
        attributes than strictly necessary. 

        Even after three readings of your example, I failed to
        understand it.

      

    

      

        

          

            

              

                
 

                        A major difference with OAuth 2.0 is that there
                        is no bilateral trust relationship between an
                        authorization server and a resource server: =


                        for a given category of attributes, a resource
                        server may trust one or more authorization
                        servers. Another major difference with OAuth 2.0.

                        is that the content of an attributes token is
                        meant to be accessible to the client.=


              

            

          

          
This is not how OAuth 2.0 works. See
              slides 7 and 8 from my original IETF presentation on what
              became OAuth 2.0

          


            

          
        

      

    

    
I looked at the two slides. 

      

    
Unfortunately slide 7 has just one arrow with
        the word "trust". This is insufficient to understand what=
 is
        meant unless being present 

        at the presentation. Does it mean that the PR (RS) trusts one AS
        or that it may trust multiple ASs ?

      

    
Unfortunately slide 8 has just one arrow
        between the PR and the AS which is red-crossed but no text at
        all. This is insufficient to understand

        what is meant unless being present at the presentation. Does it
        mean that the PR and the AS never communicate directly ?

        Does it mean that they have no relationships at all, besides the
        one way trust relationship mentioned in slide 7 ?

    
So it hard to say whether these two slides are
        indeed meaning that there
            is no bilateral relationship between an authorization server
            and a resource server.
Apologies for not providing an explanation on the slides.

Slide 7 shows that trust between the AS and PR (now RS=
) was unidirectional, from the RS to the AS.
Slide 8 indicates=C2=
=A0that trust is not bidirectional.

There is no li=
mit on how many ASs an RS may trust.
=C2=A0

    
On Jun=
e
          12, Nat Sakimura recently answered to an email with
        the following topic:

    
    
    

      
Re: [OAUTH-WG] Comments o=
n
          draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
          Authorization Framework: JWT Secured Authorization Request))

    

    
    
    
My arguments were:
    
    
    
=C2=A0=C2=A0=C2=A0=C2=A0 Th=
e original model
        for OAuth was making the assumption that the AS and the RS had a
        strong
        bilateral relationship.

      

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
      A key question is whether such strong
          relationship will be maintained for
          ever or 

      =C2=A0=C2=A0=C2=A0=C2=A0 whether it will be allo=
wed to perform some
        evolutions of this
        relationship.

      

      =C2=A0=C2=A0=C2=A0=C2=A0 In order to respect the=
 privacy of the
        users, there is the need to encompass
        other scenarios. One of these scenarios is that the AS and the
        RS 

      =C2=A0=C2=A0=C2=A0=C2=A0 do not need
        any longer to have such a strong relationship. In terms of trust
        relationships,
        a RS simply needs to trust the access tokens issued by an AS. 

      =C2=A0=C2=A0=C2=A0=C2=A0 The AS does have
        any more a "need to know" of all the RSs that are accepti=
ng its
        access tokens. This would be a major simplification of the
        current global
        architecture.

    
    
    
Nat's position was: 
      

    
    
    

      
"My take is that the=
 basic
          assumption of OAuth 2.0 Framework is
          that there is a strong relationship between AS and RS. 

          I feel that it is quite
          unrealistic that an RS would trust the access token issued by
          an AS that it has
          no strong relationship with".

    

    
    
    
There are indeed different
        positions on this topic.=C2=A0 

I don't think Nat and I have different opinions, but =
I will let Nat clarify.
Just because there is a strong relationsh=
ip between the AS and RS, does not mean it is bidirectional. I would unders=
tand=C2=A0

"I feel that it is quite
          unrealistic that an RS would trust the access token issued by
          an AS that it has
          no strong relationship with"

to ind=
icate Nat is expecting the trust to be from the RS to the AS.
=C2=A0
<=
div>

      

    

      

        

          


            

          
The AS may not even know who the RS
              (or PR in the slides) is.

          


            

          
<snip>=C2=A0

          

            

              

                
 

                        I got rid of the word "delegation": the c=
lient
                        does not delegate anything to an authorization
                        server. If it would, this would mean that the
                        authorization server 

                        would be able to act as the client and could
                        know everything that the client will do, which
                        comes into contradiction with the user's
                        privacy.

                      

              

            

          

          


            

          
The=C2=A0above is not true.
          
=C2=A0

          
The Resource Owner is delegating
              access control to the AS in authorization use cases.
        

      

    

    
The OAuth 2.0 model does not mandate any more
        the presence of a Resource Owner.

Why do you say that? The RO is who owns the RS. Your statem=
ent does not make sense.
=C2=A0

    

      

        

          


            

          
The client is may be delegating user
              authentication to the AS in identity claim use cases.<=
/div>
        

      

    

    
Delegating user authentication to the AS is
        different from delegating access control to the AS.

Agreed. Your statement was there was no d=
elegation. I'm explaining there are potentially=C2=A0two delegations.=
=C2=A0

    

      

        

          


            

          
The AS can act as the client in many
              OAuth deployments, as the access token is a bearer token.
            

        

      

    

    
A bearer token is rather insecure.
Cookies are also bearer tokens. But we use them all t=
he time in web=C2=A0apps for=C2=A0storing session state=C2=A0and prior auth=
entication! :)

=C2=A0

    

      

        

          
That does not mean the AS knows what
              the client is doing. 

            

        

      

    

    
There are currently two attempts in the OAuth
        WG to let know to the AS what the client is doing:

    
    
      
  • draft-ietf-oauth-jwsreq-22=C2=A0=C2=A0 (The =
OAuth 2.0
          Authorization Framework: JWT Secured Authorization Request)
    • 
      
  • draft-ietf-oauth-rar-01 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 (OAuth 2.0
          Rich Authorization Requests)
<=
div>Those are optional, and in some situations are a desired property.
=C2=A0
/Dick



--000000000000524ba505a9792ebb--


From nobody Thu Jul  2 11:01: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 BA2243A0BD6 for ; Thu,  2 Jul 2020 11:01:44 -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 fqkOVeji9VdA for ; Thu,  2 Jul 2020 11:01:43 -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 076E33A0BD4 for ; Thu,  2 Jul 2020 11:01:43 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id n23so33406431ljh.7 for ; Thu, 02 Jul 2020 11:01: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=X2YGvBVIdzOACuXDRRFW7y2PYeVQ7Ek8CGiWNWfpw8w=; b=sjCXlpvkfqfK459RztI21H+FBqJ1rnGy85cmYDAoBhSA7iURavJIx7no17JtoL9qGM iswskSWjEjh9ofXS71XotwdcGoRD5rtko2+UUXplsEiuyK+M5jZ1bVhFx8vJqZRzOuYu i+ib91k7E1WrrOHkIOsBARnZLIb+4ppcuvzG6coSDTuHiqFOosRMSFJKj3y/vFVDyXtM hbkYH3xxj1cygOPmHFP5ZXTnmrmruRQu4cY1u9+M/BHDSRGZQxtWc58Qej9gIccTS8lG SorEWUrcp9PcZmPkCrdInE4TVeNOQbEIaYDWKNJvBWcnMm+4XA7kGH2X3ElA8p3yAOni RqmA==
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=X2YGvBVIdzOACuXDRRFW7y2PYeVQ7Ek8CGiWNWfpw8w=; b=XB0vhOwKFqXInLbnYMSDBtHFk+4Q+7ZyVKRY3e/8aVWpI3QZq1Y9AgNSiA/PUww8BZ O47FHK9lHzzpZEg63Ty5sx5ZAaX7tzAHU901QtxPVncm98g6XZkX8/0zXpUz/b0W3crr 0PqzmMHqIqBnTBKmvxIqLsu1wXpOziOkcSmltiXlIv19PUuXG8P5zBWVUw6rcDz8Lggx Ts74ZOuHH0AHqcmerwuWdfQEDREkKxCeGUotn978ItT1A6VJK9yM5LFpD1Rp/fyS6Orl qf6UXEl5eEirOPsXZ7JC3aHMUBTBVWPI9fo7NJ/FYp8pLv1o4ZZshbJmcdapsNE/MHUb N0zQ==
X-Gm-Message-State: AOAM533n1OCaS+hXJPY9YubhU9iUIVMTNGeDUnaMbL4UPTBZDKV2FH8d 9zliGtJkf8Z1jPgWevtu01LHZ3wvtaCXSWT9G28=
X-Google-Smtp-Source: ABdhPJzhxZM2VMKpWIQZwLyQ5WY6OclkqxLyLLFq/Ahx2tm+3ZR+ai6Gs96vbfTOhGrlLWZy82Rw5Ty58sc++tOOURU=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr4608313ljh.110.1593712901198;  Thu, 02 Jul 2020 11:01:41 -0700 (PDT)
MIME-Version: 1.0
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu>  <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr>  
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 2 Jul 2020 11:01:05 -0700
Message-ID: 
To: Tom Jones 
Cc: Denis , Justin Richer , txauth@ietf.org, Tobias Looker 
Content-Type: multipart/alternative; boundary="00000000000059957505a97933dd"
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 02 Jul 2020 18:01:45 -0000

--00000000000059957505a97933dd
Content-Type: text/plain; charset="UTF-8"

I agree it is not always true, sorry I did not make that clear.

My statement is that OAuth 2.0 does not require the AS to have knowledge of
the RS.


On Thu, Jul 2, 2020 at 10:56 AM Tom Jones 
wrote:

> Dick, the statement about the AS and RS is not always true. In federations
> we are always concerned that information is not leaked outside the approved
> parties and the AS messages will likely be encrypted for the sole use of
> the RS.
> Peace ..tom
>
>
> On Thu, Jul 2, 2020 at 10:44 AM Dick Hardt  wrote:
>
>> Apologies for the delayed response:
>>
>> On Fri, Jun 26, 2020 at 9:04 AM Denis  wrote:
>>
>>> The principle where a RS would only have relationships with one AS would
>>> make the model non scalable.
>>> It would prevent to get attributes from two different ASs,  for
>>> example:
>>> identity attributes from a bank and a master degree diploma from a
>>> university.
>>>
>>
>> Where do you see that the RS can have a relationship with only one AS?
>>
>>
>>>
>>> For privacy reasons, every AS should know as little as possible about
>>> the interactions between a client and multiple RSs.
>>> It is even possible that this goes as little as knowing *nothing at all*
>>> .
>>>
>>
>> OAuth 2.0 works this way now.
>>
>>
>>>
>>> The OAuth 2.0 assumption where the AS is in a position to know all the
>>> interactions of a given user has with all the RSs
>>> that an AS server has a relationship with should not be re-iterated.
>>>
>>
>> I am still confused why you think the AS knows anything abou the
>> interactions a given use has with all the RSs. The AS knows which clients
>> the user is using, but does not need to have any knowledge of which RSs a
>> client is accessing.
>>
>>
>> The AS does not need to know anything about the RS. The RS clearly needs
>> to trust the AS, as it is trusting the access granted by the AS to the
>> client, but it is unidirectional trust between the RS and the AS.
>>
>> /Dick
>>
>

--00000000000059957505a97933dd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I agree it is not always true, sorry I did not make that c=
lear.

My statement is that OAuth 2.0 does not require th=
e AS to have knowledge=C2=A0of the RS.


On Thu, Jul 2, 2=
020 at 10:56 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
Dick, the statement about=
 the AS and RS is not always true. In federations we are always concerned t=
hat information is not leaked outside the approved parties and the AS messa=
ges will likely be encrypted for the sole use of the RS.
<=
div>
Peace ..tom


On Thu, Jul 2, 2020 at 10:44 AM Dick Hardt <dick.hardt@gmail.com> wrote:
<=
div>Apologies for the delayed response:

On Fri, Jun 26, 2020 at 9:04 AM Deni=
s <denis.ietf@fr=
ee.fr> wrote:

 =20
   =20
 =20
  

    
The principle where a RS would only
      have relationships with one AS would make the model non scalable.
=


      It would prevent to get attributes from two different ASs,=C2=A0 for
      example:=C2=A0 

      identity attributes from a bank and a master degree diploma from a
      university.

Where do =
you see that the RS can have a relationship with only one AS?
=C2=
=A0

    

    


    

    For privacy reasons, every AS should know as little as possible
    about the interactions between a client and multiple RSs.

    
It is even possible that this goes as
      little as knowing nothing at all.

OAuth 2.0 works this way now.=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">

    


    

    

      
The OAuth 2.0 assumption where the AS
        is in a position to know all the interactions of a given user
        has with all the RSs 

        that an AS server has a relationship with should not be
        re-iterated.

I am=
 still confused why you think the AS knows anything abou the interactions a=
 given use has with all the RSs. The AS knows which clients the user is usi=
ng, but does not need to have any knowledge of which RSs a client is access=
ing.
=C2=A0
=C2=A0
The AS does not need to kn=
ow anything about the RS. The RS clearly needs to trust the AS, as it is tr=
usting the access granted by the AS to the client, but it is unidirectional=
 trust between the RS and the AS.

/Dick





--00000000000059957505a97933dd--


From nobody Thu Jul  2 11:16: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 B9DA63A0A9E for ; Thu,  2 Jul 2020 11:16: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 J55_zMY1cjzX for ; Thu,  2 Jul 2020 11:16:05 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 A2BDF3A0A96 for ; Thu,  2 Jul 2020 11:16:04 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id o4so16804495lfi.7 for ; Thu, 02 Jul 2020 11:16: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=XrCOjjWPnSMmHebs4vkenagJUw66jGMcYWwIhWZR48A=; b=E+Z6po/aQTReOtcOWXV6ocZbwiHhIqR/n514mqYoUBiHlHEXPOYSCgV6OX4L5G311q 2PYiOzDUrzOcnoQBsoNSPRysZSrV2tm1uwyo14JX/kEYVovWZgHv/qDy0o0S1u4thHrs VsC91LLapz1uxFCL97LS1hhufUsKALWSw5kd9pU0H2Zt2IxKiud62iYzR6Tk3tOEd/27 4ljwvutEOnKB089jGS2pbyrUXpiCJIScltTGrY1ROTBtm0YlW7XRZ3w/GnyBkboYVaZL xAYxL+DaiUMEPhkmcRfPHNFELePy7fgVVeYZ6z1D1yWcnZ+qnM2izjZIQovik8Uu0rFO oCtQ==
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=XrCOjjWPnSMmHebs4vkenagJUw66jGMcYWwIhWZR48A=; b=icGIrqR91drz/NNCmKdMKb4S4vXdVwIrM3TUMNzEKvfD3vWFcp0tC/vE14L9cmTt/w VFEuaIHLU0sDu3+JEnIWoLa7UMiCqXf63CecCFgIrbSVH0M02WZtGHpVu6F3IckzsFHn PtdHo2ocHa4LzKzNiArkQTsmiLT84AoJ1J/g3ioydUOp4GhZ+Lb2+CoAoIbdaqAXRs3p 4KvSCWZY4aGd/E03fEVx5Z147bUI6kiQ6bd+7BlsstfiAb1thUYAP0LHDf9+BQ3nyuT0 vc0rlCWLKPS5bT/yfXV2F5vGYIAHAT7dOvZwEcg1eME/84Db2YEro/lovMp/S6HPsQYp LlVw==
X-Gm-Message-State: AOAM531h1VrIJ7n3BjW+TBgA35Q2fqn45GJgBdDwiQdxmaQM57lIG/2/ VVBRqm+9/0N06hCN/eCBw2bn8R3VeCdhA3adOqs=
X-Google-Smtp-Source: ABdhPJwT09oSnyw06U4IX4Njmo7lzgHBJ13raV2POPld7m26MYH1628sksOm8toJJ4JApgcAzlYQB08tVMNw32zYaW0=
X-Received: by 2002:ac2:5093:: with SMTP id f19mr19365726lfm.10.1593713762604;  Thu, 02 Jul 2020 11:16:02 -0700 (PDT)
MIME-Version: 1.0
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com>    
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 2 Jul 2020 11:15:26 -0700
Message-ID: 
To: Denis 
Cc: txauth@ietf.org, Nat Sakimura 
Content-Type: multipart/alternative; boundary="000000000000b19dce05a979669a"
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 02 Jul 2020 18:16:08 -0000

--000000000000b19dce05a979669a
Content-Type: text/plain; charset="UTF-8"

(dropping IESG, adding Nat as Denis is quoting him)

On Thu, Jul 2, 2020 at 10:59 AM Dick Hardt  wrote:

> Catching up on this email ... comments inserted ...
>
> On Mon, Jun 29, 2020 at 12:06 AM Denis  wrote:
>
>> Hello Dick,
>>
>> Denis, thanks for sharing your thoughts, some clarifications on your
>> statements inserted:
>>
>> On Fri, Jun 26, 2020 at 9:42 AM Denis  wrote:
>> 
>>
>>> *New proposed charter*
>>>
>>> 
>>
>>>
>>> Resource servers inform their clients about which access token formats
>>> are acceptable and depending upon the king of operation
>>> that is requested, which kind of attributes are needed and from which
>>> ASs that my be obtained.
>>>
>>> While at times this may be appropriate, at other times disclosing the
>> attributes the RS requires is not needed by the client.
>> For example, an enterprise client accessing a resource does not need to
>> know which groups a user belongs to,
>> but the RS may require that to determine if the user running the client
>> has access.
>>
>> As soon as there is a desire to implement privacy by default, the client
>> should not provide more attributes than strictly necessary.
>> Even after three readings of your example, I failed to understand it.
>>
>>
>>> A major difference with OAuth 2.0 is that there is no bilateral trust
>>> relationship between an authorization server and a resource server:
>>> for a given category of attributes, a resource server may trust one or
>>> more authorization servers. Another major difference with OAuth 2.0.
>>> is that the content of an attributes token is meant to be accessible to
>>> the client.
>>>
>>> This is not how OAuth 2.0 works. See slides 7 and 8 from my original
>> IETF presentation on what became OAuth 2.0
>>
>> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation
>>
>> I looked at the two slides.
>>
>> Unfortunately slide 7 has just one arrow with the word "trust". This is
>> insufficient to understand what is meant unless being present
>> at the presentation. Does it mean that the PR (RS) trusts one AS or that
>> it may trust multiple ASs ?
>>
> Unfortunately slide 8 has just one arrow between the PR and the AS which
>> is red-crossed but no text at all. This is insufficient to understand
>> what is meant unless being present at the presentation. Does it mean that
>> the PR and the AS never communicate directly ?
>> Does it mean that they have no relationships at all, besides the one way
>> trust relationship mentioned in slide 7 ?
>>
>> So it hard to say whether these two slides are indeed meaning that there
>> is no bilateral relationship between an authorization server and a resource
>> server.
>>
> Apologies for not providing an explanation on the slides.
>
> Slide 7 shows that trust between the AS and PR (now RS) was
> unidirectional, from the RS to the AS.
> Slide 8 indicates that trust is not bidirectional.
>
> There is no limit on how many ASs an RS may trust.
>
>
>> On June 12, Nat Sakimura recently answered to an email with the
>> following topic:
>>
>> Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
>> Authorization Framework: JWT Secured Authorization Request))
>>
>> My arguments were:
>>
>>      The original model for OAuth was making the assumption that the AS
>> and the RS had a strong bilateral relationship.
>>
>>       *A key question is whether such strong relationship will be
>> maintained for ever *or
>>      whether it will be allowed to perform some evolutions of this
>> relationship.
>>
>>      In order to respect the privacy of the users, there is the need to
>> encompass other scenarios. One of these scenarios is that the AS and the RS
>>      do not need any longer to have such a strong relationship. In terms
>> of trust relationships, a RS simply needs to trust the access tokens issued
>> by an AS.
>>      The AS does have any more a "need to know" of all the RSs that are
>> accepting its access tokens. This would be a major simplification of the
>> current global architecture.
>>
>> Nat's position was:
>>
>> "My take is that the basic assumption of OAuth 2.0 Framework is that
>> there is a strong relationship between AS and RS.
>> I feel that it is quite unrealistic that an RS would trust the access
>> token issued by an AS that it has no strong relationship with".
>>
>> There are indeed different positions on this topic.
>>
>
> I don't think Nat and I have different opinions, but I will let Nat
> clarify.
> Just because there is a strong relationship between the AS and RS, does
> not mean it is bidirectional. I would understand
>
> "I feel that it is quite unrealistic that an RS would trust the access
> token issued by an AS that it has no strong relationship with"
>
> to indicate Nat is expecting the trust to be from the RS to the AS.
>
>
>
>>
>> The AS may not even know who the RS (or PR in the slides) is.
>>
>> 
>>
>>>
>>> I got rid of the word "delegation": the client does not delegate
>>> anything to an authorization server. If it would, this would mean that the
>>> authorization server
>>> would be able to act as the client and could know everything that the
>>> client will do, which comes into contradiction with the user's privacy.
>>>
>>
>> The above is not true.
>>
>> The Resource Owner is delegating access control to the AS in
>> authorization use cases.
>>
>> The OAuth 2.0 model does not mandate any more the presence of a Resource
>> Owner.
>>
>
> Why do you say that? The RO is who owns the RS. Your statement does not
> make sense.
>
>
>>
>> The client is may be delegating user authentication to the AS in identity
>> claim use cases.
>>
>> Delegating user authentication to the AS is different from delegating
>> access control to the AS.
>>
>
> Agreed. Your statement was there was no delegation. I'm explaining there
> are potentially two delegations.
>
>>
>> The AS can act as the client in many OAuth deployments, as the access
>> token is a bearer token.
>>
>> A bearer token is rather insecure.
>>
> Cookies are also bearer tokens. But we use them all the time in web apps
> for storing session state and prior authentication! :)
>
>
>
>> That does not mean the AS knows what the client is doing.
>>
>> There are currently two attempts in the OAuth WG to let know to the AS
>> what the client is doing:
>>
>>    - draft-ietf-oauth-jwsreq-22   (The OAuth 2.0 Authorization
>>    Framework: JWT Secured Authorization Request)
>>    - draft-ietf-oauth-rar-01         (OAuth 2.0 Rich Authorization
>>    Requests)
>>
>> Those are optional, and in some situations are a desired property.
>
> /Dick
>
>

--000000000000b19dce05a979669a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



(dropping IESG, adding Nat as D=
enis is quoting him)

On Thu, Jul 2, 2020 at 10:59 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Catching up on this emai=
l ... comments inserted ...

On Mon, Jun 29, 2020 at 12:06 AM Denis <denis.ietf@free.fr&g=
t; wrote:

 =20
   =20
 =20
  

    
Hello Dick,

    


      

    

     =20
      

        
Denis, thanks for sharing you=
r
            thoughts, some clarifications on your statements inserted:

        

        
        

          
On Fri=
,
              Jun 26, 2020 at 9:42 AM Denis <denis.ietf@free.fr>
              wrote:

          
<snip>

          

            

              

                

                  
New proposed charter

                

              

            

          

          
<snip>=C2=A0

          

            

              

                
 

                            Resource servers inform their clients about
                            which access token formats are acceptable
                            and depending upon the king of operation=


                            that is requested, which kind of attributes
                            are needed and from which ASs that my be
                            obtained.<=
span lang=3D"EN-US">

                              

                      

              

            

          

          
While at times this may be
              appropriate, at other times disclosing the attributes the
              RS requires is not needed by the client. 

              For example, an enterprise client accessing a resource
              does not need to know which groups a user belongs to, 

              but the RS may require that to determine if the user
              running the client has access.

            

        

      

    

    
As soon as there is a desire to implement
        privacy by default, the client should not provide more
        attributes than strictly necessary. 

        Even after three readings of your example, I failed to
        understand it.

      

    

      

        

          

            

              

                
 

                        A major difference with OAuth 2.0 is that there
                        is no bilateral trust relationship between an
                        authorization server and a resource server: =


                        for a given category of attributes, a resource
                        server may trust one or more authorization
                        servers. Another major difference with OAuth 2.0.

                        is that the content of an attributes token is
                        meant to be accessible to the client.=


              

            

          

          
This is not how OAuth 2.0 works. See
              slides 7 and 8 from my original IETF presentation on what
              became OAuth 2.0

          


            

          
        

      

    

    
I looked at the two slides. 

      

    
Unfortunately slide 7 has just one arrow with
        the word "trust". This is insufficient to understand what=
 is
        meant unless being present 

        at the presentation. Does it mean that the PR (RS) trusts one AS
        or that it may trust multiple ASs ?

      

    
Unfortunately slide 8 has just one arrow
        between the PR and the AS which is red-crossed but no text at
        all. This is insufficient to understand

        what is meant unless being present at the presentation. Does it
        mean that the PR and the AS never communicate directly ?

        Does it mean that they have no relationships at all, besides the
        one way trust relationship mentioned in slide 7 ?

    
So it hard to say whether these two slides are
        indeed meaning that there
            is no bilateral relationship between an authorization server
            and a resource server.
Apologies for not providing an explanation on the slides.

Slide 7 shows that trust between the AS and PR (now RS=
) was unidirectional, from the RS to the AS.
Slide 8 indicates=C2=
=A0that trust is not bidirectional.

There is no li=
mit on how many ASs an RS may trust.
=C2=A0

    
On Jun=
e
          12, Nat Sakimura recently answered to an email with
        the following topic:

    
    
    

      
Re: [OAUTH-WG] Comments o=
n
          draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
          Authorization Framework: JWT Secured Authorization Request))

    

    
    
    
My arguments were:
    
    
    
=C2=A0=C2=A0=C2=A0=C2=A0 Th=
e original model
        for OAuth was making the assumption that the AS and the RS had a
        strong
        bilateral relationship.

      

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
      A key question is whether such strong
          relationship will be maintained for
          ever or 

      =C2=A0=C2=A0=C2=A0=C2=A0 whether it will be allo=
wed to perform some
        evolutions of this
        relationship.

      

      =C2=A0=C2=A0=C2=A0=C2=A0 In order to respect the=
 privacy of the
        users, there is the need to encompass
        other scenarios. One of these scenarios is that the AS and the
        RS 

      =C2=A0=C2=A0=C2=A0=C2=A0 do not need
        any longer to have such a strong relationship. In terms of trust
        relationships,
        a RS simply needs to trust the access tokens issued by an AS. 

      =C2=A0=C2=A0=C2=A0=C2=A0 The AS does have
        any more a "need to know" of all the RSs that are accepti=
ng its
        access tokens. This would be a major simplification of the
        current global
        architecture.

    
    
    
Nat's position was: 
      

    
    
    

      
"My take is that the=
 basic
          assumption of OAuth 2.0 Framework is
          that there is a strong relationship between AS and RS. 

          I feel that it is quite
          unrealistic that an RS would trust the access token issued by
          an AS that it has
          no strong relationship with".

    

    
    
    
There are indeed different
        positions on this topic.=C2=A0 

I don't think Nat and I have different opinions, but =
I will let Nat clarify.
Just because there is a strong relationsh=
ip between the AS and RS, does not mean it is bidirectional. I would unders=
tand=C2=A0

"I feel that it is quite
          unrealistic that an RS would trust the access token issued by
          an AS that it has
          no strong relationship with"

to ind=
icate Nat is expecting the trust to be from the RS to the AS.
=C2=A0
<=
div>

      

    

      

        

          


            

          
The AS may not even know who the RS
              (or PR in the slides) is.

          


            

          
<snip>=C2=A0

          

            

              

                
 

                        I got rid of the word "delegation": the c=
lient
                        does not delegate anything to an authorization
                        server. If it would, this would mean that the
                        authorization server 

                        would be able to act as the client and could
                        know everything that the client will do, which
                        comes into contradiction with the user's
                        privacy.

                      

              

            

          

          


            

          
The=C2=A0above is not true.
          
=C2=A0

          
The Resource Owner is delegating
              access control to the AS in authorization use cases.
        

      

    

    
The OAuth 2.0 model does not mandate any more
        the presence of a Resource Owner.

Why do you say that? The RO is who owns the RS. Your statem=
ent does not make sense.
=C2=A0

    

      

        

          


            

          
The client is may be delegating user
              authentication to the AS in identity claim use cases.<=
/div>
        

      

    

    
Delegating user authentication to the AS is
        different from delegating access control to the AS.

Agreed. Your statement was there was no d=
elegation. I'm explaining there are potentially=C2=A0two delegations.=
=C2=A0

    

      

        

          


            

          
The AS can act as the client in many
              OAuth deployments, as the access token is a bearer token.
            

        

      

    

    
A bearer token is rather insecure.
Cookies are also bearer tokens. But we use them all t=
he time in web=C2=A0apps for=C2=A0storing session state=C2=A0and prior auth=
entication! :)

=C2=A0

    

      

        

          
That does not mean the AS knows what
              the client is doing. 

            

        

      

    

    
There are currently two attempts in the OAuth
        WG to let know to the AS what the client is doing:

    
    
      
  • draft-ietf-oauth-jwsreq-22=C2=A0=C2=A0 (The =
OAuth 2.0
          Authorization Framework: JWT Secured Authorization Request)
    • 
      
  • draft-ietf-oauth-rar-01 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 (OAuth 2.0
          Rich Authorization Requests)
<=
div>Those are optional, and in some situations are a desired property.
=C2=A0
/Dick




--000000000000b19dce05a979669a--


From nobody Thu Jul  2 12:34: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 1F8E93A082A for ; Thu,  2 Jul 2020 12:34:17 -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_REMOTE_IMAGE=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 5RPRKJXbWPNM for ; Thu,  2 Jul 2020 12:34:13 -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 6AF213A084C for ; Thu,  2 Jul 2020 12:34:12 -0700 (PDT)
Received: from [192.168.1.14] (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 062JYAaR032541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 Jul 2020 15:34:10 -0400
From: Justin Richer 
Message-Id: <5AA3C0D4-A250-4EFB-B3E9-F71E8BD959A6@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_223D97EF-2206-46CF-8D27-8BDD8652DFE7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 2 Jul 2020 15:34:10 -0400
In-Reply-To: 
Cc: David Pyke , txauth@ietf.org
To: Tom Jones 
References:   <3b8d3690-47e2-ff00-1065-29647d18555b@readycomputing.com>  <00827624-7361-4c5f-b34f-0edc8f7493dc@readycomputing.com> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Possible Use Case for GNAP
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, 02 Jul 2020 19:34:17 -0000

--Apple-Mail=_223D97EF-2206-46CF-8D27-8BDD8652DFE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

David, thanks for bringing this use case here. If I=E2=80=99m =
understanding this, the problem has more to do with the data as it =
traverses the API fulfillment than it does with the authorization =
request on the way in, right? I think that this has some potentially =
interesting implications on the way the client requests resources (using =
a rich descriptive structure) and the UX associated with that at the AS. =
Aaron Parecki=E2=80=99s had some thoughts on something similar within =
the OAuth WG, so maybe he can chime in on this here.

There are also some implications about the transitive trust through the =
network. If we look at each hop as a separately authorized request, =
could we define them in a way that they=E2=80=99re chained from each =
other down the line? Maybe it would be possible for the root HIN to get =
a new token for each of the downstream HINs, but this new token is in =
the context of the first one. OAuth token exchange lets you do something =
like this, but here we could have it be augmented and amended with the =
rights and requests of the root HIN as well.=20

I think Tom is largely right, though, in that GNAP would be a :carrier: =
for that kind of request through the network, and the :details: of it =
would need to be worked out in a vertical-specific definition. But the =
infrastructure is important!

What are the aspects of OAuth 2 that make this kind of multi-hop =
deployment difficult to use with OAuth 2 today, though? In understanding =
the limitations, we can start to address them here in GNAP.

 =E2=80=94 Justin

> On Jul 2, 2020, at 1:46 PM, Tom Jones  =
wrote:
>=20
> My guess is that txauth is only concerned with the link between the =
user (indirectly to get consent) the destination EHR, which is =
perversely called the client of the user, and the RS which is the =
combined HIE in its entirety. The RCE should work out the hop x hop =
stuff. This link (which i sent out previously) is intended to address =
the patient as the AS with a self issued ID. The interesting problem =
from health care is that the AS consent will need to be in terms that =
the user understands, which is not defined, and not the FHIR claims =
detail. The HIAWG of Kantara has taken on the challenge of healthcare =
identity assurance semantics. A different Kantara WG is working on the =
syntax of these messages. =20
> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token =
 =20
> Peace ..tom
>=20
>=20
> On Thu, Jul 2, 2020 at 10:02 AM David Pyke =
> =
wrote:
> Each hop relays the information but may have to do a transform on the =
data on the way through.  So, the data shouldn't be archived as the =
network is designed purely to route request and responses from =
originator to  responder.  As such, there's no need for individual =
access notifications.  However, the data is not necessarily encrypted as =
this is designed as a trusted network.  The FHIR query would be routed =
through to the responder, and the results routed back to the query =
originator.=20
>=20
> Notifications to the user would be not needed as to the originator =
system the network is (should be) transparent.  However, to maintain the =
trust of the authorization/authentication, each hop will have to =
capture, and forward to one or more responders in the network.
>=20
> For example
>=20
> EHR A sends out a patient record discovery request to it's upstream =
actor, that is forwarded to it's upstream HIN.
> The HIN sends that request to all other HINs who forward it (depending =
on the capabilities of the HIN) to the various actors.  The originating =
user needs to be identified to the responders for audit and access =
consent. However, the cert that is used may (and likely will) change for =
each hop and be different the org that was the query source, which will =
still need to be identified to the responders
> Some of those actors' EHRs respond saying they have data on that =
patient.
> The responding HINs aggregates the responses and sends on bundle to =
the initiating HIN who forwards it via it's network to the query source
> That source sends out a requests to saying "Send me the data from all =
the sources", that goes out, and results are aggregated on the way back =
into one bundle.  Same requirements as 2=20
> All of that needs to be managed from a =
trust/authentication/authorization point of view. Simple, right?
>=20
>=20
>=20
> On 2020-07-02 12:45 p.m., Tom Jones wrote:
>> without a better understanding of the "hop" it is hard to say. Does =
each "hop" archive the PHI in FHIR format? if so each would need to =
notify the user of access, as i see the problem. That sounds like =
something that would scare the patient. If the "hop" just handled (for =
example) an encrypted packet, that would not be a problem. OTOH if a =
federation were involved, the federation could notify the user. Less =
scary perhaps.
>> Peace ..tom
>>=20
>>=20
>> On Thu, Jul 2, 2020 at 9:41 AM David Pyke =
> wrote:
>> Great to hear!
>>=20
>> My main concern is that the cert use may be an issue as it's passed =
through the hops.  A hop may want to have their predecessor  use the =
predecessor's cert coming in but may swap out their own cert for the =
next connection (and the same happening on the way back).  So, the =
ability to trace certs through the relaying would be an issue so that =
trust is maintained even when those certs aren't chained together.  It =
would be good if there was one cert or a set of chained certs used for =
the two traversal but that's not likely to be the case..
>>=20
>> Thanks!
>>=20
>> On 2020-07-02 12:26 p.m., Tom Jones wrote:
>>=20
>>> We discussed that use case this morning in OIDC. A proposal has been =
made for a new endpoint that I would like to see working from the EHR =
endpoints. Did you have other concerns besides the source and =
destination endpoints for the data?
>>> Peace ..tom
>>>=20
>>>=20
>>> On Thu, Jul 2, 2020 at 8:30 AM David Pyke =
> wrote:
>>> I am working on a Healthcare IT project that requires multi-hop =
transmission of REST based (FHIR: fhir.hl7.org ) =
resources.  The established protocol uses OAuth2 which doens't lend =
itself to multi-hop relay.
>>>=20
>>> I saw a presentation on XYZ/GNAP and thought it might be early =
enough to get on the train to consider how it might address that =
structure.  The system I'm working on is from the US Office of the =
National Coordinator for Healthcare IT (ONC) called TEFCA.  At minimum =
there would be 4 hops, at maximum, could be 8-10 and no bypassing of the =
network can be done.  As I said, OAuth2 doesn't handle that without =
significant issues.
>>>=20
>>> If this is not a use case that can be considered, please accept my =
apologies.
>>>=20
>>> Thanks
>>>=20
>>> Dave Pyke
>>>=20
>>> --=20
>>> David Pyke
>>>=20
>>> Manager, Strategic Consulting
>>>=20
>>> =
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
------------
>>>=20
>>>  
>>>    =
  =
=09
>>> Office: +1 212 877 3307 x5001
>>>=20
>>> david.pyke@readycomputing.com 
>>> www.readycomputing.com 
>>> 150 Beekman Street, Floor 3, New York, NY 10038
>>>=20
>>>=20
>>> The information in this e-mail communication together with any =
attachments is intended only for the person or entity to which it is =
addressed and may contain confidential and/or privileged material. If =
you are not the intended recipient of this                               =
      communication, please notify us immediately. Any views expressed =
in this communication are those of the sender, unless otherwise =
specifically stated. Ready Computing does not represent, warrant or =
guarantee that the integrity of this communication has been maintained =
or the communication is free of errors, virus or interference.
>>>=20
>>> This is not a secure transmission. The information contained in this =
transmission is highly prohibited from containing privileged and =
confidential information, including patient information protected by =
federal and state privacy laws. It is intended only for the use of the =
person(s) named above. If you are not the intended recipient, you are =
hereby notified that any review, dissemination, distribution, or =
duplication of this communication is strictly prohibited. If you are not =
the intended recipient, please contact the sender by reply email and =
destroy all copies of the original message. --=20
>>> Txauth mailing list
>>> Txauth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/txauth =

>>>=20
>> --=20
>> David Pyke
>>=20
>> Manager, Strategic Consulting
>>=20
>> =
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
------------
>>=20
>>  
>>    =
  =
=09
>> Office: +1 212 877 3307 x5001
>>=20
>> david.pyke@readycomputing.com 
>> www.readycomputing.com 
>> 150 Beekman Street, Floor 3, New York, NY 10038
>>=20
>>=20
>> The information in this e-mail communication together with any =
attachments is intended only for the person or entity to which it is =
addressed and may contain confidential and/or privileged material. If =
you are not the intended recipient of this                             =
communication, please notify us immediately. Any views expressed in this =
communication are those of the sender, unless otherwise specifically =
stated. Ready Computing does not represent, warrant or guarantee that =
the integrity of this communication has been maintained or the =
communication is free of errors, virus or interference.
>>=20
>> This is not a secure transmission. The information contained in this =
transmission is highly prohibited from containing privileged and =
confidential information, including patient information protected by =
federal and state privacy laws. It is intended only for the use of the =
person(s) named above. If you are not the intended recipient, you are =
hereby notified that any review, dissemination, distribution, or =
duplication of this communication is strictly prohibited. If you are not =
the intended recipient, please contact the sender by reply email and =
destroy all copies of the original message. --=20
>> Txauth mailing list
>> Txauth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/txauth =

> --=20
> David Pyke
>=20
> Manager, Strategic Consulting
>=20
> =
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
------------
>=20
>  
>    =
  =
=09
> Office: +1 212 877 3307 x5001
>=20
> david.pyke@readycomputing.com 
> www.readycomputing.com 
> 150 Beekman Street, Floor 3, New York, NY 10038
>=20
>=20
> The information in this e-mail communication together with any =
attachments is intended only for the person or entity to which it is =
addressed and may contain confidential and/or privileged material. If =
you are not the intended recipient of this communication, please notify =
us immediately. Any views expressed in this communication are those of =
the sender, unless otherwise specifically stated. Ready Computing does =
not represent, warrant or guarantee that the integrity of this =
communication has been maintained or the communication is free of =
errors, virus or interference.
>=20
> This is not a secure transmission. The information contained in this =
transmission is highly prohibited from containing privileged and =
confidential information, including patient information protected by =
federal and state privacy laws. It is intended only for the use of the =
person(s) named above. If you are not the intended recipient, you are =
hereby notified that any review, dissemination, distribution, or =
duplication of this communication is strictly prohibited. If you are not =
the intended recipient, please contact the sender by reply email and =
destroy all copies of the original message.
> --=20
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth


--Apple-Mail=_223D97EF-2206-46CF-8D27-8BDD8652DFE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

David, thanks for bringing this use case here. If I=E2=80=99=
m understanding this, the problem has more to do with the data as it =
traverses the API fulfillment than it does with the authorization =
request on the way in, right? I think that this has some potentially =
interesting implications on the way the client requests resources (using =
a rich descriptive structure) and the UX associated with that at the AS. =
Aaron Parecki=E2=80=99s had some thoughts on something similar within =
the OAuth WG, so maybe he can chime in on this here.

There are also some implications about =
the transitive trust through the network. If we look at each hop as a =
separately authorized request, could we define them in a way that =
they=E2=80=99re chained from each other down the line? Maybe it would be =
possible for the root HIN to get a new token for each of the downstream =
HINs, but this new token is in the context of the first one. OAuth token =
exchange lets you do something like this, but here we could have it be =
augmented and amended with the rights and requests of the root HIN as =
well. 

I think Tom is largely right, though, in that GNAP would be a =
:carrier: for that kind of request through the network, and the =
:details: of it would need to be worked out in a vertical-specific =
definition. But the infrastructure is important!

What are the aspects of OAuth 2 that =
make this kind of multi-hop deployment difficult to use with OAuth 2 =
today, though? In understanding the limitations, we can start to address =
them here in GNAP.

 =E2=80=94 Justin

On Jul =
2, 2020, at 1:46 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

My guess is that txauth is only =
concerned with the link between the user (indirectly to get =
consent) the destination EHR, which is perversely called the client =
of the user, and the RS which is the combined HIE in its entirety. The =
RCE should work out the hop x hop stuff. This link (which i sent out =
previously) is intended to address the patient as the AS with a self =
issued ID. The interesting problem from health care is that the AS =
consent will need to be in terms that the user understands, which is not =
defined, and not the FHIR claims detail. The HIAWG of Kantara has taken =
on the challenge of healthcare identity assurance semantics. A =
different Kantara WG is working on the syntax of these =
messages.  
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token  
Peace ..tom


On Thu, Jul 2, 2020 at 10:02 AM David =
Pyke <david.pyke@readycomputing.com> wrote:

 =20
   =20
 =20
  
Each hop relays the information but may =
have to do a transform on
      the data on the way through.  So, the data shouldn't be =
archived
      as the network is designed purely to route request and responses
      from originator to  responder.  As such, there's no need =
for
      individual access notifications.  However, the data is not
      necessarily encrypted as this is designed as a trusted =
network. 
      The FHIR query would be routed through to the responder, and the
      results routed back to the query originator. 

    
Notifications to the user would be not needed as =
to the
      originator system the network is (should be) transparent. 
      However, to maintain the trust of the
      authorization/authentication, each hop will have to capture, and
      forward to one or more responders in the network.
For example

    
    
      
  1. EHR A sends out a patient record discovery request =
to it's
        upstream actor, that is forwarded to it's upstream HIN.
    2. 
      
  2. The HIN sends that request to all other HINs who =
forward it
        (depending on the capabilities of the HIN) to the various
        actors.  The originating user needs to be identified to the
        responders for audit and access consent. However, the cert that
        is used may (and likely will) change for each hop and be
        different the org that was the query source, which will still
        need to be identified to the responders
    
      
    3. 
      
  3. Some of those actors' EHRs respond saying they have =
data on
        that patient.
    4. 
      
  4. The responding HINs aggregates the responses and =
sends on
        bundle to the initiating HIN who forwards it via it's network to
        the query source
    5. 
      
  5. That source sends out a requests to saying "Send me =
the data
        from all the sources", that goes out, and results are aggregated
        on the way back into one bundle.  Same requirements as 2 =

    
      
    6. 
    
All of that needs to be managed from a
      trust/authentication/authorization point of view. Simple, =
right?

    


    

    
On 2020-07-02 12:45 p.m., Tom Jones
      wrote:

    

    

     =20
      
without a better understanding of the =
"hop" it is
        hard to say. Does each "hop" archive the PHI in FHIR format? if
        so each would need to notify the user of access, as i see the
        problem. That sounds like something that would scare the
        patient. If the "hop" just handled (for example) =
an encrypted
        packet, that would not be a problem. OTOH if a federation were
        involved, the federation could notify the user. Less scary
        perhaps.

        

          

            

              
Peace ..tom

            

          

        

        

      

      

      

        
On Thu, Jul 2, 2020 at =
9:41 AM
          David Pyke <david.pyke=3D40readycomputing.com@dmarc.ietf.org>
          wrote:

        

        

          
Great=
 to hear!
My main =
concern is that the cert use may
                be an issue as it's passed through the hops.  A hop =
may
                want to have their predecessor  use the =
predecessor's
                cert coming in but may swap out their own cert for the
                next connection (and the same happening on the way
                back).  So, the ability to trace certs through the
                relaying would be an issue so that trust is maintained
                even when those certs aren't chained together.  It =
would
                be good if there was one cert or a set of chained certs
                used for the two traversal but that's not likely to be
                the case..
Thanks!

            

            
On 2020-07-02 12:26 p.m., Tom Jones =
wrote:

            


            

            

              
We discussed that use case =
this morning in
                OIDC. A proposal has been made for a new endpoint that I
                would like to see working from the EHR endpoints. Did
                you have other concerns besides the source and
                destination endpoints for the data?

                

                  

                    

                      
Peace ..tom

                    

                  

                

                

              

              

              

                
On Thu, Jul 2, =
2020 at
                  8:30 AM David Pyke <david.pyke=3D40readycomputing.com@dmarc.ietf.org>
                  wrote:

                

                

                  
I am working on a Healthcare IT
                        project that requires multi-hop transmission of
                        REST based (FHIR: fhir.hl7.org)
                        resources.  The established protocol uses =
OAuth2
                        which doens't lend itself to multi-hop =
relay.
I saw a =
presentation on XYZ/GNAP
                        and thought it might be early enough to get on
                        the train to consider how it might address that
                        structure.  The system I'm working on is =
from
                        the US Office of the National Coordinator for
                        Healthcare IT (ONC) called TEFCA.  At =
minimum
                        there would be 4 hops, at maximum, could be 8-10
                        and no bypassing of the network can be =
done.  As
                        I said, OAuth2 doesn't handle that without
                        significant issues.

                      
If this is not a use case =
that can be considered,
                      please accept my apologies.
Thanks
Dave Pyke

                    

                    
-- 

                      

                        =

                          

                            

                              
 David
                                      Pyke

                              		
                            

                            

                              
 Manager,
                                    Strategic Consulting

                              		
                            

                            

                              
 ---------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
-----------------------

                              		
                            

                            

                              
 3D"Logo"
 3D"LinkedIn 3D"Twitter 3D"Youtbue

                              		
                              
Office: +1 212
                                    877 3307 x5001

                                

                                  
                                    

                                      

                                          
david.pyke@readycomputing.com

                                          
                                                =
www.readycomputing.com

                                      		
                                    

                                    

                                      
150
                                            Beekman Street, Floor 3, New
                                            York, NY 10038

                                      		
                                    

                                    

                                      

                                      		
                                    

                                  
                                

                              		
                            

                            

                              

                                  The
                                    information in this e-mail
                                    communication together with any
                                    attachments is intended only for the
                                    person or entity to which it is
                                    addressed and may contain
                                    confidential and/or privileged
                                    material. If you are not the
                                    intended recipient of this
                                    communication, please notify us
                                    immediately. Any views expressed in
                                    this communication are those of the
                                    sender, unless otherwise
                                    specifically stated. Ready Computing
                                    does not represent, warrant or
                                    guarantee that the integrity of this
                                    communication has been maintained or
                                    the communication is free of errors,
                                    virus or interference.

                              		
                            

                          
                        

                      

                    

                  

                  

                  This is not a secure transmission. The information
                  contained in this transmission is highly prohibited
                  from containing privileged and confidential
                  information, including patient information protected
                  by federal and state privacy laws. It is intended only
                  for the use of the person(s) named above. If you are
                  not the intended recipient, you are hereby notified
                  that any review, dissemination, distribution, or
                  duplication of this communication is strictly
                  prohibited. If you are not the intended recipient,
                  please contact the sender by reply email and destroy
                  all copies of the original message. -- 

                  Txauth mailing list

                  Txauth@ietf.org

                  https://www.ietf.org/mailman/listinfo/txauth
=

                

              

              

              

            

            
-- 

              

                =

                  

                    

                      
 David Pyke

                      		
                    

                    

                      
 Manager,
                            Strategic Consulting

                      		
                    

                    

                      
 ---------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
-----------------------

                      		
                    

                    

                      
 3D"Logo"
 3D"LinkedIn 3D"Twitter 3D"Youtbue

                      		
                      
Office:
                            +1 212 877 3307 x5001

                        

                          
                            

                              

                                  
                                        =
david.pyke@readycomputing.com

                                  
                                        =
www.readycomputing.com

                              		
                            

                            

                              
150
                                    Beekman Street, Floor 3, New York,
                                    NY 10038

                              		
                            

                            

                              

                              		
                            

                          
                        

                      		
                    

                    

                      

                          The
                            information in this e-mail communication
                            together with any attachments is intended
                            only for the person or entity to which it is
                            addressed and may contain confidential
                            and/or privileged material. If you are not
                            the intended recipient of this
                            communication, please notify us immediately.
                            Any views expressed in this communication
                            are those of the sender, unless otherwise
                            specifically stated. Ready Computing does
                            not represent, warrant or guarantee that the
                            integrity of this communication has been
                            maintained or the communication is free of
                            errors, virus or interference.

                      		
                    

                  
                

              

            

          

          

          This is not a secure transmission. The information contained
          in this transmission is highly prohibited from containing
          privileged and confidential information, including patient
          information protected by federal and state privacy laws. It is
          intended only for the use of the person(s) named above. If you
          are not the intended recipient, you are hereby notified that
          any review, dissemination, distribution, or duplication of
          this communication is strictly prohibited. If you are not the
          intended recipient, please contact the sender by reply email
          and destroy all copies of the original message. -- 

          Txauth mailing list

          Txauth@ietf.org

          https://www.ietf.org/mailman/listinfo/txauth
=

        

      

    

    
-- 

     =20
     =20
     =20
     =20
      

        =

          

            

              

                  David Pyke

              		
            

            

              

                  Manager,
                    Strategic Consulting

              		
            

            

              
 ---------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
-----------------------

              		
            

            

              

                  3D"Logo"

                  3D"LinkedIn 3D"Twitter 3D"Youtbue

              		
              
Office:
                    +1 212 877 3307 x5001

                

                  
                    

                      

                          
                                =
david.pyke@readycomputing.com

                          
                                =
www.readycomputing.com

                      		
                    

                    

                      
150
                            Beekman Street, Floor 3, New York, NY =
10038

                      		
                    

                    

                      

                      		
                    

                  
                

              		
            

            

              

                  The
                    information in this e-mail communication together
                    with any attachments is intended only for the person
                    or entity to which it is addressed and may contain
                    confidential and/or privileged material. If you are
                    not the intended recipient of this communication,
                    please notify us immediately. Any views expressed in
                    this communication are those of the sender, unless
                    otherwise specifically stated. Ready Computing does
                    not represent, warrant or guarantee that the
                    integrity of this communication has been maintained
                    or the communication is free of errors, virus or
                    interference.

              		
            

          
        

      

    

  





This is not a secure transmission. The information contained in this=20
transmission is highly prohibited from containing privileged and=20
confidential information, including patient information protected by=20
federal and state privacy laws. It is intended only for the use of the=20=

person(s) named above. If you are not the intended recipient, you are=20
hereby notified that any review, dissemination, distribution, or=20
duplication of this communication is strictly prohibited. If you are not
 the intended recipient, please contact the sender by reply email and=20
destroy all copies of the original message.
                       

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

=

--Apple-Mail=_223D97EF-2206-46CF-8D27-8BDD8652DFE7--


From nobody Fri Jul  3 01:19: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 2E8DF3A08CD for ; Fri,  3 Jul 2020 01:19: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 1nVLQAlQD9RD for ; Fri,  3 Jul 2020 01:19:47 -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 021583A0839 for ; Fri,  3 Jul 2020 01:19:46 -0700 (PDT)
Received: by mail-il1-x131.google.com with SMTP id r12so19392721ilh.4 for ; Fri, 03 Jul 2020 01:19: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=iKmegSuuaZWCR3i2ESzJP2ZHxXMhRMWw9pl3l+8THts=; b=uJomChMnV/S/eCVFmEmDJG+cPZv9fJqZeNYbuZ7W+Wur6GpBS62IpY5+vDoCEhJ0jf WuoYG5HeChHrrLA7v+PitnugIFPmqR41ABDD7U6HakGuB6PSnmBfQvyjGClPf4Xw5oYS 0joaro4Os3geyPgRWfW4nfyjwurq8ZgUEbPTmGl+uHTYlx3GWYP14A/KNJehz3h8WheF TXl4AwE86zFUCl3PnDGsS7JC2vbFPocJvvwV21QwbiLQ+lQMF42gAWcbGVLesYIKVl8J eaEYMzVnPuwvU8GVkn/bYiLhrsnNu69SHxM8GzGyTFPWjCMxveM9juZb2DrVnV97T1Ox SdZw==
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=iKmegSuuaZWCR3i2ESzJP2ZHxXMhRMWw9pl3l+8THts=; b=uN9L8k0j9kvWBi/oygKblM+gyFcnsY1eQWDig+DIsngyyIiCDmjTgvfD3DE9bghbm+ E1AZyH5+65i4CN144IkpQDcYApWNo5DCO+2Kqhu0uQDJlS6jPYD79OJN/i76xFyfLXKJ 3V1V/Jb3U7mXPgaNap0R3mH13y9A3JB08YiVNAXin2HSOO6oZggJ37VKJLUmpYKXH884 vgU9D+R8t/B9cmmsA31tokKhU2XFfQmvMO9PG6IcVyxm9I3gPBA7eqDlyMHexgmrmqx5 8txjGHkjo8raQA/xY33ODAXRwXpjpBdW+ncO4mlVZC14R5WljE/QJlbjvGy6io9bIbtJ bvjQ==
X-Gm-Message-State: AOAM531qKro/qnHzyr49lhi4vw5tTsmDYd0BovUDtGcMYaE035/dQj3w cR7KIodBTI7MsGrT4+WT40Z5bE7N7eExdhC2UAw=
X-Google-Smtp-Source: ABdhPJxz/HpCjb2IXPai5B3z8gkAKNJedxO93ciON08GYjzkn8Xp220u48eZQyHBN0i3dnikTUF9wDulV7V1AjU5QNM=
X-Received: by 2002:a05:6e02:682:: with SMTP id o2mr15576145ils.188.1593764386299;  Fri, 03 Jul 2020 01:19:46 -0700 (PDT)
MIME-Version: 1.0
References:     
In-Reply-To: 
From: Fabien Imbault 
Date: Fri, 3 Jul 2020 10:19:34 +0200
Message-ID: 
To: Dick Hardt 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000019e41105a9853089"
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 03 Jul 2020 08:19:49 -0000

--00000000000019e41105a9853089
Content-Type: text/plain; charset="UTF-8"

Thanks Dick.

Likewise, comments inserted (marked with "FI").

On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt  wrote:

> Hi Fabien, sorry for the late reply
>
> Comments and questions inserted ...
>
> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault 
> wrote:
> 
>
>>
>> Beyond what I said on the redirect, we could probably benefit from a more
>> formal definition of the flows (a bit different between the 2 proposals),
>> as proposed recently by Francis Pouatcha for instance
>> (interact/decoupled/embedded flows, TBD).
>>
>
> Which proposal was that?
>

FI : I'll try to find it back.

>
>
>>
>> What I'm missing in both proposals (personal opinion):
>>
>> - I know that JSON is the usual format, but it would be really useful to
>> complement the schemas with some JSON-LD descriptions as well. It would
>> ease extensions and interoperability (by avoiding conflicting schemas), and
>> could even provide a more generic way of representing verifiable
>> presentations (challenge/nonce associated to a domain for instance). While
>> most of this work on linked data has been done at W3C, it would add value
>> to the current proposal so I think we should consider it.
>>
>
> I'm not understanding how JSON-LD would fit in. Would you provide an
> example?
>

FI : when it comes to extendibility, JSON-LD and JSON schemas could work
together to provide a more explicit information on the type of information
we're handling. You'll find a comparison at
https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs with
standard JWT. In practice, this comes handy as a basis for verified
credentials, would clarify the OIDC semantics and disambiguate the meaning
of specific tokens (see for instance the discussion at
https://www.rfc-editor.org/rfc/rfc8417.html#section-4 on "Preventing
Confusion between SETs and Other JWTs").
https://w3c.github.io/vc-imp-guide/#extending-jwts provides interesting
examples.


>
>>
>> - from an extensibility point of view, I'm not sure it's very useful to
>> list all possibilities. For instance, as of now, it wouldn't be possible to
>> use the protocol for constrained devices, so there's no real value in
>> saying that it could be extended with CoAP (then we need a separate
>> document, that references the current GNAP rfc). What's more useful to know
>> if the context of the current document, when you're implementing it, is
>> what behaviour can really be extended in a fairly straightforward
>> way, without changing anything in the core spec. For instance, what can I
>> do with other types of tokens than JWT? Neither proposal is very clear as
>> to how we would implement extensions in practice.
>>
>
> In XAuth I refer to CoAP not as an extension, but as an one example of
> other client authentication mechanisms. While it only applies to CoAP, I
> think it is useful to call out how we intend GNAP to be extended.
>

FI : isn't the charter already covering this?

>
> Just like OAuth 2.0, the access token is opaque to the client, and it is
> not specified, so I'm confused what you mean by "other types of tokens than
> JWT"?
>
> FI : I mean, for instance, linked data proofs, macaroons, and so on.

>
>
>>
>> - from an implementation perspective, it would make sense to decompose
>> the flow between the Grant Server (GS) and the login/consent part (as done
>> for instance by ory.sh). This way you would separate the concerns: on one
>> side you have the HTTP flows (managed by the GS, which can be very
>> optimized from a backend perspective), but you can delegate/customize the
>> interaction UI to some agreed dedicated endpoint (typically a JS site).
>> Maybe that's just a detail which doesn't have its place in the spec, but
>> since it would change the flow, it might be important to consider, at least
>> as a possibility/extension.
>>
>
> Is the interaction UI not part of the GS though? I agree that an
> implementation can decompose those, but that sounds like an implementation
> choice of the GS, and not something that requires standardization. I agree
> that we want to anticipate the decomposition.* Is there a change in the
> flow that would make that easier?
>

FI : I agree with you on the principle. We're currently testing that to
make sure the standard is supporting these kind of implementation choice.
In XYZ, it means changing the URI for the interaction, having an additional
nonce for the interact server (maybe we can remove that constraint later
on, because it changes details in the interaction), and the rest stays the
same.

>
> *One of the reasons I favor using URIs and methods for the different
> functionality of the GS API is that it is easy for a router to route a
> request to different components of the GS.
>

FI : yes, and that's something interesting that we'll need to discuss
further.

>
> /Dick
>
>>

--00000000000019e41105a9853089
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Dick.=C2=A0
=

Likewise, comments inserted (marked with "FI").
On =
Thu, Jul 2, 2020 at 7:34 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Fabien, so=
rry for the late reply

Comments and questions=C2=A0inser=
ted ...=C2=A0

On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <fabien.imbault@gma=
il.com> wrote:
<snip>

Beyond what I said on the redirect, we could probably benefit from =
a more formal definition of the flows (a bit different between the 2 propos=
als), as proposed recently by Francis Pouatcha for instance (interact/decou=
pled/embedded flows, TBD).

=
Which proposal was that?

=
FI : I'll try to find it back.=C2=A0
=C2=
=A0

What I'm missing in both proposals (per=
sonal opinion):=C2=A0

- I know that JSON is the us=
ual format, but it would be really useful to complement the schemas with so=
me JSON-LD descriptions as well. It would ease extensions and interoperabil=
ity (by avoiding conflicting schemas), and could even provide a more generi=
c way of representing verifiable presentations (challenge/nonce associated =
to a domain for instance). While most of this work on linked data has been =
done at W3C, it would add value to the current proposal so=C2=A0I think we =
should consider it.=C2=A0

I'=
;m not understanding how JSON-LD would fit in. Would you provide an example=
?

FI : when it comes to e=
xtendibility, JSON-LD and JSON schemas could work together to provide a mor=
e explicit information on the type of information we're handling. You&#=
39;ll find a comparison at=C2=A0https://w3c.github.io/vc-imp-guide/#=
benefits-of-json-ld-and-ld-proofs=C2=A0with standard JWT. In practice, =
this comes handy as a basis for verified credentials, would clarify the OID=
C semantics and disambiguate the meaning of specific tokens (see for instan=
ce the discussion at=C2=A0https://www.rfc-editor.org/rfc/rfc8417.html#section-4=
=C2=A0on "Preventing Confusion between SETs and Other JWTs").=C2=
=A0=C2=A0
https://w3c.github.io/vc-imp-guide/#extending-jwts=C2=A0provide=
s interesting examples.=C2=A0

=
=C2=A0

- from an extensibility point of view, I'm not =
sure it's very useful to list all possibilities. For instance, as of no=
w, it wouldn't be possible to use the protocol for constrained devices,=
 so there's no real value in saying that it could be extended with CoAP=
 (then we need a separate document, that references the current GNAP rfc). =
What's more useful to know if the context of the current document, when=
 you're implementing it, is what behaviour can really be extended in a =
fairly straightforward way,=C2=A0without changing anything in the core spec=
. For instance, what can I do with other types of tokens than JWT? Neither =
proposal is very clear as to how we would implement extensions in practice.=


In XAuth I refer to CoAP not a=
s an extension, but as an one example of other client authentication mechan=
isms. While it only applies to CoAP, I think it is useful to call out how w=
e intend GNAP to be extended.=C2=A0

=

FI : isn't the charter already covering this?=C2=A0

Just like OAuth 2.0, the access token =
is opaque to the client, and it is not specified, so I'm confused what =
you mean by "other types of tokens than JWT"?

FI : I mean, for instance, linked data proof=
s, macaroons, and so on.=C2=A0
=C2=
=A0

- from an implementation perspective, it would make se=
nse to decompose the flow between the Grant Server (GS) and the login/conse=
nt part (as done for instance by ory.sh). This way you would separate the c=
oncerns: on one side you have the HTTP flows (managed by the GS, which can =
be very optimized from a backend perspective), but you can delegate/customi=
ze the interaction UI to some agreed dedicated endpoint (typically a JS sit=
e). Maybe that's just a detail which doesn't have its place in the =
spec, but since it would change the flow, it might be important to consider=
,=C2=A0at least as a possibility/extension.
Is the interaction UI not part of the GS though? I agree that =
an implementation can decompose those, but that sounds like an implementati=
on choice of the GS, and not something that requires standardization. I agr=
ee that we want to anticipate the decomposition.* Is there a change in the =
flow that would make that easier?

FI : I agree with you on the principle. We're currently testin=
g that to make sure the standard is supporting these kind of implementation=
 choice. In XYZ, it means changing the URI for the interaction, having an a=
dditional nonce for the interact server (maybe we can remove that constrain=
t later on, because it changes details in the interaction), and the rest st=
ays the same.=C2=A0
=


*One of the=
 reasons I favor using URIs and methods for the different functionality=C2=
=A0of the GS API is that it is easy for a router to route a request to diff=
erent components of the GS.

FI : yes, and that's something interesting that we'll need to di=
scuss further.=C2=A0
=C2=A0
/Dick
<=
div dir=3D"ltr">











--00000000000019e41105a9853089--


From nobody Fri Jul  3 02:09: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 9E9283A00DF for ; Fri,  3 Jul 2020 02:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 jAcLuPidQIHM for ; Fri,  3 Jul 2020 02:09:38 -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 7A8AC3A0B3A for ; Fri,  3 Jul 2020 02:09:37 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d12 with ME id yZ9a220094FMSmm03Z9aUQ; Fri, 03 Jul 2020 11:09:35 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 03 Jul 2020 11:09:35 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt 
Cc: Tom Jones , Justin Richer , txauth@ietf.org, Tobias Looker 
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu>  <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr> 
From: Denis 
Message-ID: 
Date: Fri, 3 Jul 2020 11:09:39 +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="------------740A8D61DB12305136E553CC"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 03 Jul 2020 09:09:40 -0000

This is a multi-part message in MIME format.
--------------740A8D61DB12305136E553CC
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Dick,

> Apologies for the delayed response:
>
> On Fri, Jun 26, 2020 at 9:04 AM Denis  > wrote:
>
>     The principle where a RS would only have relationships with one AS
>     would make the model non scalable.
>     It would prevent to get attributes from two different ASs,  for
>     example:
>     identity attributes from a bank and a master degree diploma from a
>     university.
>
>
> Where do you see that the RS can have a relationship with only one AS?

In general, a RS can trust one or more AS, but this does not necessarily 
means that a RS and an AS have a (bi-)lateral relationship.
The current text of the charter is vague enough so that no one can 
really know. The text of the charter should be made more explicit.

>     For privacy reasons, every AS should know as little as possible
>     about the interactions between a client and multiple RSs.
>     It is even possible that this goes as little as knowing /nothing
>     at all/.
>
>
> OAuth 2.0 works this way now.

I don't think so. Today, the only way to request specific attributes in 
OAuth 2.0. is to use the scope/RS pair which means that:

  * the AS knows to which RS the access token is intended, and
  * the AS and the RS have a bi-lateral relationship to know what the
    scope means.

>  The OAuth 2.0 assumption where the AS is in a position to know all 
> the interactions of a given user has with all the RSs
> that an AS server has a relationship with should not be re-iterated.
>
> I am still confused why you think the AS knows anything about the 
> interactions a given user has with all the RSs.
> The AS knows which clients the user is using, but does not need to 
> have any knowledge of which RSs a client is accessing.

In OAuth 2.0, as soon as, for security reasons, an access token is 
targeted then the AS is able to know who the target is.
In GNAP, while not preventing this, we should have the ability to hide 
to the AS who the RS target is.

>  The AS does not need to know anything about the RS. The RS clearly 
> needs to trust the AS, as it is trusting the access granted by the AS 
> to the client,
> but it is /unidirectional trust/ between the RS and the AS.

"unidirectional trust" is not an appropriate wording. Since trust is 
between an entity A and an entity B for some kind of operation C
it does not presume what may happen in terms of trust between entity B 
and entity A. Nevertheless, it looks like that we are in agreement on 
that point.

Denis

>
> /Dick



--------------740A8D61DB12305136E553CC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Dick,

    


    

    

      
      

        
Apologies for the delayed response:

        

        

          
On Fri, Jun 26, 2020 at 9:04
            AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              
The principle where a RS would only have
                relationships with one AS would make the model non
                scalable.

              

              
 It would prevent to get attributes from two
                different ASs,  for example:  

                identity attributes from a bank and a master degree
                diploma from a university.

              

            

          

          


          

          
Where do you see that the RS can have a relationship with
            only one AS?

        

      

    

    
In general, a RS can trust one or more AS, but this does not
      necessarily means that a RS and an AS have a (bi-)lateral
      relationship.

      The current text of the charter is vague enough so that no one can
      really know. The text of the charter should be made more explicit.

      

    

    

      

        

          

            

              
 

              For privacy reasons, every AS should know as little as
              possible about the interactions between a client and
              multiple RSs.

              
It is even possible that this goes as little as
                knowing nothing at all.

            

          

          


          

          
OAuth 2.0 works this way now. 

          

        

      

    

    
I don't think so. Today, the only way to request specific
      attributes in OAuth 2.0. is to use the scope/RS pair which means
      that:

    
    
      
  • the AS knows to which RS the access token is intended, and
    • 
      
  • the AS and the RS have a bi-lateral relationship to know what
        the scope means.
    
      
    • 
    

    

      

        

          
 The OAuth 2.0 assumption where the AS is in a position
            to know all the interactions of a given user has with all
            the RSs 

            that an AS server has a relationship with should not be
            re-iterated.

          


          

          
I am still confused why you think the AS knows anything
            about the interactions a given user has with all the RSs. 

            The AS knows which clients the user is using, but does not
            need to have any knowledge of which RSs a client is
            accessing.

        

      

    

    
In OAuth 2.0, as soon as, for security reasons, an access token
      is targeted then the AS is able to know who the target is.

      In GNAP, while not preventing this, we should have the ability to
      hide to the AS who the RS target is.

    

    

      

        

          
 The AS does not need to know anything about the RS. The
            RS clearly needs to trust the AS, as it is trusting the
            access granted by the AS to the client, 

            but it is unidirectional trust between the RS and
            the AS.

        

      

    

    
"unidirectional trust" is not an appropriate wording. Since trust
      is between an entity A and an entity B for some kind of operation
      C 

      it does not presume what may happen in terms of trust between
      entity B and entity A. Nevertheless, it looks like that we are in
      agreement on that point.

    

    
Denis

    

    

      

        

          


          

          
/Dick

        

      

    

    


    

  


--------------740A8D61DB12305136E553CC--


From nobody Fri Jul  3 02:16:32 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 8C36E3A0B21 for ; Fri,  3 Jul 2020 02:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level: 
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 fJKEuZidRESg for ; Fri,  3 Jul 2020 02:16:17 -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 8F03A3A0B2C for ; Fri,  3 Jul 2020 02:16:16 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d12 with ME id yZGD2200L4FMSmm03ZGEYb; Fri, 03 Jul 2020 11:16:14 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 03 Jul 2020 11:16:14 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt 
Cc: iesg@ietf.org, txauth@ietf.org
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com>    
From: Denis 
Message-ID: <3c21e0fa-5636-54fe-675f-abc5b41ab09e@free.fr>
Date: Fri, 3 Jul 2020 11:16: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="------------E1AE8D21848A3C5B35C88752"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 03 Jul 2020 09:16:20 -0000

This is a multi-part message in MIME format.
--------------E1AE8D21848A3C5B35C88752
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Dick,

> Catching up on this email ... comments inserted ...
>
> On Mon, Jun 29, 2020 at 12:06 AM Denis  > wrote:
>
>     Hello Dick,
>
>>     Denis, thanks for sharing your thoughts, some clarifications on
>>     your statements inserted:
>>
>>     On Fri, Jun 26, 2020 at 9:42 AM Denis >     > wrote:
>>     
>>
>>             *New proposed charter*
>>
>>     
>>
>>
>>             Resource servers inform their clients about which access
>>             token formats are acceptable and depending upon the king
>>             of operation
>>             that is requested, which kind of attributes are needed
>>             and from which ASs that my be obtained.
>>
>>     While at times this may be appropriate, at other times disclosing
>>     the attributes the RS requires is not needed by the client.
>>     For example, an enterprise client accessing a resource does not
>>     need to know which groups a user belongs to,
>>     but the RS may require that to determine if the user running the
>>     client has access.
>
>     As soon as there is a desire to implement privacy by default, the
>     client should not provide more attributes than strictly necessary.
>     Even after three readings of your example, I failed to understand it.
>
>>
>>             A major difference with OAuth 2.0 is that there is no
>>             bilateral trust relationship between an authorization
>>             server and a resource server:
>>             for a given category of attributes, a resource server may
>>             trust one or more authorization servers. Another major
>>             difference with OAuth 2.0.
>>             is that the content of an attributes token is meant to be
>>             accessible to the client.
>>
>>     This is not how OAuth 2.0 works. See slides 7 and 8 from my
>>     original IETF presentation on what became OAuth 2.0
>>
>>     https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation
>
>     I looked at the two slides.
>
>     Unfortunately slide 7 has just one arrow with the word "trust".
>     This is insufficient to understand what is meant unless being present
>     at the presentation. Does it mean that the PR (RS) trusts one AS
>     or that it may trust multiple ASs ?
>
>     Unfortunately slide 8 has just one arrow between the PR and the AS
>     which is red-crossed but no text at all. This is insufficient to
>     understand
>     what is meant unless being present at the presentation. Does it
>     mean that the PR and the AS never communicate directly ?
>     Does it mean that they have no relationships at all, besides the
>     one way trust relationship mentioned in slide 7 ?
>
>     So it hard to say whether these two slides are indeed meaning that
>     there is no bilateral relationship between an authorization server
>     and a resource server.
>
> Apologies for not providing an explanation on the slides.
>
> Slide 7 shows that trust between the AS and PR (now RS) was 
> unidirectional, from the RS to the AS.
> Slide 8 indicates that trust is not bidirectional.

[Denis]  ... which means that slide 8 contradicts slide 7.  :-)

I would have preferred that you meant: the RS and the AS never 
communicate directly, which is indeed a nice property to follow
to ensure the user's privacy.

> There is no limit on how many ASs an RS may trust.

[Denis] This is fine.

> On June 12, Nat Sakimura recently answered to an email with the 
> following topic:
>
>         Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The
>         OAuth 2.0 Authorization Framework: JWT Secured Authorization
>         Request))
>
>     My arguments were:
>
>          The original model for OAuth was making the assumption that
>     the AS and the RS had a strong bilateral relationship.
>
>     *A key question is whether such strong relationship will be
>     maintained for ever *or
>          whether it will be allowed to perform some evolutions of this
>     relationship.
>
>          In order to respect the privacy of the users, there is the
>     need to encompass other scenarios. One of these scenarios is that
>     the AS and the RS
>          do not need any longer to have such a strong relationship. In
>     terms of trust relationships, a RS simply needs to trust the
>     access tokens issued by an AS.
>          The AS does have any more a "need to know" of all the RSs
>     that are accepting its access tokens. This would be a major
>     simplification of the current global architecture.
>
>     Nat's position was:
>
>         "My take is that the basic assumption of OAuth 2.0 Framework
>         is that there is a strong relationship between AS and RS.
>         I feel that it is quite unrealistic that an RS would trust the
>         access token issued by an AS that it has no strong
>         relationship with".
>
>     There are indeed different positions on this topic.
>
>
> I don't think Nat and I have different opinions, but I will let Nat 
> clarify.
> Just because there is a strong relationship between the AS and RS, 
> does not mean it is bidirectional. I would understand
>
> "I feel that it is quite unrealistic that an RS would trust the access 
> token issued by an AS that it has no strong relationship with"
>
> to indicate Nat is expecting the trust to be from the RS to the AS.

[Denis]  Speaking of a "strong relationship" is ambiguous. The key point 
being whether the relationship is unilateral or bilateral.
There is no need to use the wording "strong relationship" when the 
relationship is only unilateral: a RS simply trusts an AS for the access 
tokens it issues.
In such a case, this does not mean that an AS is knowing all the RSs 
that are trusting it.

On the contrary, a strong (bi-)relationship is when a RS and an AS both 
agree between them about the meaning of scope parameters.
This is a typical case for OAuth 2.0.

>
>>     The AS may not even know who the RS (or PR in the slides) is.
>>
>>     
>>
>>
>>         I got rid of the word "delegation": the client does not
>>         delegate anything to an authorization server. If it would,
>>         this would mean that the authorization server
>>         would be able to act as the client and could know everything
>>         that the client will do, which comes into contradiction with
>>         the user's privacy.
>>
>>
>>     The above is not true.
>>     The Resource Owner is delegating access control to the AS in
>>     authorization use cases.
>
>     The OAuth 2.0 model does not mandate any more the presence of a
>     Resource Owner.
>
>
> Why do you say that? The RO is who owns the RS. Your statement does 
> not make sense.

[Denis]  I mean that there is not necessarily a protocol defined so that 
the RO can interact with the requests from the clients.

>>
>>     The client is may be delegating user authentication to the AS in
>>     identity claim use cases.
>
>     Delegating user authentication to the AS is different from
>     delegating access control to the AS.
>
>
> Agreed. Your statement was there was no delegation. I'm explaining 
> there are potentially two delegations.
>
>>
>>     The AS can act as the client in many OAuth deployments, as the
>>     access token is a bearer token.
>
>     A bearer token is rather insecure.
>
> Cookies are also bearer tokens. But we use them all the time in 
> web apps for storing session state and prior authentication! :)
>
>>     That does not mean the AS knows what the client is doing.
>
>     There are currently two attempts in the OAuth WG to let know to
>     the AS what the client is doing:
>
>       * draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization
>         Framework: JWT Secured Authorization Request)
>       * draft-ietf-oauth-rar-01     (OAuth 2.0 Rich Authorization
>         Requests)
>
> Those are optional, and in some situations are a desired property.

[Denis]  However, in these two drafts, the privacy considerations 
sections are silent on this point.

Denis

> /Dick
>


--------------E1AE8D21848A3C5B35C88752
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Dick,

    


    

    

      
      

        

          

            

              
Catching up on this email ... comments inserted ...

              

              

                
On Mon, Jun 29, 2020
                  at 12:06 AM Denis <denis.ietf@free.fr>
                  wrote:

                

                

                  

                    
Hello Dick,

                    


                      

                    

                      

                        
Denis, thanks
                            for sharing your thoughts, some
                            clarifications on your statements inserted:

                        

                        
                        

                          
On Fri, Jun 26, 2020 at 9:42
                              AM Denis <denis.ietf@free.fr>
                              wrote:

                          
<snip>

                          

                            

                              

                                

                                  
New
                                            proposed charter

                                

                              

                            

                          

                          
<snip> 

                          

                            

                              

                                
 

                                            Resource servers inform
                                            their clients about which
                                            access token formats are
                                            acceptable and depending
                                            upon the king of operation

                                            that is requested, which
                                            kind of attributes are
                                            needed and from which ASs
                                            that my be obtained.

                                              

                                      

                              

                            

                          

                          
While at times this
                              may be appropriate, at other times
                              disclosing the attributes the RS requires
                              is not needed by the client. 

                              For example, an enterprise client
                              accessing a resource does not need to know
                              which groups a user belongs to, 

                              but the RS may require that to determine
                              if the user running the client has access.

                            

                        

                      

                    

                    
As soon as there is a desire
                        to implement privacy by default, the client
                        should not provide more attributes than strictly
                        necessary. 

                        Even after three readings of your example, I
                        failed to understand it.

                      

                    

                      

                        

                          

                            

                              

                                
 

                                        A major difference with OAuth
                                        2.0 is that there is no
                                        bilateral trust relationship
                                        between an authorization server
                                        and a resource server: 

                                        for a given category of
                                        attributes, a resource server
                                        may trust one or more
                                        authorization servers. Another
                                        major difference with OAuth 2.0.

                                        is that the content of an
                                        attributes token is meant to be
                                        accessible to the client.

                              

                            

                          

                          
This is not how OAuth
                              2.0 works. See slides 7 and 8 from my
                              original IETF presentation on what became
                              OAuth 2.0

                          


                            

                          
                        

                      

                    

                    
I looked at the two slides. 

                      

                    
Unfortunately slide 7 has just
                        one arrow with the word "trust". This is
                        insufficient to understand what is meant unless
                        being present 

                        at the presentation. Does it mean that the PR
                        (RS) trusts one AS or that it may trust multiple
                        ASs ?

                  

                

                

                  

                    
 

                    
Unfortunately slide 8 has just
                        one arrow between the PR and the AS which is
                        red-crossed but no text at all. This is
                        insufficient to understand

                        what is meant unless being present at the
                        presentation. Does it mean that the PR and the
                        AS never communicate directly ?

                        Does it mean that they have no relationships at
                        all, besides the one way trust relationship
                        mentioned in slide 7 ?

                    
So it hard to say whether
                        these two slides are indeed meaning that there is no
                            bilateral relationship between an
                            authorization server and a resource server.

                  

                

                

                  
Apologies for not providing an explanation on the
                    slides.

                  


                  

                  
Slide 7 shows that trust between the AS and PR
                    (now RS) was unidirectional, from the RS to the AS.

                  
Slide 8 indicates that trust is not
                    bidirectional.

                

              

            

          

        

      

    

    
[Denis]  ... which means that slide 8
        contradicts slide 7.  :-) 

      

    
I would have preferred that you meant: the RS
        and the AS never communicate directly, which is indeed a nice
        property to follow 

        to ensure the user's privacy.

        

      

    

      

        

          

            

              

                

                  
There is no limit on how many ASs an RS may
                    trust.

                

              

            

          

        

      

    

    
[Denis] This is fine.

    

      

        

          

            

              

                
 On June 12,
                    Nat Sakimura recently answered to an email
                    with the following topic:

                

                  
  
                    

                      
Re:
                          [OAUTH-WG] Comments on
                          draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
                          Authorization Framework: JWT Secured
                          Authorization Request))

                    

                     
                    
My arguments
                        were:

                     
                    
     The
                        original model for OAuth was making the
                        assumption that the AS and the RS had a strong
                        bilateral relationship.

                      

                            A key question is
                          whether such strong relationship will be
                          maintained for ever or 

                           whether it will be allowed
                        to perform some evolutions of this relationship.

                      

                           In order to respect the
                        privacy of the users, there is the need to
                        encompass other scenarios. One of these
                        scenarios is that the AS and the RS 

                           do not need any longer to
                        have such a strong relationship. In terms of
                        trust relationships, a RS simply needs to trust
                        the access tokens issued by an AS. 

                           The AS does have any more
                        a "need to know" of all the RSs that are
                        accepting its access tokens. This would be a
                        major simplification of the current global
                        architecture.

                     
                    
Nat's
                        position was: 

                      

                     
                    

                      
"My take
                          is that the basic assumption of OAuth 2.0
                          Framework is that there is a strong
                          relationship between AS and RS. 

                          I feel that it is quite unrealistic that an RS
                          would trust the access token issued by an AS
                          that it has no strong relationship with".

                    

                     
                    
There are
                        indeed different positions on this topic.  

                      

                  

                

                


                

                
I don't think Nat and I have different opinions,
                  but I will let Nat clarify.

                
Just because there is a strong relationship between
                  the AS and RS, does not mean it is bidirectional. I
                  would understand 

                


                

                
"I feel that it is quite unrealistic that an RS
                  would trust the access token issued by an AS that it
                  has no strong relationship with"

                


                

                
to indicate Nat is expecting the trust to be from
                  the RS to the AS.

              

            

          

        

      

    

    
[Denis]  Speaking of a "strong relationship"
        is ambiguous. The key point being whether the relationship is
        unilateral or bilateral.

        There is no need to use the wording "strong relationship" when
        the relationship is only unilateral: a RS simply trusts an AS
        for the access tokens it issues. 

        In such a case, this does not mean that an AS is knowing all the
        RSs that are trusting it.

    
On the contrary, a strong (bi-)relationship is
        when a RS and an AS both agree between them about the meaning of scope
        parameters.

        This is a typical case for OAuth 2.0.

    

    

      

        

          

            

              


                

                  

                    

                      

                        

                          
The AS may not even
                              know who the RS (or PR in the slides) is.

                          


                            

                          
<snip> 

                          

                            

                              

                                
 

                                        I got rid of the word
                                        "delegation": the client does
                                        not delegate anything to an
                                        authorization server. If it
                                        would, this would mean that the
                                        authorization server 

                                        would be able to act as the
                                        client and could know everything
                                        that the client will do, which
                                        comes into contradiction with
                                        the user's privacy.

                                      

                              

                            

                          

                          


                            

                          
The above is not true.

                          
 

                          
The Resource Owner is
                              delegating access control to the AS in
                              authorization use cases.

                        

                      

                    

                    
The OAuth 2.0 model does not
                        mandate any more the presence of a Resource
                        Owner.

                  

                

                


                

                
Why do you say that? The RO is who owns the RS.
                  Your statement does not make sense.

              

            

          

        

      

    

    
[Denis]  I mean that there is not necessarily
        a protocol defined so that the RO can interact with the requests
        from the clients.

    

    

      

        

          

            

              

                
 

                

                  

                    

                      

                        

                          


                            

                          
The client is may be
                              delegating user authentication to the AS
                              in identity claim use cases.

                        

                      

                    

                    
Delegating user authentication
                        to the AS is different from delegating access
                        control to the AS.

                  

                

                


                

                
Agreed. Your statement was there was no delegation.
                  I'm explaining there are potentially two delegations. 

                

                  

                    

                      

                        

                          


                            

                          
The AS can act as the
                              client in many OAuth deployments, as the
                              access token is a bearer token. 

                        

                      

                    

                    
A bearer token is rather
                        insecure.

                  

                

                
Cookies are also bearer tokens. But we use them all
                  the time in web apps for storing session state and
                  prior authentication! :)

                


                

                
 

                

                  

                    

                      

                        

                          
That does not mean the
                              AS knows what the client is doing. 

                            

                        

                      

                    

                    
There are currently two
                        attempts in the OAuth WG to let know to the AS
                        what the client is doing:

                    
    
                      
  • draft-ietf-oauth-jwsreq-22  
                          (The OAuth 2.0 Authorization Framework: JWT
                          Secured Authorization Request)
    • 
                      
  • draft-ietf-oauth-rar-01    
                              (OAuth 2.0 Rich Authorization Requests)
    • 
                    

                  

                

                
Those are optional, and in some situations are a
                  desired property.

              

            

          

        

      

    

    
[Denis]  However, in these two drafts, the
        privacy considerations sections are silent on this point.

    
 Denis

    

      

        

          

            

              

                
 

                
/Dick

                


                

              

            

          

        

      

    

    


    

  


--------------E1AE8D21848A3C5B35C88752--


From nobody Fri Jul  3 02:19: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 4EA3B3A0B6F for ; Fri,  3 Jul 2020 02:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 q3UZjF56GfXs for ; Fri,  3 Jul 2020 02:19:29 -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 3CC793A0B84 for ; Fri,  3 Jul 2020 02:19:28 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d12 with ME id yZKR2200K4FMSmm03ZKS2W; Fri, 03 Jul 2020 11:19:26 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 03 Jul 2020 11:19:26 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt , Tom Jones 
Cc: Justin Richer , txauth@ietf.org, Tobias Looker 
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu>  <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr>   
From: Denis 
Message-ID: <88ca4d3c-4605-5220-279e-d1665cbc076d@free.fr>
Date: Fri, 3 Jul 2020 11:19:31 +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="------------6BAC74B084CDCC4CEC48E7AF"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 03 Jul 2020 09:19:38 -0000

This is a multi-part message in MIME format.
--------------6BAC74B084CDCC4CEC48E7AF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello  Dick,
> I agree it is not always true, sorry I did not make that clear.
>
> My statement is that OAuth 2.0 does not require the AS to have 
> knowledge of the RS.

As soon as the scope parameter is being used, then the AS has a prior 
knowledge of the RS.
When the scope parameter is not used, then the client has no ability to 
modulate the attributes.

Even when the AS has a no prior knowledge of the RS, when the access 
token is targeted to a given RS,
then the AS has the knowledge of which RS is likely to be accessed by 
the client.

While it may be interesting to list some of the limitations of OAuth 
2.0, it is much more important
to focus on the characteristics we would like to support with GNAP ...  
and to mention them in the charter.

Denis

>
> On Thu, Jul 2, 2020 at 10:56 AM Tom Jones 
> > 
> wrote:
>
>     Dick, the statement about the AS and RS is not always true. In
>     federations we are always concerned that information is not leaked
>     outside the approved parties and the AS messages will likely be
>     encrypted for the sole use of the RS.
>     Peace ..tom
>
>
>     On Thu, Jul 2, 2020 at 10:44 AM Dick Hardt      > wrote:
>
>         Apologies for the delayed response:
>
>         On Fri, Jun 26, 2020 at 9:04 AM Denis          > wrote:
>
>             The principle where a RS would only have relationships
>             with one AS would make the model non scalable.
>             It would prevent to get attributes from two different
>             ASs,  for example:
>             identity attributes from a bank and a master degree
>             diploma from a university.
>
>
>         Where do you see that the RS can have a relationship with only
>         one AS?
>
>
>             For privacy reasons, every AS should know as little as
>             possible about the interactions between a client and
>             multiple RSs.
>             It is even possible that this goes as little as knowing
>             /nothing at all/.
>
>
>         OAuth 2.0 works this way now.
>
>
>             The OAuth 2.0 assumption where the AS is in a position to
>             know all the interactions of a given user has with all the
>             RSs
>             that an AS server has a relationship with should not be
>             re-iterated.
>
>
>         I am still confused why you think the AS knows anything abou
>         the interactions a given use has with all the RSs. The AS
>         knows which clients the user is using, but does not need to
>         have any knowledge of which RSs a client is accessing.
>         The AS does not need to know anything about the RS. The RS
>         clearly needs to trust the AS, as it is trusting the access
>         granted by the AS to the client, but it is unidirectional
>         trust between the RS and the AS.
>
>         /Dick
>


--------------6BAC74B084CDCC4CEC48E7AF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello  Dick,

    

      
      
I agree it is not always true, sorry I did not make
        that clear.
        


        

        
My statement is that OAuth 2.0 does not require the AS to
          have knowledge of the RS.

      

    

    
As soon as the scope parameter is being used, then the AS has a
      prior knowledge of the RS.

      When the scope parameter is not used, then the client has no
      ability to modulate the attributes.

    
Even when the AS has a no prior knowledge of the RS, when the
      access token is targeted to a given RS, 

      then the AS has the knowledge of which RS is likely to be accessed
      by the client.

    
While it may be interesting to list some of the limitations of
      OAuth 2.0, it is much more important 

      to focus on the characteristics we would like to support with GNAP
      ...  and to mention them in the charter.

    
Denis

    


      

        
On Thu, Jul 2, 2020 at 10:56
          AM Tom Jones <thomasclinganjones@gmail.com>
          wrote:

        

        

          
Dick, the statement about the AS and RS is not
            always true. In federations we are always concerned that
            information is not leaked outside the approved parties and
            the AS messages will likely be encrypted for the sole use of
            the RS.

            

              

                

                  
Peace ..tom

                

              

            

            

          

          

          

            
On Thu, Jul 2, 2020 at
              10:44 AM Dick Hardt <dick.hardt@gmail.com>
              wrote:

            

            

              

                
Apologies for the delayed response:

                

                

                  
On Fri, Jun 26, 2020
                    at 9:04 AM Denis <denis.ietf@free.fr>
                    wrote:

                  

                  

                    

                      
The principle where a RS would only have
                        relationships with one AS would make the model
                        non scalable.

                      

                      
 It would prevent to get attributes from two
                        different ASs,  for example:  

                        identity attributes from a bank and a master
                        degree diploma from a university.

                      

                    

                  

                  


                  

                  
Where do you see that the RS can have a
                    relationship with only one AS?

                  
 

                  

                  

                    

                      
 

                      


                      

                      For privacy reasons, every AS should know as
                      little as possible about the interactions between
                      a client and multiple RSs.

                      
It is even possible that this goes as little
                        as knowing nothing at all.

                    

                  

                  


                  

                  
OAuth 2.0 works this way now. 

                  
 

                  

                    

                      


                      

                      

                        
The OAuth 2.0 assumption where the AS is in
                          a position to know all the interactions of a
                          given user has with all the RSs 

                          that an AS server has a relationship with
                          should not be re-iterated.

                      

                    

                  

                  


                  

                  
I am still confused why you think the AS knows
                    anything abou the interactions a given use has with
                    all the RSs. The AS knows which clients the user is
                    using, but does not need to have any knowledge of
                    which RSs a client is accessing.

                  
 

                  
 

                  
The AS does not need to know anything about the
                    RS. The RS clearly needs to trust the AS, as it is
                    trusting the access granted by the AS to the client,
                    but it is unidirectional trust between the RS and
                    the AS.

                  


                  

                  
/Dick

                

              

            

          

        

      

    

    


    

  


--------------6BAC74B084CDCC4CEC48E7AF--


From nobody Fri Jul  3 02:27: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 8086D3A0B6B for ; Fri,  3 Jul 2020 02:27:55 -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 MZVdAM4Jhy6c for ; Fri,  3 Jul 2020 02:27:54 -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 364763A0044 for ; Fri,  3 Jul 2020 02:27:54 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id a12so31848741ion.13 for ; Fri, 03 Jul 2020 02:27:54 -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=n21CwZk9k4hVl/D6R8mZzqRoE6uFT7uXml02Bum4u9Q=; b=FpBsMP+5a/pnVzYlSdNK1PXeE+pPl1FG0W+P7ik3v1978mk+ffaNIrk5YXyiI+D6Od pZCDQH6LV/PbzclE2a5YO9E6gB3uvNFOw7YcM1AeqC774c4rwcJiIDoypR0t/FB452oI yfBt8A6knY2fDTaL3TSjNdavCdwG9S1xCSX70t2kO7VtwTrF8aN59MRvVhsGBuQRHXFb yU7YuuQnwIqBQ7bqw16LBNh/pyH7drAGnFOY20yWj4VU//JmerMTHJiI0VpOc3IflIGe 7ijZukSXeHpZNXfSQHs5Pi/7zJEupWN6qw80ZU86nIab2tCZQnqAcweudgyw3BHLJXDN vGMA==
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=n21CwZk9k4hVl/D6R8mZzqRoE6uFT7uXml02Bum4u9Q=; b=YyoPjLUOk7qF1fQZu2kClBbOCjN/nMOeIZoz1mDZ6XUhPakdPq0oYy2WAMjkWS24qQ L4Ravr7mVoOy1Br3s+Oxgsm/YsGy41BmSJO3SIu6vm+HLfBefFqjXVQg4G0YdpFFn1CC bMoaA5Kot3/5JEOupZVUgnTm+8WHxEvkmmbcJvi/JE2HBWm6aWL2UxnggTdeGFyjfjsX A6WVx0tY/vX/oksxUxusbvWLn2vOl7I0oCxI3FjPd36Ah0BMzjECiCU/i+5SJlihMTc6 jGxviprXCRxtDSds8ykHSeI47W1mGq+NogPB+gwEvcIAl3CCCC/XMklI9z/qVDW4goxv /+lw==
X-Gm-Message-State: AOAM5332qK3oaxDVuJpT6DbWkEYqYs/rJ5KKvQL4366tbQd7OqyRuGAs oDtJFxQZpKLCIhV9yHCcaZMt3tg8Eoa77SQYkMVnzBQ0iB4=
X-Google-Smtp-Source: ABdhPJyjyGNKLmwsVKJDEVOYmIpe1cpR4Y1UbJDpV1dGon9WoqqXXWCsrdTVfla4I66v13GzWxzQ++3wIUeN7ajdKaE=
X-Received: by 2002:a5d:8f98:: with SMTP id l24mr11331064iol.141.1593768473273;  Fri, 03 Jul 2020 02:27:53 -0700 (PDT)
MIME-Version: 1.0
From: Fabien Imbault 
Date: Fri, 3 Jul 2020 11:27:42 +0200
Message-ID: 
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b4276205a9862389"
Archived-At: 
Subject: [Txauth] RS/AS communication for multiparty 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: Fri, 03 Jul 2020 09:27:56 -0000

--000000000000b4276205a9862389
Content-Type: text/plain; charset="UTF-8"

Hello Denis,

I have been following your comments. I still fail to see the global privacy
preserving architecture you're proposing. It would help to get a more
thorough proposal if you can.

But more specifically, I have a comment on :

"I would have preferred that you meant: the RS and the AS never
communicate directly, which is indeed a nice property to follow
to ensure the user's privacy."

I think that may come as an issue in some cases, especially for
multiparty patterns (like in UMA). Typically we may wish the RS to
start a grant request and use the handle to continue until a token is
generated.

I think those cases, which weren't initially covered by OAuth2, are
very important to cover as well. How would you cover such
requirements?

Fabien

--000000000000b4276205a9862389
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Denis,

I have been following your=
 comments. I still fail to see the global privacy preserving architecture y=
ou're proposing. It would help to get a more thorough proposal if you c=
an.

But more specifically, I have a comment on :=C2=
=A0

"I would have preferred that yo=
u meant: the RS and the AS never=20
communicate directly, which is indeed a nice property to follow
to ensure the user's privacy."
I think that may com=
e as an issue in some cases, especially for multiparty patterns (like in UM=
A). Typically we may wish the RS to start a grant request and use the handl=
e to continue until a token is generated.
I think those case=
s, which weren't initially covered by OAuth2, are very important to cov=
er as well. How would you cover such requirements?
Fabien


--000000000000b4276205a9862389--


From nobody Fri Jul  3 03:01: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 BAEB03A0BB3 for ; Fri,  3 Jul 2020 03:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level: 
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 t346I6clYU4I for ; Fri,  3 Jul 2020 03:01:17 -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 CB80D3A0BB2 for ; Fri,  3 Jul 2020 03:01:16 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d12 with ME id ya1E220014FMSmm03a1ESW; Fri, 03 Jul 2020 12:01:15 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 03 Jul 2020 12:01:15 +0200
X-ME-IP: 86.238.65.197
To: Fabien Imbault , txauth@ietf.org
References: 
From: Denis 
Message-ID: 
Date: Fri, 3 Jul 2020 12:01: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="------------13E1A0B07ECCFD039866F606"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] RS/AS communication for multiparty 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: Fri, 03 Jul 2020 10:01:19 -0000

This is a multi-part message in MIME format.
--------------13E1A0B07ECCFD039866F606
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Fabien,

In 2017, I made a presentation at the OAuth workshop in Zurich.

The paper is available from: 
https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf

The slides are available from: 
https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.ppt
_Note_: The slides should be viewed "full screen" to get the animations.

The general approach is how to construct from scratch a "privacy by 
design" architecture taking also into consideration "security by design".

Coming back to your requirement, I would not cover it if it infringes 
the sentence "the RS and the AS never communicate directly".

You should start your design by defining the trust relationships, then 
apply the privacy requirements while not forgetting the security 
requirements.

Denis

> Hello Denis,
>
> I have been following your comments. I still fail to see the global 
> privacy preserving architecture you're proposing. It would help to get 
> a more thorough proposal if you can.
>
> But more specifically, I have a comment on :
>
> "I would have preferred that you meant: the RS and the AS never
> communicate directly, which is indeed a nice property to follow
> to ensure the user's privacy."
> I think that may come as an issue in some cases, especially for multiparty patterns (like in UMA). Typically we may wish the RS to start a grant request and use the handle to continue until a token is generated.
> I think those cases, which weren't initially covered by OAuth2, are very important to cover as well. How would you cover such requirements?
> Fabien
>


--------------13E1A0B07ECCFD039866F606
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Fabien,

    


    

    
In 2017, I made a presentation at the
      OAuth workshop in Zurich.

    


    

    
The paper is available from: https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf

    


    

    
The slides are available from: https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.ppt

    

    
Note: The slides should be
      viewed "full screen" to get the animations. 

    

    


    

    
The general approach is how to
      construct from scratch a "privacy by design" architecture taking
      also into consideration "security by design".

    


    

    
Coming back to your requirement, I
      would not cover it if it infringes the sentence "the RS and the AS
      never communicate directly".

    


    

    
You should start your design by
      defining the trust relationships, then apply the privacy
      requirements while not forgetting the security requirements.

      

    

    
Denis

    


    

    

      
      
Hello Denis,
        


        

        
I have been following your comments. I still fail to see
          the global privacy preserving architecture you're proposing.
          It would help to get a more thorough proposal if you can.

          


          

          
But more specifically, I have a comment on : 

          


          

          

            
"I would have preferred that you meant: the RS and the AS never 
communicate directly, which is indeed a nice property to follow
to ensure the user's privacy."

            
I think that may come as an issue in some cases, especially for multiparty patterns (like in UMA). Typically we may wish the RS to start a grant request and use the handle to continue until a token is generated.

            
I think those cases, which weren't initially covered by OAuth2, are very important to cover as well. How would you cover such requirements?

            
Fabien

          

        

      

      

      

    

    


    

  


--------------13E1A0B07ECCFD039866F606--


From nobody Fri Jul  3 07:46: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 E69BA3A0860 for ; Fri,  3 Jul 2020 07:46:26 -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 0B-y0brAGftP for ; Fri,  3 Jul 2020 07:46:25 -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 382703A0835 for ; Fri,  3 Jul 2020 07:46:25 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id r12so20278573ilh.4 for ; Fri, 03 Jul 2020 07:46:25 -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=ijeGpa0ty3w+ZEVPKrKX7rS9ku+srtTgYxM7Gt5F+sI=; b=GsP7RHqKOSRWgCK5Wg/ojW2Om1hW1WI6Hq/CEV4t5q8YbTnUtIycHyJQcwEvX5w9vv uogAcVQ46vnu1ZnH4itj/Q6tP6WMrKXp7RQe6JgRmAs5oww3f8evbLV6GapNz2fu5yEF f7bFajlZCBycPELRIn9CwotZAoVI+t8vf4f/NwDBtvsi92Y4OR9E18nn2/cllQwUr3Zc 00b7zXzzPezPStGdxdC/9Db04YPPFp2MpGFrRxnQm0smM/G0eR6f81W/5yYjbdSW0JNn Z154igwycYxwqWKcs/axjjzCXvtT2EVizq4nHdmh6dNyb5PlPVSoxEe6acS9qlfmzYJe uVHA==
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=ijeGpa0ty3w+ZEVPKrKX7rS9ku+srtTgYxM7Gt5F+sI=; b=OnKxFwhAnIhKXb7o7ippDqYzEcXKreqXmDtf21AzkvhH9IkoWRXK3NEPXiI8OhY6N0 5nPEILpO5RUR5XcgdxAfZyyzp2zAuZL+sLV8m5eUgSO7PXgBv5Cwjl4ltqt90R8+3A7y rEvQyTA3znIL8El0ValCF0x/Al9YLUdhoTL1tH22ed7BmX8G4nWIvfh778+22+LJmD3T qp/xRzI8jeMujKwHkUJQIeTWOyrLHkhsa7yKZqOgcB2cVjCdwItiK9MQVGIFeHYIeoUC NHi1mS3fHUWTEiZMD1eRQN+mBCCeHf/PtHoF/3EeXK7ZJWXO0uvGnkjNfjBRZ2JN/UNq VUqg==
X-Gm-Message-State: AOAM533dFge0qgAgzrk0GCMaZAoOV468ZSbSBur4QRPXVqg7QUZCkfoy naWbTjMYPJIuxxvXn+KE/y1SHlqJ9gnp6zSyOOZ0T80W
X-Google-Smtp-Source: ABdhPJyk4NeT5ViDtqckfzyM7GUBYIsauqcb2xijctdwCq1g4lT76Pi5hD6BfNyywcoK6Q2HGD76/+sKyEigvX1H/Lk=
X-Received: by 2002:a92:b749:: with SMTP id c9mr18798390ilm.289.1593787584383;  Fri, 03 Jul 2020 07:46:24 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Fabien Imbault 
Date: Fri, 3 Jul 2020 16:46:13 +0200
Message-ID: 
To: Denis 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d090e305a98a96f4"
Archived-At: 
Subject: Re: [Txauth] RS/AS communication for multiparty 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: Fri, 03 Jul 2020 14:46:27 -0000

--000000000000d090e305a98a96f4
Content-Type: text/plain; charset="UTF-8"

Thanks Denis. It clarifies what you have in mind.

While I agree with the general idea that we need to take privacy more
seriously, there are a few hypotheses that we need to put in perspective :
1) AS-RS relationship <=> big brother. It may happen as we all know, but
you always have the choice as a user to not deal with orgs you don't like
or maybe even take action if they don't respect the law.
2) the collusion possibility (Alice's uncle) : there are of course
situations where that may be an issue. This is I guess the reason for the
sovrin foundation to require that only approved issuers can participate.
But even if you open up the system, it always ends up as whether you can
trust the uncle to be honest in the first place (knowing that trust is a
social construct). So I may require the issuer to be a well known
participant instead.
3) The use of hardware FIDO inspired components does relax some of the
previous concern, but comes with its own sets of challenges. Biometrics
come with their own sets of potential issues. More trivially, if you loose
your hardware, you loose your ID. And there can also be hacks in hardware.
If I find a way to import or export the private key from the enclave, the
system fails.

So in the end, I agree it's best to enable as much privacy by design as we
possibly can, but we need to put that in perspective with use cases too and
make some tradeoffs. Healthcare in particular is a domain that is concerned
with a constant balance between privacy and security, and sometimes there
is no possibility to tick all boxes.
I think an UMA2/OpenId Heart scenario is a very important case to consider
in that respect.

Fabien




On Fri, Jul 3, 2020 at 12:01 PM Denis  wrote:

> Hello Fabien,
>
> In 2017, I made a presentation at the OAuth workshop in Zurich.
>
> The paper is available from:
> https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf
>
> The slides are available from:
> https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.ppt
> *Note*: The slides should be viewed "full screen" to get the animations.
>
> The general approach is how to construct from scratch a "privacy by
> design" architecture taking also into consideration "security by design".
>
> Coming back to your requirement, I would not cover it if it infringes the
> sentence "the RS and the AS never communicate directly".
>
> You should start your design by defining the trust relationships, then
> apply the privacy requirements while not forgetting the security
> requirements.
>
> Denis
>
> Hello Denis,
>
> I have been following your comments. I still fail to see the global
> privacy preserving architecture you're proposing. It would help to get a
> more thorough proposal if you can.
>
> But more specifically, I have a comment on :
>
> "I would have preferred that you meant: the RS and the AS never
> communicate directly, which is indeed a nice property to follow
> to ensure the user's privacy."
>
> I think that may come as an issue in some cases, especially for multiparty patterns (like in UMA). Typically we may wish the RS to start a grant request and use the handle to continue until a token is generated.
>
> I think those cases, which weren't initially covered by OAuth2, are very important to cover as well. How would you cover such requirements?
>
> Fabien
>
>
>
>

--000000000000d090e305a98a96f4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Denis. It clarifies what you have in mind.=C2=A0
While I agree with the general idea that we need to take p=
rivacy more seriously, there are a few hypotheses that we need to put in pe=
rspective :=C2=A0
1) AS-RS relationship <=3D> big brother. =
It may happen as we all know, but you always have the choice as a user to n=
ot deal with orgs you don't like or maybe even take action if they don&=
#39;t respect the law.=C2=A0 =C2=A0
2) the collusion possibility =
(Alice's uncle) : there are of course situations where that may be an i=
ssue. This is I guess the reason for the sovrin foundation to require that =
only approved issuers can participate. But even if you open up the system, =
it always ends up as whether you can trust the uncle to be honest in the fi=
rst place (knowing that trust is a social construct). So I may require the =
issuer to be a well known participant instead.
3) The use of hard=
ware FIDO inspired components does relax some of the previous concern, but =
comes with its own sets of challenges. Biometrics come with their own sets =
of potential issues. More trivially, if you loose your hardware, you loose =
your ID. And there can also be hacks in hardware. If I find a way to import=
 or export the private key from the enclave, the system fails.
So in the end, I agree it's best to enable as much privacy=
 by design as we possibly can, but we need to put that in perspective with =
use cases too and make some tradeoffs. Healthcare in particular is a domain=
 that is concerned with a constant balance between privacy and security, an=
d sometimes there is no possibility to tick all boxes.=C2=A0
I th=
ink an UMA2/OpenId Heart scenario is a very important case to consider in t=
hat respect.=C2=A0

Fabien=C2=A0




On Fri, Jul 3, 2020 at 12:01 PM Denis <<=
a href=3D"mailto:denis.ietf@free.fr">denis.ietf@free.fr> wrote:
<=
/div>

 =20
   =20
 =20
  

    
Hello Fabien,

    


    

    
In 2017, I made a presentation at the
      OAuth workshop in Zurich.

    


    

    
    


    

    
    
Note: The slides should be
      viewed "full screen" to get the animations. 

    

    


    

    
The general approach is how to
      construct from scratch a "privacy by design" architecture t=
aking
      also into consideration "security by design".

    


    

    
Coming back to your requirement, I
      would not cover it if it infringes the sentence "the RS and the =
AS
      never communicate directly".

    


    

    
You should start your design by
      defining the trust relationships, then apply the privacy
      requirements while not forgetting the security requirements.

      

    

    
Denis

    


    

    

     =20
      
Hello Denis,
        


        

        
I have been following your comments. I still fail to see
          the global privacy preserving architecture you're proposing.
          It would help to get a more thorough proposal if you can.

          


          

          
But more specifically, I have a comment on :=C2=A0

          


          

          

            
&qu=
ot;I would have preferred that you meant: the RS and the AS never=20
communicate directly, which is indeed a nice property to follow
to ensure the user's privacy."

            
I t=
hink that may come as an issue in some cases, especially for multiparty pat=
terns (like in UMA). Typically we may wish the RS to start a grant request =
and use the handle to continue until a token is generated.

            
I t=
hink those cases, which weren't initially covered by OAuth2, are very i=
mportant to cover as well. How would you cover such requirements?

            
Fab=
ien

          

        

      

      

      

    

    


    

  





--000000000000d090e305a98a96f4--


From nobody Fri Jul  3 18:33: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 5DC1E3A0805 for ; Fri,  3 Jul 2020 18:33:25 -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 CkMXVf8N7iFP for ; Fri,  3 Jul 2020 18:33:23 -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 D843B3A0803 for ; Fri,  3 Jul 2020 18:33:22 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id s16so14026703lfp.12 for ; Fri, 03 Jul 2020 18:33: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=sv4FBdhbfVsoa0GJKJPBo7hN5fHiqXl1dnNgcefEVBI=; b=a6294nKklqfrOVcJ8mCPy7uLCcjYuRxVkGpZFdr44p2GBDxDRbcw9/3ndglyGci1uL WorLyLmFs46camyKjkt0j7gT4+IhRwCfqP08JH1O99xW86Gdps0P1Vw7H1TNOVYqVIEq sEXsp83mVkV23irtJt/OTGShW+IaI7iXpQWNxADZqf4FAgVPgzHYZO0axv19qxhujUTd YmApjhfao6fm+kyzmDFpe6xbBlZ/p5UhFjAGVKvyPzvIKnjffDtvG6fkGwPPwxMb5Tba 7IhCMx0onH30xBbbvxyjis8gi3V0mnyA0GTQ6mMmtHwA8D/4sEID96pB6pq5S10Xii1h smaA==
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=sv4FBdhbfVsoa0GJKJPBo7hN5fHiqXl1dnNgcefEVBI=; b=KsbTlzNhb6lQWaS2UxXQDcUDJv8rE5rBv7knBbX0OcNnkOoYGXNg2hsi0rt6/w3zYb ZWpLwt+lLlmAYHlGFil6JaNqoAscgkU29cJW+Xo0mmcMFBB1cT+MxRTKwY93AgJvmQ/M 6xVVjj10awUCzL/atI9sbT05x7ezNPeIv0hU57MZ/LDcok7MpWmKe+fXjOA4Rvu2tyg3 pBBuTdKesWa4KaT5RduyrA69oX0v79plnsYPZoG7xmWI1RKqyU6h/7YrmkhBoKcnD0nv J6sD164Rrph1QWkQiVTlVjKshIgpEHjOEksbkDMst5TaiYXePQpHSWPr/F47ER93/btY G8aw==
X-Gm-Message-State: AOAM530JH9ow0B+Z/CDkXGkrEbFDq0RYgPy98d+NjHG1mJ2sOFVTY5v/ M1SRB9XGjFQ4zz5XzPSnQ5yvwZPClD4CGLpe4p8=
X-Google-Smtp-Source: ABdhPJxZPRsdknVXbqsWNLfDsj0+U5uYpPfOvAwblJNLZYf7mBgiaJGxin5UGX9v0FmqbRsj9y+ytP+gracrTKnZr3s=
X-Received: by 2002:a19:c8a:: with SMTP id 132mr23531313lfm.23.1593826400795;  Fri, 03 Jul 2020 18:33:20 -0700 (PDT)
MIME-Version: 1.0
References:      
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 3 Jul 2020 18:32:44 -0700
Message-ID: 
To: Fabien Imbault 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007402c105a993a0d8"
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 04 Jul 2020 01:33:25 -0000

--0000000000007402c105a993a0d8
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault 
wrote:

> Thanks Dick.
>
> Likewise, comments inserted (marked with "FI").
>
> On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt  wrote:
>
>> Hi Fabien, sorry for the late reply
>>
>> Comments and questions inserted ...
>>
>> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault 
>> wrote:
>> 
>>
>>>
>>> Beyond what I said on the redirect, we could probably benefit from a
>>> more formal definition of the flows (a bit different between the 2
>>> proposals), as proposed recently by Francis Pouatcha for instance
>>> (interact/decoupled/embedded flows, TBD).
>>>
>>
>> Which proposal was that?
>>
>
> FI : I'll try to find it back.
>
>>
>>
>>>
>>> What I'm missing in both proposals (personal opinion):
>>>
>>> - I know that JSON is the usual format, but it would be really useful to
>>> complement the schemas with some JSON-LD descriptions as well. It would
>>> ease extensions and interoperability (by avoiding conflicting schemas), and
>>> could even provide a more generic way of representing verifiable
>>> presentations (challenge/nonce associated to a domain for instance). While
>>> most of this work on linked data has been done at W3C, it would add value
>>> to the current proposal so I think we should consider it.
>>>
>>
>> I'm not understanding how JSON-LD would fit in. Would you provide an
>> example?
>>
>
> FI : when it comes to extendibility, JSON-LD and JSON schemas could work
> together to provide a more explicit information on the type of information
> we're handling. You'll find a comparison at
> https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs with
> standard JWT. In practice, this comes handy as a basis for verified
> credentials, would clarify the OIDC semantics and disambiguate the meaning
> of specific tokens (see for instance the discussion at
> https://www.rfc-editor.org/rfc/rfc8417.html#section-4 on "Preventing
> Confusion between SETs and Other JWTs").
> https://w3c.github.io/vc-imp-guide/#extending-jwts provides interesting
> examples.
>

It appears that you are proposing the JSON-LD be used in claims? Am I
correct? Or is there somewhere it would be used in the Grant Request JSON?

My understanding of the charter is the GNAP is a transport for claims, and
that those would be defined somewhere else. OpenID Connect and Verified
Credentials are good examples. The query for a claims similarly would be
defined somewhere else.


>
>
>>
>>>
>>> - from an extensibility point of view, I'm not sure it's very useful to
>>> list all possibilities. For instance, as of now, it wouldn't be possible to
>>> use the protocol for constrained devices, so there's no real value in
>>> saying that it could be extended with CoAP (then we need a separate
>>> document, that references the current GNAP rfc). What's more useful to know
>>> if the context of the current document, when you're implementing it, is
>>> what behaviour can really be extended in a fairly straightforward
>>> way, without changing anything in the core spec. For instance, what can I
>>> do with other types of tokens than JWT? Neither proposal is very clear as
>>> to how we would implement extensions in practice.
>>>
>>
>> In XAuth I refer to CoAP not as an extension, but as an one example of
>> other client authentication mechanisms. While it only applies to CoAP, I
>> think it is useful to call out how we intend GNAP to be extended.
>>
>
> FI : isn't the charter already covering this?
>

Yes, but most people that are not in the WG don't read the charter. :)


>
>> Just like OAuth 2.0, the access token is opaque to the client, and it is
>> not specified, so I'm confused what you mean by "other types of tokens than
>> JWT"?
>>
>> FI : I mean, for instance, linked data proofs, macaroons, and so on.
>

I see. When I read 'token', I think of access tokens. You are referring to
what I would call a claims, which per above are defined somewhere else.


>
>>
>>>
>>> - from an implementation perspective, it would make sense to decompose
>>> the flow between the Grant Server (GS) and the login/consent part (as done
>>> for instance by ory.sh). This way you would separate the concerns: on one
>>> side you have the HTTP flows (managed by the GS, which can be very
>>> optimized from a backend perspective), but you can delegate/customize the
>>> interaction UI to some agreed dedicated endpoint (typically a JS site).
>>> Maybe that's just a detail which doesn't have its place in the spec, but
>>> since it would change the flow, it might be important to consider, at least
>>> as a possibility/extension.
>>>
>>
>> Is the interaction UI not part of the GS though? I agree that an
>> implementation can decompose those, but that sounds like an implementation
>> choice of the GS, and not something that requires standardization. I agree
>> that we want to anticipate the decomposition.* Is there a change in the
>> flow that would make that easier?
>>
>
> FI : I agree with you on the principle. We're currently testing that to
> make sure the standard is supporting these kind of implementation choice.
> In XYZ, it means changing the URI for the interaction, having an additional
> nonce for the interact server (maybe we can remove that constraint later
> on, because it changes details in the interaction), and the rest stays the
> same.
>

I'd be interested in the details on how you are implementing it!


>
>> *One of the reasons I favor using URIs and methods for the different
>> functionality of the GS API is that it is easy for a router to route a
>> request to different components of the GS.
>>
>
> FI : yes, and that's something interesting that we'll need to discuss
> further.
>

:)


>
>> /Dick
>>
>>>

--0000000000007402c105a993a0d8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Jul 3, 2020 at 1:19 AM Fabien=
 Imbault <fabien.imbault@gma=
il.com> wrote:
Thanks Dick.=C2=A0

Likewise, comments inserted (marked with "FI"=
;).

On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Fabien, sorry for the late reply

Comments =
and questions=C2=A0inserted ...=C2=A0

On Wed, Jun 17, 2020 at 3:47 AM =
Fabien Imbault <fabien.imbault@gmail.com> wrote:
<snip>

Beyond what I said on the redirect, we coul=
d probably benefit from a more formal definition of the flows (a bit differ=
ent between the 2 proposals), as proposed recently by Francis Pouatcha for =
instance (interact/decoupled/embedded flows, TBD).

Which proposal was that?

FI : I'll try to find it back.=C2=A0
=C2=A0

What I'm missing =
in both proposals (personal opinion):=C2=A0

- I kn=
ow that JSON is the usual format, but it would be really useful to compleme=
nt the schemas with some JSON-LD descriptions as well. It would ease extens=
ions and interoperability (by avoiding conflicting schemas), and could even=
 provide a more generic way of representing verifiable presentations (chall=
enge/nonce associated to a domain for instance). While most of this work on=
 linked data has been done at W3C, it would add value to the current propos=
al so=C2=A0I think we should consider it.=C2=A0

I'm not understanding how JSON-LD would fit in. Would =
you provide an example?

F=
I : when it comes to extendibility, JSON-LD and JSON schemas could work tog=
ether to provide a more explicit information on the type of information we&=
#39;re handling. You'll find a comparison at=C2=A0https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs=C2=A0with standard JWT. In practice, this comes handy as a basis for ver=
ified credentials, would clarify the OIDC semantics and disambiguate the me=
aning of specific tokens (see for instance the discussion at=C2=A0https://www.rfc-editor.org/rfc/rfc8417.html#section-4=C2=A0on "P=
reventing Confusion between SETs and Other JWTs").=C2=A0=C2=A0
https://w3c.github.io/vc-imp-guide/#extending-jwts=C2=A0provid=
es interesting examples.=C2=A0

It appears that you are proposing the JSON-LD be used in claims? Am I=
 correct? Or is there somewhere it would be used in the Grant Request JSON?=


My understanding of the charter is the GNAP is a =
transport for claims, and that those would be defined somewhere else. OpenI=
D Connect and Verified Credentials are good examples. The query for a claim=
s similarly would be defined somewhere else.
=C2=A0

=C2=A0

-=
 from an extensibility point of view, I'm not sure it's very useful=
 to list all possibilities. For instance, as of now, it wouldn't be pos=
sible to use the protocol for constrained devices, so there's no real v=
alue in saying that it could be extended with CoAP (then we need a separate=
 document, that references the current GNAP rfc). What's more useful to=
 know if the context of the current document, when you're implementing =
it, is what behaviour can really be extended in a fairly straightforward wa=
y,=C2=A0without changing anything in the core spec. For instance, what can =
I do with other types of tokens than JWT? Neither proposal is very clear as=
 to how we would implement extensions in practice.
=


In XAuth I refer to CoAP not as an extension, but as an=
 one example of other client authentication mechanisms. While it only appli=
es to CoAP, I think it is useful to call out how we intend GNAP to be exten=
ded.=C2=A0

FI : isn't=
 the charter already covering this?=C2=A0

Yes, but most people that are not in the WG don't read=
 the charter. :)
=C2=A0

Just like OAuth 2.0, the access token is opaque to th=
e client, and it is not specified, so I'm confused what you mean by &qu=
ot;other types of tokens than JWT"?

FI : I mean, for instance, linked data proofs, macaroons, a=
nd so on.=C2=A0

I see. Wh=
en I read 'token', I think of access tokens. You are referring to w=
hat I would call a claims, which per above are defined somewhere else.
=C2=A0
=C2=
=A0

- from an implementation perspective, it would make se=
nse to decompose the flow between the Grant Server (GS) and the login/conse=
nt part (as done for instance by ory.sh). This way you would separate the c=
oncerns: on one side you have the HTTP flows (managed by the GS, which can =
be very optimized from a backend perspective), but you can delegate/customi=
ze the interaction UI to some agreed dedicated endpoint (typically a JS sit=
e). Maybe that's just a detail which doesn't have its place in the =
spec, but since it would change the flow, it might be important to consider=
,=C2=A0at least as a possibility/extension.
Is the interaction UI not part of the GS though? I agree that =
an implementation can decompose those, but that sounds like an implementati=
on choice of the GS, and not something that requires standardization. I agr=
ee that we want to anticipate the decomposition.* Is there a change in the =
flow that would make that easier?

FI : I agree with you on the principle. We're currently testin=
g that to make sure the standard is supporting these kind of implementation=
 choice. In XYZ, it means changing the URI for the interaction, having an a=
dditional nonce for the interact server (maybe we can remove that constrain=
t later on, because it changes details in the interaction), and the rest st=
ays the same.=C2=A0

I'=
;d be interested in the details on how you are implementing it!
=
=C2=A0

*One =
of the reasons I favor using URIs and methods for the different functionali=
ty=C2=A0of the GS API is that it is easy for a router to route a request to=
 different components of the GS.

FI : yes, and that's something interesting that we'll need =
to discuss further.=C2=A0

:)
=C2=A0
=C2=A0=

/Dick
<=
div dir=3D"ltr">












--0000000000007402c105a993a0d8--


From nobody Fri Jul  3 18:42: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 2BD923A0846 for ; Fri,  3 Jul 2020 18:42: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 Blv4jDfTG7vR for ; Fri,  3 Jul 2020 18:41:57 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450: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 449853A0839 for ; Fri,  3 Jul 2020 18:41:57 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id s16so14032781lfp.12 for ; Fri, 03 Jul 2020 18:41: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=fywBnJJXBS3iwjTVMF5Abv7YLt1mZHpq1nJAlFjkZ5E=; b=LAN6Pkxx7dBvb95JxX4KnFSVmCSqbKZ0FFX3BX93pGlG1ULKX3qQf3X//epPCAgLl1 waSgGh8ts6Wd1mCHL0Lmzq01NtJcVBL3bXRKp35LjthslZfHhiwiNBDLGauylNUl3CAj k/PLZEh1CLE4UanTTy75ncOtl/toOHaC2x0PEauCGb1E90zaWe1fYhcAEhrFevN/irZe jIKNepF2szNOyMDM0ym+pj8MpVH1pMoe3nocvGlj5anvCSx5+nLNrjdpoCPhD1/L0IsY yWaDHGDgVx3C9sxB51PRoIpsHzPQ7PXz2hqm1L5WcqOqx/0BR8QipoKCzqfOphoD1Ss9 WNoA==
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=fywBnJJXBS3iwjTVMF5Abv7YLt1mZHpq1nJAlFjkZ5E=; b=uliKgThicTU3eqYBOeNlul0et6lNy93BUJb+dL5GPZcvqv1DVWDjxtyO+KE270fYQb EHp06y/1P2657T7Aawo1CpYvU3p27opj61ASn+/vTHw2bTfyR374d2GiuFrt9b9+6J6i lbK6ZrWOd2cTVnhqsIxQmSo9AE56V/RNgpusmRq3KBhNzyCRbr1OP6P8VaQ0dvMF/QHx HKTbe0F9Q/uv9kMxeS8B0C55rAdWg5kIVLmXH+9r5BzmJDBpMfHgAoIM8ID3z+61kL5d mQMEXv/Ka9IvkMbquNBXWf11f+VY105MLk9YvTzLg0cXoMhjY+OjhYGkt9m2tyE8ANGH IHpA==
X-Gm-Message-State: AOAM532j8YHW4RBHFhw4ROVl9IGpGrgBOgzOcCn/ERK390B4DVV79BML cMog1r5HHnnngyhBXbFe0B/QhU5/lYWVbftbA2U=
X-Google-Smtp-Source: ABdhPJxqcvamQC21Z9P4/btS8zSnDnGnk4qpsFQ2a1hEer80R26lG36N61zSHwFxBs9gD4Ocy3PDcr1/1HPmhmDtbD8=
X-Received: by 2002:ac2:518c:: with SMTP id u12mr23489991lfi.91.1593826915188;  Fri, 03 Jul 2020 18:41:55 -0700 (PDT)
MIME-Version: 1.0
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com>     <3c21e0fa-5636-54fe-675f-abc5b41ab09e@free.fr>
In-Reply-To: <3c21e0fa-5636-54fe-675f-abc5b41ab09e@free.fr>
From: Dick Hardt 
Date: Fri, 3 Jul 2020 18:41:19 -0700
Message-ID: 
To: Denis 
Cc: txauth@ietf.org, Nat Sakimura 
Content-Type: multipart/alternative; boundary="0000000000001d055d05a993bf99"
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 04 Jul 2020 01:42:00 -0000

--0000000000001d055d05a993bf99
Content-Type: text/plain; charset="UTF-8"

+ Nat as he is mentioned
- IESG

On Fri, Jul 3, 2020 at 2:16 AM Denis  wrote:

> Hello Dick,
>
> Catching up on this email ... comments inserted ...
>
> On Mon, Jun 29, 2020 at 12:06 AM Denis  wrote:
>
>> Hello Dick,
>>
>> Denis, thanks for sharing your thoughts, some clarifications on your
>> statements inserted:
>>
>> On Fri, Jun 26, 2020 at 9:42 AM Denis  wrote:
>> 
>>
>>> *New proposed charter*
>>>
>>> 
>>
>>>
>>> Resource servers inform their clients about which access token formats
>>> are acceptable and depending upon the king of operation
>>> that is requested, which kind of attributes are needed and from which
>>> ASs that my be obtained.
>>>
>>> While at times this may be appropriate, at other times disclosing the
>> attributes the RS requires is not needed by the client.
>> For example, an enterprise client accessing a resource does not need to
>> know which groups a user belongs to,
>> but the RS may require that to determine if the user running the client
>> has access.
>>
>> As soon as there is a desire to implement privacy by default, the client
>> should not provide more attributes than strictly necessary.
>> Even after three readings of your example, I failed to understand it.
>>
>>
>>> A major difference with OAuth 2.0 is that there is no bilateral trust
>>> relationship between an authorization server and a resource server:
>>> for a given category of attributes, a resource server may trust one or
>>> more authorization servers. Another major difference with OAuth 2.0.
>>> is that the content of an attributes token is meant to be accessible to
>>> the client.
>>>
>>> This is not how OAuth 2.0 works. See slides 7 and 8 from my original
>> IETF presentation on what became OAuth 2.0
>>
>> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation
>>
>> I looked at the two slides.
>>
>> Unfortunately slide 7 has just one arrow with the word "trust". This is
>> insufficient to understand what is meant unless being present
>> at the presentation. Does it mean that the PR (RS) trusts one AS or that
>> it may trust multiple ASs ?
>>
> Unfortunately slide 8 has just one arrow between the PR and the AS which
>> is red-crossed but no text at all. This is insufficient to understand
>> what is meant unless being present at the presentation. Does it mean that
>> the PR and the AS never communicate directly ?
>> Does it mean that they have no relationships at all, besides the one way
>> trust relationship mentioned in slide 7 ?
>>
>> So it hard to say whether these two slides are indeed meaning that there
>> is no bilateral relationship between an authorization server and a resource
>> server.
>>
> Apologies for not providing an explanation on the slides.
>
> Slide 7 shows that trust between the AS and PR (now RS) was
> unidirectional, from the RS to the AS.
> Slide 8 indicates that trust is not bidirectional.
>
> [Denis]  ... which means that slide 8 contradicts slide 7.  :-)
>

Slide 8 says it does not go both ways. Slide 7 says it goes one way. I
don't see the contradiction.

> I would have preferred that you meant: the RS and the AS never communicate
> directly, which is indeed a nice property to follow
> to ensure the user's privacy.
>
That is one model. Other models are appropriate in other circumstances.


>
> There is no limit on how many ASs an RS may trust.
>
> [Denis] This is fine.
>
>  On June 12, Nat Sakimura recently answered to an email with the
> following topic:
>
>> Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
>> Authorization Framework: JWT Secured Authorization Request))
>>
>> My arguments were:
>>
>>      The original model for OAuth was making the assumption that the AS
>> and the RS had a strong bilateral relationship.
>>
>>       *A key question is whether such strong relationship will be
>> maintained for ever *or
>>      whether it will be allowed to perform some evolutions of this
>> relationship.
>>
>>      In order to respect the privacy of the users, there is the need to
>> encompass other scenarios. One of these scenarios is that the AS and the RS
>>      do not need any longer to have such a strong relationship. In terms
>> of trust relationships, a RS simply needs to trust the access tokens issued
>> by an AS.
>>      The AS does have any more a "need to know" of all the RSs that are
>> accepting its access tokens. This would be a major simplification of the
>> current global architecture.
>>
>> Nat's position was:
>>
>> "My take is that the basic assumption of OAuth 2.0 Framework is that
>> there is a strong relationship between AS and RS.
>> I feel that it is quite unrealistic that an RS would trust the access
>> token issued by an AS that it has no strong relationship with".
>>
>> There are indeed different positions on this topic.
>>
>
> I don't think Nat and I have different opinions, but I will let Nat
> clarify.
> Just because there is a strong relationship between the AS and RS, does
> not mean it is bidirectional. I would understand
>
> "I feel that it is quite unrealistic that an RS would trust the access
> token issued by an AS that it has no strong relationship with"
>
> to indicate Nat is expecting the trust to be from the RS to the AS.
>
> [Denis]  Speaking of a "strong relationship" is ambiguous. The key point
> being whether the relationship is unilateral or bilateral.
> There is no need to use the wording "strong relationship" when the
> relationship is only unilateral: a RS simply trusts an AS for the access
> tokens it issues.
> In such a case, this does not mean that an AS is knowing all the RSs that
> are trusting it.
>
> On the contrary, a strong (bi-)relationship is when a RS and an AS both
> agree between them about the meaning of scope parameters.
> This is a typical case for OAuth 2.0.
>
You can ask Nat what he meant by "strong relationship"

The AS is stating what a scope means to it and the user. The RS can do
whatever it wants. I don't see that as requiring a bidirectional
relationship.




>
>
> The AS may not even know who the RS (or PR in the slides) is.
>>
>> 
>>
>>>
>>> I got rid of the word "delegation": the client does not delegate
>>> anything to an authorization server. If it would, this would mean that the
>>> authorization server
>>> would be able to act as the client and could know everything that the
>>> client will do, which comes into contradiction with the user's privacy.
>>>
>>
>> The above is not true.
>>
>> The Resource Owner is delegating access control to the AS in
>> authorization use cases.
>>
>> The OAuth 2.0 model does not mandate any more the presence of a Resource
>> Owner.
>>
>
> Why do you say that? The RO is who owns the RS. Your statement does not
> make sense.
>
> [Denis]  I mean that there is not necessarily a protocol defined so that
> the RO can interact with the requests from the clients.
>
Is the RO the User? In consumer use cases it usually is, and the RO is
using the client. I'm not sure what you scenario you are describing


>
>
>
>>
>> The client is may be delegating user authentication to the AS in identity
>> claim use cases.
>>
>> Delegating user authentication to the AS is different from delegating
>> access control to the AS.
>>
>
> Agreed. Your statement was there was no delegation. I'm explaining there
> are potentially two delegations.
>
>>
>> The AS can act as the client in many OAuth deployments, as the access
>> token is a bearer token.
>>
>> A bearer token is rather insecure.
>>
> Cookies are also bearer tokens. But we use them all the time in web apps
> for storing session state and prior authentication! :)
>
>
>
>> That does not mean the AS knows what the client is doing.
>>
>> There are currently two attempts in the OAuth WG to let know to the AS
>> what the client is doing:
>>
>>    - draft-ietf-oauth-jwsreq-22   (The OAuth 2.0 Authorization
>>    Framework: JWT Secured Authorization Request)
>>    - draft-ietf-oauth-rar-01         (OAuth 2.0 Rich Authorization
>>    Requests)
>>
>> Those are optional, and in some situations are a desired property.
>
> [Denis]  However, in these two drafts, the privacy considerations sections
> are silent on this point.
>
There are lots of missing details in both drafts! Security considerations,
error messages etc.

I think pretty much everyone is onboard supporting privacy, but not all use
cases have the same privacy considerations.

/Dick

--0000000000001d055d05a993bf99
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


+ Nat as he is mentioned
- IESG
On Fri, =
Jul 3, 2020 at 2:16 AM Denis <deni=
s.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hello Dick,

    


    

    

     =20
      

        

          

            

              
Catching up on this email ... comments inserted ...
              

              

                
On Mon, Jun 29, 2020
                  at 12:06 AM Denis <denis.ietf@free.fr>
                  wrote:

                

                

                  

                    
Hello Dick,

                    


                      

                    

                      

                        
Denis, thanks
                            for sharing your thoughts, some
                            clarifications on your statements inserted:

                        

                        
                        

                          
On Fri, Jun 26, 2020 at 9:42
                              AM Denis <denis.ietf@free.fr>
                              wrote:

                          
&l=
t;snip>

                          

                            

                              

                                

                                  
New
                                            proposed charter

                                

                              

                            

                          

                          
<snip>=C2=A0

                          

                            

                              

                                
 =


                                            Resource servers inform
                                            their clients about which
                                            access token formats are
                                            acceptable and depending
                                            upon the king of operation

                                            that is requested, which
                                            kind of attributes are
                                            needed and from which ASs
                                            that my be obtained.

                                              <=
/span>

                                      

                              

                            

                          

                          
While at times this
                              may be appropriate, at other times
                              disclosing the attributes the RS requires
                              is not needed by the client. 

                              For example, an enterprise client
                              accessing a resource does not need to know
                              which groups a user belongs to, 

                              but the RS may require that to determine
                              if the user running the client has access.
                            

                        

                      

                    

                    
As soon as there is a desire
                        to implement privacy by default, the client
                        should not provide more attributes than strictly
                        necessary. 

                        Even after three readings of your example, I
                        failed to understand it.

                      

                    

                      

                        

                          

                            

                              

                                
 

                                        A major difference with OAuth
                                        2.0 is that there is no
                                        bilateral trust relationship
                                        between an authorization server
                                        and a resource server: 

                                        for a given category of
                                        attributes, a resource server
                                        may trust one or more
                                        authorization servers. Another
                                        major difference with OAuth 2.0.

                                        is that the content of an
                                        attributes token is meant to be
                                        accessible to the client.

                              

                            

                          

                          
This is not how OAuth
                              2.0 works. See slides 7 and 8 from my
                              original IETF presentation on what became
                              OAuth 2.0

                          


                            

                          
                        

                      

                    

                    
I looked at the two slides. 
                      

                    
Unfortunately slide 7 has just
                        one arrow with the word "trust". This is
                        insufficient to understand what is meant unless
                        being present 

                        at the presentation. Does it mean that the PR
                        (RS) trusts one AS or that it may trust multiple
                        ASs ?

                  

                

                

                  

                    
 

                    
Unfortunately slide 8 has just
                        one arrow between the PR and the AS which is
                        red-crossed but no text at all. This is
                        insufficient to understand

                        what is meant unless being present at the
                        presentation. Does it mean that the PR and the
                        AS never communicate directly ?

                        Does it mean that they have no relationships at
                        all, besides the one way trust relationship
                        mentioned in slide 7 ?

                    
So it hard to say whether
                        these two slides are indeed meaning that there is no
                            bilateral relationship between an
                            authorization server and a resource server.

                  

                

                

                  
Apologies for not providing an explanation on the
                    slides.

                  


                  

                  
Slide 7 shows that trust between the AS and PR
                    (now RS) was unidirectional, from the RS to the AS.
                  
Slide 8 indicates=C2=A0that trust is not
                    bidirectional.

                

              

            

          

        

      

    

    
[Denis]=C2=A0 ... which means that slide 8
        contradicts slide 7.=C2=A0 :-) 

Slide 8 says it does not go both ways. Slide 7 says it go=
es one way. I don't see the contradiction.=C2=A0

      

    
I would have preferred that you meant: the RS
        and the AS never communicate directly, which is indeed a nice
        property to follow 

        to ensure the user's privacy.
=

That is one model. Other models are appropriate in other circumstances=
.
=C2=A0
<=
div>

        

      

    

      

        

          

            

              

                

                  
There is no limit on how many ASs an RS may
                    trust.

                

              

            

          

        

      

    

    
[Denis] This is fine.

    

      

        

          

            

              

                
=C2=A0On Jun=
e 12,
                    Nat Sakimura recently answered to an email
                    with the following topic:

                

                  
  
                    

                      
Re:
                          [OAUTH-WG] Comments on
                          draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
                          Authorization Framework: JWT Secured
                          Authorization Request))

                    

                     
                    
My argument=
s
                        were:

                     
                    
=C2=A0=C2=
=A0=C2=A0=C2=A0 The
                        original model for OAuth was making the
                        assumption that the AS and the RS had a strong
                        bilateral relationship.

                      

                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
b>A key question is
                          whether such strong relationship will be
                          maintained for ever or 

                      =C2=A0=C2=A0=C2=A0=C2=A0 whether=
 it will be allowed
                        to perform some evolutions of this relationship.

                      

                      =C2=A0=C2=A0=C2=A0=C2=A0 In orde=
r to respect the
                        privacy of the users, there is the need to
                        encompass other scenarios. One of these
                        scenarios is that the AS and the RS 

                      =C2=A0=C2=A0=C2=A0=C2=A0 do not =
need any longer to
                        have such a strong relationship. In terms of
                        trust relationships, a RS simply needs to trust
                        the access tokens issued by an AS. 

                      =C2=A0=C2=A0=C2=A0=C2=A0 The AS =
does have any more
                        a "need to know" of all the RSs that are
                        accepting its access tokens. This would be a
                        major simplification of the current global
                        architecture.

                     
                    
Nat's
                        position was: 

                      

                     
                    

                      
"My =
take
                          is that the basic assumption of OAuth 2.0
                          Framework is that there is a strong
                          relationship between AS and RS. 

                          I feel that it is quite unrealistic that an RS
                          would trust the access token issued by an AS
                          that it has no strong relationship with".

                    

                     
                    
There are
                        indeed different positions on this topic.=C2=A0 
                      

                  

                

                


                

                
I don't think Nat and I have different opinions,
                  but I will let Nat clarify.

                
Just because there is a strong relationship between
                  the AS and RS, does not mean it is bidirectional. I
                  would understand=C2=A0

                


                

                
"I feel that it is quite unrealistic that an RS
                  would trust the access token issued by an AS that it
                  has no strong relationship with"

                


                

                
to indicate Nat is expecting the trust to be from
                  the RS to the AS.

              

            

          

        

      

    

    
[Denis]=C2=A0 Speaking of a "strong relati=
onship"
        is ambiguous. The key point being whether the relationship is
        unilateral or bilateral.

        There is no need to use the wording "strong relationship"=
 when
        the relationship is only unilateral: a RS simply trusts an AS
        for the access tokens it issues. 

        In such a case, this does not mean that an AS is knowing all the
        RSs that are trusting it.

    
On the contrary, a strong (bi-)relationship is
        when a RS and an AS both agree between them about the meaning of scope
        parameters.

        This is a typical case for OAuth 2.0.
=

You can ask Nat what he meant by "strong relationship"
=


The AS is stating what a scope means to it and the user=
. The RS can do whatever it wants. I don't see that as requiring a bidi=
rectional relationship.


=C2=A0


    

    

      

        

          

            

              


                

                  

                    

                      

                        

                          
The AS may not even
                              know who the RS (or PR in the slides) is.

                          


                            

                          
<snip>=C2=A0

                          

                            

                              

                                
 

                                        I got rid of the word
                                        "delegation": the client =
does
                                        not delegate anything to an
                                        authorization server. If it
                                        would, this would mean that the
                                        authorization server 

                                        would be able to act as the
                                        client and could know everything
                                        that the client will do, which
                                        comes into contradiction with
                                        the user's privacy.

                                      

                              

                            

                          

                          


                            

                          
The=C2=A0above is not t=
rue.

                          
=C2=A0

                          
The Resource Owner is
                              delegating access control to the AS in
                              authorization use cases.

                        

                      

                    

                    
The OAuth 2.0 model does not
                        mandate any more the presence of a Resource
                        Owner.

                  

                

                


                

                
Why do you say that? The RO is who owns the RS.
                  Your statement does not make sense.

              

            

          

        

      

    

    
[Denis]=C2=A0 I mean that there is not necessar=
ily
        a protocol defined so that the RO can interact with the requests
        from the clients.
Is the RO the U=
ser? In consumer use cases it usually is, and the RO is using the client. I=
'm not sure what you scenario you are describing
=C2=A0
=



    

    

      

        

          

            

              

                
=C2=A0

                

                  

                    

                      

                        

                          


                            

                          
The client is may be
                              delegating user authentication to the AS
                              in identity claim use cases.

                        

                      

                    

                    
Delegating user authentication
                        to the AS is different from delegating access
                        control to the AS.

                  

                

                


                

                
Agreed. Your statement was there was no delegation.
                  I'm explaining there are potentially=C2=A0two delegat=
ions.=C2=A0

                

                  

                    

                      

                        

                          


                            

                          
The AS can act as the
                              client in many OAuth deployments, as the
                              access token is a bearer token. 

                        

                      

                    

                    
A bearer token is rather
                        insecure.

                  

                

                
Cookies are also bearer tokens. But we use them all
                  the time in web=C2=A0apps for=C2=A0storing session state=
=C2=A0and
                  prior authentication! :)

                


                

                
=C2=A0

                

                  

                    

                      

                        

                          
That does not mean the
                              AS knows what the client is doing. 

                            

                        

                      

                    

                    
There are currently two
                        attempts in the OAuth WG to let know to the AS
                        what the client is doing:

                    
    
                      
  • draft-ietf-oauth-jwsreq-22=
=C2=A0=C2=A0
                          (The OAuth 2.0 Authorization Framework: JWT
                          Secured Authorization Request)
    • 
                      
  • draft-ietf-oauth-rar-01 =C2=
=A0 =C2=A0
                          =C2=A0 =C2=A0 (OAuth 2.0 Rich Authorization Reque=
sts)
    • 
                    

                  

                

                
Those are optional, and in some situations are a
                  desired property.

              

            

          

        

      

    

    
[Denis]=C2=A0 However, in these two drafts, the
        privacy considerations sections are silent on this point.
There are lots of missing details in both drafts! =
Security considerations, error messages etc.

I thi=
nk pretty much everyone is onboard supporting privacy, but not all use case=
s have the same privacy considerations.

/Dick


--0000000000001d055d05a993bf99--


From nobody Fri Jul  3 18:51: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 0DD7C3A09AB for ; Fri,  3 Jul 2020 18:51:16 -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 Aq1ljKgocUJL for ; Fri,  3 Jul 2020 18:51:14 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450: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 406C53A0990 for ; Fri,  3 Jul 2020 18:51:14 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id s16so14038937lfp.12 for ; Fri, 03 Jul 2020 18:51: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=8ktxl46j13XLtYaLXmGULjMxR0cJLz/F6IXOc1+iP0E=; b=pVjj2plqZqvtu1PyGrvEIyasUUgSDf9P25UNsKnUwLwLPdMfM/HbM8yd7QYbdu+6PC Ov4/L13rMVET0OD9xDZBiYzpBvsPWYibsrgm6Ep7GIEDTc2G2ijM6BcpGxhcTa27x270 oNtxYEVjVWYMCNHGu7gZ3C+H2uZ7jadHs7zYzmwkI6z0Nh0gvM7XQpNhN9HP7bn6Y4pq OBvggz/tBijksfHnT6rWqYgVe/Gw1nCbz7pUNWDk0RQ4x7jlZ+dZUovBM5RE8GeoNunu yM49Pg4VlrVVASfYHs3CeSC+tI4JNCjIJdaG/Uz+ZzDB+wd5vP7uhWxhDYDyrBwIPa9T SIUw==
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=8ktxl46j13XLtYaLXmGULjMxR0cJLz/F6IXOc1+iP0E=; b=Z3QqaFyKiYTBH09ZSzkkXr3UAMlLwZvfPZtXBCoxlou/HD7WlmN2amS5AESAzGb+p3 0eSFHkuV7tvSc0m/UUKBfg+NSr8DcP++BEo76P9L4CNi1JwYvwWs1fm4WmmbKqSc+MtX m5GoQHt0JaUmhefB/uPyW8tUYJ7cVogzgR9iByULbsOVIALlwc6asEQHjyMy/c9OfLCP xIUXITzaM2iohm/7w2dPRQvrR9LmggYV0mt9t9YYmWrdlIBlwIy/+btkgxvTyVdJtMkv prOkhQSBPHaEnsOuYbeTCJDzEZFBYrtHyQ8NvB8ShoEdmnLeB84l4oGpjjQ0kaYRVsYL 1ocQ==
X-Gm-Message-State: AOAM532UwrpHLNmrUjJECP+uKM4/6sWsABPfpxe+LkzWwcEWyrSmKJ23 C3Im0my1ELoefnB2ZSvoNpxzHkR7ihmu8A6eBMc=
X-Google-Smtp-Source: ABdhPJxv6zdZ9biFT8zL6jgqVE0zB6XKG9ZQNPvoP2JwVymBnDRHSHUwQYnBpFVvQNr9Uq3D+q9aKvZ4zSl1swupCF4=
X-Received: by 2002:a19:c8a:: with SMTP id 132mr23568208lfm.23.1593827472279;  Fri, 03 Jul 2020 18:51:12 -0700 (PDT)
MIME-Version: 1.0
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu>  <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr>    <88ca4d3c-4605-5220-279e-d1665cbc076d@free.fr>
In-Reply-To: <88ca4d3c-4605-5220-279e-d1665cbc076d@free.fr>
From: Dick Hardt 
Date: Fri, 3 Jul 2020 18:50:36 -0700
Message-ID: 
To: Denis 
Cc: Tom Jones , Justin Richer ,  txauth@ietf.org, Tobias Looker 
Content-Type: multipart/alternative; boundary="000000000000518ec505a993e008"
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 04 Jul 2020 01:51:16 -0000

--000000000000518ec505a993e008
Content-Type: text/plain; charset="UTF-8"

While the scopes used in some implementations imply the RS, there is
nothing in OAuth 2.0 that requires the scope to imply the RS.

When you use your driver's license to prove your age at a liquor store, it
is unidirectional trust. The issuer likely has no relationship with the
audience.

I think you are contemplating claims rather than tokens if the driver's
license example is what you are contemplating.




On Fri, Jul 3, 2020 at 2:19 AM Denis  wrote:

> Hello  Dick,
>
> I agree it is not always true, sorry I did not make that clear.
>
> My statement is that OAuth 2.0 does not require the AS to have
> knowledge of the RS.
>
> As soon as the scope parameter is being used, then the AS has a prior
> knowledge of the RS.
> When the scope parameter is not used, then the client has no ability to
> modulate the attributes.
>
> Even when the AS has a no prior knowledge of the RS, when the access token
> is targeted to a given RS,
> then the AS has the knowledge of which RS is likely to be accessed by the
> client.
>
> While it may be interesting to list some of the limitations of OAuth 2.0,
> it is much more important
> to focus on the characteristics we would like to support with GNAP ...
> and to mention them in the charter.
>
> Denis
>
>
> On Thu, Jul 2, 2020 at 10:56 AM Tom Jones 
> wrote:
>
>> Dick, the statement about the AS and RS is not always true. In
>> federations we are always concerned that information is not leaked outside
>> the approved parties and the AS messages will likely be encrypted for the
>> sole use of the RS.
>> Peace ..tom
>>
>>
>> On Thu, Jul 2, 2020 at 10:44 AM Dick Hardt  wrote:
>>
>>> Apologies for the delayed response:
>>>
>>> On Fri, Jun 26, 2020 at 9:04 AM Denis  wrote:
>>>
>>>> The principle where a RS would only have relationships with one AS
>>>> would make the model non scalable.
>>>> It would prevent to get attributes from two different ASs,  for
>>>> example:
>>>> identity attributes from a bank and a master degree diploma from a
>>>> university.
>>>>
>>>
>>> Where do you see that the RS can have a relationship with only one AS?
>>>
>>>
>>>>
>>>> For privacy reasons, every AS should know as little as possible about
>>>> the interactions between a client and multiple RSs.
>>>> It is even possible that this goes as little as knowing *nothing at
>>>> all*.
>>>>
>>>
>>> OAuth 2.0 works this way now.
>>>
>>>
>>>>
>>>> The OAuth 2.0 assumption where the AS is in a position to know all the
>>>> interactions of a given user has with all the RSs
>>>> that an AS server has a relationship with should not be re-iterated.
>>>>
>>>
>>> I am still confused why you think the AS knows anything abou the
>>> interactions a given use has with all the RSs. The AS knows which clients
>>> the user is using, but does not need to have any knowledge of which RSs a
>>> client is accessing.
>>>
>>>
>>> The AS does not need to know anything about the RS. The RS clearly needs
>>> to trust the AS, as it is trusting the access granted by the AS to the
>>> client, but it is unidirectional trust between the RS and the AS.
>>>
>>> /Dick
>>>
>>
>

--000000000000518ec505a993e008
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


While the scopes used in some implementations imply the RS=
, there is nothing in OAuth 2.0 that requires the scope to imply the RS.
When you use your driver's license to prove your age a=
t a liquor store, it is unidirectional trust. The issuer likely has no rela=
tionship with the audience.

I think you are contem=
plating claims rather than tokens if the driver's license example is wh=
at you are contemplating.=C2=A0



On Fri, Jul 3, 2020 at 2:19 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hello=C2=A0 Dick,

    

     =20
      
I agree it is not always true, sorry I did not make
        that clear.
        


        

        
My statement is that OAuth 2.0 does not require the AS to
          have knowledge=C2=A0of the RS.

      

    

    
As soon as the scope parameter is being used, then the AS has a
      prior knowledge of the RS.

      When the scope parameter is not used, then the client has no
      ability to modulate the attributes.

    
Even when the AS has a no prior knowledge of the RS, when the
      access token is targeted to a given RS, 

      then the AS has the knowledge of which RS is likely to be accessed
      by the client.

    
While it may be interesting to list some of the limitations of
      OAuth 2.0, it is much more important 

      to focus on the characteristics we would like to support with GNAP
      ...=C2=A0 and to mention them in the charter.

    
Denis

    


      

        
On Thu, Jul 2, 2020 at 10:56
          AM Tom Jones <thomasclinganjones@gmail.com>
          wrote:

        

        

          
Dick, the statement about the AS and RS is not
            always true. In federations we are always concerned that
            information is not leaked outside the approved parties and
            the AS messages will likely be encrypted for the sole use of
            the RS.

            

              

                

                  
Peace ..tom

                

              

            

            

          

          

          

            
On Thu, Jul 2, 2020 at
              10:44 AM Dick Hardt <dick.hardt@gmail.com>
              wrote:

            

            

              

                
Apologies for the delayed response:

                

                

                  
On Fri, Jun 26, 202=
0
                    at 9:04 AM Denis <denis.ietf@free.fr>
                    wrote:

                  

                  

                    

                      
The principle where a RS would only have
                        relationships with one AS would make the model
                        non scalable.

                      

                      
 It would prevent to get attributes from two
                        different ASs,=C2=A0 for example:=C2=A0 

                        identity attributes from a bank and a master
                        degree diploma from a university.

                      

                    

                  

                  


                  

                  
Where do you see that the RS can have a
                    relationship with only one AS?

                  
=C2=A0

                  

                  

                    

                      
 

                      


                      

                      For privacy reasons, every AS should know as
                      little as possible about the interactions between
                      a client and multiple RSs.

                      
It is even possible that this goes as little
                        as knowing nothing at all.

                    

                  

                  


                  

                  
OAuth 2.0 works this way now.=C2=A0

                  
=C2=A0

                  

                    

                      


                      

                      

                        
The OAuth 2.0 assumption where the AS is in
                          a position to know all the interactions of a
                          given user has with all the RSs 

                          that an AS server has a relationship with
                          should not be re-iterated.

                      

                    

                  

                  


                  

                  
I am still confused why you think the AS knows
                    anything abou the interactions a given use has with
                    all the RSs. The AS knows which clients the user is
                    using, but does not need to have any knowledge of
                    which RSs a client is accessing.

                  
=C2=A0

                  
=C2=A0

                  
The AS does not need to know anything about the
                    RS. The RS clearly needs to trust the AS, as it is
                    trusting the access granted by the AS to the client,
                    but it is unidirectional trust between the RS and
                    the AS.

                  


                  

                  
/Dick

                

              

            

          

        

      

    

    


    

  





--000000000000518ec505a993e008--


From nobody Sun Jul  5 05:47: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 444083A005F for ; Sun,  5 Jul 2020 05:47: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 w7Xw5uxpXQAZ for ; Sun,  5 Jul 2020 05:47:44 -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 A2A7C3A005B for ; Sun,  5 Jul 2020 05:47:44 -0700 (PDT)
Received: by mail-il1-x12f.google.com with SMTP id a11so22479026ilk.0 for ; Sun, 05 Jul 2020 05:47: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=HkrKTIS6H8SVzXVz0YOE1X8VnLV2HPqBg+l/HTgZT7s=; b=oVH0O7PFeaQZ2Sz5bWyVeWzvv+v6fnEVMbUB9y0+iPY9U5HeaUYacCyqK9nSeUDvpo EhyoTSo45U4OtySZNqY29RzljEPUd9r4SHiv5jmoB/9qv9Gz8CZ/7105pJUaOGER/Oq4 BNXptV3uGjf8R1Yf5esvdBN7+Uot1B/8dyl8ckFwYf5CFcp+HsflsiUkCFT1NTQs3GoV TBqTWha//WbPP4E7HGUafHpUOqDvAsCSMqItgDhkMpS+s9ObjZ6A79ZP0VrwakouFvdx EA0Ue6xfZcdqJ43BGVqWS/AQNCAO70uQhh0c4imYuBOCc/JaWgZpQYYf1HtWwN89vSah UXZQ==
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=HkrKTIS6H8SVzXVz0YOE1X8VnLV2HPqBg+l/HTgZT7s=; b=oDkayVQVMDv8qXoxCNuyPsV8lRwVOpcf3qZfG610s+soZYa1T+nUhhv/6tkzdtCTVm J7QQFZtwqGeZjyQUAkGHpaVE5fGufFsoD1X0vb8rMyONIOOCiBz+sNcEcVAezmfioaX2 aE3i1oTbpVCcpEDNCGoIdTi5im+T9BImwjOoUcTor/Mc/LE0SxYiAvDFmQUkZkp4wA5m PnwL+58NEvzsksKAvUheyrPLmiQvv8EcWNei85vMgq7g3i3nnkPiUSsRK73m9fghpJbG y9eKhMyjIKPzbu0pFSPyFHo+KSQcGiL1FW62e+ePU1zo05w8RR4WnMRN9z3gQnfQgGSn j5zQ==
X-Gm-Message-State: AOAM533nJuVed8soKOi3IDrPIOG3Q7BnDFZd0qwYVtB8ugAOfdyA9GD9 jpBO31Mqws/dFVvX8TNSocO/Ajigb6dxMzl71C4=
X-Google-Smtp-Source: ABdhPJwhECdRvM6OVV00zgl1CYnUyzO3pwsoWa+s3/7PRD/C7Q7whoofo9ya1ygib/uru805ZW97WXdKTXPzlcLzUns=
X-Received: by 2002:a05:6e02:1313:: with SMTP id g19mr24230261ilr.123.1593953263969;  Sun, 05 Jul 2020 05:47:43 -0700 (PDT)
MIME-Version: 1.0
References:       
In-Reply-To: 
From: Fabien Imbault 
Date: Sun, 5 Jul 2020 14:47:29 +0200
Message-ID: 
To: Dick Hardt 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000166a6c05a9b12a6f"
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 05 Jul 2020 12:47:48 -0000

--000000000000166a6c05a9b12a6f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

You're spot on with you last comments, we should stay very clear on claims
vs tokens (and indeed they are defined in other working groups). I agree
with that.

What I'm suggesting is that json-ld may be used as a support for providing
context and extendibility capabilities, as it provides a conventional
manner of defining metadata to deliver on the polymorphic feature of the
core protocol.
Request/response (and continuation) endpoints may use this metadata to
adapt their behavior to the capabilities or intent of the other party
(client and AS). The most obvious example is for resources description
("dolphin-metadata" in the XYZ example), to provide semantic context around
common access patterns.

Cheers,

Fabien

Le sam. 4 juil. 2020 =C3=A0 03:33, Dick Hardt  a =C3=
=A9crit :

>
>
> On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault 
> wrote:
>
>> Thanks Dick.
>>
>> Likewise, comments inserted (marked with "FI").
>>
>> On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt  wrote:
>>
>>> Hi Fabien, sorry for the late reply
>>>
>>> Comments and questions inserted ...
>>>
>>> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault 
>>> wrote:
>>> 
>>>
>>>>
>>>> Beyond what I said on the redirect, we could probably benefit from a
>>>> more formal definition of the flows (a bit different between the 2
>>>> proposals), as proposed recently by Francis Pouatcha for instance
>>>> (interact/decoupled/embedded flows, TBD).
>>>>
>>>
>>> Which proposal was that?
>>>
>>
>> FI : I'll try to find it back.
>>
>>>
>>>
>>>>
>>>> What I'm missing in both proposals (personal opinion):
>>>>
>>>> - I know that JSON is the usual format, but it would be really useful
>>>> to complement the schemas with some JSON-LD descriptions as well. It w=
ould
>>>> ease extensions and interoperability (by avoiding conflicting schemas)=
, and
>>>> could even provide a more generic way of representing verifiable
>>>> presentations (challenge/nonce associated to a domain for instance). W=
hile
>>>> most of this work on linked data has been done at W3C, it would add va=
lue
>>>> to the current proposal so I think we should consider it.
>>>>
>>>
>>> I'm not understanding how JSON-LD would fit in. Would you provide an
>>> example?
>>>
>>
>> FI : when it comes to extendibility, JSON-LD and JSON schemas could work
>> together to provide a more explicit information on the type of informati=
on
>> we're handling. You'll find a comparison at
>> https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs wi=
th
>> standard JWT. In practice, this comes handy as a basis for verified
>> credentials, would clarify the OIDC semantics and disambiguate the meani=
ng
>> of specific tokens (see for instance the discussion at
>> https://www.rfc-editor.org/rfc/rfc8417.html#section-4 on "Preventing
>> Confusion between SETs and Other JWTs").
>> https://w3c.github.io/vc-imp-guide/#extending-jwts provides interesting
>> examples.
>>
>
> It appears that you are proposing the JSON-LD be used in claims? Am I
> correct? Or is there somewhere it would be used in the Grant Request JSON=
?
>
> My understanding of the charter is the GNAP is a transport for claims, an=
d
> that those would be defined somewhere else. OpenID Connect and Verified
> Credentials are good examples. The query for a claims similarly would be
> defined somewhere else.
>
>
>>
>>
>>>
>>>>
>>>> - from an extensibility point of view, I'm not sure it's very useful t=
o
>>>> list all possibilities. For instance, as of now, it wouldn't be possib=
le to
>>>> use the protocol for constrained devices, so there's no real value in
>>>> saying that it could be extended with CoAP (then we need a separate
>>>> document, that references the current GNAP rfc). What's more useful to=
 know
>>>> if the context of the current document, when you're implementing it, i=
s
>>>> what behaviour can really be extended in a fairly straightforward
>>>> way, without changing anything in the core spec. For instance, what ca=
n I
>>>> do with other types of tokens than JWT? Neither proposal is very clear=
 as
>>>> to how we would implement extensions in practice.
>>>>
>>>
>>> In XAuth I refer to CoAP not as an extension, but as an one example of
>>> other client authentication mechanisms. While it only applies to CoAP, =
I
>>> think it is useful to call out how we intend GNAP to be extended.
>>>
>>
>> FI : isn't the charter already covering this?
>>
>
> Yes, but most people that are not in the WG don't read the charter. :)
>
>
>>
>>> Just like OAuth 2.0, the access token is opaque to the client, and it i=
s
>>> not specified, so I'm confused what you mean by "other types of tokens =
than
>>> JWT"?
>>>
>>> FI : I mean, for instance, linked data proofs, macaroons, and so on.
>>
>
> I see. When I read 'token', I think of access tokens. You are referring t=
o
> what I would call a claims, which per above are defined somewhere else.
>
>
>>
>>>
>>>>
>>>> - from an implementation perspective, it would make sense to decompose
>>>> the flow between the Grant Server (GS) and the login/consent part (as =
done
>>>> for instance by ory.sh). This way you would separate the concerns: on =
one
>>>> side you have the HTTP flows (managed by the GS, which can be very
>>>> optimized from a backend perspective), but you can delegate/customize =
the
>>>> interaction UI to some agreed dedicated endpoint (typically a JS site)=
.
>>>> Maybe that's just a detail which doesn't have its place in the spec, b=
ut
>>>> since it would change the flow, it might be important to consider, at =
least
>>>> as a possibility/extension.
>>>>
>>>
>>> Is the interaction UI not part of the GS though? I agree that an
>>> implementation can decompose those, but that sounds like an implementat=
ion
>>> choice of the GS, and not something that requires standardization. I ag=
ree
>>> that we want to anticipate the decomposition.* Is there a change in the
>>> flow that would make that easier?
>>>
>>
>> FI : I agree with you on the principle. We're currently testing that to
>> make sure the standard is supporting these kind of implementation choice=
.
>> In XYZ, it means changing the URI for the interaction, having an additio=
nal
>> nonce for the interact server (maybe we can remove that constraint later
>> on, because it changes details in the interaction), and the rest stays t=
he
>> same.
>>
>
> I'd be interested in the details on how you are implementing it!
>
>
>>
>>> *One of the reasons I favor using URIs and methods for the different
>>> functionality of the GS API is that it is easy for a router to route a
>>> request to different components of the GS.
>>>
>>
>> FI : yes, and that's something interesting that we'll need to discuss
>> further.
>>
>
> :)
>
>
>>
>>> /Dick
>>>
>>>>

--000000000000166a6c05a9b12a6f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,=C2=A0

Yo=
u're spot on with you last comments, we should stay very clear on claim=
s vs tokens (and indeed they are defined in other working groups). I agree =
with that.=C2=A0

What I&=
#39;m suggesting is that json-ld may be used as a support for providing con=
text and extendibility capabilities, as it provides a conventional manner o=
f defining metadata to deliver on the polymorphic feature of the core proto=
col.=C2=A0
Request/response (and continuation) endpo=
ints may use this metadata to adapt their behavior to the capabilities or i=
ntent of the other party (client and AS). The most obvious example is for r=
esources description ("dolphin-metadata" in the XYZ example), to =
provide semantic context around common access patterns.=C2=A0

Cheers,

Fabien

Le sam. 4 juil. 2020 =C3=A0 03:33, Dick H=
ardt <dick.hard=
t@gmail.com> a =C3=A9crit=C2=A0:


On Fri, Jul 3, 2020 at 1:19 AM F=
abien Imbault <fabien.imbault@gmail.com> wrote:
Th=
anks Dick.=C2=A0

Likewise, comments in=
serted (marked with "FI").

On Thu, Jul 2, 2020 at 7:34 PM Dick Har=
dt <=
dick.hardt@gmail.com> wrote:
Hi Fabien, sorry for =
the late reply

Comments and questions=C2=A0inserted ...=
=C2=A0

On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <fabien.imbault@=
gmail.com> wrote:
<snip>
<=
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">

=

Beyond what I said on the redirect, we could probably benefit fr=
om a more formal definition of the flows (a bit different between the 2 pro=
posals), as proposed recently by Francis Pouatcha for instance (interact/de=
coupled/embedded flows, TBD).

Which proposal was that?

FI : I'll try to find it back.=C2=A0
=
=C2=A0

What I'm missing in both proposals (=
personal opinion):=C2=A0

- I know that JSON is the=
 usual format, but it would be really useful to complement the schemas with=
 some JSON-LD descriptions as well. It would ease extensions and interopera=
bility (by avoiding conflicting schemas), and could even provide a more gen=
eric way of representing verifiable presentations (challenge/nonce associat=
ed to a domain for instance). While most of this work on linked data has be=
en done at W3C, it would add value to the current proposal so=C2=A0I think =
we should consider it.=C2=A0

I&=
#39;m not understanding how JSON-LD would fit in. Would you provide an exam=
ple?

FI : when it comes t=
o extendibility, JSON-LD and JSON schemas could work together to provide a =
more explicit information on the type of information we're handling. Yo=
u'll find a comparison at=C2=A0https=
://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs=C2=A0w=
ith standard JWT. In practice, this comes handy as a basis for verified cre=
dentials, would clarify the OIDC semantics and disambiguate the meaning of =
specific tokens (see for instance the discussion at=C2=A0https://www.rfc-editor.org/rfc/rfc8417.html#section-4=C2=A0on "Pr=
eventing Confusion between SETs and Other JWTs").=C2=A0=C2=A0
https://w3c.github.io/vc-imp-guide/#extending-jwts=C2=
=A0provides interesting examples.=C2=A0
=

It appears that you are proposing the JSON-LD be used in cla=
ims? Am I correct? Or is there somewhere it would be used in the Grant Requ=
est JSON?

My understanding of the charter is the G=
NAP is a transport for claims, and that those would be defined somewhere el=
se. OpenID Connect and Verified Credentials are good examples. The query fo=
r a claims similarly would be defined somewhere else.
=C2=A0

=C2=A0

- from an extensibility point of view, I'm not sure it's v=
ery useful to list all possibilities. For instance, as of now, it wouldn=
9;t be possible to use the protocol for constrained devices, so there's=
 no real value in saying that it could be extended with CoAP (then we need =
a separate document, that references the current GNAP rfc). What's more=
 useful to know if the context of the current document, when you're imp=
lementing it, is what behaviour can really be extended in a fairly straight=
forward way,=C2=A0without changing anything in the core spec. For instance,=
 what can I do with other types of tokens than JWT? Neither proposal is ver=
y clear as to how we would implement extensions in practice.

In XAuth I refer to CoAP not as an extension,=
 but as an one example of other client authentication mechanisms. While it =
only applies to CoAP, I think it is useful to call out how we intend GNAP t=
o be extended.=C2=A0

FI :=
 isn't the charter already covering this?=C2=A0

Yes, but most people that are not in the WG don&=
#39;t read the charter. :)
=C2=A0

Just like OAuth 2.0, the access token is op=
aque to the client, and it is not specified, so I'm confused what you m=
ean by "other types of tokens than JWT"?

FI : I mean, for instance, linked data proofs, ma=
caroons, and so on.=C2=A0

I see. When I read 'token', I think of access tokens. You are refe=
rring to what I would call a claims, which per above are defined somewhere =
else.
=C2=A0
=C2=A0

- from an implementation perspective, it wou=
ld make sense to decompose the flow between the Grant Server (GS) and the l=
ogin/consent part (as done for instance by ory.sh). This way you would sepa=
rate the concerns: on one side you have the HTTP flows (managed by the GS, =
which can be very optimized from a backend perspective), but you can delega=
te/customize the interaction UI to some agreed dedicated endpoint (typicall=
y a JS site). Maybe that's just a detail which doesn't have its pla=
ce in the spec, but since it would change the flow, it might be important t=
o consider,=C2=A0at least as a possibility/extension.

Is the interaction UI not part of the GS though? I a=
gree that an implementation can decompose those, but that sounds like an im=
plementation choice of the GS, and not something that requires standardizat=
ion. I agree that we want to anticipate the decomposition.* Is there a chan=
ge in the flow that would make that easier?
<=
div>
FI : I agree with you on the principle. We're curren=
tly testing that to make sure the standard is supporting these kind of impl=
ementation choice. In XYZ, it means changing the URI for the interaction, h=
aving an additional nonce for the interact server (maybe we can remove that=
 constraint later on, because it changes details in the interaction), and t=
he rest stays the same.=C2=A0

=

I'd be interested in the details on how you are implementing it!
=C2=A0

<=
div>*One of the reasons I favor using URIs and methods for the different fu=
nctionality=C2=A0of the GS API is that it is easy for a router to route a r=
equest to different components of the GS.

FI : yes, and that's something interesting that we'=
;ll need to discuss further.=C2=A0

<=
/div>
:)
=C2=A0
<=
div>=C2=A0
/Dick














--000000000000166a6c05a9b12a6f--


From nobody Sun Jul  5 12:15: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 BE6D43A0A87 for ; Sun,  5 Jul 2020 12:15:10 -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 WLaBT_ClCgel for ; Sun,  5 Jul 2020 12:15:08 -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 18A1D3A0A86 for ; Sun,  5 Jul 2020 12:15:07 -0700 (PDT)
Received: from [192.168.1.14] (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 065JF4dg011828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 5 Jul 2020 15:15:05 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_82CE7FAA-882C-4A40-925B-43278BE6A28A"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sun, 5 Jul 2020 15:15:04 -0400
In-Reply-To: 
Cc: Dick Hardt , txauth@ietf.org
To: Fabien Imbault 
References:        
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 05 Jul 2020 19:15:11 -0000

--Apple-Mail=_82CE7FAA-882C-4A40-925B-43278BE6A28A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Getting the extensibility right is going to be one of the most important =
things we need to try to balance in GNAP. I=E2=80=99ve worked with =
JSONLD on a few different things, and overall I=E2=80=99m not a fan of =
it for managing things like extensibility. It=E2=80=99s one of those =
technologies that works great if you=E2=80=99re already using it for =
everything, but it=E2=80=99s a huge learning curve if you=E2=80=99re not =
in the space at all. Instead I would rather we see extensibility managed =
at the JSON level, instead of putting this kind of up-front burden of =
understanding on developers.

In XYZ, for example, you can add new items to the top of the request and =
response (along side =E2=80=9Ckey=E2=80=9D, =E2=80=9Cresources=E2=80=9D, =
=E2=80=9Cuser=E2=80=9D, =E2=80=9Caccess_token=E2=80=9D, and the like), =
and these all get their own semantics. Additionally, you can extend the =
inner parts of the protocol, like the =E2=80=9Cinteraction=E2=80=9D =
section of the request can have new interaction capabilities, and the =
key section can have new proofing mechanisms. And perhaps most =
importantly, the =E2=80=9Cresources=E2=80=9D sections can have items =
that are specific to a given API, since all APIs are potentially =
different and GNAP shouldn=E2=80=99t make assumptions about how =
they=E2=80=99re structured. The extensibility of all of these can be =
managed without using a formal schema language like JSONLD. We can =
define core elements in the GNAP spec, and allow extension on a =
registry, for example. Or we could use a name spacing mechanism for some =
things like the resources where we expect a lot of variability.

But not everything outside of our core fits this extension category. I =
don=E2=80=99t see CoAP as an extension, for example, because it=E2=80=99s =
a replacement for the whole HTTP/JSON layer, not just the =
authentication/key-proofing portions. I don=E2=80=99t think it makes =
sense to have GNAP be so abstracted away from HTTP/JSON that we end up =
with a model/binding style specification, and that sentiment is built =
into the proposed charter. An aside, you could do a COSE-style signature =
as a proof mechanism, or a CWK key format, and those would both be =
extensions to GNAP, since they could be communicated over the same base =
protocol.

And finally, there are going to be parts of the protocol that are =
controlled by other working groups and efforts. For instance, someone =
might want to make it possible to return identity information or =
resource information directly in the token response, but that=E2=80=99s =
outside of what GNAP is here for. We have agreement to return =
identifiers for users (so, things like an issuer/subject pair, an email =
address, a phone number, etc), but not profile information or other =
identity components.=20

We=E2=80=99ve got a difficult and important thing to balance here: we =
need to have enough detail in the protocol that it=E2=80=99s usable =
without having to defer to other groups or documentation (ie, you =
shouldn=E2=80=99t need a profile of GNAP to be able to run GNAP), but we =
need to be flexible enough in our structures to accommodate new ways of =
working and doing things, especially when we=E2=80=99re looking at =
things that OAuth 2 is too rigid to handle well, like flexible =
interaction methods.

 =E2=80=94 Justin

> On Jul 5, 2020, at 8:47 AM, Fabien Imbault  =
wrote:
>=20
> Hi,=20
>=20
> You're spot on with you last comments, we should stay very clear on =
claims vs tokens (and indeed they are defined in other working groups). =
I agree with that.=20
>=20
> What I'm suggesting is that json-ld may be used as a support for =
providing context and extendibility capabilities, as it provides a =
conventional manner of defining metadata to deliver on the polymorphic =
feature of the core protocol.=20
> Request/response (and continuation) endpoints may use this metadata to =
adapt their behavior to the capabilities or intent of the other party =
(client and AS). The most obvious example is for resources description =
("dolphin-metadata" in the XYZ example), to provide semantic context =
around common access patterns.=20
>=20
> Cheers,
>=20
> Fabien
>=20
> Le sam. 4 juil. 2020 =C3=A0 03:33, Dick Hardt > a =C3=A9crit :
>=20
>=20
> On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault =
> wrote:
> Thanks Dick.=20
>=20
> Likewise, comments inserted (marked with "FI").
>=20
> On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt > wrote:
> Hi Fabien, sorry for the late reply
>=20
> Comments and questions inserted ...=20
>=20
> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault =
> wrote:
> 
>=20
> Beyond what I said on the redirect, we could probably benefit from a =
more formal definition of the flows (a bit different between the 2 =
proposals), as proposed recently by Francis Pouatcha for instance =
(interact/decoupled/embedded flows, TBD).
>=20
> Which proposal was that?
>=20
> FI : I'll try to find it back.=20
> =20
>=20
> What I'm missing in both proposals (personal opinion):=20
>=20
> - I know that JSON is the usual format, but it would be really useful =
to complement the schemas with some JSON-LD descriptions as well. It =
would ease extensions and interoperability (by avoiding conflicting =
schemas), and could even provide a more generic way of representing =
verifiable presentations (challenge/nonce associated to a domain for =
instance). While most of this work on linked data has been done at W3C, =
it would add value to the current proposal so I think we should consider =
it.=20
>=20
> I'm not understanding how JSON-LD would fit in. Would you provide an =
example?
>=20
> FI : when it comes to extendibility, JSON-LD and JSON schemas could =
work together to provide a more explicit information on the type of =
information we're handling. You'll find a comparison at =
https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs =
 =
with standard JWT. In practice, this comes handy as a basis for verified =
credentials, would clarify the OIDC semantics and disambiguate the =
meaning of specific tokens (see for instance the discussion at =
https://www.rfc-editor.org/rfc/rfc8417.html#section-4 =
 on "Preventing =
Confusion between SETs and Other JWTs"). =20
> https://w3c.github.io/vc-imp-guide/#extending-jwts =
 provides =
interesting examples.=20
>=20
> It appears that you are proposing the JSON-LD be used in claims? Am I =
correct? Or is there somewhere it would be used in the Grant Request =
JSON?
>=20
> My understanding of the charter is the GNAP is a transport for claims, =
and that those would be defined somewhere else. OpenID Connect and =
Verified Credentials are good examples. The query for a claims similarly =
would be defined somewhere else.
> =20
>=20
> =20
>=20
> - from an extensibility point of view, I'm not sure it's very useful =
to list all possibilities. For instance, as of now, it wouldn't be =
possible to use the protocol for constrained devices, so there's no real =
value in saying that it could be extended with CoAP (then we need a =
separate document, that references the current GNAP rfc). What's more =
useful to know if the context of the current document, when you're =
implementing it, is what behaviour can really be extended in a fairly =
straightforward way, without changing anything in the core spec. For =
instance, what can I do with other types of tokens than JWT? Neither =
proposal is very clear as to how we would implement extensions in =
practice.
>=20
> In XAuth I refer to CoAP not as an extension, but as an one example of =
other client authentication mechanisms. While it only applies to CoAP, I =
think it is useful to call out how we intend GNAP to be extended.=20
>=20
> FI : isn't the charter already covering this?=20
>=20
> Yes, but most people that are not in the WG don't read the charter. :)
> =20
>=20
> Just like OAuth 2.0, the access token is opaque to the client, and it =
is not specified, so I'm confused what you mean by "other types of =
tokens than JWT"?
>=20
> FI : I mean, for instance, linked data proofs, macaroons, and so on.=20=

>=20
> I see. When I read 'token', I think of access tokens. You are =
referring to what I would call a claims, which per above are defined =
somewhere else.
> =20
> =20
>=20
> - from an implementation perspective, it would make sense to decompose =
the flow between the Grant Server (GS) and the login/consent part (as =
done for instance by ory.sh). This way you would separate the concerns: =
on one side you have the HTTP flows (managed by the GS, which can be =
very optimized from a backend perspective), but you can =
delegate/customize the interaction UI to some agreed dedicated endpoint =
(typically a JS site). Maybe that's just a detail which doesn't have its =
place in the spec, but since it would change the flow, it might be =
important to consider, at least as a possibility/extension.
>=20
> Is the interaction UI not part of the GS though? I agree that an =
implementation can decompose those, but that sounds like an =
implementation choice of the GS, and not something that requires =
standardization. I agree that we want to anticipate the decomposition.* =
Is there a change in the flow that would make that easier?
>=20
> FI : I agree with you on the principle. We're currently testing that =
to make sure the standard is supporting these kind of implementation =
choice. In XYZ, it means changing the URI for the interaction, having an =
additional nonce for the interact server (maybe we can remove that =
constraint later on, because it changes details in the interaction), and =
the rest stays the same.=20
>=20
> I'd be interested in the details on how you are implementing it!
> =20
>=20
> *One of the reasons I favor using URIs and methods for the different =
functionality of the GS API is that it is easy for a router to route a =
request to different components of the GS.
>=20
> FI : yes, and that's something interesting that we'll need to discuss =
further.=20
>=20
> :)
> =20
> =20
> /Dick
> --=20
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth


--Apple-Mail=_82CE7FAA-882C-4A40-925B-43278BE6A28A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Getting the extensibility right is going to be one of the =
most important things we need to try to balance in GNAP. I=E2=80=99ve =
worked with JSONLD on a few different things, and overall I=E2=80=99m =
not a fan of it for managing things like extensibility. It=E2=80=99s one =
of those technologies that works great if you=E2=80=99re already using =
it for everything, but it=E2=80=99s a huge learning curve if you=E2=80=99r=
e not in the space at all. Instead I would rather we see extensibility =
managed at the JSON level, instead of putting this kind of up-front =
burden of understanding on developers.

In XYZ, for example, you can add new =
items to the top of the request and response (along side =E2=80=9Ckey=E2=80=
=9D, =E2=80=9Cresources=E2=80=9D, =E2=80=9Cuser=E2=80=9D, =
=E2=80=9Caccess_token=E2=80=9D, and the like), and these all get their =
own semantics. Additionally, you can extend the inner parts of the =
protocol, like the =E2=80=9Cinteraction=E2=80=9D section of the request =
can have new interaction capabilities, and the key section can have new =
proofing mechanisms. And perhaps most importantly, the =E2=80=9Cresources=E2=
=80=9D sections can have items that are specific to a given API, since =
all APIs are potentially different and GNAP shouldn=E2=80=99t make =
assumptions about how they=E2=80=99re structured. The extensibility of =
all of these can be managed without using a formal schema language like =
JSONLD. We can define core elements in the GNAP spec, and allow =
extension on a registry, for example. Or we could use a name spacing =
mechanism for some things like the resources where we expect a lot of =
variability.

But=
 not everything outside of our core fits this extension category. I =
don=E2=80=99t see CoAP as an extension, for example, because it=E2=80=99s =
a replacement for the whole HTTP/JSON layer, not just the =
authentication/key-proofing portions. I don=E2=80=99t think it makes =
sense to have GNAP be so abstracted away from HTTP/JSON that we end up =
with a model/binding style specification, and that sentiment is built =
into the proposed charter. An aside, you could do a COSE-style signature =
as a proof mechanism, or a CWK key format, and those would both be =
extensions to GNAP, since they could be communicated over the same base =
protocol.

And =
finally, there are going to be parts of the protocol that are controlled =
by other working groups and efforts. For instance, someone might want to =
make it possible to return identity information or resource information =
directly in the token response, but that=E2=80=99s outside of what GNAP =
is here for. We have agreement to return identifiers for users (so, =
things like an issuer/subject pair, an email address, a phone number, =
etc), but not profile information or other identity =
components. 

We=E2=80=99ve got a difficult and important thing to balance =
here: we need to have enough detail in the protocol that it=E2=80=99s =
usable without having to defer to other groups or documentation (ie, you =
shouldn=E2=80=99t need a profile of GNAP to be able to run GNAP), but we =
need to be flexible enough in our structures to accommodate new ways of =
working and doing things, especially when we=E2=80=99re looking at =
things that OAuth 2 is too rigid to handle well, like flexible =
interaction methods.

 =E2=80=94 Justin

On Jul =
5, 2020, at 8:47 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi, 

You're spot =
on with you last comments, we should stay very clear on claims vs tokens =
(and indeed they are defined in other working groups). I agree with =
that. 

What I'm suggesting is that json-ld may be used =
as a support for providing context and extendibility capabilities, as it =
provides a conventional manner of defining metadata to deliver on the =
polymorphic feature of the core protocol. 
Request/response (and continuation) endpoints may use this =
metadata to adapt their behavior to the capabilities or intent of the =
other party (client and AS). The most obvious example is for resources =
description ("dolphin-metadata" in the XYZ example), to provide semantic =
context around common access patterns. 

Cheers,

Fabien

Le sam. 4 juil. 2020 =C3=A0 03:33, Dick Hardt =
<dick.hardt@gmail.com> a =C3=A9crit :


On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault =
<fabien.imbault@gmail.com> wrote:
Thanks Dick. 

Likewise, comments =
inserted (marked with "FI").

On Thu, Jul =
2, 2020 at 7:34 PM Dick Hardt <dick.hardt@gmail.com> =
wrote:
Hi Fabien, sorry for the late reply

Comments and =
questions inserted ... 

On Wed, Jun =
17, 2020 at 3:47 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
<snip>

Beyond what I said on =
the redirect, we could probably benefit from a more formal definition of =
the flows (a bit different between the 2 proposals), as proposed =
recently by Francis Pouatcha for instance (interact/decoupled/embedded =
flows, TBD).

Which proposal was =
that?

FI : I'll try to find it =
back. 
 

What=
 I'm missing in both proposals (personal opinion): 

- I know that JSON is =
the usual format, but it would be really useful to complement the =
schemas with some JSON-LD descriptions as well. It would ease extensions =
and interoperability (by avoiding conflicting schemas), and could even =
provide a more generic way of representing verifiable presentations =
(challenge/nonce associated to a domain for instance). While most of =
this work on linked data has been done at W3C, it would add value to the =
current proposal so I think we should consider =
it. 

I'm not understanding how JSON-LD would =
fit in. Would you provide an example?

FI : when it comes to =
extendibility, JSON-LD and JSON schemas could work together to provide a =
more explicit information on the type of information we're handling. =
You'll find a comparison at https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-=
proofs with standard JWT. In practice, this comes handy as a =
basis for verified credentials, would clarify the OIDC semantics and =
disambiguate the meaning of specific tokens (see for instance the =
discussion at https://www.rfc-editor.org/rfc/rfc8417.html#section-4 =
on "Preventing Confusion between SETs and Other =
JWTs").  
https://w3c.github.io/vc-imp-guide/#extending-jwts pro=
vides interesting examples. 

It appears that you are =
proposing the JSON-LD be used in claims? Am I correct? Or is there =
somewhere it would be used in the Grant Request JSON?

My understanding of the =
charter is the GNAP is a transport for claims, and that those would be =
defined somewhere else. OpenID Connect and Verified Credentials are good =
examples. The query for a claims similarly would be defined somewhere =
else.
 

 

- from an extensibility =
point of view, I'm not sure it's very useful to list all possibilities. =
For instance, as of now, it wouldn't be possible to use the protocol for =
constrained devices, so there's no real value in saying that it could be =
extended with CoAP (then we need a separate document, that references =
the current GNAP rfc). What's more useful to know if the context of the =
current document, when you're implementing it, is what behaviour can =
really be extended in a fairly straightforward way, without =
changing anything in the core spec. For instance, what can I do with =
other types of tokens than JWT? Neither proposal is very clear as to how =
we would implement extensions in practice.

In XAuth I refer to CoAP =
not as an extension, but as an one example of other client =
authentication mechanisms. While it only applies to CoAP, I think it is =
useful to call out how we intend GNAP to be =
extended. 

FI : isn't the charter already covering =
this? 

Yes, but most people that are not in =
the WG don't read the charter. :)
 

Just like OAuth 2.0, the access token is opaque to the =
client, and it is not specified, so I'm confused what you mean by "other =
types of tokens than JWT"?

FI : I mean, =
for instance, linked data proofs, macaroons, and so =
on. 

I see. When I read 'token', I think of =
access tokens. You are referring to what I would call a claims, which =
per above are defined somewhere else.
 
 

- from an implementation =
perspective, it would make sense to decompose the flow between the Grant =
Server (GS) and the login/consent part (as done for instance by ory.sh). =
This way you would separate the concerns: on one side you have the HTTP =
flows (managed by the GS, which can be very optimized from a backend =
perspective), but you can delegate/customize the interaction UI to some =
agreed dedicated endpoint (typically a JS site). Maybe that's just a =
detail which doesn't have its place in the spec, but since it would =
change the flow, it might be important to consider, at least as a =
possibility/extension.

Is the interaction UI not part of the =
GS though? I agree that an implementation can decompose those, but that =
sounds like an implementation choice of the GS, and not something that =
requires standardization. I agree that we want to anticipate the =
decomposition.* Is there a change in the flow that would make that =
easier?

FI : I agree with you on the principle. =
We're currently testing that to make sure the standard is supporting =
these kind of implementation choice. In XYZ, it means changing the URI =
for the interaction, having an additional nonce for the interact server =
(maybe we can remove that constraint later on, because it changes =
details in the interaction), and the rest stays the =
same. 

I'd be interested in the details on how =
you are implementing it!
 

*One of the reasons I favor using URIs and methods for the =
different functionality of the GS API is that it is easy for a =
router to route a request to different components of the =
GS.

FI : yes, and that's something =
interesting that we'll need to discuss =
further. 

:)
 
 
/Dick















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

=

--Apple-Mail=_82CE7FAA-882C-4A40-925B-43278BE6A28A--


From nobody Sun Jul  5 15:53: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 D09BD3A0BAC for ; Sun,  5 Jul 2020 15:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 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] 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 xALDWPbbaunC for ; Sun,  5 Jul 2020 15:53:49 -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 9C8A73A0BAA for ; Sun,  5 Jul 2020 15:53:49 -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 065MrhCE000655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 5 Jul 2020 18:53:45 -0400
Date: Sun, 5 Jul 2020 15:53:43 -0700
From: Benjamin Kaduk 
To: Dick Hardt 
Cc: Fabien Imbault , txauth@ietf.org
Message-ID: <20200705225343.GQ16335@kduck.mit.edu>
References:       
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 05 Jul 2020 22:53:51 -0000

Hi Dick, Fabien,

Just to clarify on one point, and check whether I'm confused:

On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:
> On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault 
> wrote:
> 
> > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt  wrote:
> >
> >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault 
> >> wrote:
> 
> >
> >> Just like OAuth 2.0, the access token is opaque to the client, and it is
> >> not specified, so I'm confused what you mean by "other types of tokens than
> >> JWT"?
> >>
> >> FI : I mean, for instance, linked data proofs, macaroons, and so on.
> >
> 
> I see. When I read 'token', I think of access tokens. You are referring to
> what I would call a claims, which per above are defined somewhere else.

My understanding was that macaroons, at least, were complete tokens that
incorporate (at least by reference) multiple claims.  So a macaroon and a
JWT would be analogous in that sense (container holding many claims).  I'm
not sure whether the same holds for a linked data proof (or if it's just a
way to represent a single claim), though.

Am I confused?

Thanks,

Ben


From nobody Mon Jul  6 01:01: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 3969A3A11A5 for ; Mon,  6 Jul 2020 01:01:31 -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 OIA-Hk_DOBxz for ; Mon,  6 Jul 2020 01:01:28 -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 A980D3A11A6 for ; Mon,  6 Jul 2020 01:01:28 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id a12so38390828ion.13 for ; Mon, 06 Jul 2020 01:01: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=9S83oqEgGX3KVp3uDjy944qfHd7CvgSMqgDB3mvWsB4=; b=m3zgy63M6ze0YEH6hHFuxcfryVrDv34+zVAazNOPqHyMQDCALfpoLWmmcf9PajywhL WzrtPoYBQLdk51akC5g0IkIYsa5jcoAxO3UHBLWUBUaxzo/+SzCkWcDwoiE6WW1qM51L B4ydTGZsz2eQmZZvYgCFp2jQEVGnLHa7VUq3ghy2XazbjeEsE6k/oIDQ0eJD0kBT82vb HdUW6sJ2K7oa21FvpClAGrG8pYia7E1nxOAas/JFFJmEak/xZkOXRX2nBVYjmvT1i/aM YYeMgnsi5m8TtMWHNr7dF58XHTttw1g+kq/dDg8sTgQdyROl+K4dHAuqXv9PtQ/VmmfD BKyQ==
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=9S83oqEgGX3KVp3uDjy944qfHd7CvgSMqgDB3mvWsB4=; b=aGVNXU+mnBuaA5RhtU3bwG8TAGXU1eAz1HoeO9NYrIEZg8R6A0XICirgMA3Od1ppHN 9tmIH0RspHkRK1UU6ZYnjAq8g6AsC8HkgCaIepAaoC1wKrFxcKsmUAMpEEzU9qNWmt27 nKPTZAHPD+Pe+8ewhOMnepTqXbkSgW7XxDkKYfQW6vrtMBycYbBfnAF3s8ioPiHsshxY YVhyMOmKtjdP4AgQnJpYGPb2GOTxdpnhUJP/b9xX49ShzL4tLjgmAg5JDawxQcBXRieX SxA4+Dd46C7x1Cm+jBg7veZMbrirLFfxOEWkfAyyONlQBmVnBxkK2RYL+/42/TvbriuQ kvyw==
X-Gm-Message-State: AOAM533T8taI/2kHbAoeR4cqQP/tsPWCdcKs3P9G/NLEJ9pH2amoR1TY T4dnRskr+oWD1Gu0H3ai1PYHsEG15dVgGaAXSBg=
X-Google-Smtp-Source: ABdhPJyOKU9xjPymLV6/gMnWUr98ZJB+VlmXvGEBcfK8O7pp2aSBU6M69GHyZ6bmJWhUoA6uO+ji41uGqsOV86rEBfw=
X-Received: by 2002:a5e:d90c:: with SMTP id n12mr23829674iop.144.1594022487866;  Mon, 06 Jul 2020 01:01:27 -0700 (PDT)
MIME-Version: 1.0
References:         
In-Reply-To: 
From: Fabien Imbault 
Date: Mon, 6 Jul 2020 10:01:16 +0200
Message-ID: 
To: Justin Richer 
Cc: Dick Hardt , txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000027433e05a9c1482e"
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 06 Jul 2020 08:01:31 -0000

--00000000000027433e05a9c1482e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Justin,

My experience is that JSONLD is much simpler than RDF (which looks much
more alien indeed) and, if done right, wouldn't necessarily be a burden.
But of course, we'd have to demonstrate the added value.

In any case, I agree that CoAP is a very different issue, and not something
I would consider an extension in the sense discussed here. So I agree 100%
on that, as well as on the links with other WG.

Maybe we could start with some concrete examples of what we would encounter
as potential extensions (of course we wouldn't get the full list, but it
might help to test a few variants).

Cheers.

Fabien

On Sun, Jul 5, 2020 at 9:15 PM Justin Richer  wrote:

> Getting the extensibility right is going to be one of the most important
> things we need to try to balance in GNAP. I=E2=80=99ve worked with JSONLD=
 on a few
> different things, and overall I=E2=80=99m not a fan of it for managing th=
ings like
> extensibility. It=E2=80=99s one of those technologies that works great if=
 you=E2=80=99re
> already using it for everything, but it=E2=80=99s a huge learning curve i=
f you=E2=80=99re
> not in the space at all. Instead I would rather we see extensibility
> managed at the JSON level, instead of putting this kind of up-front burde=
n
> of understanding on developers.
>
> In XYZ, for example, you can add new items to the top of the request and
> response (along side =E2=80=9Ckey=E2=80=9D, =E2=80=9Cresources=E2=80=9D, =
=E2=80=9Cuser=E2=80=9D, =E2=80=9Caccess_token=E2=80=9D, and the
> like), and these all get their own semantics. Additionally, you can exten=
d
> the inner parts of the protocol, like the =E2=80=9Cinteraction=E2=80=9D s=
ection of the
> request can have new interaction capabilities, and the key section can ha=
ve
> new proofing mechanisms. And perhaps most importantly, the =E2=80=9Cresou=
rces=E2=80=9D
> sections can have items that are specific to a given API, since all APIs
> are potentially different and GNAP shouldn=E2=80=99t make assumptions abo=
ut how
> they=E2=80=99re structured. The extensibility of all of these can be mana=
ged
> without using a formal schema language like JSONLD. We can define core
> elements in the GNAP spec, and allow extension on a registry, for example=
.
> Or we could use a name spacing mechanism for some things like the resourc=
es
> where we expect a lot of variability.
>
> But not everything outside of our core fits this extension category. I
> don=E2=80=99t see CoAP as an extension, for example, because it=E2=80=99s=
 a replacement for
> the whole HTTP/JSON layer, not just the authentication/key-proofing
> portions. I don=E2=80=99t think it makes sense to have GNAP be so abstrac=
ted away
> from HTTP/JSON that we end up with a model/binding style specification, a=
nd
> that sentiment is built into the proposed charter. An aside, you could do=
 a
> COSE-style signature as a proof mechanism, or a CWK key format, and those
> would both be extensions to GNAP, since they could be communicated over t=
he
> same base protocol.
>
> And finally, there are going to be parts of the protocol that are
> controlled by other working groups and efforts. For instance, someone mig=
ht
> want to make it possible to return identity information or resource
> information directly in the token response, but that=E2=80=99s outside of=
 what GNAP
> is here for. We have agreement to return identifiers for users (so, thing=
s
> like an issuer/subject pair, an email address, a phone number, etc), but
> not profile information or other identity components.
>
> We=E2=80=99ve got a difficult and important thing to balance here: we nee=
d to have
> enough detail in the protocol that it=E2=80=99s usable without having to =
defer to
> other groups or documentation (ie, you shouldn=E2=80=99t need a profile o=
f GNAP to
> be able to run GNAP), but we need to be flexible enough in our structures
> to accommodate new ways of working and doing things, especially when we=
=E2=80=99re
> looking at things that OAuth 2 is too rigid to handle well, like flexible
> interaction methods.
>
>  =E2=80=94 Justin
>
> On Jul 5, 2020, at 8:47 AM, Fabien Imbault 
> wrote:
>
> Hi,
>
> You're spot on with you last comments, we should stay very clear on claim=
s
> vs tokens (and indeed they are defined in other working groups). I agree
> with that.
>
> What I'm suggesting is that json-ld may be used as a support for providin=
g
> context and extendibility capabilities, as it provides a conventional
> manner of defining metadata to deliver on the polymorphic feature of the
> core protocol.
> Request/response (and continuation) endpoints may use this metadata to
> adapt their behavior to the capabilities or intent of the other party
> (client and AS). The most obvious example is for resources description
> ("dolphin-metadata" in the XYZ example), to provide semantic context arou=
nd
> common access patterns.
>
> Cheers,
>
> Fabien
>
> Le sam. 4 juil. 2020 =C3=A0 03:33, Dick Hardt  a =
=C3=A9crit :
>
>>
>>
>> On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault 
>> wrote:
>>
>>> Thanks Dick.
>>>
>>> Likewise, comments inserted (marked with "FI").
>>>
>>> On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt  wrote:
>>>
>>>> Hi Fabien, sorry for the late reply
>>>>
>>>> Comments and questions inserted ...
>>>>
>>>> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <
>>>> fabien.imbault@gmail.com> wrote:
>>>> 
>>>>
>>>>>
>>>>> Beyond what I said on the redirect, we could probably benefit from a
>>>>> more formal definition of the flows (a bit different between the 2
>>>>> proposals), as proposed recently by Francis Pouatcha for instance
>>>>> (interact/decoupled/embedded flows, TBD).
>>>>>
>>>>
>>>> Which proposal was that?
>>>>
>>>
>>> FI : I'll try to find it back.
>>>
>>>>
>>>>
>>>>>
>>>>> What I'm missing in both proposals (personal opinion):
>>>>>
>>>>> - I know that JSON is the usual format, but it would be really useful
>>>>> to complement the schemas with some JSON-LD descriptions as well. It =
would
>>>>> ease extensions and interoperability (by avoiding conflicting schemas=
), and
>>>>> could even provide a more generic way of representing verifiable
>>>>> presentations (challenge/nonce associated to a domain for instance). =
While
>>>>> most of this work on linked data has been done at W3C, it would add v=
alue
>>>>> to the current proposal so I think we should consider it.
>>>>>
>>>>
>>>> I'm not understanding how JSON-LD would fit in. Would you provide an
>>>> example?
>>>>
>>>
>>> FI : when it comes to extendibility, JSON-LD and JSON schemas could wor=
k
>>> together to provide a more explicit information on the type of informat=
ion
>>> we're handling. You'll find a comparison at
>>> https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs w=
ith
>>> standard JWT. In practice, this comes handy as a basis for verified
>>> credentials, would clarify the OIDC semantics and disambiguate the mean=
ing
>>> of specific tokens (see for instance the discussion at
>>> https://www.rfc-editor.org/rfc/rfc8417.html#section-4 on "Preventing
>>> Confusion between SETs and Other JWTs").
>>> https://w3c.github.io/vc-imp-guide/#extending-jwts provides interesting
>>> examples.
>>>
>>
>> It appears that you are proposing the JSON-LD be used in claims? Am I
>> correct? Or is there somewhere it would be used in the Grant Request JSO=
N?
>>
>> My understanding of the charter is the GNAP is a transport for claims,
>> and that those would be defined somewhere else. OpenID Connect and Verif=
ied
>> Credentials are good examples. The query for a claims similarly would be
>> defined somewhere else.
>>
>>
>>>
>>>
>>>>
>>>>>
>>>>> - from an extensibility point of view, I'm not sure it's very useful
>>>>> to list all possibilities. For instance, as of now, it wouldn't be po=
ssible
>>>>> to use the protocol for constrained devices, so there's no real value=
 in
>>>>> saying that it could be extended with CoAP (then we need a separate
>>>>> document, that references the current GNAP rfc). What's more useful t=
o know
>>>>> if the context of the current document, when you're implementing it, =
is
>>>>> what behaviour can really be extended in a fairly straightforward
>>>>> way, without changing anything in the core spec. For instance, what c=
an I
>>>>> do with other types of tokens than JWT? Neither proposal is very clea=
r as
>>>>> to how we would implement extensions in practice.
>>>>>
>>>>
>>>> In XAuth I refer to CoAP not as an extension, but as an one example of
>>>> other client authentication mechanisms. While it only applies to CoAP,=
 I
>>>> think it is useful to call out how we intend GNAP to be extended.
>>>>
>>>
>>> FI : isn't the charter already covering this?
>>>
>>
>> Yes, but most people that are not in the WG don't read the charter. :)
>>
>>
>>>
>>>> Just like OAuth 2.0, the access token is opaque to the client, and it
>>>> is not specified, so I'm confused what you mean by "other types of tok=
ens
>>>> than JWT"?
>>>>
>>>> FI : I mean, for instance, linked data proofs, macaroons, and so on.
>>>
>>
>> I see. When I read 'token', I think of access tokens. You are referring
>> to what I would call a claims, which per above are defined somewhere els=
e.
>>
>>
>>>
>>>>
>>>>>
>>>>> - from an implementation perspective, it would make sense to decompos=
e
>>>>> the flow between the Grant Server (GS) and the login/consent part (as=
 done
>>>>> for instance by ory.sh). This way you would separate the concerns: on=
 one
>>>>> side you have the HTTP flows (managed by the GS, which can be very
>>>>> optimized from a backend perspective), but you can delegate/customize=
 the
>>>>> interaction UI to some agreed dedicated endpoint (typically a JS site=
).
>>>>> Maybe that's just a detail which doesn't have its place in the spec, =
but
>>>>> since it would change the flow, it might be important to consider, at=
 least
>>>>> as a possibility/extension.
>>>>>
>>>>
>>>> Is the interaction UI not part of the GS though? I agree that an
>>>> implementation can decompose those, but that sounds like an implementa=
tion
>>>> choice of the GS, and not something that requires standardization. I a=
gree
>>>> that we want to anticipate the decomposition.* Is there a change in th=
e
>>>> flow that would make that easier?
>>>>
>>>
>>> FI : I agree with you on the principle. We're currently testing that to
>>> make sure the standard is supporting these kind of implementation choic=
e.
>>> In XYZ, it means changing the URI for the interaction, having an additi=
onal
>>> nonce for the interact server (maybe we can remove that constraint late=
r
>>> on, because it changes details in the interaction), and the rest stays =
the
>>> same.
>>>
>>
>> I'd be interested in the details on how you are implementing it!
>>
>>
>>>
>>>> *One of the reasons I favor using URIs and methods for the different
>>>> functionality of the GS API is that it is easy for a router to route a
>>>> request to different components of the GS.
>>>>
>>>
>>> FI : yes, and that's something interesting that we'll need to discuss
>>> further.
>>>
>>
>> :)
>>
>>
>>>
>>>> /Dick
>>>>
>>>>> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>

--00000000000027433e05a9c1482e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Justin,=C2=A0

My experien=
ce is that JSONLD is much simpler than RDF (which looks much more alien ind=
eed) and, if done=C2=A0right, wouldn't necessarily be a burden. But of =
course, we'd have to demonstrate the added value.=C2=A0

<=
/div>
In any case, I agree that CoAP is a very different issue, and not=
 something I would consider an extension in the sense discussed here. So I =
agree 100% on that, as well as on the links with other=C2=A0WG.
<=
br>
Maybe we could start with some concrete examples of what we w=
ould encounter as potential extensions (of course we wouldn't get the f=
ull list,=C2=A0but it might help to test a few variants).=C2=A0
<=
br>
Cheers.

Fabien

On Sun, Jul 5, 2020 =
at 9:15 PM Justin Richer <jricher@mit=
.edu> wrote:
Getting the extensibility rig=
ht is going to be one of the most important things we need to try to balanc=
e in GNAP. I=E2=80=99ve worked with JSONLD on a few different things, and o=
verall I=E2=80=99m not a fan of it for managing things like extensibility. =
It=E2=80=99s one of those technologies that works great if you=E2=80=99re a=
lready using it for everything, but it=E2=80=99s a huge learning curve if y=
ou=E2=80=99re not in the space at all. Instead I would rather we see extens=
ibility managed at the JSON level, instead of putting this kind of up-front=
 burden of understanding on developers.

In XYZ, for exam=
ple, you can add new items to the top of the request and response (along si=
de =E2=80=9Ckey=E2=80=9D, =E2=80=9Cresources=E2=80=9D, =E2=80=9Cuser=E2=80=
=9D, =E2=80=9Caccess_token=E2=80=9D, and the like), and these all get their=
 own semantics. Additionally, you can extend the inner parts of the protoco=
l, like the =E2=80=9Cinteraction=E2=80=9D section of the request can have n=
ew interaction capabilities, and the key section can have new proofing mech=
anisms. And perhaps most importantly, the =E2=80=9Cresources=E2=80=9D secti=
ons can have items that are specific to a given API, since all APIs are pot=
entially different and GNAP shouldn=E2=80=99t make assumptions about how th=
ey=E2=80=99re structured. The extensibility of all of these can be managed =
without using a formal schema language like JSONLD. We can define core elem=
ents in the GNAP spec, and allow extension on a registry, for example. Or w=
e could use a name spacing mechanism for some things like the resources whe=
re we expect a lot of variability.

But not everyth=
ing outside of our core fits this extension category. I don=E2=80=99t see C=
oAP as an extension, for example, because it=E2=80=99s a replacement for th=
e whole HTTP/JSON layer, not just the authentication/key-proofing portions.=
 I don=E2=80=99t think it makes sense to have GNAP be so abstracted away fr=
om HTTP/JSON that we end up with a model/binding style specification, and t=
hat sentiment is built into the proposed charter. An aside, you could do a =
COSE-style signature as a proof mechanism, or a CWK key format, and those w=
ould both be extensions to GNAP, since they could be communicated over the =
same base protocol.

And finally, there are going t=
o be parts of the protocol that are controlled by other working groups and =
efforts. For instance, someone might want to make it possible to return ide=
ntity information or resource information directly in the token response, b=
ut that=E2=80=99s outside of what GNAP is here for. We have agreement to re=
turn identifiers for users (so, things like an issuer/subject pair, an emai=
l address, a phone number, etc), but not profile information or other ident=
ity components.=C2=A0

We=E2=80=99ve got a difficul=
t and important thing to balance here: we need to have enough detail in the=
 protocol that it=E2=80=99s usable without having to defer to other groups =
or documentation (ie, you shouldn=E2=80=99t need a profile of GNAP to be ab=
le to run GNAP), but we need to be flexible enough in our structures to acc=
ommodate new ways of working and doing things, especially when we=E2=80=99r=
e looking at things that OAuth 2 is too rigid to handle well, like flexible=
 interaction methods.

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


On Jul 5, 2020, at 8:47 AM, Fa=
bien Imbault <fabien.imbault@gmail.com> wrote:

Hi,=C2=A0

You're spot on =
with you last comments, we should stay very clear on claims vs tokens (and =
indeed they are defined in other working groups). I agree with that.=C2=A0<=
/div>

What I'm suggesting =
is that json-ld may be used as a support for providing context and extendib=
ility capabilities, as it provides a conventional manner of defining metada=
ta to deliver on the polymorphic feature of the core protocol.=C2=A0
<=
div dir=3D"auto">Request/response (and continuation) endpoints may use this=
 metadata to adapt their behavior to the capabilities or intent of the othe=
r party (client and AS). The most obvious example is for resources descript=
ion ("dolphin-metadata" in the XYZ example), to provide semantic =
context around common access patterns.=C2=A0

Cheers,

Fabien

Le sam. 4 juil. 2020 =C3=A0 03:33, Dick Hardt <dick.hardt@gmail.com&=
gt; a =C3=A9crit=C2=A0:


On Fri, Jul 3, 2020 at 1:19 A=
M Fabien Imbault <fabien.imbault@gmail.com> wrote:
Thanks Dick.=C2=A0

Likewise, comments=
 inserted (marked with "FI").

On Thu, Jul 2, 2020 at 7:34 PM Dick =
Hardt <dick.hardt@gmail.com> wrote:
Hi Fabien, sorry f=
or the late reply

Comments and questions=C2=A0inserted .=
..=C2=A0

On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <fabien.imb=
ault@gmail.com> wrote:
<snip>

Beyond what I said on the redirect, we could probably benef=
it from a more formal definition of the flows (a bit different between the =
2 proposals), as proposed recently by Francis Pouatcha for instance (intera=
ct/decoupled/embedded flows, TBD).

Which proposal was that?

FI : I'll try to find it back.=C2=A0
=C2=A0

What I'm missing in both proposals (personal opin=
ion):=C2=A0

- I know that JSON is the usual format=
, but it would be really useful to complement the schemas with some JSON-LD=
 descriptions as well. It would ease extensions and interoperability (by av=
oiding conflicting schemas), and could even provide a more generic way of r=
epresenting verifiable presentations (challenge/nonce associated to a domai=
n for instance). While most of this work on linked data has been done at W3=
C, it would add value to the current proposal so=C2=A0I think we should con=
sider it.=C2=A0

I'm not und=
erstanding how JSON-LD would fit in. Would you provide an example?

FI : when it comes to extendibili=
ty, JSON-LD and JSON schemas could work together to provide a more explicit=
 information on the type of information we're handling. You'll find=
 a comparison at=C2=A0https://w3c.github=
.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs=C2=A0with standard =
JWT. In practice, this comes handy as a basis for verified credentials, wou=
ld clarify the OIDC semantics and disambiguate the meaning of specific toke=
ns (see for instance the discussion at=C2=A0https://www.=
rfc-editor.org/rfc/rfc8417.html#section-4=C2=A0on "Preventing Conf=
usion between SETs and Other JWTs").=C2=A0=C2=A0
https://w3c.github.io/vc-imp-guide/#extending-jwts=C2=A0provides i=
nteresting examples.=C2=A0

It appears that you are proposing the JSON-LD be used in claims? Am I cor=
rect? Or is there somewhere it would be used in the Grant Request JSON?

My understanding of the charter is the GNAP is a tran=
sport for claims, and that those would be defined somewhere else. OpenID Co=
nnect and Verified Credentials are good examples. The query for a claims si=
milarly would be defined somewhere else.
=C2=A0

=C2=A0

- fro=
m an extensibility point of view, I'm not sure it's very useful to =
list all possibilities. For instance, as of now, it wouldn't be possibl=
e to use the protocol for constrained devices, so there's no real value=
 in saying that it could be extended with CoAP (then we need a separate doc=
ument, that references the current GNAP rfc). What's more useful to kno=
w if the context of the current document, when you're implementing it, =
is what behaviour can really be extended in a fairly straightforward way,=
=C2=A0without changing anything in the core spec. For instance, what can I =
do with other types of tokens than JWT? Neither proposal is very clear as t=
o how we would implement extensions in practice.

In XAuth I refer to CoAP not as an extension, but as an o=
ne example of other client authentication mechanisms. While it only applies=
 to CoAP, I think it is useful to call out how we intend GNAP to be extende=
d.=C2=A0

FI : isn't t=
he charter already covering this?=C2=A0
=

Yes, but most people that are not in the WG don't read t=
he charter. :)
=C2=A0

Just like OAuth 2.0, the access token is opaque to th=
e client, and it is not specified, so I'm confused what you mean by &qu=
ot;other types of tokens than JWT"?

FI : I mean, for instance, linked data proofs, macaroons, a=
nd so on.=C2=A0

I see. Wh=
en I read 'token', I think of access tokens. You are referring to w=
hat I would call a claims, which per above are defined somewhere else.
=C2=A0
=C2=
=A0

- from an implementation perspective, it would make se=
nse to decompose the flow between the Grant Server (GS) and the login/conse=
nt part (as done for instance by ory.sh). This way you would separate the c=
oncerns: on one side you have the HTTP flows (managed by the GS, which can =
be very optimized from a backend perspective), but you can delegate/customi=
ze the interaction UI to some agreed dedicated endpoint (typically a JS sit=
e). Maybe that's just a detail which doesn't have its place in the =
spec, but since it would change the flow, it might be important to consider=
,=C2=A0at least as a possibility/extension.
Is the interaction UI not part of the GS though? I agree that =
an implementation can decompose those, but that sounds like an implementati=
on choice of the GS, and not something that requires standardization. I agr=
ee that we want to anticipate the decomposition.* Is there a change in the =
flow that would make that easier?

FI : I agree with you on the principle. We're currently testin=
g that to make sure the standard is supporting these kind of implementation=
 choice. In XYZ, it means changing the URI for the interaction, having an a=
dditional nonce for the interact server (maybe we can remove that constrain=
t later on, because it changes details in the interaction), and the rest st=
ays the same.=C2=A0

I'=
;d be interested in the details on how you are implementing it!
=
=C2=A0

*One =
of the reasons I favor using URIs and methods for the different functionali=
ty=C2=A0of the GS API is that it is easy for a router to route a request to=
 different components of the GS.

FI : yes, and that's something interesting that we'll need =
to discuss further.=C2=A0

:)
=C2=A0
=C2=A0=

/Dick
<=
div dir=3D"ltr">













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




--00000000000027433e05a9c1482e--


From nobody Mon Jul  6 01:19: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 929323A11C3 for ; Mon,  6 Jul 2020 01:19: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, RCVD_IN_DNSWL_BLOCKED=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 5B6LCgbDHXYm for ; Mon,  6 Jul 2020 01:19:15 -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 4564F3A11C1 for ; Mon,  6 Jul 2020 01:19:15 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id i4so38355124iov.11 for ; Mon, 06 Jul 2020 01:19: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=r4v+qriGN+GIoZzUh3h5ZaWeKzCbBS2yfVALT0xlp1E=; b=J+06rm6MQvz2EsAI21kl9Y2G8VmHRyd6RP2xGqpjGnHmPQA6jsCZsI11flEwl/90d6 izgPXVlBQjaxUpaFqP0CLAw092im9uySm/ZFHQqLQqXiLEHbt5jtsEwkUm7ed1Xf97T0 0rZnGcYsH3kVklmBMo+sd0B+QUJhWqEBLvD0hltiQ/akjXvgTg0sFoHwzAhr5JKp0oa4 OUBjHFkoeesyCCwTcCIXeR2bCuwSHOQ7aMMzB3mhY0HsUj/L8gQs4oouOcRhn30vxKw4 a2aqLfujJ7xVD2U6OgOxM29e9HOpZhLPua1hE22jUHBq/GU9YhRPYFNPsd68zgvQoAxu fXcw==
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=r4v+qriGN+GIoZzUh3h5ZaWeKzCbBS2yfVALT0xlp1E=; b=lA6mVn8h5BlsnpBWIzku3znJe+z3ECQz8Ilepbqt5ddCJ5a012IN/A71lHcZea3QU/ WpP7SLXk4qMRaMxhSvXX+HOL3E49tTC/ghtpx8Z46HbdkbH8eZVBQW4GUAfeNHKC/I7c HUQA+rDq+grjYzOLq5r+HlEfroHLz5Nu0uY+MF6sH6wRtyYyLnEnE7bZO34mf0IyTZRQ VSPVFzK/T2+bJfSbfeNpVd34YMq1QZqo82yuQ2FQk13TkZxsbfu2ZPbfPPFjONCXHuGT 88mUNdQMEkbiBYWC2AsFOW8Q6uGQN5hV3uyj0MM902wfqq0dUeehW7IeoqsaTmHXC3Qg yK2w==
X-Gm-Message-State: AOAM531zSpSwdUJo7yfyMF9N97Gi/0bwf+MFAdVh1WR3kPkn771ish4w FCEE+WqcOB2KwsYPB+SK9P0bywCEpkOxOBiX3ZTGPhnECYc=
X-Google-Smtp-Source: ABdhPJxI50uu2SmEU9UBMvl8bcLQgz7GUMCf4ho/YxpEQnuBJ3mNUbnrAEUJBc2zZjYEhRGtd0OxXel+oxefRH1LG6E=
X-Received: by 2002:a5d:8f98:: with SMTP id l24mr24050939iol.141.1594023554446;  Mon, 06 Jul 2020 01:19:14 -0700 (PDT)
MIME-Version: 1.0
References:        <20200705225343.GQ16335@kduck.mit.edu>
In-Reply-To: <20200705225343.GQ16335@kduck.mit.edu>
From: Fabien Imbault 
Date: Mon, 6 Jul 2020 10:19:03 +0200
Message-ID: 
To: Benjamin Kaduk 
Cc: Dick Hardt , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b9f83205a9c187fc"
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 06 Jul 2020 08:19:17 -0000

--000000000000b9f83205a9c187fc
Content-Type: text/plain; charset="UTF-8"

Writing too fast, with an iteration of unrelated examples, did not convey
the right message. Sorry if it wasn't clear and confusing. We indeed need
to differentiate between bearer tokens (e.g. JWT, macaroons or even simple
cookies, etc.) and identity claims (e.g. OIDC claims, linked data proofs,
etc.).
I only wanted to say that we need to take into account that there might be
a variety of formats defined elsewhere. Not only OIDC (for claims) + JWT
(for access tokens).

Regarding JWT vs macaroons : I would say that JWT are additive, while
macaroons are organized around caveats (so they're subtractive in a sense).
But indeed they are both used in similar settings.

Hope that clarifies.
Fabien

On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk  wrote:

> Hi Dick, Fabien,
>
> Just to clarify on one point, and check whether I'm confused:
>
> On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:
> > On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault 
> > wrote:
> >
> > > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt 
> wrote:
> > >
> > >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <
> fabien.imbault@gmail.com>
> > >> wrote:
> >
> > >
> > >> Just like OAuth 2.0, the access token is opaque to the client, and it
> is
> > >> not specified, so I'm confused what you mean by "other types of
> tokens than
> > >> JWT"?
> > >>
> > >> FI : I mean, for instance, linked data proofs, macaroons, and so on.
> > >
> >
> > I see. When I read 'token', I think of access tokens. You are referring
> to
> > what I would call a claims, which per above are defined somewhere else.
>
> My understanding was that macaroons, at least, were complete tokens that
> incorporate (at least by reference) multiple claims.  So a macaroon and a
> JWT would be analogous in that sense (container holding many claims).  I'm
> not sure whether the same holds for a linked data proof (or if it's just a
> way to represent a single claim), though.
>
> Am I confused?
>
> Thanks,
>
> Ben
>

--000000000000b9f83205a9c187fc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Writing too fast, with an iteration of unrelated examples,=
 did not convey the right message.=C2=A0Sorry if it wasn't clear and co=
nfusing. We indeed need to differentiate between bearer tokens (e.g. JWT, m=
acaroons or even simple cookies, etc.) and identity claims (e.g. OIDC claim=
s, linked data proofs, etc.).
I only wanted to say that we ne=
ed to take into account that there might be a variety of formats defined el=
sewhere. Not only OIDC (for claims) + JWT (for access tokens).
=
=C2=A0
Regarding JWT vs macaroons : I would say that JWT ar=
e additive, while macaroons are organized around caveats (so they're su=
btractive in a sense). But indeed they are both used in similar settings.=
=C2=A0

Hope that clarifies.
Fabien
=


On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Dick, Fabien,



Just to clarify on one point, and check whether I'm confused:



On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:

> On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault <fabien.imbault@gmail.com><=
br>
> wrote:

> 

> > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt <dick.hardt@gmail.com> wrote:<=
br>
> >

> >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <fabien.imbault@gmail.co=
m>

> >> wrote:

> 

> >

> >> Just like OAuth 2.0, the access token is opaque to the client=
, and it is

> >> not specified, so I'm confused what you mean by "oth=
er types of tokens than

> >> JWT"?

> >>

> >> FI : I mean, for instance, linked data proofs, macaroons, and=
 so on.

> >

> 

> I see. When I read 'token', I think of access tokens. You are =
referring to

> what I would call a claims, which per above are defined somewhere else=
.



My understanding was that macaroons, at least, were complete tokens that
incorporate (at least by reference) multiple claims.=C2=A0 So a macaroon an=
d a

JWT would be analogous in that sense (container holding many claims).=C2=A0=
 I'm

not sure whether the same holds for a linked data proof (or if it's jus=
t a

way to represent a single claim), though.



Am I confused?



Thanks,



Ben




--000000000000b9f83205a9c187fc--


From nobody Mon Jul  6 03:15: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 732FF3A12E8 for ; Mon,  6 Jul 2020 03:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level: 
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 bCtRvbyZf3xp for ; Mon,  6 Jul 2020 03:15:46 -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 B64643A12E7 for ; Mon,  6 Jul 2020 03:15:45 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d58 with ME id zmFi220054FMSmm03mFida; Mon, 06 Jul 2020 12:15:43 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 06 Jul 2020 12:15:43 +0200
X-ME-IP: 86.238.65.197
To: Fabien Imbault 
Cc: txauth@ietf.org
References:   
From: Denis 
Message-ID: <8a723292-4d04-63c7-e57c-7e7307e145c8@free.fr>
Date: Mon, 6 Jul 2020 12:15:41 +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="------------8BA96BA3E613D4705A7ACD3C"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] RS/AS communication for multiparty 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: Mon, 06 Jul 2020 10:15:49 -0000

This is a multi-part message in MIME format.
--------------8BA96BA3E613D4705A7ACD3C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Fabien,
> Thanks Denis. It clarifies what you have in mind.
>
> While I agree with the general idea that we need to take privacy more 
> seriously, there are a few hypotheses that we need to put in 
> perspective :
>
> 1) AS-RS relationship <=> big brother. It may happen as we all know, 
> but you always have the choice as a user to not deal with orgs you 
> don't like
> or maybe even take action if they don't respect the law.

Unfortunately, the choice you mention is not always possible. There is a 
fundamental point here: since it is not always possible to trust an AS 
to respect the law,
it is possible to build an architecture where the AS will be unable to 
by-pass the law. It is the difference between :

  * "the AS *should not* do this or that" (but it could if it would) and
  * "the AS *cannot do* this or that" (it cannot even if it would).

> 2) the collusion possibility (Alice's uncle) : there are of course 
> situations where that may be an issue. This is I guess the reason for 
> the sovrin foundation
> to require that only approved issuers can participate. But even if you 
> open up the system, it always ends up as whether you can trust the 
> uncle to be honest
> in the first place (knowing that trust is a social construct).

When using computers, trust is not a "social construct". It is a 
construction where an entity A trusts an entity B for some behaviour C.
In the ABC attack, the RS will never know whether someone forwarded or 
not an access token to Alice.

> So I may require the issuer to be a well known participant instead.
>
> 3) The use of hardware FIDO inspired components does relax some of the 
> previous concern, but comes with its own sets of challenges.
> Biometrics come with their own sets of potential issues.

The use of FIDO does not imply that you must use its biometrics features.

> More trivially, if you loose your hardware, you loose your ID.

If you loose your ID, you should report of its loss. It also means that 
by design, a mechanism has been constructed to recover from the situation
within a short period of time. Unfortunately, such a property is 
currently missing in FIDO, but it does not mean that it cannot be added.

> And there can also be hacks in hardware. If I find a way to import or 
> export the private key from the enclave, the system fails.

The whole system does not fail. When someone attempts to export a 
private key from an hardware device in an unlawful way, it takes some 
time and some expertise.
As soon as the legitimate holder realizes the lost of his hardware, he 
should report the loss. Then after, the discovery of private keys stored 
into the device is no more an issue.

> So in the end, I agree it's best to enable as much privacy by design 
> as we possibly can, but we need to put that in perspective with use 
> cases too and make some tradeoffs.
> Healthcare in particular is a domain that is concerned with a constant 
> balance between privacy and security, and sometimes there is no 
> possibility to tick all boxes.
> I think an UMA2/OpenId Heart scenario is a very important case to 
> consider in that respect.

The goal of this BoF/WG is not to rubber-stamp the "Health Relationship 
Trust Profile for User-Managed Access 2.0" specification.

Since the "Health Relationship Trust Profile for User-Managed Access 
2.0" specification has nothing really specific to healthcare, what is 
the "very important case" you have in mind ?
Would it be possible to model a specific characteristic you have in mind 
in terms of model components, operations flows, trust relationships, 
privacy requirements and security requirements ?

Denis

>
> Fabien
>
>
>
>
> On Fri, Jul 3, 2020 at 12:01 PM Denis  > wrote:
>
>     Hello Fabien,
>
>     In 2017, I made a presentation at the OAuth workshop in Zurich.
>
>     The paper is available from:
>     https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf
>
>     The slides are available from:
>     https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.ppt
>     _Note_: The slides should be viewed "full screen" to get the
>     animations.
>
>     The general approach is how to construct from scratch a "privacy
>     by design" architecture taking also into consideration "security
>     by design".
>
>     Coming back to your requirement, I would not cover it if it
>     infringes the sentence "the RS and the AS never communicate directly".
>
>     You should start your design by defining the trust relationships,
>     then apply the privacy requirements while not forgetting the
>     security requirements.
>
>     Denis
>
>>     Hello Denis,
>>
>>     I have been following your comments. I still fail to see the
>>     global privacy preserving architecture you're proposing. It would
>>     help to get a more thorough proposal if you can.
>>
>>     But more specifically, I have a comment on :
>>
>>     "I would have preferred that you meant: the RS and the AS never
>>     communicate directly, which is indeed a nice property to follow
>>     to ensure the user's privacy."
>>     I think that may come as an issue in some cases, especially for multiparty patterns (like in UMA). Typically we may wish the RS to start a grant request and use the handle to continue until a token is generated.
>>     I think those cases, which weren't initially covered by OAuth2, are very important to cover as well. How would you cover such requirements?
>>     Fabien
>>
>


--------------8BA96BA3E613D4705A7ACD3C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Fabien,

    

      
      
Thanks Denis. It clarifies what you have in mind. 
        


        

        
While I agree with the general idea that we need to take
          privacy more seriously, there are a few hypotheses that we
          need to put in perspective : 

          

        

        
1) AS-RS relationship <=> big brother. It may happen
          as we all know, but you always have the choice as a user to
          not deal with orgs you don't like 

          or maybe even take action if they don't respect the law.

        

      

    

    
Unfortunately, the choice you mention is not always possible.
      There is a fundamental point here: since it is not always possible
      to trust an AS to respect the law,

      it is possible to build an architecture where the AS will be
      unable to by-pass the law. It is the difference between :

    
    
      
  • "the AS should not do this or that" (but it could if
        it would) and
    • 
      
  • "the AS cannot do this or that" (it cannot even if it
        would).  
    
      
    • 
    

    

      

        
2) the collusion possibility (Alice's uncle) : there are of
          course situations where that may be an issue. This is I guess
          the reason for the sovrin foundation 

          to require that only approved issuers can participate. But
          even if you open up the system, it always ends up as whether
          you can trust the uncle to be honest 

          in the first place (knowing that trust is a social construct).
        

      

    

    
When using computers, trust is not a "social construct". It is a
      construction where an entity A trusts an entity B for some
      behaviour C. 

      In the ABC attack, the RS will never know whether someone
      forwarded or not an access token to Alice.

    

    

      

        
So I may require the issuer to be a well known participant
          instead.

          

          3) The use of hardware FIDO inspired components does relax
          some of the previous concern, but comes with its own sets of
          challenges.

          Biometrics come with their own sets of potential issues. 

      

    

    
The use of FIDO does not imply that you must use its biometrics
      features.

    

      

        
More trivially, if you loose your hardware, you loose your
          ID. 

      

    

    
If you loose your ID, you should report of its loss. It also
      means that by design, a mechanism has been constructed to recover
      from the situation 

      within a short period of time. Unfortunately, such a property is
      currently missing in FIDO, but it does not mean that it cannot be
      added.

    

    

      

        
And there can also be hacks in hardware. If I find a way to
          import or export the private key from the enclave, the system
          fails.

      

    

    
The whole system does not fail. When someone attempts to export a
      private key from an hardware device in an unlawful way, it takes
      some time and some expertise.

      As soon as the legitimate holder realizes the lost of his
      hardware, he should report the loss. Then after, the discovery of
      private keys stored into the device is no more an issue.

    

      

        
So in the end, I agree it's best to enable as much privacy
          by design as we possibly can, but we need to put that in
          perspective with use cases too and make some tradeoffs. 

          Healthcare in particular is a domain that is concerned with a
          constant balance between privacy and security, and sometimes
          there is no possibility to tick all boxes. 

        
I think an UMA2/OpenId Heart scenario is a very important
          case to consider in that respect. 

        

      

    

    
The goal of this BoF/WG is not to rubber-stamp the "Health
      Relationship Trust Profile for User-Managed Access 2.0"
      specification. 

    
Since the "Health Relationship Trust Profile for User-Managed
      Access 2.0" specification has nothing really specific to
      healthcare, what is the "very important case" you have in mind ?

      Would it be possible to model a specific characteristic you have
      in mind in terms of model components, operations flows, trust
      relationships, privacy requirements and security requirements ?

    

    
Denis

    

    

      

        


        

        
Fabien 

        


        

        


        

        


        

      

      

      

        
On Fri, Jul 3, 2020 at 12:01
          PM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hello Fabien,

            


            

            
In 2017, I made a presentation at the OAuth workshop in
              Zurich.

            


            

            
            


            

            
            
Note: The slides should be viewed "full screen"
              to get the animations. 

            

            


            

            
The general approach is how to construct from scratch a
              "privacy by design" architecture taking also into
              consideration "security by design".

            


            

            
Coming back to your requirement, I would not cover it
              if it infringes the sentence "the RS and the AS never
              communicate directly".

            


            

            
You should start your design by defining the trust
              relationships, then apply the privacy requirements while
              not forgetting the security requirements.

              

            

            
Denis

            


            

            

              
Hello Denis,
                


                

                
I have been following your comments. I still fail
                  to see the global privacy preserving architecture
                  you're proposing. It would help to get a more thorough
                  proposal if you can.

                  


                  

                  
But more specifically, I have a comment on : 

                  


                  

                  

                    
"I would have preferred that you meant: the RS and the AS never 
communicate directly, which is indeed a nice property to follow
to ensure the user's privacy."

                    
I think that may come as an issue in some cases, especially for multiparty patterns (like in UMA). Typically we may wish the RS to start a grant request and use the handle to continue until a token is generated.

                    
I think those cases, which weren't initially covered by OAuth2, are very important to cover as well. How would you cover such requirements?

                    
Fabien

                  

                

              

              

              

            

            


            

          

        

      

    

    


    

  


--------------8BA96BA3E613D4705A7ACD3C--


From nobody Mon Jul  6 04:06:32 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 C704B3A138C for ; Mon,  6 Jul 2020 04:06: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 P7wgdxZGeTmv for ; Mon,  6 Jul 2020 04:06:27 -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 EBFB03A138A for ; Mon,  6 Jul 2020 04:06:26 -0700 (PDT)
Received: by mail-io1-xd32.google.com with SMTP id a12so38872432ion.13 for ; Mon, 06 Jul 2020 04:06: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=fFNZIoSMOESZyhr55vuTA6oSCSJBZ9YS4P5dGQYqCBA=; b=IFs1HHhBV41Jwxe/APOMmFYpDK2MImpfxAnnyrjX6MHoNLFizBJcbgWppai5Fugp96 2/AS9XUng0Q6ecz1iafUrhsgJpGelupAkfT13WCIGDWGFbIfwRweq6f9F2YcP3XZ5myK fscgCucQ4/SThHCpWrDLOp51516r/AqsVRmZEE/y2f6FgwhJPWZ1Yk493ZYo37nCCE+u lkB8/sd6bG/B0co+p+W1/FcERwPMqkQ8dsP+VvwbhjAzTh5piRvhEmtB4ENAPFYRac1O /3QfvpbTY0ZgUd2m4b7j4PddA1TNML/wZ+MWGN2+q2DlfaV6qVYOcVMwod6kNSgJG9ij bQ3A==
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=fFNZIoSMOESZyhr55vuTA6oSCSJBZ9YS4P5dGQYqCBA=; b=PHmZFTCMBvG7LmgOO1mKAEO5g0EwiQsHMIBTnrXUc81Tm3D8rgnBwfdWb4vWZabgL+ RDJHUfH359+SYFhyRwOruuSX4s4ipqFhfVoUbnU1cQpAGBE2iM/krY0Lc53+iiCQI7f5 fxZSn+8qG9AlH+1XRhYDZAqd3o5UIBI6Q+C7NEDgsHMX4u+nkqUWn9wuQKWeZDxUMhwW csYGMBFIwkfRJN/HQtv/wJaPRSGcmMBi+/8i563PexpS+5KQ3JkkpfeQxlAAyANOO2v6 /EOvA9r+lxOYBj4Rw4xrcSCFckDL2SDUyUUDGfVzwb8Fg3tdJn6GuLbF/o6H/t3aX1sc T1oA==
X-Gm-Message-State: AOAM531k0noYUjTvT+O+thynU7ghXdXEHuf2rQL0S43SAZELA2ap7MtW zcTZUZ1wMJV1kRGItfzMfJY8CFMSpcpZHl+Bvao=
X-Google-Smtp-Source: ABdhPJwmqaIlH6rvasdAuxIFFdAKaXeu1DcbrESVydUIYZ7EGgJMwPyLfJn33opFzTX23ZPr7atjr5C8N3PstXlXpjk=
X-Received: by 2002:a05:6638:69d:: with SMTP id i29mr53373019jab.47.1594033585976;  Mon, 06 Jul 2020 04:06:25 -0700 (PDT)
MIME-Version: 1.0
References:    <8a723292-4d04-63c7-e57c-7e7307e145c8@free.fr>
In-Reply-To: <8a723292-4d04-63c7-e57c-7e7307e145c8@free.fr>
From: Fabien Imbault 
Date: Mon, 6 Jul 2020 13:06:13 +0200
Message-ID: 
To: Denis 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a6f8b305a9c3dd8a"
Archived-At: 
Subject: Re: [Txauth] RS/AS communication for multiparty 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: Mon, 06 Jul 2020 11:06:30 -0000

--000000000000a6f8b305a9c3dd8a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

Thanks for your feedback. Your scheme is interesting and covers well the
personal access.

The variant I'm referring to is multiparty access, which is a fairly common
pattern also. Handled as an extension in Oauth2, but to my knowledge it
requires an additional relationship between RS and AS. Maybe we can come up
with an alternative design, I don't know yet.

Cheers.

Fabien


Le lun. 6 juil. 2020 =C3=A0 12:23, Denis  a =C3=A9crit =
:

> Hello Fabien,
>
> Thanks Denis. It clarifies what you have in mind.
>
> While I agree with the general idea that we need to take privacy more
> seriously, there are a few hypotheses that we need to put in perspective =
:
>
> 1) AS-RS relationship <=3D> big brother. It may happen as we all know, bu=
t
> you always have the choice as a user to not deal with orgs you don't like
> or maybe even take action if they don't respect the law.
>
> Unfortunately, the choice you mention is not always possible. There is a
> fundamental point here: since it is not always possible to trust an AS to
> respect the law,
> it is possible to build an architecture where the AS will be unable to
> by-pass the law. It is the difference between :
>
>    - "the AS *should not* do this or that" (but it could if it would) and
>    - "the AS *cannot do* this or that" (it cannot even if it would).
>
> 2) the collusion possibility (Alice's uncle) : there are of course
> situations where that may be an issue. This is I guess the reason for the
> sovrin foundation
> to require that only approved issuers can participate. But even if you
> open up the system, it always ends up as whether you can trust the uncle =
to
> be honest
> in the first place (knowing that trust is a social construct).
>
> When using computers, trust is not a "social construct". It is a
> construction where an entity A trusts an entity B for some behaviour C.
> In the ABC attack, the RS will never know whether someone forwarded or no=
t
> an access token to Alice.
>
> So I may require the issuer to be a well known participant instead.
>
> 3) The use of hardware FIDO inspired components does relax some of the
> previous concern, but comes with its own sets of challenges.
> Biometrics come with their own sets of potential issues.
>
> The use of FIDO does not imply that you must use its biometrics features.
>
> More trivially, if you loose your hardware, you loose your ID.
>
> If you loose your ID, you should report of its loss. It also means that b=
y
> design, a mechanism has been constructed to recover from the situation
> within a short period of time. Unfortunately, such a property is currentl=
y
> missing in FIDO, but it does not mean that it cannot be added.
>
> And there can also be hacks in hardware. If I find a way to import or
> export the private key from the enclave, the system fails.
>
> The whole system does not fail. When someone attempts to export a private
> key from an hardware device in an unlawful way, it takes some time and so=
me
> expertise.
> As soon as the legitimate holder realizes the lost of his hardware, he
> should report the loss. Then after, the discovery of private keys stored
> into the device is no more an issue.
>
> So in the end, I agree it's best to enable as much privacy by design as w=
e
> possibly can, but we need to put that in perspective with use cases too a=
nd
> make some tradeoffs.
> Healthcare in particular is a domain that is concerned with a constant
> balance between privacy and security, and sometimes there is no possibili=
ty
> to tick all boxes.
> I think an UMA2/OpenId Heart scenario is a very important case to conside=
r
> in that respect.
>
> The goal of this BoF/WG is not to rubber-stamp the "Health Relationship
> Trust Profile for User-Managed Access 2.0" specification.
>
> Since the "Health Relationship Trust Profile for User-Managed Access 2.0"
> specification has nothing really specific to healthcare, what is the "ver=
y
> important case" you have in mind ?
> Would it be possible to model a specific characteristic you have in mind
> in terms of model components, operations flows, trust relationships,
> privacy requirements and security requirements ?
>
> Denis
>
>
> Fabien
>
>
>
>
> On Fri, Jul 3, 2020 at 12:01 PM Denis  wrote:
>
>> Hello Fabien,
>>
>> In 2017, I made a presentation at the OAuth workshop in Zurich.
>>
>> The paper is available from:
>> https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design=
-eID-scheme-supporting-Attribute-based-Access-Control.pdf
>>
>> The slides are available from:
>> https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.p=
pt
>> *Note*: The slides should be viewed "full screen" to get the animations.
>>
>> The general approach is how to construct from scratch a "privacy by
>> design" architecture taking also into consideration "security by design"=
.
>>
>> Coming back to your requirement, I would not cover it if it infringes th=
e
>> sentence "the RS and the AS never communicate directly".
>>
>> You should start your design by defining the trust relationships, then
>> apply the privacy requirements while not forgetting the security
>> requirements.
>>
>> Denis
>>
>> Hello Denis,
>>
>> I have been following your comments. I still fail to see the global
>> privacy preserving architecture you're proposing. It would help to get a
>> more thorough proposal if you can.
>>
>> But more specifically, I have a comment on :
>>
>> "I would have preferred that you meant: the RS and the AS never
>> communicate directly, which is indeed a nice property to follow
>> to ensure the user's privacy."
>>
>> I think that may come as an issue in some cases, especially for multipar=
ty patterns (like in UMA). Typically we may wish the RS to start a grant re=
quest and use the handle to continue until a token is generated.
>>
>> I think those cases, which weren't initially covered by OAuth2, are very=
 important to cover as well. How would you cover such requirements?
>>
>> Fabien
>>
>>
>>
>>
>

--000000000000a6f8b305a9c3dd8a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis,

Th=
anks for your feedback. Your scheme is interesting and covers well the pers=
onal access.=C2=A0

The v=
ariant I'm referring to is multiparty access, which is a fairly common =
pattern also. Handled as an extension in Oauth2, but to my knowledge it req=
uires an additional relationship between RS and AS. Maybe we can come up wi=
th an alternative design, I don't know yet.=C2=A0

Cheers.=C2=A0

Fabien=C2=A0

Le lun. 6=
 juil. 2020 =C3=A0 12:23, Denis <d=
enis.ietf@free.fr> a =C3=A9crit=C2=A0:

 =20
   =20
 =20
  

    
Hello Fabien,

    

     =20
      
Thanks Denis. It clarifies what you have in mind.=C2=
=A0
        


        

        
While I agree with the general idea that we need to take
          privacy more seriously, there are a few hypotheses that we
          need to put in perspective : 

          

        

        
1) AS-RS relationship <=3D> big brother. It may happen
          as we all know, but you always have the choice as a user to
          not deal with orgs you don't like 

          or maybe even take action if they don't respect the law.

        

      

    

    
Unfortunately, the choice you mention is not always possible.
      There is a fundamental point here: since it is not always possible
      to trust an AS to respect the law,

      it is possible to build an architecture where the AS will be
      unable to by-pass the law. It is the difference between :

    
    
      
  • "the AS should not do this or that" (but it coul=
d if
        it would) and
    • 
      
  • "the AS cannot do this or that" (it cannot even =
if it
        would).=C2=A0 
    
      
    • 
    

    

      

        
2) the collusion possibility (Alice's uncle) : there are o=
f
          course situations where that may be an issue. This is I guess
          the reason for the sovrin foundation 

          to require that only approved issuers can participate. But
          even if you open up the system, it always ends up as whether
          you can trust the uncle to be honest 

          in the first place (knowing that trust is a social construct).
        

      

    

    
When using computers, trust is not a "social construct". I=
t is a
      construction where an entity A trusts an entity B for some
      behaviour C. 

      In the ABC attack, the RS will never know whether someone
      forwarded or not an access token to Alice.

    

    

      

        
So I may require the issuer to be a well known participant
          instead.

          

          3) The use of hardware FIDO inspired components does relax
          some of the previous concern, but comes with its own sets of
          challenges.

          Biometrics come with their own sets of potential issues. 

      

    

    
The use of FIDO does not imply that you must use its biometrics
      features.

    

      

        
More trivially, if you loose your hardware, you loose your
          ID. 

      

    

    
If you loose your ID, you should report of its loss. It also
      means that by design, a mechanism has been constructed to recover
      from the situation 

      within a short period of time. Unfortunately, such a property is
      currently missing in FIDO, but it does not mean that it cannot be
      added.

    

    

      

        
And there can also be hacks in hardware. If I find a way to
          import or export the private key from the enclave, the system
          fails.

      

    

    
The whole system does not fail. When someone attempts to export a
      private key from an hardware device in an unlawful way, it takes
      some time and some expertise.

      As soon as the legitimate holder realizes the lost of his
      hardware, he should report the loss. Then after, the discovery of
      private keys stored into the device is no more an issue.

    

      

        
So in the end, I agree it's best to enable as much privacy
          by design as we possibly can, but we need to put that in
          perspective with use cases too and make some tradeoffs. 

          Healthcare in particular is a domain that is concerned with a
          constant balance between privacy and security, and sometimes
          there is no possibility to tick all boxes.=C2=A0

        
I think an UMA2/OpenId Heart scenario is a very important
          case to consider in that respect. 

        

      

    

    
The goal of this BoF/WG is not to rubber-stamp the "Health
      Relationship Trust Profile for User-Managed Access 2.0"
      specification. 

    
Since the "Health Relationship Trust Profile for User-Managed
      Access 2.0" specification has nothing really specific to
      healthcare, what is the "very important case" you have in m=
ind ?

      Would it be possible to model a specific characteristic you have
      in mind in terms of model components, operations flows, trust
      relationships, privacy requirements and security requirements ?

    

    
Denis

    

    

      

        


        

        
Fabien=C2=A0

        


        

        


        

        


        

      

      

      

        
On Fri, Jul 3, 2020 at 12:01
          PM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hello Fabien,

            


            

            
In 2017, I made a presentation at the OAuth workshop in
              Zurich.

            


            

            
            


            

            
            
Note: The slides should be viewed "full screen=
"
              to get the animations. 

            

            


            

            
The general approach is how to construct from scratch a
              "privacy by design" architecture taking also into
              consideration "security by design".

            


            

            
Coming back to your requirement, I would not cover it
              if it infringes the sentence "the RS and the AS never
              communicate directly".

            


            

            
You should start your design by defining the trust
              relationships, then apply the privacy requirements while
              not forgetting the security requirements.

              

            

            
Denis

            


            

            

              
Hello Denis,
                


                

                
I have been following your comments. I still fail
                  to see the global privacy preserving architecture
                  you're proposing. It would help to get a more thoroug=
h
                  proposal if you can.

                  


                  

                  
But more specifically, I have a comment on :=C2=A0
                  


                  

                  

                    
"I would have preferred that you meant: the RS and the AS never=
=20
communicate directly, which is indeed a nice property to follow
to ensure the user's privacy."

                    
I think that may come as an issue in some cases, especially for multip=
arty patterns (like in UMA). Typically we may wish the RS to start a grant =
request and use the handle to continue until a token is generated.

                    
I think those cases, which weren't initially covered by OAuth2, ar=
e very important to cover as well. How would you cover such requirements?
                    
Fabien

                  

                

              

              

              

            

            


            

          

        

      

    

    


    

  





--000000000000a6f8b305a9c3dd8a--


From nobody Mon Jul  6 05: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 9C62F3A1441; Mon,  6 Jul 2020 05:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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=cert.org
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 Irj9kxzdmmQ2; Mon,  6 Jul 2020 05:35:38 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 34D703A143F; Mon,  6 Jul 2020 05:35:38 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 066CZaMu032179; Mon, 6 Jul 2020 08:35:36 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 066CZaMu032179
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1594038937; bh=sCbLngrNj1BIkAhLkWN+EC7ObM1Ouhs93LPe1lrpFw4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=mT8FyfUM5OjJRR50Y8TQNKe/kYuLc1+DD12V7yEIXn06/qVfhggsRyi6BlyRL3SeW hAzp/EHloYWL+N9q/iwWbpdZyizUJKb0N5xRtaiLH1dltUGgGjOzoWofH+Bjdz8Ax0 m3n1P2sT6fQUMBbpUAzt0N/zeqpK0OpTTlCiG9To=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 066CZVsb007214; Mon, 6 Jul 2020 08:35:31 -0400
Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 6 Jul 2020 08:35:31 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 6 Jul 2020 08:35:31 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Mon, 6 Jul 2020 08:35:31 -0400
From: Roman Danyliw 
To: Benjamin Kaduk , Justin Richer 
CC: The IESG , "gnap-chairs@ietf.org" , "txauth@ietf.org" 
Thread-Topic: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT)
Thread-Index: AQHWSp+mfNB0WcCRrESVJnDDV24D0KjpTf1ggACtvQCAB910AIAABn+AgAACqQCACKQ44A==
Date: Mon, 6 Jul 2020 12:35:30 +0000
Message-ID: 
References: <159305522436.11733.15198171728373227965@ietfa.amsl.com>  <559FF73B-38D4-4D49-8827-0958613912C0@mit.edu> <20200630193602.GT58278@kduck.mit.edu>  <20200630200848.GU58278@kduck.mit.edu>
In-Reply-To: <20200630200848.GU58278@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.202.182]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT)
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, 06 Jul 2020 12:35:41 -0000

SGkhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gS2Fk
dWsgPGthZHVrQG1pdC5lZHU+DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMzAsIDIwMjAgNDowOSBQ
TQ0KPiBUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1Pg0KPiBDYzogUm9tYW4gRGFu
eWxpdyA8cmRkQGNlcnQub3JnPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBnbmFwLQ0KPiBj
aGFpcnNAaWV0Zi5vcmc7IHR4YXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1R4YXV0aF0g
QmVuamFtaW4gS2FkdWsncyBObyBPYmplY3Rpb24gb24gY2hhcnRlci1pZXRmLWduYXAtMDAtDQo+
IDAxOiAod2l0aCBDT01NRU5UKQ0KPiANCj4gSGkgSnVzdGluLA0KPiANCj4gT24gVHVlLCBKdW4g
MzAsIDIwMjAgYXQgMDM6NTk6MTdQTSAtMDQwMCwgSnVzdGluIFJpY2hlciB3cm90ZToNCj4gPiBI
aSBCZW4sDQo+ID4NCj4gPiA+IE9uIEp1biAzMCwgMjAyMCwgYXQgMzozNiBQTSwgQmVuamFtaW4g
S2FkdWsgPGthZHVrQG1pdC5lZHU+IHdyb3RlOg0KPiA+ID4NCj4gPiA+IEhpIEp1c3RpbiENCj4g
PiA+DQo+ID4gPiBPbiBUaHUsIEp1biAyNSwgMjAyMCBhdCAwMzoyOTozNlBNIC0wNDAwLCBKdXN0
aW4gUmljaGVyIHdyb3RlOg0KPiA+ID4+IEhpIEJlbiwNCj4gPiA+Pg0KPiA+ID4+IFRoYW5rcyBm
b3IgdGhlIHRob3JvdWdoIHJlYWQgdGhyb3VnaCwgYXMgYWx3YXlzLg0KPiA+ID4+DQo+ID4gPj4g
U29tZSBvZiBteSBvd24gdGhvdWdodHMgdGhlIFRPRE8gaXRlbXMgaW5saW5lIGJlbG93Lg0KPiA+
ID4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gVGhpcyBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxv
cCBhIGZpbmUtZ3JhaW5lZCBkZWxlZ2F0aW9uDQo+ID4gPj4+PiBwcm90b2NvbCBmb3IgYXV0aG9y
aXphdGlvbiBhbmQgQVBJIGFjY2VzcywgYXMgd2VsbCBhcyByZXF1ZXN0aW5nDQo+ID4gPj4+PiBh
bmQgcHJvdmlkaW5nIHVzZXIgaWRlbnRpZmllcnMgYW5kIGNsYWltcy4NCj4gPiA+Pj4+DQo+ID4g
Pj4+PiBuaXQ6IHRoaXMgYXBwZWFycyB0byBwYXJzZSBhcyAicHJvdmlkaW5nIHVzZXIgY2xhaW1z
IiwgYW5kIEknbQ0KPiA+ID4+Pj4gbm90IHN1cmUgd2hhdCB0aGF0IG1lYW5zLg0KPiA+ID4+Pg0K
PiA+ID4+PiBUT0RPDQo+ID4gPj4NCj4gPiA+PiBZZXMsIHRoZSBpcyBpbnRlbmRlZCB0byBwYXJz
ZSBhcyDigJxwcm92aWRpbmcgdXNlciBjbGFpbXPigJ0uIFRoZSBpZGVhIGhlcmUgaXMNCj4gdGhh
dCB0aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRvIHNlbmQgY2xhaW1zIHRoYXQgaXQgaGFzIHRv
IHRoZSBBUyB0aGF0IHdpbGwNCj4gaWRlbnRpZnkgdGhlIHVzZXIgaW4gYSBmYXNoaW9uIHRoYXQg
dGhlIEFTIGNhbiB2ZXJpZnkuIEluIHRoZXNlIGNhc2VzLCB0aGUgQVMgY2FuDQo+IG1ha2UgYSBw
b2xpY3kgZGVjaXNpb24gd2l0aG91dCBkaXJlY3RseSBpbnZvbHZpbmcgdGhlIHVzZXIgZm9yIGlu
dGVyYWN0aW9uLiBUaGlzIGlzDQo+IGxhcmdlbHkgYSBnYXAgaW4gdGhlIE9BdXRoIDIgd29ybGQs
IHRob3VnaCB0aGUgUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgZ3JhbnQNCj4gYW5kIHRoZSBBc3Nl
cnRpb25zIGdyYW50IGtpbmQgZ28gaW4gdGhpcyBkaXJlY3Rpb24sIGJ1dCB0aGVyZeKAmXMgYSBk
ZXNpcmUgaW4gdGhlDQo+IGNvbW11bml0eSBmb3IgYSBnZW5lcmFsIG1lY2hhbmlzbSBmb3IgZG9p
bmcgdGhpcy4gVG8gYmUgY2xlYXIsIEdOQVAgaXMgZ29pbmcNCj4gdG8gZGVmZXIgdGhlIGRldGFp
bHMgb2YgdGhlc2Uga2luZHMgb2YgYXNzZXJ0aW9ucyB0byBvdGhlciBzcGVjaWZpY2F0aW9ucywg
bGlrZQ0KPiBXM0PigJlzIFZlcmlmaWFibGUgQ3JlZGVudGlhbHMuDQo+ID4gPg0KPiA+ID4gTGV0
IG1lIHBsYXkgdGhpcyBiYWNrIHRvIGNoZWNrIHRoYXQgSSd2ZSBnb3QgaXQgcmlnaHQ6IHRoZSBp
ZGVhIGlzDQo+ID4gPiB0aGF0IHRoZSBjbGllbnQgbWlnaHQgaGF2ZSBzb21lIGV4aXN0aW5nIGFz
c2VydGlvbiBvciBzb21ldGhpbmcgdGhhdA0KPiA+ID4gaXMgZXZpZGVuY2UgdGhhdCB0aGUgdXNl
ciBoYXMgYWxyZWFkeSBjb25zZW50ZWQgdG8gc29tZXRoaW5nLCBhbmQNCj4gPiA+IHRoZSBwcm90
b2NvbCBpcyBnb2luZyB0byBpbmNsdWRlIGEgd2F5IGZvciB0aGUgY2xpZW50IHRvIGNvbnZleSB0
aGlzDQo+ID4gPiBhcnRpZmFjdCB0byB0aGUgQVMgc28gdGhhdCB0aGUgQVMgY2FuIHZhbGlkYXRl
IGl0IGFuZCBza2lwIGJvdGhlcmluZw0KPiA+ID4gdGhlIHVzZXIgZGlyZWN0bHk/ICBJIHRoaW5r
IHdlJ2QgcHJvYmFibHkgd2FudCBzb21lIGFkZGl0aW9uYWwNCj4gPiA+IGFkamVjdGl2ZSBoZXJl
IHRvIGNsYXJpZnkgKCJ1c2VyLWNvbnNlbnQgY2xhaW1zIiwgInVzZXIgdmVyaWZpY2F0aW9uDQo+
ID4gPiBjbGFpbXMiLCBldGMuKSAtLSBteSBvcmlnaW5hbCBiZXN0LWd1ZXNzIHJlYWRpbmcgd2Fz
IHRoYXQgdGhpcyB3YXMNCj4gPiA+ICJ1c2VyLXN1cHBsaWVkIGNsYWltcyIsIGUuZy4sICJJJ2Qg
bGlrZSBteSB0b2tlbiB0byBpbmNsdWRlIHRoaXMNCj4gPiA+IGFyYml0cmFyeSBjbGFpbSBJIGp1
c3QgbWFkZSB1cCwgcGxlYXNlIi4gIChUaGUgbGF0dGVyJ3MNCj4gPiA+IGludGVybWluZ2xpbmcg
b2YgdXNlci1zdXBwbGllZCBhbmQgdHJ1c3RlZC1zb3VyY2UgZGF0YSBpcyBhIHJlY2lwZQ0KPiA+
ID4gZm9yIHNlY3VyaXR5IGlzc3Vlcywgb2YgY291cnNlLikNCj4gPg0KPiA+IEFoLCBJIHNlZSB0
aGUgY29uZnVzaW9uIG5vdzsgcmlnaHQsIHRoZSBpZGVhIGlzIG5vdCBhYm91dCB0aGUgdXNlciBw
dXR0aW5nDQo+IGNsYWltcyBpbnRvIHNvbWV0aGluZyB0aGF0IHRoZSBBUyBlY2hvZXMgYmFjayB0
byB0aGUgY2xpZW50LiBXZSB3YW50IHRoZSBBUyB0bw0KPiBiZSBhYmxlIHRvIHNlbmQgc3R1ZmYg
YmFjayB0aGF0IGl0IGtub3dzIGFib3V0IHRoZSB1c2VyLCBidXQgdGhlIGNsaWVudCBzaG91bGQg
YmUNCj4gYWJsZSB0byBzZW5kIGl0IHRvIHRoZSBBUyBhcyB3ZWxsLiBGb3Igc3R1ZmYgZnJvbSB0
aGUgY2xpZW50LCB0aGVyZSBhcmUgdHdvDQo+IGNhdGVnb3JpZXMgb2YgaW5mb3JtYXRpb24gcGVv
cGxlIGFyZSBpbnRlcmVzdGVkIGluOiBpZGVudGlmaWVycyB0aGF0IGFyZW7igJl0DQo+IHByb3Zl
biB5ZXQgKHNvIGl04oCZcyBqdXN0IGEgaGludCB0byB0aGUgQVMgYWJvdXQgd2hvIHRoZSBjbGll
bnQgOnRoaW5rczogdGhlIHVzZXIgaXMsDQo+IGxpa2UgYSB1c2VybmFtZSkgYW5kIHByb3ZhYmxl
IGNsYWltIHNldHMgdGhhdCB0aGUgQVMgY2FuIHZlcmlmeSBpbmRlcGVuZGVudGx5DQo+IChhbmQg
dGhlIHByb3RvY29sIGRvZXNu4oCZdCBjYXJlIGhvdyB0aGF0IGdldHMgdmFsaWRhdGVkKS4gTW9z
dCBsaWtlbHkgdGhlc2UgbGF0dGVyDQo+IG9uZXMgd2lsbCBiZSBmb3JtYXR0ZWQgYXMgYXNzZXJ0
aW9ucy4gSSBkaWRu4oCZdCB3YW50IHRoZSBjaGFydGVyIGxhbmd1YWdlIHRvIGxpbWl0DQo+IHRo
ZSBmb3JtYXQsIGJ1dCBJIG1pZ2h0IGJlIG92ZXJ0aGlua2luZyBpdC4gSSB3YW50ZWQgdG8gbWFr
ZSBzdXJlIHRoZSBjaGFydGVyDQo+IGNhcHR1cmVkIHRoZSBpbnRlbnQgb2YgdXNlciBpbmZvcm1h
dGlvbiBub3QgYmVpbmcgYSBvbmUtd2F5IGZsb3cgaW4gdGhlDQo+IHByb3RvY29sLiBIb3cgYWJv
dXQgdGhpczoNCj4gPg0KPiA+IAnigKYgZm9yIGF1dGhvcml6YXRpb24sIEFQSSBhY2Nlc3MsIHVz
ZXIgaWRlbnRpZmllcnMsIGFuZCBpZGVudGl0eSBhc3NlcnRpb25zLg0KPiBUaGUgcHJvdG9jb2wg
d2lsbCBhbHNvIGFsbG93IHRoZSBjbGllbnQgdG8gcHJlc2VudCB1bnZlcmlmaWVkIGlkZW50aWZp
ZXJzIGFuZA0KPiB2ZXJpZmlhYmxlIGFzc2VydGlvbnMgdG8gdGhlIEFTIGFzIHBhcnQgb2YgaXRz
IHJlcXVlc3QuDQo+ID4NCj4gPiBJdOKAmXMgbXVjaCwgbXVjaCBsb25nZXIsIGJ1dCBob3BlZnVs
bHkgaXQgYXZvaWRzIHRoZSBnYXJkZW4gcGF0aCBhbmQgaG9wZWZ1bGx5DQo+IGdldHMgYXQgY2Fw
dHVyaW5nIHRoZSBpbnRlbnQuDQo+IA0KPiBJIHRoaW5rIGl0IGxvb2tzIGdvb2QsIHRoYW5rcy4N
Cg0KQWRkZWQgdG8gLTA1Lg0KDQo+ID4gPg0KPiA+ID4+DQo+ID4gPj4+DQo+ID4gPj4+PiBUaGUg
cHJvdG9jb2wgd2lsbCBkZWNvdXBsZSB0aGUgaW50ZXJhY3Rpb24gY2hhbm5lbHMsIHN1Y2ggYXMg
dGhlDQo+ID4gPj4+PiBlbmQgdXNlcuKAmXMgYnJvd3NlciBbLi4uXQ0KPiA+ID4+Pj4NCj4gPiA+
Pj4+ICJpbnRlcmFjdGlvbiBjaGFubmVscyIgbWlnaHQgYmUgYSB0ZXJtIG9mIGFydCB0aGF0IG5l
ZWRzIGNsYXJpZmljYXRpb24/DQo+ID4gPj4+DQo+ID4gPj4+IFRPRE8NCj4gPiA+Pg0KPiA+ID4+
IEkgZG9u4oCZdCB0aGluayBpdOKAmXMgYSBzcGVjaWZpYyB0ZXJtIG9mIGFydC4gSSB0aGluayB3
ZSByZWFsbHkgbWVhbnQg4oCcZGlmZmVyZW50DQo+IHdheXMgdG8gaW50ZXJhY3Qgd2l0aCB0aGUg
dXNlcuKAnS4gT25lIG9mIE9BdXRoIDLigJlzIGxpbWl0YXRpb25zIGlzIHRoYXQgaXQsIGZvciB0
aGUNCj4gbW9zdCBwYXJ0LCBhc3N1bWVzIHRoZSB1c2Vy4oCZcyBpbiBhIGJyb3dzZXIsIGFuZCB0
aGUgY29yZSBvZiB0aGUgcHJvdG9jb2wgaXMgYnVpbHQNCj4gYXJvdW5kIHRoYXQuIE9uZSBvZiB0
aGUgZ29hbHMgb2YgR05BUCBpcyB0byBnZXQgYXdheSBmcm9tIHRoYXQgYXMgYSBiYXNlDQo+IGFz
c3VtcHRpb24uDQo+ID4gPg0KPiA+ID4gUGVyaGFwcyAiZGVjb3VwbGUgdGhlIGNoYW5uZWxzIGJ5
IHdoaWNoIHRoZSBwcm90b2NvbCBwYXJ0aWNpcGFudHMNCj4gPiA+IGNvbW11bmljYXRlIj8NCj4g
Pg0KPiA+IFRoYXQgY2FuIHdvcmsuDQoNCkl0J3MgYSBsaXR0bGUgd29yZHksIGJ1dCBhZGRlZCB0
byAtMDUuDQoNCj4gPiA+DQo+ID4gPj4+DQo+ID4gPj4+PiBUaGUgY2xpZW50IGFuZCBBdXRob3Jp
emF0aW9uIFNlcnZlciAoQVMpIHdpbGwgaW52b2x2ZSBhIHVzZXIgdG8NCj4gPiA+Pj4+IG1ha2Ug
YW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbiBhcyBuZWNlc3NhcnkgdGhyb3VnaCBpbnRlcmFjdGlv
bg0KPiA+ID4+Pj4gbWVjaGFuaXNtcyBpbmRpY2F0ZWQgYnkgdGhlIHByb3RvY29sLg0KPiA+ID4+
Pj4NCj4gPiA+Pj4+PiBGcm9tIGEgcHJpdmFjeSBwZXJzcGVjdGl2ZSwgd2lsbCBhbGwgb2YgdGhl
IGluZm9ybWF0aW9uIHRvIGJlDQo+ID4gPj4+Pj4gbWFkZQ0KPiA+ID4+Pj4gYXZhaWxhYmxlIGZy
b20gdGhlIEFTIHRvIHRoZSBSUyBiZSB2aXNpYmxlIHRvIHRoZSB1c2VyIGFzIHRoZXkNCj4gPiA+
Pj4+IG1ha2UgdGhpcyBhdXRob3JpemF0aW9uIGRlY2lzaW9uPw0KPiA+ID4+Pg0KPiA+ID4+PiBU
T0RPDQo+ID4gPj4NCj4gPiA+PiBVbHRpbWF0ZWx5IEkgZG9u4oCZdCB0aGluayB3ZSBjYW4gZnVs
bHkgc3BlY2lmeSB0aGUgQVMgYmVoYXZpb3IgaGVyZSwgYnV0IHRoaXMNCj4gaXMgYSBnb29kIHBp
bGxhciBmb3IgcHJpdmFjeSBjb25zaWRlcmF0aW9ucy4NCg0KTm8gYWN0aW9uIHRha2VuIGhlcmUu
DQoNCj4gPiA+Pg0KPiA+ID4+Pg0KPiA+ID4+Pj4gVGhlIGdyb3VwIHdpbGwgZGVmaW5lIGludGVy
b3BlcmFiaWxpdHkgZm9yIHRoaXMgcHJvdG9jb2wgYmV0d2Vlbg0KPiA+ID4+Pj4gZGlmZmVyZW50
IHBhcnRpZXMsIGluY2x1ZGluZw0KPiA+ID4+Pj4gIC0gY2xpZW50IGFuZCBhdXRob3JpemF0aW9u
IHNlcnZlcjsNCj4gPiA+Pj4+ICAtIGNsaWVudCBhbmQgcmVzb3VyY2Ugc2VydmVyOyBhbmQNCj4g
PiA+Pj4+ICAtIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIuDQo+ID4g
Pj4+Pg0KPiA+ID4+Pj4gW29ibGlnYXRvcnkgbm90ZSB0aGF0IGp1c3QgYmVjYXVzZSB3ZSBkZWZp
bmUgYW4gQVMvUlMgY2hhbm5lbA0KPiA+ID4+Pj4gZG9lc24ndCBtZWFuIGl0IHdpbGwgYmUgcmVx
dWlyZWQgdG8gdXNlIG9uZSBhdCBydW50aW1lLCBnaXZlbiB0aGUNCj4gPiA+Pj4+IHBvdGVudGlh
bCBmb3Igc2VsZi1jb250YWluZWQgdG9rZW5zP10NCj4gPiA+Pj4NCj4gPiA+Pj4gQXJlIHlvdSB0
aGlua2luZyB0aGF0IGNsYXJpZmljYXRpb24gd291bGQgYmUgZXhwbGljaXRseSBzdGF0ZWQ/DQoN
Ck5vIGFjdGlvbiB0YWtlbiBoZXJlLg0KDQo+ID4gPj4gTm90ZSB0aGF0IGEgc2VsZi1jb250YWlu
ZWQgdG9rZW4gaXMgb25lIG9mIHRoZSBjb21tdW5pY2F0aW9uIGNoYW5uZWxzDQo+IHRoYXQgdGhl
IGdyb3VwIGhhZCBpbiBtaW5kIGZvciBBUy9SUy4gV2UgdHJpZWQgdG8gd3JpdGUgdGhlIHJlcXVp
cmVtZW50cyBpbg0KPiBzdWNoIGEgd2F5IGFzIHRvIGFsbG93IGZvciBzZWxmLWNvbnRhaW5lZCBt
ZXNzYWdlcywgc2VydmljZS1iYXNlZCBzdHVmZiAobGlrZQ0KPiBpbnRyb3NwZWN0aW9uKSwgb3Ig
ZXZlbiBhbGwtaW4tb25lLWJveCBzb2x1dGlvbnMgdGhhdCBkb27igJl0IG5lZWQNCj4g4oCcY29t
bXVuaWNhdGlvbuKAnSBhcGFydCBmcm9tIGJvdGggcmVhZGluZyB0aGUgc2FtZSBkYXRhYmFzZS4g
VGhpcyBpcyBhbg0KPiBhcmNoaXRlY3R1cmFsIHBpbGxhciBib3Jyb3dlZCBmcm9tIE9BdXRoIDIu
DQo+ID4gPj4NCj4gPiA+Pj4NCj4gPiA+Pj4+IC0gU3VwcG9ydCBmb3IgZGlyZWN0ZWQsIGF1ZGll
bmNlLXJlc3RyaWN0ZWQgYWNjZXNzIHRva2Vucw0KPiA+ID4+Pj4NCj4gPiA+Pj4+IEkgdGhpbmsg
d2UgbmVlZCB0byBjbGFyaWZ5IHdoYXQgImRpcmVjdGVkIiBpcyBpbnRlbmRlZCB0byBtZWFuDQo+
ID4gPj4+PiBoZXJlIChpZiBpdCdzIG5vdCBqdXN0IGEgc3lub255bSBmb3IgImF1ZGllbmNlLXJl
c3RyaWN0ZWQiIGluDQo+ID4gPj4+PiB3aGljaCBjYXNlIGl0IHNob3VsZCBqdXN0IGJlIHJlbW92
ZWQpLg0KPiA+ID4+Pg0KPiA+ID4+PiBUT0RPDQo+ID4gPj4NCj4gPiA+PiBUaGlzIG9uZSBpcyBt
eSBmYXVsdCDigJQgdGhlIGNvbmNlcHQgd2XigJlyZSB0YWxraW5nIGFib3V0IGhlcmUgaXMgb25l
IHdoZXJlDQo+IHRoZSBBUyBjYW4gZWZmZWN0aXZlbHkgdGVsbCB0aGUgY2xpZW50IHdoZXJlIGFu
ZCBob3cgaXQgc2hvdWxkIHVzZSB0aGUgdG9rZW4uDQo+IFRoZXJlIGFyZSBhIGNvdXBsZSBkaWZm
ZXJlbnQgV0cgcGFydGljaXBhbnRzIHdobyBoYXZlIGV4cHJlc3NlZCBleHBsaWNpdA0KPiBpbnRl
cmVzdCBpbiB0aGlzLCBhbmQgSeKAmXZlIHN0YXJ0ZWQgYSB0aHJlYWQgb24gdGhhdCB0b3BpYyBy
ZWNlbnRseToNCj4gPiA+Pg0KPiA+ID4+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj
aC9tc2cvdHhhdXRoL2VQMTYyUDIzNU9VMF9Ka3NZNTE1RmcNCj4gPiA+PiBtSEZqMC8NCj4gPiA+
DQo+ID4gPiBJIHRoaW5rIEkgcmVhZCB0aGF0IG9uZSA6KQ0KPiA+ID4NCj4gPiA+IFdvdWxkICJB
Uy1kaXJlY3RlZCBkaXNwYXRjaCB0byB0aGUgYXBwcm9wcmlhdGUgUlMiIChvciBzaW1pbGFyKSBi
ZSBhDQo+ID4gPiB1c2VmdWwgd2F5IHRvIGRlc2NyaWJlIHRoaXM/DQo+ID4NCj4gPiBJIHRoaW5r
IHRoYXQgd29ya3MsIGFzIGl04oCZcyBiYXNpY2FsbHkgYWJvdXQgdGhlIEFTIHRlbGxpbmcgdGhl
IGNsaWVudCB3aGF0IHRvIGRvDQo+IG5leHQuDQoNCkFkZGVkIHRvIC0wNS4NCg0KPiA+ID4NCj4g
PiA+Pj4NCj4gPiA+Pj4+IC0gQSB2YXJpZXR5IG9mIGNsaWVudCBhcHBsaWNhdGlvbnMsIGluY2x1
ZGluZyBXZWIsIG1vYmlsZSwNCj4gPiA+Pj4+ICAgc2luZ2xlLXBhZ2UsIGFuZCBpbnRlcmFjdGlv
bi1jb25zdHJhaW5lZCBhcHBsaWNhdGlvbnMNCj4gPiA+Pj4+DQo+ID4gPj4+PiBzaWRlIG5vdGU6
IHRoaXMgb25lIGZlZWxzIGxpa2UgaXQgd291bGQgYmUgZWFzaWVyIHRvIHBocmFzZSBhcw0KPiA+
ID4+Pj4gInRoZSBXRyB3aWxsIHNlZWsgdG8gbWluaW1pemUgYXNzdW1wdGlvbnMgYWJvdXQgdGhl
IGZvcm0gb2YNCj4gPiA+Pj4+IGNsaWVudCBhcHBsaWNhdGlvbnMsIGFsbG93aW5nIGZvciBbLi4u
XSINCj4gPiA+Pj4NCj4gPiA+Pj4gVE9ETw0KPiA+ID4+DQo+ID4gPj4gVGhhdCBzZWVtcyByZWFz
b25hYmxlIHRvIG1lLCBhbmQgaXQgZ29lcyBoYW5kLWluLWhhbmQgd2l0aCB0aGUgY2hhbmdlcw0K
PiB0byBpbnRlcmFjdGlvbiBtZW50aW9uZWQgYWJvdmUuDQoNCldhcyBmaXhlZCBpbiAtMDQuDQoN
Cj4gPiA+Pj4+IEFkZGl0aW9uYWxseSwgdGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNoYW5pc21z
IGZvciBtYW5hZ2VtZW50IG9mDQo+ID4gPj4+PiB0aGUgcHJvdG9jb2wgbGlmZWN5Y2xlIGluY2x1
ZGluZzoNCj4gPiA+Pj4+IFsuLi5dDQo+ID4gPj4+PiAtIE1lY2hhbmlzbXMgZm9yIHRoZSBBUyBh
bmQgUlMgdG8gY29tbXVuaWNhdGUgdGhlIGFjY2VzcyBncmFudGVkIGJ5DQo+IGFuDQo+ID4gPj4+
PiAgIGFjY2VzcyB0b2tlbg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IE1heWJlIEknbSBqdXN0IGNvbmZ1
c2VkLCBidXQgaXNuJ3QgInRoZSBhY2Nlc3MgZ3JhbnRlZCBieSBhbiBhY2Nlc3MNCj4gdG9rZW4i
DQo+ID4gPj4+PiBleGFjdGx5IHRoZSBzZXQgb2YgYXV0aG9yaXphdGlvbnMgY29udmV5ZWQgYnkg
dGhhdCB0b2tlbiwgaS5lLiwNCj4gPiA+Pj4+IHRoZSBjb3JlIHBvaW50IG9mIHRoZSBwcm90b2Nv
bD8gIEknbSBub3Qgc3VyZSB3aGF0IGtpbmQgInByb3RvY29sDQo+ID4gPj4+PiBsaWZlY3ljbGUg
bWFuYWdlbWVudCIgdGhpcyBpdGVtIGlzIGludGVuZGluZyB0byBpbmRpY2F0ZS4NCj4gPiA+Pj4N
Cj4gPiA+Pj4gVE9ETw0KPiA+ID4+DQo+ID4gPj4gVGhpcyB0aWVzIGludG8gd2hhdOKAmXMgYWJv
dmU6IHRoZSBpZGVhIGlzIHRvIGhhdmUgYSBzdGFuZGFyZCBtb2RlbCBmb3Igd2hhdA0KPiBhbiBh
Y2Nlc3MgdG9rZW4gcmVwcmVzZW50cywgYW5kIHRoaXMgc2F5cyB3ZeKAmXJlIGdvaW5nIHRvIHN0
YW5kYXJkaXplIHdheXMgZm9yDQo+IHRoZSBBUyBhbmQgUlMgdG8gY29tbXVuaWNhdGUgdGhhdC4g
VGhpcyBjb3VsZCBiZSBpbnNpZGUgdGhlIHRva2VuLCB0aHJvdWdoIGFuDQo+IGludHJvc3BlY3Rp
b24gc3R5bGUgc2VydmljZSwgb3Igc29tZSBvdGhlciB0aGluZyB3ZSBoYXZlbuKAmXQgZmlndXJl
ZCBvdXQgeWV0LiBCdXQNCj4gdGhlIHRoaW5nIGlzLCBhbGwgb2YgdGhlc2UgbWVjaGFuaXNtcyBz
aG91bGQgYmUgY29tbXVuaWNhdGluZyB0aGUgc2FtZSBzZXQgb2YNCj4gaW5mb3JtYXRpb24uIFRo
aXMgaXMgc29tZXRoaW5nIHRoZSBPQXV0aCBXRyBkaWRu4oCZdCBhZGRyZXNzLCBhbmQgc28gd2Ug
ZW5kZWQNCj4gdXAgd2l0aCBzb21lIGRpc3Bhcml0eSBpbiB0aGUgaGFuZGZ1bCBvZiBkZS1mYWN0
byBhY2Nlc3MgdG9rZW4gZGF0YSBtb2RlbHMNCj4gdGhlcmUuIFRoZSBnb2FsIHdhcyB0byBhdm9p
ZCB0aGF0Lg0KPiA+ID4NCj4gPiA+IEFoLCBva2F5LiAgU28gaXMgdGhlIGtleSBwb2ludCB0aGF0
IHRoZXNlIG1lY2hhbmlzbXMvZGF0YS1tb2RlbHMgYXJlDQo+ID4gPiAiY29uc2lzdGVudCBhY3Jv
c3MgdGhlIGVudGlyZSBzZXQgb2YgcHJvdG9jb2wgZmxvd3MiPw0KPiA+ID4NCj4gPg0KPiA+IFll
cywgZXhhY3RseS4gV2Ugd2FudCB0aGUgZGlmZmVyZW50IHBpZWNlcyB0byBoYXZlIGEgY29uc2lz
dGVudCBtb2RlbCwNCj4gd2l0aG91dCB0dXJuaW5nIHRoZSBzcGVjIGludG8gYW4g4oCcYWJzdHJh
Y3QgZGF0YSBtb2RlbOKAnSBzcGVjIGl0c2VsZiAoYmVjYXVzZSB3ZQ0KPiB3YW50IGl0IHRvIGJl
IGEgY29uY3JldGUgcHJvdG9jb2wpLiBTbyBob3cgYWJvdXQ6DQo+ID4NCj4gPiAJLSBEYXRhIG1v
ZGVsIGZvciBncmFudGVkIGFjY2VzcyBhbmQgbWVjaGFuaXNtcyBmb3IgdGhlIEFTIGFuZCBSUyB0
bw0KPiBjb21tdW5pY2F0ZSB0aGUgZ3JhbnRlZCBhY2Nlc3MgbW9kZWwuDQo+IA0KPiBXb3JrcyBm
b3IgbWUuDQoNCkFkZGVkIHRvIC0wNS4NCg0KPiBUaGFua3MgYWdhaW4hDQo+IA0KPiAtQmVuDQo=


From nobody Mon Jul  6 05:39:43 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 097643A1442 for ; Mon,  6 Jul 2020 05:39:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.378
X-Spam-Level: 
X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.999] 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 nRNyBRuCen7o for ; Mon,  6 Jul 2020 05:39:41 -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 963EC3A1441 for ; Mon,  6 Jul 2020 05:39:40 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d61 with ME id zofa2200K4FMSmm03ofbhL; Mon, 06 Jul 2020 14:39:36 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 06 Jul 2020 14:39:36 +0200
X-ME-IP: 86.238.65.197
To: "txauth@ietf.org" 
From: Denis 
Message-ID: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>
Date: Mon, 6 Jul 2020 14:39: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
Content-Type: multipart/alternative; boundary="------------2BA9BA9FCD5AF2F8AA686FAE"
Content-Language: en-GB
Archived-At: 
Subject: [Txauth] Support of FIDO and data minimization by RSs
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, 06 Jul 2020 12:39:43 -0000

This is a multi-part message in MIME format.
--------------2BA9BA9FCD5AF2F8AA686FAE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

**This is a new thread: a proposal for a RS authorization algorithmand a 
way to support FIDO by RSs

In order to support the privacy principle of "data minimization" by RSs, 
only the attributes that are strictly necessary to perform
an operation requested by a client should be requested by the RS.

When a client wants to authenticate, it will usually be informed by the 
RS on how to do it (see more details about two exceptions at the end of 
this email).
Which conditions are needed to perform other operations will only be 
disclosed to authenticated users at the time they are willing to perform 
an operation.

Two categories of operations will be considered: authentication 
operations and other operations.

For the "authentication" operation, two cases will be supported:

-FIDO U2F or

-one or more attributes from one or more ASs.

In the second case, an access will be granted by a RS based on an 
mathematical expression which is formed using some combination of ANDand 
ORconditions.

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 /a Condition /:

/Condition x/= { AS identifier + set of attributes types + optional 
scope identifier }

The presence of the /optional/ scope identifier allows to provide a 
backward compatibility with ASs from the OAuth 2.0. world:
the optional scope identifier is only present when a bilateral 
relationship has been established between a RS and an AS prior
to any access (/and will continue to be maintained/) using 
"out-of-bands" means.

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.

An example is used to explain the concepts.

"Operation(s)/ Mathematical expression" pairs managed by the RO of a RS.

*Operation*

	

*Mathematical expression*

Authentication

	

/Condition 1/OR/Condition 2/

Operation A OROperation Z

	

/Condition 3/AND/Condition 4/

Conditions table:

Condition 1

	

FIDO U2F 1.2

	

-

	

-

Condition 2

	

AS 1

	

set 1 of attributes types

	

Condition 3

	

AS 4

	

set 2 of attributes types

	

scope identifier : 21

Condition 4

	

AS 9

	

set 3 of attributes types

	

-

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 
the set of attributes types which are indicated for a given AS
are appropriate to him or not and then select that AS if it has a 
relationship with it.

In this example, one mathematical expression for the combination of 
conditions using AND and OR operators is "/Condition 3/OR/Condition 4",//
which means that///some types of attributes from AS 4 AND some other 
types of attributes from AS 9 are both needed by RSx to perform on RSx
either the Operation A or the Operation Z.

In this example, RS 1 and AS 4 have established a bilateral relationship 
(and have agreed to define and use scope identifiers)
whereas RS 1 and AS 9 have not established any bilateral relationship 
prior to the exchange.

The user makes up his mind whether the attributes requested by AS 1 and 
AS 9 are reasonable and if so, requests two access tokens:
one to AS 4 and another one to AS 9.

For AS 4, the client shall use the scope identifier with the value 21.
For AS 9, the client shall use the set 3 of attributes types indicated 
in the Condition 4.

In order to save one exchange, a RS could publicly publish how its 
clients can authenticate.
However,  it is also possible to consider no guidance at all: in such a 
case, using "out-of-bands" means, the clients should know how to 
authenticate.

Denis


--------------2BA9BA9FCD5AF2F8AA686FAE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
 This is a new thread: a proposal for a RS
        authorization algorithm and a way to support FIDO by RSs

      

    
In order to support the privacy principle of
        "data
        minimization" by RSs, only the attributes that are strictly
        necessary to
        perform 

        an operation requested by a client should be requested by the
        RS.

    
When a client wants to authenticate, it will
        usually be informed by the
        RS on how to do it (see more details about two exceptions at the
        end of this email).
        

        Which conditions are needed to perform other operations will
        only be disclosed
        to authenticated users at the time they are willing to perform
        an operation.

    
Two categories of operations will be
        considered: authentication
        operations and other operations.

      

    
 For the "authentication" operation,
        two cases will be supported: 

    
-         
        FIDO U2F or
      

    
-         
        one or more attributes from one or more ASs.
      

    
In the second case, 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 a
          Condition :

    
Condition
          x = { AS identifier
        + set of attributes types + optional scope identifier } 

      

    
The presence of the optional scope
        identifier allows to provide
        a backward compatibility with ASs from the OAuth 2.0. world: 

        the optional scope
        identifier is only present when a bilateral relationship has
        been established
        between a RS and an AS prior 

        to any access (and will continue to be maintained)
        using "out-of-bands" means. 

      

    
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.

    
An example is used to explain the concepts.

    
"Operation(s)/ Mathematical expression"
        pairs
        managed by the RO of a RS. 

      

    

      
        

          
            
Operation

          		
          
            
Mathematical expression

          		
        

        

          
            
Authentication

          		
          
            
Condition 1 OR Condition 2

          		
        

        

          
            
Operation A OR Operation
                Z

          		
          
            
Condition 3 AND Condition 4

          		
        

      
    

    
Conditions
        table: 

    

      
        

          
            
Condition 1

          		
          
            
FIDO
                U2F 1.2

          		
          
            
-

          		
          
            
-

          		
        

        

          
            
Condition 2

          		
          
            
AS 1

          		
          
            
set 1 of attributes types

          		
          
            
 

          		
        

        

          
            
Condition 3

          		
          
            
AS 4

          		
          
            
set 2 of attributes types

          		
          
            
scope identifier : 21

          		
        

        

          
            
Condition 4

          		
          
            
AS 9

          		
          
            
set 3 of attributes types

          		
          
            
-

          		
        

      
    

    
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
        the set of attributes types which are indicated
        for a given AS 

        are
        appropriate to him or not and then select that AS if it has a
        relationship with it.

    
In this example, one mathematical expression
        for the combination of
        conditions using AND and OR operators is "Condition
            3 OR Condition 4", 

            which means that some types of
        attributes from AS 4 AND some
        other types of
        attributes from AS 9 are both needed by RSx to perform on RSx 

        either the Operation A or the Operation Z. 

    
In this example, RS 1 and AS 4 have
        established a bilateral relationship
        (and have agreed to define and use scope identifiers) 

        whereas RS 1 and AS 9 have not
        established any bilateral relationship prior to the exchange. 

      

    
The user makes up his mind whether the
        attributes requested by AS 1 and
        AS 9 are reasonable and if so, requests two access tokens: 

        one to AS 4 and
        another one to AS 9.

    
For AS 4, the client shall use the
        scope identifier with the value 21.

        For AS 9, the client shall use the set 3 of attributes types
        indicated in
        the Condition 4.

    
In order to save one exchange, a RS could
        publicly publish how its
        clients can authenticate. 

        However,  it is
        also possible to consider no guidance at all: in such a case,
        using
        "out-of-bands" means, the clients should know how to
        authenticate.

    
Denis 

      

    

  


--------------2BA9BA9FCD5AF2F8AA686FAE--


From nobody Mon Jul  6 05:45: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 156EC3A144B; Mon,  6 Jul 2020 05:45:14 -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_FILL_THIS_FORM_SHORT=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=cert.org
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 C1SG1KaG0ZFM; Mon,  6 Jul 2020 05:45:11 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 CBCC93A1448; Mon,  6 Jul 2020 05:45:10 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 066Cj8Og001069; Mon, 6 Jul 2020 08:45:08 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 066Cj8Og001069
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1594039509; bh=OZGI4c3Rr5eZFd8rmde0AJ1u2rgz5pfb8p73tUHZlFU=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=KYFTmpEgAELBrBiqtbfFL8ZEPwcC7iOAdZmpWu0s3W+O2pssYoOwBm7QuZDXiH96m O9pPg4WOpyVUp7OwCHi1QBK2z5Ti3yeUzQ7YeruJdrGa75CKjg85EaSL/jcMCJWpvS 73mgzqa6KqG2Xmmbs/YosNF+YvjecjZOgfWYpj3I=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 066Cj3oG009182; Mon, 6 Jul 2020 08:45:04 -0400
Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 6 Jul 2020 08:45:03 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 6 Jul 2020 08:45:03 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Mon, 6 Jul 2020 08:45:03 -0400
From: Roman Danyliw 
To: Tom Jones , Justin Richer 
CC: Dick Hardt , The IESG , "txauth@ietf.org" 
Thread-Topic: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
Thread-Index: AQHWS9RNiDy30JPhzE2lVpUcI/9MaqjrZ9iAgAA94QCAABKeAIAO1kag
Date: Mon, 6 Jul 2020 12:45:03 +0000
Message-ID: 
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com>  <830A4653-5912-46DE-8173-BA149899FDD3@mit.edu> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.202.182]
Content-Type: multipart/related; boundary="_004_e1a8197a96a24e229ed1ec956394337acertorg_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 06 Jul 2020 12:45:14 -0000

--_004_e1a8197a96a24e229ed1ec956394337acertorg_
Content-Type: multipart/alternative;
 boundary="_000_e1a8197a96a24e229ed1ec956394337acertorg_"

--_000_e1a8197a96a24e229ed1ec956394337acertorg_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkhDQoNClRoZSBtaWxlc3RvbmVzIGJlbG93IHRoZSBjaGFydGVyIHRleHQgbm93IHJlZmxlY3Qg
dGhlIHByb3Bvc2VkIHNpbXBsaWZpY2F0aW9uIGRlc2NyaWJlZCBiZWxvdyAoYnkgRGljaykuDQoN
ClJlZ2FyZHMsDQpSb21hbg0KDQpGcm9tOiBpZXNnIDxpZXNnLWJvdW5jZXNAaWV0Zi5vcmc+IE9u
IEJlaGFsZiBPZiBUb20gSm9uZXMNClNlbnQ6IEZyaWRheSwgSnVuZSAyNiwgMjAyMCA2OjEwIFBN
DQpUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1Pg0KQ2M6IERpY2sgSGFyZHQgPGRp
Y2suaGFyZHRAZ21haWwuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyB0eGF1dGhAaWV0
Zi5vcmcNClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBXRyBSZXZpZXc6IEdyYW50IE5lZ290aWF0aW9u
IGFuZCBBdXRob3JpemF0aW9uIFByb3RvY29sIChnbmFwKQ0KDQpSaWdodCAtIEkgaGF2ZSBhbHJl
YWR5IHByb3Bvc2VkIGJpbmRpbmcgdG8gYXBwbGljYXRpb24gbGV2ZWwga2V5cyBpbiBvdGhlciB2
ZW51ZXMgYW5kIHN0cm9uZ2x5IG9wcG9zZSBjb250aW51ZWQgdXNlIG9mIGNoYW5uZWwgYmluZGlu
Zy4NClBlYWNlIC4udG9tDQoNCg0KT24gRnJpLCBKdW4gMjYsIDIwMjAgYXQgMjowMyBQTSBKdXN0
aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3Rl
Og0KSSBhZ3JlZSB3aXRoIHRoaXMgcHJvcG9zZWQgY2hhbmdlIGluIHdvcmRpbmcgZm9yIHRoZSBt
aWxlc3RvbmVzLiBXZSBkb27igJl0IHdhbnQgdG8gYXJ0aWZpY2lhbGx5IGxpbWl0IHRoZSBrZXkg
YmluZGluZyBwcmVzZW50YXRpb24gbWVjaGFuaXNtcy4gV2hpbGUgSSB0aGluayB0aGUgdGhyZWUg
bGlzdGVkIGFyZSBsaWtlbHkgdG8gYmUgYW1vbmcgdGhlIGZpcnN0IG9uZXMgd2Ugc2VlIChiYXNl
ZCBvbiBwcmlvciBhcnQgYW5kIGN1cnJlbnQgY29tbXVuaXR5IGludGVyZXN0KSwgSSBkb27igJl0
IHRoaW5rIHdlIGNhbiBwcmVkaWN0IGVudGlyZWx5IHdoYXQgd2lsbCBiZSBkZXZlbG9wZWQgYnkg
dGhlIGdyb3VwIGFuZCB3aGVuLg0KDQog4oCUIEp1c3Rpbg0KDQoNCk9uIEp1biAyNiwgMjAyMCwg
YXQgMToyMSBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2su
aGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KSSBhbSBjb25jZXJuZWQgd2l0aCB0aGUgZm9s
bG93aW5nIG1pbGVzdG9uZXM6DQoNCg0KICBPY3QgMjAyMSAtIEtleSBwcmVzZW50YXRpb24gbWVj
aGFuaXNtIGJpbmRpbmcgdG8gdGhlIGNvcmUgcHJvdG9jb2wsIFRMUywgdG8NCiAgV0dMQw0KDQog
IE9jdCAyMDIxIC0gS2V5IHByZXNlbnRhdGlvbiBtZWNoYW5pc20gYmluZGluZyB0byB0aGUgY29y
ZSBwcm90b2NvbCwNCiAgZGV0YWNoZWQgSFRUUCBzaWduYXR1cmVzLCB0byBXR0xDDQoNCiAgT2N0
IDIwMjEgLSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBiaW5kaW5nIHRvIHRoZSBjb3JlIHBy
b3RvY29sLA0KICBlbWJlZGRlZCBIVFRQIHNpZ25hdHVyZSwgdG8gV0dMQw0KDQpJIHRoaW5rIGl0
IGlzIG92ZXJseSBwcmVzY3JpcHRpdmUgdG8gc3BlY2lmeSB3aGljaCBrZXkgcHJlc2VudGF0aW9u
IG1lY2hhbmlzbXMgd2lsbCBiZSBjcmVhdGVkLCBhbmQgaXQgaW1wbGllcyB0aGF0IG90aGVyIGtl
eSBwcmVzZW50YXRpb24gbWVjaGFuaXNtcyB3aWxsIG5vdCBiZSB3b3JrZWQgb24uIFdoaWxlIGl0
IGlzIHBvc3NpYmxlIHRoYXQgY2hhbm5lbCBiaW5kaW5nIG1lY2hhbmlzbXMgc3VjaCBhcyBUTFMs
IGRldGFjaGVkIEhUVFAgc2lnbmF0dXJlcywgYW5kIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlcyB3
aWxsIGJlIGFwcHJvcHJpYXRlIGtleSBwcmVzZW50YXRpb24gbWVjaGFuaXNtcyBmb3IgR05BUCwg
aXQgaXMgYWxzbyBxdWl0ZSBwb3NzaWJsZSB0aGF0IHRoZSBXRyB3aWxsIGRldGVybWluZSBvbmUg
b3IgbW9yZSBhcmUgbm90IGFwcHJvcHJpYXRlLCBvciB0aGUgdW5kZXJseWluZyBtZWNoYW5pc20g
bWF5IG5vdCBnYWluIGFjY2VwdGFuY2UsIG9yIGNoYW5uZWwgYmluZGluZyBpcyBub3QgYWx3YXlz
IG5lZWRlZC4gRm9yIGV4YW1wbGUsIHRoZSBlZmZvcnQgdG8gYmluZCBPQXV0aCBhY2Nlc3MgdG9r
ZW5zIHVzaW5nIFJGQzg0NzEgd2FzIGRpc2JhbmRlZC4NCg0KQWRkaXRpb25hbGx5LCB0aGVyZSBh
cmUgdHdvIHByaW1hcnkgY29tbXVuaWNhdGlvbiBjaGFubmVscyBpbiB0aGUgcHJvdG9jb2wgdGhh
dCBoYXZlIGRpZmZlcmVudCBzZWN1cml0eSByZXF1aXJlbWVudHMuIFRoZSBjbGllbnQgdG8gYXV0
aG9yaXphdGlvbiBzZXJ2ZXIsIGFuZCB0aGUgY2xpZW50IHRvIHJlc291cmNlIHNlcnZlci4gVGhl
IHRlcm0gImNvcmUgcHJvdG9jb2wiIGlzIHZhZ3VlIGFuZCBjb3VsZCBiZSBjb25zdHJ1ZWQgdGhh
dCB0aGUgc2FtZSBtZWNoYW5pc20gTVVTVCBiZSB1c2VkIGluIGJvdGggY2hhbm5lbHMuDQoNCkkg
cHJvcG9zZSB0aGUgZm9sbG93aW5nIG5ldyB3b3JkaW5nOg0KDQpPY3QgMjAyMSAtIEtleSBwcmVz
ZW50YXRpb24gbWVjaGFuaXNtIGJpbmRpbmcgZm9yIGVhY2ggY29tbXVuaWNhdGlvbiBjaGFubmVs
IHRvIFdHTEMuDQoNCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0NCkZy
b206IFRoZSBJRVNHIDxpZXNnLXNlY3JldGFyeUBpZXRmLm9yZzxtYWlsdG86aWVzZy1zZWNyZXRh
cnlAaWV0Zi5vcmc+Pg0KRGF0ZTogRnJpLCBKdW4gMjYsIDIwMjAgYXQgOToxMCBBTQ0KU3ViamVj
dDogV0cgUmV2aWV3OiBHcmFudCBOZWdvdGlhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBQcm90b2Nv
bCAoZ25hcCkNClRvOiBJRVRGLUFubm91bmNlIDxpZXRmLWFubm91bmNlQGlldGYub3JnPG1haWx0
bzppZXRmLWFubm91bmNlQGlldGYub3JnPj4NCkNjOiA8dHhhdXRoQGlldGYub3JnPG1haWx0bzp0
eGF1dGhAaWV0Zi5vcmc+Pg0KDQoNCkEgbmV3IElFVEYgV0cgaGFzIGJlZW4gcHJvcG9zZWQgaW4g
dGhlIFNlY3VyaXR5IEFyZWEuIFRoZSBJRVNHIGhhcyBub3QgbWFkZQ0KYW55IGRldGVybWluYXRp
b24geWV0LiBUaGUgZm9sbG93aW5nIGRyYWZ0IGNoYXJ0ZXIgd2FzIHN1Ym1pdHRlZCwgYW5kIGlz
DQpwcm92aWRlZCBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3NlcyBvbmx5LiBQbGVhc2Ugc2VuZCB5
b3VyIGNvbW1lbnRzIHRvIHRoZQ0KSUVTRyBtYWlsaW5nIGxpc3QgKGllc2dAaWV0Zi5vcmc8bWFp
bHRvOmllc2dAaWV0Zi5vcmc+KSBieSAyMDIwLTA3LTA2Lg0KDQpHcmFudCBOZWdvdGlhdGlvbiBh
bmQgQXV0aG9yaXphdGlvbiBQcm90b2NvbCAoZ25hcCkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDdXJyZW50
IHN0YXR1czogUHJvcG9zZWQgV0cNCg0KQ2hhaXJzOg0KICBZYXJvbiBTaGVmZmVyIDx5YXJvbmYu
aWV0ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+DQogIExlaWYgSm9o
YW5zc29uIDxsZWlmakBzdW5ldC5zZTxtYWlsdG86bGVpZmpAc3VuZXQuc2U+Pg0KDQpBc3NpZ25l
ZCBBcmVhIERpcmVjdG9yOg0KICBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc8bWFpbHRvOnJk
ZEBjZXJ0Lm9yZz4+DQoNClNlY3VyaXR5IEFyZWEgRGlyZWN0b3JzOg0KICBCZW5qYW1pbiBLYWR1
ayA8a2FkdWtAbWl0LmVkdTxtYWlsdG86a2FkdWtAbWl0LmVkdT4+DQogIFJvbWFuIERhbnlsaXcg
PHJkZEBjZXJ0Lm9yZzxtYWlsdG86cmRkQGNlcnQub3JnPj4NCg0KTWFpbGluZyBsaXN0Og0KICBB
ZGRyZXNzOiB0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aEBpZXRmLm9yZz4NCiAgVG8gc3Vi
c2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KICBB
cmNoaXZlOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL3R4YXV0aC8N
Cg0KR3JvdXAgcGFnZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ncm91cC9nbmFwLw0K
DQpDaGFydGVyOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYt
Z25hcC8NCg0KVGhpcyBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBhIGZpbmUtZ3JhaW5l
ZCBkZWxlZ2F0aW9uIHByb3RvY29sIGZvcg0KYXV0aG9yaXphdGlvbiBhbmQgQVBJIGFjY2Vzcywg
YXMgd2VsbCBhcyByZXF1ZXN0aW5nIGFuZCBwcm92aWRpbmcgdXNlcg0KaWRlbnRpZmllcnMgYW5k
IGNsYWltcy4gVGhpcyBwcm90b2NvbCB3aWxsIGFsbG93IGFuIGF1dGhvcml6aW5nIHBhcnR5IHRv
DQpkZWxlZ2F0ZSBhY2Nlc3MgdG8gY2xpZW50IHNvZnR3YXJlIHRocm91Z2ggYW4gYXV0aG9yaXph
dGlvbiBzZXJ2ZXIuIEl0IHdpbGwNCmV4cGFuZCB1cG9uIHRoZSB1c2VzIGNhc2VzIGN1cnJlbnRs
eSBzdXBwb3J0ZWQgYnkgT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdA0KKGl0c2VsZiBhbiBl
eHRlbnNpb24gb2YgT0F1dGggMi4wKSB0byBzdXBwb3J0IGF1dGhvcml6YXRpb25zIHNjb3BlZCBh
cw0KbmFycm93bHkgYXMgYSBzaW5nbGUgdHJhbnNhY3Rpb24sIHByb3ZpZGUgYSBjbGVhciBmcmFt
ZXdvcmsgZm9yIGludGVyYWN0aW9uDQphbW9uZyBhbGwgcGFydGllcyBpbnZvbHZlZCBpbiB0aGUg
cHJvdG9jb2wgZmxvdywgYW5kIHJlbW92ZSB1bm5lY2Vzc2FyeQ0KZGVwZW5kZW5jZSBvbiBhIGJy
b3dzZXIgb3IgdXNlci1hZ2VudCBmb3IgY29vcmRpbmF0aW5nIGludGVyYWN0aW9ucy4uDQoNClRo
ZSBkZWxlZ2F0aW9uIHByb2Nlc3Mgd2lsbCBiZSBhY3RlZCB1cG9uIGJ5IG11bHRpcGxlIHBhcnRp
ZXMgaW4gdGhlIHByb3RvY29sLA0KZWFjaCBwZXJmb3JtaW5nIGEgc3BlY2lmaWMgcm9sZS4gVGhl
IHByb3RvY29sIHdpbGwgZGVjb3VwbGUgdGhlIGludGVyYWN0aW9uDQpjaGFubmVscywgc3VjaCBh
cyB0aGUgZW5kIHVzZXLigJlzIGJyb3dzZXIsIGZyb20gdGhlIGRlbGVnYXRpb24gY2hhbm5lbCwg
d2hpY2gNCmhhcHBlbnMgZGlyZWN0bHkgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9y
aXphdGlvbiBzZXJ2ZXIgKGluIGNvbnRyYXN0DQp3aXRoIE9BdXRoIDIuMCwgd2hpY2ggaXMgaW5p
dGlhdGVkIGJ5IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhlIHVzZXLigJlzDQpicm93c2VyKS4g
VGhlIHByb3RvY29sIHdpbGwgaW5jbHVkZSBhIG1lYW5zIG9mIHNwZWNpZnlpbmcgaG93IHRoZSB1
c2VyIGNhbg0KcG90ZW50aWFsbHkgYmUgaW52b2x2ZWQgaW4gYW4gaW50ZXJhY3RpdmUgZmFzaGlv
biBkdXJpbmcgdGhlIGRlbGVnYXRpb24NCnByb2Nlc3MuIFRoZSBjbGllbnQgYW5kIEF1dGhvcml6
YXRpb24gU2VydmVyIChBUykgd2lsbCB1c2UgdGhlc2UgaW50ZXJhY3Rpb24NCm1lY2hhbmlzbXMg
dG8gaW52b2x2ZSB0aGUgdXNlciwgYXMgbmVjZXNzYXJ5LCB0byBtYWtlIGF1dGhvcml6YXRpb24g
ZGVjaXNpb25zLg0KVGhpcyBkZWNvdXBsaW5nIGF2b2lkcyBtYW55IG9mIHRoZSBzZWN1cml0eSBj
b25jZXJucyBhbmQgdGVjaG5pY2FsIGNoYWxsZW5nZXMNCm9mIE9BdXRoIDIuMCBhbmQgcHJvdmlk
ZXMgYSBub24taW52YXNpdmUgcGF0aCBmb3Igc3VwcG9ydGluZyBmdXR1cmUgdHlwZXMgb2YNCmNs
aWVudHMgYW5kIGludGVyYWN0aW9uIGNoYW5uZWxzLg0KDQpUaGUgZ3JvdXAgd2lsbCBkZWZpbmUg
aW50ZXJvcGVyYWJpbGl0eSBmb3IgdGhpcyBwcm90b2NvbCBiZXR3ZWVuIGRpZmZlcmVudA0KcGFy
dGllcywgaW5jbHVkaW5nDQogLSBjbGllbnQgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyOw0KIC0g
Y2xpZW50IGFuZCByZXNvdXJjZSBzZXJ2ZXI7IGFuZA0KIC0gYXV0aG9yaXphdGlvbiBzZXJ2ZXIg
YW5kIHJlc291cmNlIHNlcnZlci4NCg0KVGhlIGdyb3VwIHdpbGwgc2VlayB0byBtaW5pbWl6ZSBh
c3N1bXB0aW9ucyBhYm91dCB0aGUgZm9ybSBvZiBjbGllbnQNCmFwcGxpY2F0aW9ucywgYWxsb3dp
bmcgZm9yOg0KLSBGaW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiBhY2Nlc3MNCi0gQXBwcm92
YWwgb2YgQVMgYXR0ZXN0YXRpb24gdG8gaWRlbnRpZmllcnMgYW5kIG90aGVyIGlkZW50aXR5IGNs
YWltcw0KLSBBcHByb3ZhbCBvZiBhY2Nlc3MgdG8gbXVsdGlwbGUgcmVzb3VyY2VzIGFuZCBBUElz
IGluIGEgc2luZ2xlIGludGVyYWN0aW9uDQotIFN1cHBvcnQgZm9yIG11bHRpcGxlIGFjY2VzcyB0
b2tlbnMgaW4gYSBzaW5nbGUgcmVxdWVzdCBhbmQgcmVzcG9uc2UNCi0gU3VwcG9ydCBmb3IgZGly
ZWN0ZWQsIGF1ZGllbmNlLXJlc3RyaWN0ZWQgYWNjZXNzIHRva2Vucw0KLSBTZXBhcmF0aW9uIGJl
dHdlZW4gdGhlIHBhcnR5IGF1dGhvcml6aW5nIGFjY2VzcyBhbmQgdGhlIHBhcnR5IG9wZXJhdGlu
ZyB0aGUNCmNsaWVudCByZXF1ZXN0aW5nIGFjY2Vzcw0KDQpUaGUgZ3JvdXAgd2lsbCBkZWZpbmUg
ZXh0ZW5zaW9uIHBvaW50cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3INCmZsZXhpYmls
aXR5IGluIGFyZWFzIGluY2x1ZGluZzoNCg0KLSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtl
eXMsIG1lc3NhZ2Ugc2lnbmF0dXJlcywgYW5kIHByb29mIG9mIHBvc3Nlc3Npb24NCi0gVXNlciBp
bnRlcmFjdGlvbiBtZWNoYW5pc21zIGluY2x1ZGluZyB3ZWIgYW5kIG5vbi13ZWIgbWV0aG9kcw0K
LSBNZWNoYW5pc21zIGZvciBjb252ZXlpbmcgdXNlciwgc29mdHdhcmUsIG9yZ2FuaXphdGlvbiwg
YW5kIG90aGVyDQppbmZvcm1hdGlvbiB1c2VkIGluIGF1dGhvcml6YXRpb24gZGVjaXNpb25zDQot
IE1lY2hhbmlzbXMgZm9yIHByZXNlbnRpbmcgdG9rZW5zIHRvIHJlc291cmNlIHNlcnZlcnMgYW5k
IGJpbmRpbmcgcmVzb3VyY2UNCnJlcXVlc3RzIHRvIHRva2VucyBhbmQgYXNzb2NpYXRlZCBjcnlw
dG9ncmFwaGljIGtleXMNCi0gT3B0aW1pemVkIGluY2x1c2lvbiBvZiBhZGRpdGlvbmFsIGluZm9y
bWF0aW9uIChpbmNsdWRpbmcgaWRlbnRpZmllcnMgYW5kDQppZGVudGl0eSBhc3NlcnRpb25zKSB0
aHJvdWdoIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3MNCg0KQWRkaXRpb25hbGx5LCB0aGUgZ3JvdXAg
d2lsbCBwcm92aWRlIG1lY2hhbmlzbXMgZm9yIG1hbmFnZW1lbnQgb2YgdGhlIHByb3RvY29sDQps
aWZlY3ljbGUgaW5jbHVkaW5nOg0KDQotIERpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBz
ZXJ2ZXINCi0gUmV2b2NhdGlvbiBvZiBhY3RpdmUgdG9rZW5zDQotIE1lY2hhbmlzbXMgZm9yIHRo
ZSBBUyBhbmQgUlMgdG8gY29tbXVuaWNhdGUgdGhlIGFjY2VzcyBncmFudGVkIGJ5IGFuIGFjY2Vz
cw0KdG9rZW4NCg0KQWx0aG91Z2ggdGhlIGFydGlmYWN0cyBmb3IgdGhpcyB3b3JrIGFyZSBub3Qg
aW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUNCmJhY2t3YXJkcy1jb21wYXRpYmxlIHdpdGggT0F1
dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0LCB0aGUgZ3JvdXAgd2lsbCBhdHRlbXB0DQp0byBzaW1w
bGlmeSBtaWdyYXRpbmcgZnJvbSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0IHRvIHRoZSBu
ZXcgcHJvdG9jb2wNCndoZXJlIHBvc3NpYmxlLg0KDQpUaGlzIGdyb3VwIGlzIG5vdCBjaGFydGVy
ZWQgdG8gZGV2ZWxvcCBleHRlbnNpb25zIHRvIE9BdXRoIDIuMCwgYW5kIGFzIHN1Y2gNCndpbGwg
Zm9jdXMgb24gbmV3IHRlY2hub2xvZ2ljYWwgc29sdXRpb25zIG5vdCBuZWNlc3NhcmlseSBjb21w
YXRpYmxlIHdpdGgNCk9BdXRoIDIuMC4gRnVuY3Rpb25hbGl0eSB0aGF0IGJ1aWxkcyBkaXJlY3Rs
eSBvbiBPQXV0aCAyLjAgd2lsbCBiZSBkaXJlY3RlZA0KdG8gdGhlIE9BdXRoIFdvcmtpbmcgR3Jv
dXAsIGluY2x1ZGluZyBmdW5jdGlvbmFsaXR5IGJhY2stcG9ydGVkIGZyb20gdGhlDQpwcm90b2Nv
bCBkZXZlbG9wZWQgaGVyZSB0byBPQXV0aCAyLjAuDQoNClRoZSBncm91cCBpcyBjaGFydGVyZWQg
dG8gZGV2ZWxvcCBtZWNoYW5pc21zIGZvciBhcHBseWluZyBjcnlwdG9ncmFwaGljDQptZXRob2Rz
LCBzdWNoIGFzIEpPU0UgYW5kIENPU0UsIHRvIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3MuIFRoaXMg
Z3JvdXAgaXMgbm90DQpjaGFydGVyZWQgdG8gZGV2ZWxvcCBuZXcgY3J5cHRvZ3JhcGhpYyBtZXRo
b2RzLg0KDQpUaGUgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3Ig
Y29udmV5aW5nIGlkZW50aXR5DQppbmZvcm1hdGlvbiB3aXRoaW4gdGhlIHByb3RvY29sIGluY2x1
ZGluZyBleGlzdGluZyBpZGVudGlmaWVycyAoc3VjaCBhcyBlbWFpbA0KYWRkcmVzc2VzLCBwaG9u
ZSBudW1iZXJzLCB1c2VybmFtZXMsIGFuZCBzdWJqZWN0IGlkZW50aWZpZXJzKSBhbmQgYXNzZXJ0
aW9ucw0KKHN1Y2ggYXMgT3BlbklEIENvbm5lY3QgSUQgVG9rZW5zLCBTQU1MIEFzc2VydGlvbnMs
IGFuZCBWZXJpZmlhYmxlDQpDcmVkZW50aWFscykuIFRoZSBncm91cCBpcyBub3QgY2hhcnRlcmVk
IHRvIGRldmVsb3AgbmV3IGZvcm1hdHMgZm9yDQppZGVudGlmaWVycyBvciBhc3NlcnRpb25zLCBu
b3IgaXMgdGhlIGdyb3VwIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIHNjaGVtYXMgZm9yDQp1c2VyIGlu
Zm9ybWF0aW9uLCBwcm9maWxlcywgb3Igb3RoZXIgaWRlbnRpdHkgYXR0cmlidXRlcywgdW5sZXNz
IGEgdmlhYmxlDQpleGlzdGluZyBmb3JtYXQgaXMgbm90IGF2YWlsYWJsZS4NCg0KVGhlIGluaXRp
YWwgd29yayB3aWxsIGZvY3VzIG9uIHVzaW5nIEhUVFBTIGZvciBjb21tdW5pY2F0aW9uIGJldHdl
ZW4gdGhlDQpjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGFraW5nIGFkdmFu
dGFnZSBvZiBvcHRpbWl6YXRpb24NCmZlYXR1cmVzIG9mIEhUVFAvMiBhbmQgSFRUUC8zIHdoZXJl
IHBvc3NpYmxlLCBhbmQgd2lsbCBzdHJpdmUgdG8gZW5hYmxlDQpzaW1wbGUgbWFwcGluZyB0byBv
dGhlciBwcm90b2NvbHMgc3VjaCBhcyBDT0FQIHdoZW4gZG9pbmcgc28gZG9lcyBub3QNCmNvbmZs
aWN0IHdpdGggdGhlIHByaW1hcnkgZm9jdXMuDQoNCk1pbGVzdG9uZXMgdG8gaW5jbHVkZToNCi0g
Q29yZSBkZWxlZ2F0aW9uIHByb3RvY29sDQotIEtleSBwcmVzZW50YXRpb24gbWVjaGFuaXNtIGJp
bmRpbmdzIHRvIHRoZSBjb3JlIHByb3RvY29sIGluY2x1ZGluZyBUTFMsDQpkZXRhY2hlZCBIVFRQ
IHNpZ25hdHVyZSwgYW5kIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlcw0KLSBDb252ZXlhbmNlIG1l
Y2hhbmlzbXMgZm9yIGlkZW50aWZpZXJzIGFuZCBhc3NlcnRpb25zDQotIEd1aWRlbGluZXMgZm9y
IHVzZSBvZiBwcm90b2NvbCBleHRlbnNpb24gcG9pbnRzDQotIChpZiBuZWVkZWQpIEd1aWRlbGlu
ZXMgb24gbWlncmF0aW9uIHBhdGhzLCBpbXBsZW1lbnRhdGlvbiwgYW5kIG9wZXJhdGlvbnMNCg0K
V2hlcmUgcG9zc2libGUsIHRoZSBncm91cCB3aWxsIHNlZWsgdG8gbWFrZSB1c2Ugb2YgdG9vbHMg
dG8gZ3VpZGUgYW5kIGluZm9ybQ0KdGhlIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzIGluY2x1ZGlu
ZyBmb3JtYWwgYW5hbHlzaXMsIGFyY2hpdGVjdHVyZSBkb2N1bWVudHMsDQphbmQgdXNlIGNhc2Ug
ZG9jdW1lbnRzLiBUaGVzZSBhcnRpZmFjdHMgd2lsbCBub3QgYmUgY29uc2lkZXJlZCBhcyB3b3Jr
aW5nDQpncm91cCBtaWxlc3RvbmVzIG9yIGRlbGl2ZXJhYmxlcy4NCg0KVGhlIHdvcmtpbmcgZ3Jv
dXAgd2lsbCBjb29wZXJhdGUgYW5kIGNvb3JkaW5hdGUgd2l0aCBvdGhlciBJRVRGIFdHcyBzdWNo
IGFzDQpPQVVUSCwgYW5kIHdvcmsgd2l0aCBleHRlcm5hbCBvcmdhbml6YXRpb25zLCBzdWNoIGFz
IHRoZSBPcGVuSUQgRm91bmRhdGlvbiwNCmFzIGFwcHJvcHJpYXRlLg0KDQpNaWxlc3RvbmVzOg0K
DQogIEp1bCAyMDIxIC0gQ29yZSBkZWxlZ2F0aW9uIHByb3RvY29sIGluIFdHTEMNCg0KICBPY3Qg
MjAyMSAtIEtleSBwcmVzZW50YXRpb24gbWVjaGFuaXNtIGJpbmRpbmcgdG8gdGhlIGNvcmUgcHJv
dG9jb2wsIFRMUywgdG8NCiAgV0dMQw0KDQogIE9jdCAyMDIxIC0gS2V5IHByZXNlbnRhdGlvbiBt
ZWNoYW5pc20gYmluZGluZyB0byB0aGUgY29yZSBwcm90b2NvbCwNCiAgZGV0YWNoZWQgSFRUUCBz
aWduYXR1cmVzLCB0byBXR0xDDQoNCiAgT2N0IDIwMjEgLSBLZXkgcHJlc2VudGF0aW9uIG1lY2hh
bmlzbSBiaW5kaW5nIHRvIHRoZSBjb3JlIHByb3RvY29sLA0KICBlbWJlZGRlZCBIVFRQIHNpZ25h
dHVyZSwgdG8gV0dMQw0KDQogIERlYyAyMDIxIC0gR3VpZGVsaW5lcyBmb3IgdXNlIG9mIHByb3Rv
Y29sIGV4dGVuc2lvbiBwb2ludHMgdG8gV0dMQw0KDQogIEZlYiAyMDIyIC0gR3VpZGVsaW5lcyBv
biBtaWdyYXRpb24gcGF0aHMsIGltcGxlbWVudGF0aW9uLCBhbmQgb3BlcmF0aW9ucyB0bw0KICAg
V0dMQw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCklFVEYtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnPG1h
aWx0bzpJRVRGLUFubm91bmNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9pZXRmLWFubm91bmNlDQpbSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuXeGQpw0K
LS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGll
dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg0K
LS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGll
dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg==

--_000_e1a8197a96a24e229ed1ec956394337acertorg_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+
PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9y
OnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N
Ci5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0t
LT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZv
bnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAz
IDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v
c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Okdh
ZHVnaTsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0
aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp
bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN
Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K
CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu
LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt
cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93
dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7
c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp
di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9
IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx
IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg
bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y
ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpITxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5UaGUgbWlsZXN0b25lcyBiZWxvdyB0aGUgY2hhcnRlciB0ZXh0IG5vdyByZWZsZWN0IHRo
ZSBwcm9wb3NlZCBzaW1wbGlmaWNhdGlvbiBkZXNjcmliZWQgYmVsb3cgKGJ5IERpY2spLjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Um9tYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz
LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gaWVz
ZyAmbHQ7aWVzZy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KVG9t
IEpvbmVzPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVuZSAyNiwgMjAyMCA2OjEwIFBNPGJy
Pg0KPGI+VG86PC9iPiBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PGJyPg0K
PGI+Q2M6PC9iPiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs7IFRoZSBJ
RVNHICZsdDtpZXNnQGlldGYub3JnJmd0OzsgdHhhdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJlOiBbVHhhdXRoXSBXRyBSZXZpZXc6IEdyYW50IE5lZ290aWF0aW9uIGFuZCBBdXRo
b3JpemF0aW9uIFByb3RvY29sIChnbmFwKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlJpZ2h0IC0gSSBoYXZlIGFscmVhZHkgcHJvcG9zZWQgYmluZGluZyB0
byBhcHBsaWNhdGlvbiBsZXZlbCBrZXlzIGluIG90aGVyIHZlbnVlcyBhbmQgc3Ryb25nbHkgb3Bw
b3NlIGNvbnRpbnVlZCB1c2Ugb2YgY2hhbm5lbCBiaW5kaW5nLjxiciBjbGVhcj0iYWxsIj4NCjxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlBlYWNlIC4udG9tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKdW4gMjYsIDIwMjAgYXQgMjowMyBQ
TSBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1Ij5qcmlj
aGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7
cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6
MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdpdGggdGhpcyBwcm9w
b3NlZCBjaGFuZ2UgaW4gd29yZGluZyBmb3IgdGhlIG1pbGVzdG9uZXMuIFdlIGRvbuKAmXQgd2Fu
dCB0byBhcnRpZmljaWFsbHkgbGltaXQgdGhlIGtleSBiaW5kaW5nIHByZXNlbnRhdGlvbiBtZWNo
YW5pc21zLiBXaGlsZSBJIHRoaW5rIHRoZSB0aHJlZSBsaXN0ZWQgYXJlIGxpa2VseSB0byBiZSBh
bW9uZyB0aGUgZmlyc3Qgb25lcyB3ZSBzZWUgKGJhc2VkIG9uIHByaW9yIGFydA0KIGFuZCBjdXJy
ZW50IGNvbW11bml0eSBpbnRlcmVzdCksIEkgZG9u4oCZdCB0aGluayB3ZSBjYW4gcHJlZGljdCBl
bnRpcmVseSB3aGF0IHdpbGwgYmUgZGV2ZWxvcGVkIGJ5IHRoZSBncm91cCBhbmQgd2hlbi4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KA
lCBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+
DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u
IEp1biAyNiwgMjAyMCwgYXQgMToyMSBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRv
OmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5j
b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGFtIGNvbmNlcm5lZCB3aXRo
IHRoZSBmb2xsb3dpbmcgbWlsZXN0b25lczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgT2N0IDIw
MjEgLSZuYnNwO0tleSZuYnNwO3ByZXNlbnRhdGlvbiZuYnNwO21lY2hhbmlzbSBiaW5kaW5nIHRv
IHRoZSBjb3JlIHByb3RvY29sLCBUTFMsIHRvPGJyPg0KJm5ic3A7IFdHTEM8YnI+DQo8YnI+DQom
bmJzcDsgT2N0IDIwMjEgLSZuYnNwO0tleSZuYnNwO3ByZXNlbnRhdGlvbiZuYnNwO21lY2hhbmlz
bSBiaW5kaW5nIHRvIHRoZSBjb3JlIHByb3RvY29sLDxicj4NCiZuYnNwOyBkZXRhY2hlZCBIVFRQ
IHNpZ25hdHVyZXMsIHRvIFdHTEM8YnI+DQo8YnI+DQombmJzcDsgT2N0IDIwMjEgLSZuYnNwO0tl
eSZuYnNwO3ByZXNlbnRhdGlvbiZuYnNwO21lY2hhbmlzbSBiaW5kaW5nIHRvIHRoZSBjb3JlIHBy
b3RvY29sLDxicj4NCiZuYnNwOyBlbWJlZGRlZCBIVFRQIHNpZ25hdHVyZSwgdG8gV0dMQzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgaXQgaXMg
b3Zlcmx5IHByZXNjcmlwdGl2ZSB0byBzcGVjaWZ5IHdoaWNoIGtleSBwcmVzZW50YXRpb24gbWVj
aGFuaXNtcyB3aWxsIGJlIGNyZWF0ZWQsIGFuZCBpdCBpbXBsaWVzIHRoYXQgb3RoZXIga2V5IHBy
ZXNlbnRhdGlvbiBtZWNoYW5pc21zIHdpbGwgbm90IGJlIHdvcmtlZCBvbi4NCiBXaGlsZSBpdCBp
cyBwb3NzaWJsZSB0aGF0IGNoYW5uZWwgYmluZGluZyBtZWNoYW5pc21zIHN1Y2ggYXMgVExTLCBk
ZXRhY2hlZCBIVFRQIHNpZ25hdHVyZXMsIGFuZCBlbWJlZGRlZCBIVFRQIHNpZ25hdHVyZXMgd2ls
bCBiZSBhcHByb3ByaWF0ZSBrZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbXMgZm9yIEdOQVAsIGl0
IGlzIGFsc28gcXVpdGUgcG9zc2libGUgdGhhdCB0aGUgV0cgd2lsbCBkZXRlcm1pbmUgb25lIG9y
IG1vcmUgYXJlIG5vdCBhcHByb3ByaWF0ZSwNCiBvciB0aGUgdW5kZXJseWluZyBtZWNoYW5pc20g
bWF5IG5vdCBnYWluIGFjY2VwdGFuY2UsIG9yIGNoYW5uZWwgYmluZGluZyBpcyBub3QgYWx3YXlz
IG5lZWRlZC4gRm9yIGV4YW1wbGUsIHRoZSBlZmZvcnQgdG8gYmluZCBPQXV0aCBhY2Nlc3MgdG9r
ZW5zIHVzaW5nIFJGQzg0NzEgd2FzIGRpc2JhbmRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj5BZGRpdGlvbmFsbHksIHRoZXJlIGFyZSB0d28gcHJpbWFy
eSBjb21tdW5pY2F0aW9uIGNoYW5uZWxzIGluIHRoZSBwcm90b2NvbCB0aGF0IGhhdmUgZGlmZmVy
ZW50IHNlY3VyaXR5IHJlcXVpcmVtZW50cy4gVGhlIGNsaWVudCB0byBhdXRob3JpemF0aW9uIHNl
cnZlciwgYW5kIHRoZSBjbGllbnQgdG8NCiByZXNvdXJjZSBzZXJ2ZXIuIFRoZSB0ZXJtICZxdW90
O2NvcmUgcHJvdG9jb2wmcXVvdDsgaXMgdmFndWUgYW5kIGNvdWxkIGJlIGNvbnN0cnVlZCB0aGF0
IHRoZSBzYW1lIG1lY2hhbmlzbSBNVVNUIGJlIHVzZWQgaW4gYm90aCBjaGFubmVscy48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIHByb3Bvc2UgdGhlIGZv
bGxvd2luZyBuZXcgd29yZGluZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5PY3QgMjAyMSAtIEtleSBwcmVzZW50YXRpb24gbWVjaGFuaXNtIGJpbmRpbmcg
Zm9yIGVhY2ggY29tbXVuaWNhdGlvbiBjaGFubmVsIHRvIFdHTEMuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tLS0tLS0t
LS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTom
bmJzcDs8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+VGhlIElFU0c8L3NwYW4+PC9zdHJvbmc+Jm5ic3A7Jmx0OzxhIGhyZWY9
Im1haWx0bzppZXNnLXNlY3JldGFyeUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmllc2ctc2Vj
cmV0YXJ5QGlldGYub3JnPC9hPiZndDs8YnI+DQpEYXRlOiBGcmksIEp1biAyNiwgMjAyMCBhdCA5
OjEwIEFNPGJyPg0KU3ViamVjdDogV0cgUmV2aWV3OiBHcmFudCBOZWdvdGlhdGlvbiBhbmQgQXV0
aG9yaXphdGlvbiBQcm90b2NvbCAoZ25hcCk8YnI+DQpUbzogSUVURi1Bbm5vdW5jZSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXRm
LWFubm91bmNlQGlldGYub3JnPC9hPiZndDs8YnI+DQpDYzogJmx0OzxhIGhyZWY9Im1haWx0bzp0
eGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KQSBuZXcgSUVURiBXRyBoYXMgYmVlbiBwcm9wb3NlZCBp
biB0aGUgU2VjdXJpdHkgQXJlYS4gVGhlIElFU0cgaGFzIG5vdCBtYWRlPGJyPg0KYW55IGRldGVy
bWluYXRpb24geWV0LiBUaGUgZm9sbG93aW5nIGRyYWZ0IGNoYXJ0ZXIgd2FzIHN1Ym1pdHRlZCwg
YW5kIGlzPGJyPg0KcHJvdmlkZWQgZm9yIGluZm9ybWF0aW9uYWwgcHVycG9zZXMgb25seS4gUGxl
YXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGU8YnI+DQpJRVNHIG1haWxpbmcgbGlzdCAoPGEg
aHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZXNnQGlldGYub3Jn
PC9hPikgYnkgMjAyMC0wNy0wNi48YnI+DQo8YnI+DQpHcmFudCBOZWdvdGlhdGlvbiBhbmQgQXV0
aG9yaXphdGlvbiBQcm90b2NvbCAoZ25hcCk8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkN1cnJl
bnQgc3RhdHVzOiBQcm9wb3NlZCBXRzxicj4NCjxicj4NCkNoYWlyczo8YnI+DQombmJzcDsgWWFy
b24gU2hlZmZlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KJm5ic3A7IExl
aWYgSm9oYW5zc29uICZsdDs8YSBocmVmPSJtYWlsdG86bGVpZmpAc3VuZXQuc2UiIHRhcmdldD0i
X2JsYW5rIj5sZWlmakBzdW5ldC5zZTwvYT4mZ3Q7PGJyPg0KPGJyPg0KQXNzaWduZWQgQXJlYSBE
aXJlY3Rvcjo8YnI+DQombmJzcDsgUm9tYW4gRGFueWxpdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJk
ZEBjZXJ0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJkZEBjZXJ0Lm9yZzwvYT4mZ3Q7PGJyPg0KPGJy
Pg0KU2VjdXJpdHkgQXJlYSBEaXJlY3RvcnM6PGJyPg0KJm5ic3A7IEJlbmphbWluIEthZHVrICZs
dDs8YSBocmVmPSJtYWlsdG86a2FkdWtAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmthZHVrQG1p
dC5lZHU8L2E+Jmd0Ozxicj4NCiZuYnNwOyBSb21hbiBEYW55bGl3ICZsdDs8YSBocmVmPSJtYWls
dG86cmRkQGNlcnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+cmRkQGNlcnQub3JnPC9hPiZndDs8YnI+
DQo8YnI+DQpNYWlsaW5nIGxpc3Q6PGJyPg0KJm5ic3A7IEFkZHJlc3M6Jm5ic3A7PGEgaHJlZj0i
bWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0aEBpZXRmLm9yZzwv
YT48YnI+DQombmJzcDsgVG8gc3Vic2NyaWJlOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PGJyPg0KJm5ic3A7IEFyY2hp
dmU6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dz
ZS90eGF1dGgvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h
cmNoL2Jyb3dzZS90eGF1dGgvPC9hPjxicj4NCjxicj4NCkdyb3VwIHBhZ2U6Jm5ic3A7PGEgaHJl
Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ncm91cC9nbmFwLyIgdGFyZ2V0PSJfYmxh
bmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZ3JvdXAvZ25hcC88L2E+PGJyPg0KPGJy
Pg0KQ2hhcnRlcjombmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9jaGFydGVyLWlldGYtZ25hcC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2Vy
LmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtZ25hcC88L2E+PGJyPg0KPGJyPg0KVGhpcyBncm91
cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBhIGZpbmUtZ3JhaW5lZCBkZWxlZ2F0aW9uIHByb3Rv
Y29sIGZvcjxicj4NCmF1dGhvcml6YXRpb24gYW5kIEFQSSBhY2Nlc3MsIGFzIHdlbGwgYXMgcmVx
dWVzdGluZyBhbmQgcHJvdmlkaW5nIHVzZXI8YnI+DQppZGVudGlmaWVycyBhbmQgY2xhaW1zLiBU
aGlzIHByb3RvY29sIHdpbGwgYWxsb3cgYW4gYXV0aG9yaXppbmcgcGFydHkgdG88YnI+DQpkZWxl
Z2F0ZSBhY2Nlc3MgdG8gY2xpZW50IHNvZnR3YXJlIHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBz
ZXJ2ZXIuIEl0IHdpbGw8YnI+DQpleHBhbmQgdXBvbiB0aGUgdXNlcyBjYXNlcyBjdXJyZW50bHkg
c3VwcG9ydGVkIGJ5IE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3Q8YnI+DQooaXRzZWxmIGFu
IGV4dGVuc2lvbiBvZiBPQXV0aCAyLjApIHRvIHN1cHBvcnQgYXV0aG9yaXphdGlvbnMgc2NvcGVk
IGFzPGJyPg0KbmFycm93bHkgYXMgYSBzaW5nbGUgdHJhbnNhY3Rpb24sIHByb3ZpZGUgYSBjbGVh
ciBmcmFtZXdvcmsgZm9yIGludGVyYWN0aW9uPGJyPg0KYW1vbmcgYWxsIHBhcnRpZXMgaW52b2x2
ZWQgaW4gdGhlIHByb3RvY29sIGZsb3csIGFuZCByZW1vdmUgdW5uZWNlc3Nhcnk8YnI+DQpkZXBl
bmRlbmNlIG9uIGEgYnJvd3NlciBvciB1c2VyLWFnZW50IGZvciBjb29yZGluYXRpbmcgaW50ZXJh
Y3Rpb25zLi48YnI+DQo8YnI+DQpUaGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYmUgYWN0ZWQg
dXBvbiBieSBtdWx0aXBsZSBwYXJ0aWVzIGluIHRoZSBwcm90b2NvbCw8YnI+DQplYWNoIHBlcmZv
cm1pbmcgYSBzcGVjaWZpYyByb2xlLiBUaGUgcHJvdG9jb2wgd2lsbCBkZWNvdXBsZSB0aGUgaW50
ZXJhY3Rpb248YnI+DQpjaGFubmVscywgc3VjaCBhcyB0aGUgZW5kIHVzZXLigJlzIGJyb3dzZXIs
IGZyb20gdGhlIGRlbGVnYXRpb24gY2hhbm5lbCwgd2hpY2g8YnI+DQpoYXBwZW5zIGRpcmVjdGx5
IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChpbiBjb250
cmFzdDxicj4NCndpdGggT0F1dGggMi4wLCB3aGljaCBpcyBpbml0aWF0ZWQgYnkgdGhlIGNsaWVu
dCByZWRpcmVjdGluZyB0aGUgdXNlcuKAmXM8YnI+DQpicm93c2VyKS4gVGhlIHByb3RvY29sIHdp
bGwgaW5jbHVkZSBhIG1lYW5zIG9mIHNwZWNpZnlpbmcgaG93IHRoZSB1c2VyIGNhbjxicj4NCnBv
dGVudGlhbGx5IGJlIGludm9sdmVkIGluIGFuIGludGVyYWN0aXZlIGZhc2hpb24gZHVyaW5nIHRo
ZSBkZWxlZ2F0aW9uPGJyPg0KcHJvY2Vzcy4gVGhlIGNsaWVudCBhbmQgQXV0aG9yaXphdGlvbiBT
ZXJ2ZXIgKEFTKSB3aWxsIHVzZSB0aGVzZSBpbnRlcmFjdGlvbjxicj4NCm1lY2hhbmlzbXMgdG8g
aW52b2x2ZSB0aGUgdXNlciwgYXMgbmVjZXNzYXJ5LCB0byBtYWtlIGF1dGhvcml6YXRpb24gZGVj
aXNpb25zLjxicj4NClRoaXMgZGVjb3VwbGluZyBhdm9pZHMgbWFueSBvZiB0aGUgc2VjdXJpdHkg
Y29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFsbGVuZ2VzPGJyPg0Kb2YgT0F1dGggMi4wIGFuZCBw
cm92aWRlcyBhIG5vbi1pbnZhc2l2ZSBwYXRoIGZvciBzdXBwb3J0aW5nIGZ1dHVyZSB0eXBlcyBv
Zjxicj4NCmNsaWVudHMgYW5kIGludGVyYWN0aW9uIGNoYW5uZWxzLjxicj4NCjxicj4NClRoZSBn
cm91cCB3aWxsIGRlZmluZSBpbnRlcm9wZXJhYmlsaXR5IGZvciB0aGlzIHByb3RvY29sIGJldHdl
ZW4gZGlmZmVyZW50PGJyPg0KcGFydGllcywgaW5jbHVkaW5nPGJyPg0KJm5ic3A7LSBjbGllbnQg
YW5kIGF1dGhvcml6YXRpb24gc2VydmVyOzxicj4NCiZuYnNwOy0gY2xpZW50IGFuZCByZXNvdXJj
ZSBzZXJ2ZXI7IGFuZDxicj4NCiZuYnNwOy0gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291
cmNlIHNlcnZlci48YnI+DQo8YnI+DQpUaGUgZ3JvdXAgd2lsbCBzZWVrIHRvIG1pbmltaXplIGFz
c3VtcHRpb25zIGFib3V0IHRoZSBmb3JtIG9mIGNsaWVudDxicj4NCmFwcGxpY2F0aW9ucywgYWxs
b3dpbmcgZm9yOjxicj4NCi0gRmluZS1ncmFpbmVkIHNwZWNpZmljYXRpb24gb2YgYWNjZXNzPGJy
Pg0KLSBBcHByb3ZhbCBvZiBBUyBhdHRlc3RhdGlvbiB0byBpZGVudGlmaWVycyBhbmQgb3RoZXIg
aWRlbnRpdHkgY2xhaW1zPGJyPg0KLSBBcHByb3ZhbCBvZiBhY2Nlc3MgdG8gbXVsdGlwbGUgcmVz
b3VyY2VzIGFuZCBBUElzIGluIGEgc2luZ2xlIGludGVyYWN0aW9uPGJyPg0KLSBTdXBwb3J0IGZv
ciBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zIGluIGEgc2luZ2xlIHJlcXVlc3QgYW5kIHJlc3BvbnNl
PGJyPg0KLSBTdXBwb3J0IGZvciBkaXJlY3RlZCwgYXVkaWVuY2UtcmVzdHJpY3RlZCBhY2Nlc3Mg
dG9rZW5zPGJyPg0KLSBTZXBhcmF0aW9uIGJldHdlZW4gdGhlIHBhcnR5IGF1dGhvcml6aW5nIGFj
Y2VzcyBhbmQgdGhlIHBhcnR5IG9wZXJhdGluZyB0aGU8YnI+DQpjbGllbnQgcmVxdWVzdGluZyBh
Y2Nlc3M8YnI+DQo8YnI+DQpUaGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBvaW50cyBm
b3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3I8YnI+DQpmbGV4aWJpbGl0eSBpbiBhcmVhcyBp
bmNsdWRpbmc6PGJyPg0KPGJyPg0KLSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1l
c3NhZ2Ugc2lnbmF0dXJlcywgYW5kIHByb29mIG9mIHBvc3Nlc3Npb248YnI+DQotIFVzZXIgaW50
ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBub24td2ViIG1ldGhvZHM8YnI+
DQotIE1lY2hhbmlzbXMgZm9yIGNvbnZleWluZyB1c2VyLCBzb2Z0d2FyZSwgb3JnYW5pemF0aW9u
LCBhbmQgb3RoZXI8YnI+DQppbmZvcm1hdGlvbiB1c2VkIGluIGF1dGhvcml6YXRpb24gZGVjaXNp
b25zPGJyPg0KLSBNZWNoYW5pc21zIGZvciBwcmVzZW50aW5nIHRva2VucyB0byByZXNvdXJjZSBz
ZXJ2ZXJzIGFuZCBiaW5kaW5nIHJlc291cmNlPGJyPg0KcmVxdWVzdHMgdG8gdG9rZW5zIGFuZCBh
c3NvY2lhdGVkIGNyeXB0b2dyYXBoaWMga2V5czxicj4NCi0gT3B0aW1pemVkIGluY2x1c2lvbiBv
ZiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIChpbmNsdWRpbmcgaWRlbnRpZmllcnMgYW5kPGJyPg0K
aWRlbnRpdHkgYXNzZXJ0aW9ucykgdGhyb3VnaCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzPGJyPg0K
PGJyPg0KQWRkaXRpb25hbGx5LCB0aGUgZ3JvdXAgd2lsbCBwcm92aWRlIG1lY2hhbmlzbXMgZm9y
IG1hbmFnZW1lbnQgb2YgdGhlIHByb3RvY29sPGJyPg0KbGlmZWN5Y2xlIGluY2x1ZGluZzo8YnI+
DQo8YnI+DQotIERpc2NvdmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXI8YnI+DQotIFJl
dm9jYXRpb24gb2YgYWN0aXZlIHRva2Vuczxicj4NCi0gTWVjaGFuaXNtcyBmb3IgdGhlIEFTIGFu
ZCBSUyB0byBjb21tdW5pY2F0ZSB0aGUgYWNjZXNzIGdyYW50ZWQgYnkgYW4gYWNjZXNzPGJyPg0K
dG9rZW48YnI+DQo8YnI+DQpBbHRob3VnaCB0aGUgYXJ0aWZhY3RzIGZvciB0aGlzIHdvcmsgYXJl
IG5vdCBpbnRlbmRlZCBvciBleHBlY3RlZCB0byBiZTxicj4NCmJhY2t3YXJkcy1jb21wYXRpYmxl
IHdpdGggT0F1dGggMi4wIG9yIE9wZW5JRCBDb25uZWN0LCB0aGUgZ3JvdXAgd2lsbCBhdHRlbXB0
PGJyPg0KdG8gc2ltcGxpZnkgbWlncmF0aW5nIGZyb20gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29u
bmVjdCB0byB0aGUgbmV3IHByb3RvY29sPGJyPg0Kd2hlcmUgcG9zc2libGUuPGJyPg0KPGJyPg0K
VGhpcyBncm91cCBpcyBub3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgZXh0ZW5zaW9ucyB0byBPQXV0
aCAyLjAsIGFuZCBhcyBzdWNoPGJyPg0Kd2lsbCBmb2N1cyBvbiBuZXcgdGVjaG5vbG9naWNhbCBz
b2x1dGlvbnMgbm90IG5lY2Vzc2FyaWx5IGNvbXBhdGlibGUgd2l0aDxicj4NCk9BdXRoIDIuMC4g
RnVuY3Rpb25hbGl0eSB0aGF0IGJ1aWxkcyBkaXJlY3RseSBvbiBPQXV0aCAyLjAgd2lsbCBiZSBk
aXJlY3RlZDxicj4NCnRvIHRoZSBPQXV0aCBXb3JraW5nIEdyb3VwLCBpbmNsdWRpbmcgZnVuY3Rp
b25hbGl0eSBiYWNrLXBvcnRlZCBmcm9tIHRoZTxicj4NCnByb3RvY29sIGRldmVsb3BlZCBoZXJl
IHRvIE9BdXRoIDIuMC48YnI+DQo8YnI+DQpUaGUgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVs
b3AgbWVjaGFuaXNtcyBmb3IgYXBwbHlpbmcgY3J5cHRvZ3JhcGhpYzxicj4NCm1ldGhvZHMsIHN1
Y2ggYXMgSk9TRSBhbmQgQ09TRSwgdG8gdGhlIGRlbGVnYXRpb24gcHJvY2Vzcy4gVGhpcyBncm91
cCBpcyBub3Q8YnI+DQpjaGFydGVyZWQgdG8gZGV2ZWxvcCBuZXcgY3J5cHRvZ3JhcGhpYyBtZXRo
b2RzLjxicj4NCjxicj4NClRoZSBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBtZWNoYW5p
c21zIGZvciBjb252ZXlpbmcgaWRlbnRpdHk8YnI+DQppbmZvcm1hdGlvbiB3aXRoaW4gdGhlIHBy
b3RvY29sIGluY2x1ZGluZyBleGlzdGluZyBpZGVudGlmaWVycyAoc3VjaCBhcyBlbWFpbDxicj4N
CmFkZHJlc3NlcywgcGhvbmUgbnVtYmVycywgdXNlcm5hbWVzLCBhbmQgc3ViamVjdCBpZGVudGlm
aWVycykgYW5kIGFzc2VydGlvbnM8YnI+DQooc3VjaCBhcyBPcGVuSUQgQ29ubmVjdCBJRCBUb2tl
bnMsIFNBTUwgQXNzZXJ0aW9ucywgYW5kIFZlcmlmaWFibGU8YnI+DQpDcmVkZW50aWFscykuIFRo
ZSBncm91cCBpcyBub3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgbmV3IGZvcm1hdHMgZm9yPGJyPg0K
aWRlbnRpZmllcnMgb3IgYXNzZXJ0aW9ucywgbm9yIGlzIHRoZSBncm91cCBjaGFydGVyZWQgdG8g
ZGV2ZWxvcCBzY2hlbWFzIGZvcjxicj4NCnVzZXIgaW5mb3JtYXRpb24sIHByb2ZpbGVzLCBvciBv
dGhlciBpZGVudGl0eSBhdHRyaWJ1dGVzLCB1bmxlc3MgYSB2aWFibGU8YnI+DQpleGlzdGluZyBm
b3JtYXQgaXMgbm90IGF2YWlsYWJsZS48YnI+DQo8YnI+DQpUaGUgaW5pdGlhbCB3b3JrIHdpbGwg
Zm9jdXMgb24gdXNpbmcgSFRUUFMgZm9yIGNvbW11bmljYXRpb24gYmV0d2VlbiB0aGU8YnI+DQpj
bGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGFraW5nIGFkdmFudGFnZSBvZiBv
cHRpbWl6YXRpb248YnI+DQpmZWF0dXJlcyBvZiBIVFRQLzIgYW5kIEhUVFAvMyB3aGVyZSBwb3Nz
aWJsZSwgYW5kIHdpbGwgc3RyaXZlIHRvIGVuYWJsZTxicj4NCnNpbXBsZSBtYXBwaW5nIHRvIG90
aGVyIHByb3RvY29scyBzdWNoIGFzIENPQVAgd2hlbiBkb2luZyBzbyBkb2VzIG5vdDxicj4NCmNv
bmZsaWN0IHdpdGggdGhlIHByaW1hcnkgZm9jdXMuPGJyPg0KPGJyPg0KTWlsZXN0b25lcyB0byBp
bmNsdWRlOjxicj4NCi0gQ29yZSBkZWxlZ2F0aW9uIHByb3RvY29sPGJyPg0KLSBLZXkgcHJlc2Vu
dGF0aW9uIG1lY2hhbmlzbSBiaW5kaW5ncyB0byB0aGUgY29yZSBwcm90b2NvbCBpbmNsdWRpbmcg
VExTLDxicj4NCmRldGFjaGVkIEhUVFAgc2lnbmF0dXJlLCBhbmQgZW1iZWRkZWQgSFRUUCBzaWdu
YXR1cmVzPGJyPg0KLSBDb252ZXlhbmNlIG1lY2hhbmlzbXMgZm9yIGlkZW50aWZpZXJzIGFuZCBh
c3NlcnRpb25zPGJyPg0KLSBHdWlkZWxpbmVzIGZvciB1c2Ugb2YgcHJvdG9jb2wgZXh0ZW5zaW9u
IHBvaW50czxicj4NCi0gKGlmIG5lZWRlZCkgR3VpZGVsaW5lcyBvbiBtaWdyYXRpb24gcGF0aHMs
IGltcGxlbWVudGF0aW9uLCBhbmQgb3BlcmF0aW9uczxicj4NCjxicj4NCldoZXJlIHBvc3NpYmxl
LCB0aGUgZ3JvdXAgd2lsbCBzZWVrIHRvIG1ha2UgdXNlIG9mIHRvb2xzIHRvIGd1aWRlIGFuZCBp
bmZvcm08YnI+DQp0aGUgc3RhbmRhcmRpemF0aW9uIHByb2Nlc3MgaW5jbHVkaW5nIGZvcm1hbCBh
bmFseXNpcywgYXJjaGl0ZWN0dXJlIGRvY3VtZW50cyw8YnI+DQphbmQgdXNlIGNhc2UgZG9jdW1l
bnRzLiBUaGVzZSBhcnRpZmFjdHMgd2lsbCBub3QgYmUgY29uc2lkZXJlZCBhcyB3b3JraW5nPGJy
Pg0KZ3JvdXAgbWlsZXN0b25lcyBvciBkZWxpdmVyYWJsZXMuPGJyPg0KPGJyPg0KVGhlIHdvcmtp
bmcgZ3JvdXAgd2lsbCBjb29wZXJhdGUgYW5kIGNvb3JkaW5hdGUgd2l0aCBvdGhlciBJRVRGIFdH
cyBzdWNoIGFzPGJyPg0KT0FVVEgsIGFuZCB3b3JrIHdpdGggZXh0ZXJuYWwgb3JnYW5pemF0aW9u
cywgc3VjaCBhcyB0aGUgT3BlbklEIEZvdW5kYXRpb24sPGJyPg0KYXMgYXBwcm9wcmlhdGUuPGJy
Pg0KPGJyPg0KTWlsZXN0b25lczo8YnI+DQo8YnI+DQombmJzcDsgSnVsIDIwMjEgLSBDb3JlIGRl
bGVnYXRpb24gcHJvdG9jb2wgaW4gV0dMQzxicj4NCjxicj4NCiZuYnNwOyBPY3QgMjAyMSAtIEtl
eSBwcmVzZW50YXRpb24gbWVjaGFuaXNtIGJpbmRpbmcgdG8gdGhlIGNvcmUgcHJvdG9jb2wsIFRM
UywgdG88YnI+DQombmJzcDsgV0dMQzxicj4NCjxicj4NCiZuYnNwOyBPY3QgMjAyMSAtIEtleSBw
cmVzZW50YXRpb24gbWVjaGFuaXNtIGJpbmRpbmcgdG8gdGhlIGNvcmUgcHJvdG9jb2wsJm5ic3A7
PGJyPg0KJm5ic3A7IGRldGFjaGVkIEhUVFAgc2lnbmF0dXJlcywgdG8gV0dMQzxicj4NCjxicj4N
CiZuYnNwOyBPY3QgMjAyMSAtIEtleSBwcmVzZW50YXRpb24gbWVjaGFuaXNtIGJpbmRpbmcgdG8g
dGhlIGNvcmUgcHJvdG9jb2wsPGJyPg0KJm5ic3A7IGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlLCB0
byBXR0xDPGJyPg0KPGJyPg0KJm5ic3A7IERlYyAyMDIxIC0gR3VpZGVsaW5lcyBmb3IgdXNlIG9m
IHByb3RvY29sIGV4dGVuc2lvbiBwb2ludHMgdG8gV0dMQzxicj4NCjxicj4NCiZuYnNwOyBGZWIg
MjAyMiAtIEd1aWRlbGluZXMgb24gbWlncmF0aW9uIHBhdGhzLCBpbXBsZW1lbnRhdGlvbiwgYW5k
IG9wZXJhdGlvbnMgdG88YnI+DQombmJzcDsgJm5ic3A7V0dMQzxicj4NCjxicj4NCjxicj4NCjxi
cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
SUVURi1Bbm5vdW5jZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SUVURi1Bbm5v
dW5jZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklFVEYtQW5ub3VuY2VAaWV0Zi5vcmc8L2E+
PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRm
LWFubm91bmNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9pZXRmLWFubm91bmNlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIj48aW1nIGJvcmRl
cj0iMCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxMDAiIHN0eWxlPSJ3aWR0aDoxLjA0MTZpbjtoZWln
aHQ6MS4wNDE2aW4iIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iY2lkOn5XUkQwMDAuanBnIiBhbHQ9
IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hp
dGUiPuGQpzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPi0tJm5ic3A7PGJy
Pg0KVHhhdXRoIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86VHhhdXRo
QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VHhhdXRoQGlldGYu
b3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5r
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3R4YXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KVHhhdXRoIG1haWxpbmcg
bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5UeGF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_e1a8197a96a24e229ed1ec956394337acertorg_--

--_004_e1a8197a96a24e229ed1ec956394337acertorg_
Content-Type: image/jpeg; name="~WRD000.jpg"
Content-Description: ~WRD000.jpg
Content-Disposition: inline; filename="~WRD000.jpg"; size=823;
 creation-date="Mon, 06 Jul 2020 12:44:09 GMT";
 modification-date="Mon, 06 Jul 2020 12:44:09 GMT"
Content-ID: <~WRD000.jpg>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a
HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigD//2Q==

--_004_e1a8197a96a24e229ed1ec956394337acertorg_--


From nobody Mon Jul  6 07:34:32 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 C02723A1585 for ; Mon,  6 Jul 2020 07:34:22 -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_REMOTE_IMAGE=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=readycomputing.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 sx4nNJyyZUt5 for ; Mon,  6 Jul 2020 07:34:17 -0700 (PDT)
Received: from mail-qv1-xf44.google.com (mail-qv1-xf44.google.com [IPv6:2607:f8b0:4864:20::f44]) (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 1C5183A15CA for ; Mon,  6 Jul 2020 07:34:16 -0700 (PDT)
Received: by mail-qv1-xf44.google.com with SMTP id m9so17293790qvx.5 for ; Mon, 06 Jul 2020 07:34:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=readycomputing.com; s=google; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=C1FGV0iwJ6+TNoTrj/fLNTA72TrbeZxuXkgBLeDAWto=; b=TLkGcUu27hGRr8SJE1rwMj6RU9lZbjxiAIFSjTMnUEZrZYfAepAQta8Qp2zbQdnFBD yHstliSuzNui/K9HmI8XOsaPGF82iht7aJHSXx06B5RVc5ljkRlFhJ+AD5CXpWOCKXW4 5pDHv+rCtc8WNyXZL9Sgk9F0MuAnoCDKQ4GgIbEctdquBEC0Q/eBzJRYlIFFtVWr1Oh6 tqMKalW06RCdOhKBGFMqrOapfFyOtbFEmYPxggB0jViluiZoqQM8LumJdykbv4zrBFj/ TF+RAktIOJN7SIrHoy+LExcDI2p4MDsURkuILxI5ue4QZ9uO8zBAUSQU4JlbxA2YzUNr DKOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=C1FGV0iwJ6+TNoTrj/fLNTA72TrbeZxuXkgBLeDAWto=; b=CurepcjbIESKsipwJfNAZA8Y04fKMi28JromSPzdRWHbgcIJ7t5O363o6//1Lgcd0e 12tAfqq4CZyOUdVgmPRd9bB5+BV4nccAIJnLssFbtACRun9/XFsWjo+F3IbtpduEj5Tr E5WOUq0aFHYaa5eImdeWQTFrQv/qxCV4kx+2MzMLh6Lvfsab4WytymJOCNSopom3W07a UtSaWHwZJXD9Nvpr2PBtVvO4u3aqC95ku0o8WeI/WhlE/qDSbRxWbQ70hK6/31WZ+FGJ 7dCod7Sd1k66YoR262EBfZ9H9BkX3sm53ugDDAZh9plndbh1UA5J2YC4FGoutqRblQbB 07hg==
X-Gm-Message-State: AOAM533YGQKuD0t7k1rVzXT4V6E3FBPMP3DLyQSVpapppshH4Dw89cZO sNLWuorARKqzdxLIehWdL6j2dHS1O72etpItRhIpURsEbL4KyZeuBEtSCV73h6F+L+kFtm3Flet 4NfT2Qnk7MBlQKNFladR0TtkjxJXOukSA/2PMfCv6i7K5y8etsRkcdFUq6BZmCMVCmvKlWSEqOw ==
X-Google-Smtp-Source: ABdhPJwYD5fqDXgZUGoqS7UI1fHt19X750SE7KT/7Dg1COGoVj3JTtf3gqRMHJfmiFbteABs7NPLtA==
X-Received: by 2002:a0c:ab55:: with SMTP id i21mr48324658qvb.139.1594046055597;  Mon, 06 Jul 2020 07:34:15 -0700 (PDT)
Received: from ?IPv6:2607:fea8:aa20:59d:9ce4:29ad:3cfe:46ff? ([2607:fea8:aa20:59d:9ce4:29ad:3cfe:46ff]) by smtp.googlemail.com with ESMTPSA id r185sm20434423qkb.39.2020.07.06.07.34.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jul 2020 07:34:14 -0700 (PDT)
From: David Pyke 
X-Google-Original-From: David Pyke 
To: Justin Richer , Tom Jones 
Cc: txauth@ietf.org
References:   <3b8d3690-47e2-ff00-1065-29647d18555b@readycomputing.com>  <00827624-7361-4c5f-b34f-0edc8f7493dc@readycomputing.com>  <5AA3C0D4-A250-4EFB-B3E9-F71E8BD959A6@mit.edu>
Message-ID: <7d8f8a78-01c9-ec27-b5d3-d03b7fb9a159@readycomputing.com>
Date: Mon, 6 Jul 2020 10:34:13 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <5AA3C0D4-A250-4EFB-B3E9-F71E8BD959A6@mit.edu>
Content-Type: multipart/alternative; boundary="------------DC301C5DBBAFD238E6E4F0EE"
Content-Language: en-CA
Archived-At: 
Subject: Re: [Txauth] Possible Use Case for GNAP
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, 06 Jul 2020 14:34:30 -0000

This is a multi-part message in MIME format.
--------------DC301C5DBBAFD238E6E4F0EE
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

Those are exactly the issues I was facing.=C2=A0 While I can make the hops=
=20
independent, they need to be chained so that everything is traceable.=C2=A0=
=C2=A0=20
It's possible but ugly with OAuth.

On 2020-07-02 3:34 p.m., Justin Richer wrote:
> If we look at each hop as a separately authorized request, could we=20
> define them in a way that they=E2=80=99re chained from each other down th=
e=20
> line? Maybe it would be possible for the root HIN to get a new token=20
> for each of the downstream HINs, but this new token is in the context=20
> of the first one
--=20

*David Pyke*

Manager, Strategic Consulting

---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------

Logo 

LinkedIn icon  Twitter=20
icon  Youtbue icon=20


=09

Office: +1 212 877 3307 x5001

_david.pyke@readycomputing.com _

_www.readycomputing.com _

150 Beekman Street, Floor 3, New York, NY 10038


The information in this e-mail communication together with any=20
attachments is intended only for the person or entity to which it is=20
addressed and may contain confidential and/or privileged material. If=20
you are not the intended recipient of this communication, please notify=20
us immediately. Any views expressed in this communication are those of=20
the sender, unless otherwise specifically stated. Ready Computing does=20
not represent, warrant or guarantee that the integrity of this=20
communication has been maintained or the communication is free of=20
errors, virus or interference.


--=20
This is not a secure transmission. The information contained in this=20

transmission is highly prohibited from containing privileged and=20

confidential information, including patient information protected by=20

federal and state privacy laws. It is intended only for the use of the=20

person(s) named above. If you are not the intended recipient, you are=20

hereby notified that any review, dissemination, distribution, or=20

duplication of this communication is strictly prohibited. If you are not
=20
the intended recipient, please contact the sender by reply email and=20

destroy all copies of the original message.
                       =20

--------------DC301C5DBBAFD238E6E4F0EE
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Those are exactly the issues I was facing.=C2=A0 W=
hile
        I can make the hops independent, they need to be chained so that
        everything is traceable.=C2=A0=C2=A0 It's possible but ugly with OA=
uth.

    

    
On 2020-07-02 3:34 p.m., Justin Richer
      wrote:

    

    
If we look
      at each hop as a separately authorized request, could we define
      them in a way that they=E2=80=99re chained from each other down the l=
ine?
      Maybe it would be possible for the root HIN to get a new token for
      each of the downstream HINs, but this new token is in the context
      of the first one

    
-- 

      
      
      
      
      

        

          
            

              
                

                  David Pyke
              

            

            

              
                

                  Manager,
                    Strategic Consulting

              		
            

            

              
                
 ---------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------------------------------------------------------------------<=
/p>
              

            

            

              
                

                  3D"Logo"

                

                  3D"LinkedIn 3D"Twitter 3D"Youtbue

              		
              
                
Offi=
ce:
                    +1 212 877 3307 x5001

                

                  
                    

                      
                        

                          
                                david.pyke@readycomputing.com

                        

                          
                                www.readycomputing.com

                      		
                    

                    

                      
                        
150
                            Beekman Street, Floor 3, New York, NY 10038

                      		
                    

                    

                      

                      		
                    

                  
                

              		
            

            

              
                

                  The
                    information in this e-mail communication together
                    with any attachments is intended only for the person
                    or entity to which it is addressed and may contain
                    confidential and/or privileged material. If you are
                    not the intended recipient of this communication,
                    please notify us immediately. Any views expressed in
                    this communication are those of the sender, unless
                    otherwise specifically stated. Ready Computing does
                    not represent, warrant or guarantee that the
                    integrity of this communication has been maintained
                    or the communication is free of errors, virus or
                    interference.

              		
            

          
        

      

    

  




This is not a secure transmission. The information contained in this=20
transmission is highly prohibited from containing privileged and=20
confidential information, including patient information protected by=20
federal and state privacy laws. It is intended only for the use of the=20
person(s) named above. If you are not the intended recipient, you are=20
hereby notified that any review, dissemination, distribution, or=20
duplication of this communication is strictly prohibited. If you are not
 the intended recipient, please contact the sender by reply email and=20
destroy all copies of the original message.
                       
--------------DC301C5DBBAFD238E6E4F0EE--


From nobody Mon Jul  6 07:35: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 E56463A157E for ; Mon,  6 Jul 2020 07:35:55 -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=cert.org
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 IZDQbzTta_qP for ; Mon,  6 Jul 2020 07:35:52 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 538D13A1574 for ; Mon,  6 Jul 2020 07:35:51 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 066EZlLB018448; Mon, 6 Jul 2020 10:35:47 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 066EZlLB018448
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1594046147; bh=LPUrTs/A04q1JW5T8HQ7r+wS8+sNzM/rpE0UxypK5V4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=opJ1UbRsGo4ezlY+O48JFKeNloqY2cDrH1gFOWNfdnTnXqbLzucA6t8oWufHykBJf BHPyKzVLFwTf66fr/HpdorN0dVcxXj9HY/rIdbcRjAMnEnIggtQA7bU7wYb1uzoTP1 lJuiKFbYkcLupeo0z3wYhVP20j6hcEsVmwTvD/KY=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 066EZkj5009602; Mon, 6 Jul 2020 10:35:46 -0400
Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 6 Jul 2020 10:35:46 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 6 Jul 2020 10:35:46 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Mon, 6 Jul 2020 10:35:46 -0400
From: Roman Danyliw 
To: Dick Hardt , Denis 
CC: Nat Sakimura , "txauth@ietf.org" 
Thread-Topic: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
Thread-Index: AQHWS9RNiDy30JPhzE2lVpUcI/9MaqjrXPEAgAAQEoCABAYNgIAFbXIAgAEAHICAARM1gIADnf7w
Date: Mon, 6 Jul 2020 14:35:45 +0000
Message-ID: <731a364a19a74e1d982d59d9c441dc0a@cert.org>
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com>     <3c21e0fa-5636-54fe-675f-abc5b41ab09e@free.fr> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.202.182]
Content-Type: multipart/alternative; boundary="_000_731a364a19a74e1d982d59d9c441dc0acertorg_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 06 Jul 2020 14:35:56 -0000

--_000_731a364a19a74e1d982d59d9c441dc0acertorg_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGVsbG8hDQoNCknigJltIHRvcC1wb3N0aW5nIGhlcmUgYmVjYXVzZSB0aGVyZSBpcyBubyBlYXN5
IHdheSBmb3IgbWUgdG8gY2xlYW5pbmcgaW5zZXJ0IG15IHByb2Nlc3MgY29tbWVudC4gIEkgdGhp
bmsgd2UgYXJlIGhhdmluZyBhIG5lY2Vzc2FyeSBjb252ZXJzYXRpb24gYmVsb3cgYW5kIGluIG5v
IHdheSBzaG91bGQgaXQgc3RvcCBiZWNhdXNlIG9mIHRoaXMgbm90ZS4NCg0KQXMgYSBwcm9jZXNz
IGNoZWNrLCB0aGlzIHRocmVhZCBzdGFydGVkIHdpdGggYSByZXF1ZXN0IGZvciBjb21tdW5pdHkg
cmV2aWV3IG9uIHRoZSBjaGFydGVyIHRleHQgWzFdLiAgQW1vbmcgb3RoZXIgdGhpbmdzLCB0aGlz
IGNoYXJ0ZXIgcmV2aWV3IGlzIHRyeWluZyB0byBlbnN1cmUgdGhlIHByb2JsZW0gaXMgY2xlYXIs
IGRlZmluZXMgdGhlIGJvdW5kcyBvZiB0aGUgZGVzaXJlZCBzb2x1dGlvbnMgYW5kIGlkZW50aWZp
ZXMgY3JpdGljYWwgb2JqZWN0aW9ucyBmcm9tIHRoZSBjb25zZW5zdXMtZGVyaXZlZCB0ZXh0LiAg
VGhlIHRleHQgaXMgbm90IGludGVuZGVkIHRvIGRlZmluZSBkZXRhaWxlZCByZXF1aXJlbWVudHMv
YXJjaGl0ZWN0dXJlLCByZXNvbHZlIHRyYWRlb2Zmcywgb3IgdG8gc3BlY2lmeSBhIHNvbHV0aW9u
LCB1bmxlc3MgdGhleSBhcmUgY3JpdGljYWwgdG8gYm91bmRpbmcgdGhlIHNvbHV0aW9uLiAgVGhl
c2UgZGV0YWlscyBzaG91bGQgYmUgbGVmdCB0byBmdXR1cmUgZGlzY3Vzc2lvbnMgb2YgYSBjaGFy
dGVyZWQgV0cgKG5vdCB0aGF0IHRoZXkgY2Fu4oCZdCBzdGFydCBub3cgaW4gcGFyYWxsZWwpLiAg
QWRkaXRpb25hbGx5LCBhcyBhIHJlbWluZGVyLCB3aGlsZSB0aGVyZSBhcmUgbXVsdGlwbGUgaW5k
aXZpZHVhbCBkcmFmdHMgd2l0aCBwcm9wb3NlZCBzb2x1dGlvbnMgaW4gdGhlIGRhdGF0cmFja2Vy
LCB0aGUgZGVzaWduIGRlY2lzaW9ucyB0aGV5IG1ha2UgYXJlIG5vdCBwYXJ0IG9mIHRoZSBjaGFy
dGVyIGFuZCB0aGVpciBhZG9wdGlvbiBpcyBub3QgYXNzdW1lZCBieSB0aGUgY2hhcnRlci4gIElm
IHRoZXJlIGFyZSBrZXkgZGVzaWduIGVsZW1lbnRzIGluIHRob3NlIG9yIGFueSBvdGhlciBkb2N1
bWVudHMgdGhhdCBpcyBmZWx0IHRvIGJlIGNydWNpYWwgdG8gc2NvcGluZyB0aGUgV0csICB3ZSBu
ZWVkIHRvIGNhcHR1cmUgdGhlIHRoaW5raW5nLCBnZW5lcmFsaXplIGl0IChhcyBhcHByb3ByaWF0
ZSksIGFuZCBhZGQgaXQgdG8gdGhlIGNoYXJ0ZXIgdGV4dCBleHBsaWNpdGx5IG9yIGJ5IHJlZmVy
ZW5jZS4NCg0KTGV04oCZcyBjb250aW51ZSB0byB0YWxrIGFib3V0IHRoZSB0ZWNobmljYWwgZGV0
YWlscyBvZiB0aGUgdXNlIGNhc2VzLCBkZXNpZ24gcHJvcGVydGllcywgY29uc3RyYWludHMgYW5k
IGNhbmRpZGF0ZSBzb2x1dGlvbnMuICBBZGRpdGlvbmFsbHksIGdpdmVuIHRoZSAtMDUgY2hhcnRl
ciB0ZXh0IGFuZCBtaWxlc3RvbmVzIFsyXSwgaXQgd291bGQgYmUgaGVscGZ1bCB0byB1bmRlcnN0
YW5kIHdoYXQgb3V0c3RhbmRpbmcgY29uY2VybnMgcmVtYWluIHdpdGggdGhlIGNoYXJ0ZXIgdGV4
dCBpbiBwcmVwYXJhdGlvbiBmb3IgdGhlIFRodXJzZGF5LCBKdWx5IDl0aCB0ZWxlY2hhdCB3aGVy
ZSB0aGUgSUVTRyB3aWxsIHVzZSBjb21tdW5pdHkgZmVlZGJhY2sgdG8gaGVscCBkZWNpZGUgdGhl
IHdheSBhaGVhZCBmb3IgdGhpcyBwcm9wb3NlZCBXRy4NCg0KUm9tYW4NCg0KWzFdIGh0dHBzOi8v
bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHhhdXRoLzRuRThydHlSUHRkazBGcmNsUTFj
LUZXTU84dy8NClsyXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWll
dGYtZ25hcC8NCg0KDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9u
IEJlaGFsZiBPZiBEaWNrIEhhcmR0DQpTZW50OiBGcmlkYXksIEp1bHkgMywgMjAyMCA5OjQxIFBN
DQpUbzogRGVuaXMgPGRlbmlzLmlldGZAZnJlZS5mcj4NCkNjOiBOYXQgU2FraW11cmEgPHNha2lt
dXJhQGdtYWlsLmNvbT47IHR4YXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUeGF1dGhdIFdH
IFJldmlldzogR3JhbnQgTmVnb3RpYXRpb24gYW5kIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgKGdu
YXApDQoNCisgTmF0IGFzIGhlIGlzIG1lbnRpb25lZA0KLSBJRVNHDQoNCk9uIEZyaSwgSnVsIDMs
IDIwMjAgYXQgMjoxNiBBTSBEZW5pcyA8ZGVuaXMuaWV0ZkBmcmVlLmZyPG1haWx0bzpkZW5pcy5p
ZXRmQGZyZWUuZnI+PiB3cm90ZToNCkhlbGxvIERpY2ssDQoNCkNhdGNoaW5nIHVwIG9uIHRoaXMg
ZW1haWwgLi4uIGNvbW1lbnRzIGluc2VydGVkIC4uLg0KDQpPbiBNb24sIEp1biAyOSwgMjAyMCBh
dCAxMjowNiBBTSBEZW5pcyA8ZGVuaXMuaWV0ZkBmcmVlLmZyPG1haWx0bzpkZW5pcy5pZXRmQGZy
ZWUuZnI+PiB3cm90ZToNCkhlbGxvIERpY2ssDQoNCkRlbmlzLCB0aGFua3MgZm9yIHNoYXJpbmcg
eW91ciB0aG91Z2h0cywgc29tZSBjbGFyaWZpY2F0aW9ucyBvbiB5b3VyIHN0YXRlbWVudHMgaW5z
ZXJ0ZWQ6DQoNCk9uIEZyaSwgSnVuIDI2LCAyMDIwIGF0IDk6NDIgQU0gRGVuaXMgPGRlbmlzLmll
dGZAZnJlZS5mcjxtYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyPj4gd3JvdGU6DQo8c25pcD4NCg0K
TmV3IHByb3Bvc2VkIGNoYXJ0ZXINCjxzbmlwPg0KDQpSZXNvdXJjZSBzZXJ2ZXJzIGluZm9ybSB0
aGVpciBjbGllbnRzIGFib3V0IHdoaWNoIGFjY2VzcyB0b2tlbiBmb3JtYXRzIGFyZSBhY2NlcHRh
YmxlIGFuZCBkZXBlbmRpbmcgdXBvbiB0aGUga2luZyBvZiBvcGVyYXRpb24NCnRoYXQgaXMgcmVx
dWVzdGVkLCB3aGljaCBraW5kIG9mIGF0dHJpYnV0ZXMgYXJlIG5lZWRlZCBhbmQgZnJvbSB3aGlj
aCBBU3MgdGhhdCBteSBiZSBvYnRhaW5lZC4NCldoaWxlIGF0IHRpbWVzIHRoaXMgbWF5IGJlIGFw
cHJvcHJpYXRlLCBhdCBvdGhlciB0aW1lcyBkaXNjbG9zaW5nIHRoZSBhdHRyaWJ1dGVzIHRoZSBS
UyByZXF1aXJlcyBpcyBub3QgbmVlZGVkIGJ5IHRoZSBjbGllbnQuDQpGb3IgZXhhbXBsZSwgYW4g
ZW50ZXJwcmlzZSBjbGllbnQgYWNjZXNzaW5nIGEgcmVzb3VyY2UgZG9lcyBub3QgbmVlZCB0byBr
bm93IHdoaWNoIGdyb3VwcyBhIHVzZXIgYmVsb25ncyB0bywNCmJ1dCB0aGUgUlMgbWF5IHJlcXVp
cmUgdGhhdCB0byBkZXRlcm1pbmUgaWYgdGhlIHVzZXIgcnVubmluZyB0aGUgY2xpZW50IGhhcyBh
Y2Nlc3MuDQoNCkFzIHNvb24gYXMgdGhlcmUgaXMgYSBkZXNpcmUgdG8gaW1wbGVtZW50IHByaXZh
Y3kgYnkgZGVmYXVsdCwgdGhlIGNsaWVudCBzaG91bGQgbm90IHByb3ZpZGUgbW9yZSBhdHRyaWJ1
dGVzIHRoYW4gc3RyaWN0bHkgbmVjZXNzYXJ5Lg0KRXZlbiBhZnRlciB0aHJlZSByZWFkaW5ncyBv
ZiB5b3VyIGV4YW1wbGUsIEkgZmFpbGVkIHRvIHVuZGVyc3RhbmQgaXQuDQoNCkEgbWFqb3IgZGlm
ZmVyZW5jZSB3aXRoIE9BdXRoIDIuMCBpcyB0aGF0IHRoZXJlIGlzIG5vIGJpbGF0ZXJhbCB0cnVz
dCByZWxhdGlvbnNoaXAgYmV0d2VlbiBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgYSByZXNv
dXJjZSBzZXJ2ZXI6DQpmb3IgYSBnaXZlbiBjYXRlZ29yeSBvZiBhdHRyaWJ1dGVzLCBhIHJlc291
cmNlIHNlcnZlciBtYXkgdHJ1c3Qgb25lIG9yIG1vcmUgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzLiBB
bm90aGVyIG1ham9yIGRpZmZlcmVuY2Ugd2l0aCBPQXV0aCAyLjAuDQppcyB0aGF0IHRoZSBjb250
ZW50IG9mIGFuIGF0dHJpYnV0ZXMgdG9rZW4gaXMgbWVhbnQgdG8gYmUgYWNjZXNzaWJsZSB0byB0
aGUgY2xpZW50Lg0KVGhpcyBpcyBub3QgaG93IE9BdXRoIDIuMCB3b3Jrcy4gU2VlIHNsaWRlcyA3
IGFuZCA4IGZyb20gbXkgb3JpZ2luYWwgSUVURiBwcmVzZW50YXRpb24gb24gd2hhdCBiZWNhbWUg
T0F1dGggMi4wDQoNCmh0dHBzOi8vd3d3LnNsaWRlc2hhcmUubmV0L2d1ZXN0ZTY0OGIvaWV0Zi03
Ny1vYXV0aC13cmFwLXByZXNlbnRhdGlvbg0KDQpJIGxvb2tlZCBhdCB0aGUgdHdvIHNsaWRlcy4N
Cg0KVW5mb3J0dW5hdGVseSBzbGlkZSA3IGhhcyBqdXN0IG9uZSBhcnJvdyB3aXRoIHRoZSB3b3Jk
ICJ0cnVzdCIuIFRoaXMgaXMgaW5zdWZmaWNpZW50IHRvIHVuZGVyc3RhbmQgd2hhdCBpcyBtZWFu
dCB1bmxlc3MgYmVpbmcgcHJlc2VudA0KYXQgdGhlIHByZXNlbnRhdGlvbi4gRG9lcyBpdCBtZWFu
IHRoYXQgdGhlIFBSIChSUykgdHJ1c3RzIG9uZSBBUyBvciB0aGF0IGl0IG1heSB0cnVzdCBtdWx0
aXBsZSBBU3MgPw0KDQpVbmZvcnR1bmF0ZWx5IHNsaWRlIDggaGFzIGp1c3Qgb25lIGFycm93IGJl
dHdlZW4gdGhlIFBSIGFuZCB0aGUgQVMgd2hpY2ggaXMgcmVkLWNyb3NzZWQgYnV0IG5vIHRleHQg
YXQgYWxsLiBUaGlzIGlzIGluc3VmZmljaWVudCB0byB1bmRlcnN0YW5kDQp3aGF0IGlzIG1lYW50
IHVubGVzcyBiZWluZyBwcmVzZW50IGF0IHRoZSBwcmVzZW50YXRpb24uIERvZXMgaXQgbWVhbiB0
aGF0IHRoZSBQUiBhbmQgdGhlIEFTIG5ldmVyIGNvbW11bmljYXRlIGRpcmVjdGx5ID8NCkRvZXMg
aXQgbWVhbiB0aGF0IHRoZXkgaGF2ZSBubyByZWxhdGlvbnNoaXBzIGF0IGFsbCwgYmVzaWRlcyB0
aGUgb25lIHdheSB0cnVzdCByZWxhdGlvbnNoaXAgbWVudGlvbmVkIGluIHNsaWRlIDcgPw0KDQpT
byBpdCBoYXJkIHRvIHNheSB3aGV0aGVyIHRoZXNlIHR3byBzbGlkZXMgYXJlIGluZGVlZCBtZWFu
aW5nIHRoYXQgdGhlcmUgaXMgbm8gYmlsYXRlcmFsIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGFuIGF1
dGhvcml6YXRpb24gc2VydmVyIGFuZCBhIHJlc291cmNlIHNlcnZlci4NCkFwb2xvZ2llcyBmb3Ig
bm90IHByb3ZpZGluZyBhbiBleHBsYW5hdGlvbiBvbiB0aGUgc2xpZGVzLg0KDQpTbGlkZSA3IHNo
b3dzIHRoYXQgdHJ1c3QgYmV0d2VlbiB0aGUgQVMgYW5kIFBSIChub3cgUlMpIHdhcyB1bmlkaXJl
Y3Rpb25hbCwgZnJvbSB0aGUgUlMgdG8gdGhlIEFTLg0KU2xpZGUgOCBpbmRpY2F0ZXMgdGhhdCB0
cnVzdCBpcyBub3QgYmlkaXJlY3Rpb25hbC4NCg0KW0RlbmlzXSAgLi4uIHdoaWNoIG1lYW5zIHRo
YXQgc2xpZGUgOCBjb250cmFkaWN0cyBzbGlkZSA3LiAgOi0pDQoNClNsaWRlIDggc2F5cyBpdCBk
b2VzIG5vdCBnbyBib3RoIHdheXMuIFNsaWRlIDcgc2F5cyBpdCBnb2VzIG9uZSB3YXkuIEkgZG9u
J3Qgc2VlIHRoZSBjb250cmFkaWN0aW9uLg0KDQpJIHdvdWxkIGhhdmUgcHJlZmVycmVkIHRoYXQg
eW91IG1lYW50OiB0aGUgUlMgYW5kIHRoZSBBUyBuZXZlciBjb21tdW5pY2F0ZSBkaXJlY3RseSwg
d2hpY2ggaXMgaW5kZWVkIGEgbmljZSBwcm9wZXJ0eSB0byBmb2xsb3cNCnRvIGVuc3VyZSB0aGUg
dXNlcidzIHByaXZhY3kuDQpUaGF0IGlzIG9uZSBtb2RlbC4gT3RoZXIgbW9kZWxzIGFyZSBhcHBy
b3ByaWF0ZSBpbiBvdGhlciBjaXJjdW1zdGFuY2VzLi4NCg0KDQoNClRoZXJlIGlzIG5vIGxpbWl0
IG9uIGhvdyBtYW55IEFTcyBhbiBSUyBtYXkgdHJ1c3QuDQoNCltEZW5pc10gVGhpcyBpcyBmaW5l
Lg0KIE9uIEp1bmUgMTIsIE5hdCBTYWtpbXVyYSByZWNlbnRseSBhbnN3ZXJlZCB0byBhbiBlbWFp
bCB3aXRoIHRoZSBmb2xsb3dpbmcgdG9waWM6DQpSZTogW09BVVRILVdHXSBDb21tZW50cyBvbiBk
cmFmdC1pZXRmLW9hdXRoLWp3c3JlcS0yMiAoVGhlIE9BdXRoIDIuMCBBdXRob3JpemF0aW9uIEZy
YW1ld29yazogSldUIFNlY3VyZWQgQXV0aG9yaXphdGlvbiBSZXF1ZXN0KSkNCk15IGFyZ3VtZW50
cyB3ZXJlOg0KICAgICBUaGUgb3JpZ2luYWwgbW9kZWwgZm9yIE9BdXRoIHdhcyBtYWtpbmcgdGhl
IGFzc3VtcHRpb24gdGhhdCB0aGUgQVMgYW5kIHRoZSBSUyBoYWQgYSBzdHJvbmcgYmlsYXRlcmFs
IHJlbGF0aW9uc2hpcC4NCg0KICAgICAgQSBrZXkgcXVlc3Rpb24gaXMgd2hldGhlciBzdWNoIHN0
cm9uZyByZWxhdGlvbnNoaXAgd2lsbCBiZSBtYWludGFpbmVkIGZvciBldmVyIG9yDQogICAgIHdo
ZXRoZXIgaXQgd2lsbCBiZSBhbGxvd2VkIHRvIHBlcmZvcm0gc29tZSBldm9sdXRpb25zIG9mIHRo
aXMgcmVsYXRpb25zaGlwLg0KDQogICAgIEluIG9yZGVyIHRvIHJlc3BlY3QgdGhlIHByaXZhY3kg
b2YgdGhlIHVzZXJzLCB0aGVyZSBpcyB0aGUgbmVlZCB0byBlbmNvbXBhc3Mgb3RoZXIgc2NlbmFy
aW9zLiBPbmUgb2YgdGhlc2Ugc2NlbmFyaW9zIGlzIHRoYXQgdGhlIEFTIGFuZCB0aGUgUlMNCiAg
ICAgZG8gbm90IG5lZWQgYW55IGxvbmdlciB0byBoYXZlIHN1Y2ggYSBzdHJvbmcgcmVsYXRpb25z
aGlwLiBJbiB0ZXJtcyBvZiB0cnVzdCByZWxhdGlvbnNoaXBzLCBhIFJTIHNpbXBseSBuZWVkcyB0
byB0cnVzdCB0aGUgYWNjZXNzIHRva2VucyBpc3N1ZWQgYnkgYW4gQVMuDQogICAgIFRoZSBBUyBk
b2VzIGhhdmUgYW55IG1vcmUgYSAibmVlZCB0byBrbm93IiBvZiBhbGwgdGhlIFJTcyB0aGF0IGFy
ZSBhY2NlcHRpbmcgaXRzIGFjY2VzcyB0b2tlbnMuIFRoaXMgd291bGQgYmUgYSBtYWpvciBzaW1w
bGlmaWNhdGlvbiBvZiB0aGUgY3VycmVudCBnbG9iYWwgYXJjaGl0ZWN0dXJlLg0KTmF0J3MgcG9z
aXRpb24gd2FzOg0KIk15IHRha2UgaXMgdGhhdCB0aGUgYmFzaWMgYXNzdW1wdGlvbiBvZiBPQXV0
aCAyLjAgRnJhbWV3b3JrIGlzIHRoYXQgdGhlcmUgaXMgYSBzdHJvbmcgcmVsYXRpb25zaGlwIGJl
dHdlZW4gQVMgYW5kIFJTLg0KSSBmZWVsIHRoYXQgaXQgaXMgcXVpdGUgdW5yZWFsaXN0aWMgdGhh
dCBhbiBSUyB3b3VsZCB0cnVzdCB0aGUgYWNjZXNzIHRva2VuIGlzc3VlZCBieSBhbiBBUyB0aGF0
IGl0IGhhcyBubyBzdHJvbmcgcmVsYXRpb25zaGlwIHdpdGgiLg0KVGhlcmUgYXJlIGluZGVlZCBk
aWZmZXJlbnQgcG9zaXRpb25zIG9uIHRoaXMgdG9waWMuDQoNCkkgZG9uJ3QgdGhpbmsgTmF0IGFu
ZCBJIGhhdmUgZGlmZmVyZW50IG9waW5pb25zLCBidXQgSSB3aWxsIGxldCBOYXQgY2xhcmlmeS4N
Ckp1c3QgYmVjYXVzZSB0aGVyZSBpcyBhIHN0cm9uZyByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUg
QVMgYW5kIFJTLCBkb2VzIG5vdCBtZWFuIGl0IGlzIGJpZGlyZWN0aW9uYWwuIEkgd291bGQgdW5k
ZXJzdGFuZA0KDQoiSSBmZWVsIHRoYXQgaXQgaXMgcXVpdGUgdW5yZWFsaXN0aWMgdGhhdCBhbiBS
UyB3b3VsZCB0cnVzdCB0aGUgYWNjZXNzIHRva2VuIGlzc3VlZCBieSBhbiBBUyB0aGF0IGl0IGhh
cyBubyBzdHJvbmcgcmVsYXRpb25zaGlwIHdpdGgiDQoNCnRvIGluZGljYXRlIE5hdCBpcyBleHBl
Y3RpbmcgdGhlIHRydXN0IHRvIGJlIGZyb20gdGhlIFJTIHRvIHRoZSBBUy4NCg0KW0RlbmlzXSAg
U3BlYWtpbmcgb2YgYSAic3Ryb25nIHJlbGF0aW9uc2hpcCIgaXMgYW1iaWd1b3VzLiBUaGUga2V5
IHBvaW50IGJlaW5nIHdoZXRoZXIgdGhlIHJlbGF0aW9uc2hpcCBpcyB1bmlsYXRlcmFsIG9yIGJp
bGF0ZXJhbC4NClRoZXJlIGlzIG5vIG5lZWQgdG8gdXNlIHRoZSB3b3JkaW5nICJzdHJvbmcgcmVs
YXRpb25zaGlwIiB3aGVuIHRoZSByZWxhdGlvbnNoaXAgaXMgb25seSB1bmlsYXRlcmFsOiBhIFJT
IHNpbXBseSB0cnVzdHMgYW4gQVMgZm9yIHRoZSBhY2Nlc3MgdG9rZW5zIGl0IGlzc3Vlcy4NCklu
IHN1Y2ggYSBjYXNlLCB0aGlzIGRvZXMgbm90IG1lYW4gdGhhdCBhbiBBUyBpcyBrbm93aW5nIGFs
bCB0aGUgUlNzIHRoYXQgYXJlIHRydXN0aW5nIGl0Lg0KDQpPbiB0aGUgY29udHJhcnksIGEgc3Ry
b25nIChiaS0pcmVsYXRpb25zaGlwIGlzIHdoZW4gYSBSUyBhbmQgYW4gQVMgYm90aCBhZ3JlZSBi
ZXR3ZWVuIHRoZW0gYWJvdXQgdGhlIG1lYW5pbmcgb2Ygc2NvcGUgcGFyYW1ldGVycy4NClRoaXMg
aXMgYSB0eXBpY2FsIGNhc2UgZm9yIE9BdXRoIDIuMC4NCllvdSBjYW4gYXNrIE5hdCB3aGF0IGhl
IG1lYW50IGJ5ICJzdHJvbmcgcmVsYXRpb25zaGlwIg0KDQpUaGUgQVMgaXMgc3RhdGluZyB3aGF0
IGEgc2NvcGUgbWVhbnMgdG8gaXQgYW5kIHRoZSB1c2VyLi4gVGhlIFJTIGNhbiBkbyB3aGF0ZXZl
ciBpdCB3YW50cy4gSSBkb24ndCBzZWUgdGhhdCBhcyByZXF1aXJpbmcgYSBiaWRpcmVjdGlvbmFs
IHJlbGF0aW9uc2hpcC4NCg0KDQoNCg0KDQoNClRoZSBBUyBtYXkgbm90IGV2ZW4ga25vdyB3aG8g
dGhlIFJTIChvciBQUiBpbiB0aGUgc2xpZGVzKSBpcy4NCg0KPHNuaXA+DQoNCkkgZ290IHJpZCBv
ZiB0aGUgd29yZCAiZGVsZWdhdGlvbiI6IHRoZSBjbGllbnQgZG9lcyBub3QgZGVsZWdhdGUgYW55
dGhpbmcgdG8gYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIElmIGl0IHdvdWxkLCB0aGlzIHdvdWxk
IG1lYW4gdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXINCndvdWxkIGJlIGFibGUgdG8gYWN0
IGFzIHRoZSBjbGllbnQgYW5kIGNvdWxkIGtub3cgZXZlcnl0aGluZyB0aGF0IHRoZSBjbGllbnQg
d2lsbCBkbywgd2hpY2ggY29tZXMgaW50byBjb250cmFkaWN0aW9uIHdpdGggdGhlIHVzZXIncyBw
cml2YWN5Lg0KDQpUaGUgYWJvdmUgaXMgbm90IHRydWUuDQoNClRoZSBSZXNvdXJjZSBPd25lciBp
cyBkZWxlZ2F0aW5nIGFjY2VzcyBjb250cm9sIHRvIHRoZSBBUyBpbiBhdXRob3JpemF0aW9uIHVz
ZSBjYXNlcy4NCg0KVGhlIE9BdXRoIDIuMCBtb2RlbCBkb2VzIG5vdCBtYW5kYXRlIGFueSBtb3Jl
IHRoZSBwcmVzZW5jZSBvZiBhIFJlc291cmNlIE93bmVyLg0KDQpXaHkgZG8geW91IHNheSB0aGF0
PyBUaGUgUk8gaXMgd2hvIG93bnMgdGhlIFJTLiBZb3VyIHN0YXRlbWVudCBkb2VzIG5vdCBtYWtl
IHNlbnNlLg0KDQpbRGVuaXNdICBJIG1lYW4gdGhhdCB0aGVyZSBpcyBub3QgbmVjZXNzYXJpbHkg
YSBwcm90b2NvbCBkZWZpbmVkIHNvIHRoYXQgdGhlIFJPIGNhbiBpbnRlcmFjdCB3aXRoIHRoZSBy
ZXF1ZXN0cyBmcm9tIHRoZSBjbGllbnRzLg0KSXMgdGhlIFJPIHRoZSBVc2VyPyBJbiBjb25zdW1l
ciB1c2UgY2FzZXMgaXQgdXN1YWxseSBpcywgYW5kIHRoZSBSTyBpcyB1c2luZyB0aGUgY2xpZW50
LiBJJ20gbm90IHN1cmUgd2hhdCB5b3Ugc2NlbmFyaW8geW91IGFyZSBkZXNjcmliaW5nDQoNCg0K
DQoNCg0KVGhlIGNsaWVudCBpcyBtYXkgYmUgZGVsZWdhdGluZyB1c2VyIGF1dGhlbnRpY2F0aW9u
IHRvIHRoZSBBUyBpbiBpZGVudGl0eSBjbGFpbSB1c2UgY2FzZXMuDQoNCkRlbGVnYXRpbmcgdXNl
ciBhdXRoZW50aWNhdGlvbiB0byB0aGUgQVMgaXMgZGlmZmVyZW50IGZyb20gZGVsZWdhdGluZyBh
Y2Nlc3MgY29udHJvbCB0byB0aGUgQVMuDQoNCkFncmVlZC4gWW91ciBzdGF0ZW1lbnQgd2FzIHRo
ZXJlIHdhcyBubyBkZWxlZ2F0aW9uLiBJJ20gZXhwbGFpbmluZyB0aGVyZSBhcmUgcG90ZW50aWFs
bHkgdHdvIGRlbGVnYXRpb25zLg0KDQpUaGUgQVMgY2FuIGFjdCBhcyB0aGUgY2xpZW50IGluIG1h
bnkgT0F1dGggZGVwbG95bWVudHMsIGFzIHRoZSBhY2Nlc3MgdG9rZW4gaXMgYSBiZWFyZXIgdG9r
ZW4uDQoNCkEgYmVhcmVyIHRva2VuIGlzIHJhdGhlciBpbnNlY3VyZS4NCkNvb2tpZXMgYXJlIGFs
c28gYmVhcmVyIHRva2Vucy4gQnV0IHdlIHVzZSB0aGVtIGFsbCB0aGUgdGltZSBpbiB3ZWIgYXBw
cyBmb3Igc3RvcmluZyBzZXNzaW9uIHN0YXRlIGFuZCBwcmlvciBhdXRoZW50aWNhdGlvbiEgOikN
Cg0KDQpUaGF0IGRvZXMgbm90IG1lYW4gdGhlIEFTIGtub3dzIHdoYXQgdGhlIGNsaWVudCBpcyBk
b2luZy4NCg0KVGhlcmUgYXJlIGN1cnJlbnRseSB0d28gYXR0ZW1wdHMgaW4gdGhlIE9BdXRoIFdH
IHRvIGxldCBrbm93IHRvIHRoZSBBUyB3aGF0IHRoZSBjbGllbnQgaXMgZG9pbmc6DQoNCiAgKiAg
IGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIyICAgKFRoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlv
biBGcmFtZXdvcms6IEpXVCBTZWN1cmVkIEF1dGhvcml6YXRpb24gUmVxdWVzdCkNCiAgKiAgIGRy
YWZ0LWlldGYtb2F1dGgtcmFyLTAxICAgICAgICAgKE9BdXRoIDIuMCBSaWNoIEF1dGhvcml6YXRp
b24gUmVxdWVzdHMpDQpUaG9zZSBhcmUgb3B0aW9uYWwsIGFuZCBpbiBzb21lIHNpdHVhdGlvbnMg
YXJlIGEgZGVzaXJlZCBwcm9wZXJ0eS4NCg0KW0RlbmlzXSAgSG93ZXZlciwgaW4gdGhlc2UgdHdv
IGRyYWZ0cywgdGhlIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgc2VjdGlvbnMgYXJlIHNpbGVudCBv
biB0aGlzIHBvaW50Lg0KVGhlcmUgYXJlIGxvdHMgb2YgbWlzc2luZyBkZXRhaWxzIGluIGJvdGgg
ZHJhZnRzISBTZWN1cml0eSBjb25zaWRlcmF0aW9ucywgZXJyb3IgbWVzc2FnZXMgZXRjLg0KDQpJ
IHRoaW5rIHByZXR0eSBtdWNoIGV2ZXJ5b25lIGlzIG9uYm9hcmQgc3VwcG9ydGluZyBwcml2YWN5
LCBidXQgbm90IGFsbCB1c2UgY2FzZXMgaGF2ZSB0aGUgc2FtZSBwcml2YWN5IGNvbnNpZGVyYXRp
b25zLg0KDQovRGljaw0K

--_000_731a364a19a74e1d982d59d9c441dc0acertorg_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n
czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy
IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O
b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz
cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxp
Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN
Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox
LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk
OjE1Nzk2Mjk5Mzg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01MTc1MjM3NDt9DQpAbGlzdCBs
MDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7
fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2
ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0
LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K
QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u
dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u
dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246
bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX
aW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv
bTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm
YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv
OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh
W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r
PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkhlbGxvITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSB0b3AtcG9zdGluZyBoZXJl
IGJlY2F1c2UgdGhlcmUgaXMgbm8gZWFzeSB3YXkgZm9yIG1lIHRvIGNsZWFuaW5nIGluc2VydCBt
eSBwcm9jZXNzIGNvbW1lbnQuJm5ic3A7IEkgdGhpbmsgd2UgYXJlIGhhdmluZyBhIG5lY2Vzc2Fy
eSBjb252ZXJzYXRpb24gYmVsb3cgYW5kIGluIG5vIHdheSBzaG91bGQgaXQgc3RvcCBiZWNhdXNl
IG9mIHRoaXMgbm90ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgYSBwcm9jZXNzIGNoZWNr
LCB0aGlzIHRocmVhZCBzdGFydGVkIHdpdGggYSByZXF1ZXN0IGZvciBjb21tdW5pdHkgcmV2aWV3
IG9uIHRoZSBjaGFydGVyIHRleHQgWzFdLiZuYnNwOyBBbW9uZyBvdGhlciB0aGluZ3MsIHRoaXMg
Y2hhcnRlciByZXZpZXcgaXMgdHJ5aW5nIHRvIGVuc3VyZSB0aGUgcHJvYmxlbSBpcyBjbGVhciwg
ZGVmaW5lcyB0aGUgYm91bmRzIG9mIHRoZSBkZXNpcmVkIHNvbHV0aW9ucyBhbmQgaWRlbnRpZmll
cw0KIGNyaXRpY2FsIG9iamVjdGlvbnMgZnJvbSB0aGUgY29uc2Vuc3VzLWRlcml2ZWQgdGV4dC4m
bmJzcDsgVGhlIHRleHQgaXMgbm90IGludGVuZGVkIHRvIGRlZmluZSBkZXRhaWxlZCByZXF1aXJl
bWVudHMvYXJjaGl0ZWN0dXJlLCByZXNvbHZlIHRyYWRlb2Zmcywgb3IgdG8gc3BlY2lmeSBhIHNv
bHV0aW9uLCB1bmxlc3MgdGhleSBhcmUgY3JpdGljYWwgdG8gYm91bmRpbmcgdGhlIHNvbHV0aW9u
LiZuYnNwOyBUaGVzZSBkZXRhaWxzIHNob3VsZCBiZSBsZWZ0IHRvIGZ1dHVyZQ0KIGRpc2N1c3Np
b25zIG9mIGEgY2hhcnRlcmVkIFdHIChub3QgdGhhdCB0aGV5IGNhbuKAmXQgc3RhcnQgbm93IGlu
IHBhcmFsbGVsKS4mbmJzcDsgQWRkaXRpb25hbGx5LCBhcyBhIHJlbWluZGVyLCB3aGlsZSB0aGVy
ZSBhcmUgbXVsdGlwbGUgaW5kaXZpZHVhbCBkcmFmdHMgd2l0aCBwcm9wb3NlZCBzb2x1dGlvbnMg
aW4gdGhlIGRhdGF0cmFja2VyLCB0aGUgZGVzaWduIGRlY2lzaW9ucyB0aGV5IG1ha2UgYXJlIG5v
dCBwYXJ0IG9mIHRoZSBjaGFydGVyIGFuZCB0aGVpcg0KIGFkb3B0aW9uIGlzIG5vdCBhc3N1bWVk
IGJ5IHRoZSBjaGFydGVyLiZuYnNwOyBJZiB0aGVyZSBhcmUga2V5IGRlc2lnbiBlbGVtZW50cyBp
biB0aG9zZSBvciBhbnkgb3RoZXIgZG9jdW1lbnRzIHRoYXQgaXMgZmVsdCB0byBiZSBjcnVjaWFs
IHRvIHNjb3BpbmcgdGhlIFdHLCAmbmJzcDt3ZSBuZWVkIHRvIGNhcHR1cmUgdGhlIHRoaW5raW5n
LCBnZW5lcmFsaXplIGl0IChhcyBhcHByb3ByaWF0ZSksIGFuZCBhZGQgaXQgdG8gdGhlIGNoYXJ0
ZXIgdGV4dCBleHBsaWNpdGx5DQogb3IgYnkgcmVmZXJlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5MZXTigJlzIGNvbnRpbnVlIHRvIHRhbGsgYWJvdXQgdGhlIHRlY2huaWNhbCBkZXRhaWxz
IG9mIHRoZSB1c2UgY2FzZXMsIGRlc2lnbiBwcm9wZXJ0aWVzLCBjb25zdHJhaW50cyBhbmQgY2Fu
ZGlkYXRlIHNvbHV0aW9ucy4mbmJzcDsgQWRkaXRpb25hbGx5LCBnaXZlbiB0aGUgLTA1IGNoYXJ0
ZXIgdGV4dCBhbmQgbWlsZXN0b25lcyBbMl0sIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gdW5kZXJz
dGFuZCB3aGF0IG91dHN0YW5kaW5nDQogY29uY2VybnMgcmVtYWluIHdpdGggdGhlIGNoYXJ0ZXIg
dGV4dCBpbiBwcmVwYXJhdGlvbiBmb3IgdGhlIFRodXJzZGF5LCBKdWx5IDk8c3VwPnRoPC9zdXA+
IHRlbGVjaGF0IHdoZXJlIHRoZSBJRVNHIHdpbGwgdXNlIGNvbW11bml0eSBmZWVkYmFjayB0byBo
ZWxwIGRlY2lkZSB0aGUgd2F5IGFoZWFkIGZvciB0aGlzIHByb3Bvc2VkIFdHLjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5Sb21hbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0gPGEgaHJlZj0i
aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90eGF1dGgvNG5FOHJ0eVJQdGRr
MEZyY2xRMWMtRldNTzh3LyI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn
L3R4YXV0aC80bkU4cnR5UlB0ZGswRnJjbFExYy1GV01POHcvPC9hPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+WzJdIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1nbmFwLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9jaGFydGVyLWlldGYtZ25hcC88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu
NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw
aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUeGF1dGggJmx0O3R4
YXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5EaWNrIEhhcmR0
PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSnVseSAzLCAyMDIwIDk6NDEgUE08YnI+DQo8Yj5U
bzo8L2I+IERlbmlzICZsdDtkZW5pcy5pZXRmQGZyZWUuZnImZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBO
YXQgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdtYWlsLmNvbSZndDs7IHR4YXV0aEBpZXRmLm9yZzxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1R4YXV0aF0gV0cgUmV2aWV3OiBHcmFudCBOZWdvdGlh
dGlvbiBhbmQgQXV0aG9yaXphdGlvbiBQcm90b2NvbCAoZ25hcCk8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsgTmF0IGFzIGhlIGlzIG1l
bnRpb25lZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+LSBJRVNHPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P
biBGcmksIEp1bCAzLCAyMDIwIGF0IDI6MTYgQU0gRGVuaXMgJmx0OzxhIGhyZWY9Im1haWx0bzpk
ZW5pcy5pZXRmQGZyZWUuZnIiPmRlbmlzLmlldGZAZnJlZS5mcjwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5IZWxsbyBEaWNrLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYXRjaGlu
ZyB1cCBvbiB0aGlzIGVtYWlsIC4uLiBjb21tZW50cyBpbnNlcnRlZCAuLi48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgSnVuIDI5LCAyMDIwIGF0
IDEyOjA2IEFNIERlbmlzICZsdDs8YSBocmVmPSJtYWlsdG86ZGVuaXMuaWV0ZkBmcmVlLmZyIiB0
YXJnZXQ9Il9ibGFuayI+ZGVuaXMuaWV0ZkBmcmVlLmZyPC9hPiZndDsgd3JvdGU6PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm
dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl
ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl
cmlmIj5IZWxsbyBEaWNrLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkRlbmlzLCB0aGFua3MgZm9yIHNoYXJpbmcgeW91
ciB0aG91Z2h0cywgc29tZSBjbGFyaWZpY2F0aW9ucyBvbiB5b3VyIHN0YXRlbWVudHMgaW5zZXJ0
ZWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk9u
IEZyaSwgSnVuIDI2LCAyMDIwIGF0IDk6NDIgQU0gRGVuaXMgJmx0OzxhIGhyZWY9Im1haWx0bzpk
ZW5pcy5pZXRmQGZyZWUuZnIiIHRhcmdldD0iX2JsYW5rIj5kZW5pcy5pZXRmQGZyZWUuZnI8L2E+
Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
c2Fucy1zZXJpZiI+Jmx0O3NuaXAmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y
aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5OZXcgcHJvcG9zZWQgY2hhcnRlcjwvc3Bh
bj48L2I+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbHQ7c25pcCZndDsmbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g
Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0K
UmVzb3VyY2Ugc2VydmVycyBpbmZvcm0gdGhlaXIgY2xpZW50cyBhYm91dCB3aGljaCBhY2Nlc3Mg
dG9rZW4gZm9ybWF0cyBhcmUgYWNjZXB0YWJsZSBhbmQgZGVwZW5kaW5nIHVwb24gdGhlIGtpbmcg
b2Ygb3BlcmF0aW9uPGJyPg0KdGhhdCBpcyByZXF1ZXN0ZWQsIHdoaWNoIGtpbmQgb2YgYXR0cmli
dXRlcyBhcmUgbmVlZGVkIGFuZCBmcm9tIHdoaWNoIEFTcyB0aGF0IG15IGJlIG9idGFpbmVkLjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldoaWxlIGF0IHRpbWVzIHRoaXMg
bWF5IGJlIGFwcHJvcHJpYXRlLCBhdCBvdGhlciB0aW1lcyBkaXNjbG9zaW5nIHRoZSBhdHRyaWJ1
dGVzIHRoZSBSUyByZXF1aXJlcyBpcyBub3QgbmVlZGVkIGJ5IHRoZSBjbGllbnQuDQo8YnI+DQpG
b3IgZXhhbXBsZSwgYW4gZW50ZXJwcmlzZSBjbGllbnQgYWNjZXNzaW5nIGEgcmVzb3VyY2UgZG9l
cyBub3QgbmVlZCB0byBrbm93IHdoaWNoIGdyb3VwcyBhIHVzZXIgYmVsb25ncyB0bywNCjxicj4N
CmJ1dCB0aGUgUlMgbWF5IHJlcXVpcmUgdGhhdCB0byBkZXRlcm1pbmUgaWYgdGhlIHVzZXIgcnVu
bmluZyB0aGUgY2xpZW50IGhhcyBhY2Nlc3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkFzIHNvb24gYXMgdGhlcmUgaXMgYSBk
ZXNpcmUgdG8gaW1wbGVtZW50IHByaXZhY3kgYnkgZGVmYXVsdCwgdGhlIGNsaWVudCBzaG91bGQg
bm90IHByb3ZpZGUgbW9yZSBhdHRyaWJ1dGVzIHRoYW4gc3RyaWN0bHkgbmVjZXNzYXJ5Lg0KPGJy
Pg0KRXZlbiBhZnRlciB0aHJlZSByZWFkaW5ncyBvZiB5b3VyIGV4YW1wbGUsIEkgZmFpbGVkIHRv
IHVuZGVyc3RhbmQgaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu
MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp
Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkEgbWFq
b3IgZGlmZmVyZW5jZSB3aXRoIE9BdXRoIDIuMCBpcyB0aGF0IHRoZXJlIGlzIG5vIGJpbGF0ZXJh
bCB0cnVzdCByZWxhdGlvbnNoaXAgYmV0d2VlbiBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQg
YSByZXNvdXJjZSBzZXJ2ZXI6DQo8YnI+DQpmb3IgYSBnaXZlbiBjYXRlZ29yeSBvZiBhdHRyaWJ1
dGVzLCBhIHJlc291cmNlIHNlcnZlciBtYXkgdHJ1c3Qgb25lIG9yIG1vcmUgYXV0aG9yaXphdGlv
biBzZXJ2ZXJzLiBBbm90aGVyIG1ham9yIGRpZmZlcmVuY2Ugd2l0aCBPQXV0aCAyLjAuPGJyPg0K
aXMgdGhhdCB0aGUgY29udGVudCBvZiBhbiBhdHRyaWJ1dGVzIHRva2VuIGlzIG1lYW50IHRvIGJl
IGFjY2Vzc2libGUgdG8gdGhlIGNsaWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z
LXNlcmlmIj5UaGlzIGlzIG5vdCBob3cgT0F1dGggMi4wIHdvcmtzLiBTZWUgc2xpZGVzIDcgYW5k
IDggZnJvbSBteSBvcmlnaW5hbCBJRVRGIHByZXNlbnRhdGlvbiBvbiB3aGF0IGJlY2FtZSBPQXV0
aCAyLjA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z
LXNlcmlmIj48YSBocmVmPSJodHRwczovL3d3dy5zbGlkZXNoYXJlLm5ldC9ndWVzdGU2NDhiL2ll
dGYtNzctb2F1dGgtd3JhcC1wcmVzZW50YXRpb24iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3
dy5zbGlkZXNoYXJlLm5ldC9ndWVzdGU2NDhiL2lldGYtNzctb2F1dGgtd3JhcC1wcmVzZW50YXRp
b248L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LHNhbnMtc2VyaWYiPkkgbG9va2VkIGF0IHRoZSB0d28gc2xpZGVzLiA8L3NwYW4+DQo8bzpwPjwv
bzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz
YW5zLXNlcmlmIj5VbmZvcnR1bmF0ZWx5IHNsaWRlIDcgaGFzIGp1c3Qgb25lIGFycm93IHdpdGgg
dGhlIHdvcmQgJnF1b3Q7dHJ1c3QmcXVvdDsuIFRoaXMgaXMgaW5zdWZmaWNpZW50IHRvIHVuZGVy
c3RhbmQgd2hhdCBpcyBtZWFudCB1bmxlc3MgYmVpbmcgcHJlc2VudA0KPGJyPg0KYXQgdGhlIHBy
ZXNlbnRhdGlvbi4gRG9lcyBpdCBtZWFuIHRoYXQgdGhlIFBSIChSUykgdHJ1c3RzIG9uZSBBUyBv
ciB0aGF0IGl0IG1heSB0cnVzdCBtdWx0aXBsZSBBU3MgPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt
YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cD48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VW5mb3J0dW5hdGVs
eSBzbGlkZSA4IGhhcyBqdXN0IG9uZSBhcnJvdyBiZXR3ZWVuIHRoZSBQUiBhbmQgdGhlIEFTIHdo
aWNoIGlzIHJlZC1jcm9zc2VkIGJ1dCBubyB0ZXh0IGF0IGFsbC4gVGhpcyBpcyBpbnN1ZmZpY2ll
bnQgdG8gdW5kZXJzdGFuZDxicj4NCndoYXQgaXMgbWVhbnQgdW5sZXNzIGJlaW5nIHByZXNlbnQg
YXQgdGhlIHByZXNlbnRhdGlvbi4gRG9lcyBpdCBtZWFuIHRoYXQgdGhlIFBSIGFuZCB0aGUgQVMg
bmV2ZXIgY29tbXVuaWNhdGUgZGlyZWN0bHkgPzxicj4NCkRvZXMgaXQgbWVhbiB0aGF0IHRoZXkg
aGF2ZSBubyByZWxhdGlvbnNoaXBzIGF0IGFsbCwgYmVzaWRlcyB0aGUgb25lIHdheSB0cnVzdCBy
ZWxhdGlvbnNoaXAgbWVudGlvbmVkIGluIHNsaWRlIDcgPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm
Ij5TbyBpdCBoYXJkIHRvIHNheSB3aGV0aGVyIHRoZXNlIHR3byBzbGlkZXMgYXJlIGluZGVlZCBt
ZWFuaW5nIHRoYXQgdGhlcmUgaXMgbm8gYmlsYXRlcmFsIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGFu
IGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCBhIHJlc291cmNlIHNlcnZlci48L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+QXBvbG9naWVzIGZvciBub3QgcHJvdmlkaW5nIGFuIGV4cGxhbmF0aW9uIG9u
IHRoZSBzbGlkZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlNsaWRlIDcgc2hvd3MgdGhhdCB0cnVzdCBiZXR3ZWVuIHRoZSBBUyBhbmQgUFIg
KG5vdyBSUykgd2FzIHVuaWRpcmVjdGlvbmFsLCBmcm9tIHRoZSBSUyB0byB0aGUgQVMuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbGlkZSA4IGlu
ZGljYXRlcyZuYnNwO3RoYXQgdHJ1c3QgaXMgbm90IGJpZGlyZWN0aW9uYWwuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OyxzYW5zLXNlcmlmIj5bRGVuaXNdJm5ic3A7IC4uLiB3aGljaCBtZWFucyB0aGF0IHNs
aWRlIDggY29udHJhZGljdHMgc2xpZGUgNy4mbmJzcDsgOi0pDQo8L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlNsaWRlIDggc2F5cyBpdCBkb2VzIG5vdCBnbyBib3RoIHdheXMuIFNsaWRlIDcgc2F5cyBpdCBn
b2VzIG9uZSB3YXkuIEkgZG9uJ3Qgc2VlIHRoZSBjb250cmFkaWN0aW9uLiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5JIHdvdWxkIGhhdmUgcHJlZmVy
cmVkIHRoYXQgeW91IG1lYW50OiB0aGUgUlMgYW5kIHRoZSBBUyBuZXZlciBjb21tdW5pY2F0ZSBk
aXJlY3RseSwgd2hpY2ggaXMgaW5kZWVkIGEgbmljZSBwcm9wZXJ0eSB0byBmb2xsb3cNCjxicj4N
CnRvIGVuc3VyZSB0aGUgdXNlcidzIHByaXZhY3kuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcyBv
bmUgbW9kZWwuIE90aGVyIG1vZGVscyBhcmUgYXBwcm9wcmlhdGUgaW4gb3RoZXIgY2lyY3Vtc3Rh
bmNlcy4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp
biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cD48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIG5vIGxpbWl0IG9u
IGhvdyBtYW55IEFTcyBhbiBSUyBtYXkgdHJ1c3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl
cmlmIj5bRGVuaXNdIFRoaXMgaXMgZmluZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl
cmlmIj5PbiBKdW5lIDEyLCBOYXQgU2FraW11cmEgcmVjZW50bHkgYW5zd2VyZWQgdG8gYW4gZW1h
aWwgd2l0aCB0aGUgZm9sbG93aW5nIHRvcGljOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlJlOiBbT0FVVEgt
V0ddIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtb2F1dGgtandzcmVxLTIyIChUaGUgT0F1dGggMi4w
IEF1dGhvcml6YXRpb24gRnJhbWV3b3JrOiBKV1QgU2VjdXJlZCBBdXRob3JpemF0aW9uIFJlcXVl
c3QpKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt
c2VyaWYiPk15IGFyZ3VtZW50cyB3ZXJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgb3JpZ2luYWwgbW9kZWwg
Zm9yIE9BdXRoIHdhcyBtYWtpbmcgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgQVMgYW5kIHRoZSBS
UyBoYWQgYSBzdHJvbmcgYmlsYXRlcmFsIHJlbGF0aW9uc2hpcC48L3NwYW4+PGJyPg0KPGJyPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5BIGtleSBxdWVzdGlvbiBpcyB3aGV0aGVy
IHN1Y2ggc3Ryb25nIHJlbGF0aW9uc2hpcCB3aWxsIGJlIG1haW50YWluZWQgZm9yIGV2ZXINCjwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt
c2VyaWYiPm9yIDwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoZXRoZXIgaXQg
d2lsbCBiZSBhbGxvd2VkIHRvIHBlcmZvcm0gc29tZSBldm9sdXRpb25zIG9mIHRoaXMgcmVsYXRp
b25zaGlwLjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIG9yZGVy
IHRvIHJlc3BlY3QgdGhlIHByaXZhY3kgb2YgdGhlIHVzZXJzLCB0aGVyZSBpcyB0aGUgbmVlZCB0
byBlbmNvbXBhc3Mgb3RoZXIgc2NlbmFyaW9zLiBPbmUgb2YgdGhlc2Ugc2NlbmFyaW9zIGlzIHRo
YXQgdGhlIEFTIGFuZCB0aGUgUlMNCjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGRvIG5vdCBuZWVkIGFueSBsb25nZXIgdG8gaGF2ZSBzdWNoIGEgc3Ryb25nIHJlbGF0aW9uc2hp
cC4gSW4gdGVybXMgb2YgdHJ1c3QgcmVsYXRpb25zaGlwcywgYSBSUyBzaW1wbHkgbmVlZHMgdG8g
dHJ1c3QgdGhlIGFjY2VzcyB0b2tlbnMgaXNzdWVkIGJ5IGFuIEFTLg0KPC9zcGFuPjxicj4NCjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIEFTIGRvZXMgaGF2ZSBhbnkgbW9yZSBhICZxdW90O25l
ZWQgdG8ga25vdyZxdW90OyBvZiBhbGwgdGhlIFJTcyB0aGF0IGFyZSBhY2NlcHRpbmcgaXRzIGFj
Y2VzcyB0b2tlbnMuIFRoaXMgd291bGQgYmUgYSBtYWpvciBzaW1wbGlmaWNhdGlvbiBvZiB0aGUg
Y3VycmVudCBnbG9iYWwgYXJjaGl0ZWN0dXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LHNhbnMtc2VyaWYiPk5hdCdzIHBvc2l0aW9uIHdhczoNCjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+JnF1b3Q7TXkgdGFrZSBpcyB0aGF0IHRoZSBiYXNp
YyBhc3N1bXB0aW9uIG9mIE9BdXRoIDIuMCBGcmFtZXdvcmsgaXMgdGhhdCB0aGVyZSBpcyBhIHN0
cm9uZyByZWxhdGlvbnNoaXAgYmV0d2VlbiBBUyBhbmQgUlMuDQo8YnI+DQpJIGZlZWwgdGhhdCBp
dCBpcyBxdWl0ZSB1bnJlYWxpc3RpYyB0aGF0IGFuIFJTIHdvdWxkIHRydXN0IHRoZSBhY2Nlc3Mg
dG9rZW4gaXNzdWVkIGJ5IGFuIEFTIHRoYXQgaXQgaGFzIG5vIHN0cm9uZyByZWxhdGlvbnNoaXAg
d2l0aCZxdW90Oy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OyxzYW5zLXNlcmlmIj5UaGVyZSBhcmUgaW5kZWVkIGRpZmZlcmVudCBwb3NpdGlvbnMgb24gdGhp
cyB0b3BpYy4mbmJzcDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCB0aGluayBOYXQgYW5k
IEkgaGF2ZSBkaWZmZXJlbnQgb3BpbmlvbnMsIGJ1dCBJIHdpbGwgbGV0IE5hdCBjbGFyaWZ5Ljxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBi
ZWNhdXNlIHRoZXJlIGlzIGEgc3Ryb25nIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBBUyBhbmQg
UlMsIGRvZXMgbm90IG1lYW4gaXQgaXMgYmlkaXJlY3Rpb25hbC4gSSB3b3VsZCB1bmRlcnN0YW5k
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZxdW90O0kgZmVlbCB0aGF0IGl0IGlzIHF1aXRlIHVucmVhbGlzdGljIHRoYXQgYW4gUlMg
d291bGQgdHJ1c3QgdGhlIGFjY2VzcyB0b2tlbiBpc3N1ZWQgYnkgYW4gQVMgdGhhdCBpdCBoYXMg
bm8gc3Ryb25nIHJlbGF0aW9uc2hpcCB3aXRoJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIGluZGljYXRlIE5hdCBpcyBleHBlY3Rp
bmcgdGhlIHRydXN0IHRvIGJlIGZyb20gdGhlIFJTIHRvIHRoZSBBUy48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z
LXNlcmlmIj5bRGVuaXNdJm5ic3A7IFNwZWFraW5nIG9mIGEgJnF1b3Q7c3Ryb25nIHJlbGF0aW9u
c2hpcCZxdW90OyBpcyBhbWJpZ3VvdXMuIFRoZSBrZXkgcG9pbnQgYmVpbmcgd2hldGhlciB0aGUg
cmVsYXRpb25zaGlwIGlzIHVuaWxhdGVyYWwgb3IgYmlsYXRlcmFsLjxicj4NClRoZXJlIGlzIG5v
IG5lZWQgdG8gdXNlIHRoZSB3b3JkaW5nICZxdW90O3N0cm9uZyByZWxhdGlvbnNoaXAmcXVvdDsg
d2hlbiB0aGUgcmVsYXRpb25zaGlwIGlzIG9ubHkgdW5pbGF0ZXJhbDogYSBSUyBzaW1wbHkgdHJ1
c3RzIGFuIEFTIGZvciB0aGUgYWNjZXNzIHRva2VucyBpdCBpc3N1ZXMuDQo8YnI+DQpJbiBzdWNo
IGEgY2FzZSwgdGhpcyBkb2VzIG5vdCBtZWFuIHRoYXQgYW4gQVMgaXMga25vd2luZyBhbGwgdGhl
IFJTcyB0aGF0IGFyZSB0cnVzdGluZyBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+T24gdGhl
IGNvbnRyYXJ5LCBhIHN0cm9uZyAoYmktKXJlbGF0aW9uc2hpcCBpcyB3aGVuIGEgUlMgYW5kIGFu
IEFTIGJvdGggYWdyZWUgYmV0d2VlbiB0aGVtIGFib3V0IHRoZSBtZWFuaW5nIG9mIHNjb3BlIHBh
cmFtZXRlcnMuPGJyPg0KVGhpcyBpcyBhIHR5cGljYWwgY2FzZSBmb3IgT0F1dGggMi4wLjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPllvdSBjYW4gYXNrIE5hdCB3aGF0IGhlIG1lYW50IGJ5ICZxdW90O3N0cm9u
ZyByZWxhdGlvbnNoaXAmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIEFTIGlzIHN0YXRpbmcgd2hhdCBhIHNjb3BlIG1lYW5zIHRv
IGl0IGFuZCB0aGUgdXNlci4uIFRoZSBSUyBjYW4gZG8gd2hhdGV2ZXIgaXQgd2FudHMuIEkgZG9u
J3Qgc2VlIHRoYXQgYXMgcmVxdWlyaW5nIGEgYmlkaXJlY3Rpb25hbCByZWxhdGlvbnNoaXAuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w
cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHA+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBBUyBtYXkg
bm90IGV2ZW4ga25vdyB3aG8gdGhlIFJTIChvciBQUiBpbiB0aGUgc2xpZGVzKSBpcy48L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbHQ7
c25pcCZndDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+
DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OyxzYW5zLXNlcmlmIj48YnI+DQpJIGdvdCByaWQgb2YgdGhlIHdvcmQgJnF1b3Q7ZGVsZWdh
dGlvbiZxdW90OzogdGhlIGNsaWVudCBkb2VzIG5vdCBkZWxlZ2F0ZSBhbnl0aGluZyB0byBhbiBh
dXRob3JpemF0aW9uIHNlcnZlci4gSWYgaXQgd291bGQsIHRoaXMgd291bGQgbWVhbiB0aGF0IHRo
ZSBhdXRob3JpemF0aW9uIHNlcnZlcg0KPGJyPg0Kd291bGQgYmUgYWJsZSB0byBhY3QgYXMgdGhl
IGNsaWVudCBhbmQgY291bGQga25vdyBldmVyeXRoaW5nIHRoYXQgdGhlIGNsaWVudCB3aWxsIGRv
LCB3aGljaCBjb21lcyBpbnRvIGNvbnRyYWRpY3Rpb24gd2l0aCB0aGUgdXNlcidzIHByaXZhY3ku
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGUmbmJzcDthYm92ZSBpcyBub3QgdHJ1ZS48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy
aWYiPlRoZSBSZXNvdXJjZSBPd25lciBpcyBkZWxlZ2F0aW5nIGFjY2VzcyBjb250cm9sIHRvIHRo
ZSBBUyBpbiBhdXRob3JpemF0aW9uIHVzZSBjYXNlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhlIE9BdXRoIDIuMCBtb2Rl
bCBkb2VzIG5vdCBtYW5kYXRlIGFueSBtb3JlIHRoZSBwcmVzZW5jZSBvZiBhIFJlc291cmNlIE93
bmVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2h5IGRvIHlvdSBzYXkgdGhhdD8gVGhlIFJPIGlzIHdo
byBvd25zIHRoZSBSUy4gWW91ciBzdGF0ZW1lbnQgZG9lcyBub3QgbWFrZSBzZW5zZS48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OyxzYW5zLXNlcmlmIj5bRGVuaXNdJm5ic3A7IEkgbWVhbiB0aGF0IHRoZXJlIGlzIG5vdCBu
ZWNlc3NhcmlseSBhIHByb3RvY29sIGRlZmluZWQgc28gdGhhdCB0aGUgUk8gY2FuIGludGVyYWN0
IHdpdGggdGhlIHJlcXVlc3RzIGZyb20gdGhlIGNsaWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMg
dGhlIFJPIHRoZSBVc2VyPyBJbiBjb25zdW1lciB1c2UgY2FzZXMgaXQgdXN1YWxseSBpcywgYW5k
IHRoZSBSTyBpcyB1c2luZyB0aGUgY2xpZW50LiBJJ20gbm90IHN1cmUgd2hhdCB5b3Ugc2NlbmFy
aW8geW91IGFyZSBkZXNjcmliaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk
ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu
Ij4NCjxkaXY+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGUgY2xpZW50IGlzIG1heSBiZSBkZWxlZ2F0aW5n
IHVzZXIgYXV0aGVudGljYXRpb24gdG8gdGhlIEFTIGluIGlkZW50aXR5IGNsYWltIHVzZSBjYXNl
cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu
cy1zZXJpZiI+RGVsZWdhdGluZyB1c2VyIGF1dGhlbnRpY2F0aW9uIHRvIHRoZSBBUyBpcyBkaWZm
ZXJlbnQgZnJvbSBkZWxlZ2F0aW5nIGFjY2VzcyBjb250cm9sIHRvIHRoZSBBUy48L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkFncmVlZC4gWW91ciBzdGF0ZW1lbnQgd2FzIHRoZXJlIHdhcyBubyBkZWxlZ2F0
aW9uLiBJJ20gZXhwbGFpbmluZyB0aGVyZSBhcmUgcG90ZW50aWFsbHkmbmJzcDt0d28gZGVsZWdh
dGlvbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGUgQVMgY2FuIGFj
dCBhcyB0aGUgY2xpZW50IGluIG1hbnkgT0F1dGggZGVwbG95bWVudHMsIGFzIHRoZSBhY2Nlc3Mg
dG9rZW4gaXMgYSBiZWFyZXIgdG9rZW4uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QSBiZWFyZXIgdG9rZW4gaXMgcmF0aGVy
IGluc2VjdXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvb2tpZXMgYXJlIGFsc28gYmVhcmVyIHRva2Vu
cy4gQnV0IHdlIHVzZSB0aGVtIGFsbCB0aGUgdGltZSBpbiB3ZWImbmJzcDthcHBzIGZvciZuYnNw
O3N0b3Jpbmcgc2Vzc2lvbiBzdGF0ZSZuYnNwO2FuZCBwcmlvciBhdXRoZW50aWNhdGlvbiEgOik8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w
cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhhdCBkb2VzIG5vdCBtZWFuIHRoZSBB
UyBrbm93cyB3aGF0IHRoZSBjbGllbnQgaXMgZG9pbmcuDQo8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmUgYXJlIGN1cnJl
bnRseSB0d28gYXR0ZW1wdHMgaW4gdGhlIE9BdXRoIFdHIHRvIGxldCBrbm93IHRvIHRoZSBBUyB3
aGF0IHRoZSBjbGllbnQgaXMgZG9pbmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9
ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+
DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+
ZHJhZnQtaWV0Zi1vYXV0aC1qd3NyZXEtMjImbmJzcDsmbmJzcDsgKFRoZSBPQXV0aCAyLjAgQXV0
aG9yaXphdGlvbiBGcmFtZXdvcms6IEpXVCBTZWN1cmVkIEF1dGhvcml6YXRpb24gUmVxdWVzdCk8
L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAg
bGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LHNhbnMtc2VyaWYiPmRyYWZ0LWlldGYtb2F1dGgtcmFyLTAxICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAoT0F1dGggMi4wIFJpY2ggQXV0aG9yaXphdGlvbiBSZXF1ZXN0cyk8L3NwYW4+PG86
cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5UaG9zZSBhcmUgb3B0aW9uYWwsIGFuZCBpbiBzb21lIHNpdHVhdGlvbnMg
YXJlIGEgZGVzaXJlZCBwcm9wZXJ0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5bRGVuaXNdJm5i
c3A7IEhvd2V2ZXIsIGluIHRoZXNlIHR3byBkcmFmdHMsIHRoZSBwcml2YWN5IGNvbnNpZGVyYXRp
b25zIHNlY3Rpb25zIGFyZSBzaWxlbnQgb24gdGhpcyBwb2ludC48L3NwYW4+PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U
aGVyZSBhcmUgbG90cyBvZiBtaXNzaW5nIGRldGFpbHMgaW4gYm90aCBkcmFmdHMhIFNlY3VyaXR5
IGNvbnNpZGVyYXRpb25zLCBlcnJvciBtZXNzYWdlcyBldGMuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgcHJldHR5IG11Y2ggZXZl
cnlvbmUgaXMgb25ib2FyZCBzdXBwb3J0aW5nIHByaXZhY3ksIGJ1dCBub3QgYWxsIHVzZSBjYXNl
cyBoYXZlIHRoZSBzYW1lIHByaXZhY3kgY29uc2lkZXJhdGlvbnMuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9EaWNrPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_731a364a19a74e1d982d59d9c441dc0acertorg_--


From nobody Mon Jul  6 07:56: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 B62633A15C4 for ; Mon,  6 Jul 2020 07:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level: 
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=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 AgvviC9MCH9p for ; Mon,  6 Jul 2020 07:55:07 -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 8DEA23A1574 for ; Mon,  6 Jul 2020 07:55:06 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d77 with ME id zqv3220064FMSmm03qv3RS; Mon, 06 Jul 2020 16:55:04 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 06 Jul 2020 16:55:04 +0200
X-ME-IP: 86.238.65.197
To: iesg@ietf.org
Cc: txauth@ietf.org
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com>
From: Denis 
Message-ID: <7563640e-f515-3e73-a4eb-3902ec7af50e@free.fr>
Date: Mon, 6 Jul 2020 16:55: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: <159318778098.29096.6482921706088845432@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------482FBF1D47BB2A6BF10C111A"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 06 Jul 2020 14:55:11 -0000

This is a multi-part message in MIME format.
--------------482FBF1D47BB2A6BF10C111A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Since it is today the last day to send back comments, you will find 
hereafter my comments on the last charter version-05.


    charter-ietf-gnap-00-05

This group is chartered to develop a fine-grained delegation protocol 
for authorization, API access, user identifiers, and identity 
assertions. [Denis] Fine. The protocol will also allow the client to 
present unverified identifiers and verifiable assertions to the AS as 
part of its request. [Denis] This sentence is too vague because "as part 
of its request" is not explicit enough. If it means"as part as an access 
token request" this should be explicitly said. If, it is not the case, 
then it should be clearly explained. The AS should know as little as 
possible (including nothing) about what the client is doing. This 
protocol will allow an authorizing party to delegate access to client 
software through an authorization server. [Denis] The word "*privacy*" 
is still missing in the charter. "Delegating access to client software 
through an authorization server" is negating the fact that the user's 
privacy will ever be considered. IMHO, I believe that a RS may delegate 
some operation to another RS, but I don't believe that an AS should be 
concerned by any form of delegation, otherwise it would have the ability 
to act as "Big Brother". OAuth has not been constructed taking into 
consideration the user's privacy. The major difference with it should be 
that GNAP has been constructed along "*privacy by design*" principles. 
It will *expand* upon the uses cases currently supported by OAuth 2.0 
and OpenID Connect (itself an extension of OAuth 2.0) to support 
authorizations scoped as narrowly as a single transaction, provide a 
clear framework for interaction among all parties involved in the 
protocol flow, and remove unnecessary dependence on a browser or 
user-agent for coordinating interactions. [Denis] There is no need to 
refer to OAuth 2.0 and OpenID Connect. Some existing uses cases (i.e. 
"*non-expanded"* use cases) should be supported differently from OAuth 
2.0 and OpenID Connect, in particular to support the user's privacy. The 
delegation process will be acted upon by multiple parties in the 
protocol, each performing a specific role. The protocol will decouple 
the channels used by the protocol participants to communicate from the 
delegation channel, which happens directly between the client and the 
authorization server (in contrast with OAuth 2.0, which is initiated by 
the client redirecting the user’s browser). [Denis] Here again, the 
delegation process, if any, should be handled by RSs and not by ASs. The 
term "delegation channel" is being used but it is left undefined. It is 
not understandable. The protocol will include a means of specifying how 
the user can potentially be involved in an interactive fashion during 
the delegation process. The client and Authorization Server (AS) will 
use these interaction mechanisms to involve the user, as necessary, to 
make authorization decisions. [Denis] Here again, the delegation 
process, if any, should be handled by RSs and not by ASs. The AS should 
know as little as possible (including nothing) about what the client is 
doing. This decoupling avoids many of the security concerns and 
technical challenges of OAuth 2.0 and provides a non-invasive path for 
supporting future types of clients and interaction channels. [Denis] 
This is not understandable to me. Is such a sentence really needed in a 
charter ? The group will define interoperability for this protocol 
between different parties, including

-client and authorization server;

-client and resource server; and

- authorization server and resource server. [Denis] In order to support 
the user's privacy, there should be no interaction at all between an 
authorization server and a resource server /at the time of a client 
request/. The group will seek to minimize assumptions about the form of 
client applications, allowing for:

-Fine-grained specification of access

-Approval of AS attestation to identifiers and other identity claims

-Approval of access to multiple resources and APIs in a single interaction

-Multiple access tokens in a single request and response

-AS-directed dispatch of access tokens to the appropriate RS

[Denis] As-directed dispatch does not allow to support the user's 
privacy. However, RS-directed dispatch allows to support the user's 
privacy. It should be explicitly mentioned.

-Separation between the party authorizing access and the party operating 
the client requesting access [Denis] It is questionable whether such a 
separation would be really beneficial. In doubt, this item should be 
removed. The group will define extension points for this protocol to 
allow for flexibility in areas including: Cryptographic agility for 
keys, message signatures, and proof of possession

-User interaction mechanisms including web and non-web methods

-Mechanisms for conveying user, software, organization, and other 
information used in authorization decisions

-Mechanisms for presenting tokens to resource servers and binding 
resource requests to tokens and associated cryptographic keys

Optimized inclusion of additional information (including identifiers and 
identity assertions) through the delegation process Additionally, the 
group will provide mechanisms for management of the protocol lifecycle 
including:

-Discovery of the authorization server

-Revocation of active tokens

Data model for granted access and mechanisms for the AS and RS to 
communicate the granted access model [Denis] While it is the duty for 
the RS to communicate the granted access model to the client /at the 
appropriate instant of time/, the AS should be kept fully ignorant of 
it. Although the artifacts for this work are not intended or expected to 
be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will 
attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the 
new protocol where possible. 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. Functionality that 
builds directly on OAuth 2.0 will be directed to the OAuth Working 
Group, including functionality back-ported from the protocol developed 
here to OAuth 2.0. The group is chartered to develop mechanisms for 
applying cryptographic methods, such as JOSE and COSE, to the delegation 
process. This group is not chartered to develop new cryptographic 
methods. The group is chartered to develop mechanisms for conveying 
identity information within the protocol including existing identifiers 
(such as email addresses, phone numbers, usernames, and subject 
identifiers) and assertions (such as OpenID Connect ID Tokens, SAML 
Assertions, and Verifiable Credentials). The group is not chartered to 
develop new formats for identifiers or assertions, nor is the group 
chartered to develop schemas for user information, profiles, or other 
identity attributes, unless a viable existing format is not available. 
The initial work will focus on using HTTPS for communication between the 
client and the authorization server, taking advantage of optimization 
features of HTTP/2 and HTTP/3 where possible, and will strive to enable 
simple mapping to other protocols such as COAP when doing so does not 
conflict with the primary focus. Milestones to include:

-Core delegation protocol

[Denis] Before defining a "Core delegation protocol", a simple client 
server-protocol involving the presentation of several access tokens to 
one RS should be defined. Privacy principles should be applied when 
defining the protocol. Then after, a delegation mechanism allowing one 
RS to forward an operation to another RS should be defined.

-Key presentation mechanism bindings to the core protocol including TLS, 
detached HTTP signature, and embedded HTTP signatures

[Denis] Bindings to TLS are now deprecated, why should they be 
maintained ? Signatures may be needed but they do not necessarily need 
to be "detached HTTP signature, and embedded HTTP signatures". This item 
should be either removed or reworded.

-Conveyance mechanisms for identifiers and assertions

-Guidelines for use of protocol extension points (if needed)

      -    Guidelines on migration paths, implementation, and operations

[Denis] The above three lines are rather mysterious.

Where possible, the group will seek to make use of tools to guide and 
inform the standardization process including formal analysis,
architecture documents, and use case documents. These artifacts will not 
be considered as working group milestones or deliverables.

The working group will cooperate and coordinate with other IETF WGs such 
as OAUTH, and work with external organizations,
such as the OpenID Foundation, as appropriate.

[Denis] The charter should be shorter.

/Denis

> A new IETF WG has been proposed in the Security Area. The IESG has not made
> any determination yet. The following draft charter was submitted, and is
> provided for informational purposes only. Please send your comments to the
> IESG mailing list (iesg@ietf.org)*by 2020-07-06*.
>
> Grant Negotiation and Authorization Protocol (gnap)
> -----------------------------------------------------------------------
> Current status: Proposed WG
>
> Chairs:
>    Yaron Sheffer 
>    Leif Johansson 
>
> Assigned Area Director:
>    Roman Danyliw 
>
> Security Area Directors:
>    Benjamin Kaduk 
>    Roman Danyliw 
>
> Mailing list:
>    Address: txauth@ietf.org
>    To subscribe: ​https://www.ietf.org/mailman/listinfo/txauth
>    Archive: https://mailarchive.ietf.org/arch/browse/txauth/
>
> Group page: https://datatracker.ietf.org/group/gnap/
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/
>
> This group is chartered to develop a fine-grained delegation protocol for
> authorization and API access, as well as requesting and providing user
> identifiers and claims. This protocol will allow an authorizing party to
> delegate access to client software through an authorization server. It will
> expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect
> (itself an extension of OAuth 2.0) to support authorizations scoped as
> narrowly as a single transaction, provide a clear framework for interaction
> among all parties involved in the protocol flow, and remove unnecessary
> dependence on a browser or user-agent for coordinating interactions.
>
> The delegation process will be acted upon by multiple parties in the protocol,
> each performing a specific role. The protocol will decouple the interaction
> channels, such as the end user’s browser, from the delegation channel, which
> happens directly between the client and the authorization server (in contrast
> with OAuth 2.0, which is initiated by the client redirecting the user’s
> browser). The protocol will include a means of specifying how the user can
> potentially be involved in an interactive fashion during the delegation
> process. The client and Authorization Server (AS) will use these interaction
> mechanisms to involve the user, as necessary, to make authorization decisions.
> This decoupling avoids many of the security concerns and technical challenges
> of OAuth 2.0 and provides a non-invasive path for supporting future types of
> clients and interaction channels.
>
> The group will define interoperability for this protocol between different
> parties, including
>   - client and authorization server;
>   - client and resource server; and
>   - authorization server and resource server.
>
> The group will seek to minimize assumptions about the form of client
> applications, allowing for:
> - Fine-grained specification of access
> - Approval of AS attestation to identifiers and other identity claims
> - Approval of access to multiple resources and APIs in a single interaction
> - Support for multiple access tokens in a single request and response
> - Support for directed, audience-restricted access tokens
> - Separation between the party authorizing access and the party operating the
> client requesting access
>
> The group will define extension points for this protocol to allow for
> flexibility in areas including:
>
> - Cryptographic agility for keys, message signatures, and proof of possession
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other
> information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding resource
> requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information (including identifiers and
> identity assertions) through the delegation process
>
> Additionally, the group will provide mechanisms for management of the protocol
> lifecycle including:
>
> - Discovery of the authorization server
> - Revocation of active tokens
> - Mechanisms for the AS and RS to communicate the access granted by an access
> token
>
> Although the artifacts for this work are not intended or expected to be
> backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt
> to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol
> where possible.
>
> 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. Functionality that builds directly on OAuth 2.0 will be directed
> to the OAuth Working Group, including functionality back-ported from the
> protocol developed here to OAuth 2.0.
>
> The group is chartered to develop mechanisms for applying cryptographic
> methods, such as JOSE and COSE, to the delegation process. This group is not
> chartered to develop new cryptographic methods.
>
> The group is chartered to develop mechanisms for conveying identity
> information within the protocol including existing identifiers (such as email
> addresses, phone numbers, usernames, and subject identifiers) and assertions
> (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
> Credentials). The group is not chartered to develop new formats for
> identifiers or assertions, nor is the group chartered to develop schemas for
> user information, profiles, or other identity attributes, unless a viable
> existing format is not available.
>
> The initial work will focus on using HTTPS for communication between the
> client and the authorization server, taking advantage of optimization
> features of HTTP/2 and HTTP/3 where possible, and will strive to enable
> simple mapping to other protocols such as COAP when doing so does not
> conflict with the primary focus.
>
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol including TLS,
> detached HTTP signature, and embedded HTTP signatures
> - Conveyance mechanisms for identifiers and assertions
> - Guidelines for use of protocol extension points
> - (if needed) Guidelines on migration paths, implementation, and operations
>
> Where possible, the group will seek to make use of tools to guide and inform
> the standardization process including formal analysis, architecture documents,
> and use case documents. These artifacts will not be considered as working
> group milestones or deliverables.
>
> The working group will cooperate and coordinate with other IETF WGs such as
> OAUTH, and work with external organizations, such as the OpenID Foundation,
> as appropriate.
>
> Milestones:
>
>    Jul 2021 - Core delegation protocol in WGLC
>
>    Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to
>    WGLC
>
>    Oct 2021 - Key presentation mechanism binding to the core protocol,
>    detached HTTP signatures, to WGLC
>
>    Oct 2021 - Key presentation mechanism binding to the core protocol,
>    embedded HTTP signature, to WGLC
>
>    Dec 2021 - Guidelines for use of protocol extension points to WGLC
>
>    Feb 2022 - Guidelines on migration paths, implementation, and operations to
>     WGLC
>
>
>


--------------482FBF1D47BB2A6BF10C111A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Since it is today
        the last day to send back comments, you will find hereafter my
        comments on the last charter version-05.

    

      
charter-ietf-gnap-00-05

      
This group is chartered to develop a fine-grained delegation protocol for authorization, API access, user identifiers, and identity assertions. 

[Denis] Fine.

The protocol will also allow the client to present unverified identifiers and verifiable assertions to the AS as part of its request. 

[Denis] This sentence is too vague because "as part of its request" is not explicit enough. If it means  "as part as an access token request" 
this should be explicitly said. If, it is not the case, then it should be clearly explained. The AS should know as little as possible (including nothing)
about what the client is doing.

This protocol will allow an authorizing party to delegate access to client software through an authorization server. 

[Denis] The word "privacy" is still missing in the charter. "Delegating access to client software through an authorization server" 
is negating the fact that the user's privacy will ever be considered. IMHO, I believe that a RS may delegate some operation to another RS, 
but I don't believe that an AS should be concerned by any form of delegation, otherwise it would have the ability to act as "Big Brother".
OAuth has not been constructed taking into consideration the user's privacy. The major difference with it should be that GNAP has been 
constructed along "privacy by design" principles.

It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations 
scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove 
unnecessary dependence on a browser or user-agent for coordinating interactions.

[Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. Some existing uses cases (i.e. "non-expanded" use cases) should be supported 
differently from OAuth 2.0 and OpenID Connect, in particular to support the user's privacy.

The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the channels used 
by the protocol participants to communicate from the delegation channel, which happens directly between the client and the authorization server (in contrast 
with OAuth 2.0, which is initiated by the client redirecting the user’s browser). 

[Denis] Here again, the delegation process, if any, should be handled by RSs and not by ASs. 
The term "delegation channel" is being used but it is left undefined. It is not understandable.

The protocol will include a means of specifying how the user can potentially be involved in an interactive fashion during the delegation process. 
The client and Authorization Server (AS) will use these interaction mechanisms to involve the user, as necessary, to make authorization decisions.

[Denis] Here again, the delegation process, if any, should be handled by RSs and not by ASs. The AS should know as little as possible (including nothing)
about what the client is doing.

This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types 
of clients and interaction channels.

[Denis] This is not understandable to me. Is such a sentence really needed in a charter ?

The group will define interoperability for this protocol between different parties, including

      
-          client and authorization server;

      
-          client and resource server; and

      
     -      authorization server and resource server.

[Denis] In order to support the user's privacy, there should be no interaction at all between an authorization server and a resource server 
at the time of a client request.

The group will seek to minimize assumptions about the form of client applications, allowing for:

      
-          Fine-grained specification of access

      
-          Approval of AS attestation to identifiers and other identity claims

      
-          Approval of access to multiple resources and APIs in a single interaction

      
-          Multiple access tokens in a single request and response

      
-          AS-directed dispatch of access tokens to the appropriate RS

      
[Denis] As-directed dispatch does not allow to support the user's privacy. However, RS-directed dispatch allows to support the user's privacy.
It should be explicitly mentioned.


      
-          Separation between the party authorizing access and the party operating the client requesting access 

[Denis] It is questionable whether such a separation would be really beneficial. In doubt, this item should be removed.

The group will define extension points for this protocol to allow for flexibility in areas including:

Cryptographic agility for keys, message signatures, and proof of possession

      
-          User interaction mechanisms including web and non-web methods

      
-          Mechanisms for conveying user, software, organization, and other information used in authorization decisions 

      
-          Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys 

      
Optimized inclusion of additional information (including identifiers and identity assertions) through the delegation process 

Additionally, the group will provide mechanisms for management of the protocol lifecycle including:

      
-          Discovery of the authorization server

      
-          Revocation of active tokens

      
Data model for granted access and mechanisms for the AS and RS to communicate the granted access model

[Denis] While it is the duty for the RS to communicate the granted access model to the client at the appropriate instant of time, 
the AS should be kept fully ignorant of it.

Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, 
the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.

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. Functionality that builds directly on OAuth 2.0 will be directed to the OAuth Working Group, including 
functionality back-ported from the protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. 
This group is not chartered to develop new cryptographic methods.

The group is chartered to develop mechanisms for conveying identity information within the protocol including existing identifiers 
(such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, 
SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group 
chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available.

The initial work will focus on using HTTPS for communication between the client and the authorization server, taking advantage 
of optimization features of HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to other protocols such as COAP 
when doing so does not conflict with the primary focus.

Milestones to include:

      
-          Core delegation protocol

      
[Denis] Before defining a "Core delegation protocol", a simple client server-protocol involving the presentation of several access tokens to one RS should be defined. 
Privacy principles should be applied when defining the protocol. Then after, a delegation mechanism allowing one RS to forward an operation to another RS should be defined.

      
-          Key presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded HTTP signatures 

      
[Denis] Bindings to TLS are now deprecated, why should they be maintained ? 
Signatures may be needed but they do not necessarily need to be "detached HTTP signature, and embedded HTTP signatures". 
This item should be either removed or reworded.

      
-          Conveyance mechanisms for identifiers and assertions 

      
-          Guidelines for use of protocol extension points (if needed) 

      
      
      
     -    Guidelines on
          migration paths, implementation, and operations 

        

      

        [Denis] The above three lines
          are rather mysterious.

      

          Where possible, the group will seek to make use of tools to
          guide and inform
          the standardization process including formal analysis, 

          architecture documents,
          and use case documents. These artifacts will not be considered
          as working group
          milestones or deliverables.

      

          The working group will cooperate and coordinate with other
          IETF WGs such as
          OAUTH, and work with external organizations, 

          such as the OpenID Foundation, as
          appropriate.

      

      [Denis] The charter should be shorter.

        

    


        

    
/Denis

    


    

    

      
A new IETF WG has been proposed in the Security Area. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list (iesg@ietf.org) by 2020-07-06.

Grant Negotiation and Authorization Protocol (gnap)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Yaron Sheffer <yaronf.ietf@gmail.com>
  Leif Johansson <leifj@sunet.se>

Assigned Area Director:
  Roman Danyliw <rdd@cert.org>

Security Area Directors:
  Benjamin Kaduk <kaduk@mit.edu>
  Roman Danyliw <rdd@cert.org>

Mailing list:
  Address: txauth@ietf.org
  To subscribe: ​https://www.ietf.org/mailman/listinfo/txauth
  Archive: https://mailarchive.ietf.org/arch/browse/txauth/

Group page: https://datatracker.ietf.org/group/gnap/

Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/

This group is chartered to develop a fine-grained delegation protocol for
authorization and API access, as well as requesting and providing user
identifiers and claims. This protocol will allow an authorizing party to
delegate access to client software through an authorization server. It will
expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect
(itself an extension of OAuth 2.0) to support authorizations scoped as
narrowly as a single transaction, provide a clear framework for interaction
among all parties involved in the protocol flow, and remove unnecessary
dependence on a browser or user-agent for coordinating interactions.

The delegation process will be acted upon by multiple parties in the protocol,
each performing a specific role. The protocol will decouple the interaction
channels, such as the end user’s browser, from the delegation channel, which
happens directly between the client and the authorization server (in contrast
with OAuth 2.0, which is initiated by the client redirecting the user’s
browser). The protocol will include a means of specifying how the user can
potentially be involved in an interactive fashion during the delegation
process. The client and Authorization Server (AS) will use these interaction
mechanisms to involve the user, as necessary, to make authorization decisions.
This decoupling avoids many of the security concerns and technical challenges
of OAuth 2.0 and provides a non-invasive path for supporting future types of
clients and interaction channels.

The group will define interoperability for this protocol between different
parties, including
 - client and authorization server;
 - client and resource server; and
 - authorization server and resource server.

The group will seek to minimize assumptions about the form of client
applications, allowing for:
- Fine-grained specification of access
- Approval of AS attestation to identifiers and other identity claims
- Approval of access to multiple resources and APIs in a single interaction
- Support for multiple access tokens in a single request and response
- Support for directed, audience-restricted access tokens
- Separation between the party authorizing access and the party operating the
client requesting access

The group will define extension points for this protocol to allow for
flexibility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possession
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other
information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource
requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information (including identifiers and
identity assertions) through the delegation process

Additionally, the group will provide mechanisms for management of the protocol
lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Mechanisms for the AS and RS to communicate the access granted by an access
token

Although the artifacts for this work are not intended or expected to be
backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt
to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol
where possible.

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. Functionality that builds directly on OAuth 2.0 will be directed
to the OAuth Working Group, including functionality back-ported from the
protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic
methods, such as JOSE and COSE, to the delegation process. This group is not
chartered to develop new cryptographic methods.

The group is chartered to develop mechanisms for conveying identity
information within the protocol including existing identifiers (such as email
addresses, phone numbers, usernames, and subject identifiers) and assertions
(such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
Credentials). The group is not chartered to develop new formats for
identifiers or assertions, nor is the group chartered to develop schemas for
user information, profiles, or other identity attributes, unless a viable
existing format is not available.

The initial work will focus on using HTTPS for communication between the
client and the authorization server, taking advantage of optimization
features of HTTP/2 and HTTP/3 where possible, and will strive to enable
simple mapping to other protocols such as COAP when doing so does not
conflict with the primary focus.

Milestones to include:
- Core delegation protocol
- Key presentation mechanism bindings to the core protocol including TLS,
detached HTTP signature, and embedded HTTP signatures
- Conveyance mechanisms for identifiers and assertions
- Guidelines for use of protocol extension points
- (if needed) Guidelines on migration paths, implementation, and operations

Where possible, the group will seek to make use of tools to guide and inform
the standardization process including formal analysis, architecture documents,
and use case documents. These artifacts will not be considered as working
group milestones or deliverables.

The working group will cooperate and coordinate with other IETF WGs such as
OAUTH, and work with external organizations, such as the OpenID Foundation,
as appropriate.

Milestones:

  Jul 2021 - Core delegation protocol in WGLC

  Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to
  WGLC

  Oct 2021 - Key presentation mechanism binding to the core protocol, 
  detached HTTP signatures, to WGLC

  Oct 2021 - Key presentation mechanism binding to the core protocol,
  embedded HTTP signature, to WGLC

  Dec 2021 - Guidelines for use of protocol extension points to WGLC

  Feb 2022 - Guidelines on migration paths, implementation, and operations to
   WGLC





    

    


    

  


--------------482FBF1D47BB2A6BF10C111A--


From nobody Mon Jul  6 08: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 233173A16BB for ; Mon,  6 Jul 2020 08:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level: 
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 fUpEfsWH1ujd for ; Mon,  6 Jul 2020 08:49:19 -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 882113A16BC for ; Mon,  6 Jul 2020 08:49:18 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d77 with ME id zrpE220034FMSmm03rpEXQ; Mon, 06 Jul 2020 17:49:16 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 06 Jul 2020 17:49:16 +0200
X-ME-IP: 86.238.65.197
To: Roman Danyliw , Dick Hardt 
Cc: Nat Sakimura , "txauth@ietf.org" , The IESG 
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com>     <3c21e0fa-5636-54fe-675f-abc5b41ab09e@free.fr>  <731a364a19a74e1d982d59d9c441dc0a@cert.org>
From: Denis 
Message-ID: 
Date: Mon, 6 Jul 2020 17:49: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
In-Reply-To: <731a364a19a74e1d982d59d9c441dc0a@cert.org>
Content-Type: multipart/alternative; boundary="------------D6BF789AA34D0550171A0845"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 06 Jul 2020 15:49:22 -0000

This is a multi-part message in MIME format.
--------------D6BF789AA34D0550171A0845
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

One single comment.

Dick wrote on the last line:

    I think pretty much everyone is onboard supporting privacy, but not
    all use cases have the same privacy considerations.

I hope that this is true, but in such a case I can't understand why the 
word "*privacy*" is missing in the charter.

Denis

Note: IESG added

> Hello!
>
> I’m top-posting here because there is no easy way for me to cleaning 
> insert my process comment.  I think we are having a necessary 
> conversation below and in no way should it stop because of this note.
>
> As a process check, this thread started with a request for community 
> review on the charter text [1]. Among other things, this charter 
> review is trying to ensure the problem is clear, defines the bounds of 
> the desired solutions and identifies critical objections from the 
> consensus-derived text.  The text is not intended to define detailed 
> requirements/architecture, resolve tradeoffs, or to specify a 
> solution, unless they are critical to bounding the solution.  These 
> details should be left to future discussions of a chartered WG (not 
> that they can’t start now in parallel).  Additionally, as a reminder, 
> while there are multiple individual drafts with proposed solutions in 
> the datatracker, the design decisions they make are not part of the 
> charter and their adoption is not assumed by the charter. If there are 
> key design elements in those or any other documents that is felt to be 
> crucial to scoping the WG,  we need to capture the thinking, 
> generalize it (as appropriate), and add it to the charter text 
> explicitly or by reference.
>
> Let’s continue to talk about the technical details of the use cases, 
> design properties, constraints and candidate solutions.  Additionally, 
> given the -05 charter text and milestones [2], it would be helpful to 
> understand what outstanding concerns remain with the charter text in 
> preparation for the Thursday, July 9^th telechat where the IESG will 
> use community feedback to help decide the way ahead for this proposed WG.
>
> Roman
>
> [1] 
> https://mailarchive.ietf.org/arch/msg/txauth/4nE8rtyRPtdk0FrclQ1c-FWMO8w/
>
> [2] https://datatracker.ietf.org/doc/charter-ietf-gnap/ 
> 
>
> *From:* Txauth  *On Behalf Of *Dick Hardt
> *Sent:* Friday, July 3, 2020 9:41 PM
> *To:* Denis 
> *Cc:* Nat Sakimura ; txauth@ietf.org
> *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization 
> Protocol (gnap)
>
> + Nat as he is mentioned
>
> - IESG
>
> On Fri, Jul 3, 2020 at 2:16 AM Denis  > wrote:
>
>     Hello Dick,
>
>         Catching up on this email ... comments inserted ...
>
>         On Mon, Jun 29, 2020 at 12:06 AM Denis          > wrote:
>
>             Hello Dick,
>
>                 Denis, thanks for sharing your thoughts, some
>                 clarifications on your statements inserted:
>
>                 On Fri, Jun 26, 2020 at 9:42 AM Denis
>                 > wrote:
>
>                 
>
>                         *New proposed charter*
>
>                 
>
>
>                         Resource servers inform their clients about
>                         which access token formats are acceptable and
>                         depending upon the king of operation
>                         that is requested, which kind of attributes
>                         are needed and from which ASs that my be obtained.
>
>                 While at times this may be appropriate, at other times
>                 disclosing the attributes the RS requires is not
>                 needed by the client.
>                 For example, an enterprise client accessing a resource
>                 does not need to know which groups a user belongs to,
>                 but the RS may require that to determine if the user
>                 running the client has access.
>
>             As soon as there is a desire to implement privacy by
>             default, the client should not provide more attributes
>             than strictly necessary.
>             Even after three readings of your example, I failed to
>             understand it.
>
>
>                         A major difference with OAuth 2.0 is that
>                         there is no bilateral trust relationship
>                         between an authorization server and a resource
>                         server:
>                         for a given category of attributes, a resource
>                         server may trust one or more authorization
>                         servers. Another major difference with OAuth 2.0.
>                         is that the content of an attributes token is
>                         meant to be accessible to the client.
>
>                 This is not how OAuth 2.0 works. See slides 7 and 8
>                 from my original IETF presentation on what became
>                 OAuth 2.0
>
>                 https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation
>
>             I looked at the two slides.
>
>             Unfortunately slide 7 has just one arrow with the word
>             "trust". This is insufficient to understand what is meant
>             unless being present
>             at the presentation. Does it mean that the PR (RS) trusts
>             one AS or that it may trust multiple ASs ?
>
>             Unfortunately slide 8 has just one arrow between the PR
>             and the AS which is red-crossed but no text at all. This
>             is insufficient to understand
>             what is meant unless being present at the presentation.
>             Does it mean that the PR and the AS never communicate
>             directly ?
>             Does it mean that they have no relationships at all,
>             besides the one way trust relationship mentioned in slide 7 ?
>
>             So it hard to say whether these two slides are indeed
>             meaning that there is no bilateral relationship between an
>             authorization server and a resource server.
>
>         Apologies for not providing an explanation on the slides.
>
>         Slide 7 shows that trust between the AS and PR (now RS) was
>         unidirectional, from the RS to the AS.
>
>         Slide 8 indicates that trust is not bidirectional.
>
>     [Denis] ... which means that slide 8 contradicts slide 7. :-)
>
> Slide 8 says it does not go both ways. Slide 7 says it goes one way. I 
> don't see the contradiction.
>
>     I would have preferred that you meant: the RS and the AS never
>     communicate directly, which is indeed a nice property to follow
>     to ensure the user's privacy.
>
> That is one model. Other models are appropriate in other circumstances..
>
>         There is no limit on how many ASs an RS may trust.
>
>     [Denis] This is fine.
>
>         On June 12, Nat Sakimura recently answered to an email with
>         the following topic:
>
>                 Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22
>                 (The OAuth 2.0 Authorization Framework: JWT Secured
>                 Authorization Request))
>
>             My arguments were:
>
>                  The original model for OAuth was making the
>             assumption that the AS and the RS had a strong bilateral
>             relationship.
>
>             *A key question is whether such strong relationship will
>             be maintained for ever *or
>             whether it will be allowed to perform some evolutions of
>             this relationship.
>
>             In order to respect the privacy of the users, there is the
>             need to encompass other scenarios. One of these scenarios
>             is that the AS and the RS
>             do not need any longer to have such a strong relationship.
>             In terms of trust relationships, a RS simply needs to
>             trust the access tokens issued by an AS.
>             The AS does have any more a "need to know" of all the RSs
>             that are accepting its access tokens. This would be a
>             major simplification of the current global architecture.
>
>             Nat's position was:
>
>                 "My take is that the basic assumption of OAuth 2.0
>                 Framework is that there is a strong relationship
>                 between AS and RS.
>                 I feel that it is quite unrealistic that an RS would
>                 trust the access token issued by an AS that it has no
>                 strong relationship with".
>
>             There are indeed different positions on this topic.
>
>         I don't think Nat and I have different opinions, but I will
>         let Nat clarify.
>
>         Just because there is a strong relationship between the AS and
>         RS, does not mean it is bidirectional. I would understand
>
>         "I feel that it is quite unrealistic that an RS would trust
>         the access token issued by an AS that it has no strong
>         relationship with"
>
>         to indicate Nat is expecting the trust to be from the RS to
>         the AS.
>
>     [Denis] Speaking of a "strong relationship" is ambiguous. The key
>     point being whether the relationship is unilateral or bilateral.
>     There is no need to use the wording "strong relationship" when the
>     relationship is only unilateral: a RS simply trusts an AS for the
>     access tokens it issues.
>     In such a case, this does not mean that an AS is knowing all the
>     RSs that are trusting it.
>
>     On the contrary, a strong (bi-)relationship is when a RS and an AS
>     both agree between them about the meaning of scope parameters.
>     This is a typical case for OAuth 2.0.
>
> You can ask Nat what he meant by "strong relationship"
>
> The AS is stating what a scope means to it and the user.. The RS can 
> do whatever it wants. I don't see that as requiring a bidirectional 
> relationship.
>
>                 The AS may not even know who the RS (or PR in the
>                 slides) is.
>
>                 
>
>
>                     I got rid of the word "delegation": the client
>                     does not delegate anything to an authorization
>                     server. If it would, this would mean that the
>                     authorization server
>                     would be able to act as the client and could know
>                     everything that the client will do, which comes
>                     into contradiction with the user's privacy.
>
>                 The above is not true.
>
>                 The Resource Owner is delegating access control to the
>                 AS in authorization use cases.
>
>             The OAuth 2.0 model does not mandate any more the presence
>             of a Resource Owner.
>
>         Why do you say that? The RO is who owns the RS. Your statement
>         does not make sense.
>
>     [Denis] I mean that there is not necessarily a protocol defined so
>     that the RO can interact with the requests from the clients.
>
> Is the RO the User? In consumer use cases it usually is, and the RO is 
> using the client. I'm not sure what you scenario you are describing
>
>                 The client is may be delegating user authentication to
>                 the AS in identity claim use cases.
>
>             Delegating user authentication to the AS is different from
>             delegating access control to the AS.
>
>         Agreed. Your statement was there was no delegation. I'm
>         explaining there are potentially two delegations.
>
>                 The AS can act as the client in many OAuth
>                 deployments, as the access token is a bearer token.
>
>             A bearer token is rather insecure.
>
>         Cookies are also bearer tokens. But we use them all the time
>         in web apps for storing session state and prior authentication! :)
>
>                 That does not mean the AS knows what the client is doing.
>
>             There are currently two attempts in the OAuth WG to let
>             know to the AS what the client is doing:
>
>               * draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
>                 Authorization Framework: JWT Secured Authorization
>                 Request)
>               * draft-ietf-oauth-rar-01         (OAuth 2.0 Rich
>                 Authorization Requests)
>
>         Those are optional, and in some situations are a desired property.
>
>     [Denis] However, in these two drafts, the privacy considerations
>     sections are silent on this point.
>
> There are lots of missing details in both drafts! Security 
> considerations, error messages etc.
>
> I think pretty much everyone is onboard supporting privacy, but not 
> all use cases have the same privacy considerations.
>
> /Dick
>


--------------D6BF789AA34D0550171A0845
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
One single comment.

    


    

    
Dick wrote on the last line:

    

      
I think pretty much everyone is
        onboard supporting privacy, but not all use cases have the same
        privacy considerations.

    

    
I hope that this is true, but in such a
      case I can't understand why the word "privacy" is missing
      in the charter.

    


    

    
Denis

    


    

    
Note: IESG added

    


    

    

      
      
      
      

        
Hello!

        
 

        
I’m top-posting here because there is no
          easy way for me to cleaning insert my process comment.  I
          think we are having a necessary conversation below and in no
          way should it stop because of this note.

        
 

        
As a process check, this thread started
          with a request for community review on the charter text [1]. 
          Among other things, this charter review is trying to ensure
          the problem is clear, defines the bounds of the desired
          solutions and identifies critical objections from the
          consensus-derived text.  The text is not intended to define
          detailed requirements/architecture, resolve tradeoffs, or to
          specify a solution, unless they are critical to bounding the
          solution.  These details should be left to future discussions
          of a chartered WG (not that they can’t start now in
          parallel).  Additionally, as a reminder, while there are
          multiple individual drafts with proposed solutions in the
          datatracker, the design decisions they make are not part of
          the charter and their adoption is not assumed by the charter. 
          If there are key design elements in those or any other
          documents that is felt to be crucial to scoping the WG,  we
          need to capture the thinking, generalize it (as appropriate),
          and add it to the charter text explicitly or by reference.

        
 

        
Let’s continue to talk about the technical
          details of the use cases, design properties, constraints and
          candidate solutions.  Additionally, given the -05 charter text
          and milestones [2], it would be helpful to understand what
          outstanding concerns remain with the charter text in
          preparation for the Thursday, July 9th telechat
          where the IESG will use community feedback to help decide the
          way ahead for this proposed WG.

        
 

        
Roman

        
 

        
[1] 
https://mailarchive.ietf.org/arch/msg/txauth/4nE8rtyRPtdk0FrclQ1c-FWMO8w/

        
[2] 
            https://datatracker.ietf.org/doc/charter-ietf-gnap/

        
 

        
 

        
 

        

          

            

              
From: Txauth
                <txauth-bounces@ietf.org> On Behalf Of
                Dick Hardt

                Sent: Friday, July 3, 2020 9:41 PM

                To: Denis <denis.ietf@free.fr>

                Cc: Nat Sakimura <sakimura@gmail.com>;
                txauth@ietf.org

                Subject: Re: [Txauth] WG Review: Grant
                Negotiation and Authorization Protocol (gnap)

            

          

          
 

          

            

              
+ Nat as he is mentioned

            

            

              
- IESG

            

            
 

            

              

                
On Fri, Jul 3, 2020 at 2:16 AM
                  Denis <denis.ietf@free.fr>
                  wrote:

              

              

                

                  

                    
Hello Dick,

                  

                  

                    
 

                  

                  

                    

                      

                        

                          

                            

                              
Catching up on this
                                email ... comments inserted ...

                            

                            
 

                            

                              

                                
On Mon, Jun 29,
                                  2020 at 12:06 AM Denis <denis.ietf@free.fr>
                                  wrote:

                              

                              

                                

                                  

                                    
Hello
                                        Dick,

                                  

                                  

                                    
 

                                  

                                  

                                    

                                      

                                        
Denis,
                                            thanks for sharing your
                                            thoughts, some
                                            clarifications on your
                                            statements inserted:

                                      

                                      
 

                                      

                                        

                                          
On
                                              Fri, Jun 26, 2020 at 9:42
                                              AM Denis <denis.ietf@free.fr>
                                              wrote:

                                        

                                        

                                          
<snip>

                                        

                                        

                                          

                                            

                                              

                                                
New
                                                      proposed charter

                                              

                                            

                                          

                                        

                                        

                                          
<snip> 

                                        

                                        

                                          

                                            

                                              

                                                


                                                    Resource servers
                                                    inform their clients
                                                    about which access
                                                    token formats are
                                                    acceptable and
                                                    depending upon the
                                                    king of operation

                                                    that is requested,
                                                    which kind of
                                                    attributes are
                                                    needed and from
                                                    which ASs that my be
                                                    obtained.

                                              

                                            

                                          

                                        

                                        

                                          
While
                                              at times this may be
                                              appropriate, at other
                                              times disclosing the
                                              attributes the RS requires
                                              is not needed by the
                                              client.
                                              

                                              For example, an enterprise
                                              client accessing a
                                              resource does not need to
                                              know which groups a user
                                              belongs to,
                                              

                                              but the RS may require
                                              that to determine if the
                                              user running the client
                                              has access.

                                        

                                      

                                    

                                  

                                  
As
                                      soon as there is a desire to
                                      implement privacy by default, the
                                      client should not provide more
                                      attributes than strictly
                                      necessary.
                                      

                                      Even after three readings of your
                                      example, I failed to understand
                                      it.

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                


                                                    A major difference
                                                    with OAuth 2.0 is
                                                    that there is no
                                                    bilateral trust
                                                    relationship between
                                                    an authorization
                                                    server and a
                                                    resource server:
                                                    

                                                    for a given category
                                                    of attributes, a
                                                    resource server may
                                                    trust one or more
                                                    authorization
                                                    servers. Another
                                                    major difference
                                                    with OAuth 2.0.

                                                    is that the content
                                                    of an attributes
                                                    token is meant to be
                                                    accessible to the
                                                    client.

                                              

                                            

                                          

                                        

                                        

                                          
This
                                              is not how OAuth 2.0
                                              works. See slides 7 and 8
                                              from my original IETF
                                              presentation on what
                                              became OAuth 2.0

                                        

                                        

                                          
 

                                        

                                        
                                      

                                    

                                  

                                  
I
                                      looked at the two slides. 
                                    

                                  
Unfortunately
                                      slide 7 has just one arrow with
                                      the word "trust". This is
                                      insufficient to understand what is
                                      meant unless being present
                                      

                                      at the presentation. Does it mean
                                      that the PR (RS) trusts one AS or
                                      that it may trust multiple ASs ?

                                

                              

                              

                                

                                  
Unfortunately
                                      slide 8 has just one arrow between
                                      the PR and the AS which is
                                      red-crossed but no text at all.
                                      This is insufficient to understand

                                      what is meant unless being present
                                      at the presentation. Does it mean
                                      that the PR and the AS never
                                      communicate directly ?

                                      Does it mean that they have no
                                      relationships at all, besides the
                                      one way trust relationship
                                      mentioned in slide 7 ?

                                  
So
                                      it hard to say whether these two
                                      slides are indeed meaning that
                                      there is no bilateral relationship
                                      between an authorization server
                                      and a resource server.

                                

                              

                              

                                

                                  
Apologies for not
                                    providing an explanation on the
                                    slides.

                                

                                

                                  
 

                                

                                

                                  
Slide 7 shows
                                    that trust between the AS and PR
                                    (now RS) was unidirectional, from
                                    the RS to the AS.

                                

                                

                                  
Slide 8
                                    indicates that trust is not
                                    bidirectional.

                                

                              

                            

                          

                        

                      

                    

                  

                  
[Denis] 
                      ... which means that slide 8 contradicts slide 7. 
                      :-)
                    

                

              

              

                
 

              

              

                
Slide 8 says it does not go both
                  ways. Slide 7 says it goes one way. I don't see the
                  contradiction. 

              

              

                

                  
I
                      would have preferred that you meant: the RS and
                      the AS never communicate directly, which is indeed
                      a nice property to follow
                      

                      to ensure the user's privacy.

                

              

              

                
That is one model. Other models are
                  appropriate in other circumstances..

              

              

                
 

              

              

                

                  
 

                  

                    

                      

                        

                          

                            

                              

                                

                                  
There is no limit
                                    on how many ASs an RS may trust.

                                

                              

                            

                          

                        

                      

                    

                  

                  
[Denis]
                      This is fine.

                  

                    

                      

                        

                          

                            

                              

                                
 On
                                    June 12, Nat Sakimura recently
                                    answered to an email with the
                                    following topic:

                              

                              

                                

                                  

                                    
Re: [OAUTH-WG] Comments
                                        on draft-ietf-oauth-jwsreq-22
                                        (The OAuth 2.0 Authorization
                                        Framework: JWT Secured
                                        Authorization Request))

                                  

                                  
My arguments were:

                                  
     The original model
                                      for OAuth was making the
                                      assumption that the AS and the RS
                                      had a strong bilateral
                                      relationship.

                                    

                                          A
                                        key question is whether such
                                        strong relationship will be
                                        maintained for ever
                                      or
                                    

                                        
                                      whether it will be allowed to
                                      perform some evolutions of this
                                      relationship.

                                    

                                        
                                      In order to respect the privacy of
                                      the users, there is the need to
                                      encompass other scenarios. One of
                                      these scenarios is that the AS and
                                      the RS
                                    

                                        
                                      do not need any longer to have
                                      such a strong relationship. In
                                      terms of trust relationships, a RS
                                      simply needs to trust the access
                                      tokens issued by an AS.
                                    

                                        
                                      The AS does have any more a "need
                                      to know" of all the RSs that are
                                      accepting its access tokens. This
                                      would be a major simplification of
                                      the current global architecture.

                                  
Nat's position was:
                                    

                                  

                                    
"My take is that the
                                        basic assumption of OAuth 2.0
                                        Framework is that there is a
                                        strong relationship between AS
                                        and RS.
                                        

                                        I feel that it is quite
                                        unrealistic that an RS would
                                        trust the access token issued by
                                        an AS that it has no strong
                                        relationship with".

                                  

                                  
There are indeed
                                      different positions on this
                                      topic. 
                                    

                                

                              

                              

                                
 

                              

                              

                                
I don't think Nat
                                  and I have different opinions, but I
                                  will let Nat clarify.

                              

                              

                                
Just because there
                                  is a strong relationship between the
                                  AS and RS, does not mean it is
                                  bidirectional. I would understand 

                              

                              

                                
 

                              

                              

                                
"I feel that it is
                                  quite unrealistic that an RS would
                                  trust the access token issued by an AS
                                  that it has no strong relationship
                                  with"

                              

                              

                                
 

                              

                              

                                
to indicate Nat is
                                  expecting the trust to be from the RS
                                  to the AS.

                              

                            

                          

                        

                      

                    

                  

                  
[Denis] 
                      Speaking of a "strong relationship" is ambiguous.
                      The key point being whether the relationship is
                      unilateral or bilateral.

                      There is no need to use the wording "strong
                      relationship" when the relationship is only
                      unilateral: a RS simply trusts an AS for the
                      access tokens it issues.
                      

                      In such a case, this does not mean that an AS is
                      knowing all the RSs that are trusting it.

                  
On
                      the contrary, a strong (bi-)relationship is when a
                      RS and an AS both agree between them about the
                      meaning of scope parameters.

                      This is a typical case for OAuth 2.0.

                

              

              

                
You can ask Nat what he meant by
                  "strong relationship"

              

              

                
 

              

              

                
The AS is stating what a scope
                  means to it and the user.. The RS can do whatever it
                  wants. I don't see that as requiring a bidirectional
                  relationship.

              

              

                
 

              

              

                
 

              

              

                
 

              

              

                

                  
 

                  

                    

                      

                        

                          

                            

                              
 

                              

                                

                                  

                                    

                                      

                                        

                                          
The
                                              AS may not even know who
                                              the RS (or PR in the
                                              slides) is.

                                        

                                        

                                          
 

                                        

                                        

                                          
<snip> 

                                        

                                        

                                          

                                            

                                              


                                                  I got rid of the word
                                                  "delegation": the
                                                  client does not
                                                  delegate anything to
                                                  an authorization
                                                  server. If it would,
                                                  this would mean that
                                                  the authorization
                                                  server
                                                  

                                                  would be able to act
                                                  as the client and
                                                  could know everything
                                                  that the client will
                                                  do, which comes into
                                                  contradiction with the
                                                  user's privacy.

                                            

                                          

                                        

                                        

                                          
 

                                        

                                        

                                          
The above
                                              is not true.

                                        

                                        

                                          
 

                                        

                                        

                                          
The
                                              Resource Owner is
                                              delegating access control
                                              to the AS in authorization
                                              use cases.

                                        

                                      

                                    

                                  

                                  
The
                                      OAuth 2.0 model does not mandate
                                      any more the presence of a
                                      Resource Owner.

                                

                              

                              

                                
 

                              

                              

                                
Why do you say
                                  that? The RO is who owns the RS. Your
                                  statement does not make sense.

                              

                            

                          

                        

                      

                    

                  

                  
[Denis] 
                      I mean that there is not necessarily a protocol
                      defined so that the RO can interact with the
                      requests from the clients.

                

              

              

                
Is the RO the User? In consumer use
                  cases it usually is, and the RO is using the client.
                  I'm not sure what you scenario you are describing

              

              

                
 

              

              

                

                  
 

                  

                    

                      

                        

                          

                            

                              

                                
 

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
 

                                        

                                        

                                          
The
                                              client is may be
                                              delegating user
                                              authentication to the AS
                                              in identity claim use
                                              cases.

                                        

                                      

                                    

                                  

                                  
Delegating
                                      user authentication to the AS is
                                      different from delegating access
                                      control to the AS.

                                

                              

                              

                                
 

                              

                              

                                
Agreed. Your
                                  statement was there was no delegation.
                                  I'm explaining there are
                                  potentially two delegations. 

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
 

                                        

                                        

                                          
The
                                              AS can act as the client
                                              in many OAuth deployments,
                                              as the access token is a
                                              bearer token.
                                            

                                        

                                      

                                    

                                  

                                  
A
                                      bearer token is rather insecure.

                                

                              

                              

                                
Cookies are also
                                  bearer tokens. But we use them all the
                                  time in web apps for storing session
                                  state and prior authentication! :)

                              

                              

                                
 

                              

                              

                                
 

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
That
                                              does not mean the AS knows
                                              what the client is doing.
                                            

                                        

                                      

                                    

                                  

                                  
There
                                      are currently two attempts in the
                                      OAuth WG to let know to the AS
                                      what the client is doing:

                                  
    
                                    
  • 
                                      draft-ietf-oauth-jwsreq-22  
                                        (The OAuth 2.0 Authorization
                                        Framework: JWT Secured
                                        Authorization Request)
    • 
                                    
  • 
                                      draft-ietf-oauth-rar-01
                                                (OAuth 2.0 Rich
                                        Authorization Requests)
    • 
                                  

                                

                              

                              

                                
Those are optional,
                                  and in some situations are a desired
                                  property.

                              

                            

                          

                        

                      

                    

                  

                  
[Denis] 
                      However, in these two drafts, the privacy
                      considerations sections are silent on this point.

                

              

              

                
There are lots of missing details
                  in both drafts! Security considerations, error
                  messages etc.

              

              

                
 

              

              

                
I think pretty much everyone is
                  onboard supporting privacy, but not all use cases have
                  the same privacy considerations.

              

              

                
 

              

              

                
/Dick

              

            

          

        

      

    

    


    

  


--------------D6BF789AA34D0550171A0845--


From nobody Mon Jul  6 09:13: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 C40233A17C6 for ; Mon,  6 Jul 2020 09:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level: 
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=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 xxlXkGb5KtT3 for ; Mon,  6 Jul 2020 09:13:41 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450: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 891EA3A175A for ; Mon,  6 Jul 2020 09:13:29 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id t74so22935828lff.2 for ; Mon, 06 Jul 2020 09:13: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=KOufeDjyTe/MS8/f+oC8SF2neSwrk0CRjZw0Me24Hy0=; b=lWYnWXYQVoy0U6WgF+ulv/RdCAEQIh9WavpxuQy34aUHP+kTYPEto9QaFhu3r9+2RR 9S1U6VcKWjP7l1gufhqJeFJx8bSeaSB1E/0e339e30hXt5+3Q6+6S41EyUrNi8y21k08 xXSzUO3UV8xX9hhlM5iLOJJrKeXcDfy2d0rfyJR1mIvotS5AQtsAnfaV3GRmfETfqzaM 7hIFXAVg6yMdBWedE2B0woIPjLbLTxyka9ZP1RJxkjPOQBk5/EPdh+gG8iv7jyJgC7jj zc41O3ZyHeRaOZZ6rRurBz6/r+bFX41T5QyLYcVXKF39e3HRD9lvPYoVSJwrLvegSBez 2+qQ==
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=KOufeDjyTe/MS8/f+oC8SF2neSwrk0CRjZw0Me24Hy0=; b=P1uwo3uwgwzA4HY7QBeRAx7O8KOJ+UxOumHKKVboNXrb//33VN666uiGjCLNz/WrQU UbliaEm7w2GEf3Scuu3pjC59tQtaFFhRu7Bh6R2P6msKGdQdxIp1RA6mZFE9Gqi+ZNo8 QnmfTmqI/uHthjFOWP4VPEiiGtYb04jyufSZZWAclbYeZWNp4h98y/6yYkHamPTXEp1L tsYZlA5ni0OBw8HZ/pZcBNg/DeeoqzmMYkCxDdmFRw27DwpK1186fYaiy1t9fTMPWoQl Q/uCG8MQhP+J8lRngMfOPiWvLVSO4Br7E4sLCo8Zcfr5ydPJYhnZQpAl0zoj2Via3HqQ 6tWQ==
X-Gm-Message-State: AOAM533md/F7fYcmu24R6NwlJmrS3bXSskoPG6dTnxXlMKz9YyQ0qLYW ZK7IhtRBu5TuvDGunHoh5GRNvTZwsPrVm7iT4cc=
X-Google-Smtp-Source: ABdhPJxMVUGiKPJ6Uw6OK1TfyMtWlRN8RrYifQiw129AA0We7+MBx30K1LPcgC2ydVNzGEwdzdIx+zCJVPgaKJ3XXZQ=
X-Received: by 2002:a19:4143:: with SMTP id o64mr30261731lfa.157.1594052007424;  Mon, 06 Jul 2020 09:13:27 -0700 (PDT)
MIME-Version: 1.0
References:        <20200705225343.GQ16335@kduck.mit.edu> 
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 6 Jul 2020 09:12:51 -0700
Message-ID: 
To: Fabien Imbault 
Cc: Benjamin Kaduk , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a7f93005a9c8277b"
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 06 Jul 2020 16:13:50 -0000

--000000000000a7f93005a9c8277b
Content-Type: text/plain; charset="UTF-8"

Fabien: it would be interesting to see how you think JSON-LD could be used
in the protocol if you have some ideas on that. In XAuth, I am explicit
that there are different formats / schema for tokens and claims. There is
no default, so it is clear how additional formats can be requested and
returned.

Ben: I think that token formats such as macaroons are out of scope of GNAP,
or at least the core protocol. The key feature of macaroons is the ability
to further restrict the authorization. An interesting idea, but depends on
a shared secret, and I have not heard of deployments. In a quick google on
macaroons, I came across this talk from Gopher Con
https://about.sourcegraph.com/go/gophercon-2018-an-over-engineering-disaster-with-macaroons
.

Justin: good to see we are on the same page on all your points. I'd add
that we should consider what JSON is used in the protocol to minimize or
eliminate any impedance mismatch between JSON and CBOR.

/Dick

On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault 
wrote:

> Writing too fast, with an iteration of unrelated examples, did not convey
> the right message. Sorry if it wasn't clear and confusing. We indeed need
> to differentiate between bearer tokens (e.g. JWT, macaroons or even simple
> cookies, etc.) and identity claims (e.g. OIDC claims, linked data proofs,
> etc.).
> I only wanted to say that we need to take into account that there might be
> a variety of formats defined elsewhere. Not only OIDC (for claims) + JWT
> (for access tokens).
>
> Regarding JWT vs macaroons : I would say that JWT are additive, while
> macaroons are organized around caveats (so they're subtractive in a sense).
> But indeed they are both used in similar settings.
>
> Hope that clarifies.
> Fabien
>
> On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk  wrote:
>
>> Hi Dick, Fabien,
>>
>> Just to clarify on one point, and check whether I'm confused:
>>
>> On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:
>> > On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault > >
>> > wrote:
>> >
>> > > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt 
>> wrote:
>> > >
>> > >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <
>> fabien.imbault@gmail.com>
>> > >> wrote:
>> >
>> > >
>> > >> Just like OAuth 2.0, the access token is opaque to the client, and
>> it is
>> > >> not specified, so I'm confused what you mean by "other types of
>> tokens than
>> > >> JWT"?
>> > >>
>> > >> FI : I mean, for instance, linked data proofs, macaroons, and so on.
>> > >
>> >
>> > I see. When I read 'token', I think of access tokens. You are referring
>> to
>> > what I would call a claims, which per above are defined somewhere else.
>>
>> My understanding was that macaroons, at least, were complete tokens that
>> incorporate (at least by reference) multiple claims.  So a macaroon and a
>> JWT would be analogous in that sense (container holding many claims).  I'm
>> not sure whether the same holds for a linked data proof (or if it's just a
>> way to represent a single claim), though.
>>
>> Am I confused?
>>
>> Thanks,
>>
>> Ben
>>
>

--000000000000a7f93005a9c8277b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Fabien: it would be inte=
resting to see how you think JSON-LD could be used in the protocol if you h=
ave some ideas on that. In XAuth, I am explicit that there are different fo=
rmats / schema for tokens=C2=A0and claims. There is no default, so it is cl=
ear how additional formats can be requested and returned.

Ben: I think that token formats such as macaroons are out of scope of GNA=
P, or at least the core protocol. The key feature of macaroons is the abili=
ty to further restrict the authorization. An interesting idea, but depends =
on a shared secret, and I have not heard of deployments. In a quick google =
on macaroons, I came across this talk from Gopher Con=C2=A0https://about.sourcegraph.com/go/gophercon-2018-an-over-engine=
ering-disaster-with-macaroons.

Justin: good to=
 see we are on the same page on all your points. I'd add that we should=
 consider what JSON is used in the protocol to minimize or eliminate any=C2=
=A0impedance=C2=A0mismatch between JSON and CBOR.

=
/Dick

On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Writ=
ing too fast, with an iteration of unrelated examples, did not convey the r=
ight message.=C2=A0Sorry if it wasn't clear and confusing. We indeed ne=
ed to differentiate between bearer tokens (e.g. JWT, macaroons or even simp=
le cookies, etc.) and identity claims (e.g. OIDC claims, linked data proofs=
, etc.).
I only wanted to say that we need to take into accou=
nt that there might be a variety of formats defined elsewhere. Not only OID=
C (for claims) + JWT (for access tokens).
=C2=A0
=
Regarding JWT vs macaroons : I would say that JWT are additive, while macar=
oons are organized around caveats (so they're subtractive in a sense). =
But indeed they are both used in similar settings.=C2=A0

Hope that clarifies.
Fabien

On Mon, Jul 6, 2020=
 at 12:53 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Dick, Fabien,



Just to clarify on one point, and check whether I'm confused:



On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:

> On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault <fabien.imbault@gmail.com><=
br>
> wrote:

> 

> > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt <dick.hardt@gmail.com> wrote:<=
br>
> >

> >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <fabien.imbault@gmail.co=
m>

> >> wrote:

> 

> >

> >> Just like OAuth 2.0, the access token is opaque to the client=
, and it is

> >> not specified, so I'm confused what you mean by "oth=
er types of tokens than

> >> JWT"?

> >>

> >> FI : I mean, for instance, linked data proofs, macaroons, and=
 so on.

> >

> 

> I see. When I read 'token', I think of access tokens. You are =
referring to

> what I would call a claims, which per above are defined somewhere else=
.



My understanding was that macaroons, at least, were complete tokens that
incorporate (at least by reference) multiple claims.=C2=A0 So a macaroon an=
d a

JWT would be analogous in that sense (container holding many claims).=C2=A0=
 I'm

not sure whether the same holds for a linked data proof (or if it's jus=
t a

way to represent a single claim), though.



Am I confused?



Thanks,



Ben






--000000000000a7f93005a9c8277b--


From nobody Mon Jul  6 09:20: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 2ED823A1629 for ; Mon,  6 Jul 2020 09:20: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_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=MmlpLUfz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qeeYjCK6
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 cOOtoD_eyzE5 for ; Mon,  6 Jul 2020 09:20:29 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3188F3A15D9 for ; Mon,  6 Jul 2020 09:20:29 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 83F685C0219; Mon,  6 Jul 2020 12:20:28 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 06 Jul 2020 12:20:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=NCo+ZGGqcVzRFzo0FFt4WxLdfWLaKhV 8iYfwmiDdaM4=; b=MmlpLUfzfv33TtCzw/a3xKh929VP5+xivFhlNpAvgogSP0C MCNfAaywif9oaTpXo27e9kVMpYUR+EU/VA6UzlaQtH5rdOs6fh9+3Wf4KZizOzgV j5ujwHS2wyFk1pTDIa9SKED2ajmBnrC6nr+9h+kvarYgQLYDeoSYecmpBQcZmEXN mdQKR/3bSppLTohyyL+xPxhHPZCsterOAxW/+r+sMCtAfQzbtI1DLJ3WaltHDZXp Bzr7of61C7S5bXdAFto5kp+O2TFISIw4hWprQoM5qpheThpTqLoRF0Uv/qjjR2Kp Utvky5Oh4o/GzDLu/W3wd8aLOMokDmlP+0Zr7kg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=NCo+ZG GqcVzRFzo0FFt4WxLdfWLaKhV8iYfwmiDdaM4=; b=qeeYjCK6l7bWH28+9kIUAc DSf6x7+5vpFkB00NWI7UJSNmQwuShsv1WEgDlgH9KEOPQM4HZdOW+cBLpYHBdiQF 4yQ9KZZxERHQNOZveZz+Ns0qcx3YlktQAPJNvC1Diig38P+Kn+398XnXU+sIDyc2 AgKk1GN4VTfcleekVwvzbvt7NznYQPAgMIf/TTwlNov2SAgohbgvh95nsTIL1s+F d/9To2X9e6MkfO5ucua5i9XANl3vnCqFRAusp6J/jaEv8kSIQWgiZ4bk6Pgj3qkZ VhGgI5OLoq/hHFyBbqsedEfrgUaOQDb3UP/emf/SVODiuKtSJcTvKf6ZOYEhXihA ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudefgddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdghrgih nhgvucevhhgrnhhgfdcuoeifhigtsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtth gvrhhnpeeuieetledtjeegfefhgfffueevgeehfefhudejheeuleejffeugeejffegkeei heenucffohhmrghinhepshhouhhrtggvghhrrghphhdrtghomhdpihgvthhfrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepfiihtges fhgrshhtmhgrihhlrdhfmh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2F887E00B3; Mon,  6 Jul 2020 12:20:28 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:        <20200705225343.GQ16335@kduck.mit.edu>  
Date: Mon, 06 Jul 2020 12:20:07 -0400
From: "Wayne Chang" 
To: "Dick Hardt" , "Fabien Imbault" 
Cc: "Benjamin Kaduk" , txauth@ietf.org
Content-Type: multipart/alternative; boundary=af21197bf68241e3a6ffb242de2e0207
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 06 Jul 2020 16:20:31 -0000

--af21197bf68241e3a6ffb242de2e0207
Content-Type: text/plain

Hi, just wanted to chime in that in the W3C credentials ecosystem, the JWT vs. JSON-LD proofs debate has raged on and consumed a lot of everyone's time. There are a lot of industry stakeholders who are skittish around requirements to adopt unfamiliar standard, and for some large companies involved in that ecosystem JWTs are more familiar than JSON-LD. For the Verifiable Credentials spec in particular, the authors decided to support both and were careful to ensure this possibility.

This might be a decision better made higher up in the stack than what GNAP is trying to accomplish.

On Mon, Jul 6, 2020, at 12:12 PM, Dick Hardt wrote:
> Fabien: it would be interesting to see how you think JSON-LD could be used in the protocol if you have some ideas on that. In XAuth, I am explicit that there are different formats / schema for tokens and claims. There is no default, so it is clear how additional formats can be requested and returned.
> 
> Ben: I think that token formats such as macaroons are out of scope of GNAP, or at least the core protocol. The key feature of macaroons is the ability to further restrict the authorization. An interesting idea, but depends on a shared secret, and I have not heard of deployments. In a quick google on macaroons, I came across this talk from Gopher Con https://about.sourcegraph.com/go/gophercon-2018-an-over-engineering-disaster-with-macaroons.
> 
> Justin: good to see we are on the same page on all your points. I'd add that we should consider what JSON is used in the protocol to minimize or eliminate any impedance mismatch between JSON and CBOR.
> 
> /Dick
> 
> On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault  wrote:
>> Writing too fast, with an iteration of unrelated examples, did not convey the right message. Sorry if it wasn't clear and confusing. We indeed need to differentiate between bearer tokens (e.g. JWT, macaroons or even simple cookies, etc.) and identity claims (e.g. OIDC claims, linked data proofs, etc.).
>> I only wanted to say that we need to take into account that there might be a variety of formats defined elsewhere. Not only OIDC (for claims) + JWT (for access tokens).
>> 
>> Regarding JWT vs macaroons : I would say that JWT are additive, while macaroons are organized around caveats (so they're subtractive in a sense). But indeed they are both used in similar settings. 
>> 
>> Hope that clarifies.
>> Fabien
>> 
>> On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk  wrote:
>>> Hi Dick, Fabien,
>>> 
>>>  Just to clarify on one point, and check whether I'm confused:
>>> 
>>>  On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:
>>>  > On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault 
>>>  > wrote:
>>>  > 
>>>  > > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt  wrote:
>>>  > >
>>>  > >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault 
>>>  > >> wrote:
>>>  > 
>>>  > >
>>>  > >> Just like OAuth 2.0, the access token is opaque to the client, and it is
>>>  > >> not specified, so I'm confused what you mean by "other types of tokens than
>>>  > >> JWT"?
>>>  > >>
>>>  > >> FI : I mean, for instance, linked data proofs, macaroons, and so on.
>>>  > >
>>>  > 
>>>  > I see. When I read 'token', I think of access tokens. You are referring to
>>>  > what I would call a claims, which per above are defined somewhere else..
>>> 
>>>  My understanding was that macaroons, at least, were complete tokens that
>>>  incorporate (at least by reference) multiple claims. So a macaroon and a
>>>  JWT would be analogous in that sense (container holding many claims). I'm
>>>  not sure whether the same holds for a linked data proof (or if it's just a
>>>  way to represent a single claim), though.
>>> 
>>>  Am I confused?
>>> 
>>>  Thanks,
>>> 
>>>  Ben
> -- 
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
> 

--af21197bf68241e3a6ffb242de2e0207
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


Hi, just w=
anted to chime in that in the W3C credentials ecosystem, the JWT vs. JSO=
N-LD proofs debate has raged on and consumed a lot of everyone's time. T=
here are a lot of industry stakeholders who are skittish around requirem=
ents to adopt unfamiliar standard, and for some large companies involved=
 in that ecosystem JWTs are more familiar than JSON-LD. For the Ver=
ifiable Credentials spec in particular, the authors decided to support b=
oth and were careful to ensure this possibility.

=

This might be a decision better made higher up in the s=
tack than what GNAP is trying to accomplish.

On Mon, Jul 6, 2020, at 12:12 PM, Dick Hardt wrote:
Fabien: it would be interesting to see how y=
ou think JSON-LD could be used in the protocol if you have some ideas on=
 that. In XAuth, I am explicit that there are different formats / schema=
 for tokens and claims. There is no default, so it is clear how add=
itional formats can be requested and returned.

<=
div>Ben: I think that token formats such as macaroons are out of scope o=
f GNAP, or at least the core protocol. The key feature of macaroons is t=
he ability to further restrict the authorization. An interesting idea, b=
ut depends on a shared secret, and I have not heard of deployments. In a=
 quick google on macaroons, I came across this talk from Gopher Con =
;https://about.sourcegraph.com/go/gopher=
con-2018-an-over-engineering-disaster-with-macaroons.
=

Justin: good to see we are on the same page on all your p=
oints. I'd add that we should consider what JSON is used in the protocol=
 to minimize or eliminate any impedance mismatch between JSON =
and CBOR.

/Dick

On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Writing too fast, with an iteration of unrelated =
examples, did not convey the right message. Sorry if it wasn't clea=
r and confusing. We indeed need to differentiate between bearer tokens (=
e.g. JWT, macaroons or even simple cookies, etc.) and identity claims (e=
.g. OIDC claims, linked data proofs, etc.).
I on=
ly wanted to say that we need to take into account that there might be a=
 variety of formats defined elsewhere. Not only OIDC (for claims) + JWT =
(for access tokens).
 
Regarding =
JWT vs macaroons : I would say that JWT are additive, while macaroons ar=
e organized around caveats (so they're subtractive in a sense). But inde=
ed they are both used in similar settings. 

=

Hope that clarifies.
Fabien

On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk <=
;kaduk@mit.edu>=
; wrote:
Hi Dick, Fabien,
 
 J=
ust to clarify on one point, and check whether I'm confused:
 
 On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt=
 wrote:
 > On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbaul=
t <fabi=
en.imbault@gmail.com>
 > wrote:
 &=
gt; 
 > > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt =
<dick.hardt=
@gmail.com> wrote:
 > >
 > &=
gt;> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <fabien.imbault@gmail.co=
m>
 > >> wrote:
 > 
 > >
 > >> Just like OAuth 2.0, th=
e access token is opaque to the client, and it is
 > &g=
t;> not specified, so I'm confused what you mean by "other types of t=
okens than
 > >> JWT"?
 > >&g=
t;
 > >> FI : I mean, for instance, linked data p=
roofs, macaroons, and so on.
 > >
 >=
; 
 > I see. When I read 'token', I think of access tok=
ens. You are referring to
 > what I would call a claims=
, which per above are defined somewhere else..
 
=

 My understanding was that macaroons, at least, were complete token=
s that
 incorporate (at least by reference) multiple claim=
s.  So a macaroon and a
 JWT would be analogous in th=
at sense (container holding many claims).  I'm
 not s=
ure whether the same holds for a linked data proof (or if it's just a
 way to represent a single claim), though.
 
 Am I confused?
 
 Thanks,
<=
/div>
 
 Ben
=

-- 
Txauth mailing list
=




--af21197bf68241e3a6ffb242de2e0207--


From nobody Mon Jul  6 09:22: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 935213A1629 for ; Mon,  6 Jul 2020 09:22: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, 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 fo-FjzuV2aQn for ; Mon,  6 Jul 2020 09:22:06 -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 4C5E13A15D9 for ; Mon,  6 Jul 2020 09:22:06 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id t9so22915468lfl.5 for ; Mon, 06 Jul 2020 09:22: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=9n243jFpxoo8QiSLLdfV+3S+8EasPrlVANBfx4YWmsA=; b=sQjq9au3t3QN4wKYLFe8Yz2X9VB3zWUlOJz41003C+TcELqQOBpqlUw5tSZ4FfLfhZ 4iu/EuchgwJILxpzkCWioh4Iq+5bwE31Tx+/phhdslILLJEoUrOskUOeNvO0Z44Ih9jH WgJthYLi+TQ4tdUxD6x8yRMcY2MB4W7b6hNoLOE8t8QiTSoLDa513trV1aldoSNGcAgX 4mUzfu089j0zy6IM7yoppS6U1YdLdmxvQ4osE6BQTIbRVYFnIe3B6S7vaXofxXJ1LYV2 7tOU6Q8vFvQ+KcuJmJ3J6JXaRZBoPz4ViAo75GQLv/veeov9EW0lyzmTDN21UJzlZNYJ E58Q==
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=9n243jFpxoo8QiSLLdfV+3S+8EasPrlVANBfx4YWmsA=; b=dprZNOfRLp9XrPUm42w+5NR8h97d8OUgZur3nzopyjHW0qt+BLotSpaXmlIZuRGbC5 6wlrdpW66EiUZy2oup4mhcfi0HeXePfHUwZ3sEZUlyaNyIbmaoI1iBmlJBiQgaOBVFi4 yR8LZ3wVdai5SyIYDeF37uhOwsCHZJ4On785+m0LBvGpYFOtTWVrHRmvplzFzoiqcHdt fJZXD7gk7z44uNdMIdBgcCYPcCFw/ZCHLRRw+9VQopqC3W6fTOk5L0nVCPLxo/wncvdG zP5SCnNJbBn9k6ZzvqgnSpL6TobRhvSn38WVW35nCs7pMQMdNOdp/sLz3Q7iZEpAg/Go wzLA==
X-Gm-Message-State: AOAM532pLQAZ7HQrMqEhbHxyt+yPrlOHWccAUu6O/qO9W/9BqRA/2Bn1 hI77HrLc1H7O3790v8+ZiJDaT/X9fPCMvQ/6DjZWC/k+
X-Google-Smtp-Source: ABdhPJwiYC8C01t5dTpoBNsDKjMCa5HNM/sFm3r/5XAlrbMhsmIiKGFgOo48YCrXmkCDzqW2+O4xAWLKWwG8CYUrZgY=
X-Received: by 2002:ac2:5093:: with SMTP id f19mr31022330lfm.10.1594052524198;  Mon, 06 Jul 2020 09:22:04 -0700 (PDT)
MIME-Version: 1.0
References: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>
In-Reply-To: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>
From: Dick Hardt 
Date: Mon, 6 Jul 2020 09:21:28 -0700
Message-ID: 
To: Denis 
Cc: "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000754e7405a9c846e6"
Archived-At: 
Subject: Re: [Txauth] Support of FIDO and data minimization by RSs
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, 06 Jul 2020 16:22:09 -0000

--000000000000754e7405a9c846e6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis

Would you provide some background on what you are trying to solve with
this? I'm guessing it is privacy related.

Perhaps a use case would help make it more concrete?

/Dick


On Mon, Jul 6, 2020 at 5:39 AM Denis  wrote:

> This is a new thread: a proposal for a RS authorization algorithm and a
> way to support FIDO by RSs
>
> In order to support the privacy principle of "data minimization" by RSs,
> only the attributes that are strictly necessary to perform
> an operation requested by a client should be requested by the RS.
>
> When a client wants to authenticate, it will usually be informed by the R=
S
> on how to do it (see more details about two exceptions at the end of this
> email).
> Which conditions are needed to perform other operations will only be
> disclosed to authenticated users at the time they are willing to perform =
an
> operation.
>
> Two categories of operations will be considered: authentication operation=
s
> and other operations.
>
> For the "authentication" operation, two cases will be supported:
>
> -          FIDO U2F or
>
> -          one or more attributes from one or more ASs.
>
> In the second case, 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 *a Condition *:
>
> *Condition x* =3D { AS identifier + set of attributes types + optional
> scope identifier }
>
> The presence of the *optional* scope identifier allows to provide a
> backward compatibility with ASs from the OAuth 2.0. world:
> the optional scope identifier is only present when a bilateral
> relationship has been established between a RS and an AS prior
> to any access (*and will continue to be maintained*) using "out-of-bands"
> means.
>
> 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.
>
> An example is used to explain the concepts.
>
> "Operation(s)/ Mathematical expression" pairs managed by the RO of a RS.
>
> *Operation*
>
> *Mathematical expression*
>
> Authentication
>
> *Condition 1* OR *Condition 2*
>
> Operation A OR Operation Z
>
> *Condition 3* AND *Condition 4*
>
> Conditions table:
>
> Condition 1
>
> FIDO U2F 1.2
>
> -
>
> -
>
> Condition 2
>
> AS 1
>
> set 1 of attributes types
>
>
>
> Condition 3
>
> AS 4
>
> set 2 of attributes types
>
> scope identifier : 21
>
> Condition 4
>
> AS 9
>
> set 3 of attributes types
>
> -
>
> 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 th=
e
> set of attributes types which are indicated for a given AS
> are appropriate to him or not and then select that AS if it has a
> relationship with it.
>
> In this example, one mathematical expression for the combination of
> conditions using AND and OR operators is "*Condition 3* OR *Condition 4",=
*
> * which means that* some types of attributes from AS 4 AND some other
> types of attributes from AS 9 are both needed by RSx to perform on RSx
> either the Operation A or the Operation Z.
>
> In this example, RS 1 and AS 4 have established a bilateral relationship
> (and have agreed to define and use scope identifiers)
> whereas RS 1 and AS 9 have not established any bilateral relationship
> prior to the exchange.
>
> The user makes up his mind whether the attributes requested by AS 1 and A=
S
> 9 are reasonable and if so, requests two access tokens:
> one to AS 4 and another one to AS 9.
>
> For AS 4, the client shall use the scope identifier with the value 21.
> For AS 9, the client shall use the set 3 of attributes types indicated in
> the Condition 4.
>
> In order to save one exchange, a RS could publicly publish how its client=
s
> can authenticate.
> However,  it is also possible to consider no guidance at all: in such a
> case, using "out-of-bands" means, the clients should know how to
> authenticate.
>
> Denis
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000754e7405a9c846e6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis

Would you provide some backgro=
und on what you are trying to solve with this? I'm guessing it is priva=
cy related.=C2=A0

Perhaps a use case would help ma=
ke it more concrete?

/Dick


On =
Mon, Jul 6, 2020 at 5:39 AM Denis <denis.ietf@free.fr> wrote:

 =20

   =20
 =20
  

    
 This is a new thread: a proposal for a RS
        authorization algorithm and a way to support FIDO by RSs

      

    
In order to support the privacy principle of
        "data
        minimization" by RSs, only the attributes that are strictly
        necessary to
        perform 

        an operation requested by a client should be requested by the
        RS.

    
When a client wants to authenticate, it will
        usually be informed by the
        RS on how to do it (see more details about two exceptions at the
        end of this email).
        

        Which conditions are needed to perform other operations will
        only be disclosed
        to authenticated users at the time they are willing to perform
        an operation.

    
Two categories of operations will be
        considered: authentication
        operations and other operations.

      

    
 For the "authentication" operation,
        two cases will be supported: 

    
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
        FIDO=
 U2F or
      

    
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
        one =
or more attributes from one or more ASs.
      

    
In the second case, 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
          C=
ondition
            2

            Condition 1 OR Condition 2

        (=
Condition
            1 A=
ND
          C=
ondition
            2) =
OR
          C=
ondition
            3

            (Condition 1 OR Condition 2)
          AND
          C=
ondition
            3 =


        

    

    
The following notation is being used for a
          Condition :

    
Condition
          x =3D=
 { AS identifier
        + set of attributes types + optional scope identifier } 

      

    
The presence of the optional scope
        identifier allows to provide
        a backward compatibility with ASs from the OAuth 2.0. world: 

        the optional scope
        identifier is only present when a bilateral relationship has
        been established
        between a RS and an AS prior 

        to any access (and will continue to be maintained)
        using "out-of-bands" means. 

      

    
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.

    
An example is used to explain the concepts.

    
"Operation(s)/ Mathematical expression"
        pairs
        managed by the RO of a RS. 

      

    

      
        

          
            
Operation

          		
          
            
Mathematical expression

          		
        

        

          
            
Authentication

          		
          
            
Condition 1 OR<=
span style=3D"font-family:Arial;color:black" lang=3D"EN-US"> =
Condition =
2

          		
        

        

          
            
Operation A OR Operation
                Z

          		
          
            
Condition 3 AND=
 Condition=
 4

          		
        

      
    

    
Conditions
        table: 

    

      
        

          
            
Condition 1

          		
          
            
FIDO
                U2F 1.2

          		
          
            
-

          		
          
            
-

          		
        

        

          
            
Condition 2

          		
          
            
AS 1

          		
          
            
set 1 of attributes types

          		
          
            
=C2=A0

          		
        

        

          
            
Condition 3

          		
          
            
AS 4

          		
          
            
set 2 of attributes types

          		
          
            
scope identifier : 21

          		
        

        

          
            
Condition 4

          		
          
            
AS 9

          		
          
            
set 3 of attributes types

          		
          
            
-

          		
        

      
    

    
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
        the set of attributes types wh=
ich are indicated
        for a given AS 

        are
        appropriate to him or not and then select that AS if it has a
        relationship with it.

    
In this example, one mathematical expression
        for the combination of
        conditions using AND and OR operators is "Condition
            3 <=
span>OR Condition 4&quo=
t;, 

            which means that some types of
        attributes from AS 4 AND some
        other types of
        attributes from AS 9 are both needed by RSx to perform on RSx 

        either the Operation A or the Operation Z. 

    
In this example, RS 1 and AS 4 have
        established a bilateral relationship
        (and have agreed to define and use scope identifiers) 

        whereas RS 1 and AS 9 have not
        established any bilateral relationship prior to the exchange. 

      

    
The user makes up his mind whether the
        attributes requested by AS 1 and
        AS 9 are reasonable and if so, requests two access tokens: 

        one to AS 4 and
        another one to AS 9.

    
For AS 4, the clie=
nt shall use the
        scope identifier with the value 21.

        For AS 9, the client shall use the set 3 of attributes types
        indicated in
        the Condition 4.

    
In order to save one exchange, a RS could
        publicly publish how its
        clients can authenticate. 

        However,=C2=A0 it is
        also possible to consider no guidance at all: in such a case,
        using
        "out-of-bands" means, the clients should know how to
        authenticate.

    
Denis 

      

    

  


-- 

Txauth mailing list

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




--000000000000754e7405a9c846e6--


From nobody Mon Jul  6 09:26: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 DC06C3A16AE; Mon,  6 Jul 2020 09:26: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 L8_U5I_dy98j; Mon,  6 Jul 2020 09:26:07 -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 A0D833A1618; Mon,  6 Jul 2020 09:26:06 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id 9so46097620ljv.5; Mon, 06 Jul 2020 09:26: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=jdr5J2q07kzZduUMegqQJpQhhcgTc4QqiLYY4pK2q5k=; b=AGtLiSGdokRcnImM2wB0Qu1CH67ObavSa3OLhxDWZ+9yPShp0e/s3sir5xb13TAIBL fQY2d7gwyfYG+Wwq6nCrwaTtafCkI8gkbRg8rzgzxS/iU0Io/9r+YEi/dwz97EoElr1A J1hr1+EStYiVYpOEVxf2sGo8M5DIdsoQv8LOZ+VMg8BXNAxn016xInyC4Yxrx+cDEeC6 Ogy3oTjAbgwfh/bLNcPG3shvHsDgyvwuPl0LguTLdfbW1/LAvGJlF70DBtPoapNGPBvu Vs1e37Xeg8G+UzMwWUXebDIA1xwmHYNEeBQh5xeNQI+RADimG5fIbHr2jGQpDBfV6/ig 6hDw==
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=jdr5J2q07kzZduUMegqQJpQhhcgTc4QqiLYY4pK2q5k=; b=LkozWS2PjD2yKxesbBB7zSNNXpfIK499bGkjpL3sepNZQoiEx5wDp+3IScG90YrYtv n8T02UGeUoqKfbDJNrQ53/UxhyDbc4LakttV98LeMmDUMIYYTfsns7FIXTn69+VfcFxj aKjmQTaU+4kqe8SUvc+ZgthYMI9JrPDhgBc1pmih3rpF1ARjuHKajbs8Loau8haTdDFy ly3tzp2ffy0kbVwEe1IXcFhb1iuVPJS0jm99DGdU+mW0jOzj2RkRvv0iEuAmiQ52Jy1J J3TUJpIiFd3iYI44JUDQ8Wa5cs2jZUWLYmFEL02jg49d7LQFUUiH8yPZ76Q6e3dro5Lp f/Jg==
X-Gm-Message-State: AOAM532ILc95C/y4WaQWyvRx4u83xfh92WAUEa3dRszHEPssHC4ct9+N Y+oOWWTj20klXeFYyLd790bVBoMwYm7JUUtcH10=
X-Google-Smtp-Source: ABdhPJy1h7ikCfRbncuqhvB4L4qY2MqCy7puKcVcBpbncUSSqAfCxwVPKkJnDDG3oVZQ8oBtDSbgN4lmJjtj2S1oQH8=
X-Received: by 2002:a05:651c:547:: with SMTP id q7mr26177291ljp.437.1594052764659;  Mon, 06 Jul 2020 09:26:04 -0700 (PDT)
MIME-Version: 1.0
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com>     <3c21e0fa-5636-54fe-675f-abc5b41ab09e@free.fr>  <731a364a19a74e1d982d59d9c441dc0a@cert.org> 
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 6 Jul 2020 09:25:28 -0700
Message-ID: 
To: Denis 
Cc: Roman Danyliw , Nat Sakimura ,  "txauth@ietf.org" , The IESG 
Content-Type: multipart/alternative; boundary="000000000000ca71c105a9c854ef"
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 06 Jul 2020 16:26:10 -0000

--000000000000ca71c105a9c854ef
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis

Just like "privacy", "security" is not called out as a goal. (it is
mentioned as an issue with OAuth 2.0).



On Mon, Jul 6, 2020 at 8:49 AM Denis  wrote:

> One single comment.
>
> Dick wrote on the last line:
>
> I think pretty much everyone is onboard supporting privacy, but not all
> use cases have the same privacy considerations.
>
> I hope that this is true, but in such a case I can't understand why the
> word "*privacy*" is missing in the charter.
>
> Denis
>
> Note: IESG added
>
> Hello!
>
>
>
> I=E2=80=99m top-posting here because there is no easy way for me to clean=
ing
> insert my process comment.  I think we are having a necessary conversatio=
n
> below and in no way should it stop because of this note.
>
>
>
> As a process check, this thread started with a request for community
> review on the charter text [1].  Among other things, this charter review =
is
> trying to ensure the problem is clear, defines the bounds of the desired
> solutions and identifies critical objections from the consensus-derived
> text.  The text is not intended to define detailed
> requirements/architecture, resolve tradeoffs, or to specify a solution,
> unless they are critical to bounding the solution.  These details should =
be
> left to future discussions of a chartered WG (not that they can=E2=80=99t=
 start now
> in parallel).  Additionally, as a reminder, while there are multiple
> individual drafts with proposed solutions in the datatracker, the design
> decisions they make are not part of the charter and their adoption is not
> assumed by the charter.  If there are key design elements in those or any
> other documents that is felt to be crucial to scoping the WG,  we need to
> capture the thinking, generalize it (as appropriate), and add it to the
> charter text explicitly or by reference.
>
>
>
> Let=E2=80=99s continue to talk about the technical details of the use cas=
es,
> design properties, constraints and candidate solutions.  Additionally,
> given the -05 charter text and milestones [2], it would be helpful to
> understand what outstanding concerns remain with the charter text in
> preparation for the Thursday, July 9th telechat where the IESG will use
> community feedback to help decide the way ahead for this proposed WG.
>
>
>
> Roman
>
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/txauth/4nE8rtyRPtdk0FrclQ1c-FWMO8w/
>
> [2] https://datatracker.ietf.org/doc/charter-ietf-gnap/
>
>
>
>
>
>
>
> *From:* Txauth   *On
> Behalf Of *Dick Hardt
> *Sent:* Friday, July 3, 2020 9:41 PM
> *To:* Denis  
> *Cc:* Nat Sakimura  ;
> txauth@ietf.org
> *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization
> Protocol (gnap)
>
>
>
> + Nat as he is mentioned
>
> - IESG
>
>
>
> On Fri, Jul 3, 2020 at 2:16 AM Denis  wrote:
>
> Hello Dick,
>
>
>
> Catching up on this email ... comments inserted ...
>
>
>
> On Mon, Jun 29, 2020 at 12:06 AM Denis  wrote:
>
> Hello Dick,
>
>
>
> Denis, thanks for sharing your thoughts, some clarifications on your
> statements inserted:
>
>
>
> On Fri, Jun 26, 2020 at 9:42 AM Denis  wrote:
>
> 
>
> *New proposed charter*
>
> 
>
>
> Resource servers inform their clients about which access token formats ar=
e
> acceptable and depending upon the king of operation
> that is requested, which kind of attributes are needed and from which ASs
> that my be obtained.
>
> While at times this may be appropriate, at other times disclosing the
> attributes the RS requires is not needed by the client.
> For example, an enterprise client accessing a resource does not need to
> know which groups a user belongs to,
> but the RS may require that to determine if the user running the client
> has access.
>
> As soon as there is a desire to implement privacy by default, the client
> should not provide more attributes than strictly necessary.
> Even after three readings of your example, I failed to understand it.
>
>
> A major difference with OAuth 2.0 is that there is no bilateral trust
> relationship between an authorization server and a resource server:
> for a given category of attributes, a resource server may trust one or
> more authorization servers. Another major difference with OAuth 2.0.
> is that the content of an attributes token is meant to be accessible to
> the client.
>
> This is not how OAuth 2.0 works. See slides 7 and 8 from my original IETF
> presentation on what became OAuth 2.0
>
>
>
> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation
>
> I looked at the two slides.
>
> Unfortunately slide 7 has just one arrow with the word "trust". This is
> insufficient to understand what is meant unless being present
> at the presentation. Does it mean that the PR (RS) trusts one AS or that
> it may trust multiple ASs ?
>
> Unfortunately slide 8 has just one arrow between the PR and the AS which
> is red-crossed but no text at all. This is insufficient to understand
> what is meant unless being present at the presentation. Does it mean that
> the PR and the AS never communicate directly ?
> Does it mean that they have no relationships at all, besides the one way
> trust relationship mentioned in slide 7 ?
>
> So it hard to say whether these two slides are indeed meaning that there
> is no bilateral relationship between an authorization server and a resour=
ce
> server.
>
> Apologies for not providing an explanation on the slides.
>
>
>
> Slide 7 shows that trust between the AS and PR (now RS) was
> unidirectional, from the RS to the AS.
>
> Slide 8 indicates that trust is not bidirectional.
>
> [Denis]  ... which means that slide 8 contradicts slide 7.  :-)
>
>
>
> Slide 8 says it does not go both ways. Slide 7 says it goes one way. I
> don't see the contradiction.
>
> I would have preferred that you meant: the RS and the AS never communicat=
e
> directly, which is indeed a nice property to follow
> to ensure the user's privacy.
>
> That is one model. Other models are appropriate in other circumstances..
>
>
>
>
>
> There is no limit on how many ASs an RS may trust.
>
> [Denis] This is fine.
>
>  On June 12, Nat Sakimura recently answered to an email with the
> following topic:
>
> Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
> Authorization Framework: JWT Secured Authorization Request))
>
> My arguments were:
>
>      The original model for OAuth was making the assumption that the AS
> and the RS had a strong bilateral relationship.
>
>       *A key question is whether such strong relationship will be
> maintained for ever *or
>      whether it will be allowed to perform some evolutions of this
> relationship.
>
>      In order to respect the privacy of the users, there is the need to
> encompass other scenarios. One of these scenarios is that the AS and the =
RS
>      do not need any longer to have such a strong relationship. In terms
> of trust relationships, a RS simply needs to trust the access tokens issu=
ed
> by an AS.
>      The AS does have any more a "need to know" of all the RSs that are
> accepting its access tokens. This would be a major simplification of the
> current global architecture.
>
> Nat's position was:
>
> "My take is that the basic assumption of OAuth 2.0 Framework is that ther=
e
> is a strong relationship between AS and RS.
> I feel that it is quite unrealistic that an RS would trust the access
> token issued by an AS that it has no strong relationship with".
>
> There are indeed different positions on this topic.
>
>
>
> I don't think Nat and I have different opinions, but I will let Nat
> clarify.
>
> Just because there is a strong relationship between the AS and RS, does
> not mean it is bidirectional. I would understand
>
>
>
> "I feel that it is quite unrealistic that an RS would trust the access
> token issued by an AS that it has no strong relationship with"
>
>
>
> to indicate Nat is expecting the trust to be from the RS to the AS.
>
> [Denis]  Speaking of a "strong relationship" is ambiguous. The key point
> being whether the relationship is unilateral or bilateral.
> There is no need to use the wording "strong relationship" when the
> relationship is only unilateral: a RS simply trusts an AS for the access
> tokens it issues.
> In such a case, this does not mean that an AS is knowing all the RSs that
> are trusting it.
>
> On the contrary, a strong (bi-)relationship is when a RS and an AS both
> agree between them about the meaning of scope parameters.
> This is a typical case for OAuth 2.0.
>
> You can ask Nat what he meant by "strong relationship"
>
>
>
> The AS is stating what a scope means to it and the user.. The RS can do
> whatever it wants. I don't see that as requiring a bidirectional
> relationship.
>
>
>
>
>
>
>
>
>
>
>
> The AS may not even know who the RS (or PR in the slides) is.
>
>
>
> 
>
>
> I got rid of the word "delegation": the client does not delegate anything
> to an authorization server. If it would, this would mean that the
> authorization server
> would be able to act as the client and could know everything that the
> client will do, which comes into contradiction with the user's privacy.
>
>
>
> The above is not true.
>
>
>
> The Resource Owner is delegating access control to the AS in authorizatio=
n
> use cases.
>
> The OAuth 2.0 model does not mandate any more the presence of a Resource
> Owner.
>
>
>
> Why do you say that? The RO is who owns the RS. Your statement does not
> make sense.
>
> [Denis]  I mean that there is not necessarily a protocol defined so that
> the RO can interact with the requests from the clients.
>
> Is the RO the User? In consumer use cases it usually is, and the RO is
> using the client. I'm not sure what you scenario you are describing
>
>
>
>
>
>
>
>
>
> The client is may be delegating user authentication to the AS in identity
> claim use cases.
>
> Delegating user authentication to the AS is different from delegating
> access control to the AS.
>
>
>
> Agreed. Your statement was there was no delegation. I'm explaining there
> are potentially two delegations.
>
>
>
> The AS can act as the client in many OAuth deployments, as the access
> token is a bearer token.
>
> A bearer token is rather insecure.
>
> Cookies are also bearer tokens. But we use them all the time in web apps
> for storing session state and prior authentication! :)
>
>
>
>
>
> That does not mean the AS knows what the client is doing.
>
> There are currently two attempts in the OAuth WG to let know to the AS
> what the client is doing:
>
>    - draft-ietf-oauth-jwsreq-22   (The OAuth 2.0 Authorization Framework:
>    JWT Secured Authorization Request)
>    - draft-ietf-oauth-rar-01         (OAuth 2.0 Rich Authorization
>    Requests)
>
> Those are optional, and in some situations are a desired property.
>
> [Denis]  However, in these two drafts, the privacy considerations section=
s
> are silent on this point.
>
> There are lots of missing details in both drafts! Security considerations=
,
> error messages etc.
>
>
>
> I think pretty much everyone is onboard supporting privacy, but not all
> use cases have the same privacy considerations.
>
>
>
> /Dick
>
>
>

--000000000000ca71c105a9c854ef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis

Just like=C2=A0"privacy&q=
uot;, "security" is not called out as a goal. (it is mentioned as=
 an issue with OAuth 2.0).



On Mon, Jul 6=
, 2020 at 8:49 AM Denis <denis.iet=
f@free.fr> wrote:

 =20
   =20
 =20
  

    
One single comment.

    


    

    
Dick wrote on the last line:

    

      
I think pretty much everyone is
        onboard supporting privacy, but not all use cases have the same
        privacy considerations.

    

    
I hope that this is true, but in such a
      case I can't understand why the word "privacy" i=
s missing
      in the charter.

    


    

    
Denis

    


    

    
Note: IESG added

    


    

    

     =20
     =20
     =20
      

        
Hello!

        
=C2=A0

        
I=E2=80=99m top-posting here because there i=
s no
          easy way for me to cleaning insert my process comment.=C2=A0 I
          think we are having a necessary conversation below and in no
          way should it stop because of this note.

        
=C2=A0

        
As a process check, this thread started
          with a request for community review on the charter text [1].=C2=
=A0
          Among other things, this charter review is trying to ensure
          the problem is clear, defines the bounds of the desired
          solutions and identifies critical objections from the
          consensus-derived text.=C2=A0 The text is not intended to define
          detailed requirements/architecture, resolve tradeoffs, or to
          specify a solution, unless they are critical to bounding the
          solution.=C2=A0 These details should be left to future discussion=
s
          of a chartered WG (not that they can=E2=80=99t start now in
          parallel).=C2=A0 Additionally, as a reminder, while there are
          multiple individual drafts with proposed solutions in the
          datatracker, the design decisions they make are not part of
          the charter and their adoption is not assumed by the charter.=C2=
=A0
          If there are key design elements in those or any other
          documents that is felt to be crucial to scoping the WG, =C2=A0we
          need to capture the thinking, generalize it (as appropriate),
          and add it to the charter text explicitly or by reference.=


        
=C2=A0

        
Let=E2=80=99s continue to talk about the tec=
hnical
          details of the use cases, design properties, constraints and
          candidate solutions.=C2=A0 Additionally, given the -05 charter te=
xt
          and milestones [2], it would be helpful to understand what
          outstanding concerns remain with the charter text in
          preparation for the Thursday, July 9th telechat
          where the IESG will use community feedback to help decide the
          way ahead for this proposed WG.

        
=C2=A0

        
Roman

        
=C2=A0

        
[1] 
https://mailarchive.ietf.org/arch/msg/txauth/4nE8rtyRPtdk0FrclQ1c-FWMO8w/

        
[2] 
            https://datatracker.ietf.org/doc/charter-ietf-gnap/<=
u>

        
=C2=A0

        
=C2=A0

        
=C2=A0

        

          

            

              
From: Txauth
                <txauth-bounces@ietf.org> On Behalf Of
                Dick Hardt

                Sent: Friday, July 3, 2020 9:41 PM

                To: Denis <denis.ietf@free.fr>

                Cc: Nat Sakimura <sakimura@gmail.com>;
                txauth=
@ietf.org

                Subject: Re: [Txauth] WG Review: Grant
                Negotiation and Authorization Protocol (gnap)=


            

          

          
=C2=A0

          

            

              
+ Nat as he is mentioned=


            

            

              
- IESG

            

            
=C2=A0

            

              

                
On Fri, Jul 3, 2020 at 2:16 AM
                  Denis <denis.ietf@free.fr>
                  wrote:

              

              

                

                  

                    
Hello Dick,

                  

                  

                    
=C2=A0

                  

                  

                    

                      

                        

                          

                            

                              
Catching up on this
                                email ... comments inserted ...

                            

                            
=C2=A0

                            

                              

                                
On Mon, Jun 29,
                                  2020 at 12:06 AM Denis <denis.ietf@free.fr>
                                  wrote:

                              

                              

                                

                                  

                                    
Hello
                                        Dick,

                                  

                                  

                                    
=C2=A0=


                                  

                                  

                                    

                                      

                                        
Denis,
                                            thanks for sharing your
                                            thoughts, some
                                            clarifications on your
                                            statements inserted:<=
/u>

                                      

                                      
=C2=A0<=
u>

                                      

                                        

                                          
On
                                              Fri, Jun 26, 2020 at 9:42
                                              AM Denis <denis.ietf@free.fr>
                                              wrote:
                                        

                                        

                                          
<snip>

                                        

                                        

                                          

                                            

                                              

                                                
New
                                                      proposed charter

                                              

                                            

                                          

                                        

                                        

                                          
<snip>=C2=A0<=
/p>
                                        

                                        

                                          

                                            

                                              

                                                


                                                    Resource servers
                                                    inform their clients
                                                    about which access
                                                    token formats are
                                                    acceptable and
                                                    depending upon the
                                                    king of operation

                                                    that is requested,
                                                    which kind of
                                                    attributes are
                                                    needed and from
                                                    which ASs that my be
                                                    obtained.=


                                              

                                            

                                          

                                        

                                        

                                          
While
                                              at times this may be
                                              appropriate, at other
                                              times disclosing the
                                              attributes the RS requires
                                              is not needed by the
                                              client.
                                              

                                              For example, an enterprise
                                              client accessing a
                                              resource does not need to
                                              know which groups a user
                                              belongs to,
                                              

                                              but the RS may require
                                              that to determine if the
                                              user running the client
                                              has access.<=
/u>

                                        

                                      

                                    

                                  

                                  
As
                                      soon as there is a desire to
                                      implement privacy by default, the
                                      client should not provide more
                                      attributes than strictly
                                      necessary.
                                      

                                      Even after three readings of your
                                      example, I failed to understand
                                      it.

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                


                                                    A major difference
                                                    with OAuth 2.0 is
                                                    that there is no
                                                    bilateral trust
                                                    relationship between
                                                    an authorization
                                                    server and a
                                                    resource server:
                                                    

                                                    for a given category
                                                    of attributes, a
                                                    resource server may
                                                    trust one or more
                                                    authorization
                                                    servers. Another
                                                    major difference
                                                    with OAuth 2.0.

                                                    is that the content
                                                    of an attributes
                                                    token is meant to be
                                                    accessible to the
                                                    client.

                                              

                                            

                                          

                                        

                                        

                                          
This
                                              is not how OAuth 2.0
                                              works. See slides 7 and 8
                                              from my original IETF
                                              presentation on what
                                              became OAuth 2.0

                                        

                                        

                                          
=C2=
=A0

                                        

                                        
                                      

                                    

                                  

                                  
I
                                      looked at the two slides. 
                                    

                                  
Unfortunately
                                      slide 7 has just one arrow with
                                      the word "trust". This is
                                      insufficient to understand what is
                                      meant unless being present
                                      

                                      at the presentation. Does it mean
                                      that the PR (RS) trusts one AS or
                                      that it may trust multiple ASs ?

                                

                              

                              

                                

                                  
Unfortunately
                                      slide 8 has just one arrow between
                                      the PR and the AS which is
                                      red-crossed but no text at all.
                                      This is insufficient to understand
                                      what is meant unless being present
                                      at the presentation. Does it mean
                                      that the PR and the AS never
                                      communicate directly ?

                                      Does it mean that they have no
                                      relationships at all, besides the
                                      one way trust relationship
                                      mentioned in slide 7 ?<=
u>

                                  
So
                                      it hard to say whether these two
                                      slides are indeed meaning that
                                      there is no bilateral relationship
                                      between an authorization server
                                      and a resource server.<=
u>

                                

                              

                              

                                

                                  
Apologies for not
                                    providing an explanation on the
                                    slides.

                                

                                

                                  
=C2=A0

                                

                                

                                  
Slide 7 shows
                                    that trust between the AS and PR
                                    (now RS) was unidirectional, from
                                    the RS to the AS.

                                

                                

                                  
Slide 8
                                    indicates=C2=A0that trust is not
                                    bidirectional.

                                

                              

                            

                          

                        

                      

                    

                  

                  
[Denis]=
=C2=A0
                      ... which means that slide 8 contradicts slide 7.=C2=
=A0
                      :-)
                    

                

              

              

                
=C2=A0

              

              

                
Slide 8 says it does not go both
                  ways. Slide 7 says it goes one way. I don't see the
                  contradiction.=C2=A0

              

              

                

                  
I
                      would have preferred that you meant: the RS and
                      the AS never communicate directly, which is indeed
                      a nice property to follow
                      

                      to ensure the user's privacy.

                

              

              

                
That is one model. Other models are
                  appropriate in other circumstances..

              

              

                
=C2=A0

              

              

                

                  
=C2=A0

                  

                    

                      

                        

                          

                            

                              

                                

                                  
There is no limit
                                    on how many ASs an RS may trust.=


                                

                              

                            

                          

                        

                      

                    

                  

                  
[Denis]
                      This is fine.

                  

                    

                      

                        

                          

                            

                              

                                
=C2=A0On
                                    June 12, Nat Sakimura recently
                                    answered to an email with the
                                    following topic:
                              

                              

                                

                                  

                                    
Re: [OAUTH-WG] Comments
                                        on draft-ietf-oauth-jwsreq-22
                                        (The OAuth 2.0 Authorization
                                        Framework: JWT Secured
                                        Authorization Request))

                                  

                                  
My arguments were:

                                  
=C2=A0=C2=A0=C2=A0=C2=A0 The original model
                                      for OAuth was making the
                                      assumption that the AS and the RS
                                      had a strong bilateral
                                      relationship.

                                    

                                    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A
                                        key question is whether such
                                        strong relationship will be
                                        maintained for ever
                                      or
                                    

                                    =C2=A0=C2=A0=C2=A0=C2=A0
                                      whether it will be allowed to
                                      perform some evolutions of this
                                      relationship.

                                    

                                    =C2=A0=C2=A0=C2=A0=C2=A0
                                      In order to respect the privacy of
                                      the users, there is the need to
                                      encompass other scenarios. One of
                                      these scenarios is that the AS and
                                      the RS
                                    

                                    =C2=A0=C2=A0=C2=A0=C2=A0
                                      do not need any longer to have
                                      such a strong relationship. In
                                      terms of trust relationships, a RS
                                      simply needs to trust the access
                                      tokens issued by an AS.
                                    

                                    =C2=A0=C2=A0=C2=A0=C2=A0
                                      The AS does have any more a "nee=
d
                                      to know" of all the RSs that are
                                      accepting its access tokens. This
                                      would be a major simplification of
                                      the current global architecture.

                                  
Nat's position was:
                                    

                                  

                                    
"My take is that the
                                        basic assumption of OAuth 2.0
                                        Framework is that there is a
                                        strong relationship between AS
                                        and RS.
                                        

                                        I feel that it is quite
                                        unrealistic that an RS would
                                        trust the access token issued by
                                        an AS that it has no strong
                                        relationship with".<=
/u>

                                  

                                  
There are indeed
                                      different positions on this
                                      topic.=C2=A0
                                    

                                

                              

                              

                                
=C2=A0=


                              

                              

                                
I don't think Na=
t
                                  and I have different opinions, but I
                                  will let Nat clarify.

                              

                              

                                
Just because there
                                  is a strong relationship between the
                                  AS and RS, does not mean it is
                                  bidirectional. I would understand=C2=A0

                              

                              

                                
=C2=A0=


                              

                              

                                
"I feel that it=
 is
                                  quite unrealistic that an RS would
                                  trust the access token issued by an AS
                                  that it has no strong relationship
                                  with"

                              

                              

                                
=C2=A0=


                              

                              

                                
to indicate Nat is
                                  expecting the trust to be from the RS
                                  to the AS.

                              

                            

                          

                        

                      

                    

                  

                  
[Denis]=
=C2=A0
                      Speaking of a "strong relationship" is ambi=
guous.
                      The key point being whether the relationship is
                      unilateral or bilateral.

                      There is no need to use the wording "strong
                      relationship" when the relationship is only
                      unilateral: a RS simply trusts an AS for the
                      access tokens it issues.
                      

                      In such a case, this does not mean that an AS is
                      knowing all the RSs that are trusting it.

                  
On
                      the contrary, a strong (bi-)relationship is when a
                      RS and an AS both agree between them about the
                      meaning of scope parameters.

                      This is a typical case for OAuth 2.0.

                

              

              

                
You can ask Nat what he meant by
                  "strong relationship"

              

              

                
=C2=A0

              

              

                
The AS is stating what a scope
                  means to it and the user.. The RS can do whatever it
                  wants. I don't see that as requiring a bidirectional
                  relationship.

              

              

                
=C2=A0

              

              

                
=C2=A0

              

              

                
=C2=A0

              

              

                

                  
=C2=A0

                  

                    

                      

                        

                          

                            

                              
=C2=A0
                              

                                

                                  

                                    

                                      

                                        

                                          
The
                                              AS may not even know who
                                              the RS (or PR in the
                                              slides) is.<=
/u>

                                        

                                        

                                          
=C2=
=A0

                                        

                                        

                                          
<snip>=C2=A0<=
/p>
                                        

                                        

                                          

                                            

                                              


                                                  I got rid of the word
                                                  "delegation": t=
he
                                                  client does not
                                                  delegate anything to
                                                  an authorization
                                                  server. If it would,
                                                  this would mean that
                                                  the authorization
                                                  server
                                                  

                                                  would be able to act
                                                  as the client and
                                                  could know everything
                                                  that the client will
                                                  do, which comes into
                                                  contradiction with the
                                                  user's privacy.

                                            

                                          

                                        

                                        

                                          
=C2=
=A0

                                        

                                        

                                          
The=C2=A0above
                                              is not true.=


                                        

                                        

                                          
=C2=A0

                                        

                                        

                                          
The
                                              Resource Owner is
                                              delegating access control
                                              to the AS in authorization
                                              use cases.

                                        

                                      

                                    

                                  

                                  
The
                                      OAuth 2.0 model does not mandate
                                      any more the presence of a
                                      Resource Owner.<=
/p>
                                

                              

                              

                                
=C2=A0=


                              

                              

                                
Why do you say
                                  that? The RO is who owns the RS. Your
                                  statement does not make sense.<=
/u>

                              

                            

                          

                        

                      

                    

                  

                  
[Denis]=
=C2=A0
                      I mean that there is not necessarily a protocol
                      defined so that the RO can interact with the
                      requests from the clients.

                

              

              

                
Is the RO the User? In consumer use
                  cases it usually is, and the RO is using the client.
                  I'm not sure what you scenario you are describing<=
/u>

              

              

                
=C2=A0

              

              

                

                  
=C2=A0

                  

                    

                      

                        

                          

                            

                              

                                
=C2=A0=


                              

                              

                                

                                  

                                    

                                      

                                        

                                          
=C2=
=A0

                                        

                                        

                                          
The
                                              client is may be
                                              delegating user
                                              authentication to the AS
                                              in identity claim use
                                              cases.
                                        

                                      

                                    

                                  

                                  
Delegating
                                      user authentication to the AS is
                                      different from delegating access
                                      control to the AS.

                                

                              

                              

                                
=C2=A0=


                              

                              

                                
Agreed. Your
                                  statement was there was no delegation.
                                  I'm explaining there are
                                  potentially=C2=A0two delegations.=C2=A0

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
=C2=
=A0

                                        

                                        

                                          
The
                                              AS can act as the client
                                              in many OAuth deployments,
                                              as the access token is a
                                              bearer token.
                                            

                                        

                                      

                                    

                                  

                                  
A
                                      bearer token is rather insecure.

                                

                              

                              

                                
Cookies are also
                                  bearer tokens. But we use them all the
                                  time in web=C2=A0apps for=C2=A0storing se=
ssion
                                  state=C2=A0and prior authentication! :)

                              

                              

                                
=C2=A0=


                              

                              

                                
=C2=A0=


                              

                              

                                

                                  

                                    

                                      

                                        

                                          
That
                                              does not mean the AS knows
                                              what the client is doing.
                                            

                                        

                                      

                                    

                                  

                                  
There
                                      are currently two attempts in the
                                      OAuth WG to let know to the AS
                                      what the client is doing:

                                  
    
                                    
  • 
                                      draft-ietf-oauth-jwsreq-22=C2=A0=C2=A0
                                        (The OAuth 2.0 Authorization
                                        Framework: JWT Secured
                                        Authorization Request)
    • 
                                    
  • 
                                      draft-ietf-oauth-rar-01
                                        =C2=A0 =C2=A0 =C2=A0 =C2=A0 (OAuth =
2.0 Rich
                                        Authorization Requests)
    • 
                                  

                                

                              

                              

                                
Those are optional,
                                  and in some situations are a desired
                                  property.

                              

                            

                          

                        

                      

                    

                  

                  
[Denis]=
=C2=A0
                      However, in these two drafts, the privacy
                      considerations sections are silent on this point.

                

              

              

                
There are lots of missing details
                  in both drafts! Security considerations, error
                  messages etc.

              

              

                
=C2=A0

              

              

                
I think pretty much everyone is
                  onboard supporting privacy, but not all use cases have
                  the same privacy considerations.

              

              

                
=C2=A0

              

              

                
/Dick

              

            

          

        

      

    

    


    

  





--000000000000ca71c105a9c854ef--


From nobody Mon Jul  6 09:26: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 9B41F3A16CE; Mon,  6 Jul 2020 09:26:22 -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_FILL_THIS_FORM_SHORT=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 Oy_bLmyfoQ69; Mon,  6 Jul 2020 09:26:19 -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 DB77F3A16C1; Mon,  6 Jul 2020 09:26:18 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id 9so46098566ljv.5; Mon, 06 Jul 2020 09:26: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=iOcRBA3CcD/B9Jju9GHisQZGgufIWcNJM8MUVh5EXSA=; b=jjJKSV0wGjyftmqgzB9jpGJg40QWqxt2KGGtgaFxbMjgl8NBfWWqgAGUIE42inywIl g8MJQzWJrta74Hx8lpZ6R7vRpot2dcxWiSzCLT0GmcGBC2q5iKJ5HwMA0HUbnoKBWnFy fgpWtP5p7jHAt1t7pFxpc7FnFInZdMqTbZTTgAB7RbJPCb7ZGoU3Rs9NF11nI6rGcvXt /rkSYkA/aMRI61tlllU3NnLfSzfjKH60wIpCOZ3UkOEoqShGG0dkKLeqV6G7tOAxqTME /uOvXVNbD7lHqG5SUceKzQ7vL+oS7Ud1MkFdNLYaksXCj0Bme1Zv9UyCVW7RnPgPBz6V teVA==
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=iOcRBA3CcD/B9Jju9GHisQZGgufIWcNJM8MUVh5EXSA=; b=adOwOsfmJpbeKrzfCsFtLLXGJjWFydObXjCx9PuY83fbqnSfDVA1mNyxXvTbt7vSiM jt2C2oSo57QOJPLwW7qk5tVhrJq0/jGuhAMFkTtdjfy9Te2T5ugt3ijlveIFPdoFvK9z xwTQl0o3EKL/28KB7cCugUDoxxZEnaFlcKXBMi7T5/jJXjc/mRivleJzZsaNaFcw0I+J OD2lB3gX7hukjsj3A9TK6xbv9U2SZAbUdwoTwMRhu9Pr5MtoLOnOZWC7EcgpwS6k+YUO /R/c+rgvL6d1dmTb3ytEKG2VgbCX+6CeWGHvy00ZZjQGF89F46apJk3LyAW5QBhWk8aS F6+Q==
X-Gm-Message-State: AOAM5328NdRmCAVytN7JWncR2a+hXHvabCEI8oZlD5dh7RdCSVk4BMeC Nwqu6msrsKmR8lEOu9Ke8T37MElETx0SSQsU61g=
X-Google-Smtp-Source: ABdhPJzRr7ezZ1qRqfRaXM8zD+a9GAFTFobd9fSARnWy4Ymf3U2wgUXyEmUKpJUj3vXxYNW6nqLKnQ75sJYaq5NOMl4=
X-Received: by 2002:a2e:b70b:: with SMTP id j11mr13990950ljo.142.1594052776969;  Mon, 06 Jul 2020 09:26:16 -0700 (PDT)
MIME-Version: 1.0
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com>  <830A4653-5912-46DE-8173-BA149899FDD3@mit.edu>  
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 6 Jul 2020 09:25:40 -0700
Message-ID: 
To: Roman Danyliw 
Cc: Tom Jones , Justin Richer ,  The IESG , "txauth@ietf.org" 
Content-Type: multipart/related; boundary="00000000000087152805a9c8555b"
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 06 Jul 2020 16:26:23 -0000

--00000000000087152805a9c8555b
Content-Type: multipart/alternative; boundary="00000000000087152705a9c8555a"

--00000000000087152705a9c8555a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Roman!

On Mon, Jul 6, 2020 at 5:45 AM Roman Danyliw  wrote:

> Hi!
>
>
>
> The milestones below the charter text now reflect the proposed
> simplification described below (by Dick).
>
>
>
> Regards,
>
> Roman
>
>
>
> *From:* iesg  *On Behalf Of * Tom Jones
> *Sent:* Friday, June 26, 2020 6:10 PM
> *To:* Justin Richer 
> *Cc:* Dick Hardt ; The IESG ;
> txauth@ietf.org
> *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization
> Protocol (gnap)
>
>
>
> Right - I have already proposed binding to application level keys in othe=
r
> venues and strongly oppose continued use of channel binding.
>
> Peace ..tom
>
>
>
>
>
> On Fri, Jun 26, 2020 at 2:03 PM Justin Richer  wrote:
>
> I agree with this proposed change in wording for the milestones. We don=
=E2=80=99t
> want to artificially limit the key binding presentation mechanisms. While=
 I
> think the three listed are likely to be among the first ones we see (base=
d
> on prior art and current community interest), I don=E2=80=99t think we ca=
n predict
> entirely what will be developed by the group and when.
>
>
>
>  =E2=80=94 Justin
>
>
>
> On Jun 26, 2020, at 1:21 PM, Dick Hardt  wrote:
>
>
>
>
>
> I am concerned with the following milestones:
>
>
>
>
>
>   Oct 2021 - Key presentation mechanism binding to the core protocol, TLS=
,
> to
>   WGLC
>
>   Oct 2021 - Key presentation mechanism binding to the core protocol,
>   detached HTTP signatures, to WGLC
>
>   Oct 2021 - Key presentation mechanism binding to the core protocol,
>   embedded HTTP signature, to WGLC
>
>
>
> I think it is overly prescriptive to specify which key presentation
> mechanisms will be created, and it implies that other key presentation
> mechanisms will not be worked on. While it is possible that channel bindi=
ng
> mechanisms such as TLS, detached HTTP signatures, and embedded HTTP
> signatures will be appropriate key presentation mechanisms for GNAP, it i=
s
> also quite possible that the WG will determine one or more are not
> appropriate, or the underlying mechanism may not gain acceptance, or
> channel binding is not always needed. For example, the effort to bind OAu=
th
> access tokens using RFC8471 was disbanded.
>
>
>
> Additionally, there are two primary communication channels in the protoco=
l
> that have different security requirements. The client to authorization
> server, and the client to resource server. The term "core protocol" is
> vague and could be construed that the same mechanism MUST be used in both
> channels.
>
>
>
> I propose the following new wording:
>
>
>
> Oct 2021 - Key presentation mechanism binding for each communication
> channel to WGLC.
>
>
>
>
>
> ---------- Forwarded message ---------
>
> From: *The IESG* 
> Date: Fri, Jun 26, 2020 at 9:10 AM
> Subject: WG Review: Grant Negotiation and Authorization Protocol (gnap)
> To: IETF-Announce 
> Cc: 
>
>
>
> A new IETF WG has been proposed in the Security Area. The IESG has not ma=
de
> any determination yet. The following draft charter was submitted, and is
> provided for informational purposes only. Please send your comments to th=
e
> IESG mailing list (iesg@ietf.org) by 2020-07-06.
>
> Grant Negotiation and Authorization Protocol (gnap)
> -----------------------------------------------------------------------
> Current status: Proposed WG
>
> Chairs:
>   Yaron Sheffer 
>   Leif Johansson 
>
> Assigned Area Director:
>   Roman Danyliw 
>
> Security Area Directors:
>   Benjamin Kaduk 
>   Roman Danyliw 
>
> Mailing list:
>   Address: txauth@ietf.org
>   To subscribe: https://www.ietf.org/mailman/listinfo/txauth
>   Archive: https://mailarchive.ietf.org/arch/browse/txauth/
>
> Group page: https://datatracker.ietf.org/group/gnap/
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/
>
> This group is chartered to develop a fine-grained delegation protocol for
> authorization and API access, as well as requesting and providing user
> identifiers and claims. This protocol will allow an authorizing party to
> delegate access to client software through an authorization server. It wi=
ll
> expand upon the uses cases currently supported by OAuth 2.0 and OpenID
> Connect
> (itself an extension of OAuth 2.0) to support authorizations scoped as
> narrowly as a single transaction, provide a clear framework for interacti=
on
> among all parties involved in the protocol flow, and remove unnecessary
> dependence on a browser or user-agent for coordinating interactions..
>
> The delegation process will be acted upon by multiple parties in the
> protocol,
> each performing a specific role. The protocol will decouple the interacti=
on
> channels, such as the end user=E2=80=99s browser, from the delegation cha=
nnel,
> which
> happens directly between the client and the authorization server (in
> contrast
> with OAuth 2.0, which is initiated by the client redirecting the user=E2=
=80=99s
> browser). The protocol will include a means of specifying how the user ca=
n
> potentially be involved in an interactive fashion during the delegation
> process. The client and Authorization Server (AS) will use these
> interaction
> mechanisms to involve the user, as necessary, to make authorization
> decisions.
> This decoupling avoids many of the security concerns and technical
> challenges
> of OAuth 2.0 and provides a non-invasive path for supporting future types
> of
> clients and interaction channels.
>
> The group will define interoperability for this protocol between differen=
t
> parties, including
>  - client and authorization server;
>  - client and resource server; and
>  - authorization server and resource server.
>
> The group will seek to minimize assumptions about the form of client
> applications, allowing for:
> - Fine-grained specification of access
> - Approval of AS attestation to identifiers and other identity claims
> - Approval of access to multiple resources and APIs in a single interacti=
on
> - Support for multiple access tokens in a single request and response
> - Support for directed, audience-restricted access tokens
> - Separation between the party authorizing access and the party operating
> the
> client requesting access
>
> The group will define extension points for this protocol to allow for
> flexibility in areas including:
>
> - Cryptographic agility for keys, message signatures, and proof of
> possession
> - User interaction mechanisms including web and non-web methods
> - Mechanisms for conveying user, software, organization, and other
> information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding resour=
ce
> requests to tokens and associated cryptographic keys
> - Optimized inclusion of additional information (including identifiers an=
d
> identity assertions) through the delegation process
>
> Additionally, the group will provide mechanisms for management of the
> protocol
> lifecycle including:
>
> - Discovery of the authorization server
> - Revocation of active tokens
> - Mechanisms for the AS and RS to communicate the access granted by an
> access
> token
>
> Although the artifacts for this work are not intended or expected to be
> backwards-compatible with OAuth 2.0 or OpenID Connect, the group will
> attempt
> to simplify migrating from OAuth 2.0 and OpenID Connect to the new protoc=
ol
> where possible.
>
> This group is not chartered to develop extensions to OAuth 2.0, and as su=
ch
> will focus on new technological solutions not necessarily compatible with
> OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be direct=
ed
> to the OAuth Working Group, including functionality back-ported from the
> protocol developed here to OAuth 2.0.
>
> The group is chartered to develop mechanisms for applying cryptographic
> methods, such as JOSE and COSE, to the delegation process. This group is
> not
> chartered to develop new cryptographic methods.
>
> The group is chartered to develop mechanisms for conveying identity
> information within the protocol including existing identifiers (such as
> email
> addresses, phone numbers, usernames, and subject identifiers) and
> assertions
> (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
> Credentials). The group is not chartered to develop new formats for
> identifiers or assertions, nor is the group chartered to develop schemas
> for
> user information, profiles, or other identity attributes, unless a viable
> existing format is not available.
>
> The initial work will focus on using HTTPS for communication between the
> client and the authorization server, taking advantage of optimization
> features of HTTP/2 and HTTP/3 where possible, and will strive to enable
> simple mapping to other protocols such as COAP when doing so does not
> conflict with the primary focus.
>
> Milestones to include:
> - Core delegation protocol
> - Key presentation mechanism bindings to the core protocol including TLS,
> detached HTTP signature, and embedded HTTP signatures
> - Conveyance mechanisms for identifiers and assertions
> - Guidelines for use of protocol extension points
> - (if needed) Guidelines on migration paths, implementation, and operatio=
ns
>
> Where possible, the group will seek to make use of tools to guide and
> inform
> the standardization process including formal analysis, architecture
> documents,
> and use case documents. These artifacts will not be considered as working
> group milestones or deliverables.
>
> The working group will cooperate and coordinate with other IETF WGs such =
as
> OAUTH, and work with external organizations, such as the OpenID Foundatio=
n,
> as appropriate.
>
> Milestones:
>
>   Jul 2021 - Core delegation protocol in WGLC
>
>   Oct 2021 - Key presentation mechanism binding to the core protocol, TLS=
,
> to
>   WGLC
>
>   Oct 2021 - Key presentation mechanism binding to the core protocol,
>   detached HTTP signatures, to WGLC
>
>   Oct 2021 - Key presentation mechanism binding to the core protocol,
>   embedded HTTP signature, to WGLC
>
>   Dec 2021 - Guidelines for use of protocol extension points to WGLC
>
>   Feb 2022 - Guidelines on migration paths, implementation, and operation=
s
> to
>    WGLC
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
> [image: Image removed by sender.]=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
>
>

--00000000000087152705a9c8555a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Roman!

On Mon, Jul 6, 2020 at 5:45 AM Roman Danyliw =
<rdd@cert.org> wrote:











Hi!


=C2=A0


The milestones below the charter text now reflect th=
e proposed simplification described below (by Dick).


=C2=A0


Regards,


Roman


=C2=A0








From: iesg <iesg-bounces@ietf.org> On Behalf Of =

Tom Jones

Sent: Friday, June 26, 2020 6:10 PM

To: Justin Richer <jricher@mit.edu>

Cc: Dick Hardt <dick.hardt@gmail.com>; The IESG <iesg@ietf.org>; txauth@ietf.org

Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization=
 Protocol (gnap)






=C2=A0




Right - I have already proposed binding to applicati=
on level keys in other venues and strongly oppose continued use of channel =
binding.












Peace ..tom










=C2=A0




=C2=A0






On Fri, Jun 26, 2020 at 2:03 PM Justin Richer <jricher@mit.edu> =
wrote:








I agree with this proposed change in wording for the=
 milestones. We don=E2=80=99t want to artificially limit the key binding pr=
esentation mechanisms. While I think the three listed are likely to be amon=
g the first ones we see (based on prior art
 and current community interest), I don=E2=80=99t think we can predict enti=
rely what will be developed by the group and when.=C2=A0




=C2=A0






=C2=A0=E2=80=94 Justin















On Jun 26, 2020, at 1:21 PM, Dick Hardt <dick.hardt@gmail.com=
> wrote:




=C2=A0










=C2=A0






I am concerned with the following milestones:






=C2=A0






=C2=A0






=C2=A0 Oct 2021 -=C2=A0Key=C2=A0presentation=C2=A0mechanism bind=
ing to the core protocol, TLS, to

=C2=A0 WGLC



=C2=A0 Oct 2021 -=C2=A0Key=C2=A0presentation=C2=A0mechanism binding to the =
core protocol,

=C2=A0 detached HTTP signatures, to WGLC



=C2=A0 Oct 2021 -=C2=A0Key=C2=A0presentation=C2=A0mechanism binding to the =
core protocol,

=C2=A0 embedded HTTP signature, to WGLC






=C2=A0






I think it is overly prescriptive to specify which key presentat=
ion mechanisms will be created, and it implies that other key presentation =
mechanisms will not be worked on.
 While it is possible that channel binding mechanisms such as TLS, detached=
 HTTP signatures, and embedded HTTP signatures will be appropriate key pres=
entation mechanisms for GNAP, it is also quite possible that the WG will de=
termine one or more are not appropriate,
 or the underlying mechanism may not gain acceptance, or channel binding is=
 not always needed. For example, the effort to bind OAuth access tokens usi=
ng RFC8471 was disbanded.






=C2=A0






Additionally, there are two primary communication channels in th=
e protocol that have different security requirements. The client to authori=
zation server, and the client to
 resource server. The term "core protocol" is vague and could be =
construed that the same mechanism MUST be used in both channels.<=
/u>






=C2=A0






I propose the following new wording:






=C2=A0






Oct 2021 - Key presentation mechanism binding for each communica=
tion channel to WGLC.






=C2=A0






=C2=A0




---------- Forwarded message ---------






From:=C2=A0The IESG=C2=A0<iesg-secretary@ietf.org>

Date: Fri, Jun 26, 2020 at 9:10 AM

Subject: WG Review: Grant Negotiation and Authorization Protocol (gnap)

To: IETF-Announce <ietf-announce@ietf.org>

Cc: <txauth@ietf.or=
g>








A new IETF WG has been proposed in the Security Area. The IESG has not made=


any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the<=
br>
IESG mailing list (iesg@=
ietf.org) by 2020-07-06.



Grant Negotiation and Authorization Protocol (gnap)

-----------------------------------------------------------------------

Current status: Proposed WG



Chairs:

=C2=A0 Yaron Sheffer <yaronf.ietf@gmail.com>

=C2=A0 Leif Johansson <leifj@sunet.se>



Assigned Area Director:

=C2=A0 Roman Danyliw <=
rdd@cert.org>



Security Area Directors:

=C2=A0 Benjamin Kaduk <kaduk@mit.edu>

=C2=A0 Roman Danyliw <=
rdd@cert.org>



Mailing list:

=C2=A0 Address:=C2=A0t=
xauth@ietf.org

=C2=A0 To subscribe:=C2=A0https://www.ietf.org/mailman/listinfo/txauth<=
br>
=C2=A0 Archive:=C2=A0https://mailarchive.ietf.org/arch/browse/txauth/



Group page:=C2=A0https://datatracker.ietf.org/group/gnap/



Charter:=C2=A0https://datatracker.ietf.org/doc/charter-ietf-gnap/



This group is chartered to develop a fine-grained delegation protocol for
authorization and API access, as well as requesting and providing user

identifiers and claims. This protocol will allow an authorizing party to
delegate access to client software through an authorization server. It will=


expand upon the uses cases currently supported by OAuth 2.0 and OpenID Conn=
ect

(itself an extension of OAuth 2.0) to support authorizations scoped as

narrowly as a single transaction, provide a clear framework for interaction=


among all parties involved in the protocol flow, and remove unnecessary

dependence on a browser or user-agent for coordinating interactions..



The delegation process will be acted upon by multiple parties in the protoc=
ol,

each performing a specific role. The protocol will decouple the interaction=


channels, such as the end user=E2=80=99s browser, from the delegation chann=
el, which

happens directly between the client and the authorization server (in contra=
st

with OAuth 2.0, which is initiated by the client redirecting the user=E2=80=
=99s

browser). The protocol will include a means of specifying how the user can<=
br>
potentially be involved in an interactive fashion during the delegation

process. The client and Authorization Server (AS) will use these interactio=
n

mechanisms to involve the user, as necessary, to make authorization decisio=
ns.

This decoupling avoids many of the security concerns and technical challeng=
es

of OAuth 2.0 and provides a non-invasive path for supporting future types o=
f

clients and interaction channels.



The group will define interoperability for this protocol between different<=
br>
parties, including

=C2=A0- client and authorization server;

=C2=A0- client and resource server; and

=C2=A0- authorization server and resource server.



The group will seek to minimize assumptions about the form of client

applications, allowing for:

- Fine-grained specification of access

- Approval of AS attestation to identifiers and other identity claims

- Approval of access to multiple resources and APIs in a single interaction=


- Support for multiple access tokens in a single request and response

- Support for directed, audience-restricted access tokens

- Separation between the party authorizing access and the party operating t=
he

client requesting access



The group will define extension points for this protocol to allow for

flexibility in areas including:



- Cryptographic agility for keys, message signatures, and proof of possessi=
on

- User interaction mechanisms including web and non-web methods

- Mechanisms for conveying user, software, organization, and other

information used in authorization decisions

- Mechanisms for presenting tokens to resource servers and binding resource=


requests to tokens and associated cryptographic keys

- Optimized inclusion of additional information (including identifiers and<=
br>
identity assertions) through the delegation process



Additionally, the group will provide mechanisms for management of the proto=
col

lifecycle including:



- Discovery of the authorization server

- Revocation of active tokens

- Mechanisms for the AS and RS to communicate the access granted by an acce=
ss

token



Although the artifacts for this work are not intended or expected to be

backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attem=
pt

to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol=


where possible.



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. Functionality that builds directly on OAuth 2.0 will be directed=


to the OAuth Working Group, including functionality back-ported from the
protocol developed here to OAuth 2.0.



The group is chartered to develop mechanisms for applying cryptographic

methods, such as JOSE and COSE, to the delegation process. This group is no=
t

chartered to develop new cryptographic methods.



The group is chartered to develop mechanisms for conveying identity

information within the protocol including existing identifiers (such as ema=
il

addresses, phone numbers, usernames, and subject identifiers) and assertion=
s

(such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable

Credentials). The group is not chartered to develop new formats for

identifiers or assertions, nor is the group chartered to develop schemas fo=
r

user information, profiles, or other identity attributes, unless a viable
existing format is not available.



The initial work will focus on using HTTPS for communication between the
client and the authorization server, taking advantage of optimization

features of HTTP/2 and HTTP/3 where possible, and will strive to enable

simple mapping to other protocols such as COAP when doing so does not

conflict with the primary focus.



Milestones to include:

- Core delegation protocol

- Key presentation mechanism bindings to the core protocol including TLS,
detached HTTP signature, and embedded HTTP signatures

- Conveyance mechanisms for identifiers and assertions

- Guidelines for use of protocol extension points

- (if needed) Guidelines on migration paths, implementation, and operations=




Where possible, the group will seek to make use of tools to guide and infor=
m

the standardization process including formal analysis, architecture documen=
ts,

and use case documents. These artifacts will not be considered as working
group milestones or deliverables.



The working group will cooperate and coordinate with other IETF WGs such as=


OAUTH, and work with external organizations, such as the OpenID Foundation,=


as appropriate.



Milestones:



=C2=A0 Jul 2021 - Core delegation protocol in WGLC



=C2=A0 Oct 2021 - Key presentation mechanism binding to the core protocol, =
TLS, to

=C2=A0 WGLC



=C2=A0 Oct 2021 - Key presentation mechanism binding to the core protocol,=
=C2=A0

=C2=A0 detached HTTP signatures, to WGLC



=C2=A0 Oct 2021 - Key presentation mechanism binding to the core protocol,<=
br>
=C2=A0 embedded HTTP signature, to WGLC



=C2=A0 Dec 2021 - Guidelines for use of protocol extension points to WGLC


=C2=A0 Feb 2022 - Guidelines on migration paths, implementation, and operat=
ions to

=C2=A0 =C2=A0WGLC







_______________________________________________

IETF-Announce mailing list

IETF-Announce@i=
etf.org

https://www.ietf.org/mailman/listinfo/ietf-announce










3D"Image=E1=90=A7




--=C2=A0

Txauth mailing list

Txauth@ietf.org<=
span style=3D"font-size:9pt;font-family:Helvetica,sans-serif">

https=
://www.ietf.org/mailman/listinfo/txauth








=C2=A0






-- 

Txauth mailing list

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















--00000000000087152705a9c8555a--

--00000000000087152805a9c8555b
Content-Type: image/jpeg; name="~WRD000.jpg"
Content-Disposition: inline; filename="~WRD000.jpg"
Content-Transfer-Encoding: base64
Content-ID: <17324f26b89a30f8d381>
X-Attachment-Id: 17324f26b89a30f8d381

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a
HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii
gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA
CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK
KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo
ooAKKKKACiiigAooooAKKKKACiiigD//2Q==
--00000000000087152805a9c8555b--


From nobody Mon Jul  6 09: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 160383A16BF for ; Mon,  6 Jul 2020 09:27: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 M3kZpAVZOva4 for ; Mon,  6 Jul 2020 09:27:32 -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 1D0B83A16AE for ; Mon,  6 Jul 2020 09:27:32 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id n23so46197034ljh.7 for ; Mon, 06 Jul 2020 09:27:31 -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=dRrRgIWZzMcIgDN14GEXqCD0cRAiMh/TkGf9ac9iC8Q=; b=oHmcYqRclxxXqqAt7UCZ21kP4xNlyKZbTrJXgNtLes0KdRq1RiywWcVQ07oBVczIx1 +pu2u4YaemFoZxmLVu6S3PCZ2oPrg81hSQghTVnQZMCHKRKyaa0xtIUK6MD/RfvoA4sF 1YrrF9ExY13gXIhmyoOWqvDy4+GU6ldK0yPlrPAqu9W27lSacg5e+HBnbE44IGHEWWie HhPurv0v2WXUIVyk+vQX4HbqaM4fwY3a0yd0MsAHtREIhapEF+2EZsA63deGwgYGBpsW e8w9qRCvEXkYswqpPCnlG9QOy4r5serq7ylR/2yuu99zwHEIfWejLd+zuncTfqUYEwL4 M8OA==
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=dRrRgIWZzMcIgDN14GEXqCD0cRAiMh/TkGf9ac9iC8Q=; b=h+pmFDHk9YdWQsfkda1uBwgtp4fpnRzxEXKpnKpGm9XKNSpYnhAG7THVqn5AMGN8Se ZmF4etZLgYq2JEwE+LJd82l2rY/BPLdxo56kKV9QGNUkRc4fmpvDuPsejV72WgPBklSb 1/VGNku+dp9L1nqXbgYosWFFBkmO9KgmQ64NJcg2EnSmsEpOzD3P4GgmGr+tLwopys9s 1qGL2wHZCwecS4PGYWN1WgMc88VaiYSsC3SkQxWSqt9foTSlZjCm6EAfjToBoSPiENj+ Jqxyp25wrkZQgbONZBi/c+Lk+c413DBofZiRKqWQQLfgDm1S3MeD89X7L4FocFXIhX5I 7HAQ==
X-Gm-Message-State: AOAM532CZNxaUedT6FmCVqqxKhjNzH2LqyrkWvJZLVkHax9pouRD7DOL s1tfnSm/jPrngqFI1MowNNYL/49o2IjI1IynDRc=
X-Google-Smtp-Source: ABdhPJxBIe1Kt6hPIDT4/VtwOokG+OUQLOia4pAM1WMAJdrxFl7xrJxJyeAblAwq7Bz1JRpqJC8gFOwuyTpQjHTBNBs=
X-Received: by 2002:a2e:7f10:: with SMTP id a16mr29023022ljd.69.1594052849856;  Mon, 06 Jul 2020 09:27:29 -0700 (PDT)
MIME-Version: 1.0
References:        <20200705225343.GQ16335@kduck.mit.edu>   
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 6 Jul 2020 09:26:53 -0700
Message-ID: 
To: Wayne Chang 
Cc: Fabien Imbault , Benjamin Kaduk ,  txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000de771f05a9c85966"
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 06 Jul 2020 16:27:35 -0000

--000000000000de771f05a9c85966
Content-Type: text/plain; charset="UTF-8"

Agreed.

For those that don't know Wayne, he is pretty involved in the VC efforts.

On Mon, Jul 6, 2020 at 9:20 AM Wayne Chang  wrote:

> Hi, just wanted to chime in that in the W3C credentials ecosystem, the JWT
> vs. JSON-LD proofs debate has raged on and consumed a lot of everyone's
> time. There are a lot of industry stakeholders who are skittish around
> requirements to adopt unfamiliar standard, and for some large companies
> involved in that ecosystem JWTs are more familiar than JSON-LD. For the
> Verifiable Credentials spec in particular, the authors decided to support
> both and were careful to ensure this possibility.
>
> This might be a decision better made higher up in the stack than what GNAP
> is trying to accomplish.
>
> On Mon, Jul 6, 2020, at 12:12 PM, Dick Hardt wrote:
>
> Fabien: it would be interesting to see how you think JSON-LD could be used
> in the protocol if you have some ideas on that. In XAuth, I am explicit
> that there are different formats / schema for tokens and claims. There is
> no default, so it is clear how additional formats can be requested and
> returned.
>
> Ben: I think that token formats such as macaroons are out of scope of
> GNAP, or at least the core protocol. The key feature of macaroons is the
> ability to further restrict the authorization. An interesting idea, but
> depends on a shared secret, and I have not heard of deployments. In a quick
> google on macaroons, I came across this talk from Gopher Con
> https://about.sourcegraph.com/go/gophercon-2018-an-over-engineering-disaster-with-macaroons
> .
>
> Justin: good to see we are on the same page on all your points. I'd add
> that we should consider what JSON is used in the protocol to minimize or
> eliminate any impedance mismatch between JSON and CBOR.
>
> /Dick
>
> On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault 
> wrote:
>
> Writing too fast, with an iteration of unrelated examples, did not convey
> the right message. Sorry if it wasn't clear and confusing. We indeed need
> to differentiate between bearer tokens (e.g. JWT, macaroons or even simple
> cookies, etc.) and identity claims (e.g. OIDC claims, linked data proofs,
> etc.).
> I only wanted to say that we need to take into account that there might be
> a variety of formats defined elsewhere. Not only OIDC (for claims) + JWT
> (for access tokens).
>
> Regarding JWT vs macaroons : I would say that JWT are additive, while
> macaroons are organized around caveats (so they're subtractive in a sense).
> But indeed they are both used in similar settings.
>
> Hope that clarifies.
> Fabien
>
> On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk  wrote:
>
> Hi Dick, Fabien,
>
> Just to clarify on one point, and check whether I'm confused:
>
> On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:
> > On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault 
> > wrote:
> >
> > > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt 
> wrote:
> > >
> > >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <
> fabien.imbault@gmail.com>
> > >> wrote:
> >
> > >
> > >> Just like OAuth 2.0, the access token is opaque to the client, and it
> is
> > >> not specified, so I'm confused what you mean by "other types of
> tokens than
> > >> JWT"?
> > >>
> > >> FI : I mean, for instance, linked data proofs, macaroons, and so on.
> > >
> >
> > I see. When I read 'token', I think of access tokens. You are referring
> to
> > what I would call a claims, which per above are defined somewhere else..
>
> My understanding was that macaroons, at least, were complete tokens that
> incorporate (at least by reference) multiple claims.  So a macaroon and a
> JWT would be analogous in that sense (container holding many claims).  I'm
> not sure whether the same holds for a linked data proof (or if it's just a
> way to represent a single claim), though.
>
> Am I confused?
>
> Thanks,
>
> Ben
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>

--000000000000de771f05a9c85966
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Agreed.

For those that don't know W=
ayne, he is pretty involved in the VC efforts.

On Mon, Jul 6, 2020 at =
9:20 AM Wayne Chang <wyc@fastmail.fm<=
/a>> wrote:
<=
u>
On Mon, Jul 6, 2020, at 12:12 PM, Dick Hardt wrote:
Fabien: it would be interes=
ting to see how you think JSON-LD could be used in the protocol if you have=
 some ideas on that. In XAuth, I am explicit that there are different forma=
ts / schema for tokens=C2=A0and claims. There is no default, so it is clear=
 how additional formats can be requested and returned.
Justin: good to see we are on the same page on all your poi=
nts. I'd add that we should consider what JSON is used in the protocol =
to minimize or eliminate any=C2=A0impedance=C2=A0mismatch between JSON and =
CBOR.

/Dick

On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault <fabien.imbault@gmail=
.com> wrote:
<=
div>Writing too fast, with an iteration of unrelated examples, did not conv=
ey the right message.=C2=A0Sorry if it wasn't clear and confusing. We i=
ndeed need to differentiate between bearer tokens (e.g. JWT, macaroons or e=
ven simple cookies, etc.) and identity claims (e.g. OIDC claims, linked dat=
a proofs, etc.).
I only wanted to say that we need =
to take into account that there might be a variety of formats defined elsew=
here. Not only OIDC (for claims) + JWT (for access tokens).
=
=C2=A0
Regarding JWT vs macaroons : I would say that JW=
T are additive, while macaroons are organized around caveats (so they'r=
e subtractive in a sense). But indeed they are both used in similar setting=
s.=C2=A0

Hope that clarifies.
Fabien

O=
n Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Dick, Fabien,
 
 Just =
to clarify on one point, and check whether I'm confused:
=
 
 On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote=
:
 > On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault <fabien.imbault@g=
mail.com>
 > wrote:
 > 
<=
div> > > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt <dick.hardt@gmail.com> wr=
ote:
 > >
 > >> On Wed, Jun 17, =
2020 at 3:47 AM Fabien Imbault <fabien.imbault@gmail.com>
 > =
>> wrote:
 > 
 > >
 > >> Just like OAuth 2.0, the access token is opaque to the clie=
nt, and it is
 > >> not specified, so I'm confus=
ed what you mean by "other types of tokens than
 > &g=
t;> JWT"?
 > >>
 > >>=
 FI : I mean, for instance, linked data proofs, macaroons, and so on.
 > >
 > 
 > I see. When I =
read 'token', I think of access tokens. You are referring to
 > what I would call a claims, which per above are defined somew=
here else..
 
 My understanding was that macaro=
ons, at least, were complete tokens that
 incorporate (at lea=
st by reference) multiple claims.=C2=A0 So a macaroon and a
 =
JWT would be analogous in that sense (container holding many claims).=C2=A0=
 I'm
 not sure whether the same holds for a linked data p=
roof (or if it's just a
 way to represent a single claim)=
, though.
 
 Am I confused?
 
=

 Thanks,
 
 Ben
--=C2=A0
Txauth m=
ailing list




--000000000000de771f05a9c85966--


From nobody Mon Jul  6 09:30: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 BF7CA3A16E7 for ; Mon,  6 Jul 2020 09:30: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 SPjbk19ld_22 for ; Mon,  6 Jul 2020 09:30:13 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 B5C1A3A16E0 for ; Mon,  6 Jul 2020 09:30:13 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id o5so39904356iow.8 for ; Mon, 06 Jul 2020 09:30: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=9Fi2zqffl7aiBrCMkNAWKFNJ87K93W8VVbeyyfJthM8=; b=CKj8Ad7aJC/EjZ3x5jJbE3+BMcEfiG1pHuDuStYom1M6SCXsCxTkW7JVVpoOHvDjdR 1dybZNKQh/jdEDxCYhZqogx9IjuAokeik+0mRfCeTN/WFbiFmRp7y2WyP+eUV6qyMF2y DPsKjnBlcvlZw26qYIIf5vPKKyvg3qDuSQ6lNu0B3mRUwNu8PEYynQvMs8wTM566zSft EXwHiPIRFLvbw0XbR04ixImc+Gi6qeJCU37OWs9yhjzyukb8Da361hu3e7AK73wrfHNe tvam+ZentZjl16e5sqcnL+Ftgn3/0qsAlnjVBg00lkmT6V5B66LdxM7mEnPK5v7tE4eb AuKg==
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=9Fi2zqffl7aiBrCMkNAWKFNJ87K93W8VVbeyyfJthM8=; b=Pmi1Km9I4PV8OVrRQrzmK590kLVTBi1oDngNty/G2w7SZuqfzF527YojZKdBhDIFpD sRanqtEyK0EAy3shBGQp5I4zT972PjBAgGbolkN98fF7IMVr6xRUEj4kykoxklW/qCBr a1yvKNn1yTzSLrpMHFFPUXnbSKZm5yAAViG7R4bapjc1DqgDd/Ne+D9OK0tG7GtB2hgG XaZ0ZS0dYqJN4diyNNsGdLHnLTiGT5RYyZfqxChhXfZrXZ1O/jOKpgYHUM6If/TJAWaN elTzabXdDQaaaJqTp/NwPS7XMPx3MOkQjdpwupUdVfT3IaNeEkPEmgo2PxuHp8dIjeij yZcA==
X-Gm-Message-State: AOAM533C6yL5MoLT78u3kz6a4C9t1RLG1Vfl5ysCEuB1HQ3CLhsBXuWX VLJT2fR4xiSniF8ytj2eJqFI0PjrM7xOQfbsjlY=
X-Google-Smtp-Source: ABdhPJwu76YWkfTdX+/fUO9MZUClxxiEHLR2NtbIYcnFoWqX/dLbbvvE/tizt5wrHN+SqtUfmwstUHiQz0vYCXffLDc=
X-Received: by 2002:a5d:8f98:: with SMTP id l24mr25927383iol.141.1594053012927;  Mon, 06 Jul 2020 09:30:12 -0700 (PDT)
MIME-Version: 1.0
References:        <20200705225343.GQ16335@kduck.mit.edu>    
In-Reply-To: 
From: Fabien Imbault 
Date: Mon, 6 Jul 2020 18:30:00 +0200
Message-ID: 
To: Dick Hardt 
Cc: Wayne Chang , Benjamin Kaduk , txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000096bb0005a9c86312"
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 06 Jul 2020 16:30:16 -0000

--00000000000096bb0005a9c86312
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

OK with that. The priority should be on the core of the protocol anyway.
Fabien

Le lun. 6 juil. 2020 =C3=A0 18:27, Dick Hardt  a =C3=
=A9crit :

> Agreed.
>
> For those that don't know Wayne, he is pretty involved in the VC efforts.
>
> On Mon, Jul 6, 2020 at 9:20 AM Wayne Chang  wrote:
>
>> Hi, just wanted to chime in that in the W3C credentials ecosystem, the
>> JWT vs. JSON-LD proofs debate has raged on and consumed a lot of everyon=
e's
>> time. There are a lot of industry stakeholders who are skittish around
>> requirements to adopt unfamiliar standard, and for some large companies
>> involved in that ecosystem JWTs are more familiar than JSON-LD. For the
>> Verifiable Credentials spec in particular, the authors decided to suppor=
t
>> both and were careful to ensure this possibility.
>>
>> This might be a decision better made higher up in the stack than what
>> GNAP is trying to accomplish.
>>
>> On Mon, Jul 6, 2020, at 12:12 PM, Dick Hardt wrote:
>>
>> Fabien: it would be interesting to see how you think JSON-LD could be
>> used in the protocol if you have some ideas on that. In XAuth, I am
>> explicit that there are different formats / schema for tokens and claims=
.
>> There is no default, so it is clear how additional formats can be reques=
ted
>> and returned.
>>
>> Ben: I think that token formats such as macaroons are out of scope of
>> GNAP, or at least the core protocol. The key feature of macaroons is the
>> ability to further restrict the authorization. An interesting idea, but
>> depends on a shared secret, and I have not heard of deployments. In a qu=
ick
>> google on macaroons, I came across this talk from Gopher Con
>> https://about.sourcegraph.com/go/gophercon-2018-an-over-engineering-disa=
ster-with-macaroons
>> .
>>
>> Justin: good to see we are on the same page on all your points. I'd add
>> that we should consider what JSON is used in the protocol to minimize or
>> eliminate any impedance mismatch between JSON and CBOR.
>>
>> /Dick
>>
>> On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault 
>> wrote:
>>
>> Writing too fast, with an iteration of unrelated examples, did not conve=
y
>> the right message. Sorry if it wasn't clear and confusing. We indeed nee=
d
>> to differentiate between bearer tokens (e.g. JWT, macaroons or even simp=
le
>> cookies, etc.) and identity claims (e.g. OIDC claims, linked data proofs=
,
>> etc.).
>> I only wanted to say that we need to take into account that there might
>> be a variety of formats defined elsewhere. Not only OIDC (for claims) + =
JWT
>> (for access tokens).
>>
>> Regarding JWT vs macaroons : I would say that JWT are additive, while
>> macaroons are organized around caveats (so they're subtractive in a sens=
e).
>> But indeed they are both used in similar settings.
>>
>> Hope that clarifies.
>> Fabien
>>
>> On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk  wrote:
>>
>> Hi Dick, Fabien,
>>
>> Just to clarify on one point, and check whether I'm confused:
>>
>> On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:
>> > On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault > >
>> > wrote:
>> >
>> > > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt 
>> wrote:
>> > >
>> > >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <
>> fabien.imbault@gmail.com>
>> > >> wrote:
>> >
>> > >
>> > >> Just like OAuth 2.0, the access token is opaque to the client, and
>> it is
>> > >> not specified, so I'm confused what you mean by "other types of
>> tokens than
>> > >> JWT"?
>> > >>
>> > >> FI : I mean, for instance, linked data proofs, macaroons, and so on=
.
>> > >
>> >
>> > I see. When I read 'token', I think of access tokens. You are referrin=
g
>> to
>> > what I would call a claims, which per above are defined somewhere else=
..
>>
>> My understanding was that macaroons, at least, were complete tokens that
>> incorporate (at least by reference) multiple claims.  So a macaroon and =
a
>> JWT would be analogous in that sense (container holding many claims).  I=
'm
>> not sure whether the same holds for a linked data proof (or if it's just=
 a
>> way to represent a single claim), though.
>>
>> Am I confused?
>>
>> Thanks,
>>
>> Ben
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>>

--00000000000096bb0005a9c86312
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


OK with that. The priority should be on the core of the p=
rotocol anyway.=C2=A0
Fabien=C2=A0

Le lun. 6 juil. 20=
20 =C3=A0 18:27, Dick Hardt <dic=
k.hardt@gmail.com> a =C3=A9crit=C2=A0:
Agreed.

For those that don&#=
39;t know Wayne, he is pretty involved in the VC efforts.

On Mon, Jul =
6, 2020 at 9:20 AM Wayne Chang <wyc@fastmail.fm> wrote:
Hi, ju=
st wanted to chime in that in the W3C credentials ecosystem, the JWT vs. JS=
ON-LD proofs debate has raged on and consumed a lot of everyone's time.=
 There are a lot of industry stakeholders who are skittish around requireme=
nts to adopt unfamiliar standard, and for some large companies involved in =
that ecosystem JWTs are more familiar than JSON-LD.=C2=A0For the Verifiable=
 Credentials spec in particular, the authors decided to support both and we=
re careful to ensure this possibility.

<=
div>This might be a decision better made higher up in the stack than what G=
NAP is trying to accomplish.

On Mon, Jul=
 6, 2020, at 12:12 PM, Dick Hardt wrote:
Fabien: it would be interesting to=
 see how you think JSON-LD could be used in the protocol if you have some i=
deas on that. In XAuth, I am explicit that there are different formats / sc=
hema for tokens=C2=A0and claims. There is no default, so it is clear how ad=
ditional formats can be requested and returned.

Ben: I think that token formats such as macaroons are out of scope of GNA=
P, or at least the core protocol. The key feature of macaroons is the abili=
ty to further restrict the authorization. An interesting idea, but depends =
on a shared secret, and I have not heard of deployments. In a quick google =
on macaroons, I came across this talk from Gopher Con=C2=A0https://about.sourcegraph=
.com/go/gophercon-2018-an-over-engineering-disaster-with-macaroons.
=


Justin: good to see we are on the same page on al=
l your points. I'd add that we should consider what JSON is used in the=
 protocol to minimize or eliminate any=C2=A0impedance=C2=A0mismatch between=
 JSON and CBOR.

/Dick

=

On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault &=
lt;fabien.imbault@gmail.com> wrote:
Writing too fast, with an iteration of unr=
elated examples, did not convey the right message.=C2=A0Sorry if it wasn=
9;t clear and confusing. We indeed need to differentiate between bearer tok=
ens (e.g. JWT, macaroons or even simple cookies, etc.) and identity claims =
(e.g. OIDC claims, linked data proofs, etc.).
I onl=
y wanted to say that we need to take into account that there might be a var=
iety of formats defined elsewhere. Not only OIDC (for claims) + JWT (for ac=
cess tokens).
=C2=A0
Regarding JWT vs mac=
aroons : I would say that JWT are additive, while macaroons are organized a=
round caveats (so they're subtractive in a sense). But indeed they are =
both used in similar settings.=C2=A0

Hope=
 that clarifies.
Fabien

<=
/div>
On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk &=
lt;ka=
duk@mit.edu> wrote:
Hi Dic=
k, Fabien,
 
 Just to clarify on one point, and=
 check whether I'm confused:
 
 On Fri, Jul=
 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:
 > On Fri=
, Jul 3, 2020 at 1:19 AM Fabien Imbault <fabien.imbault@gmail.com<=
/a>>
 > >> wrote:
 > 
=

 > >
 > >> Just like OAuth 2.0, the acces=
s token is opaque to the client, and it is
 > >> not=
 specified, so I'm confused what you mean by "other types of token=
s than
 > >> JWT"?
 > >>=

 > >> FI : I mean, for instance, linked data proofs=
, macaroons, and so on.
 > >
 > 
 > I see. When I read 'token', I think of access tokens=
. You are referring to
 > what I would call a claims, whic=
h per above are defined somewhere else..
 
 My =
understanding was that macaroons, at least, were complete tokens that
 incorporate (at least by reference) multiple claims.=C2=A0 So a m=
acaroon and a
 JWT would be analogous in that sense (containe=
r holding many claims).=C2=A0 I'm
 not sure whether the s=
ame holds for a linked data proof (or if it's just a
 way=
 to represent a single claim), though.
 
 Am I =
confused?
 
 Thanks,
 
<=
div> Ben
--=
=C2=A0
Txauth mailing list





--00000000000096bb0005a9c86312--


From nobody Mon Jul  6 09:38: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 A77EF3A178F for ; Mon,  6 Jul 2020 09:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.62
X-Spam-Level: 
X-Spam-Status: No, score=-0.62 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.276, 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 cTPqe5SzhQXt for ; Mon,  6 Jul 2020 09:38:20 -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 65DFB3A1790 for ; Mon,  6 Jul 2020 09:38:19 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d77 with ME id zseG2200D4FMSmm03seGn9; Mon, 06 Jul 2020 18:38:17 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 06 Jul 2020 18:38:17 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt 
Cc: Roman Danyliw , Nat Sakimura , "txauth@ietf.org" , The IESG 
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com>     <3c21e0fa-5636-54fe-675f-abc5b41ab09e@free.fr>  <731a364a19a74e1d982d59d9c441dc0a@cert.org>  
From: Denis 
Message-ID: <354edabf-d9d5-1318-403f-866043e8d0a6@free.fr>
Date: Mon, 6 Jul 2020 18:38: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="------------5C0DF65D021A32FAB4B12586"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 06 Jul 2020 16:38:27 -0000

This is a multi-part message in MIME format.
--------------5C0DF65D021A32FAB4B12586
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Dick,
> Hi Denis
>
> Just like "privacy", "security" is not called out as a goal. (it is 
> mentioned as an issue with OAuth 2.0).

The word "security" appears once in the charter, but the word "privacy" 
does not appear.

What goes wellwithout saying, goes even better whenyou sayit.

Many features announced in the charter *prevent *to apply privacy 
principles.
So it is easy to get the impression that the charter is considering that 
privacy is a non-goal.

"Privacy by design" should be mentioned as well as "privacy by default".
These two magic sentences are of utmost importance.

Denis

>
> On Mon, Jul 6, 2020 at 8:49 AM Denis  > wrote:
>
>     One single comment.
>
>     Dick wrote on the last line:
>
>         I think pretty much everyone is onboard supporting privacy,
>         but not all use cases have the same privacy considerations.
>
>     I hope that this is true, but in such a case I can't understand
>     why the word "*privacy*" is missing in the charter.
>
>     Denis
>
>     Note: IESG added
>
>>     Hello!
>>
>>     I’m top-posting here because there is no easy way for me to
>>     cleaning insert my process comment.  I think we are having a
>>     necessary conversation below and in no way should it stop because
>>     of this note.
>>
>>     As a process check, this thread started with a request for
>>     community review on the charter text [1].  Among other things,
>>     this charter review is trying to ensure the problem is clear,
>>     defines the bounds of the desired solutions and identifies
>>     critical objections from the consensus-derived text.  The text is
>>     not intended to define detailed requirements/architecture,
>>     resolve tradeoffs, or to specify a solution, unless they are
>>     critical to bounding the solution.  These details should be left
>>     to future discussions of a chartered WG (not that they can’t
>>     start now in parallel). Additionally, as a reminder, while there
>>     are multiple individual drafts with proposed solutions in the
>>     datatracker, the design decisions they make are not part of the
>>     charter and their adoption is not assumed by the charter.  If
>>     there are key design elements in those or any other documents
>>     that is felt to be crucial to scoping the WG,  we need to capture
>>     the thinking, generalize it (as appropriate), and add it to the
>>     charter text explicitly or by reference.
>>
>>     Let’s continue to talk about the technical details of the use
>>     cases, design properties, constraints and candidate solutions. 
>>     Additionally, given the -05 charter text and milestones [2], it
>>     would be helpful to understand what outstanding concerns remain
>>     with the charter text in preparation for the Thursday, July 9^th
>>     telechat where the IESG will use community feedback to help
>>     decide the way ahead for this proposed WG.
>>
>>     Roman
>>
>>     [1]
>>     https://mailarchive.ietf.org/arch/msg/txauth/4nE8rtyRPtdk0FrclQ1c-FWMO8w/
>>
>>     [2] https://datatracker.ietf.org/doc/charter-ietf-gnap/
>>     
>>
>>     *From:* Txauth 
>>      *On Behalf Of *Dick Hardt
>>     *Sent:* Friday, July 3, 2020 9:41 PM
>>     *To:* Denis  
>>     *Cc:* Nat Sakimura 
>>     ; txauth@ietf.org 
>>     *Subject:* Re: [Txauth] WG Review: Grant Negotiation and
>>     Authorization Protocol (gnap)
>>
>>     + Nat as he is mentioned
>>
>>     - IESG
>>
>>     On Fri, Jul 3, 2020 at 2:16 AM Denis >     > wrote:
>>
>>         Hello Dick,
>>
>>             Catching up on this email ... comments inserted ...
>>
>>             On Mon, Jun 29, 2020 at 12:06 AM Denis
>>             > wrote:
>>
>>                 Hello Dick,
>>
>>                     Denis, thanks for sharing your thoughts, some
>>                     clarifications on your statements inserted:
>>
>>                     On Fri, Jun 26, 2020 at 9:42 AM Denis
>>                     >
>>                     wrote:
>>
>>                     
>>
>>                             *New proposed charter*
>>
>>                     
>>
>>
>>                             Resource servers inform their clients
>>                             about which access token formats are
>>                             acceptable and depending upon the king of
>>                             operation
>>                             that is requested, which kind of
>>                             attributes are needed and from which ASs
>>                             that my be obtained.
>>
>>                     While at times this may be appropriate, at other
>>                     times disclosing the attributes the RS requires
>>                     is not needed by the client.
>>                     For example, an enterprise client accessing a
>>                     resource does not need to know which groups a
>>                     user belongs to,
>>                     but the RS may require that to determine if the
>>                     user running the client has access.
>>
>>                 As soon as there is a desire to implement privacy by
>>                 default, the client should not provide more
>>                 attributes than strictly necessary.
>>                 Even after three readings of your example, I failed
>>                 to understand it.
>>
>>
>>                             A major difference with OAuth 2.0 is that
>>                             there is no bilateral trust relationship
>>                             between an authorization server and a
>>                             resource server:
>>                             for a given category of attributes, a
>>                             resource server may trust one or more
>>                             authorization servers. Another major
>>                             difference with OAuth 2.0.
>>                             is that the content of an attributes
>>                             token is meant to be accessible to the
>>                             client.
>>
>>                     This is not how OAuth 2.0 works. See slides 7 and
>>                     8 from my original IETF presentation on what
>>                     became OAuth 2.0
>>
>>                     https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation
>>
>>                 I looked at the two slides.
>>
>>                 Unfortunately slide 7 has just one arrow with the
>>                 word "trust". This is insufficient to understand what
>>                 is meant unless being present
>>                 at the presentation. Does it mean that the PR (RS)
>>                 trusts one AS or that it may trust multiple ASs ?
>>
>>                 Unfortunately slide 8 has just one arrow between the
>>                 PR and the AS which is red-crossed but no text at
>>                 all. This is insufficient to understand
>>                 what is meant unless being present at the
>>                 presentation. Does it mean that the PR and the AS
>>                 never communicate directly ?
>>                 Does it mean that they have no relationships at all,
>>                 besides the one way trust relationship mentioned in
>>                 slide 7 ?
>>
>>                 So it hard to say whether these two slides are indeed
>>                 meaning that there is no bilateral relationship
>>                 between an authorization server and a resource server.
>>
>>             Apologies for not providing an explanation on the slides.
>>
>>             Slide 7 shows that trust between the AS and PR (now RS)
>>             was unidirectional, from the RS to the AS.
>>
>>             Slide 8 indicates that trust is not bidirectional.
>>
>>         [Denis] ... which means that slide 8 contradicts slide 7.  :-)
>>
>>     Slide 8 says it does not go both ways. Slide 7 says it goes one
>>     way. I don't see the contradiction.
>>
>>         I would have preferred that you meant: the RS and the AS
>>         never communicate directly, which is indeed a nice property
>>         to follow
>>         to ensure the user's privacy.
>>
>>     That is one model. Other models are appropriate in other
>>     circumstances..
>>
>>             There is no limit on how many ASs an RS may trust.
>>
>>         [Denis] This is fine.
>>
>>             On June 12, Nat Sakimura recently answered to an email
>>             with the following topic:
>>
>>                     Re: [OAUTH-WG] Comments on
>>                     draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
>>                     Authorization Framework: JWT Secured
>>                     Authorization Request))
>>
>>                 My arguments were:
>>
>>                 The original model for OAuth was making the
>>                 assumption that the AS and the RS had a strong
>>                 bilateral relationship.
>>
>>                 *A key question is whether such strong relationship
>>                 will be maintained for ever *or
>>                 whether it will be allowed to perform some evolutions
>>                 of this relationship.
>>
>>                 In order to respect the privacy of the users, there
>>                 is the need to encompass other scenarios. One of
>>                 these scenarios is that the AS and the RS
>>                 do not need any longer to have such a strong
>>                 relationship. In terms of trust relationships, a RS
>>                 simply needs to trust the access tokens issued by an AS.
>>                 The AS does have any more a "need to know" of all the
>>                 RSs that are accepting its access tokens. This would
>>                 be a major simplification of the current global
>>                 architecture.
>>
>>                 Nat's position was:
>>
>>                     "My take is that the basic assumption of OAuth
>>                     2.0 Framework is that there is a strong
>>                     relationship between AS and RS.
>>                     I feel that it is quite unrealistic that an RS
>>                     would trust the access token issued by an AS that
>>                     it has no strong relationship with".
>>
>>                 There are indeed different positions on this topic.
>>
>>             I don't think Nat and I have different opinions, but I
>>             will let Nat clarify.
>>
>>             Just because there is a strong relationship between the
>>             AS and RS, does not mean it is bidirectional. I would
>>             understand
>>
>>             "I feel that it is quite unrealistic that an RS would
>>             trust the access token issued by an AS that it has no
>>             strong relationship with"
>>
>>             to indicate Nat is expecting the trust to be from the RS
>>             to the AS.
>>
>>         [Denis] Speaking of a "strong relationship" is ambiguous. The
>>         key point being whether the relationship is unilateral or
>>         bilateral.
>>         There is no need to use the wording "strong relationship"
>>         when the relationship is only unilateral: a RS simply trusts
>>         an AS for the access tokens it issues.
>>         In such a case, this does not mean that an AS is knowing all
>>         the RSs that are trusting it.
>>
>>         On the contrary, a strong (bi-)relationship is when a RS and
>>         an AS both agree between them about the meaning of scope
>>         parameters.
>>         This is a typical case for OAuth 2.0.
>>
>>     You can ask Nat what he meant by "strong relationship"
>>
>>     The AS is stating what a scope means to it and the user.. The RS
>>     can do whatever it wants. I don't see that as requiring a
>>     bidirectional relationship.
>>
>>                     The AS may not even know who the RS (or PR in the
>>                     slides) is.
>>
>>                     
>>
>>
>>                         I got rid of the word "delegation": the
>>                         client does not delegate anything to an
>>                         authorization server. If it would, this would
>>                         mean that the authorization server
>>                         would be able to act as the client and could
>>                         know everything that the client will do,
>>                         which comes into contradiction with the
>>                         user's privacy.
>>
>>                     The above is not true.
>>
>>                     The Resource Owner is delegating access control
>>                     to the AS in authorization use cases.
>>
>>                 The OAuth 2.0 model does not mandate any more the
>>                 presence of a Resource Owner.
>>
>>             Why do you say that? The RO is who owns the RS. Your
>>             statement does not make sense.
>>
>>         [Denis] I mean that there is not necessarily a protocol
>>         defined so that the RO can interact with the requests from
>>         the clients.
>>
>>     Is the RO the User? In consumer use cases it usually is, and the
>>     RO is using the client. I'm not sure what you scenario you are
>>     describing
>>
>>                     The client is may be delegating user
>>                     authentication to the AS in identity claim use cases.
>>
>>                 Delegating user authentication to the AS is different
>>                 from delegating access control to the AS.
>>
>>             Agreed. Your statement was there was no delegation. I'm
>>             explaining there are potentially two delegations.
>>
>>                     The AS can act as the client in many OAuth
>>                     deployments, as the access token is a bearer token.
>>
>>                 A bearer token is rather insecure.
>>
>>             Cookies are also bearer tokens. But we use them all the
>>             time in web apps for storing session state and prior
>>             authentication! :)
>>
>>                     That does not mean the AS knows what the client
>>                     is doing.
>>
>>                 There are currently two attempts in the OAuth WG to
>>                 let know to the AS what the client is doing:
>>
>>                   * draft-ietf-oauth-jwsreq-22   (The OAuth 2.0
>>                     Authorization Framework: JWT Secured
>>                     Authorization Request)
>>                   * draft-ietf-oauth-rar-01 (OAuth 2.0 Rich
>>                     Authorization Requests)
>>
>>             Those are optional, and in some situations are a desired
>>             property.
>>
>>         [Denis] However, in these two drafts, the privacy
>>         considerations sections are silent on this point.
>>
>>     There are lots of missing details in both drafts! Security
>>     considerations, error messages etc.
>>
>>     I think pretty much everyone is onboard supporting privacy, but
>>     not all use cases have the same privacy considerations.
>>
>>     /Dick
>>
>


--------------5C0DF65D021A32FAB4B12586
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Dick,

    

      
      
Hi Denis
        


        

        
Just like "privacy", "security" is not called out as a
          goal. (it is mentioned as an issue with OAuth 2.0).

      

    

    
The word "security" appears once in the charter, but the word
      "privacy" does not appear.

    
What goes well without saying, goes even better when you say it.

    
Many features announced in the charter prevent to apply
      privacy principles.  

      So it is easy to get the impression that the charter is
      considering that privacy is a non-goal.

    
"Privacy by design" should be mentioned as well as "privacy by
      default". 

      These two magic sentences are of utmost importance.

    
Denis

    


      

        
On Mon, Jul 6, 2020 at 8:49 AM
          Denis <denis.ietf@free.fr> wrote:

        

        

          

            
One single comment.

            


            

            
Dick wrote on the last line:

            

              
I think pretty much everyone is onboard supporting
                privacy, but not all use cases have the same privacy
                considerations.

            

            
I hope that this is true, but in such a case I can't
              understand why the word "privacy" is missing in the
              charter.

            


            

            
Denis

            


            

            
Note: IESG added

            


            

            

              

                
Hello!

                
 

                
I’m top-posting here because there
                  is no easy way for me to cleaning insert my process
                  comment.  I think we are having a necessary
                  conversation below and in no way should it stop
                  because of this note.

                
 

                
As a process check, this thread
                  started with a request for community review on the
                  charter text [1].  Among other things, this charter
                  review is trying to ensure the problem is clear,
                  defines the bounds of the desired solutions and
                  identifies critical objections from the
                  consensus-derived text.  The text is not intended to
                  define detailed requirements/architecture, resolve
                  tradeoffs, or to specify a solution, unless they are
                  critical to bounding the solution.  These details
                  should be left to future discussions of a chartered WG
                  (not that they can’t start now in parallel). 
                  Additionally, as a reminder, while there are multiple
                  individual drafts with proposed solutions in the
                  datatracker, the design decisions they make are not
                  part of the charter and their adoption is not assumed
                  by the charter.  If there are key design elements in
                  those or any other documents that is felt to be
                  crucial to scoping the WG,  we need to capture the
                  thinking, generalize it (as appropriate), and add it
                  to the charter text explicitly or by reference.

                
 

                
Let’s continue to talk about the
                  technical details of the use cases, design properties,
                  constraints and candidate solutions.  Additionally,
                  given the -05 charter text and milestones [2], it
                  would be helpful to understand what outstanding
                  concerns remain with the charter text in preparation
                  for the Thursday, July 9th telechat where
                  the IESG will use community feedback to help decide
                  the way ahead for this proposed WG.

                
 

                
Roman

                
 

                
[1] 
https://mailarchive.ietf.org/arch/msg/txauth/4nE8rtyRPtdk0FrclQ1c-FWMO8w/

                
[2] 
                    https://datatracker.ietf.org/doc/charter-ietf-gnap/

                
 

                
 

                
 

                

                  

                    

                      
From: Txauth <txauth-bounces@ietf.org>
                        On Behalf Of Dick Hardt

                        Sent: Friday, July 3, 2020 9:41 PM

                        To: Denis <denis.ietf@free.fr>

                        Cc: Nat Sakimura <sakimura@gmail.com>;
                        txauth@ietf.org

                        Subject: Re: [Txauth] WG Review: Grant
                        Negotiation and Authorization Protocol (gnap)

                    

                  

                  
 

                  

                    

                      
+ Nat as he is mentioned

                    

                    

                      
- IESG

                    

                    
 

                    

                      

                        
On Fri, Jul 3, 2020 at 2:16
                          AM Denis <denis.ietf@free.fr>
                          wrote:

                      

                      

                        

                          

                            
Hello Dick,

                          

                          

                            
 

                          

                          

                            

                              

                                

                                  

                                    

                                      
Catching up
                                        on this email ... comments
                                        inserted ...

                                    

                                    
 

                                    

                                      

                                        
On Mon, Jun
                                          29, 2020 at 12:06 AM Denis
                                          <denis.ietf@free.fr>
                                          wrote:

                                      

                                      

                                        

                                          

                                            
Hello
                                                Dick,

                                          

                                          

                                            
 

                                          

                                          

                                            

                                              

                                                
Denis, thanks for sharing your
                                                    thoughts, some
                                                    clarifications on
                                                    your statements
                                                    inserted:

                                              

                                              
 

                                              

                                                

                                                  
On Fri, Jun 26, 2020 at 9:42 AM
                                                      Denis <denis.ietf@free.fr> wrote:

                                                

                                                

                                                  
<snip>

                                                

                                                

                                                  

                                                    

                                                      

                                                        
New
                                                          proposed
                                                          charter

                                                      

                                                    

                                                  

                                                

                                                

                                                  
<snip> 

                                                

                                                

                                                  

                                                    

                                                      

                                                        


                                                          Resource
                                                          servers inform
                                                          their clients
                                                          about which
                                                          access token
                                                          formats are
                                                          acceptable and
                                                          depending upon
                                                          the king of
                                                          operation

                                                          that is
                                                          requested,
                                                          which kind of
                                                          attributes are
                                                          needed and
                                                          from which ASs
                                                          that my be
                                                          obtained.

                                                      

                                                    

                                                  

                                                

                                                

                                                  
While at times this may be
                                                      appropriate, at
                                                      other times
                                                      disclosing the
                                                      attributes the RS
                                                      requires is not
                                                      needed by the
                                                      client. 

                                                      For example, an
                                                      enterprise client
                                                      accessing a
                                                      resource does not
                                                      need to know which
                                                      groups a user
                                                      belongs to, 

                                                      but the RS may
                                                      require that to
                                                      determine if the
                                                      user running the
                                                      client has access.

                                                

                                              

                                            

                                          

                                          
As
                                              soon as there is a desire
                                              to implement privacy by
                                              default, the client should
                                              not provide more
                                              attributes than strictly
                                              necessary. 

                                              Even after three readings
                                              of your example, I failed
                                              to understand it.

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        


                                                          A major
                                                          difference
                                                          with OAuth 2.0
                                                          is that there
                                                          is no
                                                          bilateral
                                                          trust
                                                          relationship
                                                          between an
                                                          authorization
                                                          server and a
                                                          resource
                                                          server: 

                                                          for a given
                                                          category of
                                                          attributes, a
                                                          resource
                                                          server may
                                                          trust one or
                                                          more
                                                          authorization
                                                          servers.
                                                          Another major
                                                          difference
                                                          with OAuth
                                                          2.0.

                                                          is that the
                                                          content of an
                                                          attributes
                                                          token is meant
                                                          to be
                                                          accessible to
                                                          the client.

                                                      

                                                    

                                                  

                                                

                                                

                                                  
This is not how OAuth 2.0 works.
                                                      See slides 7 and 8
                                                      from my original
                                                      IETF presentation
                                                      on what became
                                                      OAuth 2.0

                                                

                                                

                                                  
 

                                                

                                                
                                              

                                            

                                          

                                          
I
                                              looked at the two slides.
                                             

                                          
Unfortunately
                                              slide 7 has just one arrow
                                              with the word "trust".
                                              This is insufficient to
                                              understand what is meant
                                              unless being present 

                                              at the presentation. Does
                                              it mean that the PR (RS)
                                              trusts one AS or that it
                                              may trust multiple ASs ?

                                        

                                      

                                      

                                        

                                          
Unfortunately
                                              slide 8 has just one arrow
                                              between the PR and the AS
                                              which is red-crossed but
                                              no text at all. This is
                                              insufficient to understand

                                              what is meant unless being
                                              present at the
                                              presentation. Does it mean
                                              that the PR and the AS
                                              never communicate directly
                                              ?

                                              Does it mean that they
                                              have no relationships at
                                              all, besides the one way
                                              trust relationship
                                              mentioned in slide 7 ?

                                          
So
                                              it hard to say whether
                                              these two slides are
                                              indeed meaning that there
                                              is no bilateral
                                              relationship between an
                                              authorization server and a
                                              resource server.

                                        

                                      

                                      

                                        

                                          
Apologies
                                            for not providing an
                                            explanation on the slides.

                                        

                                        

                                          
 

                                        

                                        

                                          
Slide 7
                                            shows that trust between the
                                            AS and PR (now RS) was
                                            unidirectional, from the RS
                                            to the AS.

                                        

                                        

                                          
Slide 8
                                            indicates that trust is not
                                            bidirectional.

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                          
[Denis] 
                              ... which means that slide 8 contradicts
                              slide 7.  :-) 

                        

                      

                      

                        
 

                      

                      

                        
Slide 8 says it does not go
                          both ways. Slide 7 says it goes one way. I
                          don't see the contradiction. 

                      

                      

                        

                          
I
                              would have preferred that you meant: the
                              RS and the AS never communicate directly,
                              which is indeed a nice property to follow
                              

                              to ensure the user's privacy.

                        

                      

                      

                        
That is one model. Other
                          models are appropriate in other
                          circumstances..

                      

                      

                        
 

                      

                      

                        

                          
 

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
There is
                                            no limit on how many ASs an
                                            RS may trust.

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                          
[Denis]
                              This is fine.

                          

                            

                              

                                

                                  

                                    

                                      

                                        
 On
                                            June 12, Nat Sakimura
                                            recently answered to an
                                            email with the following
                                            topic:

                                      

                                      

                                        

                                          

                                            
Re:
                                                [OAUTH-WG] Comments on
                                                draft-ietf-oauth-jwsreq-22
                                                (The OAuth 2.0
                                                Authorization Framework:
                                                JWT Secured
                                                Authorization Request))

                                          

                                          
My
                                              arguments were:

                                          
    
                                              The original model for
                                              OAuth was making the
                                              assumption that the AS and
                                              the RS had a strong
                                              bilateral relationship.

                                            

                                                  A
                                                key question is whether
                                                such strong relationship
                                                will be maintained for
                                                ever or
                                            

                                                
                                              whether it will be allowed
                                              to perform some evolutions
                                              of this relationship.

                                            

                                                
                                              In order to respect the
                                              privacy of the users,
                                              there is the need to
                                              encompass other scenarios.
                                              One of these scenarios is
                                              that the AS and the RS 

                                                
                                              do not need any longer to
                                              have such a strong
                                              relationship. In terms of
                                              trust relationships, a RS
                                              simply needs to trust the
                                              access tokens issued by an
                                              AS. 

                                                
                                              The AS does have any more
                                              a "need to know" of all
                                              the RSs that are accepting
                                              its access tokens. This
                                              would be a major
                                              simplification of the
                                              current global
                                              architecture.

                                          
Nat's
                                              position was: 

                                          

                                            
"My
                                                take is that the basic
                                                assumption of OAuth 2.0
                                                Framework is that there
                                                is a strong relationship
                                                between AS and RS. 

                                                I feel that it is quite
                                                unrealistic that an RS
                                                would trust the access
                                                token issued by an AS
                                                that it has no strong
                                                relationship with".

                                          

                                          
There
                                              are indeed different
                                              positions on this topic. 
                                            

                                        

                                      

                                      

                                        
 

                                      

                                      

                                        
I don't
                                          think Nat and I have different
                                          opinions, but I will let Nat
                                          clarify.

                                      

                                      

                                        
Just
                                          because there is a strong
                                          relationship between the AS
                                          and RS, does not mean it is
                                          bidirectional. I would
                                          understand 

                                      

                                      

                                        
 

                                      

                                      

                                        
"I feel
                                          that it is quite unrealistic
                                          that an RS would trust the
                                          access token issued by an AS
                                          that it has no strong
                                          relationship with"

                                      

                                      

                                        
 

                                      

                                      

                                        
to indicate
                                          Nat is expecting the trust to
                                          be from the RS to the AS.

                                      

                                    

                                  

                                

                              

                            

                          

                          
[Denis] 
                              Speaking of a "strong relationship" is
                              ambiguous. The key point being whether the
                              relationship is unilateral or bilateral.

                              There is no need to use the wording
                              "strong relationship" when the
                              relationship is only unilateral: a RS
                              simply trusts an AS for the access tokens
                              it issues. 

                              In such a case, this does not mean that an
                              AS is knowing all the RSs that are
                              trusting it.

                          
On
                              the contrary, a strong (bi-)relationship
                              is when a RS and an AS both agree between
                              them about the meaning of scope
                              parameters.

                              This is a typical case for OAuth 2.0.

                        

                      

                      

                        
You can ask Nat what he
                          meant by "strong relationship"

                      

                      

                        
 

                      

                      

                        
The AS is stating what a
                          scope means to it and the user.. The RS can do
                          whatever it wants. I don't see that as
                          requiring a bidirectional relationship.

                      

                      

                        
 

                      

                      

                        
 

                      

                      

                        
 

                      

                      

                        

                          
 

                          

                            

                              

                                

                                  

                                    

                                      
 

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
The AS may not even know who the RS
                                                      (or PR in the
                                                      slides) is.

                                                

                                                

                                                  
 

                                                

                                                

                                                  
<snip> 

                                                

                                                

                                                  

                                                    

                                                      


                                                          I got rid of
                                                          the word
                                                          "delegation":
                                                          the client
                                                          does not
                                                          delegate
                                                          anything to an
                                                          authorization
                                                          server. If it
                                                          would, this
                                                          would mean
                                                          that the
                                                          authorization
                                                          server 

                                                          would be able
                                                          to act as the
                                                          client and
                                                          could know
                                                          everything
                                                          that the
                                                          client will
                                                          do, which
                                                          comes into
                                                          contradiction
                                                          with the
                                                          user's
                                                          privacy.

                                                    

                                                  

                                                

                                                

                                                  
 

                                                

                                                

                                                  
The above is not true.

                                                

                                                

                                                  
 

                                                

                                                

                                                  
The Resource Owner is delegating
                                                      access control to
                                                      the AS in
                                                      authorization use
                                                      cases.

                                                

                                              

                                            

                                          

                                          
The
                                              OAuth 2.0 model does not
                                              mandate any more the
                                              presence of a Resource
                                              Owner.

                                        

                                      

                                      

                                        
 

                                      

                                      

                                        
Why do you
                                          say that? The RO is who owns
                                          the RS. Your statement does
                                          not make sense.

                                      

                                    

                                  

                                

                              

                            

                          

                          
[Denis] 
                              I mean that there is not necessarily a
                              protocol defined so that the RO can
                              interact with the requests from the
                              clients.

                        

                      

                      

                        
Is the RO the User? In
                          consumer use cases it usually is, and the RO
                          is using the client. I'm not sure what you
                          scenario you are describing

                      

                      

                        
 

                      

                      

                        

                          
 

                          

                            

                              

                                

                                  

                                    

                                      

                                        
 

                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
 

                                                

                                                

                                                  
The client is may be delegating
                                                      user
                                                      authentication to
                                                      the AS in identity
                                                      claim use cases.

                                                

                                              

                                            

                                          

                                          
Delegating
                                              user authentication to the
                                              AS is different from
                                              delegating access control
                                              to the AS.

                                        

                                      

                                      

                                        
 

                                      

                                      

                                        
Agreed.
                                          Your statement was there was
                                          no delegation. I'm explaining
                                          there are potentially two
                                          delegations. 

                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
 

                                                

                                                

                                                  
The AS can act as the client in
                                                      many OAuth
                                                      deployments, as
                                                      the access token
                                                      is a bearer token.
                                                    

                                                

                                              

                                            

                                          

                                          
A
                                              bearer token is rather
                                              insecure.

                                        

                                      

                                      

                                        
Cookies are
                                          also bearer tokens. But we use
                                          them all the time in web apps
                                          for storing session state and
                                          prior authentication! :)

                                      

                                      

                                        
 

                                      

                                      

                                        
 

                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
That does not mean the AS knows
                                                      what the client is
                                                      doing. 

                                                

                                              

                                            

                                          

                                          
There
                                              are currently two attempts
                                              in the OAuth WG to let
                                              know to the AS what the
                                              client is doing:

                                          
    
                                            
  •  draft-ietf-oauth-jwsreq-22   (The
                                                OAuth 2.0 Authorization
                                                Framework: JWT Secured
                                                Authorization Request)
    • 
                                            
  •  draft-ietf-oauth-rar-01        
                                                (OAuth 2.0 Rich
                                                Authorization Requests)
    • 
                                          

                                        

                                      

                                      

                                        
Those are
                                          optional, and in some
                                          situations are a desired
                                          property.

                                      

                                    

                                  

                                

                              

                            

                          

                          
[Denis] 
                              However, in these two drafts, the privacy
                              considerations sections are silent on this
                              point.

                        

                      

                      

                        
There are lots of missing
                          details in both drafts! Security
                          considerations, error messages etc.

                      

                      

                        
 

                      

                      

                        
I think pretty much
                          everyone is onboard supporting privacy, but
                          not all use cases have the same privacy
                          considerations.

                      

                      

                        
 

                      

                      

                        
/Dick

                      

                    

                  

                

              

            

            


            

          

        

      

    

    


    

  


--------------5C0DF65D021A32FAB4B12586--


From nobody Mon Jul  6 09: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 134A93A16A4 for ; Mon,  6 Jul 2020 09:40:22 -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 wlUH3QNArLwg for ; Mon,  6 Jul 2020 09:40:20 -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 6650C3A09B7 for ; Mon,  6 Jul 2020 09:40:20 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id q74so16460830iod.1 for ; Mon, 06 Jul 2020 09:40:20 -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=wcragi44knsMYMDHma8iJPCSHwLwcnWfdj79xloMWmk=; b=ZqQltmrpDVEPQLBiDrhQSq2uys04ym8L2VhYv/zyk4RbWyqy3axWUJHG15AanaCglK Rz4n0lYbGTv0jxHPWq1SltMP69JH7mYj3l63ti/NlezCVJP63L1byJI9yPQsBUFlgYKi gWZE6Cdnh+ALs5EdDiN0f9f30RijCZT6CIk9bgIP9IWn6qwIlZYSc9+0yRdLvOxCh2Jz dJtiJKXrti+MBqgITwOeKIPF00rZQBkjzsfW8pJ3jipUBzU0G7ctEbKK5IIAzuDdxD6f 6ulSXKX9zZRNM7dC8g+wFI8aS2ayN3+HGKhzs7tnoH//0xCue8tA241T5KoOMdyglubK +sgw==
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=wcragi44knsMYMDHma8iJPCSHwLwcnWfdj79xloMWmk=; b=Wn+hD7mAWyS6UJVDzhdXOMg9IdXhmQOGyw0+gFxqGtPnZVeAFxqvJnpsSUd+Tuai7Z GERg8/c/pxo0NTt5tvC/YFiXWLUwUnVSfx6boOiqJfyEfsJjwDFDsJyUMJjivwYYQa4m JzNxv2R8vR0ca8bQD/uuXoK2eKgYSeSiqkoo4DYkB6zzjalb5praqCqjp7eCtrVrXkHv Fnw/7PCm3qCefSltwiHV+YriVi2EHxVHLBZcyWxSBWALU2icVEYrOk8aW8MuSBLQg8dE 28gbBVxKKrbaXDnZ+Xjabszi/7KiiTMybvzSaWHrhTWPvMnCtajjQ7fppNEqYkU86/OL wyHw==
X-Gm-Message-State: AOAM531+MwlAVauCS01lnB0S6KQr3PKAdjBosmV8L5orYtwU6XLcYFKK erclgEu54pRl9/c80RB14w2EQiNWgC6iD7uowHU=
X-Google-Smtp-Source: ABdhPJyZ2uQXgwJ3bBLyg+KQmXpWVFiJiClJHg0yJWS7bMnSSVw2lOj/40RNaNUSWhUGFCLEYIIDjEfsXUX6xfhf3Bg=
X-Received: by 2002:a05:6602:2207:: with SMTP id n7mr25788252ion.162.1594053619787;  Mon, 06 Jul 2020 09:40:19 -0700 (PDT)
MIME-Version: 1.0
References:        <20200705225343.GQ16335@kduck.mit.edu>  
In-Reply-To: 
From: Fabien Imbault 
Date: Mon, 6 Jul 2020 18:40:05 +0200
Message-ID: 
To: Dick Hardt 
Cc: Benjamin Kaduk , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c2aa4705a9c887ca"
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 06 Jul 2020 16:40:22 -0000

--000000000000c2aa4705a9c887ca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dick,

Yes, when that's ready I'll share some examples (but again, we don't intend
to ignite lengthy debates, see previous answer -> let's keep it as an aside
experiment, as food for thought).

As for macaroons, it's used quite extensively in production within some
blockchain implementations (lightning for instance) and on our side we have
a variant without a shared secret. But here again, we don't need to discuss
that further, as long as we allow for the possibility to use other types
than JWT (which we use also of course).

Thanks.

Fabien


Le lun. 6 juil. 2020 =C3=A0 18:13, Dick Hardt  a =C3=
=A9crit :

> Fabien: it would be interesting to see how you think JSON-LD could be use=
d
> in the protocol if you have some ideas on that. In XAuth, I am explicit
> that there are different formats / schema for tokens and claims. There is
> no default, so it is clear how additional formats can be requested and
> returned.
>
> Ben: I think that token formats such as macaroons are out of scope of
> GNAP, or at least the core protocol. The key feature of macaroons is the
> ability to further restrict the authorization. An interesting idea, but
> depends on a shared secret, and I have not heard of deployments. In a qui=
ck
> google on macaroons, I came across this talk from Gopher Con
> https://about.sourcegraph.com/go/gophercon-2018-an-over-engineering-disas=
ter-with-macaroons
> .
>
> Justin: good to see we are on the same page on all your points. I'd add
> that we should consider what JSON is used in the protocol to minimize or
> eliminate any impedance mismatch between JSON and CBOR.
>
> /Dick
>
> On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault 
> wrote:
>
>> Writing too fast, with an iteration of unrelated examples, did not conve=
y
>> the right message. Sorry if it wasn't clear and confusing. We indeed nee=
d
>> to differentiate between bearer tokens (e.g. JWT, macaroons or even simp=
le
>> cookies, etc.) and identity claims (e.g. OIDC claims, linked data proofs=
,
>> etc.).
>> I only wanted to say that we need to take into account that there might
>> be a variety of formats defined elsewhere. Not only OIDC (for claims) + =
JWT
>> (for access tokens).
>>
>> Regarding JWT vs macaroons : I would say that JWT are additive, while
>> macaroons are organized around caveats (so they're subtractive in a sens=
e).
>> But indeed they are both used in similar settings.
>>
>> Hope that clarifies.
>> Fabien
>>
>> On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk  wrote:
>>
>>> Hi Dick, Fabien,
>>>
>>> Just to clarify on one point, and check whether I'm confused:
>>>
>>> On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:
>>> > On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault <
>>> fabien.imbault@gmail.com>
>>> > wrote:
>>> >
>>> > > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt 
>>> wrote:
>>> > >
>>> > >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <
>>> fabien.imbault@gmail.com>
>>> > >> wrote:
>>> >
>>> > >
>>> > >> Just like OAuth 2.0, the access token is opaque to the client, and
>>> it is
>>> > >> not specified, so I'm confused what you mean by "other types of
>>> tokens than
>>> > >> JWT"?
>>> > >>
>>> > >> FI : I mean, for instance, linked data proofs, macaroons, and so o=
n.
>>> > >
>>> >
>>> > I see. When I read 'token', I think of access tokens. You are
>>> referring to
>>> > what I would call a claims, which per above are defined somewhere els=
e.
>>>
>>> My understanding was that macaroons, at least, were complete tokens tha=
t
>>> incorporate (at least by reference) multiple claims.  So a macaroon and=
 a
>>> JWT would be analogous in that sense (container holding many claims).
>>> I'm
>>> not sure whether the same holds for a linked data proof (or if it's jus=
t
>>> a
>>> way to represent a single claim), though.
>>>
>>> Am I confused?
>>>
>>> Thanks,
>>>
>>> Ben
>>>
>>

--000000000000c2aa4705a9c887ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Dick,

Yes=
, when that's ready I'll share some examples (but again, we don'=
;t intend to ignite lengthy debates, see previous answer -> let's ke=
ep it as an aside experiment, as food for thought).=C2=A0

As for macaroons, it's used quite ext=
ensively in production within some blockchain implementations (lightning fo=
r instance) and on our side we have a variant without a shared secret. But =
here again, we don't need to discuss that further, as long as we allow =
for the possibility to use other types than JWT (which we use also of cours=
e).=C2=A0

Thanks.=C2=A0<=
/div>

Fabien=C2=A0

Le lun. 6 juil. 2020 =C3=A0 18:13, Dick Hardt <dick.hardt@gmail.com> a =C3=A9crit=C2=A0:
Fabien: it would be interesting to see how you think JSON-LD coul=
d be used in the protocol if you have some ideas on that. In XAuth, I am ex=
plicit that there are different formats / schema for tokens=C2=A0and claims=
. There is no default, so it is clear how additional formats can be request=
ed and returned.

Ben: I think that token formats such as=
 macaroons are out of scope of GNAP, or at least the core protocol. The key=
 feature of macaroons is the ability to further restrict the authorization.=
 An interesting idea, but depends on a shared secret, and I have not heard =
of deployments. In a quick google on macaroons, I came across this talk fro=
m Gopher Con=C2=A0https://about.sourcegraph.com/go/gophercon-2018-an-over-engineerin=
g-disaster-with-macaroons.

Justin: good to see=
 we are on the same page on all your points. I'd add that we should con=
sider what JSON is used in the protocol to minimize or eliminate any=C2=A0i=
mpedance=C2=A0mismatch between JSON and CBOR.

/Dic=
k

On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault <fabien.imbau=
lt@gmail.com> wrote:
Writing too fast, with an iteration of unrelat=
ed examples, did not convey the right message.=C2=A0Sorry if it wasn't =
clear and confusing. We indeed need to differentiate between bearer tokens =
(e.g. JWT, macaroons or even simple cookies, etc.) and identity claims (e.g=
. OIDC claims, linked data proofs, etc.).
I only wanted to sa=
y that we need to take into account that there might be a variety of format=
s defined elsewhere. Not only OIDC (for claims) + JWT (for access tokens).<=
/div>
=C2=A0
Regarding JWT vs macaroons : I would say t=
hat JWT are additive, while macaroons are organized around caveats (so they=
're subtractive in a sense). But indeed they are both used in similar s=
ettings.=C2=A0

Hope that clarifies.
Fabien

On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk <kaduk@mit.ed=
u> wrote:
Hi Dick, Fabien,



Just to clarify on one point, and check whether I'm confused:



On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:

> On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault <fabien.imbault=
@gmail.com>

> wrote:

> 

> > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt <dick.hardt@gmail.=
com> wrote:

> >

> >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <fabi=
en.imbault@gmail.com>

> >> wrote:

> 

> >

> >> Just like OAuth 2.0, the access token is opaque to the client=
, and it is

> >> not specified, so I'm confused what you mean by "oth=
er types of tokens than

> >> JWT"?

> >>

> >> FI : I mean, for instance, linked data proofs, macaroons, and=
 so on.

> >

> 

> I see. When I read 'token', I think of access tokens. You are =
referring to

> what I would call a claims, which per above are defined somewhere else=
.



My understanding was that macaroons, at least, were complete tokens that
incorporate (at least by reference) multiple claims.=C2=A0 So a macaroon an=
d a

JWT would be analogous in that sense (container holding many claims).=C2=A0=
 I'm

not sure whether the same holds for a linked data proof (or if it's jus=
t a

way to represent a single claim), though.



Am I confused?



Thanks,



Ben








--000000000000c2aa4705a9c887ca--


From nobody Mon Jul  6 09:48: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 7E26F3A171A for ; Mon,  6 Jul 2020 09:48:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 fZ8MrCuGAHw5 for ; Mon,  6 Jul 2020 09:48:29 -0700 (PDT)
Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (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 49F7D3A170E for ; Mon,  6 Jul 2020 09:48:28 -0700 (PDT)
Received: by mail-ot1-x341.google.com with SMTP id g37so8416579otb.9 for ; Mon, 06 Jul 2020 09:48:28 -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=5POpSShotbiYh1uOLD0Ggx78DNNP1HmhltRPXWUExp8=; b=MK4sxjJP+B+5LALzAnqb+bvriFBNnNoK5ONyZmbScn7O0DToNQbvF8vJzxqZKIUpRL 4kvG+m5NOrJPx82WWUTyOpjLVdu6Ge7CqLPnE0/L5tLIFtjPiKAAjoK4Mj7zMkOh8pYQ fq6OUFZY7mIFuPzghWB4eQSJtvESfsAUJF1maEHpAU+raek5LLavbKzLs3oaaUk6EaIm Sgg2XMyu6x+NcFGxKW0CnG80TGxtxgQIdjOtEidS0P110pf9E7nOtm0RRiMPIxFCXgxh rFp6CKjni6kVM4WEaaPbfnBofHCxSxwyxBlKE0CeMiKmmla5CZFBMj8uxnB1N73eWpjJ xnZg==
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=5POpSShotbiYh1uOLD0Ggx78DNNP1HmhltRPXWUExp8=; b=Ju7Ca85GV2vCaiY9hezp8xecKSZTxmLq7HIa4oC2RT8591/BZNSZiotAplwYD+DTd7 Qwh7//y/fdb96Efov/jwlQJY3/9gGH+8IhuaM22rPzCuYjWvjV89s4N6MY9YexoCM/Me SwaIYmWFa3olO836lIuHkgqVqujsZPTEiGTxD8X65j2zdtPJFezEC9M5iyIYk+rH13yh KFR3b8h+HbBPFWBr/alA0W36VLDulq1El9W3T2191KX/8BKt/DWX+LabKjzdl4PjRE3z DOHbmIF8HCndPCZNRN+l3bjNvjKyrLrkjpXihYG7dO9Nglvmeev6oypg4x6UDfbcV8wn Unyg==
X-Gm-Message-State: AOAM533/qDPLah0bQWkWMw/rotqXGCOTt4xRThWbkwgMJOWkcCXyIpkh sTDahA5nXdHTnXUD3wnkVY2XXxtGoPOPntRcf+rraQ==
X-Google-Smtp-Source: ABdhPJy00+TQBOiH6vD/QKEW/qowNFcVjVAyQSa/J40p6vvG+m6H8xhIxegST9hh1+7VuLDUYtTsC+cWwI2R6GJg2Gg=
X-Received: by 2002:a9d:2661:: with SMTP id a88mr42901645otb.74.1594054108029;  Mon, 06 Jul 2020 09:48:28 -0700 (PDT)
MIME-Version: 1.0
References:   <3b8d3690-47e2-ff00-1065-29647d18555b@readycomputing.com>  <00827624-7361-4c5f-b34f-0edc8f7493dc@readycomputing.com>  <5AA3C0D4-A250-4EFB-B3E9-F71E8BD959A6@mit.edu> <7d8f8a78-01c9-ec27-b5d3-d03b7fb9a159@readycomputing.com>
In-Reply-To: <7d8f8a78-01c9-ec27-b5d3-d03b7fb9a159@readycomputing.com>
From: Steinar Noem 
Date: Mon, 6 Jul 2020 18:48:16 +0200
Message-ID: 
To: David Pyke 
Cc: Justin Richer , Tom Jones ,  txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000dcc00005a9c8a4f5"
Archived-At: 
Subject: Re: [Txauth] Possible Use Case for GNAP
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, 06 Jul 2020 16:48:32 -0000

--000000000000dcc00005a9c8a4f5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey, we have some (sort of) similar cases and requirements today which we
have solved by implementing the token-exchange spec.
It certainly doesn=E2=80=99t solve all the issues discussed here, but for
traceability it does the job for us. Being able to express an
=E2=80=9Cauthorization stack-trace=E2=80=9D and the original user identity =
is both useful
and required  in our case.

-Steinar

man. 6. jul. 2020 kl. 16:34 skrev David Pyke :

> Those are exactly the issues I was facing.  While I can make the hops
> independent, they need to be chained so that everything is traceable.
> It's possible but ugly with OAuth.
> On 2020-07-02 3:34 p.m., Justin Richer wrote:
>
> If we look at each hop as a separately authorized request, could we defin=
e
> them in a way that they=E2=80=99re chained from each other down the line?=
 Maybe it
> would be possible for the root HIN to get a new token for each of the
> downstream HINs, but this new token is in the context of the first one
>
> --
>
> *David Pyke*
>
> Manager, Strategic Consulting
>
>
> -------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------
>
> [image: Logo] 
>
> [image: LinkedIn icon] =
 [image:
> Twitter icon]  [image:
> Youtbue icon] 
>
> Office: +1 212 877 3307 x5001
>
> * david.pyke@readycomputing.com *
>
> * www.readycomputing.com *
>
> 150 Beekman Street, Floor 3, New York, NY 10038
> 
>
> The information in this e-mail communication together with any attachment=
s
> is intended only for the person or entity to which it is addressed and ma=
y
> contain confidential and/or privileged material. If you are not the
> intended recipient of this communication, please notify us immediately. A=
ny
> views expressed in this communication are those of the sender, unless
> otherwise specifically stated. Ready Computing does not represent, warran=
t
> or guarantee that the integrity of this communication has been maintained
> or the communication is free of errors, virus or interference.
>
> This is not a secure transmission. The information contained in this
> transmission is highly prohibited from containing privileged and
> confidential information, including patient information protected by
> federal and state privacy laws. It is intended only for the use of the
> person(s) named above. If you are not the intended recipient, you are
> hereby notified that any review, dissemination, distribution, or
> duplication of this communication is strictly prohibited. If you are not
> the intended recipient, please contact the sender by reply email and
> destroy all copies of the original message. --
> 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 |

--000000000000dcc00005a9c8a4f5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey, we have some (sort of) similar cases and requir=
ements today which we have solved by implementing the token-exchange spec.=
=C2=A0
It certainly doesn=E2=80=99t solve all the is=
sues discussed here, but for traceability it does the job for us. Being abl=
e to express an =E2=80=9Cauthorization stack-trace=E2=80=9D and the origina=
l user identity is both useful and required =C2=A0in our case.

-Steinar

man. 6. jul. 2020=
 kl. 16:34 skrev David Pyke <david.pyke=3D40readycomputing.com@dmarc.ietf.org>:

 =20
   =20
 =20
  

    
Those are exactly the i=
ssues I was facing.=C2=A0 While
        I can make the hops independent, they need to be chained so that
        everything is traceable.=C2=A0=C2=A0 It's possible but ugly wit=
h OAuth.

    

    
On 2020-07-02 3:34 p.m., Justin Richer
      wrote:

    

    
If we look
      at each hop as a separately authorized request, could we define
      them in a way that they=E2=80=99re chained from each other down the l=
ine?
      Maybe it would be possible for the root HIN to get a new token for
      each of the downstream HINs, but this new token is in the context
      of the first one

    
-- 

     =20
     =20
     =20
     =20
      

        

          
            

              
                

                  David Pyke<=
/b>

              		
            

            

              
                

                  Manag=
er,
                    Strategic Consulting

              		
            

            

              
                
 ----------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
------------------------------------------------

              		
            

            

              
                

                  3D"Logo"

                

                  3D"LinkedIn 3D"Twitter 3D"Youtbue

              		
              
                
Office=
:
                    +1 212 877 3307 x5001

                

                  
                    

                      
                        

                          
                                david.pyke@readycomputing.com

                        

                          
                                www.readycomputing.com

                      		
                    

                    

                      
                        
150
                            Beekman Street, Floor 3, New York, NY 10038=


                      		
                    

                    

                      

                      		
                    

                  
                

              		
            

            

              
                

                  The
                    information in this e-mail communication together
                    with any attachments is intended only for the person
                    or entity to which it is addressed and may contain
                    confidential and/or privileged material. If you are
                    not the intended recipient of this communication,
                    please notify us immediately. Any views expressed in
                    this communication are those of the sender, unless
                    otherwise specifically stated. Ready Computing does
                    not represent, warrant or guarantee that the
                    integrity of this communication has been maintained
                    or the communication is free of errors, virus or
                    interference.

              		
            

          
        

      

    

  





This is not a secure transmission. The information contained in this=20
transmission is highly prohibited from containing privileged and=20
confidential information, including patient information protected by=20
federal and state privacy laws. It is intended only for the use of the=20
person(s) named above. If you are not the intended recipient, you are=20
hereby notified that any review, dissemination, distribution, or=20
duplication of this communication is strictly prohibited. If you are not
 the intended recipient, please contact the sender by reply email and=20
destroy all copies of the original message.
                       -- 

Txauth mailing list

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


-- 
<=
div style=3D"color:rgb(80,0,80)">Vennli=
g hilsen

Steinar Noem
Partner Udelt AS
Systemutv=
ikler
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@u=
delt.no=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.=
udelt.no=C2=A0|=C2=A0


--000000000000dcc00005a9c8a4f5--


From nobody Mon Jul  6 09:59: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 1DA993A17E8; Mon,  6 Jul 2020 09:59: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 oFfsc17XxSA2; Mon,  6 Jul 2020 09:58:59 -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 CAFDE3A1809; Mon,  6 Jul 2020 09:58:58 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id q4so10548872lji.2; Mon, 06 Jul 2020 09:58:58 -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=OeyxxEsbbBTtRX7fNeYuixV4JY4+4XZLSMvVf9QGyNU=; b=WFSp9/y6PZuLsIVj3BhitEK6AvUo3GpDDivSpqgZkj9LKk+uNpLYL2k1JitV75p5tR uAwB/uD6nfIFYY7FQWXTTURveE6AaBcJ5Ji18n6GKIEAWL5caw1Vam1aGuA7BumrQZWW 3RHgb1ZOLK7JnBSOEAXkr13Otz4V0ak+25YFS3kig3I3ZrQNuClSgC1+RH4Xxz83xNsj 2Uhu2YdJmbXLHfpyb1db/N4PnNVmd/9VVMk/p4zFliWNPU+dx4sDI070N2aGDEGsOSXV s15vWYrnJ1ZCmgz4mLYax6AX5N7hN1AGx5q70EMOhq3EcVGAEA69lsuo1Qbq5vvKmdHV UktA==
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=OeyxxEsbbBTtRX7fNeYuixV4JY4+4XZLSMvVf9QGyNU=; b=Uj2bjHQnZNRJOhidOSGIYm+bfo9G5y/hQUO5xsdbW75hOrpremUfimUgIuEqb1jJCl w1TTTDTmwxwDpHs/Wpcl/5J0LtuNbpqLAdL7NNiRcJhgczcUXmQaXYQ/pLx/iXBpfKS0 +hqESsmdIz8a49kxWRrNPu3TOwPKRaQeqzh2aI9+/SfQ9GeCou6NBPVyx2cH9GiTaFgw HazIrA16IcTt6voqqo1USWXBeNDIGqelcIGvXkGLJBAPCxoEReDiLh1v01WSEgScIWxv Rl31XZKghGh/tOQ5QoEB57D+v2wi2X/TgSk7YpI682+PpQczx1wFEOMMFkYmznYFAaI3 502Q==
X-Gm-Message-State: AOAM5324VsxFKcpFQ9tW2NMtQeBJggWhHDp8ablfeiQXag5yl0qE8NLu Gj/0mUQayAXiZOgcTlHnpm5FbA2LDAxPmhE/k1co8Pqf
X-Google-Smtp-Source: ABdhPJyPJSV3fRLVk4XDsSZxFBRmExHyyM0V4r0S/s2kL4nTGgJvu1dofMwQhAoBAZs9r4iyVeMtAegc4GF2QN6yxDw=
X-Received: by 2002:a2e:900a:: with SMTP id h10mr29375886ljg.242.1594054736725;  Mon, 06 Jul 2020 09:58:56 -0700 (PDT)
MIME-Version: 1.0
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com>     <3c21e0fa-5636-54fe-675f-abc5b41ab09e@free.fr>  <731a364a19a74e1d982d59d9c441dc0a@cert.org>   <354edabf-d9d5-1318-403f-866043e8d0a6@free.fr>
In-Reply-To: <354edabf-d9d5-1318-403f-866043e8d0a6@free.fr>
From: Dick Hardt 
Date: Mon, 6 Jul 2020 09:58:20 -0700
Message-ID: 
To: Denis 
Cc: Roman Danyliw , Nat Sakimura ,  "txauth@ietf.org" , The IESG 
Content-Type: multipart/alternative; boundary="00000000000055cc4205a9c8cabc"
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 06 Jul 2020 16:59:10 -0000

--00000000000055cc4205a9c8cabc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Security is not called out as a goal, but is a goal for ALL
implementations/deployments.

While privacy will be a goal for some implementations/deployments, it will
NOT be a goal for all. I think your suggested additions will constrain the
work.


On Mon, Jul 6, 2020 at 9:38 AM Denis  wrote:

> Hi Dick,
>
> Hi Denis
>
> Just like "privacy", "security" is not called out as a goal. (it is
> mentioned as an issue with OAuth 2.0).
>
> The word "security" appears once in the charter, but the word "privacy"
> does not appear.
>
> What goes well without saying, goes even better when you say it.
>
> Many features announced in the charter *prevent *to apply privacy
> principles.
> So it is easy to get the impression that the charter is considering that
> privacy is a non-goal.
>
> "Privacy by design" should be mentioned as well as "privacy by default".
> These two magic sentences are of utmost importance.
>
> Denis
>
>
> On Mon, Jul 6, 2020 at 8:49 AM Denis  wrote:
>
>> One single comment.
>>
>> Dick wrote on the last line:
>>
>> I think pretty much everyone is onboard supporting privacy, but not all
>> use cases have the same privacy considerations.
>>
>> I hope that this is true, but in such a case I can't understand why the
>> word "*privacy*" is missing in the charter.
>>
>> Denis
>>
>> Note: IESG added
>>
>> Hello!
>>
>>
>>
>> I=E2=80=99m top-posting here because there is no easy way for me to clea=
ning
>> insert my process comment.  I think we are having a necessary conversati=
on
>> below and in no way should it stop because of this note.
>>
>>
>>
>> As a process check, this thread started with a request for community
>> review on the charter text [1].  Among other things, this charter review=
 is
>> trying to ensure the problem is clear, defines the bounds of the desired
>> solutions and identifies critical objections from the consensus-derived
>> text.  The text is not intended to define detailed
>> requirements/architecture, resolve tradeoffs, or to specify a solution,
>> unless they are critical to bounding the solution.  These details should=
 be
>> left to future discussions of a chartered WG (not that they can=E2=80=99=
t start now
>> in parallel).  Additionally, as a reminder, while there are multiple
>> individual drafts with proposed solutions in the datatracker, the design
>> decisions they make are not part of the charter and their adoption is no=
t
>> assumed by the charter.  If there are key design elements in those or an=
y
>> other documents that is felt to be crucial to scoping the WG,  we need t=
o
>> capture the thinking, generalize it (as appropriate), and add it to the
>> charter text explicitly or by reference.
>>
>>
>>
>> Let=E2=80=99s continue to talk about the technical details of the use ca=
ses,
>> design properties, constraints and candidate solutions.  Additionally,
>> given the -05 charter text and milestones [2], it would be helpful to
>> understand what outstanding concerns remain with the charter text in
>> preparation for the Thursday, July 9th telechat where the IESG will use
>> community feedback to help decide the way ahead for this proposed WG.
>>
>>
>>
>> Roman
>>
>>
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/txauth/4nE8rtyRPtdk0FrclQ1c-FWMO8w=
/
>>
>> [2] https://datatracker.ietf.org/doc/charter-ietf-gnap/
>>
>>
>>
>>
>>
>>
>>
>> *From:* Txauth   *On
>> Behalf Of *Dick Hardt
>> *Sent:* Friday, July 3, 2020 9:41 PM
>> *To:* Denis  
>> *Cc:* Nat Sakimura  ;
>> txauth@ietf.org
>> *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization
>> Protocol (gnap)
>>
>>
>>
>> + Nat as he is mentioned
>>
>> - IESG
>>
>>
>>
>> On Fri, Jul 3, 2020 at 2:16 AM Denis  wrote:
>>
>> Hello Dick,
>>
>>
>>
>> Catching up on this email ... comments inserted ...
>>
>>
>>
>> On Mon, Jun 29, 2020 at 12:06 AM Denis  wrote:
>>
>> Hello Dick,
>>
>>
>>
>> Denis, thanks for sharing your thoughts, some clarifications on your
>> statements inserted:
>>
>>
>>
>> On Fri, Jun 26, 2020 at 9:42 AM Denis  wrote:
>>
>> 
>>
>> *New proposed charter*
>>
>> 
>>
>>
>> Resource servers inform their clients about which access token formats
>> are acceptable and depending upon the king of operation
>> that is requested, which kind of attributes are needed and from which AS=
s
>> that my be obtained.
>>
>> While at times this may be appropriate, at other times disclosing the
>> attributes the RS requires is not needed by the client.
>> For example, an enterprise client accessing a resource does not need to
>> know which groups a user belongs to,
>> but the RS may require that to determine if the user running the client
>> has access.
>>
>> As soon as there is a desire to implement privacy by default, the client
>> should not provide more attributes than strictly necessary.
>> Even after three readings of your example, I failed to understand it.
>>
>>
>> A major difference with OAuth 2.0 is that there is no bilateral trust
>> relationship between an authorization server and a resource server:
>> for a given category of attributes, a resource server may trust one or
>> more authorization servers. Another major difference with OAuth 2.0.
>> is that the content of an attributes token is meant to be accessible to
>> the client.
>>
>> This is not how OAuth 2.0 works. See slides 7 and 8 from my original IET=
F
>> presentation on what became OAuth 2.0
>>
>>
>>
>> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation
>>
>> I looked at the two slides.
>>
>> Unfortunately slide 7 has just one arrow with the word "trust". This is
>> insufficient to understand what is meant unless being present
>> at the presentation. Does it mean that the PR (RS) trusts one AS or that
>> it may trust multiple ASs ?
>>
>> Unfortunately slide 8 has just one arrow between the PR and the AS which
>> is red-crossed but no text at all. This is insufficient to understand
>> what is meant unless being present at the presentation. Does it mean tha=
t
>> the PR and the AS never communicate directly ?
>> Does it mean that they have no relationships at all, besides the one way
>> trust relationship mentioned in slide 7 ?
>>
>> So it hard to say whether these two slides are indeed meaning that there
>> is no bilateral relationship between an authorization server and a resou=
rce
>> server.
>>
>> Apologies for not providing an explanation on the slides.
>>
>>
>>
>> Slide 7 shows that trust between the AS and PR (now RS) was
>> unidirectional, from the RS to the AS.
>>
>> Slide 8 indicates that trust is not bidirectional.
>>
>> [Denis]  ... which means that slide 8 contradicts slide 7.  :-)
>>
>>
>>
>> Slide 8 says it does not go both ways. Slide 7 says it goes one way. I
>> don't see the contradiction.
>>
>> I would have preferred that you meant: the RS and the AS never
>> communicate directly, which is indeed a nice property to follow
>> to ensure the user's privacy.
>>
>> That is one model. Other models are appropriate in other circumstances..
>>
>>
>>
>>
>>
>> There is no limit on how many ASs an RS may trust.
>>
>> [Denis] This is fine.
>>
>>  On June 12, Nat Sakimura recently answered to an email with the
>> following topic:
>>
>> Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0
>> Authorization Framework: JWT Secured Authorization Request))
>>
>> My arguments were:
>>
>>      The original model for OAuth was making the assumption that the AS
>> and the RS had a strong bilateral relationship.
>>
>>       *A key question is whether such strong relationship will be
>> maintained for ever *or
>>      whether it will be allowed to perform some evolutions of this
>> relationship.
>>
>>      In order to respect the privacy of the users, there is the need to
>> encompass other scenarios. One of these scenarios is that the AS and the=
 RS
>>      do not need any longer to have such a strong relationship. In terms
>> of trust relationships, a RS simply needs to trust the access tokens iss=
ued
>> by an AS.
>>      The AS does have any more a "need to know" of all the RSs that are
>> accepting its access tokens. This would be a major simplification of the
>> current global architecture.
>>
>> Nat's position was:
>>
>> "My take is that the basic assumption of OAuth 2.0 Framework is that
>> there is a strong relationship between AS and RS.
>> I feel that it is quite unrealistic that an RS would trust the access
>> token issued by an AS that it has no strong relationship with".
>>
>> There are indeed different positions on this topic.
>>
>>
>>
>> I don't think Nat and I have different opinions, but I will let Nat
>> clarify.
>>
>> Just because there is a strong relationship between the AS and RS, does
>> not mean it is bidirectional. I would understand
>>
>>
>>
>> "I feel that it is quite unrealistic that an RS would trust the access
>> token issued by an AS that it has no strong relationship with"
>>
>>
>>
>> to indicate Nat is expecting the trust to be from the RS to the AS.
>>
>> [Denis]  Speaking of a "strong relationship" is ambiguous. The key point
>> being whether the relationship is unilateral or bilateral.
>> There is no need to use the wording "strong relationship" when the
>> relationship is only unilateral: a RS simply trusts an AS for the access
>> tokens it issues.
>> In such a case, this does not mean that an AS is knowing all the RSs tha=
t
>> are trusting it.
>>
>> On the contrary, a strong (bi-)relationship is when a RS and an AS both
>> agree between them about the meaning of scope parameters.
>> This is a typical case for OAuth 2.0.
>>
>> You can ask Nat what he meant by "strong relationship"
>>
>>
>>
>> The AS is stating what a scope means to it and the user.. The RS can do
>> whatever it wants. I don't see that as requiring a bidirectional
>> relationship.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> The AS may not even know who the RS (or PR in the slides) is.
>>
>>
>>
>> 
>>
>>
>> I got rid of the word "delegation": the client does not delegate anythin=
g
>> to an authorization server. If it would, this would mean that the
>> authorization server
>> would be able to act as the client and could know everything that the
>> client will do, which comes into contradiction with the user's privacy.
>>
>>
>>
>> The above is not true.
>>
>>
>>
>> The Resource Owner is delegating access control to the AS in
>> authorization use cases.
>>
>> The OAuth 2.0 model does not mandate any more the presence of a Resource
>> Owner.
>>
>>
>>
>> Why do you say that? The RO is who owns the RS. Your statement does not
>> make sense.
>>
>> [Denis]  I mean that there is not necessarily a protocol defined so that
>> the RO can interact with the requests from the clients.
>>
>> Is the RO the User? In consumer use cases it usually is, and the RO is
>> using the client. I'm not sure what you scenario you are describing
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> The client is may be delegating user authentication to the AS in identit=
y
>> claim use cases.
>>
>> Delegating user authentication to the AS is different from delegating
>> access control to the AS.
>>
>>
>>
>> Agreed. Your statement was there was no delegation. I'm explaining there
>> are potentially two delegations.
>>
>>
>>
>> The AS can act as the client in many OAuth deployments, as the access
>> token is a bearer token.
>>
>> A bearer token is rather insecure.
>>
>> Cookies are also bearer tokens. But we use them all the time in web apps
>> for storing session state and prior authentication! :)
>>
>>
>>
>>
>>
>> That does not mean the AS knows what the client is doing.
>>
>> There are currently two attempts in the OAuth WG to let know to the AS
>> what the client is doing:
>>
>>    - draft-ietf-oauth-jwsreq-22   (The OAuth 2.0 Authorization
>>    Framework: JWT Secured Authorization Request)
>>    - draft-ietf-oauth-rar-01         (OAuth 2.0 Rich Authorization
>>    Requests)
>>
>> Those are optional, and in some situations are a desired property.
>>
>> [Denis]  However, in these two drafts, the privacy considerations
>> sections are silent on this point.
>>
>> There are lots of missing details in both drafts! Security
>> considerations, error messages etc.
>>
>>
>>
>> I think pretty much everyone is onboard supporting privacy, but not all
>> use cases have the same privacy considerations.
>>
>>
>>
>> /Dick
>>
>>
>>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--00000000000055cc4205a9c8cabc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Security is not called out as a goal, but is a goal for AL=
L implementations/deployments.

While privacy will be a g=
oal for some implementations/deployments, it will NOT be a goal for all. I =
think your suggested additions will constrain=C2=A0the work.

=


On Mon, Jul 6, 2020 at 9:38 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hi Dick,

    

     =20
      
Hi Denis
        


        

        
Just like=C2=A0"privacy", "security" is no=
t called out as a
          goal. (it is mentioned as an issue with OAuth 2.0).

      

    

    
The word "security" appears once in the charter, but the w=
ord
      "privacy" does not appear.

    
What goes well without saying, goes even better when you say it.

    
Many features announced in the charter prevent to apply
      privacy principles.=C2=A0 

      So it is easy to get the impression that the charter is
      considering that privacy is a non-goal.

    
"Privacy by design" should be mentioned as well as "p=
rivacy by
      default". 

      These two magic sentences are of utmost importance.

    
Denis

    


      

        
On Mon, Jul 6, 2020 at 8:49 A=
M
          Denis <denis.ietf@free.fr> wrote:

        

        

          

            
One single comment.

            


            

            
Dick wrote on the last line:

            

              
I think pretty much everyone is onboard supporting
                privacy, but not all use cases have the same privacy
                considerations.

            

            
I hope that this is true, but in such a case I can't
              understand why the word "privacy" is missing=
 in the
              charter.

            


            

            
Denis

            


            

            
Note: IESG added

            


            

            

              

                
Hello!

                
=C2=A0

                
I=E2=80=99m top-posting here because=
 there
                  is no easy way for me to cleaning insert my process
                  comment.=C2=A0 I think we are having a necessary
                  conversation below and in no way should it stop
                  because of this note.

                
=C2=A0

                
As a process check, this thread
                  started with a request for community review on the
                  charter text [1].=C2=A0 Among other things, this charter
                  review is trying to ensure the problem is clear,
                  defines the bounds of the desired solutions and
                  identifies critical objections from the
                  consensus-derived text.=C2=A0 The text is not intended to
                  define detailed requirements/architecture, resolve
                  tradeoffs, or to specify a solution, unless they are
                  critical to bounding the solution.=C2=A0 These details
                  should be left to future discussions of a chartered WG
                  (not that they can=E2=80=99t start now in parallel).=C2=
=A0
                  Additionally, as a reminder, while there are multiple
                  individual drafts with proposed solutions in the
                  datatracker, the design decisions they make are not
                  part of the charter and their adoption is not assumed
                  by the charter.=C2=A0 If there are key design elements in
                  those or any other documents that is felt to be
                  crucial to scoping the WG, =C2=A0we need to capture the
                  thinking, generalize it (as appropriate), and add it
                  to the charter text explicitly or by reference.

                
=C2=A0

                
Let=E2=80=99s continue to talk about=
 the
                  technical details of the use cases, design properties,
                  constraints and candidate solutions.=C2=A0 Additionally,
                  given the -05 charter text and milestones [2], it
                  would be helpful to understand what outstanding
                  concerns remain with the charter text in preparation
                  for the Thursday, July 9th telechat where
                  the IESG will use community feedback to help decide
                  the way ahead for this proposed WG.

                
=C2=A0

                
Roman

                
=C2=A0

                
[1] 
https://mailarchive.ietf.org/arch/msg/txauth/4nE8rtyRPtdk0FrclQ1c-FWMO8w/

                
[2] 
                    https://datatracker.ietf.org/doc/charter-ietf-gnap/=


                
=C2=A0

                
=C2=A0

                
=C2=A0

                

                  

                    

                      
From: Txauth <txauth-bounces@ietf.=
org>
                        On Behalf Of Dick Hardt

                        Sent: Friday, July 3, 2020 9:41 PM

                        To: Denis <denis.ietf@free.fr>

                        Cc: Nat Sakimura <sakimura@gmail.com>;
                        txauth@ietf.org

                        Subject: Re: [Txauth] WG Review: Grant
                        Negotiation and Authorization Protocol (gnap)

                    

                  

                  
=C2=A0

                  

                    

                      
+ Nat as he is mentioned

                    

                    

                      
- IESG

                    

                    
=C2=A0

                    

                      

                        
On Fri, Jul 3, 2020 at 2:16
                          AM Denis <denis.ietf@free.fr>
                          wrote:

                      

                      

                        

                          

                            
Hello Dick,

                          

                          

                            
=C2=A0

                          

                          

                            

                              

                                

                                  

                                    

                                      
Catching up
                                        on this email ... comments
                                        inserted ...

                                    

                                    
=C2=A0

                                    

                                      

                                        
On Mon, Jun
                                          29, 2020 at 12:06 AM Denis
                                          <denis.ietf@free.fr>
                                          wrote:

                                      

                                      

                                        

                                          

                                            
Hello
                                                Dick,

                                          

                                          

                                            
=C2=A0
                                          

                                          

                                            

                                              

                                                
Denis, thanks for sharing your
                                                    thoughts, some
                                                    clarifications on
                                                    your statements
                                                    inserted:

                                              

                                              
=C2=A0=


                                              

                                                

                                                  
On Fri, Jun 26, 2020 at 9:42 AM
                                                      Denis <denis.ietf@free.fr> wro=
te:

                                                

                                                

                                                  
<snip>

                                                

                                                

                                                  

                                                    

                                                      

                                                        
New
                                                          proposed
                                                          charter

                                                      

                                                    

                                                  

                                                

                                                

                                                  
<snip>=C2=A0

                                                

                                                

                                                  

                                                    

                                                      

                                                        


                                                          Resource
                                                          servers inform
                                                          their clients
                                                          about which
                                                          access token
                                                          formats are
                                                          acceptable and
                                                          depending upon
                                                          the king of
                                                          operation

                                                          that is
                                                          requested,
                                                          which kind of
                                                          attributes are
                                                          needed and
                                                          from which ASs
                                                          that my be
                                                          obtained.<=
/p>
                                                      

                                                    

                                                  

                                                

                                                

                                                  
While at times this may be
                                                      appropriate, at
                                                      other times
                                                      disclosing the
                                                      attributes the RS
                                                      requires is not
                                                      needed by the
                                                      client. 

                                                      For example, an
                                                      enterprise client
                                                      accessing a
                                                      resource does not
                                                      need to know which
                                                      groups a user
                                                      belongs to, 

                                                      but the RS may
                                                      require that to
                                                      determine if the
                                                      user running the
                                                      client has access.

                                                

                                              

                                            

                                          

                                          
As
                                              soon as there is a desire
                                              to implement privacy by
                                              default, the client should
                                              not provide more
                                              attributes than strictly
                                              necessary. 

                                              Even after three readings
                                              of your example, I failed
                                              to understand it.

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        


                                                          A major
                                                          difference
                                                          with OAuth 2.0
                                                          is that there
                                                          is no
                                                          bilateral
                                                          trust
                                                          relationship
                                                          between an
                                                          authorization
                                                          server and a
                                                          resource
                                                          server: 

                                                          for a given
                                                          category of
                                                          attributes, a
                                                          resource
                                                          server may
                                                          trust one or
                                                          more
                                                          authorization
                                                          servers.
                                                          Another major
                                                          difference
                                                          with OAuth
                                                          2.0.

                                                          is that the
                                                          content of an
                                                          attributes
                                                          token is meant
                                                          to be
                                                          accessible to
                                                          the client.

                                                      

                                                    

                                                  

                                                

                                                

                                                  
This is not how OAuth 2.0 works.
                                                      See slides 7 and 8
                                                      from my original
                                                      IETF presentation
                                                      on what became
                                                      OAuth 2.0

                                                

                                                

                                                  
=
=C2=A0

                                                

                                                
                                              

                                            

                                          

                                          
I
                                              looked at the two slides.
                                             

                                          
Unfortunately
                                              slide 7 has just one arrow
                                              with the word "trust&quo=
t;.
                                              This is insufficient to
                                              understand what is meant
                                              unless being present 

                                              at the presentation. Does
                                              it mean that the PR (RS)
                                              trusts one AS or that it
                                              may trust multiple ASs ?

                                        

                                      

                                      

                                        

                                          
Unfortunately
                                              slide 8 has just one arrow
                                              between the PR and the AS
                                              which is red-crossed but
                                              no text at all. This is
                                              insufficient to understand
                                              what is meant unless being
                                              present at the
                                              presentation. Does it mean
                                              that the PR and the AS
                                              never communicate directly
                                              ?

                                              Does it mean that they
                                              have no relationships at
                                              all, besides the one way
                                              trust relationship
                                              mentioned in slide 7 ?=


                                          
So
                                              it hard to say whether
                                              these two slides are
                                              indeed meaning that there
                                              is no bilateral
                                              relationship between an
                                              authorization server and a
                                              resource server.

                                        

                                      

                                      

                                        

                                          
Apologies
                                            for not providing an
                                            explanation on the slides.

                                        

                                        

                                          
=C2=A0

                                        

                                        

                                          
Slide 7
                                            shows that trust between the
                                            AS and PR (now RS) was
                                            unidirectional, from the RS
                                            to the AS.

                                        

                                        

                                          
Slide 8
                                            indicates=C2=A0that trust is no=
t
                                            bidirectional.

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                          
[=
Denis]=C2=A0
                              ... which means that slide 8 contradicts
                              slide 7.=C2=A0 :-) 

                        

                      

                      

                        
=C2=A0

                      

                      

                        
Slide 8 says it does not go
                          both ways. Slide 7 says it goes one way. I
                          don't see the contradiction.=C2=A0

                      

                      

                        

                          
I
                              would have preferred that you meant: the
                              RS and the AS never communicate directly,
                              which is indeed a nice property to follow
                              

                              to ensure the user's privacy.

                        

                      

                      

                        
That is one model. Other
                          models are appropriate in other
                          circumstances..

                      

                      

                        
=C2=A0

                      

                      

                        

                          
=C2=A0

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
There is
                                            no limit on how many ASs an
                                            RS may trust.

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                          
[=
Denis]
                              This is fine.

                          

                            

                              

                                

                                  

                                    

                                      

                                        
=C2=A0On
                                            June 12, Nat Sakimura
                                            recently answered to an
                                            email with the following
                                            topic:

                                      

                                      

                                        

                                          

                                            
Re:
                                                [OAUTH-WG] Comments on
                                                draft-ietf-oauth-jwsreq-22
                                                (The OAuth 2.0
                                                Authorization Framework:
                                                JWT Secured
                                                Authorization Request))

                                          

                                          
My
                                              arguments were:

                                          
=C2=A0=C2=A0=C2=A0=C2=A0
                                              The original model for
                                              OAuth was making the
                                              assumption that the AS and
                                              the RS had a strong
                                              bilateral relationship.

                                            

                                            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
A
                                                key question is whether
                                                such strong relationship
                                                will be maintained for
                                                ever or
                                            

                                            =C2=A0=C2=A0=C2=A0=C2=A0
                                              whether it will be allowed
                                              to perform some evolutions
                                              of this relationship.<=
br>
                                            

                                            =C2=A0=C2=A0=C2=A0=C2=A0
                                              In order to respect the
                                              privacy of the users,
                                              there is the need to
                                              encompass other scenarios.
                                              One of these scenarios is
                                              that the AS and the RS 

                                            =C2=A0=C2=A0=C2=A0=C2=A0
                                              do not need any longer to
                                              have such a strong
                                              relationship. In terms of
                                              trust relationships, a RS
                                              simply needs to trust the
                                              access tokens issued by an
                                              AS. 

                                            =C2=A0=C2=A0=C2=A0=C2=A0
                                              The AS does have any more
                                              a "need to know" of=
 all
                                              the RSs that are accepting
                                              its access tokens. This
                                              would be a major
                                              simplification of the
                                              current global
                                              architecture.

                                          
Nat's
                                              position was: 

                                          

                                            
"My
                                                take is that the basic
                                                assumption of OAuth 2.0
                                                Framework is that there
                                                is a strong relationship
                                                between AS and RS. 

                                                I feel that it is quite
                                                unrealistic that an RS
                                                would trust the access
                                                token issued by an AS
                                                that it has no strong
                                                relationship with".

                                          

                                          
There
                                              are indeed different
                                              positions on this topic.=C2=
=A0
                                            

                                        

                                      

                                      

                                        
=C2=A0

                                      

                                      

                                        
I don't
                                          think Nat and I have different
                                          opinions, but I will let Nat
                                          clarify.

                                      

                                      

                                        
Just
                                          because there is a strong
                                          relationship between the AS
                                          and RS, does not mean it is
                                          bidirectional. I would
                                          understand=C2=A0

                                      

                                      

                                        
=C2=A0

                                      

                                      

                                        
"I feel
                                          that it is quite unrealistic
                                          that an RS would trust the
                                          access token issued by an AS
                                          that it has no strong
                                          relationship with"

                                      

                                      

                                        
=C2=A0

                                      

                                      

                                        
to indicate
                                          Nat is expecting the trust to
                                          be from the RS to the AS.

                                      

                                    

                                  

                                

                              

                            

                          

                          
[=
Denis]=C2=A0
                              Speaking of a "strong relationship"=
 is
                              ambiguous. The key point being whether the
                              relationship is unilateral or bilateral.

                              There is no need to use the wording
                              "strong relationship" when the
                              relationship is only unilateral: a RS
                              simply trusts an AS for the access tokens
                              it issues. 

                              In such a case, this does not mean that an
                              AS is knowing all the RSs that are
                              trusting it.

                          
O=
n
                              the contrary, a strong (bi-)relationship
                              is when a RS and an AS both agree between
                              them about the meaning of scope
                              parameters.

                              This is a typical case for OAuth 2.0.<=
/p>
                        

                      

                      

                        
You can ask Nat what he
                          meant by "strong relationship"

                      

                      

                        
=C2=A0

                      

                      

                        
The AS is stating what a
                          scope means to it and the user.. The RS can do
                          whatever it wants. I don't see that as
                          requiring a bidirectional relationship.

                      

                      

                        
=C2=A0

                      

                      

                        
=C2=A0

                      

                      

                        
=C2=A0

                      

                      

                        

                          
=C2=A0

                          

                            

                              

                                

                                  

                                    

                                      
=C2=A0

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
The AS may not even know who the=
 RS
                                                      (or PR in the
                                                      slides) is.
                                                

                                                

                                                  
=
=C2=A0

                                                

                                                

                                                  
<snip>=C2=A0

                                                

                                                

                                                  

                                                    

                                                      


                                                          I got rid of
                                                          the word
                                                          "delegation&=
quot;:
                                                          the client
                                                          does not
                                                          delegate
                                                          anything to an
                                                          authorization
                                                          server. If it
                                                          would, this
                                                          would mean
                                                          that the
                                                          authorization
                                                          server 

                                                          would be able
                                                          to act as the
                                                          client and
                                                          could know
                                                          everything
                                                          that the
                                                          client will
                                                          do, which
                                                          comes into
                                                          contradiction
                                                          with the
                                                          user's
                                                          privacy.
                                                    

                                                  

                                                

                                                

                                                  
=
=C2=A0

                                                

                                                

                                                  
The=C2=A0above is not true.

                                                

                                                

                                                  
=C2=A0

                                                

                                                

                                                  
The Resource Owner is delegating
                                                      access control to
                                                      the AS in
                                                      authorization use
                                                      cases.

                                                

                                              

                                            

                                          

                                          
The
                                              OAuth 2.0 model does not
                                              mandate any more the
                                              presence of a Resource
                                              Owner.

                                        

                                      

                                      

                                        
=C2=A0

                                      

                                      

                                        
Why do you
                                          say that? The RO is who owns
                                          the RS. Your statement does
                                          not make sense.

                                      

                                    

                                  

                                

                              

                            

                          

                          
[=
Denis]=C2=A0
                              I mean that there is not necessarily a
                              protocol defined so that the RO can
                              interact with the requests from the
                              clients.

                        

                      

                      

                        
Is the RO the User? In
                          consumer use cases it usually is, and the RO
                          is using the client. I'm not sure what you
                          scenario you are describing

                      

                      

                        
=C2=A0

                      

                      

                        

                          
=C2=A0

                          

                            

                              

                                

                                  

                                    

                                      

                                        
=C2=A0

                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
=
=C2=A0

                                                

                                                

                                                  
The client is may be delegating
                                                      user
                                                      authentication to
                                                      the AS in identity
                                                      claim use cases.

                                                

                                              

                                            

                                          

                                          
Delegating
                                              user authentication to the
                                              AS is different from
                                              delegating access control
                                              to the AS.

                                        

                                      

                                      

                                        
=C2=A0

                                      

                                      

                                        
Agreed.
                                          Your statement was there was
                                          no delegation. I'm explaining
                                          there are potentially=C2=A0two
                                          delegations.=C2=A0

                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
=
=C2=A0

                                                

                                                

                                                  
The AS can act as the client in
                                                      many OAuth
                                                      deployments, as
                                                      the access token
                                                      is a bearer token.
                                                    

                                                

                                              

                                            

                                          

                                          
A
                                              bearer token is rather
                                              insecure.

                                        

                                      

                                      

                                        
Cookies are
                                          also bearer tokens. But we use
                                          them all the time in web=C2=A0app=
s
                                          for=C2=A0storing session state=C2=
=A0and
                                          prior authentication! :)

                                      

                                      

                                        
=C2=A0

                                      

                                      

                                        
=C2=A0

                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
That does not mean the AS knows
                                                      what the client is
                                                      doing. 

                                                

                                              

                                            

                                          

                                          
There
                                              are currently two attempts
                                              in the OAuth WG to let
                                              know to the AS what the
                                              client is doing:

                                          
    
                                            
  •  draft-ietf-oauth-jwsreq-22=C2=A0=C2=
=A0 (The
                                                OAuth 2.0 Authorization
                                                Framework: JWT Secured
                                                Authorization Request)
    • 
                                            
  •  draft-ietf-oauth-rar-01 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0
                                                (OAuth 2.0 Rich
                                                Authorization Requests)
    • 
                                          

                                        

                                      

                                      

                                        
Those are
                                          optional, and in some
                                          situations are a desired
                                          property.

                                      

                                    

                                  

                                

                              

                            

                          

                          
[=
Denis]=C2=A0
                              However, in these two drafts, the privacy
                              considerations sections are silent on this
                              point.

                        

                      

                      

                        
There are lots of missing
                          details in both drafts! Security
                          considerations, error messages etc.

                      

                      

                        
=C2=A0

                      

                      

                        
I think pretty much
                          everyone is onboard supporting privacy, but
                          not all use cases have the same privacy
                          considerations.

                      

                      

                        
=C2=A0

                      

                      

                        
/Dick

                      

                    

                  

                

              

            

            


            

          

        

      

    

    


    

  


-- 

Txauth mailing list

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




--00000000000055cc4205a9c8cabc--


From nobody Mon Jul  6 10:15: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 E0E7C3A177D for ; Mon,  6 Jul 2020 10:15:42 -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 jD6PArrzP3Ma for ; Mon,  6 Jul 2020 10:15:40 -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 AF53F3A176D for ; Mon,  6 Jul 2020 10:15:40 -0700 (PDT)
Received: from [192.168.1.7] (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 066HFb3r029469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jul 2020 13:15:38 -0400
From: Justin Richer 
Message-Id: <80EF56C2-C67F-40C8-B376-C655937950DA@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_60264D27-87E7-4A5C-9D13-975219956C5F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 6 Jul 2020 13:15:37 -0400
In-Reply-To: 
Cc: Dick Hardt , Benjamin Kaduk , txauth@ietf.org
To: Fabien Imbault 
References:        <20200705225343.GQ16335@kduck.mit.edu>   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Additional implementation
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, 06 Jul 2020 17:15:43 -0000

--Apple-Mail=_60264D27-87E7-4A5C-9D13-975219956C5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Fabien,

I think macaroons could be an interesting technology to apply in GNAP as =
an option for key proofing, for both client->AS and client->RS calls. =
Since they=E2=80=99re ultimately about tying a key to a data payload, I =
can see how they would be useful in both cases. I don=E2=80=99t think =
they=E2=80=99d be a core technology requirement for GNAP though, since =
flexibility on key presentation is one of the core issues that GNAP is =
looking to address. I would be interested to see how macaroons would =
apply here, perhaps as an alternative alongside JWT.

Dick, I=E2=80=99m unaware of anything in JSON that can=E2=80=99t be =
directly expressed in CBOR. The reverse is not true, but that won=E2=80=99=
t pose a problem for GNAP.=20

 =E2=80=94 Justin

> On Jul 6, 2020, at 12:40 PM, Fabien Imbault  =
wrote:
>=20
> Hi Dick,
>=20
> Yes, when that's ready I'll share some examples (but again, we don't =
intend to ignite lengthy debates, see previous answer -> let's keep it =
as an aside experiment, as food for thought).=20
>=20
> As for macaroons, it's used quite extensively in production within =
some blockchain implementations (lightning for instance) and on our side =
we have a variant without a shared secret. But here again, we don't need =
to discuss that further, as long as we allow for the possibility to use =
other types than JWT (which we use also of course).=20
>=20
> Thanks.=20
>=20
> Fabien=20
>=20
>=20
> Le lun. 6 juil. 2020 =C3=A0 18:13, Dick Hardt > a =C3=A9crit :
> Fabien: it would be interesting to see how you think JSON-LD could be =
used in the protocol if you have some ideas on that. In XAuth, I am =
explicit that there are different formats / schema for tokens and =
claims.. There is no default, so it is clear how additional formats can =
be requested and returned.
>=20
> Ben: I think that token formats such as macaroons are out of scope of =
GNAP, or at least the core protocol. The key feature of macaroons is the =
ability to further restrict the authorization. An interesting idea, but =
depends on a shared secret, and I have not heard of deployments. In a =
quick google on macaroons, I came across this talk from Gopher Con =
https://about.sourcegraph.com/go/gophercon-2018-an-over-engineering-disast=
er-with-macaroons =
.
>=20
> Justin: good to see we are on the same page on all your points. I'd =
add that we should consider what JSON is used in the protocol to =
minimize or eliminate any impedance mismatch between JSON and CBOR.
>=20
> /Dick
>=20
> On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault =
> wrote:
> Writing too fast, with an iteration of unrelated examples, did not =
convey the right message. Sorry if it wasn't clear and confusing. We =
indeed need to differentiate between bearer tokens (e.g. JWT, macaroons =
or even simple cookies, etc.) and identity claims (e.g.. OIDC claims, =
linked data proofs, etc.).
> I only wanted to say that we need to take into account that there =
might be a variety of formats defined elsewhere. Not only OIDC (for =
claims) + JWT (for access tokens).
> =20
> Regarding JWT vs macaroons : I would say that JWT are additive, while =
macaroons are organized around caveats (so they're subtractive in a =
sense). But indeed they are both used in similar settings.=20
>=20
> Hope that clarifies.
> Fabien
>=20
> On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk > wrote:
> Hi Dick, Fabien,
>=20
> Just to clarify on one point, and check whether I'm confused:
>=20
> On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:
> > On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault =
>
> > wrote:
> >=20
> > > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt > wrote:
> > >
> > >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault =
>
> > >> wrote:
> >=20
> > >
> > >> Just like OAuth 2.0, the access token is opaque to the client, =
and it is
> > >> not specified, so I'm confused what you mean by "other types of =
tokens than
> > >> JWT"?
> > >>
> > >> FI : I mean, for instance, linked data proofs, macaroons, and so =
on.
> > >
> >=20
> > I see. When I read 'token', I think of access tokens. You are =
referring to
> > what I would call a claims, which per above are defined somewhere =
else..
>=20
> My understanding was that macaroons, at least, were complete tokens =
that
> incorporate (at least by reference) multiple claims.  So a macaroon =
and a
> JWT would be analogous in that sense (container holding many claims).  =
I'm
> not sure whether the same holds for a linked data proof (or if it's =
just a
> way to represent a single claim), though.
>=20
> Am I confused?
>=20
> Thanks,
>=20
> Ben
> --=20
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth


--Apple-Mail=_60264D27-87E7-4A5C-9D13-975219956C5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Fabien,

I =
think macaroons could be an interesting technology to apply in GNAP as =
an option for key proofing, for both client->AS and client->RS =
calls. Since they=E2=80=99re ultimately about tying a key to a data =
payload, I can see how they would be useful in both cases. I don=E2=80=99t=
 think they=E2=80=99d be a core technology requirement for GNAP though, =
since flexibility on key presentation is one of the core issues that =
GNAP is looking to address. I would be interested to see how macaroons =
would apply here, perhaps as an alternative alongside JWT.

Dick, I=E2=80=99m =
unaware of anything in JSON that can=E2=80=99t be directly expressed in =
CBOR. The reverse is not true, but that won=E2=80=99t pose a problem for =
GNAP. 

 =E2=80=94 Justin

On Jul =
6, 2020, at 12:40 PM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

Hi Dick,

Yes, when =
that's ready I'll share some examples (but again, we don't intend to =
ignite lengthy debates, see previous answer -> let's keep it as an =
aside experiment, as food for thought). 

As for =
macaroons, it's used quite extensively in production within some =
blockchain implementations (lightning for instance) and on our side we =
have a variant without a shared secret. But here again, we don't need to =
discuss that further, as long as we allow for the possibility to use =
other types than JWT (which we use also of course). 

Thanks. 

Fabien 


Le lun. 6 juil. 2020 =C3=A0 18:13, Dick =
Hardt <dick.hardt@gmail.com> a =C3=A9crit :
Fabien:=
 it would be interesting to see how you think JSON-LD could be used in =
the protocol if you have some ideas on that. In XAuth, I am explicit =
that there are different formats / schema for tokens and claims.. =
There is no default, so it is clear how additional formats can be =
requested and returned.

Ben: I think that token formats such as macaroons are out of =
scope of GNAP, or at least the core protocol. The key feature of =
macaroons is the ability to further restrict the authorization. An =
interesting idea, but depends on a shared secret, and I have not heard =
of deployments. In a quick google on macaroons, I came across this talk =
from Gopher Con https://about.sourcegraph.com/go/gophercon-2018-an-over-enginee=
ring-disaster-with-macaroons.

Justin: good to see we are on the same =
page on all your points. I'd add that we should consider what JSON is =
used in the protocol to minimize or eliminate =
any impedance mismatch between JSON and CBOR.

/Dick

On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault =
<fabien.imbault@gmail.com> wrote:
Writing =
too fast, with an iteration of unrelated examples, did not convey the =
right message. Sorry if it wasn't clear and confusing. We indeed =
need to differentiate between bearer tokens (e.g. JWT, macaroons or even =
simple cookies, etc.) and identity claims (e.g.. OIDC claims, linked =
data proofs, etc.).
I =
only wanted to say that we need to take into account that there might be =
a variety of formats defined elsewhere. Not only OIDC (for claims) + JWT =
(for access tokens).
 
Regarding JWT vs macaroons : I would say that JWT are =
additive, while macaroons are organized around caveats (so they're =
subtractive in a sense). But indeed they are both used in similar =
settings. 

Hope =
that clarifies.
Fabien

On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk =
<kaduk@mit.edu> wrote:
Hi Dick, Fabien,



Just to clarify on one point, and check whether I'm confused:



On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:
=

> On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault <fabien.imbault@gmail.com>

> wrote:

> 

> > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt <dick.hardt@gmail.com> wrote:

> >

> >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <fabien.imbault@gmail.com>

> >> wrote:

> 

> >

> >> Just like OAuth 2.0, the access token is opaque to the =
client, and it is

> >> not specified, so I'm confused what you mean by "other =
types of tokens than

> >> JWT"?

> >>

> >> FI : I mean, for instance, linked data proofs, macaroons, =
and so on.

> >

> 

> I see. When I read 'token', I think of access tokens. You are =
referring to

> what I would call a claims, which per above are defined somewhere =
else..



My understanding was that macaroons, at least, were complete tokens =
that

incorporate (at least by reference) multiple claims.  So a macaroon =
and a

JWT would be analogous in that sense (container holding many =
claims).  I'm

not sure whether the same holds for a linked data proof (or if it's just =
a

way to represent a single claim), though.



Am I confused?



Thanks,



Ben







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

=

--Apple-Mail=_60264D27-87E7-4A5C-9D13-975219956C5F--


From nobody Mon Jul  6 10:28: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 CA2BC3A1800 for ; Mon,  6 Jul 2020 10:28:00 -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 QFHDnPNHllGj for ; Mon,  6 Jul 2020 10:27:58 -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 4A3AC3A17F9 for ; Mon,  6 Jul 2020 10:27:57 -0700 (PDT)
Received: from [192.168.1.7] (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 066HRrfI000883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jul 2020 13:27:54 -0400
From: Justin Richer 
Message-Id: <2F429EC5-85FD-4991-AED8-8478BD371A00@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_722773DC-340E-4EEA-A963-2F04EA74FF24"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 6 Jul 2020 13:27:53 -0400
In-Reply-To: 
Cc: Denis , txauth@ietf.org
To: Fabien Imbault 
References:    <8a723292-4d04-63c7-e57c-7e7307e145c8@free.fr> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] RS/AS communication for multiparty 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: Mon, 06 Jul 2020 17:28:01 -0000

--Apple-Mail=_722773DC-340E-4EEA-A963-2F04EA74FF24
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Fabien and Denis,

I think here we can see that there are multiple different directions =
that people=E2=80=99s use cases and concerns will pull GNAP=E2=80=99s =
design. Some want to have the AS have no knowledge of the RS, and only =
the client to know that; others want the AS to have knowledge of all of =
its RS=E2=80=99s and be able to dispatch an naive client to one. The =
thing is, I think both of these have merit and both of them can be =
accommodated in the protocol. Allowing one does not disallow the other. =
It=E2=80=99s not up to GNAP to decide which of these approaches is =
morally correct.

In particular, addressing both of these dimensions is one of the things =
that having a multi-dimensional language for requesting resources in a =
standard way is going to help beyond what OAuth 2 can do. These queries =
can be designed in such a way to minimize disclosure to the AS or to =
minimize the amount of knowledge in the client, or anywhere in between. =
Ultimately it=E2=80=99s up to the RS to decide whether the rights =
associated with the token are good enough for the request, and GNAP=E2=80=99=
s proposed charter says we=E2=80=99ll be defining both a means for =
fine-grained requests as well as a consistent data model for the =
token=E2=80=99s rights. Neither of these assumes that the RS will be =
identified, nor that it can=E2=80=99t be.

 =E2=80=94 Justin

> On Jul 6, 2020, at 7:06 AM, Fabien Imbault  =
wrote:
>=20
> Hi Denis,
>=20
> Thanks for your feedback. Your scheme is interesting and covers well =
the personal access.=20
>=20
> The variant I'm referring to is multiparty access, which is a fairly =
common pattern also. Handled as an extension in Oauth2, but to my =
knowledge it requires an additional relationship between RS and AS. =
Maybe we can come up with an alternative design, I don't know yet.=20
>=20
> Cheers.=20
>=20
> Fabien=20
>=20
>=20
> Le lun. 6 juil. 2020 =C3=A0 12:23, Denis > a =C3=A9crit :
> Hello Fabien,
>> Thanks Denis. It clarifies what you have in mind.=20
>>=20
>> While I agree with the general idea that we need to take privacy more =
seriously, there are a few hypotheses that we need to put in perspective =
:=20
>>=20
>> 1) AS-RS relationship <=3D> big brother. It may happen as we all =
know, but you always have the choice as a user to not deal with orgs you =
don't like=20
>> or maybe even take action if they don't respect the law.
> Unfortunately, the choice you mention is not always possible. There is =
a fundamental point here: since it is not always possible to trust an AS =
to respect the law,
> it is possible to build an architecture where the AS will be unable to =
by-pass the law. It is the difference between :
>=20
> "the AS should not do this or that" (but it could if it would) and
> "the AS cannot do this or that" (it cannot even if it would). =20
>> 2) the collusion possibility (Alice's uncle) : there are of course =
situations where that may be an issue. This is I guess the reason for =
the sovrin foundation=20
>> to require that only approved issuers can participate. But even if =
you open up the system, it always ends up as whether you can trust the =
uncle to be honest=20
>> in the first place (knowing that trust is a social construct).
> When using computers, trust is not a "social construct". It is a =
construction where an entity A trusts an entity B for some behaviour C.=20=

> In the ABC attack, the RS will never know whether someone forwarded or =
not an access token to Alice.
>=20
>> So I may require the issuer to be a well known participant instead.
>>=20
>> 3) The use of hardware FIDO inspired components does relax some of =
the previous concern, but comes with its own sets of challenges.
>> Biometrics come with their own sets of potential issues.
> The use of FIDO does not imply that you must use its biometrics =
features.
>=20
>> More trivially, if you loose your hardware, you loose your ID.
> If you loose your ID, you should report of its loss. It also means =
that by design, a mechanism has been constructed to recover from the =
situation=20
> within a short period of time. Unfortunately, such a property is =
currently missing in FIDO, but it does not mean that it cannot be added.
>=20
>> And there can also be hacks in hardware. If I find a way to import or =
export the private key from the enclave, the system fails.
> The whole system does not fail. When someone attempts to export a =
private key from an hardware device in an unlawful way, it takes some =
time and some expertise.
> As soon as the legitimate holder realizes the lost of his hardware, he =
should report the loss. Then after, the discovery of private keys stored =
into the device is no more an issue.
>=20
>> So in the end, I agree it's best to enable as much privacy by design =
as we possibly can, but we need to put that in perspective with use =
cases too and make some tradeoffs.=20
>> Healthcare in particular is a domain that is concerned with a =
constant balance between privacy and security, and sometimes there is no =
possibility to tick all boxes.=20
>> I think an UMA2/OpenId Heart scenario is a very important case to =
consider in that respect.=20
> The goal of this BoF/WG is not to rubber-stamp the "Health =
Relationship Trust Profile for User-Managed Access 2.0" specification.
>=20
> Since the "Health Relationship Trust Profile for User-Managed Access =
2.0" specification has nothing really specific to healthcare, what is =
the "very important case" you have in mind ?
> Would it be possible to model a specific characteristic you have in =
mind in terms of model components, operations flows, trust =
relationships, privacy requirements and security requirements ?
>=20
> Denis
>=20
>>=20
>> Fabien=20
>>=20
>>=20
>>=20
>>=20
>> On Fri, Jul 3, 2020 at 12:01 PM Denis > wrote:
>> Hello Fabien,
>>=20
>> In 2017, I made a presentation at the OAuth workshop in Zurich.
>>=20
>> The paper is available from: =
https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-e=
ID-scheme-supporting-Attribute-based-Access-Control.pdf =

>>=20
>> The slides are available from: =
https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.ppt=
 =

>> Note: The slides should be viewed "full screen" to get the =
animations.=20
>>=20
>> The general approach is how to construct from scratch a "privacy by =
design" architecture taking also into consideration "security by =
design".
>>=20
>> Coming back to your requirement, I would not cover it if it infringes =
the sentence "the RS and the AS never communicate directly".
>>=20
>> You should start your design by defining the trust relationships, =
then apply the privacy requirements while not forgetting the security =
requirements.
>>=20
>> Denis
>>=20
>>> Hello Denis,
>>>=20
>>> I have been following your comments. I still fail to see the global =
privacy preserving architecture you're proposing. It would help to get a =
more thorough proposal if you can.
>>>=20
>>> But more specifically, I have a comment on :=20
>>>=20
>>> "I would have preferred that you meant: the RS and the AS never=20
>>> communicate directly, which is indeed a nice property to follow
>>> to ensure the user's privacy."
>>> I think that may come as an issue in some cases, especially for =
multiparty patterns (like in UMA). Typically we may wish the RS to start =
a grant request and use the handle to continue until a token is =
generated.
>>> I think those cases, which weren't initially covered by OAuth2, are =
very important to cover as well. How would you cover such requirements?
>>> Fabien
>>>=20
>>>=20
>>=20
>=20
> --=20
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth


--Apple-Mail=_722773DC-340E-4EEA-A963-2F04EA74FF24
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Fabien and Denis,

I think here we can see that there are multiple different =
directions that people=E2=80=99s use cases and concerns will pull =
GNAP=E2=80=99s design. Some want to have the AS have no knowledge of the =
RS, and only the client to know that; others want the AS to have =
knowledge of all of its RS=E2=80=99s and be able to dispatch an naive =
client to one. The thing is, I think both of these have merit and both =
of them can be accommodated in the protocol. Allowing one does not =
disallow the other. It=E2=80=99s not up to GNAP to decide which of these =
approaches is morally correct.

In particular, addressing both of these =
dimensions is one of the things that having a multi-dimensional language =
for requesting resources in a standard way is going to help beyond what =
OAuth 2 can do. These queries can be designed in such a way to minimize =
disclosure to the AS or to minimize the amount of knowledge in the =
client, or anywhere in between. Ultimately it=E2=80=99s up to the RS to =
decide whether the rights associated with the token are good enough for =
the request, and GNAP=E2=80=99s proposed charter says we=E2=80=99ll be =
defining both a means for fine-grained requests as well as a consistent =
data model for the token=E2=80=99s rights. Neither of these assumes that =
the RS will be identified, nor that it can=E2=80=99t be.

 =E2=80=94 =
Justin

On Jul 6, 2020, at 7:06 AM, Fabien Imbault =
<fabien.imbault@gmail.com> wrote:

Hi Denis,

Thanks for =
your feedback. Your scheme is interesting and covers well the personal =
access. 

The variant I'm referring to is multiparty =
access, which is a fairly common pattern also. Handled as an extension =
in Oauth2, but to my knowledge it requires an additional relationship =
between RS and AS. Maybe we can come up with an alternative design, I =
don't know yet. 

Cheers. 

Fabien 


Le lun. 6 juil. 2020 =C3=A0 12:23, =
Denis <denis.ietf@free.fr> a =C3=A9crit :

 =20
   =20
 =20
  

    
Hello Fabien,

    

     =20
      
Thanks Denis. It clarifies what you =
have in mind. 
        


        

        
While I agree with the general idea that we need =
to take
          privacy more seriously, there are a few hypotheses that we
          need to put in perspective : 

          

        

        
1) AS-RS relationship <=3D> big brother. =
It may happen
          as we all know, but you always have the choice as a user to
          not deal with orgs you don't like 

          or maybe even take action if they don't respect the law.

        

      

    
Unfortunately, the choice you mention is =
not always possible.
      There is a fundamental point here: since it is not always possible
      to trust an AS to respect the law,

      it is possible to build an architecture where the AS will be
      unable to by-pass the law. It is the difference between :

    
    
      
  • "the AS should not do this or =
that" (but it could if
        it would) and
    • 
      
  • "the AS cannot do this or that" =
(it cannot even if it
        would).  
    
      
    • 
    

    

      

        
2) the collusion possibility (Alice's uncle) : =
there are of
          course situations where that may be an issue. This is I guess
          the reason for the sovrin foundation 

          to require that only approved issuers can participate. But
          even if you open up the system, it always ends up as whether
          you can trust the uncle to be honest 

          in the first place (knowing that trust is a social construct).
        

      

    
When using computers, trust is not a =
"social construct". It is a
      construction where an entity A trusts an entity B for some
      behaviour C. 

      In the ABC attack, the RS will never know whether someone
      forwarded or not an access token to Alice.

    

    

      

        
So I may require the issuer to be a well known =
participant
          instead.

          

          3) The use of hardware FIDO inspired components does relax
          some of the previous concern, but comes with its own sets of
          challenges.

          Biometrics come with their own sets of potential issues. =


      

    
The use of FIDO does not imply that you =
must use its biometrics
      features.

    

      

        
More trivially, if you loose your hardware, you =
loose your
          ID. 

      

    
If you loose your ID, you should report =
of its loss. It also
      means that by design, a mechanism has been constructed to recover
      from the situation 

      within a short period of time. Unfortunately, such a property is
      currently missing in FIDO, but it does not mean that it cannot be
      added.

    

    

      

        
And there can also be hacks in hardware. If I =
find a way to
          import or export the private key from the enclave, the system
          fails.

      

    
The whole system does not fail. When =
someone attempts to export a
      private key from an hardware device in an unlawful way, it takes
      some time and some expertise.

      As soon as the legitimate holder realizes the lost of his
      hardware, he should report the loss. Then after, the discovery of
      private keys stored into the device is no more an issue.

    

      

        
So in the end, I agree it's best to enable as =
much privacy
          by design as we possibly can, but we need to put that in
          perspective with use cases too and make some tradeoffs. 

          Healthcare in particular is a domain that is concerned with a
          constant balance between privacy and security, and sometimes
          there is no possibility to tick all boxes. 

        
I think an UMA2/OpenId Heart scenario is a very =
important
          case to consider in that respect. 

        

      

    
The goal of this BoF/WG is not to =
rubber-stamp the "Health
      Relationship Trust Profile for User-Managed Access 2.0"
      specification. 
Since the "Health Relationship =
Trust Profile for User-Managed
      Access 2.0" specification has nothing really specific to
      healthcare, what is the "very important case" you have in mind =
?

      Would it be possible to model a specific characteristic you have
      in mind in terms of model components, operations flows, trust
      relationships, privacy requirements and security requirements ?

    
Denis

    

    

      

        


        

        
Fabien 

        


        

        


        

        


        

      

      

      

        
On Fri, Jul 3, 2020 at =
12:01
          PM Denis <denis.ietf@free.fr>=
 wrote:

        

        

          

            
Hello Fabien,

            


            

            
In 2017, I made a presentation at the OAuth =
workshop in
              Zurich.

            


            

            
The paper is available from: https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-=
by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf

            


            

            
The slides are available from: https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacyb=
ydesign.ppt

            

            
Note: The slides should be =
viewed "full screen"
              to get the animations. 

            

            


            

            
The general approach is how to construct =
from scratch a
              "privacy by design" architecture taking also into
              consideration "security by design".

            


            

            
Coming back to your requirement, I would not =
cover it
              if it infringes the sentence "the RS and the AS never
              communicate directly".

            


            

            
You should start your design by defining the =
trust
              relationships, then apply the privacy requirements while
              not forgetting the security requirements.

              

            

            
Denis

            


            

            

              
Hello Denis,
                


                

                
I have been following your comments. I =
still fail
                  to see the global privacy preserving architecture
                  you're proposing. It would help to get a more thorough
                  proposal if you can.

                  


                  

                  
But more specifically, I have a =
comment on : 

                  


                  

                  

                    
"I would have preferred that you meant: the RS and =
the AS never=20
communicate directly, which is indeed a nice property to follow
to ensure the user's privacy."

                    
I think that may come as an issue in some cases, =
especially for multiparty patterns (like in UMA). Typically we may wish =
the RS to start a grant request and use the handle to continue until a =
token is generated.

                    
I think those cases, which weren't initially =
covered by OAuth2, are very important to cover as well. How would you =
cover such requirements?

                    
Fabien

                  

                

              

              

              

            


            

          

        

      

    


    

  




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

=

--Apple-Mail=_722773DC-340E-4EEA-A963-2F04EA74FF24--


From nobody Mon Jul  6 10:30: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 2DB453A182E for ; Mon,  6 Jul 2020 10:30:44 -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_REMOTE_IMAGE=0.01, 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 3dnE0hYrsmSe for ; Mon,  6 Jul 2020 10:30:42 -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 1BBB13A1826 for ; Mon,  6 Jul 2020 10:30:41 -0700 (PDT)
Received: from [192.168.1.7] (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 066HUcUW001711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jul 2020 13:30:38 -0400
From: Justin Richer 
Message-Id: <4E50ABA2-7FFE-4B02-94DA-35CC0D2FF034@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E4059CC3-840F-4D1C-ACC7-F18E332B20FA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 6 Jul 2020 13:30:38 -0400
In-Reply-To: 
Cc: David Pyke , Tom Jones , txauth@ietf.org
To: Steinar Noem 
References:   <3b8d3690-47e2-ff00-1065-29647d18555b@readycomputing.com>  <00827624-7361-4c5f-b34f-0edc8f7493dc@readycomputing.com>  <5AA3C0D4-A250-4EFB-B3E9-F71E8BD959A6@mit.edu> <7d8f8a78-01c9-ec27-b5d3-d03b7fb9a159@readycomputing.com> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Possible Use Case for GNAP
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, 06 Jul 2020 17:30:44 -0000

--Apple-Mail=_E4059CC3-840F-4D1C-ACC7-F18E332B20FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Something very much like this was the original driver to my now-defunct =
OAuth 2 token chaining draft:

https://tools.ietf.org/html/draft-richer-oauth-chain-00 =


Most of the concepts here were eventually subsumed by the token exchange =
specification, though with support for more complex use cases as well.=20=


In XYZ, one of the reasons that we have an explicit =E2=80=9Ctransaction =
handle=E2=80=9D to represent the grant request is that it allows us to =
build in this kind of multi-party chaining. A downstream party can refer =
to an ongoing request and start a new one in its context. This is also =
the idea behind how you=E2=80=99d do an RS-first flow: the RS would get =
a resource or transaction handle and give it back to the client, which =
would make a request for a new token based on that artifact. Note, for =
clarity, we didn=E2=80=99t implement it explicitly in our code base, but =
a number of thought experiments went into the design of the overall =
protocol and it=E2=80=99s noted on the website in a few places. It=E2=80=99=
s something that I think is worth exploring, and it=E2=80=99s well =
within our scope given it=E2=80=99s an area that OAuth 2 does address =
today. It=E2=80=99s my hope that by taking a step back from the OAuth 2 =
solution and understanding its problems, we can have a more consistent =
and robust solution in GNAP.

 =E2=80=94 Justin

> On Jul 6, 2020, at 12:48 PM, Steinar Noem  wrote:
>=20
> Hey, we have some (sort of) similar cases and requirements today which =
we have solved by implementing the token-exchange spec.=20
> It certainly doesn=E2=80=99t solve all the issues discussed here, but =
for traceability it does the job for us. Being able to express an =
=E2=80=9Cauthorization stack-trace=E2=80=9D and the original user =
identity is both useful and required  in our case.
>=20
> -Steinar
>=20
> man. 6. jul. 2020 kl. 16:34 skrev David Pyke =
>:
> Those are exactly the issues I was facing.  While I can make the hops =
independent, they need to be chained so that everything is traceable.   =
It's possible but ugly with OAuth.
>=20
> On 2020-07-02 3:34 p.m., Justin Richer wrote:
>> If we look at each hop as a separately authorized request, could we =
define them in a way that they=E2=80=99re chained from each other down =
the line? Maybe it would be possible for the root HIN to get a new token =
for each of the downstream HINs, but this new token is in the context of =
the first one
> --=20
> David Pyke
>=20
> Manager, Strategic Consulting
>=20
> =
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
------------
>=20
>  
>    =
  =
=09
> Office: +1 212 877 3307 x5001
>=20
> david.pyke@readycomputing.com 
> www.readycomputing.com 
> 150 Beekman Street, Floor 3, New York, NY 10038 =

>=20
> The information in this e-mail communication together with any =
attachments is intended only for the person or entity to which it is =
addressed and may contain confidential and/or privileged material. If =
you are not the intended recipient of this communication, please notify =
us immediately. Any views expressed in this communication are those of =
the sender, unless otherwise specifically stated. Ready Computing does =
not represent, warrant or guarantee that the integrity of this =
communication has been maintained or the communication is free of =
errors, virus or interference.
>=20
> This is not a secure transmission. The information contained in this =
transmission is highly prohibited from containing privileged and =
confidential information, including patient information protected by =
federal and state privacy laws. It is intended only for the use of the =
person(s) named above. If you are not the intended recipient, you are =
hereby notified that any review, dissemination, distribution, or =
duplication of this communication is strictly prohibited. If you are not =
the intended recipient, please contact the sender by reply email and =
destroy all copies of the original message. --=20
> Txauth mailing list
> Txauth@ietf.org 
> https://www.ietf.org/mailman/listinfo/txauth =

> --=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


--Apple-Mail=_E4059CC3-840F-4D1C-ACC7-F18E332B20FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Something very much like this was the original driver to my =
now-defunct OAuth 2 token chaining draft:

https://tools.ietf.org/html/draft-richer-oauth-chain-00

Most of the =
concepts here were eventually subsumed by the token exchange =
specification, though with support for more complex use cases as =
well. 

In =
XYZ, one of the reasons that we have an explicit =E2=80=9Ctransaction =
handle=E2=80=9D to represent the grant request is that it allows us to =
build in this kind of multi-party chaining. A downstream party can refer =
to an ongoing request and start a new one in its context. This is also =
the idea behind how you=E2=80=99d do an RS-first flow: the RS would get =
a resource or transaction handle and give it back to the client, which =
would make a request for a new token based on that artifact. Note, for =
clarity, we didn=E2=80=99t implement it explicitly in our code base, but =
a number of thought experiments went into the design of the overall =
protocol and it=E2=80=99s noted on the website in a few places. It=E2=80=99=
s something that I think is worth exploring, and it=E2=80=99s well =
within our scope given it=E2=80=99s an area that OAuth 2 does address =
today. It=E2=80=99s my hope that by taking a step back from the OAuth 2 =
solution and understanding its problems, we can have a more consistent =
and robust solution in GNAP.

 =E2=80=94 Justin

On Jul 6, 2020, at 12:48 PM, Steinar Noem <steinar@udelt.no> =
wrote:

Hey, we have =
some (sort of) similar cases and requirements today which we have solved =
by implementing the token-exchange spec. 
It certainly doesn=E2=80=99t solve all the issues discussed =
here, but for traceability it does the job for us. Being able to express =
an =E2=80=9Cauthorization stack-trace=E2=80=9D and the original user =
identity is both useful and required  in our case.

-Steinar

man. 6. jul. =
2020 kl. 16:34 skrev David Pyke <david.pyke=3D40readycomputing.com@dmarc.ietf.org>:

 =20
   =20
 =20
  
Those are exactly the issues I was facing.  While
        I can make the hops independent, they need to be chained so that
        everything is traceable.   It's possible but ugly with =
OAuth.

    

    
On 2020-07-02 3:34 p.m., Justin Richer
      wrote:

    

    
If we look
      at each hop as a separately authorized request, could we define
      them in a way that they=E2=80=99re chained from each other down =
the line?
      Maybe it would be possible for the root HIN to get a new token for
      each of the downstream HINs, but this new token is in the context
      of the first one

    
-- 

     =20
     =20
     =20
     =20
      

        =

          

            

              

                  David Pyke

              		
            

            

              

                  Manager,
                    Strategic Consulting

              		
            

            

              
 ---------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
--------------------------------------------------------------------------=
-----------------------

              		
            

            

              

                  3D"Logo"

                  3D"LinkedIn 3D"Twitter 3D"Youtbue

              		
              
Office:
                    +1 212 877 3307 x5001

                

                  
                    

                      

                          
                                =
david.pyke@readycomputing.com

                          
                                =
www.readycomputing.com

                      		
                    

                    

                      
150
                            Beekman Street, Floor 3, New York, NY =
10038

                      		
                    

                    

                      

                      		
                    

                  
                

              		
            

            

              

                  The
                    information in this e-mail communication together
                    with any attachments is intended only for the person
                    or entity to which it is addressed and may contain
                    confidential and/or privileged material. If you are
                    not the intended recipient of this communication,
                    please notify us immediately. Any views expressed in
                    this communication are those of the sender, unless
                    otherwise specifically stated. Ready Computing does
                    not represent, warrant or guarantee that the
                    integrity of this communication has been maintained
                    or the communication is free of errors, virus or
                    interference.

              		
            

          
        

      

    

  





This is not a secure transmission. The information contained in this=20
transmission is highly prohibited from containing privileged and=20
confidential information, including patient information protected by=20
federal and state privacy laws. It is intended only for the use of the=20=

person(s) named above. If you are not the intended recipient, you are=20
hereby notified that any review, dissemination, distribution, or=20
duplication of this communication is strictly prohibited. If you are not
 the intended recipient, please contact the sender by reply email and=20
destroy all copies of the original message.
                       -- 

Txauth mailing list

Txauth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth
=


-- 
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler
 
| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no | 



=

--Apple-Mail=_E4059CC3-840F-4D1C-ACC7-F18E332B20FA--


From nobody Mon Jul  6 11:14: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 6080B3A0602 for ; Mon,  6 Jul 2020 11:14:38 -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 Jo2FrD3aylhI for ; Mon,  6 Jul 2020 11:14:36 -0700 (PDT)
Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 913BF3A0795 for ; Mon,  6 Jul 2020 11:14:35 -0700 (PDT)
Received: by mail-lf1-x143.google.com with SMTP id g2so23167496lfb.0 for ; Mon, 06 Jul 2020 11:14:35 -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=UJ1G4yhvvOiEHj6NdNZ3sz47jPn7xrW5nYXpE+KS2d4=; b=a9xMMy6o6+5oZPMvY3M9cuDUD56qOsGQ4lI8ruRmfHWrTYuw+wWG+dXV2yBgvCdREe 5BUYMXsu7sjD7tgqssPjRxg/5zfMhNy68FspbMZV48Jvq5BbIqVzoJ+hgmxETO2ETwH2 OqGINzGSV8bjzw3FhDyR/San1mLlt2HDsJtnie1UKy/RNKIvxn5j7Ee9cgu5t9S6xlyt LmMVN1iiAVszhB+yRGpzZ87wq5IXT9VkRPays9mnD8Mj4UOpxGWyBPeKHCwvWuvmzE/Q Nd7ap2ZuVvkIOwF/kgqoP6yvJ/QwWXga1JAMTvKDyxE0D+h6ZQx55tboJyhixYpBtEBL d7gQ==
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=UJ1G4yhvvOiEHj6NdNZ3sz47jPn7xrW5nYXpE+KS2d4=; b=EepWY4lQqUv7mqM/4p08ckRW5d7+goT00vUW5LBPC4lGu7wzSin9IESTDwq6R2hhNU FcVBCSYg4fREn36GP6yuW8vF5Y05a6X7LCWDL7AJvAiwyRXwd8Hbfe+ydkBIk08VvcKY gjSkqMefk3dqxOL0RmjPTN5/zMDwBGnk4GNnF2an18NxbOg0bGni6x1FG/dapkiT88ff EzSa7OLkbLI0+/poLeMOHiNYe5jh1T13KyjUQlP2Qy3o8wjhdFRGrCTMk0JBvaTRYNPD 6u+hRg+frGaqUw+5hVEVQ0tqUpUBoHJSGO8ZAgHNZxzzc23RqBcIHBVobhQHGhiWOrlI CyUQ==
X-Gm-Message-State: AOAM531cXwYLxd1nkwg81MN/y39M+djqgc5GOUj5hFAwByj+L2uQgdt5 2SMMbxliEvuTe0bJq9DvjP8I0Ca/6cW2xA7r4y4jeF/yReE=
X-Google-Smtp-Source: ABdhPJxx2fa0HpIgNE5XbdYbBDrFBiOU/ZsesCMDeQPLTAilL7sBsYCxUdTrH03y/PoFIQm9WxZalrUOKPtU3ZgYS6Q=
X-Received: by 2002:a19:c8a:: with SMTP id 132mr30770186lfm.23.1594059273042;  Mon, 06 Jul 2020 11:14:33 -0700 (PDT)
MIME-Version: 1.0
From: Dick Hardt 
Date: Mon, 6 Jul 2020 11:13:57 -0700
Message-ID: 
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b87db805a9c9d84c"
Archived-At: 
Subject: [Txauth] updated draft-hardt-xauth-protocol (-11) and an implementation!
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, 06 Jul 2020 18:14:39 -0000

--000000000000b87db805a9c9d84c
Content-Type: text/plain; charset="UTF-8"

I have updated the draft based on my implementation experience:

https://tools.ietf.org/html/draft-hardt-xauth-protocol-11

(note that the links at the top of the page are messed up -- I managed to
break the IETF tool)

I also updated the JOSE spec

https://tools.ietf.org/html/draft-hardt-gnap-jose-01

Here is the implementation in nodejs:

https://github.com/dickhardt/XAuth-poc

I implemented a CLI client that uses the indirect interaction mode, and a
web client that uses the redirect interaction mode.
The PoC supports no client authentication, and the proposed JOSE client
authentication mechanism.

The CLI client supports a QR code scan, or a -f flag can be set to fake out
the user -- handy for development.

All the protocol call and signing work is inline in the clients. I have not
made an attempt to create a module to support the protocol client side.

I wrote up some learnings here:

https://github.com/dickhardt/XAuth-poc/wiki/Lessons-Learned---draft-11---initial-version

Copy and pasted below:
Confirmations:

   - claims.[schema] works well to determine if claims schema is supported
   - authorization.type worked well to detect the authorization schema
   - separate DBs for client.id (registered clients) and client.handle
   (dynamic clients) keeps these similar, but different storage systems
   independent. Have to detect which type of client, but code was not onerous.
   - separate identifiers for dynamic and registered clients made it easy
   to have policy that let registered clients do things not available for
   dynamic clients (write access) and to require Grant Verification.
   - interaction modes made it easy to evaluate what would happen in
   interaction and decide what was allowed and not allowed
   - representing grants and authorizations as URIs and using methods for
   different APIs made routing to different modules simple. Adding a new API,
   Grant Verification was simple.
   - the top level objects made it easy to decompose validating and
   processing user, client, interaction, claims, and authorizations
   - warnings about ignored parameters looks useful, but coding it is
   brittle - JSON Schema may make it declarative
   - once a decoded JOSE token was available, it was simple to acquire the
   embedded JWK for a dynamic client
   - Grant and AZ ids in URI made it easy to return 404 early. Also made it
   easy to get client key.


Lessons

   - Implementation stored registered and dynamic clients in two different
   databases. Code has to switch between the two. For simpler implementations
   store client.id and client.handle in same DB.
   - space separated scopes from OAuth 2.x is a coding thunk
   - OIDC claims having a null value is a thunk. Had to use hasOwnProperty
   instead of just testing value
   - claims.oidc.userinfo.mail is a long path to ask for a claim. Perhaps
   have oidc_userinfo and oidc_id_token?
   - separate top level objects for authorization and authorizations seems
   clumsy - perhaps detect plurality by detecting 'type' property? 'type'
   would be reserved for clients to not use. If no 'type', then each property
   is a separate authorization request. Or always have plural, but then an
   extra level for the common, single authorization use case.
   - having a '-' in a property name is messy in JS
   - parsing and peaking into JSON or decoding the JOSE object to find
   client info in Create Grant is required before authentication can happen.
   Took a while to figure out the right order to structure routing and
   middleware.
   - JSON Schema  looks like it may simplify
   input JSON validation. Also useful for validating responses in automated
   testing. IETF IDs have not been picked up in a WG so far.
   - My HTML skills suck
   - My ES6 knowledge is lacking

--000000000000b87db805a9c9d84c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I have updated the draft based on my implementation experien=
ce:


(note that the links at the top of the page are messed up -- I managed to =
break the IETF tool)

I also updated th=
e JOSE spec


Here is the implementatio=
n in nodejs:

https://github.com/dickhardt/XAuth-poc

I implemented a CLI client that uses the=
 indirect interaction mode, and a web client that uses the redirect interac=
tion mode.=C2=A0
The PoC supports no client authentication, and t=
he proposed JOSE client authentication mechanism.=C2=A0

The CLI client supports a QR code scan, or a -f flag can be set to fa=
ke out the user -- handy for development.

All the =
protocol call and signing work is inline in the clients. I have not made an=
 attempt to create a module to support the protocol client side.

I wrote up some learnings here:


Copy and pasted below:
Confirmations:
  • claims=
.[schema] works well to determine if claims schema is supported
  • authorization.type worked we=
ll to detect the authorization schema
  • separate DBs for client.i=
d (registered clients) and client.handle (dynamic clients) keeps these =
similar, but different storage systems independent. Have to detect which ty=
pe of client, but code was not onerous.
  • separate identifiers for dynamic and registered clie=
nts made it easy to have policy that let registered clients do things not a=
vailable for dynamic clients (write access) and to require Grant Verificati=
on.
  • interaction m=
odes made it easy to evaluate what would happen in interaction and decide w=
hat was allowed and not allowed
  • representing grants and authorizations as URIs and using met=
hods for different APIs made routing to different modules simple. Adding a =
new API, Grant Verification was simple.
  • the top level objects made it easy to decompose vali=
dating and processing user, client, interaction, claims, and authorizations=

  • warnings about i=
gnored parameters looks useful, but coding it is brittle - JSON Schema may =
make it declarative
  • once a decoded JOSE token was available, it was simple to acquire the em=
bedded JWK for a dynamic client
  • Grant and AZ ids in URI made it easy to return 404 early. Al=
so made it easy to get client key.
Les=
sons
  • Implementation stored registered and dynamic clients in two differen=
t databases. Code has to switch between the two. For simpler implementation=
s store client.id and client.handle in sam=
e DB.
  • space separ=
ated scopes from OAuth 2.x is a coding thunk
  • OIDC claims having a null value is a thunk. Had=
 to use hasOwnProperty instead of just testing value
  • claims.oidc.userinfo.mail is a long pat=
h to ask for a claim. Perhaps have oidc_userinfo and oidc_id_token?
    • separate top level objec=
ts for authorization and authorizations seems clumsy - perhaps detect plura=
lity by detecting 'type' property? 'type' would be reserved=
 for clients to not use. If no 'type', then each property is a sepa=
rate authorization request. Or always have plural, but then an extra level =
for the common, single authorization use case.
  • having a '-' in a property name is me=
ssy in JS
  • parsing=
 and peaking into JSON or decoding the JOSE object to find client info in C=
reate Grant is required before authentication can happen. Took a while to f=
igure out the right order to structure routing and middleware.
  • JSON Schema=C2=A0=
looks like it may simplify input JSON validation. Also useful for validatin=
g responses in automated testing. IETF IDs have not been picked up in a WG =
so far.
  • My HTML s=
kills suck
  • My ES6=
 knowledge is lacking



--000000000000b87db805a9c9d84c--


From nobody Mon Jul  6 12:01: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 043B83A0A51 for ; Mon,  6 Jul 2020 12:01: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, 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 EmFysIziPZO2 for ; Mon,  6 Jul 2020 12:01:32 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450: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 76C473A0A65 for ; Mon,  6 Jul 2020 12:01:30 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id t9so23225700lfl.5 for ; Mon, 06 Jul 2020 12:01:30 -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=aBhqmuJnQDiSEGCXa8qREvv4SivWTjoBoomrrXjNnt4=; b=r88odOou6hPAAW7NXmfDUkXRhNrpQl2osKc0wrBag9qsjEuN8myulgn670d/fj0Xzh m2ok3GRRRgW6K14STS/PNZmAA7zEFW7nxU1zO2zMWQNgjqAK0CuImeZbnVhV2Fi52Vr1 MhTQMgnS2qBDZCClrAz64fKizydxkS6zDZfoRsYTuJL0jE05Yls1C8tdDFT2lJAqQjNZ xLnaSwS1uxkru9dwqH/PMj6hI9m4DirLcTntP9+6Z4TGh8s47qPEgc2eLZmRLdpxpSRL fZm/u2VLavcyye8TEz+iXWBDoO8b35ziyX5R01ebPolQguP5i5l2ihPyWrRVXt8j6Fwz f1pQ==
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=aBhqmuJnQDiSEGCXa8qREvv4SivWTjoBoomrrXjNnt4=; b=CKJtj1X3nRDidQICEJgAqL/9hFinlQEHI7//5oaj9Vkm1jNK3NH7y8uAk+1DZlZmwr ZyInihWfw98sCioK/kTrK12gYJFfzqW1ONTZwK2WDNzEvCGp1bIgw40MIcB1o5eRTQX9 F0JHU+QjOyTiPcy1tKK4u6eEMU5fJ4Tr6p+fmmEgp2AnJmr8cGhK5WLyCDLtpdwlFHHu cRe/6EMtN74uM0an2fMNLNPS0jQEguVpfDxg0NtZkPjLGwVFk8TDzFBcC4cuQEaXEPRM 8jWS3NuP+gJ9SpJinUcqVe/U/WGAyMby61K5ZvnqW8EDFwpLxoaRtl5kxL33NTws3doj 1Y3Q==
X-Gm-Message-State: AOAM531Xgng/TNEf/9eGmsYehMKp6MvwC/nBaul1gDd7G44iEIqStBIu bo1uNYUcXiaDAQlGuWzM1+CZvFT7I82nYI1HZmvbszMy3f0=
X-Google-Smtp-Source: ABdhPJwxQkvcLI4tuBMJ3hz+gwZshc5bucuQcodELwAiRAP25q8eNOQRjOOGo2scOBMCupYBS7CDiK4F+WMimcpxW1Y=
X-Received: by 2002:ac2:518c:: with SMTP id u12mr30749968lfi.91.1594062088151;  Mon, 06 Jul 2020 12:01:28 -0700 (PDT)
MIME-Version: 1.0
From: Dick Hardt 
Date: Mon, 6 Jul 2020 12:00:51 -0700
Message-ID: 
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000083a5a405a9ca8039"
Archived-At: 
Subject: [Txauth] JSON Schema?
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, 06 Jul 2020 19:01:41 -0000

--00000000000083a5a405a9ca8039
Content-Type: text/plain; charset="UTF-8"

Hey

Does anyone have experience and/or opinions on JSON Schema [1]?

When implementing XAuth [2], I wrote a bunch of hand crafted JSON
validation code. JSON schema looks like it could be a great way to validate
input, and to create automated tests for output. It may also be a great way
to document the Grant Response JSON.

/ Dick

[1] https://json-schema.org/
[2] https://github.com/dickhardt/XAuth-poc

--00000000000083a5a405a9ca8039
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey

D=
oes anyone have experience and/or opinions=C2=A0on JSON Schema [1]?

When implementing XAuth [2], I wrote a bunch of hand craf=
ted JSON validation code. JSON schema looks like it could be a great way to=
 validate input, and to create automated tests for output. It may also be a=
 great way to document the Grant Response JSON.

/ =
Dick





--00000000000083a5a405a9ca8039--


From nobody Mon Jul  6 12:13: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 7979D3A09C6 for ; Mon,  6 Jul 2020 12:13:05 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=raSkuz8z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NRf/qnK/
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 DDAcfXl6YDYb for ; Mon,  6 Jul 2020 12:13:03 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999533A09C9 for ; Mon,  6 Jul 2020 12:13:03 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 97181B12; Mon,  6 Jul 2020 15:13:01 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 06 Jul 2020 15:13:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=5S4D972RUGbey4+0d6qYjVyia3ViN9u 5wC5w62JMKIM=; b=raSkuz8z7HNZzqIrhGJwJ09m1h+avyMYcvjjcBH4mH2IBZ0 47jsmqrliSaWElJOB2fwFRp9wW1lHxPugWcYEFbUIfLHcGzgpTF07WfGt1DmiiP7 SUhmPXFpXwF5J4D7/fRDoI7bzt1h7FsAYvfKzUl9in8fGoYTkHrNevH25bHtWZQi EWJbSFYDgOeeZuctCtL4KCrSLMeGHxgUYTyIyDhkZ96BV2kqfKh3BLJ9cai2fl0J URKt/ZfV0nnAmbDlNTWlE1xpEqWi9yaFsPg1aFCA6RLfEjH5hiFocC2DATOyMgZ+ 65HWTcxA2dDwo5Ro1iP4MuCcwjR/ekOJxlXkyIw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=5S4D97 2RUGbey4+0d6qYjVyia3ViN9u5wC5w62JMKIM=; b=NRf/qnK/OhtZTAVvHzJi6O IePzRjlbtNSMKsok1ygx934aoUzXN9GTAZFakwITL3zBIxR2VYXDeVP8PBn5xj2Z vuOBkZde78lilYwlU3lQDGVDfF8c7pawx832KM+f352WlEjDfrzGajbYTg0PSvoa Yt0o03EdTXVDGuSRrur7X7IBp0Qb4pNHRpCEiaKts7Ew8Z8M7+Ve7D9Rap2hqhlX JYeeH1xKw7UHjMfPmA4EAgTJdgqvaWGDwFQUy3+FwasfdzIyqkH9vF4lZgeeKh6X IaQYLwNstHz7UkxI5jaJ4J6XEJH2xLVTluyy0rP91MsfhINsks0QGaLyG+aARTQg ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudefgddufeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdghrgih nhgvucevhhgrnhhgfdcuoeifhigtsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtth gvrhhnpeeugfeiueelueduleehkeelhfefgffhieevvdehtefgheffkeefudfhheduteet hfenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhjshhonhdqshgthhgvmhgrrdhorh hgpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpeifhigtsehfrghsthhmrghilhdrfhhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BB230E00C9; Mon,  6 Jul 2020 15:13:00 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-Id: <0b47af92-76df-4ef7-9a74-11d94d9aaeb2@www.fastmail.com>
In-Reply-To: 
References: 
Date: Mon, 06 Jul 2020 15:12:40 -0400
From: "Wayne Chang" 
To: "Dick Hardt" , txauth@ietf.org
Content-Type: multipart/alternative; boundary=8cac1a1dddf34654a906b7d8270358e2
Archived-At: 
Subject: Re: [Txauth] JSON Schema?
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, 06 Jul 2020 19:13:06 -0000

--8cac1a1dddf34654a906b7d8270358e2
Content-Type: text/plain

I've used this approach to provide conformance tests to specifications. Here's a self-contained dir doing that:

https://github.com/decentralized-identity/presentation-exchange/tree/6b1b42338dd5ad96f67b7fee43187d96535b95a9/test/submission-requirements

It can then be run using `yarn run test`, as defined in:
https://github.com/decentralized-identity/presentation-exchange/blob/6b1b42338dd5ad96f67b7fee43187d96535b95a9/package.json#L20

Last note is that I see the v7 version with most supported implementations across different languages, so I've stuck with that one:
https://json-schema.org/draft-07/json-schema-release-notes.html

On Mon, Jul 6, 2020, at 3:00 PM, Dick Hardt wrote:
> Hey
> 
> Does anyone have experience and/or opinions on JSON Schema [1]?
> 
> When implementing XAuth [2], I wrote a bunch of hand crafted JSON validation code. JSON schema looks like it could be a great way to validate input, and to create automated tests for output. It may also be a great way to document the Grant Response JSON.
> 
> / Dick
> 
> [1] https://json-schema.org/
> [2] https://github.com/dickhardt/XAuth-poc
> 
> 
> -- 
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
> 

--8cac1a1dddf34654a906b7d8270358e2
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


I've used this =
approach to provide conformance tests to specifications. Here's a self-c=
ontained dir doing that:


It can then be run using `yarn run test`, as defined in=
:

Last note is that I see the v7 version with m=
ost supported implementations across different languages, so I've stuck =
with that one:

On Mon, Jul 6,=
 2020, at 3:00 PM, Dick Hardt wrote:
=

Hey

Does anyone have experience and/or=
 opinions on JSON Schema [1]?

When imp=
lementing XAuth [2], I wrote a bunch of hand crafted JSON validation cod=
e. JSON schema looks like it could be a great way to validate input, and=
 to create automated tests for output. It may also be a great way to doc=
ument the Grant Response JSON.

-- 
Txauth mailing list



--8cac1a1dddf34654a906b7d8270358e2--


From nobody Mon Jul  6 12:18: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 CC2CB3A09D3 for ; Mon,  6 Jul 2020 12:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level: 
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 AOzJSmWOKDxJ for ; Mon,  6 Jul 2020 12:17:45 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80EA03A09BE for ; Mon,  6 Jul 2020 12:17:44 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d72 with ME id zvHe220094FMSmm03vHe5q; Mon, 06 Jul 2020 21:17:42 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 06 Jul 2020 21:17:42 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt 
Cc: "txauth@ietf.org" , The IESG , Roman Danyliw 
References: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr> 
From: Denis 
Message-ID: 
Date: Mon, 6 Jul 2020 21:17:37 +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="------------78F9E1D443D5CDE53B855480"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Support of FIDO and data minimization by RSs
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, 06 Jul 2020 19:17:48 -0000

This is a multi-part message in MIME format.
--------------78F9E1D443D5CDE53B855480
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Dick,

Congratulations ! You made a good guess (but the guess was easy): my 
approach is indeed privacy related.

_Note_: Since it is close to the end of the day in my time zone (and 
since it is the last day for comments to the charter),
I copy both the IESG and Roman so that they can know that GNAP should 
also consider a*bridge with FIDO*.

I have several goals:

    1 - make a bridge with FIDO U2F (I will illustrate this with a
    specific scenario).

    2 - prevent every AS to know which RSs are going to be accessed or
    which kind of operation the client will be doing.
         This is to prevent an AS to act as "Big Brother".

    3 - apply both "privacy by default" and "data minimization" (when
    the user authenticates it may authenticate using FIDO or
          by presenting one or more access tokens. Then after, the
    necessary attributes that are necessary to perform a given operation
         are only requested and released at the time they are indeed
    needed to perform the given operation (i.e. they are not released
         when the user logs on).

    4 - the proposed RS Authorization algorithm allows a great
    flexibility, in particular it supports FIDO and different attributes
          from different ASs may be requested by the RS.

    5 - the rules associated with the RS Authorization algorithm are
    making these rules only available at the time the client indicates
          which operation it is willing to perform (i.e. by default,
    they are not public).

    6 - access tokens are NOT OPAQUE to the clients so that every client
    can make sure that their content reflects what has been requested.

*A simple scenario to illustrate*

A student wants to apply for a new university. He connects to the RS of 
the University. He first creates an account using FIDO.
He then selects the button "Preliminary information for applying to the 
university". He is asked to enter two categories of information:

      * citizenship information and
      * prior graduations.

The student can interrupt the preliminary registration procedure at any 
time and continue it at any time later on.

When the student is finished, it selects the button "Application to the 
university".

    The university RS "reads" the citizen ship of the student and let
    know to the student whether a paper form
    and/or an electronic form of the identity of the student may be
    provided. Let us assume the later case and that
    the student is a citizen from France. Then the university RS
    indicates which French banks or other French organisations
    are trusted to provide an access token. The client checks whether
    this list fits one of the AS with which it has a relationship.

    The university RS "reads" the prior graduations of the student and
    then let know to the student whether a paper form
    and/or an electronic form of the last graduation of the student may
    be provided. Let us assume the later case and
    that the student is from Yale University. Then the university
    indicates the address of the AS from Yale University.
    If the student is indeed from Yale University, he should be able to
    provide the requested access token.

Such scenario which follows some privacy principles cannot be 
constructed "/after the design"/ (it will not happen by magic or by 
accident)
This is why the approach is called "privacy by design".

Denis

> Hi Denis
>
> Would you provide some background on what you are trying to solve with 
> this? I'm guessing it is privacy related.
>
> Perhaps a use case would help make it more concrete?
>
> /Dick
>
>
> On Mon, Jul 6, 2020 at 5:39 AM Denis  > wrote:
>
>     **eThis is a new thread: a proposal for a RS authorization
>     algorithmand a way to support FIDO by RSs
>
>     In order to support the privacy principle of "data minimization"
>     by RSs, only the attributes that are strictly necessary to perform
>     an operation requested by a client should be requested by the RS.
>
>     When a client wants to authenticate, it will usually be informed
>     by the RS on how to do it (see more details about two exceptions
>     at the end of this email).
>     Which conditions are needed to perform other operations will only
>     be disclosed to authenticated users at the time they are willing
>     to perform an operation.
>
>     Two categories of operations will be considered: authentication
>     operations and other operations.
>
>     For the "authentication" operation, two cases will be supported:
>
>     -FIDO U2F or
>
>     -one or more attributes from one or more ASs.
>
>     In the second case, an access will be granted by a RS based on an
>     mathematical expression which is formed using some combination of
>     ANDand ORconditions.
>
>     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 /a Condition /:
>
>     /Condition x/= { AS identifier + set of attributes types +
>     optional scope identifier }
>
>     The presence of the /optional/ scope identifier allows to provide
>     a backward compatibility with ASs from the OAuth 2.0. world:
>     the optional scope identifier is only present when a bilateral
>     relationship has been established between a RS and an AS prior
>     to any access (/and will continue to be maintained/) using
>     "out-of-bands" means.
>
>     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.
>
>     An example is used to explain the concepts.
>
>     "Operation(s)/ Mathematical expression" pairs managed by the RO of
>     a RS.
>
>     *Operation*
>
>     	
>
>     *Mathematical expression*
>
>     Authentication
>
>     	
>
>     /Condition 1/OR/Condition 2/
>
>     Operation A OROperation Z
>
>     	
>
>     /Condition 3/AND/Condition 4/
>
>     Conditions table:
>
>     Condition 1
>
>     	
>
>     FIDO U2F 1.2
>
>     	
>
>     -
>
>     	
>
>     -
>
>     Condition 2
>
>     	
>
>     AS 1
>
>     	
>
>     set 1 of attributes types
>
>     	
>
>     Condition 3
>
>     	
>
>     AS 4
>
>     	
>
>     set 2 of attributes types
>
>     	
>
>     scope identifier : 21
>
>     Condition 4
>
>     	
>
>     AS 9
>
>     	
>
>     set 3 of attributes types
>
>     	
>
>     -
>
>     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 the set of attributes types which are indicated for a
>     given AS
>     are appropriate to him or not and then select that AS if it has a
>     relationship with it.
>
>     In this example, one mathematical expression for the combination
>     of conditions using AND and OR operators is "/Condition
>     3/OR/Condition 4",//
>     which means that///some types of attributes from AS 4 AND some
>     other types of attributes from AS 9 are both needed by RSx to
>     perform on RSx
>     either the Operation A or the Operation Z.
>
>     In this example, RS 1 and AS 4 have established a bilateral
>     relationship (and have agreed to define and use scope identifiers)
>     whereas RS 1 and AS 9 have not established any bilateral
>     relationship prior to the exchange.
>
>     The user makes up his mind whether the attributes requested by AS
>     1 and AS 9 are reasonable and if so, requests two access tokens:
>     one to AS 4 and another one to AS 9.
>
>     For AS 4, the client shall use the scope identifier with the value 21.
>     For AS 9, the client shall use the set 3 of attributes types
>     indicated in the Condition 4.
>
>     In order to save one exchange, a RS could publicly publish how its
>     clients can authenticate.
>     However,  it is also possible to consider no guidance at all: in
>     such a case, using "out-of-bands" means, the clients should know
>     how to authenticate.
>
>     Denis
>
>     -- 
>     Txauth mailing list
>     Txauth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/txauth
>


--------------78F9E1D443D5CDE53B855480
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Dick,

    


    

    
Congratulations ! You made a good guess
      (but the guess was easy): my approach is indeed privacy related.

    


    

    
Note: Since it is close to the
      end of the day in my time zone (and since it is the last day for
      comments to the charter), 

      I copy both the IESG and Roman so that they can know that GNAP
      should also consider a bridge with FIDO.

    

    
I have several goals:

    

      
1 - make a bridge with FIDO U2F (I
        will illustrate this with a specific scenario).

      


      

      
2 - prevent every AS to know which
        RSs are going to be accessed or which kind of operation the
        client will be doing.

            This is to prevent an AS to act as "Big Brother".

      

      


      

      
3 - apply both "privacy by default"
        and "data minimization" (when the user authenticates it may
        authenticate using FIDO or 

             by presenting one or more access tokens. Then after, the
        necessary attributes that are necessary to perform a given
        operation 

            are only requested and released at the time they are indeed
        needed to perform the given operation (i.e. they are not
        released 

            when the user logs on).

      


      

      
4 - the proposed RS Authorization
        algorithm allows a great flexibility, in particular it supports
        FIDO and different attributes 

             from different ASs may be requested by the RS.

      


      

      
5 - the rules associated with the RS
        Authorization algorithm are making these rules only available at
        the time the client indicates 

             which operation it is willing to perform (i.e. by default,
        they are not public).

      


      

      
6 - access tokens are NOT OPAQUE to
        the clients so that every client can make sure that their
        content reflects what has been requested.

      

    

    
 A simple scenario to illustrate

    

    


    

    
A student wants to apply for a new
      university. He connects to the RS of the University. He first
      creates an account using FIDO.

      He then selects the button "Preliminary information for applying
      to the university". He is asked to enter two categories of
      information:

    

      
    
        
  • citizenship information and 
    • 
        
  • prior graduations.
    • 
      

    

    
The student can interrupt the
      preliminary registration procedure at any time and continue it at
      any time later on.

    


    

    
When the student is finished, it
      selects the button "Application to the university".

    

    

      
The university RS "reads" the citizen
        ship of the student and let know to the student whether a paper
        form 

        and/or an electronic form of the identity of the student may be
        provided. Let us assume the later case and that 

        the student is a citizen from France. Then the university RS
        indicates which French banks or other French organisations 

        are trusted to provide an access token. The client checks
        whether this list fits one of the AS with which it has a
        relationship.

      

      


      

      The university RS "reads" the prior graduations of the student and
      then let know to the student whether a paper form 

      and/or an electronic form of the last graduation of the student
      may be provided. Let us assume the later case and 

      that the student is from Yale University. Then the university
      indicates the address of the AS from Yale University.

      If the student is indeed from Yale University, he should be able
      to provide the requested access token.

    

    
Such scenario which follows some privacy principles cannot be
      constructed "after the design" (it will not happen by magic
      or by accident)

      This is why the approach is called "privacy by design".

    
Denis

    

    

      
Hi Denis
        


        

        
Would you provide some background on what you are trying to
          solve with this? I'm guessing it is privacy related. 

        


        

        
Perhaps a use case would help make it more concrete?

        


        

        
/Dick

        


        

      

      

      

        
On Mon, Jul 6, 2020 at 5:39 AM
          Denis <denis.ietf@free.fr> wrote:

        

        

          

            
 eThis is a new
                thread: a proposal for a RS authorization algorithm and a way to
                support FIDO by RSs

              

            
In order to support the privacy principle
                of "data minimization" by RSs, only the attributes that
                are strictly necessary to perform 

                an operation requested by a client should be requested
                by the RS.

            
When a client wants to authenticate, it
                will usually be informed by the RS on how to do it (see
                more details about two exceptions at the end of this
                email). 

                Which conditions are needed to perform other operations
                will only be disclosed to authenticated users at the
                time they are willing to perform an operation.

            
Two categories of operations will be
                considered: authentication operations and other
                operations.

              

            
 For the "authentication" operation, two
                cases will be supported: 

            
-         
                FIDO U2F or 

            
-         
                one or more attributes from one or more
                ASs. 

            
In the second case, 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 a
                  Condition :

            
Condition x = { AS
                identifier + set of attributes types + optional scope
                identifier } 

              

            
The presence of the optional scope
                identifier allows to provide a backward compatibility
                with ASs from the OAuth 2.0. world: 

                the optional scope identifier is only present when a
                bilateral relationship has been established between a RS
                and an AS prior 

                to any access (and will continue to be maintained)
                using "out-of-bands" means. 

              

            
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.

            
An example is used to explain the concepts.

            
"Operation(s)/ Mathematical expression"
                pairs managed by the RO of a RS. 

              

            

              
                

                  
                    
Operation

                  		
                  
                    
Mathematical
                          expression

                  		
                

                

                  
                    
Authentication

                  		
                  
                    
Condition 1 OR Condition 2

                  		
                

                

                  
                    
Operation A OR Operation
                        Z

                  		
                  
                    
Condition 3 AND Condition 4

                  		
                

              
            

            
Conditions table:
              

            

              
                

                  
                    
Condition 1

                  		
                  
                    
FIDO
                        U2F 1.2

                  		
                  
                    
-

                  		
                  
                    
-

                  		
                

                

                  
                    
Condition 2

                  		
                  
                    
AS 1

                  		
                  
                    
set 1 of attributes types

                  		
                  
                    
 

                  		
                

                

                  
                    
Condition 3

                  		
                  
                    
AS 4

                  		
                  
                    
set 2 of attributes types

                  		
                  
                    
scope identifier : 21

                  		
                

                

                  
                    
Condition 4

                  		
                  
                    
AS 9

                  		
                  
                    
set 3 of attributes types

                  		
                  
                    
-

                  		
                

              
            

            
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 the set of attributes
                  types which are indicated for a given AS 

                are appropriate to him or not and then select that AS if
                it has a relationship with it.

            
In this example, one mathematical
                expression for the combination of conditions using AND
                and OR operators is "Condition
                    3 OR Condition 4", 

                    which means that some types of
                attributes from AS 4 AND
                some other types of attributes from AS 9 are both needed
                by RSx to perform on RSx 

                either the Operation A or the Operation Z. 

            
In this example, RS 1 and AS 4 have
                established a bilateral relationship (and have agreed to
                define and use scope identifiers) 

                whereas RS 1 and AS 9 have not established any bilateral
                relationship prior to the exchange. 

              

            
The user makes up his mind whether the
                attributes requested by AS 1 and AS 9 are reasonable and
                if so, requests two access tokens: 

                one to AS 4 and another one to AS 9.

            
For AS 4, the client shall use the
                scope identifier with the value 21.

                For AS 9, the client shall use the set 3 of attributes
                types indicated in the Condition 4.

            
In order to save one exchange, a RS could
                publicly publish how its clients can authenticate. 

                However,  it is also possible to consider no guidance at
                all: in such a case, using "out-of-bands" means, the
                clients should know how to authenticate.

            
Denis 

              

          

          -- 

          Txauth mailing list

          Txauth@ietf.org

          https://www.ietf.org/mailman/listinfo/txauth

        

      

    

    


    

  


--------------78F9E1D443D5CDE53B855480--


From nobody Mon Jul  6 12:54: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 D958C3A09F0 for ; Mon,  6 Jul 2020 12:54: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 JJo0JsMlxQ5D for ; Mon,  6 Jul 2020 12:54: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 E550B3A09EF for ; Mon,  6 Jul 2020 12:54:09 -0700 (PDT)
Received: from [192.168.1.7] (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 066Js7qU018503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jul 2020 15:54:07 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_59150599-5897-4950-97AE-CD7C8022CE5A"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 6 Jul 2020 15:54:07 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References: 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] JSON Schema?
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, 06 Jul 2020 19:54:12 -0000

--Apple-Mail=_59150599-5897-4950-97AE-CD7C8022CE5A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think it=E2=80=99s potentially ok for defining the specification and =
its boundaries, but it is not ok if it ends up requiring client and AS =
developers to use JSON Schema directly to implement anything. In other =
words, you should be a able to still write a bunch of hand-crafted =
validation code to make it work, or to use a parser that drops things =
into structured objects for you (like my Java implementation of XYZ =
does). Much like my argument against JSONLD, I think anything beyond a =
JSON parser=20

Another aspect that I don=E2=80=99t like about JSON schema is that it =
makes it difficult to describe things in terms of polymorphic data =
types. Polymorphism in the protocol is an important part of the XYZ =
proposal=E2=80=99s design, and as a feature it directly addresses a =
number of the items you found when doing your XAuth implementation, like =
parsing OAuth scopes and dealing with the authorization/authorizations =
mutually-exclusive oddness that you mentioned. I strongly believe that =
GNAP should make use of a polymorphic protocol structure for these and =
other reasons. Polymorphism is a built-in feature of the JSON data =
model, and it=E2=80=99s also fully possible to support under CBOR and =
other data serialization languages. Even JWT most famously uses =
polymorphism for the =E2=80=9Caud=E2=80=9D field, which can be a string =
or an array of strings depending on context, all with clear semantics. =
Defining that in JSON schema is not impossible, but it=E2=80=99s not =
easy.

So overall, I think JSON schema is probably not a good fit here.

 =E2=80=94 Justin

> On Jul 6, 2020, at 3:00 PM, Dick Hardt  wrote:
>=20
> Hey
>=20
> Does anyone have experience and/or opinions on JSON Schema [1]?
>=20
> When implementing XAuth [2], I wrote a bunch of hand crafted JSON =
validation code. JSON schema looks like it could be a great way to =
validate input, and to create automated tests for output. It may also be =
a great way to document the Grant Response JSON.
>=20
> / Dick
>=20
> [1] https://json-schema.org/ 
> [2] https://github.com/dickhardt/XAuth-poc =

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


--Apple-Mail=_59150599-5897-4950-97AE-CD7C8022CE5A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
think it=E2=80=99s potentially ok for defining the specification and its =
boundaries, but it is not ok if it ends up requiring client and AS =
developers to use JSON Schema directly to implement anything. In other =
words, you should be a able to still write a bunch of hand-crafted =
validation code to make it work, or to use a parser that drops things =
into structured objects for you (like my Java implementation of XYZ =
does). Much like my argument against JSONLD, I think anything beyond a =
JSON parser 

Another aspect that I don=E2=80=99t like about JSON schema is =
that it makes it difficult to describe things in terms of polymorphic =
data types. Polymorphism in the protocol is an important part of the XYZ =
proposal=E2=80=99s design, and as a feature it directly addresses a =
number of the items you found when doing your XAuth implementation, like =
parsing OAuth scopes and dealing with the authorization/authorizations =
mutually-exclusive oddness that you mentioned. I strongly believe that =
GNAP should make use of a polymorphic protocol structure for these and =
other reasons. Polymorphism is a built-in feature of the JSON data =
model, and it=E2=80=99s also fully possible to support under CBOR and =
other data serialization languages. Even JWT most famously uses =
polymorphism for the =E2=80=9Caud=E2=80=9D field, which can be a string =
or an array of strings depending on context, all with clear semantics. =
Defining that in JSON schema is not impossible, but it=E2=80=99s not =
easy.

So =
overall, I think JSON schema is probably not a good fit here.

 =E2=80=94 =
Justin

On Jul 6, 2020, at 3:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey

Does anyone have experience and/or opinions on JSON =
Schema [1]?

When=
 implementing XAuth [2], I wrote a bunch of hand crafted JSON validation =
code. JSON schema looks like it could be a great way to validate input, =
and to create automated tests for output. It may also be a great way to =
document the Grant Response JSON.

/ Dick

[1] https://json-schema.org/
[2] https://github.com/dickhardt/XAuth-poc



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

=

--Apple-Mail=_59150599-5897-4950-97AE-CD7C8022CE5A--


From nobody Mon Jul  6 12:55: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 0E4D93A09DE; Mon,  6 Jul 2020 12:55:03 -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 03mp3T56oVIk; Mon,  6 Jul 2020 12:55: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 05C423A09EF; Mon,  6 Jul 2020 12:54:59 -0700 (PDT)
Received: from [192.168.1.7] (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 066Js7qV018503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jul 2020 15:54:54 -0400
From: Justin Richer 
Message-Id: <46705E7E-D657-4CF1-80DA-0ADDFD6D8B41@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8ED051D4-D59D-4B38-912B-955E4BFD932E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 6 Jul 2020 15:54:54 -0400
In-Reply-To: 
Cc: Dick Hardt , "rdd@cert.org" , "txauth@ietf.org" , The IESG 
To: Denis 
References: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>  
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Support of FIDO and data minimization by RSs
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, 06 Jul 2020 19:55:03 -0000

--Apple-Mail=_8ED051D4-D59D-4B38-912B-955E4BFD932E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think removing the opacity of access tokens to clients is going to be =
a non-starter for most of this community.=20

 =E2=80=94 Justin

> On Jul 6, 2020, at 3:17 PM, Denis  wrote:
>=20
> Hi Dick,
>=20
> Congratulations ! You made a good guess (but the guess was easy): my =
approach is indeed privacy related.
>=20
> Note: Since it is close to the end of the day in my time zone (and =
since it is the last day for comments to the charter),=20
> I copy both the IESG and Roman so that they can know that GNAP should =
also consider a bridge with FIDO.
>=20
> I have several goals:
> 1 - make a bridge with FIDO U2F (I will illustrate this with a =
specific scenario).
>=20
> 2 - prevent every AS to know which RSs are going to be accessed or =
which kind of operation the client will be doing.
>     This is to prevent an AS to act as "Big Brother".
>=20
> 3 - apply both "privacy by default" and "data minimization" (when the =
user authenticates it may authenticate using FIDO or=20
>      by presenting one or more access tokens. Then after, the =
necessary attributes that are necessary to perform a given operation=20
>     are only requested and released at the time they are indeed needed =
to perform the given operation (i.e. they are not released=20
>     when the user logs on).
>=20
> 4 - the proposed RS Authorization algorithm allows a great =
flexibility, in particular it supports FIDO and different attributes=20
>      from different ASs may be requested by the RS.
>=20
> 5 - the rules associated with the RS Authorization algorithm are =
making these rules only available at the time the client indicates=20
>      which operation it is willing to perform (i.e. by default, they =
are not public).
>=20
> 6 - access tokens are NOT OPAQUE to the clients so that every client =
can make sure that their content reflects what has been requested.
> A simple scenario to illustrate
>=20
> A student wants to apply for a new university. He connects to the RS =
of the University. He first creates an account using FIDO.
> He then selects the button "Preliminary information for applying to =
the university". He is asked to enter two categories of information:
> citizenship information and
> prior graduations.
> The student can interrupt the preliminary registration procedure at =
any time and continue it at any time later on.
>=20
> When the student is finished, it selects the button "Application to =
the university".
> The university RS "reads" the citizen ship of the student and let know =
to the student whether a paper form=20
> and/or an electronic form of the identity of the student may be =
provided. Let us assume the later case and that=20
> the student is a citizen from France. Then the university RS indicates =
which French banks or other French organisations=20
> are trusted to provide an access token. The client checks whether this =
list fits one of the AS with which it has a relationship.
>=20
> The university RS "reads" the prior graduations of the student and =
then let know to the student whether a paper form=20
> and/or an electronic form of the last graduation of the student may be =
provided. Let us assume the later case and=20
> that the student is from Yale University. Then the university =
indicates the address of the AS from Yale University.
> If the student is indeed from Yale University, he should be able to =
provide the requested access token.
> Such scenario which follows some privacy principles cannot be =
constructed "after the design" (it will not happen by magic or by =
accident)
> This is why the approach is called "privacy by design".
>=20
> Denis
>=20
>> Hi Denis
>>=20
>> Would you provide some background on what you are trying to solve =
with this? I'm guessing it is privacy related.=20
>>=20
>> Perhaps a use case would help make it more concrete?
>>=20
>> /Dick
>>=20
>>=20
>> On Mon, Jul 6, 2020 at 5:39 AM Denis > wrote:
>> eThis is a new thread: a proposal for a RS authorization algorithm =
and a way to support FIDO by RSs
>>=20
>> In order to support the privacy principle of "data minimization" by =
RSs, only the attributes that are strictly necessary to perform=20
>> an operation requested by a client should be requested by the RS.
>>=20
>> When a client wants to authenticate, it will usually be informed by =
the RS on how to do it (see more details about two exceptions at the end =
of this email).=20
>> Which conditions are needed to perform other operations will only be =
disclosed to authenticated users at the time they are willing to perform =
an operation.
>>=20
>> Two categories of operations will be considered: authentication =
operations and other operations.
>>=20
>> For the "authentication" operation, two cases will be supported:
>>=20
>> -          FIDO U2F or
>> -          one or more attributes from one or more ASs.
>> In the second case, an access will be granted by a RS based on an =
mathematical expression which is formed using some combination of AND =
and OR conditions.
>>=20
>> Examples of combinations:
>>=20
>> 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=20
>>=20
>> The following notation is being used for a Condition :
>>=20
>> Condition x =3D { AS identifier + set of attributes types + optional =
scope identifier }=20
>>=20
>> The presence of the optional scope identifier allows to provide a =
backward compatibility with ASs from the OAuth 2.0. world:=20
>> the optional scope identifier is only present when a bilateral =
relationship has been established between a RS and an AS prior=20
>> to any access (and will continue to be maintained) using =
"out-of-bands" means.=20
>>=20
>> Each RS internally constructs an authorization table with the =
following content:
>>=20
>> 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 =
conditions.
>> An example is used to explain the concepts.
>>=20
>> "Operation(s)/ Mathematical expression" pairs managed by the RO of a =
RS.=20
>>=20
>> Operation
>>=20
>> Mathematical expression
>>=20
>> Authentication
>>=20
>> Condition 1 OR Condition 2
>>=20
>> Operation A OR Operation Z
>>=20
>> Condition 3 AND Condition 4
>>=20
>> Conditions table:
>>=20
>> Condition 1
>>=20
>> FIDO U2F 1.2
>>=20
>> -
>>=20
>> -
>>=20
>> Condition 2
>>=20
>> AS 1
>>=20
>> set 1 of attributes types
>>=20
>> =20
>> Condition 3
>>=20
>> AS 4
>>=20
>> set 2 of attributes types
>>=20
>> scope identifier : 21
>>=20
>> Condition 4
>>=20
>> AS 9
>>=20
>> set 3 of attributes types
>>=20
>> -
>>=20
>> Given the operation selected by the client, the RS returns the =
appropriate mathematical expression and only the associated conditions=20=

>> used in that mathematical expression. The user may then decide =
whether the set of attributes types which are indicated for a given AS=20=

>> are appropriate to him or not and then select that AS if it has a =
relationship with it.
>>=20
>> In this example, one mathematical expression for the combination of =
conditions using AND and OR operators is "Condition 3 OR Condition 4",=20=

>> which means that some types of attributes from AS 4 AND some other =
types of attributes from AS 9 are both needed by RSx to perform on RSx=20=

>> either the Operation A or the Operation Z.
>>=20
>> In this example, RS 1 and AS 4 have established a bilateral =
relationship (and have agreed to define and use scope identifiers)=20
>> whereas RS 1 and AS 9 have not established any bilateral relationship =
prior to the exchange.=20
>>=20
>> The user makes up his mind whether the attributes requested by AS 1 =
and AS 9 are reasonable and if so, requests two access tokens:=20
>> one to AS 4 and another one to AS 9.
>>=20
>> For AS 4, the client shall use the scope identifier with the value =
21.
>> For AS 9, the client shall use the set 3 of attributes types =
indicated in the Condition 4.
>>=20
>> In order to save one exchange, a RS could publicly publish how its =
clients can authenticate.=20
>> However,  it is also possible to consider no guidance at all: in such =
a case, using "out-of-bands" means, the clients should know how to =
authenticate.
>>=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


--Apple-Mail=_8ED051D4-D59D-4B38-912B-955E4BFD932E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
think removing the opacity of access tokens to clients is going to be a =
non-starter for most of this community. 

 =E2=80=94 Justin

On Jul 6, 2020, at 3:17 PM, Denis <denis.ietf@free.fr> =
wrote:



 =20
  

    
Hi Dick,

    


    

    
Congratulations ! You made a good =
guess
      (but the guess was easy): my approach is indeed privacy =
related.

    


    

    
Note: Since it is =
close to the
      end of the day in my time zone (and since it is the last day for
      comments to the charter), 

      I copy both the IESG and Roman so that they can know that GNAP
      should also consider a bridge with FIDO.

    

    
I have several goals:

    

      
1 - make a bridge with FIDO U2F (I
        will illustrate this with a specific scenario).

      


      

      
2 - prevent every AS to know which
        RSs are going to be accessed or which kind of operation the
        client will be doing.

            This is to prevent an AS to act as "Big =
Brother".

      

      


      

      
3 - apply both "privacy by default"
        and "data minimization" (when the user authenticates it may
        authenticate using FIDO or 

             by presenting one or more access tokens. =
Then after, the
        necessary attributes that are necessary to perform a given
        operation 

            are only requested and released at the time =
they are indeed
        needed to perform the given operation (i.e. they are not
        released 

            when the user logs on).

      


      

      
4 - the proposed RS Authorization
        algorithm allows a great flexibility, in particular it supports
        FIDO and different attributes 

             from different ASs may be requested by =
the RS.

      


      

      
5 - the rules associated with the =
RS
        Authorization algorithm are making these rules only available at
        the time the client indicates 

             which operation it is willing to perform =
(i.e. by default,
        they are not public).

      


      

      
6 - access tokens are NOT OPAQUE to
        the clients so that every client can make sure that their
        content reflects what has been requested.

      

    

    
 A simple scenario to =
illustrate

    

    


    

    
A student wants to apply for a new
      university. He connects to the RS of the University. He first
      creates an account using FIDO.

      He then selects the button "Preliminary information for applying
      to the university". He is asked to enter two categories of
      information:

    

      
    
        
  • citizenship information and 
    • 
        
  • prior graduations.
    • 
      

    

    
The student can interrupt the
      preliminary registration procedure at any time and continue it at
      any time later on.

    


    

    
When the student is finished, it
      selects the button "Application to the university".

    

    

      
The university RS "reads" the =
citizen
        ship of the student and let know to the student whether a paper
        form 

        and/or an electronic form of the identity of the student may be
        provided. Let us assume the later case and that 

        the student is a citizen from France. Then the university RS
        indicates which French banks or other French organisations 

        are trusted to provide an access token. The client checks
        whether this list fits one of the AS with which it has a
        relationship.

      

      


      

      The university RS "reads" the prior graduations of the student and
      then let know to the student whether a paper form 

      and/or an electronic form of the last graduation of the student
      may be provided. Let us assume the later case and 

      that the student is from Yale University. Then the university
      indicates the address of the AS from Yale University.
=

      If the student is indeed from Yale University, he should be able
      to provide the requested access token.

    
Such scenario which follows some privacy =
principles cannot be
      constructed "after the design" (it will not =
happen by magic
      or by accident)

      This is why the approach is called "privacy by design".
Denis

    

    

      
Hi Denis
        


        

        
Would you provide some background on what you =
are trying to
          solve with this? I'm guessing it is privacy =
related. 

        


        

        
Perhaps a use case would help make it more =
concrete?

        


        

        
/Dick

        


        

      

      

      

        
On Mon, Jul 6, 2020 at =
5:39 AM
          Denis <denis.ietf@free.fr> wrote:

        

        

          
 eThis is a new
                thread: a proposal for a RS authorization =
algorithm and a way to
                support FIDO by RSs

              
In order to =
support the privacy principle
                of "data minimization" by RSs, only the attributes that
                are strictly necessary to perform 

                an operation requested by a client should be requested
                by the RS.
When a client =
wants to authenticate, it
                will usually be informed by the RS on how to do it (see
                more details about two exceptions at the end of this
                email). 

                Which conditions are needed to perform other operations
                will only be disclosed to authenticated users at the
                time they are willing to perform an =
operation.
Two categories of =
operations will be
                considered: authentication operations and other
                operations.

              
 For the =
"authentication" operation, two
                cases will be supported: 
-         
                FIDO U2F=
 or 
-         
                one or more attributes from one or more
                ASs. 
In the second =
case, 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 a
                  Condition :
Condition x =3D { AS
                identifier + set of attributes types + optional scope
                identifier } 

              
The presence of =
the optional scope
                identifier allows to provide a backward compatibility
                with ASs from the OAuth 2.0. world: 

                the optional scope identifier is only present when a
                bilateral relationship has been established between a RS
                and an AS prior 

                to any access (and will continue to be =
maintained)
                using "out-of-bands" means. 

              
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
                conditions.
An example is used =
to explain the concepts.
"Operation(s)/ =
Mathematical expression"
                pairs managed by the RO of a RS. 

              

            

              
                

                  
Operation

                  		
                  
Mathematical
                          expression

                  		
                

                

                  
Authentication

                  		
                  
Condition =
1 OR Condition =
2

                  		
                

                

                  
Operation A OR =
Operation
                        Z

                  		
                  
Condition =
3 AND Condition =
4

                  		
                

              
            
Conditions table:
              

            

              
                

                  
Condition=
 1

                  		
                  
FIDO
                        U2F 1.2

                  		
                  
-

                  		
                  
-

                  		
                

                

                  
Condition=
 2

                  		
                  
AS 1

                  		
                  
set 1 of =
attributes types

                  		
                  
 

                  		
                

                

                  
Condition=
 3

                  		
                  
AS 4

                  		
                  
set 2 of =
attributes types

                  		
                  
scope identifier : =
21

                  		
                

                

                  
Condition=
 4

                  		
                  
AS 9

                  		
                  
set 3 of =
attributes types

                  		
                  
-

                  		
                

              
            
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 the set of attributes
                  types which are indicated for a given AS 

                are appropriate to him or not and then select that AS if
                it has a relationship with it.
In this example, one mathematical
                expression for the combination of conditions using AND
                and OR operators is "Condition
                    3 OR Condition 4", 

                    which means that some =
types of
                attributes from AS 4 AND
                some other types of attributes from AS 9 are both needed
                by RSx to perform on RSx 

                either the Operation A or the Operation Z. 
In this example, RS 1 and AS 4 have
                established a bilateral relationship (and have agreed to
                define and use scope identifiers) 

                whereas RS 1 and AS 9 have not established any bilateral
                relationship prior to the exchange. 

              
The user makes up =
his mind whether the
                attributes requested by AS 1 and AS 9 are reasonable and
                if so, requests two access tokens: 

                one to AS 4 and another one to AS 9.
For AS 4, the client shall use the
                scope identifier with the value 21.

                For AS 9, the client shall use the set 3 of attributes
                types indicated in the Condition 4.
In order to save one exchange, a RS could
                publicly publish how its clients can authenticate. 

                However,  it is also possible to consider no =
guidance at
                all: in such a case, using "out-of-bands" means, the
                clients should know how to authenticate.
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=_8ED051D4-D59D-4B38-912B-955E4BFD932E--


From nobody Mon Jul  6 12:55: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 CB61B3A09F4 for ; Mon,  6 Jul 2020 12:55:56 -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 xB8D1dlxaT_4 for ; Mon,  6 Jul 2020 12:55:55 -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 266A13A09F0 for ; Mon,  6 Jul 2020 12:55:54 -0700 (PDT)
Received: from [192.168.1.7] (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 066Js7qW018503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jul 2020 15:55:52 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_AB2B658A-C92A-419C-96BC-5F2687EF8757"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 6 Jul 2020 15:55:52 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:  
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] JSON Schema?
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, 06 Jul 2020 19:55:57 -0000

--Apple-Mail=_AB2B658A-C92A-419C-96BC-5F2687EF8757
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jul 6, 2020, at 3:54 PM, Justin Richer  wrote:
>=20
> I think it=E2=80=99s potentially ok for defining the specification and =
its boundaries, but it is not ok if it ends up requiring client and AS =
developers to use JSON Schema directly to implement anything. In other =
words, you should be a able to still write a bunch of hand-crafted =
validation code to make it work, or to use a parser that drops things =
into structured objects for you (like my Java implementation of XYZ =
does). Much like my argument against JSONLD, I think anything beyond a =
JSON parser=20

=E2=80=A6 and generator is too much to ask. (Sorry, hit send too early.)

>=20
> Another aspect that I don=E2=80=99t like about JSON schema is that it =
makes it difficult to describe things in terms of polymorphic data =
types. Polymorphism in the protocol is an important part of the XYZ =
proposal=E2=80=99s design, and as a feature it directly addresses a =
number of the items you found when doing your XAuth implementation, like =
parsing OAuth scopes and dealing with the authorization/authorizations =
mutually-exclusive oddness that you mentioned. I strongly believe that =
GNAP should make use of a polymorphic protocol structure for these and =
other reasons. Polymorphism is a built-in feature of the JSON data =
model, and it=E2=80=99s also fully possible to support under CBOR and =
other data serialization languages. Even JWT most famously uses =
polymorphism for the =E2=80=9Caud=E2=80=9D field, which can be a string =
or an array of strings depending on context, all with clear semantics. =
Defining that in JSON schema is not impossible, but it=E2=80=99s not =
easy.
>=20
> So overall, I think JSON schema is probably not a good fit here.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 6, 2020, at 3:00 PM, Dick Hardt > wrote:
>>=20
>> Hey
>>=20
>> Does anyone have experience and/or opinions on JSON Schema [1]?
>>=20
>> When implementing XAuth [2], I wrote a bunch of hand crafted JSON =
validation code. JSON schema looks like it could be a great way to =
validate input, and to create automated tests for output. It may also be =
a great way to document the Grant Response JSON.
>>=20
>> / Dick
>>=20
>> [1] https://json-schema.org/ 
>> [2] https://github.com/dickhardt/XAuth-poc =

>>=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=_AB2B658A-C92A-419C-96BC-5F2687EF8757
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On =
Jul 6, 2020, at 3:54 PM, Justin Richer <jricher@mit.edu> =
wrote:



I think it=E2=80=99s =
potentially ok for defining the specification and its boundaries, but it =
is not ok if it ends up requiring client and AS developers to use JSON =
Schema directly to implement anything. In other words, you should be a =
able to still write a bunch of hand-crafted validation code to make it =
work, or to use a parser that drops things into structured objects for =
you (like my Java implementation of XYZ does). Much like my argument =
against JSONLD, I think anything beyond a JSON =
parser 

=E2=80=
=A6 and generator is too much to ask. (Sorry, hit send too =
early.)


Another aspect that I don=E2=80=99t =
like about JSON schema is that it makes it difficult to describe things =
in terms of polymorphic data types. Polymorphism in the protocol is an =
important part of the XYZ proposal=E2=80=99s design, and as a feature it =
directly addresses a number of the items you found when doing your XAuth =
implementation, like parsing OAuth scopes and dealing with the =
authorization/authorizations mutually-exclusive oddness that you =
mentioned. I strongly believe that GNAP should make use of a polymorphic =
protocol structure for these and other reasons. Polymorphism is a =
built-in feature of the JSON data model, and it=E2=80=99s also fully =
possible to support under CBOR and other data serialization languages. =
Even JWT most famously uses polymorphism for the =E2=80=9Caud=E2=80=9D =
field, which can be a string or an array of strings depending on =
context, all with clear semantics. Defining that in JSON schema is not =
impossible, but it=E2=80=99s not easy.

So overall, I think JSON schema is =
probably not a good fit here.

 =E2=80=94 Justin

On Jul 6, 2020, at 3:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey
Does anyone have =
experience and/or opinions on JSON Schema [1]?

When implementing XAuth =
[2], I wrote a bunch of hand crafted JSON validation code. JSON schema =
looks like it could be a great way to validate input, and to create =
automated tests for output. It may also be a great way to document the =
Grant Response JSON.

/ Dick

[1] https://json-schema.org/
[2] https://github.com/dickhardt/XAuth-poc



-- 
Txauth mailing 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=_AB2B658A-C92A-419C-96BC-5F2687EF8757--


From nobody Mon Jul  6 13:17: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 610653A0A50 for ; Mon,  6 Jul 2020 13:17: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, 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 oi7C_VHHQUTR for ; Mon,  6 Jul 2020 13:17:05 -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 8966D3A0A49 for ; Mon,  6 Jul 2020 13:17:05 -0700 (PDT)
Received: by mail-lj1-x241.google.com with SMTP id d17so32356332ljl.3 for ; Mon, 06 Jul 2020 13:17: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=SxCNnClmu4slK56y+cQvmOU8xYxJvEtPJNcBROW7dwQ=; b=X6Ikct0QobIGit8vnjoPBPJyc8YQ7F55gSxRh0kU5cKPGQyNBtmjotDhdgOxz+x6OY Sy9Hd28YRHiDms/kDdrB8ukFT1J1aNbZYzVKuHyBvSyqfu+i8+32HTlN6m58aWYwE1ya EVSnojvi9p6ivabv9w41NiMNQJHo/b+iTkg7LY7xa+TvujZUcFlNBM/32LuDoIu02DaA b3BVVvFQ3sI0RFEnvern5mrMX+gMa+9ovMj9DaNWdROVuMfyRlMkv8KcF8qdSMRnWRIk pmwINMyfwnJaAMPrLYaDYVedQU16V4FpKq3XPGbcMVNSQMUTSAmv/KTcA4I/HmW2Ng3+ 9CIg==
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=SxCNnClmu4slK56y+cQvmOU8xYxJvEtPJNcBROW7dwQ=; b=s0Cdop/sZObO9grVw8OVo1Pp3Ds0S0uqFdgDRujTwL285tlkf64a8/CGDE3vt1xJZc pBrkuyQcIranu5Fy8BRkkJOy1CqJ3X8YNY1qf/8QHdIIDl8RDvo5fhWEYGBn0f8He+aQ Zlg9//VvCCgMK2Tw63lqaneRRWFClaV9byW8sVPZbeN8op3+XlPdBg+rv4iFbL+BDrb3 cZilbvjYyYSdLZ0OyiUMr1V/ubU8bAjmiHzBUoqRYcdfzAuemi10MReL/QWJjCh2RV1G hwtU8NGFw76Qp1KtjicukRkOG1BYGaTdltAD8wTuewN1oX8q3SI8Azi0srH+APjiiKxB S3Xg==
X-Gm-Message-State: AOAM533qTXlrxtSe2F4yjR4IUBABH0K4g4YXMsxK0EtExE0IP3kBJiLP dkzgs/skVuwZwHv3Am7cxFCoXrTn9tzDlKdvCbo=
X-Google-Smtp-Source: ABdhPJx9je/lb4FY8ehCUSK9Jbr1W3nsKEVvCvFJq9pA6x+WnshknlB+a5YQD2+ofKQi6f4Keof2N1e3OTWhxPS+m2Q=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr22733493ljn.5.1594066623352; Mon, 06 Jul 2020 13:17:03 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 6 Jul 2020 13:16:27 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d555ee05a9cb8eef"
Archived-At: 
Subject: Re: [Txauth] JSON Schema?
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, 06 Jul 2020 20:17:09 -0000

--000000000000d555ee05a9cb8eef
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Wayne and Justin.

I agree that we would not want to make it an implementation requirement.

I asked Tim Bray his thoughts (edited the IETF JSON specs, one of XML
creators)

Tim has written a number of blog posts on JSON Schema. TL;DR: he is not a
huge fan.

He pointed out the IETF JSON Type Definition ID [2]. This looks much
simpler and addresses many of the concerns Tim had expressed with JSON
Schema. It also has a more recent draft published on the IETF.
Unfortunately there do not seem to be many implementations, and the website
[3] is missing the promised docs [4]. The latest ID [5] looks to be derived
from CDDL (RFC 8610) [6].

I reached out to the core JSON Schema people, and they are focussed on
making JSON Schema changes to support efforts for the next version of Open
API [7]

My take: I may use Open Schema in my PoC implementation not unlike what
Wayne did, but it does not look like either JSON Schema or JSON Type
Definition is ready for the WG to use at this point.

/Dick

[1]
https://www.google.com/search?as_q=3Djson+schema&hl=3Den&ie=3DUTF-8&btnG=3D=
Google%2BSearch&as_qdr=3Dall&as_occt=3Dany&as_dt=3Di&as_sitesearch=3Dtbray.=
org


[2] https://datatracker.ietf.org/doc/draft-ucarion-json-type-definition/

[3] https://jsontypedef.com/

[4] https://jsontypedef.com/docs/getting-started/overview

[5] https://tools.ietf.org/html/draft-ucarion-json-type-definition-04

[6] https://tools.ietf.org/html/rfc8610

[7] https://github.com/OAI/OpenAPI-Specification


On Mon, Jul 6, 2020 at 12:55 PM Justin Richer  wrote:

>
> On Jul 6, 2020, at 3:54 PM, Justin Richer  wrote:
>
> I think it=E2=80=99s potentially ok for defining the specification and it=
s
> boundaries, but it is not ok if it ends up requiring client and AS
> developers to use JSON Schema directly to implement anything. In other
> words, you should be a able to still write a bunch of hand-crafted
> validation code to make it work, or to use a parser that drops things int=
o
> structured objects for you (like my Java implementation of XYZ does). Muc=
h
> like my argument against JSONLD, I think anything beyond a JSON parser
>
>
> =E2=80=A6 and generator is too much to ask. (Sorry, hit send too early.)
>
>
> Another aspect that I don=E2=80=99t like about JSON schema is that it mak=
es it
> difficult to describe things in terms of polymorphic data types.
> Polymorphism in the protocol is an important part of the XYZ proposal=E2=
=80=99s
> design, and as a feature it directly addresses a number of the items you
> found when doing your XAuth implementation, like parsing OAuth scopes and
> dealing with the authorization/authorizations mutually-exclusive oddness
> that you mentioned. I strongly believe that GNAP should make use of a
> polymorphic protocol structure for these and other reasons. Polymorphism =
is
> a built-in feature of the JSON data model, and it=E2=80=99s also fully po=
ssible to
> support under CBOR and other data serialization languages. Even JWT most
> famously uses polymorphism for the =E2=80=9Caud=E2=80=9D field, which can=
 be a string or an
> array of strings depending on context, all with clear semantics. Defining
> that in JSON schema is not impossible, but it=E2=80=99s not easy.
>
> So overall, I think JSON schema is probably not a good fit here.
>
>  =E2=80=94 Justin
>
> On Jul 6, 2020, at 3:00 PM, Dick Hardt  wrote:
>
> Hey
>
> Does anyone have experience and/or opinions on JSON Schema [1]?
>
> When implementing XAuth [2], I wrote a bunch of hand crafted JSON
> validation code. JSON schema looks like it could be a great way to valida=
te
> input, and to create automated tests for output. It may also be a great w=
ay
> to document the Grant Response JSON.
>
> / Dick
>
> [1] https://json-schema.org/
> [2] https://github.com/dickhardt/XAuth-poc
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>

--000000000000d555ee05a9cb8eef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Wayne and Justin.

I agree th=
at we would not want to make it an implementation requirement.

I asked Tim Bray his thoughts (edited =
the IETF JSON specs, one of XML creators)

Tim has wr=
itten a number of blog posts on JSON Schema. TL;DR: he is not a huge fan.=
=C2=A0

He pointed out the IETF JSON Type Definitio=
n ID [2]. This looks much simpler and addresses many of the concerns Tim ha=
d expressed with JSON Schema. It also has a more recent draft published on =
the IETF. Unfortunately there do not seem to be many implementations, and t=
he website [3] is missing the promised docs [4]. The latest=C2=A0ID [5] loo=
ks to be derived from CDDL (RFC 8610) [6].

I reach=
ed out to the core JSON Schema people, and they are focussed on making JSON=
 Schema changes to support efforts for the next version of Open API [7]

My take: I may use Open Schema in my PoC implementati=
on not unlike what Wayne did, but it does not look like either JSON Schema =
or JSON Type Definition is ready for the WG to use at this point.

/Dick

=C2=A0



On Mon, Jul 6, 2020 at 12:55 PM Justin Richer <jricher@mit.edu> wrote:

On Jul 6, 2020, at 3:5=
4 PM, Justin Richer <jricher@mit.edu> wrote:



I think it=E2=80=99s potentially =
ok for defining the specification and its boundaries, but it is not ok if i=
t ends up requiring client and AS developers to use JSON Schema directly to=
 implement anything. In other words, you should be a able to still write a =
bunch of hand-crafted validation code to make it work, or to use a parser t=
hat drops things into structured objects for you (like my Java implementati=
on of XYZ does). Much like my argument against JSONLD, I think anything bey=
ond a JSON parser=C2=A0

=E2=80=
=A6 and generator is too much to ask. (Sorry, hit send too early.)
<=
div>
Another aspect that I don=E2=80=99t like about JSON sche=
ma is that it makes it difficult to describe things in terms of polymorphic=
 data types. Polymorphism in the protocol is an important part of the XYZ p=
roposal=E2=80=99s design, and as a feature it directly addresses a number o=
f the items you found when doing your XAuth implementation, like parsing OA=
uth scopes and dealing with the authorization/authorizations mutually-exclu=
sive oddness that you mentioned. I strongly believe that GNAP should make u=
se of a polymorphic protocol structure for these and other reasons. Polymor=
phism is a built-in feature of the JSON data model, and it=E2=80=99s also f=
ully possible to support under CBOR and other data serialization languages.=
 Even JWT most famously uses polymorphism for the =E2=80=9Caud=E2=80=9D fie=
ld, which can be a string or an array of strings depending on context, all =
with clear semantics. Defining that in JSON schema is not impossible, but i=
t=E2=80=99s not easy.

So overall, I think JSON sch=
ema is probably not a good fit here.

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

On Jul 6, 2020, at 3:=
00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey

Does anyone have expe=
rience and/or opinions=C2=A0on JSON Schema [1]?

Wh=
en implementing XAuth [2], I wrote a bunch of hand crafted JSON validation =
code. JSON schema looks like it could be a great way to validate input, and=
 to create automated tests for output. It may also be a great way to docume=
nt the Grant Response JSON.

/ Dick

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


-- 
Txauth mailing list=

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



--000000000000d555ee05a9cb8eef--


From nobody Mon Jul  6 13:27: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 DB40B3A0A65; Mon,  6 Jul 2020 13: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 k1reti0EQU-0; Mon,  6 Jul 2020 13:27:26 -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 E60853A0A64; Mon,  6 Jul 2020 13:27:25 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id e8so12847917ljb.0; Mon, 06 Jul 2020 13:27:25 -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=/s9tYz/6jdm8sRDTjLuaD0OZis7KJFCWp5PDxcWefGo=; b=irYIZkd9Y/P/XQWQyHuIpqil1wJj2MmSZ/Ol1YtfQtzlRZkON3RsbafLDqM6ZDyMgU 9jvaRlbcLjRGnk9fYDsT4DGaLfyKVOCTFpgVEstOYEUiF/au4LUinLdT9SENnj0EKQ82 +KeEGS0BzVd4PwDaUsaFjBA9cqSPj1UkEcPrrKLwuI2u1oe/HfRwE1uneTPI6a+9VCrv P09IFYKsqVxXl5tKjVFRf4YjWubmqU9Zk3eep6VxY3EUzOJ5AGkCAuPNKS74pAPIa3IJ 1bcxWQUj9Ua2npM/m2vgMHMjQ5YMefYcqpykFJ3iqbGQF/s1pe1WaVEeZaXFdD+V+bel PjAg==
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=/s9tYz/6jdm8sRDTjLuaD0OZis7KJFCWp5PDxcWefGo=; b=f9I4qsjGzRpHp9PKhv7U6/0gMlTYW5K5M2st4sfsN5gVHSx/R4WxghqWsgZNkyV0n2 +XHa7bTtwuVkKCzIra2HZZDc7Xsg0pWIZ68vDWXYsQjidL/aDs1NUI3oYTlf71w+oiuX mD9wWQOBH36ybg9IV/c7rVd5epoSXtzu0lrGpIPLI6I9ohlcmKIiBdcxkUbRC11elXEG K9l8sfoiU11OFZcQRSdEGgzCAJpiaQF0dJ06DcSHhH6XLL3yFvVkRv93o5wCz9Ttp0hR yny1f9B4dSHDB41S5tCxeXwFVzPp8AkN+NVo4EKJUzUxckpcx/44P5SEvRFR09TGJkmG qgKQ==
X-Gm-Message-State: AOAM532pEpS87agp4hAOKeJxt2nmRldNYPLLLcSMp032CIXKzOrpP4ZS f5Ynt95y0KgSCA2ZUHDyMhtP9DGg8rML0WDoq5o=
X-Google-Smtp-Source: ABdhPJz6vXuJf1WHnakfMTgPoHDwhivjACFpOFoVAxc+4+RLQzHZJYlRIqCqxWKI4JXQhjABGp4gIsM+7M1NvfX3Rtw=
X-Received: by 2002:a2e:7f10:: with SMTP id a16mr29503280ljd.69.1594067243664;  Mon, 06 Jul 2020 13:27:23 -0700 (PDT)
MIME-Version: 1.0
References: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>  
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 6 Jul 2020 13:26:47 -0700
Message-ID: 
To: Denis 
Cc: Roman Danyliw , "txauth@ietf.org" , The IESG 
Content-Type: multipart/alternative; boundary="000000000000ce8ae305a9cbb3c8"
Archived-At: 
Subject: Re: [Txauth] Support of FIDO and data minimization by RSs
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, 06 Jul 2020 20:27:29 -0000

--000000000000ce8ae305a9cbb3c8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis

Thanks for writing up the scenarios, that helps me ensure we are talking
about the same thing. They are similar to scenarios that have been
discussed by the digeriti for what seems forever!

To elaborate on my other email, I do think GNAP should support
implementations that need "privacy by design". I don't think that is
applicable to all the use cases, and would overly restrict the use cases
that many participants want to solve with GNAP.

I think the resulting GNAP document should have a Privacy Considerations
section and/or a separate Privacy document, to assist implementers in
dealing with potential privacy issues.

Perhaps if we had a privacy related milestone you would feel your concerns
will be addressed by the WG?


On Mon, Jul 6, 2020 at 12:17 PM Denis  wrote:

> Hi Dick,
>
> Congratulations ! You made a good guess (but the guess was easy): my
> approach is indeed privacy related.
>
> *Note*: Since it is close to the end of the day in my time zone (and
> since it is the last day for comments to the charter),
> I copy both the IESG and Roman so that they can know that GNAP should als=
o
> consider a* bridge with FIDO*.
>
> I have several goals:
>
> 1 - make a bridge with FIDO U2F (I will illustrate this with a specific
> scenario).
>
> 2 - prevent every AS to know which RSs are going to be accessed or which
> kind of operation the client will be doing.
>     This is to prevent an AS to act as "Big Brother".
>
> 3 - apply both "privacy by default" and "data minimization" (when the use=
r
> authenticates it may authenticate using FIDO or
>      by presenting one or more access tokens. Then after, the necessary
> attributes that are necessary to perform a given operation
>     are only requested and released at the time they are indeed needed to
> perform the given operation (i.e. they are not released
>     when the user logs on).
>
> 4 - the proposed RS Authorization algorithm allows a great flexibility, i=
n
> particular it supports FIDO and different attributes
>      from different ASs may be requested by the RS.
>
> 5 - the rules associated with the RS Authorization algorithm are making
> these rules only available at the time the client indicates
>      which operation it is willing to perform (i.e. by default, they are
> not public).
>
> 6 - access tokens are NOT OPAQUE to the clients so that every client can
> make sure that their content reflects what has been requested.
>
> *A simple scenario to illustrate*
>
> A student wants to apply for a new university. He connects to the RS of
> the University. He first creates an account using FIDO.
> He then selects the button "Preliminary information for applying to the
> university". He is asked to enter two categories of information:
>
>
>    - citizenship information and
>    - prior graduations.
>
> The student can interrupt the preliminary registration procedure at any
> time and continue it at any time later on.
>
> When the student is finished, it selects the button "Application to the
> university".
>
> The university RS "reads" the citizen ship of the student and let know to
> the student whether a paper form
> and/or an electronic form of the identity of the student may be provided.
> Let us assume the later case and that
> the student is a citizen from France. Then the university RS indicates
> which French banks or other French organisations
> are trusted to provide an access token. The client checks whether this
> list fits one of the AS with which it has a relationship.
>
> The university RS "reads" the prior graduations of the student and then
> let know to the student whether a paper form
> and/or an electronic form of the last graduation of the student may be
> provided. Let us assume the later case and
> that the student is from Yale University. Then the university indicates
> the address of the AS from Yale University.
> If the student is indeed from Yale University, he should be able to
> provide the requested access token.
>
> Such scenario which follows some privacy principles cannot be constructed=
 "*after
> the design"* (it will not happen by magic or by accident)
> This is why the approach is called "privacy by design".
>
> Denis
>
> Hi Denis
>
> Would you provide some background on what you are trying to solve with
> this? I'm guessing it is privacy related.
>
> Perhaps a use case would help make it more concrete?
>
> /Dick
>
>
> On Mon, Jul 6, 2020 at 5:39 AM Denis  wrote:
>
>> eThis is a new thread: a proposal for a RS authorization algorithm and a
>> way to support FIDO by RSs
>>
>> In order to support the privacy principle of "data minimization" by RSs,
>> only the attributes that are strictly necessary to perform
>> an operation requested by a client should be requested by the RS.
>>
>> When a client wants to authenticate, it will usually be informed by the
>> RS on how to do it (see more details about two exceptions at the end of
>> this email).
>> Which conditions are needed to perform other operations will only be
>> disclosed to authenticated users at the time they are willing to perform=
 an
>> operation.
>>
>> Two categories of operations will be considered: authentication
>> operations and other operations.
>>
>> For the "authentication" operation, two cases will be supported:
>>
>> -          FIDO U2F or
>>
>> -          one or more attributes from one or more ASs.
>>
>> In the second case, an access will be granted by a RS based on an
>> mathematical expression which is formed using some combination of AND an=
d
>> 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 *a Condition *:
>>
>> *Condition x* =3D { AS identifier + set of attributes types + optional
>> scope identifier }
>>
>> The presence of the *optional* scope identifier allows to provide a
>> backward compatibility with ASs from the OAuth 2.0. world:
>> the optional scope identifier is only present when a bilateral
>> relationship has been established between a RS and an AS prior
>> to any access (*and will continue to be maintained*) using
>> "out-of-bands" means.
>>
>> 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 condi=
tions.
>>
>> An example is used to explain the concepts.
>>
>> "Operation(s)/ Mathematical expression" pairs managed by the RO of a RS.
>>
>> *Operation*
>>
>> *Mathematical expression*
>>
>> Authentication
>>
>> *Condition 1* OR *Condition 2*
>>
>> Operation A OR Operation Z
>>
>> *Condition 3* AND *Condition 4*
>>
>> Conditions table:
>>
>> Condition 1
>>
>> FIDO U2F 1.2
>>
>> -
>>
>> -
>>
>> Condition 2
>>
>> AS 1
>>
>> set 1 of attributes types
>>
>>
>>
>> Condition 3
>>
>> AS 4
>>
>> set 2 of attributes types
>>
>> scope identifier : 21
>>
>> Condition 4
>>
>> AS 9
>>
>> set 3 of attributes types
>>
>> -
>>
>> 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
>> the set of attributes types which are indicated for a given AS
>> are appropriate to him or not and then select that AS if it has a
>> relationship with it.
>>
>> In this example, one mathematical expression for the combination of
>> conditions using AND and OR operators is "*Condition 3* OR *Condition
>> 4",*
>> * which means that* some types of attributes from AS 4 AND some other
>> types of attributes from AS 9 are both needed by RSx to perform on RSx
>> either the Operation A or the Operation Z.
>>
>> In this example, RS 1 and AS 4 have established a bilateral relationship
>> (and have agreed to define and use scope identifiers)
>> whereas RS 1 and AS 9 have not established any bilateral relationship
>> prior to the exchange.
>>
>> The user makes up his mind whether the attributes requested by AS 1 and
>> AS 9 are reasonable and if so, requests two access tokens:
>> one to AS 4 and another one to AS 9.
>>
>> For AS 4, the client shall use the scope identifier with the value 21.
>> For AS 9, the client shall use the set 3 of attributes types indicated i=
n
>> the Condition 4.
>>
>> In order to save one exchange, a RS could publicly publish how its
>> clients can authenticate.
>> However,  it is also possible to consider no guidance at all: in such a
>> case, using "out-of-bands" means, the clients should know how to
>> authenticate.
>>
>> 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
>

--000000000000ce8ae305a9cbb3c8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis

Thanks for writing up the scen=
arios,=C2=A0that=C2=A0helps me ensure we are talking about the same thing. =
They are similar to scenarios that have been discussed by the digeriti for =
what seems forever!

To elaborate on my other email=
, I do think GNAP should support implementations that need "privacy by=
 design". I don't think that is applicable to all the use cases, a=
nd would overly restrict the use cases that many participants want to solve=
 with GNAP.

I think the resulting GNAP document sh=
ould have a Privacy Considerations section and/or a separate Privacy docume=
nt, to assist implementers=C2=A0in dealing with potential privacy issues.

Perhaps if we had a privacy related milestone you w=
ould feel your concerns will be addressed by the WG?


On=
 Mon, Jul 6, 2020 at 12:17 PM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hi Dick,

    


    

    
Congratulations ! You made a good guess
      (but the guess was easy): my approach is indeed privacy related.
    


    

    
Note: Since it is close to the
      end of the day in my time zone (and since it is the last day for
      comments to the charter), 

      I copy both the IESG and Roman so that they can know that GNAP
      should also consider a bridge with FIDO.

    

    
I have several goals:

    

      
1 - make a bridge with FIDO U2F (I
        will illustrate this with a specific scenario).

      


      

      
2 - prevent every AS to know which
        RSs are going to be accessed or which kind of operation the
        client will be doing.

        =C2=A0=C2=A0=C2=A0 This is to prevent an AS to act as "Big Bro=
ther".

      

      


      

      
3 - apply both "privacy by default"
        and "data minimization" (when the user authenticates it m=
ay
        authenticate using FIDO or 

        =C2=A0 =C2=A0=C2=A0 by presenting one or more access tokens. Then a=
fter, the
        necessary attributes that are necessary to perform a given
        operation 

        =C2=A0=C2=A0=C2=A0 are only requested and released at the time they=
 are indeed
        needed to perform the given operation (i.e. they are not
        released 

        =C2=A0 =C2=A0 when the user logs on).

      


      

      
4 - the proposed RS Authorization
        algorithm allows a great flexibility, in particular it supports
        FIDO and different attributes 

        =C2=A0=C2=A0=C2=A0=C2=A0 from different ASs may be requested by the=
 RS.

      


      

      
5 - the rules associated with the RS
        Authorization algorithm are making these rules only available at
        the time the client indicates 

        =C2=A0 =C2=A0=C2=A0 which operation it is willing to perform (i.e. =
by default,
        they are not public).

      


      

      
6 - access tokens are NOT OPAQUE to
        the clients so that every client can make sure that their
        content reflects what has been requested.

      

    

    
 A simple scenario to illustrate

    

    


    

    
A student wants to apply for a new
      university. He connects to the RS of the University. He first
      creates an account using FIDO.

      He then selects the button "Preliminary information for applying
      to the university". He is asked to enter two categories of
      information:

    

      
    
        
  • citizenship information and 
    • 
        
  • prior graduations.
    • 
      

    

    
The student can interrupt the
      preliminary registration procedure at any time and continue it at
      any time later on.

    


    

    
When the student is finished, it
      selects the button "Application to the university".

    

    

      
The university RS "reads" the citizen
        ship of the student and let know to the student whether a paper
        form 

        and/or an electronic form of the identity of the student may be
        provided. Let us assume the later case and that 

        the student is a citizen from France. Then the university RS
        indicates which French banks or other French organisations 

        are trusted to provide an access token. The client checks
        whether this list fits one of the AS with which it has a
        relationship.

      

      


      

      The university RS "reads" the prior graduations of the stud=
ent and
      then let know to the student whether a paper form 

      and/or an electronic form of the last graduation of the student
      may be provided. Let us assume the later case and 

      that the student is from Yale University. Then the university
      indicates the address of the AS from Yale University.

      If the student is indeed from Yale University, he should be able
      to provide the requested access token.

    

    
Such scenario which follows some privacy principles cannot be
      constructed "after the design" (it will not happen b=
y magic
      or by accident)

      This is why the approach is called "privacy by design".

    
Denis

    

    

      
Hi Denis
        


        

        
Would you provide some background on what you are trying to
          solve with this? I'm guessing it is privacy related.=C2=A0
        


        

        
Perhaps a use case would help make it more concrete?

        


        

        
/Dick

        


        

      

      

      

        
On Mon, Jul 6, 2020 at 5:39 A=
M
          Denis <denis.ietf@free.fr> wrote:

        

        

          

            
 =
eThis is a new
                thread: a proposal for a RS authorization algorithm<=
span style=3D"font-family:Arial" lang=3D"EN-US"> and a way to
                support FIDO by RSs

              

            
In order to support the privacy principle
                of "data minimization" by RSs, only the attribute=
s that
                are strictly necessary to perform 

                an operation requested by a client should be requested
                by the RS.

            
When a client wants to authenticate, it
                will usually be informed by the RS on how to do it (see
                more details about two exceptions at the end of this
                email). 

                Which conditions are needed to perform other operations
                will only be disclosed to authenticated users at the
                time they are willing to perform an operation.

            
Two categories of operations will be
                considered: authentication operations and other
                operations.

              

            
 For the "authentication" operation, two
                cases will be supported: 

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                FIDO U2F or 

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                one or more attributes from one or more
                ASs. 

            
In the second case, 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 Conditi=
on 2

                    Condition 1 OR Condition 2

                (Condition 1 AND Condition 2) OR Condition 3

                    (Condition 1 OR Condition 2) AND Conditio=
n 3 

                

            

            
The following notation is being used for a
                  Condition :

            
Condition x =3D { AS
                identifier + set of attributes types + optional scope
                identifier } 

              

            
The presence of the optional scope
                identifier allows to provide a backward compatibility
                with ASs from the OAuth 2.0. world: 

                the optional scope identifier is only present when a
                bilateral relationship has been established between a RS
                and an AS prior 

                to any access (and will continue to be maintained)
                using "out-of-bands" means. 

              

            
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.

            
An example is used to explain the concepts.

            
"Operation(s)/ Mathematical expression"
                pairs managed by the RO of a RS. 

              

            

              
                

                  
                    
Operation

                  		
                  
                    
Mathematical
                          expression

                  		
                

                

                  
                    
Authentication

                  		
                  
                    
Condition 1 OR =
Condition 2

                  		
                

                

                  
                    
Operation A OR Operation
                        Z

                  		
                  
                    
Condition 3 AND Condition 4

                  		
                

              
            

            
Conditions table:
              

            

              
                

                  
                    
Condition 1

                  		
                  
                    
FIDO
                        U2F 1.2

                  		
                  
                    
-

                  		
                  
                    
-

                  		
                

                

                  
                    
Condition 2

                  		
                  
                    
AS 1

                  		
                  
                    
set 1 of attributes types

                  		
                  
                    
=C2=A0

                  		
                

                

                  
                    
Condition 3

                  		
                  
                    
AS 4

                  		
                  
                    
set 2 of attributes types

                  		
                  
                    
scope identifier : 21

                  		
                

                

                  
                    
Condition 4

                  		
                  
                    
AS 9

                  		
                  
                    
set 3 of attributes types

                  		
                  
                    
-

                  		
                

              
            

            
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 the set of att=
ributes
                  types which are indicated for a given AS 

                are appropriate to him or not and then select that AS if
                it has a relationship with it.

            
In this example, one mathematical
                expression for the combination of conditions using AND
                and OR operators is "C=
ondition
                    3 =
OR Conditi=
on 4", <=
br>
                    which means that some types of
                attributes from AS 4 AND
                some other types of attributes from AS 9 are both needed
                by RSx to perform on RSx 

                either the Operation A or the Operation Z. 

            
In this example, RS 1 and AS 4 have
                established a bilateral relationship (and have agreed to
                define and use scope identifiers) 

                whereas RS 1 and AS 9 have not established any bilateral
                relationship prior to the exchange. 

              

            
The user makes up his mind whether the
                attributes requested by AS 1 and AS 9 are reasonable and
                if so, requests two access tokens: 

                one to AS 4 and another one to AS 9.

            
For AS 4=
, the client shall use the
                scope identifier with the value 21.

                For AS 9, the client shall use the set 3 of attributes
                types indicated in the Condition 4.

            
In order to save one exchange, a RS could
                publicly publish how its clients can authenticate. 

                However,=C2=A0 it is also possible to consider no guidance =
at
                all: in such a case, using "out-of-bands" means, =
the
                clients should know how to authenticate.

            
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




--000000000000ce8ae305a9cbb3c8--


From nobody Mon Jul  6 13:30: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 957C73A0A6A for ; Mon,  6 Jul 2020 13:30:47 -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 mzupRRCLVgQB for ; Mon,  6 Jul 2020 13:30: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 2349F3A0A66 for ; Mon,  6 Jul 2020 13:30:44 -0700 (PDT)
Received: from [192.168.1.7] (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 066KUg6v031049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jul 2020 16:30:42 -0400
From: Justin Richer 
Message-Id: <561C0AB5-BF44-4B8D-82C4-DA0A12DFB668@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E255B426-B0B6-4731-8C6B-DD4D45A40AC3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 6 Jul 2020 16:30:42 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] JSON Schema?
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, 06 Jul 2020 20:30:48 -0000

--Apple-Mail=_E255B426-B0B6-4731-8C6B-DD4D45A40AC3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The best thing about schema languages is that there are so many of them =
to choose from. :)

I do like Wayne=E2=80=99s idea of using JSON schema (or something =
similar) in a validation test suite, and that=E2=80=99s something that =
the group should consider. Formal tools like test suites, use case =
documents, and formal analysis are all in our toolbox as we build out =
GNAP, and so we can decide which, if any, make sense.

 =E2=80=94 Justin

> On Jul 6, 2020, at 4:16 PM, Dick Hardt  wrote:
>=20
> Thanks Wayne and Justin.
>=20
> I agree that we would not want to make it an implementation =
requirement.
>=20
> I asked Tim Bray his thoughts (edited the IETF JSON specs, one of XML =
creators)
>=20
> Tim has written a number of blog posts on JSON Schema. TL;DR: he is =
not a huge fan.=20
>=20
> He pointed out the IETF JSON Type Definition ID [2]. This looks much =
simpler and addresses many of the concerns Tim had expressed with JSON =
Schema. It also has a more recent draft published on the IETF. =
Unfortunately there do not seem to be many implementations, and the =
website [3] is missing the promised docs [4]. The latest ID [5] looks to =
be derived from CDDL (RFC 8610) [6].
>=20
> I reached out to the core JSON Schema people, and they are focussed on =
making JSON Schema changes to support efforts for the next version of =
Open API [7]
>=20
> My take: I may use Open Schema in my PoC implementation not unlike =
what Wayne did, but it does not look like either JSON Schema or JSON =
Type Definition is ready for the WG to use at this point.
>=20
> /Dick
>=20
> [1] =
https://www.google.com/search?as_q=3Djson+schema&hl=3Den&ie=3DUTF-8&btnG=3D=
Google%2BSearch&as_qdr=3Dall&as_occt=3Dany&as_dt=3Di&as_sitesearch=3Dtbray=
.org =

>  =
=20
> [2] =
https://datatracker.ietf.org/doc/draft-ucarion-json-type-definition/ =

>=20
> [3] https://jsontypedef.com/ 
>=20
> [4] https://jsontypedef.com/docs/getting-started/overview =

>=20
> [5] https://tools.ietf.org/html/draft-ucarion-json-type-definition-04 =

>=20
> [6] https://tools.ietf.org/html/rfc8610 =

>=20
> [7] https://github.com/OAI/OpenAPI-Specification =

>=20
>=20
> On Mon, Jul 6, 2020 at 12:55 PM Justin Richer > wrote:
>=20
>> On Jul 6, 2020, at 3:54 PM, Justin Richer > wrote:
>>=20
>> I think it=E2=80=99s potentially ok for defining the specification =
and its boundaries, but it is not ok if it ends up requiring client and =
AS developers to use JSON Schema directly to implement anything. In =
other words, you should be a able to still write a bunch of hand-crafted =
validation code to make it work, or to use a parser that drops things =
into structured objects for you (like my Java implementation of XYZ =
does). Much like my argument against JSONLD, I think anything beyond a =
JSON parser=20
>=20
> =E2=80=A6 and generator is too much to ask. (Sorry, hit send too =
early.)
>=20
>>=20
>> Another aspect that I don=E2=80=99t like about JSON schema is that it =
makes it difficult to describe things in terms of polymorphic data =
types. Polymorphism in the protocol is an important part of the XYZ =
proposal=E2=80=99s design, and as a feature it directly addresses a =
number of the items you found when doing your XAuth implementation, like =
parsing OAuth scopes and dealing with the authorization/authorizations =
mutually-exclusive oddness that you mentioned. I strongly believe that =
GNAP should make use of a polymorphic protocol structure for these and =
other reasons. Polymorphism is a built-in feature of the JSON data =
model, and it=E2=80=99s also fully possible to support under CBOR and =
other data serialization languages. Even JWT most famously uses =
polymorphism for the =E2=80=9Caud=E2=80=9D field, which can be a string =
or an array of strings depending on context, all with clear semantics. =
Defining that in JSON schema is not impossible, but it=E2=80=99s not =
easy.
>>=20
>> So overall, I think JSON schema is probably not a good fit here.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 6, 2020, at 3:00 PM, Dick Hardt > wrote:
>>>=20
>>> Hey
>>>=20
>>> Does anyone have experience and/or opinions on JSON Schema [1]?
>>>=20
>>> When implementing XAuth [2], I wrote a bunch of hand crafted JSON =
validation code. JSON schema looks like it could be a great way to =
validate input, and to create automated tests for output. It may also be =
a great way to document the Grant Response JSON.
>>>=20
>>> / Dick
>>>=20
>>> [1] https://json-schema.org/ 
>>> [2] https://github.com/dickhardt/XAuth-poc =

>>>=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


--Apple-Mail=_E255B426-B0B6-4731-8C6B-DD4D45A40AC3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The =
best thing about schema languages is that there are so many of them to =
choose from. :)

I do like Wayne=E2=80=99s idea of using JSON schema (or =
something similar) in a validation test suite, and that=E2=80=99s =
something that the group should consider. Formal tools like test suites, =
use case documents, and formal analysis are all in our toolbox as we =
build out GNAP, and so we can decide which, if any, make =
sense.

 =E2=
=80=94 Justin

On Jul 6, 2020, at 4:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Thanks Wayne and =
Justin.

I agree that we would not want to make it an implementation =
requirement.

I asked Tim Bray his thoughts (edited the IETF =
JSON specs, one of XML creators)

Tim has written a number of blog posts =
on JSON Schema. TL;DR: he is not a huge fan. 

He pointed out the IETF =
JSON Type Definition ID [2]. This looks much simpler and addresses many =
of the concerns Tim had expressed with JSON Schema. It also has a more =
recent draft published on the IETF. Unfortunately there do not seem to =
be many implementations, and the website [3] is missing the promised =
docs [4]. The latest ID [5] looks to be derived from CDDL (RFC =
8610) [6].

I =
reached out to the core JSON Schema people, and they are focussed on =
making JSON Schema changes to support efforts for the next version of =
Open API [7]

My =
take: I may use Open Schema in my PoC implementation not unlike what =
Wayne did, but it does not look like either JSON Schema or JSON Type =
Definition is ready for the WG to use at this point.

/Dick

[1] https://www.google.com/search?as_q=3Djson+schema&hl=3Den&am=
p;ie=3DUTF-8&btnG=3DGoogle%2BSearch&as_qdr=3Dall&as_occt=3Dany=
&as_dt=3Di&as_sitesearch=3Dtbray.org
 
[2] https://datatracker.ietf.org/doc/draft-ucarion-json-type-defini=
tion/

[3] https://jsontypedef.com/

[4] https://jsontypedef.com/docs/getting-started/overview
=


[5] https://tools.ietf.org/html/draft-ucarion-json-type-definition-=
04

[6] https://tools.ietf.org/html/rfc8610

[7] https://github.com/OAI/OpenAPI-Specification

On Mon, Jul 6, 2020 at 12:55 PM Justin Richer =
<jricher@mit.edu> =
wrote:

On Jul 6, 2020, at 3:54 PM, =
Justin Richer <jricher@mit.edu> wrote:



I think it=E2=80=99s =
potentially ok for defining the specification and its boundaries, but it =
is not ok if it ends up requiring client and AS developers to use JSON =
Schema directly to implement anything. In other words, you should be a =
able to still write a bunch of hand-crafted validation code to make it =
work, or to use a parser that drops things into structured objects for =
you (like my Java implementation of XYZ does). Much like my argument =
against JSONLD, I think anything beyond a JSON =
parser 

=E2=80=A6 and generator is too much to =
ask. (Sorry, hit send too early.)


Another aspect that I don=E2=80=99t like about JSON schema is =
that it makes it difficult to describe things in terms of polymorphic =
data types. Polymorphism in the protocol is an important part of the XYZ =
proposal=E2=80=99s design, and as a feature it directly addresses a =
number of the items you found when doing your XAuth implementation, like =
parsing OAuth scopes and dealing with the authorization/authorizations =
mutually-exclusive oddness that you mentioned. I strongly believe that =
GNAP should make use of a polymorphic protocol structure for these and =
other reasons. Polymorphism is a built-in feature of the JSON data =
model, and it=E2=80=99s also fully possible to support under CBOR and =
other data serialization languages. Even JWT most famously uses =
polymorphism for the =E2=80=9Caud=E2=80=9D field, which can be a string =
or an array of strings depending on context, all with clear semantics. =
Defining that in JSON schema is not impossible, but it=E2=80=99s not =
easy.

So =
overall, I think JSON schema is probably not a good fit here.

 =E2=80=94 =
Justin

On Jul 6, 2020, at 3:00 PM, =
Dick Hardt <dick.hardt@gmail.com> wrote:

Hey

Does anyone have experience and/or opinions on JSON =
Schema [1]?

When=
 implementing XAuth [2], I wrote a bunch of hand crafted JSON validation =
code. JSON schema looks like it could be a great way to validate input, =
and to create automated tests for output. It may also be a great way to =
document the Grant Response JSON.

/ Dick

[1] https://json-schema.org/
[2] https://github.com/dickhardt/XAuth-poc



-- 
Txauth mailing 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=_E255B426-B0B6-4731-8C6B-DD4D45A40AC3--


From nobody Mon Jul  6 13:39: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 772313A0A83 for ; Mon,  6 Jul 2020 13:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.62
X-Spam-Level: 
X-Spam-Status: No, score=-0.62 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.276, 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 G5ChleD-tkzq for ; Mon,  6 Jul 2020 13:39:19 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr [80.12.242.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12CEC3A0A80 for ; Mon,  6 Jul 2020 13:39:18 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d88 with ME id zwfF2200Y4FMSmm03wfGhJ; Mon, 06 Jul 2020 22:39:17 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 06 Jul 2020 22:39:17 +0200
X-ME-IP: 86.238.65.197
To: Justin Richer , Fabien Imbault 
Cc: txauth@ietf.org
References:    <8a723292-4d04-63c7-e57c-7e7307e145c8@free.fr>  <2F429EC5-85FD-4991-AED8-8478BD371A00@mit.edu>
From: Denis 
Message-ID: <9f2f39f0-9f72-c76e-e3b1-c35a75bd69d8@free.fr>
Date: Mon, 6 Jul 2020 22:39: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: <2F429EC5-85FD-4991-AED8-8478BD371A00@mit.edu>
Content-Type: multipart/alternative; boundary="------------D654A8511FA717314FC89EAE"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] RS/AS communication for multiparty 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: Mon, 06 Jul 2020 20:39:23 -0000

This is a multi-part message in MIME format.
--------------D654A8511FA717314FC89EAE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Justin,

> Fabien and Denis,
>
> I think here we can see that there are multiple different directions 
> that people’s use cases and concerns will pull GNAP’s design. Some 
> want to have the AS have no knowledge of the RS, and only the client 
> to know that; others want the AS to have knowledge of all of its RS’s 
> and be able to dispatch an naive client to one. The thing is, I think 
> both of these have merit and both of them can be accommodated in the 
> protocol. Allowing one does not disallow the other. It’s not up to 
> GNAP to decide which of these approaches is morally correct.

As soon as we allow a RS to get access tokens from multiples ASs, the 
driving of a client by a *single AS* does not make sense any more.
If we allow the RSs to drive the clients, it will also apply to "naive 
clients" and then they do not need to be driven by a *single AS*.

The model should be the same whether a RS requests to get an access 
token from a single AS or from multiple ASs.

The delegation model would also be quite different whether the client 
will be driven by a single AS or be driven by each RS
that is attempting to respond to an original operation.  Has the 
delegation model been discussed on the mailing list ?

Accommodating both approaches in the same protocol appears to me rather 
difficult:
I do not see how "privacy by design" could be melt into "spy by design" 
nor how "spy by design" could  be melt into "privacy by design".

Denis

> In particular, addressing both of these dimensions is one of the 
> things that having a multi-dimensional language for requesting 
> resources in a standard way is going to help beyond what OAuth 2 can 
> do. These queries can be designed in such a way to minimize disclosure 
> to the AS or to minimize the amount of knowledge in the client, or 
> anywhere in between. Ultimately it’s up to the RS to decide whether 
> the rights associated with the token are good enough for the request, 
> and GNAP’s proposed charter says we’ll be defining both a means for 
> fine-grained requests as well as a consistent data model for the 
> token’s rights. Neither of these assumes that the RS will be 
> identified, nor that it can’t be.
>
>  — Justin
>
>> On Jul 6, 2020, at 7:06 AM, Fabien Imbault > > wrote:
>>
>> Hi Denis,
>>
>> Thanks for your feedback. Your scheme is interesting and covers well 
>> the personal access.
>>
>> The variant I'm referring to is multiparty access, which is a fairly 
>> common pattern also. Handled as an extension in Oauth2, but to my 
>> knowledge it requires an additional relationship between RS and AS. 
>> Maybe we can come up with an alternative design, I don't know yet.
>>
>> Cheers.
>>
>> Fabien
>>
>>
>> Le lun. 6 juil. 2020 à 12:23, Denis > > a écrit :
>>
>>     Hello Fabien,
>>>     Thanks Denis. It clarifies what you have in mind.
>>>
>>>     While I agree with the general idea that we need to take privacy
>>>     more seriously, there are a few hypotheses that we need to put
>>>     in perspective :
>>>
>>>     1) AS-RS relationship <=> big brother. It may happen as we all
>>>     know, but you always have the choice as a user to not deal with
>>>     orgs you don't like
>>>     or maybe even take action if they don't respect the law.
>>
>>     Unfortunately, the choice you mention is not always possible.
>>     There is a fundamental point here: since it is not always
>>     possible to trust an AS to respect the law,
>>     it is possible to build an architecture where the AS will be
>>     unable to by-pass the law. It is the difference between :
>>
>>       * "the AS *should not* do this or that" (but it could if it
>>         would) and
>>       * "the AS *cannot do* this or that" (it cannot even if it would).
>>
>>>     2) the collusion possibility (Alice's uncle) : there are of
>>>     course situations where that may be an issue. This is I guess
>>>     the reason for the sovrin foundation
>>>     to require that only approved issuers can participate. But even
>>>     if you open up the system, it always ends up as whether you can
>>>     trust the uncle to be honest
>>>     in the first place (knowing that trust is a social construct).
>>
>>     When using computers, trust is not a "social construct". It is a
>>     construction where an entity A trusts an entity B for some
>>     behaviour C.
>>     In the ABC attack, the RS will never know whether someone
>>     forwarded or not an access token to Alice.
>>
>>>     So I may require the issuer to be a well known participant instead.
>>>
>>>     3) The use of hardware FIDO inspired components does relax some
>>>     of the previous concern, but comes with its own sets of challenges.
>>>     Biometrics come with their own sets of potential issues.
>>
>>     The use of FIDO does not imply that you must use its biometrics
>>     features.
>>
>>>     More trivially, if you loose your hardware, you loose your ID.
>>
>>     If you loose your ID, you should report of its loss. It also
>>     means that by design, a mechanism has been constructed to recover
>>     from the situation
>>     within a short period of time. Unfortunately, such a property is
>>     currently missing in FIDO, but it does not mean that it cannot be
>>     added.
>>
>>>     And there can also be hacks in hardware. If I find a way to
>>>     import or export the private key from the enclave, the system fails.
>>
>>     The whole system does not fail. When someone attempts to export a
>>     private key from an hardware device in an unlawful way, it takes
>>     some time and some expertise.
>>     As soon as the legitimate holder realizes the lost of his
>>     hardware, he should report the loss. Then after, the discovery of
>>     private keys stored into the device is no more an issue.
>>
>>>     So in the end, I agree it's best to enable as much privacy by
>>>     design as we possibly can, but we need to put that in
>>>     perspective with use cases too and make some tradeoffs.
>>>     Healthcare in particular is a domain that is concerned with a
>>>     constant balance between privacy and security, and sometimes
>>>     there is no possibility to tick all boxes.
>>>     I think an UMA2/OpenId Heart scenario is a very important case
>>>     to consider in that respect.
>>
>>     The goal of this BoF/WG is not to rubber-stamp the "Health
>>     Relationship Trust Profile for User-Managed Access 2.0"
>>     specification.
>>
>>     Since the "Health Relationship Trust Profile for User-Managed
>>     Access 2.0" specification has nothing really specific to
>>     healthcare, what is the "very important case" you have in mind ?
>>     Would it be possible to model a specific characteristic you have
>>     in mind in terms of model components, operations flows, trust
>>     relationships, privacy requirements and security requirements ?
>>
>>     Denis
>>
>>>
>>>     Fabien
>>>
>>>
>>>
>>>
>>>     On Fri, Jul 3, 2020 at 12:01 PM Denis >>     > wrote:
>>>
>>>         Hello Fabien,
>>>
>>>         In 2017, I made a presentation at the OAuth workshop in Zurich.
>>>
>>>         The paper is available from:
>>>         https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf
>>>
>>>         The slides are available from:
>>>         https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.ppt
>>>         _Note_: The slides should be viewed "full screen" to get the
>>>         animations.
>>>
>>>         The general approach is how to construct from scratch a
>>>         "privacy by design" architecture taking also into
>>>         consideration "security by design".
>>>
>>>         Coming back to your requirement, I would not cover it if it
>>>         infringes the sentence "the RS and the AS never communicate
>>>         directly".
>>>
>>>         You should start your design by defining the trust
>>>         relationships, then apply the privacy requirements while not
>>>         forgetting the security requirements.
>>>
>>>         Denis
>>>
>>>>         Hello Denis,
>>>>
>>>>         I have been following your comments. I still fail to see
>>>>         the global privacy preserving architecture you're
>>>>         proposing. It would help to get a more thorough proposal if
>>>>         you can.
>>>>
>>>>         But more specifically, I have a comment on :
>>>>
>>>>         "I would have preferred that you meant: the RS and the AS never
>>>>         communicate directly, which is indeed a nice property to follow
>>>>         to ensure the user's privacy."
>>>>         I think that may come as an issue in some cases, especially for multiparty patterns (like in UMA). Typically we may wish the RS to start a grant request and use the handle to continue until a token is generated.
>>>>         I think those cases, which weren't initially covered by OAuth2, are very important to cover as well. How would you cover such requirements?
>>>>         Fabien
>>>>
>>>
>>
>> -- 
>> Txauth mailing list
>> Txauth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/txauth
>


--------------D654A8511FA717314FC89EAE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Justin,

    


    

    

      
      Fabien and Denis,
      


      

      
I think here we can see that there are multiple
        different directions that people’s use cases and concerns will
        pull GNAP’s design. Some want to have the AS have no knowledge
        of the RS, and only the client to know that; others want the AS
        to have knowledge of all of its RS’s and be able to dispatch an
        naive client to one. The thing is, I think both of these have
        merit and both of them can be accommodated in the protocol.
        Allowing one does not disallow the other. It’s not up to GNAP to
        decide which of these approaches is morally correct.

    

    

    As soon as we allow a RS to get access tokens from multiples ASs,
    the driving of a client by a single AS does not make sense
    any more.

    If we allow the RSs to drive the clients, it will also apply to
    "naive clients" and then they do not need to be driven by a single
      AS.
    
The model should be the same whether a RS requests to get an
      access token from a single AS or from multiple ASs.

    
The delegation model would also be quite different whether the
      client will be driven by a single AS or be driven by each RS 

      that is attempting to respond to an original operation.  Has the
      delegation model been discussed on the mailing list ?

    
Accommodating both approaches in the same protocol appears to me
      rather difficult: 

      I do not see how "privacy by design" could be melt into "spy by
      design" nor how "spy by design" could  be melt into "privacy by
      design".

    
Denis

    

      
In particular, addressing both of these dimensions
        is one of the things that having a multi-dimensional language
        for requesting resources in a standard way is going to help
        beyond what OAuth 2 can do. These queries can be designed in
        such a way to minimize disclosure to the AS or to minimize the
        amount of knowledge in the client, or anywhere in between.
        Ultimately it’s up to the RS to decide whether the rights
        associated with the token are good enough for the request, and
        GNAP’s proposed charter says we’ll be defining both a means for
        fine-grained requests as well as a consistent data model for the
        token’s rights. Neither of these assumes that the RS will be
        identified, nor that it can’t be.

      


      

      
 — Justin

        


          

            
On Jul 6, 2020, at 7:06 AM, Fabien Imbault
              <fabien.imbault@gmail.com>
              wrote:

            

            

              
              
Hi Denis,
                


                

                
Thanks for your feedback. Your
                  scheme is interesting and covers well the personal
                  access. 

                


                

                
The variant I'm referring to is
                  multiparty access, which is a fairly common pattern
                  also. Handled as an extension in Oauth2, but to my
                  knowledge it requires an additional relationship
                  between RS and AS. Maybe we can come up with an
                  alternative design, I don't know yet. 

                


                

                
Cheers. 

                


                

                
Fabien 

                


                

              

              

              

                
Le lun. 6 juil. 2020 à
                  12:23, Denis <denis.ietf@free.fr>
                  a écrit :

                

                

                  

                    
Hello Fabien,

                    

                      
Thanks Denis. It clarifies
                        what you have in mind. 
                        


                        

                        
While I agree with the general
                          idea that we need to take privacy more
                          seriously, there are a few hypotheses that we
                          need to put in perspective : 

                          

                        

                        
1) AS-RS relationship <=>
                          big brother. It may happen as we all know, but
                          you always have the choice as a user to not
                          deal with orgs you don't like 

                          or maybe even take action if they don't
                          respect the law.

                        

                      

                    

                    
Unfortunately, the choice you mention is
                      not always possible. There is a fundamental point
                      here: since it is not always possible to trust an
                      AS to respect the law,

                      it is possible to build an architecture where the
                      AS will be unable to by-pass the law. It is the
                      difference between :

                    
    
                      
  • "the AS should not
                        do this or that" (but it could if it would) and
    • 
                      
  • "the AS cannot do
                        this or that" (it cannot even if it would).  
    
                      
    • 
                    

                    

                      

                        
2) the collusion possibility
                          (Alice's uncle) : there are of course
                          situations where that may be an issue. This is
                          I guess the reason for the sovrin foundation 

                          to require that only approved issuers can
                          participate. But even if you open up the
                          system, it always ends up as whether you can
                          trust the uncle to be honest 

                          in the first place (knowing that trust is a
                          social construct). 

                      

                    

                    
When using computers, trust is not a
                      "social construct". It is a construction where an
                      entity A trusts an entity B for some behaviour C.
                      

                      In the ABC attack, the RS will never know whether
                      someone forwarded or not an access token to Alice.

                    

                    

                      

                        
So I may require the issuer to be
                          a well known participant instead.

                          

                          3) The use of hardware FIDO inspired
                          components does relax some of the previous
                          concern, but comes with its own sets of
                          challenges.

                          Biometrics come with their own sets of
                          potential issues. 

                      

                    

                    
The use of FIDO does not imply that you
                      must use its biometrics features.

                    

                      

                        
More trivially, if you loose your
                          hardware, you loose your ID. 

                      

                    

                    
If you loose your ID, you should report
                      of its loss. It also means that by design, a
                      mechanism has been constructed to recover from the
                      situation 

                      within a short period of time. Unfortunately, such
                      a property is currently missing in FIDO, but it
                      does not mean that it cannot be added.

                    

                    

                      

                        
And there can also be hacks in
                          hardware. If I find a way to import or export
                          the private key from the enclave, the system
                          fails.

                      

                    

                    
The whole system does not fail. When
                      someone attempts to export a private key from an
                      hardware device in an unlawful way, it takes some
                      time and some expertise.

                      As soon as the legitimate holder realizes the lost
                      of his hardware, he should report the loss. Then
                      after, the discovery of private keys stored into
                      the device is no more an issue.

                    

                      

                        
So in the end, I agree it's best
                          to enable as much privacy by design as we
                          possibly can, but we need to put that in
                          perspective with use cases too and make some
                          tradeoffs. 

                          Healthcare in particular is a domain that is
                          concerned with a constant balance between
                          privacy and security, and sometimes there is
                          no possibility to tick all boxes. 

                        
I think an UMA2/OpenId Heart
                          scenario is a very important case to consider
                          in that respect. 

                        

                      

                    

                    
The goal of this BoF/WG is not to
                      rubber-stamp the "Health Relationship Trust
                      Profile for User-Managed Access 2.0"
                      specification. 

                    
Since the "Health Relationship Trust
                      Profile for User-Managed Access 2.0" specification
                      has nothing really specific to healthcare, what is
                      the "very important case" you have in mind ?

                      Would it be possible to model a specific
                      characteristic you have in mind in terms of model
                      components, operations flows, trust relationships,
                      privacy requirements and security requirements ?

                    

                    
Denis

                    

                    

                      

                        


                        

                        
Fabien 

                        


                        

                        


                        

                        


                        

                      

                      

                      

                        
On Fri, Jul 3,
                          2020 at 12:01 PM Denis <denis.ietf@free.fr>
                          wrote:

                        

                        

                          

                            
Hello Fabien,

                            


                            

                            
In 2017, I made a presentation
                              at the OAuth workshop in Zurich.

                            


                            

                            
                            


                            

                            
                            
Note: The
                              slides should be viewed "full screen" to
                              get the animations. 

                            

                            


                            

                            
The general approach is how to
                              construct from scratch a "privacy by
                              design" architecture taking also into
                              consideration "security by design".

                            


                            

                            
Coming back to your
                              requirement, I would not cover it if it
                              infringes the sentence "the RS and the AS
                              never communicate directly".

                            


                            

                            
You should start your design
                              by defining the trust relationships, then
                              apply the privacy requirements while not
                              forgetting the security requirements.

                              

                            

                            
Denis

                            


                            

                            

                              
Hello Denis,
                                


                                

                                
I have been following your
                                  comments. I still fail to see the
                                  global privacy preserving architecture
                                  you're proposing. It would help to get
                                  a more thorough proposal if you can.

                                  


                                  

                                  
But more specifically, I
                                    have a comment on : 

                                  


                                  

                                  

                                    
"I would have preferred that you meant: the RS and the AS never 
communicate directly, which is indeed a nice property to follow
to ensure the user's privacy."

                                    
I think that may come as an issue in some cases, especially for multiparty patterns (like in UMA). Typically we may wish the RS to start a grant request and use the handle to continue until a token is generated.

                                    
I think those cases, which weren't initially covered by OAuth2, are very important to cover as well. How would you cover such requirements?

                                    
Fabien

                                  

                                

                              

                              

                              

                            

                            


                            

                          

                        

                      

                    

                    


                    

                  

                

              

              -- 

              Txauth mailing list

              Txauth@ietf.org

              https://www.ietf.org/mailman/listinfo/txauth

            

          

        

        

      

    

    


    

  


--------------D654A8511FA717314FC89EAE--


From nobody Mon Jul  6 13:41: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 2879E3A0A8B for ; Mon,  6 Jul 2020 13:41:54 -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 mURADvjcuHGF for ; Mon,  6 Jul 2020 13:41:52 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 69C523A0A87 for ; Mon,  6 Jul 2020 13:41:52 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id e8so12903318ljb.0 for ; Mon, 06 Jul 2020 13:41: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=fQ/aRR0rixwXJ9hpBo21V+Tf1uuSZeRGIg4OU/4nISI=; b=gRThaIguTojpqM0PTQ7UHfONngPERoHYgU7g2UoLbqx1zBSQCfbhQQjJVMMVNLwQ43 cmGsxV7PuSu2vnaSu5+el5mzePWunA1qv5uW/SAbt9ATWrh0YyXKX/MDkxeqvHZHKD8Z 3DzOwQob3D2e6QOeN2zcu6iK1CISmpZhcZlgyn5cmyEAwKZ4imZtsGS63f7THo1JDxOC A84UCzQH32hUQ/u9avbkT5kcX9kKtPmf520a3OtBqJc1G/3D+B/BJIoil3zjOqygCjjd Tk2L02RXy3EP2+QKZs6kfiw/NqsXPRq59av3iQQaKhp/vH0JhjyAycMwlnYDLKBKMJNO oVUQ==
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=fQ/aRR0rixwXJ9hpBo21V+Tf1uuSZeRGIg4OU/4nISI=; b=HGKZxR5RkxCN3NUeuMdeBdEB24nbEPHCAcbjV/sYSBH3iZ0edBUofRu7daBcfA9kJO EMGBv+ufHAQjDJj+d6GcxHumqt/7GFK82v5jBVYC828so/2qfLOq/Ls3/YiCSWy69NbN 5WoctMtT8txzeXAyi9u0ahFGisx6FeNFL60ORzzYWf9plZWr/JF4eU53fKX0SZIBIuzt S/GjhKLe673lgd3BtEfDoiwaQzxneuqNz+HOGwoYAwqC7RZGtp3jwKF1qaDWOZ08MPi2 IptlFDTW+qT6yOSNlupwtdmSuOi67fV+Yng8+lnEgUBnjeBFplqjZa0DRQtyKkZTDiww zIsQ==
X-Gm-Message-State: AOAM533s3QfbZr9tKBeASufz63+Cb67Ed1air8zUsRELS00j7oJCoyPm LVvSD+AQjfImbWGjkFaKlvki/1wKZF6vy6LH618=
X-Google-Smtp-Source: ABdhPJxisZjjhhmOX1X8JGZnJAcrTmZSNJQKwkAOx2D1vKrriWzh6ceNxWWdGWGexgU/6JH6+DX4ux85Bys7uQkU2Oc=
X-Received: by 2002:a2e:7f10:: with SMTP id a16mr29525338ljd.69.1594068110439;  Mon, 06 Jul 2020 13:41:50 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 6 Jul 2020 13:41:14 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007879ce05a9cbe794"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 06 Jul 2020 20:41:55 -0000

--0000000000007879ce05a9cbe794
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Responding to Justin's polymorphism comments ...

On Mon, Jul 6, 2020 at 12:54 PM Justin Richer  wrote:

> Polymorphism in the protocol is an important part of the XYZ proposal=E2=
=80=99s
> design, and as a feature it directly addresses a number of the items you
> found when doing your XAuth implementation, like parsing OAuth scopes and
> dealing with the authorization/authorizations mutually-exclusive oddness
> that you mentioned. I strongly believe that GNAP should make use of a
> polymorphic protocol structure for these and other reasons. Polymorphism =
is
> a built-in feature of the JSON data model, and it=E2=80=99s also fully po=
ssible to
> support under CBOR and other data serialization languages. Even JWT most
> famously uses polymorphism for the =E2=80=9Caud=E2=80=9D field, which can=
 be a string or an
> array of strings depending on context, all with clear semantics.
>

 I strongly disagree with "GNAP should make use of a polymorphic protocol
structure"

We should use it only if we really need it, and it makes implementations
simpler. I personally don't think it accomplished that in JWT with the
audience. I would bet there is a fair amount of code that does not check if
the 'aud' property is an array, it just assumes it is a string.

wrt. my authorization / authorizations oddness, polymorphism would not
solve it as the contents of both authorization / authorizations in XAuth
are objects.

/Dick

--0000000000007879ce05a9cbe794
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Responding to Justin's polymorphism comments ...=C2=A0

On Mon, Jul 6, =
2020 at 12:54 PM Justin Richer <jrich=
er@mit.edu> wrote:
Polymorphism in t=
he protocol is an important part of the XYZ proposal=E2=80=99s design, and =
as a feature it directly addresses a number of the items you found when doi=
ng your XAuth implementation, like parsing OAuth scopes and dealing with th=
e authorization/authorizations mutually-exclusive oddness that you mentione=
d. I strongly believe that GNAP should make use of a polymorphic protocol s=
tructure for these and other reasons. Polymorphism is a built-in feature of=
 the JSON data model, and it=E2=80=99s also fully possible to support under=
 CBOR and other data serialization languages. Even JWT most famously uses p=
olymorphism for the =E2=80=9Caud=E2=80=9D field, which can be a string or a=
n array of strings depending on context, all with clear semantics.

=C2=A0I strongly disagree with "GN=
AP should make use of a polymorphic protocol structure"

=

We should use it only if we really need it, and it makes impleme=
ntations simpler. I personally don't think it accomplished that in JWT =
with the audience. I would bet there is a fair amount of code that does not=
 check if the 'aud' property is an array, it just assumes it is a s=
tring.

wrt. my authorization / authorizations oddn=
ess, polymorphism would not solve it as the contents of both authorization =
/ authorizations in XAuth are objects.=C2=A0

/Dick=




--0000000000007879ce05a9cbe794--


From nobody Mon Jul  6 14:15: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 7B7C03A0AF9 for ; Mon,  6 Jul 2020 14:15:09 -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 yowPTaQOSFnQ for ; Mon,  6 Jul 2020 14:15:08 -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 C3C7D3A0AF8 for ; Mon,  6 Jul 2020 14:15:07 -0700 (PDT)
Received: from [192.168.1.7] (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 066LF48b012567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jul 2020 17:15:05 -0400
From: Justin Richer 
Message-Id: <18579E44-EF14-49A6-903C-8B45A832B59A@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EB20E481-6885-4725-A14B-DFA72E23A1B2"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 6 Jul 2020 17:15:04 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 06 Jul 2020 21:15:10 -0000

--Apple-Mail=_EB20E481-6885-4725-A14B-DFA72E23A1B2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I once felt that way, too, and the first few iterations of XYZ did not =
use polymorphism. But I found, through hands-on experience, that it =
solves many more problems than it creates. I think that JWT didn=E2=80=99t=
 quite do it because there was one limited place in the spec that used =
the feature =E2=80=94 it was the exception, not a core part of the data =
model. And, JWT implementations that don=E2=80=99t expect an array in =
=E2=80=9Caud=E2=80=9D aren=E2=80=99t compliant, after all.

This is obviously an implementation detail for the WG to debate, and I =
think polymorphism should be one of the tools in consideration from the =
start.=20

 =E2=80=94 Justin

> On Jul 6, 2020, at 4:41 PM, Dick Hardt  wrote:
>=20
>=20
> Responding to Justin's polymorphism comments ...=20
>=20
> On Mon, Jul 6, 2020 at 12:54 PM Justin Richer > wrote:
> Polymorphism in the protocol is an important part of the XYZ =
proposal=E2=80=99s design, and as a feature it directly addresses a =
number of the items you found when doing your XAuth implementation, like =
parsing OAuth scopes and dealing with the authorization/authorizations =
mutually-exclusive oddness that you mentioned. I strongly believe that =
GNAP should make use of a polymorphic protocol structure for these and =
other reasons. Polymorphism is a built-in feature of the JSON data =
model, and it=E2=80=99s also fully possible to support under CBOR and =
other data serialization languages. Even JWT most famously uses =
polymorphism for the =E2=80=9Caud=E2=80=9D field, which can be a string =
or an array of strings depending on context, all with clear semantics.
>=20
>  I strongly disagree with "GNAP should make use of a polymorphic =
protocol structure"
>=20
> We should use it only if we really need it, and it makes =
implementations simpler. I personally don't think it accomplished that =
in JWT with the audience. I would bet there is a fair amount of code =
that does not check if the 'aud' property is an array, it just assumes =
it is a string.
>=20
> wrt. my authorization / authorizations oddness, polymorphism would not =
solve it as the contents of both authorization / authorizations in XAuth =
are objects.=20
>=20
> /Dick
>=20


--Apple-Mail=_EB20E481-6885-4725-A14B-DFA72E23A1B2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
once felt that way, too, and the first few iterations of XYZ did not use =
polymorphism. But I found, through hands-on experience, that it solves =
many more problems than it creates. I think that JWT didn=E2=80=99t =
quite do it because there was one limited place in the spec that used =
the feature =E2=80=94 it was the exception, not a core part of the data =
model. And, JWT implementations that don=E2=80=99t expect an array in =
=E2=80=9Caud=E2=80=9D aren=E2=80=99t compliant, after all.

This is obviously an =
implementation detail for the WG to debate, and I think polymorphism =
should be one of the tools in consideration from the =
start. 

 =E2=80=94 Justin

On Jul =
6, 2020, at 4:41 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


Responding to Justin's polymorphism comments =
... 

On Mon, Jul 6, 2020 at 12:54 PM Justin =
Richer <jricher@mit.edu> wrote:
Polymorphism in the protocol is =
an important part of the XYZ proposal=E2=80=99s design, and as a feature =
it directly addresses a number of the items you found when doing your =
XAuth implementation, like parsing OAuth scopes and dealing with the =
authorization/authorizations mutually-exclusive oddness that you =
mentioned. I strongly believe that GNAP should make use of a polymorphic =
protocol structure for these and other reasons. Polymorphism is a =
built-in feature of the JSON data model, and it=E2=80=99s also fully =
possible to support under CBOR and other data serialization languages. =
Even JWT most famously uses polymorphism for the =E2=80=9Caud=E2=80=9D =
field, which can be a string or an array of strings depending on =
context, all with clear semantics.

 I strongly =
disagree with "GNAP should make use of a polymorphic protocol =
structure"

We =
should use it only if we really need it, and it makes implementations =
simpler. I personally don't think it accomplished that in JWT with the =
audience. I would bet there is a fair amount of code that does not check =
if the 'aud' property is an array, it just assumes it is a =
string.

wrt. =
my authorization / authorizations oddness, polymorphism would not solve =
it as the contents of both authorization / authorizations in XAuth are =
objects. 

/Dick




=

--Apple-Mail=_EB20E481-6885-4725-A14B-DFA72E23A1B2--


From nobody Mon Jul  6 14:19: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 34ED83A0B06 for ; Mon,  6 Jul 2020 14:19:03 -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 AuHazCeuXKxV for ; Mon,  6 Jul 2020 14:19:01 -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 8133C3A0B03 for ; Mon,  6 Jul 2020 14:19:01 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id 9so47267187ljv.5 for ; Mon, 06 Jul 2020 14:19:01 -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=3ZIq0SSh7b5K25vLdtmm3hu833hKf4jEz4Rlz7AajRM=; b=PwGz98Cwk6mp5HaJSvNhk+oAbkSVGZGDezmHyQXzFhYhvk8pmqRfqSc5V+23kKMo5N V35n4n3cNxRikRBvb26ARZ3kSwUesPbzeOj0TxspejZPRgZOw9wBRmvKlsqRVPC18ImF H4Xdsgt/vDm7HvaHZH7K+j1GuCyje6SArJvNGjkf6mrT7qbaFMA9z5F59xzQZHftfvro qXdAo5xfq2NeT2ljn4TqRs7/tuUUhYdR010ZOY4vKdqY/69od+iwKpCNgAJ/2sgaVlbH 4xxnu6RY2NRfmPWgIRSdf8wSAqhfv3GApsQS+gEhGQ3BS1Ab9S+znGa+Y2o4R9DK8RTi SSyw==
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=3ZIq0SSh7b5K25vLdtmm3hu833hKf4jEz4Rlz7AajRM=; b=kCiaz4y/UmytyNvDJIuCXtDHz9JrMNaln417P/jFM4qMYEU/kBC9eZ0t9rW4Jh+Er/ NmPudgQMP7M3URR+gG2ucuL5RtV0Y4iGH6ojXvPTfZeisbnjcLQIXGAh/kHofFIkkXfI HtbZ9ytx68dDZNuvvDvsfW5fZUa5Bisi03I0aSm4i5u7yyxcOIGRPpI/ytW9bdNTndri r5zx3Px3XF5KG+JJ0Vn+c8AEQDZgjWApVz/a8T0roWCs9v95LTTBIPdiHRPXB2ivPaXh P2Wn4CigwIfCDX8vXpcFh+12Hv6IZ7RgtrbUKyHU4u50mJ0kgpoTJFgi6o04s+p6+Sea 5KQg==
X-Gm-Message-State: AOAM530VFM5+t0rZsj25j0jOtp+rcwJ9dUFnc38R78DpgwcvV1TDogVy Frp0hhzHwR1ZDVOoA+4m0lU8VBz6fe76o8AglVo=
X-Google-Smtp-Source: ABdhPJw6r8KRO5ROCw0hmvs/VVlBtcw17I4DXLSccf7cX520IBxKVFV+yfscWFw3tlKddrocKhzmJpvCIMVZDL7gwxE=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr16723460ljh.110.1594070339498;  Mon, 06 Jul 2020 14:18:59 -0700 (PDT)
MIME-Version: 1.0
References:    <18579E44-EF14-49A6-903C-8B45A832B59A@mit.edu>
In-Reply-To: <18579E44-EF14-49A6-903C-8B45A832B59A@mit.edu>
From: Dick Hardt 
Date: Mon, 6 Jul 2020 14:18:23 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005535a605a9cc6c84"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 06 Jul 2020 21:19:03 -0000

--0000000000005535a605a9cc6c84
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree with:

"I think polymorphism should be one of the tools in consideration from the
start."

I was disagreeing with the 'should' in:

"GNAP should make use of a polymorphic protocol structure"


On Mon, Jul 6, 2020 at 2:15 PM Justin Richer  wrote:

> I once felt that way, too, and the first few iterations of XYZ did not us=
e
> polymorphism. But I found, through hands-on experience, that it solves ma=
ny
> more problems than it creates. I think that JWT didn=E2=80=99t quite do i=
t because
> there was one limited place in the spec that used the feature =E2=80=94 i=
t was the
> exception, not a core part of the data model. And, JWT implementations th=
at
> don=E2=80=99t expect an array in =E2=80=9Caud=E2=80=9D aren=E2=80=99t com=
pliant, after all.
>
> This is obviously an implementation detail for the WG to debate, and I
> think polymorphism should be one of the tools in consideration from the
> start.
>
>  =E2=80=94 Justin
>
> On Jul 6, 2020, at 4:41 PM, Dick Hardt  wrote:
>
>
> Responding to Justin's polymorphism comments ...
>
> On Mon, Jul 6, 2020 at 12:54 PM Justin Richer  wrote:
>
>> Polymorphism in the protocol is an important part of the XYZ proposal=E2=
=80=99s
>> design, and as a feature it directly addresses a number of the items you
>> found when doing your XAuth implementation, like parsing OAuth scopes an=
d
>> dealing with the authorization/authorizations mutually-exclusive oddness
>> that you mentioned. I strongly believe that GNAP should make use of a
>> polymorphic protocol structure for these and other reasons. Polymorphism=
 is
>> a built-in feature of the JSON data model, and it=E2=80=99s also fully p=
ossible to
>> support under CBOR and other data serialization languages. Even JWT most
>> famously uses polymorphism for the =E2=80=9Caud=E2=80=9D field, which ca=
n be a string or an
>> array of strings depending on context, all with clear semantics.
>>
>
>  I strongly disagree with "GNAP should make use of a polymorphic protocol
> structure"
>
> We should use it only if we really need it, and it makes implementations
> simpler. I personally don't think it accomplished that in JWT with the
> audience. I would bet there is a fair amount of code that does not check =
if
> the 'aud' property is an array, it just assumes it is a string.
>
> wrt. my authorization / authorizations oddness, polymorphism would not
> solve it as the contents of both authorization / authorizations in XAuth
> are objects.
>
> /Dick
>
>
>

--0000000000005535a605a9cc6c84
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I agree with:
"I think polymorphism should be one of the tools in consi=
deration from the start."

I was disagreeing w=
ith the 'should' in:

"GNAP should mak=
e use of a polymorphic protocol structure"


On Mon, Jul 6, 2020 at 2:15 PM Justin Richer <jricher@mit.edu> wrote:
=
I once felt that way, too, and the first few iterations of XYZ did not use =
polymorphism. But I found, through hands-on experience, that it solves many=
 more problems than it creates. I think that JWT didn=E2=80=99t quite do it=
 because there was one limited place in the spec that used the feature =E2=
=80=94 it was the exception, not a core part of the data model. And, JWT im=
plementations that don=E2=80=99t expect an array in =E2=80=9Caud=E2=80=9D a=
ren=E2=80=99t compliant, after all.

This is obviously an=
 implementation detail for the WG to debate, and I think polymorphism shoul=
d be one of the tools in consideration from the start.=C2=A0

=

=C2=A0=E2=80=94 Justin

On Jul 6, 2020, at 4:41 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


=

Responding to Justin's polymorphism comments ...=C2=A0

On Mon, Jul =
6, 2020 at 12:54 PM Justin Richer <jricher@mit.edu> wrote:
Polymorphism in the protocol is =
an important part of the XYZ proposal=E2=80=99s design, and as a feature it=
 directly addresses a number of the items you found when doing your XAuth i=
mplementation, like parsing OAuth scopes and dealing with the authorization=
/authorizations mutually-exclusive oddness that you mentioned. I strongly b=
elieve that GNAP should make use of a polymorphic protocol structure for th=
ese and other reasons. Polymorphism is a built-in feature of the JSON data =
model, and it=E2=80=99s also fully possible to support under CBOR and other=
 data serialization languages. Even JWT most famously uses polymorphism for=
 the =E2=80=9Caud=E2=80=9D field, which can be a string or an array of stri=
ngs depending on context, all with clear semantics.

=C2=A0I strongly disagree with "GNAP should make =
use of a polymorphic protocol structure"

We s=
hould use it only if we really need it, and it makes implementations simple=
r. I personally don't think it accomplished that in JWT with the audien=
ce. I would bet there is a fair amount of code that does not check if the &=
#39;aud' property is an array, it just assumes it is a string.

wrt. my authorization / authorizations oddness, polymorphi=
sm would not solve it as the contents of both authorization / authorization=
s in XAuth are objects.=C2=A0

/Dick

=






--0000000000005535a605a9cc6c84--


From nobody Mon Jul  6 20:08: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 414563A09A4; Mon,  6 Jul 2020 20:08:42 -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_FILL_THIS_FORM_SHORT=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=cert.org
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 zHpKZJh97K8j; Mon,  6 Jul 2020 20:08:39 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 0266E3A09A3; Mon,  6 Jul 2020 20:08:38 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06738ZoK004184; Mon, 6 Jul 2020 23:08:35 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 06738ZoK004184
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1594091315; bh=bu9Bbai87uhpKaMXXHNtmylPHuI+qcO/Wmzioofog7I=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=B2UCdpVeWpIchd6ulz00JOhJWThd5RDfjqn3BKCACgXi0/PWakvC1yqAledohcez4 8pKflGHFJC0rdi0J77wCxIsfpzg44EB5EUWcLNTB9maZn9WOpD0frxkdMZ/br/+iig JTzgPWKsBf4TYkfznXBGiwtnByUrg9TgA/pCN6TA=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06738Yv9045183; Mon, 6 Jul 2020 23:08:34 -0400
Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 6 Jul 2020 23:08:34 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 6 Jul 2020 23:08:33 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Mon, 6 Jul 2020 23:08:33 -0400
From: Roman Danyliw 
To: Denis , "iesg@ietf.org" 
CC: "txauth@ietf.org" 
Thread-Topic: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
Thread-Index: AQHWS9RNiDy30JPhzE2lVpUcI/9Maqj69j8AgABtYMA=
Date: Tue, 7 Jul 2020 03:08:32 +0000
Message-ID: <3424311c60f541b197cfda6e9f3b494e@cert.org>
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <7563640e-f515-3e73-a4eb-3902ec7af50e@free.fr>
In-Reply-To: <7563640e-f515-3e73-a4eb-3902ec7af50e@free.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.202.182]
Content-Type: multipart/alternative; boundary="_000_3424311c60f541b197cfda6e9f3b494ecertorg_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 07 Jul 2020 03:08:42 -0000

--_000_3424311c60f541b197cfda6e9f3b494ecertorg_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgRGVuaXMhDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIGFuZCBmb3IgcmVwZWF0aW5nIHlv
dXIgcmV2aWV3IG9uIHRoZSByZXZpc2VkIHRleHQuICBNb3JlIGlubGluZSDigKYNCg0KRnJvbTog
aWVzZyA8aWVzZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRGVuaXMNClNlbnQ6IE1v
bmRheSwgSnVseSA2LCAyMDIwIDEwOjU1IEFNDQpUbzogaWVzZ0BpZXRmLm9yZw0KQ2M6IHR4YXV0
aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUeGF1dGhdIFdHIFJldmlldzogR3JhbnQgTmVnb3Rp
YXRpb24gYW5kIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgKGduYXApDQoNClNpbmNlIGl0IGlzIHRv
ZGF5IHRoZSBsYXN0IGRheSB0byBzZW5kIGJhY2sgY29tbWVudHMsIHlvdSB3aWxsIGZpbmQgaGVy
ZWFmdGVyIG15IGNvbW1lbnRzIG9uIHRoZSBsYXN0IGNoYXJ0ZXIgdmVyc2lvbi0wNS4NCmNoYXJ0
ZXItaWV0Zi1nbmFwLTAwLTA1DQoNClRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3Ag
YSBmaW5lLWdyYWluZWQgZGVsZWdhdGlvbiBwcm90b2NvbCBmb3IgYXV0aG9yaXphdGlvbiwgQVBJ
IGFjY2VzcywgdXNlciBpZGVudGlmaWVycywgYW5kIGlkZW50aXR5IGFzc2VydGlvbnMuDQoNCg0K
DQpbRGVuaXNdIEZpbmUuDQoNCg0KDQpUaGUgcHJvdG9jb2wgd2lsbCBhbHNvIGFsbG93IHRoZSBj
bGllbnQgdG8gcHJlc2VudCB1bnZlcmlmaWVkIGlkZW50aWZpZXJzIGFuZCB2ZXJpZmlhYmxlIGFz
c2VydGlvbnMgdG8gdGhlIEFTIGFzIHBhcnQgb2YgaXRzIHJlcXVlc3QuDQoNCg0KDQpbRGVuaXNd
IFRoaXMgc2VudGVuY2UgaXMgdG9vIHZhZ3VlIGJlY2F1c2UgImFzIHBhcnQgb2YgaXRzIHJlcXVl
c3QiIGlzIG5vdCBleHBsaWNpdCBlbm91Z2guIElmIGl0IG1lYW5zICAiYXMgcGFydCBhcyBhbiBh
Y2Nlc3MgdG9rZW4gcmVxdWVzdCINCg0KdGhpcyBzaG91bGQgYmUgZXhwbGljaXRseSBzYWlkLiBJ
ZiwgaXQgaXMgbm90IHRoZSBjYXNlLCB0aGVuIGl0IHNob3VsZCBiZSBjbGVhcmx5IGV4cGxhaW5l
ZC4gVGhlIEFTIHNob3VsZCBrbm93IGFzIGxpdHRsZSBhcyBwb3NzaWJsZSAoaW5jbHVkaW5nIG5v
dGhpbmcpDQoNCmFib3V0IHdoYXQgdGhlIGNsaWVudCBpcyBkb2luZy4NCg0KDQoNCltSb21hbl0g
VGhlIOKAnHJlcXVlc3TigJ0gaGVyZSBpcyB0aGUg4oCcYWNjZXNzIHRva2VuIHJlcXVlc3TigJ0u
ICBUaGF0IGNhbiBiZSBtYWRlIGNsZWFyZXIuDQoNCg0KDQpUaGlzIHByb3RvY29sIHdpbGwgYWxs
b3cgYW4gYXV0aG9yaXppbmcgcGFydHkgdG8gZGVsZWdhdGUgYWNjZXNzIHRvIGNsaWVudCBzb2Z0
d2FyZSB0aHJvdWdoIGFuIGF1dGhvcml6YXRpb24gc2VydmVyLg0KDQoNCg0KW0RlbmlzXSBUaGUg
d29yZCAicHJpdmFjeSIgaXMgc3RpbGwgbWlzc2luZyBpbiB0aGUgY2hhcnRlci4gIkRlbGVnYXRp
bmcgYWNjZXNzIHRvIGNsaWVudCBzb2Z0d2FyZSB0aHJvdWdoIGFuIGF1dGhvcml6YXRpb24gc2Vy
dmVyIg0KDQppcyBuZWdhdGluZyB0aGUgZmFjdCB0aGF0IHRoZSB1c2VyJ3MgcHJpdmFjeSB3aWxs
IGV2ZXIgYmUgY29uc2lkZXJlZC4gSU1ITywgSSBiZWxpZXZlIHRoYXQgYSBSUyBtYXkgZGVsZWdh
dGUgc29tZSBvcGVyYXRpb24gdG8gYW5vdGhlciBSUywNCg0KYnV0IEkgZG9uJ3QgYmVsaWV2ZSB0
aGF0IGFuIEFTIHNob3VsZCBiZSBjb25jZXJuZWQgYnkgYW55IGZvcm0gb2YgZGVsZWdhdGlvbiwg
b3RoZXJ3aXNlIGl0IHdvdWxkIGhhdmUgdGhlIGFiaWxpdHkgdG8gYWN0IGFzICJCaWcgQnJvdGhl
ciIuDQoNCk9BdXRoIGhhcyBub3QgYmVlbiBjb25zdHJ1Y3RlZCB0YWtpbmcgaW50byBjb25zaWRl
cmF0aW9uIHRoZSB1c2VyJ3MgcHJpdmFjeS4gVGhlIG1ham9yIGRpZmZlcmVuY2Ugd2l0aCBpdCBz
aG91bGQgYmUgdGhhdCBHTkFQIGhhcyBiZWVuDQoNCmNvbnN0cnVjdGVkIGFsb25nICJwcml2YWN5
IGJ5IGRlc2lnbiIgcHJpbmNpcGxlcy4NCg0KDQoNCltSb21hbl0gIEkgZG9u4oCZdCBleGFjdGx5
IGZvbGxvdyBob3cgY29uc2lkZXJhdGlvbnMgZm9yIHByaXZhY3kgYXJlIGJlaW5nIG5lZ2F0ZWQu
ICBBYm92ZSBhbmQgYmV5b25kIHVzZS1jYXNlIHNwZWNpZmljIGNvbnNpZGVyYXRpb25zIHRoYXQg
d291bGQgYmUgZGVmaW5lZCBsYXRlciwgUkZDNjk3MyBpcyB0aGUgSUVURiBjb25zZW5zdXMgZGVz
aWduIGd1aWRhbmNlIHRoYXQgd2lsbCBndWlkZSB0aGUgcHJpdmFjeSB0aHJlYXRzIGFuZCBtaXRp
Z2F0aW9ucyBvZiB0aGUgd29yay4gIFdoYXQgZGVzaWduIGd1aWRhbmNlIHdvdWxkIHlvdSByZWNv
bW1lbmQgdGhhdCB0aGUgV0cgc2hvdWxkIGNvbnNpZGVyIHRoYXQgYXJlbuKAmXQgY2FwdHVyZWQg
aW4gUkZDNjk3Mz8NCg0KDQoNCkl0IHdpbGwgZXhwYW5kIHVwb24gdGhlIHVzZXMgY2FzZXMgY3Vy
cmVudGx5IHN1cHBvcnRlZCBieSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0IChpdHNlbGYg
YW4gZXh0ZW5zaW9uIG9mIE9BdXRoIDIuMCkgdG8gc3VwcG9ydCBhdXRob3JpemF0aW9ucw0KDQpz
Y29wZWQgYXMgbmFycm93bHkgYXMgYSBzaW5nbGUgdHJhbnNhY3Rpb24sIHByb3ZpZGUgYSBjbGVh
ciBmcmFtZXdvcmsgZm9yIGludGVyYWN0aW9uIGFtb25nIGFsbCBwYXJ0aWVzIGludm9sdmVkIGlu
IHRoZSBwcm90b2NvbCBmbG93LCBhbmQgcmVtb3ZlDQoNCnVubmVjZXNzYXJ5IGRlcGVuZGVuY2Ug
b24gYSBicm93c2VyIG9yIHVzZXItYWdlbnQgZm9yIGNvb3JkaW5hdGluZyBpbnRlcmFjdGlvbnMu
DQoNCg0KDQpbRGVuaXNdIFRoZXJlIGlzIG5vIG5lZWQgdG8gcmVmZXIgdG8gT0F1dGggMi4wIGFu
ZCBPcGVuSUQgQ29ubmVjdC4gU29tZSBleGlzdGluZyB1c2VzIGNhc2VzIChpLmUuICJub24tZXhw
YW5kZWQiIHVzZSBjYXNlcykgc2hvdWxkIGJlIHN1cHBvcnRlZA0KDQpkaWZmZXJlbnRseSBmcm9t
IE9BdXRoIDIuMCBhbmQgT3BlbklEIENvbm5lY3QsIGluIHBhcnRpY3VsYXIgdG8gc3VwcG9ydCB0
aGUgdXNlcidzIHByaXZhY3kuDQoNCg0KDQpbUm9tYW5dIEnigJlkIHdhbnQgdG8gaGVhciBvdGhl
cnMgb24gdGhpcyByZXNjb3BpbmcuICBCdWlsZGluZyB1cG9uIHRoZSB1c2UgY2FzZXMgb2YgT0F1
dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCBoYXMgYmVlbiBjb3JlLCBjb25zZW5zdXMtdmFsaWRh
dGVkIHRlbmFudCBmb3Igc29tZSB0aW1lIG5vdy4NCg0KDQoNClRoZSBkZWxlZ2F0aW9uIHByb2Nl
c3Mgd2lsbCBiZSBhY3RlZCB1cG9uIGJ5IG11bHRpcGxlIHBhcnRpZXMgaW4gdGhlIHByb3RvY29s
LCBlYWNoIHBlcmZvcm1pbmcgYSBzcGVjaWZpYyByb2xlLiBUaGUgcHJvdG9jb2wgd2lsbCBkZWNv
dXBsZSB0aGUgY2hhbm5lbHMgdXNlZA0KDQpieSB0aGUgcHJvdG9jb2wgcGFydGljaXBhbnRzIHRv
IGNvbW11bmljYXRlIGZyb20gdGhlIGRlbGVnYXRpb24gY2hhbm5lbCwgd2hpY2ggaGFwcGVucyBk
aXJlY3RseSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciAo
aW4gY29udHJhc3QNCg0Kd2l0aCBPQXV0aCAyLjAsIHdoaWNoIGlzIGluaXRpYXRlZCBieSB0aGUg
Y2xpZW50IHJlZGlyZWN0aW5nIHRoZSB1c2Vy4oCZcyBicm93c2VyKS4NCg0KDQoNCltEZW5pc10g
SGVyZSBhZ2FpbiwgdGhlIGRlbGVnYXRpb24gcHJvY2VzcywgaWYgYW55LCBzaG91bGQgYmUgaGFu
ZGxlZCBieSBSU3MgYW5kIG5vdCBieSBBU3MuDQoNClRoZSB0ZXJtICJkZWxlZ2F0aW9uIGNoYW5u
ZWwiIGlzIGJlaW5nIHVzZWQgYnV0IGl0IGlzIGxlZnQgdW5kZWZpbmVkLiBJdCBpcyBub3QgdW5k
ZXJzdGFuZGFibGUuDQoNCg0KDQpbUm9tYW5dIFRoaXMgc2VudGVuY2Ugd2FzIGp1c3QgYWRkZWQg
aW50byAtMDUgYWRkcmVzcyBTZWN1cml0eSBBRCBmZWVkYmFjay4gIEluIHRoaXMgY2FzZSwgaXQg
d2FzIG1hZGUgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBpbi1iYW5kIHNpZ25hbGluZyBhbmQgdGhl
IG5ldyBwdXJwb3NlLXRvLWJlLWJ1aWx0IGNoYW5uZWwuDQoNCg0KDQpUaGUgcHJvdG9jb2wgd2ls
bCBpbmNsdWRlIGEgbWVhbnMgb2Ygc3BlY2lmeWluZyBob3cgdGhlIHVzZXIgY2FuIHBvdGVudGlh
bGx5IGJlIGludm9sdmVkIGluIGFuIGludGVyYWN0aXZlIGZhc2hpb24gZHVyaW5nIHRoZSBkZWxl
Z2F0aW9uIHByb2Nlc3MuDQoNClRoZSBjbGllbnQgYW5kIEF1dGhvcml6YXRpb24gU2VydmVyIChB
Uykgd2lsbCB1c2UgdGhlc2UgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyB0byBpbnZvbHZlIHRoZSB1
c2VyLCBhcyBuZWNlc3NhcnksIHRvIG1ha2UgYXV0aG9yaXphdGlvbiBkZWNpc2lvbnMuDQoNCg0K
DQpbRGVuaXNdIEhlcmUgYWdhaW4sIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3MsIGlmIGFueSwgc2hv
dWxkIGJlIGhhbmRsZWQgYnkgUlNzIGFuZCBub3QgYnkgQVNzLiBUaGUgQVMgc2hvdWxkIGtub3cg
YXMgbGl0dGxlIGFzIHBvc3NpYmxlIChpbmNsdWRpbmcgbm90aGluZykNCg0KYWJvdXQgd2hhdCB0
aGUgY2xpZW50IGlzIGRvaW5nLg0KDQoNCg0KW1JvbWFuXSBVbmRlcnN0b29kIOKAkyBhcyBJIHVu
ZGVyc3RhbmQgaXQsIHlvdSBoYXZlIGNvbmNlcm4gd2l0aCB0aGUgc2NvcGUgb2YgdGhlIEFTIGJl
aGF2aW9yLiAgSeKAmWQgYmUgaW50ZXJlc3RpbmcgaW4gaGVhcmluZyBhZGRpdGlvbmFsIHN1cHBv
cnQgZm9yIHRoaXMgcmVzY29waW5nLg0KDQoNCg0KVGhpcyBkZWNvdXBsaW5nIGF2b2lkcyBtYW55
IG9mIHRoZSBzZWN1cml0eSBjb25jZXJucyBhbmQgdGVjaG5pY2FsIGNoYWxsZW5nZXMgb2YgT0F1
dGggMi4wIGFuZCBwcm92aWRlcyBhIG5vbi1pbnZhc2l2ZSBwYXRoIGZvciBzdXBwb3J0aW5nIGZ1
dHVyZSB0eXBlcw0KDQpvZiBjbGllbnRzIGFuZCBpbnRlcmFjdGlvbiBjaGFubmVscy4NCg0KDQoN
CltEZW5pc10gVGhpcyBpcyBub3QgdW5kZXJzdGFuZGFibGUgdG8gbWUuIElzIHN1Y2ggYSBzZW50
ZW5jZSByZWFsbHkgbmVlZGVkIGluIGEgY2hhcnRlciA/DQoNCg0KDQpbUm9tYW5dIENhbiBzb21l
b25lIG9uIHRoZSBUeEF1dGggbWFpbGluZyBsaXN0IHJlbWluZCB1cyBvbiB3aHkgdGhpcyBzZW50
ZW5jZSBpcyBoZXJlPyAgV2l0aCBhIGZyZXNoIHJlYWQsIEkgYWxzbyBjYW7igJl0IHJlbWVtYmVy
IHdoeSB3ZSBuZWVkIGl0Lg0KDQoNCg0KVGhlIGdyb3VwIHdpbGwgZGVmaW5lIGludGVyb3BlcmFi
aWxpdHkgZm9yIHRoaXMgcHJvdG9jb2wgYmV0d2VlbiBkaWZmZXJlbnQgcGFydGllcywgaW5jbHVk
aW5nDQoNCi0gICAgICAgICAgY2xpZW50IGFuZCBhdXRob3JpemF0aW9uIHNlcnZlcjsNCg0KLSAg
ICAgICAgICBjbGllbnQgYW5kIHJlc291cmNlIHNlcnZlcjsgYW5kDQoNCiAgICAgLSAgICAgIGF1
dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIuDQoNCg0KDQpbRGVuaXNdIElu
IG9yZGVyIHRvIHN1cHBvcnQgdGhlIHVzZXIncyBwcml2YWN5LCB0aGVyZSBzaG91bGQgYmUgbm8g
aW50ZXJhY3Rpb24gYXQgYWxsIGJldHdlZW4gYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIGEg
cmVzb3VyY2Ugc2VydmVyDQoNCmF0IHRoZSB0aW1lIG9mIGEgY2xpZW50IHJlcXVlc3QuDQoNCg0K
DQpUaGUgZ3JvdXAgd2lsbCBzZWVrIHRvIG1pbmltaXplIGFzc3VtcHRpb25zIGFib3V0IHRoZSBm
b3JtIG9mIGNsaWVudCBhcHBsaWNhdGlvbnMsIGFsbG93aW5nIGZvcjoNCg0KLSAgICAgICAgICBG
aW5lLWdyYWluZWQgc3BlY2lmaWNhdGlvbiBvZiBhY2Nlc3MNCg0KLSAgICAgICAgICBBcHByb3Zh
bCBvZiBBUyBhdHRlc3RhdGlvbiB0byBpZGVudGlmaWVycyBhbmQgb3RoZXIgaWRlbnRpdHkgY2xh
aW1zDQoNCi0gICAgICAgICAgQXBwcm92YWwgb2YgYWNjZXNzIHRvIG11bHRpcGxlIHJlc291cmNl
cyBhbmQgQVBJcyBpbiBhIHNpbmdsZSBpbnRlcmFjdGlvbg0KDQotICAgICAgICAgIE11bHRpcGxl
IGFjY2VzcyB0b2tlbnMgaW4gYSBzaW5nbGUgcmVxdWVzdCBhbmQgcmVzcG9uc2UNCg0KLSAgICAg
ICAgICBBUy1kaXJlY3RlZCBkaXNwYXRjaCBvZiBhY2Nlc3MgdG9rZW5zIHRvIHRoZSBhcHByb3By
aWF0ZSBSUw0KDQpbRGVuaXNdIEFzLWRpcmVjdGVkIGRpc3BhdGNoIGRvZXMgbm90IGFsbG93IHRv
IHN1cHBvcnQgdGhlIHVzZXIncyBwcml2YWN5LiBIb3dldmVyLCBSUy1kaXJlY3RlZCBkaXNwYXRj
aCBhbGxvd3MgdG8gc3VwcG9ydCB0aGUgdXNlcidzIHByaXZhY3kuDQoNCkl0IHNob3VsZCBiZSBl
eHBsaWNpdGx5IG1lbnRpb25lZC4NCg0KW1JvbWFuXSBBcyBhYm92ZSAocGVyIHRoZSBBUyB2cy4g
UlMgYmVoYXZpb3IpDQoNCi0gICAgICAgICAgU2VwYXJhdGlvbiBiZXR3ZWVuIHRoZSBwYXJ0eSBh
dXRob3JpemluZyBhY2Nlc3MgYW5kIHRoZSBwYXJ0eSBvcGVyYXRpbmcgdGhlIGNsaWVudCByZXF1
ZXN0aW5nIGFjY2Vzcw0KDQoNCg0KW0RlbmlzXSBJdCBpcyBxdWVzdGlvbmFibGUgd2hldGhlciBz
dWNoIGEgc2VwYXJhdGlvbiB3b3VsZCBiZSByZWFsbHkgYmVuZWZpY2lhbC4gSW4gZG91YnQsIHRo
aXMgaXRlbSBzaG91bGQgYmUgcmVtb3ZlZC4NCg0KW1JvbWFuXSBDb3VsZCB5b3Ugc2F5IG1vcmUg
b24gd2h5IHRoaXMgZmxleGliaWxpdHkgd291bGRu4oCZdCBiZSB3b3J0aCBpdD8NCg0KVGhlIGdy
b3VwIHdpbGwgZGVmaW5lIGV4dGVuc2lvbiBwb2ludHMgZm9yIHRoaXMgcHJvdG9jb2wgdG8gYWxs
b3cgZm9yIGZsZXhpYmlsaXR5IGluIGFyZWFzIGluY2x1ZGluZzoNCg0KDQoNCkNyeXB0b2dyYXBo
aWMgYWdpbGl0eSBmb3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBhbmQgcHJvb2Ygb2YgcG9z
c2Vzc2lvbg0KDQotICAgICAgICAgIFVzZXIgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRp
bmcgd2ViIGFuZCBub24td2ViIG1ldGhvZHMNCg0KLSAgICAgICAgICBNZWNoYW5pc21zIGZvciBj
b252ZXlpbmcgdXNlciwgc29mdHdhcmUsIG9yZ2FuaXphdGlvbiwgYW5kIG90aGVyIGluZm9ybWF0
aW9uIHVzZWQgaW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbnMNCg0KLSAgICAgICAgICBNZWNoYW5p
c21zIGZvciBwcmVzZW50aW5nIHRva2VucyB0byByZXNvdXJjZSBzZXJ2ZXJzIGFuZCBiaW5kaW5n
IHJlc291cmNlIHJlcXVlc3RzIHRvIHRva2VucyBhbmQgYXNzb2NpYXRlZCBjcnlwdG9ncmFwaGlj
IGtleXMNCg0KT3B0aW1pemVkIGluY2x1c2lvbiBvZiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIChp
bmNsdWRpbmcgaWRlbnRpZmllcnMgYW5kIGlkZW50aXR5IGFzc2VydGlvbnMpIHRocm91Z2ggdGhl
IGRlbGVnYXRpb24gcHJvY2Vzcw0KDQoNCg0KQWRkaXRpb25hbGx5LCB0aGUgZ3JvdXAgd2lsbCBw
cm92aWRlIG1lY2hhbmlzbXMgZm9yIG1hbmFnZW1lbnQgb2YgdGhlIHByb3RvY29sIGxpZmVjeWNs
ZSBpbmNsdWRpbmc6DQoNCi0gICAgICAgICAgRGlzY292ZXJ5IG9mIHRoZSBhdXRob3JpemF0aW9u
IHNlcnZlcg0KDQotICAgICAgICAgIFJldm9jYXRpb24gb2YgYWN0aXZlIHRva2Vucw0KDQpEYXRh
IG1vZGVsIGZvciBncmFudGVkIGFjY2VzcyBhbmQgbWVjaGFuaXNtcyBmb3IgdGhlIEFTIGFuZCBS
UyB0byBjb21tdW5pY2F0ZSB0aGUgZ3JhbnRlZCBhY2Nlc3MgbW9kZWwNCg0KDQoNCltEZW5pc10g
V2hpbGUgaXQgaXMgdGhlIGR1dHkgZm9yIHRoZSBSUyB0byBjb21tdW5pY2F0ZSB0aGUgZ3JhbnRl
ZCBhY2Nlc3MgbW9kZWwgdG8gdGhlIGNsaWVudCBhdCB0aGUgYXBwcm9wcmlhdGUgaW5zdGFudCBv
ZiB0aW1lLA0KDQp0aGUgQVMgc2hvdWxkIGJlIGtlcHQgZnVsbHkgaWdub3JhbnQgb2YgaXQuDQoN
Cg0KDQpBbHRob3VnaCB0aGUgYXJ0aWZhY3RzIGZvciB0aGlzIHdvcmsgYXJlIG5vdCBpbnRlbmRl
ZCBvciBleHBlY3RlZCB0byBiZSBiYWNrd2FyZHMtY29tcGF0aWJsZSB3aXRoIE9BdXRoIDIuMCBv
ciBPcGVuSUQgQ29ubmVjdCwNCg0KdGhlIGdyb3VwIHdpbGwgYXR0ZW1wdCB0byBzaW1wbGlmeSBt
aWdyYXRpbmcgZnJvbSBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0IHRvIHRoZSBuZXcgcHJv
dG9jb2wgd2hlcmUgcG9zc2libGUuDQoNCg0KDQpUaGlzIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQg
dG8gZGV2ZWxvcCBleHRlbnNpb25zIHRvIE9BdXRoIDIuMCwgYW5kIGFzIHN1Y2ggd2lsbCBmb2N1
cyBvbiBuZXcgdGVjaG5vbG9naWNhbCBzb2x1dGlvbnMgbm90IG5lY2Vzc2FyaWx5DQoNCmNvbXBh
dGlibGUgd2l0aCBPQXV0aCAyLjAuIEZ1bmN0aW9uYWxpdHkgdGhhdCBidWlsZHMgZGlyZWN0bHkg
b24gT0F1dGggMi4wIHdpbGwgYmUgZGlyZWN0ZWQgdG8gdGhlIE9BdXRoIFdvcmtpbmcgR3JvdXAs
IGluY2x1ZGluZw0KDQpmdW5jdGlvbmFsaXR5IGJhY2stcG9ydGVkIGZyb20gdGhlIHByb3RvY29s
IGRldmVsb3BlZCBoZXJlIHRvIE9BdXRoIDIuMC4NCg0KDQoNClRoZSBncm91cCBpcyBjaGFydGVy
ZWQgdG8gZGV2ZWxvcCBtZWNoYW5pc21zIGZvciBhcHBseWluZyBjcnlwdG9ncmFwaGljIG1ldGhv
ZHMsIHN1Y2ggYXMgSk9TRSBhbmQgQ09TRSwgdG8gdGhlIGRlbGVnYXRpb24gcHJvY2Vzcy4NCg0K
VGhpcyBncm91cCBpcyBub3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgbmV3IGNyeXB0b2dyYXBoaWMg
bWV0aG9kcy4NCg0KDQoNClRoZSBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBtZWNoYW5p
c21zIGZvciBjb252ZXlpbmcgaWRlbnRpdHkgaW5mb3JtYXRpb24gd2l0aGluIHRoZSBwcm90b2Nv
bCBpbmNsdWRpbmcgZXhpc3RpbmcgaWRlbnRpZmllcnMNCg0KKHN1Y2ggYXMgZW1haWwgYWRkcmVz
c2VzLCBwaG9uZSBudW1iZXJzLCB1c2VybmFtZXMsIGFuZCBzdWJqZWN0IGlkZW50aWZpZXJzKSBh
bmQgYXNzZXJ0aW9ucyAoc3VjaCBhcyBPcGVuSUQgQ29ubmVjdCBJRCBUb2tlbnMsDQoNClNBTUwg
QXNzZXJ0aW9ucywgYW5kIFZlcmlmaWFibGUgQ3JlZGVudGlhbHMpLiBUaGUgZ3JvdXAgaXMgbm90
IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG5ldyBmb3JtYXRzIGZvciBpZGVudGlmaWVycyBvciBhc3Nl
cnRpb25zLCBub3IgaXMgdGhlIGdyb3VwDQoNCmNoYXJ0ZXJlZCB0byBkZXZlbG9wIHNjaGVtYXMg
Zm9yIHVzZXIgaW5mb3JtYXRpb24sIHByb2ZpbGVzLCBvciBvdGhlciBpZGVudGl0eSBhdHRyaWJ1
dGVzLCB1bmxlc3MgYSB2aWFibGUgZXhpc3RpbmcgZm9ybWF0IGlzIG5vdCBhdmFpbGFibGUuDQoN
Cg0KDQpUaGUgaW5pdGlhbCB3b3JrIHdpbGwgZm9jdXMgb24gdXNpbmcgSFRUUFMgZm9yIGNvbW11
bmljYXRpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIs
IHRha2luZyBhZHZhbnRhZ2UNCg0Kb2Ygb3B0aW1pemF0aW9uIGZlYXR1cmVzIG9mIEhUVFAvMiBh
bmQgSFRUUC8zIHdoZXJlIHBvc3NpYmxlLCBhbmQgd2lsbCBzdHJpdmUgdG8gZW5hYmxlIHNpbXBs
ZSBtYXBwaW5nIHRvIG90aGVyIHByb3RvY29scyBzdWNoIGFzIENPQVANCg0Kd2hlbiBkb2luZyBz
byBkb2VzIG5vdCBjb25mbGljdCB3aXRoIHRoZSBwcmltYXJ5IGZvY3VzLg0KDQoNCg0KTWlsZXN0
b25lcyB0byBpbmNsdWRlOg0KDQotICAgICAgICAgIENvcmUgZGVsZWdhdGlvbiBwcm90b2NvbA0K
DQpbRGVuaXNdIEJlZm9yZSBkZWZpbmluZyBhICJDb3JlIGRlbGVnYXRpb24gcHJvdG9jb2wiLCBh
IHNpbXBsZSBjbGllbnQgc2VydmVyLXByb3RvY29sIGludm9sdmluZyB0aGUgcHJlc2VudGF0aW9u
IG9mIHNldmVyYWwgYWNjZXNzIHRva2VucyB0byBvbmUgUlMgc2hvdWxkIGJlIGRlZmluZWQuDQoN
ClByaXZhY3kgcHJpbmNpcGxlcyBzaG91bGQgYmUgYXBwbGllZCB3aGVuIGRlZmluaW5nIHRoZSBw
cm90b2NvbC4gVGhlbiBhZnRlciwgYSBkZWxlZ2F0aW9uIG1lY2hhbmlzbSBhbGxvd2luZyBvbmUg
UlMgdG8gZm9yd2FyZCBhbiBvcGVyYXRpb24gdG8gYW5vdGhlciBSUyBzaG91bGQgYmUgZGVmaW5l
ZC4NCg0KLSAgICAgICAgICBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBiaW5kaW5ncyB0byB0
aGUgY29yZSBwcm90b2NvbCBpbmNsdWRpbmcgVExTLCBkZXRhY2hlZCBIVFRQIHNpZ25hdHVyZSwg
YW5kIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlcw0KDQpbRGVuaXNdIEJpbmRpbmdzIHRvIFRMUyBh
cmUgbm93IGRlcHJlY2F0ZWQsIHdoeSBzaG91bGQgdGhleSBiZSBtYWludGFpbmVkID8NCg0KU2ln
bmF0dXJlcyBtYXkgYmUgbmVlZGVkIGJ1dCB0aGV5IGRvIG5vdCBuZWNlc3NhcmlseSBuZWVkIHRv
IGJlICJkZXRhY2hlZCBIVFRQIHNpZ25hdHVyZSwgYW5kIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJl
cyIuDQoNClRoaXMgaXRlbSBzaG91bGQgYmUgZWl0aGVyIHJlbW92ZWQgb3IgcmV3b3JkZWQuDQoN
CltSb21hbl0gTm90ZWQuICBJ4oCZZCB3YW50IHRvIGhlYXIgb3RoZXJzIG9uIHRoaXMgcmVzY29w
aW5nLg0KDQoNCg0KLSAgICAgICAgICBDb252ZXlhbmNlIG1lY2hhbmlzbXMgZm9yIGlkZW50aWZp
ZXJzIGFuZCBhc3NlcnRpb25zDQoNCi0gICAgICAgICAgR3VpZGVsaW5lcyBmb3IgdXNlIG9mIHBy
b3RvY29sIGV4dGVuc2lvbiBwb2ludHMgKGlmIG5lZWRlZCkNCiAgICAgLSAgICBHdWlkZWxpbmVz
IG9uIG1pZ3JhdGlvbiBwYXRocywgaW1wbGVtZW50YXRpb24sIGFuZCBvcGVyYXRpb25zDQpbRGVu
aXNdIFRoZSBhYm92ZSB0aHJlZSBsaW5lcyBhcmUgcmF0aGVyIG15c3RlcmlvdXMuDQpbUm9tYW5d
IFRoZSBndWlkZWxpbmVzIG9uIG1pZ3JhdGlvbiBwYXRocyBjYW1lIGZyb20gdGhlIGluaXRpYWwg
SUVTRyByZXZpZXcgaW4gb3JkZXIgdG8gaGF2ZSBhIG5hbWVkIGFjdGl2aXR5IHRvIGFjdGlvbiB0
aGUgZGVzaWduIGdvYWwgb2Yg4oCc4oCmIHRoZSBncm91cCB3aWxsIGF0dGVtcHQgdG8gc2ltcGxp
ZnkgbWlncmF0aW5nIGZyb20gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCB0byB0aGUgbmV3
IHByb3RvY29sIHdoZXJlIHBvc3NpYmxl4oCdIGEgYml0IGVhcmxpZXIgaW4gdGhlIHRleHQuDQpX
aGVyZSBwb3NzaWJsZSwgdGhlIGdyb3VwIHdpbGwgc2VlayB0byBtYWtlIHVzZSBvZiB0b29scyB0
byBndWlkZSBhbmQgaW5mb3JtIHRoZSBzdGFuZGFyZGl6YXRpb24gcHJvY2VzcyBpbmNsdWRpbmcg
Zm9ybWFsIGFuYWx5c2lzLA0KYXJjaGl0ZWN0dXJlIGRvY3VtZW50cywgYW5kIHVzZSBjYXNlIGRv
Y3VtZW50cy4gVGhlc2UgYXJ0aWZhY3RzIHdpbGwgbm90IGJlIGNvbnNpZGVyZWQgYXMgd29ya2lu
ZyBncm91cCBtaWxlc3RvbmVzIG9yIGRlbGl2ZXJhYmxlcy4NClRoZSB3b3JraW5nIGdyb3VwIHdp
bGwgY29vcGVyYXRlIGFuZCBjb29yZGluYXRlIHdpdGggb3RoZXIgSUVURiBXR3Mgc3VjaCBhcyBP
QVVUSCwgYW5kIHdvcmsgd2l0aCBleHRlcm5hbCBvcmdhbml6YXRpb25zLA0Kc3VjaCBhcyB0aGUg
T3BlbklEIEZvdW5kYXRpb24sIGFzIGFwcHJvcHJpYXRlLg0KW0RlbmlzXSBUaGUgY2hhcnRlciBz
aG91bGQgYmUgc2hvcnRlci4NCg0KW1JvbWFuXSBEZWZpbml0ZWx5LiAgTmV2ZXJ0aGVsZXNzLCB3
ZSBoYXZlIHRoZSBjdXJyZW50IHRleHQgdGhyb3VnaCByb3VnaCBjb25zZW5zdXMgcHJvY2VzcyBh
Y2hpZXZlZCBmcm9tIHR3byBCb0ZzIGFuZCBtdWx0aXBsZSBtYWlsaW5nIGxpc3QgY29uc2Vuc3Vz
IGNhbGxzLg0KDQpSZWdhcmRzLA0KUm9tYW4NCg0KL0RlbmlzDQoNCg0KQSBuZXcgSUVURiBXRyBo
YXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgU2VjdXJpdHkgQXJlYS4gVGhlIElFU0cgaGFzIG5vdCBt
YWRlDQoNCmFueSBkZXRlcm1pbmF0aW9uIHlldC4gVGhlIGZvbGxvd2luZyBkcmFmdCBjaGFydGVy
IHdhcyBzdWJtaXR0ZWQsIGFuZCBpcw0KDQpwcm92aWRlZCBmb3IgaW5mb3JtYXRpb25hbCBwdXJw
b3NlcyBvbmx5LiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZQ0KDQpJRVNHIG1haWxp
bmcgbGlzdCAoaWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4pIGJ5IDIwMjAtMDct
MDYuDQoNCg0KDQpHcmFudCBOZWdvdGlhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBQcm90b2NvbCAo
Z25hcCkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQ3VycmVudCBzdGF0dXM6IFByb3Bvc2VkIFdHDQoN
Cg0KDQpDaGFpcnM6DQoNCiAgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPjxt
YWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPg0KDQogIExlaWYgSm9oYW5zc29uIDxsZWlmakBz
dW5ldC5zZT48bWFpbHRvOmxlaWZqQHN1bmV0LnNlPg0KDQoNCg0KQXNzaWduZWQgQXJlYSBEaXJl
Y3RvcjoNCg0KICBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+PG1haWx0bzpyZGRAY2VydC5v
cmc+DQoNCg0KDQpTZWN1cml0eSBBcmVhIERpcmVjdG9yczoNCg0KICBCZW5qYW1pbiBLYWR1ayA8
a2FkdWtAbWl0LmVkdT48bWFpbHRvOmthZHVrQG1pdC5lZHU+DQoNCiAgUm9tYW4gRGFueWxpdyA8
cmRkQGNlcnQub3JnPjxtYWlsdG86cmRkQGNlcnQub3JnPg0KDQoNCg0KTWFpbGluZyBsaXN0Og0K
DQogIEFkZHJlc3M6IHR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPg0KDQog
IFRvIHN1YnNjcmliZTog4oCLaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90
eGF1dGgNCg0KICBBcmNoaXZlOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJv
d3NlL3R4YXV0aC8NCg0KDQoNCkdyb3VwIHBhZ2U6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZ3JvdXAvZ25hcC8NCg0KDQoNCkNoYXJ0ZXI6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2NoYXJ0ZXItaWV0Zi1nbmFwLw0KDQoNCg0KVGhpcyBncm91cCBpcyBjaGFydGVyZWQg
dG8gZGV2ZWxvcCBhIGZpbmUtZ3JhaW5lZCBkZWxlZ2F0aW9uIHByb3RvY29sIGZvcg0KDQphdXRo
b3JpemF0aW9uIGFuZCBBUEkgYWNjZXNzLCBhcyB3ZWxsIGFzIHJlcXVlc3RpbmcgYW5kIHByb3Zp
ZGluZyB1c2VyDQoNCmlkZW50aWZpZXJzIGFuZCBjbGFpbXMuIFRoaXMgcHJvdG9jb2wgd2lsbCBh
bGxvdyBhbiBhdXRob3JpemluZyBwYXJ0eSB0bw0KDQpkZWxlZ2F0ZSBhY2Nlc3MgdG8gY2xpZW50
IHNvZnR3YXJlIHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIEl0IHdpbGwNCg0KZXhw
YW5kIHVwb24gdGhlIHVzZXMgY2FzZXMgY3VycmVudGx5IHN1cHBvcnRlZCBieSBPQXV0aCAyLjAg
YW5kIE9wZW5JRCBDb25uZWN0DQoNCihpdHNlbGYgYW4gZXh0ZW5zaW9uIG9mIE9BdXRoIDIuMCkg
dG8gc3VwcG9ydCBhdXRob3JpemF0aW9ucyBzY29wZWQgYXMNCg0KbmFycm93bHkgYXMgYSBzaW5n
bGUgdHJhbnNhY3Rpb24sIHByb3ZpZGUgYSBjbGVhciBmcmFtZXdvcmsgZm9yIGludGVyYWN0aW9u
DQoNCmFtb25nIGFsbCBwYXJ0aWVzIGludm9sdmVkIGluIHRoZSBwcm90b2NvbCBmbG93LCBhbmQg
cmVtb3ZlIHVubmVjZXNzYXJ5DQoNCmRlcGVuZGVuY2Ugb24gYSBicm93c2VyIG9yIHVzZXItYWdl
bnQgZm9yIGNvb3JkaW5hdGluZyBpbnRlcmFjdGlvbnMuDQoNCg0KDQpUaGUgZGVsZWdhdGlvbiBw
cm9jZXNzIHdpbGwgYmUgYWN0ZWQgdXBvbiBieSBtdWx0aXBsZSBwYXJ0aWVzIGluIHRoZSBwcm90
b2NvbCwNCg0KZWFjaCBwZXJmb3JtaW5nIGEgc3BlY2lmaWMgcm9sZS4gVGhlIHByb3RvY29sIHdp
bGwgZGVjb3VwbGUgdGhlIGludGVyYWN0aW9uDQoNCmNoYW5uZWxzLCBzdWNoIGFzIHRoZSBlbmQg
dXNlcuKAmXMgYnJvd3NlciwgZnJvbSB0aGUgZGVsZWdhdGlvbiBjaGFubmVsLCB3aGljaA0KDQpo
YXBwZW5zIGRpcmVjdGx5IGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24g
c2VydmVyIChpbiBjb250cmFzdA0KDQp3aXRoIE9BdXRoIDIuMCwgd2hpY2ggaXMgaW5pdGlhdGVk
IGJ5IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhlIHVzZXLigJlzDQoNCmJyb3dzZXIpLiBUaGUg
cHJvdG9jb2wgd2lsbCBpbmNsdWRlIGEgbWVhbnMgb2Ygc3BlY2lmeWluZyBob3cgdGhlIHVzZXIg
Y2FuDQoNCnBvdGVudGlhbGx5IGJlIGludm9sdmVkIGluIGFuIGludGVyYWN0aXZlIGZhc2hpb24g
ZHVyaW5nIHRoZSBkZWxlZ2F0aW9uDQoNCnByb2Nlc3MuIFRoZSBjbGllbnQgYW5kIEF1dGhvcml6
YXRpb24gU2VydmVyIChBUykgd2lsbCB1c2UgdGhlc2UgaW50ZXJhY3Rpb24NCg0KbWVjaGFuaXNt
cyB0byBpbnZvbHZlIHRoZSB1c2VyLCBhcyBuZWNlc3NhcnksIHRvIG1ha2UgYXV0aG9yaXphdGlv
biBkZWNpc2lvbnMuDQoNClRoaXMgZGVjb3VwbGluZyBhdm9pZHMgbWFueSBvZiB0aGUgc2VjdXJp
dHkgY29uY2VybnMgYW5kIHRlY2huaWNhbCBjaGFsbGVuZ2VzDQoNCm9mIE9BdXRoIDIuMCBhbmQg
cHJvdmlkZXMgYSBub24taW52YXNpdmUgcGF0aCBmb3Igc3VwcG9ydGluZyBmdXR1cmUgdHlwZXMg
b2YNCg0KY2xpZW50cyBhbmQgaW50ZXJhY3Rpb24gY2hhbm5lbHMuDQoNCg0KDQpUaGUgZ3JvdXAg
d2lsbCBkZWZpbmUgaW50ZXJvcGVyYWJpbGl0eSBmb3IgdGhpcyBwcm90b2NvbCBiZXR3ZWVuIGRp
ZmZlcmVudA0KDQpwYXJ0aWVzLCBpbmNsdWRpbmcNCg0KIC0gY2xpZW50IGFuZCBhdXRob3JpemF0
aW9uIHNlcnZlcjsNCg0KIC0gY2xpZW50IGFuZCByZXNvdXJjZSBzZXJ2ZXI7IGFuZA0KDQogLSBh
dXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyLg0KDQoNCg0KVGhlIGdyb3Vw
IHdpbGwgc2VlayB0byBtaW5pbWl6ZSBhc3N1bXB0aW9ucyBhYm91dCB0aGUgZm9ybSBvZiBjbGll
bnQNCg0KYXBwbGljYXRpb25zLCBhbGxvd2luZyBmb3I6DQoNCi0gRmluZS1ncmFpbmVkIHNwZWNp
ZmljYXRpb24gb2YgYWNjZXNzDQoNCi0gQXBwcm92YWwgb2YgQVMgYXR0ZXN0YXRpb24gdG8gaWRl
bnRpZmllcnMgYW5kIG90aGVyIGlkZW50aXR5IGNsYWltcw0KDQotIEFwcHJvdmFsIG9mIGFjY2Vz
cyB0byBtdWx0aXBsZSByZXNvdXJjZXMgYW5kIEFQSXMgaW4gYSBzaW5nbGUgaW50ZXJhY3Rpb24N
Cg0KLSBTdXBwb3J0IGZvciBtdWx0aXBsZSBhY2Nlc3MgdG9rZW5zIGluIGEgc2luZ2xlIHJlcXVl
c3QgYW5kIHJlc3BvbnNlDQoNCi0gU3VwcG9ydCBmb3IgZGlyZWN0ZWQsIGF1ZGllbmNlLXJlc3Ry
aWN0ZWQgYWNjZXNzIHRva2Vucw0KDQotIFNlcGFyYXRpb24gYmV0d2VlbiB0aGUgcGFydHkgYXV0
aG9yaXppbmcgYWNjZXNzIGFuZCB0aGUgcGFydHkgb3BlcmF0aW5nIHRoZQ0KDQpjbGllbnQgcmVx
dWVzdGluZyBhY2Nlc3MNCg0KDQoNClRoZSBncm91cCB3aWxsIGRlZmluZSBleHRlbnNpb24gcG9p
bnRzIGZvciB0aGlzIHByb3RvY29sIHRvIGFsbG93IGZvcg0KDQpmbGV4aWJpbGl0eSBpbiBhcmVh
cyBpbmNsdWRpbmc6DQoNCg0KDQotIENyeXB0b2dyYXBoaWMgYWdpbGl0eSBmb3Iga2V5cywgbWVz
c2FnZSBzaWduYXR1cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vzc2lvbg0KDQotIFVzZXIgaW50ZXJh
Y3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBub24td2ViIG1ldGhvZHMNCg0KLSBN
ZWNoYW5pc21zIGZvciBjb252ZXlpbmcgdXNlciwgc29mdHdhcmUsIG9yZ2FuaXphdGlvbiwgYW5k
IG90aGVyDQoNCmluZm9ybWF0aW9uIHVzZWQgaW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbnMNCg0K
LSBNZWNoYW5pc21zIGZvciBwcmVzZW50aW5nIHRva2VucyB0byByZXNvdXJjZSBzZXJ2ZXJzIGFu
ZCBiaW5kaW5nIHJlc291cmNlDQoNCnJlcXVlc3RzIHRvIHRva2VucyBhbmQgYXNzb2NpYXRlZCBj
cnlwdG9ncmFwaGljIGtleXMNCg0KLSBPcHRpbWl6ZWQgaW5jbHVzaW9uIG9mIGFkZGl0aW9uYWwg
aW5mb3JtYXRpb24gKGluY2x1ZGluZyBpZGVudGlmaWVycyBhbmQNCg0KaWRlbnRpdHkgYXNzZXJ0
aW9ucykgdGhyb3VnaCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzDQoNCg0KDQpBZGRpdGlvbmFsbHks
IHRoZSBncm91cCB3aWxsIHByb3ZpZGUgbWVjaGFuaXNtcyBmb3IgbWFuYWdlbWVudCBvZiB0aGUg
cHJvdG9jb2wNCg0KbGlmZWN5Y2xlIGluY2x1ZGluZzoNCg0KDQoNCi0gRGlzY292ZXJ5IG9mIHRo
ZSBhdXRob3JpemF0aW9uIHNlcnZlcg0KDQotIFJldm9jYXRpb24gb2YgYWN0aXZlIHRva2Vucw0K
DQotIE1lY2hhbmlzbXMgZm9yIHRoZSBBUyBhbmQgUlMgdG8gY29tbXVuaWNhdGUgdGhlIGFjY2Vz
cyBncmFudGVkIGJ5IGFuIGFjY2Vzcw0KDQp0b2tlbg0KDQoNCg0KQWx0aG91Z2ggdGhlIGFydGlm
YWN0cyBmb3IgdGhpcyB3b3JrIGFyZSBub3QgaW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUNCg0K
YmFja3dhcmRzLWNvbXBhdGlibGUgd2l0aCBPQXV0aCAyLjAgb3IgT3BlbklEIENvbm5lY3QsIHRo
ZSBncm91cCB3aWxsIGF0dGVtcHQNCg0KdG8gc2ltcGxpZnkgbWlncmF0aW5nIGZyb20gT0F1dGgg
Mi4wIGFuZCBPcGVuSUQgQ29ubmVjdCB0byB0aGUgbmV3IHByb3RvY29sDQoNCndoZXJlIHBvc3Np
YmxlLg0KDQoNCg0KVGhpcyBncm91cCBpcyBub3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgZXh0ZW5z
aW9ucyB0byBPQXV0aCAyLjAsIGFuZCBhcyBzdWNoDQoNCndpbGwgZm9jdXMgb24gbmV3IHRlY2hu
b2xvZ2ljYWwgc29sdXRpb25zIG5vdCBuZWNlc3NhcmlseSBjb21wYXRpYmxlIHdpdGgNCg0KT0F1
dGggMi4wLiBGdW5jdGlvbmFsaXR5IHRoYXQgYnVpbGRzIGRpcmVjdGx5IG9uIE9BdXRoIDIuMCB3
aWxsIGJlIGRpcmVjdGVkDQoNCnRvIHRoZSBPQXV0aCBXb3JraW5nIEdyb3VwLCBpbmNsdWRpbmcg
ZnVuY3Rpb25hbGl0eSBiYWNrLXBvcnRlZCBmcm9tIHRoZQ0KDQpwcm90b2NvbCBkZXZlbG9wZWQg
aGVyZSB0byBPQXV0aCAyLjAuDQoNCg0KDQpUaGUgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVs
b3AgbWVjaGFuaXNtcyBmb3IgYXBwbHlpbmcgY3J5cHRvZ3JhcGhpYw0KDQptZXRob2RzLCBzdWNo
IGFzIEpPU0UgYW5kIENPU0UsIHRvIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3MuIFRoaXMgZ3JvdXAg
aXMgbm90DQoNCmNoYXJ0ZXJlZCB0byBkZXZlbG9wIG5ldyBjcnlwdG9ncmFwaGljIG1ldGhvZHMu
DQoNCg0KDQpUaGUgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3Ig
Y29udmV5aW5nIGlkZW50aXR5DQoNCmluZm9ybWF0aW9uIHdpdGhpbiB0aGUgcHJvdG9jb2wgaW5j
bHVkaW5nIGV4aXN0aW5nIGlkZW50aWZpZXJzIChzdWNoIGFzIGVtYWlsDQoNCmFkZHJlc3Nlcywg
cGhvbmUgbnVtYmVycywgdXNlcm5hbWVzLCBhbmQgc3ViamVjdCBpZGVudGlmaWVycykgYW5kIGFz
c2VydGlvbnMNCg0KKHN1Y2ggYXMgT3BlbklEIENvbm5lY3QgSUQgVG9rZW5zLCBTQU1MIEFzc2Vy
dGlvbnMsIGFuZCBWZXJpZmlhYmxlDQoNCkNyZWRlbnRpYWxzKS4gVGhlIGdyb3VwIGlzIG5vdCBj
aGFydGVyZWQgdG8gZGV2ZWxvcCBuZXcgZm9ybWF0cyBmb3INCg0KaWRlbnRpZmllcnMgb3IgYXNz
ZXJ0aW9ucywgbm9yIGlzIHRoZSBncm91cCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBzY2hlbWFzIGZv
cg0KDQp1c2VyIGluZm9ybWF0aW9uLCBwcm9maWxlcywgb3Igb3RoZXIgaWRlbnRpdHkgYXR0cmli
dXRlcywgdW5sZXNzIGEgdmlhYmxlDQoNCmV4aXN0aW5nIGZvcm1hdCBpcyBub3QgYXZhaWxhYmxl
Lg0KDQoNCg0KVGhlIGluaXRpYWwgd29yayB3aWxsIGZvY3VzIG9uIHVzaW5nIEhUVFBTIGZvciBj
b21tdW5pY2F0aW9uIGJldHdlZW4gdGhlDQoNCmNsaWVudCBhbmQgdGhlIGF1dGhvcml6YXRpb24g
c2VydmVyLCB0YWtpbmcgYWR2YW50YWdlIG9mIG9wdGltaXphdGlvbg0KDQpmZWF0dXJlcyBvZiBI
VFRQLzIgYW5kIEhUVFAvMyB3aGVyZSBwb3NzaWJsZSwgYW5kIHdpbGwgc3RyaXZlIHRvIGVuYWJs
ZQ0KDQpzaW1wbGUgbWFwcGluZyB0byBvdGhlciBwcm90b2NvbHMgc3VjaCBhcyBDT0FQIHdoZW4g
ZG9pbmcgc28gZG9lcyBub3QNCg0KY29uZmxpY3Qgd2l0aCB0aGUgcHJpbWFyeSBmb2N1cy4NCg0K
DQoNCk1pbGVzdG9uZXMgdG8gaW5jbHVkZToNCg0KLSBDb3JlIGRlbGVnYXRpb24gcHJvdG9jb2wN
Cg0KLSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBiaW5kaW5ncyB0byB0aGUgY29yZSBwcm90
b2NvbCBpbmNsdWRpbmcgVExTLA0KDQpkZXRhY2hlZCBIVFRQIHNpZ25hdHVyZSwgYW5kIGVtYmVk
ZGVkIEhUVFAgc2lnbmF0dXJlcw0KDQotIENvbnZleWFuY2UgbWVjaGFuaXNtcyBmb3IgaWRlbnRp
ZmllcnMgYW5kIGFzc2VydGlvbnMNCg0KLSBHdWlkZWxpbmVzIGZvciB1c2Ugb2YgcHJvdG9jb2wg
ZXh0ZW5zaW9uIHBvaW50cw0KDQotIChpZiBuZWVkZWQpIEd1aWRlbGluZXMgb24gbWlncmF0aW9u
IHBhdGhzLCBpbXBsZW1lbnRhdGlvbiwgYW5kIG9wZXJhdGlvbnMNCg0KDQoNCldoZXJlIHBvc3Np
YmxlLCB0aGUgZ3JvdXAgd2lsbCBzZWVrIHRvIG1ha2UgdXNlIG9mIHRvb2xzIHRvIGd1aWRlIGFu
ZCBpbmZvcm0NCg0KdGhlIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzIGluY2x1ZGluZyBmb3JtYWwg
YW5hbHlzaXMsIGFyY2hpdGVjdHVyZSBkb2N1bWVudHMsDQoNCmFuZCB1c2UgY2FzZSBkb2N1bWVu
dHMuIFRoZXNlIGFydGlmYWN0cyB3aWxsIG5vdCBiZSBjb25zaWRlcmVkIGFzIHdvcmtpbmcNCg0K
Z3JvdXAgbWlsZXN0b25lcyBvciBkZWxpdmVyYWJsZXMuDQoNCg0KDQpUaGUgd29ya2luZyBncm91
cCB3aWxsIGNvb3BlcmF0ZSBhbmQgY29vcmRpbmF0ZSB3aXRoIG90aGVyIElFVEYgV0dzIHN1Y2gg
YXMNCg0KT0FVVEgsIGFuZCB3b3JrIHdpdGggZXh0ZXJuYWwgb3JnYW5pemF0aW9ucywgc3VjaCBh
cyB0aGUgT3BlbklEIEZvdW5kYXRpb24sDQoNCmFzIGFwcHJvcHJpYXRlLg0KDQoNCg0KTWlsZXN0
b25lczoNCg0KDQoNCiAgSnVsIDIwMjEgLSBDb3JlIGRlbGVnYXRpb24gcHJvdG9jb2wgaW4gV0dM
Qw0KDQoNCg0KICBPY3QgMjAyMSAtIEtleSBwcmVzZW50YXRpb24gbWVjaGFuaXNtIGJpbmRpbmcg
dG8gdGhlIGNvcmUgcHJvdG9jb2wsIFRMUywgdG8NCg0KICBXR0xDDQoNCg0KDQogIE9jdCAyMDIx
IC0gS2V5IHByZXNlbnRhdGlvbiBtZWNoYW5pc20gYmluZGluZyB0byB0aGUgY29yZSBwcm90b2Nv
bCwNCg0KICBkZXRhY2hlZCBIVFRQIHNpZ25hdHVyZXMsIHRvIFdHTEMNCg0KDQoNCiAgT2N0IDIw
MjEgLSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBiaW5kaW5nIHRvIHRoZSBjb3JlIHByb3Rv
Y29sLA0KDQogIGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlLCB0byBXR0xDDQoNCg0KDQogIERlYyAy
MDIxIC0gR3VpZGVsaW5lcyBmb3IgdXNlIG9mIHByb3RvY29sIGV4dGVuc2lvbiBwb2ludHMgdG8g
V0dMQw0KDQoNCg0KICBGZWIgMjAyMiAtIEd1aWRlbGluZXMgb24gbWlncmF0aW9uIHBhdGhzLCBp
bXBsZW1lbnRhdGlvbiwgYW5kIG9wZXJhdGlvbnMgdG8NCg0KICAgV0dMQw0KDQoNCg0KDQoNCg0K
DQoNCg==

--_000_3424311c60f541b197cfda6e9f3b494ecertorg_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh
IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy
IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O
b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx
cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
Zjt9DQpoMg0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGlu
ZyAyIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt
c2l6ZToxOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJZm9udC13
ZWlnaHQ6Ym9sZDt9DQpoNA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGlu
azoiSGVhZGluZyA0IENoYXIiOw0KCW1hcmdpbi10b3A6Mi4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBp
bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDowaW47DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJZm9udC1zaXplOjExLjBwdDsN
Cglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMkY1NDk2
Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOml0YWxpYzt9DQphOmxpbmssIHNw
YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu
a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4
dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y
bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt
YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhlYWRpbmcyQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVh
ZGluZyAyIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJI
ZWFkaW5nIDIiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIExpZ2h0IixzYW5zLXNlcmlmOw0KCWNv
bG9yOiMyRjU0OTY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt
ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz
cGFuLkhlYWRpbmc0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyA0IENoYXIiOw0KCW1z
by1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDQiOw0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIExpZ2h0IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMyRjU0OTY7DQoJZm9u
dC1zdHlsZTppdGFsaWM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi
IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K
PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIERlbmlzITxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5UaGFua3MgZm9yIHRoZSBmZWVkYmFjayBhbmQgZm9yIHJlcGVhdGluZyB5b3VyIHJldmll
dyBvbiB0aGUgcmV2aXNlZCB0ZXh0LiZuYnNwOyBNb3JlIGlubGluZSDigKY8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w
OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gaWVzZyAmbHQ7aWVzZy1ib3VuY2VzQGlldGYub3Jn
Jmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KRGVuaXM8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5
LCBKdWx5IDYsIDIwMjAgMTA6NTUgQU08YnI+DQo8Yj5Ubzo8L2I+IGllc2dAaWV0Zi5vcmc8YnI+
DQo8Yj5DYzo8L2I+IHR4YXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1R4
YXV0aF0gV0cgUmV2aWV3OiBHcmFudCBOZWdvdGlhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBQcm90
b2NvbCAoZ25hcCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+
U2luY2UgaXQgaXMgdG9kYXkgdGhlIGxhc3QgZGF5IHRvIHNlbmQgYmFjayBjb21tZW50cywgeW91
IHdpbGwgZmluZCBoZXJlYWZ0ZXIgbXkgY29tbWVudHMgb24gdGhlIGxhc3QgY2hhcnRlciB2ZXJz
aW9uLTA1Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxoMj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEzLjVwdCI+Y2hhcnRlci1pZXRmLWduYXAtMDAtMDU8L3NwYW4+PG86
cD48L286cD48L2gyPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGdyb3VwIGlzIGNoYXJ0ZXJl
ZCB0byBkZXZlbG9wIGEgZmluZS1ncmFpbmVkIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIGF1dGhv
cml6YXRpb24sIEFQSSBhY2Nlc3MsIHVzZXIgaWRlbnRpZmllcnMsIGFuZCBpZGVudGl0eSBhc3Nl
cnRpb25zLiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjpibHVlIj5bRGVuaXNdIEZpbmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHByb3RvY29sIHdpbGwgYWxzbyBhbGxvdyB0
aGUgY2xpZW50IHRvIHByZXNlbnQgdW52ZXJpZmllZCBpZGVudGlmaWVycyBhbmQgdmVyaWZpYWJs
ZSBhc3NlcnRpb25zIHRvIHRoZSBBUyBhcyBwYXJ0IG9mIGl0cyByZXF1ZXN0LiA8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibHVlIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibHVlIj5bRGVu
aXNdIFRoaXMgc2VudGVuY2UgaXMgdG9vIHZhZ3VlIGJlY2F1c2UgJnF1b3Q7YXMgcGFydCBvZiBp
dHMgcmVxdWVzdCZxdW90OyBpcyBub3QgZXhwbGljaXQgZW5vdWdoLiBJZiBpdCBtZWFucyZuYnNw
OyAmcXVvdDthcyBwYXJ0IGFzIGFuIGFjY2VzcyB0b2tlbiByZXF1ZXN0JnF1b3Q7IDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsdWUiPnRoaXMgc2hv
dWxkIGJlIGV4cGxpY2l0bHkgc2FpZC4gSWYsIGl0IGlzIG5vdCB0aGUgY2FzZSwgdGhlbiBpdCBz
aG91bGQgYmUgY2xlYXJseSBleHBsYWluZWQuIFRoZSBBUyBzaG91bGQga25vdyBhcyBsaXR0bGUg
YXMgcG9zc2libGUgKGluY2x1ZGluZyBub3RoaW5nKTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsdWUiPmFib3V0IHdoYXQgdGhlIGNsaWVudCBpcyBk
b2luZy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPltSb21hbl0gVGhlIOKAnHJlcXVlc3TigJ0gaGVyZSBpcyB0aGUg4oCcYWNj
ZXNzIHRva2VuIHJlcXVlc3TigJ0uJm5ic3A7IFRoYXQgY2FuIGJlIG1hZGUgY2xlYXJlci48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBwcm90b2NvbCB3aWxs
IGFsbG93IGFuIGF1dGhvcml6aW5nIHBhcnR5IHRvIGRlbGVnYXRlIGFjY2VzcyB0byBjbGllbnQg
c29mdHdhcmUgdGhyb3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlci4gPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymx1ZSI+W0RlbmlzXSBU
aGUgd29yZCAmcXVvdDs8Yj5wcml2YWN5PC9iPiZxdW90OyBpcyBzdGlsbCBtaXNzaW5nIGluIHRo
ZSBjaGFydGVyLiAmcXVvdDtEZWxlZ2F0aW5nIGFjY2VzcyB0byBjbGllbnQgc29mdHdhcmUgdGhy
b3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciZxdW90OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibHVlIj5pcyBuZWdhdGluZyB0aGUgZmFjdCB0
aGF0IHRoZSB1c2VyJ3MgcHJpdmFjeSB3aWxsIGV2ZXIgYmUgY29uc2lkZXJlZC4gSU1ITywgSSBi
ZWxpZXZlIHRoYXQgYSBSUyBtYXkgZGVsZWdhdGUgc29tZSBvcGVyYXRpb24gdG8gYW5vdGhlciBS
UywgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymx1
ZSI+YnV0IEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IGFuIEFTIHNob3VsZCBiZSBjb25jZXJuZWQgYnkg
YW55IGZvcm0gb2YgZGVsZWdhdGlvbiwgb3RoZXJ3aXNlIGl0IHdvdWxkIGhhdmUgdGhlIGFiaWxp
dHkgdG8gYWN0IGFzICZxdW90O0JpZyBCcm90aGVyJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsdWUiPk9BdXRoIGhhcyBub3QgYmVlbiBj
b25zdHJ1Y3RlZCB0YWtpbmcgaW50byBjb25zaWRlcmF0aW9uIHRoZSB1c2VyJ3MgcHJpdmFjeS4g
VGhlIG1ham9yIGRpZmZlcmVuY2Ugd2l0aCBpdCBzaG91bGQgYmUgdGhhdCBHTkFQIGhhcyBiZWVu
IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsdWUi
PmNvbnN0cnVjdGVkIGFsb25nICZxdW90OzxiPnByaXZhY3kgYnkgZGVzaWduPC9iPiZxdW90OyBw
cmluY2lwbGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltS
b21hbl0mbmJzcDsgSSBkb27igJl0IGV4YWN0bHkgZm9sbG93IGhvdyBjb25zaWRlcmF0aW9ucyBm
b3IgcHJpdmFjeSBhcmUgYmVpbmcgbmVnYXRlZC4mbmJzcDsgQWJvdmUgYW5kIGJleW9uZCB1c2Ut
Y2FzZSBzcGVjaWZpYyBjb25zaWRlcmF0aW9ucyB0aGF0IHdvdWxkIGJlIGRlZmluZWQgbGF0ZXIs
IFJGQzY5NzMgaXMgdGhlIElFVEYgY29uc2Vuc3VzIGRlc2lnbiBndWlkYW5jZSB0aGF0IHdpbGwg
Z3VpZGUgdGhlIHByaXZhY3kgdGhyZWF0cyBhbmQgbWl0aWdhdGlvbnMgb2YgdGhlIHdvcmsuJm5i
c3A7IFdoYXQgZGVzaWduIGd1aWRhbmNlIHdvdWxkIHlvdSByZWNvbW1lbmQgdGhhdCB0aGUgV0cg
c2hvdWxkIGNvbnNpZGVyIHRoYXQgYXJlbuKAmXQgY2FwdHVyZWQgaW4gUkZDNjk3Mz88bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkl0IHdpbGwgPGI+ZXhwYW5kPC9iPiB1
cG9uIHRoZSB1c2VzIGNhc2VzIGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkgT0F1dGggMi4wIGFuZCBP
cGVuSUQgQ29ubmVjdCAoaXRzZWxmIGFuIGV4dGVuc2lvbiBvZiBPQXV0aCAyLjApIHRvIHN1cHBv
cnQgYXV0aG9yaXphdGlvbnMgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt
c2VyaWYiPnNjb3BlZCBhcyBuYXJyb3dseSBhcyBhIHNpbmdsZSB0cmFuc2FjdGlvbiwgcHJvdmlk
ZSBhIGNsZWFyIGZyYW1ld29yayBmb3IgaW50ZXJhY3Rpb24gYW1vbmcgYWxsIHBhcnRpZXMgaW52
b2x2ZWQgaW4gdGhlIHByb3RvY29sIGZsb3csIGFuZCByZW1vdmUgPG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPnVubmVjZXNzYXJ5IGRlcGVuZGVuY2Ugb24gYSBi
cm93c2VyIG9yIHVzZXItYWdlbnQgZm9yIGNvb3JkaW5hdGluZyBpbnRlcmFjdGlvbnMuPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsdWUiPltEZW5pc10gVGhl
cmUgaXMgbm8gbmVlZCB0byByZWZlciB0byBPQXV0aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0LiBT
b21lIGV4aXN0aW5nIHVzZXMgY2FzZXMgKGkuZS4gJnF1b3Q7PGI+bm9uLWV4cGFuZGVkJnF1b3Q7
PC9iPiB1c2UgY2FzZXMpIHNob3VsZCBiZSBzdXBwb3J0ZWQgPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymx1ZSI+ZGlmZmVyZW50bHkgZnJvbSBPQXV0
aCAyLjAgYW5kIE9wZW5JRCBDb25uZWN0LCBpbiBwYXJ0aWN1bGFyIHRvIHN1cHBvcnQgdGhlIHVz
ZXIncyBwcml2YWN5Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+W1JvbWFuXSBJ4oCZZCB3YW50IHRvIGhlYXIgb3RoZXJzIG9u
IHRoaXMgcmVzY29waW5nLiZuYnNwOyBCdWlsZGluZyB1cG9uIHRoZSB1c2UgY2FzZXMgb2YgT0F1
dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCBoYXMgYmVlbiBjb3JlLCBjb25zZW5zdXMtdmFsaWRh
dGVkIHRlbmFudCBmb3Igc29tZSB0aW1lIG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw
cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssc2Fucy1zZXJpZiI+VGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGJlIGFjdGVkIHVwb24g
YnkgbXVsdGlwbGUgcGFydGllcyBpbiB0aGUgcHJvdG9jb2wsIGVhY2ggcGVyZm9ybWluZyBhIHNw
ZWNpZmljIHJvbGUuIFRoZSBwcm90b2NvbCB3aWxsIGRlY291cGxlIHRoZSBjaGFubmVscyB1c2Vk
IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5ieSB0aGUgcHJv
dG9jb2wgcGFydGljaXBhbnRzIHRvIGNvbW11bmljYXRlIGZyb20gdGhlIGRlbGVnYXRpb24gY2hh
bm5lbCwgd2hpY2ggaGFwcGVucyBkaXJlY3RseSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBh
dXRob3JpemF0aW9uIHNlcnZlciAoaW4gY29udHJhc3QgPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPndpdGggT0F1dGggMi4wLCB3aGljaCBpcyBpbml0aWF0ZWQg
YnkgdGhlIGNsaWVudCByZWRpcmVjdGluZyB0aGUgdXNlcuKAmXMgYnJvd3NlcikuIDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibHVlIj5bRGVuaXNdIEhlcmUg
YWdhaW4sIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3MsIGlmIGFueSwgc2hvdWxkIGJlIGhhbmRsZWQg
YnkgUlNzIGFuZCBub3QgYnkgQVNzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjpibHVlIj5UaGUgdGVybSAmcXVvdDtkZWxlZ2F0aW9uIGNoYW5uZWwm
cXVvdDsgaXMgYmVpbmcgdXNlZCBidXQgaXQgaXMgbGVmdCB1bmRlZmluZWQuIEl0IGlzIG5vdCB1
bmRlcnN0YW5kYWJsZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1JvbWFuXSBUaGlzIHNlbnRlbmNlIHdhcyBqdXN0IGFk
ZGVkIGludG8gLTA1IGFkZHJlc3MgU2VjdXJpdHkgQUQgZmVlZGJhY2suJm5ic3A7IEluIHRoaXMg
Y2FzZSwgaXQgd2FzIG1hZGUgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBpbi1iYW5kIHNpZ25hbGlu
ZyBhbmQgdGhlIG5ldyBwdXJwb3NlLXRvLWJlLWJ1aWx0IGNoYW5uZWwuPG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGUgcHJvdG9jb2wgd2lsbCBpbmNsdWRlIGEgbWVh
bnMgb2Ygc3BlY2lmeWluZyBob3cgdGhlIHVzZXIgY2FuIHBvdGVudGlhbGx5IGJlIGludm9sdmVk
IGluIGFuIGludGVyYWN0aXZlIGZhc2hpb24gZHVyaW5nIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mu
IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGUgY2xpZW50
IGFuZCBBdXRob3JpemF0aW9uIFNlcnZlciAoQVMpIHdpbGwgdXNlIHRoZXNlIGludGVyYWN0aW9u
IG1lY2hhbmlzbXMgdG8gaW52b2x2ZSB0aGUgdXNlciwgYXMgbmVjZXNzYXJ5LCB0byBtYWtlIGF1
dGhvcml6YXRpb24gZGVjaXNpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z
ZXJpZiI+WzxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj5EZW5pc10gSGVyZSBhZ2FpbiwgdGhlIGRl
bGVnYXRpb24gcHJvY2VzcywgaWYgYW55LCBzaG91bGQgYmUgaGFuZGxlZCBieSBSU3MgYW5kIG5v
dCBieSBBU3MuIFRoZSBBUyBzaG91bGQga25vdyBhcyBsaXR0bGUgYXMgcG9zc2libGUgKGluY2x1
ZGluZyBub3RoaW5nKTxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjpibHVlIj5hYm91dCB3aGF0IHRoZSBjbGllbnQgaXMgZG9pbmcuPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl
cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij5bUm9tYW5dIFVuZGVyc3Rvb2Qg4oCTIGFzIEkgdW5kZXJzdGFuZCBpdCwgeW91IGhhdmUgY29u
Y2VybiB3aXRoIHRoZSBzY29wZSBvZiB0aGUgQVMgYmVoYXZpb3IuJm5ic3A7IEnigJlkIGJlIGlu
dGVyZXN0aW5nIGluIGhlYXJpbmcgYWRkaXRpb25hbCBzdXBwb3J0IGZvciB0aGlzIHJlc2NvcGlu
Zy4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMg
ZGVjb3VwbGluZyBhdm9pZHMgbWFueSBvZiB0aGUgc2VjdXJpdHkgY29uY2VybnMgYW5kIHRlY2hu
aWNhbCBjaGFsbGVuZ2VzIG9mIE9BdXRoIDIuMCBhbmQgcHJvdmlkZXMgYSBub24taW52YXNpdmUg
cGF0aCBmb3Igc3VwcG9ydGluZyBmdXR1cmUgdHlwZXMgPG86cD48L286cD48L3NwYW4+PC9wcmU+
DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPm9mIGNsaWVudHMgYW5kIGludGVyYWN0aW9uIGNoYW5uZWxz
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibHVlIj5bRGVu
aXNdIFRoaXMgaXMgbm90IHVuZGVyc3RhbmRhYmxlIHRvIG1lLiBJcyBzdWNoIGEgc2VudGVuY2Ug
cmVhbGx5IG5lZWRlZCBpbiBhIGNoYXJ0ZXIgPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv
bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bUm9tYW5dIENhbiBzb21lb25l
IG9uIHRoZSBUeEF1dGggbWFpbGluZyBsaXN0IHJlbWluZCB1cyBvbiB3aHkgdGhpcyBzZW50ZW5j
ZSBpcyBoZXJlPyZuYnNwOyBXaXRoIGEgZnJlc2ggcmVhZCwgSSBhbHNvIGNhbuKAmXQgcmVtZW1i
ZXIgd2h5IHdlIG5lZWQgaXQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm
Ij5UaGUgZ3JvdXAgd2lsbCBkZWZpbmUgaW50ZXJvcGVyYWJpbGl0eSBmb3IgdGhpcyBwcm90b2Nv
bCBiZXR3ZWVuIGRpZmZlcmVudCBwYXJ0aWVzLCBpbmNsdWRpbmc8L3NwYW4+PG86cD48L286cD48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OyxzYW5zLXNlcmlmIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5j
bGllbnQgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt
c2VyaWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmNsaWVudCBh
bmQgcmVzb3VyY2Ugc2VydmVyOyBhbmQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
c2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNlcnZlci48bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymx1ZSI+W0RlbmlzXSBJ
biBvcmRlciB0byBzdXBwb3J0IHRoZSB1c2VyJ3MgcHJpdmFjeSwgdGhlcmUgc2hvdWxkIGJlIG5v
IGludGVyYWN0aW9uIGF0IGFsbCBiZXR3ZWVuIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCBh
IHJlc291cmNlIHNlcnZlciA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PGk+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjpibHVlIj5hdCB0aGUgdGltZSBvZiBhIGNsaWVudCByZXF1ZXN0PC9zcGFu
PjwvaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsdWUiPi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBncm91cCB3aWxsIHNl
ZWsgdG8gbWluaW1pemUgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIGZvcm0gb2YgY2xpZW50IGFwcGxp
Y2F0aW9ucywgYWxsb3dpbmcgZm9yOjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjYuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv
bTowaW47bWFyZ2luLWxlZnQ6MzUuN3B0O21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVu
dDotMTcuODVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
c2Fucy1zZXJpZiI+RmluZS1ncmFpbmVkIHNwZWNpZmljYXRpb24gb2YgYWNjZXNzPC9zcGFuPjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6Ni4wcHQ7bWFy
Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDozNS43cHQ7bWFyZ2lu
LWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xNy44NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5BcHByb3ZhbCBvZiBBUyBhdHRl
c3RhdGlvbiB0byBpZGVudGlmaWVycyBhbmQgb3RoZXIgaWRlbnRpdHkgY2xhaW1zPC9zcGFuPjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6Ni4wcHQ7bWFy
Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDozNS43cHQ7bWFyZ2lu
LWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xNy44NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5BcHByb3ZhbCBvZiBhY2Nlc3Mg
dG8gbXVsdGlwbGUgcmVzb3VyY2VzIGFuZCBBUElzIGluIGEgc2luZ2xlIGludGVyYWN0aW9uPC9z
cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6Ni4w
cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDozNS43cHQ7
bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xNy44NXB0Ij48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm
Ij4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5NdWx0aXBsZSBhY2Nl
c3MgdG9rZW5zIGluIGEgc2luZ2xlIHJlcXVlc3QgYW5kIHJlc3BvbnNlPC9zcGFuPjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6Ni4wcHQ7bWFyZ2luLXJp
Z2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDozNS43cHQ7bWFyZ2luLWJvdHRv
bTouMDAwMXB0O3RleHQtaW5kZW50Oi0xNy44NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tPC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
c2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5BUy1kaXJlY3RlZCBkaXNwYXRjaCBvZiBh
Y2Nlc3MgdG9rZW5zIHRvIHRoZSBhcHByb3ByaWF0ZSBSUzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibHVl
Ij5bRGVuaXNdIEFzLWRpcmVjdGVkIGRpc3BhdGNoIGRvZXMgbm90IGFsbG93IHRvIHN1cHBvcnQg
dGhlIHVzZXIncyBwcml2YWN5LiBIb3dldmVyLCBSUy1kaXJlY3RlZCBkaXNwYXRjaCBhbGxvd3Mg
dG8gc3VwcG9ydCB0aGUgdXNlcidzIHByaXZhY3kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlIHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsdWUiPkl0
IHNob3VsZCBiZSBleHBsaWNpdGx5IG1lbnRpb25lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6Ni4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1JvbWFuXSBB
cyBhYm92ZSAocGVyIHRoZSBBUyB2cy4gUlMgYmVoYXZpb3IpPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6Ni4wcHQ7bWFyZ2luLXJpZ2h0OjBp
bjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDozNS43cHQ7bWFyZ2luLWJvdHRvbTouMDAw
MXB0O3RleHQtaW5kZW50Oi0xNy44NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z
ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5TZXBhcmF0aW9uIGJldHdlZW4gdGhlIHBhcnR5IGF1
dGhvcml6aW5nIGFjY2VzcyBhbmQgdGhlIHBhcnR5IG9wZXJhdGluZyB0aGUgY2xpZW50IHJlcXVl
c3RpbmcgYWNjZXNzIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OjYuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFy
Z2luLWxlZnQ6MzUuN3B0O21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotMTcuODVw
dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6Ni4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90
dG9tOjBpbjttYXJnaW4tbGVmdDo0MC45NXB0O21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWlu
ZGVudDotMTcuODVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibHVlIj5bRGVuaXNdIEl0IGlzIHF1
ZXN0aW9uYWJsZSB3aGV0aGVyIHN1Y2ggYSBzZXBhcmF0aW9uIHdvdWxkIGJlIHJlYWxseSBiZW5l
ZmljaWFsLiBJbiBkb3VidCwgdGhpcyBpdGVtIHNob3VsZCBiZSByZW1vdmVkLjwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi10
b3A6Ni4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1JvbWFuXSBDb3VsZCB5b3Ugc2F5IG1vcmUgb24g
d2h5IHRoaXMgZmxleGliaWxpdHkgd291bGRu4oCZdCBiZSB3b3J0aCBpdD8mbmJzcDsgPG86cD48
L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6Ni4wcHQ7
bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDozNS43cHQ7bWFy
Z2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xNy44NXB0Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5U
aGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBvaW50cyBmb3IgdGhpcyBwcm90b2NvbCB0
byBhbGxvdyBmb3IgZmxleGliaWxpdHkgaW4gYXJlYXMgaW5jbHVkaW5nOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjYuMHB0O21hcmdpbi1y
aWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MzUuN3B0O21hcmdpbi1ib3R0
b206LjAwMDFwdDt0ZXh0LWluZGVudDotMTcuODVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6Ni4w
cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDozNS43cHQ7
bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xNy44NXB0Ij48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm
Ij5DcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3NhZ2Ugc2lnbmF0dXJlcywgYW5k
IHByb29mIG9mIHBvc3Nlc3Npb248L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDo2LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206
MGluO21hcmdpbi1sZWZ0OjM1LjdwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6
LTE3Ljg1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh
bnMtc2VyaWYiPlVzZXIgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBu
b24td2ViIG1ldGhvZHM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDo2LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21h
cmdpbi1sZWZ0OjM1LjdwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LTE3Ljg1
cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LHNhbnMtc2VyaWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy
aWYiPk1lY2hhbmlzbXMgZm9yIGNvbnZleWluZyB1c2VyLCBzb2Z0d2FyZSwgb3JnYW5pemF0aW9u
LCBhbmQgb3RoZXIgaW5mb3JtYXRpb24gdXNlZCBpbiBhdXRob3JpemF0aW9uIGRlY2lzaW9ucyA8
L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo2
LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjM1Ljdw
dDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LTE3Ljg1cHQiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy
aWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk1lY2hhbmlzbXMg
Zm9yIHByZXNlbnRpbmcgdG9rZW5zIHRvIHJlc291cmNlIHNlcnZlcnMgYW5kIGJpbmRpbmcgcmVz
b3VyY2UgcmVxdWVzdHMgdG8gdG9rZW5zIGFuZCBhc3NvY2lhdGVkIGNyeXB0b2dyYXBoaWMga2V5
cyA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+T3B0aW1pemVk
IGluY2x1c2lvbiBvZiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIChpbmNsdWRpbmcgaWRlbnRpZmll
cnMgYW5kIGlkZW50aXR5IGFzc2VydGlvbnMpIHRocm91Z2ggdGhlIGRlbGVnYXRpb24gcHJvY2Vz
cyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkFkZGl0aW9uYWxseSwg
dGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNoYW5pc21zIGZvciBtYW5hZ2VtZW50IG9mIHRoZSBw
cm90b2NvbCBsaWZlY3ljbGUgaW5jbHVkaW5nOjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjYuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu
LWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MzUuN3B0O21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0
LWluZGVudDotMTcuODVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZiI+RGlzY292ZXJ5IG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcjwv
c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjYu
MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MzUuN3B0
O21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotMTcuODVwdCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp
ZiI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+UmV2b2NhdGlvbiBv
ZiBhY3RpdmUgdG9rZW5zPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy
aWYiPkRhdGEgbW9kZWwgZm9yIGdyYW50ZWQgYWNjZXNzIGFuZCBtZWNoYW5pc21zIGZvciB0aGUg
QVMgYW5kIFJTIHRvIGNvbW11bmljYXRlIHRoZSBncmFudGVkIGFjY2VzcyBtb2RlbDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibHVlIj5bRGVuaXNdIFdoaWxl
IGl0IGlzIHRoZSBkdXR5IGZvciB0aGUgUlMgdG8gY29tbXVuaWNhdGUgdGhlIGdyYW50ZWQgYWNj
ZXNzIG1vZGVsIHRvIHRoZSBjbGllbnQgPGk+YXQgdGhlIGFwcHJvcHJpYXRlIGluc3RhbnQgb2Yg
dGltZTwvaT4sIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOmJsdWUiPnRoZSBBUyBzaG91bGQgYmUga2VwdCBmdWxseSBpZ25vcmFudCBvZiBpdC48L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm
Ij5BbHRob3VnaCB0aGUgYXJ0aWZhY3RzIGZvciB0aGlzIHdvcmsgYXJlIG5vdCBpbnRlbmRlZCBv
ciBleHBlY3RlZCB0byBiZSBiYWNrd2FyZHMtY29tcGF0aWJsZSB3aXRoIE9BdXRoIDIuMCBvciBP
cGVuSUQgQ29ubmVjdCwgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy
aWYiPnRoZSBncm91cCB3aWxsIGF0dGVtcHQgdG8gc2ltcGxpZnkgbWlncmF0aW5nIGZyb20gT0F1
dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVjdCB0byB0aGUgbmV3IHByb3RvY29sIHdoZXJlIHBvc3Np
YmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBncm91cCBp
cyBub3QgY2hhcnRlcmVkIHRvIGRldmVsb3AgZXh0ZW5zaW9ucyB0byBPQXV0aCAyLjAsIGFuZCBh
cyBzdWNoIHdpbGwgZm9jdXMgb24gbmV3IHRlY2hub2xvZ2ljYWwgc29sdXRpb25zIG5vdCBuZWNl
c3NhcmlseSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Y29t
cGF0aWJsZSB3aXRoIE9BdXRoIDIuMC4gRnVuY3Rpb25hbGl0eSB0aGF0IGJ1aWxkcyBkaXJlY3Rs
eSBvbiBPQXV0aCAyLjAgd2lsbCBiZSBkaXJlY3RlZCB0byB0aGUgT0F1dGggV29ya2luZyBHcm91
cCwgaW5jbHVkaW5nIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm
Ij5mdW5jdGlvbmFsaXR5IGJhY2stcG9ydGVkIGZyb20gdGhlIHByb3RvY29sIGRldmVsb3BlZCBo
ZXJlIHRvIE9BdXRoIDIuMC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi
PlRoZSBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBtZWNoYW5pc21zIGZvciBhcHBseWlu
ZyBjcnlwdG9ncmFwaGljIG1ldGhvZHMsIHN1Y2ggYXMgSk9TRSBhbmQgQ09TRSwgdG8gdGhlIGRl
bGVnYXRpb24gcHJvY2Vzcy4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt
c2VyaWYiPlRoaXMgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG5ldyBjcnlwdG9n
cmFwaGljIG1ldGhvZHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy
aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5U
aGUgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3IgY29udmV5aW5n
IGlkZW50aXR5IGluZm9ybWF0aW9uIHdpdGhpbiB0aGUgcHJvdG9jb2wgaW5jbHVkaW5nIGV4aXN0
aW5nIGlkZW50aWZpZXJzIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl
cmlmIj4oc3VjaCBhcyBlbWFpbCBhZGRyZXNzZXMsIHBob25lIG51bWJlcnMsIHVzZXJuYW1lcywg
YW5kIHN1YmplY3QgaWRlbnRpZmllcnMpIGFuZCBhc3NlcnRpb25zIChzdWNoIGFzIE9wZW5JRCBD
b25uZWN0IElEIFRva2VucywgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt
c2VyaWYiPlNBTUwgQXNzZXJ0aW9ucywgYW5kIFZlcmlmaWFibGUgQ3JlZGVudGlhbHMpLiBUaGUg
Z3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG5ldyBmb3JtYXRzIGZvciBpZGVudGlm
aWVycyBvciBhc3NlcnRpb25zLCBub3IgaXMgdGhlIGdyb3VwIDxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5jaGFydGVyZWQgdG8gZGV2ZWxvcCBzY2hlbWFzIGZv
ciB1c2VyIGluZm9ybWF0aW9uLCBwcm9maWxlcywgb3Igb3RoZXIgaWRlbnRpdHkgYXR0cmlidXRl
cywgdW5sZXNzIGEgdmlhYmxlIGV4aXN0aW5nIGZvcm1hdCBpcyBub3QgYXZhaWxhYmxlLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGluaXRpYWwgd29yayB3aWxs
IGZvY3VzIG9uIHVzaW5nIEhUVFBTIGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGNsaWVu
dCBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0YWtpbmcgYWR2YW50YWdlIDxvOnA+PC9v
OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5vZiBvcHRpbWl6YXRpb24gZmVh
dHVyZXMgb2YgSFRUUC8yIGFuZCBIVFRQLzMgd2hlcmUgcG9zc2libGUsIGFuZCB3aWxsIHN0cml2
ZSB0byBlbmFibGUgc2ltcGxlIG1hcHBpbmcgdG8gb3RoZXIgcHJvdG9jb2xzIHN1Y2ggYXMgQ09B
UCA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+d2hlbiBkb2lu
ZyBzbyBkb2VzIG5vdCBjb25mbGljdCB3aXRoIHRoZSBwcmltYXJ5IGZvY3VzLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TWlsZXN0b25lcyB0byBpbmNsdWRlOjwvc3Bh
bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjYuMHB0
O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MzUuN3B0O21h
cmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotMTcuODVwdCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+
LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Q29yZSBkZWxlZ2F0aW9u
IHByb3RvY29sPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tdG9w
OjYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsdWUiPltEZW5pc10gQmVmb3JlIGRlZmluaW5n
IGEgJnF1b3Q7Q29yZSBkZWxlZ2F0aW9uIHByb3RvY29sJnF1b3Q7LCBhIHNpbXBsZSBjbGllbnQg
c2VydmVyLXByb3RvY29sIGludm9sdmluZyB0aGUgcHJlc2VudGF0aW9uIG9mIHNldmVyYWwgYWNj
ZXNzIHRva2VucyB0byBvbmUgUlMgc2hvdWxkIGJlIGRlZmluZWQuIDxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLXRvcDo2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjpibHVlIj5Qcml2YWN5IHByaW5jaXBsZXMgc2hvdWxkIGJlIGFwcGxpZWQgd2hlbiBkZWZpbmlu
ZyB0aGUgcHJvdG9jb2wuIFRoZW4gYWZ0ZXIsIGEgZGVsZWdhdGlvbiBtZWNoYW5pc20gYWxsb3dp
bmcgb25lIFJTIHRvIGZvcndhcmQgYW4gb3BlcmF0aW9uIHRvIGFub3RoZXIgUlMgc2hvdWxkIGJl
IGRlZmluZWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjYuMHB0O21hcmdpbi1yaWdodDowaW47bWFy
Z2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MzUuN3B0O21hcmdpbi1ib3R0b206LjAwMDFwdDt0
ZXh0LWluZGVudDotMTcuODVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LTwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssc2Fucy1zZXJpZiI+S2V5IHByZXNlbnRhdGlvbiBtZWNoYW5pc20gYmluZGluZ3Mg
dG8gdGhlIGNvcmUgcHJvdG9jb2wgaW5jbHVkaW5nIFRMUywgZGV0YWNoZWQgSFRUUCBzaWduYXR1
cmUsIGFuZCBlbWJlZGRlZCBIVFRQIHNpZ25hdHVyZXMgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy
LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsdWUi
PltEZW5pc10gQmluZGluZ3MgdG8gVExTIGFyZSBub3cgZGVwcmVjYXRlZCwgd2h5IHNob3VsZCB0
aGV5IGJlIG1haW50YWluZWQgPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9
Im1hcmdpbi10b3A6Ni4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymx1ZSI+U2lnbmF0dXJlcyBt
YXkgYmUgbmVlZGVkIGJ1dCB0aGV5IGRvIG5vdCBuZWNlc3NhcmlseSBuZWVkIHRvIGJlICZxdW90
O2RldGFjaGVkIEhUVFAgc2lnbmF0dXJlLCBhbmQgZW1iZWRkZWQgSFRUUCBzaWduYXR1cmVzJnF1
b3Q7LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6Ni4w
cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymx1ZSI+VGhpcyBpdGVtIHNob3VsZCBiZSBlaXRoZXIg
cmVtb3ZlZCBvciByZXdvcmRlZC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw
YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tdG9wOjYuMHB0Ij48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PltSb21hbl0gTm90ZWQuJm5ic3A7IEnigJlkIHdhbnQgdG8gaGVhciBvdGhlcnMgb24gdGhpcyBy
ZXNjb3BpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tdG9w
OjYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjYuMHB0O21hcmdpbi1yaWdodDowaW47bWFy
Z2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6MzUuN3B0O21hcmdpbi1ib3R0b206LjAwMDFwdDt0
ZXh0LWluZGVudDotMTcuODVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LTwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssc2Fucy1zZXJpZiI+Q29udmV5YW5jZSBtZWNoYW5pc21zIGZvciBpZGVudGlmaWVy
cyBhbmQgYXNzZXJ0aW9ucyA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDo2LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGlu
O21hcmdpbi1sZWZ0OjM1LjdwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1pbmRlbnQ6LTE3
Ljg1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt
c2VyaWYiPkd1aWRlbGluZXMgZm9yIHVzZSBvZiBwcm90b2NvbCBleHRlbnNpb24gcG9pbnRzIChp
ZiBuZWVkZWQpIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0mbmJzcDsmbmJzcDsmbmJzcDsgR3VpZGVsaW5lcyBv
biBtaWdyYXRpb24gcGF0aHMsIGltcGxlbWVudGF0aW9uLCBhbmQgb3BlcmF0aW9ucw0KPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibHVlIj5bRGVuaXNd
IFRoZSBhYm92ZSB0aHJlZSBsaW5lcyBhcmUgcmF0aGVyIG15c3RlcmlvdXMuPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MTUuNzVw
dCI+DQpbUm9tYW5dIFRoZSBndWlkZWxpbmVzIG9uIG1pZ3JhdGlvbiBwYXRocyBjYW1lIGZyb20g
dGhlIGluaXRpYWwgSUVTRyByZXZpZXcgaW4gb3JkZXIgdG8gaGF2ZSBhIG5hbWVkIGFjdGl2aXR5
IHRvIGFjdGlvbiB0aGUgZGVzaWduIGdvYWwgb2Yg4oCc4oCmIHRoZSBncm91cCB3aWxsIGF0dGVt
cHQgdG8gc2ltcGxpZnkgbWlncmF0aW5nIGZyb20gT0F1dGggMi4wIGFuZCBPcGVuSUQgQ29ubmVj
dCB0byB0aGUgbmV3IHByb3RvY29sIHdoZXJlIHBvc3NpYmxl4oCdDQogYSBiaXQgZWFybGllciBp
biB0aGUgdGV4dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPldoZXJlIHBv
c3NpYmxlLCB0aGUgZ3JvdXAgd2lsbCBzZWVrIHRvIG1ha2UgdXNlIG9mIHRvb2xzIHRvIGd1aWRl
IGFuZCBpbmZvcm0gdGhlIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzIGluY2x1ZGluZyBmb3JtYWwg
YW5hbHlzaXMsDQo8YnI+DQphcmNoaXRlY3R1cmUgZG9jdW1lbnRzLCBhbmQgdXNlIGNhc2UgZG9j
dW1lbnRzLiBUaGVzZSBhcnRpZmFjdHMgd2lsbCBub3QgYmUgY29uc2lkZXJlZCBhcyB3b3JraW5n
IGdyb3VwIG1pbGVzdG9uZXMgb3IgZGVsaXZlcmFibGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY29vcGVyYXRlIGFu
ZCBjb29yZGluYXRlIHdpdGggb3RoZXIgSUVURiBXR3Mgc3VjaCBhcyBPQVVUSCwgYW5kIHdvcmsg
d2l0aCBleHRlcm5hbCBvcmdhbml6YXRpb25zLA0KPGJyPg0Kc3VjaCBhcyB0aGUgT3BlbklEIEZv
dW5kYXRpb24sIGFzIGFwcHJvcHJpYXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOmJsdWUiPltEZW5pc10gVGhlIGNoYXJ0ZXIgc2hvdWxkIGJlIHNob3J0
ZXIuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z
LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltSb21hbl0gRGVmaW5pdGVs
eS4mbmJzcDsgTmV2ZXJ0aGVsZXNzLCB3ZSBoYXZlIHRoZSBjdXJyZW50IHRleHQgdGhyb3VnaCBy
b3VnaCBjb25zZW5zdXMgcHJvY2VzcyBhY2hpZXZlZCBmcm9tIHR3byBCb0ZzIGFuZCBtdWx0aXBs
ZSBtYWlsaW5nIGxpc3QgY29uc2Vuc3VzIGNhbGxzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S
ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9tYW4gPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsdWUi
Pi9EZW5pczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+QSBuZXcgSUVU
RiBXRyBoYXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgU2VjdXJpdHkgQXJlYS4gVGhlIElFU0cgaGFz
IG5vdCBtYWRlPG86cD48L286cD48L3ByZT4NCjxwcmU+YW55IGRldGVybWluYXRpb24geWV0LiBU
aGUgZm9sbG93aW5nIGRyYWZ0IGNoYXJ0ZXIgd2FzIHN1Ym1pdHRlZCwgYW5kIGlzPG86cD48L286
cD48L3ByZT4NCjxwcmU+cHJvdmlkZWQgZm9yIGluZm9ybWF0aW9uYWwgcHVycG9zZXMgb25seS4g
UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5J
RVNHIG1haWxpbmcgbGlzdCAoPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0
Zi5vcmc8L2E+KSA8Yj5ieSAyMDIwLTA3LTA2PC9iPi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5HcmFudCBOZWdvdGlhdGlvbiBhbmQgQXV0aG9y
aXphdGlvbiBQcm90b2NvbCAoZ25hcCk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkN1cnJlbnQgc3RhdHVzOiBQcm9wb3NlZCBXRzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNoYWly
czo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgWWFyb24gU2hlZmZlciA8YSBocmVmPSJt
YWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj4mbHQ7eWFyb25mLmlldGZAZ21haWwuY29tJmd0
OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgTGVpZiBKb2hhbnNzb24gPGEgaHJl
Zj0ibWFpbHRvOmxlaWZqQHN1bmV0LnNlIj4mbHQ7bGVpZmpAc3VuZXQuc2UmZ3Q7PC9hPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFzc2lnbmVk
IEFyZWEgRGlyZWN0b3I6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IFJvbWFuIERhbnls
aXcgPGEgaHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyI+Jmx0O3JkZEBjZXJ0Lm9yZyZndDs8L2E+
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U2Vj
dXJpdHkgQXJlYSBEaXJlY3RvcnM6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IEJlbmph
bWluIEthZHVrIDxhIGhyZWY9Im1haWx0bzprYWR1a0BtaXQuZWR1Ij4mbHQ7a2FkdWtAbWl0LmVk
dSZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IFJvbWFuIERhbnlsaXcgPGEg
aHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyI+Jmx0O3JkZEBjZXJ0Lm9yZyZndDs8L2E+PG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TWFpbGluZyBs
aXN0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBBZGRyZXNzOiA8YSBocmVmPSJtYWls
dG86dHhhdXRoQGlldGYub3JnIj50eGF1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7IFRvIHN1YnNjcmliZTogPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0NhbWJyaWEgTWF0aCZxdW90OyxzZXJpZiI+4oCLPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsg
QXJjaGl2ZTogPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dz
ZS90eGF1dGgvIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL3R4YXV0
aC88L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+R3JvdXAgcGFnZTogPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ncm91
cC9nbmFwLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9ncm91cC9nbmFwLzwvYT48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5DaGFydGVy
OiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYt
Z25hcC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1nbmFw
LzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5UaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGEgZmluZS1ncmFpbmVkIGRlbGVn
YXRpb24gcHJvdG9jb2wgZm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+YXV0aG9yaXphdGlvbiBh
bmQgQVBJIGFjY2VzcywgYXMgd2VsbCBhcyByZXF1ZXN0aW5nIGFuZCBwcm92aWRpbmcgdXNlcjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlkZW50aWZpZXJzIGFuZCBjbGFpbXMuIFRoaXMgcHJvdG9j
b2wgd2lsbCBhbGxvdyBhbiBhdXRob3JpemluZyBwYXJ0eSB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPmRlbGVnYXRlIGFjY2VzcyB0byBjbGllbnQgc29mdHdhcmUgdGhyb3VnaCBhbiBhdXRob3Jp
emF0aW9uIHNlcnZlci4gSXQgd2lsbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmV4cGFuZCB1cG9u
IHRoZSB1c2VzIGNhc2VzIGN1cnJlbnRseSBzdXBwb3J0ZWQgYnkgT0F1dGggMi4wIGFuZCBPcGVu
SUQgQ29ubmVjdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPihpdHNlbGYgYW4gZXh0ZW5zaW9uIG9m
IE9BdXRoIDIuMCkgdG8gc3VwcG9ydCBhdXRob3JpemF0aW9ucyBzY29wZWQgYXM8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5uYXJyb3dseSBhcyBhIHNpbmdsZSB0cmFuc2FjdGlvbiwgcHJvdmlkZSBh
IGNsZWFyIGZyYW1ld29yayBmb3IgaW50ZXJhY3Rpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5h
bW9uZyBhbGwgcGFydGllcyBpbnZvbHZlZCBpbiB0aGUgcHJvdG9jb2wgZmxvdywgYW5kIHJlbW92
ZSB1bm5lY2Vzc2FyeTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRlcGVuZGVuY2Ugb24gYSBicm93
c2VyIG9yIHVzZXItYWdlbnQgZm9yIGNvb3JkaW5hdGluZyBpbnRlcmFjdGlvbnMuPG86cD48L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIGRlbGVnYXRp
b24gcHJvY2VzcyB3aWxsIGJlIGFjdGVkIHVwb24gYnkgbXVsdGlwbGUgcGFydGllcyBpbiB0aGUg
cHJvdG9jb2wsPG86cD48L286cD48L3ByZT4NCjxwcmU+ZWFjaCBwZXJmb3JtaW5nIGEgc3BlY2lm
aWMgcm9sZS4gVGhlIHByb3RvY29sIHdpbGwgZGVjb3VwbGUgdGhlIGludGVyYWN0aW9uPG86cD48
L286cD48L3ByZT4NCjxwcmU+Y2hhbm5lbHMsIHN1Y2ggYXMgdGhlIGVuZCB1c2Vy4oCZcyBicm93
c2VyLCBmcm9tIHRoZSBkZWxlZ2F0aW9uIGNoYW5uZWwsIHdoaWNoPG86cD48L286cD48L3ByZT4N
CjxwcmU+aGFwcGVucyBkaXJlY3RseSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBhdXRob3Jp
emF0aW9uIHNlcnZlciAoaW4gY29udHJhc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53aXRoIE9B
dXRoIDIuMCwgd2hpY2ggaXMgaW5pdGlhdGVkIGJ5IHRoZSBjbGllbnQgcmVkaXJlY3RpbmcgdGhl
IHVzZXLigJlzPG86cD48L286cD48L3ByZT4NCjxwcmU+YnJvd3NlcikuIFRoZSBwcm90b2NvbCB3
aWxsIGluY2x1ZGUgYSBtZWFucyBvZiBzcGVjaWZ5aW5nIGhvdyB0aGUgdXNlciBjYW48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5wb3RlbnRpYWxseSBiZSBpbnZvbHZlZCBpbiBhbiBpbnRlcmFjdGl2
ZSBmYXNoaW9uIGR1cmluZyB0aGUgZGVsZWdhdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBy
b2Nlc3MuIFRoZSBjbGllbnQgYW5kIEF1dGhvcml6YXRpb24gU2VydmVyIChBUykgd2lsbCB1c2Ug
dGhlc2UgaW50ZXJhY3Rpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5tZWNoYW5pc21zIHRvIGlu
dm9sdmUgdGhlIHVzZXIsIGFzIG5lY2Vzc2FyeSwgdG8gbWFrZSBhdXRob3JpemF0aW9uIGRlY2lz
aW9ucy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGRlY291cGxpbmcgYXZvaWRzIG1hbnkg
b2YgdGhlIHNlY3VyaXR5IGNvbmNlcm5zIGFuZCB0ZWNobmljYWwgY2hhbGxlbmdlczxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPm9mIE9BdXRoIDIuMCBhbmQgcHJvdmlkZXMgYSBub24taW52YXNpdmUg
cGF0aCBmb3Igc3VwcG9ydGluZyBmdXR1cmUgdHlwZXMgb2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5jbGllbnRzIGFuZCBpbnRlcmFjdGlvbiBjaGFubmVscy48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgZ3JvdXAgd2lsbCBkZWZpbmUgaW50
ZXJvcGVyYWJpbGl0eSBmb3IgdGhpcyBwcm90b2NvbCBiZXR3ZWVuIGRpZmZlcmVudDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPnBhcnRpZXMsIGluY2x1ZGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiAtIGNsaWVudCBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXI7PG86cD48L286cD48L3ByZT4NCjxw
cmU+IC0gY2xpZW50IGFuZCByZXNvdXJjZSBzZXJ2ZXI7IGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiAtIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIuPG86cD48L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIGdyb3VwIHdp
bGwgc2VlayB0byBtaW5pbWl6ZSBhc3N1bXB0aW9ucyBhYm91dCB0aGUgZm9ybSBvZiBjbGllbnQ8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hcHBsaWNhdGlvbnMsIGFsbG93aW5nIGZvcjo8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4tIEZpbmUtZ3JhaW5lZCBzcGVjaWZpY2F0aW9uIG9mIGFjY2Vzczxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gQXBwcm92YWwgb2YgQVMgYXR0ZXN0YXRpb24gdG8gaWRl
bnRpZmllcnMgYW5kIG90aGVyIGlkZW50aXR5IGNsYWltczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
Pi0gQXBwcm92YWwgb2YgYWNjZXNzIHRvIG11bHRpcGxlIHJlc291cmNlcyBhbmQgQVBJcyBpbiBh
IHNpbmdsZSBpbnRlcmFjdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gU3VwcG9ydCBmb3Ig
bXVsdGlwbGUgYWNjZXNzIHRva2VucyBpbiBhIHNpbmdsZSByZXF1ZXN0IGFuZCByZXNwb25zZTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gU3VwcG9ydCBmb3IgZGlyZWN0ZWQsIGF1ZGllbmNlLXJl
c3RyaWN0ZWQgYWNjZXNzIHRva2VuczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gU2VwYXJhdGlv
biBiZXR3ZWVuIHRoZSBwYXJ0eSBhdXRob3JpemluZyBhY2Nlc3MgYW5kIHRoZSBwYXJ0eSBvcGVy
YXRpbmcgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Y2xpZW50IHJlcXVlc3RpbmcgYWNjZXNz
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhl
IGdyb3VwIHdpbGwgZGVmaW5lIGV4dGVuc2lvbiBwb2ludHMgZm9yIHRoaXMgcHJvdG9jb2wgdG8g
YWxsb3cgZm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+ZmxleGliaWxpdHkgaW4gYXJlYXMgaW5j
bHVkaW5nOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlPi0gQ3J5cHRvZ3JhcGhpYyBhZ2lsaXR5IGZvciBrZXlzLCBtZXNzYWdlIHNpZ25hdHVyZXMs
IGFuZCBwcm9vZiBvZiBwb3NzZXNzaW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+LSBVc2VyIGlu
dGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRob2RzPG86
cD48L286cD48L3ByZT4NCjxwcmU+LSBNZWNoYW5pc21zIGZvciBjb252ZXlpbmcgdXNlciwgc29m
dHdhcmUsIG9yZ2FuaXphdGlvbiwgYW5kIG90aGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+aW5m
b3JtYXRpb24gdXNlZCBpbiBhdXRob3JpemF0aW9uIGRlY2lzaW9uczxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPi0gTWVjaGFuaXNtcyBmb3IgcHJlc2VudGluZyB0b2tlbnMgdG8gcmVzb3VyY2Ugc2Vy
dmVycyBhbmQgYmluZGluZyByZXNvdXJjZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJlcXVlc3Rz
IHRvIHRva2VucyBhbmQgYXNzb2NpYXRlZCBjcnlwdG9ncmFwaGljIGtleXM8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4tIE9wdGltaXplZCBpbmNsdXNpb24gb2YgYWRkaXRpb25hbCBpbmZvcm1hdGlv
biAoaW5jbHVkaW5nIGlkZW50aWZpZXJzIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlkZW50
aXR5IGFzc2VydGlvbnMpIHRocm91Z2ggdGhlIGRlbGVnYXRpb24gcHJvY2VzczxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFkZGl0aW9uYWxseSwg
dGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNoYW5pc21zIGZvciBtYW5hZ2VtZW50IG9mIHRoZSBw
cm90b2NvbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmxpZmVjeWNsZSBpbmNsdWRpbmc6PG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+LSBEaXNjb3Zl
cnkgb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyPG86cD48L286cD48L3ByZT4NCjxwcmU+LSBS
ZXZvY2F0aW9uIG9mIGFjdGl2ZSB0b2tlbnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIE1lY2hh
bmlzbXMgZm9yIHRoZSBBUyBhbmQgUlMgdG8gY29tbXVuaWNhdGUgdGhlIGFjY2VzcyBncmFudGVk
IGJ5IGFuIGFjY2VzczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRva2VuPG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QWx0aG91Z2ggdGhlIGFydGlm
YWN0cyBmb3IgdGhpcyB3b3JrIGFyZSBub3QgaW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmU8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5iYWNrd2FyZHMtY29tcGF0aWJsZSB3aXRoIE9BdXRoIDIuMCBv
ciBPcGVuSUQgQ29ubmVjdCwgdGhlIGdyb3VwIHdpbGwgYXR0ZW1wdDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPnRvIHNpbXBsaWZ5IG1pZ3JhdGluZyBmcm9tIE9BdXRoIDIuMCBhbmQgT3BlbklEIENv
bm5lY3QgdG8gdGhlIG5ldyBwcm90b2NvbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPndoZXJlIHBv
c3NpYmxlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlPlRoaXMgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIGV4dGVuc2lvbnMgdG8g
T0F1dGggMi4wLCBhbmQgYXMgc3VjaDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPndpbGwgZm9jdXMg
b24gbmV3IHRlY2hub2xvZ2ljYWwgc29sdXRpb25zIG5vdCBuZWNlc3NhcmlseSBjb21wYXRpYmxl
IHdpdGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PQXV0aCAyLjAuIEZ1bmN0aW9uYWxpdHkgdGhh
dCBidWlsZHMgZGlyZWN0bHkgb24gT0F1dGggMi4wIHdpbGwgYmUgZGlyZWN0ZWQ8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT50byB0aGUgT0F1dGggV29ya2luZyBHcm91cCwgaW5jbHVkaW5nIGZ1bmN0
aW9uYWxpdHkgYmFjay1wb3J0ZWQgZnJvbSB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wcm90
b2NvbCBkZXZlbG9wZWQgaGVyZSB0byBPQXV0aCAyLjAuPG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBk
ZXZlbG9wIG1lY2hhbmlzbXMgZm9yIGFwcGx5aW5nIGNyeXB0b2dyYXBoaWM8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5tZXRob2RzLCBzdWNoIGFzIEpPU0UgYW5kIENPU0UsIHRvIHRoZSBkZWxlZ2F0
aW9uIHByb2Nlc3MuIFRoaXMgZ3JvdXAgaXMgbm90PG86cD48L286cD48L3ByZT4NCjxwcmU+Y2hh
cnRlcmVkIHRvIGRldmVsb3AgbmV3IGNyeXB0b2dyYXBoaWMgbWV0aG9kcy48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgZ3JvdXAgaXMgY2hh
cnRlcmVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3IgY29udmV5aW5nIGlkZW50aXR5PG86cD48
L286cD48L3ByZT4NCjxwcmU+aW5mb3JtYXRpb24gd2l0aGluIHRoZSBwcm90b2NvbCBpbmNsdWRp
bmcgZXhpc3RpbmcgaWRlbnRpZmllcnMgKHN1Y2ggYXMgZW1haWw8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5hZGRyZXNzZXMsIHBob25lIG51bWJlcnMsIHVzZXJuYW1lcywgYW5kIHN1YmplY3QgaWRl
bnRpZmllcnMpIGFuZCBhc3NlcnRpb25zPG86cD48L286cD48L3ByZT4NCjxwcmU+KHN1Y2ggYXMg
T3BlbklEIENvbm5lY3QgSUQgVG9rZW5zLCBTQU1MIEFzc2VydGlvbnMsIGFuZCBWZXJpZmlhYmxl
PG86cD48L286cD48L3ByZT4NCjxwcmU+Q3JlZGVudGlhbHMpLiBUaGUgZ3JvdXAgaXMgbm90IGNo
YXJ0ZXJlZCB0byBkZXZlbG9wIG5ldyBmb3JtYXRzIGZvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PmlkZW50aWZpZXJzIG9yIGFzc2VydGlvbnMsIG5vciBpcyB0aGUgZ3JvdXAgY2hhcnRlcmVkIHRv
IGRldmVsb3Agc2NoZW1hcyBmb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT51c2VyIGluZm9ybWF0
aW9uLCBwcm9maWxlcywgb3Igb3RoZXIgaWRlbnRpdHkgYXR0cmlidXRlcywgdW5sZXNzIGEgdmlh
YmxlPG86cD48L286cD48L3ByZT4NCjxwcmU+ZXhpc3RpbmcgZm9ybWF0IGlzIG5vdCBhdmFpbGFi
bGUuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
VGhlIGluaXRpYWwgd29yayB3aWxsIGZvY3VzIG9uIHVzaW5nIEhUVFBTIGZvciBjb21tdW5pY2F0
aW9uIGJldHdlZW4gdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Y2xpZW50IGFuZCB0aGUgYXV0
aG9yaXphdGlvbiBzZXJ2ZXIsIHRha2luZyBhZHZhbnRhZ2Ugb2Ygb3B0aW1pemF0aW9uPG86cD48
L286cD48L3ByZT4NCjxwcmU+ZmVhdHVyZXMgb2YgSFRUUC8yIGFuZCBIVFRQLzMgd2hlcmUgcG9z
c2libGUsIGFuZCB3aWxsIHN0cml2ZSB0byBlbmFibGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5z
aW1wbGUgbWFwcGluZyB0byBvdGhlciBwcm90b2NvbHMgc3VjaCBhcyBDT0FQIHdoZW4gZG9pbmcg
c28gZG9lcyBub3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jb25mbGljdCB3aXRoIHRoZSBwcmlt
YXJ5IGZvY3VzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8cHJlPk1pbGVzdG9uZXMgdG8gaW5jbHVkZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIENv
cmUgZGVsZWdhdGlvbiBwcm90b2NvbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gS2V5IHByZXNl
bnRhdGlvbiBtZWNoYW5pc20gYmluZGluZ3MgdG8gdGhlIGNvcmUgcHJvdG9jb2wgaW5jbHVkaW5n
IFRMUyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kZXRhY2hlZCBIVFRQIHNpZ25hdHVyZSwgYW5k
IGVtYmVkZGVkIEhUVFAgc2lnbmF0dXJlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gQ29udmV5
YW5jZSBtZWNoYW5pc21zIGZvciBpZGVudGlmaWVycyBhbmQgYXNzZXJ0aW9uczxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPi0gR3VpZGVsaW5lcyBmb3IgdXNlIG9mIHByb3RvY29sIGV4dGVuc2lvbiBw
b2ludHM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIChpZiBuZWVkZWQpIEd1aWRlbGluZXMgb24g
bWlncmF0aW9uIHBhdGhzLCBpbXBsZW1lbnRhdGlvbiwgYW5kIG9wZXJhdGlvbnM8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5XaGVyZSBwb3NzaWJs
ZSwgdGhlIGdyb3VwIHdpbGwgc2VlayB0byBtYWtlIHVzZSBvZiB0b29scyB0byBndWlkZSBhbmQg
aW5mb3JtPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNz
IGluY2x1ZGluZyBmb3JtYWwgYW5hbHlzaXMsIGFyY2hpdGVjdHVyZSBkb2N1bWVudHMsPG86cD48
L286cD48L3ByZT4NCjxwcmU+YW5kIHVzZSBjYXNlIGRvY3VtZW50cy4gVGhlc2UgYXJ0aWZhY3Rz
IHdpbGwgbm90IGJlIGNvbnNpZGVyZWQgYXMgd29ya2luZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
Pmdyb3VwIG1pbGVzdG9uZXMgb3IgZGVsaXZlcmFibGVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY29v
cGVyYXRlIGFuZCBjb29yZGluYXRlIHdpdGggb3RoZXIgSUVURiBXR3Mgc3VjaCBhczxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPk9BVVRILCBhbmQgd29yayB3aXRoIGV4dGVybmFsIG9yZ2FuaXphdGlv
bnMsIHN1Y2ggYXMgdGhlIE9wZW5JRCBGb3VuZGF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PmFzIGFwcHJvcHJpYXRlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPk1pbGVzdG9uZXM6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IEp1bCAyMDIxIC0gQ29yZSBkZWxlZ2F0aW9uIHBy
b3RvY29sIGluIFdHTEM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsgT2N0IDIwMjEgLSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBi
aW5kaW5nIHRvIHRoZSBjb3JlIHByb3RvY29sLCBUTFMsIHRvPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7IFdHTEM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsgT2N0IDIwMjEgLSBLZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBi
aW5kaW5nIHRvIHRoZSBjb3JlIHByb3RvY29sLCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDsmbmJzcDtkZXRhY2hlZCBIVFRQIHNpZ25hdHVyZXMsIHRvIFdHTEM8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgT2N0IDIwMjEgLSBL
ZXkgcHJlc2VudGF0aW9uIG1lY2hhbmlzbSBiaW5kaW5nIHRvIHRoZSBjb3JlIHByb3RvY29sLDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBlbWJlZGRlZCBIVFRQIHNpZ25hdHVyZSwgdG8g
V0dMQzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOyBEZWMgMjAyMSAtIEd1aWRlbGluZXMgZm9yIHVzZSBvZiBwcm90b2NvbCBleHRlbnNp
b24gcG9pbnRzIHRvIFdHTEM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDsgRmViIDIwMjIgLSBHdWlkZWxpbmVzIG9uIG1pZ3JhdGlvbiBw
YXRocywgaW1wbGVtZW50YXRpb24sIGFuZCBvcGVyYXRpb25zIHRvPG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7Jm5ic3A7IFdHTEM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_3424311c60f541b197cfda6e9f3b494ecertorg_--


From nobody Mon Jul  6 20:32: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 0C8F03A09EF; Mon,  6 Jul 2020 20:32:30 -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_FILL_THIS_FORM_SHORT=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 qYyn_RQYNbLR; Mon,  6 Jul 2020 20:32:26 -0700 (PDT)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0: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 0A78B3A09F0; Mon,  6 Jul 2020 20:32:25 -0700 (PDT)
Received: by mail-oi1-x22e.google.com with SMTP id k6so29898933oij.11; Mon, 06 Jul 2020 20:32:25 -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=x/EMIjkOhSnM63+wW57fvH4IRHnAedDwvoZbvo4wl+g=; b=Xh5ssdkiGEAsA3W/OqtjWnsZdV2gu7rw+QthNyfkRmSl+SqkQ4ADfU/jyDMLuVM5/6 tc19s6kKTeKymlvAlAajogovv0dpJo1lsJwZioLRF+ON+fifyCmm2NlORrb9S9rHzWS1 U/Knl1IYnoluwNtqo8zaXmm0ciQlit1oeFppHrX6yGhoik2YuEtm57oYgWdJAB8q1NYL u+qkJ9tqzcLRE+owGmXmYNEQzOces0rkzr26G5Rdt3BSqQoFVLgcVKrL3Fx8Bm812B7Q kq82onzizkQU4w1LekAWfjNl+FplVS48imjI7uqXwDO4CnRpaj0L65Hb40nZGDYd76di MODQ==
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=x/EMIjkOhSnM63+wW57fvH4IRHnAedDwvoZbvo4wl+g=; b=nfPylb+6LQWGu8nK0me31Rh0mTluhQn3SRZndyeoBhPks9gwmkApJZi4BD0c5X/vQN c0Aj0rwM8DQdPhSTSYKAmadgQuB80cpK+Jfl5NOupHZeyualC/CH0Q2+hVWf6n3p8kaR NBuSL81r6RlAK6eE5timbx9Bxfl6u/ZzUsun/ggGjIlp5EVt1k1m+sZPo65aa403Lkky f0C5An4eCOpx6wYyoI9QQpHyp3WR7RHGCSdbKWjWboH3bHJb955txISOR7EW6vaMYeXU n9CJZhHHDcYZw0YigixAkynLIczeh14hR8JViTedXe+2W0pLYNdnBmdFTPP3++3Qbu3W 2Hww==
X-Gm-Message-State: AOAM5303gz/sCcPHg4Uqmku7safxqxqYUusSjpmrTD0rmiwlIb83flBN N3BfNiDFvlB8dpxhm3CdM7YIkE5trWN5jI63z7BkLQu+
X-Google-Smtp-Source: ABdhPJyCqW8z7Uw0utd5EgP6NYmoXYZdqqN9gg8SIykkdK2xXldoYr0SipxZ8Ns+wlScy9FFsZoEZ2ZYGh1Gc+tyB3A=
X-Received: by 2002:aca:4b50:: with SMTP id y77mr1801724oia.63.1594092744917;  Mon, 06 Jul 2020 20:32:24 -0700 (PDT)
MIME-Version: 1.0
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <7563640e-f515-3e73-a4eb-3902ec7af50e@free.fr> <3424311c60f541b197cfda6e9f3b494e@cert.org>
In-Reply-To: <3424311c60f541b197cfda6e9f3b494e@cert.org>
From: Tom Jones 
Date: Mon, 6 Jul 2020 20:32:12 -0700
Message-ID: 
To: Roman Danyliw 
Cc: Denis , "iesg@ietf.org" ,  "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000ccc5e705a9d1a390"
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 07 Jul 2020 03:32:30 -0000

--000000000000ccc5e705a9d1a390
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I guess I disagree with several of the assertions made by Denis, especially
the one about the AS knowing as little as possible about the requirement of
the client as it will be presented to the RS. That may be his use case, but
in mine the AS is tightly bound to the user and the ONLY means for the user
to get information about why the client wants or deserves access to the
resources. In the healthcare case, the client and the RS understand the
meaning of the data, the AS and the user have a limited understanding of
the data. The AS formulates the grant, which is in terms of the request for
access, which the AS needs to understand the request to present to the user
for approval. The AS creates a grant, which is not in terms of the claims
provided, but in terms of the requirements for access. Clearly the AS and
RS (and client) need a shared taxonomy of the request types. The AS does
not need to understand the presentation of access from the RS to the
client, but the AS does need full understanding of the request in terms the
user can comprehend.
Peace ..tom


On Mon, Jul 6, 2020 at 8:08 PM Roman Danyliw  wrote:

> Hi Denis!
>
>
>
> Thanks for the feedback and for repeating your review on the revised
> text.  More inline =E2=80=A6
>
>
>
> *From:* iesg  *On Behalf Of * Denis
> *Sent:* Monday, July 6, 2020 10:55 AM
> *To:* iesg@ietf.org
> *Cc:* txauth@ietf.org
> *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization
> Protocol (gnap)
>
>
>
> Since it is today the last day to send back comments, you will find
> hereafter my comments on the last charter version-05.
> charter-ietf-gnap-00-05
>
> This group is chartered to develop a fine-grained delegation protocol for=
 authorization, API access, user identifiers, and identity assertions.
>
>
>
> [Denis] Fine.
>
>
>
> The protocol will also allow the client to present unverified identifiers=
 and verifiable assertions to the AS as part of its request.
>
>
>
> [Denis] This sentence is too vague because "as part of its request" is no=
t explicit enough. If it means  "as part as an access token request"
>
> this should be explicitly said. If, it is not the case, then it should be=
 clearly explained. The AS should know as little as possible (including not=
hing)
>
> about what the client is doing.
>
>
>
> [Roman] The =E2=80=9Crequest=E2=80=9D here is the =E2=80=9Caccess token r=
equest=E2=80=9D.  That can be made clearer.
>
>
>
> This protocol will allow an authorizing party to delegate access to clien=
t software through an authorization server.
>
>
>
> [Denis] The word "*privacy*" is still missing in the charter. "Delegating=
 access to client software through an authorization server"
>
> is negating the fact that the user's privacy will ever be considered. IMH=
O, I believe that a RS may delegate some operation to another RS,
>
> but I don't believe that an AS should be concerned by any form of delegat=
ion, otherwise it would have the ability to act as "Big Brother".
>
> OAuth has not been constructed taking into consideration the user's priva=
cy. The major difference with it should be that GNAP has been
>
> constructed along "*privacy by design*" principles.
>
>
>
> [Roman]  I don=E2=80=99t exactly follow how considerations for privacy ar=
e being negated.  Above and beyond use-case specific considerations that wo=
uld be defined later, RFC6973 is the IETF consensus design guidance that wi=
ll guide the privacy threats and mitigations of the work.  What design guid=
ance would you recommend that the WG should consider that aren=E2=80=99t ca=
ptured in RFC6973?
>
>
>
> It will *expand* upon the uses cases currently supported by OAuth 2.0 and=
 OpenID Connect (itself an extension of OAuth 2.0) to support authorization=
s
>
> scoped as narrowly as a single transaction, provide a clear framework for=
 interaction among all parties involved in the protocol flow, and remove
>
> unnecessary dependence on a browser or user-agent for coordinating intera=
ctions.
>
>
>
> [Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. Some e=
xisting uses cases (i.e. "*non-expanded"* use cases) should be supported
>
> differently from OAuth 2.0 and OpenID Connect, in particular to support t=
he user's privacy.
>
>
>
> [Roman] I=E2=80=99d want to hear others on this rescoping.  Building upon=
 the use cases of OAuth 2.0 and OpenID Connect has been core, consensus-val=
idated tenant for some time now.
>
>
>
> The delegation process will be acted upon by multiple parties in the prot=
ocol, each performing a specific role. The protocol will decouple the chann=
els used
>
> by the protocol participants to communicate from the delegation channel, =
which happens directly between the client and the authorization server (in =
contrast
>
> with OAuth 2.0, which is initiated by the client redirecting the user=E2=
=80=99s browser).
>
>
>
> [Denis] Here again, the delegation process, if any, should be handled by =
RSs and not by ASs.
>
> The term "delegation channel" is being used but it is left undefined. It =
is not understandable.
>
>
>
> [Roman] This sentence was just added into -05 address Security AD feedbac=
k.  In this case, it was made to distinguish between in-band signaling and =
the new purpose-to-be-built channel.
>
>
>
> The protocol will include a means of specifying how the user can potentia=
lly be involved in an interactive fashion during the delegation process.
>
> The client and Authorization Server (AS) will use these interaction mecha=
nisms to involve the user, as necessary, to make authorization decisions.
>
>
>
> [Denis] Here again, the delegation process, if any, should be handled by =
RSs and not by ASs. The AS should know as little as possible (including not=
hing)
>
> about what the client is doing.
>
>
>
> [Roman] Understood =E2=80=93 as I understand it, you have concern with th=
e scope of the AS behavior.  I=E2=80=99d be interesting in hearing addition=
al support for this rescoping.
>
>
>
> This decoupling avoids many of the security concerns and technical challe=
nges of OAuth 2.0 and provides a non-invasive path for supporting future ty=
pes
>
> of clients and interaction channels.
>
>
>
> [Denis] This is not understandable to me. Is such a sentence really neede=
d in a charter ?
>
>
>
> [Roman] Can someone on the TxAuth mailing list remind us on why this sent=
ence is here?  With a fresh read, I also can=E2=80=99t remember why we need=
 it.
>
>
>
> The group will define interoperability for this protocol between differen=
t parties, including
>
> -          client and authorization server;
>
> -          client and resource server; and
>
>      -      authorization server and resource server.
>
>
>
> [Denis] In order to support the user's privacy, there should be no intera=
ction at all between an authorization server and a resource server
>
> *at the time of a client request*.
>
>
>
> The group will seek to minimize assumptions about the form of client appl=
ications, allowing for:
>
> -          Fine-grained specification of access
>
> -          Approval of AS attestation to identifiers and other identity c=
laims
>
> -          Approval of access to multiple resources and APIs in a single =
interaction
>
> -          Multiple access tokens in a single request and response
>
> -          AS-directed dispatch of access tokens to the appropriate RS
>
> [Denis] As-directed dispatch does not allow to support the user's privacy=
. However, RS-directed dispatch allows to support the user's privacy.
>
> It should be explicitly mentioned.
>
> [Roman] As above (per the AS vs. RS behavior)
>
> -          Separation between the party authorizing access and the party =
operating the client requesting access
>
>
>
> [Denis] It is questionable whether such a separation would be really bene=
ficial. In doubt, this item should be removed.
>
> [Roman] Could you say more on why this flexibility wouldn=E2=80=99t be wo=
rth it?
>
> The group will define extension points for this protocol to allow for fle=
xibility in areas including:
>
>
>
> Cryptographic agility for keys, message signatures, and proof of possessi=
on
>
> -          User interaction mechanisms including web and non-web methods
>
> -          Mechanisms for conveying user, software, organization, and oth=
er information used in authorization decisions
>
> -          Mechanisms for presenting tokens to resource servers and bindi=
ng resource requests to tokens and associated cryptographic keys
>
> Optimized inclusion of additional information (including identifiers and =
identity assertions) through the delegation process
>
>
>
> Additionally, the group will provide mechanisms for management of the pro=
tocol lifecycle including:
>
> -          Discovery of the authorization server
>
> -          Revocation of active tokens
>
> Data model for granted access and mechanisms for the AS and RS to communi=
cate the granted access model
>
>
>
> [Denis] While it is the duty for the RS to communicate the granted access=
 model to the client *at the appropriate instant of time*,
>
> the AS should be kept fully ignorant of it.
>
>
>
> Although the artifacts for this work are not intended or expected to be b=
ackwards-compatible with OAuth 2.0 or OpenID Connect,
>
> the group will attempt to simplify migrating from OAuth 2.0 and OpenID Co=
nnect to the new protocol where possible.
>
>
>
> This group is not chartered to develop extensions to OAuth 2.0, and as su=
ch will focus on new technological solutions not necessarily
>
> compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.=
0 will be directed to the OAuth Working Group, including
>
> functionality back-ported from the protocol developed here to OAuth 2.0.
>
>
>
> The group is chartered to develop mechanisms for applying cryptographic m=
ethods, such as JOSE and COSE, to the delegation process.
>
> This group is not chartered to develop new cryptographic methods.
>
>
>
> The group is chartered to develop mechanisms for conveying identity infor=
mation within the protocol including existing identifiers
>
> (such as email addresses, phone numbers, usernames, and subject identifie=
rs) and assertions (such as OpenID Connect ID Tokens,
>
> SAML Assertions, and Verifiable Credentials). The group is not chartered =
to develop new formats for identifiers or assertions, nor is the group
>
> chartered to develop schemas for user information, profiles, or other ide=
ntity attributes, unless a viable existing format is not available.
>
>
>
> The initial work will focus on using HTTPS for communication between the =
client and the authorization server, taking advantage
>
> of optimization features of HTTP/2 and HTTP/3 where possible, and will st=
rive to enable simple mapping to other protocols such as COAP
>
> when doing so does not conflict with the primary focus.
>
>
>
> Milestones to include:
>
> -          Core delegation protocol
>
> [Denis] Before defining a "Core delegation protocol", a simple client ser=
ver-protocol involving the presentation of several access tokens to one RS =
should be defined.
>
> Privacy principles should be applied when defining the protocol. Then aft=
er, a delegation mechanism allowing one RS to forward an operation to anoth=
er RS should be defined.
>
> -          Key presentation mechanism bindings to the core protocol inclu=
ding TLS, detached HTTP signature, and embedded HTTP signatures
>
> [Denis] Bindings to TLS are now deprecated, why should they be maintained=
 ?
>
> Signatures may be needed but they do not necessarily need to be "detached=
 HTTP signature, and embedded HTTP signatures".
>
> This item should be either removed or reworded.
>
> [Roman] Noted.  I=E2=80=99d want to hear others on this rescoping.
>
>
>
> -          Conveyance mechanisms for identifiers and assertions
>
> -          Guidelines for use of protocol extension points (if needed)
>
>      -    Guidelines on migration paths, implementation, and operations
>
> [Denis] The above three lines are rather mysterious.
>
> [Roman] The guidelines on migration paths came from the initial IESG
> review in order to have a named activity to action the design goal of =E2=
=80=9C=E2=80=A6
> the group will attempt to simplify migrating from OAuth 2.0 and OpenID
> Connect to the new protocol where possible=E2=80=9D a bit earlier in the =
text.
>
> Where possible, the group will seek to make use of tools to guide and
> inform the standardization process including formal analysis,
> architecture documents, and use case documents. These artifacts will not
> be considered as working group milestones or deliverables.
>
> The working group will cooperate and coordinate with other IETF WGs such
> as OAUTH, and work with external organizations,
> such as the OpenID Foundation, as appropriate.
>
> [Denis] The charter should be shorter.
>
>
>
> [Roman] Definitely.  Nevertheless, we have the current text through rough
> consensus process achieved from two BoFs and multiple mailing list
> consensus calls.
>
>
>
> Regards,
>
> Roman
>
>
>
> /Denis
>
>
>
> A new IETF WG has been proposed in the Security Area. The IESG has not ma=
de
>
> any determination yet. The following draft charter was submitted, and is
>
> provided for informational purposes only. Please send your comments to th=
e
>
> IESG mailing list (iesg@ietf.org) *by 2020-07-06*.
>
>
>
> Grant Negotiation and Authorization Protocol (gnap)
>
> -----------------------------------------------------------------------
>
> Current status: Proposed WG
>
>
>
> Chairs:
>
>   Yaron Sheffer  
>
>   Leif Johansson  
>
>
>
> Assigned Area Director:
>
>   Roman Danyliw  
>
>
>
> Security Area Directors:
>
>   Benjamin Kaduk  
>
>   Roman Danyliw  
>
>
>
> Mailing list:
>
>   Address: txauth@ietf.org
>
>   To subscribe: =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/txauth
>
>   Archive: https://mailarchive.ietf.org/arch/browse/txauth/
>
>
>
> Group page: https://datatracker.ietf.org/group/gnap/
>
>
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/
>
>
>
> This group is chartered to develop a fine-grained delegation protocol for
>
> authorization and API access, as well as requesting and providing user
>
> identifiers and claims. This protocol will allow an authorizing party to
>
> delegate access to client software through an authorization server. It wi=
ll
>
> expand upon the uses cases currently supported by OAuth 2.0 and OpenID Co=
nnect
>
> (itself an extension of OAuth 2.0) to support authorizations scoped as
>
> narrowly as a single transaction, provide a clear framework for interacti=
on
>
> among all parties involved in the protocol flow, and remove unnecessary
>
> dependence on a browser or user-agent for coordinating interactions.
>
>
>
> The delegation process will be acted upon by multiple parties in the prot=
ocol,
>
> each performing a specific role. The protocol will decouple the interacti=
on
>
> channels, such as the end user=E2=80=99s browser, from the delegation cha=
nnel, which
>
> happens directly between the client and the authorization server (in cont=
rast
>
> with OAuth 2.0, which is initiated by the client redirecting the user=E2=
=80=99s
>
> browser). The protocol will include a means of specifying how the user ca=
n
>
> potentially be involved in an interactive fashion during the delegation
>
> process. The client and Authorization Server (AS) will use these interact=
ion
>
> mechanisms to involve the user, as necessary, to make authorization decis=
ions.
>
> This decoupling avoids many of the security concerns and technical challe=
nges
>
> of OAuth 2.0 and provides a non-invasive path for supporting future types=
 of
>
> clients and interaction channels.
>
>
>
> The group will define interoperability for this protocol between differen=
t
>
> parties, including
>
>  - client and authorization server;
>
>  - client and resource server; and
>
>  - authorization server and resource server.
>
>
>
> The group will seek to minimize assumptions about the form of client
>
> applications, allowing for:
>
> - Fine-grained specification of access
>
> - Approval of AS attestation to identifiers and other identity claims
>
> - Approval of access to multiple resources and APIs in a single interacti=
on
>
> - Support for multiple access tokens in a single request and response
>
> - Support for directed, audience-restricted access tokens
>
> - Separation between the party authorizing access and the party operating=
 the
>
> client requesting access
>
>
>
> The group will define extension points for this protocol to allow for
>
> flexibility in areas including:
>
>
>
> - Cryptographic agility for keys, message signatures, and proof of posses=
sion
>
> - User interaction mechanisms including web and non-web methods
>
> - Mechanisms for conveying user, software, organization, and other
>
> information used in authorization decisions
>
> - Mechanisms for presenting tokens to resource servers and binding resour=
ce
>
> requests to tokens and associated cryptographic keys
>
> - Optimized inclusion of additional information (including identifiers an=
d
>
> identity assertions) through the delegation process
>
>
>
> Additionally, the group will provide mechanisms for management of the pro=
tocol
>
> lifecycle including:
>
>
>
> - Discovery of the authorization server
>
> - Revocation of active tokens
>
> - Mechanisms for the AS and RS to communicate the access granted by an ac=
cess
>
> token
>
>
>
> Although the artifacts for this work are not intended or expected to be
>
> backwards-compatible with OAuth 2.0 or OpenID Connect, the group will att=
empt
>
> to simplify migrating from OAuth 2.0 and OpenID Connect to the new protoc=
ol
>
> where possible.
>
>
>
> This group is not chartered to develop extensions to OAuth 2.0, and as su=
ch
>
> will focus on new technological solutions not necessarily compatible with
>
> OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be direct=
ed
>
> to the OAuth Working Group, including functionality back-ported from the
>
> protocol developed here to OAuth 2.0.
>
>
>
> The group is chartered to develop mechanisms for applying cryptographic
>
> methods, such as JOSE and COSE, to the delegation process. This group is =
not
>
> chartered to develop new cryptographic methods.
>
>
>
> The group is chartered to develop mechanisms for conveying identity
>
> information within the protocol including existing identifiers (such as e=
mail
>
> addresses, phone numbers, usernames, and subject identifiers) and asserti=
ons
>
> (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
>
> Credentials). The group is not chartered to develop new formats for
>
> identifiers or assertions, nor is the group chartered to develop schemas =
for
>
> user information, profiles, or other identity attributes, unless a viable
>
> existing format is not available.
>
>
>
> The initial work will focus on using HTTPS for communication between the
>
> client and the authorization server, taking advantage of optimization
>
> features of HTTP/2 and HTTP/3 where possible, and will strive to enable
>
> simple mapping to other protocols such as COAP when doing so does not
>
> conflict with the primary focus.
>
>
>
> Milestones to include:
>
> - Core delegation protocol
>
> - Key presentation mechanism bindings to the core protocol including TLS,
>
> detached HTTP signature, and embedded HTTP signatures
>
> - Conveyance mechanisms for identifiers and assertions
>
> - Guidelines for use of protocol extension points
>
> - (if needed) Guidelines on migration paths, implementation, and operatio=
ns
>
>
>
> Where possible, the group will seek to make use of tools to guide and inf=
orm
>
> the standardization process including formal analysis, architecture docum=
ents,
>
> and use case documents. These artifacts will not be considered as working
>
> group milestones or deliverables.
>
>
>
> The working group will cooperate and coordinate with other IETF WGs such =
as
>
> OAUTH, and work with external organizations, such as the OpenID Foundatio=
n,
>
> as appropriate.
>
>
>
> Milestones:
>
>
>
>   Jul 2021 - Core delegation protocol in WGLC
>
>
>
>   Oct 2021 - Key presentation mechanism binding to the core protocol, TLS=
, to
>
>   WGLC
>
>
>
>   Oct 2021 - Key presentation mechanism binding to the core protocol,
>
>   detached HTTP signatures, to WGLC
>
>
>
>   Oct 2021 - Key presentation mechanism binding to the core protocol,
>
>   embedded HTTP signature, to WGLC
>
>
>
>   Dec 2021 - Guidelines for use of protocol extension points to WGLC
>
>
>
>   Feb 2022 - Guidelines on migration paths, implementation, and operation=
s to
>
>    WGLC
>
>
>
>
>
>
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000ccc5e705a9d1a390
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I guess I disagree with several of the assertions made by =
Denis, especially the one about the AS knowing as little as possible about=
=C2=A0the requirement of the client as it will be presented to the=C2=A0RS.=
 That may be his use case, but in mine the AS is tightly bound to the user =
and the ONLY means for the user to get information about why the client wan=
ts or deserves=C2=A0access to the resources. In the healthcare case, the cl=
ient and the RS understand the meaning of the data, the AS and the user hav=
e a limited understanding of the data. The AS formulates the grant, which i=
s in terms of the request for access, which the AS needs to understand the =
request to present to the user for approval. The AS creates a grant, which =
is not in terms of the claims provided, but in terms of the requirements fo=
r access. Clearly the AS and RS (and client) need a shared taxonomy of the =
request types. The AS does not need to understand the presentation of acces=
s from the RS to the client, but the=C2=A0AS does need full understanding o=
f the request in terms the user can comprehend.
Peace ..tom




-- 

Txauth mailing list

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



--000000000000ccc5e705a9d1a390--


From nobody Mon Jul  6 20:42:03 2020
Return-Path: 
X-Original-To: txauth@ietf.org
Delivered-To: txauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD173A09F6; Mon,  6 Jul 2020 20:41:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Martin Duke via Datatracker 
To: "The IESG" 
Cc: gnap-chairs@ietf.org, txauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.7.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke 
Message-ID: <159409331733.9511.16331687866989311971@ietfa.amsl.com>
Date: Mon, 06 Jul 2020 20:41:57 -0700
Archived-At: 
Subject: [Txauth] Martin Duke's No Objection on charter-ietf-gnap-00-06: (with COMMENT)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jul 2020 03:41:58 -0000

Martin Duke has entered the following ballot position for
charter-ietf-gnap-00-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-gnap/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please expand ‘AS’ on first use.




From nobody Mon Jul  6 22:30: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 E54863A0859 for ; Mon,  6 Jul 2020 22:30:55 -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 rIurM5JShF93 for ; Mon,  6 Jul 2020 22:30:54 -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 1CE7C3A0853 for ; Mon,  6 Jul 2020 22:30:53 -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 0675Unxl018643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Jul 2020 01:30:51 -0400
Date: Mon, 6 Jul 2020 22:30:48 -0700
From: Benjamin Kaduk 
To: Dick Hardt 
Cc: Justin Richer , txauth@ietf.org
Message-ID: <20200707053048.GV16335@kduck.mit.edu>
References:    
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: 
Subject: Re: [Txauth] JSON Schema?
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, 07 Jul 2020 05:30:56 -0000

On Mon, Jul 06, 2020 at 01:16:27PM -0700, Dick Hardt wrote:
> Thanks Wayne and Justin.
> 
> I agree that we would not want to make it an implementation requirement.
> 
> I asked Tim Bray his thoughts (edited the IETF JSON specs, one of XML
> creators)
> 
> Tim has written a number of blog posts on JSON Schema. TL;DR: he is not a
> huge fan.
> 
> He pointed out the IETF JSON Type Definition ID [2]. This looks much
> simpler and addresses many of the concerns Tim had expressed with JSON
> Schema. It also has a more recent draft published on the IETF.

FWIW, draft-ucarion-json-type-definition is in the RFC Editor's queue as a
document published via the ISE stream, as can be seen at
https://www.rfc-editor.org/current_queue.php and
https://datatracker.ietf.org/doc/draft-ucarion-json-type-definition/

It's only been at the RFC Editor for a week or so, and we're running 10
weeks minimum to publication, it will not be an RFC for anouther couple
months at least.

-Ben

> Unfortunately there do not seem to be many implementations, and the website
> [3] is missing the promised docs [4]. The latest ID [5] looks to be derived
> from CDDL (RFC 8610) [6].
> 
> I reached out to the core JSON Schema people, and they are focussed on
> making JSON Schema changes to support efforts for the next version of Open
> API [7]
> 
> My take: I may use Open Schema in my PoC implementation not unlike what
> Wayne did, but it does not look like either JSON Schema or JSON Type
> Definition is ready for the WG to use at this point.
> 
> /Dick
> 
> [1]
> https://www.google.com/search?as_q=json+schema&hl=en&ie=UTF-8&btnG=Google%2BSearch&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=tbray.org
> 
> 
> [2] https://datatracker.ietf.org/doc/draft-ucarion-json-type-definition/
> 
> [3] https://jsontypedef.com/
> 
> [4] https://jsontypedef.com/docs/getting-started/overview
> 
> [5] https://tools.ietf.org/html/draft-ucarion-json-type-definition-04
> 
> [6] https://tools.ietf.org/html/rfc8610
> 
> [7] https://github.com/OAI/OpenAPI-Specification
> 
> 
> On Mon, Jul 6, 2020 at 12:55 PM Justin Richer  wrote:
> 
> >
> > On Jul 6, 2020, at 3:54 PM, Justin Richer  wrote:
> >
> > I think it’s potentially ok for defining the specification and its
> > boundaries, but it is not ok if it ends up requiring client and AS
> > developers to use JSON Schema directly to implement anything. In other
> > words, you should be a able to still write a bunch of hand-crafted
> > validation code to make it work, or to use a parser that drops things into
> > structured objects for you (like my Java implementation of XYZ does). Much
> > like my argument against JSONLD, I think anything beyond a JSON parser
> >
> >
> > … and generator is too much to ask. (Sorry, hit send too early.)
> >
> >
> > Another aspect that I don’t like about JSON schema is that it makes it
> > difficult to describe things in terms of polymorphic data types.
> > Polymorphism in the protocol is an important part of the XYZ proposal’s
> > design, and as a feature it directly addresses a number of the items you
> > found when doing your XAuth implementation, like parsing OAuth scopes and
> > dealing with the authorization/authorizations mutually-exclusive oddness
> > that you mentioned. I strongly believe that GNAP should make use of a
> > polymorphic protocol structure for these and other reasons. Polymorphism is
> > a built-in feature of the JSON data model, and it’s also fully possible to
> > support under CBOR and other data serialization languages. Even JWT most
> > famously uses polymorphism for the “aud” field, which can be a string or an
> > array of strings depending on context, all with clear semantics. Defining
> > that in JSON schema is not impossible, but it’s not easy.
> >
> > So overall, I think JSON schema is probably not a good fit here.
> >
> >  — Justin
> >
> > On Jul 6, 2020, at 3:00 PM, Dick Hardt  wrote:
> >
> > Hey
> >
> > Does anyone have experience and/or opinions on JSON Schema [1]?
> >
> > When implementing XAuth [2], I wrote a bunch of hand crafted JSON
> > validation code. JSON schema looks like it could be a great way to validate
> > input, and to create automated tests for output. It may also be a great way
> > to document the Grant Response JSON.
> >
> > / Dick
> >
> > [1] https://json-schema.org/
> > [2] https://github.com/dickhardt/XAuth-poc
> >
> >
> > --
> > Txauth mailing 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


From nobody Tue Jul  7 03:40: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 E36533A0A97 for ; Tue,  7 Jul 2020 03:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 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] 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 E5rMRdocuRQA for ; Tue,  7 Jul 2020 03:40:50 -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 7C32B3A0A94 for ; Tue,  7 Jul 2020 03:40:50 -0700 (PDT)
Received: from [192.168.1.7] (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 067Aelrt022165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Jul 2020 06:40:48 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Justin Richer 
In-Reply-To: 
Date: Tue, 7 Jul 2020 06:40:47 -0400
Cc: txauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>
References:   
To: Dick Hardt 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 07 Jul 2020 10:40:52 -0000

I wanted to respond to this comment more fully:

> wrt. my authorization / authorizations oddness, polymorphism would not =
solve it as the contents of both authorization / authorizations in XAuth =
are objects.=20

It=E2=80=99s not surprising that this is the case, as the XAuth protocol =
was not designed with polymorphism as a tool to consider. This is =
exactly the reason that I say we should have polymorphism in the toolbox =
from the start, as it allows us to avoid this kind of awkwardness in =
many cases.

The equivalent =E2=80=9Cresources=E2=80=9D structure in XYZ uses an =
array to convey the scope strings and the rich request objects at the =
same level. This allows the protocol to have one construct, the =
=E2=80=9Cresources=E2=80=9D array, that contains items that describe =
what rights the client is requesting in the resulting access token. An =
array of items is the natural representation of such a construct in a =
JSON-based protocol.

The reason for this design is a simple adaptation of OAuth 2. The native =
data structure underlying the OAuth 2 =E2=80=9Cscope=E2=80=9D parameter =
is a set, but OAuth 2 had to invent a standard serialization for it (the =
space-separated single string) in order to convey it across the front =
channel as a query parameter. I remember we=E2=80=99d considered making =
it an array in the token endpoint response, but ultimately decided to =
keep it consistent with the lowest-common-denominator representation, =
which makes sense. However, we aren=E2=80=99t bound to that limitation =
of OAuth 2 anymore and so there is no reason to keep the =
space-separated-string notion around. At the very least, scopes should =
be a native JSON array of strings. RAR uses a JSON array of objects =
natively, but encodes it as a URL-encoded string in order to fit into =
OAuth 2=E2=80=99s front channel and token endpoint push. Should we also =
keep the encoding part of RAR if we keep the space-separated-string =
encoding of scope from OAuth 2? It certainly seems silly to argue for =
that, and  would argue that we need neither string-based encoding and we =
can use native structures for both.

Since GNAP is also allowing fine-grained requests as well as the more =
course-grained scope style access, we can also put them together. This =
would allow us to have a single array of elements, each element being =
either a single string or an object with multiple dimensions.=20

Now: while this is an example of the benefits of polymorphism at the =
protocol level, how does this help the authorization/authorizations =
conundrum above? In XYZ, a single access token request is an array of =
=E2=80=9Cresource=E2=80=9D elements, but a multiple access token request =
is an object/map, whose values are the same =E2=80=9Cresource=E2=80=9D =
arrays as a single request. This makes the requests much more consistent =
to create and parse than having two closely-named and mutually-exclusive =
properties.=20

This isn=E2=80=99t a magic panacea though, and it requires a bit of work =
to apply the tools well. When I added multiple access tokens to XYZ, I =
didn=E2=80=99t want to change the format of the single access token, =
which was already an object. The natural response type of the multiple =
access tokens was also an object, and so we ended up with =E2=80=94 you =
guessed it =E2=80=94 a pair of closely-named and mutually-exclusive =
properties. I don=E2=80=99t like it, and I think there=E2=80=99s likely =
a better way around this, but I haven=E2=80=99t gone back to try and =
design that problem out yet. But it=E2=80=99s something that I think we =
can likely address in GNAP, especially if we=E2=80=99re willing to step =
back and change how we look at things.

 =E2=80=94 Justin=


From nobody Tue Jul  7 05:26: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 2A89D3A0C17 for ; Tue,  7 Jul 2020 05:26:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level: 
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 dBpT9TruWbTb for ; Tue,  7 Jul 2020 05:26:27 -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 DF9A13A0C12 for ; Tue,  7 Jul 2020 05:26:25 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d40 with ME id 0CSM2300A4FMSmm03CSNSN; Tue, 07 Jul 2020 14:26:24 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 07 Jul 2020 14:26:24 +0200
X-ME-IP: 86.238.65.197
To: Justin Richer 
Cc: Dick Hardt , "rdd@cert.org" , "txauth@ietf.org" , The IESG 
References: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>   <46705E7E-D657-4CF1-80DA-0ADDFD6D8B41@mit.edu>
From: Denis 
Message-ID: <85b03911-d1c6-127f-2480-bfab4b94ffe2@free.fr>
Date: Tue, 7 Jul 2020 14:26: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: <46705E7E-D657-4CF1-80DA-0ADDFD6D8B41@mit.edu>
Content-Type: multipart/alternative; boundary="------------3619D94840491F1ABB5FEDD1"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Support of FIDO and data minimization by RSs
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, 07 Jul 2020 12:26:29 -0000

This is a multi-part message in MIME format.
--------------3619D94840491F1ABB5FEDD1
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Justin,

> I think removing the opacity of access tokens to clients is going to 
> be a non-starter for most of this community.

Token opacity is considered as a dogma in OAuth 2.0. More explanations 
why access tokens should not be opaque in GNAP.

Token introspection mandates a dialogue from the RS to the AS which 
allows the AS to know which RS
got a given access token. So token introspection allows the AS to trace 
the client. This should be avoided.
Using NON-OPAQUE access tokens solves the issue both for the RSs and for 
the clients. This means that
access tokens used for GNAP shall include a version number or a format 
identifier.

Applying a "security by design" approach leads to specific design 
requirements. The key question is whether
this BoF prefers a "Privacy by design" approach or /implicitly /a "Big 
Brother by design" approach.

Denis

>
>  — Justin
>
>> On Jul 6, 2020, at 3:17 PM, Denis > > wrote:
>>
>> Hi Dick,
>>
>> Congratulations ! You made a good guess (but the guess was easy): my 
>> approach is indeed privacy related.
>>
>> _Note_: Since it is close to the end of the day in my time zone (and 
>> since it is the last day for comments to the charter),
>> I copy both the IESG and Roman so that they can know that GNAP should 
>> also consider a*bridge with FIDO*.
>>
>> I have several goals:
>>
>>     1 - make a bridge with FIDO U2F (I will illustrate this with a
>>     specific scenario).
>>
>>     2 - prevent every AS to know which RSs are going to be accessed
>>     or which kind of operation the client will be doing.
>>         This is to prevent an AS to act as "Big Brother".
>>
>>     3 - apply both "privacy by default" and "data minimization" (when
>>     the user authenticates it may authenticate using FIDO or
>>          by presenting one or more access tokens. Then after, the
>>     necessary attributes that are necessary to perform a given operation
>>         are only requested and released at the time they are indeed
>>     needed to perform the given operation (i.e. they are not released
>>         when the user logs on).
>>
>>     4 - the proposed RS Authorization algorithm allows a great
>>     flexibility, in particular it supports FIDO and different attributes
>>          from different ASs may be requested by the RS.
>>
>>     5 - the rules associated with the RS Authorization algorithm are
>>     making these rules only available at the time the client indicates
>>          which operation it is willing to perform (i.e. by default,
>>     they are not public).
>>
>>     6 - access tokens are NOT OPAQUE to the clients so that every
>>     client can make sure that their content reflects what has been
>>     requested.
>>
>> *A simple scenario to illustrate*
>>
>> A student wants to apply for a new university. He connects to the RS 
>> of the University. He first creates an account using FIDO.
>> He then selects the button "Preliminary information for applying to 
>> the university". He is asked to enter two categories of information:
>>
>>       * citizenship information and
>>       * prior graduations.
>>
>> The student can interrupt the preliminary registration procedure at 
>> any time and continue it at any time later on.
>>
>> When the student is finished, it selects the button "Application to 
>> the university".
>>
>>     The university RS "reads" the citizen ship of the student and let
>>     know to the student whether a paper form
>>     and/or an electronic form of the identity of the student may be
>>     provided. Let us assume the later case and that
>>     the student is a citizen from France. Then the university RS
>>     indicates which French banks or other French organisations
>>     are trusted to provide an access token. The client checks whether
>>     this list fits one of the AS with which it has a relationship.
>>
>>     The university RS "reads" the prior graduations of the student
>>     and then let know to the student whether a paper form
>>     and/or an electronic form of the last graduation of the student
>>     may be provided. Let us assume the later case and
>>     that the student is from Yale University. Then the university
>>     indicates the address of the AS from Yale University.
>>     If the student is indeed from Yale University, he should be able
>>     to provide the requested access token.
>>
>> Such scenario which follows some privacy principles cannot be 
>> constructed "/after the design"/ (it will not happen by magic or by 
>> accident)
>> This is why the approach is called "privacy by design".
>>
>> Denis
>>
>>> Hi Denis
>>>
>>> Would you provide some background on what you are trying to solve 
>>> with this? I'm guessing it is privacy related.
>>>
>>> Perhaps a use case would help make it more concrete?
>>>
>>> /Dick
>>>
>>>
>>> On Mon, Jul 6, 2020 at 5:39 AM Denis >> > wrote:
>>>
>>>     **eThis is a new thread: a proposal for a RS authorization
>>>     algorithmand a way to support FIDO by RSs
>>>
>>>     In order to support the privacy principle of "data minimization"
>>>     by RSs, only the attributes that are strictly necessary to perform
>>>     an operation requested by a client should be requested by the RS.
>>>
>>>     When a client wants to authenticate, it will usually be informed
>>>     by the RS on how to do it (see more details about two exceptions
>>>     at the end of this email).
>>>     Which conditions are needed to perform other operations will
>>>     only be disclosed to authenticated users at the time they are
>>>     willing to perform an operation.
>>>
>>>     Two categories of operations will be considered: authentication
>>>     operations and other operations.
>>>
>>>     For the "authentication" operation, two cases will be supported:
>>>
>>>     -FIDO U2F or
>>>
>>>     -one or more attributes from one or more ASs.
>>>
>>>     In the second case, an access will be granted by a RS based on
>>>     an mathematical expression which is formed using some
>>>     combination of ANDand ORconditions.
>>>
>>>     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 /a Condition /:
>>>
>>>     /Condition x/= { AS identifier + set of attributes types +
>>>     optional scope identifier }
>>>
>>>     The presence of the /optional/ scope identifier allows to
>>>     provide a backward compatibility with ASs from the OAuth 2.0.
>>>     world:
>>>     the optional scope identifier is only present when a bilateral
>>>     relationship has been established between a RS and an AS prior
>>>     to any access (/and will continue to be maintained/) using
>>>     "out-of-bands" means.
>>>
>>>     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.
>>>
>>>     An example is used to explain the concepts.
>>>
>>>     "Operation(s)/ Mathematical expression" pairs managed by the RO
>>>     of a RS.
>>>
>>>     *Operation*
>>>
>>>     	
>>>
>>>     *Mathematical expression*
>>>
>>>     Authentication
>>>
>>>     	
>>>
>>>     /Condition 1/OR/Condition 2/
>>>
>>>     Operation A OROperation Z
>>>
>>>     	
>>>
>>>     /Condition 3/AND/Condition 4/
>>>
>>>     Conditions table:
>>>
>>>     Condition 1
>>>
>>>     	
>>>
>>>     FIDO U2F 1.2
>>>
>>>     	
>>>
>>>     -
>>>
>>>     	
>>>
>>>     -
>>>
>>>     Condition 2
>>>
>>>     	
>>>
>>>     AS 1
>>>
>>>     	
>>>
>>>     set 1 of attributes types
>>>
>>>     	
>>>
>>>     Condition 3
>>>
>>>     	
>>>
>>>     AS 4
>>>
>>>     	
>>>
>>>     set 2 of attributes types
>>>
>>>     	
>>>
>>>     scope identifier : 21
>>>
>>>     Condition 4
>>>
>>>     	
>>>
>>>     AS 9
>>>
>>>     	
>>>
>>>     set 3 of attributes types
>>>
>>>     	
>>>
>>>     -
>>>
>>>     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 the set of attributes types which are indicated for a
>>>     given AS
>>>     are appropriate to him or not and then select that AS if it has
>>>     a relationship with it.
>>>
>>>     In this example, one mathematical expression for the combination
>>>     of conditions using AND and OR operators is "/Condition
>>>     3/OR/Condition 4",//
>>>     which means that///some types of attributes from AS 4 AND some
>>>     other types of attributes from AS 9 are both needed by RSx to
>>>     perform on RSx
>>>     either the Operation A or the Operation Z.
>>>
>>>     In this example, RS 1 and AS 4 have established a bilateral
>>>     relationship (and have agreed to define and use scope identifiers)
>>>     whereas RS 1 and AS 9 have not established any bilateral
>>>     relationship prior to the exchange.
>>>
>>>     The user makes up his mind whether the attributes requested by
>>>     AS 1 and AS 9 are reasonable and if so, requests two access tokens:
>>>     one to AS 4 and another one to AS 9.
>>>
>>>     For AS 4, the client shall use the scope identifier with the
>>>     value 21.
>>>     For AS 9, the client shall use the set 3 of attributes types
>>>     indicated in the Condition 4.
>>>
>>>     In order to save one exchange, a RS could publicly publish how
>>>     its clients can authenticate.
>>>     However,  it is also possible to consider no guidance at all: in
>>>     such a case, using "out-of-bands" means, the clients should know
>>>     how to authenticate.
>>>
>>>     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
>


--------------3619D94840491F1ABB5FEDD1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Justin,

    


    

    

      
      I think removing the opacity of access tokens to clients is going
      to be a non-starter for most of this community. 

    

    
Token opacity is considered as a dogma in OAuth 2.0. More
      explanations why access tokens should not be opaque in GNAP.

    

    
Token introspection mandates a dialogue from the RS to the AS
      which allows the AS to know which RS 

      got a given access token. So token introspection allows the AS to
      trace the client. This should be avoided.

      Using NON-OPAQUE access tokens solves the issue both for the RSs
      and for the clients. This means that 

      access tokens used for GNAP shall include a version number or a
      format identifier.

    

    
Applying a "security by design" approach leads to specific design
      requirements. The key question is whether 

      this BoF prefers a "Privacy by design" approach or implicitly
      a "Big Brother by design" approach.

    

    
Denis

    

      


      

      
 — Justin

        


          

            
On Jul 6, 2020, at 3:17 PM, Denis <denis.ietf@free.fr> wrote:

            

            

              
              

                
Hi Dick,

                


                

                
Congratulations ! You made
                  a good guess (but the guess was easy): my approach is
                  indeed privacy related.

                


                

                
Note: Since
                  it is close to the end of the day in my time zone (and
                  since it is the last day for comments to the charter),
                  

                  I copy both the IESG and Roman so that they can know
                  that GNAP should also consider a bridge
                    with FIDO.

                

                
I have several goals:

                

                  
1 - make a bridge with
                    FIDO U2F (I will illustrate this with a specific
                    scenario).

                  


                  

                  
2 - prevent every AS to
                    know which RSs are going to be accessed or which
                    kind of operation the client will be doing.

                        This is to prevent an AS to act as "Big
                    Brother".

                  

                  


                  

                  
3 - apply both "privacy
                    by default" and "data minimization" (when the user
                    authenticates it may authenticate using FIDO or 

                         by presenting one or more access tokens. Then
                    after, the necessary attributes that are necessary
                    to perform a given operation 

                        are only requested and released at the time they
                    are indeed needed to perform the given operation
                    (i.e. they are not released 

                        when the user logs on).

                  


                  

                  
4 - the proposed RS
                    Authorization algorithm allows a great flexibility,
                    in particular it supports FIDO and different
                    attributes 

                         from different ASs may be requested by the RS.

                  


                  

                  
5 - the rules associated
                    with the RS Authorization algorithm are making these
                    rules only available at the time the client
                    indicates 

                         which operation it is willing to perform (i.e.
                    by default, they are not public).

                  


                  

                  
6 - access tokens are NOT
                    OPAQUE to the clients so that every client can make
                    sure that their content reflects what has been
                    requested.

                  

                

                
 A simple
                    scenario to illustrate

                

                


                

                
A student wants to apply
                  for a new university. He connects to the RS of the
                  University. He first creates an account using FIDO.

                  He then selects the button "Preliminary information
                  for applying to the university". He is asked to enter
                  two categories of information:

                

                  
    
                    
  • citizenship information and 
    • 
                    
  • prior graduations.
    • 
                  

                

                
The student can interrupt
                  the preliminary registration procedure at any time and
                  continue it at any time later on.

                


                

                
When the student is
                  finished, it selects the button "Application to the
                  university".

                

                

                  
The university RS "reads"
                    the citizen ship of the student and let know to the
                    student whether a paper form 

                    and/or an electronic form of the identity of the
                    student may be provided. Let us assume the later
                    case and that 

                    the student is a citizen from France. Then the
                    university RS indicates which French banks or other
                    French organisations 

                    are trusted to provide an access token. The client
                    checks whether this list fits one of the AS with
                    which it has a relationship.

                  

                  


                  

                  The university RS "reads" the prior graduations of the
                  student and then let know to the student whether a
                  paper form 

                  and/or an electronic form of the last graduation of
                  the student may be provided. Let us assume the later
                  case and 

                  that the student is from Yale University. Then the
                  university indicates the address of the AS from Yale
                  University.

                  If the student is indeed from Yale University, he
                  should be able to provide the requested access token.

                

                
Such scenario which follows some privacy
                  principles cannot be constructed "after
                    the design" (it will not happen by magic or by
                  accident)

                  This is why the approach is called "privacy by
                  design".

                
Denis

                

                

                  
Hi Denis
                    


                    

                    
Would you provide some background on
                      what you are trying to solve with this? I'm
                      guessing it is privacy related. 

                    


                    

                    
Perhaps a use case would help make it
                      more concrete?

                    


                    

                    
/Dick

                    


                    

                  

                  

                  

                    
On Mon, Jul 6,
                      2020 at 5:39 AM Denis <denis.ietf@free.fr>
                      wrote:

                    

                    

                      

                        
 eThis is a new thread: a
                            proposal for a RS authorization algorithm and a way to support FIDO by
                            RSs

                          

                        
In order to support the privacy
                            principle of "data minimization" by RSs,
                            only the attributes that are strictly
                            necessary to perform 

                            an operation requested by a client should be
                            requested by the RS.

                        
When a client wants to
                            authenticate, it will usually be informed by
                            the RS on how to do it (see more details
                            about two exceptions at the end of this
                            email). 

                            Which conditions are needed to perform other
                            operations will only be disclosed to
                            authenticated users at the time they are
                            willing to perform an operation.

                        
Two categories of operations
                            will be considered: authentication
                            operations and other operations.

                          

                        
 For the "authentication"
                            operation, two cases will be supported: 

                        
-         
                            FIDO U2F or 

                        
-         
                            one or more attributes from one
                            or more ASs. 

                        
In the second case, 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 a Condition :

                        
Condition x = { AS identifier + set of
                            attributes types + optional scope identifier
                            } 

                          

                        
The presence of the optional scope identifier
                            allows to provide a backward compatibility
                            with ASs from the OAuth 2.0. world: 

                            the optional scope identifier is only
                            present when a bilateral relationship has
                            been established between a RS and an AS
                            prior 

                            to any access (and will continue
                              to be maintained) using "out-of-bands"
                            means. 

                          

                        
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.

                        
An example is used to explain
                            the concepts.

                        
"Operation(s)/ Mathematical
                            expression" pairs managed by the RO of a RS.
                            

                          

                        

                          
                            

                              
                                
Operation

                              		
                              
                                
Mathematical
                                      expression

                              		
                            

                            

                              
                                
Authentication

                              		
                              
                                
Condition 1 OR Condition
                                      2

                              		
                            

                            

                              
                                
Operation A OR
                                      Operation Z

                              		
                              
                                
Condition 3 AND Condition
                                      4

                              		
                            

                          
                        

                        
Conditions table: 

                        

                          
                            

                              
                                
Condition 1

                              		
                              
                                
FIDO
                                    U2F 1.2

                              		
                              
                                
-

                              		
                              
                                
-

                              		
                            

                            

                              
                                
Condition 2

                              		
                              
                                
AS 1

                              		
                              
                                
set 1 of attributes
                                    types

                              		
                              
                                
 

                                

                              		
                            

                            

                              
                                
Condition 3

                              		
                              
                                
AS 4

                              		
                              
                                
set 2 of attributes
                                    types

                              		
                              
                                
scope identifier : 21

                              		
                            

                            

                              
                                
Condition 4

                              		
                              
                                
AS 9

                              		
                              
                                
set 3 of attributes
                                    types

                              		
                              
                                
-

                              		
                            

                          
                        

                        
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 the set of attributes types
                            which are indicated for a given AS 

                            are appropriate to him or not and then
                            select that AS if it has a relationship with
                            it.

                        
In this example, one
                            mathematical expression for the combination
                            of conditions using AND and OR operators is
                            "Condition
                                3 OR Condition
                                4", 

                                which means that
                            some types of attributes from AS 4 AND
                            some other types of attributes from AS 9 are
                            both needed by RSx to perform on RSx 

                            either the Operation A or the Operation Z. 

                        
In this example, RS 1 and AS 4
                            have established a bilateral relationship
                            (and have agreed to define and use scope
                            identifiers) 

                            whereas RS 1 and AS 9 have not established
                            any bilateral relationship prior to the
                            exchange. 

                          

                        
The user makes up his mind
                            whether the attributes requested by AS 1 and
                            AS 9 are reasonable and if so, requests two
                            access tokens: 

                            one to AS 4 and another one to AS 9.

                        
For AS 4, the
                            client shall use the scope identifier with
                            the value 21.

                            For AS 9, the client shall use the set 3 of
                            attributes types indicated in the Condition
                            4.

                        
In order to save one exchange,
                            a RS could publicly publish how its clients
                            can authenticate. 

                            However,  it is also possible to consider no
                            guidance at all: in such a case, using
                            "out-of-bands" means, the clients should
                            know how to authenticate.

                        
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

            

          

        

        

      

    

    


    

  


--------------3619D94840491F1ABB5FEDD1--


From nobody Tue Jul  7 05:43: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 7633E3A0C39 for ; Tue,  7 Jul 2020 05:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level: 
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=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 8dIPzUQ6OuKu for ; Tue,  7 Jul 2020 05:43:07 -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 6C8F23A0C1F for ; Tue,  7 Jul 2020 05:43:06 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d40 with ME id 0Cj32300J4FMSmm03Cj4Hc; Tue, 07 Jul 2020 14:43:04 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 07 Jul 2020 14:43:04 +0200
X-ME-IP: 86.238.65.197
To: Roman Danyliw , "iesg@ietf.org" 
Cc: "txauth@ietf.org" 
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <7563640e-f515-3e73-a4eb-3902ec7af50e@free.fr> <3424311c60f541b197cfda6e9f3b494e@cert.org>
From: Denis 
Message-ID: <36de4e6a-41fe-81b1-6c92-69fe5b63ad6f@free.fr>
Date: Tue, 7 Jul 2020 14:43: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: <3424311c60f541b197cfda6e9f3b494e@cert.org>
Content-Type: multipart/alternative; boundary="------------BF63B7896775EBF5D8C2E7AC"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 07 Jul 2020 12:43:11 -0000

This is a multi-part message in MIME format.
--------------BF63B7896775EBF5D8C2E7AC
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Roman,
>
> Hi Denis!
>
> Thanks for the feedback and for repeating your review on the revised 
> text.  More inline …
>
> *From:* iesg  *On Behalf Of * Denis
> *Sent:* Monday, July 6, 2020 10:55 AM
> *To:* iesg@ietf.org
> *Cc:* txauth@ietf.org
> *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization 
> Protocol (gnap)
>
> Since it is today the last day to send back comments, you will find 
> hereafter my comments on the last charter version-05.
>
BTW, I sent an email yesterday evening with the subject: *Support of 
FIDO* and data minimization by RSs, where I indicated that the charter 
should
mention FIDO U2F so that it should be possible to logon to a RS using 
either FIDO or by presenting one (or more) access tokens from one (or 
more) AS.

The original email is here : 
https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/

>
>     charter-ietf-gnap-00-05
>
> This group is chartered to develop a fine-grained delegation protocol 
> for authorization, API access, user identifiers, and identity assertions.
> [Denis] Fine.
> The protocol will also allow the client to present unverified 
> identifiers and verifiable assertions to the AS as part of its request.
> [Denis] This sentence is too vague because "as part of its request" is 
> not explicit enough. If it means  "as part as an access token request"
> this should be explicitly said. If, it is not the case, then it should 
> be clearly explained. The AS should know as little as possible 
> (including nothing)
> about what the client is doing.
> [Roman] The “request” here is the “access token request”.  That can be 
> made clearer.

This would be appreciated.

> This protocol will allow an authorizing party to delegate access to 
> client software through an authorization server.
> [Denis] The word "*privacy*" is still missing in the charter. 
> "Delegating access to client software through an authorization server"
> is negating the fact that the user's privacy will ever be considered. 
> IMHO, I believe that a RS may delegate some operation to another RS,
> but I don't believe that an AS should be concerned by any form of 
> delegation, otherwise it would have the ability to act as "Big Brother".
> OAuth has not been constructed taking into consideration the user's 
> privacy. The major difference with it should be that GNAP has been
> constructed along "*privacy by design*" principles.
> [Roman]  I don’t exactly follow how considerations for privacy are 
> being negated.  Above and beyond use-case specific considerations that 
> would be defined later, RFC6973 is the IETF consensus design guidance 
> that will guide the privacy threats and mitigations of the work.  What 
> design guidance would you recommend that the WG should consider that 
> aren’t captured in RFC6973?

I believe my message is quite clear : If the AS is handling the 
delegation process, it will know what the client is doing or where it is 
going.
On the contrary, if the RS is handling the delegation process, the AS 
will be unable to know what the client is doing. In addition, an AS-centric
architecture would not be scalable and would need a lot of 
synchronizations between ASs and RSs. The user consent should be handled 
by the RS
and not by the AS. When a RS is unable to provide the service, it is 
best placed to tell directly to the client what it could do next.

RFC 6973 is very good document. Section 7.1 states:

           b.  Data.  What information does the protocol expose about 
individuals, their devices, and/or their device usage (other than the 
identifiers discussed in (a))?

Data includes both the operation and the data associated with the 
operation. An AS should be kept ignorant of both the operation and the 
data associated with the operation.

    c.  Observers.  (...) Are there ways for protocol implementers to 
    choose to limit the information shared with each entity?

If theses guidances were followed, the proposed architecture would not 
be AS-centric.

> It will *expand* upon the uses cases currently supported by OAuth 2.0 
> and OpenID Connect (itself an extension of OAuth 2.0) to support 
> authorizations
> scoped as narrowly as a single transaction, provide a clear framework 
> for interaction among all parties involved in the protocol flow, and 
> remove
> unnecessary dependence on a browser or user-agent for coordinating 
> interactions.
> [Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. 
> Some existing uses cases (i.e. "*non-expanded"* use cases) should be 
> supported
> differently from OAuth 2.0 and OpenID Connect, in particular to 
> support the user's privacy.
> [Roman] I’d want to hear others on this rescoping.  Building upon the 
> use cases of OAuth 2.0 and OpenID Connect has been core, 
> consensus-validated tenant for some time now.
> The delegation process will be acted upon by multiple parties in the 
> protocol, each performing a specific role. The protocol will decouple 
> the channels used
> by the protocol participants to communicate from the delegation 
> channel, which happens directly between the client and the 
> authorization server (in contrast
> with OAuth 2.0, which is initiated by the client redirecting the 
> user’s browser).
> [Denis] Here again, the delegation process, if any, should be handled 
> by RSs and not by ASs.
> The term "delegation channel" is being used but it is left undefined. 
> It is not understandable.
> [Roman] This sentence was just added into -05 address Security AD 
> feedback.  In this case, it was made to distinguish between in-band 
> signaling and the new purpose-to-be-built channel.

Since delegation should not be handled by the AS, a delegation channel 
should not exist.

> The protocol will include a means of specifying how the user can 
> potentially be involved in an interactive fashion during the 
> delegation process.
> The client and Authorization Server (AS) will use these interaction 
> mechanisms to involve the user, as necessary, to make authorization 
> decisions.
> [Denis] Here again, the delegation process, if any, should be handled 
> by RSs and not by ASs. The AS should know as little as possible 
> (including nothing)
> about what the client is doing.
> [Roman] Understood – as I understand it, you have concern with the 
> scope of the AS behavior.  I’d be interesting in hearing additional 
> support for this rescoping.
> This decoupling avoids many of the security concerns and technical 
> challenges of OAuth 2.0 and provides a non-invasive path for 
> supporting future types
> of clients and interaction channels.
> [Denis] This is not understandable to me. Is such a sentence really 
> needed in a charter ?
> [Roman] Can someone on the TxAuth mailing list remind us on why this 
> sentence is here?  With a fresh read, I also can’t remember why we 
> need it.
> The group will define interoperability for this protocol between 
> different parties, including
> -client and authorization server;
> -client and resource server; and
>      -      authorization server and resource server.
> [Denis] In order to support the user's privacy, there should be no 
> interaction at all between an authorization server and a resource server
> /at the time of a client request/.
> The group will seek to minimize assumptions about the form of client 
> applications, allowing for:
> -Fine-grained specification of access
> -Approval of AS attestation to identifiers and other identity claims
> -Approval of access to multiple resources and APIs in a single interaction
> -Multiple access tokens in a single request and response
> -AS-directed dispatch of access tokens to the appropriate RS
> [Denis] As-directed dispatch does not allow to support the user's 
> privacy. However, RS-directed dispatch allows to support the user's 
> privacy.
> It should be explicitly mentioned.
> [Roman] As above (per the AS vs. RS behavior)
> -Separation between the party authorizing access and the party 
> operating the client requesting access
> [Denis] It is questionable whether such a separation would be really 
> beneficial. In doubt, this item should be removed.
> [Roman] Could you say more on why this flexibility wouldn’t be worth it?

Except for added complexity, there is no need to have separate channels. 
It is simpler to send the access token in addition to the data
and, for additional security, to sign the data using a private key 
corresponding to a public key present in the access token.

> The group will define extension points for this protocol to allow for 
> flexibility in areas including:
> Cryptographic agility for keys, message signatures, and proof of 
> possession
> -User interaction mechanisms including web and non-web methods
> -Mechanisms for conveying user, software, organization, and other 
> information used in authorization decisions
> -Mechanisms for presenting tokens to resource servers and binding 
> resource requests to tokens and associated cryptographic keys
> Optimized inclusion of additional information (including identifiers 
> and identity assertions) through the delegation process
> Additionally, the group will provide mechanisms for management of the 
> protocol lifecycle including:
> -Discovery of the authorization server
> -Revocation of active tokens
> Data model for granted access and mechanisms for the AS and RS to 
> communicate the granted access model
> [Denis] While it is the duty for the RS to communicate the granted 
> access model to the client /at the appropriate instant of time/,
> the AS should be kept fully ignorant of it.
> Although the artifacts for this work are not intended or expected to 
> be backwards-compatible with OAuth 2.0 or OpenID Connect,
> the group will attempt to simplify migrating from OAuth 2.0 and OpenID 
> Connect to the new protocol where possible.
> 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. Functionality that builds directly on OAuth 
> 2.0 will be directed to the OAuth Working Group, including
> functionality back-ported from the protocol developed here to OAuth 2.0.
> The group is chartered to develop mechanisms for applying 
> cryptographic methods, such as JOSE and COSE, to the delegation process.
> This group is not chartered to develop new cryptographic methods.
> The group is chartered to develop mechanisms for conveying identity 
> information within the protocol including existing identifiers
> (such as email addresses, phone numbers, usernames, and subject 
> identifiers) and assertions (such as OpenID Connect ID Tokens,
> SAML Assertions, and Verifiable Credentials). The group is not 
> chartered to develop new formats for identifiers or assertions, nor is 
> the group
> chartered to develop schemas for user information, profiles, or other 
> identity attributes, unless a viable existing format is not available.
> The initial work will focus on using HTTPS for communication between 
> the client and the authorization server, taking advantage
> of optimization features of HTTP/2 and HTTP/3 where possible, and will 
> strive to enable simple mapping to other protocols such as COAP
> when doing so does not conflict with the primary focus.
> Milestones to include:
> -Core delegation protocol
> [Denis] Before defining a "Core delegation protocol", a simple client 
> server-protocol involving the presentation of several access tokens to 
> one RS should be defined.
> Privacy principles should be applied when defining the protocol. Then 
> after, a delegation mechanism allowing one RS to forward an operation 
> to another RS should be defined.
> -Key presentation mechanism bindings to the core protocol including 
> TLS, detached HTTP signature, and embedded HTTP signatures
> [Denis] Bindings to TLS are now deprecated, why should they be 
> maintained ?
> Signatures may be needed but they do not necessarily need to be 
> "detached HTTP signature, and embedded HTTP signatures".
> This item should be either removed or reworded.
> [Roman] Noted.  I’d want to hear others on this rescoping.

As explained above, it is possible to sign the data using a private key 
corresponding to a public key present in the access token.

> -Conveyance mechanisms for identifiers and assertions
> -Guidelines for use of protocol extension points (if needed)
>
> -    Guidelines on migration paths, implementation, and operations
>
> [Denis] The above three lines are rather mysterious.
>
> [Roman] The guidelines on migration paths came from the initial IESG 
> review in order to have a named activity to action the design goal of 
> “… the group will attempt to simplify migrating from OAuth 2.0 and 
> OpenID Connect to the new protocol where possible” a bit earlier in 
> the text.
>
> Where possible, the group will seek to make use of tools to guide and 
> inform the standardization process including formal analysis,
> architecture documents, and use case documents. These artifacts will 
> not be considered as working group milestones or deliverables.
>
> The working group will cooperate and coordinate with other IETF WGs 
> such as OAUTH, and work with external organizations,
> such as the OpenID Foundation, as appropriate.
>
> [Denis] The charter should be shorter.
>
> [Roman] Definitely.  Nevertheless, we have the current text through 
> rough consensus process achieved from two BoFs and multiple mailing 
> list consensus calls.
>
In a previous post, I proposed a much shorter text.

Denis

> Regards,
>
> Roman
>
> /Denis
>
>     A new IETF WG has been proposed in the Security Area. The IESG has not made
>
>     any determination yet. The following draft charter was submitted, and is
>
>     provided for informational purposes only. Please send your comments to the
>
>     IESG mailing list (iesg@ietf.org  )*by 2020-07-06*.
>
>     Grant Negotiation and Authorization Protocol (gnap)
>
>     -----------------------------------------------------------------------
>
>     Current status: Proposed WG
>
>     Chairs:
>
>        Yaron Sheffer  
>
>        Leif Johansson  
>
>     Assigned Area Director:
>
>        Roman Danyliw  
>
>     Security Area Directors:
>
>        Benjamin Kaduk  
>
>        Roman Danyliw  
>
>     Mailing list:
>
>        Address:txauth@ietf.org  
>
>        To subscribe:​https://www.ietf.org/mailman/listinfo/txauth
>
>        Archive:https://mailarchive.ietf.org/arch/browse/txauth/
>
>     Group page:https://datatracker.ietf.org/group/gnap/
>
>     Charter:https://datatracker.ietf.org/doc/charter-ietf-gnap/
>
>     This group is chartered to develop a fine-grained delegation protocol for
>
>     authorization and API access, as well as requesting and providing user
>
>     identifiers and claims. This protocol will allow an authorizing party to
>
>     delegate access to client software through an authorization server. It will
>
>     expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect
>
>     (itself an extension of OAuth 2.0) to support authorizations scoped as
>
>     narrowly as a single transaction, provide a clear framework for interaction
>
>     among all parties involved in the protocol flow, and remove unnecessary
>
>     dependence on a browser or user-agent for coordinating interactions.
>
>     The delegation process will be acted upon by multiple parties in the protocol,
>
>     each performing a specific role. The protocol will decouple the interaction
>
>     channels, such as the end user’s browser, from the delegation channel, which
>
>     happens directly between the client and the authorization server (in contrast
>
>     with OAuth 2.0, which is initiated by the client redirecting the user’s
>
>     browser). The protocol will include a means of specifying how the user can
>
>     potentially be involved in an interactive fashion during the delegation
>
>     process. The client and Authorization Server (AS) will use these interaction
>
>     mechanisms to involve the user, as necessary, to make authorization decisions.
>
>     This decoupling avoids many of the security concerns and technical challenges
>
>     of OAuth 2.0 and provides a non-invasive path for supporting future types of
>
>     clients and interaction channels.
>
>     The group will define interoperability for this protocol between different
>
>     parties, including
>
>       - client and authorization server;
>
>       - client and resource server; and
>
>       - authorization server and resource server.
>
>     The group will seek to minimize assumptions about the form of client
>
>     applications, allowing for:
>
>     - Fine-grained specification of access
>
>     - Approval of AS attestation to identifiers and other identity claims
>
>     - Approval of access to multiple resources and APIs in a single interaction
>
>     - Support for multiple access tokens in a single request and response
>
>     - Support for directed, audience-restricted access tokens
>
>     - Separation between the party authorizing access and the party operating the
>
>     client requesting access
>
>     The group will define extension points for this protocol to allow for
>
>     flexibility in areas including:
>
>     - Cryptographic agility for keys, message signatures, and proof of possession
>
>     - User interaction mechanisms including web and non-web methods
>
>     - Mechanisms for conveying user, software, organization, and other
>
>     information used in authorization decisions
>
>     - Mechanisms for presenting tokens to resource servers and binding resource
>
>     requests to tokens and associated cryptographic keys
>
>     - Optimized inclusion of additional information (including identifiers and
>
>     identity assertions) through the delegation process
>
>     Additionally, the group will provide mechanisms for management of the protocol
>
>     lifecycle including:
>
>     - Discovery of the authorization server
>
>     - Revocation of active tokens
>
>     - Mechanisms for the AS and RS to communicate the access granted by an access
>
>     token
>
>     Although the artifacts for this work are not intended or expected to be
>
>     backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt
>
>     to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol
>
>     where possible.
>
>     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. Functionality that builds directly on OAuth 2.0 will be directed
>
>     to the OAuth Working Group, including functionality back-ported from the
>
>     protocol developed here to OAuth 2.0.
>
>     The group is chartered to develop mechanisms for applying cryptographic
>
>     methods, such as JOSE and COSE, to the delegation process. This group is not
>
>     chartered to develop new cryptographic methods.
>
>     The group is chartered to develop mechanisms for conveying identity
>
>     information within the protocol including existing identifiers (such as email
>
>     addresses, phone numbers, usernames, and subject identifiers) and assertions
>
>     (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
>
>     Credentials). The group is not chartered to develop new formats for
>
>     identifiers or assertions, nor is the group chartered to develop schemas for
>
>     user information, profiles, or other identity attributes, unless a viable
>
>     existing format is not available.
>
>     The initial work will focus on using HTTPS for communication between the
>
>     client and the authorization server, taking advantage of optimization
>
>     features of HTTP/2 and HTTP/3 where possible, and will strive to enable
>
>     simple mapping to other protocols such as COAP when doing so does not
>
>     conflict with the primary focus.
>
>     Milestones to include:
>
>     - Core delegation protocol
>
>     - Key presentation mechanism bindings to the core protocol including TLS,
>
>     detached HTTP signature, and embedded HTTP signatures
>
>     - Conveyance mechanisms for identifiers and assertions
>
>     - Guidelines for use of protocol extension points
>
>     - (if needed) Guidelines on migration paths, implementation, and operations
>
>     Where possible, the group will seek to make use of tools to guide and inform
>
>     the standardization process including formal analysis, architecture documents,
>
>     and use case documents. These artifacts will not be considered as working
>
>     group milestones or deliverables.
>
>     The working group will cooperate and coordinate with other IETF WGs such as
>
>     OAUTH, and work with external organizations, such as the OpenID Foundation,
>
>     as appropriate.
>
>     Milestones:
>
>        Jul 2021 - Core delegation protocol in WGLC
>
>        Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to
>
>        WGLC
>
>        Oct 2021 - Key presentation mechanism binding to the core protocol,
>
>        detached HTTP signatures, to WGLC
>
>        Oct 2021 - Key presentation mechanism binding to the core protocol,
>
>        embedded HTTP signature, to WGLC
>
>        Dec 2021 - Guidelines for use of protocol extension points to WGLC
>
>        Feb 2022 - Guidelines on migration paths, implementation, and operations to
>
>         WGLC
>


--------------BF63B7896775EBF5D8C2E7AC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Roman,

    

      
      
      
      

        
Hi Denis!

        
 

        
Thanks for the feedback and for repeating
          your review on the revised text.  More inline …

        
 

        

          

            

              
From: iesg
                <iesg-bounces@ietf.org> On Behalf Of 
                Denis

                Sent: Monday, July 6, 2020 10:55 AM

                To: iesg@ietf.org

                Cc: txauth@ietf.org

                Subject: Re: [Txauth] WG Review: Grant
                Negotiation and Authorization Protocol (gnap)

            

          

          
 

          

            
Since
                it is today the last day to send back comments, you will
                find hereafter my comments on the last charter
                version-05.

          

        

      

    

    
BTW, I sent an email yesterday evening with the subject: Support
        of FIDO and data minimization by RSs, where I indicated that
      the charter should 

      mention FIDO U2F so that it should be possible to logon to a RS
      using either FIDO or by presenting one (or more) access tokens
      from one (or more) AS.

    
The original email is here : https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/

    

      

        

          

            

          

          

            
charter-ietf-gnap-00-05

            
This group is chartered to develop a fine-grained delegation protocol for authorization, API access, user identifiers, and identity assertions. 

            
 

            
[Denis] Fine.

            
 

            
The protocol will also allow the client to present unverified identifiers and verifiable assertions to the AS as part of its request. 

            
 

            
[Denis] This sentence is too vague because "as part of its request" is not explicit enough. If it means  "as part as an access token request" 

            
this should be explicitly said. If, it is not the case, then it should be clearly explained. The AS should know as little as possible (including nothing)

            
about what the client is doing.

            
 

            
[Roman] The “request” here is the “access token request”.  That can be made clearer.

          

        

      

    

    
This would be appreciated.

    

      

        

          

            

            
 

            
This protocol will allow an authorizing party to delegate access to client software through an authorization server. 

            
 

            
[Denis] The word "privacy" is still missing in the charter. "Delegating access to client software through an authorization server" 

            
is negating the fact that the user's privacy will ever be considered. IMHO, I believe that a RS may delegate some operation to another RS, 

            
but I don't believe that an AS should be concerned by any form of delegation, otherwise it would have the ability to act as "Big Brother".

            
OAuth has not been constructed taking into consideration the user's privacy. The major difference with it should be that GNAP has been 

            
constructed along "privacy by design" principles.

            
 

            
[Roman]  I don’t exactly follow how considerations for privacy are being negated.  Above and beyond use-case specific considerations that would be defined later, 
RFC6973 is the IETF consensus design guidance that will guide the privacy threats and mitigations of the work.  What design guidance would you recommend that 
the WG should consider that aren’t captured in RFC6973?

          

        

      

    

    
I believe my message is quite clear : If the AS is handling the
      delegation process, it will know what the client is doing or where
      it is going. 

      On the contrary, if the RS is handling the delegation process, the
      AS will be unable to know what the client is doing. In addition,
      an AS-centric 

      architecture would not be scalable and would need a lot of
      synchronizations between ASs and RSs. The user consent should be
      handled by the RS 

      and not by the AS. When a RS is unable to provide the service, it
      is best placed to tell directly to the client what it could do
      next. 

    

    
RFC 6973 is very good document. Section 7.1 states: 

    

    
          b.  Data.  What information does the protocol expose
      about individuals, their devices, and/or their device usage (other
      than the identifiers discussed in (a))? 

    

    
Data includes both the operation and the data associated with the
      operation. An AS should be kept ignorant of both the operation and
      the data associated with the operation.

    

      
c.  Observers.  (...) Are there ways for protocol implementers
        to  choose to limit the information shared with each entity?  

      

    

    
If theses guidances were followed, the proposed architecture
      would not be AS-centric.

    

      

        

          

            
 

            
It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations 

            
scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove 

            
unnecessary dependence on a browser or user-agent for coordinating interactions.

            
 

            
[Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. Some existing uses cases (i.e. "non-expanded" use cases) should be supported 

            
differently from OAuth 2.0 and OpenID Connect, in particular to support the user's privacy.

            
 

            
[Roman] I’d want to hear others on this rescoping.  Building upon the use cases of OAuth 2.0 and OpenID Connect has been core, consensus-validated tenant for some time now.

            
 

            
The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the channels used 

            
by the protocol participants to communicate from the delegation channel, which happens directly between the client and the authorization server (in contrast 

            
with OAuth 2.0, which is initiated by the client redirecting the user’s browser). 

            
 

            
[Denis] Here again, the delegation process, if any, should be handled by RSs and not by ASs. 

            
The term "delegation channel" is being used but it is left undefined. It is not understandable.

            
 

            
[Roman] This sentence was just added into -05 address Security AD feedback.  In this case, it was made to distinguish between in-band signaling and the new purpose-to-be-built channel.

          

        

      

    

    
Since delegation should not be handled by the AS, a delegation
      channel should not exist.

    

      

        

          

            

            
 

            
The protocol will include a means of specifying how the user can potentially be involved in an interactive fashion during the delegation process. 

            
The client and Authorization Server (AS) will use these interaction mechanisms to involve the user, as necessary, to make authorization decisions.

            
 

            
[Denis] Here again, the delegation process, if any, should be handled by RSs and not by ASs. The AS should know as little as possible (including nothing)

            
about what the client is doing.

            
 

            
[Roman] Understood – as I understand it, you have concern with the scope of the AS behavior.  I’d be interesting in hearing additional support for this rescoping.  

            
 

            
This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types 

            
of clients and interaction channels.

            
 

            
[Denis] This is not understandable to me. Is such a sentence really needed in a charter ?

            
 

            
[Roman] Can someone on the TxAuth mailing list remind us on why this sentence is here?  With a fresh read, I also can’t remember why we need it.

            
 

            
The group will define interoperability for this protocol between different parties, including

            
-          client and authorization server;

            
-          client and resource server; and

            
     -      authorization server and resource server.

            
 

            
[Denis] In order to support the user's privacy, there should be no interaction at all between an authorization server and a resource server 

            
at the time of a client request.

            
 

            
The group will seek to minimize assumptions about the form of client applications, allowing for:

            
-          Fine-grained specification of access

            
-          Approval of AS attestation to identifiers and other identity claims

            
-          Approval of access to multiple resources and APIs in a single interaction

            
-          Multiple access tokens in a single request and response

            
-          AS-directed dispatch of access tokens to the appropriate RS

            
[Denis] As-directed dispatch does not allow to support the user's privacy. However, RS-directed dispatch allows to support the user's privacy.

            
It should be explicitly mentioned.

            
[Roman] As above (per the AS vs. RS behavior)

            
-          Separation between the party authorizing access and the party operating the client requesting access 

            
 

            
[Denis] It is questionable whether such a separation would be really beneficial. In doubt, this item should be removed.

            
[Roman] Could you say more on why this flexibility wouldn’t be worth it?  

          

        

      

    

    
Except for added complexity, there is no need to have separate
      channels. It is simpler to send the access token in addition to
      the data 

      and, for additional security, to sign the data using a private key
      corresponding to a public key present in the access token.

    

      

        

          

            

            
The group will define extension points for this protocol to allow for flexibility in areas including:

            
 

            
Cryptographic agility for keys, message signatures, and proof of possession

            
-          User interaction mechanisms including web and non-web methods

            
-          Mechanisms for conveying user, software, organization, and other information used in authorization decisions 

            
-          Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys 

            
Optimized inclusion of additional information (including identifiers and identity assertions) through the delegation process 

            
 

            
Additionally, the group will provide mechanisms for management of the protocol lifecycle including:

            
-          Discovery of the authorization server

            
-          Revocation of active tokens

            
Data model for granted access and mechanisms for the AS and RS to communicate the granted access model

            
 

            
[Denis] While it is the duty for the RS to communicate the granted access model to the client at the appropriate instant of time, 

            
the AS should be kept fully ignorant of it.

            
 

            
Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, 

            
the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.

            
 

            
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. Functionality that builds directly on OAuth 2.0 will be directed to the OAuth Working Group, including 

            
functionality back-ported from the protocol developed here to OAuth 2.0.

            
 

            
The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. 

            
This group is not chartered to develop new cryptographic methods.

            
 

            
The group is chartered to develop mechanisms for conveying identity information within the protocol including existing identifiers 

            
(such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, 

            
SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group 

            
chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available.

            
 

            
The initial work will focus on using HTTPS for communication between the client and the authorization server, taking advantage 

            
of optimization features of HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to other protocols such as COAP 

            
when doing so does not conflict with the primary focus.

            
 

            
Milestones to include:

            
-          Core delegation protocol

            
[Denis] Before defining a "Core delegation protocol", a simple client server-protocol involving the presentation of several access tokens to one RS should be defined. 

            
Privacy principles should be applied when defining the protocol. Then after, a delegation mechanism allowing one RS to forward an operation to another RS should be defined.

            
-          Key presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded HTTP signatures 

            
[Denis] Bindings to TLS are now deprecated, why should they be maintained ? 

            
Signatures may be needed but they do not necessarily need to be "detached HTTP signature, and embedded HTTP signatures". 

            
This item should be either removed or reworded.

            
[Roman] Noted.  I’d want to hear others on this rescoping.

          

        

      

    

    
As explained above, it is possible to sign the data using a
      private key corresponding to a public key present in the access
      token.

    

      

        

          

            

            
 

            
-          Conveyance mechanisms for identifiers and assertions 

            
-          Guidelines for use of protocol extension points (if needed) 

            
    
                -    Guidelines on migration paths, implementation, and
                operations
              

            
[Denis] The
                above three lines are rather mysterious.

            
[Roman]
              The guidelines on migration paths came from the initial
              IESG review in order to have a named activity to action
              the design goal of “… the group will attempt to simplify
              migrating from OAuth 2.0 and OpenID Connect to the new
              protocol where possible” a bit earlier in the text.

            
Where
                possible, the group will seek to make use of tools to
                guide and inform the standardization process including
                formal analysis,
                

                architecture documents, and use case documents. These
                artifacts will not be considered as working group
                milestones or deliverables.

            
The
                working group will cooperate and coordinate with other
                IETF WGs such as OAUTH, and work with external
                organizations,
                

                such as the OpenID Foundation, as appropriate.

            
[Denis]
                The charter should be shorter.

            
 

            
[Roman] Definitely.  Nevertheless, we
              have the current text through rough consensus process
              achieved from two BoFs and multiple mailing list consensus
              calls.

          

        

      

    

    
In a previous post, I proposed a much shorter text.

    
Denis

    

    

      

        

          

            

            
 

            
Regards,

            
Roman 

          

          

            
 

          

          

            
/Denis

          

          

            
 

          

          

            
A new IETF WG has been proposed in the Security Area. The IESG has not made

            
any determination yet. The following draft charter was submitted, and is

            
provided for informational purposes only. Please send your comments to the

            
IESG mailing list (iesg@ietf.org) by 2020-07-06.

            
 

            
Grant Negotiation and Authorization Protocol (gnap)

            
-----------------------------------------------------------------------

            
Current status: Proposed WG

            
 

            
Chairs:

            
  Yaron Sheffer <yaronf.ietf@gmail.com>

            
  Leif Johansson <leifj@sunet.se>

            
 

            
Assigned Area Director:

            
  Roman Danyliw <rdd@cert.org>

            
 

            
Security Area Directors:

            
  Benjamin Kaduk <kaduk@mit.edu>

            
  Roman Danyliw <rdd@cert.org>

            
 

            
Mailing list:

            
  Address: txauth@ietf.org

            
  To subscribe: ​https://www.ietf.org/mailman/listinfo/txauth

            
  Archive: https://mailarchive.ietf.org/arch/browse/txauth/

            
 

            
Group page: https://datatracker.ietf.org/group/gnap/

            
 

            
Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/

            
 

            
This group is chartered to develop a fine-grained delegation protocol for

            
authorization and API access, as well as requesting and providing user

            
identifiers and claims. This protocol will allow an authorizing party to

            
delegate access to client software through an authorization server. It will

            
expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect

            
(itself an extension of OAuth 2.0) to support authorizations scoped as

            
narrowly as a single transaction, provide a clear framework for interaction

            
among all parties involved in the protocol flow, and remove unnecessary

            
dependence on a browser or user-agent for coordinating interactions.

            
 

            
The delegation process will be acted upon by multiple parties in the protocol,

            
each performing a specific role. The protocol will decouple the interaction

            
channels, such as the end user’s browser, from the delegation channel, which

            
happens directly between the client and the authorization server (in contrast

            
with OAuth 2.0, which is initiated by the client redirecting the user’s

            
browser). The protocol will include a means of specifying how the user can

            
potentially be involved in an interactive fashion during the delegation

            
process. The client and Authorization Server (AS) will use these interaction

            
mechanisms to involve the user, as necessary, to make authorization decisions.

            
This decoupling avoids many of the security concerns and technical challenges

            
of OAuth 2.0 and provides a non-invasive path for supporting future types of

            
clients and interaction channels.

            
 

            
The group will define interoperability for this protocol between different

            
parties, including

            
 - client and authorization server;

            
 - client and resource server; and

            
 - authorization server and resource server.

            
 

            
The group will seek to minimize assumptions about the form of client

            
applications, allowing for:

            
- Fine-grained specification of access

            
- Approval of AS attestation to identifiers and other identity claims

            
- Approval of access to multiple resources and APIs in a single interaction

            
- Support for multiple access tokens in a single request and response

            
- Support for directed, audience-restricted access tokens

            
- Separation between the party authorizing access and the party operating the

            
client requesting access

            
 

            
The group will define extension points for this protocol to allow for

            
flexibility in areas including:

            
 

            
- Cryptographic agility for keys, message signatures, and proof of possession

            
- User interaction mechanisms including web and non-web methods

            
- Mechanisms for conveying user, software, organization, and other

            
information used in authorization decisions

            
- Mechanisms for presenting tokens to resource servers and binding resource

            
requests to tokens and associated cryptographic keys

            
- Optimized inclusion of additional information (including identifiers and

            
identity assertions) through the delegation process

            
 

            
Additionally, the group will provide mechanisms for management of the protocol

            
lifecycle including:

            
 

            
- Discovery of the authorization server

            
- Revocation of active tokens

            
- Mechanisms for the AS and RS to communicate the access granted by an access

            
token

            
 

            
Although the artifacts for this work are not intended or expected to be

            
backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt

            
to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol

            
where possible.

            
 

            
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. Functionality that builds directly on OAuth 2.0 will be directed

            
to the OAuth Working Group, including functionality back-ported from the

            
protocol developed here to OAuth 2.0.

            
 

            
The group is chartered to develop mechanisms for applying cryptographic

            
methods, such as JOSE and COSE, to the delegation process. This group is not

            
chartered to develop new cryptographic methods.

            
 

            
The group is chartered to develop mechanisms for conveying identity

            
information within the protocol including existing identifiers (such as email

            
addresses, phone numbers, usernames, and subject identifiers) and assertions

            
(such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable

            
Credentials). The group is not chartered to develop new formats for

            
identifiers or assertions, nor is the group chartered to develop schemas for

            
user information, profiles, or other identity attributes, unless a viable

            
existing format is not available.

            
 

            
The initial work will focus on using HTTPS for communication between the

            
client and the authorization server, taking advantage of optimization

            
features of HTTP/2 and HTTP/3 where possible, and will strive to enable

            
simple mapping to other protocols such as COAP when doing so does not

            
conflict with the primary focus.

            
 

            
Milestones to include:

            
- Core delegation protocol

            
- Key presentation mechanism bindings to the core protocol including TLS,

            
detached HTTP signature, and embedded HTTP signatures

            
- Conveyance mechanisms for identifiers and assertions

            
- Guidelines for use of protocol extension points

            
- (if needed) Guidelines on migration paths, implementation, and operations

            
 

            
Where possible, the group will seek to make use of tools to guide and inform

            
the standardization process including formal analysis, architecture documents,

            
and use case documents. These artifacts will not be considered as working

            
group milestones or deliverables.

            
 

            
The working group will cooperate and coordinate with other IETF WGs such as

            
OAUTH, and work with external organizations, such as the OpenID Foundation,

            
as appropriate.

            
 

            
Milestones:

            
 

            
  Jul 2021 - Core delegation protocol in WGLC

            
 

            
  Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to

            
  WGLC

            
 

            
  Oct 2021 - Key presentation mechanism binding to the core protocol, 

            
  detached HTTP signatures, to WGLC

            
 

            
  Oct 2021 - Key presentation mechanism binding to the core protocol,

            
  embedded HTTP signature, to WGLC

            
 

            
  Dec 2021 - Guidelines for use of protocol extension points to WGLC

            
 

            
  Feb 2022 - Guidelines on migration paths, implementation, and operations to

            
   WGLC

            
 

            
 

            
 

          

          
 

        

      

    

    


    

  


--------------BF63B7896775EBF5D8C2E7AC--


From nobody Tue Jul  7 08:28: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 A45403A0E4B; Tue,  7 Jul 2020 08:28: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 jC1Jh6ZcIvis; Tue,  7 Jul 2020 08:28:40 -0700 (PDT)
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0: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 693AA3A0E53; Tue,  7 Jul 2020 08:28:40 -0700 (PDT)
Received: by mail-oi1-x22f.google.com with SMTP id k22so23850324oib.0; Tue, 07 Jul 2020 08:28: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=gG2YOOUiV8OsaaNU/pg/u1XRMjDY61EEcIXyQJdwLJI=; b=oojJ44lt87HAxchnsKIKMt/BvUbJUrpLS4Hq1UhMgJvLHtRsFDPfjE+XIrDeJ0QtUI h5zmlchVF/xRq1rKBIgrNIQIKays4BU1lUS3DDvKbfbOQXBRevcAhVKZBFqrClGwCWrJ 37ie9JEWayYvjusiW1pNJes93RIXzip3HDPx0SOIu4Hhx9keTrHgBNZajJpjihzDNpC4 t5cQ5DmOVpdLBADnFGkJKoVqHwU9CP3Ynmv/ZHzeBWmTkux6VeGqUH+pIYM/ka/pOntD 5GmgFMA10WJGSDve+its9EVXXhtiCqO735ww1jy2GovypspqxHi3wqStHKKZbym1Uq9E YPmw==
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=gG2YOOUiV8OsaaNU/pg/u1XRMjDY61EEcIXyQJdwLJI=; b=OO61c0OSee0W49Q7aFWDfPl/OUtlV4gjGT1fC43TGZyazkXrT8ORmhyi/6E75r0phS ASEBUybq3SqntUpVOwTjgQEeWgBbJ0YJNYEDa5lAyNSPw0kjOgWuOtZBFdyh4h5hyewg 0SiIqkAlyXnvS6kHteMfbpK7bqUyeU2/SAszhcfcTx++drxtfEkcV+t5XE2Ug0hcnaBh BIVkgSH4N9cvogSljejoLvP8I3jIAlprCd/mKlAKpxq9igaVjs90IHoD7s1HpoN9/Pfw 0FfSV1EZgo3xqgclE3f83h1qqQY7CnnBepnbUMtat+8UmF/+sqZMRpJfO5TzFYbURXrN Rfxg==
X-Gm-Message-State: AOAM531quDEBpFCVYBGhePJnB/hJIMRNLJLJNMNGlNNUcToy3hHrWEjJ ZER9HtobsZhZEBfuFp75uW3BWxCDXyQhdCir2cXCjQ==
X-Google-Smtp-Source: ABdhPJw75HZGNE4erOibFGGQqpb7Cya4nMwoZniFF1/snTh3/V9Sc/0UhRrD56e1R5CLGSbQE5UeXt/HI5iel7AnzNM=
X-Received: by 2002:aca:4b50:: with SMTP id y77mr3608778oia.63.1594135719462;  Tue, 07 Jul 2020 08:28:39 -0700 (PDT)
MIME-Version: 1.0
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <7563640e-f515-3e73-a4eb-3902ec7af50e@free.fr> <3424311c60f541b197cfda6e9f3b494e@cert.org> <36de4e6a-41fe-81b1-6c92-69fe5b63ad6f@free.fr>
In-Reply-To: <36de4e6a-41fe-81b1-6c92-69fe5b63ad6f@free.fr>
From: Tom Jones 
Date: Tue, 7 Jul 2020 08:28:16 -0700
Message-ID: 
To: Denis 
Cc: Roman Danyliw , The IESG , "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000484c8e05a9dba517"
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 07 Jul 2020 15:28:45 -0000

--000000000000484c8e05a9dba517
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

To be perfectly blunt about it, if Denis' view on the AS were to prevail. I
would have little use for the resulting standards and would not even
attempt compliance with them.

thx ..Tom (mobile)

On Tue, Jul 7, 2020, 5:43 AM Denis  wrote:

> Hi Roman,
>
> Hi Denis!
>
>
>
> Thanks for the feedback and for repeating your review on the revised
> text.  More inline =E2=80=A6
>
>
>
> *From:* iesg   *On Behalf
> Of * Denis
> *Sent:* Monday, July 6, 2020 10:55 AM
> *To:* iesg@ietf.org
> *Cc:* txauth@ietf.org
> *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization
> Protocol (gnap)
>
>
>
> Since it is today the last day to send back comments, you will find
> hereafter my comments on the last charter version-05.
>
> BTW, I sent an email yesterday evening with the subject: *Support of FIDO=
*
> and data minimization by RSs, where I indicated that the charter should
> mention FIDO U2F so that it should be possible to logon to a RS using
> either FIDO or by presenting one (or more) access tokens from one (or mor=
e)
> AS.
>
> The original email is here :
> https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/
>
> charter-ietf-gnap-00-05
>
> This group is chartered to develop a fine-grained delegation protocol for=
 authorization, API access, user identifiers, and identity assertions.
>
>
>
> [Denis] Fine.
>
>
>
> The protocol will also allow the client to present unverified identifiers=
 and verifiable assertions to the AS as part of its request.
>
>
>
> [Denis] This sentence is too vague because "as part of its request" is no=
t explicit enough. If it means  "as part as an access token request"
>
> this should be explicitly said. If, it is not the case, then it should be=
 clearly explained. The AS should know as little as possible (including not=
hing)
>
> about what the client is doing.
>
>
>
> [Roman] The =E2=80=9Crequest=E2=80=9D here is the =E2=80=9Caccess token r=
equest=E2=80=9D.  That can be made clearer.
>
> This would be appreciated.
>
>
>
> This protocol will allow an authorizing party to delegate access to clien=
t software through an authorization server.
>
>
>
> [Denis] The word "*privacy*" is still missing in the charter. "Delegating=
 access to client software through an authorization server"
>
> is negating the fact that the user's privacy will ever be considered. IMH=
O, I believe that a RS may delegate some operation to another RS,
>
> but I don't believe that an AS should be concerned by any form of delegat=
ion, otherwise it would have the ability to act as "Big Brother".
>
> OAuth has not been constructed taking into consideration the user's priva=
cy. The major difference with it should be that GNAP has been
>
> constructed along "*privacy by design*" principles.
>
>
>
> [Roman]  I don=E2=80=99t exactly follow how considerations for privacy ar=
e being negated.  Above and beyond use-case specific considerations that wo=
uld be defined later,
> RFC6973 is the IETF consensus design guidance that will guide the privacy=
 threats and mitigations of the work.  What design guidance would you recom=
mend that
> the WG should consider that aren=E2=80=99t captured in RFC6973?
>
> I believe my message is quite clear : If the AS is handling the delegatio=
n
> process, it will know what the client is doing or where it is going.
> On the contrary, if the RS is handling the delegation process, the AS wil=
l
> be unable to know what the client is doing. In addition, an AS-centric
> architecture would not be scalable and would need a lot of
> synchronizations between ASs and RSs. The user consent should be handled =
by
> the RS
> and not by the AS. When a RS is unable to provide the service, it is best
> placed to tell directly to the client what it could do next.
>
> RFC 6973 is very good document. Section 7.1 states:
>
>           b.  Data.  What information does the protocol expose about
> individuals, their devices, and/or their device usage (other than the
> identifiers discussed in (a))?
>
> Data includes both the operation and the data associated with the
> operation. An AS should be kept ignorant of both the operation and the da=
ta
> associated with the operation.
>
> c.  Observers.  (...) Are there ways for protocol implementers to  choose
> to limit the information shared with each entity?
>
> If theses guidances were followed, the proposed architecture would not be
> AS-centric.
>
>
>
> It will *expand* upon the uses cases currently supported by OAuth 2.0 and=
 OpenID Connect (itself an extension of OAuth 2.0) to support authorization=
s
>
> scoped as narrowly as a single transaction, provide a clear framework for=
 interaction among all parties involved in the protocol flow, and remove
>
> unnecessary dependence on a browser or user-agent for coordinating intera=
ctions.
>
>
>
> [Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. Some e=
xisting uses cases (i.e. "*non-expanded"* use cases) should be supported
>
> differently from OAuth 2.0 and OpenID Connect, in particular to support t=
he user's privacy.
>
>
>
> [Roman] I=E2=80=99d want to hear others on this rescoping.  Building upon=
 the use cases of OAuth 2.0 and OpenID Connect has been core, consensus-val=
idated tenant for some time now.
>
>
>
> The delegation process will be acted upon by multiple parties in the prot=
ocol, each performing a specific role. The protocol will decouple the chann=
els used
>
> by the protocol participants to communicate from the delegation channel, =
which happens directly between the client and the authorization server (in =
contrast
>
> with OAuth 2.0, which is initiated by the client redirecting the user=E2=
=80=99s browser).
>
>
>
> [Denis] Here again, the delegation process, if any, should be handled by =
RSs and not by ASs.
>
> The term "delegation channel" is being used but it is left undefined. It =
is not understandable.
>
>
>
> [Roman] This sentence was just added into -05 address Security AD feedbac=
k.  In this case, it was made to distinguish between in-band signaling and =
the new purpose-to-be-built channel.
>
> Since delegation should not be handled by the AS, a delegation channel
> should not exist.
>
>
>
> The protocol will include a means of specifying how the user can potentia=
lly be involved in an interactive fashion during the delegation process.
>
> The client and Authorization Server (AS) will use these interaction mecha=
nisms to involve the user, as necessary, to make authorization decisions.
>
>
>
> [Denis] Here again, the delegation process, if any, should be handled by =
RSs and not by ASs. The AS should know as little as possible (including not=
hing)
>
> about what the client is doing.
>
>
>
> [Roman] Understood =E2=80=93 as I understand it, you have concern with th=
e scope of the AS behavior.  I=E2=80=99d be interesting in hearing addition=
al support for this rescoping.
>
>
>
> This decoupling avoids many of the security concerns and technical challe=
nges of OAuth 2.0 and provides a non-invasive path for supporting future ty=
pes
>
> of clients and interaction channels.
>
>
>
> [Denis] This is not understandable to me. Is such a sentence really neede=
d in a charter ?
>
>
>
> [Roman] Can someone on the TxAuth mailing list remind us on why this sent=
ence is here?  With a fresh read, I also can=E2=80=99t remember why we need=
 it.
>
>
>
> The group will define interoperability for this protocol between differen=
t parties, including
>
> -          client and authorization server;
>
> -          client and resource server; and
>
>      -      authorization server and resource server.
>
>
>
> [Denis] In order to support the user's privacy, there should be no intera=
ction at all between an authorization server and a resource server
>
> *at the time of a client request*.
>
>
>
> The group will seek to minimize assumptions about the form of client appl=
ications, allowing for:
>
> -          Fine-grained specification of access
>
> -          Approval of AS attestation to identifiers and other identity c=
laims
>
> -          Approval of access to multiple resources and APIs in a single =
interaction
>
> -          Multiple access tokens in a single request and response
>
> -          AS-directed dispatch of access tokens to the appropriate RS
>
> [Denis] As-directed dispatch does not allow to support the user's privacy=
. However, RS-directed dispatch allows to support the user's privacy.
>
> It should be explicitly mentioned.
>
> [Roman] As above (per the AS vs. RS behavior)
>
> -          Separation between the party authorizing access and the party =
operating the client requesting access
>
>
>
> [Denis] It is questionable whether such a separation would be really bene=
ficial. In doubt, this item should be removed.
>
> [Roman] Could you say more on why this flexibility wouldn=E2=80=99t be wo=
rth it?
>
> Except for added complexity, there is no need to have separate channels.
> It is simpler to send the access token in addition to the data
> and, for additional security, to sign the data using a private key
> corresponding to a public key present in the access token.
>
> The group will define extension points for this protocol to allow for fle=
xibility in areas including:
>
>
>
> Cryptographic agility for keys, message signatures, and proof of possessi=
on
>
> -          User interaction mechanisms including web and non-web methods
>
> -          Mechanisms for conveying user, software, organization, and oth=
er information used in authorization decisions
>
> -          Mechanisms for presenting tokens to resource servers and bindi=
ng resource requests to tokens and associated cryptographic keys
>
> Optimized inclusion of additional information (including identifiers and =
identity assertions) through the delegation process
>
>
>
> Additionally, the group will provide mechanisms for management of the pro=
tocol lifecycle including:
>
> -          Discovery of the authorization server
>
> -          Revocation of active tokens
>
> Data model for granted access and mechanisms for the AS and RS to communi=
cate the granted access model
>
>
>
> [Denis] While it is the duty for the RS to communicate the granted access=
 model to the client *at the appropriate instant of time*,
>
> the AS should be kept fully ignorant of it.
>
>
>
> Although the artifacts for this work are not intended or expected to be b=
ackwards-compatible with OAuth 2.0 or OpenID Connect,
>
> the group will attempt to simplify migrating from OAuth 2.0 and OpenID Co=
nnect to the new protocol where possible.
>
>
>
> This group is not chartered to develop extensions to OAuth 2.0, and as su=
ch will focus on new technological solutions not necessarily
>
> compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.=
0 will be directed to the OAuth Working Group, including
>
> functionality back-ported from the protocol developed here to OAuth 2.0.
>
>
>
> The group is chartered to develop mechanisms for applying cryptographic m=
ethods, such as JOSE and COSE, to the delegation process.
>
> This group is not chartered to develop new cryptographic methods.
>
>
>
> The group is chartered to develop mechanisms for conveying identity infor=
mation within the protocol including existing identifiers
>
> (such as email addresses, phone numbers, usernames, and subject identifie=
rs) and assertions (such as OpenID Connect ID Tokens,
>
> SAML Assertions, and Verifiable Credentials). The group is not chartered =
to develop new formats for identifiers or assertions, nor is the group
>
> chartered to develop schemas for user information, profiles, or other ide=
ntity attributes, unless a viable existing format is not available.
>
>
>
> The initial work will focus on using HTTPS for communication between the =
client and the authorization server, taking advantage
>
> of optimization features of HTTP/2 and HTTP/3 where possible, and will st=
rive to enable simple mapping to other protocols such as COAP
>
> when doing so does not conflict with the primary focus.
>
>
>
> Milestones to include:
>
> -          Core delegation protocol
>
> [Denis] Before defining a "Core delegation protocol", a simple client ser=
ver-protocol involving the presentation of several access tokens to one RS =
should be defined.
>
> Privacy principles should be applied when defining the protocol. Then aft=
er, a delegation mechanism allowing one RS to forward an operation to anoth=
er RS should be defined.
>
> -          Key presentation mechanism bindings to the core protocol inclu=
ding TLS, detached HTTP signature, and embedded HTTP signatures
>
> [Denis] Bindings to TLS are now deprecated, why should they be maintained=
 ?
>
> Signatures may be needed but they do not necessarily need to be "detached=
 HTTP signature, and embedded HTTP signatures".
>
> This item should be either removed or reworded.
>
> [Roman] Noted.  I=E2=80=99d want to hear others on this rescoping.
>
> As explained above, it is possible to sign the data using a private key
> corresponding to a public key present in the access token.
>
>
>
> -          Conveyance mechanisms for identifiers and assertions
>
> -          Guidelines for use of protocol extension points (if needed)
>
>      -    Guidelines on migration paths, implementation, and operations
>
> [Denis] The above three lines are rather mysterious.
>
> [Roman] The guidelines on migration paths came from the initial IESG
> review in order to have a named activity to action the design goal of =E2=
=80=9C=E2=80=A6
> the group will attempt to simplify migrating from OAuth 2.0 and OpenID
> Connect to the new protocol where possible=E2=80=9D a bit earlier in the =
text.
>
> Where possible, the group will seek to make use of tools to guide and
> inform the standardization process including formal analysis,
> architecture documents, and use case documents. These artifacts will not
> be considered as working group milestones or deliverables.
>
> The working group will cooperate and coordinate with other IETF WGs such
> as OAUTH, and work with external organizations,
> such as the OpenID Foundation, as appropriate.
>
> [Denis] The charter should be shorter.
>
>
>
> [Roman] Definitely.  Nevertheless, we have the current text through rough
> consensus process achieved from two BoFs and multiple mailing list
> consensus calls.
>
> In a previous post, I proposed a much shorter text.
>
> Denis
>
>
>
> Regards,
>
> Roman
>
>
>
> /Denis
>
>
>
> A new IETF WG has been proposed in the Security Area. The IESG has not ma=
de
>
> any determination yet. The following draft charter was submitted, and is
>
> provided for informational purposes only. Please send your comments to th=
e
>
> IESG mailing list (iesg@ietf.org) *by 2020-07-06*.
>
>
>
> Grant Negotiation and Authorization Protocol (gnap)
>
> -----------------------------------------------------------------------
>
> Current status: Proposed WG
>
>
>
> Chairs:
>
>   Yaron Sheffer  
>
>   Leif Johansson  
>
>
>
> Assigned Area Director:
>
>   Roman Danyliw  
>
>
>
> Security Area Directors:
>
>   Benjamin Kaduk  
>
>   Roman Danyliw  
>
>
>
> Mailing list:
>
>   Address: txauth@ietf.org
>
>   To subscribe: =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/txauth
>
>   Archive: https://mailarchive.ietf.org/arch/browse/txauth/
>
>
>
> Group page: https://datatracker.ietf.org/group/gnap/
>
>
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/
>
>
>
> This group is chartered to develop a fine-grained delegation protocol for
>
> authorization and API access, as well as requesting and providing user
>
> identifiers and claims. This protocol will allow an authorizing party to
>
> delegate access to client software through an authorization server. It wi=
ll
>
> expand upon the uses cases currently supported by OAuth 2.0 and OpenID Co=
nnect
>
> (itself an extension of OAuth 2.0) to support authorizations scoped as
>
> narrowly as a single transaction, provide a clear framework for interacti=
on
>
> among all parties involved in the protocol flow, and remove unnecessary
>
> dependence on a browser or user-agent for coordinating interactions.
>
>
>
> The delegation process will be acted upon by multiple parties in the prot=
ocol,
>
> each performing a specific role. The protocol will decouple the interacti=
on
>
> channels, such as the end user=E2=80=99s browser, from the delegation cha=
nnel, which
>
> happens directly between the client and the authorization server (in cont=
rast
>
> with OAuth 2.0, which is initiated by the client redirecting the user=E2=
=80=99s
>
> browser). The protocol will include a means of specifying how the user ca=
n
>
> potentially be involved in an interactive fashion during the delegation
>
> process. The client and Authorization Server (AS) will use these interact=
ion
>
> mechanisms to involve the user, as necessary, to make authorization decis=
ions.
>
> This decoupling avoids many of the security concerns and technical challe=
nges
>
> of OAuth 2.0 and provides a non-invasive path for supporting future types=
 of
>
> clients and interaction channels.
>
>
>
> The group will define interoperability for this protocol between differen=
t
>
> parties, including
>
>  - client and authorization server;
>
>  - client and resource server; and
>
>  - authorization server and resource server.
>
>
>
> The group will seek to minimize assumptions about the form of client
>
> applications, allowing for:
>
> - Fine-grained specification of access
>
> - Approval of AS attestation to identifiers and other identity claims
>
> - Approval of access to multiple resources and APIs in a single interacti=
on
>
> - Support for multiple access tokens in a single request and response
>
> - Support for directed, audience-restricted access tokens
>
> - Separation between the party authorizing access and the party operating=
 the
>
> client requesting access
>
>
>
> The group will define extension points for this protocol to allow for
>
> flexibility in areas including:
>
>
>
> - Cryptographic agility for keys, message signatures, and proof of posses=
sion
>
> - User interaction mechanisms including web and non-web methods
>
> - Mechanisms for conveying user, software, organization, and other
>
> information used in authorization decisions
>
> - Mechanisms for presenting tokens to resource servers and binding resour=
ce
>
> requests to tokens and associated cryptographic keys
>
> - Optimized inclusion of additional information (including identifiers an=
d
>
> identity assertions) through the delegation process
>
>
>
> Additionally, the group will provide mechanisms for management of the pro=
tocol
>
> lifecycle including:
>
>
>
> - Discovery of the authorization server
>
> - Revocation of active tokens
>
> - Mechanisms for the AS and RS to communicate the access granted by an ac=
cess
>
> token
>
>
>
> Although the artifacts for this work are not intended or expected to be
>
> backwards-compatible with OAuth 2.0 or OpenID Connect, the group will att=
empt
>
> to simplify migrating from OAuth 2.0 and OpenID Connect to the new protoc=
ol
>
> where possible.
>
>
>
> This group is not chartered to develop extensions to OAuth 2.0, and as su=
ch
>
> will focus on new technological solutions not necessarily compatible with
>
> OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be direct=
ed
>
> to the OAuth Working Group, including functionality back-ported from the
>
> protocol developed here to OAuth 2.0.
>
>
>
> The group is chartered to develop mechanisms for applying cryptographic
>
> methods, such as JOSE and COSE, to the delegation process. This group is =
not
>
> chartered to develop new cryptographic methods.
>
>
>
> The group is chartered to develop mechanisms for conveying identity
>
> information within the protocol including existing identifiers (such as e=
mail
>
> addresses, phone numbers, usernames, and subject identifiers) and asserti=
ons
>
> (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
>
> Credentials). The group is not chartered to develop new formats for
>
> identifiers or assertions, nor is the group chartered to develop schemas =
for
>
> user information, profiles, or other identity attributes, unless a viable
>
> existing format is not available.
>
>
>
> The initial work will focus on using HTTPS for communication between the
>
> client and the authorization server, taking advantage of optimization
>
> features of HTTP/2 and HTTP/3 where possible, and will strive to enable
>
> simple mapping to other protocols such as COAP when doing so does not
>
> conflict with the primary focus.
>
>
>
> Milestones to include:
>
> - Core delegation protocol
>
> - Key presentation mechanism bindings to the core protocol including TLS,
>
> detached HTTP signature, and embedded HTTP signatures
>
> - Conveyance mechanisms for identifiers and assertions
>
> - Guidelines for use of protocol extension points
>
> - (if needed) Guidelines on migration paths, implementation, and operatio=
ns
>
>
>
> Where possible, the group will seek to make use of tools to guide and inf=
orm
>
> the standardization process including formal analysis, architecture docum=
ents,
>
> and use case documents. These artifacts will not be considered as working
>
> group milestones or deliverables.
>
>
>
> The working group will cooperate and coordinate with other IETF WGs such =
as
>
> OAUTH, and work with external organizations, such as the OpenID Foundatio=
n,
>
> as appropriate.
>
>
>
> Milestones:
>
>
>
>   Jul 2021 - Core delegation protocol in WGLC
>
>
>
>   Oct 2021 - Key presentation mechanism binding to the core protocol, TLS=
, to
>
>   WGLC
>
>
>
>   Oct 2021 - Key presentation mechanism binding to the core protocol,
>
>   detached HTTP signatures, to WGLC
>
>
>
>   Oct 2021 - Key presentation mechanism binding to the core protocol,
>
>   embedded HTTP signature, to WGLC
>
>
>
>   Dec 2021 - Guidelines for use of protocol extension points to WGLC
>
>
>
>   Feb 2022 - Guidelines on migration paths, implementation, and operation=
s to
>
>    WGLC
>
>
>
>
>
>
>
>
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000484c8e05a9dba517
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


To be perfectly blunt about it, if Denis' view on the=
 AS were to prevail. I would have little use for the resulting standards an=
d would not even attempt compliance with them.

thx ..Tom (mobile)

On Tue, Jul 7, 2020, 5:43 AM D=
enis <denis.ietf@free.fr> w=
rote:

 =20
   =20
 =20
  

    
Hi Roman,

    

     =20
     =20
     =20
      

        
Hi Denis!

        
=C2=A0

        
Thanks for the feedback and for repeating
          your review on the revised text.=C2=A0 More inline =E2=80=A6

        
=C2=A0

        

          

            

              
From: iesg
                <iesg-bounces@ietf.org> On Behalf Of 
                Denis

                Sent: Monday, July 6, 2020 10:55 AM

                To: iesg@ietf.org

                Cc: txauth@ietf.org

                Subject: Re: [Txauth] WG Review: Grant
                Negotiation and Authorization Protocol (gnap)=


            

          

          
=C2=A0

          

            
Since
                it is today the last day to send back comments, you will
                find hereafter my comments on the last charter
                version-05.

          

        

      

    

    
BTW, I sent an email yesterday evening with the subject: Support
        of FIDO and data minimization by RSs, where I indicated that
      the charter should 

      mention FIDO U2F so that it should be possible to logon to a RS
      using either FIDO or by presenting one (or more) access tokens
      from one (or more) AS.

    
The original email is here : https://mailarchive.ietf.org/arch/msg/txau=
th/fTwQCOfq6do9oL3iIPQczD7icwE/

    

      

        

          

            

          

          

            
charter-ietf-gnap-00-05

            
This group is chartered to develop a fine-grained delegatio=
n protocol for authorization, API access, user identifiers, and identity as=
sertions. <=
u>

            
=C2=A0

            
[Denis] Fine.

            
=C2=A0

            
The protocol will also allow the client to present unverifi=
ed identifiers and verifiable assertions to the AS as part of its request. =


            
=C2=A0

            
[Denis] This sentence is too vague because "=
;as part of its request" is not explicit enough. If it means=C2=A0 &qu=
ot;as part as an access token request" 

            
this should be explicitly said. If, it is not th=
e case, then it should be clearly explained. The AS should know as little a=
s possible (including nothing)

            
about what the client is doing.<=
/u>

            
=C2=A0

            
[Roman] The =E2=80=9Crequest=E2=80=9D here is the =E2=80=
=9Caccess token request=E2=80=9D.=C2=A0 That can be made clearer.
          

        

      

    

    
This would be appreciated.

    

      

        

          

            

            
=C2=A0

            
This protocol will allow an authorizing party to delegate a=
ccess to client software through an authorization server. 

            
=C2=A0

            
[Denis] The word "privacy" is s=
till missing in the charter. "Delegating access to client software thr=
ough an authorization server" 

            
is negating the fact that the user's privacy=
 will ever be considered. IMHO, I believe that a RS may delegate some opera=
tion to another RS, 

            
but I don't believe that an AS should be con=
cerned by any form of delegation, otherwise it would have the ability to ac=
t as "Big Brother".

            
OAuth has not been constructed taking into consi=
deration the user's privacy. The major difference with it should be tha=
t GNAP has been 

            
constructed along "privacy by design=
" principles.

            
=C2=A0

            
[Roman]=C2=A0 I don=E2=80=99t exactly follow how consider=
ations for privacy are being negated.=C2=A0 Above and beyond use-case speci=
fic considerations that would be defined later,=20
RFC6973 is the IETF consensus design guidance that will guide the privacy t=
hreats and mitigations of the work.=C2=A0 What design guidance would you re=
commend that=20
the WG should consider that aren=E2=80=99t captured in RFC6973?

          

        

      

    

    
I believe my message is quite clear : If the AS is handling the
      delegation process, it will know what the client is doing or where
      it is going. 

      On the contrary, if the RS is handling the delegation process, the
      AS will be unable to know what the client is doing. In addition,
      an AS-centric 

      architecture would not be scalable and would need a lot of
      synchronizations between ASs and RSs. The user consent should be
      handled by the RS 

      and not by the AS. When a RS is unable to provide the service, it
      is best placed to tell directly to the client what it could do
      next. 

    

    
RFC 6973 is very good document. Section 7.1 states: 

    

    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 b.=C2=A0 Data.=C2=A0 What informa=
tion does the protocol expose
      about individuals, their devices, and/or their device usage (other
      than the identifiers discussed in (a))? 

    

    
Data includes both the operation and the data associated with the
      operation. An AS should be kept ignorant of both the operation and
      the data associated with the operation.

    

      
c.=C2=A0 Observers.=C2=A0 (...) Are there ways for protocol implem=
enters
        to=C2=A0 choose to limit the information shared with each entity?=
=C2=A0 

      

    

    
If theses guidances were followed, the proposed architecture
      would not be AS-centric.

    

      

        

          

            
=C2=A0

            
It will expand upon the uses cases currently support=
ed by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to su=
pport authorizations 

            
scoped as narrowly as a single transaction, provide a clear=
 framework for interaction among all parties involved in the protocol flow,=
 and remove 

            
unnecessary dependence on a browser or user-agent for coord=
inating interactions.

            
=C2=A0

            
[Denis] There is no need to refer to OAuth 2.0 a=
nd OpenID Connect. Some existing uses cases (i.e. "non-expanded&quo=
t; use cases) should be supported 

            
differently from OAuth 2.0 and OpenID Connect, i=
n particular to support the user's privacy.<=
/pre>
            
=C2=A0

            
[Roman] I=E2=80=99d want to hear others on this rescoping=
.=C2=A0 Building upon the use cases of OAuth 2.0 and OpenID Connect has bee=
n core, consensus-validated tenant for some time now.<=
/pre>
            
=C2=A0

            
The delegation process will be acted upon by multiple parti=
es in the protocol, each performing a specific role. The protocol will deco=
uple the channels used 

            
by the protocol participants to communicate from the delega=
tion channel, which happens directly between the client and the authorizati=
on server (in contrast 

            
with OAuth 2.0, which is initiated by the client redirectin=
g the user=E2=80=99s browser). 

            
=C2=A0

            
[Denis] Here again, the delegation process, if a=
ny, should be handled by RSs and not by ASs. 

            
The term "delegation channel" is being=
 used but it is left undefined. It is not understandable.

            
=C2=A0

            
[Roman] This sentence was just added into -05 address Sec=
urity AD feedback.=C2=A0 In this case, it was made to distinguish between i=
n-band signaling and the new purpose-to-be-built channel.

          

        

      

    

    
Since delegation should not be handled by the AS, a delegation
      channel should not exist.

    

      

        

          

            

            
=C2=A0

            
The protocol will include a means of specifying how the use=
r can potentially be involved in an interactive fashion during the delegati=
on process. 

            
The client and Authorization Server (AS) will use these int=
eraction mechanisms to involve the user, as necessary, to make authorizatio=
n decisions.

            
=C2=A0

            
[Denis] Here again, the delegati=
on process, if any, should be handled by RSs and not by ASs. The AS should =
know as little as possible (including nothing)<=
/pre>
            
about what the client is doing.<=
/u>

            
=C2=A0

            
[Roman] Understood =E2=80=93 as I understand it, you have=
 concern with the scope of the AS behavior.=C2=A0 I=E2=80=99d be interestin=
g in hearing additional support for this rescoping.=C2=A0 

            
=C2=A0

            
This decoupling avoids many of the security concerns and te=
chnical challenges of OAuth 2.0 and provides a non-invasive path for suppor=
ting future types 

            
of clients and interaction channels.
            
=C2=A0

            
[Denis] This is not understandable to me. Is suc=
h a sentence really needed in a charter ?

            
=C2=A0

            
[Roman] Can someone on the TxAuth mailing list remind us =
on why this sentence is here?=C2=A0 With a fresh read, I also can=E2=80=99t=
 remember why we need it.

            
=C2=A0

            
The group will define interoperability for this protocol be=
tween different parties, including

            
-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client and authorization server;

            
-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client and resource server; and=


            
=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 au=
thorization server and resource server.

            
=C2=A0

            
[Denis] In order to support the user's priva=
cy, there should be no interaction at all between an authorization server a=
nd a resource server 

            
at the time of a client request.

            
=C2=A0

            
The group will seek to minimize assumptions about the form =
of client applications, allowing for:

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Fine-grained specification of access

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Approval of AS attestation to identifiers and other iden=
tity claims

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Approval of access to multiple resources and APIs in a s=
ingle interaction

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Multiple access tokens in a single request and response<=
/span>

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 AS-directed dispatch of access tokens to the appropriate=
 RS

            
[Denis] As-directed d=
ispatch does not allow to support the user's privacy. However, RS-direc=
ted dispatch allows to support the user's privacy.=


            
It should be explicit=
ly mentioned.

            
[Roman] As above (per the AS v=
s. RS behavior)

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Separation between the party authorizing access and the =
party operating the client requesting access 

            
=C2=A0

            
[Denis] It is questionable whether s=
uch a separation would be really beneficial. In doubt, this item should be =
removed.

            
[Roman] Could you say more on =
why this flexibility wouldn=E2=80=99t be worth it?=C2=A0 

          

        

      

    

    
Except for added complexity, there is no need to have separate
      channels. It is simpler to send the access token in addition to
      the data 

      and, for additional security, to sign the data using a private key
      corresponding to a public key present in the access token.

    

      

        

          

            

            
The group will define extension points for this =
protocol to allow for flexibility in areas including:<=
/pre>
            
=C2=A0

            
Cryptographic agility for keys, message signatur=
es, and proof of possession

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 User interaction mechanisms including web and non-web me=
thods

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Mechanisms for conveying user, software, organization, a=
nd other information used in authorization decisions <=
/pre>
            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Mechanisms for presenting tokens to resource servers and=
 binding resource requests to tokens and associated cryptographic keys 

            
Optimized inclusion of additional information (including id=
entifiers and identity assertions) through the delegation process 

            
=C2=A0

            
Additionally, the group will provide mechanisms for managem=
ent of the protocol lifecycle including:

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Discovery of the authorization server

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Revocation of active tokens

            
Data model for granted access and mechanisms for the AS and=
 RS to communicate the granted access model

            
=C2=A0

            
[Denis] While it is the duty for the RS to commu=
nicate the granted access model to the client at the appropriate instant=
 of time, 

            
the AS should be kept fully ignorant of it.

            
=C2=A0

            
Although the artifacts for this work are not intended or ex=
pected to be backwards-compatible with OAuth 2.0 or OpenID Connect, =


            
the group will attempt to simplify migrating from OAuth 2.0=
 and OpenID Connect to the new protocol where possible.

            
=C2=A0

            
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. Functionality that builds direct=
ly on OAuth 2.0 will be directed to the OAuth Working Group, including <=
/u>

            
functionality back-ported from the protocol developed here =
to OAuth 2.0.

            
=C2=A0

            
The group is chartered to develop mechanisms for applying c=
ryptographic methods, such as JOSE and COSE, to the delegation process. =


            
This group is not chartered to develop new cryptographic me=
thods.

            
=C2=A0

            
The group is chartered to develop mechanisms for conveying =
identity information within the protocol including existing identifiers =


            
(such as email addresses, phone numbers, usernames, and sub=
ject identifiers) and assertions (such as OpenID Connect ID Tokens, =


            
SAML Assertions, and Verifiable Credentials). The group is =
not chartered to develop new formats for identifiers or assertions, nor is =
the group 

            
chartered to develop schemas for user information, profiles=
, or other identity attributes, unless a viable existing format is not avai=
lable.

            
=C2=A0

            
The initial work will focus on using HTTPS for communicatio=
n between the client and the authorization server, taking advantage =


            
of optimization features of HTTP/2 and HTTP/3 where possibl=
e, and will strive to enable simple mapping to other protocols such as COAP=
 

            
when doing so does not conflict with the primary focus.<=
/u>

            
=C2=A0

            
Milestones to include:

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Core delegation protocol

            
[Denis] Before defini=
ng a "Core delegation protocol", a simple client server-protocol =
involving the presentation of several access tokens to one RS should be def=
ined. 

            
Privacy principles sh=
ould be applied when defining the protocol. Then after, a delegation mechan=
ism allowing one RS to forward an operation to another RS should be defined=
.

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Key presentation mechanism bindings to the core protocol=
 including TLS, detached HTTP signature, and embedded HTTP signatures 

            
[Denis] Bindings to T=
LS are now deprecated, why should they be maintained ? 

            
Signatures may be nee=
ded but they do not necessarily need to be "detached HTTP signature, a=
nd embedded HTTP signatures". 

            
This item should be e=
ither removed or reworded.

            
[Roman] Noted.=C2=A0 I=E2=80=
=99d want to hear others on this rescoping.

          

        

      

    

    
As explained above, it is possible to sign the data using a
      private key corresponding to a public key present in the access
      token.

    

      

        

          

            

            
=C2=A0
            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Conveyance mechanisms for identifiers and assertions 

            
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Guidelines for use of protocol extension points (if need=
ed) 

            
=C2=A0=C2=A0=C2=A0=C2=A0
                -=C2=A0=C2=A0=C2=A0 Guidelines on migration paths, implemen=
tation, and
                operations
              

            
[Denis] The
                above three lines are rather mysterious.

            
[Roman]
              The guidelines on migration paths came from the initial
              IESG review in order to have a named activity to action
              the design goal of =E2=80=9C=E2=80=A6 the group will attempt =
to simplify
              migrating from OAuth 2.0 and OpenID Connect to the new
              protocol where possible=E2=80=9D a bit earlier in the text.

            
Where
                possible, the group will seek to make use of tools to
                guide and inform the standardization process including
                formal analysis,
                

                architecture documents, and use case documents. These
                artifacts will not be considered as working group
                milestones or deliverables.

            
The
                working group will cooperate and coordinate with other
                IETF WGs such as OAUTH, and work with external
                organizations,
                

                such as the OpenID Foundation, as appropriate.

            
[Denis]
                The charter should be shorter.

            
=C2=A0

            
[Roman] Definitely.=C2=A0 Nevertheless, =
we
              have the current text through rough consensus process
              achieved from two BoFs and multiple mailing list consensus
              calls.

          

        

      

    

    
In a previous post, I proposed a much shorter text.

    
Denis

    

    

      

        

          

            

            
=C2=A0

            
Regards,

            
Roman 

          

          

            
=C2=A0

          

          

            
/Denis

          

          

            
=C2=A0

          

          

            
A new IETF WG has been proposed in the Security Area. The =
IESG has not made

            
any determination yet. The following draft charter was sub=
mitted, and is

            
provided for informational purposes only. Please send your=
 comments to the

            
IESG mailing list (iesg@ietf.org) by 2020-07-06.<=
/u>

            
=C2=A0

            
Grant Negotiation and Authorization Protocol (gnap)=


            
----------------------------------------------------------=
-------------

            
Current status: Proposed WG

            
=C2=A0

            
Chairs:

            
=C2=A0 Yaron Sheffer <yaronf.ietf@gmail.com><=
u>

            
=C2=A0 Leif Johansson <leifj@sunet.se>=


            
=C2=A0

            
Assigned Area Director:

            
=C2=A0 Roman Danyliw <rdd@cert.org>
            
=C2=A0

            
Security Area Directors:

            
=C2=A0 Benjamin Kaduk <kaduk@mit.edu>
            
=C2=A0 Roman Danyliw <rdd@cert.org>
            
=C2=A0

            
Mailing list:

            
=C2=A0 Address: txauth@ietf.org

            
=C2=A0 To subscribe: =E2=80=8Bhttps://www.ietf.o=
rg/mailman/listinfo/txauth

            
=C2=A0 Archive: https://mailarchive=
.ietf.org/arch/browse/txauth/

            
=C2=A0

            
Group page: https://datatracker.ietf.org/gr=
oup/gnap/

            
=C2=A0

            
Charter: https://datatracker.iet=
f.org/doc/charter-ietf-gnap/

            
=C2=A0

            
This group is chartered to develop a fine-grained delegati=
on protocol for

            
authorization and API access, as well as requesting and pr=
oviding user

            
identifiers and claims. This protocol will allow an author=
izing party to

            
delegate access to client software through an authorizatio=
n server. It will

            
expand upon the uses cases currently supported by OAuth 2.=
0 and OpenID Connect

            
(itself an extension of OAuth 2.0) to support authorizatio=
ns scoped as

            
narrowly as a single transaction, provide a clear framewor=
k for interaction

            
among all parties involved in the protocol flow, and remov=
e unnecessary

            
dependence on a browser or user-agent for coordinating int=
eractions.

            
=C2=A0

            
The delegation process will be acted upon by multiple part=
ies in the protocol,

            
each performing a specific role. The protocol will decoupl=
e the interaction

            
channels, such as the end user=E2=80=99s browser, from the=
 delegation channel, which

            
happens directly between the client and the authorization =
server (in contrast

            
with OAuth 2.0, which is initiated by the client redirecti=
ng the user=E2=80=99s

            
browser). The protocol will include a means of specifying =
how the user can

            
potentially be involved in an interactive fashion during t=
he delegation

            
process. The client and Authorization Server (AS) will use=
 these interaction

            
mechanisms to involve the user, as necessary, to make auth=
orization decisions.

            
This decoupling avoids many of the security concerns and t=
echnical challenges

            
of OAuth 2.0 and provides a non-invasive path for supporti=
ng future types of

            
clients and interaction channels.

            
=C2=A0

            
The group will define interoperability for this protocol b=
etween different

            
parties, including

            
 - client and authorization server;

            
 - client and resource server; and

            
 - authorization server and resource server.=


            
=C2=A0

            
The group will seek to minimize assumptions about the form=
 of client

            
applications, allowing for:

            
- Fine-grained specification of access

            
- Approval of AS attestation to identifiers and other iden=
tity claims

            
- Approval of access to multiple resources and APIs in a s=
ingle interaction

            
- Support for multiple access tokens in a single request a=
nd response

            
- Support for directed, audience-restricted access tokens<=
u>

            
- Separation between the party authorizing access and the =
party operating the

            
client requesting access

            
=C2=A0

            
The group will define extension points for this protocol t=
o allow for

            
flexibility in areas including:

            
=C2=A0

            
- Cryptographic agility for keys, message signatures, and =
proof of possession

            
- User interaction mechanisms including web and non-web me=
thods

            
- Mechanisms for conveying user, software, organization, a=
nd other

            
information used in authorization decisions<=
/pre>
            
- Mechanisms for presenting tokens to resource servers and=
 binding resource

            
requests to tokens and associated cryptographic keys

            
- Optimized inclusion of additional information (including=
 identifiers and

            
identity assertions) through the delegation process=


            
=C2=A0

            
Additionally, the group will provide mechanisms for manage=
ment of the protocol

            
lifecycle including:

            
=C2=A0

            
- Discovery of the authorization server
            
- Revocation of active tokens

            
- Mechanisms for the AS and RS to communicate the access g=
ranted by an access

            
token

            
=C2=A0

            
Although the artifacts for this work are not intended or e=
xpected to be

            
backwards-compatible with OAuth 2.0 or OpenID Connect, the=
 group will attempt

            
to simplify migrating from OAuth 2.0 and OpenID Connect to=
 the new protocol

            
where possible.

            
=C2=A0

            
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. Functionality that builds directly on OAuth 2.0=
 will be directed

            
to the OAuth Working Group, including functionality back-p=
orted from the

            
protocol developed here to OAuth 2.0.

            
=C2=A0

            
The group is chartered to develop mechanisms for applying =
cryptographic

            
methods, such as JOSE and COSE, to the delegation process.=
 This group is not

            
chartered to develop new cryptographic methods.<=
/u>

            
=C2=A0

            
The group is chartered to develop mechanisms for conveying=
 identity

            
information within the protocol including existing identif=
iers (such as email

            
addresses, phone numbers, usernames, and subject identifie=
rs) and assertions

            
(such as OpenID Connect ID Tokens, SAML Assertions, and Ve=
rifiable

            
Credentials). The group is not chartered to develop new fo=
rmats for

            
identifiers or assertions, nor is the group chartered to d=
evelop schemas for

            
user information, profiles, or other identity attributes, =
unless a viable

            
existing format is not available.

            
=C2=A0

            
The initial work will focus on using HTTPS for communicati=
on between the

            
client and the authorization server, taking advantage of o=
ptimization

            
features of HTTP/2 and HTTP/3 where possible, and will str=
ive to enable

            
simple mapping to other protocols such as COAP when doing =
so does not

            
conflict with the primary focus.

            
=C2=A0

            
Milestones to include:

            
- Core delegation protocol

            
- Key presentation mechanism bindings to the core protocol=
 including TLS,

            
detached HTTP signature, and embedded HTTP signatures

            
- Conveyance mechanisms for identifiers and assertions<=
/u>

            
- Guidelines for use of protocol extension points

            
- (if needed) Guidelines on migration paths, implementatio=
n, and operations

            
=C2=A0

            
Where possible, the group will seek to make use of tools t=
o guide and inform

            
the standardization process including formal analysis, arc=
hitecture documents,

            
and use case documents. These artifacts will not be consid=
ered as working

            
group milestones or deliverables.

            
=C2=A0

            
The working group will cooperate and coordinate with other=
 IETF WGs such as

            
OAUTH, and work with external organizations, such as the O=
penID Foundation,

            
as appropriate.

            
=C2=A0

            
Milestones:

            
=C2=A0

            
=C2=A0 Jul 2021 - Core delegation protocol in WGLC<=
u>

            
=C2=A0

            
=C2=A0 Oct 2021 - Key presentation mechanism binding to th=
e core protocol, TLS, to

            
=C2=A0 WGLC

            
=C2=A0

            
=C2=A0 Oct 2021 - Key presentation mechanism binding to th=
e core protocol, 

            
=C2=A0=C2=A0detached HTTP signatures, to WGLC

            
=C2=A0

            
=C2=A0 Oct 2021 - Key presentation mechanism binding to th=
e core protocol,

            
=C2=A0 embedded HTTP signature, to WGLC
            
=C2=A0

            
=C2=A0 Dec 2021 - Guidelines for use of protocol extension=
 points to WGLC

            
=C2=A0

            
=C2=A0 Feb 2022 - Guidelines on migration paths, implement=
ation, and operations to

            
=C2=A0=C2=A0 WGLC

            
=C2=A0

            
=C2=A0

            
=C2=A0

          

          
=C2=A0

        

      

    

    


    

  


-- 

Txauth mailing list

Txa=
uth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth<=
/a>




--000000000000484c8e05a9dba517--


From nobody Tue Jul  7 09:04: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 C68283A0F58; Tue,  7 Jul 2020 09:04:15 -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_FILL_THIS_FORM_SHORT=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 yosihyiBc_kF; Tue,  7 Jul 2020 09:03:38 -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 932323A0F33; Tue,  7 Jul 2020 09:03:37 -0700 (PDT)
Received: from [192.168.1.7] (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 067G3Uiq009549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Jul 2020 12:03:30 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_B5C4130C-DE2A-4822-ACC9-7A01F90B9459"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 7 Jul 2020 12:03:30 -0400
In-Reply-To: <36de4e6a-41fe-81b1-6c92-69fe5b63ad6f@free.fr>
Cc: "rdd@cert.org" , "iesg@ietf.org" , "txauth@ietf.org" 
To: Denis 
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <7563640e-f515-3e73-a4eb-3902ec7af50e@free.fr> <3424311c60f541b197cfda6e9f3b494e@cert.org> <36de4e6a-41fe-81b1-6c92-69fe5b63ad6f@free.fr>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 07 Jul 2020 16:04:17 -0000

--Apple-Mail=_B5C4130C-DE2A-4822-ACC9-7A01F90B9459
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Denis,

A lot of what you=E2=80=99re describing below changes the very nature of =
the roles in the system. The component that manages the consent and =
issues tokens is, by definition, the AS. The user shouldn=E2=80=99t ever =
have to interact directly with the RS, since the RS is, by definition, =
an API that is called by software, not an interactive component.=20

But it=E2=80=99s important to note that these are only :roles: to be =
played and not strictly speaking separate pieces of software, and that =
these roles can be combined and split in a variety of ways. For =
instance, in what you=E2=80=99re talking about below, instead of saying =
that it=E2=80=99s the RS that manages the consent, what if you saw it as =
the functionality of the AS that=E2=80=99s been split between two =
components: one privacy-preserving element that issues tokens, and =
another that deals with interaction and consent. This is already a =
pattern that some in the WG have expressed interest in supporting with =
GNAP, and the core charter tenet of separating the interaction from the =
delegation channels is something that could help there.=20

Would it be possible to look at your use case in this different light? =
It=E2=80=99s always possible that we need to re-cast some of these =
roles, and that=E2=80=99s been done before: in OAuth 2 we defined the AS =
and RS roles separately, even though they can always be deployed =
together anyway. So with that it=E2=80=99s possible that there are other =
distinct pieces here that are working together that we need to tease =
out, but that=E2=80=99s something for the WG to figure out. We can =
always decide to separate out the parts and allow them to be recombined =
in deployment, But I do not think it is helpful to redefine the existing =
roles, especially by moving key facets from one existing role to =
another.

 =E2=80=94 Justin

> On Jul 7, 2020, at 8:43 AM, Denis  wrote:
>=20
> Hi Roman,
>> Hi Denis!
>> =20
>> Thanks for the feedback and for repeating your review on the revised =
text.  More inline =E2=80=A6
>> =20
>> From: iesg   On =
Behalf Of Denis
>> Sent: Monday, July 6, 2020 10:55 AM
>> To: iesg@ietf.org 
>> Cc: txauth@ietf.org 
>> Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization =
Protocol (gnap)
>> =20
>> Since it is today the last day to send back comments, you will find =
hereafter my comments on the last charter version-05.
> BTW, I sent an email yesterday evening with the subject: Support of =
FIDO and data minimization by RSs, where I indicated that the charter =
should=20
> mention FIDO U2F so that it should be possible to logon to a RS using =
either FIDO or by presenting one (or more) access tokens from one (or =
more) AS.
>=20
> The original email is here : =
https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/ =
charter-ietf-gnap-00-05
>>=20
>> This group is chartered to develop a fine-grained delegation protocol =
for authorization, API access, user identifiers, and identity =
assertions.=20
>> =20
>> [Denis] Fine.
>> =20
>> The protocol will also allow the client to present unverified =
identifiers and verifiable assertions to the AS as part of its request.=20=

>> =20
>> [Denis] This sentence is too vague because "as part of its request" =
is not explicit enough. If it means  "as part as an access token =
request"=20
>> this should be explicitly said. If, it is not the case, then it =
should be clearly explained. The AS should know as little as possible =
(including nothing)
>> about what the client is doing.
>> =20
>> [Roman] The =E2=80=9Crequest=E2=80=9D here is the =E2=80=9Caccess =
token request=E2=80=9D.  That can be made clearer.
> This would be appreciated.
>=20
>> =20
>> This protocol will allow an authorizing party to delegate access to =
client software through an authorization server.=20
>> =20
>> [Denis] The word "privacy" is still missing in the charter. =
"Delegating access to client software through an authorization server"=20=

>> is negating the fact that the user's privacy will ever be considered. =
IMHO, I believe that a RS may delegate some operation to another RS,=20
>> but I don't believe that an AS should be concerned by any form of =
delegation, otherwise it would have the ability to act as "Big Brother".
>> OAuth has not been constructed taking into consideration the user's =
privacy. The major difference with it should be that GNAP has been=20
>> constructed along "privacy by design" principles.
>> =20
>> [Roman]  I don=E2=80=99t exactly follow how considerations for =
privacy are being negated.  Above and beyond use-case specific =
considerations that would be defined later,=20
>> RFC6973 is the IETF consensus design guidance that will guide the =
privacy threats and mitigations of the work.  What design guidance would =
you recommend that=20
>> the WG should consider that aren=E2=80=99t captured in RFC6973?
> I believe my message is quite clear : If the AS is handling the =
delegation process, it will know what the client is doing or where it is =
going.=20
> On the contrary, if the RS is handling the delegation process, the AS =
will be unable to know what the client is doing. In addition, an =
AS-centric=20
> architecture would not be scalable and would need a lot of =
synchronizations between ASs and RSs. The user consent should be handled =
by the RS=20
> and not by the AS. When a RS is unable to provide the service, it is =
best placed to tell directly to the client what it could do next.=20
>=20
> RFC 6973 is very good document. Section 7.1 states:=20
>=20
>           b.  Data.  What information does the protocol expose about =
individuals, their devices, and/or their device usage (other than the =
identifiers discussed in (a))?=20
>=20
> Data includes both the operation and the data associated with the =
operation. An AS should be kept ignorant of both the operation and the =
data associated with the operation.
>=20
> c.  Observers.  (...) Are there ways for protocol implementers to  =
choose to limit the information shared with each entity? =20
>=20
> If theses guidances were followed, the proposed architecture would not =
be AS-centric.
>=20
>> =20
>> It will expand upon the uses cases currently supported by OAuth 2.0 =
and OpenID Connect (itself an extension of OAuth 2.0) to support =
authorizations=20
>> scoped as narrowly as a single transaction, provide a clear framework =
for interaction among all parties involved in the protocol flow, and =
remove=20
>> unnecessary dependence on a browser or user-agent for coordinating =
interactions.
>> =20
>> [Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. =
Some existing uses cases (i.e. "non-expanded" use cases) should be =
supported=20
>> differently from OAuth 2.0 and OpenID Connect, in particular to =
support the user's privacy.
>> =20
>> [Roman] I=E2=80=99d want to hear others on this rescoping.  Building =
upon the use cases of OAuth 2.0 and OpenID Connect has been core, =
consensus-validated tenant for some time now.
>> =20
>> The delegation process will be acted upon by multiple parties in the =
protocol, each performing a specific role. The protocol will decouple =
the channels used=20
>> by the protocol participants to communicate from the delegation =
channel, which happens directly between the client and the authorization =
server (in contrast=20
>> with OAuth 2.0, which is initiated by the client redirecting the =
user=E2=80=99s browser).=20
>> =20
>> [Denis] Here again, the delegation process, if any, should be handled =
by RSs and not by ASs.=20
>> The term "delegation channel" is being used but it is left undefined. =
It is not understandable.
>> =20
>> [Roman] This sentence was just added into -05 address Security AD =
feedback.  In this case, it was made to distinguish between in-band =
signaling and the new purpose-to-be-built channel.
> Since delegation should not be handled by the AS, a delegation channel =
should not exist.
>=20
>> =20
>> The protocol will include a means of specifying how the user can =
potentially be involved in an interactive fashion during the delegation =
process.=20
>> The client and Authorization Server (AS) will use these interaction =
mechanisms to involve the user, as necessary, to make authorization =
decisions.
>> =20
>> [Denis] Here again, the delegation process, if any, should be handled =
by RSs and not by ASs. The AS should know as little as possible =
(including nothing)
>> about what the client is doing.
>> =20
>> [Roman] Understood =E2=80=93 as I understand it, you have concern =
with the scope of the AS behavior.  I=E2=80=99d be interesting in =
hearing additional support for this rescoping. =20
>> =20
>> This decoupling avoids many of the security concerns and technical =
challenges of OAuth 2.0 and provides a non-invasive path for supporting =
future types=20
>> of clients and interaction channels.
>> =20
>> [Denis] This is not understandable to me. Is such a sentence really =
needed in a charter ?
>> =20
>> [Roman] Can someone on the TxAuth mailing list remind us on why this =
sentence is here?  With a fresh read, I also can=E2=80=99t remember why =
we need it.
>> =20
>> The group will define interoperability for this protocol between =
different parties, including
>> -          client and authorization server;
>> -          client and resource server; and
>>      -      authorization server and resource server.
>> =20
>> [Denis] In order to support the user's privacy, there should be no =
interaction at all between an authorization server and a resource server=20=

>> at the time of a client request.
>> =20
>> The group will seek to minimize assumptions about the form of client =
applications, allowing for:
>> -          Fine-grained specification of access
>> -          Approval of AS attestation to identifiers and other =
identity claims
>> -          Approval of access to multiple resources and APIs in a =
single interaction
>> -          Multiple access tokens in a single request and response
>> -          AS-directed dispatch of access tokens to the appropriate =
RS
>> [Denis] As-directed dispatch does not allow to support the user's =
privacy. However, RS-directed dispatch allows to support the user's =
privacy.
>> It should be explicitly mentioned.
>> [Roman] As above (per the AS vs. RS behavior)
>> -          Separation between the party authorizing access and the =
party operating the client requesting access=20
>> =20
>> [Denis] It is questionable whether such a separation would be really =
beneficial. In doubt, this item should be removed.
>> [Roman] Could you say more on why this flexibility wouldn=E2=80=99t =
be worth it? =20
> Except for added complexity, there is no need to have separate =
channels. It is simpler to send the access token in addition to the data=20=

> and, for additional security, to sign the data using a private key =
corresponding to a public key present in the access token.
>=20
>> The group will define extension points for this protocol to allow for =
flexibility in areas including:
>> =20
>> Cryptographic agility for keys, message signatures, and proof of =
possession
>> -          User interaction mechanisms including web and non-web =
methods
>> -          Mechanisms for conveying user, software, organization, and =
other information used in authorization decisions=20
>> -          Mechanisms for presenting tokens to resource servers and =
binding resource requests to tokens and associated cryptographic keys=20
>> Optimized inclusion of additional information (including identifiers =
and identity assertions) through the delegation process=20
>> =20
>> Additionally, the group will provide mechanisms for management of the =
protocol lifecycle including:
>> -          Discovery of the authorization server
>> -          Revocation of active tokens
>> Data model for granted access and mechanisms for the AS and RS to =
communicate the granted access model
>> =20
>> [Denis] While it is the duty for the RS to communicate the granted =
access model to the client at the appropriate instant of time,=20
>> the AS should be kept fully ignorant of it.
>> =20
>> Although the artifacts for this work are not intended or expected to =
be backwards-compatible with OAuth 2.0 or OpenID Connect,=20
>> the group will attempt to simplify migrating from OAuth 2.0 and =
OpenID Connect to the new protocol where possible.
>> =20
>> This group is not chartered to develop extensions to OAuth 2.0, and =
as such will focus on new technological solutions not necessarily=20
>> compatible with OAuth 2.0. Functionality that builds directly on =
OAuth 2.0 will be directed to the OAuth Working Group, including=20
>> functionality back-ported from the protocol developed here to OAuth =
2.0.
>> =20
>> The group is chartered to develop mechanisms for applying =
cryptographic methods, such as JOSE and COSE, to the delegation process.=20=

>> This group is not chartered to develop new cryptographic methods.
>> =20
>> The group is chartered to develop mechanisms for conveying identity =
information within the protocol including existing identifiers=20
>> (such as email addresses, phone numbers, usernames, and subject =
identifiers) and assertions (such as OpenID Connect ID Tokens,=20
>> SAML Assertions, and Verifiable Credentials). The group is not =
chartered to develop new formats for identifiers or assertions, nor is =
the group=20
>> chartered to develop schemas for user information, profiles, or other =
identity attributes, unless a viable existing format is not available.
>> =20
>> The initial work will focus on using HTTPS for communication between =
the client and the authorization server, taking advantage=20
>> of optimization features of HTTP/2 and HTTP/3 where possible, and =
will strive to enable simple mapping to other protocols such as COAP=20
>> when doing so does not conflict with the primary focus.
>> =20
>> Milestones to include:
>> -          Core delegation protocol
>> [Denis] Before defining a "Core delegation protocol", a simple client =
server-protocol involving the presentation of several access tokens to =
one RS should be defined.=20
>> Privacy principles should be applied when defining the protocol. Then =
after, a delegation mechanism allowing one RS to forward an operation to =
another RS should be defined.
>> -          Key presentation mechanism bindings to the core protocol =
including TLS, detached HTTP signature, and embedded HTTP signatures=20
>> [Denis] Bindings to TLS are now deprecated, why should they be =
maintained ?=20
>> Signatures may be needed but they do not necessarily need to be =
"detached HTTP signature, and embedded HTTP signatures".=20
>> This item should be either removed or reworded.
>> [Roman] Noted.  I=E2=80=99d want to hear others on this rescoping.
> As explained above, it is possible to sign the data using a private =
key corresponding to a public key present in the access token.
>=20
>> =20
>> -          Conveyance mechanisms for identifiers and assertions=20
>> -          Guidelines for use of protocol extension points (if =
needed)=20
>>      -    Guidelines on migration paths, implementation, and =
operations
>> [Denis] The above three lines are rather mysterious.
>> [Roman] The guidelines on migration paths came from the initial IESG =
review in order to have a named activity to action the design goal of =
=E2=80=9C=E2=80=A6 the group will attempt to simplify migrating from =
OAuth 2.0 and OpenID Connect to the new protocol where possible=E2=80=9D =
a bit earlier in the text.
>> Where possible, the group will seek to make use of tools to guide and =
inform the standardization process including formal analysis,=20
>> architecture documents, and use case documents. These artifacts will =
not be considered as working group milestones or deliverables.
>> The working group will cooperate and coordinate with other IETF WGs =
such as OAUTH, and work with external organizations,=20
>> such as the OpenID Foundation, as appropriate.
>> [Denis] The charter should be shorter.
>> =20
>> [Roman] Definitely.  Nevertheless, we have the current text through =
rough consensus process achieved from two BoFs and multiple mailing list =
consensus calls.
> In a previous post, I proposed a much shorter text.
>=20
> Denis
>=20
>> =20
>> Regards,
>> Roman=20
>> =20
>> /Denis
>> =20
>> A new IETF WG has been proposed in the Security Area. The IESG has =
not made
>> any determination yet. The following draft charter was submitted, and =
is
>> provided for informational purposes only. Please send your comments =
to the
>> IESG mailing list (iesg@ietf.org ) by =
2020-07-06.
>> =20
>> Grant Negotiation and Authorization Protocol (gnap)
>> =
-----------------------------------------------------------------------
>> Current status: Proposed WG
>> =20
>> Chairs:
>>   Yaron Sheffer  =

>>   Leif Johansson  
>> =20
>> Assigned Area Director:
>>   Roman Danyliw  
>> =20
>> Security Area Directors:
>>   Benjamin Kaduk  
>>   Roman Danyliw  
>> =20
>> Mailing list:
>>   Address: txauth@ietf.org 
>>   To subscribe: =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/txauth =

>>   Archive: https://mailarchive.ietf.org/arch/browse/txauth/ =

>> =20
>> Group page: https://datatracker.ietf.org/group/gnap/ =

>> =20
>> Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/ =

>> =20
>> This group is chartered to develop a fine-grained delegation protocol =
for
>> authorization and API access, as well as requesting and providing =
user
>> identifiers and claims. This protocol will allow an authorizing party =
to
>> delegate access to client software through an authorization server. =
It will
>> expand upon the uses cases currently supported by OAuth 2.0 and =
OpenID Connect
>> (itself an extension of OAuth 2.0) to support authorizations scoped =
as
>> narrowly as a single transaction, provide a clear framework for =
interaction
>> among all parties involved in the protocol flow, and remove =
unnecessary
>> dependence on a browser or user-agent for coordinating interactions.
>> =20
>> The delegation process will be acted upon by multiple parties in the =
protocol,
>> each performing a specific role. The protocol will decouple the =
interaction
>> channels, such as the end user=E2=80=99s browser, from the delegation =
channel, which
>> happens directly between the client and the authorization server (in =
contrast
>> with OAuth 2.0, which is initiated by the client redirecting the =
user=E2=80=99s
>> browser). The protocol will include a means of specifying how the =
user can
>> potentially be involved in an interactive fashion during the =
delegation
>> process. The client and Authorization Server (AS) will use these =
interaction
>> mechanisms to involve the user, as necessary, to make authorization =
decisions.
>> This decoupling avoids many of the security concerns and technical =
challenges
>> of OAuth 2.0 and provides a non-invasive path for supporting future =
types of
>> clients and interaction channels.
>> =20
>> The group will define interoperability for this protocol between =
different
>> parties, including
>>  - client and authorization server;
>>  - client and resource server; and
>>  - authorization server and resource server.
>> =20
>> The group will seek to minimize assumptions about the form of client
>> applications, allowing for:
>> - Fine-grained specification of access
>> - Approval of AS attestation to identifiers and other identity claims
>> - Approval of access to multiple resources and APIs in a single =
interaction
>> - Support for multiple access tokens in a single request and response
>> - Support for directed, audience-restricted access tokens
>> - Separation between the party authorizing access and the party =
operating the
>> client requesting access
>> =20
>> The group will define extension points for this protocol to allow for
>> flexibility in areas including:
>> =20
>> - Cryptographic agility for keys, message signatures, and proof of =
possession
>> - User interaction mechanisms including web and non-web methods
>> - Mechanisms for conveying user, software, organization, and other
>> information used in authorization decisions
>> - Mechanisms for presenting tokens to resource servers and binding =
resource
>> requests to tokens and associated cryptographic keys
>> - Optimized inclusion of additional information (including =
identifiers and
>> identity assertions) through the delegation process
>> =20
>> Additionally, the group will provide mechanisms for management of the =
protocol
>> lifecycle including:
>> =20
>> - Discovery of the authorization server
>> - Revocation of active tokens
>> - Mechanisms for the AS and RS to communicate the access granted by =
an access
>> token
>> =20
>> Although the artifacts for this work are not intended or expected to =
be
>> backwards-compatible with OAuth 2.0 or OpenID Connect, the group will =
attempt
>> to simplify migrating from OAuth 2.0 and OpenID Connect to the new =
protocol
>> where possible.
>> =20
>> 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. Functionality that builds directly on OAuth 2.0 will be =
directed
>> to the OAuth Working Group, including functionality back-ported from =
the
>> protocol developed here to OAuth 2.0.
>> =20
>> The group is chartered to develop mechanisms for applying =
cryptographic
>> methods, such as JOSE and COSE, to the delegation process. This group =
is not
>> chartered to develop new cryptographic methods.
>> =20
>> The group is chartered to develop mechanisms for conveying identity
>> information within the protocol including existing identifiers (such =
as email
>> addresses, phone numbers, usernames, and subject identifiers) and =
assertions
>> (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
>> Credentials). The group is not chartered to develop new formats for
>> identifiers or assertions, nor is the group chartered to develop =
schemas for
>> user information, profiles, or other identity attributes, unless a =
viable
>> existing format is not available.
>> =20
>> The initial work will focus on using HTTPS for communication between =
the
>> client and the authorization server, taking advantage of optimization
>> features of HTTP/2 and HTTP/3 where possible, and will strive to =
enable
>> simple mapping to other protocols such as COAP when doing so does not
>> conflict with the primary focus.
>> =20
>> Milestones to include:
>> - Core delegation protocol
>> - Key presentation mechanism bindings to the core protocol including =
TLS,
>> detached HTTP signature, and embedded HTTP signatures
>> - Conveyance mechanisms for identifiers and assertions
>> - Guidelines for use of protocol extension points
>> - (if needed) Guidelines on migration paths, implementation, and =
operations
>> =20
>> Where possible, the group will seek to make use of tools to guide and =
inform
>> the standardization process including formal analysis, architecture =
documents,
>> and use case documents. These artifacts will not be considered as =
working
>> group milestones or deliverables.
>> =20
>> The working group will cooperate and coordinate with other IETF WGs =
such as
>> OAUTH, and work with external organizations, such as the OpenID =
Foundation,
>> as appropriate.
>> =20
>> Milestones:
>> =20
>>   Jul 2021 - Core delegation protocol in WGLC
>> =20
>>   Oct 2021 - Key presentation mechanism binding to the core protocol, =
TLS, to
>>   WGLC
>> =20
>>   Oct 2021 - Key presentation mechanism binding to the core protocol,=20=

>>   detached HTTP signatures, to WGLC
>> =20
>>   Oct 2021 - Key presentation mechanism binding to the core protocol,
>>   embedded HTTP signature, to WGLC
>> =20
>>   Dec 2021 - Guidelines for use of protocol extension points to WGLC
>> =20
>>   Feb 2022 - Guidelines on migration paths, implementation, and =
operations to
>>    WGLC
>> =20
>> =20
>> =20
>> =20
>>=20
>=20
> --=20
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth


--Apple-Mail=_B5C4130C-DE2A-4822-ACC9-7A01F90B9459
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Denis,

A =
lot of what you=E2=80=99re describing below changes the very nature of =
the roles in the system. The component that manages the consent and =
issues tokens is, by definition, the AS. The user shouldn=E2=80=99t ever =
have to interact directly with the RS, since the RS is, by definition, =
an API that is called by software, not an interactive =
component. 

But it=E2=80=99s important to note that these are only =
:roles: to be played and not strictly speaking separate pieces of =
software, and that these roles can be combined and split in a variety of =
ways. For instance, in what you=E2=80=99re talking about below, instead =
of saying that it=E2=80=99s the RS that manages the consent, what if you =
saw it as the functionality of the AS that=E2=80=99s been split between =
two components: one privacy-preserving element that issues tokens, and =
another that deals with interaction and consent. This is already a =
pattern that some in the WG have expressed interest in supporting with =
GNAP, and the core charter tenet of separating the interaction from the =
delegation channels is something that could help there. 

Would it be possible to =
look at your use case in this different light? It=E2=80=99s always =
possible that we need to re-cast some of these roles, and that=E2=80=99s =
been done before: in OAuth 2 we defined the AS and RS roles separately, =
even though they can always be deployed together anyway. So with that =
it=E2=80=99s possible that there are other distinct pieces here that are =
working together that we need to tease out, but that=E2=80=99s something =
for the WG to figure out. We can always decide to separate out the parts =
and allow them to be recombined in deployment, But I do not think it is =
helpful to redefine the existing roles, especially by moving key facets =
from one existing role to another.

 =E2=80=94 Justin

On Jul 7, 2020, at 8:43 AM, Denis <denis.ietf@free.fr> =
wrote:

Hi Roman,
Hi =
Denis!
 
Thanks for the feedback and for repeating your review on the =
revised text.  More inline =E2=80=A6
 
From: iesg <iesg-bounces@ietf.org> On Behalf =
Of Denis
Sent: Monday, July 6, 2020 10:55 =
AM
To: iesg@ietf.org
Cc: txauth@ietf.org
Subject: Re: [Txauth] WG Review: =
Grant Negotiation and Authorization Protocol (gnap)
 
Since it is today the last day to send back =
comments, you will find hereafter my comments on the last charter =
version-05.
BTW, =
I sent an email yesterday evening with the subject: Support of =
FIDO and data =
minimization by RSs, where I indicated that the charter should 
mention FIDO =
U2F so that it should be possible to logon to a RS using either FIDO or =
by presenting one (or more) access tokens from one (or more) AS.
The =
original email is here : https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iI=
PQczD7icwE/
charter-ietf-gnap-00-05
This=
 group is chartered to develop a fine-grained delegation protocol for =
authorization, API access, user identifiers, and identity assertions. =

 
[Denis] Fine.
 
The protocol will also allow the client to =
present unverified identifiers and verifiable assertions to the AS as =
part of its request. 
 
[Denis] This sentence is too vague =
because "as part of its request" is not explicit enough. If it =
means  "as part as an access token request" 
this should be explicitly said. If, it is not the case, then =
it should be clearly explained. The AS should know as little as possible =
(including nothing)
about what the =
client is doing.
 
[Roman] The =E2=80=9Crequest=E2=80=9D here is =
the =E2=80=9Caccess token request=E2=80=9D.  That can be made =
clearer.
This =
would be appreciated.
 
This protocol will allow an authorizing party to =
delegate access to client software through an authorization server. 
 
[Denis] The word "privacy" is still missing in the charter. "Delegating =
access to client software through an authorization server" 
is negating the fact that the user's privacy will ever be =
considered. IMHO, I believe that a RS may delegate some operation to =
another RS, 
but I don't believe that an AS =
should be concerned by any form of delegation, otherwise it would have =
the ability to act as "Big Brother".
OAuth has not been constructed taking into consideration the =
user's privacy. The major difference with it should be that GNAP has =
been 
constructed along "privacy by design" principles.
 
[Roman]  I don=E2=80=99t exactly =
follow how considerations for privacy are being negated.  Above and =
beyond use-case specific considerations that would be defined later,=20
RFC6973 is the IETF consensus design guidance that will guide the =
privacy threats and mitigations of the work.  What design guidance =
would you recommend that=20
the WG should consider that aren=E2=80=99t captured in RFC6973?
I =
believe my message is quite clear : If the AS is handling the delegation =
process, it will know what the client is doing or where it is =
going. 
On=
 the contrary, if the RS is handling the delegation process, the AS will =
be unable to know what the client is doing. In addition, an =
AS-centric 
architecture would not be scalable and would need a lot of =
synchronizations between ASs and RSs. The user consent should be handled =
by the RS 
and not by the AS. When a RS is unable to provide the =
service, it is best placed to tell directly to the client what it could =
do next. 
RFC 6973 is very good document. Section 7.1 =
states: 
          b.  =
Data.  What information does the protocol expose about individuals, =
their devices, and/or their device usage (other than the identifiers =
discussed in (a))? 
Data includes both the operation and the data =
associated with the operation. An AS should be kept ignorant of both the =
operation and the data associated with the operation.
c.  Observers.  (...) Are there ways for protocol =
implementers to  choose to limit the information shared with each =
entity?  
If theses guidances were followed, =
the proposed architecture would not be AS-centric.
 
It will expand upon the uses cases currently supported by OAuth =
2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support =
authorizations 
scoped as narrowly as a single =
transaction, provide a clear framework for interaction among all parties =
involved in the protocol flow, and remove 
unnecessary dependence on a browser or user-agent for =
coordinating interactions.
 
[Denis] There is no need to refer =
to OAuth 2.0 and OpenID Connect. Some existing uses cases (i.e. "non-expanded" use cases) should be supported 
differently from OAuth 2.0 and OpenID Connect, in particular =
to support the user's privacy.
 
[Roman] I=E2=80=99d want to hear others on this =
rescoping.  Building upon the use cases of OAuth 2.0 and OpenID =
Connect has been core, consensus-validated tenant for some time now.
 
The delegation process will be acted upon =
by multiple parties in the protocol, each performing a specific role. =
The protocol will decouple the channels used 
by =
the protocol participants to communicate from the delegation channel, =
which happens directly between the client and the authorization server =
(in contrast 
with OAuth 2.0, which is initiated by the =
client redirecting the user=E2=80=99s browser). 
 
[Denis] Here again, the delegation =
process, if any, should be handled by RSs and not by ASs. 
The term "delegation channel" is being used but it is left =
undefined. It is not understandable.
 
[Roman] This sentence was just added =
into -05 address Security AD feedback.  In this case, it was made =
to distinguish between in-band signaling and the new purpose-to-be-built =
channel.
Since =
delegation should not be handled by the AS, a delegation channel should =
not exist.
 
The protocol will include a means of specifying =
how the user can potentially be involved in an interactive fashion =
during the delegation process. 
The client and Authorization =
Server (AS) will use these interaction mechanisms to involve the user, =
as necessary, to make authorization decisions.
 
[Denis] =
Here again, the delegation process, if any, should be handled by RSs and =
not by ASs. The AS should know as little as possible (including =
nothing)
about what the client is =
doing.
 
[Roman] Understood =E2=80=93 as I understand it, =
you have concern with the scope of the AS behavior.  I=E2=80=99d be =
interesting in hearing additional support for this rescoping.  
 
This decoupling avoids many of the =
security concerns and technical challenges of OAuth 2.0 and provides a =
non-invasive path for supporting future types 
of =
clients and interaction channels.
 
[Denis] This is not understandable =
to me. Is such a sentence really needed in a charter ?
 
[Roman] Can someone on the TxAuth =
mailing list remind us on why this sentence is here?  With a fresh =
read, I also can=E2=80=99t remember why we need it.
 
The group will define interoperability for this =
protocol between different parties, including
-          =
client and authorization server;
-          =
client and resource server; and
     -      =
authorization server and resource server.
 
[Denis] In order to support the =
user's privacy, there should be no interaction at all between an =
authorization server and a resource server 
at the time of a client =
request.
 
The group will seek to minimize =
assumptions about the form of client applications, allowing =
for:
-          =
Fine-grained specification of access
-          =
Approval of AS attestation to identifiers and other identity =
claims
-          =
Approval of access to multiple resources and APIs in a single =
interaction
-          =
Multiple access tokens in a single request and =
response
-          =
AS-directed dispatch of access tokens to the appropriate =
RS
[Denis] As-directed dispatch does =
not allow to support the user's privacy. However, RS-directed dispatch =
allows to support the user's privacy.
It should be explicitly mentioned.
[Roman] As above (per the AS vs. RS behavior)
-          =
Separation between the party authorizing access and the party =
operating the client requesting access 
 
[Denis] It is =
questionable whether such a separation would be really beneficial. In =
doubt, this item should be removed.
[Roman] Could you say more on why this flexibility wouldn=E2=80=
=99t be worth it?  
Except =
for added complexity, there is no need to have separate channels. It is =
simpler to send the access token in addition to the data 
and, for =
additional security, to sign the data using a private key corresponding =
to a public key present in the access token.
The =
group will define extension points for this protocol to allow for =
flexibility in areas including:
 
Cryptographic agility for =
keys, message signatures, and proof of possession
-          =
User interaction mechanisms including web and non-web =
methods
-          =
Mechanisms for conveying user, software, organization, and =
other information used in authorization decisions 
-          =
Mechanisms for presenting tokens to resource servers and =
binding resource requests to tokens and associated cryptographic keys =

Optimized inclusion of additional information =
(including identifiers and identity assertions) through the delegation =
process 
 
Additionally, the group will =
provide mechanisms for management of the protocol lifecycle =
including:
-          =
Discovery of the authorization server
-          =
Revocation of active tokens
Data=
 model for granted access and mechanisms for the AS and RS to =
communicate the granted access model
 
[Denis] While it is the duty for =
the RS to communicate the granted access model to the client at the appropriate instant of time, 
the AS should be kept fully ignorant of it.
 
Although the artifacts for this work are not =
intended or expected to be backwards-compatible with OAuth 2.0 or OpenID =
Connect, 
the group will attempt to simplify migrating =
from OAuth 2.0 and OpenID Connect to the new protocol where =
possible.
 
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. Functionality that builds directly =
on OAuth 2.0 will be directed to the OAuth Working Group, including 
functionality back-ported from the protocol developed here to =
OAuth 2.0.
 
The group is chartered to =
develop mechanisms for applying cryptographic methods, such as JOSE and =
COSE, to the delegation process. 
This group is not chartered =
to develop new cryptographic methods.
 
The group is chartered to develop mechanisms for =
conveying identity information within the protocol including existing =
identifiers 
(such as email addresses, phone numbers, =
usernames, and subject identifiers) and assertions (such as OpenID =
Connect ID Tokens, 
SAML Assertions, and =
Verifiable Credentials). The group is not chartered to develop new =
formats for identifiers or assertions, nor is the group 
chartered to develop schemas for user information, profiles, =
or other identity attributes, unless a viable existing format is not =
available.
 
The initial work will focus =
on using HTTPS for communication between the client and the =
authorization server, taking advantage 
of =
optimization features of HTTP/2 and HTTP/3 where possible, and will =
strive to enable simple mapping to other protocols such as COAP 
when=
 doing so does not conflict with the primary focus.
 
Milestones to include:
-          =
Core delegation protocol
[Denis] Before =
defining a "Core delegation protocol", a simple client server-protocol =
involving the presentation of several access tokens to one RS should be =
defined. 
Privacy principles should be =
applied when defining the protocol. Then after, a delegation mechanism =
allowing one RS to forward an operation to another RS should be =
defined.
-          =
Key presentation mechanism bindings to the core protocol =
including TLS, detached HTTP signature, and embedded HTTP signatures =

[Denis] Bindings to TLS are now =
deprecated, why should they be maintained ? 
Signatures may be needed but they do not necessarily need to =
be "detached HTTP signature, and embedded HTTP signatures". 
This item should be either removed or reworded.
[Roman] Noted.  I=E2=80=99d want to hear others on this =
rescoping.
As =
explained above, it is possible to sign the data using a private key =
corresponding to a public key present in the access =
token.
 
-          =
Conveyance mechanisms for identifiers and assertions =

-          =
Guidelines for use of protocol extension points (if needed) =

     -    Guidelines on =
migration paths, implementation, and operations
[Denis] =
The above three lines are rather mysterious.
[Roman] The guidelines on migration paths came from the =
initial IESG review in order to have a named activity to action the =
design goal of =E2=80=9C=E2=80=A6 the group will attempt to simplify =
migrating from OAuth 2.0 and OpenID Connect to the new protocol where =
possible=E2=80=9D a bit earlier in the text.
Where possible, the =
group will seek to make use of tools to guide and inform the =
standardization process including formal analysis, 
architecture =
documents, and use case documents. These artifacts will not be =
considered as working group milestones or deliverables.
The working group =
will cooperate and coordinate with other IETF WGs such as OAUTH, and =
work with external organizations, 
such as the =
OpenID Foundation, as appropriate.
[Denis] The charter should be =
shorter.
 
[Roman] Definitely.  Nevertheless, we have the current =
text through rough consensus process achieved from two BoFs and multiple =
mailing list consensus calls.
In a =
previous post, I proposed a much shorter text.
Denis
 
Regards,
Roman 
 
/Denis
 
A new IETF WG has been proposed in =
the Security Area. The IESG has not made
any determination yet. The =
following draft charter was submitted, and is
provided for informational purposes only. Please send your =
comments to the
IESG mailing list (iesg@ietf.org) by =
2020-07-06.
 
Grant Negotiation and Authorization Protocol (gnap)
---------------------------------------------------------------=
--------
Current status: Proposed WG
 
Chairs:
  Yaron Sheffer <yaronf.ietf@gmail.com>
  =
Leif Johansson <leifj@sunet.se>
 
Assigned Area Director:
  Roman Danyliw <rdd@cert.org>
 
Security Area Directors:
  Benjamin Kaduk <kaduk@mit.edu>
  Roman Danyliw <rdd@cert.org>
 
Mailing=
 list:
  Address: txauth@ietf.org
  To subscribe: =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/txauth
  =
Archive: https://mailarchive.ietf.org/arch/browse/txauth/
 
Group =
page: https://datatracker.ietf.org/group/gnap/
 
Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/
 
This =
group is chartered to develop a fine-grained delegation protocol for
authorization and API access, as well as requesting and =
providing user
identifiers and claims. This protocol will allow an =
authorizing party to
delegate access to client software through an =
authorization server. It will
expand upon the uses cases =
currently supported by OAuth 2.0 and OpenID Connect
(itself=
 an extension of OAuth 2.0) to support authorizations scoped as
narrowly as a single transaction, provide a clear framework =
for interaction
among all parties involved in the protocol flow, and remove =
unnecessary
dependence on a browser or user-agent for coordinating =
interactions.
 
The delegation process will be acted upon by multiple parties =
in the protocol,
each performing a specific role. The protocol will decouple =
the interaction
channels, such as the end user=E2=80=99s browser, from the =
delegation channel, which
happens directly between the client and the =
authorization server (in contrast
with OAuth 2.0, which is initiated =
by the client redirecting the user=E2=80=99s
browser). The protocol will include a means of specifying how =
the user can
potentially be involved in an interactive fashion during the =
delegation
process. The client and Authorization Server (AS) will use =
these interaction
mechanisms to involve the user, as necessary, to make =
authorization decisions.
This decoupling avoids many of the security =
concerns and technical challenges
of OAuth 2.0 and provides a =
non-invasive path for supporting future types of
clients=
 and interaction channels.
 
The =
group will define interoperability for this protocol between =
different
parties, including
 - client and authorization =
server;
 - client and resource server; and
 - =
authorization server and resource server.
 
The =
group will seek to minimize assumptions about the form of client
applications, allowing for:
- Fine-grained specification of =
access
- Approval of AS attestation to identifiers and other =
identity claims
- Approval of access to multiple resources and APIs in a =
single interaction
- Support for multiple access tokens in a single request and =
response
- Support for directed, audience-restricted access tokens
- =
Separation between the party authorizing access and the party operating =
the
client =
requesting access
 
The group will define extension points for this protocol to =
allow for
flexibility in areas including:
 
- =
Cryptographic agility for keys, message signatures, and proof of =
possession
- User interaction mechanisms including web and non-web =
methods
- Mechanisms for conveying user, software, organization, and =
other
information used in authorization decisions
- =
Mechanisms for presenting tokens to resource servers and binding =
resource
requests to tokens and associated cryptographic keys
- =
Optimized inclusion of additional information (including identifiers =
and
identity assertions) through the delegation process
 
Additionally, the group will provide mechanisms for =
management of the protocol
lifecycle including:
 
- =
Discovery of the authorization server
- Revocation of active tokens
- =
Mechanisms for the AS and RS to communicate the access granted by an =
access
token
 
Although the artifacts for this work are not intended or =
expected to be
backwards-compatible with OAuth 2.0 or OpenID Connect, the =
group will attempt
to simplify migrating from OAuth 2.0 and OpenID Connect to =
the new protocol
where possible.
 
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. Functionality that builds directly on OAuth 2.0 will be =
directed
to the OAuth Working Group, including functionality =
back-ported from the
protocol developed here to OAuth 2.0.
 
The =
group is chartered to develop mechanisms for applying cryptographic
methods, such as JOSE and COSE, to the delegation process. =
This group is not
chartered to develop new cryptographic methods.
 
The =
group is chartered to develop mechanisms for conveying identity
information within the protocol including existing =
identifiers (such as email
addresses, phone numbers, =
usernames, and subject identifiers) and assertions
(such =
as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
Credentials). The group is not chartered to develop new =
formats for
identifiers or assertions, nor is the group chartered to =
develop schemas for
user information, profiles, or other identity attributes, =
unless a viable
existing format is not available.
 
The =
initial work will focus on using HTTPS for communication between the
client =
and the authorization server, taking advantage of optimization
features of HTTP/2 and HTTP/3 where possible, and will strive =
to enable
simple mapping to other protocols such as COAP when doing so =
does not
conflict with the primary focus.
 
Milestones to include:
- Core delegation protocol
- Key =
presentation mechanism bindings to the core protocol including TLS,
detached HTTP signature, and embedded HTTP signatures
- =
Conveyance mechanisms for identifiers and assertions
- =
Guidelines for use of protocol extension points
- (if =
needed) Guidelines on migration paths, implementation, and =
operations
 
Where possible, the group will seek to make use of tools to =
guide and inform
the standardization process including formal analysis, =
architecture documents,
and use case documents. These artifacts will not =
be considered as working
group milestones or deliverables.
 
The =
working group will cooperate and coordinate with other IETF WGs such =
as
OAUTH, =
and work with external organizations, such as the OpenID Foundation,
as =
appropriate.
 
Milestones:
 
  Jul 2021 - Core delegation =
protocol in WGLC
 
  Oct 2021 - Key presentation mechanism binding to the =
core protocol, TLS, to
  WGLC
 
  =
Oct 2021 - Key presentation mechanism binding to the core protocol, 
  detached HTTP signatures, to WGLC
 
  =
Oct 2021 - Key presentation mechanism binding to the core protocol,
  =
embedded HTTP signature, to WGLC
 
  =
Dec 2021 - Guidelines for use of protocol extension points to WGLC
 
  =
Feb 2022 - Guidelines on migration paths, implementation, and operations =
to
   WGLC
 
 
 
 

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

=

--Apple-Mail=_B5C4130C-DE2A-4822-ACC9-7A01F90B9459--


From nobody Tue Jul  7 10:04: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 853693A1140 for ; Tue,  7 Jul 2020 10:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level: 
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=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 DBMPcbJ1b25g for ; Tue,  7 Jul 2020 10:04:31 -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 7BD8A3A115E for ; Tue,  7 Jul 2020 10:04:30 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d89 with ME id 0H4R2300w4FMSmm03H4StT; Tue, 07 Jul 2020 19:04:28 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 07 Jul 2020 19:04:28 +0200
X-ME-IP: 86.238.65.197
To: Justin Richer 
Cc: "rdd@cert.org" , "iesg@ietf.org" , "txauth@ietf.org" 
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <7563640e-f515-3e73-a4eb-3902ec7af50e@free.fr> <3424311c60f541b197cfda6e9f3b494e@cert.org> <36de4e6a-41fe-81b1-6c92-69fe5b63ad6f@free.fr> 
From: Denis 
Message-ID: 
Date: Tue, 7 Jul 2020 19:04:23 +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="------------E18763AA8C1C01D5DFD9C294"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 07 Jul 2020 17:04:36 -0000

This is a multi-part message in MIME format.
--------------E18763AA8C1C01D5DFD9C294
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Justin,
> Denis,
>
> A lot of what you’re describing below changes the very nature of the 
> roles in the system. The component that manages the consent and issues 
> tokens is, by definition, the AS.

The current charter states: "the artifacts for this work are not 
intended or expected to be backwards-compatible with OAuth 2.0 or OpenID 
Connect".
So we are not bound to OAuth 2.0 nor OpenID Connect. Hence, we do not 
need to stick with all their concepts.

I believe that the user's consent should be given after a dialogue with 
the RS which does not mean that the RS shall capture the user's consent
since it is the duty of the client. When a user selects one operation 
among a choice of operations proposed by the RS, the RS should inform
the client about which attributes it needs to present and from which 
ASs. It is only at this moment that the clients learns which ASs are
adequate. Before this moment, the dialogue *cannot* be handled by an AS. 
Then after the duty of the client is to look for these attributes and
to get them from one or more ASs. ASs are all equal. There is no single 
AS with which the user shall be bound or have a particular relationship

Managing the authorization (and the user's consent) at the RS is simple: 
I have proposed a way to do it (and FIDO U2F is even included).

Managing the authorization at the AS would mandate a close 
synchronization between the RS and all the ASs with which it has a 
relationship.
There would be the need to define a synch. protocol and it is much 
simpler to avoid to use such a protocol and thus not to define it.
"Out-of-bands" means for such a synchronisation would not be a better 
solution. But the major issue by managing the user's consent at the AS
is to allow the AS to act as Big Brother.

A copy and paste from a document published under the "Digital Europe for 
All" (DE4A) project :

    The privacy principle requires that the private life, the home and
    the communications of each citizen
    are respected and that no personal data are gathered without a
    legitimate reason and purpose.

    Data protection and privacy should (as far as possible) be *achieved
    by design*, i.e. be embedded in the
    technical solutions and services in a way that misuse or
    illegitimate access is made impossible or at
    least very difficult through the technical approach itself, and
    *without having to rely on organisational **
    **measures or solely on legal measures to guarantee the compliance*.

    Main sources for this principle: CFREU, GDPR, eIDAS, eGov Action
    Plan, EIF, Tallinn Declaration, and
    SDGR.

> The user shouldn’t ever have to interact directly with the RS, since 
> the RS is, by definition, an API that is called by software, not an 
> interactive component.
>
> But it’s important to note that these are only :roles: to be played 
> and not strictly speaking separate pieces of software, and that these 
> roles can be combined and split in a variety of ways. For instance, in 
> what you’re talking about below, instead of saying that it’s the RS 
> that manages the consent, what if you saw it as the functionality of 
> the AS that’s been split between two components: one 
> privacy-preserving element that issues tokens, and another that deals 
> with interaction and consent. This is already a pattern that some in 
> the WG have expressed interest in supporting with GNAP, and the core 
> charter tenet of separating the interaction from the delegation 
> channels is something that could help there.
>
> Would it be possible to look at your use case in this different light?

I could see the RS (i.e. not the AS) split into two components: an API 
and an MMI to manage the choices and the consent of the user.
This looks artificial but would it help ?

Denis

> It’s always possible that we need to re-cast some of these roles, and 
> that’s been done before: in OAuth 2 we defined the AS and RS roles 
> separately, even though they can always be deployed together anyway. 
> So with that it’s possible that there are other distinct pieces here 
> that are working together that we need to tease out, but that’s 
> something for the WG to figure out. We can always decide to separate 
> out the parts and allow them to be recombined in deployment, But I do 
> not think it is helpful to redefine the existing roles, especially by 
> moving key facets from one existing role to another.
>
>  — Justin
>
>> On Jul 7, 2020, at 8:43 AM, Denis > > wrote:
>>
>> Hi Roman,
>>> Hi Denis!
>>> Thanks for the feedback and for repeating your review on the revised 
>>> text.  More inline …
>>> *From:*iesg*On Behalf Of*Denis
>>> *Sent:*Monday, July 6, 2020 10:55 AM
>>> *To:*iesg@ietf.org
>>> *Cc:*txauth@ietf.org
>>> *Subject:*Re: [Txauth] WG Review: Grant Negotiation and 
>>> Authorization Protocol (gnap)
>>> Since it is today the last day to send back comments, you will find 
>>> hereafter my comments on the last charter version-05.
>>
>> BTW, I sent an email yesterday evening with the subject:*Support of 
>> FIDO*and data minimization by RSs, where I indicated that the charter 
>> should
>> mention FIDO U2F so that it should be possible to logon to a RS using 
>> either FIDO or by presenting one (or more) access tokens from one (or 
>> more) AS.
>>
>> The original email is here 
>> :https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/
>>
>>>
>>>     charter-ietf-gnap-00-05
>>>
>>> This group is chartered to develop a fine-grained delegation 
>>> protocol for authorization, API access, user identifiers, and 
>>> identity assertions.
>>> [Denis] Fine.
>>> The protocol will also allow the client to present unverified 
>>> identifiers and verifiable assertions to the AS as part of its request.
>>> [Denis] This sentence is too vague because "as part of its request" 
>>> is not explicit enough. If it means  "as part as an access token 
>>> request"
>>> this should be explicitly said. If, it is not the case, then it 
>>> should be clearly explained. The AS should know as little as 
>>> possible (including nothing)
>>> about what the client is doing.
>>> [Roman] The “request” here is the “access token request”.  That can 
>>> be made clearer.
>>
>> This would be appreciated.
>>
>>> This protocol will allow an authorizing party to delegate access to 
>>> client software through an authorization server.
>>> [Denis] The word "*privacy*" is still missing in the charter. 
>>> "Delegating access to client software through an authorization server"
>>> is negating the fact that the user's privacy will ever be 
>>> considered. IMHO, I believe that a RS may delegate some operation to 
>>> another RS,
>>> but I don't believe that an AS should be concerned by any form of 
>>> delegation, otherwise it would have the ability to act as "Big Brother".
>>> OAuth has not been constructed taking into consideration the user's 
>>> privacy. The major difference with it should be that GNAP has been
>>> constructed along "*privacy by design*" principles.
>>> [Roman]  I don’t exactly follow how considerations for privacy are 
>>> being negated.  Above and beyond use-case specific considerations 
>>> that would be defined later, RFC6973 is the IETF consensus design 
>>> guidance that will guide the privacy threats and mitigations of the 
>>> work.  What design guidance would you recommend that the WG should 
>>> consider that aren’t captured in RFC6973?
>>
>> I believe my message is quite clear : If the AS is handling the 
>> delegation process, it will know what the client is doing or where it 
>> is going.
>> On the contrary, if the RS is handling the delegation process, the AS 
>> will be unable to know what the client is doing. In addition, an 
>> AS-centric
>> architecture would not be scalable and would need a lot of 
>> synchronizations between ASs and RSs. The user consent should be 
>> handled by the RS
>> and not by the AS. When a RS is unable to provide the service, it is 
>> best placed to tell directly to the client what it could do next.
>>
>> RFC 6973 is very good document. Section 7.1 states:
>>
>>           b.  Data. What information does the protocol expose about 
>> individuals, their devices, and/or their device usage (other than the 
>> identifiers discussed in (a))?
>>
>> Data includes both the operation and the data associated with the 
>> operation. An AS should be kept ignorant of both the operation and 
>> the data associated with the operation.
>>
>>     c.  Observers.  (...) Are there ways for protocol implementers
>>     to  choose to limit the information shared with each entity?
>>
>> If theses guidances were followed, the proposed architecture would 
>> not be AS-centric.
>>
>>> It will *expand* upon the uses cases currently supported by OAuth 
>>> 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support 
>>> authorizations
>>> scoped as narrowly as a single transaction, provide a clear 
>>> framework for interaction among all parties involved in the protocol 
>>> flow, and remove
>>> unnecessary dependence on a browser or user-agent for coordinating 
>>> interactions.
>>> [Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. 
>>> Some existing uses cases (i.e. "*non-expanded"* use cases) should be 
>>> supported
>>> differently from OAuth 2.0 and OpenID Connect, in particular to 
>>> support the user's privacy.
>>> [Roman] I’d want to hear others on this rescoping.  Building upon 
>>> the use cases of OAuth 2.0 and OpenID Connect has been core, 
>>> consensus-validated tenant for some time now.
>>> The delegation process will be acted upon by multiple parties in the 
>>> protocol, each performing a specific role. The protocol will 
>>> decouple the channels used
>>> by the protocol participants to communicate from the delegation 
>>> channel, which happens directly between the client and the 
>>> authorization server (in contrast
>>> with OAuth 2.0, which is initiated by the client redirecting the 
>>> user’s browser).
>>> [Denis] Here again, the delegation process, if any, should be 
>>> handled by RSs and not by ASs.
>>> The term "delegation channel" is being used but it is left 
>>> undefined. It is not understandable.
>>> [Roman] This sentence was just added into -05 address Security AD 
>>> feedback.  In this case, it was made to distinguish between in-band 
>>> signaling and the new purpose-to-be-built channel.
>>
>> Since delegation should not be handled by the AS, a delegation 
>> channel should not exist.
>>
>>> The protocol will include a means of specifying how the user can 
>>> potentially be involved in an interactive fashion during the 
>>> delegation process.
>>> The client and Authorization Server (AS) will use these interaction 
>>> mechanisms to involve the user, as necessary, to make authorization 
>>> decisions.
>>> [Denis] Here again, the delegation process, if any, should be 
>>> handled by RSs and not by ASs. The AS should know as little as 
>>> possible (including nothing)
>>> about what the client is doing.
>>> [Roman] Understood – as I understand it, you have concern with the 
>>> scope of the AS behavior.  I’d be interesting in hearing additional 
>>> support for this rescoping.
>>> This decoupling avoids many of the security concerns and technical 
>>> challenges of OAuth 2.0 and provides a non-invasive path for 
>>> supporting future types
>>> of clients and interaction channels.
>>> [Denis] This is not understandable to me. Is such a sentence really 
>>> needed in a charter ?
>>> [Roman] Can someone on the TxAuth mailing list remind us on why this 
>>> sentence is here?  With a fresh read, I also can’t remember why we 
>>> need it.
>>> The group will define interoperability for this protocol between 
>>> different parties, including
>>> -client and authorization server;
>>> -client and resource server; and
>>>      -      authorization server and resource server.
>>> [Denis] In order to support the user's privacy, there should be no 
>>> interaction at all between an authorization server and a resource 
>>> server
>>> /at the time of a client request/.
>>> The group will seek to minimize assumptions about the form of client 
>>> applications, allowing for:
>>> -Fine-grained specification of access
>>> -Approval of AS attestation to identifiers and other identity claims
>>> -Approval of access to multiple resources and APIs in a single 
>>> interaction
>>> -Multiple access tokens in a single request and response
>>> -AS-directed dispatch of access tokens to the appropriate RS
>>> [Denis] As-directed dispatch does not allow to support the user's 
>>> privacy. However, RS-directed dispatch allows to support the user's 
>>> privacy.
>>> It should be explicitly mentioned.
>>> [Roman] As above (per the AS vs. RS behavior)
>>> -Separation between the party authorizing access and the party 
>>> operating the client requesting access
>>> [Denis] It is questionable whether such a separation would be really 
>>> beneficial. In doubt, this item should be removed.
>>> [Roman] Could you say more on why this flexibility wouldn’t be worth 
>>> it?
>>
>> Except for added complexity, there is no need to have separate 
>> channels. It is simpler to send the access token in addition to the data
>> and, for additional security, to sign the data using a private key 
>> corresponding to a public key present in the access token.
>>
>>> The group will define extension points for this protocol to allow 
>>> for flexibility in areas including:
>>> Cryptographic agility for keys, message signatures, and proof of 
>>> possession
>>> -User interaction mechanisms including web and non-web methods
>>> -Mechanisms for conveying user, software, organization, and other 
>>> information used in authorization decisions
>>> -Mechanisms for presenting tokens to resource servers and binding 
>>> resource requests to tokens and associated cryptographic keys
>>> Optimized inclusion of additional information (including identifiers 
>>> and identity assertions) through the delegation process
>>> Additionally, the group will provide mechanisms for management of 
>>> the protocol lifecycle including:
>>> -Discovery of the authorization server
>>> -Revocation of active tokens
>>> Data model for granted access and mechanisms for the AS and RS to 
>>> communicate the granted access model
>>> [Denis] While it is the duty for the RS to communicate the granted 
>>> access model to the client /at the appropriate instant of time/,
>>> the AS should be kept fully ignorant of it.
>>> Although the artifacts for this work are not intended or expected to 
>>> be backwards-compatible with OAuth 2.0 or OpenID Connect,
>>> the group will attempt to simplify migrating from OAuth 2.0 and 
>>> OpenID Connect to the new protocol where possible.
>>> 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. Functionality that builds directly on 
>>> OAuth 2.0 will be directed to the OAuth Working Group, including
>>> functionality back-ported from the protocol developed here to OAuth 2.0.
>>> The group is chartered to develop mechanisms for applying 
>>> cryptographic methods, such as JOSE and COSE, to the delegation 
>>> process.
>>> This group is not chartered to develop new cryptographic methods.
>>> The group is chartered to develop mechanisms for conveying identity 
>>> information within the protocol including existing identifiers
>>> (such as email addresses, phone numbers, usernames, and subject 
>>> identifiers) and assertions (such as OpenID Connect ID Tokens,
>>> SAML Assertions, and Verifiable Credentials). The group is not 
>>> chartered to develop new formats for identifiers or assertions, nor 
>>> is the group
>>> chartered to develop schemas for user information, profiles, or 
>>> other identity attributes, unless a viable existing format is not 
>>> available.
>>> The initial work will focus on using HTTPS for communication between 
>>> the client and the authorization server, taking advantage
>>> of optimization features of HTTP/2 and HTTP/3 where possible, and 
>>> will strive to enable simple mapping to other protocols such as COAP
>>> when doing so does not conflict with the primary focus.
>>> Milestones to include:
>>> -Core delegation protocol
>>> [Denis] Before defining a "Core delegation protocol", a simple 
>>> client server-protocol involving the presentation of several access 
>>> tokens to one RS should be defined.
>>> Privacy principles should be applied when defining the protocol. 
>>> Then after, a delegation mechanism allowing one RS to forward an 
>>> operation to another RS should be defined.
>>> -Key presentation mechanism bindings to the core protocol including 
>>> TLS, detached HTTP signature, and embedded HTTP signatures
>>> [Denis] Bindings to TLS are now deprecated, why should they be 
>>> maintained ?
>>> Signatures may be needed but they do not necessarily need to be 
>>> "detached HTTP signature, and embedded HTTP signatures".
>>> This item should be either removed or reworded.
>>> [Roman] Noted.  I’d want to hear others on this rescoping.
>>
>> As explained above, it is possible to sign the data using a private 
>> key corresponding to a public key present in the access token.
>>
>>> -Conveyance mechanisms for identifiers and assertions
>>> -Guidelines for use of protocol extension points (if needed)
>>>      -    Guidelines on migration paths, implementation, and operations
>>> [Denis] The above three lines are rather mysterious.
>>> [Roman] The guidelines on migration paths came from the initial IESG 
>>> review in order to have a named activity to action the design goal 
>>> of “… the group will attempt to simplify migrating from OAuth 2.0 
>>> and OpenID Connect to the new protocol where possible” a bit earlier 
>>> in the text.
>>> Where possible, the group will seek to make use of tools to guide 
>>> and inform the standardization process including formal analysis,
>>> architecture documents, and use case documents. These artifacts will 
>>> not be considered as working group milestones or deliverables.
>>> The working group will cooperate and coordinate with other IETF WGs 
>>> such as OAUTH, and work with external organizations,
>>> such as the OpenID Foundation, as appropriate.
>>> [Denis] The charter should be shorter.
>>> [Roman] Definitely.  Nevertheless, we have the current text through 
>>> rough consensus process achieved from two BoFs and multiple mailing 
>>> list consensus calls.
>>
>> In a previous post, I proposed a much shorter text.
>>
>> Denis
>>
>>> Regards,
>>> Roman
>>> /Denis
>>>
>>>     A new IETF WG has been proposed in the Security Area. The IESG has not made
>>>
>>>     any determination yet. The following draft charter was submitted, and is
>>>
>>>     provided for informational purposes only. Please send your comments to the
>>>
>>>     IESG mailing list (iesg@ietf.org  )*by 2020-07-06*.
>>>
>>>     Grant Negotiation and Authorization Protocol (gnap)
>>>
>>>     -----------------------------------------------------------------------
>>>
>>>     Current status: Proposed WG
>>>
>>>     Chairs:
>>>
>>>        Yaron Sheffer  
>>>
>>>        Leif Johansson  
>>>
>>>     Assigned Area Director:
>>>
>>>        Roman Danyliw  
>>>
>>>     Security Area Directors:
>>>
>>>        Benjamin Kaduk  
>>>
>>>        Roman Danyliw  
>>>
>>>     Mailing list:
>>>
>>>        Address:txauth@ietf.org  
>>>
>>>        To subscribe:​https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>        Archive:https://mailarchive.ietf.org/arch/browse/txauth/
>>>
>>>     Group page:https://datatracker.ietf.org/group/gnap/
>>>
>>>     Charter:https://datatracker.ietf.org/doc/charter-ietf-gnap/
>>>
>>>     This group is chartered to develop a fine-grained delegation protocol for
>>>
>>>     authorization and API access, as well as requesting and providing user
>>>
>>>     identifiers and claims. This protocol will allow an authorizing party to
>>>
>>>     delegate access to client software through an authorization server. It will
>>>
>>>     expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect
>>>
>>>     (itself an extension of OAuth 2.0) to support authorizations scoped as
>>>
>>>     narrowly as a single transaction, provide a clear framework for interaction
>>>
>>>     among all parties involved in the protocol flow, and remove unnecessary
>>>
>>>     dependence on a browser or user-agent for coordinating interactions.
>>>
>>>     The delegation process will be acted upon by multiple parties in the protocol,
>>>
>>>     each performing a specific role. The protocol will decouple the interaction
>>>
>>>     channels, such as the end user’s browser, from the delegation channel, which
>>>
>>>     happens directly between the client and the authorization server (in contrast
>>>
>>>     with OAuth 2.0, which is initiated by the client redirecting the user’s
>>>
>>>     browser). The protocol will include a means of specifying how the user can
>>>
>>>     potentially be involved in an interactive fashion during the delegation
>>>
>>>     process. The client and Authorization Server (AS) will use these interaction
>>>
>>>     mechanisms to involve the user, as necessary, to make authorization decisions.
>>>
>>>     This decoupling avoids many of the security concerns and technical challenges
>>>
>>>     of OAuth 2.0 and provides a non-invasive path for supporting future types of
>>>
>>>     clients and interaction channels.
>>>
>>>     The group will define interoperability for this protocol between different
>>>
>>>     parties, including
>>>
>>>       - client and authorization server;
>>>
>>>       - client and resource server; and
>>>
>>>       - authorization server and resource server.
>>>
>>>     The group will seek to minimize assumptions about the form of client
>>>
>>>     applications, allowing for:
>>>
>>>     - Fine-grained specification of access
>>>
>>>     - Approval of AS attestation to identifiers and other identity claims
>>>
>>>     - Approval of access to multiple resources and APIs in a single interaction
>>>
>>>     - Support for multiple access tokens in a single request and response
>>>
>>>     - Support for directed, audience-restricted access tokens
>>>
>>>     - Separation between the party authorizing access and the party operating the
>>>
>>>     client requesting access
>>>
>>>     The group will define extension points for this protocol to allow for
>>>
>>>     flexibility in areas including:
>>>
>>>     - Cryptographic agility for keys, message signatures, and proof of possession
>>>
>>>     - User interaction mechanisms including web and non-web methods
>>>
>>>     - Mechanisms for conveying user, software, organization, and other
>>>
>>>     information used in authorization decisions
>>>
>>>     - Mechanisms for presenting tokens to resource servers and binding resource
>>>
>>>     requests to tokens and associated cryptographic keys
>>>
>>>     - Optimized inclusion of additional information (including identifiers and
>>>
>>>     identity assertions) through the delegation process
>>>
>>>     Additionally, the group will provide mechanisms for management of the protocol
>>>
>>>     lifecycle including:
>>>
>>>     - Discovery of the authorization server
>>>
>>>     - Revocation of active tokens
>>>
>>>     - Mechanisms for the AS and RS to communicate the access granted by an access
>>>
>>>     token
>>>
>>>     Although the artifacts for this work are not intended or expected to be
>>>
>>>     backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt
>>>
>>>     to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol
>>>
>>>     where possible.
>>>
>>>     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. Functionality that builds directly on OAuth 2.0 will be directed
>>>
>>>     to the OAuth Working Group, including functionality back-ported from the
>>>
>>>     protocol developed here to OAuth 2.0.
>>>
>>>     The group is chartered to develop mechanisms for applying cryptographic
>>>
>>>     methods, such as JOSE and COSE, to the delegation process. This group is not
>>>
>>>     chartered to develop new cryptographic methods.
>>>
>>>     The group is chartered to develop mechanisms for conveying identity
>>>
>>>     information within the protocol including existing identifiers (such as email
>>>
>>>     addresses, phone numbers, usernames, and subject identifiers) and assertions
>>>
>>>     (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
>>>
>>>     Credentials). The group is not chartered to develop new formats for
>>>
>>>     identifiers or assertions, nor is the group chartered to develop schemas for
>>>
>>>     user information, profiles, or other identity attributes, unless a viable
>>>
>>>     existing format is not available.
>>>
>>>     The initial work will focus on using HTTPS for communication between the
>>>
>>>     client and the authorization server, taking advantage of optimization
>>>
>>>     features of HTTP/2 and HTTP/3 where possible, and will strive to enable
>>>
>>>     simple mapping to other protocols such as COAP when doing so does not
>>>
>>>     conflict with the primary focus.
>>>
>>>     Milestones to include:
>>>
>>>     - Core delegation protocol
>>>
>>>     - Key presentation mechanism bindings to the core protocol including TLS,
>>>
>>>     detached HTTP signature, and embedded HTTP signatures
>>>
>>>     - Conveyance mechanisms for identifiers and assertions
>>>
>>>     - Guidelines for use of protocol extension points
>>>
>>>     - (if needed) Guidelines on migration paths, implementation, and operations
>>>
>>>     Where possible, the group will seek to make use of tools to guide and inform
>>>
>>>     the standardization process including formal analysis, architecture documents,
>>>
>>>     and use case documents. These artifacts will not be considered as working
>>>
>>>     group milestones or deliverables.
>>>
>>>     The working group will cooperate and coordinate with other IETF WGs such as
>>>
>>>     OAUTH, and work with external organizations, such as the OpenID Foundation,
>>>
>>>     as appropriate.
>>>
>>>     Milestones:
>>>
>>>        Jul 2021 - Core delegation protocol in WGLC
>>>
>>>        Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to
>>>
>>>        WGLC
>>>
>>>        Oct 2021 - Key presentation mechanism binding to the core protocol,
>>>
>>>        detached HTTP signatures, to WGLC
>>>
>>>        Oct 2021 - Key presentation mechanism binding to the core protocol,
>>>
>>>        embedded HTTP signature, to WGLC
>>>
>>>        Dec 2021 - Guidelines for use of protocol extension points to WGLC
>>>
>>>        Feb 2022 - Guidelines on migration paths, implementation, and operations to
>>>
>>>         WGLC
>>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/txauth
>


--------------E18763AA8C1C01D5DFD9C294
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Justin,

    

      
      Denis,
      


      

      
A lot of what you’re describing below changes the
        very nature of the roles in the system. The component that
        manages the consent and issues tokens is, by definition, the AS.
      

    

    
The current charter states: "the artifacts for this work are not
      intended or expected to be backwards-compatible with OAuth 2.0 or
      OpenID Connect".

      So we are not bound to OAuth 2.0 nor OpenID Connect. Hence, we do
      not need to stick with all their concepts.

    

    
I believe that the user's consent should be given after a
      dialogue with the RS which does not mean that the RS shall capture
      the user's consent 

      since it is the duty of the client. When a user selects one
      operation among a choice of operations proposed by the RS, the RS
      should inform 

      the client about which attributes it needs to present and from
      which ASs. It is only at this moment that the clients learns which
      ASs are

      adequate. Before this moment, the dialogue *cannot* be handled by
      an AS. Then after the duty of the client is to look for these
      attributes and 

      to get them from one or more ASs. ASs are all equal. There is no
      single AS with which the user shall be bound or have a particular
      relationship

    

    
Managing the authorization (and the user's consent) at the RS is
      simple: I have proposed a way to do it (and FIDO U2F is even
      included).

    
Managing the authorization at the AS would mandate a close
      synchronization between the RS and all the ASs with which it has a
      relationship.

      There would be the need to define a synch. protocol and it is much
      simpler to avoid to use such a protocol and thus not to define it.

      "Out-of-bands" means for such a synchronisation would not be a
      better solution. But the major issue by managing the user's
      consent at the AS 

      is to allow the AS to act as Big Brother.

    
A copy and paste from a document published under the "Digital
      Europe for All" (DE4A) project :

    

      
The privacy principle requires that the private life, the home
        and the communications of each citizen 

        are respected and that no personal data are gathered without a
        legitimate reason and purpose.

        

        Data protection and privacy should (as far as possible) be achieved
          by design, i.e. be embedded in the 

        technical solutions and services in a way that misuse or
        illegitimate access is made impossible or at 

        least very difficult through the technical approach itself, and
        without having to rely on organisational 

        measures or solely on legal measures to guarantee the
          compliance. 

        

        Main sources for this principle: CFREU, GDPR, eIDAS, eGov Action
        Plan, EIF, Tallinn Declaration, and 

        SDGR. 

      

    

    

      
The user shouldn’t ever have to interact directly
        with the RS, since the RS is, by definition, an API that is
        called by software, not an interactive component. 

      


      

      
But it’s important to note that these are only
        :roles: to be played and not strictly speaking separate pieces
        of software, and that these roles can be combined and split in a
        variety of ways. For instance, in what you’re talking about
        below, instead of saying that it’s the RS that manages the
        consent, what if you saw it as the functionality of the AS
        that’s been split between two components: one privacy-preserving
        element that issues tokens, and another that deals with
        interaction and consent. This is already a pattern that some in
        the WG have expressed interest in supporting with GNAP, and the
        core charter tenet of separating the interaction from the
        delegation channels is something that could help there. 

      


      

      
Would it be possible to look at your use case in
        this different light? 

    

    
I could see the RS (i.e. not the AS) split into two components:
      an API and an MMI to manage the choices and the consent of the
      user. 

      This looks artificial but would it help ?

    
Denis

    

    

      
It’s always possible that we need to re-cast some of
        these roles, and that’s been done before: in OAuth 2 we defined
        the AS and RS roles separately, even though they can always be
        deployed together anyway. So with that it’s possible that there
        are other distinct pieces here that are working together that we
        need to tease out, but that’s something for the WG to figure
        out. We can always decide to separate out the parts and allow
        them to be recombined in deployment, But I do not think it is
        helpful to redefine the existing roles, especially by moving key
        facets from one existing role to another.

      


      

      
 — Justin

      

        


          

            
On Jul 7, 2020, at 8:43 AM, Denis <denis.ietf@free.fr> wrote:

            

            

              
Hi Roman,

              

                

                  
Hi
                    Denis!

                  
 

                  
Thanks
                    for the feedback and for repeating your review on
                    the revised text.  More inline …

                  
 

                  

                    

                      

                        
From: iesg <iesg-bounces@ietf.org> On Behalf Of Denis

                          Sent: Monday,
                          July 6, 2020 10:55 AM

                          To: iesg@ietf.org

                          Cc: txauth@ietf.org

                          Subject: Re:
                          [Txauth] WG Review: Grant Negotiation and
                          Authorization Protocol (gnap)

                      

                    

                    
 

                    

                      
Since it is today the
                          last day to send back comments, you will find
                          hereafter my comments on the last charter
                          version-05.

                    

                  

                

              

              
BTW, I sent an email
                yesterday evening with the subject: Support
                  of FIDO and
                data minimization by RSs, where I indicated that the
                charter should 

                mention FIDO U2F so that it should be possible to logon
                to a RS using either FIDO or by presenting one (or more)
                access tokens from one (or more) AS.

              
The original email is
                here : https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/

              

                

                  

                    

                      

                    

                    

                      
charter-ietf-gnap-00-05

                      
This group is chartered to develop a fine-grained delegation protocol for authorization, API access, user identifiers, and identity assertions. 

                      
 

                      
[Denis] Fine.

                      
 

                      
The protocol will also allow the client to present unverified identifiers and verifiable assertions to the AS as part of its request. 

                      
 

                      
[Denis] This sentence is too vague because "as part of its request" is not explicit enough. If it means  "as part as an access token request" 

                      
this should be explicitly said. If, it is not the case, then it should be clearly explained. The AS should know as little as possible (including nothing)

                      
about what the client is doing.

                      
 

                      
[Roman] The “request” here is the “access token request”.  That can be made clearer.

                    

                  

                

              

              
This would be
                appreciated.

              

                

                  

                    

                      

                      
 

                      
This protocol will allow an authorizing party to delegate access to client software through an authorization server. 

                      
 

                      
[Denis] The word "privacy" is still missing in the charter. "Delegating access to client software through an authorization server" 

                      
is negating the fact that the user's privacy will ever be considered. IMHO, I believe that a RS may delegate some operation to another RS, 

                      
but I don't believe that an AS should be concerned by any form of delegation, otherwise it would have the ability to act as "Big Brother".

                      
OAuth has not been constructed taking into consideration the user's privacy. The major difference with it should be that GNAP has been 

                      
constructed along "privacy by design" principles.

                      
 

                      
[Roman]  I don’t exactly follow how considerations for privacy are being negated.  Above and beyond use-case specific considerations that would be defined later, 
RFC6973 is the IETF consensus design guidance that will guide the privacy threats and mitigations of the work.  What design guidance would you recommend that 
the WG should consider that aren’t captured in RFC6973?

                    

                  

                

              

              
I believe my message is
                quite clear : If the AS is handling the delegation
                process, it will know what the client is doing or where
                it is going. 

                On the contrary, if the RS is handling the delegation
                process, the AS will be unable to know what the client
                is doing. In addition, an AS-centric 

                architecture would not be scalable and would need a lot
                of synchronizations between ASs and RSs. The user
                consent should be handled by the RS 

                and not by the AS. When a RS is unable to provide the
                service, it is best placed to tell directly to the
                client what it could do next. 

              

              
RFC 6973 is very good
                document. Section 7.1 states: 

              

              
          b.  Data. 
                What information does the protocol expose about
                individuals, their devices, and/or their device usage
                (other than the identifiers discussed in (a))? 

              

              
Data includes both the
                operation and the data associated with the operation. An
                AS should be kept ignorant of both the operation and the
                data associated with the operation.

              

                
c.  Observers.  (...) Are there ways for
                  protocol implementers to  choose to limit the
                  information shared with each entity?  

                

              

              
If theses guidances
                were followed, the proposed architecture would not be
                AS-centric.

              

                

                  

                    

                      
 

                      
It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations 

                      
scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove 

                      
unnecessary dependence on a browser or user-agent for coordinating interactions.

                      
 

                      
[Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. Some existing uses cases (i.e. "non-expanded" use cases) should be supported 

                      
differently from OAuth 2.0 and OpenID Connect, in particular to support the user's privacy.

                      
 

                      
[Roman] I’d want to hear others on this rescoping.  Building upon the use cases of OAuth 2.0 and OpenID Connect has been core, consensus-validated tenant for some time now.

                      
 

                      
The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the channels used 

                      
by the protocol participants to communicate from the delegation channel, which happens directly between the client and the authorization server (in contrast 

                      
with OAuth 2.0, which is initiated by the client redirecting the user’s browser). 

                      
 

                      
[Denis] Here again, the delegation process, if any, should be handled by RSs and not by ASs. 

                      
The term "delegation channel" is being used but it is left undefined. It is not understandable.

                      
 

                      
[Roman] This sentence was just added into -05 address Security AD feedback.  In this case, it was made to distinguish between in-band signaling and the new purpose-to-be-built channel.

                    

                  

                

              

              
Since delegation should
                not be handled by the AS, a delegation channel should
                not exist.

              

                

                  

                    

                      

                      
 

                      
The protocol will include a means of specifying how the user can potentially be involved in an interactive fashion during the delegation process. 

                      
The client and Authorization Server (AS) will use these interaction mechanisms to involve the user, as necessary, to make authorization decisions.

                      
 

                      
[Denis] Here again, the delegation process, if any, should be handled by RSs and not by ASs. The AS should know as little as possible (including nothing)

                      
about what the client is doing.

                      
 

                      
[Roman] Understood – as I understand it, you have concern with the scope of the AS behavior.  I’d be interesting in hearing additional support for this rescoping.  

                      
 

                      
This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types 

                      
of clients and interaction channels.

                      
 

                      
[Denis] This is not understandable to me. Is such a sentence really needed in a charter ?

                      
 

                      
[Roman] Can someone on the TxAuth mailing list remind us on why this sentence is here?  With a fresh read, I also can’t remember why we need it.

                      
 

                      
The group will define interoperability for this protocol between different parties, including

                      
-          client and authorization server;

                      
-          client and resource server; and

                      
     -      authorization server and resource server.

                      
 

                      
[Denis] In order to support the user's privacy, there should be no interaction at all between an authorization server and a resource server 

                      
at the time of a client request.

                      
 

                      
The group will seek to minimize assumptions about the form of client applications, allowing for:

                      
-          Fine-grained specification of access

                      
-          Approval of AS attestation to identifiers and other identity claims

                      
-          Approval of access to multiple resources and APIs in a single interaction

                      
-          Multiple access tokens in a single request and response

                      
-          AS-directed dispatch of access tokens to the appropriate RS

                      
[Denis] As-directed dispatch does not allow to support the user's privacy. However, RS-directed dispatch allows to support the user's privacy.

                      
It should be explicitly mentioned.

                      
[Roman] As above (per the AS vs. RS behavior)

                      
-          Separation between the party authorizing access and the party operating the client requesting access 

                      
 

                      
[Denis] It is questionable whether such a separation would be really beneficial. In doubt, this item should be removed.

                      
[Roman] Could you say more on why this flexibility wouldn’t be worth it?  

                    

                  

                

              

              
Except for added
                complexity, there is no need to have separate channels.
                It is simpler to send the access token in addition to
                the data 

                and, for additional security, to sign the data using a
                private key corresponding to a public key present in the
                access token.

              

                

                  

                    

                      

                      
The group will define extension points for this protocol to allow for flexibility in areas including:

                      
 

                      
Cryptographic agility for keys, message signatures, and proof of possession

                      
-          User interaction mechanisms including web and non-web methods

                      
-          Mechanisms for conveying user, software, organization, and other information used in authorization decisions 

                      
-          Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys 

                      
Optimized inclusion of additional information (including identifiers and identity assertions) through the delegation process 

                      
 

                      
Additionally, the group will provide mechanisms for management of the protocol lifecycle including:

                      
-          Discovery of the authorization server

                      
-          Revocation of active tokens

                      
Data model for granted access and mechanisms for the AS and RS to communicate the granted access model

                      
 

                      
[Denis] While it is the duty for the RS to communicate the granted access model to the client at the appropriate instant of time, 

                      
the AS should be kept fully ignorant of it.

                      
 

                      
Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, 

                      
the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.

                      
 

                      
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. Functionality that builds directly on OAuth 2.0 will be directed to the OAuth Working Group, including 

                      
functionality back-ported from the protocol developed here to OAuth 2.0.

                      
 

                      
The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. 

                      
This group is not chartered to develop new cryptographic methods.

                      
 

                      
The group is chartered to develop mechanisms for conveying identity information within the protocol including existing identifiers 

                      
(such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, 

                      
SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group 

                      
chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available.

                      
 

                      
The initial work will focus on using HTTPS for communication between the client and the authorization server, taking advantage 

                      
of optimization features of HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to other protocols such as COAP 

                      
when doing so does not conflict with the primary focus.

                      
 

                      
Milestones to include:

                      
-          Core delegation protocol

                      
[Denis] Before defining a "Core delegation protocol", a simple client server-protocol involving the presentation of several access tokens to one RS should be defined. 

                      
Privacy principles should be applied when defining the protocol. Then after, a delegation mechanism allowing one RS to forward an operation to another RS should be defined.

                      
-          Key presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded HTTP signatures 

                      
[Denis] Bindings to TLS are now deprecated, why should they be maintained ? 

                      
Signatures may be needed but they do not necessarily need to be "detached HTTP signature, and embedded HTTP signatures". 

                      
This item should be either removed or reworded.

                      
[Roman] Noted.  I’d want to hear others on this rescoping.

                    

                  

                

              

              
As explained above, it
                is possible to sign the data using a private key
                corresponding to a public key present in the access
                token.

              

                

                  

                    

                      

                      
 

                      
-          Conveyance mechanisms for identifiers and assertions 

                      
-          Guidelines for use of protocol extension points (if needed) 

                      
     -    Guidelines on
                          migration paths, implementation, and
                          operations

                      
[Denis] The
                          above three lines are rather mysterious.

                      
[Roman] The guidelines on
                        migration paths came from the initial IESG
                        review in order to have a named activity to
                        action the design goal of “… the group will
                        attempt to simplify migrating from OAuth 2.0 and
                        OpenID Connect to the new protocol where
                        possible” a bit earlier in the text.

                      
Where possible, the
                          group will seek to make use of tools to guide
                          and inform the standardization process
                          including formal analysis, 

                          architecture documents, and use case
                          documents. These artifacts will not be
                          considered as working group milestones or
                          deliverables.

                      
The working group will
                          cooperate and coordinate with other IETF WGs
                          such as OAUTH, and work with external
                          organizations, 

                          such as the OpenID Foundation, as appropriate.

                      
[Denis] The
                          charter should be shorter.

                      
 

                      
[Roman] Definitely.  Nevertheless, we
                        have the current text through rough consensus
                        process achieved from two BoFs and multiple
                        mailing list consensus calls.

                    

                  

                

              

              
In a previous post, I
                proposed a much shorter text.

              
Denis

              

              

                

                  

                    

                      

                      
 

                      
Regards,

                      
Roman 

                    

                    

                      
 

                    

                    

                      
/Denis

                    

                    

                      
 

                    

                    

                      
A new IETF WG has been proposed in the Security Area. The IESG has not made

                      
any determination yet. The following draft charter was submitted, and is

                      
provided for informational purposes only. Please send your comments to the

                      
IESG mailing list (iesg@ietf.org) by 2020-07-06.

                      
 

                      
Grant Negotiation and Authorization Protocol (gnap)

                      
-----------------------------------------------------------------------

                      
Current status: Proposed WG

                      
 

                      
Chairs:

                      
  Yaron Sheffer <yaronf.ietf@gmail.com>

                      
  Leif Johansson <leifj@sunet.se>

                      
 

                      
Assigned Area Director:

                      
  Roman Danyliw <rdd@cert.org>

                      
 

                      
Security Area Directors:

                      
  Benjamin Kaduk <kaduk@mit.edu>

                      
  Roman Danyliw <rdd@cert.org>

                      
 

                      
Mailing list:

                      
  Address: txauth@ietf.org

                      
  To subscribe: ​https://www.ietf.org/mailman/listinfo/txauth

                      
  Archive: https://mailarchive.ietf.org/arch/browse/txauth/

                      
 

                      
Group page: https://datatracker.ietf.org/group/gnap/

                      
 

                      
Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/

                      
 

                      
This group is chartered to develop a fine-grained delegation protocol for

                      
authorization and API access, as well as requesting and providing user

                      
identifiers and claims. This protocol will allow an authorizing party to

                      
delegate access to client software through an authorization server. It will

                      
expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect

                      
(itself an extension of OAuth 2.0) to support authorizations scoped as

                      
narrowly as a single transaction, provide a clear framework for interaction

                      
among all parties involved in the protocol flow, and remove unnecessary

                      
dependence on a browser or user-agent for coordinating interactions.

                      
 

                      
The delegation process will be acted upon by multiple parties in the protocol,

                      
each performing a specific role. The protocol will decouple the interaction

                      
channels, such as the end user’s browser, from the delegation channel, which

                      
happens directly between the client and the authorization server (in contrast

                      
with OAuth 2.0, which is initiated by the client redirecting the user’s

                      
browser). The protocol will include a means of specifying how the user can

                      
potentially be involved in an interactive fashion during the delegation

                      
process. The client and Authorization Server (AS) will use these interaction

                      
mechanisms to involve the user, as necessary, to make authorization decisions.

                      
This decoupling avoids many of the security concerns and technical challenges

                      
of OAuth 2.0 and provides a non-invasive path for supporting future types of

                      
clients and interaction channels.

                      
 

                      
The group will define interoperability for this protocol between different

                      
parties, including

                      
 - client and authorization server;

                      
 - client and resource server; and

                      
 - authorization server and resource server.

                      
 

                      
The group will seek to minimize assumptions about the form of client

                      
applications, allowing for:

                      
- Fine-grained specification of access

                      
- Approval of AS attestation to identifiers and other identity claims

                      
- Approval of access to multiple resources and APIs in a single interaction

                      
- Support for multiple access tokens in a single request and response

                      
- Support for directed, audience-restricted access tokens

                      
- Separation between the party authorizing access and the party operating the

                      
client requesting access

                      
 

                      
The group will define extension points for this protocol to allow for

                      
flexibility in areas including:

                      
 

                      
- Cryptographic agility for keys, message signatures, and proof of possession

                      
- User interaction mechanisms including web and non-web methods

                      
- Mechanisms for conveying user, software, organization, and other

                      
information used in authorization decisions

                      
- Mechanisms for presenting tokens to resource servers and binding resource

                      
requests to tokens and associated cryptographic keys

                      
- Optimized inclusion of additional information (including identifiers and

                      
identity assertions) through the delegation process

                      
 

                      
Additionally, the group will provide mechanisms for management of the protocol

                      
lifecycle including:

                      
 

                      
- Discovery of the authorization server

                      
- Revocation of active tokens

                      
- Mechanisms for the AS and RS to communicate the access granted by an access

                      
token

                      
 

                      
Although the artifacts for this work are not intended or expected to be

                      
backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt

                      
to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol

                      
where possible.

                      
 

                      
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. Functionality that builds directly on OAuth 2.0 will be directed

                      
to the OAuth Working Group, including functionality back-ported from the

                      
protocol developed here to OAuth 2.0.

                      
 

                      
The group is chartered to develop mechanisms for applying cryptographic

                      
methods, such as JOSE and COSE, to the delegation process. This group is not

                      
chartered to develop new cryptographic methods.

                      
 

                      
The group is chartered to develop mechanisms for conveying identity

                      
information within the protocol including existing identifiers (such as email

                      
addresses, phone numbers, usernames, and subject identifiers) and assertions

                      
(such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable

                      
Credentials). The group is not chartered to develop new formats for

                      
identifiers or assertions, nor is the group chartered to develop schemas for

                      
user information, profiles, or other identity attributes, unless a viable

                      
existing format is not available.

                      
 

                      
The initial work will focus on using HTTPS for communication between the

                      
client and the authorization server, taking advantage of optimization

                      
features of HTTP/2 and HTTP/3 where possible, and will strive to enable

                      
simple mapping to other protocols such as COAP when doing so does not

                      
conflict with the primary focus.

                      
 

                      
Milestones to include:

                      
- Core delegation protocol

                      
- Key presentation mechanism bindings to the core protocol including TLS,

                      
detached HTTP signature, and embedded HTTP signatures

                      
- Conveyance mechanisms for identifiers and assertions

                      
- Guidelines for use of protocol extension points

                      
- (if needed) Guidelines on migration paths, implementation, and operations

                      
 

                      
Where possible, the group will seek to make use of tools to guide and inform

                      
the standardization process including formal analysis, architecture documents,

                      
and use case documents. These artifacts will not be considered as working

                      
group milestones or deliverables.

                      
 

                      
The working group will cooperate and coordinate with other IETF WGs such as

                      
OAUTH, and work with external organizations, such as the OpenID Foundation,

                      
as appropriate.

                      
 

                      
Milestones:

                      
 

                      
  Jul 2021 - Core delegation protocol in WGLC

                      
 

                      
  Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to

                      
  WGLC

                      
 

                      
  Oct 2021 - Key presentation mechanism binding to the core protocol, 

                      
  detached HTTP signatures, to WGLC

                      
 

                      
  Oct 2021 - Key presentation mechanism binding to the core protocol,

                      
  embedded HTTP signature, to WGLC

                      
 

                      
  Dec 2021 - Guidelines for use of protocol extension points to WGLC

                      
 

                      
  Feb 2022 - Guidelines on migration paths, implementation, and operations to

                      
   WGLC

                      
 

                      
 

                      
 

                    

                    
 

                  

                

              

              


              

              -- 

              Txauth mailing list

              Txauth@ietf.org

              https://www.ietf.org/mailman/listinfo/txauth

          

        

        

      

    

    


    

  


--------------E18763AA8C1C01D5DFD9C294--


From nobody Tue Jul  7 10:07: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 CCB3D3A115D; Tue,  7 Jul 2020 10:07:16 -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_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 jEbH-iKkdqud; Tue,  7 Jul 2020 10:07:12 -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 CC53C3A1160; Tue,  7 Jul 2020 10:07:11 -0700 (PDT)
Received: by mail-ot1-x32d.google.com with SMTP id 5so32831607oty.11; Tue, 07 Jul 2020 10:07: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=1ufTYs/2ZkbuD1DpKxcyjtZYQisiqzGBezw8VRI+RcI=; b=Y1evX4jsrCbgcfvQS+snOBzHi0vAFIJYUs0QSgH82lUTkkrTuBCKm0XYhtw4BoOVfw 70pkVDAX+n+1JSXg7For8j3TbYLl181sfYQRWQ1A/yORY4elgB8DNd2JdraZ9cgvKTc8 drNQEATOyT6Kc1unRugrU96BcQzs0L9eKWIzFYWvfgDKVmRTjV+1qcnqBNG/QKVHnNx+ 3WqDTjv6IP3kDLq1ZTxIA7IsKMlrLcEHpWFrL3gPOliRbA6AOh4iQiX4wM/cTab/7UIZ n/r6hcX4RX8B4H4DB4uVYyI/AwLSH9yWzxb5o9Wu8WoTZhz510X83FPsRmo8qKVIcz1t ldpg==
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=1ufTYs/2ZkbuD1DpKxcyjtZYQisiqzGBezw8VRI+RcI=; b=SAvZ5bR6WUar3zQ0tTaRMUw1yDLA8MudIIz66dX7WWfcfH6+KjBNWRgnYsJxEdbIh+ yofbgtUnJprLAILkRn2uJmyrgYeUfE1p1iq4fMfbiHk9Vl0za/Tek1WhGJFFOCJKgCeO s8xtfC2++24JfjjmUvpHm8OGbJBOJGFgx8CAREYuU7/7ndQ/p1GYHnTkIV1yjoxke6Zj jV4Z6oDuyj3iSPEb7eRhBQsiwQR/FEYlCdVKzzIEuQ/vmSGEy2K4ny644EVDirbx3B8w bTp+PfYD9hDBgW9So/9OK7WpM2salB9+I2xV+y0cN7MtSaoLSe8LjNKCr3IbE7JUjb3C ouKQ==
X-Gm-Message-State: AOAM531s309lKhVhTmZ7WUFk3BnW1WbAQJ9LYhWi0r/BCpdYEjj5rV5+ 8xhY9LQxrE/qWngQ7GFFNC8TRzjNUvW4SmbxLEY=
X-Google-Smtp-Source: ABdhPJycn1DqRqCweUE3VoFL57MBToLAON56cmwWjyrRvwVkWWpprDFwaVrXcb2AIdxcqykTYakVBYJ/GAbE8t839Ug=
X-Received: by 2002:a9d:66ca:: with SMTP id t10mr29704149otm.358.1594141630724;  Tue, 07 Jul 2020 10:07:10 -0700 (PDT)
MIME-Version: 1.0
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <7563640e-f515-3e73-a4eb-3902ec7af50e@free.fr> <3424311c60f541b197cfda6e9f3b494e@cert.org> <36de4e6a-41fe-81b1-6c92-69fe5b63ad6f@free.fr>  
In-Reply-To: 
From: Tom Jones 
Date: Tue, 7 Jul 2020 10:06:56 -0700
Message-ID: 
To: Denis 
Cc: Justin Richer , Roman Danyliw , "iesg@ietf.org" , "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000009efd8705a9dd05f0"
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 07 Jul 2020 17:07:17 -0000

--0000000000009efd8705a9dd05f0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Again to be blunt, my flow for consent doesn't match yours.

thx ..Tom (mobile)

On Tue, Jul 7, 2020, 10:04 AM Denis  wrote:

> Justin,
>
> Denis,
>
> A lot of what you=E2=80=99re describing below changes the very nature of =
the roles
> in the system. The component that manages the consent and issues tokens i=
s,
> by definition, the AS.
>
> The current charter states: "the artifacts for this work are not intended
> or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect".
> So we are not bound to OAuth 2.0 nor OpenID Connect. Hence, we do not nee=
d
> to stick with all their concepts.
>
> I believe that the user's consent should be given after a dialogue with
> the RS which does not mean that the RS shall capture the user's consent
> since it is the duty of the client. When a user selects one operation
> among a choice of operations proposed by the RS, the RS should inform
> the client about which attributes it needs to present and from which ASs.
> It is only at this moment that the clients learns which ASs are
> adequate. Before this moment, the dialogue *cannot* be handled by an AS.
> Then after the duty of the client is to look for these attributes and
> to get them from one or more ASs. ASs are all equal. There is no single A=
S
> with which the user shall be bound or have a particular relationship
>
> Managing the authorization (and the user's consent) at the RS is simple: =
I
> have proposed a way to do it (and FIDO U2F is even included).
>
> Managing the authorization at the AS would mandate a close synchronizatio=
n
> between the RS and all the ASs with which it has a relationship.
> There would be the need to define a synch. protocol and it is much simple=
r
> to avoid to use such a protocol and thus not to define it.
> "Out-of-bands" means for such a synchronisation would not be a better
> solution. But the major issue by managing the user's consent at the AS
> is to allow the AS to act as Big Brother.
>
> A copy and paste from a document published under the "Digital Europe for
> All" (DE4A) project :
>
> The privacy principle requires that the private life, the home and the
> communications of each citizen
> are respected and that no personal data are gathered without a legitimate
> reason and purpose.
>
> Data protection and privacy should (as far as possible) be *achieved by
> design*, i.e. be embedded in the
> technical solutions and services in a way that misuse or illegitimate
> access is made impossible or at
> least very difficult through the technical approach itself, and *without
> having to rely on organisational *
> *measures or solely on legal measures to guarantee the compliance*.
>
> Main sources for this principle: CFREU, GDPR, eIDAS, eGov Action Plan,
> EIF, Tallinn Declaration, and
> SDGR.
>
> The user shouldn=E2=80=99t ever have to interact directly with the RS, si=
nce the
> RS is, by definition, an API that is called by software, not an interacti=
ve
> component.
>
> But it=E2=80=99s important to note that these are only :roles: to be play=
ed and
> not strictly speaking separate pieces of software, and that these roles c=
an
> be combined and split in a variety of ways. For instance, in what you=E2=
=80=99re
> talking about below, instead of saying that it=E2=80=99s the RS that mana=
ges the
> consent, what if you saw it as the functionality of the AS that=E2=80=99s=
 been
> split between two components: one privacy-preserving element that issues
> tokens, and another that deals with interaction and consent. This is
> already a pattern that some in the WG have expressed interest in supporti=
ng
> with GNAP, and the core charter tenet of separating the interaction from
> the delegation channels is something that could help there.
>
> Would it be possible to look at your use case in this different light?
>
> I could see the RS (i.e. not the AS) split into two components: an API an=
d
> an MMI to manage the choices and the consent of the user.
> This looks artificial but would it help ?
>
> Denis
>
> It=E2=80=99s always possible that we need to re-cast some of these roles,=
 and
> that=E2=80=99s been done before: in OAuth 2 we defined the AS and RS role=
s
> separately, even though they can always be deployed together anyway. So
> with that it=E2=80=99s possible that there are other distinct pieces here=
 that are
> working together that we need to tease out, but that=E2=80=99s something =
for the WG
> to figure out. We can always decide to separate out the parts and allow
> them to be recombined in deployment, But I do not think it is helpful to
> redefine the existing roles, especially by moving key facets from one
> existing role to another.
>
>  =E2=80=94 Justin
>
> On Jul 7, 2020, at 8:43 AM, Denis  wrote:
>
> Hi Roman,
>
> Hi Denis!
>
> Thanks for the feedback and for repeating your review on the revised
> text.  More inline =E2=80=A6
>
> *From:* iesg   *On Behalf
> Of *Denis
> *Sent:* Monday, July 6, 2020 10:55 AM
> *To:* iesg@ietf.org
> *Cc:* txauth@ietf.org
> *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization
> Protocol (gnap)
>
> Since it is today the last day to send back comments, you will find
> hereafter my comments on the last charter version-05.
>
> BTW, I sent an email yesterday evening with the subject: *Support of FIDO=
*
>  and data minimization by RSs, where I indicated that the charter should
> mention FIDO U2F so that it should be possible to logon to a RS using
> either FIDO or by presenting one (or more) access tokens from one (or mor=
e)
> AS.
>
> The original email is here :
> https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/
>
> charter-ietf-gnap-00-05
>
> This group is chartered to develop a fine-grained delegation protocol for=
 authorization, API access, user identifiers, and identity assertions.
>
>
>
> [Denis] Fine.
>
>
>
> The protocol will also allow the client to present unverified identifiers=
 and verifiable assertions to the AS as part of its request.
>
>
>
> [Denis] This sentence is too vague because "as part of its request" is no=
t explicit enough. If it means  "as part as an access token request"
>
> this should be explicitly said. If, it is not the case, then it should be=
 clearly explained. The AS should know as little as possible (including not=
hing)
>
> about what the client is doing.
>
>
>
> [Roman] The =E2=80=9Crequest=E2=80=9D here is the =E2=80=9Caccess token r=
equest=E2=80=9D.  That can be made clearer.
>
> This would be appreciated.
>
>
>
> This protocol will allow an authorizing party to delegate access to clien=
t software through an authorization server.
>
>
>
> [Denis] The word "*privacy*" is still missing in the charter. "Delegating=
 access to client software through an authorization server"
>
> is negating the fact that the user's privacy will ever be considered. IMH=
O, I believe that a RS may delegate some operation to another RS,
>
> but I don't believe that an AS should be concerned by any form of delegat=
ion, otherwise it would have the ability to act as "Big Brother".
>
> OAuth has not been constructed taking into consideration the user's priva=
cy. The major difference with it should be that GNAP has been
>
> constructed along "*privacy by design*" principles.
>
>
>
> [Roman]  I don=E2=80=99t exactly follow how considerations for privacy ar=
e being negated.  Above and beyond use-case specific considerations that wo=
uld be defined later,
> RFC6973 is the IETF consensus design guidance that will guide the privacy=
 threats and mitigations of the work.  What design guidance would you recom=
mend that
> the WG should consider that aren=E2=80=99t captured in RFC6973?
>
> I believe my message is quite clear : If the AS is handling the delegatio=
n
> process, it will know what the client is doing or where it is going.
> On the contrary, if the RS is handling the delegation process, the AS wil=
l
> be unable to know what the client is doing. In addition, an AS-centric
> architecture would not be scalable and would need a lot of
> synchronizations between ASs and RSs. The user consent should be handled =
by
> the RS
> and not by the AS. When a RS is unable to provide the service, it is best
> placed to tell directly to the client what it could do next.
>
> RFC 6973 is very good document. Section 7.1 states:
>
>           b.  Data.  What information does the protocol expose about
> individuals, their devices, and/or their device usage (other than the
> identifiers discussed in (a))?
>
> Data includes both the operation and the data associated with the
> operation. An AS should be kept ignorant of both the operation and the da=
ta
> associated with the operation.
>
> c.  Observers.  (...) Are there ways for protocol implementers to  choose
> to limit the information shared with each entity?
>
> If theses guidances were followed, the proposed architecture would not be
> AS-centric.
>
>
>
> It will *expand* upon the uses cases currently supported by OAuth 2.0 and=
 OpenID Connect (itself an extension of OAuth 2.0) to support authorization=
s
>
> scoped as narrowly as a single transaction, provide a clear framework for=
 interaction among all parties involved in the protocol flow, and remove
>
> unnecessary dependence on a browser or user-agent for coordinating intera=
ctions.
>
>
>
> [Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. Some e=
xisting uses cases (i.e. "*non-expanded"* use cases) should be supported
>
> differently from OAuth 2.0 and OpenID Connect, in particular to support t=
he user's privacy.
>
>
>
> [Roman] I=E2=80=99d want to hear others on this rescoping.  Building upon=
 the use cases of OAuth 2.0 and OpenID Connect has been core, consensus-val=
idated tenant for some time now.
>
>
>
> The delegation process will be acted upon by multiple parties in the prot=
ocol, each performing a specific role. The protocol will decouple the chann=
els used
>
> by the protocol participants to communicate from the delegation channel, =
which happens directly between the client and the authorization server (in =
contrast
>
> with OAuth 2.0, which is initiated by the client redirecting the user=E2=
=80=99s browser).
>
>
>
> [Denis] Here again, the delegation process, if any, should be handled by =
RSs and not by ASs.
>
> The term "delegation channel" is being used but it is left undefined. It =
is not understandable.
>
>
>
> [Roman] This sentence was just added into -05 address Security AD feedbac=
k.  In this case, it was made to distinguish between in-band signaling and =
the new purpose-to-be-built channel.
>
> Since delegation should not be handled by the AS, a delegation channel
> should not exist.
>
>
>
> The protocol will include a means of specifying how the user can potentia=
lly be involved in an interactive fashion during the delegation process.
>
> The client and Authorization Server (AS) will use these interaction mecha=
nisms to involve the user, as necessary, to make authorization decisions.
>
>
>
> [Denis] Here again, the delegation process, if any, should be handled by =
RSs and not by ASs. The AS should know as little as possible (including not=
hing)
>
> about what the client is doing.
>
>
>
> [Roman] Understood =E2=80=93 as I understand it, you have concern with th=
e scope of the AS behavior.  I=E2=80=99d be interesting in hearing addition=
al support for this rescoping.
>
>
>
> This decoupling avoids many of the security concerns and technical challe=
nges of OAuth 2.0 and provides a non-invasive path for supporting future ty=
pes
>
> of clients and interaction channels.
>
>
>
> [Denis] This is not understandable to me. Is such a sentence really neede=
d in a charter ?
>
>
>
> [Roman] Can someone on the TxAuth mailing list remind us on why this sent=
ence is here?  With a fresh read, I also can=E2=80=99t remember why we need=
 it.
>
>
>
> The group will define interoperability for this protocol between differen=
t parties, including
>
> -          client and authorization server;
>
> -          client and resource server; and
>
>      -      authorization server and resource server.
>
>
>
> [Denis] In order to support the user's privacy, there should be no intera=
ction at all between an authorization server and a resource server
>
> *at the time of a client request*.
>
>
>
> The group will seek to minimize assumptions about the form of client appl=
ications, allowing for:
>
> -          Fine-grained specification of access
>
> -          Approval of AS attestation to identifiers and other identity c=
laims
>
> -          Approval of access to multiple resources and APIs in a single =
interaction
>
> -          Multiple access tokens in a single request and response
>
> -          AS-directed dispatch of access tokens to the appropriate RS
>
> [Denis] As-directed dispatch does not allow to support the user's privacy=
. However, RS-directed dispatch allows to support the user's privacy.
>
> It should be explicitly mentioned.
>
> [Roman] As above (per the AS vs. RS behavior)
>
> -          Separation between the party authorizing access and the party =
operating the client requesting access
>
>
>
> [Denis] It is questionable whether such a separation would be really bene=
ficial. In doubt, this item should be removed.
>
> [Roman] Could you say more on why this flexibility wouldn=E2=80=99t be wo=
rth it?
>
> Except for added complexity, there is no need to have separate channels.
> It is simpler to send the access token in addition to the data
> and, for additional security, to sign the data using a private key
> corresponding to a public key present in the access token.
>
> The group will define extension points for this protocol to allow for fle=
xibility in areas including:
>
>
>
> Cryptographic agility for keys, message signatures, and proof of possessi=
on
>
> -          User interaction mechanisms including web and non-web methods
>
> -          Mechanisms for conveying user, software, organization, and oth=
er information used in authorization decisions
>
> -          Mechanisms for presenting tokens to resource servers and bindi=
ng resource requests to tokens and associated cryptographic keys
>
> Optimized inclusion of additional information (including identifiers and =
identity assertions) through the delegation process
>
>
>
> Additionally, the group will provide mechanisms for management of the pro=
tocol lifecycle including:
>
> -          Discovery of the authorization server
>
> -          Revocation of active tokens
>
> Data model for granted access and mechanisms for the AS and RS to communi=
cate the granted access model
>
>
>
> [Denis] While it is the duty for the RS to communicate the granted access=
 model to the client *at the appropriate instant of time*,
>
> the AS should be kept fully ignorant of it.
>
>
>
> Although the artifacts for this work are not intended or expected to be b=
ackwards-compatible with OAuth 2.0 or OpenID Connect,
>
> the group will attempt to simplify migrating from OAuth 2.0 and OpenID Co=
nnect to the new protocol where possible.
>
>
>
> This group is not chartered to develop extensions to OAuth 2.0, and as su=
ch will focus on new technological solutions not necessarily
>
> compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.=
0 will be directed to the OAuth Working Group, including
>
> functionality back-ported from the protocol developed here to OAuth 2.0.
>
>
>
> The group is chartered to develop mechanisms for applying cryptographic m=
ethods, such as JOSE and COSE, to the delegation process.
>
> This group is not chartered to develop new cryptographic methods.
>
>
>
> The group is chartered to develop mechanisms for conveying identity infor=
mation within the protocol including existing identifiers
>
> (such as email addresses, phone numbers, usernames, and subject identifie=
rs) and assertions (such as OpenID Connect ID Tokens,
>
> SAML Assertions, and Verifiable Credentials). The group is not chartered =
to develop new formats for identifiers or assertions, nor is the group
>
> chartered to develop schemas for user information, profiles, or other ide=
ntity attributes, unless a viable existing format is not available.
>
>
>
> The initial work will focus on using HTTPS for communication between the =
client and the authorization server, taking advantage
>
> of optimization features of HTTP/2 and HTTP/3 where possible, and will st=
rive to enable simple mapping to other protocols such as COAP
>
> when doing so does not conflict with the primary focus.
>
>
>
> Milestones to include:
>
> -          Core delegation protocol
>
> [Denis] Before defining a "Core delegation protocol", a simple client ser=
ver-protocol involving the presentation of several access tokens to one RS =
should be defined.
>
> Privacy principles should be applied when defining the protocol. Then aft=
er, a delegation mechanism allowing one RS to forward an operation to anoth=
er RS should be defined.
>
> -          Key presentation mechanism bindings to the core protocol inclu=
ding TLS, detached HTTP signature, and embedded HTTP signatures
>
> [Denis] Bindings to TLS are now deprecated, why should they be maintained=
 ?
>
> Signatures may be needed but they do not necessarily need to be "detached=
 HTTP signature, and embedded HTTP signatures".
>
> This item should be either removed or reworded.
>
> [Roman] Noted.  I=E2=80=99d want to hear others on this rescoping.
>
> As explained above, it is possible to sign the data using a private key
> corresponding to a public key present in the access token.
>
>
>
> -          Conveyance mechanisms for identifiers and assertions
>
> -          Guidelines for use of protocol extension points (if needed)
>
>      -    Guidelines on migration paths, implementation, and operations
> [Denis] The above three lines are rather mysterious.
> [Roman] The guidelines on migration paths came from the initial IESG
> review in order to have a named activity to action the design goal of =E2=
=80=9C=E2=80=A6
> the group will attempt to simplify migrating from OAuth 2.0 and OpenID
> Connect to the new protocol where possible=E2=80=9D a bit earlier in the =
text.
> Where possible, the group will seek to make use of tools to guide and
> inform the standardization process including formal analysis,
> architecture documents, and use case documents. These artifacts will not
> be considered as working group milestones or deliverables.
> The working group will cooperate and coordinate with other IETF WGs such
> as OAUTH, and work with external organizations,
> such as the OpenID Foundation, as appropriate.
> [Denis] The charter should be shorter.
>
> [Roman] Definitely.  Nevertheless, we have the current text through rough
> consensus process achieved from two BoFs and multiple mailing list
> consensus calls.
>
> In a previous post, I proposed a much shorter text.
>
> Denis
>
>
> Regards,
> Roman
>
> /Denis
>
>
> A new IETF WG has been proposed in the Security Area. The IESG has not ma=
de
>
> any determination yet. The following draft charter was submitted, and is
>
> provided for informational purposes only. Please send your comments to th=
e
>
> IESG mailing list (iesg@ietf.org) *by 2020-07-06*.
>
>
>
> Grant Negotiation and Authorization Protocol (gnap)
>
> -----------------------------------------------------------------------
>
> Current status: Proposed WG
>
>
>
> Chairs:
>
>   Yaron Sheffer  
>
>   Leif Johansson  
>
>
>
> Assigned Area Director:
>
>   Roman Danyliw  
>
>
>
> Security Area Directors:
>
>   Benjamin Kaduk  
>
>   Roman Danyliw  
>
>
>
> Mailing list:
>
>   Address: txauth@ietf.org
>
>   To subscribe: =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/txauth
>
>   Archive: https://mailarchive.ietf.org/arch/browse/txauth/
>
>
>
> Group page: https://datatracker.ietf.org/group/gnap/
>
>
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/
>
>
>
> This group is chartered to develop a fine-grained delegation protocol for
>
> authorization and API access, as well as requesting and providing user
>
> identifiers and claims. This protocol will allow an authorizing party to
>
> delegate access to client software through an authorization server. It wi=
ll
>
> expand upon the uses cases currently supported by OAuth 2.0 and OpenID Co=
nnect
>
> (itself an extension of OAuth 2.0) to support authorizations scoped as
>
> narrowly as a single transaction, provide a clear framework for interacti=
on
>
> among all parties involved in the protocol flow, and remove unnecessary
>
> dependence on a browser or user-agent for coordinating interactions.
>
>
>
> The delegation process will be acted upon by multiple parties in the prot=
ocol,
>
> each performing a specific role. The protocol will decouple the interacti=
on
>
> channels, such as the end user=E2=80=99s browser, from the delegation cha=
nnel, which
>
> happens directly between the client and the authorization server (in cont=
rast
>
> with OAuth 2.0, which is initiated by the client redirecting the user=E2=
=80=99s
>
> browser). The protocol will include a means of specifying how the user ca=
n
>
> potentially be involved in an interactive fashion during the delegation
>
> process. The client and Authorization Server (AS) will use these interact=
ion
>
> mechanisms to involve the user, as necessary, to make authorization decis=
ions.
>
> This decoupling avoids many of the security concerns and technical challe=
nges
>
> of OAuth 2.0 and provides a non-invasive path for supporting future types=
 of
>
> clients and interaction channels.
>
>
>
> The group will define interoperability for this protocol between differen=
t
>
> parties, including
>
>  - client and authorization server;
>
>  - client and resource server; and
>
>  - authorization server and resource server.
>
>
>
> The group will seek to minimize assumptions about the form of client
>
> applications, allowing for:
>
> - Fine-grained specification of access
>
> - Approval of AS attestation to identifiers and other identity claims
>
> - Approval of access to multiple resources and APIs in a single interacti=
on
>
> - Support for multiple access tokens in a single request and response
>
> - Support for directed, audience-restricted access tokens
>
> - Separation between the party authorizing access and the party operating=
 the
>
> client requesting access
>
>
>
> The group will define extension points for this protocol to allow for
>
> flexibility in areas including:
>
>
>
> - Cryptographic agility for keys, message signatures, and proof of posses=
sion
>
> - User interaction mechanisms including web and non-web methods
>
> - Mechanisms for conveying user, software, organization, and other
>
> information used in authorization decisions
>
> - Mechanisms for presenting tokens to resource servers and binding resour=
ce
>
> requests to tokens and associated cryptographic keys
>
> - Optimized inclusion of additional information (including identifiers an=
d
>
> identity assertions) through the delegation process
>
>
>
> Additionally, the group will provide mechanisms for management of the pro=
tocol
>
> lifecycle including:
>
>
>
> - Discovery of the authorization server
>
> - Revocation of active tokens
>
> - Mechanisms for the AS and RS to communicate the access granted by an ac=
cess
>
> token
>
>
>
> Although the artifacts for this work are not intended or expected to be
>
> backwards-compatible with OAuth 2.0 or OpenID Connect, the group will att=
empt
>
> to simplify migrating from OAuth 2.0 and OpenID Connect to the new protoc=
ol
>
> where possible.
>
>
>
> This group is not chartered to develop extensions to OAuth 2.0, and as su=
ch
>
> will focus on new technological solutions not necessarily compatible with
>
> OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be direct=
ed
>
> to the OAuth Working Group, including functionality back-ported from the
>
> protocol developed here to OAuth 2.0.
>
>
>
> The group is chartered to develop mechanisms for applying cryptographic
>
> methods, such as JOSE and COSE, to the delegation process. This group is =
not
>
> chartered to develop new cryptographic methods.
>
>
>
> The group is chartered to develop mechanisms for conveying identity
>
> information within the protocol including existing identifiers (such as e=
mail
>
> addresses, phone numbers, usernames, and subject identifiers) and asserti=
ons
>
> (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
>
> Credentials). The group is not chartered to develop new formats for
>
> identifiers or assertions, nor is the group chartered to develop schemas =
for
>
> user information, profiles, or other identity attributes, unless a viable
>
> existing format is not available.
>

--0000000000009efd8705a9dd05f0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Again to be blunt, my flow for consent doesn't match =
yours.

thx ..Tom (mobile)

On Tue, Jul 7, 2020, 10:04 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Justin,

    

     =20
      Denis,
      


      

      
A lot of what you=E2=80=99re describing below changes the
        very nature of the roles in the system. The component that
        manages the consent and issues tokens is, by definition, the AS.
      

    

    
The current charter states: "the artifacts for this work are no=
t
      intended or expected to be backwards-compatible with OAuth 2.0 or
      OpenID Connect".

      So we are not bound to OAuth 2.0 nor OpenID Connect. Hence, we do
      not need to stick with all their concepts.

    

    
I believe that the user's consent should be given after a
      dialogue with the RS which does not mean that the RS shall capture
      the user's consent 

      since it is the duty of the client. When a user selects one
      operation among a choice of operations proposed by the RS, the RS
      should inform 

      the client about which attributes it needs to present and from
      which ASs. It is only at this moment that the clients learns which
      ASs are

      adequate. Before this moment, the dialogue *cannot* be handled by
      an AS. Then after the duty of the client is to look for these
      attributes and 

      to get them from one or more ASs. ASs are all equal. There is no
      single AS with which the user shall be bound or have a particular
      relationship

    

    
Managing the authorization (and the user's consent) at the RS is
      simple: I have proposed a way to do it (and FIDO U2F is even
      included).

    
Managing the authorization at the AS would mandate a close
      synchronization between the RS and all the ASs with which it has a
      relationship.

      There would be the need to define a synch. protocol and it is much
      simpler to avoid to use such a protocol and thus not to define it.
      "Out-of-bands" means for such a synchronisation would not b=
e a
      better solution. But the major issue by managing the user's
      consent at the AS 

      is to allow the AS to act as Big Brother.

    
A copy and paste from a document published under the "Digital
      Europe for All" (DE4A) project :

    

      
The privacy principle requires that the private life, the home
        and the communications of each citizen 

        are respected and that no personal data are gathered without a
        legitimate reason and purpose.

        

        Data protection and privacy should (as far as possible) be achie=
ved
          by design, i.e. be embedded in the 

        technical solutions and services in a way that misuse or
        illegitimate access is made impossible or at 

        least very difficult through the technical approach itself, and
        without having to rely on organisational 

        measures or solely on legal measures to guarantee the
          compliance. 

        

        Main sources for this principle: CFREU, GDPR, eIDAS, eGov Action
        Plan, EIF, Tallinn Declaration, and 

        SDGR. 

      

    

    

      
The user shouldn=E2=80=99t ever have to interact directly
        with the RS, since the RS is, by definition, an API that is
        called by software, not an interactive component.=C2=A0

      


      

      
But it=E2=80=99s important to note that these are only
        :roles: to be played and not strictly speaking separate pieces
        of software, and that these roles can be combined and split in a
        variety of ways. For instance, in what you=E2=80=99re talking about
        below, instead of saying that it=E2=80=99s the RS that manages the
        consent, what if you saw it as the functionality of the AS
        that=E2=80=99s been split between two components: one privacy-prese=
rving
        element that issues tokens, and another that deals with
        interaction and consent. This is already a pattern that some in
        the WG have expressed interest in supporting with GNAP, and the
        core charter tenet of separating the interaction from the
        delegation channels is something that could help there.=C2=A0

      


      

      
Would it be possible to look at your use case in
        this different light? 

    

    
I could see the RS (i.e. not the AS) split into two components:
      an API and an MMI to manage the choices and the consent of the
      user. 

      This looks artificial but would it help ?

    
Denis

    

    

      
It=E2=80=99s always possible that we need to re-cast some of
        these roles, and that=E2=80=99s been done before: in OAuth 2 we def=
ined
        the AS and RS roles separately, even though they can always be
        deployed together anyway. So with that it=E2=80=99s possible that t=
here
        are other distinct pieces here that are working together that we
        need to tease out, but that=E2=80=99s something for the WG to figur=
e
        out. We can always decide to separate out the parts and allow
        them to be recombined in deployment, But I do not think it is
        helpful to redefine the existing roles, especially by moving key
        facets from one existing role to another.

      


      

      
=C2=A0=E2=80=94 Justin

      

        


          

            
On Jul 7, 2020, at 8:43 AM, Denis <denis.ietf@free.fr> wrote:

            

            

              
Hi Roman,

              

                

                  
Hi
                    Denis!

                  
=C2=A0

                  
Thanks
                    for the feedback and for repeating your review on
                    the revised text.=C2=A0 More inline =E2=80=A6=


                  
=C2=A0

                  

                    

                      

                        
From:=C2=A0iesg=
=C2=A0<iesg-b=
ounces@ietf.org>=C2=A0On Behalf Of=C2=A0Denis

                          Sent:=C2=A0Monday,
                          July 6, 2020 10:55 AM

                          To:=C2=A0iesg@ietf.org

                          Cc:=C2=A0txauth@ietf.org

                          Subject:=C2=A0Re:
                          [Txauth] WG Review: Grant Negotiation and
                          Authorization Protocol (gnap)

                      

                    

                    
=C2=A0

                    

                      
Since it is today the
                          last day to send back comments, you will find
                          hereafter my comments on the last charter
                          version-05.

                    

                  

                

              

              
BTW, I sent an email
                yesterday evening with the subject:=C2=A0Su=
pport
                  of FIDO=C2=A0and
                data minimization by RSs, where I indicated that the
                charter should=C2=A0

                mention FIDO U2F so that it should be possible to logon
                to a RS using either FIDO or by presenting one (or more)
                access tokens from one (or more) AS.

              
The original email is
                here :=C2=A0https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIP=
QczD7icwE/

              

                

                  

                    

                      

                    

                    

                      
charter-ietf-gnap-00-05

                      
This group is chartered to develop a fine-grained del=
egation protocol for authorization, API access, user identifiers, and ident=
ity assertions. =


                      
=C2=A0

                      
[Denis] Fine.

                      
=C2=A0

                      
The protocol will also allow the client to present un=
verified identifiers and verifiable assertions to the AS as part of its req=
uest. 

                      
=C2=A0

                      
[Denis] This sentence is too vague because=
 "as part of its request" is not explicit enough. If it means=C2=
=A0 "as part as an access token request" 
                      
this should be explicitly said. If, it is =
not the case, then it should be clearly explained. The AS should know as li=
ttle as possible (including nothing)

                      
about what the client is doing.

                      
=C2=A0

                      
[Roman] The =E2=80=9Crequest=E2=80=9D here is the =
=E2=80=9Caccess token request=E2=80=9D.=C2=A0 That can be made clearer.

                    

                  

                

              

              
This would be
                appreciated.

              

                

                  

                    

                      

                      
=C2=A0

                      
This protocol will allow an authorizing party to dele=
gate access to client software through an authorization server. <=
/u>

                      
=C2=A0

                      
[Denis] The word "privacy"=
; is still missing in the charter. "Delegating access to client softwa=
re through an authorization server" 

                      
is negating the fact that the user's p=
rivacy will ever be considered. IMHO, I believe that a RS may delegate some=
 operation to another RS, 

                      
but I don't believe that an AS should =
be concerned by any form of delegation, otherwise it would have the ability=
 to act as "Big Brother".

                      
OAuth has not been constructed taking into=
 consideration the user's privacy. The major difference with it should =
be that GNAP has been 

                      
constructed along "privacy by desi=
gn" principles.

                      
=C2=A0

                      
[Roman]=C2=A0 I don=E2=80=99t exactly follow how co=
nsiderations for privacy are being negated.=C2=A0 Above and beyond use-case=
 specific considerations that would be defined later,=20
RFC6973 is the IETF consensus design guidance that will guide the privacy t=
hreats and mitigations of the work.=C2=A0 What design guidance would you re=
commend that=20
the WG should consider that aren=E2=80=99t captured in RFC6973?

                    

                  

                

              

              
I believe my message is
                quite clear : If the AS is handling the delegation
                process, it will know what the client is doing or where
                it is going.=C2=A0

                On the contrary, if the RS is handling the delegation
                process, the AS will be unable to know what the client
                is doing. In addition, an AS-centric=C2=A0

                architecture would not be scalable and would need a lot
                of synchronizations between ASs and RSs. The user
                consent should be handled by the RS=C2=A0

                and not by the AS. When a RS is unable to provide the
                service, it is best placed to tell directly to the
                client what it could do next.=C2=A0

              

              
RFC 6973 is very good
                document. Section 7.1 states:=C2=A0

              

              
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 b.=C2=
=A0 Data.=C2=A0
                What information does the protocol expose about
                individuals, their devices, and/or their device usage
                (other than the identifiers discussed in (a))?=C2=A0<=
/span>

              

              
Data includes both the
                operation and the data associated with the operation. An
                AS should be kept ignorant of both the operation and the
                data associated with the operation.

              

                
c.=C2=A0 Observers.=C2=A0 (...) Are there ways for
                  protocol implementers to=C2=A0 choose to limit the
                  information shared with each entity?=C2=A0=C2=A0

                

              

              
If theses guidances
                were followed, the proposed architecture would not be
                AS-centric.

              

                

                  

                    

                      
=C2=A0

                      
It will expand upon the uses cases currently s=
upported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0)=
 to support authorizations 

                      
scoped as narrowly as a single transaction, provide a=
 clear framework for interaction among all parties involved in the protocol=
 flow, and remove 

                      
unnecessary dependence on a browser or user-agent for=
 coordinating interactions.

                      
=C2=A0

                      
[Denis] There is no need to refer to OAuth=
 2.0 and OpenID Connect. Some existing uses cases (i.e. "non-expand=
ed" use cases) should be supported 

                      
differently from OAuth 2.0 and OpenID Conn=
ect, in particular to support the user's privacy.

                      
=C2=A0

                      
[Roman] I=E2=80=99d want to hear others on this res=
coping.=C2=A0 Building upon the use cases of OAuth 2.0 and OpenID Connect h=
as been core, consensus-validated tenant for some time now.

                      
=C2=A0

                      
The delegation process will be acted upon by multiple=
 parties in the protocol, each performing a specific role. The protocol wil=
l decouple the channels used 

                      
by the protocol participants to communicate from the =
delegation channel, which happens directly between the client and the autho=
rization server (in contrast 

                      
with OAuth 2.0, which is initiated by the client redi=
recting the user=E2=80=99s browser). 

                      
=C2=A0

                      
[Denis] Here again, the delegation process=
, if any, should be handled by RSs and not by ASs. 
                      
The term "delegation channel" is=
 being used but it is left undefined. It is not understandable.

                      
=C2=A0

                      
[Roman] This sentence was just added into -05 addre=
ss Security AD feedback.=C2=A0 In this case, it was made to distinguish bet=
ween in-band signaling and the new purpose-to-be-built channel.
                    

                  

                

              

              
Since delegation should
                not be handled by the AS, a delegation channel should
                not exist.

              

                

                  

                    

                      

                      
=C2=A0

                      
The protocol will include a means of specifying how t=
he user can potentially be involved in an interactive fashion during the de=
legation process. 

                      
The client and Authorization Server (AS) will use the=
se interaction mechanisms to involve the user, as necessary, to make author=
ization decisions.

                      
=C2=A0

                      
[Denis] Here again, the de=
legation process, if any, should be handled by RSs and not by ASs. The AS s=
hould know as little as possible (including nothing)

                      
about what the client is doing.

                      
=C2=A0

                      
[Roman] Understood =E2=80=93 as I understand it, yo=
u have concern with the scope of the AS behavior.=C2=A0 I=E2=80=99d be inte=
resting in hearing additional support for this rescoping.=C2=A0 <=
/u>

                      
=C2=A0

                      
This decoupling avoids many of the security concerns =
and technical challenges of OAuth 2.0 and provides a non-invasive path for =
supporting future types 

                      
of clients and interaction channels.

                      
=C2=A0

                      
[Denis] This is not understandable to me. =
Is such a sentence really needed in a charter ?

                      
=C2=A0

                      
[Roman] Can someone on the TxAuth mailing list remi=
nd us on why this sentence is here?=C2=A0 With a fresh read, I also can=E2=
=80=99t remember why we need it.

                      
=C2=A0

                      
The group will define interoperability for this proto=
col between different parties, including

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
client a=
nd authorization server;

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
client a=
nd resource server; and

                      
=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 authorization server and resource server.

                      
=C2=A0

                      
[Denis] In order to support the user's=
 privacy, there should be no interaction at all between an authorization se=
rver and a resource server 

                      
at the time of a client request<=
/i>.=
<=
u>

                      
=C2=A0

                      
The group will seek to minimize assumptions about the=
 form of client applications, allowing for:

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Fine-gr=
ained specification of access

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Approva=
l of AS attestation to identifiers and other identity claims<=
u>

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Approva=
l of access to multiple resources and APIs in a single interaction

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Multipl=
e access tokens in a single request and response

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 AS-dire=
cted dispatch of access tokens to the appropriate RS
                      
[Denis] As-directed dispatch does not allo=
w to support the user's privacy. However, RS-directed dispatch allows t=
o support the user's privacy.

                      
It should be explicitly mentioned.<=
u>

                      
[Roman] As above (per the AS vs. RS behavior)

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Separat=
ion between the party authorizing access and the party operating the client=
 requesting access 

                      
=C2=A0

                      
[Denis] It is questionable whether=
 such a separation would be really beneficial. In doubt, this item should b=
e removed.

                      
[Roman] Could you say more on why this flexibility =
wouldn=E2=80=99t be worth it?=C2=A0 

                    

                  

                

              

              
Except for added
                complexity, there is no need to have separate channels.
                It is simpler to send the access token in addition to
                the data=C2=A0

                and, for additional security, to sign the data using a
                private key corresponding to a public key present in the
                access token.

              

                

                  

                    

                      

                      
The group will define extension points for thi=
s protocol to allow for flexibility in areas including:

                      
=C2=A0

                      
Cryptographic agility for keys, message signat=
ures, and proof of possession

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 User in=
teraction mechanisms including web and non-web methods=


                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Mechani=
sms for conveying user, software, organization, and other information used =
in authorization decisions 

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Mechani=
sms for presenting tokens to resource servers and binding resource requests=
 to tokens and associated cryptographic keys 

                      
Optimized inclusion of additional information (includ=
ing identifiers and identity assertions) through the delegation process =


                      
=C2=A0

                      
Additionally, the group will provide mechanisms for m=
anagement of the protocol lifecycle including:

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Discove=
ry of the authorization server

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Revocat=
ion of active tokens

                      
Data model for granted access and mechanisms for the =
AS and RS to communicate the granted access model
                      
=C2=A0

                      
[Denis] While it is the duty for the RS to=
 communicate the granted access model to the client at the appropriate i=
nstant of time, 

                      
the AS should be kept fully ignorant of it=
.=


                      
=C2=A0

                      
Although the artifacts for this work are not intended=
 or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, <=
u>

                      
the group will attempt to simplify migrating from OAu=
th 2.0 and OpenID Connect to the new protocol where possible.=


                      
=C2=A0

                      
This group is not chartered to develop extensions to =
OAuth 2.0, and as such will focus on new technological solutions not necess=
arily 

                      
compatible with OAuth 2.0. Functionality that builds =
directly on OAuth 2.0 will be directed to the OAuth Working Group, includin=
g 

                      
functionality back-ported from the protocol developed=
 here to OAuth 2.0.

                      
=C2=A0

                      
The group is chartered to develop mechanisms for appl=
ying cryptographic methods, such as JOSE and COSE, to the delegation proces=
s. 

                      
This group is not chartered to develop new cryptograp=
hic methods.

                      
=C2=A0

                      
The group is chartered to develop mechanisms for conv=
eying identity information within the protocol including existing identifie=
rs 

                      
(such as email addresses, phone numbers, usernames, a=
nd subject identifiers) and assertions (such as OpenID Connect ID Tokens, <=
u>

                      
SAML Assertions, and Verifiable Credentials). The gro=
up is not chartered to develop new formats for identifiers or assertions, n=
or is the group 

                      
chartered to develop schemas for user information, pr=
ofiles, or other identity attributes, unless a viable existing format is no=
t available.

                      
=C2=A0

                      
The initial work will focus on using HTTPS for commun=
ication between the client and the authorization server, taking advantage <=
u>

                      
of optimization features of HTTP/2 and HTTP/3 where p=
ossible, and will strive to enable simple mapping to other protocols such a=
s COAP 

                      
when doing so does not conflict with the primary focu=
s.

                      
=C2=A0

                      
Milestones to include:

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Core de=
legation protocol

                      
[Denis] Before defining a "Core deleg=
ation protocol", a simple client server-protocol involving the present=
ation of several access tokens to one RS should be defined. <=
/span>

                      
Privacy principles should be applied when =
defining the protocol. Then after, a delegation mechanism allowing one RS t=
o forward an operation to another RS should be defined.

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Key pre=
sentation mechanism bindings to the core protocol including TLS, detached H=
TTP signature, and embedded HTTP signatures 

                      
[Denis] Bindings to TLS are now deprecated=
, why should they be maintained ? 

                      
Signatures may be needed but they do not n=
ecessarily need to be "detached HTTP signature, and embedded HTTP sign=
atures". 

                      
This item should be either removed or rewo=
rded.=


                      
[Roman] Noted.=C2=A0 I=E2=80=99d want to hear other=
s on this rescoping.

                    

                  

                

              

              
As explained above, it
                is possible to sign the data using a private key
                corresponding to a public key present in the access
                token.

              

                

                  

                    

                      

                      
=C2=A0

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Conveya=
nce mechanisms for identifiers and assertions 

                      
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 Guideli=
nes for use of protocol extension points (if needed) <=
/pre>
                      
=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0 Guidelines on
                          migration paths, implementation, and
                          operations

                      
[Denis] The
                          above three lines are rather mysterious.

                      
[Roman] The guidelines on
                        migration paths came from the initial IESG
                        review in order to have a named activity to
                        action the design goal of =E2=80=9C=E2=80=A6 the gr=
oup will
                        attempt to simplify migrating from OAuth 2.0 and
                        OpenID Connect to the new protocol where
                        possible=E2=80=9D a bit earlier in the text.=


                      
Where possible, the
                          group will seek to make use of tools to guide
                          and inform the standardization process
                          including formal analysis,=C2=A0

                          architecture documents, and use case
                          documents. These artifacts will not be
                          considered as working group milestones or
                          deliverables.

                      
The working group will
                          cooperate and coordinate with other IETF WGs
                          such as OAUTH, and work with external
                          organizations,=C2=A0

                          such as the OpenID Foundation, as appropriate.

                      
[Denis] The
                          charter should be shorter.

                      
=C2=A0

                      
[Roman] Definitely.=C2=A0 Nevertheless, we
                        have the current text through rough consensus
                        process achieved from two BoFs and multiple
                        mailing list consensus calls.

                    

                  

                

              

              
In a previous post, I
                proposed a much shorter text.

              
Denis

              

              

                

                  

                    

                      

                      
=C2=A0

                      
Regards,

                      
Roman=C2=A0
                    

                    

                      
=C2=A0

                    

                    

                      
/Denis

                    

                    

                      
=C2=A0

                    

                    

                      
A new IETF WG has been proposed in the=
 Security Area. The IESG has not made

                      
any determination yet. The following d=
raft charter was submitted, and is

                      
provided for informational purposes on=
ly. Please send your comments to the

                      
IESG mailing list (iesg@ietf.org) by 2020-07-06.=


                      
=C2=A0

                      
Grant Negotiation and Authorization Pr=
otocol (gnap)

                      
--------------------------------------=
---------------------------------

                      
Current status: Proposed WG<=
/u>

                      
=C2=A0

                      
Chairs:

                      
=C2=A0 Yaron Sheffer <yaronf.ietf@gmail.com>=


                      
=C2=A0 Leif Johansson <leifj@sunet.se>
                      
=C2=A0

                      
Assigned Area Director:<=
/pre>
                      
=C2=A0 Roman Danyliw <rdd@cert.org>

                      
=C2=A0

                      
Security Area Directors:=


                      
=C2=A0 Benjamin Kaduk <kaduk@mit.edu>

                      
=C2=A0 Roman Danyliw <rdd@cert.org>

                      
=C2=A0

                      
Mailing list:

                      
=C2=A0 Address: txauth@ietf.org

                      
=C2=A0 To subscribe: =E2=80=8Bhttps://www.ietf.org/mai=
lman/listinfo/txauth

                      
=C2=A0 Archive: https://mailarchive.ietf.=
org/arch/browse/txauth/

                      
=C2=A0

                      
Group page: https://datatracker.ietf.org/group/gn=
ap/

                      
=C2=A0

                      
Charter: https://datatracker.ietf.org/=
doc/charter-ietf-gnap/

                      
=C2=A0

                      
This group is chartered to develop a f=
ine-grained delegation protocol for

                      
authorization and API access, as well =
as requesting and providing user

                      
identifiers and claims. This protocol =
will allow an authorizing party to

                      
delegate access to client software thr=
ough an authorization server. It will

                      
expand upon the uses cases currently s=
upported by OAuth 2.0 and OpenID Connect

                      
(itself an extension of OAuth 2.0) to =
support authorizations scoped as

                      
narrowly as a single transaction, prov=
ide a clear framework for interaction

                      
among all parties involved in the prot=
ocol flow, and remove unnecessary

                      
dependence on a browser or user-agent =
for coordinating interactions.

                      
=C2=A0

                      
The delegation process will be acted u=
pon by multiple parties in the protocol,

                      
each performing a specific role. The p=
rotocol will decouple the interaction

                      
channels, such as the end user=E2=80=
=99s browser, from the delegation channel, which

                      
happens directly between the client an=
d the authorization server (in contrast

                      
with OAuth 2.0, which is initiated by =
the client redirecting the user=E2=80=99s

                      
browser). The protocol will include a =
means of specifying how the user can

                      
potentially be involved in an interact=
ive fashion during the delegation

                      
process. The client and Authorization =
Server (AS) will use these interaction

                      
mechanisms to involve the user, as nec=
essary, to make authorization decisions.

                      
This decoupling avoids many of the sec=
urity concerns and technical challenges

                      
of OAuth 2.0 and provides a non-invasi=
ve path for supporting future types of

                      
clients and interaction channels.

                      
=C2=A0

                      
The group will define interoperability=
 for this protocol between different

                      
parties, including

                      
 - client and authorization server;=


                      
 - client and resource server; and<=
/u>

                      
 - authorization server and resource s=
erver.

                      
=C2=A0

                      
The group will seek to minimize assump=
tions about the form of client

                      
applications, allowing for:<=
/u>

                      
- Fine-grained specification of access=


                      
- Approval of AS attestation to identi=
fiers and other identity claims

                      
- Approval of access to multiple resou=
rces and APIs in a single interaction

                      
- Support for multiple access tokens i=
n a single request and response

                      
- Support for directed, audience-restr=
icted access tokens

                      
- Separation between the party authori=
zing access and the party operating the

                      
client requesting access=


                      
=C2=A0

                      
The group will define extension points=
 for this protocol to allow for

                      
flexibility in areas including:=


                      
=C2=A0

                      
- Cryptographic agility for keys, mess=
age signatures, and proof of possession

                      
- User interaction mechanisms includin=
g web and non-web methods

                      
- Mechanisms for conveying user, softw=
are, organization, and other

                      
information used in authorization deci=
sions

                      
- Mechanisms for presenting tokens to =
resource servers and binding resource

                      
requests to tokens and associated cryp=
tographic keys

                      
- Optimized inclusion of additional in=
formation (including identifiers and

                      
identity assertions) through the deleg=
ation process

                      
=C2=A0

                      
Additionally, the group will provide m=
echanisms for management of the protocol

                      
lifecycle including:
                      
=C2=A0

                      
- Discovery of the authorization serve=
r

                      
- Revocation of active tokens

                      
- Mechanisms for the AS and RS to comm=
unicate the access granted by an access

                      
token

                      
=C2=A0

                      
Although the artifacts for this work a=
re not intended or expected to be

                      
backwards-compatible with OAuth 2.0 or=
 OpenID Connect, the group will attempt

                      
to simplify migrating from OAuth 2.0 a=
nd OpenID Connect to the new protocol

                      
where possible.

                      
=C2=A0

                      
This group is not chartered to develop=
 extensions to OAuth 2.0, and as such

                      
will focus on new technological soluti=
ons not necessarily compatible with

                      
OAuth 2.0. Functionality that builds d=
irectly on OAuth 2.0 will be directed

                      
to the OAuth Working Group, including =
functionality back-ported from the

                      
protocol developed here to OAuth 2.0.<=
u>

                      
=C2=A0

                      
The group is chartered to develop mech=
anisms for applying cryptographic

                      
methods, such as JOSE and COSE, to the=
 delegation process. This group is not

                      
chartered to develop new cryptographic=
 methods.

                      
=C2=A0

                      
The group is chartered to develop mech=
anisms for conveying identity

                      
information within the protocol includ=
ing existing identifiers (such as email

                      
addresses, phone numbers, usernames, a=
nd subject identifiers) and assertions

                      
(such as OpenID Connect ID Tokens, SAM=
L Assertions, and Verifiable

                      
Credentials). The group is not charter=
ed to develop new formats for

                      
identifiers or assertions, nor is the =
group chartered to develop schemas for

                      
user information, profiles, or other i=
dentity attributes, unless a viable

                      
existing format is not available.<o=
:p cl
<=
/div>


--0000000000009efd8705a9dd05f0--


From nobody Tue Jul  7 11:06: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 E23E93A07F8; Tue,  7 Jul 2020 11:06:02 -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_FILL_THIS_FORM_SHORT=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 XPwIZJpIeiIk; Tue,  7 Jul 2020 11:05:57 -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 368BA3A00D6; Tue,  7 Jul 2020 11:05:55 -0700 (PDT)
Received: from [192.168.1.7] (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 067I5ld6026365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Jul 2020 14:05:48 -0400
From: Justin Richer 
Message-Id: <666733F9-3965-4858-B152-F79F34225894@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3FC5F57D-A201-4664-B30A-C80CF96166E4"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 7 Jul 2020 14:05:47 -0400
In-Reply-To: 
Cc: Denis , "rdd@cert.org" , "iesg@ietf.org" , "txauth@ietf.org" 
To: Tom Jones 
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <7563640e-f515-3e73-a4eb-3902ec7af50e@free.fr> <3424311c60f541b197cfda6e9f3b494e@cert.org> <36de4e6a-41fe-81b1-6c92-69fe5b63ad6f@free.fr>   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
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, 07 Jul 2020 18:06:03 -0000

--Apple-Mail=_3FC5F57D-A201-4664-B30A-C80CF96166E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Jul 7, 2020, at 1:06 PM, Tom Jones  =
wrote:
>=20
> Again to be blunt, my flow for consent doesn't match yours.
>=20

Thanks, Tom =E2=80=94 we are aware that there are pulls from different =
directions here, and that=E2=80=99s why I think it=E2=80=99s important =
for the group to try and look at them the same way. Declarations that =
there is one and only one use case aren=E2=80=99t helpful. I=E2=80=99ve =
said before, and I=E2=80=99ll say again, that I think that we can have =
both trust models inside GNAP.

> thx ..Tom (mobile)
>=20
> On Tue, Jul 7, 2020, 10:04 AM Denis > wrote:
> Justin,
>> Denis,
>>=20
>> A lot of what you=E2=80=99re describing below changes the very nature =
of the roles in the system. The component that manages the consent and =
issues tokens is, by definition, the AS.
> The current charter states: "the artifacts for this work are not =
intended or expected to be backwards-compatible with OAuth 2.0 or OpenID =
Connect".
> So we are not bound to OAuth 2.0 nor OpenID Connect. Hence, we do not =
need to stick with all their concepts.
>=20
No, but what you call things does matter. Reassigning a piece of =
functionality from one component to another without changing the name is =
problematic, as it causes a lot of confusion. We can=E2=80=99t change =
the model that OAuth 2 gave us, we live in a world where it already =
exists. It=E2=80=99s not helpful to try to force a new definition on =
something. But we can transcend that model with GNAP, and sometimes that =
means questioning the atomicity of our components and their roles.=20

> I believe that the user's consent should be given after a dialogue =
with the RS which does not mean that the RS shall capture the user's =
consent=20
> since it is the duty of the client. When a user selects one operation =
among a choice of operations proposed by the RS, the RS should inform=20
> the client about which attributes it needs to present and from which =
ASs. It is only at this moment that the clients learns which ASs are
> adequate. Before this moment, the dialogue *cannot* be handled by an =
AS. Then after the duty of the client is to look for these attributes =
and=20
> to get them from one or more ASs. ASs are all equal. There is no =
single AS with which the user shall be bound or have a particular =
relationship
>=20
> Managing the authorization (and the user's consent) at the RS is =
simple: I have proposed a way to do it (and FIDO U2F is even included).
>=20
>=20
> Managing the authorization at the AS would mandate a close =
synchronization between the RS and all the ASs with which it has a =
relationship.
> There would be the need to define a synch. protocol and it is much =
simpler to avoid to use such a protocol and thus not to define it.
> "Out-of-bands" means for such a synchronisation would not be a better =
solution. But the major issue by managing the user's consent at the AS=20=

> is to allow the AS to act as Big Brother.
>=20
Again, you seem to assume that the AS cannot be something that is in the =
control of the RS, the client, or the user. That=E2=80=99s not true. =
It=E2=80=99s a functional role in the system, not a deployment =
requirement.

> A copy and paste from a document published under the "Digital Europe =
for All" (DE4A) project :
>=20
> The privacy principle requires that the private life, the home and the =
communications of each citizen=20
> are respected and that no personal data are gathered without a =
legitimate reason and purpose.
>=20
> Data protection and privacy should (as far as possible) be achieved by =
design, i.e. be embedded in the=20
> technical solutions and services in a way that misuse or illegitimate =
access is made impossible or at=20
> least very difficult through the technical approach itself, and =
without having to rely on organisational=20
> measures or solely on legal measures to guarantee the compliance.=20
>=20
> Main sources for this principle: CFREU, GDPR, eIDAS, eGov Action Plan, =
EIF, Tallinn Declaration, and=20
> SDGR.=20
>=20
>> The user shouldn=E2=80=99t ever have to interact directly with the =
RS, since the RS is, by definition, an API that is called by software, =
not an interactive component.=20
>>=20
>> But it=E2=80=99s important to note that these are only :roles: to be =
played and not strictly speaking separate pieces of software, and that =
these roles can be combined and split in a variety of ways. For =
instance, in what you=E2=80=99re talking about below, instead of saying =
that it=E2=80=99s the RS that manages the consent, what if you saw it as =
the functionality of the AS that=E2=80=99s been split between two =
components: one privacy-preserving element that issues tokens, and =
another that deals with interaction and consent. This is already a =
pattern that some in the WG have expressed interest in supporting with =
GNAP, and the core charter tenet of separating the interaction from the =
delegation channels is something that could help there.=20
>>=20
>> Would it be possible to look at your use case in this different =
light?
> I could see the RS (i.e. not the AS) split into two components: an API =
and an MMI to manage the choices and the consent of the user.=20
> This looks artificial but would it help ?
>=20
>=20

I believe so, because then the =E2=80=9CMMI=E2=80=9D is defined as a =
separate functional component. Don=E2=80=99t be surprised when people =
classify it as =E2=80=9Cpart of the AS=E2=80=9D, since that=E2=80=99s =
where that functionality was previously hosted. It=E2=80=99s like the =
early days of OAuth 2 where people talked about both the =E2=80=9CAS=E2=80=
=9D and =E2=80=9CRS=E2=80=9D as the =E2=80=9Cserver=E2=80=9D, since that =
was the component that both pieces fulfilled. And indeed, there are a =
lot of OAuth 2 deployments that combine these two today. There are also =
other arrangements like the ones you=E2=80=99ve been talking about where =
the trust is distributed differently.=20

 =E2=80=94 Justin

> Denis
>=20
>> It=E2=80=99s always possible that we need to re-cast some of these =
roles, and that=E2=80=99s been done before: in OAuth 2 we defined the AS =
and RS roles separately, even though they can always be deployed =
together anyway. So with that it=E2=80=99s possible that there are other =
distinct pieces here that are working together that we need to tease =
out, but that=E2=80=99s something for the WG to figure out. We can =
always decide to separate out the parts and allow them to be recombined =
in deployment, But I do not think it is helpful to redefine the existing =
roles, especially by moving key facets from one existing role to =
another.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 7, 2020, at 8:43 AM, Denis > wrote:
>>>=20
>>> Hi Roman,
>>>> Hi Denis!
>>>> =20
>>>> Thanks for the feedback and for repeating your review on the =
revised text.  More inline =E2=80=A6
>>>> =20
>>>> From: iesg   =
On Behalf Of Denis
>>>> Sent: Monday, July 6, 2020 10:55 AM
>>>> To: iesg@ietf.org 
>>>> Cc: txauth@ietf.org 
>>>> Subject: Re: [Txauth] WG Review: Grant Negotiation and =
Authorization Protocol (gnap)
>>>> =20
>>>> Since it is today the last day to send back comments, you will find =
hereafter my comments on the last charter version-05.
>>> BTW, I sent an email yesterday evening with the subject: Support of =
FIDO and data minimization by RSs, where I indicated that the charter =
should=20
>>> mention FIDO U2F so that it should be possible to logon to a RS =
using either FIDO or by presenting one (or more) access tokens from one =
(or more) AS.
>>>=20
>>> The original email is here : =
https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/ =
charter-ietf-gnap-00-05
>>>>=20
>>>> This group is chartered to develop a fine-grained delegation =
protocol for authorization, API access, user identifiers, and identity =
assertions.=20
>>>> =20
>>>> [Denis] Fine.
>>>> =20
>>>> The protocol will also allow the client to present unverified =
identifiers and verifiable assertions to the AS as part of its request.=20=

>>>> =20
>>>> [Denis] This sentence is too vague because "as part of its request" =
is not explicit enough. If it means  "as part as an access token =
request"=20
>>>> this should be explicitly said. If, it is not the case, then it =
should be clearly explained. The AS should know as little as possible =
(including nothing)
>>>> about what the client is doing.
>>>> =20
>>>> [Roman] The =E2=80=9Crequest=E2=80=9D here is the =E2=80=9Caccess =
token request=E2=80=9D.  That can be made clearer.
>>> This would be appreciated.
>>>=20
>>>> =20
>>>> This protocol will allow an authorizing party to delegate access to =
client software through an authorization server.=20
>>>> =20
>>>> [Denis] The word "privacy" is still missing in the charter. =
"Delegating access to client software through an authorization server"=20=

>>>> is negating the fact that the user's privacy will ever be =
considered. IMHO, I believe that a RS may delegate some operation to =
another RS,=20
>>>> but I don't believe that an AS should be concerned by any form of =
delegation, otherwise it would have the ability to act as "Big Brother".
>>>> OAuth has not been constructed taking into consideration the user's =
privacy. The major difference with it should be that GNAP has been=20
>>>> constructed along "privacy by design" principles.
>>>> =20
>>>> [Roman]  I don=E2=80=99t exactly follow how considerations for =
privacy are being negated.  Above and beyond use-case specific =
considerations that would be defined later,=20
>>>> RFC6973 is the IETF consensus design guidance that will guide the =
privacy threats and mitigations of the work.  What design guidance would =
you recommend that=20
>>>> the WG should consider that aren=E2=80=99t captured in RFC6973?
>>> I believe my message is quite clear : If the AS is handling the =
delegation process, it will know what the client is doing or where it is =
going.=20
>>> On the contrary, if the RS is handling the delegation process, the =
AS will be unable to know what the client is doing. In addition, an =
AS-centric=20
>>> architecture would not be scalable and would need a lot of =
synchronizations between ASs and RSs. The user consent should be handled =
by the RS=20
>>> and not by the AS. When a RS is unable to provide the service, it is =
best placed to tell directly to the client what it could do next.=20
>>>=20
>>> RFC 6973 is very good document. Section 7.1 states:=20
>>>=20
>>>           b.  Data.  What information does the protocol expose about =
individuals, their devices, and/or their device usage (other than the =
identifiers discussed in (a))?=20
>>>=20
>>> Data includes both the operation and the data associated with the =
operation. An AS should be kept ignorant of both the operation and the =
data associated with the operation.
>>>=20
>>> c.  Observers.  (...) Are there ways for protocol implementers to  =
choose to limit the information shared with each entity? =20
>>>=20
>>> If theses guidances were followed, the proposed architecture would =
not be AS-centric.
>>>=20
>>>> =20
>>>> It will expand upon the uses cases currently supported by OAuth 2.0 =
and OpenID Connect (itself an extension of OAuth 2.0) to support =
authorizations=20
>>>> scoped as narrowly as a single transaction, provide a clear =
framework for interaction among all parties involved in the protocol =
flow, and remove=20
>>>> unnecessary dependence on a browser or user-agent for coordinating =
interactions.
>>>> =20
>>>> [Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. =
Some existing uses cases (i.e. "non-expanded" use cases) should be =
supported=20
>>>> differently from OAuth 2.0 and OpenID Connect, in particular to =
support the user's privacy.
>>>> =20
>>>> [Roman] I=E2=80=99d want to hear others on this rescoping.  =
Building upon the use cases of OAuth 2.0 and OpenID Connect has been =
core, consensus-validated tenant for some time now.
>>>> =20
>>>> The delegation process will be acted upon by multiple parties in =
the protocol, each performing a specific role. The protocol will =
decouple the channels used=20
>>>> by the protocol participants to communicate from the delegation =
channel, which happens directly between the client and the authorization =
server (in contrast=20
>>>> with OAuth 2.0, which is initiated by the client redirecting the =
user=E2=80=99s browser).=20
>>>> =20
>>>> [Denis] Here again, the delegation process, if any, should be =
handled by RSs and not by ASs.=20
>>>> The term "delegation channel" is being used but it is left =
undefined. It is not understandable.
>>>> =20
>>>> [Roman] This sentence was just added into -05 address Security AD =
feedback.  In this case, it was made to distinguish between in-band =
signaling and the new purpose-to-be-built channel.
>>> Since delegation should not be handled by the AS, a delegation =
channel should not exist.
>>>=20
>>>> =20
>>>> The protocol will include a means of specifying how the user can =
potentially be involved in an interactive fashion during the delegation =
process.=20
>>>> The client and Authorization Server (AS) will use these interaction =
mechanisms to involve the user, as necessary, to make authorization =
decisions.
>>>> =20
>>>> [Denis] Here again, the delegation process, if any, should be =
handled by RSs and not by ASs. The AS should know as little as possible =
(including nothing)
>>>> about what the client is doing.
>>>> =20
>>>> [Roman] Understood =E2=80=93 as I understand it, you have concern =
with the scope of the AS behavior.  I=E2=80=99d be interesting in =
hearing additional support for this rescoping. =20
>>>> =20
>>>> This decoupling avoids many of the security concerns and technical =
challenges of OAuth 2.0 and provides a non-invasive path for supporting =
future types=20
>>>> of clients and interaction channels.
>>>> =20
>>>> [Denis] This is not understandable to me. Is such a sentence really =
needed in a charter ?
>>>> =20
>>>> [Roman] Can someone on the TxAuth mailing list remind us on why =
this sentence is here?  With a fresh read, I also can=E2=80=99t remember =
why we need it.
>>>> =20
>>>> The group will define interoperability for this protocol between =
different parties, including
>>>> -          client and authorization server;
>>>> -          client and resource server; and
>>>>      -      authorization server and resource server.
>>>> =20
>>>> [Denis] In order to support the user's privacy, there should be no =
interaction at all between an authorization server and a resource server=20=

>>>> at the time of a client request.
>>>> =20
>>>> The group will seek to minimize assumptions about the form of =
client applications, allowing for:
>>>> -          Fine-grained specification of access
>>>> -          Approval of AS attestation to identifiers and other =
identity claims
>>>> -          Approval of access to multiple resources and APIs in a =
single interaction
>>>> -          Multiple access tokens in a single request and response
>>>> -          AS-directed dispatch of access tokens to the appropriate =
RS
>>>> [Denis] As-directed dispatch does not allow to support the user's =
privacy. However, RS-directed dispatch allows to support the user's =
privacy.
>>>> It should be explicitly mentioned.
>>>> [Roman] As above (per the AS vs. RS behavior)
>>>> -          Separation between the party authorizing access and the =
party operating the client requesting access=20
>>>> =20
>>>> [Denis] It is questionable whether such a separation would be =
really beneficial. In doubt, this item should be removed.
>>>> [Roman] Could you say more on why this flexibility wouldn=E2=80=99t =
be worth it? =20
>>> Except for added complexity, there is no need to have separate =
channels. It is simpler to send the access token in addition to the data=20=

>>> and, for additional security, to sign the data using a private key =
corresponding to a public key present in the access token.
>>>=20
>>>> The group will define extension points for this protocol to allow =
for flexibility in areas including:
>>>> =20
>>>> Cryptographic agility for keys, message signatures, and proof of =
possession
>>>> -          User interaction mechanisms including web and non-web =
methods
>>>> -          Mechanisms for conveying user, software, organization, =
and other information used in authorization decisions=20
>>>> -          Mechanisms for presenting tokens to resource servers and =
binding resource requests to tokens and associated cryptographic keys=20
>>>> Optimized inclusion of additional information (including =
identifiers and identity assertions) through the delegation process=20
>>>> =20
>>>> Additionally, the group will provide mechanisms for management of =
the protocol lifecycle including:
>>>> -          Discovery of the authorization server
>>>> -          Revocation of active tokens
>>>> Data model for granted access and mechanisms for the AS and RS to =
communicate the granted access model
>>>> =20
>>>> [Denis] While it is the duty for the RS to communicate the granted =
access model to the client at the appropriate instant of time,=20
>>>> the AS should be kept fully ignorant of it.
>>>> =20
>>>> Although the artifacts for this work are not intended or expected =
to be backwards-compatible with OAuth 2.0 or OpenID Connect,=20
>>>> the group will attempt to simplify migrating from OAuth 2.0 and =
OpenID Connect to the new protocol where possible.
>>>> =20
>>>> This group is not chartered to develop extensions to OAuth 2.0, and =
as such will focus on new technological solutions not necessarily=20
>>>> compatible with OAuth 2.0. Functionality that builds directly on =
OAuth 2.0 will be directed to the OAuth Working Group, including=20
>>>> functionality back-ported from the protocol developed here to OAuth =
2.0.
>>>> =20
>>>> The group is chartered to develop mechanisms for applying =
cryptographic methods, such as JOSE and COSE, to the delegation process.=20=

>>>> This group is not chartered to develop new cryptographic methods.
>>>> =20
>>>> The group is chartered to develop mechanisms for conveying identity =
information within the protocol including existing identifiers=20
>>>> (such as email addresses, phone numbers, usernames, and subject =
identifiers) and assertions (such as OpenID Connect ID Tokens,=20
>>>> SAML Assertions, and Verifiable Credentials). The group is not =
chartered to develop new formats for identifiers or assertions, nor is =
the group=20
>>>> chartered to develop schemas for user information, profiles, or =
other identity attributes, unless a viable existing format is not =
available.
>>>> =20
>>>> The initial work will focus on using HTTPS for communication =
between the client and the authorization server, taking advantage=20
>>>> of optimization features of HTTP/2 and HTTP/3 where possible, and =
will strive to enable simple mapping to other protocols such as COAP=20
>>>> when doing so does not conflict with the primary focus.
>>>> =20
>>>> Milestones to include:
>>>> -          Core delegation protocol
>>>> [Denis] Before defining a "Core delegation protocol", a simple =
client server-protocol involving the presentation of several access =
tokens to one RS should be defined.=20
>>>> Privacy principles should be applied when defining the protocol. =
Then after, a delegation mechanism allowing one RS to forward an =
operation to another RS should be defined.
>>>> -          Key presentation mechanism bindings to the core protocol =
including TLS, detached HTTP signature, and embedded HTTP signatures=20
>>>> [Denis] Bindings to TLS are now deprecated, why should they be =
maintained ?=20
>>>> Signatures may be needed but they do not necessarily need to be =
"detached HTTP signature, and embedded HTTP signatures".=20
>>>> This item should be either removed or reworded.
>>>> [Roman] Noted.  I=E2=80=99d want to hear others on this rescoping.
>>> As explained above, it is possible to sign the data using a private =
key corresponding to a public key present in the access token.
>>>=20
>>>> =20
>>>> -          Conveyance mechanisms for identifiers and assertions=20
>>>> -          Guidelines for use of protocol extension points (if =
needed)=20
>>>>      -    Guidelines on migration paths, implementation, and =
operations
>>>> [Denis] The above three lines are rather mysterious.
>>>> [Roman] The guidelines on migration paths came from the initial =
IESG review in order to have a named activity to action the design goal =
of =E2=80=9C=E2=80=A6 the group will attempt to simplify migrating from =
OAuth 2.0 and OpenID Connect to the new protocol where possible=E2=80=9D =
a bit earlier in the text.
>>>> Where possible, the group will seek to make use of tools to guide =
and inform the standardization process including formal analysis,=20
>>>> architecture documents, and use case documents. These artifacts =
will not be considered as working group milestones or deliverables.
>>>> The working group will cooperate and coordinate with other IETF WGs =
such as OAUTH, and work with external organizations,=20
>>>> such as the OpenID Foundation, as appropriate.
>>>> [Denis] The charter should be shorter.
>>>> =20
>>>> [Roman] Definitely.  Nevertheless, we have the current text through =
rough consensus process achieved from two BoFs and multiple mailing list =
consensus calls.
>>> In a previous post, I proposed a much shorter text.
>>>=20
>>> Denis
>>>=20
>>>> =20
>>>> Regards,
>>>> Roman=20
>>>> =20
>>>> /Denis
>>>> =20
>>>> A new IETF WG has been proposed in the Security Area. The IESG has =
not made
>>>> any determination yet. The following draft charter was submitted, =
and is
>>>> provided for informational purposes only. Please send your comments =
to the
>>>> IESG mailing list (iesg@ietf.org ) by =
2020-07-06.
>>>> =20
>>>> Grant Negotiation and Authorization Protocol (gnap)
>>>> =
-----------------------------------------------------------------------
>>>> Current status: Proposed WG
>>>> =20
>>>> Chairs:
>>>>   Yaron Sheffer  =

>>>>   Leif Johansson  
>>>> =20
>>>> Assigned Area Director:
>>>>   Roman Danyliw  
>>>> =20
>>>> Security Area Directors:
>>>>   Benjamin Kaduk  
>>>>   Roman Danyliw  
>>>> =20
>>>> Mailing list:
>>>>   Address: txauth@ietf.org 
>>>>   To subscribe: =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/txauth=
 
>>>>   Archive: https://mailarchive.ietf.org/arch/browse/txauth/ =

>>>> =20
>>>> Group page: https://datatracker.ietf.org/group/gnap/ =

>>>> =20
>>>> Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/ =

>>>> =20
>>>> This group is chartered to develop a fine-grained delegation =
protocol for
>>>> authorization and API access, as well as requesting and providing =
user
>>>> identifiers and claims. This protocol will allow an authorizing =
party to
>>>> delegate access to client software through an authorization server. =
It will
>>>> expand upon the uses cases currently supported by OAuth 2.0 and =
OpenID Connect
>>>> (itself an extension of OAuth 2.0) to support authorizations scoped =
as
>>>> narrowly as a single transaction, provide a clear framework for =
interaction
>>>> among all parties involved in the protocol flow, and remove =
unnecessary
>>>> dependence on a browser or user-agent for coordinating =
interactions.
>>>> =20
>>>> The delegation process will be acted upon by multiple parties in =
the protocol,
>>>> each performing a specific role. The protocol will decouple the =
interaction
>>>> channels, such as the end user=E2=80=99s browser, from the =
delegation channel, which
>>>> happens directly between the client and the authorization server =
(in contrast
>>>> with OAuth 2.0, which is initiated by the client redirecting the =
user=E2=80=99s
>>>> browser). The protocol will include a means of specifying how the =
user can
>>>> potentially be involved in an interactive fashion during the =
delegation
>>>> process. The client and Authorization Server (AS) will use these =
interaction
>>>> mechanisms to involve the user, as necessary, to make authorization =
decisions.
>>>> This decoupling avoids many of the security concerns and technical =
challenges
>>>> of OAuth 2.0 and provides a non-invasive path for supporting future =
types of
>>>> clients and interaction channels.
>>>> =20
>>>> The group will define interoperability for this protocol between =
different
>>>> parties, including
>>>>  - client and authorization server;
>>>>  - client and resource server; and
>>>>  - authorization server and resource server.
>>>> =20
>>>> The group will seek to minimize assumptions about the form of =
client
>>>> applications, allowing for:
>>>> - Fine-grained specification of access
>>>> - Approval of AS attestation to identifiers and other identity =
claims
>>>> - Approval of access to multiple resources and APIs in a single =
interaction
>>>> - Support for multiple access tokens in a single request and =
response
>>>> - Support for directed, audience-restricted access tokens
>>>> - Separation between the party authorizing access and the party =
operating the
>>>> client requesting access
>>>> =20
>>>> The group will define extension points for this protocol to allow =
for
>>>> flexibility in areas including:
>>>> =20
>>>> - Cryptographic agility for keys, message signatures, and proof of =
possession
>>>> - User interaction mechanisms including web and non-web methods
>>>> - Mechanisms for conveying user, software, organization, and other
>>>> information used in authorization decisions
>>>> - Mechanisms for presenting tokens to resource servers and binding =
resource
>>>> requests to tokens and associated cryptographic keys
>>>> - Optimized inclusion of additional information (including =
identifiers and
>>>> identity assertions) through the delegation process
>>>> =20
>>>> Additionally, the group will provide mechanisms for management of =
the protocol
>>>> lifecycle including:
>>>> =20
>>>> - Discovery of the authorization server
>>>> - Revocation of active tokens
>>>> - Mechanisms for the AS and RS to communicate the access granted by =
an access
>>>> token
>>>> =20
>>>> Although the artifacts for this work are not intended or expected =
to be
>>>> backwards-compatible with OAuth 2.0 or OpenID Connect, the group =
will attempt
>>>> to simplify migrating from OAuth 2.0 and OpenID Connect to the new =
protocol
>>>> where possible.
>>>> =20
>>>> 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. Functionality that builds directly on OAuth 2.0 will be =
directed
>>>> to the OAuth Working Group, including functionality back-ported =
from the
>>>> protocol developed here to OAuth 2.0.
>>>> =20
>>>> The group is chartered to develop mechanisms for applying =
cryptographic
>>>> methods, such as JOSE and COSE, to the delegation process. This =
group is not
>>>> chartered to develop new cryptographic methods.
>>>> =20
>>>> The group is chartered to develop mechanisms for conveying identity
>>>> information within the protocol including existing identifiers =
(such as email
>>>> addresses, phone numbers, usernames, and subject identifiers) and =
assertions
>>>> (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
>>>> Credentials). The group is not chartered to develop new formats for
>>>> identifiers or assertions, nor is the group chartered to develop =
schemas for
>>>> user information, profiles, or other identity attributes, unless a =
viable
>>>> existing format is not available.On =
Jul 7, 2020, at 1:06 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

Again to be blunt, my flow for =
consent doesn't match yours.


Thanks,=
 Tom =E2=80=94 we are aware that there are pulls from different =
directions here, and that=E2=80=99s why I think it=E2=80=99s important =
for the group to try and look at them the same way. Declarations that =
there is one and only one use case aren=E2=80=99t helpful. I=E2=80=99ve =
said before, and I=E2=80=99ll say again, that I think that we can have =
both trust models inside GNAP.

thx ..Tom =
(mobile)

On Tue, Jul 7, 2020, 10:04 AM Denis =
<denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Justin,

    

     =20
      Denis,
      


      

      
A lot of what you=E2=80=99re describing below =
changes the
        very nature of the roles in the system. The component that
        manages the consent and issues tokens is, by definition, the AS.
      

    
The current charter states: "the =
artifacts for this work are not
      intended or expected to be backwards-compatible with OAuth 2.0 or
      OpenID Connect".

      So we are not bound to OAuth 2.0 nor OpenID Connect. Hence, we do
      not need to stick with all their concepts.
No, but =
what you call things does matter. Reassigning a piece of functionality =
from one component to another without changing the name is problematic, =
as it causes a lot of confusion. We can=E2=80=99t change the model that =
OAuth 2 gave us, we live in a world where it already exists. It=E2=80=99s =
not helpful to try to force a new definition on something. But we can =
transcend that model with GNAP, and sometimes that means questioning the =
atomicity of our components and their roles. 


    
I believe that the user's consent should be given =
after a
      dialogue with the RS which does not mean that the RS shall capture
      the user's consent 

      since it is the duty of the client. When a user selects one
      operation among a choice of operations proposed by the RS, the RS
      should inform 

      the client about which attributes it needs to present and from
      which ASs. It is only at this moment that the clients learns which
      ASs are

      adequate. Before this moment, the dialogue *cannot* be handled by
      an AS. Then after the duty of the client is to look for these
      attributes and 

      to get them from one or more ASs. ASs are all equal. There is no
      single AS with which the user shall be bound or have a particular
      relationship

    
Managing the authorization (and the user's =
consent) at the RS is
      simple: I have proposed a way to do it (and FIDO U2F is even
      included).

Managing the authorization at the AS would mandate a close
      synchronization between the RS and all the ASs with which it has a
      relationship.

      There would be the need to define a synch. protocol and it is much
      simpler to avoid to use such a protocol and thus not to define =
it.

      "Out-of-bands" means for such a synchronisation would not be a
      better solution. But the major issue by managing the user's
      consent at the AS 

      is to allow the AS to act as Big =
Brother.
Again, you =
seem to assume that the AS cannot be something that is in the control of =
the RS, the client, or the user. That=E2=80=99s not true. It=E2=80=99s a =
functional role in the system, not a deployment requirement.

A copy and paste from a document published under the "Digital
      Europe for All" (DE4A) project :

    
The privacy principle requires =
that the private life, the home
        and the communications of each citizen 

        are respected and that no personal data are gathered without a
        legitimate reason and purpose.

        

        Data protection and privacy should (as far as possible) be achieved
          by design, i.e. be embedded in the 

        technical solutions and services in a way that misuse or
        illegitimate access is made impossible or at 

        least very difficult through the technical approach itself, and
        without having to rely on organisational 

        measures or solely on legal measures to =
guarantee the
          compliance. 

        

        Main sources for this principle: CFREU, GDPR, eIDAS, eGov Action
        Plan, EIF, Tallinn Declaration, and 

        SDGR. 

      

    

    

      
The user shouldn=E2=80=99t ever have to interact =
directly
        with the RS, since the RS is, by definition, an API that is
        called by software, not an interactive component. 

      


      

      
But it=E2=80=99s important to note that these are =
only
        :roles: to be played and not strictly speaking separate pieces
        of software, and that these roles can be combined and split in a
        variety of ways. For instance, in what you=E2=80=99re talking =
about
        below, instead of saying that it=E2=80=99s the RS that manages =
the
        consent, what if you saw it as the functionality of the AS
        that=E2=80=99s been split between two components: one =
privacy-preserving
        element that issues tokens, and another that deals with
        interaction and consent. This is already a pattern that some in
        the WG have expressed interest in supporting with GNAP, and the
        core charter tenet of separating the interaction from the
        delegation channels is something that could help =
there. 

      


      

      
Would it be possible to look at your use case in
        this different light? 

    
I could see the RS (i.e. not the AS) =
split into two components:
      an API and an MMI to manage the choices and the consent of the
      user. 

      This looks artificial but would it help ?


I believe so, because then the =E2=80=9CMMI=E2=80=9D=
 is defined as a separate functional component. Don=E2=80=99t be =
surprised when people classify it as =E2=80=9Cpart of the AS=E2=80=9D, =
since that=E2=80=99s where that functionality was previously hosted. =
It=E2=80=99s like the early days of OAuth 2 where people talked about =
both the =E2=80=9CAS=E2=80=9D and =E2=80=9CRS=E2=80=9D as the =
=E2=80=9Cserver=E2=80=9D, since that was the component that both pieces =
fulfilled. And indeed, there are a lot of OAuth 2 deployments that =
combine these two today. There are also other arrangements like the ones =
you=E2=80=99ve been talking about where the trust is distributed =
differently. 

 =E2=80=94 =
Justin

Denis
=

    

    

      
It=E2=80=99s always possible that we need to =
re-cast some of
        these roles, and that=E2=80=99s been done before: in OAuth 2 we =
defined
        the AS and RS roles separately, even though they can always be
        deployed together anyway. So with that it=E2=80=99s possible =
that there
        are other distinct pieces here that are working together that we
        need to tease out, but that=E2=80=99s something for the WG to =
figure
        out. We can always decide to separate out the parts and allow
        them to be recombined in deployment, But I do not think it is
        helpful to redefine the existing roles, especially by moving key
        facets from one existing role to another.

      


      

      
 =E2=80=94 Justin

      

        


          

            
On Jul 7, 2020, at 8:43 AM, Denis <denis.ietf@free.fr> wrote:

            

            

              
Hi Roman,

              

                

                  
Hi
                    Denis!

                  
 

                  
Thanks
                    for the feedback and for repeating your review on
                    the revised text.  More inline =E2=80=A6

                  
 

                  

                    

                      

                        
From: iesg <iesg-bounces@ietf.org> On Behalf Of Denis

                          Sent: Monday,
                          July 6, 2020 10:55 AM

                          To: iesg@ietf.org

                          Cc: txauth@ietf.org

                          Subject: Re:
                          [Txauth] WG Review: Grant Negotiation and
                          Authorization Protocol (gnap)

                      

                    

                    
 

                    

                      
Since it is today the
                          last day to send back comments, you will find
                          hereafter my comments on the last charter
                          version-05.

                    

                  

                

              
BTW, I sent an email
                yesterday evening with the subject: Support
                  of FIDO and
                data minimization by RSs, where I indicated that the
                charter should 

                mention FIDO U2F so that it should be possible to logon
                to a RS using either FIDO or by presenting one (or more)
                access tokens from one (or more) AS.
The original email is
                here : https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIP=
QczD7icwE/

              

                

                  

                    

                      

                    

                    

                      
charter-ietf-gnap-00-05

                      
This group is chartered to develop a fine-grained delegation =
protocol for authorization, API access, user identifiers, and identity =
assertions. 

                      
 

                      
[Denis] Fine.

                      
 

                      
The protocol will also allow the client to present unverified =
identifiers and verifiable assertions to the AS as part of its request. =


                      
 

                      
[Denis] This sentence is too vague because "as part of its =
request" is not explicit enough. If it means  "as part as an access =
token request" 

                      
this should be explicitly said. If, it is not the case, then =
it should be clearly explained. The AS should know as little as possible =
(including nothing)

                      
about what the client is doing.

                      
 

                      
[Roman] The =E2=80=9Crequest=E2=80=9D here is the =E2=80=9Cacce=
ss token request=E2=80=9D.  That can be made clearer.

                    

                  

                

              
This would be
                appreciated.

              

                

                  

                    

                      

                      
 

                      
This protocol will allow an authorizing party to delegate =
access to client software through an authorization server. 

                      
 

                      
[Denis] The word "privacy" is still missing =
in the charter. "Delegating access to client software through an =
authorization server" 

                      
is negating the fact that the user's privacy will ever be =
considered. IMHO, I believe that a RS may delegate some operation to =
another RS, 

                      
but I don't believe that an AS should be concerned by any =
form of delegation, otherwise it would have the ability to act as "Big =
Brother".

                      
OAuth has not been constructed taking into consideration the =
user's privacy. The major difference with it should be that GNAP has =
been 

                      
constructed along "privacy by design" =
principles.

                      
 

                      
[Roman]  I don=E2=80=99t exactly follow how =
considerations for privacy are being negated.  Above and beyond =
use-case specific considerations that would be defined later,=20
RFC6973 is the IETF consensus design guidance that will guide the =
privacy threats and mitigations of the work.  What design guidance =
would you recommend that=20
the WG should consider that aren=E2=80=99t captured in RFC6973?

                    

                  

                

              
I believe my message is
                quite clear : If the AS is handling the delegation
                process, it will know what the client is doing or where
                it is going. 

                On the contrary, if the RS is handling the delegation
                process, the AS will be unable to know what the client
                is doing. In addition, an AS-centric 

                architecture would not be scalable and would need a lot
                of synchronizations between ASs and RSs. The user
                consent should be handled by the RS 

                and not by the AS. When a RS is unable to provide the
                service, it is best placed to tell directly to the
                client what it could do next. 

              
RFC 6973 is very good
                document. Section 7.1 states: 

              
          =
b.  Data. 
                What information does the protocol expose about
                individuals, their devices, and/or their device usage
                (other than the identifiers discussed in (a))? 

              
Data includes both the
                operation and the data associated with the operation. An
                AS should be kept ignorant of both the operation and the
                data associated with the operation.

              
c.  Observers.  =
(...) Are there ways for
                  protocol implementers to  choose to limit the
                  information shared with each entity?  

                

              
If theses guidances
                were followed, the proposed architecture would not be
                AS-centric.

              

                

                  

                    

                      
 

                      
It will expand upon the uses cases =
currently supported by OAuth 2.0 and OpenID Connect (itself an extension =
of OAuth 2.0) to support authorizations 

                      
scoped as narrowly as a single transaction, provide a clear =
framework for interaction among all parties involved in the protocol =
flow, and remove 

                      
unnecessary dependence on a browser or user-agent for =
coordinating interactions.

                      
 

                      
[Denis] There is no need to refer to OAuth 2.0 and OpenID =
Connect. Some existing uses cases (i.e. "non-expanded" =
use cases) should be supported 

                      
differently from OAuth 2.0 and OpenID Connect, in particular =
to support the user's privacy.

                      
 

                      
[Roman] I=E2=80=99d want to hear others on this =
rescoping.  Building upon the use cases of OAuth 2.0 and OpenID =
Connect has been core, consensus-validated tenant for some time now.

                      
 

                      
The delegation process will be acted upon by multiple parties =
in the protocol, each performing a specific role. The protocol will =
decouple the channels used 

                      
by the protocol participants to communicate from the =
delegation channel, which happens directly between the client and the =
authorization server (in contrast 

                      
with OAuth 2.0, which is initiated by the client redirecting =
the user=E2=80=99s browser). 

                      
 

                      
[Denis] Here again, the delegation process, if any, should be =
handled by RSs and not by ASs. 

                      
The term "delegation channel" is being used but it is left =
undefined. It is not understandable.

                      
 

                      
[Roman] This sentence was just added into -05 address =
Security AD feedback.  In this case, it was made to distinguish =
between in-band signaling and the new purpose-to-be-built =
channel.

                    

                  

                

              
Since delegation should
                not be handled by the AS, a delegation channel should
                not exist.

              

                

                  

                    

                      

                      
 

                      
The protocol will include a means of specifying how the user =
can potentially be involved in an interactive fashion during the =
delegation process. 

                      
The client and Authorization Server (AS) will use these =
interaction mechanisms to involve the user, as necessary, to make =
authorization decisions.

                      
 

                      
[Denis] Here again, the =
delegation process, if any, should be handled by RSs and not by ASs. The =
AS should know as little as possible (including nothing)

                      
about what the client is doing.

                      
 

                      
[Roman] Understood =E2=80=93 as I understand it, you have =
concern with the scope of the AS behavior.  I=E2=80=99d be =
interesting in hearing additional support for this rescoping.  

                      
 

                      
This decoupling avoids many of the security concerns and =
technical challenges of OAuth 2.0 and provides a non-invasive path for =
supporting future types 

                      
of clients and interaction channels.

                      
 

                      
[Denis] This is not understandable to me. Is such a sentence =
really needed in a charter ?

                      
 

                      
[Roman] Can someone on the TxAuth mailing list remind us on =
why this sentence is here?  With a fresh read, I also can=E2=80=99t =
remember why we need it.

                      
 

                      
The group will define interoperability for this protocol =
between different parties, including

                      
-          =
client and authorization server;

                      
-          =
client and resource server; and

                      
     -      =
authorization server and resource server.

                      
 

                      
[Denis] In order to support the user's privacy, there should =
be no interaction at all between an authorization server and a resource =
server 

                      
at the time of a client request.

                      
 

                      
The group will seek to minimize assumptions about the form of =
client applications, allowing for:

                      
-          =
Fine-grained specification of access

                      
-          =
Approval of AS attestation to identifiers and other identity =
claims

                      
-          =
Approval of access to multiple resources and APIs in a single =
interaction

                      
-          =
Multiple access tokens in a single request and =
response

                      
-          =
AS-directed dispatch of access tokens to the appropriate =
RS

                      
[Denis] As-directed dispatch does not allow to support the =
user's privacy. However, RS-directed dispatch allows to support the =
user's privacy.

                      
It should be explicitly mentioned.

                      
[Roman] As above (per the AS vs. RS behavior)

                      
-          =
Separation between the party authorizing access and the party =
operating the client requesting access 

                      
 

                      
[Denis] It is questionable whether such a separation would be =
really beneficial. In doubt, this item should be removed.

                      
[Roman] Could you say more on why this flexibility wouldn=E2=80=
=99t be worth it?  

                    

                  

                

              
Except for added
                complexity, there is no need to have separate channels.
                It is simpler to send the access token in addition to
                the data 

                and, for additional security, to sign the data using a
                private key corresponding to a public key present in the
                access token.

              

                

                  

                    

                      

                      
The group will define extension points for this protocol to =
allow for flexibility in areas including:

                      
 

                      
Cryptographic agility for keys, message signatures, and proof =
of possession

                      
-          =
User interaction mechanisms including web and non-web =
methods

                      
-          =
Mechanisms for conveying user, software, organization, and =
other information used in authorization decisions 

                      
-          =
Mechanisms for presenting tokens to resource servers and =
binding resource requests to tokens and associated cryptographic keys =


                      
Optimized inclusion of additional information (including =
identifiers and identity assertions) through the delegation process 

                      
 

                      
Additionally, the group will provide mechanisms for =
management of the protocol lifecycle including:

                      
-          =
Discovery of the authorization server

                      
-          =
Revocation of active tokens

                      
Data model for granted access and mechanisms for the AS and =
RS to communicate the granted access model

                      
 

                      
[Denis] While it is the duty for the RS to communicate the =
granted access model to the client at the appropriate =
instant of time, 

                      
the AS should be kept fully ignorant of it.

                      
 

                      
Although the artifacts for this work are not intended or =
expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, 

                      
the group will attempt to simplify migrating from OAuth 2.0 =
and OpenID Connect to the new protocol where possible.

                      
 

                      
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. Functionality that builds directly =
on OAuth 2.0 will be directed to the OAuth Working Group, including 

                      
functionality back-ported from the protocol developed here to =
OAuth 2.0.

                      
 

                      
The group is chartered to develop mechanisms for applying =
cryptographic methods, such as JOSE and COSE, to the delegation process. =


                      
This group is not chartered to develop new cryptographic =
methods.

                      
 

                      
The group is chartered to develop mechanisms for conveying =
identity information within the protocol including existing identifiers =


                      
(such as email addresses, phone numbers, usernames, and =
subject identifiers) and assertions (such as OpenID Connect ID Tokens, =


                      
SAML Assertions, and Verifiable Credentials). The group is =
not chartered to develop new formats for identifiers or assertions, nor =
is the group 

                      
chartered to develop schemas for user information, profiles, =
or other identity attributes, unless a viable existing format is not =
available.

                      
 

                      
The initial work will focus on using HTTPS for communication =
between the client and the authorization server, taking advantage 

                      
of optimization features of HTTP/2 and HTTP/3 where possible, =
and will strive to enable simple mapping to other protocols such as COAP =


                      
when doing so does not conflict with the primary focus.

                      
 

                      
Milestones to include:

                      
-          =
Core delegation protocol

                      
[Denis] Before defining a "Core delegation protocol", a =
simple client server-protocol involving the presentation of several =
access tokens to one RS should be defined. 

                      
Privacy principles should be applied when defining the =
protocol. Then after, a delegation mechanism allowing one RS to forward =
an operation to another RS should be defined.

                      
-          =
Key presentation mechanism bindings to the core protocol =
including TLS, detached HTTP signature, and embedded HTTP signatures =


                      
[Denis] Bindings to TLS are now deprecated, why should they =
be maintained ? 

                      
Signatures may be needed but they do not necessarily need to =
be "detached HTTP signature, and embedded HTTP signatures". 

                      
This item should be either removed or reworded.

                      
[Roman] Noted.  I=E2=80=99d want to hear others on this =
rescoping.

                    

                  

                

              
As explained above, it
                is possible to sign the data using a private key
                corresponding to a public key present in the access
                token.

              

                

                  

                    

                      

                      
 

                      
-          =
Conveyance mechanisms for identifiers and assertions =


                      
-          =
Guidelines for use of protocol extension points (if needed) =


                      
    =
 -    Guidelines on
                          migration paths, implementation, and
                          operations

                      
[Denis] The
                          above three lines are rather =
mysterious.

                      
[Roman] =
The guidelines on
                        migration paths came from the initial IESG
                        review in order to have a named activity to
                        action the design goal of =E2=80=9C=E2=80=A6 the =
group will
                        attempt to simplify migrating from OAuth 2.0 and
                        OpenID Connect to the new protocol where
                        possible=E2=80=9D a bit earlier in the text.

                      
Where possible, the
                          group will seek to make use of tools to guide
                          and inform the standardization process
                          including formal analysis, 

                          architecture documents, and use case
                          documents. These artifacts will not be
                          considered as working group milestones or
                          deliverables.

                      
The working group will
                          cooperate and coordinate with other IETF WGs
                          such as OAUTH, and work with external
                          organizations, 

                          such as the OpenID Foundation, as =
appropriate.

                      
[Denis] The
                          charter should be shorter.

                      
 

                      
[Roman]=
 Definitely.  Nevertheless, we
                        have the current text through rough consensus
                        process achieved from two BoFs and multiple
                        mailing list consensus calls.

                    

                  

                

              
In a previous post, I
                proposed a much shorter text.
Denis

              

              

                

                  

                    

                      

                      
 

                      
Regards,

                      
Roman 

                    

                    

                      
 

                    

                    

                      
/Denis

                    

                    

                      
 

                    

                    

                      
A =
new IETF WG has been proposed in the Security Area. The IESG has not =
made

                      
any determination yet. The following draft charter was =
submitted, and is

                      
provided for informational purposes only. Please send your =
comments to the

                      
IESG mailing list (iesg@ietf.org) by =
2020-07-06.

                      
 

                      
Grant Negotiation and Authorization Protocol (gnap)

                      
---------------------------------------------------------------=
--------

                      
Current status: Proposed WG

                      
 

                      
Chairs:

                      
  Yaron Sheffer <yaronf.ietf@gmail.com>

                      
  Leif Johansson <leifj@sunet.se>

                      
 

                      
Assigned Area Director:

                      
  Roman Danyliw <rdd@cert.org>

                      
 

                      
Security Area Directors:

                      
  Benjamin Kaduk <kaduk@mit.edu>

                      
  Roman Danyliw <rdd@cert.org>

                      
 

                      
Mailing list:

                      
  Address: txauth@ietf.org

                      
  To subscribe: =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/txauth

                      
  Archive: https://mailarchive.ietf.org/arch/browse/txauth/

                      
 

                      
Group page: https://datatracker.ietf.org/group/gnap/

                      
 

                      
Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/

                      
 

                      
This group is chartered to develop a fine-grained delegation =
protocol for

                      
authorization and API access, as well as requesting and =
providing user

                      
identifiers and claims. This protocol will allow an =
authorizing party to

                      
delegate access to client software through an authorization =
server. It will

                      
expand upon the uses cases currently supported by OAuth 2.0 =
and OpenID Connect

                      
(itself an extension of OAuth 2.0) to support authorizations =
scoped as

                      
narrowly as a single transaction, provide a clear framework =
for interaction

                      
among all parties involved in the protocol flow, and remove =
unnecessary

                      
dependence on a browser or user-agent for coordinating =
interactions.

                      
 

                      
The delegation process will be acted upon by multiple parties =
in the protocol,

                      
each performing a specific role. The protocol will decouple =
the interaction

                      
channels, such as the end user=E2=80=99s browser, from the =
delegation channel, which

                      
happens directly between the client and the authorization =
server (in contrast

                      
with OAuth 2.0, which is initiated by the client redirecting =
the user=E2=80=99s

                      
browser). The protocol will include a means of specifying how =
the user can

                      
potentially be involved in an interactive fashion during the =
delegation

                      
process. The client and Authorization Server (AS) will use =
these interaction

                      
mechanisms to involve the user, as necessary, to make =
authorization decisions.

                      
This decoupling avoids many of the security concerns and =
technical challenges

                      
of=
 OAuth 2.0 and provides a non-invasive path for supporting future types =
of

                      
clients and interaction channels.

                      
 

                      
The group will define interoperability for this protocol =
between different

                      
parties, including

                      
 =
- client and authorization server;

                      
 =
- client and resource server; and

                      
 =
- authorization server and resource server.

                      
 

                      
The group will seek to minimize assumptions about the form of =
client

                      
applications, allowing for:

                      
- =
Fine-grained specification of access

                      
- =
Approval of AS attestation to identifiers and other identity claims

                      
- =
Approval of access to multiple resources and APIs in a single =
interaction

                      
- =
Support for multiple access tokens in a single request and response

                      
- =
Support for directed, audience-restricted access tokens

                      
- =
Separation between the party authorizing access and the party operating =
the

                      
client requesting access

                      
 

                      
The group will define extension points for this protocol to =
allow for

                      
flexibility in areas including:

                      
 

                      
- =
Cryptographic agility for keys, message signatures, and proof of =
possession

                      
- =
User interaction mechanisms including web and non-web methods

                      
- =
Mechanisms for conveying user, software, organization, and other

                      
information used in authorization decisions

                      
- =
Mechanisms for presenting tokens to resource servers and binding =
resource

                      
requests to tokens and associated cryptographic keys

                      
- =
Optimized inclusion of additional information (including identifiers =
and

                      
identity assertions) through the delegation process

                      
 

                      
Additionally, the group will provide mechanisms for =
management of the protocol

                      
lifecycle including:

                      
 

                      
- =
Discovery of the authorization server

                      
- =
Revocation of active tokens

                      
- =
Mechanisms for the AS and RS to communicate the access granted by an =
access

                      
token

                      
 

                      
Although the artifacts for this work are not intended or =
expected to be

                      
backwards-compatible with OAuth 2.0 or OpenID Connect, the =
group will attempt

                      
to=
 simplify migrating from OAuth 2.0 and OpenID Connect to the new =
protocol

                      
where possible.

                      
 

                      
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. Functionality that builds directly on OAuth 2.0 =
will be directed

                      
to=
 the OAuth Working Group, including functionality back-ported from the

                      
protocol developed here to OAuth 2.0.

                      
 

                      
The group is chartered to develop mechanisms for applying =
cryptographic

                      
methods, such as JOSE and COSE, to the delegation process. =
This group is not

                      
chartered to develop new cryptographic methods.

                      
 

                      
The group is chartered to develop mechanisms for conveying =
identity

                      
information within the protocol including existing =
identifiers (such as email

                      
addresses, phone numbers, usernames, and subject identifiers) =
and assertions

                      
(such as OpenID Connect ID Tokens, SAML Assertions, and =
Verifiable

                      
Credentials). The group is not chartered to develop new =
formats for

                      
identifiers or assertions, nor is the group chartered to =
develop schemas for

                      
user information, profiles, or other identity attributes, =
unless a viable

                      
existing format is not available.<o:p =
cl



=

--Apple-Mail=_3FC5F57D-A201-4664-B30A-C80CF96166E4--


From nobody Tue Jul  7 13:39: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 F2B183A0A62 for ; Tue,  7 Jul 2020 13:39:34 -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_REMOTE_IMAGE=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 w7cZwvsiPrxF for ; Tue,  7 Jul 2020 13:39: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 A75843A0A56 for ; Tue,  7 Jul 2020 13:39:30 -0700 (PDT)
Received: from [192.168.1.7] (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 067KdSTS022749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Jul 2020 16:39:29 -0400
From: Justin Richer 
Message-Id: <6846D2F0-5096-404B-A529-676146392F45@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2EC0B3C3-DF0A-4896-ADD2-3A8885D9C3D1"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 7 Jul 2020 16:39:28 -0400
In-Reply-To: <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu>
Cc: Tobias Looker 
To: txauth@ietf.org
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 07 Jul 2020 20:39:35 -0000

--Apple-Mail=_2EC0B3C3-DF0A-4896-ADD2-3A8885D9C3D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I=E2=80=99ve been thinking more about these use cases, and it might help =
us to think of GNAP=E2=80=99s access tokens as capabilities in the =
computer security sense =E2=80=94 but more specifically, capabilities =
that are delivered with their own context for use. In that way, an =
otherwise naive client can be handed an access token and simply know =
exactly what to do with it. This context would be delivered alongside =
the token, so the token material itself remains opaque to the client.

I wanted to bring up a W3C spec for a capabilities model based on linked =
data:

https://w3c-ccg.github.io/zcap-ld/ 

Building a fully featured capabilities context is difficult, at the very =
least. And unfortunately, I don=E2=80=99t think this spec actually gives =
us any viable solutions to work with. In particular the =E2=80=9Cactions=E2=
=80=9D section is effectively blank, offloading the work to an external =
JSONLD process (side note, this is one of the problems I have with specs =
based on JSONLD, they externalize the important parts into local =
contexts and break interoperability =E2=80=94 but I digress). But at =
least it=E2=80=99s another way of looking at the problem space that =
might be outside the familiar zone of many of the OAuth world.

 =E2=80=94 Justin

> On Jun 26, 2020, at 9:23 AM, Justin Richer  wrote:
>=20
> On Jun 25, 2020, at 9:07 PM, Tobias Looker > wrote:
>>=20
>> I find this feature interesting and think it could be an important =
pattern going forward to enable an AS to be able to describe the utility =
of a token to the client, however as already pointed out in the thread I =
think there is some potential hidden complexity that would need to be =
ironed out such that it does not make the simple things complicated.
>>=20
>> Justin, do you see this feature as something the client has to =
explicitly request, i.e "please give me access and instructions on how =
to use my access" or rather that the AS would just return this =
information in conjunction with the access token if it had it available?
>>=20
>=20
> This is something that I=E2=80=99d brought up as a possibility on the =
previous thread =E2=80=94 something like a flag the client would set. =
This would be especially important if the AS wants to return multiple =
access tokens but the client requested 1, or the client requested N and =
the AS wants to return M in response. Basically any time there=E2=80=99s =
a mismatch, that=E2=80=99s extra complexity on the client that I really =
don=E2=80=99t think we want to be universal. A flag to turn that kind of =
direction and splitting on would be a potential start. But there are =
potential snags here too, and it comes down to how you manage the =
defaults...
>=20
>> > This is just the start, too. Things get even more complex if the =
client can ask for multiple different kinds of resources at once. What =
if the AS decides that the client needs a hyper-focused directed token =
for one part of the API, but can use a general token for other stuff? =
Can it signal that to the client? And if it can, does that mean that all =
clients need to be prepared for that kind of thing?
>>=20
>> Would a potential default be that if a client did for any reason not =
support processing the additional information returned with the =
access_token, just to ignore it? I think in the spirit of keeping the =
simple things simple, this potentially makes sense?
>=20
> That=E2=80=99s the real trick, if you ask me. It has to be :safe: for =
a client to ignore this information. Which means the AS can=E2=80=99t =
rely on the client =E2=80=9Cdoing the right thing=E2=80=9D with the =
information in the =E2=80=9Ctoken directions=E2=80=9D portion of the =
response. Even setting aside the advanced and related =E2=80=9Csplit =
tokens=E2=80=9D idea above, we need to make sure that an AS/RS setup is =
built such that if the AS tells a client =E2=80=9Conly do X with your =
token=E2=80=9D and the client does =E2=80=9CY=E2=80=9D, then there are =
other protections and practices in place to prevent things from going =
haywire if the client does =E2=80=9CY=E2=80=9D either by accident or =
through ignorance.=20
>=20
> If OAuth 2 has taught us anything, it=E2=80=99s that client =
applications are going to be the laziest participants in the security =
model. And that makes sense, really =E2=80=94 security isn=E2=80=99t =
what the client apps are trying to do, they=E2=80=99re trying to use the =
RS to do something. So we need to make sure that whatever system we =
design will fail on the safe side as much as possible, and keep things =
simple for the client.
>=20
>>=20
>> > here are some worked out samples of this:
>> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token =

>> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ =

>> Peace ..tom
>>=20
>> As one of the authors of those mentioned drafts, I am interested in =
discussing that, but perhaps on a seperate thread? As at least the bound =
assertion spec is primarily concerned with binding mechanisms for the =
artifacts produced from an authorization flow (specifically identity =
claims), whereas I think directed access tokens is just more generally =
talking about whether GNAP should support an AS conveying how to use an =
access_token it produces during a flow with a client.
>>=20
>=20
> I think that these are separate issues as well.
>=20
>  =E2=80=94 Justin
>=20
>> Thanks,
>>  	 =09
>> Tobias Looker
>> Mattr
>> +64 (0) 27 378 0461
>> tobias.looker@mattr.global 
>>  	 =
	 =
	 =

>> This communication, including any attachments, is confidential. If =
you are not the intended recipient, you should not read it - please =
contact me immediately, destroy it, and do not copy or use any part of =
this communication or disclose anything about it. Thank you. Please note =
that this communication does not designate an information system for the =
purposes of the Electronic Transactions Act 2002.
>>=20
>>=20
>> On Wed, Jun 24, 2020 at 10:14 PM Denis > wrote:
>> Justin, I fear we are still far away from an agreement about what =
this BoF should do.
>>=20
>> Tom Jones is saying " I am getting tired of the whack-a-mole approach =
..."
>>=20
>> I don't agree with you when you write: "I think it=E2=80=99s going to =
be overwhelmingly common that a given RS is going to trust exactly one =
AS=20
>> that it knows about ahead of time". Such an architecture would have =
exactly the same limitations as OAuth 2.0. and would not be scalable.
>>=20
>> Before we start, we should have a clear view of the whole picture =
rather than starting from one scenario and expanding it in many =
different directions.
>> For building an architecture, a pre-requirement is to define ALL the =
trust relationships. I don't believe that we have an agreement at this =
time on what=20
>> these trust relationships are.=20
>>=20
>> You are also using the following wording: "methods for the AS and RS =
to communicate what the token=E2=80=99s good for".=20
>> With such a paradigm, it would be impossible to protect the user's =
privacy.=20
>>=20
>> A key question is : Will GNAP take care of the user's privacy or will =
GNAP prevent to take care of the user's privacy ?
>>=20
>> About "the ability for the client to get several access tokens to get =
different resources from one request" is indeed a complex case.
>>=20
>> No one (including ASs) is able to predict in advance which access =
tokens will be needed, since they depend upon the kind of operation(s)=20=

>> the client will be willing to perform. For privacy reasons, ASs =
should be kept ignorant of all the operations that a client is going to =
perform=20
>> on one or more resource servers. I believe that every effort should =
be made to avoid the AS to be in a position to be able to trace the =
operations=20
>> performed by its clients on various RSs.
>>=20
>> To handle the complex case you envision, the full workflow of =
operations needs to be considered with a detailed focus on the time=20
>> at which the user's consent and choice happens (consent and choice is =
the first privacy principle from ISO 29100).
>>=20
>> First of all, an access token could be targeted to a service rather =
than to a server. This would already solve many cases.
>>=20
>> When a RS needs to call another RS (which does not support the same =
service) then the client should be informed by the first RS.
>> His "consent and choice" should then be obtained by the first RS and, =
when the user agrees, the client should then ask an access token=20
>> to one of the ASs trusted by the second RS in order to perform the =
subsequent operation. =20
>>=20
>> Denis
>>=20
>> PS.  In an email sent on June 23 you wrote: " I think an on-device AS =
is an important use case".  I am sorry, but I don't understand.
>>        However, I do understand what "a server-based AS" is.
>>=20
>>=20
>>> Denis, thanks for the great comments. I think that your trust model =
is pretty different from what I=E2=80=99d laid out initially, and while =
it=E2=80=99s an interesting and important one, it is not what I meant by =
=E2=80=9Cmultiple access tokens=E2=80=9D in my discussion below. I think =
that might be the cause of some disconnect here, but that doesn=E2=80=99t =
mean it=E2=80=99s out of reach for what the WG is after.
>>>=20
>>> When I refer to multiple access tokens, and what the charter calls =
out as multiple access tokens, is the ability for the client to get =
several access tokens to get different resources from one request. I =
personally see this as an optimization of a specific set of use cases, =
some of which I discussed in my original email. There are others, I=E2=80=99=
m sure, but all the ones I=E2=80=99ve seen are around the client needing =
to get several different kinds of access through an AS.=20
>>>=20
>>> I think it=E2=80=99s going to be overwhelmingly common that a given =
RS is going to trust exactly one AS that it knows about ahead of time. =
But for RS=E2=80=99s that can trust multiple AS=E2=80=99s, then we =
should have a model that can accommodate that as well. That=E2=80=99s =
why the charter calls out methods for the AS and RS to communicate what =
the token=E2=80=99s good for. I think the basis of those methods is =
going to start with a common token model, and likely incorporate into =
things like token formats and introspection-style token APIs.=20
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>> On Jun 22, 2020, at 3:55 AM, Denis > wrote:
>>>>=20
>>>> Hello Justin,
>>>>=20
>>>> A few comments between the lines.
>>>>=20
>>>>> One of the most important aspects to GNAP is going to be an =
ability to address things that OAuth 2 can=E2=80=99t, or at least =
can=E2=80=99t do without significant gymnastics. So with that, I wanted =
to bring back a use case discussion that originally came up while we =
were talking about the possibility of multiple access tokens, a few =
months back. I don=E2=80=99t know if this concept has a regular term, so =
I=E2=80=99m going to call it =E2=80=9Cdirected access tokens=E2=80=9D =
until we come up with something better =E2=80=94 assuming we decide this =
is worthwhile.=20
>>>> I don't understand what may mean "directed access tokens=E2=80=9D =
but I understand what means "multiple access tokens".=20
>>>> When speaking of "multiple access tokens", these access tokens may =
come from one or more ASs.
>>>>=20
>>>>> In OAuth, the client=E2=80=99s supposed to always know where to =
send its access token, and that knowledge is completely outside the =
protocol. This makes a lot of sense for many (if not most) deployments, =
as OAuth is really there to enable the API access that the client =
already knows about.
>>>>>=20
>>>>> But we=E2=80=99re now in a world where a client could be talking =
to a generic API that could be deployed at a number of different places, =
or a cloud deployment that the AS wants to be able to dispatch the =
client to.=20
>>>> As soon the AS is placed (again) at the centre of the model, the AS =
will have the ability to act as "Big Brother".
>>>> OAuth 2.0 has not taken care of privacy issues. On the contrary, =
GNAP should take care of them.
>>>>=20
>>>>> In order to do this, the AS needs to be able to communicate to the =
client not only the token information (and any related key and =
presentation information), but also a set of directions about what that =
specific token is good for. This needs to be information outside the =
token itself, since I believe we want to keep OAuth 2=E2=80=99s feature =
of having the token be opaque to the client. Note: while we could map =
all of these to different resource requests (in XYZ parlance) or scopes =
(in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t =
enough to tell the client what to do with the token if it doesn=E2=80=99t =
know already.=20
>>>>>=20
>>>>> I know of two use cases already in the wild, where people are =
addressing things using a mix of existing standards and some proprietary =
extensions to address things within their silos. I=E2=80=99ll try to =
summarize here, but I know the folks I=E2=80=99ve been talking to about =
this are also on the list so hopefully they can chime in with more =
detail or any corrections for something I=E2=80=99ve missed.=20
>>>>>=20
>>>>> (1) The client knows what resource it=E2=80=99s calling, but it =
doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a =
single security domain controlled by the AS,=20
>>>> Speaking of "multiple access tokens" is in contradiction with =
single security domain "controlled" by an AS.=20
>>>> A user may need to demonstrate some of his identity attributes =
granted e.g. by his bank but may also=20
>>>> need to demonstrate one or more diplomas granted by one or more =
universities. The bank cannot be=20
>>>> the "primary issuer" of a university diploma. It should not be =
either a "secondary issuer", because=20
>>>> the bank does not "need to know" what are the diplomas of the user.
>>>>=20
>>>>> but the AS needs to decide at runtime which specific instance of =
the API to direct the client to. Since things are closely tied together, =
the client just needs to effectively known an identifier for the RS, and =
this is currently implemented as a URI. Once the client has that =
identifier, it knows how to dispatch that token to that instance of the =
RS.
>>>> There is no good reason why the AS should be involved in that step.=20=

>>>> OAuth 2.0 is/was implicitly mandating a strong relationship between =
ASs and RSs which makes it non scalable.
>>>> GNAP should be based on a simple trust relationship : a given RS =
trusts some ASs for access tokens that contains some types of =
attributes.
>>>> An AS should not need to know in advance (or even at the time of an =
access token request) the RSs that are trusting it.
>>>>=20
>>>> A client could first talk to a "global service provider" which has =
the knowledge of the different RSs affiliated to it.=20
>>>>=20
>>>>> (2) The client knows what kind of thing it=E2=80=99s looking for, =
but doesn=E2=80=99t know who to ask it from.=20
>>>> Once again, the client could first talk to a "global service =
provider" which has the knowledge of the different RSs affiliated to it.=20=

>>>>=20
>>>>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the =
AS, and the AS needs to dispatch to different resources depending on =
which user logged in (and possibly what the user consented to). To make =
things more concrete, the client needs to get driver=E2=80=99s license =
information, but doesn=E2=80=99t know ahead of time which of the many =
state/provincial bureaus to call to get that information because it =
doesn=E2=80=99t know yet who the user is.=20
>>>> When a user has a driving license, he knows its issuer. The user =
can then provide some hint to the client.
>>>>=20
>>>>> The AS will know who the user is once they log in and approve =
things, and so it can direct the client to call the correct RS. Since =
this is a relatively simple API with a pre-negotiated cross-domain =
trust, the AS returns a URL that the client presents the token at.=20
>>>>  A single AS should not be aware of all the attributes a user has.=20=

>>>>=20
>>>>>=20
>>>>> As far as I know, in both of these cases, the token is only good =
for that API and not others =E2=80=94 but more on that later.
>>>>>=20
>>>>> A simple thing to do is just give back a URL with the access =
token, which tells the client where to go.=20
>>>>>=20
>>>>> 	{
>>>>> 		=E2=80=9Caccess_token=E2=80=9D: {
>>>>> 			=E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=
=9D,
>>>>> 			=E2=80=9Cresource_uri=E2=80=9D: =
=E2=80=9Chttps://example/foo "
>>>>> 		}
>>>>> 	}
>>>>>=20
>>>>> This is good for some kinds of APIs, but it=E2=80=99s limiting =
because not all APIs dispatch based on the URL. An AS might want to =
divvy up access tokens to an API that=E2=80=99s keyed on headers, or =
verbs, or any number of things. And it doesn=E2=80=99t tell us =
immediately what to do about non-exact URL matches. Can the client add =
query parameters and still use the token? What about path segments? I =
like that this simple approach addresses some common deployments that we =
already see today (see above), it=E2=80=99s not universal. Do we want or =
need a universal description language for directing where tokens go?
>>>>>=20
>>>>> This also opens up a whole new set of security questions. If the =
AS can now direct the client where to use the token, could a rogue AS =
convince a legit client to use a stolen token at the wrong RS? And what =
if the client ignores the directions from the AS entirely? Could this =
open up new avenues of attack?
>>>>>=20
>>>>> This is just the start, too. Things get even more complex if the =
client can ask for multiple different kinds of resources at once. What =
if the AS decides that the client needs a hyper-focused directed token =
for one part of the API, but can use a general token for other stuff? =
Can it signal that to the client? And if it can, does that mean that all =
clients need to be prepared for that kind of thing?
>>>>>=20
>>>>> I firmly believe that whatever we build in GNAP, we need to =
optimize for the overwhelmingly common use case of a client getting a =
single access token to call APIs that it already knows about. Anything =
we add on top of that really can=E2=80=99t get in the way of this, =
because if it does, there=E2=80=99s very small chance that people will =
try to use this for everyday things. Keep the simple things simple, and =
the complex things possible, after all.
>>>>>=20
>>>>> I=E2=80=99m really looking forward to hearing what the community =
thinks about these use cases, and hopefully the people I=E2=80=99ve =
chatted with offline about this can join the conversation and provide =
more light than I was able to.
>>>> The two use cases which are considered above are:
>>>>=20
>>>> (1) The client knows what resource it=E2=80=99s calling, but it =
doesn=E2=80=99t know where it=E2=80=99s hosted.
>>>> (2) The client knows what kind of thing it=E2=80=99s looking for, =
but doesn=E2=80=99t know who to ask it from.=20
>>>>=20
>>>> That does not mean in any way that these two use cases should be =
solved by placing the AS at the centre of the solution.
>>>>=20
>>>> Denis
>>>>=20
>>>>>=20
>>>>>  =E2=80=94 Justin
>>>>>=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 =

>>=20
>> This communication, including any attachments, is confidential. If =
you are not the intended recipient, you should not read it - please =
contact me immediately, destroy it, and do not copy or use any part of =
this communication or disclose anything about it. Thank you. Please note =
that this communication does not designate an information system for the =
purposes of the Electronic Transactions Act 2002.
>=20
> --=20
> Txauth mailing list
> Txauth@ietf.org 
> https://www.ietf.org/mailman/listinfo/txauth =


--Apple-Mail=_2EC0B3C3-DF0A-4896-ADD2-3A8885D9C3D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I=E2=80=99ve been thinking more about these use cases, and it =
might help us to think of GNAP=E2=80=99s access tokens as capabilities =
in the computer security sense =E2=80=94 but more specifically, =
capabilities that are delivered with their own context for use. In that =
way, an otherwise naive client can be handed an access token and simply =
know exactly what to do with it. This context would be delivered =
alongside the token, so the token material itself remains opaque to the =
client.

I wanted to =
bring up a W3C spec for a capabilities model based on linked data:

https://w3c-ccg.github.io/zcap-ld/
Building a fully featured capabilities =
context is difficult, at the very least. And unfortunately, I don=E2=80=99=
t think this spec actually gives us any viable solutions to work with. =
In particular the =E2=80=9Cactions=E2=80=9D section is effectively =
blank, offloading the work to an external JSONLD process (side note, =
this is one of the problems I have with specs based on JSONLD, they =
externalize the important parts into local contexts and break =
interoperability =E2=80=94 but I digress). But at least it=E2=80=99s =
another way of looking at the problem space that might be outside the =
familiar zone of many of the OAuth world.

 =E2=80=94 Justin

On Jun 26, 2020, at 9:23 AM, Justin Richer <jricher@mit.edu> =
wrote:

On Jun 25, 2020, at 9:07 PM, =
Tobias Looker <tobias.looker@mattr.global> wrote:

I find this feature interesting and think it =
could be an important pattern going forward to enable an AS to =
be able to describe the utility of a token to the client, however as =
already pointed out in the thread I think there is some potential hidden =
complexity that would need to be ironed out such that it does not make =
the simple things complicated.

Justin, do you see this feature as something the client has =
to explicitly request, i.e "please give me access and instructions on =
how to use my access" or rather that the AS would just return this =
information in conjunction with the access token if it had it =
available?


This is something that I=E2=80=99d =
brought up as a possibility on the previous thread =E2=80=94 something =
like a flag the client would set. This would be especially important if =
the AS wants to return multiple access tokens but the client requested =
1, or the client requested N and the AS wants to return M in response. =
Basically any time there=E2=80=99s a mismatch, that=E2=80=99s extra =
complexity on the client that I really don=E2=80=99t think we want to be =
universal. A flag to turn that kind of direction and splitting on would =
be a potential start. But there are potential snags here too, and it =
comes down to how you manage the defaults...

> This is just the start, too. =
Things get even more complex if the client can ask for multiple =
different kinds of resources at once. What if the AS decides that the =
client needs a hyper-focused directed token for one part of the API, but =
can use a general token for other stuff? Can it signal that to the =
client? And if it can, does that mean that all clients need to be =
prepared for that kind of thing?

Would a potential default be that if a =
client did for any reason not support processing the additional =
information returned with the access_token, just to ignore it? I think =
in the spirit of keeping the simple things simple, this potentially =
makes sense?

That=E2=80=99s the real trick, if you =
ask me. It has to be :safe: for a client to ignore this information. =
Which means the AS can=E2=80=99t rely on the client =E2=80=9Cdoing the =
right thing=E2=80=9D with the information in the =E2=80=9Ctoken =
directions=E2=80=9D portion of the response. Even setting aside the =
advanced and related =E2=80=9Csplit tokens=E2=80=9D idea above, we need =
to make sure that an AS/RS setup is built such that if the AS tells a =
client =E2=80=9Conly do X with your token=E2=80=9D and the client does =
=E2=80=9CY=E2=80=9D, then there are other protections and practices in =
place to prevent things from going haywire if the client does =E2=80=9CY=E2=
=80=9D either by accident or through ignorance. 

If OAuth 2 has taught us =
anything, it=E2=80=99s that client applications are going to be the =
laziest participants in the security model. And that makes sense, really =
=E2=80=94 security isn=E2=80=99t what the client apps are trying to do, =
they=E2=80=99re trying to use the RS to do something. So we need to make =
sure that whatever system we design will fail on the safe side as much =
as possible, and keep things simple for the client.


> here are some worked out samples of this:
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
https://mattrglobal.github.io/oidc-client-bound-assertions-spec=
/
Peace ..tom

As one of the authors of those =
mentioned drafts, I am interested in discussing that, but perhaps on a =
seperate thread? As at least the bound assertion spec =
is primarily concerned with binding mechanisms for the =
artifacts produced from an authorization flow (specifically identity =
claims), whereas I think directed access tokens is just more generally =
talking about whether GNAP should support an AS conveying how to use an =
access_token it produces during a flow with a =
client.


I think that these are separate issues =
as well.

 =E2=80=94 Justin

Thanks,
<=
/tbody>
3D"Mattr 
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr3D"Mattr3D"Mattr3D"Mattr

This communication, including any =
attachments, is confidential. If you are not the intended recipient, you =
should not read it - please contact me immediately, destroy it, and do =
not copy or use any part of this communication or disclose anything =
about it. Thank you. Please note that this communication does not =
designate an information system for the purposes of the Electronic =
Transactions Act 2002.


On Wed, Jun 24, 2020 at 10:14 PM Denis =
<denis.ietf@free.fr> wrote:
Justin, I fear we are still far away from an =
agreement about what this BoF should do.

Tom Jones is saying " I am getting =
tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it=E2=80=99=
s going to be overwhelmingly common that a given RS is going to trust =
exactly one AS 
that it knows about ahead of time". Such an =
architecture would have exactly the same limitations as OAuth 2.0. and =
would not be scalable.

Before we start, we should have a clear view =
of the whole picture rather than starting from one scenario and =
expanding it in many different directions.
For =
building an architecture, a pre-requirement is to define ALL the trust =
relationships. I don't believe that we have an agreement at this time on =
what 
these trust relationships are. 

You are also using the =
following wording: "methods for the AS and RS to communicate what the =
token=E2=80=99s good for". 
With such a =
paradigm, it would be impossible to protect the user's privacy. 

A key question is : Will =
GNAP take care of the user's privacy or will GNAP prevent to take care of the =
user's privacy ?

About "the ability for the client to get several access =
tokens to get different resources from one request" is indeed a complex =
case.

No one =
(including ASs) is able to predict in advance which access tokens will =
be needed, since they depend upon the kind of operation(s) 
the client =
will be willing to perform. For privacy reasons, ASs should be kept =
ignorant of all the operations that a client is going to perform 
on one or =
more resource servers. I believe that every effort should be made to =
avoid the AS to be in a position to be able to trace the operations 
performed by =
its clients on various RSs.

To handle the complex case you envision, the full workflow =
of operations needs to be considered with a detailed focus on the =
time 
at =
which the user's consent and choice happens (consent and choice is the first privacy =
principle from ISO 29100).

First of all, an access token could be targeted to a service =
rather than to a server. This would already solve many cases.

When a RS needs to call =
another RS (which does not support the same service) then the client =
should be informed by the first RS.
His "consent =
and choice" should then be obtained by the first RS and, when the user =
agrees, the client should then ask an access token 
to one of =
the ASs trusted by the second RS in order to perform the subsequent =
operation.  

Denis

PS.  In an email sent on June 23 you wrote: " I think an =
on-device AS is an important use case".  I am sorry, but I don't =
understand.
       However, =
I do understand what "a server-based AS" is.


Denis, thanks for =
the great comments. I think that your trust model is pretty different =
from what I=E2=80=99d laid out initially, and while it=E2=80=99s an =
interesting and important one, it is not what I meant by =E2=80=9Cmultiple=
 access tokens=E2=80=9D in my discussion below. I think that might be =
the cause of some disconnect here, but that doesn=E2=80=99t mean it=E2=80=99=
s out of reach for what the WG is after.

When I refer to multiple access tokens, =
and what the charter calls out as multiple access tokens, is the ability =
for the client to get several access tokens to get different resources =
from one request. I personally see this as an optimization of a specific =
set of use cases, some of which I discussed in my original email. There =
are others, I=E2=80=99m sure, but all the ones I=E2=80=99ve seen are =
around the client needing to get several different kinds of access =
through an AS. 

I think it=E2=80=99s going to be =
overwhelmingly common that a given RS is going to trust exactly one AS =
that it knows about ahead of time. But for RS=E2=80=99s that can trust =
multiple AS=E2=80=99s, then we should have a model that can accommodate =
that as well. That=E2=80=99s why the charter calls out methods for the =
AS and RS to communicate what the token=E2=80=99s good for. I think the =
basis of those methods is going to start with a common token model, and =
likely incorporate into things like token formats and =
introspection-style token APIs. 

 =E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the =
lines.

One of =
the most important aspects to GNAP is going to be an ability to address =
things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do without =
significant gymnastics. So with that, I wanted to bring back a use case =
discussion that originally came up while we were talking about the =
possibility of multiple access tokens, a few months back. I don=E2=80=99t =
know if this concept has a regular term, so I=E2=80=99m going to call it =
=E2=80=9Cdirected access tokens=E2=80=9D until we come up with something =
better =E2=80=94 assuming we decide this is worthwhile. 
I don't understand =
what may mean "directed access tokens=E2=80=9D but I understand what =
means "multiple access tokens". 
When speaking of "multiple access tokens", these access =
tokens may come from one or more ASs.
In OAuth, the client=E2=80=99s =
supposed to always know where to send its access token, and that =
knowledge is completely outside the protocol. This makes a lot of sense =
for many (if not most) deployments, as OAuth is really there to enable =
the API access that the client already knows about.

But we=E2=80=99re now in =
a world where a client could be talking to a generic API that could be =
deployed at a number of different places, or a cloud deployment that the =
AS wants to be able to dispatch the client to. 
As soon the AS is =
placed (again) at the centre of the model, the AS will have the ability =
to act as "Big Brother".
OAuth 2.0 has not taken care of =
privacy issues. On the contrary, GNAP should take care of =
them.
In order to =
do this, the AS needs to be able to communicate to the client not only =
the token information (and any related key and presentation =
information), but also a set of directions about what that specific token is good =
for. This needs to be information outside the token itself, since =
I believe we want to keep OAuth 2=E2=80=99s feature of having the =
token be opaque to the client. Note: while we could map all of these to =
different resource requests (in XYZ parlance) or scopes (in OAuth 2 =
legacy parlance) on the request side, this isn=E2=80=99t enough to tell =
the client what to do with the token if it doesn=E2=80=99t know already. 

I know of two use cases =
already in the wild, where people are addressing things using a mix of =
existing standards and some proprietary extensions to address things =
within their silos. I=E2=80=99ll try to summarize here, but I know the =
folks I=E2=80=99ve been talking to about this are also on the list so =
hopefully they can chime in with more detail or any corrections for =
something I=E2=80=99ve missed. 

(1) The client knows what resource =
it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s =
hosted. Everything is in a single security domain controlled by the =
AS, 
Speaking of "multiple =
access tokens" is in contradiction with single security domain =
"controlled" by an AS. 
A =
user may need to demonstrate some of his identity attributes granted =
e.g. by his bank but may also 
need to demonstrate one or more diplomas granted by one or =
more universities. The bank cannot be 
the "primary issuer" of a university diploma. It should not =
be either a "secondary issuer", because 
the bank does not "need to know" what are the diplomas of the user.
but the AS =
needs to decide at runtime which specific instance of the API to direct =
the client to. Since things are closely tied together, the client just =
needs to effectively known an identifier for the RS, and this is =
currently implemented as a URI. Once the client has that identifier, it =
knows how to dispatch that token to that instance of the =
RS.
There is no good reason why =
the AS should be involved in that step. 
OAuth 2.0 is/was implicitly mandating a strong relationship =
between ASs and RSs which makes it non scalable.
GNAP =
should be based on a simple trust relationship : a given RS trusts some =
ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time =
of an access token request) the RSs that are trusting it.
A client could first talk to a "global service =
provider" which has the knowledge of the different RSs affiliated to =
it. 
(2) The client knows what kind =
of thing it=E2=80=99s looking for, but doesn=E2=80=99t know who to ask =
it from. 
Once again, the =
client could first talk to a "global service provider" which has the =
knowledge of the different RSs affiliated to it. 
There=E2=80=99s a cross-domain trust that=E2=80=99s bridged =
by the AS, and the AS needs to dispatch to different resources depending =
on which user logged in (and possibly what the user consented to). To =
make things more concrete, the client needs to get driver=E2=80=99s =
license information, but doesn=E2=80=99t know ahead of time which of the =
many state/provincial bureaus to call to get that information because it =
doesn=E2=80=99t know yet who the user is. 
When a user has a =
driving license, he knows its issuer. The user can then provide some =
hint to the client.
The =
AS will know who the user is once they log in and approve things, and so =
it can direct the client to call the correct RS. Since this is a =
relatively simple API with a pre-negotiated cross-domain trust, the AS =
returns a URL that the client presents the token at. 
 A single AS =
should not be aware of all the attributes a user has. 

As far as I know, in =
both of these cases, the token is only good for that API and not others =
=E2=80=94 but more on that later.

A simple thing to do is just give back =
a URL with the access token, which tells the client where to =
go. 

	{
		=
=E2=80=9Caccess_token=E2=80=9D: {
			=
=E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
			=
=E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
		}
	=
}

This =
is good for some kinds of APIs, but it=E2=80=99s limiting because not =
all APIs dispatch based on the URL. An AS might want to divvy up access =
tokens to an API that=E2=80=99s keyed on headers, or verbs, or any =
number of things. And it doesn=E2=80=99t tell us immediately what to do =
about non-exact URL matches. Can the client add query parameters and =
still use the token? What about path segments? I like that this simple =
approach addresses some common deployments that we already see today =
(see above), it=E2=80=99s not universal. Do we want or need a universal =
description language for directing where tokens go?

This also opens up a =
whole new set of security questions. If the AS can now direct the client =
where to use the token, could a rogue AS convince a legit client to use =
a stolen token at the wrong RS? And what if the client ignores the =
directions from the AS entirely? Could this open up new avenues of =
attack?

This =
is just the start, too. Things get even more complex if the client can =
ask for multiple different kinds of resources at once. What if the AS =
decides that the client needs a hyper-focused directed token for one =
part of the API, but can use a general token for other stuff? Can it =
signal that to the client? And if it can, does that mean that all =
clients need to be prepared for that kind of thing?

I firmly believe that =
whatever we build in GNAP, we need to optimize for the overwhelmingly =
common use case of a client getting a single access token to call APIs =
that it already knows about. Anything we add on top of that really =
can=E2=80=99t get in the way of this, because if it does, there=E2=80=99s =
very small chance that people will try to use this for everyday things. =
Keep the simple things simple, and the complex things possible, after =
all.

I=E2=80=99m=
 really looking forward to hearing what the community thinks about these =
use cases, and hopefully the people I=E2=80=99ve chatted with offline =
about this can join the conversation and provide more light than I was =
able to.
The two use cases which are =
considered above are:
(1) The client =
knows what resource it=E2=80=99s calling, but it doesn=E2=80=99t know =
where it=E2=80=99s hosted.
(2) The client knows what kind =
of thing it=E2=80=99s looking for, but doesn=E2=80=99t know who to ask =
it from. 
That =
does not mean in any way that these two use cases should be solved by =
placing the AS at the centre of the solution.
Denis

 =E2=80=94 Justin


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

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

This =
communication, including any attachments, is confidential. If you are =
not the intended recipient, you should not read it - please contact me =
immediately, destroy it, and do not copy or use any part of this =
communication or disclose anything about it. Thank you. Please note that =
this communication does not designate an information system for the =
purposes of the Electronic Transactions Act =
2002.

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

=

--Apple-Mail=_2EC0B3C3-DF0A-4896-ADD2-3A8885D9C3D1--


From nobody Tue Jul  7 16:21: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 375C03A0BFD; Tue,  7 Jul 2020 16:21: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 i2prhgd7zULh; Tue,  7 Jul 2020 16:21:22 -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 313E03A0BFC; Tue,  7 Jul 2020 16:21:22 -0700 (PDT)
Received: by mail-lj1-x241.google.com with SMTP id h19so52055780ljg.13; Tue, 07 Jul 2020 16:21: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=zOtzxTmSyM1BxkBK2IaIVT0hpnvbWiSUcYaVsdQ8hsQ=; b=bO7aWBFGdsRrIdI8s9r15nID5tMP79yhnrotKC9iUCUWPPmVyk6fkkd0swn6V7SZ/D hC1JGBcuLzj7BJzGYpeedwbxoPMCGtKlPNas4zuQKS5vDwb7TB6RJH8IxgkaYJ9xa3lX nBgK+u7ng41L40TP8eI18RjC4taINcxrhnzwp47EgdE5sHrc0Sk+zyNrbfFzGsRnnrvm 4LZiDR0DdERKzyB49+0SM7W7qKpMhEeKU8dMAiARatdWr3SRPviUcMQP+qyVRWyuQGuo 1jNdZitO9TCB7nEUVeQSOPWIFKn8eEOgfF1lK1D+b4UZaYRkBAgS0cSCAGm0ZWRnXkzq Relg==
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=zOtzxTmSyM1BxkBK2IaIVT0hpnvbWiSUcYaVsdQ8hsQ=; b=uMThESsNPpbAfB0RNWcd5MYQtiOFkHdPn2qgCnkJiU71llkCdNnfGciDHJ+zAke1W1 R6v81LEtSmI4MjXtOe/vmzCxduXexNcO+rq4XLxN7uQrAruexJxHzYNAc9ImW1QE05JH UxoZnKw3KWDxsmJ0P5Mw/SIldD0ANNs/u4+Dj6TwENnalMuOkzRfYeJCXHN+xiw07xyf 8kHy23xyDTXvf0u20LxCKFOOUx8M0ck79V+MnIE5XpV2i03WhMGMKr86FKVCGqD39q5g wG8zKTCStXzuzb3Oi2mrg+xIo9GRBI6AzOSnmxjx+V76BiU1bZFwVAPg9zGFqs4XhG1N xjrQ==
X-Gm-Message-State: AOAM530DgaUumVGNlRSBdicRsrOl2Vqx+IDkObAZ595JVsShUO7/zPQc qpgGvGNo+d/fDMbe6EghQ+D1F3XjTbY7iURnGg8=
X-Google-Smtp-Source: ABdhPJyzPBj0mmVmwWsVyB+1iojH9YIHeP8CMLK8WMx9YogkZw2oml7FQHKQURdlpGe99yurIU8DMxgpftzajoe1uPU=
X-Received: by 2002:a2e:8316:: with SMTP id a22mr8408507ljh.246.1594164080040;  Tue, 07 Jul 2020 16:21:20 -0700 (PDT)
MIME-Version: 1.0
References: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>   <46705E7E-D657-4CF1-80DA-0ADDFD6D8B41@mit.edu> <85b03911-d1c6-127f-2480-bfab4b94ffe2@free.fr>
In-Reply-To: <85b03911-d1c6-127f-2480-bfab4b94ffe2@free.fr>
From: Dick Hardt 
Date: Tue, 7 Jul 2020 16:20:43 -0700
Message-ID: 
To: Denis 
Cc: Justin Richer , "rdd@cert.org" , "txauth@ietf.org" , The IESG 
Content-Type: multipart/alternative; boundary="000000000000b45f6905a9e23f03"
Archived-At: 
Subject: Re: [Txauth] Support of FIDO and data minimization by RSs
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, 07 Jul 2020 23:21:25 -0000

--000000000000b45f6905a9e23f03
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Denis: you seem to keep implying that other architectures don't preserve
privacy. A couple counterpoints:

Token opacity helps privacy in another dimension -- the client does not see
the information about the user.

Many OAuth developments have self contained tokens. There is no token
introspection call. This, coupled with opaque tokens, is more privacy
preserving than the client being able to peek in a token.

=E1=90=A7

On Tue, Jul 7, 2020 at 5:26 AM Denis  wrote:

> Hi Justin,
>
> I think removing the opacity of access tokens to clients is going to be a
> non-starter for most of this community.
>
> Token opacity is considered as a dogma in OAuth 2.0. More explanations wh=
y
> access tokens should not be opaque in GNAP.
>
> Token introspection mandates a dialogue from the RS to the AS which allow=
s
> the AS to know which RS
> got a given access token. So token introspection allows the AS to trace
> the client. This should be avoided.
> Using NON-OPAQUE access tokens solves the issue both for the RSs and for
> the clients. This means that
> access tokens used for GNAP shall include a version number or a format
> identifier.
>
> Applying a "security by design" approach leads to specific design
> requirements. The key question is whether
> this BoF prefers a "Privacy by design" approach or *implicitly *a "Big
> Brother by design" approach.
>
> Denis
>
>
>  =E2=80=94 Justin
>
> On Jul 6, 2020, at 3:17 PM, Denis  wrote:
>
> Hi Dick,
>
> Congratulations ! You made a good guess (but the guess was easy): my
> approach is indeed privacy related.
>
> *Note*: Since it is close to the end of the day in my time zone (and
> since it is the last day for comments to the charter),
> I copy both the IESG and Roman so that they can know that GNAP should als=
o
> consider a* bridge with FIDO*.
>
> I have several goals:
>
> 1 - make a bridge with FIDO U2F (I will illustrate this with a specific
> scenario).
>
> 2 - prevent every AS to know which RSs are going to be accessed or which
> kind of operation the client will be doing.
>     This is to prevent an AS to act as "Big Brother".
>
> 3 - apply both "privacy by default" and "data minimization" (when the use=
r
> authenticates it may authenticate using FIDO or
>      by presenting one or more access tokens. Then after, the necessary
> attributes that are necessary to perform a given operation
>     are only requested and released at the time they are indeed needed to
> perform the given operation (i.e. they are not released
>     when the user logs on).
>
> 4 - the proposed RS Authorization algorithm allows a great flexibility, i=
n
> particular it supports FIDO and different attributes
>      from different ASs may be requested by the RS.
>
> 5 - the rules associated with the RS Authorization algorithm are making
> these rules only available at the time the client indicates
>      which operation it is willing to perform (i.e. by default, they are
> not public).
>
> 6 - access tokens are NOT OPAQUE to the clients so that every client can
> make sure that their content reflects what has been requested.
>
> *A simple scenario to illustrate*
>
> A student wants to apply for a new university. He connects to the RS of
> the University. He first creates an account using FIDO.
> He then selects the button "Preliminary information for applying to the
> university". He is asked to enter two categories of information:
>
>
>    - citizenship information and
>    - prior graduations.
>
> The student can interrupt the preliminary registration procedure at any
> time and continue it at any time later on.
>
> When the student is finished, it selects the button "Application to the
> university".
>
> The university RS "reads" the citizen ship of the student and let know to
> the student whether a paper form
> and/or an electronic form of the identity of the student may be provided.
> Let us assume the later case and that
> the student is a citizen from France. Then the university RS indicates
> which French banks or other French organisations
> are trusted to provide an access token. The client checks whether this
> list fits one of the AS with which it has a relationship.
>
> The university RS "reads" the prior graduations of the student and then
> let know to the student whether a paper form
> and/or an electronic form of the last graduation of the student may be
> provided. Let us assume the later case and
> that the student is from Yale University. Then the university indicates
> the address of the AS from Yale University.
> If the student is indeed from Yale University, he should be able to
> provide the requested access token.
>
> Such scenario which follows some privacy principles cannot be constructed=
 "*after
> the design"* (it will not happen by magic or by accident)
> This is why the approach is called "privacy by design".
>
> Denis
>
> Hi Denis
>
> Would you provide some background on what you are trying to solve with
> this? I'm guessing it is privacy related.
>
> Perhaps a use case would help make it more concrete?
>
> /Dick
>
>
> On Mon, Jul 6, 2020 at 5:39 AM Denis  wrote:
>
>> eThis is a new thread: a proposal for a RS authorization algorithm and a
>> way to support FIDO by RSs
>>
>> In order to support the privacy principle of "data minimization" by RSs,
>> only the attributes that are strictly necessary to perform
>> an operation requested by a client should be requested by the RS.
>>
>> When a client wants to authenticate, it will usually be informed by the
>> RS on how to do it (see more details about two exceptions at the end of
>> this email).
>> Which conditions are needed to perform other operations will only be
>> disclosed to authenticated users at the time they are willing to perform=
 an
>> operation.
>>
>> Two categories of operations will be considered: authentication
>> operations and other operations.
>>
>> For the "authentication" operation, two cases will be supported:
>>
>> -          FIDO U2F or
>>
>> -          one or more attributes from one or more ASs.
>>
>> In the second case, an access will be granted by a RS based on an
>> mathematical expression which is formed using some combination of AND an=
d
>> 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 *a Condition *:
>>
>> *Condition x* =3D { AS identifier + set of attributes types + optional
>> scope identifier }
>>
>> The presence of the *optional* scope identifier allows to provide a
>> backward compatibility with ASs from the OAuth 2.0. world:
>> the optional scope identifier is only present when a bilateral
>> relationship has been established between a RS and an AS prior
>> to any access (*and will continue to be maintained*) using
>> "out-of-bands" means.
>>
>> 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 condi=
tions.
>>
>> An example is used to explain the concepts.
>>
>> "Operation(s)/ Mathematical expression" pairs managed by the RO of a RS.
>>
>> *Operation*
>>
>> *Mathematical expression*
>>
>> Authentication
>>
>> *Condition 1* OR *Condition 2*
>>
>> Operation A OR Operation Z
>>
>> *Condition 3* AND *Condition 4*
>>
>> Conditions table:
>>
>> Condition 1
>>
>> FIDO U2F 1.2
>>
>> -
>>
>> -
>>
>> Condition 2
>>
>> AS 1
>>
>> set 1 of attributes types
>>
>>
>> Condition 3
>>
>> AS 4
>>
>> set 2 of attributes types
>>
>> scope identifier : 21
>>
>> Condition 4
>>
>> AS 9
>>
>> set 3 of attributes types
>>
>> -
>>
>> 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
>> the set of attributes types which are indicated for a given AS
>> are appropriate to him or not and then select that AS if it has a
>> relationship with it.
>>
>> In this example, one mathematical expression for the combination of
>> conditions using AND and OR operators is "*Condition 3* OR *Condition
>> 4",*
>> * which means that* some types of attributes from AS 4 AND some other
>> types of attributes from AS 9 are both needed by RSx to perform on RSx
>> either the Operation A or the Operation Z.
>>
>> In this example, RS 1 and AS 4 have established a bilateral relationship
>> (and have agreed to define and use scope identifiers)
>> whereas RS 1 and AS 9 have not established any bilateral relationship
>> prior to the exchange.
>>
>> The user makes up his mind whether the attributes requested by AS 1 and
>> AS 9 are reasonable and if so, requests two access tokens:
>> one to AS 4 and another one to AS 9.
>>
>> For AS 4, the client shall use the scope identifier with the value 21.
>> For AS 9, the client shall use the set 3 of attributes types indicated i=
n
>> the Condition 4.
>>
>> In order to save one exchange, a RS could publicly publish how its
>> clients can authenticate.
>> However,  it is also possible to consider no guidance at all: in such a
>> case, using "out-of-bands" means, the clients should know how to
>> authenticate.
>>
>> 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
>
>
>
>

--000000000000b45f6905a9e23f03
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Denis: you seem to keep implying that other architectures =
don't preserve privacy. A couple counterpoints:

Toke=
n opacity helps privacy in another dimension -- the client does not see the=
 information about the user.

Many OAuth developments hav=
e self contained tokens. There is no token introspection=C2=A0call. This, c=
oupled with opaque tokens, is more privacy preserving than the client being=
 able to peek in a token.

3D""=E1=90=
=A7

On Tue, Jul 7, 2020 at 5:26 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hi Justin,

    


    

    

     =20
      I think removing the opacity of access tokens to clients is going
      to be a non-starter for most of this community. 

    

    
Token opacity is considered as a dogma in OAuth 2.0. More
      explanations why access tokens should not be opaque in GNAP.

    

    
Token introspection mandates a dialogue from the RS to the AS
      which allows the AS to know which RS 

      got a given access token. So token introspection allows the AS to
      trace the client. This should be avoided.

      Using NON-OPAQUE access tokens solves the issue both for the RSs
      and for the clients. This means that 

      access tokens used for GNAP shall include a version number or a
      format identifier.

    

    
Applying a "security by design" approach leads to specific=
 design
      requirements. The key question is whether 

      this BoF prefers a "Privacy by design" approach or impli=
citly
      a "Big Brother by design" approach.

    

    
Denis

    

      


      

      
=C2=A0=E2=80=94 Justin

        


          

            
On Jul 6, 2020, at 3:17 PM, Denis <denis.ietf@free.fr> wrote:

            

            

             =20
              

                
Hi Dick,

                


                

                
Congratulations ! You made
                  a good guess (but the guess was easy): my approach is
                  indeed privacy related.

                


                

                
Note: Since
                  it is close to the end of the day in my time zone (and
                  since it is the last day for comments to the charter),
                  

                  I copy both the IESG and Roman so that they can know
                  that GNAP should also consider a bridge
                    with FIDO.

                

                
I have several goals:

                

                  
1 - make a bridge with
                    FIDO U2F (I will illustrate this with a specific
                    scenario).

                  


                  

                  
2 - prevent every AS to
                    know which RSs are going to be accessed or which
                    kind of operation the client will be doing.

                    =C2=A0=C2=A0=C2=A0 This is to prevent an AS to act as &=
quot;Big
                    Brother".

                  

                  


                  

                  
3 - apply both "privacy
                    by default" and "data minimization" (whe=
n the user
                    authenticates it may authenticate using FIDO or 

                    =C2=A0 =C2=A0=C2=A0 by presenting one or more access to=
kens. Then
                    after, the necessary attributes that are necessary
                    to perform a given operation 

                    =C2=A0=C2=A0=C2=A0 are only requested and released at t=
he time they
                    are indeed needed to perform the given operation
                    (i.e. they are not released 

                    =C2=A0 =C2=A0 when the user logs on).

                  


                  

                  
4 - the proposed RS
                    Authorization algorithm allows a great flexibility,
                    in particular it supports FIDO and different
                    attributes 

                    =C2=A0=C2=A0=C2=A0=C2=A0 from different ASs may be requ=
ested by the RS.

                  


                  

                  
5 - the rules associated
                    with the RS Authorization algorithm are making these
                    rules only available at the time the client
                    indicates 

                    =C2=A0 =C2=A0=C2=A0 which operation it is willing to pe=
rform (i.e.
                    by default, they are not public).

                  


                  

                  
6 - access tokens are NOT
                    OPAQUE to the clients so that every client can make
                    sure that their content reflects what has been
                    requested.

                  

                

                
 A simple
                    scenario to illustrate

                

                


                

                
A student wants to apply
                  for a new university. He connects to the RS of the
                  University. He first creates an account using FIDO.

                  He then selects the button "Preliminary information
                  for applying to the university". He is asked to ente=
r
                  two categories of information:

                

                  
    
                    
  • citizenship information and 
    • 
                    
  • prior graduations.
    • 
                  

                

                
The student can interrupt
                  the preliminary registration procedure at any time and
                  continue it at any time later on.

                


                

                
When the student is
                  finished, it selects the button "Application to the
                  university".

                

                

                  
The university RS "reads"
                    the citizen ship of the student and let know to the
                    student whether a paper form 

                    and/or an electronic form of the identity of the
                    student may be provided. Let us assume the later
                    case and that 

                    the student is a citizen from France. Then the
                    university RS indicates which French banks or other
                    French organisations 

                    are trusted to provide an access token. The client
                    checks whether this list fits one of the AS with
                    which it has a relationship.

                  

                  


                  

                  The university RS "reads" the prior graduations=
 of the
                  student and then let know to the student whether a
                  paper form 

                  and/or an electronic form of the last graduation of
                  the student may be provided. Let us assume the later
                  case and 

                  that the student is from Yale University. Then the
                  university indicates the address of the AS from Yale
                  University.

                  If the student is indeed from Yale University, he
                  should be able to provide the requested access token.

                

                
Such scenario which follows some privacy
                  principles cannot be constructed "after
                    the design" (it will not happen by magic or by
                  accident)

                  This is why the approach is called "privacy by
                  design".

                
Denis

                

                

                  
Hi Denis
                    


                    

                    
Would you provide some background on
                      what you are trying to solve with this? I'm
                      guessing it is privacy related.=C2=A0

                    


                    

                    
Perhaps a use case would help make it
                      more concrete?

                    


                    

                    
/Dick

                    


                    

                  

                  

                  

                    
On Mon, Jul 6,
                      2020 at 5:39 AM Denis <denis.ietf@free.fr>
                      wrote:

                    

                    

                      

                        
 eThis is a new thread: a
                            proposal for a RS authorization algorithm and a way to support FID=
O by
                            RSs

                          

                        
In order to support the privacy
                            principle of "data minimization" by R=
Ss,
                            only the attributes that are strictly
                            necessary to perform 

                            an operation requested by a client should be
                            requested by the RS.

                        
When a client wants to
                            authenticate, it will usually be informed by
                            the RS on how to do it (see more details
                            about two exceptions at the end of this
                            email). 

                            Which conditions are needed to perform other
                            operations will only be disclosed to
                            authenticated users at the time they are
                            willing to perform an operation.

                        
Two categories of operations
                            will be considered: authentication
                            operations and other operations.

                          

                        
 For the "authentication"
                            operation, two cases will be supported: =


                        
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0
                            FIDO U2F or 

                        
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0
                            one or more attributes from one
                            or more ASs. 

                        
In the second case, an access
                            will be granted by a RS based on an
                            mathematical expression which is formed
                            using some combination of AND and OR co=
nditions. 

                        
Examples of combinations:

                        

                          
Condition
                                1 AND Condition 2

                                Condition 1 OR Con=
dition
                                2

                            (Condition 1=
 AND Condition
                                2) OR Condition 3

                                (Condition 1 OR =
Condition
                                2) AND Condition 3 

                            

                        

                        
The following notation is being
                            used for a Condition :

                        
Condition x =3D { AS identifier + set of
                            attributes types + optional scope identifier
                            } 

                          

                        
The presence of the optional scope identifier
                            allows to provide a backward compatibility
                            with ASs from the OAuth 2.0. world: 

                            the optional scope identifier is only
                            present when a bilateral relationship has
                            been established between a RS and an AS
                            prior 

                            to any access (and will continue
                              to be maintained) using "out-of-band=
s"
                            means. 

                          

                        
Each RS internally constructs
                            an authorization table with
                            the following content:

                        
1=C2=B0=
=C2=A0 For
                            the "authentication" operation : eith=
er FIDO
                          U2F or a mathematical expre=
ssion
                            using conditions;

                        
2=C2=B0=
=C2=A0 For
                            any other operation : a mathematical
                            expression using conditions.

                        
An example is used to explain
                            the concepts.

                        
"Operation(s)/ Mathematical
                            expression" pairs managed by the RO of a R=
S.
                            

                          

                        

                          
                            

                              
                                
Operation

                              		
                              
                                
Mathematical
                                      expression

                              		
                            

                            

                              
                                
Authentication

                              		
                              
                                
Condition 1 OR Condition
                                      2

                              		
                            

                            

                              
                                
Operation A OR
                                      Operation Z

                              		
                              
                                
Condition 3 AND Condition
                                      4

                              		
                            

                          
                        

                        
=
Conditions table: <=
/p>
                        

                          
                            

                              
                                
Condition 1

                              		
                              
                                
FIDO
                                    U2F 1.2

                              		
                              
                                
-=


                              		
                              
                                
-=


                              		
                            

                            

                              
                                
Condition 2

                              		
                              
                                
AS 1

                              		
                              
                                
set 1 of attributes
                                    types

                              		
                              
                                
=C2=A0

                                

                              		
                            

                            

                              
                                
Condition 3

                              		
                              
                                
AS 4

                              		
                              
                                
set 2 of attributes
                                    types

                              		
                              
                                
scope identifier : 21

                              		
                            

                            

                              
                                
Condition 4

                              		
                              
                                
AS 9

                              		
                              
                                
set 3 of attributes
                                    types

                              		
                              
                                
-=


                              		
                            

                          
                        

                        
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 the set of attributes types
                            which are indicated for a given AS 

                            are appropriate to him or not and then
                            select that AS if it has a relationship with
                            it.

                        
In this example, one
                            mathematical expression for the combination
                            of conditions using AND and OR operators is
                            "Condition
                                3 OR Condition
                                4", 

                                which means that
                            some types of attributes from AS 4 AND
                            some other types of attributes from AS 9 are
                            both needed by RSx to perform on RSx 

                            either the Operation A or the Operation Z. 

                        
In this example, RS 1 and AS 4
                            have established a bilateral relationship
                            (and have agreed to define and use scope
                            identifiers) 

                            whereas RS 1 and AS 9 have not established
                            any bilateral relationship prior to the
                            exchange. 

                          

                        
The user makes up his mind
                            whether the attributes requested by AS 1 and
                            AS 9 are reasonable and if so, requests two
                            access tokens: 

                            one to AS 4 and another one to AS 9.

                        
For AS 4, the
                            client shall use the scope identifier with
                            the value 21.

                            For AS 9, the client shall use the set 3 of
                            attributes types indicated in the Condition
                            4.

                        
In order to save one exchange,
                            a RS could publicly publish how its clients
                            can authenticate. 

                            However,=C2=A0 it is also possible to consider =
no
                            guidance at all: in such a case, using
                            "out-of-bands" means, the clients sho=
uld
                            know how to authenticate.

                        
Denis 

                          

                      

                      -- 

                      Txauth mailing list

                      =
Txauth@ietf.org

                      https://www.ietf.org/mailman/listi=
nfo/txauth

                    

                  

                

                


                

              

              -- 

              Txauth mailing list

              Txauth@i=
etf.org

              https://www.ietf.org/mailman/listinfo/txauth

            

          

        

        

      

    

    


    

  





--000000000000b45f6905a9e23f03--


From nobody Tue Jul  7 16:31: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 F021D3A0C0E for ; Tue,  7 Jul 2020 16:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.682
X-Spam-Level: 
X-Spam-Status: No, score=-0.682 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_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 w8Sv6S2t5L30 for ; Tue,  7 Jul 2020 16:31:33 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 6A66B3A0C0F for ; Tue,  7 Jul 2020 16:31:33 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id r19so991596ljn.12 for ; Tue, 07 Jul 2020 16:31: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=Fzgkyc6DOWBNJZ16NldC+afVlAs/SjXcgKh0lTd1Gyw=; b=eKNQG+J9jYztA2BFRMOq8FaqDDnmA8Sz4sU1sn1fCB8Tp2BZbHDc/iLXpd9LipUxIS aOqvnGedQl6O2gwnCf/PAMTvndFqxVmXvQgXEE7w40H9cmmXahaAqY4SP9DvUUbGhrli 6UWvkTuvzwsPrQeRaWqvFpavm1FJ/wkGFYCQRMmRYqggo1zl/xanCYe1T7XJkBuD49Za 7+nBV+lEn5YIX7l8M7VlYFnMdcCUe0jp/Tn/KSn+TVsCoqCrCp5fQbz/wdULsdySX46x DJQTUQQpQA2WZQRkD9bCV59EucFVZD6ddsINjGj9q/ip8uTLrmCnKJ35c0xysuTZHgiL ptLA==
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=Fzgkyc6DOWBNJZ16NldC+afVlAs/SjXcgKh0lTd1Gyw=; b=KceNvSw7jRApy4rLpZywOaurdo0j+s4vmM1CbBT88+wFZXHe3thvC+1//wY3WxNsKy PRb6ezWsD+OHFntO+B8Ja6Bfe+XgBoZne61x+OLQhyNrWqIXjmcgFeQ/VY/Ip8MiN93c Pakgxgs0KB7nrLHXeNTmkOJwIE9spyXqYSzFBzPb1G+t/mYD1YbqyPnbb9ETWDocx7pX IVQddi7N9DFpzMCqP9M0CLz6GU9smQYaJo55zZ3QjWNW9a/NPgJoorZDlBq6Qzg4xpEi D7Vrp/6jQ34nQ4002h6QAxF6dqN9b4emktRsh2iqJJ5JIaOw8yqcu3rBbjxS5nGFJJ4L 2xpA==
X-Gm-Message-State: AOAM532VeP+omnT6gAB0l4ErzZxKV59f4hxBTetbGce/i1CoYAwOEXn8 rkCHCATJkpW0sjESmXPoZ1bG7RJE1rcp5KaKH/3qacWYFXU=
X-Google-Smtp-Source: ABdhPJxSZPgt/TZJBanyT8OKZe7LgYQbSUW9jKA9Vky16LDDAZUjfVYu68wGtaEFBqRR0mjj/MrGWsqRBK+/LhROdLU=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr20099339ljh.110.1594164691352;  Tue, 07 Jul 2020 16:31:31 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>
In-Reply-To: <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>
From: Dick Hardt 
Date: Tue, 7 Jul 2020 16:30:55 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000243f2005a9e264c9"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 07 Jul 2020 23:31:35 -0000

--000000000000243f2005a9e264c9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 7, 2020 at 3:40 AM Justin Richer  wrote:

> I wanted to respond to this comment more fully:
>
> > wrt. my authorization / authorizations oddness, polymorphism would not
> solve it as the contents of both authorization / authorizations in XAuth
> are objects.
>
> It=E2=80=99s not surprising that this is the case, as the XAuth protocol =
was not
> designed with polymorphism as a tool to consider. This is exactly the
> reason that I say we should have polymorphism in the toolbox from the
> start, as it allows us to avoid this kind of awkwardness in many cases.
>

 What evidence do you have to make this statement? "XAuth protocol was not
designed with polymorphism as a tool to consider"

It sounds like you are saying I did not consider polymorphism in the XAuth
protocol design.

I will restate my comment above about polymorphism.

Using different JSON types does not solve the problem, but as I suggest in
my comments, polymorphism of different JSON objects is one solution. An
authorization, or a dictionary of authorizations. It has the restriction
that the string "type" cannot be used as a label in the dictionary. An
example:

{
    "authorizations" {
        "type": "oauth_scope",
        "scope": "read write"
    }
}

{
    "authorizations" {
        "reader": {
            "type": "oauth_scope",
            "scope": "read"
        },
        "writer": {
            "type": "oauth_scope",
            "scope": "write"
        },
    }
}


I am looking at making this change in XAuth and in the implementation.



=E1=90=A7

--000000000000243f2005a9e264c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Jul 7, 2020 at 3:40 AM Justin=
 Richer <jricher@mit.edu> wrot=
e:
I wanted to r=
espond to this comment more fully:



> wrt. my authorization / authorizations oddness, polymorphism would not=
 solve it as the contents of both authorization / authorizations in XAuth a=
re objects. 



It=E2=80=99s not surprising that this is the case, as the XAuth protocol wa=
s not designed with polymorphism as a tool to consider. This is exactly the=
 reason that I say we should have polymorphism in the toolbox from the star=
t, as it allows us to avoid this kind of awkwardness in many cases.

=C2=A0What evidence do you have to make this s=
tatement? "XAuth protocol was not designed with polymorphism as a tool=
 to consider"

It sounds like you are sayi=
ng I did not consider polymorphism in the XAuth protocol design.
=

I will restate my comment above about polymorphism.=C2=A0

Using different JSON types does not solve the proble=
m, but as I suggest in my comments, polymorphism of different JSON objects =
is one solution. An authorization, or a dictionary of authorizations. It ha=
s the restriction that the string "type" cannot be used as a labe=
l in the dictionary. An example:

{
=C2=A0 =C2=
=A0 "authorizations" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type&=
quot;: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope&=
quot;: "read write"
=C2=A0 =C2=A0 }
}

{
=C2=A0 =
=C2=A0 "authorizations" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "re=
ader": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type"=
: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu=
ot;scope": "read"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "writer": {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "type": "oauth_scope",
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": "write"
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 }
}


I am looking at making this change in XAuth and in the=
 implementation.



3D""=E1=90=A7


--000000000000243f2005a9e264c9--


From nobody Tue Jul  7 17:01: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 6AFD43A0C87 for ; Tue,  7 Jul 2020 17:01:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=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=mattr-global.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 Bg7vP-ADWgt6 for ; Tue,  7 Jul 2020 17:01:23 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 073943A0C81 for ; Tue,  7 Jul 2020 17:01:22 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id e13so39933994qkg.5 for ; Tue, 07 Jul 2020 17:01:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattr-global.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GaSEsmjeauVl9gaFR6wddbOzFZbplg0xsUdnpH8mPzg=; b=PzXSccETxee6t6W1NUw7SMqnAn3Im2TALGAsbcuZAbMmU1TZ9reBMGRyl27n+7v3LN ZdOQdWwlJVt2M0iQCO05JjNV5KVk2/c6+/lvJc9FqShg0GAhgqACFcwCxdK3Tz6ORirz 8quvKL5asbZRhZDUsD3Ymduv/Mo65Qac79cgdEIbdiYnpJNYOlPS2YFd6jevFfyFpPBb RkMVLvQqAGJXTbOfJ9K0fcaYWymm/HkoyZL7YvFchB1hYAhqrQA5DdekyCdT56eVNSOR 2mRnL7UbPZYvh0znQOt3zQZn57LFHQ9XvgW8XXFEydmcLA/RnqMlMZEppmku0A+QtKV5 eZVg==
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=GaSEsmjeauVl9gaFR6wddbOzFZbplg0xsUdnpH8mPzg=; b=HsmZRzM44Kov/N8O89kqiZC5B0KE4twxdK4jwfwDDYWUsk1kgDHndp+DW7nzlqfYTF A1w9tiaXmKDdXEY4d8K9aJwOb0Kfni+UOs9C1REf307bdCqbmTZWggvQWrK91pnVBDGJ +i7MQ+ps+eNywpBbZ3IfkA8N4odsVRlw3hV8K6Ot9CHEUgc+fnEKOYA3Yep88102sZFn r1t/sLoIAqXEX26gfzLMfc/RxqBD0OfJy3o/lukeNxQRpbd4dAoHaTxZMRWhOyStChrl uj03gd9G80H152otLeyfwVSiFMtq1tefBRnUBRSPZoo+gWXibW93m7DoNUJJzMI52/x/ Oywg==
X-Gm-Message-State: AOAM532jHTb5sYSRaD/x7RM8XhlwNDij6nvpu7h+1mXADmub02aaQPhl QwgQBM6fn7xytwkbJZEeH9IHUvTepXw6xeeQPDa/mfGFcyVJ9LN1WrtcgrbBRkGWuCtkM4gtD8o cpQp0OV+Eum8zKo2k8Q==
X-Google-Smtp-Source: ABdhPJzMJchkYUUm0ZovyOl3MBeoUBPt4qkn0IsHMw9RjAXro9uRPXVenUys9R7I6Was/2ul1nFGt3GOnmo6Z74VuRc=
X-Received: by 2002:a37:9f10:: with SMTP id i16mr50262494qke.15.1594166481784;  Tue, 07 Jul 2020 17:01:21 -0700 (PDT)
MIME-Version: 1.0
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <6846D2F0-5096-404B-A529-676146392F45@mit.edu>
In-Reply-To: <6846D2F0-5096-404B-A529-676146392F45@mit.edu>
From: Tobias Looker 
Date: Wed, 8 Jul 2020 12:01:10 +1200
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000dc259605a9e2ce02"
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 08 Jul 2020 00:01:28 -0000

--000000000000dc259605a9e2ce02
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I've also been thinking about the parallels between ZCAP's and OAuth2.0
access tokens. To me a ZCAP is a less opaque, semantically richer
capability format, whereas an access_token is traditionally much simpler.
The key here though is I still see an access_token as a form of capability.
It appears in general one of the trade offs we will be faced with is either=
:

1. Keeping the capability received from a GNAP flow (e.g an access_token)
opaque to the client and externalizing any greater information about how to
use the capability (such as in your proposal in the first email of this
thread).
2. Internalizing information about the capabilities utility and any greater
context about it which means the capability is no longer opaque.

With that aside, the notable features in general I would like GNAP to
consider from ZCAP's, are the following.

- Delegatable capabilities (bonus if this mechanism includes the ability to
attenuate during delegation) - Consider the example where a client or RP
(RP1) receives some form of access_token (capability) from an AS and would
like to delegate this to another RP (RP2) so they can access the same
resources. If including attenuation this would mean that during this
delegation (RP1->RP2), RP1 could narrow the scope of the original access it
received so that RP2 only gets a subset of the original scope.
- Bound capabilities - Similar in some ways to dPop, essentially
establishing the ability to bind an access_token (capability) to the party
that should be able to use it (invoker). I see this as a must have in order
to be able to do attenuated delegation as described above.

Thanks,
[image: Mattr website] 
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
[image: Mattr website]  [image: Mattr on LinkedIn]
 [image: Mattr on Twitter]
 [image: Mattr on Github]

This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this
communication or disclose anything about it. Thank you. Please note that
this communication does not designate an information system for the
purposes of the Electronic Transactions Act 2002.


On Wed, Jul 8, 2020 at 8:39 AM Justin Richer  wrote:

> I=E2=80=99ve been thinking more about these use cases, and it might help =
us to
> think of GNAP=E2=80=99s access tokens as capabilities in the computer sec=
urity
> sense =E2=80=94 but more specifically, capabilities that are delivered wi=
th their
> own context for use. In that way, an otherwise naive client can be handed
> an access token and simply know exactly what to do with it. This context
> would be delivered alongside the token, so the token material itself
> remains opaque to the client.
>
> I wanted to bring up a W3C spec for a capabilities model based on linked
> data:
>
> https://w3c-ccg.github.io/zcap-ld/
>
> Building a fully featured capabilities context is difficult, at the very
> least. And unfortunately, I don=E2=80=99t think this spec actually gives =
us any
> viable solutions to work with. In particular the =E2=80=9Cactions=E2=80=
=9D section is
> effectively blank, offloading the work to an external JSONLD process (sid=
e
> note, this is one of the problems I have with specs based on JSONLD, they
> externalize the important parts into local contexts and break
> interoperability =E2=80=94 but I digress). But at least it=E2=80=99s anot=
her way of looking
> at the problem space that might be outside the familiar zone of many of t=
he
> OAuth world.
>
>  =E2=80=94 Justin
>
> On Jun 26, 2020, at 9:23 AM, Justin Richer  wrote:
>
> On Jun 25, 2020, at 9:07 PM, Tobias Looker 
> wrote:
>
>
> I find this feature interesting and think it could be an important patter=
n
> going forward to enable an AS to be able to describe the utility of a tok=
en
> to the client, however as already pointed out in the thread I think there
> is some potential hidden complexity that would need to be ironed out such
> that it does not make the simple things complicated.
>
> Justin, do you see this feature as something the client has to explicitly
> request, i.e "please give me access and instructions on how to use my
> access" or rather that the AS would just return this information in
> conjunction with the access token if it had it available?
>
>
> This is something that I=E2=80=99d brought up as a possibility on the pre=
vious
> thread =E2=80=94 something like a flag the client would set. This would b=
e
> especially important if the AS wants to return multiple access tokens but
> the client requested 1, or the client requested N and the AS wants to
> return M in response. Basically any time there=E2=80=99s a mismatch, that=
=E2=80=99s extra
> complexity on the client that I really don=E2=80=99t think we want to be =
universal.
> A flag to turn that kind of direction and splitting on would be a potenti=
al
> start. But there are potential snags here too, and it comes down to how y=
ou
> manage the defaults...
>
> > This is just the start, too. Things get even more complex if the client
> can ask for multiple different kinds of resources at once. What if the AS
> decides that the client needs a hyper-focused directed token for one part
> of the API, but can use a general token for other stuff? Can it signal th=
at
> to the client? And if it can, does that mean that all clients need to be
> prepared for that kind of thing?
>
> Would a potential default be that if a client did for any reason not
> support processing the additional information returned with the
> access_token, just to ignore it? I think in the spirit of keeping the
> simple things simple, this potentially makes sense?
>
>
> That=E2=80=99s the real trick, if you ask me. It has to be :safe: for a c=
lient to
> ignore this information. Which means the AS can=E2=80=99t rely on the cli=
ent =E2=80=9Cdoing
> the right thing=E2=80=9D with the information in the =E2=80=9Ctoken direc=
tions=E2=80=9D portion of
> the response. Even setting aside the advanced and related =E2=80=9Csplit =
tokens=E2=80=9D
> idea above, we need to make sure that an AS/RS setup is built such that i=
f
> the AS tells a client =E2=80=9Conly do X with your token=E2=80=9D and the=
 client does =E2=80=9CY=E2=80=9D,
> then there are other protections and practices in place to prevent things
> from going haywire if the client does =E2=80=9CY=E2=80=9D either by accid=
ent or through
> ignorance.
>
> If OAuth 2 has taught us anything, it=E2=80=99s that client applications =
are going
> to be the laziest participants in the security model. And that makes sens=
e,
> really =E2=80=94 security isn=E2=80=99t what the client apps are trying t=
o do, they=E2=80=99re
> trying to use the RS to do something. So we need to make sure that whatev=
er
> system we design will fail on the safe side as much as possible, and keep
> things simple for the client.
>
>
> > here are some worked out samples of this:
> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
> Peace ..tom
>
> As one of the authors of those mentioned drafts, I am interested in
> discussing that, but perhaps on a seperate thread? As at least the bound
> assertion spec is primarily concerned with binding mechanisms for the
> artifacts produced from an authorization flow (specifically identity
> claims), whereas I think directed access tokens is just more generally
> talking about whether GNAP should support an AS conveying how to use an
> access_token it produces during a flow with a client.
>
>
> I think that these are separate issues as well.
>
>  =E2=80=94 Justin
>
> Thanks,
> [image: Mattr website] 
> *Tobias Looker*
> Mattr
> +64 (0) 27 378 0461
> tobias.looker@mattr.global
> [image: Mattr website]  [image: Mattr on LinkedIn]
>  [image: Mattr on Twitter]
>  [image: Mattr on Github]
> 
> This communication, including any attachments, is confidential. If you ar=
e
> not the intended recipient, you should not read it - please contact me
> immediately, destroy it, and do not copy or use any part of this
> communication or disclose anything about it. Thank you. Please note that
> this communication does not designate an information system for the
> purposes of the Electronic Transactions Act 2002.
>
>
> On Wed, Jun 24, 2020 at 10:14 PM Denis  wrote:
>
>> Justin, I fear we are still far away from an agreement about what this
>> BoF should do.
>>
>> Tom Jones is saying " I am getting tired of the whack-a-mole approach ..=
."
>>
>> I don't agree with you when you write: "I think it=E2=80=99s going to be
>> overwhelmingly common that a given RS is going to trust exactly one AS
>> that it knows about ahead of time". Such an architecture would have
>> exactly the same limitations as OAuth 2.0. and would not be scalable.
>>
>> Before we start, we should have a clear view of the whole picture rather
>> than starting from one scenario and expanding it in many different
>> directions.
>> For building an architecture, a pre-requirement is to define ALL the
>> trust relationships. I don't believe that we have an agreement at this t=
ime
>> on what
>> these trust relationships are.
>>
>> You are also using the following wording: "methods for the AS and RS to
>> communicate what the token=E2=80=99s good for".
>> With such a paradigm, it would be impossible to protect the user's
>> privacy.
>>
>> A key question is : Will GNAP take care of the user's privacy or will GN=
AP
>>  *prevent *to take care of the user's privacy ?
>>
>> About "the ability for the client to get several access tokens to get
>> different resources from one request" is indeed a complex case.
>>
>> No one (including ASs) is able to predict in advance which access tokens
>> will be needed, since they depend upon the kind of operation(s)
>> the client will be willing to perform. For privacy reasons, ASs should b=
e
>> kept ignorant of all the operations that a client is going to perform
>> on one or more resource servers. I believe that every effort should be
>> made to avoid the AS to be in a position to be able to trace the operati=
ons
>>
>> performed by its clients on various RSs.
>>
>> To handle the complex case you envision, the full workflow of operations
>> needs to be considered with a detailed focus on the time
>> at which the user's *consent and choice* happens (*consent and choice* i=
s
>> the first privacy principle from ISO 29100).
>>
>> First of all, an access token could be targeted to a service rather than
>> to a server. This would already solve many cases.
>>
>> When a RS needs to call another RS (which does not support the same
>> service) then the client should be informed by the first RS.
>> His "consent and choice" should then be obtained by the first RS and,
>> when the user agrees, the client should then ask an access token
>> to one of the ASs trusted by the second RS in order to perform the
>> subsequent operation.
>>
>> Denis
>>
>> PS.  In an email sent on June 23 you wrote: " I think an on-device AS is
>> an important use case".  I am sorry, but I don't understand.
>>        However, I do understand what "a server-based AS" is.
>>
>>
>> Denis, thanks for the great comments. I think that your trust model is
>> pretty different from what I=E2=80=99d laid out initially, and while it=
=E2=80=99s an
>> interesting and important one, it is not what I meant by =E2=80=9Cmultip=
le access
>> tokens=E2=80=9D in my discussion below. I think that might be the cause =
of some
>> disconnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of reach=
 for what the WG is
>> after.
>>
>> When I refer to multiple access tokens, and what the charter calls out a=
s
>> multiple access tokens, is the ability for the client to get several acc=
ess
>> tokens to get different resources from one request. I personally see thi=
s
>> as an optimization of a specific set of use cases, some of which I
>> discussed in my original email. There are others, I=E2=80=99m sure, but =
all the
>> ones I=E2=80=99ve seen are around the client needing to get several diff=
erent kinds
>> of access through an AS.
>>
>> I think it=E2=80=99s going to be overwhelmingly common that a given RS i=
s going
>> to trust exactly one AS that it knows about ahead of time. But for RS=E2=
=80=99s
>> that can trust multiple AS=E2=80=99s, then we should have a model that c=
an
>> accommodate that as well. That=E2=80=99s why the charter calls out metho=
ds for the
>> AS and RS to communicate what the token=E2=80=99s good for. I think the =
basis of
>> those methods is going to start with a common token model, and likely
>> incorporate into things like token formats and introspection-style token
>> APIs.
>>
>>  =E2=80=94 Justin
>>
>> On Jun 22, 2020, at 3:55 AM, Denis  wrote:
>>
>> Hello Justin,
>>
>> A few comments between the lines.
>>
>> One of the most important aspects to GNAP is going to be an ability to
>> address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do =
without significant
>> gymnastics. So with that, I wanted to bring back a use case discussion t=
hat
>> originally came up while we were talking about the possibility of multip=
le
>> access tokens, a few months back. I don=E2=80=99t know if this concept h=
as a
>> regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access t=
okens=E2=80=9D until we
>> come up with something better =E2=80=94 assuming we decide this is worth=
while.
>>
>> I don't understand what may mean "directed access tokens=E2=80=9D but I
>> understand what means "multiple access tokens".
>> When speaking of "multiple access tokens", these access tokens may come
>> from one or more ASs.
>>
>> In OAuth, the client=E2=80=99s supposed to always know where to send its=
 access
>> token, and that knowledge is completely outside the protocol. This makes=
 a
>> lot of sense for many (if not most) deployments, as OAuth is really ther=
e
>> to enable the API access that the client already knows about.
>>
>> But we=E2=80=99re now in a world where a client could be talking to a ge=
neric API
>> that could be deployed at a number of different places, or a cloud
>> deployment that the AS wants to be able to dispatch the client to.
>>
>> As soon the AS is placed (again) at the centre of the model, the AS will
>> have the ability to act as "Big Brother".
>> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP
>> should take care of them.
>>
>> In order to do this, the AS needs to be able to communicate to the clien=
t
>> not only the token information (and any related key and presentation
>> information), but also a set of *directions* about what that specific
>> token is good for. This needs to be information outside the token itself=
,
>> since I believe we want to keep OAuth 2=E2=80=99s feature of having the =
token be
>> opaque to the client. Note: while we could map all of these to different
>> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlanc=
e)
>> on the request side, this isn=E2=80=99t enough to tell the client what t=
o do with
>> the token *if it doesn=E2=80=99t know already*.
>>
>> I know of two use cases already in the wild, where people are addressing
>> things using a mix of existing standards and some proprietary extensions=
 to
>> address things within their silos. I=E2=80=99ll try to summarize here, b=
ut I know
>> the folks I=E2=80=99ve been talking to about this are also on the list s=
o hopefully
>> they can chime in with more detail or any corrections for something I=E2=
=80=99ve
>> missed.
>>
>> (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=
=80=99t know
>> where it=E2=80=99s hosted. Everything is in a single security domain con=
trolled by
>> the AS,
>>
>> Speaking of "multiple access tokens" is in contradiction with single
>> security domain "controlled" by an AS.
>> A user may need to demonstrate some of his identity attributes granted
>> e.g. by his bank but may also
>> need to demonstrate one or more diplomas granted by one or more
>> universities. The bank cannot be
>> the "primary issuer" of a university diploma. It should not be either a
>> "secondary issuer", because
>> the bank does not "*need to know"* what are the diplomas of the user.
>>
>> but the AS needs to decide at runtime which specific instance of the API
>> to direct the client to. Since things are closely tied together, the cli=
ent
>> just needs to effectively known an identifier for the RS, and this is
>> currently implemented as a URI. Once the client has that identifier, it
>> knows how to dispatch that token to that instance of the RS.
>>
>> There is no good reason why the AS should be involved in that step.
>> OAuth 2.0 is/was implicitly mandating a strong relationship between ASs
>> and RSs which makes it non scalable.
>> GNAP should be based on a simple trust relationship : a given RS trusts
>> some ASs for access tokens that contains some types of attributes.
>> An AS should not need to know in advance (or even at the time of an
>> access token request) the RSs that are trusting it.
>>
>> A client could first talk to a "global service provider" which has the
>> knowledge of the different RSs affiliated to it.
>>
>> (2) The client knows what kind of thing it=E2=80=99s looking for, but do=
esn=E2=80=99t
>> know who to ask it from.
>>
>> Once again, the client could first talk to a "global service provider"
>> which has the knowledge of the different RSs affiliated to it.
>>
>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, a=
nd the AS needs
>> to dispatch to different resources depending on which user logged in (an=
d
>> possibly what the user consented to). To make things more concrete, the
>> client needs to get driver=E2=80=99s license information, but doesn=E2=
=80=99t know ahead of
>> time which of the many state/provincial bureaus to call to get that
>> information because it doesn=E2=80=99t know yet who the user is.
>>
>> When a user has a driving license, he knows its issuer. The user can the=
n
>> provide some hint to the client.
>>
>> The AS will know who the user is once they log in and approve things, an=
d
>> so it can direct the client to call the correct RS. Since this is a
>> relatively simple API with a pre-negotiated cross-domain trust, the AS
>> returns a URL that the client presents the token at.
>>
>>  A single AS should not be aware of all the attributes a user has.
>>
>>
>> As far as I know, in both of these cases, the token is only good for tha=
t
>> API and not others =E2=80=94 but more on that later.
>>
>> A simple thing to do is just give back a URL with the access token, whic=
h
>> tells the client where to go.
>>
>> {
>> =E2=80=9Caccess_token=E2=80=9D: {
>> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
>> =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
>> }
>> }
>>
>> This is good for some kinds of APIs, but it=E2=80=99s limiting because n=
ot all
>> APIs dispatch based on the URL. An AS might want to divvy up access toke=
ns
>> to an API that=E2=80=99s keyed on headers, or verbs, or any number of th=
ings. And
>> it doesn=E2=80=99t tell us immediately what to do about non-exact URL ma=
tches. Can
>> the client add query parameters and still use the token? What about path
>> segments? I like that this simple approach addresses some common
>> deployments that we already see today (see above), it=E2=80=99s not univ=
ersal. Do
>> we want or need a universal description language for directing where tok=
ens
>> go?
>>
>> This also opens up a whole new set of security questions. If the AS can
>> now direct the client where to use the token, could a rogue AS convince =
a
>> legit client to use a stolen token at the wrong RS? And what if the clie=
nt
>> ignores the directions from the AS entirely? Could this open up new aven=
ues
>> of attack?
>>
>> This is just the start, too. Things get even more complex if the client
>> can ask for multiple different kinds of resources at once. What if the A=
S
>> decides that the client needs a hyper-focused directed token for one par=
t
>> of the API, but can use a general token for other stuff? Can it signal t=
hat
>> to the client? And if it can, does that mean that all clients need to be
>> prepared for that kind of thing?
>>
>> I firmly believe that whatever we build in GNAP, we need to optimize for
>> the overwhelmingly common use case of a client getting a single access
>> token to call APIs that it already knows about. Anything we add on top o=
f
>> that really can=E2=80=99t get in the way of this, because if it does, th=
ere=E2=80=99s very
>> small chance that people will try to use this for everyday things. Keep =
the
>> simple things simple, and the complex things possible, after all.
>>
>> I=E2=80=99m really looking forward to hearing what the community thinks =
about
>> these use cases, and hopefully the people I=E2=80=99ve chatted with offl=
ine about
>> this can join the conversation and provide more light than I was able to=
.
>>
>> The two use cases which are considered above are:
>>
>> (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=
=80=99t know
>> where it=E2=80=99s hosted.
>> (2) The client knows what kind of thing it=E2=80=99s looking for, but do=
esn=E2=80=99t
>> know who to ask it from.
>>
>> That does not mean in any way that these two use cases should be solved
>> by placing the AS at the centre of the solution.
>>
>> Denis
>>
>>
>>  =E2=80=94 Justin
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
> This communication, including any attachments, is confidential. If you ar=
e not the intended recipient, you should not read it - please contact me im=
mediately, destroy it, and do not copy or use any part of this communicatio=
n or disclose anything about it. Thank you. Please note that this communica=
tion does not designate an information system for the purposes of the Elect=
ronic Transactions Act 2002.
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>

--=20
This communication, including any attachments, is confidential. If you are=
=20
not the intended recipient, you should not read it - please contact me=20
immediately, destroy it, and do not copy or use any part of this=20
communication or disclose anything about it. Thank you. Please note that=20
this communication does not designate an information system for the=20
purposes of the Electronic Transactions Act 2002.

--000000000000dc259605a9e2ce02
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I've also been thinking about the parallels between ZC=
AP's and OAuth2.0 access tokens. To me a ZCAP is a less opaque, semanti=
cally richer capability format, whereas an access_token is traditionally mu=
ch simpler. The key here though is I still see an access_token as a form of=
 capability. It appears in general one of the trade offs we will be faced w=
ith is either:

1. Keeping the capability received=C2=A0f=
rom a GNAP flow (e.g an access_token) opaque to the client and externalizin=
g any greater information about how to use the capability (such as in your =
proposal in the first email of this thread).
2. Internalizing inf=
ormation about the capabilities utility and any greater context about it wh=
ich means the capability is no longer opaque.

With that aside, the notable features in general I would like GNAP to cons=
ider from ZCAP's, are the following.

- Delegatable c=
apabilities (bonus if this mechanism includes the ability to attenuate duri=
ng delegation) - Consider the example where a client or RP (RP1) receives=
=C2=A0some form of access_token (capability) from an AS and would like to d=
elegate this to another RP (RP2) so they can access the same resources. If =
including attenuation=C2=A0this=C2=A0would mean that during this delegation=
 (RP1->RP2), RP1 could narrow the scope of the original access it receiv=
ed=C2=A0so that RP2 only gets a subset of the original scope.
- B=
ound capabilities - Similar in some ways to dPop, essentially establishing =
the ability to bind an access_token (capability) to the party that should b=
e able to use it (invoker). I see this as a must have in order to be able t=
o do attenuated delegation as described above.

Thanks,
3D"Mattr
=C2=A0<=
/td>
Tobias Looker
Mattr
+64 (0=
) 27 378 0461
tobias.looker@mattr.global<=
/a>
3D"Mattr3D"Mattr3D"Mattr3D"Mattr

This communication, including any attachments, is confidential. If you are=
 not the intended recipient, you should not read it - please contact me imm=
ediately, destroy it, and do not copy or use any part of this communication=
 or disclose anything about it. Thank you. Please note that this communicat=
ion does not designate an information system for the purposes of the Electr=
onic Transactions Act 2002.


On Wed, Jul 8, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99ve been thinking more about these use cases, and it might help u=
s to think of GNAP=E2=80=99s access tokens as capabilities in the computer =
security sense =E2=80=94 but more specifically, capabilities that are deliv=
ered with their own context for use. In that way, an otherwise naive client=
 can be handed an access token and simply know exactly what to do with it. =
This context would be delivered alongside the token, so the token material =
itself remains opaque to the client.

I wanted to bring u=
p a W3C spec for a capabilities model based on linked data:

<=
div>https:=
//w3c-ccg.github.io/zcap-ld/

Building a fully =
featured capabilities context is difficult, at the very least. And unfortun=
ately, I don=E2=80=99t think this spec actually gives us any viable solutio=
ns to work with. In particular the =E2=80=9Cactions=E2=80=9D section is eff=
ectively blank, offloading the work to an external JSONLD process (side not=
e, this is one of the problems I have with specs based on JSONLD, they exte=
rnalize the important parts into local contexts and break interoperability =
=E2=80=94 but I digress). But at least it=E2=80=99s another way of looking =
at the problem space that might be outside the familiar zone of many of the=
 OAuth world.

=C2=A0=E2=80=94 Justin

<=
blockquote type=3D"cite">
On Jun 26, 2020, at 9:23 AM, Justin Richer &l=
t;jricher@mit.edu&=
gt; wrote:

On=
 Jun 25, 2020, at 9:07 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

=
I find this feature interesting and think it could be an important=C2=A0pat=
tern going=C2=A0forward to enable an AS to be able to describe the utility =
of a token to the client, however as already pointed out in the thread I th=
ink there is some potential hidden complexity that would need to be ironed =
out such that it does not make the simple things complicated.

Justin, do you see this feature as something the client has to explic=
itly request, i.e "please give me access and instructions on how to us=
e my access" or rather that the AS would just return this information =
in conjunction with the access token if it had it available?

=


This is something that I=
=E2=80=99d brought up as a possibility on the previous thread =E2=80=94 som=
ething like a flag the client would set. This would be especially important=
 if the AS wants to return multiple access tokens but the client requested =
1, or the client requested N and the AS wants to return M in response. Basi=
cally any time there=E2=80=99s a mismatch, that=E2=80=99s extra complexity =
on the client that I really don=E2=80=99t think we want to be universal. A =
flag to turn that kind of direction and splitting on would be a potential s=
tart. But there are potential snags here too, and it comes down to how you =
manage the defaults...

> This is just the start, too. Things get even more complex if=
 the client can ask for multiple different kinds of resources at once. What=
 if the AS decides that the client needs a hyper-focused directed token for=
 one part of the API, but can use a general token for other stuff? Can it s=
ignal that to the client? And if it can, does that mean that all clients ne=
ed to be prepared for that kind of thing?

Would a =
potential default be that if a client did for any reason not support proces=
sing the additional information returned with the access_token, just to ign=
ore it? I think in the spirit of keeping the simple things simple, this pot=
entially makes sense?

Tha=
t=E2=80=99s the real trick, if you ask me. It has to be :safe: for a client=
 to ignore this information. Which means the AS can=E2=80=99t rely on the c=
lient =E2=80=9Cdoing the right thing=E2=80=9D with the information in the =
=E2=80=9Ctoken directions=E2=80=9D portion of the response. Even setting as=
ide the advanced and related =E2=80=9Csplit tokens=E2=80=9D idea above, we =
need to make sure that an AS/RS setup is built such that if the AS tells a =
client =E2=80=9Conly do X with your token=E2=80=9D and the client does =E2=
=80=9CY=E2=80=9D, then there are other protections and practices in place t=
o prevent things from going haywire if the client does =E2=80=9CY=E2=80=9D =
either by accident or through ignorance.=C2=A0

If =
OAuth 2 has taught us anything, it=E2=80=99s that client applications are g=
oing to be the laziest participants in the security model. And that makes s=
ense, really =E2=80=94 security isn=E2=80=99t what the client apps are tryi=
ng to do, they=E2=80=99re trying to use the RS to do something. So we need =
to make sure that whatever system we design will fail on the safe side as m=
uch as possible, and keep things simple for the client.


> here are som=
e worked out samples of this:
https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
Peace ..tom

As one of the authors of those mentioned drafts, I am interested in=
 discussing that, but perhaps on a seperate thread? As at least=C2=A0the bo=
und assertion spec is=C2=A0primarily=C2=A0concerned with binding mechanisms=
 for the artifacts produced from an authorization flow (specifically identi=
ty claims), whereas I think directed access tokens is just more generally t=
alking about whether GNAP should support an AS conveying how to use an acce=
ss_token it produces during a flow with a client.


I t=
hink that these are separate issues as well.

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

Thanks,
3D"Mattr=C2=
=A0
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.=
global
<=
td width=3D"40">3D"Mattr
<=
a href=3D"https://www.linkedin.com/company/mattrglobal" style=3D"border:non=
e;color:rgb(51,49,50);margin-right:12px" target=3D"_blank">3D"Mattr3D"Mattr3D"Mattr

This communication, including any attachments, is confid=
ential. If you are not the intended recipient, you should not read it - ple=
ase contact me immediately, destroy it, and do not copy or use any part of =
this communication or disclose anything about it. Thank you. Please note th=
at this communication does not designate an information system for the purp=
oses of the Electronic Transactions Act 2002.
=


On Wed, Jun 24, 2020 at 10:14 PM Denis <denis.ietf@free.fr> wrote:
Justin, I fea=
r we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am getting tired of the=
 whack-a-mole approach ..."

I don't agree with=
 you when you write: "I think it=E2=80=99s going to be overwhelmingly =
common that a given RS is going to trust exactly one AS=C2=A0<=
br>
that it knows about ahead of time". Such an architecture would=
 have exactly the same limitations as OAuth 2.0. and would not be scalable.=


Before we start, we should have a clear view=
 of the whole picture rather than starting from one scenario and expanding =
it in many different directions.
For building an architecture, a =
pre-requirement is to define ALL the trust relationships. I don't belie=
ve that we have an agreement at this time on what=C2=A0
the=
se trust relationships are.=C2=A0

You are also using the following wording: "methods for the AS and R=
S to communicate what the token=E2=80=99s good for".=C2=A0
With such a paradigm, it would be impossible to protect the user's=
 privacy.=C2=A0

A key question is=
 : Will GNAP take care of the user's privacy or will GNAP=C2=A0prevent=C2=A0to take care of the user's privac=
y ?

About "the ability for the client to get =
several access tokens to get different resources from one request" is =
indeed a complex case.

No one (including ASs) is a=
ble to predict in advance which access tokens will be needed, since they de=
pend upon the kind of operation(s)=C2=A0
the client will be=
 willing to perform. For privacy reasons, ASs should be kept ignorant of al=
l the operations that a client is going to perform=C2=A0
on=
 one or more resource servers. I believe that every effort should be made t=
o avoid the AS to be in a position to be able to trace the operations=
=C2=A0
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of opera=
tions needs to be considered with a detailed focus on the time=C2=A0<=
/span>
at which the user's=C2=A0consent and choice=C2=A0happens (consent and choice=C2=A0i=
s the first privacy principle from ISO 29100).

Fir=
st of all, an access token could be targeted to a service rather than to a =
server. This would already solve many cases.

When =
a RS needs to call another RS (which does not support the same service) the=
n the client should be informed by the first RS.
His "consen=
t and choice" should then be obtained by the first RS and, when the us=
er agrees, the client should then ask an access token=C2=A0to one of the ASs trusted by the second RS in order to perform the subsequ=
ent operation.=C2=A0=C2=A0

Denis<=
/div>

PS.=C2=A0 In an email sent on June 23 you wrote: &=
quot; I think an on-device AS is an important use case".=C2=A0 I am so=
rry, but I don't understand.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ho=
wever, I do understand what "a server-based AS" is.


Denis, thanks for the g=
reat comments. I think that your trust model is pretty different from what =
I=E2=80=99d laid out initially, and while it=E2=80=99s an interesting and i=
mportant one, it is not what I meant by =E2=80=9Cmultiple access tokens=E2=
=80=9D in my discussion below. I think that might be the cause of some disc=
onnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of reach for wh=
at the WG is after.

When I refer to multiple access toke=
ns, and what the charter calls out as multiple access tokens, is the abilit=
y for the client to get several access tokens to get different resources fr=
om one request. I personally see this as an optimization of a specific set =
of use cases, some of which I discussed in my original email. There are oth=
ers, I=E2=80=99m sure, but all the ones I=E2=80=99ve seen are around the cl=
ient needing to get several different kinds of access through an AS.=C2=A0<=
br>

I think it=E2=80=99s going to be overwhelmingly comm=
on that a given RS is going to trust exactly one AS that it knows about ahe=
ad of time. But for RS=E2=80=99s that can trust multiple AS=E2=80=99s, then=
 we should have a model that can accommodate that as well. That=E2=80=99s w=
hy the charter calls out methods for the AS and RS to communicate what the =
token=E2=80=99s good for. I think the basis of those methods is going to st=
art with a common token model, and likely incorporate into things like toke=
n formats and introspection-style token APIs.=C2=A0

=C2=A0=E2=80=94 Justin

On Jun =
22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the lines.

One of the most important aspects t=
o GNAP is going to be an ability to address things that OAuth 2 can=E2=80=
=99t, or at least can=E2=80=99t do without significant gymnastics. So with =
that, I wanted to bring back a use case discussion that originally came up =
while we were talking about the possibility of multiple access tokens, a fe=
w months back. I don=E2=80=99t know if this concept has a regular term, so =
I=E2=80=99m going to call it =E2=80=9Cdirected access tokens=E2=80=9D until=
 we come up with something better =E2=80=94 assuming we decide this is wort=
hwhile.=C2=A0
I don't u=
nderstand what may mean "directed access tokens=E2=80=9D but I underst=
and what means "multiple access tokens".=C2=A0
Wh=
en speaking of "multiple access tokens", these access tokens may =
come from one or more ASs.
In OAuth, the client=E2=80=99s supposed to always know where to send =
its access token, and that knowledge is completely outside the protocol. Th=
is makes a lot of sense for many (if not most) deployments, as OAuth is rea=
lly there to enable the API access that the client already knows about.

But we=E2=80=99re now in a world where a client could=
 be talking to a generic API that could be deployed at a number of differen=
t places, or a cloud deployment that the AS wants to be able to dispatch th=
e client to.=C2=A0
As soo=
n the AS is placed (again) at the centre of the model, the AS will have the=
 ability to act as "Big Brother".
OAuth 2.0 has not taken care=
 of privacy issues. On the contrary, GNAP should take care of them.
In order to do this, the AS need=
s to be able to communicate to the client not only the token information (a=
nd any related key and presentation information), but also a set of=
=C2=A0directions=C2=A0about what that specific token is good =
for. This needs to be information outside the token itself, since I=C2=A0be=
lieve we want to keep OAuth 2=E2=80=99s feature of having the token be opaq=
ue to the client. Note: while we could map all of these to different resour=
ce requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the=
 request side, this isn=E2=80=99t enough to tell the client what to do with=
 the token=C2=A0if it doesn=E2=80=99t know already.=C2=
=A0

I know of two use cases already in the wild, w=
here people are addressing things using a mix of existing standards and som=
e proprietary extensions to address things within their silos. I=E2=80=99ll=
 try to summarize here, but I know the folks I=E2=80=99ve been talking to a=
bout this are also on the list so hopefully they can chime in with more det=
ail or any corrections for something I=E2=80=99ve missed.=C2=A0
<=
br>
(1) The client knows what resource it=E2=80=99s calling, but =
it doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a singl=
e security domain controlled by the AS,=C2=A0
Speaking of "multiple access tokens" is in c=
ontradiction with single security domain "controlled" by an AS.=C2=A0
A user may need to demonstrate some of his identity at=
tributes granted e.g. by his bank but may also=C2=A0
need t=
o demonstrate one or more diplomas granted by one or more universities. The=
 bank cannot be=C2=A0
the "primary issuer" of a u=
niversity diploma. It should not be either a "secondary issuer", =
because=C2=A0
the bank does not "need to know"=
=C2=A0what are the diplomas of the user.
but the AS needs to decide at runtime =
which specific instance of the API to direct the client to. Since things ar=
e closely tied together, the client just needs to effectively known an iden=
tifier for the RS, and this is currently implemented as a URI. Once the cli=
ent has that identifier, it knows how to dispatch that token to that instan=
ce of the RS.
There is no good reason =
why the AS should be involved in that step.=C2=A0
OAuth 2.0=
 is/was implicitly mandating a strong relationship between ASs and RSs whic=
h makes it non scalable.
GNAP should be based on a simple trust relation=
ship : a given RS trusts some ASs for access tokens that contains some type=
s of attributes.
An AS should not need to know in advance (or even at th=
e time of an access token request) the RSs that are trusting it.
A client could first talk to a "global service provide=
r" which has the knowledge of the different RSs affiliated to it.=C2=A0
(2) Th=
e client knows what kind of thing it=E2=80=99s looking for, but doesn=E2=80=
=99t know who to ask it from.=C2=A0
Once again, the client could first talk to a "global servic=
e provider" which has the knowledge of the different RSs affiliated to=
 it.=C2=A0
T=
here=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, and t=
he AS needs to dispatch to different resources depending on which user logg=
ed in (and possibly what the user consented to). To make things more concre=
te, the client needs to get driver=E2=80=99s license information, but doesn=
=E2=80=99t know ahead of time which of the many state/provincial bureaus to=
 call to get that information because it doesn=E2=80=99t know yet who the u=
ser is.=C2=A0
When a user=
 has a driving license, he knows its issuer. The user can then provide some=
 hint to the client.
The =
AS will know who the user is once they log in and approve things, and so it=
 can direct the client to call the correct RS. Since this is a relatively s=
imple API with a pre-negotiated cross-domain trust, the AS returns a URL th=
at the client presents the token at.=C2=A0
=C2=A0A single AS should not be aware of all the attr=
ibutes a user has.=C2=A0

As far as I know, in both of these cases, t=
he token is only good for that API and not others =E2=80=94 but more on tha=
t later.

A simple thing to do is just give back a =
URL with the access token, which tells the client where to go.=C2=A0
<=
div>
	{
		=E2=80=9Caccess_token=E2=80=
=9D: {
			=E2=80=9Cva=
lue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
			=E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
		}
	}

This is goo=
d for some kinds of APIs, but it=E2=80=99s limiting because not all APIs di=
spatch based on the URL. An AS might want to divvy up access tokens to an A=
PI that=E2=80=99s keyed on headers, or verbs, or any number of things. And =
it doesn=E2=80=99t tell us immediately what to do about non-exact URL match=
es. Can the client add query parameters and still use the token? What about=
 path segments? I like that this simple approach addresses some common depl=
oyments that we already see today (see above), it=E2=80=99s not universal. =
Do we want or need a universal description language for directing where tok=
ens go?

This also opens up a whole new set of secu=
rity questions. If the AS can now direct the client where to use the token,=
 could a rogue AS convince a legit client to use a stolen token at the wron=
g RS? And what if the client ignores the directions from the AS entirely? C=
ould this open up new avenues of attack?

This is j=
ust the start, too. Things get even more complex if the client can ask for =
multiple different kinds of resources at once. What if the AS decides that =
the client needs a hyper-focused directed token for one part of the API, bu=
t can use a general token for other stuff? Can it signal that to the client=
? And if it can, does that mean that all clients need to be prepared for th=
at kind of thing?

I firmly believe that whatever w=
e build in GNAP, we need to optimize for the overwhelmingly common use case=
 of a client getting a single access token to call APIs that it already kno=
ws about. Anything we add on top of that really can=E2=80=99t get in the wa=
y of this, because if it does, there=E2=80=99s very small chance that peopl=
e will try to use this for everyday things. Keep the simple things simple, =
and the complex things possible, after all.

I=E2=
=80=99m really looking forward to hearing what the community thinks about t=
hese use cases, and hopefully the people I=E2=80=99ve chatted with offline =
about this can join the conversation and provide more light than I was able=
 to.
The two use cases which are consi=
dered above are:
(1) The client knows wha=
t resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=
=99s hosted.
(2) The client knows what kind of thing it=E2=80=99s lookin=
g for, but doesn=E2=80=99t know who to ask it from.=C2=A0
<=
/p>
That does not mean in any way that these=
 two use cases should be solved by placing the AS at the centre of the solu=
tion.
Denis

=C2=A0=E2=80=94 Justin


--=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

This communication, including any attachments, is confide=
ntial. If you are not the intended recipient, you should not read it - plea=
se contact me immediately, destroy it, and do not copy or use any part of t=
his communication or disclose anything about it. Thank you. Please note tha=
t this communication does not designate an information system for the purpo=
ses of the Electronic Transactions Act 2002.
=

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





This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.

--000000000000dc259605a9e2ce02--


From nobody Wed Jul  8 00:15: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 B84AB3A0C22 for ; Wed,  8 Jul 2020 00:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level: 
X-Spam-Status: No, score=-1.619 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.276, 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 5ZIimL3lg8Cc for ; Wed,  8 Jul 2020 00:14:53 -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 9EAF63A0C2E for ; Wed,  8 Jul 2020 00:14:50 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d53 with ME id 0XEm2300D4FMSmm03XEm7H; Wed, 08 Jul 2020 09:14:48 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 08 Jul 2020 09:14:48 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt 
Cc: Justin Richer , "rdd@cert.org" , "txauth@ietf.org" , The IESG 
References: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>   <46705E7E-D657-4CF1-80DA-0ADDFD6D8B41@mit.edu> <85b03911-d1c6-127f-2480-bfab4b94ffe2@free.fr> 
From: Denis 
Message-ID: 
Date: Wed, 8 Jul 2020 09:14: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="------------F0FB495A4A776B72668E1E45"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Support of FIDO and data minimization by RSs
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, 08 Jul 2020 07:14:59 -0000

This is a multi-part message in MIME format.
--------------F0FB495A4A776B72668E1E45
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Dick,

> Denis: you seem to keep implying that other architectures don't 
> preserve privacy. A couple counterpoints:
>
> Token opacity helps privacy in another dimension -- the client does 
> not see the information about the user.

The client is not an adversary to the user.

> Many OAuth developments have self contained tokens. There is no token 
> introspection call.
> This, coupled with opaque tokens, is more privacy preserving than the 
> client being able to peek in a token.

When an access token contains personal information about a user, that 
user has the right to see that personal information.

Denis

>
> ᐧ
>
> On Tue, Jul 7, 2020 at 5:26 AM Denis  > wrote:
>
>     Hi Justin,
>
>>     I think removing the opacity of access tokens to clients is going
>>     to be a non-starter for most of this community.
>
>     Token opacity is considered as a dogma in OAuth 2.0. More
>     explanations why access tokens should not be opaque in GNAP.
>
>     Token introspection mandates a dialogue from the RS to the AS
>     which allows the AS to know which RS
>     got a given access token. So token introspection allows the AS to
>     trace the client. This should be avoided.
>     Using NON-OPAQUE access tokens solves the issue both for the RSs
>     and for the clients. This means that
>     access tokens used for GNAP shall include a version number or a
>     format identifier.
>
>     Applying a "security by design" approach leads to specific design
>     requirements. The key question is whether
>     this BoF prefers a "Privacy by design" approach or /implicitly /a
>     "Big Brother by design" approach.
>
>     Denis
>
>>
>>      — Justin
>>
>>>     On Jul 6, 2020, at 3:17 PM, Denis >>     > wrote:
>>>
>>>     Hi Dick,
>>>
>>>     Congratulations ! You made a good guess (but the guess was
>>>     easy): my approach is indeed privacy related.
>>>
>>>     _Note_: Since it is close to the end of the day in my time zone
>>>     (and since it is the last day for comments to the charter),
>>>     I copy both the IESG and Roman so that they can know that GNAP
>>>     should also consider a*bridge with FIDO*.
>>>
>>>     I have several goals:
>>>
>>>         1 - make a bridge with FIDO U2F (I will illustrate this with
>>>         a specific scenario).
>>>
>>>         2 - prevent every AS to know which RSs are going to be
>>>         accessed or which kind of operation the client will be doing.
>>>             This is to prevent an AS to act as "Big Brother".
>>>
>>>         3 - apply both "privacy by default" and "data minimization"
>>>         (when the user authenticates it may authenticate using FIDO or
>>>              by presenting one or more access tokens. Then after,
>>>         the necessary attributes that are necessary to perform a
>>>         given operation
>>>             are only requested and released at the time they are
>>>         indeed needed to perform the given operation (i.e. they are
>>>         not released
>>>             when the user logs on).
>>>
>>>         4 - the proposed RS Authorization algorithm allows a great
>>>         flexibility, in particular it supports FIDO and different
>>>         attributes
>>>              from different ASs may be requested by the RS.
>>>
>>>         5 - the rules associated with the RS Authorization algorithm
>>>         are making these rules only available at the time the client
>>>         indicates
>>>              which operation it is willing to perform (i.e. by
>>>         default, they are not public).
>>>
>>>         6 - access tokens are NOT OPAQUE to the clients so that
>>>         every client can make sure that their content reflects what
>>>         has been requested.
>>>
>>>     *A simple scenario to illustrate*
>>>
>>>     A student wants to apply for a new university. He connects to
>>>     the RS of the University. He first creates an account using FIDO.
>>>     He then selects the button "Preliminary information for applying
>>>     to the university". He is asked to enter two categories of
>>>     information:
>>>
>>>           * citizenship information and
>>>           * prior graduations.
>>>
>>>     The student can interrupt the preliminary registration procedure
>>>     at any time and continue it at any time later on.
>>>
>>>     When the student is finished, it selects the button "Application
>>>     to the university".
>>>
>>>         The university RS "reads" the citizen ship of the student
>>>         and let know to the student whether a paper form
>>>         and/or an electronic form of the identity of the student may
>>>         be provided. Let us assume the later case and that
>>>         the student is a citizen from France. Then the university RS
>>>         indicates which French banks or other French organisations
>>>         are trusted to provide an access token. The client checks
>>>         whether this list fits one of the AS with which it has a
>>>         relationship.
>>>
>>>         The university RS "reads" the prior graduations of the
>>>         student and then let know to the student whether a paper form
>>>         and/or an electronic form of the last graduation of the
>>>         student may be provided. Let us assume the later case and
>>>         that the student is from Yale University. Then the
>>>         university indicates the address of the AS from Yale University.
>>>         If the student is indeed from Yale University, he should be
>>>         able to provide the requested access token.
>>>
>>>     Such scenario which follows some privacy principles cannot be
>>>     constructed "/after the design"/ (it will not happen by magic or
>>>     by accident)
>>>     This is why the approach is called "privacy by design".
>>>
>>>     Denis
>>>
>>>>     Hi Denis
>>>>
>>>>     Would you provide some background on what you are trying to
>>>>     solve with this? I'm guessing it is privacy related.
>>>>
>>>>     Perhaps a use case would help make it more concrete?
>>>>
>>>>     /Dick
>>>>
>>>>
>>>>     On Mon, Jul 6, 2020 at 5:39 AM Denis >>>     > wrote:
>>>>
>>>>         **eThis is a new thread: a proposal for a RS authorization
>>>>         algorithmand a way to support FIDO by RSs
>>>>
>>>>         In order to support the privacy principle of "data
>>>>         minimization" by RSs, only the attributes that are strictly
>>>>         necessary to perform
>>>>         an operation requested by a client should be requested by
>>>>         the RS.
>>>>
>>>>         When a client wants to authenticate, it will usually be
>>>>         informed by the RS on how to do it (see more details about
>>>>         two exceptions at the end of this email).
>>>>         Which conditions are needed to perform other operations
>>>>         will only be disclosed to authenticated users at the time
>>>>         they are willing to perform an operation.
>>>>
>>>>         Two categories of operations will be considered:
>>>>         authentication operations and other operations.
>>>>
>>>>         For the "authentication" operation, two cases will be
>>>>         supported:
>>>>
>>>>         -FIDO U2F or
>>>>
>>>>         -one or more attributes from one or more ASs.
>>>>
>>>>         In the second case, an access will be granted by a RS based
>>>>         on an mathematical expression which is formed using some
>>>>         combination of ANDand ORconditions.
>>>>
>>>>         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 /a Condition /:
>>>>
>>>>         /Condition x/= { AS identifier + set of attributes types +
>>>>         optional scope identifier }
>>>>
>>>>         The presence of the /optional/ scope identifier allows to
>>>>         provide a backward compatibility with ASs from the OAuth
>>>>         2.0. world:
>>>>         the optional scope identifier is only present when a
>>>>         bilateral relationship has been established between a RS
>>>>         and an AS prior
>>>>         to any access (/and will continue to be maintained/) using
>>>>         "out-of-bands" means.
>>>>
>>>>         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.
>>>>
>>>>         An example is used to explain the concepts.
>>>>
>>>>         "Operation(s)/ Mathematical expression" pairs managed by
>>>>         the RO of a RS.
>>>>
>>>>         *Operation*
>>>>
>>>>         	
>>>>
>>>>         *Mathematical expression*
>>>>
>>>>         Authentication
>>>>
>>>>         	
>>>>
>>>>         /Condition 1/OR/Condition 2/
>>>>
>>>>         Operation A OROperation Z
>>>>
>>>>         	
>>>>
>>>>         /Condition 3/AND/Condition 4/
>>>>
>>>>         Conditions table:
>>>>
>>>>         Condition 1
>>>>
>>>>         	
>>>>
>>>>         FIDO U2F 1.2
>>>>
>>>>         	
>>>>
>>>>         -
>>>>
>>>>         	
>>>>
>>>>         -
>>>>
>>>>         Condition 2
>>>>
>>>>         	
>>>>
>>>>         AS 1
>>>>
>>>>         	
>>>>
>>>>         set 1 of attributes types
>>>>
>>>>         	
>>>>
>>>>         Condition 3
>>>>
>>>>         	
>>>>
>>>>         AS 4
>>>>
>>>>         	
>>>>
>>>>         set 2 of attributes types
>>>>
>>>>         	
>>>>
>>>>         scope identifier : 21
>>>>
>>>>         Condition 4
>>>>
>>>>         	
>>>>
>>>>         AS 9
>>>>
>>>>         	
>>>>
>>>>         set 3 of attributes types
>>>>
>>>>         	
>>>>
>>>>         -
>>>>
>>>>         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 the set of attributes types which are
>>>>         indicated for a given AS
>>>>         are appropriate to him or not and then select that AS if it
>>>>         has a relationship with it.
>>>>
>>>>         In this example, one mathematical expression for the
>>>>         combination of conditions using AND and OR operators is
>>>>         "/Condition 3/OR/Condition 4",//
>>>>         which means that///some types of attributes from AS 4 AND
>>>>         some other types of attributes from AS 9 are both needed by
>>>>         RSx to perform on RSx
>>>>         either the Operation A or the Operation Z.
>>>>
>>>>         In this example, RS 1 and AS 4 have established a bilateral
>>>>         relationship (and have agreed to define and use scope
>>>>         identifiers)
>>>>         whereas RS 1 and AS 9 have not established any bilateral
>>>>         relationship prior to the exchange.
>>>>
>>>>         The user makes up his mind whether the attributes requested
>>>>         by AS 1 and AS 9 are reasonable and if so, requests two
>>>>         access tokens:
>>>>         one to AS 4 and another one to AS 9.
>>>>
>>>>         For AS 4, the client shall use the scope identifier with
>>>>         the value 21.
>>>>         For AS 9, the client shall use the set 3 of attributes
>>>>         types indicated in the Condition 4.
>>>>
>>>>         In order to save one exchange, a RS could publicly publish
>>>>         how its clients can authenticate.
>>>>         However,  it is also possible to consider no guidance at
>>>>         all: in such a case, using "out-of-bands" means, the
>>>>         clients should know how to authenticate.
>>>>
>>>>         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
>>
>


--------------F0FB495A4A776B72668E1E45
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Dick,

    


    

    

      
      
Denis: you seem to keep implying that other
        architectures don't preserve privacy. A couple counterpoints:
        


        

        
Token opacity helps privacy in another dimension -- the
          client does not see the information about the user.

      

    

    
The client is not an adversary to the user.

    

      

        

          
Many OAuth developments have self contained tokens. There
            is no token introspection call. 

            This, coupled with opaque tokens, is more privacy preserving
            than the client being able to peek in a token.

        

      

    

    
When an access token contains personal information about a user,
      that user has the right to see that personal information.

    

    
Denis

    

      

        


        

      

      
ᐧ

      

      

        
On Tue, Jul 7, 2020 at 5:26 AM
          Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hi Justin,

            


            

            
 I think removing the opacity of
              access tokens to clients is going to be a non-starter for
              most of this community. 

            

            
Token opacity is considered as a dogma in OAuth 2.0. More
              explanations why access tokens should not be opaque in
              GNAP.

            

            
Token introspection mandates a dialogue from the RS to
              the AS which allows the AS to know which RS 

              got a given access token. So token introspection allows
              the AS to trace the client. This should be avoided.

              Using NON-OPAQUE access tokens solves the issue both for
              the RSs and for the clients. This means that 

              access tokens used for GNAP shall include a version number
              or a format identifier.

            

            
Applying a "security by design" approach leads to
              specific design requirements. The key question is whether
              

              this BoF prefers a "Privacy by design" approach or implicitly
              a "Big Brother by design" approach.

            

            
Denis

            

              


              

              
 — Justin

                


                  

                    
On Jul 6, 2020, at 3:17 PM, Denis <denis.ietf@free.fr>
                      wrote:

                    

                    

                      

                        
Hi Dick,

                        


                        

                        
Congratulations ! You made a good guess
                          (but the guess was easy): my approach is
                          indeed privacy related.

                        


                        

                        
Note: Since it is close to the end
                          of the day in my time zone (and since it is
                          the last day for comments to the charter), 

                          I copy both the IESG and Roman so that they
                          can know that GNAP should also consider a
                            bridge with FIDO.

                        

                        
I have several goals:

                        

                          
1 - make a bridge with FIDO U2F (I will
                            illustrate this with a specific scenario).

                          


                          

                          
2 - prevent every AS to know which RSs
                            are going to be accessed or which kind of
                            operation the client will be doing.

                                This is to prevent an AS to act as "Big
                            Brother".

                          

                          


                          

                          
3 - apply both "privacy by default" and
                            "data minimization" (when the user
                            authenticates it may authenticate using FIDO
                            or 

                                 by presenting one or more access
                            tokens. Then after, the necessary attributes
                            that are necessary to perform a given
                            operation 

                                are only requested and released at the
                            time they are indeed needed to perform the
                            given operation (i.e. they are not released
                            

                                when the user logs on).

                          


                          

                          
4 - the proposed RS Authorization
                            algorithm allows a great flexibility, in
                            particular it supports FIDO and different
                            attributes 

                                 from different ASs may be requested by
                            the RS.

                          


                          

                          
5 - the rules associated with the RS
                            Authorization algorithm are making these
                            rules only available at the time the client
                            indicates 

                                 which operation it is willing to
                            perform (i.e. by default, they are not
                            public).

                          


                          

                          
6 - access tokens are NOT OPAQUE to the
                            clients so that every client can make sure
                            that their content reflects what has been
                            requested.

                          

                        

                        
 A simple scenario to illustrate

                        

                        


                        

                        
A student wants to apply for a new
                          university. He connects to the RS of the
                          University. He first creates an account using
                          FIDO.

                          He then selects the button "Preliminary
                          information for applying to the university".
                          He is asked to enter two categories of
                          information:

                        

                          
    
                            
  • citizenship information and 
    • 
                            
  • prior graduations.
    • 
                          

                        

                        
The student can interrupt the preliminary
                          registration procedure at any time and
                          continue it at any time later on.

                        


                        

                        
When the student is finished, it selects
                          the button "Application to the university".

                        

                        

                          
The university RS "reads" the citizen
                            ship of the student and let know to the
                            student whether a paper form 

                            and/or an electronic form of the identity of
                            the student may be provided. Let us assume
                            the later case and that 

                            the student is a citizen from France. Then
                            the university RS indicates which French
                            banks or other French organisations 

                            are trusted to provide an access token. The
                            client checks whether this list fits one of
                            the AS with which it has a relationship.

                          

                          


                          

                          The university RS "reads" the prior
                          graduations of the student and then let know
                          to the student whether a paper form 

                          and/or an electronic form of the last
                          graduation of the student may be provided. Let
                          us assume the later case and 

                          that the student is from Yale University. Then
                          the university indicates the address of the AS
                          from Yale University.

                          If the student is indeed from Yale University,
                          he should be able to provide the requested
                          access token.

                        

                        
Such scenario which follows some privacy
                          principles cannot be constructed "after the
                            design" (it will not happen by magic or
                          by accident)

                          This is why the approach is called "privacy by
                          design".

                        
Denis

                        

                        

                          
Hi Denis
                            


                            

                            
Would you provide some background on
                              what you are trying to solve with this?
                              I'm guessing it is privacy related. 

                            


                            

                            
Perhaps a use case would help make it
                              more concrete?

                            


                            

                            
/Dick

                            


                            

                          

                          

                          

                            
On Mon,
                              Jul 6, 2020 at 5:39 AM Denis <denis.ietf@free.fr>
                              wrote:

                            

                            

                              

                                
 eThis is a new thread:
                                    a proposal for a RS authorization
                                    algorithm and a way to support
                                    FIDO by RSs

                                  

                                
In order to support the
                                    privacy principle of "data
                                    minimization" by RSs, only the
                                    attributes that are strictly
                                    necessary to perform 

                                    an operation requested by a client
                                    should be requested by the RS.

                                
When a client wants to
                                    authenticate, it will usually be
                                    informed by the RS on how to do it
                                    (see more details about two
                                    exceptions at the end of this
                                    email). 

                                    Which conditions are needed to
                                    perform other operations will only
                                    be disclosed to authenticated users
                                    at the time they are willing to
                                    perform an operation.

                                
Two categories of
                                    operations will be considered:
                                    authentication operations and other
                                    operations.

                                  

                                
 For the
                                    "authentication" operation, two
                                    cases will be supported: 

                                
-         
                                    FIDO U2F or
                                  

                                
-         
                                    one or more attributes
                                    from one or more ASs. 

                                
In the second case, 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 a Condition :

                                
Condition x = { AS identifier +
                                    set of attributes types + optional
                                    scope identifier } 

                                  

                                
The presence of the optional
                                    scope identifier allows to provide a
                                    backward compatibility with ASs from
                                    the OAuth 2.0. world: 

                                    the optional scope identifier is
                                    only present when a bilateral
                                    relationship has been established
                                    between a RS and an AS prior 

                                    to any access (and will continue
                                      to be maintained) using
                                    "out-of-bands" means. 

                                  

                                
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.

                                
An example is used to
                                    explain the concepts.

                                
"Operation(s)/
                                    Mathematical expression" pairs
                                    managed by the RO of a RS. 

                                  

                                

                                  
                                    

                                      
                                        
Operation

                                      		
                                      
                                        
Mathematical
                                              expression

                                      		
                                    

                                    

                                      
                                        
Authentication

                                      		
                                      
                                        
Condition 1 OR Condition 2

                                      		
                                    

                                    

                                      
                                        
Operation A OR
                                              Operation Z

                                      		
                                      
                                        
Condition 3 AND Condition 4

                                      		
                                    

                                  
                                

                                
Conditions table: 

                                

                                  
                                    

                                      
                                        
Condition 1

                                      		
                                      
                                        
FIDO
                                            U2F 1.2

                                      		
                                      
                                        
-

                                      		
                                      
                                        
-

                                      		
                                    

                                    

                                      
                                        
Condition 2

                                      		
                                      
                                        
AS 1

                                      		
                                      
                                        
set 1 of
                                            attributes types

                                      		
                                      
                                        
 

                                        

                                      		
                                    

                                    

                                      
                                        
Condition 3

                                      		
                                      
                                        
AS 4

                                      		
                                      
                                        
set 2 of
                                            attributes types

                                      		
                                      
                                        
scope
                                            identifier : 21

                                      		
                                    

                                    

                                      
                                        
Condition 4

                                      		
                                      
                                        
AS 9

                                      		
                                      
                                        
set 3 of
                                            attributes types

                                      		
                                      
                                        
-

                                      		
                                    

                                  
                                

                                
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 the set of attributes types
                                    which are indicated for a given AS 

                                    are appropriate to him or not and
                                    then select that AS if it has a
                                    relationship with it.

                                
In this example, one
                                    mathematical expression for the
                                    combination of conditions using AND
                                    and OR operators is "Condition
                                        3 OR
                                      Condition
                                        4", 

                                        which means that
                                    some types of attributes from AS
                                    4 AND
                                    some other types of attributes from
                                    AS 9 are both needed by RSx to
                                    perform on RSx 

                                    either the Operation A or the
                                    Operation Z. 

                                
In this example, RS 1
                                    and AS 4 have established a
                                    bilateral relationship (and have
                                    agreed to define and use scope
                                    identifiers) 

                                    whereas RS 1 and AS 9 have not
                                    established any bilateral
                                    relationship prior to the exchange.
                                    

                                  

                                
The user makes up his
                                    mind whether the attributes
                                    requested by AS 1 and AS 9 are
                                    reasonable and if so, requests two
                                    access tokens: 

                                    one to AS 4 and another one to AS 9.

                                
For AS 4, the
                                    client shall use the scope
                                    identifier with the value 21.

                                    For AS 9, the client shall use the
                                    set 3 of attributes types indicated
                                    in the Condition 4.

                                
In order to save one
                                    exchange, a RS could publicly
                                    publish how its clients can
                                    authenticate. 

                                    However,  it is also possible to
                                    consider no guidance at all: in such
                                    a case, using "out-of-bands" means,
                                    the clients should know how to
                                    authenticate.

                                
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

                    

                  

                

                

              

            

            


            

          

        

      

    

    


    

  


--------------F0FB495A4A776B72668E1E45--


From nobody Wed Jul  8 00:26: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 D143A3A0BFC for ; Wed,  8 Jul 2020 00:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level: 
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=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 cT_v9p9hNt7v for ; Wed,  8 Jul 2020 00:26:17 -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 DEEF43A0BFA for ; Wed,  8 Jul 2020 00:26:15 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d53 with ME id 0XSB2300G4FMSmm03XSCYZ; Wed, 08 Jul 2020 09:26:13 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 08 Jul 2020 09:26:13 +0200
X-ME-IP: 86.238.65.197
To: Tobias Looker , Justin Richer 
Cc: txauth@ietf.org
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <6846D2F0-5096-404B-A529-676146392F45@mit.edu> 
From: Denis 
Message-ID: <0ed145bc-0a2a-02cb-eeaa-f0a5ab6610f9@free.fr>
Date: Wed, 8 Jul 2020 09:26: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="------------DC77D43A5C13D9BCEC1700D0"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 08 Jul 2020 07:26:21 -0000

This is a multi-part message in MIME format.
--------------DC77D43A5C13D9BCEC1700D0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Justin and Tobias,

A capability would include an identifier of both the granted 
operation(s) and the RS:
it allows the AS to know which operation(s) may be performed by the 
client and on which resource.
Since the AS knows who the client is, it is able to trace all its 
operations.
This would be a perfect "Big Brother by design" construction.

At the moment ZCAP-LD (Authorization Capabilities for Linked Data) is a 
"/draft /community group report" published in May 2020.
It is not a W3C Standard nor it is on the W3C Standards Track.

Tobias you believe that "establishing the ability to bind an 
access_token (capability) to the party that should be able to use it 
(invoker)" is a "must have".
This is indeed very important and this point is mentioned in the very 
last sentence of the above draft in section B : Handling abuse.

    Alice realizes that the abuse is coming from the invocation of a
    capability granted to some of Mallet's authentication *material*,
    and Alyssa revokes that capability.

While revoking a capability does not really make sense, checking that 
the access_token is indeed presented by the right invoker is necessary.
One way or another, a secure element needs to be used by the invoker.

Coming back to the topic of this thread which is about "Directed 
Tokens", my belief is that supporting delegation using "AS-based 
directed tokens"
would allow ASs to act as Big Brother. If there is another solution to 
support delegation (and there is one candidate) then it should be used.

Denis

> I've also been thinking about the parallels between ZCAP's and 
> OAuth2.0 access tokens. To me a ZCAP is a less opaque, semantically 
> richer capability format, whereas an access_token is traditionally 
> much simpler. The key here though is I still see an access_token as a 
> form of capability. It appears in general one of the trade offs we 
> will be faced with is either:
>
> 1. Keeping the capability received from a GNAP flow (e.g an 
> access_token) opaque to the client and externalizing any greater 
> information about how to use the capability (such as in your proposal 
> in the first email of this thread).
> 2. Internalizing information about the capabilities utility and any 
> greater context about it which means the capability is no longer opaque.
>
> With that aside, the notable features in general I would like GNAP to 
> consider from ZCAP's, are the following.
>
> - Delegatable capabilities (bonus if this mechanism includes the 
> ability to attenuate during delegation) - Consider the example where a 
> client or RP (RP1) receives some form of access_token (capability) 
> from an AS and would like to delegate this to another RP (RP2) so they 
> can access the same resources. If including attenuation this would 
> mean that during this delegation (RP1->RP2), RP1 could narrow the 
> scope of the original access it received so that RP2 only gets a 
> subset of the original scope.
> - Bound capabilities - Similar in some ways to dPop, essentially 
> establishing the ability to bind an access_token (capability) to the 
> party that should be able to use it (invoker). I see this as a must 
> have in order to be able to do attenuated delegation as described above.
>
> Thanks,
> Mattr website  		
> *Tobias Looker*
> Mattr
> +64 (0) 27 378 0461
> tobias.looker@mattr.global 
> Mattr website  	Mattr on LinkedIn 
>  	Mattr on Twitter 
>  	Mattr on Github 
> 
>
>
> This communication, including any attachments, is confidential. If you 
> are not the intended recipient, you should not read it - please 
> contact me immediately, destroy it, and do not copy or use any part of 
> this communication or disclose anything about it. Thank you. Please 
> note that this communication does not designate an information system 
> for the purposes of the Electronic Transactions Act 2002.
>
>
> On Wed, Jul 8, 2020 at 8:39 AM Justin Richer  > wrote:
>
>     I’ve been thinking more about these use cases, and it might help
>     us to think of GNAP’s access tokens as capabilities in the
>     computer security sense — but more specifically, capabilities that
>     are delivered with their own context for use. In that way, an
>     otherwise naive client can be handed an access token and simply
>     know exactly what to do with it. This context would be delivered
>     alongside the token, so the token material itself remains opaque
>     to the client.
>
>     I wanted to bring up a W3C spec for a capabilities model based on
>     linked data:
>
>     https://w3c-ccg.github.io/zcap-ld/
>
>     Building a fully featured capabilities context is difficult, at
>     the very least. And unfortunately, I don’t think this spec
>     actually gives us any viable solutions to work with. In particular
>     the “actions” section is effectively blank, offloading the work to
>     an external JSONLD process (side note, this is one of the problems
>     I have with specs based on JSONLD, they externalize the important
>     parts into local contexts and break interoperability — but I
>     digress). But at least it’s another way of looking at the problem
>     space that might be outside the familiar zone of many of the OAuth
>     world.
>
>      — Justin
>
>>     On Jun 26, 2020, at 9:23 AM, Justin Richer >     > wrote:
>>
>>     On Jun 25, 2020, at 9:07 PM, Tobias Looker
>>     >
>>     wrote:
>>>
>>>     I find this feature interesting and think it could be an
>>>     important pattern going forward to enable an AS to be able to
>>>     describe the utility of a token to the client, however as
>>>     already pointed out in the thread I think there is some
>>>     potential hidden complexity that would need to be ironed out
>>>     such that it does not make the simple things complicated.
>>>
>>>     Justin, do you see this feature as something the client has to
>>>     explicitly request, i.e "please give me access and instructions
>>>     on how to use my access" or rather that the AS would just return
>>>     this information in conjunction with the access token if it had
>>>     it available?
>>>
>>
>>     This is something that I’d brought up as a possibility on the
>>     previous thread — something like a flag the client would set.
>>     This would be especially important if the AS wants to return
>>     multiple access tokens but the client requested 1, or the client
>>     requested N and the AS wants to return M in response. Basically
>>     any time there’s a mismatch, that’s extra complexity on the
>>     client that I really don’t think we want to be universal. A flag
>>     to turn that kind of direction and splitting on would be a
>>     potential start. But there are potential snags here too, and it
>>     comes down to how you manage the defaults...
>>
>>>     > This is just the start, too. Things get even more complex if
>>>     the client can ask for multiple different kinds of resources at
>>>     once. What if the AS decides that the client needs a
>>>     hyper-focused directed token for one part of the API, but can
>>>     use a general token for other stuff? Can it signal that to the
>>>     client? And if it can, does that mean that all clients need to
>>>     be prepared for that kind of thing?
>>>
>>>     Would a potential default be that if a client did for any reason
>>>     not support processing the additional information returned with
>>>     the access_token, just to ignore it? I think in the spirit of
>>>     keeping the simple things simple, this potentially makes sense?
>>
>>     That’s the real trick, if you ask me. It has to be :safe: for a
>>     client to ignore this information. Which means the AS can’t rely
>>     on the client “doing the right thing” with the information in the
>>     “token directions” portion of the response. Even setting aside
>>     the advanced and related “split tokens” idea above, we need to
>>     make sure that an AS/RS setup is built such that if the AS tells
>>     a client “only do X with your token” and the client does “Y”,
>>     then there are other protections and practices in place to
>>     prevent things from going haywire if the client does “Y” either
>>     by accident or through ignorance.
>>
>>     If OAuth 2 has taught us anything, it’s that client applications
>>     are going to be the laziest participants in the security model.
>>     And that makes sense, really — security isn’t what the client
>>     apps are trying to do, they’re trying to use the RS to do
>>     something. So we need to make sure that whatever system we design
>>     will fail on the safe side as much as possible, and keep things
>>     simple for the client.
>>
>>>
>>>     > here are some worked out samples of this:
>>>     https://wiki.idesg..org/wiki/index.php/High_Assurance_AZ_Token
>>>     
>>>     https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
>>>     Peace ..tom
>>>
>>>     As one of the authors of those mentioned drafts, I am interested
>>>     in discussing that, but perhaps on a seperate thread? As at
>>>     least the bound assertion spec is primarily concerned with
>>>     binding mechanisms for the artifacts produced from an
>>>     authorization flow (specifically identity claims), whereas I
>>>     think directed access tokens is just more generally talking
>>>     about whether GNAP should support an AS conveying how to use an
>>>     access_token it produces during a flow with a client.
>>>
>>
>>     I think that these are separate issues as well.
>>
>>      — Justin
>>
>>>     Thanks,
>>>     Mattr website  		
>>>     *Tobias Looker*
>>>     Mattr
>>>     +64 (0) 27 378 0461
>>>     tobias.looker@mattr.global 
>>>     Mattr website  	Mattr on LinkedIn
>>>      	Mattr on Twitter
>>>      	Mattr on Github
>>>     
>>>
>>>
>>>     This communication, including any attachments, is confidential.
>>>     If you are not the intended recipient, you should not read it -
>>>     please contact me immediately, destroy it, and do not copy or
>>>     use any part of this communication or disclose anything about
>>>     it. Thank you. Please note that this communication does not
>>>     designate an information system for the purposes of the
>>>     Electronic Transactions Act 2002.
>>>
>>>
>>>     On Wed, Jun 24, 2020 at 10:14 PM Denis >>     > wrote:
>>>
>>>         Justin, I fear we are still far away from an agreement about
>>>         what this BoF should do.
>>>
>>>         Tom Jones is saying " I am getting tired of the whack-a-mole
>>>         approach ..."
>>>
>>>         I don't agree with you when you write: "I think it’s going
>>>         to be overwhelmingly common that a given RS is going to
>>>         trust exactly one AS
>>>         that it knows about ahead of time". Such an architecture
>>>         would have exactly the same limitations as OAuth 2.0. and
>>>         would not be scalable.
>>>
>>>         Before we start, we should have a clear view of the whole
>>>         picture rather than starting from one scenario and expanding
>>>         it in many different directions.
>>>         For building an architecture, a pre-requirement is to define
>>>         ALL the trust relationships. I don't believe that we have an
>>>         agreement at this time on what
>>>         these trust relationships are.
>>>
>>>         You are also using the following wording: "methods for the
>>>         AS and RS to communicate what the token’s good for".
>>>         With such a paradigm, it would be impossible to protect the
>>>         user's privacy.
>>>
>>>         A key question is : Will GNAP take care of the user's
>>>         privacy or will GNAP*prevent*to take care of the user's
>>>         privacy ?
>>>
>>>         About "the ability for the client to get several access
>>>         tokens to get different resources from one request" is
>>>         indeed a complex case.
>>>
>>>         No one (including ASs) is able to predict in advance which
>>>         access tokens will be needed, since they depend upon the
>>>         kind of operation(s)
>>>         the client will be willing to perform. For privacy reasons,
>>>         ASs should be kept ignorant of all the operations that a
>>>         client is going to perform
>>>         on one or more resource servers. I believe that every effort
>>>         should be made to avoid the AS to be in a position to be
>>>         able to trace the operations
>>>         performed by its clients on various RSs.
>>>
>>>         To handle the complex case you envision, the full workflow
>>>         of operations needs to be considered with a detailed focus
>>>         on the time
>>>         at which the user's*consent and choice*happens (/consent and
>>>         choice/is the first privacy principle from ISO 29100).
>>>
>>>         First of all, an access token could be targeted to a service
>>>         rather than to a server. This would already solve many cases.
>>>
>>>         When a RS needs to call another RS (which does not support
>>>         the same service) then the client should be informed by the
>>>         first RS.
>>>         His "consent and choice" should then be obtained by the
>>>         first RS and, when the user agrees, the client should then
>>>         ask an access token
>>>         to one of the ASs trusted by the second RS in order to
>>>         perform the subsequent operation.
>>>
>>>         Denis
>>>
>>>         PS.  In an email sent on June 23 you wrote: " I think an
>>>         on-device AS is an important use case".  I am sorry, but I
>>>         don't understand.
>>>                However, I do understand what "a server-based AS" is.
>>>
>>>
>>>>         Denis, thanks for the great comments. I think that your
>>>>         trust model is pretty different from what I’d laid out
>>>>         initially, and while it’s an interesting and important one,
>>>>         it is not what I meant by “multiple access tokens” in my
>>>>         discussion below. I think that might be the cause of some
>>>>         disconnect here, but that doesn’t mean it’s out of reach
>>>>         for what the WG is after.
>>>>
>>>>         When I refer to multiple access tokens, and what the
>>>>         charter calls out as multiple access tokens, is the ability
>>>>         for the client to get several access tokens to get
>>>>         different resources from one request. I personally see this
>>>>         as an optimization of a specific set of use cases, some of
>>>>         which I discussed in my original email. There are others,
>>>>         I’m sure, but all the ones I’ve seen are around the client
>>>>         needing to get several different kinds of access through an
>>>>         AS.
>>>>
>>>>         I think it’s going to be overwhelmingly common that a given
>>>>         RS is going to trust exactly one AS that it knows about
>>>>         ahead of time. But for RS’s that can trust multiple AS’s,
>>>>         then we should have a model that can accommodate that as
>>>>         well. That’s why the charter calls out methods for the AS
>>>>         and RS to communicate what the token’s good for. I think
>>>>         the basis of those methods is going to start with a common
>>>>         token model, and likely incorporate into things like token
>>>>         formats and introspection-style token APIs.
>>>>
>>>>          — Justin
>>>>
>>>>>         On Jun 22, 2020, at 3:55 AM, Denis >>>>         > wrote:
>>>>>
>>>>>         Hello Justin,
>>>>>
>>>>>         A few comments between the lines.
>>>>>
>>>>>>         One of the most important aspects to GNAP is going to be
>>>>>>         an ability to address things that OAuth 2 can’t, or at
>>>>>>         least can’t do without significant gymnastics. So with
>>>>>>         that, I wanted to bring back a use case discussion that
>>>>>>         originally came up while we were talking about the
>>>>>>         possibility of multiple access tokens, a few months back.
>>>>>>         I don’t know if this concept has a regular term, so I’m
>>>>>>         going to call it “directed access tokens” until we come
>>>>>>         up with something better — assuming we decide this is
>>>>>>         worthwhile.
>>>>>
>>>>>         I don't understand what may mean "directed access tokens”
>>>>>         but I understand what means "multiple access tokens".
>>>>>         When speaking of "multiple access tokens", these access
>>>>>         tokens may come from one or more ASs.
>>>>>
>>>>>>         In OAuth, the client’s supposed to always know where to
>>>>>>         send its access token, and that knowledge is completely
>>>>>>         outside the protocol. This makes a lot of sense for many
>>>>>>         (if not most) deployments, as OAuth is really there to
>>>>>>         enable the API access that the client already knows about.
>>>>>>
>>>>>>         But we’re now in a world where a client could be talking
>>>>>>         to a generic API that could be deployed at a number of
>>>>>>         different places, or a cloud deployment that the AS wants
>>>>>>         to be able to dispatch the client to.
>>>>>
>>>>>         As soon the AS is placed (again) at the centre of the
>>>>>         model, the AS will have the ability to act as "Big Brother".
>>>>>         OAuth 2.0 has not taken care of privacy issues. On the
>>>>>         contrary, GNAP should take care of them.
>>>>>
>>>>>>         In order to do this, the AS needs to be able to
>>>>>>         communicate to the client not only the token information
>>>>>>         (and any related key and presentation information), but
>>>>>>         also a set of/directions/ about what that specific token
>>>>>>         is good for. This needs to be information outside the
>>>>>>         token itself, since I believe we want to keep OAuth 2’s
>>>>>>         feature of having the token be opaque to the client.
>>>>>>         Note: while we could map all of these to different
>>>>>>         resource requests (in XYZ parlance) or scopes (in OAuth 2
>>>>>>         legacy parlance) on the request side, this isn’t enough
>>>>>>         to tell the client what to do with the token/if it
>>>>>>         doesn’t know already/.
>>>>>>
>>>>>>         I know of two use cases already in the wild, where people
>>>>>>         are addressing things using a mix of existing standards
>>>>>>         and some proprietary extensions to address things within
>>>>>>         their silos. I’ll try to summarize here, but I know the
>>>>>>         folks I’ve been talking to about this are also on the
>>>>>>         list so hopefully they can chime in with more detail or
>>>>>>         any corrections for something I’ve missed.
>>>>>>
>>>>>>         (1) The client knows what resource it’s calling, but it
>>>>>>         doesn’t know where it’s hosted. Everything is in a single
>>>>>>         security domain controlled by the AS,
>>>>>
>>>>>         Speaking of "multiple access tokens" is in contradiction
>>>>>         with single security domain "controlled" by an AS.
>>>>>         A user may need to demonstrate some of his identity
>>>>>         attributes granted e.g. by his bank but may also
>>>>>         need to demonstrate one or more diplomas granted by one or
>>>>>         more universities. The bank cannot be
>>>>>         the "primary issuer" of a university diploma. It should
>>>>>         not be either a "secondary issuer", because
>>>>>         the bank does not "/need to know"/what are the diplomas of
>>>>>         the user.
>>>>>
>>>>>>         but the AS needs to decide at runtime which specific
>>>>>>         instance of the API to direct the client to. Since things
>>>>>>         are closely tied together, the client just needs to
>>>>>>         effectively known an identifier for the RS, and this is
>>>>>>         currently implemented as a URI. Once the client has that
>>>>>>         identifier, it knows how to dispatch that token to that
>>>>>>         instance of the RS.
>>>>>
>>>>>         There is no good reason why the AS should be involved in
>>>>>         that step.
>>>>>         OAuth 2.0 is/was implicitly mandating a strong
>>>>>         relationship between ASs and RSs which makes it non scalable.
>>>>>         GNAP should be based on a simple trust relationship : a
>>>>>         given RS trusts some ASs for access tokens that contains
>>>>>         some types of attributes.
>>>>>         An AS should not need to know in advance (or even at the
>>>>>         time of an access token request) the RSs that are trusting it.
>>>>>
>>>>>         A client could first talk to a "global service provider"
>>>>>         which has the knowledge of the different RSs affiliated to it.
>>>>>
>>>>>>         (2) The client knows what kind of thing it’s looking for,
>>>>>>         but doesn’t know who to ask it from.
>>>>>
>>>>>         Once again, the client could first talk to a "global
>>>>>         service provider" which has the knowledge of the different
>>>>>         RSs affiliated to it.
>>>>>
>>>>>>         There’s a cross-domain trust that’s bridged by the AS,
>>>>>>         and the AS needs to dispatch to different resources
>>>>>>         depending on which user logged in (and possibly what the
>>>>>>         user consented to). To make things more concrete, the
>>>>>>         client needs to get driver’s license information, but
>>>>>>         doesn’t know ahead of time which of the many
>>>>>>         state/provincial bureaus to call to get that information
>>>>>>         because it doesn’t know yet who the user is.
>>>>>
>>>>>         When a user has a driving license, he knows its issuer.
>>>>>         The user can then provide some hint to the client.
>>>>>
>>>>>>         The AS will know who the user is once they log in and
>>>>>>         approve things, and so it can direct the client to call
>>>>>>         the correct RS. Since this is a relatively simple API
>>>>>>         with a pre-negotiated cross-domain trust, the AS returns
>>>>>>         a URL that the client presents the token at.
>>>>>
>>>>>          A single AS should not be aware of all the attributes a
>>>>>         user has.
>>>>>
>>>>>>
>>>>>>         As far as I know, in both of these cases, the token is
>>>>>>         only good for that API and not others — but more on that
>>>>>>         later.
>>>>>>
>>>>>>         A simple thing to do is just give back a URL with the
>>>>>>         access token, which tells the client where to go.
>>>>>>
>>>>>>         {
>>>>>>         “access_token”: {
>>>>>>         “value”: “87yui843yfer”,
>>>>>>         “resource_uri”: “https://example/foo"
>>>>>>         }
>>>>>>         }
>>>>>>
>>>>>>         This is good for some kinds of APIs, but it’s limiting
>>>>>>         because not all APIs dispatch based on the URL. An AS
>>>>>>         might want to divvy up access tokens to an API that’s
>>>>>>         keyed on headers, or verbs, or any number of things. And
>>>>>>         it doesn’t tell us immediately what to do about non-exact
>>>>>>         URL matches. Can the client add query parameters and
>>>>>>         still use the token? What about path segments? I like
>>>>>>         that this simple approach addresses some common
>>>>>>         deployments that we already see today (see above), it’s
>>>>>>         not universal. Do we want or need a universal description
>>>>>>         language for directing where tokens go?
>>>>>>
>>>>>>         This also opens up a whole new set of security questions.
>>>>>>         If the AS can now direct the client where to use the
>>>>>>         token, could a rogue AS convince a legit client to use a
>>>>>>         stolen token at the wrong RS? And what if the client
>>>>>>         ignores the directions from the AS entirely? Could this
>>>>>>         open up new avenues of attack?
>>>>>>
>>>>>>         This is just the start, too. Things get even more complex
>>>>>>         if the client can ask for multiple different kinds of
>>>>>>         resources at once. What if the AS decides that the client
>>>>>>         needs a hyper-focused directed token for one part of the
>>>>>>         API, but can use a general token for other stuff? Can it
>>>>>>         signal that to the client? And if it can, does that mean
>>>>>>         that all clients need to be prepared for that kind of thing?
>>>>>>
>>>>>>         I firmly believe that whatever we build in GNAP, we need
>>>>>>         to optimize for the overwhelmingly common use case of a
>>>>>>         client getting a single access token to call APIs that it
>>>>>>         already knows about. Anything we add on top of that
>>>>>>         really can’t get in the way of this, because if it does,
>>>>>>         there’s very small chance that people will try to use
>>>>>>         this for everyday things. Keep the simple things simple,
>>>>>>         and the complex things possible, after all.
>>>>>>
>>>>>>         I’m really looking forward to hearing what the community
>>>>>>         thinks about these use cases, and hopefully the people
>>>>>>         I’ve chatted with offline about this can join the
>>>>>>         conversation and provide more light than I was able to.
>>>>>
>>>>>         The two use cases which are considered above are:
>>>>>
>>>>>             (1) The client knows what resource it’s calling, but
>>>>>             it doesn’t know where it’s hosted.
>>>>>             (2) The client knows what kind of thing it’s looking
>>>>>             for, but doesn’t know who to ask it from.
>>>>>
>>>>>         That does not mean in any way that these two use cases
>>>>>         should be solved by placing the AS at the centre of the
>>>>>         solution.
>>>>>
>>>>>         Denis
>>>>>
>>>>>>
>>>>>>          — Justin
>>>>>>
>>>>>
>>>>>         --
>>>>>         Txauth mailing list
>>>>>         Txauth@ietf.org 
>>>>>         https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>
>>>         --
>>>         Txauth mailing list
>>>         Txauth@ietf.org 
>>>         https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>>     This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
>>
>>     --
>>     Txauth mailing list
>>     Txauth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/txauth
>
>
> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
>


--------------DC77D43A5C13D9BCEC1700D0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Justin and Tobias,

    


    

    
A capability would include an
      identifier of both the granted operation(s) and the RS: 

      it allows the AS to know which operation(s) may be performed by
      the client and on which resource.

      Since the AS knows who the client is, it is able to trace all its
      operations. 

      This would be a perfect "Big Brother by design" construction.

    


    

    
At the moment ZCAP-LD (Authorization
      Capabilities for Linked Data) is a "draft community group
      report" published in May 2020. 

      It is not a W3C Standard nor it is on the W3C Standards Track.

    


    

    
Tobias you believe that "establishing
      the ability to bind an access_token (capability) to the party that
      should be able to use it (invoker)" is a "must have".

    
This is indeed very important and this
      point is mentioned in the very last sentence of the above draft in
      section B : Handling abuse.

    

    

      
Alice realizes that the abuse is
        coming from the invocation of a capability granted to some of
        Mallet's authentication material, 

        and Alyssa revokes that capability. 

      

    

    
While revoking a capability does not
      really make sense, checking that the access_token is indeed
      presented by the right invoker is necessary. 

      One way or another, a secure element needs to be used by the
      invoker. 

    

    


    

    
Coming back to the topic of this thread
      which is about "Directed Tokens", my belief is that supporting
      delegation using "AS-based directed tokens" 

      would allow ASs to act as Big Brother. If there is another
      solution to support delegation (and there is one candidate) then
      it should be used.

    

    


    

    Denis

    


    

    

      
      
I've also been thinking about the parallels between
        ZCAP's and OAuth2.0 access tokens. To me a ZCAP is a less
        opaque, semantically richer capability format, whereas an
        access_token is traditionally much simpler. The key here though
        is I still see an access_token as a form of capability. It
        appears in general one of the trade offs we will be faced with
        is either:
        


        

        
1. Keeping the capability received from a GNAP flow (e.g an
          access_token) opaque to the client and externalizing any
          greater information about how to use the capability (such as
          in your proposal in the first email of this thread).

        
2. Internalizing information about the capabilities utility
          and any greater context about it which means the capability is
          no longer opaque.

        

          


          

          
With that aside, the notable features in general I would
            like GNAP to consider from ZCAP's, are the following.
            


            

            
- Delegatable capabilities (bonus if this mechanism
              includes the ability to attenuate during delegation) -
              Consider the example where a client or RP (RP1)
              receives some form of access_token (capability) from an AS
              and would like to delegate this to another RP (RP2) so
              they can access the same resources. If including
              attenuation this would mean that during this delegation
              (RP1->RP2), RP1 could narrow the scope of the original
              access it received so that RP2 only gets a subset of the
              original scope.

            
- Bound capabilities - Similar in some ways to dPop,
              essentially establishing the ability to bind an
              access_token (capability) to the party that should be able
              to use it (invoker). I see this as a must have in order to
              be able to do attenuated delegation as described above.
              

                

                  

                    


                    

                    
Thanks,

                      

                        
                          

                            Mattr
                                  website
                             
                            
                              

                                
                                  

                                    Tobias
                                        Looker

                                    		
                                  

                                  

                                    Mattr
                                  

                                  

                                    +64
                                      (0) 27 378 0461

                                      tobias.looker@mattr.global		
                                  

                                  

                                    
                                      

                                        
                                          

                                            Mattr website
                                            Mattr on
                                                  LinkedIn
                                            Mattr on
                                                  Twitter
                                            Mattr on
                                                  Github
                                          

                                        
                                      

                                    		
                                  

                                
                              

                            		
                          

                        
                      

                      

                      This
                        communication, including any attachments, is
                        confidential. If you are not the intended
                        recipient, you should not read it - please
                        contact me immediately, destroy it, and do not
                        copy or use any part of this communication or
                        disclose anything about it. Thank you. Please
                        note that this communication does not designate
                        an information system for the purposes of the
                        Electronic Transactions Act 2002.

                    

                  

                

                

              

            

          

        

      

      

      

        
On Wed, Jul 8, 2020 at 8:39 AM
          Justin Richer <jricher@mit.edu> wrote:

        

        

          
I’ve been thinking
            more about these use cases, and it might help us to think of
            GNAP’s access tokens as capabilities in the computer
            security sense — but more specifically, capabilities that
            are delivered with their own context for use. In that way,
            an otherwise naive client can be handed an access token and
            simply know exactly what to do with it. This context would
            be delivered alongside the token, so the token material
            itself remains opaque to the client.
            


            

            
I wanted to bring up a W3C spec for a capabilities
              model based on linked data:
              


              

              
              


              

              
Building a fully featured capabilities context is
                difficult, at the very least. And unfortunately, I don’t
                think this spec actually gives us any viable solutions
                to work with. In particular the “actions” section is
                effectively blank, offloading the work to an external
                JSONLD process (side note, this is one of the problems I
                have with specs based on JSONLD, they externalize the
                important parts into local contexts and break
                interoperability — but I digress). But at least it’s
                another way of looking at the problem space that might
                be outside the familiar zone of many of the OAuth world.

              


              

              
 — Justin

                


                  

                    
On Jun 26, 2020, at 9:23 AM, Justin Richer <jricher@mit.edu>
                      wrote:

                    

                    
On
                        Jun 25, 2020, at 9:07 PM, Tobias Looker <tobias.looker@mattr.global>
                        wrote:

                      

                        


                          

                            
I find this feature
                              interesting and think it could be an
                              important pattern going forward to enable
                              an AS to be able to describe the utility
                              of a token to the client, however as
                              already pointed out in the thread I think
                              there is some potential hidden complexity
                              that would need to be ironed out such that
                              it does not make the simple things
                              complicated.
                              


                              

                              
Justin, do you see this feature as
                                something the client has to explicitly
                                request, i.e "please give me access and
                                instructions on how to use my access" or
                                rather that the AS would just return
                                this information in conjunction with the
                                access token if it had it available?

                              


                              

                            

                          

                        

                        


                        

                        
This is something that I’d brought up as a
                          possibility on the previous thread — something
                          like a flag the client would set. This would
                          be especially important if the AS wants to
                          return multiple access tokens but the client
                          requested 1, or the client requested N and the
                          AS wants to return M in response. Basically
                          any time there’s a mismatch, that’s extra
                          complexity on the client that I really don’t
                          think we want to be universal. A flag to turn
                          that kind of direction and splitting on would
                          be a potential start. But there are potential
                          snags here too, and it comes down to how you
                          manage the defaults...

                        

                        

                          

                            

                              
> This is just the start, too.
                                Things get even more complex if the
                                client can ask for multiple different
                                kinds of resources at once. What if the
                                AS decides that the client needs a
                                hyper-focused directed token for one
                                part of the API, but can use a general
                                token for other stuff? Can it signal
                                that to the client? And if it can, does
                                that mean that all clients need to be
                                prepared for that kind of thing?

                              


                              

                              
Would a potential default be that if
                                a client did for any reason not support
                                processing the additional information
                                returned with the access_token, just to
                                ignore it? I think in the spirit of
                                keeping the simple things simple, this
                                potentially makes sense?

                            

                          

                        

                        


                        

                        
That’s the real trick, if you ask me. It
                          has to be :safe: for a client to ignore this
                          information. Which means the AS can’t rely on
                          the client “doing the right thing” with the
                          information in the “token directions” portion
                          of the response. Even setting aside the
                          advanced and related “split tokens” idea
                          above, we need to make sure that an AS/RS
                          setup is built such that if the AS tells a
                          client “only do X with your token” and the
                          client does “Y”, then there are other
                          protections and practices in place to prevent
                          things from going haywire if the client does
                          “Y” either by accident or through ignorance. 

                        


                        

                        
If OAuth 2 has taught us anything, it’s
                          that client applications are going to be the
                          laziest participants in the security model.
                          And that makes sense, really — security isn’t
                          what the client apps are trying to do, they’re
                          trying to use the RS to do something. So we
                          need to make sure that whatever system we
                          design will fail on the safe side as much as
                          possible, and keep things simple for the
                          client.

                        

                        

                          

                            

                              


                              

                              
> here are some worked out samples
                                of this:

                              
                              
                              

                                

                                  

                                    
Peace ..tom

                                    


                                    

                                    
As one of the authors of those
                                      mentioned drafts, I am interested
                                      in discussing that, but perhaps on
                                      a seperate thread? As at least the
                                      bound assertion spec
                                      is primarily concerned with
                                      binding mechanisms for the
                                      artifacts produced from an
                                      authorization flow (specifically
                                      identity claims), whereas I think
                                      directed access tokens is just
                                      more generally talking about
                                      whether GNAP should support an AS
                                      conveying how to use an
                                      access_token it produces during a
                                      flow with a client.

                                  

                                

                              

                              


                              

                            

                          

                        

                        


                        

                        
I think that these are separate issues as
                          well.

                        


                        

                        
 — Justin

                        

                        

                          

                            

                              

                                

                                  

                                    
Thanks,

                                      

                                        
                                          

                                            Mattr
                                                  website
                                             
                                            
                                              

                                                
                                                  

                                                    Tobias
                                                        Looker

                                                    		
                                                  

                                                  

                                                    Mattr
                                                  

                                                  

                                                    +64
                                                      (0) 27 378 0461

                                                      tobias.looker@mattr.global		
                                                  

                                                  

                                                    
                                                      

                                                        
                                                          

                                                          Mattr
                                                          website
                                                          Mattr on
                                                          LinkedIn
                                                          Mattr on
                                                          Twitter
                                                          Mattr on
                                                          Github
                                                          

                                                        
                                                      

                                                    		
                                                  

                                                
                                              

                                            		
                                          

                                        
                                      

                                      

                                      This
                                        communication, including any
                                        attachments, is confidential. If
                                        you are not the intended
                                        recipient, you should not read
                                        it - please contact me
                                        immediately, destroy it, and do
                                        not copy or use any part of this
                                        communication or disclose
                                        anything about it. Thank you.
                                        Please note that this
                                        communication does not designate
                                        an information system for the
                                        purposes of the Electronic
                                        Transactions Act 2002.

                                    

                                  

                                

                                

                              

                            

                            

                            

                              
On Wed,
                                Jun 24, 2020 at 10:14 PM Denis <denis.ietf@free.fr>
                                wrote:

                              

                              

                                

                                  
Justin, I fear we are still far
                                    away from an agreement about what
                                    this BoF should do.

                                  


                                  

                                  
Tom Jones is saying " I am
                                    getting tired of the whack-a-mole
                                    approach ..."

                                  


                                  

                                  I don't agree with you when you write:
                                  "I think it’s going to be
                                  overwhelmingly common that a given RS
                                  is going to trust exactly one AS 

                                  
that it knows about ahead of
                                    time". Such an architecture would
                                    have exactly the same limitations as
                                    OAuth 2.0. and would not be
                                    scalable.

                                  


                                  

                                  

                                    
Before we start, we should have
                                      a clear view of the whole picture
                                      rather than starting from one
                                      scenario and expanding it in many
                                      different directions.

                                    
For building an architecture, a
                                      pre-requirement is to define ALL
                                      the trust relationships. I don't
                                      believe that we have an agreement
                                      at this time on what 

                                      these trust relationships are. 

                                  

                                  


                                  

                                  
You are also using the following
                                    wording: "methods for the AS and RS
                                    to communicate what the token’s good
                                    for". 

                                    With such a paradigm, it would be
                                    impossible to protect the user's
                                    privacy. 

                                  

                                  


                                  

                                  
A key question is : Will GNAP
                                    take care of the user's privacy or
                                    will GNAP prevent to
                                    take care of the user's privacy ?

                                  


                                  

                                  
About "the ability for the client
                                    to get several access tokens to get
                                    different resources from one
                                    request" is indeed a complex case.

                                  


                                  

                                  
No one (including ASs) is able to
                                    predict in advance which access
                                    tokens will be needed, since they
                                    depend upon the kind of operation(s) 

                                    the client will be willing to
                                    perform. For privacy reasons, ASs
                                    should be kept ignorant of all the
                                    operations that a client is going to
                                    perform 

                                    on one or more resource servers. I
                                    believe that every effort should be
                                    made to avoid the AS to be in a
                                    position to be able to trace the
                                    operations 

                                    performed by its clients on various
                                    RSs.

                                  


                                  

                                  
To handle the complex case you
                                    envision, the full workflow of
                                    operations needs to be considered
                                    with a detailed focus on the time 

                                    at which the user's consent
                                      and choice happens
                                    (consent and choice is
                                    the first privacy principle from ISO
                                    29100).

                                  


                                  

                                  
First of all, an access token
                                    could be targeted to a service
                                    rather than to a server. This would
                                    already solve many cases.

                                  


                                  

                                  
When a RS needs to call another
                                    RS (which does not support the same
                                    service) then the client should be
                                    informed by the first RS.

                                  
His "consent and choice" should
                                    then be obtained by the first RS
                                    and, when the user agrees, the
                                    client should then ask an access
                                    token 

                                    to one of the ASs trusted by the
                                    second RS in order to perform the
                                    subsequent operation.  

                                  

                                  


                                  

                                  
Denis

                                  


                                  

                                  
PS.  In an email sent on June 23
                                    you wrote: " I think an on-device AS
                                    is an important use case".  I am
                                    sorry, but I don't understand.

                                           However, I do understand what
                                    "a server-based AS" is.

                                  

                                  


                                  

                                  


                                  

                                  
Denis, thanks
                                    for the great comments. I think that
                                    your trust model is pretty different
                                    from what I’d laid out initially,
                                    and while it’s an interesting and
                                    important one, it is not what I
                                    meant by “multiple access tokens” in
                                    my discussion below. I think that
                                    might be the cause of some
                                    disconnect here, but that doesn’t
                                    mean it’s out of reach for what the
                                    WG is after.
                                    


                                    

                                    
When I refer to multiple access
                                      tokens, and what the charter calls
                                      out as multiple access tokens, is
                                      the ability for the client to get
                                      several access tokens to get
                                      different resources from one
                                      request. I personally see this as
                                      an optimization of a specific set
                                      of use cases, some of which I
                                      discussed in my original email.
                                      There are others, I’m sure, but
                                      all the ones I’ve seen are around
                                      the client needing to get several
                                      different kinds of access through
                                      an AS. 

                                      


                                      

                                      
I think it’s going to be
                                        overwhelmingly common that a
                                        given RS is going to trust
                                        exactly one AS that it knows
                                        about ahead of time. But for
                                        RS’s that can trust multiple
                                        AS’s, then we should have a
                                        model that can accommodate that
                                        as well. That’s why the charter
                                        calls out methods for the AS and
                                        RS to communicate what the
                                        token’s good for. I think the
                                        basis of those methods is going
                                        to start with a common token
                                        model, and likely incorporate
                                        into things like token formats
                                        and introspection-style token
                                        APIs. 

                                      


                                      

                                      
 — Justin

                                        


                                          

                                            
On Jun 22, 2020, at
                                              3:55 AM, Denis <denis.ietf@free.fr>
                                              wrote:

                                            

                                            

                                              
Hello
                                                Justin,

                                              


                                              

                                              
A
                                                few comments between the
                                                lines.

                                              


                                              

                                              
One
                                                of the most important
                                                aspects to GNAP is going
                                                to be an ability to
                                                address things that
                                                OAuth 2 can’t, or at
                                                least can’t do without
                                                significant gymnastics.
                                                So with that, I wanted
                                                to bring back a use case
                                                discussion that
                                                originally came up while
                                                we were talking about
                                                the possibility of
                                                multiple access tokens,
                                                a few months back. I
                                                don’t know if this
                                                concept has a regular
                                                term, so I’m going to
                                                call it “directed access
                                                tokens” until we come up
                                                with something better —
                                                assuming we decide this
                                                is worthwhile. 

                                              

                                              
I
                                                don't understand what
                                                may mean "directed
                                                access tokens” but I
                                                understand what means
                                                "multiple access
                                                tokens". 

                                                When speaking of
                                                "multiple access
                                                tokens", these access
                                                tokens may come from one
                                                or more ASs.

                                              

                                              

                                                
In OAuth, the
                                                  client’s supposed to
                                                  always know where to
                                                  send its access token,
                                                  and that knowledge is
                                                  completely outside the
                                                  protocol. This makes a
                                                  lot of sense for many
                                                  (if not most)
                                                  deployments, as OAuth
                                                  is really there to
                                                  enable the API access
                                                  that the client
                                                  already knows about.

                                                


                                                

                                                
But we’re now in a
                                                  world where a client
                                                  could be talking to a
                                                  generic API that could
                                                  be deployed at a
                                                  number of different
                                                  places, or a cloud
                                                  deployment that the AS
                                                  wants to be able to
                                                  dispatch the client
                                                  to. 

                                              

                                              
As
                                                soon the AS is placed
                                                (again) at the centre of
                                                the model, the AS will
                                                have the ability to act
                                                as "Big Brother".

                                                OAuth 2.0 has not taken
                                                care of privacy issues.
                                                On the contrary, GNAP
                                                should take care of
                                                them.

                                              

                                                
In order to do
                                                  this, the AS needs to
                                                  be able to communicate
                                                  to the client not only
                                                  the token information
                                                  (and any related key
                                                  and presentation
                                                  information), but also
                                                  a set of directions about
                                                  what that specific
                                                  token is good for.
                                                  This needs to be
                                                  information outside
                                                  the token itself,
                                                  since I believe we
                                                  want to keep OAuth 2’s
                                                  feature of having the
                                                  token be opaque to the
                                                  client. Note: while we
                                                  could map all of these
                                                  to different resource
                                                  requests (in XYZ
                                                  parlance) or scopes
                                                  (in OAuth 2 legacy
                                                  parlance) on the
                                                  request side, this
                                                  isn’t enough to tell
                                                  the client what to do
                                                  with the token if
                                                    it doesn’t know
                                                    already. 

                                                


                                                

                                                
I know of two use
                                                  cases already in the
                                                  wild, where people are
                                                  addressing things
                                                  using a mix of
                                                  existing standards and
                                                  some proprietary
                                                  extensions to address
                                                  things within their
                                                  silos. I’ll try to
                                                  summarize here, but I
                                                  know the folks I’ve
                                                  been talking to about
                                                  this are also on the
                                                  list so hopefully they
                                                  can chime in with more
                                                  detail or any
                                                  corrections for
                                                  something I’ve
                                                  missed. 

                                                


                                                

                                                
(1) The client
                                                  knows what resource
                                                  it’s calling, but it
                                                  doesn’t know where
                                                  it’s hosted.
                                                  Everything is in a
                                                  single security domain
                                                  controlled by the AS, 

                                              

                                              
Speaking
                                                of "multiple access
                                                tokens" is in
                                                contradiction with
                                                single security domain
                                                "controlled" by an AS. 

                                                A user may need to
                                                demonstrate some of his
                                                identity attributes
                                                granted e.g. by his bank
                                                but may also 

                                                need to demonstrate one
                                                or more diplomas granted
                                                by one or more
                                                universities. The bank
                                                cannot be 

                                                the "primary issuer" of
                                                a university diploma. It
                                                should not be either a
                                                "secondary issuer",
                                                because 

                                                the bank does not "need
                                                  to know" what
                                                are the diplomas of the
                                                user.

                                              

                                              

                                                
but the AS needs to
                                                  decide at runtime
                                                  which specific
                                                  instance of the API to
                                                  direct the client to.
                                                  Since things are
                                                  closely tied together,
                                                  the client just needs
                                                  to effectively known
                                                  an identifier for the
                                                  RS, and this is
                                                  currently implemented
                                                  as a URI. Once the
                                                  client has that
                                                  identifier, it knows
                                                  how to dispatch that
                                                  token to that instance
                                                  of the RS.

                                              

                                              
There
                                                is no good reason why
                                                the AS should be
                                                involved in that step. 

                                                OAuth 2.0 is/was
                                                implicitly mandating a
                                                strong relationship
                                                between ASs and RSs
                                                which makes it non
                                                scalable.

                                                GNAP should be based on
                                                a simple trust
                                                relationship : a given
                                                RS trusts some ASs for
                                                access tokens that
                                                contains some types of
                                                attributes.

                                                An AS should not need to
                                                know in advance (or even
                                                at the time of an access
                                                token request) the RSs
                                                that are trusting it.

                                              

                                              
A
                                                client could first talk
                                                to a "global service
                                                provider" which has the
                                                knowledge of the
                                                different RSs affiliated
                                                to it. 

                                              

                                              

                                                
(2) The client
                                                  knows what kind of
                                                  thing it’s looking
                                                  for, but doesn’t know
                                                  who to ask it from. 

                                              

                                              
Once
                                                again, the client could
                                                first talk to a "global
                                                service provider" which
                                                has the knowledge of the
                                                different RSs affiliated
                                                to it. 

                                              

                                                
There’s a
                                                  cross-domain trust
                                                  that’s bridged by the
                                                  AS, and the AS needs
                                                  to dispatch to
                                                  different resources
                                                  depending on which
                                                  user logged in (and
                                                  possibly what the user
                                                  consented to). To make
                                                  things more concrete,
                                                  the client needs to
                                                  get driver’s license
                                                  information, but
                                                  doesn’t know ahead of
                                                  time which of the many
                                                  state/provincial
                                                  bureaus to call to get
                                                  that information
                                                  because it doesn’t
                                                  know yet who the user
                                                  is. 

                                              

                                              
When
                                                a user has a driving
                                                license, he knows its
                                                issuer. The user can
                                                then provide some hint
                                                to the client.

                                              

                                                
The AS will know
                                                  who the user is once
                                                  they log in and
                                                  approve things, and so
                                                  it can direct the
                                                  client to call the
                                                  correct RS. Since this
                                                  is a relatively simple
                                                  API with a
                                                  pre-negotiated
                                                  cross-domain trust,
                                                  the AS returns a URL
                                                  that the client
                                                  presents the token at. 

                                                

                                              

                                              
 A
                                                single AS should not be
                                                aware of all the
                                                attributes a user has. 

                                              

                                              

                                                


                                                

                                                
As far as I know,
                                                  in both of these
                                                  cases, the token is
                                                  only good for that API
                                                  and not others — but
                                                  more on that later.

                                                


                                                

                                                
A simple thing to
                                                  do is just give back a
                                                  URL with the access
                                                  token, which tells the
                                                  client where to go. 

                                                


                                                

                                                
	{

                                                
		“access_token”:
                                                  {

                                                
			“value”:
                                                  “87yui843yfer”,

                                                
			“resource_uri”:
                                                  “https://example/foo"

                                                
		}

                                                
	}

                                                


                                                

                                                
This is good for
                                                  some kinds of APIs,
                                                  but it’s limiting
                                                  because not all APIs
                                                  dispatch based on the
                                                  URL. An AS might want
                                                  to divvy up access
                                                  tokens to an API
                                                  that’s keyed on
                                                  headers, or verbs, or
                                                  any number of things.
                                                  And it doesn’t tell us
                                                  immediately what to do
                                                  about non-exact URL
                                                  matches. Can the
                                                  client add query
                                                  parameters and still
                                                  use the token? What
                                                  about path segments? I
                                                  like that this simple
                                                  approach addresses
                                                  some common
                                                  deployments that we
                                                  already see today (see
                                                  above), it’s not
                                                  universal. Do we want
                                                  or need a universal
                                                  description language
                                                  for directing where
                                                  tokens go?

                                                


                                                

                                                
This also opens up
                                                  a whole new set of
                                                  security questions. If
                                                  the AS can now direct
                                                  the client where to
                                                  use the token, could a
                                                  rogue AS convince a
                                                  legit client to use a
                                                  stolen token at the
                                                  wrong RS? And what if
                                                  the client ignores the
                                                  directions from the AS
                                                  entirely? Could this
                                                  open up new avenues of
                                                  attack?

                                                


                                                

                                                
This is just the
                                                  start, too. Things get
                                                  even more complex if
                                                  the client can ask for
                                                  multiple different
                                                  kinds of resources at
                                                  once. What if the AS
                                                  decides that the
                                                  client needs a
                                                  hyper-focused directed
                                                  token for one part of
                                                  the API, but can use a
                                                  general token for
                                                  other stuff? Can it
                                                  signal that to the
                                                  client? And if it can,
                                                  does that mean that
                                                  all clients need to be
                                                  prepared for that kind
                                                  of thing?

                                                


                                                

                                                
I firmly believe
                                                  that whatever we build
                                                  in GNAP, we need to
                                                  optimize for the
                                                  overwhelmingly common
                                                  use case of a client
                                                  getting a single
                                                  access token to call
                                                  APIs that it already
                                                  knows about. Anything
                                                  we add on top of that
                                                  really can’t get in
                                                  the way of this,
                                                  because if it does,
                                                  there’s very small
                                                  chance that people
                                                  will try to use this
                                                  for everyday things.
                                                  Keep the simple things
                                                  simple, and the
                                                  complex things
                                                  possible, after all.

                                                


                                                

                                                
I’m really looking
                                                  forward to hearing
                                                  what the community
                                                  thinks about these use
                                                  cases, and hopefully
                                                  the people I’ve
                                                  chatted with offline
                                                  about this can join
                                                  the conversation and
                                                  provide more light
                                                  than I was able to.

                                              

                                              
The
                                                two use cases which are
                                                considered above are:

                                              

                                                
(1) The client knows
                                                  what resource it’s
                                                  calling, but it
                                                  doesn’t know where
                                                  it’s hosted.

                                                  (2) The client knows
                                                  what kind of thing
                                                  it’s looking for, but
                                                  doesn’t know who to
                                                  ask it from. 

                                                

                                              

                                              
That
                                                does not mean in any way
                                                that these two use cases
                                                should be solved by
                                                placing the AS at the
                                                centre of the solution.

                                              
Denis

                                              

                                                


                                                

                                                
 — Justin

                                                

                                                

                                              

                                              


                                              

                                              -- 

                                              Txauth
                                                mailing list

                                              Txauth@ietf.org

                                              https://www.ietf.org/mailman/listinfo/txauth

                                          

                                        

                                        

                                      

                                    

                                  

                                  


                                  

                                

                                -- 

                                Txauth mailing list

                                Txauth@ietf.org

                                https://www.ietf.org/mailman/listinfo/txauth

                              

                            

                            

                            
This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

                          

                        

                      

                      

                      -- 

                      Txauth
                        mailing list

                      Txauth@ietf.org

                      https://www.ietf.org/mailman/listinfo/txauth

                  

                

                

              

            

          

        

      

      

      
This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

      

      

    

    


    

  


--------------DC77D43A5C13D9BCEC1700D0--


From nobody Wed Jul  8 00:35: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 13FD03A0C05; Wed,  8 Jul 2020 00:35: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, 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 LDBHngmdP2d3; Wed,  8 Jul 2020 00:35:02 -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 A0DB83A0C06; Wed,  8 Jul 2020 00:35:02 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by mail.alkaline-solutions.com (Postfix) with ESMTPA id 34ECA38486F; Wed,  8 Jul 2020 07:35:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1594193701; 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=9X1DGIQ06ox3vyszEmsXkTftGdx89u4GHRyX8Rx+zBA=; b=rj3BZ0xYz7c3oTldR8wHZUorc8VK9y1YMjV5WXX7Tqk9FUdwxs70z87ptHX4daAtU+hrzU DrovXGjhMG3v8pJxpVvkoGya4CjZk/CKUysfkx6rA0I05vVSlbOWkZL3xmG2HKzjwYumjT lwUey7Np7fTxgNHIujDeAUAXfQvsZ60=
From: David Waite 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_900D127E-FE32-4A09-93FB-08A569E8952B"
Mime-Version: 1.0
Date: Wed, 8 Jul 2020 01:34:58 -0600
In-Reply-To: 
Cc: Dick Hardt , "rdd@cert.org" , "txauth@ietf.org" , Justin Richer , The IESG 
To: Denis 
References: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>   <46705E7E-D657-4CF1-80DA-0ADDFD6D8B41@mit.edu> <85b03911-d1c6-127f-2480-bfab4b94ffe2@free.fr>  
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1594193701; 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=9X1DGIQ06ox3vyszEmsXkTftGdx89u4GHRyX8Rx+zBA=; b=ileXKOM1VYlmw7jDKDWoJiccM99kny0IKZxg/iepJijm3eun6oyK0UZeA3l8CsIr6qISov 246GSZRIqBpTkuEcx6Zz3KX33sdMsg6bqUoAKDDNEtqd/2YK0kByjKeJ6F/LDrUe/2Dw7a r0x1bnxaD8rKLXT9ju+twcV+RoXjufA=
ARC-Seal: i=1; s=dkim; d=alkaline-solutions.com; t=1594193701; a=rsa-sha256; cv=none; b=ZuxDsoWXfy4f/69qQWyDnUHIOoQirQB9LOKys0RRB8R70GGeeGd1EQkbCsxu87Pna848nK za0/vnbY9Squpvz+Atf8cy8pWoy85iYXc+LEICT7k48gWhmZRcZzeMsX9bHARadm5X4Zb6 oUJU38/hkEAHgtuuQNEjGVruS1SCu+E=
ARC-Authentication-Results: i=1; mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
Authentication-Results: mail.alkaline-solutions.com; auth=pass smtp.auth=david@alkaline-solutions.com smtp.mailfrom=david@alkaline-solutions.com
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [Txauth] Support of FIDO and data minimization by RSs
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, 08 Jul 2020 07:35:04 -0000

--Apple-Mail=_900D127E-FE32-4A09-93FB-08A569E8952B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Jul 8, 2020, at 01:14, Denis  wrote:
>=20
> Hi Dick,
>=20
>> Denis: you seem to keep implying that other architectures don't =
preserve privacy. A couple counterpoints:
>>=20
>> Token opacity helps privacy in another dimension -- the client does =
not see the information about the user.
> The client is not an adversary to the user.
>=20
Both users and authorization servers may have a limited amount of trust =
in clients, which is a reason we have scopes to limit authorization and =
why we have consent to limit exposure of user data in the form of claims =
within the OpenID Connect extension.

The access token is a message about the client from the authorization =
server to the protected resource, about the authorization. This might =
include internal details which a client should not know, including =
internal information in the case where the authorization and protected =
resource are part of the same domain.

>> Many OAuth developments have self contained tokens. There is no token =
introspection call.=20
>> This, coupled with opaque tokens, is more privacy preserving than the =
client being able to peek in a token.
> When an access token contains personal information about a user, that =
user has the right to see that personal information.
>=20
However that does not mean that data has to be exposed to all third =
party clients without user consent. The sensitive data may also not be =
personal data in which case the user does not have a right to see it, =
even under request. Finally, tokens may be issued to entities without =
equivalent rights, such as hardware devices.


-DW




--Apple-Mail=_900D127E-FE32-4A09-93FB-08A569E8952B
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii



On Jul 8, 2020, at 01:14, Denis <denis.ietf@free.fr> wrote:


  
    
  
  

    
Hi Dick,

    


    

    

      
      
Denis: you seem to keep implying that other
        architectures don't preserve privacy. A couple counterpoints:
        


        

        
Token opacity helps privacy in another dimension -- the
          client does not see the information about the user.

      

    
The client is not an adversary to the user.
Both users and authorization servers may have a limited amount of trust in clients, which is a reason we have scopes to limit authorization and why we have consent to limit exposure of user data in the form of claims within the OpenID Connect extension.

The access token is a message about the client from the authorization server to the protected resource, about the authorization. This might include internal details which a client should not know, including internal information in the case where the authorization and protected resource are part of the same domain.


    

      

        

          
Many OAuth developments have self contained tokens. There
            is no token introspection call. 

            This, coupled with opaque tokens, is more privacy preserving
            than the client being able to peek in a token.

        

      

    
When an access token contains personal information about a user,
      that user has the right to see that personal information.
However that does not mean that data has to be exposed to all third party clients without user consent. The sensitive data may also not be personal data in which case the user does not have a right to see it, even under request. Finally, tokens may be issued to entities without equivalent rights, such as hardware devices.

    

-DW




--Apple-Mail=_900D127E-FE32-4A09-93FB-08A569E8952B--


From nobody Wed Jul  8 00: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 370E33A0C1F for ; Wed,  8 Jul 2020 00:53: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, 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 NRZKf1toXHpO for ; Wed,  8 Jul 2020 00:53:58 -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 E4EBC3A0C1C for ; Wed,  8 Jul 2020 00:53:54 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id o5so45902296iow.8 for ; Wed, 08 Jul 2020 00:53:54 -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=NuYGk/orGWdF8xFJx50ocr7eg1XOiheZZi9F1u5jM68=; b=KlMsGqzyt6ezPdVMcdYSGp0RVM6r/3qY2DXVns1ztYBgBoAeg+SfSk5oXycAdHxL2t UU/Act96Di2anonb75/jocOZgczo3YOF0+M2+xudU5X06Ynr0I4AKYRc38CzvU4NSs9c 6OOrZuCixwPsV4KFBv/QggOhUQrcacTW/nENg/Bs4VLWHcrfn/HxhPSVqo4QwVXVexko XH4tJc/q5tIsQYhdWfblbaiq1trYwoTvFKb4loXWz24vy2dKi2xXYbufQmad41ndX4OV tSFA8eqJBCmOivV1KRN1qABZLQoABGTqWVzCW8r9yLNo1+UGtfj1+yq4cgs54tG6jXOA fbDw==
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=NuYGk/orGWdF8xFJx50ocr7eg1XOiheZZi9F1u5jM68=; b=foBYgQ6LyKOw+nHOQ4G8JmbiaFxdFxrsyKYrpC0vMKOba9cU8jHDTLxeD1skUJl08g 4H7yNwWKhb9A0WUFtpLToS7MXCO8UNl7SHn5i3+fRm/9tNsv8qDtHJBboLtz20a5ZHpU OclQJOC8JIQZqnXHEEIB7lAsHneBEj9X+jdtqw3g9MDkFuoA4IXyJBdp8sKAnb00zVzl tm16gz9NbUO+jb1gGHYyuQLkstSDxBoSgptU7pUSz7NvFJbpeWTlDEcPSoLhF9ec8GF0 jGCVKoGwMq3IT2YlxrAEF2hKk/MMLb4RvE/ZBB2koq7tMlCxN9Rsojp7kLezMhry4MPg MD0w==
X-Gm-Message-State: AOAM531EVjxp0cHoSXHZTgLAEDCvx5o+t5Ky/eGLh2yfHP6wpJRGrdOJ gepfu//8TibGYY2rpcHAmb29RkyhFXhTkxTrfPJME75L
X-Google-Smtp-Source: ABdhPJxRVloLEUXLbrUxftiNvxqYrSQjH0BEzG/K8/xQhb7bgxljdsNAwIrUrqI7FZVN0UQhb2v5ZnLMqYzR1/mFTIM=
X-Received: by 2002:a5e:d90c:: with SMTP id n12mr34736072iop.144.1594194833951;  Wed, 08 Jul 2020 00:53:53 -0700 (PDT)
MIME-Version: 1.0
From: Fabien Imbault 
Date: Wed, 8 Jul 2020 09:53:39 +0200
Message-ID: 
To: Txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c7d07305a9e96821"
Archived-At: 
Subject: [Txauth] Use Case: Directed Tokens
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, 08 Jul 2020 07:53:59 -0000

--000000000000c7d07305a9e96821
Content-Type: text/plain; charset="UTF-8"

Hi Justin,

Following up on the capability discussion : indeed the pattern is
interesting and has demonstrated better security than traditional role
based access controls.
Note that the system itself is not bound to json-ld, so one may simply use
ocaps without the additional semantic layer. Still when defined as in zcap,
it remains quite easy to use. I understand some of your concerns, but
believe you should see json-ld as helping for interoperability (rather than
limiting), since it explicits the context in which it is used.

This line of work builds quite extensively on academia, and especially on
debates between T.B.Lee and M.Miller. But having recently worked on VC for
identity coupled with ocaps for access works like a charm, in practice.

More generally, the remarks made by Denis are interesting, even if we may
well encounter many other / more familiar scenarios too. So I agree that we
should stay open to these different views.

Fabien

--000000000000c7d07305a9e96821
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Justin,

F=
ollowing up on the capability discussion : indeed the pattern is interestin=
g and has demonstrated better security than traditional role based access c=
ontrols.
Note that the system itself is not bound to=
 json-ld, so one may simply use ocaps without the additional semantic layer=
. Still when defined as in zcap, it remains quite easy to use. I understand=
 some of your concerns, but believe you should see json-ld as helping for i=
nteroperability (rather than limiting), since it explicits the context in w=
hich it is used.=C2=A0

T=
his line of work builds quite extensively on academia, and especially on de=
bates between T.B.Lee and M.Miller. But having recently worked on VC for id=
entity coupled with ocaps for access works like a charm, in practice.=C2=A0=


More generally, the rem=
arks made by Denis are interesting, even if we may well encounter many othe=
r / more familiar scenarios too. So I agree that we should stay open to the=
se different views.=C2=A0

Fabien


--000000000000c7d07305a9e96821--


From nobody Wed Jul  8 01:48: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 501A53A0CAE for ; Wed,  8 Jul 2020 01:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 Zw4lpZBPOQNw for ; Wed,  8 Jul 2020 01:48:06 -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 25B473A0CB3 for ; Wed,  8 Jul 2020 01:48:05 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d33 with ME id 0Yo12300C4FMSmm03Yo1R9; Wed, 08 Jul 2020 10:48:04 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 08 Jul 2020 10:48:04 +0200
X-ME-IP: 86.238.65.197
To: David Waite 
Cc: Dick Hardt , "rdd@cert.org" , "txauth@ietf.org" , Justin Richer , The IESG 
References: <02ea0d99-a8b8-7957-8d16-de0a105f9362@free.fr>   <46705E7E-D657-4CF1-80DA-0ADDFD6D8B41@mit.edu> <85b03911-d1c6-127f-2480-bfab4b94ffe2@free.fr>   
From: Denis 
Message-ID: <48cbebbc-676e-66c4-0989-7f01fdcc71b6@free.fr>
Date: Wed, 8 Jul 2020 10:47:58 +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="------------F49F6D6AC1DD6CB32DAA36E4"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Support of FIDO and data minimization by RSs
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, 08 Jul 2020 08:48:08 -0000

This is a multi-part message in MIME format.
--------------F49F6D6AC1DD6CB32DAA36E4
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi David,

Comments are between the lines.

> On Jul 8, 2020, at 01:14, Denis  > wrote:
>>
>> Hi Dick,
>>
>>> Denis: you seem to keep implying that other architectures don't 
>>> preserve privacy. A couple counterpoints:
>>>
>>> Token opacity helps privacy in another dimension -- the client does 
>>> not see the information about the user.
>>
>> The client is not an adversary to the user.
>>
> Both users and authorization servers may have a limited amount of 
> trust in clients, which is a reason we have scopes to limit authorization
> and why we have consent to limit exposure of user data in the form of 
> claims within the OpenID Connect extension.

The user has the choice of its client.

This has nothing to do with "Both users and authorization servers may 
have a limited amount of trust in clients".

> The access token is a message about the client from the authorization 
> server to the protected resource, about the authorization.
> This might include internal details which a client *should not know*, 
> including internal information in the case

This is incorrect: "This might include internal details which a client 
*i**s unable to understand* including internal information in the case

> where the authorization and protected resource are part of the same 
> domain.

This is a typical case for OAuth. In GNAP, we envision multi-domain 
operations where bilateral relationships between ASs and RSs
will not be the rule any more.

> Many OAuth developments have self contained tokens. There is no token 
> introspectioncall.
>>> This, coupled with opaque tokens, is more privacy preserving than 
>>> the client being able to peek in a token.
>>
>> When an access token contains personal information about a user, that 
>> user has the right to see that personal information.
>>
> However that does not mean that data has to be exposed to all third 
> party clients without user consent.

Access tokens are supposed to be protected by HTTPS between the client 
and the AS and between the client and the RS.
This solves the concern.

Denis

> The sensitive data may also not be personal data in which case the 
> user does not have a right to see it, even under request.
> Finally, tokens may be issued to entities without equivalent rights, 
> such as hardware devices.
>>
> -DW
>


--------------F49F6D6AC1DD6CB32DAA36E4
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi David,

    
Comments are between the lines.

    

      
      On Jul 8, 2020, at 01:14, Denis <denis.ietf@free.fr>
      wrote:
      

        


          

            
            

              
Hi Dick,

              


              

              

                
                
Denis: you seem to keep implying
                  that other architectures don't preserve privacy. A
                  couple counterpoints:
                  


                  

                  
Token opacity helps privacy in another
                    dimension -- the client does not see the information
                    about the user.

                

              

              
The client is not an adversary to the user.

            

          

        

        Both users and authorization servers may have a limited amount
        of trust in clients, which is a reason we have scopes to limit
        authorization 

        and why we have consent to limit exposure of user data in the
        form of claims within the OpenID Connect extension.

    

    
The user has the choice of its client. 

      

      This has nothing to do with "Both users and authorization servers
      may have a limited amount of trust in clients".

    

      
The access token is a message about the client from the
        authorization server to the protected resource, about the
        authorization. 

        This might include internal details which a client should
          not know, including internal information in the case 

      

    

    
This is incorrect: "This might include internal details which a
      client is unable to understand including internal
      information in the case 

    

    

      
where the authorization and protected resource are part of
        the same domain.

    

    
This is a typical case for OAuth. In GNAP, we envision
      multi-domain operations where bilateral relationships between ASs
      and RSs 

      will not be the rule any more. 

    

    

      
Many OAuth developments have self contained tokens. There is
        no token introspectioncall. 

        

          

            

              

                

                  
 This, coupled with opaque tokens, is
                    more privacy preserving than the client being able
                    to peek in a token.

                

              

            

            
When an access token contains personal
              information about a user, that user has the right to see
              that personal information.

          

        

        However that does not mean that data has to be exposed to all
        third party clients without user consent. 

      

    

    
Access tokens are supposed to be protected by HTTPS between the
      client and the AS and between the client and the RS.

      This solves the concern.

    
Denis

    

      
The sensitive data may also not be personal data in which
        case the user does not have a right to see it, even under
        request. 

        Finally, tokens may be issued to entities without equivalent
        rights, such as hardware devices.

        

          

            

              
 

            

          

        

      

      
-DW

      

    

    


    

  


--------------F49F6D6AC1DD6CB32DAA36E4--


From nobody Wed Jul  8 06:59:37 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 399C93A0C01; Wed,  8 Jul 2020 06:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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=cert.org
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 RbSMT5DW_8bJ; Wed,  8 Jul 2020 06:59:26 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 3541B3A0BFC; Wed,  8 Jul 2020 06:59:25 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 068DxOUU012499; Wed, 8 Jul 2020 09:59:24 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 068DxOUU012499
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1594216764; bh=af0Kr//cxNTqMN4jbAv6QvGpSx7w4uvS+PYyDlUIqtA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=SslxcVVmQ7K8Z+97qcl74+AUmCBhKPW9pgwrnI2UOZdZO0XswRLHNdKCeSM4PR3oQ rShJp2o+NrzZViiceJKQD+q8x6sWPDKnWjlYHI2lrFhe5fOxXYHctFC3LNVsbxjmWg 04Ff/p7M8Frd4otjaSMfVooUaAsM6nHlaZ9qAbM8=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 068DxLO5011965; Wed, 8 Jul 2020 09:59:21 -0400
Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 8 Jul 2020 09:59:20 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 8 Jul 2020 09:59:20 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Wed, 8 Jul 2020 09:59:20 -0400
From: Roman Danyliw 
To: Martin Duke , The IESG 
CC: "gnap-chairs@ietf.org" , "txauth@ietf.org" 
Thread-Topic: Martin Duke's No Objection on charter-ietf-gnap-00-06: (with COMMENT)
Thread-Index: AQHWVBCWUcF217gxYEu+/o1m4rUVaKj9tslA
Date: Wed, 8 Jul 2020 13:59:19 +0000
Message-ID: <4eb5f33e88904289977a798e062d5aae@cert.org>
References: <159409331733.9511.16331687866989311971@ietfa.amsl.com>
In-Reply-To: <159409331733.9511.16331687866989311971@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.202.182]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Txauth] Martin Duke's No Objection on charter-ietf-gnap-00-06: (with COMMENT)
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, 08 Jul 2020 13:59:31 -0000

SGkgTWFydGluIQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGllc2cg
PGllc2ctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1hcnRpbiBEdWtlIHZpYSBEYXRh
dHJhY2tlcg0KPiBTZW50OiBNb25kYXksIEp1bHkgNiwgMjAyMCAxMTo0MiBQTQ0KPiBUbzogVGhl
IElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBnbmFwLWNoYWlyc0BpZXRmLm9yZzsgdHhhdXRo
QGlldGYub3JnDQo+IFN1YmplY3Q6IE1hcnRpbiBEdWtlJ3MgTm8gT2JqZWN0aW9uIG9uIGNoYXJ0
ZXItaWV0Zi1nbmFwLTAwLTA2OiAod2l0aA0KPiBDT01NRU5UKQ0KPiANCj4gTWFydGluIER1a2Ug
aGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGNoYXJ0ZXIt
aWV0Zi1nbmFwLTAwLTA2OiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxl
YXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0K
PiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0
byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0K
PiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNh
biBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFy
dGVyLWlldGYtZ25hcC8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0K
PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBQbGVhc2UgZXhwYW5kIOKAmEFT4oCZIG9uIGZpcnN0IHVz
ZS4NCg0KRml4ZWQgaW4gLTA4LiAgR29vZCBjYXRjaC4gIFRoYXQgd2FzIGEgcmVncmVzc2lvbiBi
dWcgYXMgdGhpcyB3YXMgZml4ZWQgcHJldmlvdXNseS4NCg0KUmVnYXJkcywNClJvbWFuDQoNCg==


From nobody Wed Jul  8 07:03: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 A67C73A0C03 for ; Wed,  8 Jul 2020 07:03:44 -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 dcUqgVq1JWDH for ; Wed,  8 Jul 2020 07:03:42 -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 31B163A0C02 for ; Wed,  8 Jul 2020 07:03:41 -0700 (PDT)
Received: from [192.168.1.7] (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 068E3cbW008512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Jul 2020 10:03:38 -0400
From: Justin Richer 
Message-Id: <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9BEC7DA0-1F6A-4DEC-8C9A-F2A9C8604219"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 8 Jul 2020 10:03:38 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 08 Jul 2020 14:03:45 -0000

--Apple-Mail=_9BEC7DA0-1F6A-4DEC-8C9A-F2A9C8604219
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I=E2=80=99m glad that you=E2=80=99re looking at polymorphism as a =
possible solution to this, though I would contend that this particular =
style of polymorphism is not doing much more than pushing the =
mutual-exclusivity check down a layer instead of solving it.=20

Using multiple types can in fact solve this problem, and several others, =
as long as you=E2=80=99re willing to let go of the syntax that OAuth 2 =
invented to solve a problem that we don=E2=80=99t have to solve here =
(passing an array-type value over the front channel). In XYZ=E2=80=99s =
syntax, the request for a single access token would look like this:

{
  =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=E2=
=80=9D ]
}

And the request for the multiple access tokens would look like this:

{
  =E2=80=9Cresources": {
     =E2=80=9Creader": [ =E2=80=9Cread=E2=80=9D ],
     =E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
  }
}

I find this to be much simpler to parse and generate, as you no longer =
need to check for a specially-reserved field name (=E2=80=9Ctype=E2=80=9D)=
, and you no longer have to do a sub-parse on one of the values to get =
what you really want (the space-separated scope string into a set). =
It=E2=80=99s also a lot simpler for the developers that need to write =
this.

 =E2=80=94 Justin

> On Jul 7, 2020, at 7:30 PM, Dick Hardt  wrote:
>=20
>=20
>=20
> On Tue, Jul 7, 2020 at 3:40 AM Justin Richer > wrote:
> I wanted to respond to this comment more fully:
>=20
> > wrt. my authorization / authorizations oddness, polymorphism would =
not solve it as the contents of both authorization / authorizations in =
XAuth are objects.=20
>=20
> It=E2=80=99s not surprising that this is the case, as the XAuth =
protocol was not designed with polymorphism as a tool to consider. This =
is exactly the reason that I say we should have polymorphism in the =
toolbox from the start, as it allows us to avoid this kind of =
awkwardness in many cases.
>=20
>  What evidence do you have to make this statement? "XAuth protocol was =
not designed with polymorphism as a tool to consider"
>=20
> It sounds like you are saying I did not consider polymorphism in the =
XAuth protocol design.
>=20
> I will restate my comment above about polymorphism.=20
>=20
> Using different JSON types does not solve the problem, but as I =
suggest in my comments, polymorphism of different JSON objects is one =
solution. An authorization, or a dictionary of authorizations. It has =
the restriction that the string "type" cannot be used as a label in the =
dictionary. An example:
>=20
> {
>     "authorizations" {
>         "type": "oauth_scope",
>         "scope": "read write"
>     }
> }
>=20
> {
>     "authorizations" {
>         "reader": {
>             "type": "oauth_scope",
>             "scope": "read"
>         },
>         "writer": {
>             "type": "oauth_scope",
>             "scope": "write"
>         },
>     }
> }
>=20
>=20
> I am looking at making this change in XAuth and in the implementation.
>=20
>=20
>=20
> =E1=90=A7


--Apple-Mail=_9BEC7DA0-1F6A-4DEC-8C9A-F2A9C8604219
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I=E2=80=
=99m glad that you=E2=80=99re looking at polymorphism as a possible =
solution to this, though I would contend that this particular style of =
polymorphism is not doing much more than pushing the mutual-exclusivity =
check down a layer instead of solving it. 

Using multiple types can in fact solve =
this problem, and several others, as long as you=E2=80=99re willing to =
let go of the syntax that OAuth 2 invented to solve a problem that we =
don=E2=80=99t have to solve here (passing an array-type value over the =
front channel). In XYZ=E2=80=99s syntax, the request for a single access =
token would look like this:

{
  =E2=80=9Cresources=E2=80=9D: [ =
=E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=E2=80=9D ]
}

And=
 the request for the multiple access tokens would look like =
this:

{
  =E2=80=9Cresources": =
{
     =E2=80=9Creader": [ =
=E2=80=9Cread=E2=80=9D ],
    =
 =E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
  }
}

I find this to be much simpler to parse =
and generate, as you no longer need to check for a specially-reserved =
field name (=E2=80=9Ctype=E2=80=9D), and you no longer have to do a =
sub-parse on one of the values to get what you really want (the =
space-separated scope string into a set). It=E2=80=99s also a lot =
simpler for the developers that need to write this.

 =E2=80=94 =
Justin

On Jul 7, 2020, at 7:30 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Tue, Jul 7, 2020 at 3:40 AM Justin =
Richer <jricher@mit.edu> wrote:
I wanted to respond to this =
comment more fully:



> wrt. my authorization / authorizations oddness, polymorphism would =
not solve it as the contents of both authorization / authorizations in =
XAuth are objects. 



It=E2=80=99s not surprising that this is the case, as the XAuth protocol =
was not designed with polymorphism as a tool to consider. This is =
exactly the reason that I say we should have polymorphism in the toolbox =
from the start, as it allows us to avoid this kind of awkwardness in =
many cases.

 What evidence do you have to make =
this statement? "XAuth protocol was not designed with polymorphism as a =
tool to consider"

It sounds like you are saying I did not =
consider polymorphism in the XAuth protocol design.

I will restate my =
comment above about polymorphism. 

Using different JSON types does not =
solve the problem, but as I suggest in my comments, polymorphism of =
different JSON objects is one solution. An authorization, or a =
dictionary of authorizations. It has the restriction that the string =
"type" cannot be used as a label in the dictionary. An =
example:

{
    "authorizations" {
    =
    "type": "oauth_scope",
      =
  "scope": "read write"
    }
}

{
    =
"authorizations" {
        "reader": =
{
            "type": =
"oauth_scope",
            =
"scope": "read"
        },
        "writer": {
  =
          "type": "oauth_scope",
            "scope": "write"
        },
    =
}
}


I =
am looking at making this change in XAuth and in the =
implementation.



3D""=E1=90=A7



=

--Apple-Mail=_9BEC7DA0-1F6A-4DEC-8C9A-F2A9C8604219--


From nobody Wed Jul  8 07:32: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 892B13A0C4A for ; Wed,  8 Jul 2020 07:32:51 -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_REMOTE_IMAGE=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 LvnM-QzDY4j8 for ; Wed,  8 Jul 2020 07:32:47 -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 C8C1F3A0C44 for ; Wed,  8 Jul 2020 07:32:46 -0700 (PDT)
Received: from [192.168.1.7] (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 068EWia7020209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Jul 2020 10:32:45 -0400
From: Justin Richer 
Message-Id: <2D3EEF56-BD86-42DF-82D2-7595E19C5350@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_41DD2BAF-E9DB-456A-890B-BC401539B9BC"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 8 Jul 2020 10:32:44 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Tobias Looker 
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <6846D2F0-5096-404B-A529-676146392F45@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 08 Jul 2020 14:32:52 -0000

--Apple-Mail=_41DD2BAF-E9DB-456A-890B-BC401539B9BC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think there are two interesting layers here:=20

 - Information that the client needs to know. This is what started the =
thread, the whole =E2=80=9Chow and where am I allowed to use this =
token=E2=80=9D question. This is stuff that would be put alongside the =
token in the response from the AS, not inside the token.

 - Information that the RS needs to know. This is I think where the =
attenuation, proofing, and the actual rights associated with the token =
would go. This is stuff that would either be in the token itself or in a =
 return from an introspection style call.

Both of these fit into the =E2=80=9Cconsistent token model=E2=80=9D part =
of GNAP, but different aspects need to be communicated in different =
ways.=20

 =E2=80=94 Justin

> On Jul 7, 2020, at 8:01 PM, Tobias Looker  =
wrote:
>=20
> I've also been thinking about the parallels between ZCAP's and =
OAuth2.0 access tokens. To me a ZCAP is a less opaque, semantically =
richer capability format, whereas an access_token is traditionally much =
simpler. The key here though is I still see an access_token as a form of =
capability. It appears in general one of the trade offs we will be faced =
with is either:
>=20
> 1. Keeping the capability received from a GNAP flow (e.g an =
access_token) opaque to the client and externalizing any greater =
information about how to use the capability (such as in your proposal in =
the first email of this thread).
> 2. Internalizing information about the capabilities utility and any =
greater context about it which means the capability is no longer opaque.
>=20
> With that aside, the notable features in general I would like GNAP to =
consider from ZCAP's, are the following.
>=20
> - Delegatable capabilities (bonus if this mechanism includes the =
ability to attenuate during delegation) - Consider the example where a =
client or RP (RP1) receives some form of access_token (capability) from =
an AS and would like to delegate this to another RP (RP2) so they can =
access the same resources. If including attenuation this would mean that =
during this delegation (RP1->RP2), RP1 could narrow the scope of the =
original access it received so that RP2 only gets a subset of the =
original scope.
> - Bound capabilities - Similar in some ways to dPop, essentially =
establishing the ability to bind an access_token (capability) to the =
party that should be able to use it (invoker). I see this as a must have =
in order to be able to do attenuated delegation as described above.
>=20
> Thanks,
>  	 =09
> Tobias Looker
> Mattr
> +64 (0) 27 378 0461
> tobias.looker@mattr.global 
>  	 =
	 =
	 =

> This communication, including any attachments, is confidential. If you =
are not the intended recipient, you should not read it - please contact =
me immediately, destroy it, and do not copy or use any part of this =
communication or disclose anything about it. Thank you. Please note that =
this communication does not designate an information system for the =
purposes of the Electronic Transactions Act 2002.
>=20
>=20
> On Wed, Jul 8, 2020 at 8:39 AM Justin Richer > wrote:
> I=E2=80=99ve been thinking more about these use cases, and it might =
help us to think of GNAP=E2=80=99s access tokens as capabilities in the =
computer security sense =E2=80=94 but more specifically, capabilities =
that are delivered with their own context for use. In that way, an =
otherwise naive client can be handed an access token and simply know =
exactly what to do with it. This context would be delivered alongside =
the token, so the token material itself remains opaque to the client.
>=20
> I wanted to bring up a W3C spec for a capabilities model based on =
linked data:
>=20
> https://w3c-ccg.github.io/zcap-ld/ =

>=20
> Building a fully featured capabilities context is difficult, at the =
very least. And unfortunately, I don=E2=80=99t think this spec actually =
gives us any viable solutions to work with. In particular the =
=E2=80=9Cactions=E2=80=9D section is effectively blank, offloading the =
work to an external JSONLD process (side note, this is one of the =
problems I have with specs based on JSONLD, they externalize the =
important parts into local contexts and break interoperability =E2=80=94 =
but I digress). But at least it=E2=80=99s another way of looking at the =
problem space that might be outside the familiar zone of many of the =
OAuth world.
>=20
>  =E2=80=94 Justin
>=20
>> On Jun 26, 2020, at 9:23 AM, Justin Richer > wrote:
>>=20
>> On Jun 25, 2020, at 9:07 PM, Tobias Looker =
> wrote:
>>>=20
>>> I find this feature interesting and think it could be an important =
pattern going forward to enable an AS to be able to describe the utility =
of a token to the client, however as already pointed out in the thread I =
think there is some potential hidden complexity that would need to be =
ironed out such that it does not make the simple things complicated.
>>>=20
>>> Justin, do you see this feature as something the client has to =
explicitly request, i.e "please give me access and instructions on how =
to use my access" or rather that the AS would just return this =
information in conjunction with the access token if it had it available?
>>>=20
>>=20
>> This is something that I=E2=80=99d brought up as a possibility on the =
previous thread =E2=80=94 something like a flag the client would set. =
This would be especially important if the AS wants to return multiple =
access tokens but the client requested 1, or the client requested N and =
the AS wants to return M in response. Basically any time there=E2=80=99s =
a mismatch, that=E2=80=99s extra complexity on the client that I really =
don=E2=80=99t think we want to be universal. A flag to turn that kind of =
direction and splitting on would be a potential start. But there are =
potential snags here too, and it comes down to how you manage the =
defaults...
>>=20
>>> > This is just the start, too. Things get even more complex if the =
client can ask for multiple different kinds of resources at once. What =
if the AS decides that the client needs a hyper-focused directed token =
for one part of the API, but can use a general token for other stuff? =
Can it signal that to the client? And if it can, does that mean that all =
clients need to be prepared for that kind of thing?
>>>=20
>>> Would a potential default be that if a client did for any reason not =
support processing the additional information returned with the =
access_token, just to ignore it? I think in the spirit of keeping the =
simple things simple, this potentially makes sense?
>>=20
>> That=E2=80=99s the real trick, if you ask me. It has to be :safe: for =
a client to ignore this information. Which means the AS can=E2=80=99t =
rely on the client =E2=80=9Cdoing the right thing=E2=80=9D with the =
information in the =E2=80=9Ctoken directions=E2=80=9D portion of the =
response. Even setting aside the advanced and related =E2=80=9Csplit =
tokens=E2=80=9D idea above, we need to make sure that an AS/RS setup is =
built such that if the AS tells a client =E2=80=9Conly do X with your =
token=E2=80=9D and the client does =E2=80=9CY=E2=80=9D, then there are =
other protections and practices in place to prevent things from going =
haywire if the client does =E2=80=9CY=E2=80=9D either by accident or =
through ignorance.=20
>>=20
>> If OAuth 2 has taught us anything, it=E2=80=99s that client =
applications are going to be the laziest participants in the security =
model. And that makes sense, really =E2=80=94 security isn=E2=80=99t =
what the client apps are trying to do, they=E2=80=99re trying to use the =
RS to do something. So we need to make sure that whatever system we =
design will fail on the safe side as much as possible, and keep things =
simple for the client.
>>=20
>>>=20
>>> > here are some worked out samples of this:
>>> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token =

>>> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ =

>>> Peace ..tom
>>>=20
>>> As one of the authors of those mentioned drafts, I am interested in =
discussing that, but perhaps on a seperate thread? As at least the bound =
assertion spec is primarily concerned with binding mechanisms for the =
artifacts produced from an authorization flow (specifically identity =
claims), whereas I think directed access tokens is just more generally =
talking about whether GNAP should support an AS conveying how to use an =
access_token it produces during a flow with a client.
>>>=20
>>=20
>> I think that these are separate issues as well.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> Thanks,
>>>  	 =09
>>> Tobias Looker
>>> Mattr
>>> +64 (0) 27 378 0461
>>> tobias.looker@mattr.global 
>>>  	 =
	 =
	 =

>>> This communication, including any attachments, is confidential. If =
you are not the intended recipient, you should not read it - please =
contact me immediately, destroy it, and do not copy or use any part of =
this communication or disclose anything about it. Thank you. Please note =
that this communication does not designate an information system for the =
purposes of the Electronic Transactions Act 2002.
>>>=20
>>>=20
>>> On Wed, Jun 24, 2020 at 10:14 PM Denis > wrote:
>>> Justin, I fear we are still far away from an agreement about what =
this BoF should do.
>>>=20
>>> Tom Jones is saying " I am getting tired of the whack-a-mole =
approach ..."
>>>=20
>>> I don't agree with you when you write: "I think it=E2=80=99s going =
to be overwhelmingly common that a given RS is going to trust exactly =
one AS=20
>>> that it knows about ahead of time". Such an architecture would have =
exactly the same limitations as OAuth 2.0. and would not be scalable.
>>>=20
>>> Before we start, we should have a clear view of the whole picture =
rather than starting from one scenario and expanding it in many =
different directions.
>>> For building an architecture, a pre-requirement is to define ALL the =
trust relationships. I don't believe that we have an agreement at this =
time on what=20
>>> these trust relationships are.=20
>>>=20
>>> You are also using the following wording: "methods for the AS and RS =
to communicate what the token=E2=80=99s good for".=20
>>> With such a paradigm, it would be impossible to protect the user's =
privacy.=20
>>>=20
>>> A key question is : Will GNAP take care of the user's privacy or =
will GNAP prevent to take care of the user's privacy ?
>>>=20
>>> About "the ability for the client to get several access tokens to =
get different resources from one request" is indeed a complex case.
>>>=20
>>> No one (including ASs) is able to predict in advance which access =
tokens will be needed, since they depend upon the kind of operation(s)=20=

>>> the client will be willing to perform. For privacy reasons, ASs =
should be kept ignorant of all the operations that a client is going to =
perform=20
>>> on one or more resource servers. I believe that every effort should =
be made to avoid the AS to be in a position to be able to trace the =
operations=20
>>> performed by its clients on various RSs.
>>>=20
>>> To handle the complex case you envision, the full workflow of =
operations needs to be considered with a detailed focus on the time=20
>>> at which the user's consent and choice happens (consent and choice =
is the first privacy principle from ISO 29100).
>>>=20
>>> First of all, an access token could be targeted to a service rather =
than to a server. This would already solve many cases.
>>>=20
>>> When a RS needs to call another RS (which does not support the same =
service) then the client should be informed by the first RS.
>>> His "consent and choice" should then be obtained by the first RS =
and, when the user agrees, the client should then ask an access token=20
>>> to one of the ASs trusted by the second RS in order to perform the =
subsequent operation. =20
>>>=20
>>> Denis
>>>=20
>>> PS.  In an email sent on June 23 you wrote: " I think an on-device =
AS is an important use case".  I am sorry, but I don't understand.
>>>        However, I do understand what "a server-based AS" is.
>>>=20
>>>=20
>>>> Denis, thanks for the great comments. I think that your trust model =
is pretty different from what I=E2=80=99d laid out initially, and while =
it=E2=80=99s an interesting and important one, it is not what I meant by =
=E2=80=9Cmultiple access tokens=E2=80=9D in my discussion below. I think =
that might be the cause of some disconnect here, but that doesn=E2=80=99t =
mean it=E2=80=99s out of reach for what the WG is after.
>>>>=20
>>>> When I refer to multiple access tokens, and what the charter calls =
out as multiple access tokens, is the ability for the client to get =
several access tokens to get different resources from one request. I =
personally see this as an optimization of a specific set of use cases, =
some of which I discussed in my original email. There are others, I=E2=80=99=
m sure, but all the ones I=E2=80=99ve seen are around the client needing =
to get several different kinds of access through an AS.=20
>>>>=20
>>>> I think it=E2=80=99s going to be overwhelmingly common that a given =
RS is going to trust exactly one AS that it knows about ahead of time. =
But for RS=E2=80=99s that can trust multiple AS=E2=80=99s, then we =
should have a model that can accommodate that as well. That=E2=80=99s =
why the charter calls out methods for the AS and RS to communicate what =
the token=E2=80=99s good for. I think the basis of those methods is =
going to start with a common token model, and likely incorporate into =
things like token formats and introspection-style token APIs.=20
>>>>=20
>>>>  =E2=80=94 Justin
>>>>=20
>>>>> On Jun 22, 2020, at 3:55 AM, Denis > wrote:
>>>>>=20
>>>>> Hello Justin,
>>>>>=20
>>>>> A few comments between the lines.
>>>>>=20
>>>>>> One of the most important aspects to GNAP is going to be an =
ability to address things that OAuth 2 can=E2=80=99t, or at least =
can=E2=80=99t do without significant gymnastics. So with that, I wanted =
to bring back a use case discussion that originally came up while we =
were talking about the possibility of multiple access tokens, a few =
months back. I don=E2=80=99t know if this concept has a regular term, so =
I=E2=80=99m going to call it =E2=80=9Cdirected access tokens=E2=80=9D =
until we come up with something better =E2=80=94 assuming we decide this =
is worthwhile.=20
>>>>> I don't understand what may mean "directed access tokens=E2=80=9D =
but I understand what means "multiple access tokens".=20
>>>>> When speaking of "multiple access tokens", these access tokens may =
come from one or more ASs.
>>>>>=20
>>>>>> In OAuth, the client=E2=80=99s supposed to always know where to =
send its access token, and that knowledge is completely outside the =
protocol. This makes a lot of sense for many (if not most) deployments, =
as OAuth is really there to enable the API access that the client =
already knows about.
>>>>>>=20
>>>>>> But we=E2=80=99re now in a world where a client could be talking =
to a generic API that could be deployed at a number of different places, =
or a cloud deployment that the AS wants to be able to dispatch the =
client to.=20
>>>>> As soon the AS is placed (again) at the centre of the model, the =
AS will have the ability to act as "Big Brother".
>>>>> OAuth 2.0 has not taken care of privacy issues. On the contrary, =
GNAP should take care of them.
>>>>>=20
>>>>>> In order to do this, the AS needs to be able to communicate to =
the client not only the token information (and any related key and =
presentation information), but also a set of directions about what that =
specific token is good for. This needs to be information outside the =
token itself, since I believe we want to keep OAuth 2=E2=80=99s feature =
of having the token be opaque to the client. Note: while we could map =
all of these to different resource requests (in XYZ parlance) or scopes =
(in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t =
enough to tell the client what to do with the token if it doesn=E2=80=99t =
know already.=20
>>>>>>=20
>>>>>> I know of two use cases already in the wild, where people are =
addressing things using a mix of existing standards and some proprietary =
extensions to address things within their silos. I=E2=80=99ll try to =
summarize here, but I know the folks I=E2=80=99ve been talking to about =
this are also on the list so hopefully they can chime in with more =
detail or any corrections for something I=E2=80=99ve missed.=20
>>>>>>=20
>>>>>> (1) The client knows what resource it=E2=80=99s calling, but it =
doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a =
single security domain controlled by the AS,=20
>>>>> Speaking of "multiple access tokens" is in contradiction with =
single security domain "controlled" by an AS.=20
>>>>> A user may need to demonstrate some of his identity attributes =
granted e.g. by his bank but may also=20
>>>>> need to demonstrate one or more diplomas granted by one or more =
universities. The bank cannot be=20
>>>>> the "primary issuer" of a university diploma. It should not be =
either a "secondary issuer", because=20
>>>>> the bank does not "need to know" what are the diplomas of the =
user.
>>>>>=20
>>>>>> but the AS needs to decide at runtime which specific instance of =
the API to direct the client to. Since things are closely tied together, =
the client just needs to effectively known an identifier for the RS, and =
this is currently implemented as a URI. Once the client has that =
identifier, it knows how to dispatch that token to that instance of the =
RS.
>>>>> There is no good reason why the AS should be involved in that =
step.=20
>>>>> OAuth 2.0 is/was implicitly mandating a strong relationship =
between ASs and RSs which makes it non scalable.
>>>>> GNAP should be based on a simple trust relationship : a given RS =
trusts some ASs for access tokens that contains some types of =
attributes.
>>>>> An AS should not need to know in advance (or even at the time of =
an access token request) the RSs that are trusting it.
>>>>>=20
>>>>> A client could first talk to a "global service provider" which has =
the knowledge of the different RSs affiliated to it.=20
>>>>>=20
>>>>>> (2) The client knows what kind of thing it=E2=80=99s looking for, =
but doesn=E2=80=99t know who to ask it from.=20
>>>>> Once again, the client could first talk to a "global service =
provider" which has the knowledge of the different RSs affiliated to it.=20=

>>>>>=20
>>>>>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by =
the AS, and the AS needs to dispatch to different resources depending on =
which user logged in (and possibly what the user consented to). To make =
things more concrete, the client needs to get driver=E2=80=99s license =
information, but doesn=E2=80=99t know ahead of time which of the many =
state/provincial bureaus to call to get that information because it =
doesn=E2=80=99t know yet who the user is.=20
>>>>> When a user has a driving license, he knows its issuer. The user =
can then provide some hint to the client.
>>>>>=20
>>>>>> The AS will know who the user is once they log in and approve =
things, and so it can direct the client to call the correct RS. Since =
this is a relatively simple API with a pre-negotiated cross-domain =
trust, the AS returns a URL that the client presents the token at.=20
>>>>>  A single AS should not be aware of all the attributes a user has.=20=

>>>>>=20
>>>>>>=20
>>>>>> As far as I know, in both of these cases, the token is only good =
for that API and not others =E2=80=94 but more on that later.
>>>>>>=20
>>>>>> A simple thing to do is just give back a URL with the access =
token, which tells the client where to go.=20
>>>>>>=20
>>>>>> 	{
>>>>>> 		=E2=80=9Caccess_token=E2=80=9D: {
>>>>>> 			=E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=
=9D,
>>>>>> 			=E2=80=9Cresource_uri=E2=80=9D: =
=E2=80=9Chttps://example/foo "
>>>>>> 		}
>>>>>> 	}
>>>>>>=20
>>>>>> This is good for some kinds of APIs, but it=E2=80=99s limiting =
because not all APIs dispatch based on the URL. An AS might want to =
divvy up access tokens to an API that=E2=80=99s keyed on headers, or =
verbs, or any number of things. And it doesn=E2=80=99t tell us =
immediately what to do about non-exact URL matches. Can the client add =
query parameters and still use the token? What about path segments? I =
like that this simple approach addresses some common deployments that we =
already see today (see above), it=E2=80=99s not universal. Do we want or =
need a universal description language for directing where tokens go?
>>>>>>=20
>>>>>> This also opens up a whole new set of security questions. If the =
AS can now direct the client where to use the token, could a rogue AS =
convince a legit client to use a stolen token at the wrong RS? And what =
if the client ignores the directions from the AS entirely? Could this =
open up new avenues of attack?
>>>>>>=20
>>>>>> This is just the start, too. Things get even more complex if the =
client can ask for multiple different kinds of resources at once. What =
if the AS decides that the client needs a hyper-focused directed token =
for one part of the API, but can use a general token for other stuff? =
Can it signal that to the client? And if it can, does that mean that all =
clients need to be prepared for that kind of thing?
>>>>>>=20
>>>>>> I firmly believe that whatever we build in GNAP, we need to =
optimize for the overwhelmingly common use case of a client getting a =
single access token to call APIs that it already knows about. Anything =
we add on top of that really can=E2=80=99t get in the way of this, =
because if it does, there=E2=80=99s very small chance that people will =
try to use this for everyday things. Keep the simple things simple, and =
the complex things possible, after all.
>>>>>>=20
>>>>>> I=E2=80=99m really looking forward to hearing what the community =
thinks about these use cases, and hopefully the people I=E2=80=99ve =
chatted with offline about this can join the conversation and provide =
more light than I was able to.
>>>>> The two use cases which are considered above are:
>>>>>=20
>>>>> (1) The client knows what resource it=E2=80=99s calling, but it =
doesn=E2=80=99t know where it=E2=80=99s hosted.
>>>>> (2) The client knows what kind of thing it=E2=80=99s looking for, =
but doesn=E2=80=99t know who to ask it from.=20
>>>>>=20
>>>>> That does not mean in any way that these two use cases should be =
solved by placing the AS at the centre of the solution.
>>>>>=20
>>>>> Denis
>>>>>=20
>>>>>>=20
>>>>>>  =E2=80=94 Justin
>>>>>>=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 =

>>>=20
>>> This communication, including any attachments, is confidential. If =
you are not the intended recipient, you should not read it - please =
contact me immediately, destroy it, and do not copy or use any part of =
this communication or disclose anything about it. Thank you. Please note =
that this communication does not designate an information system for the =
purposes of the Electronic Transactions Act 2002.
>>=20
>> --=20
>> Txauth mailing list
>> Txauth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/txauth =

>=20
> This communication, including any attachments, is confidential. If you =
are not the intended recipient, you should not read it - please contact =
me immediately, destroy it, and do not copy or use any part of this =
communication or disclose anything about it. Thank you. Please note that =
this communication does not designate an information system for the =
purposes of the Electronic Transactions Act 2002.


--Apple-Mail=_41DD2BAF-E9DB-456A-890B-BC401539B9BC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
think there are two interesting layers here: 

 - Information that the client =
needs to know. This is what started the thread, the whole =E2=80=9Chow =
and where am I allowed to use this token=E2=80=9D question. This is =
stuff that would be put alongside the token in the response from the AS, =
not inside the token.

 - Information that the RS needs to know. This is I =
think where the attenuation, proofing, and the actual rights associated =
with the token would go. This is stuff that would either be in the token =
itself or in a  return from an introspection style call.

Both of these fit into =
the =E2=80=9Cconsistent token model=E2=80=9D part of GNAP, but different =
aspects need to be communicated in different ways. 

 =E2=80=94 =
Justin

On Jul 7, 2020, at 8:01 PM, Tobias Looker =
<tobias.looker@mattr.global> wrote:

I've also been thinking about the =
parallels between ZCAP's and OAuth2.0 access tokens. To me a ZCAP is a =
less opaque, semantically richer capability format, whereas an =
access_token is traditionally much simpler. The key here though is I =
still see an access_token as a form of capability. It appears in general =
one of the trade offs we will be faced with is either:

1. Keeping the capability =
received from a GNAP flow (e.g an access_token) opaque to the =
client and externalizing any greater information about how to use the =
capability (such as in your proposal in the first email of this =
thread).
2. Internalizing information about the =
capabilities utility and any greater context about it which means the =
capability is no longer opaque.

With that aside, the notable features =
in general I would like GNAP to consider from ZCAP's, are the =
following.

- =
Delegatable capabilities (bonus if this mechanism includes the ability =
to attenuate during delegation) - Consider the example where a client or =
RP (RP1) receives some form of access_token (capability) from an AS =
and would like to delegate this to another RP (RP2) so they can access =
the same resources. If including attenuation this would mean =
that during this delegation (RP1->RP2), RP1 could narrow the scope of =
the original access it received so that RP2 only gets a subset of =
the original scope.
- Bound capabilities - Similar =
in some ways to dPop, essentially establishing the ability to bind an =
access_token (capability) to the party that should be able to use it =
(invoker). I see this as a must have in order to be able to do =
attenuated delegation as described above.

Thanks,
3D"Mattr 
Tobias Looker
Mattr
+64 =
(0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr3D"Mattr3D"Mattr3D"Mattr

This communication, including any attachments, is =
confidential. If you are not the intended recipient, you should not read =
it - please contact me immediately, destroy it, and do not copy or use =
any part of this communication or disclose anything about it. Thank you. =
Please note that this communication does not designate an information =
system for the purposes of the Electronic Transactions Act =
2002.


On Wed, Jul =
8, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99ve been thinking more about these use =
cases, and it might help us to think of GNAP=E2=80=99s access tokens as =
capabilities in the computer security sense =E2=80=94 but more =
specifically, capabilities that are delivered with their own context for =
use. In that way, an otherwise naive client can be handed an access =
token and simply know exactly what to do with it. This context would be =
delivered alongside the token, so the token material itself remains =
opaque to the client.

I wanted to bring up a W3C spec for a capabilities model =
based on linked data:

https://w3c-ccg.github.io/zcap-ld/
Building a fully featured capabilities =
context is difficult, at the very least. And unfortunately, I don=E2=80=99=
t think this spec actually gives us any viable solutions to work with. =
In particular the =E2=80=9Cactions=E2=80=9D section is effectively =
blank, offloading the work to an external JSONLD process (side note, =
this is one of the problems I have with specs based on JSONLD, they =
externalize the important parts into local contexts and break =
interoperability =E2=80=94 but I digress). But at least it=E2=80=99s =
another way of looking at the problem space that might be outside the =
familiar zone of many of the OAuth world.

 =E2=80=94 Justin

On Jun 26, 2020, at 9:23 AM, Justin Richer <jricher@mit.edu> wrote:

On Jun 25, 2020, =
at 9:07 PM, Tobias Looker <tobias.looker@mattr.global> =
wrote:

I find this =
feature interesting and think it could be an important pattern =
going forward to enable an AS to be able to describe the utility of =
a token to the client, however as already pointed out in the thread I =
think there is some potential hidden complexity that would need to be =
ironed out such that it does not make the simple things complicated.

Justin, do you see this =
feature as something the client has to explicitly request, i.e "please =
give me access and instructions on how to use my access" or rather that =
the AS would just return this information in conjunction with the access =
token if it had it available?


This is something that I=E2=80=99d =
brought up as a possibility on the previous thread =E2=80=94 something =
like a flag the client would set. This would be especially important if =
the AS wants to return multiple access tokens but the client requested =
1, or the client requested N and the AS wants to return M in response. =
Basically any time there=E2=80=99s a mismatch, that=E2=80=99s extra =
complexity on the client that I really don=E2=80=99t think we want to be =
universal. A flag to turn that kind of direction and splitting on would =
be a potential start. But there are potential snags here too, and it =
comes down to how you manage the defaults...

> This is just the start, too. =
Things get even more complex if the client can ask for multiple =
different kinds of resources at once. What if the AS decides that the =
client needs a hyper-focused directed token for one part of the API, but =
can use a general token for other stuff? Can it signal that to the =
client? And if it can, does that mean that all clients need to be =
prepared for that kind of thing?

Would a potential default be that if a =
client did for any reason not support processing the additional =
information returned with the access_token, just to ignore it? I think =
in the spirit of keeping the simple things simple, this potentially =
makes sense?

That=E2=80=99s the real trick, if you =
ask me. It has to be :safe: for a client to ignore this information. =
Which means the AS can=E2=80=99t rely on the client =E2=80=9Cdoing the =
right thing=E2=80=9D with the information in the =E2=80=9Ctoken =
directions=E2=80=9D portion of the response. Even setting aside the =
advanced and related =E2=80=9Csplit tokens=E2=80=9D idea above, we need =
to make sure that an AS/RS setup is built such that if the AS tells a =
client =E2=80=9Conly do X with your token=E2=80=9D and the client does =
=E2=80=9CY=E2=80=9D, then there are other protections and practices in =
place to prevent things from going haywire if the client does =E2=80=9CY=E2=
=80=9D either by accident or through ignorance. 

If OAuth 2 has taught us =
anything, it=E2=80=99s that client applications are going to be the =
laziest participants in the security model. And that makes sense, really =
=E2=80=94 security isn=E2=80=99t what the client apps are trying to do, =
they=E2=80=99re trying to use the RS to do something. So we need to make =
sure that whatever system we design will fail on the safe side as much =
as possible, and keep things simple for the client.


> here are some worked out samples of this:
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
https://mattrglobal.github.io/oidc-client-bound-assertions-spec=
/
Peace ..tom

As one of the authors of those =
mentioned drafts, I am interested in discussing that, but perhaps on a =
seperate thread? As at least the bound assertion spec =
is primarily concerned with binding mechanisms for the =
artifacts produced from an authorization flow (specifically identity =
claims), whereas I think directed access tokens is just more generally =
talking about whether GNAP should support an AS conveying how to use an =
access_token it produces during a flow with a =
client.


I think that these are separate issues =
as well.

 =E2=80=94 Justin

Thanks,
3D"Mattr 
Tobias Looker
Mattr
+64 =
(0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr3D"Mattr3D"Mattr3D"Mattr

This communication, including any attachments, is =
confidential. If you are not the intended recipient, you should not read =
it - please contact me immediately, destroy it, and do not copy or use =
any part of this communication or disclose anything about it. Thank you. =
Please note that this communication does not designate an information =
system for the purposes of the Electronic Transactions Act =
2002.


On Wed, Jun 24, 2020 at 10:14 PM Denis =
<denis.ietf@free.fr> wrote:
Justin,=
 I fear we are still far away from an agreement about what this BoF =
should do.

Tom =
Jones is saying " I am getting tired of the whack-a-mole approach =
..."

I don't agree with you =
when you write: "I think it=E2=80=99s going to be overwhelmingly common =
that a given RS is going to trust exactly one AS 
that it knows =
about ahead of time". Such an architecture would have exactly the same =
limitations as OAuth 2.0. and would not be scalable.

Before =
we start, we should have a clear view of the whole picture rather than =
starting from one scenario and expanding it in many different =
directions.
For building an architecture, a =
pre-requirement is to define ALL the trust relationships. I don't =
believe that we have an agreement at this time on what 
these trust relationships =
are. 

You are also using the following =
wording: "methods for the AS and RS to communicate what the token=E2=80=99=
s good for". 
With such a =
paradigm, it would be impossible to protect the user's privacy. 

A key question is : Will GNAP take care =
of the user's privacy or will GNAP prevent to take care of the =
user's privacy ?

About "the ability for the client to get several access =
tokens to get different resources from one request" is indeed a complex =
case.

No one =
(including ASs) is able to predict in advance which access tokens will =
be needed, since they depend upon the kind of operation(s) 
the client will be willing to =
perform. For privacy reasons, ASs should be kept ignorant of all the =
operations that a client is going to perform 
on one or more resource servers. =
I believe that every effort should be made to avoid the AS to be in a =
position to be able to trace the operations 
performed by its clients on =
various RSs.

To =
handle the complex case you envision, the full workflow of operations =
needs to be considered with a detailed focus on the time 
at which the user's consent and choice happens (consent and =
choice is the first privacy principle =
from ISO 29100).

First of all, an access token could be targeted to a service =
rather than to a server. This would already solve many cases.

When a RS needs to call =
another RS (which does not support the same service) then the client =
should be informed by the first RS.
His "consent =
and choice" should then be obtained by the first RS and, when the user =
agrees, the client should then ask an access token 
to one of the ASs trusted by the =
second RS in order to perform the subsequent operation.  

Denis

PS.  In an email sent on June 23 =
you wrote: " I think an on-device AS is an important use case".  I =
am sorry, but I don't understand.
       However, I do understand =
what "a server-based AS" is.


Denis, thanks for the great comments. I think =
that your trust model is pretty different from what I=E2=80=99d laid out =
initially, and while it=E2=80=99s an interesting and important one, it =
is not what I meant by =E2=80=9Cmultiple access tokens=E2=80=9D in my =
discussion below. I think that might be the cause of some disconnect =
here, but that doesn=E2=80=99t mean it=E2=80=99s out of reach for what =
the WG is after.

When =
I refer to multiple access tokens, and what the charter calls out as =
multiple access tokens, is the ability for the client to get several =
access tokens to get different resources from one request. I personally =
see this as an optimization of a specific set of use cases, some of =
which I discussed in my original email. There are others, I=E2=80=99m =
sure, but all the ones I=E2=80=99ve seen are around the client needing =
to get several different kinds of access through an AS. 

I think =
it=E2=80=99s going to be overwhelmingly common that a given RS is going =
to trust exactly one AS that it knows about ahead of time. But for =
RS=E2=80=99s that can trust multiple AS=E2=80=99s, then we should have a =
model that can accommodate that as well. That=E2=80=99s why the charter =
calls out methods for the AS and RS to communicate what the token=E2=80=99=
s good for. I think the basis of those methods is going to start with a =
common token model, and likely incorporate into things like token =
formats and introspection-style token APIs. 
 =E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the =
lines.

One of the most important aspects to GNAP =
is going to be an ability to address things that OAuth 2 can=E2=80=99t, =
or at least can=E2=80=99t do without significant gymnastics. So with =
that, I wanted to bring back a use case discussion that originally came =
up while we were talking about the possibility of multiple access =
tokens, a few months back. I don=E2=80=99t know if this concept has a =
regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access =
tokens=E2=80=9D until we come up with something better =E2=80=94 =
assuming we decide this is worthwhile. 
I don't understand what may mean "directed =
access tokens=E2=80=9D but I understand what means "multiple access =
tokens". 
When speaking of =
"multiple access tokens", these access tokens may come from one or more =
ASs.
In OAuth, the client=E2=80=99=
s supposed to always know where to send its access token, and that =
knowledge is completely outside the protocol. This makes a lot of sense =
for many (if not most) deployments, as OAuth is really there to enable =
the API access that the client already knows about.

But we=E2=80=99re now in =
a world where a client could be talking to a generic API that could be =
deployed at a number of different places, or a cloud deployment that the =
AS wants to be able to dispatch the client to. 
As soon the AS is placed (again) at the =
centre of the model, the AS will have the ability to act as "Big =
Brother".
OAuth 2.0 has not taken care of privacy issues. =
On the contrary, GNAP should take care of them.
In order to do this, the =
AS needs to be able to communicate to the client not only the token =
information (and any related key and presentation information), but also =
a set of directions about what that specific token is good =
for. This needs to be information outside the token itself, since =
I believe we want to keep OAuth 2=E2=80=99s feature of having the =
token be opaque to the client. Note: while we could map all of these to =
different resource requests (in XYZ parlance) or scopes (in OAuth 2 =
legacy parlance) on the request side, this isn=E2=80=99t enough to tell =
the client what to do with the token if it doesn=E2=80=99t know already. 

I know of two use cases =
already in the wild, where people are addressing things using a mix of =
existing standards and some proprietary extensions to address things =
within their silos. I=E2=80=99ll try to summarize here, but I know the =
folks I=E2=80=99ve been talking to about this are also on the list so =
hopefully they can chime in with more detail or any corrections for =
something I=E2=80=99ve missed. 

(1) The client knows what resource =
it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s =
hosted. Everything is in a single security domain controlled by the =
AS, 
Speaking of "multiple access tokens" is in =
contradiction with single security domain "controlled" by an AS. 
A user may need to demonstrate =
some of his identity attributes granted e.g. by his bank but may =
also 
need to demonstrate one =
or more diplomas granted by one or more universities. The bank cannot =
be 
the "primary issuer" of a =
university diploma. It should not be either a "secondary issuer", =
because 
the bank does not =
"need to know" what are =
the diplomas of the user.
but the AS needs to decide =
at runtime which specific instance of the API to direct the client to. =
Since things are closely tied together, the client just needs to =
effectively known an identifier for the RS, and this is currently =
implemented as a URI. Once the client has that identifier, it knows how =
to dispatch that token to that instance of the RS.
There is no good reason why the AS should =
be involved in that step. 
OAuth 2.0 is/was implicitly mandating a strong relationship =
between ASs and RSs which makes it non scalable.
GNAP =
should be based on a simple trust relationship : a given RS trusts some =
ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time =
of an access token request) the RSs that are trusting it.
A client could first talk to a "global =
service provider" which has the knowledge of the different RSs =
affiliated to it. 
(2) The client knows what =
kind of thing it=E2=80=99s looking for, but doesn=E2=80=99t know who to =
ask it from. 
Once again, the client could first talk to =
a "global service provider" which has the knowledge of the different RSs =
affiliated to it. 
There=E2=80=99s a =
cross-domain trust that=E2=80=99s bridged by the AS, and the AS needs to =
dispatch to different resources depending on which user logged in (and =
possibly what the user consented to). To make things more concrete, the =
client needs to get driver=E2=80=99s license information, but doesn=E2=80=99=
t know ahead of time which of the many state/provincial bureaus to call =
to get that information because it doesn=E2=80=99t know yet who the user =
is. 
When a user has a driving license, he =
knows its issuer. The user can then provide some hint to the =
client.
The AS will know who the =
user is once they log in and approve things, and so it can direct the =
client to call the correct RS. Since this is a relatively simple API =
with a pre-negotiated cross-domain trust, the AS returns a URL that the =
client presents the token at. 
 A single AS should not be aware of =
all the attributes a user has. 

As far as I know, in both of these cases, the token is only =
good for that API and not others =E2=80=94 but more on that =
later.

A =
simple thing to do is just give back a URL with the access token, which =
tells the client where to go. 

	{
		=
=E2=80=9Caccess_token=E2=80=9D: {
			=
=E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
			=
=E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
		=
}
	}

This is good for some kinds of APIs, but it=E2=80=99s =
limiting because not all APIs dispatch based on the URL. An AS might =
want to divvy up access tokens to an API that=E2=80=99s keyed on =
headers, or verbs, or any number of things. And it doesn=E2=80=99t tell =
us immediately what to do about non-exact URL matches. Can the client =
add query parameters and still use the token? What about path segments? =
I like that this simple approach addresses some common deployments that =
we already see today (see above), it=E2=80=99s not universal. Do we want =
or need a universal description language for directing where tokens =
go?

This also =
opens up a whole new set of security questions. If the AS can now direct =
the client where to use the token, could a rogue AS convince a legit =
client to use a stolen token at the wrong RS? And what if the client =
ignores the directions from the AS entirely? Could this open up new =
avenues of attack?

This is just the start, too. Things get even more complex if =
the client can ask for multiple different kinds of resources at once. =
What if the AS decides that the client needs a hyper-focused directed =
token for one part of the API, but can use a general token for other =
stuff? Can it signal that to the client? And if it can, does that mean =
that all clients need to be prepared for that kind of thing?

I firmly believe that =
whatever we build in GNAP, we need to optimize for the overwhelmingly =
common use case of a client getting a single access token to call APIs =
that it already knows about. Anything we add on top of that really =
can=E2=80=99t get in the way of this, because if it does, there=E2=80=99s =
very small chance that people will try to use this for everyday things. =
Keep the simple things simple, and the complex things possible, after =
all.

I=E2=80=99m=
 really looking forward to hearing what the community thinks about these =
use cases, and hopefully the people I=E2=80=99ve chatted with offline =
about this can join the conversation and provide more light than I was =
able to.
The two use cases which are considered =
above are:
(1) The client knows what =
resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99=
s hosted.
(2) The client knows what kind of thing it=E2=80=99=
s looking for, but doesn=E2=80=99t know who to ask it from. 
That does not mean in any way that these =
two use cases should be solved by placing the AS at the centre of the =
solution.
Denis

 =E2=80=94 Justin


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


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

This communication, including any attachments, is =
confidential. If you are not the intended recipient, you should not read =
it - please contact me immediately, destroy it, and do not copy or use =
any part of this communication or disclose anything about it. Thank you. =
Please note that this communication does not designate an information =
system for the purposes of the Electronic Transactions Act =
2002.

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






This communication, including any attachments, is =
confidential. If you are not the intended recipient, you should not read =
it - please contact me immediately, destroy it, and do not copy or use =
any part of this communication or disclose anything about it. Thank you. =
Please note that this communication does not designate an information =
system for the purposes of the Electronic Transactions Act =
2002.

=

--Apple-Mail=_41DD2BAF-E9DB-456A-890B-BC401539B9BC--


From nobody Wed Jul  8 09:55: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 D08113A0F46 for ; Wed,  8 Jul 2020 09:55:42 -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 p0V7y_cew3C4 for ; Wed,  8 Jul 2020 09:55:41 -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 8E2513A0F2A for ; Wed,  8 Jul 2020 09:55:40 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id f5so39214509ljj.10 for ; Wed, 08 Jul 2020 09:55: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=UqL2i4B5EzHeZKW0JWY6phcFZSo1r7E5FlSCmcpkbH0=; b=LlyNisBsyVCXah+IUMbgcIiLFZyBWJWSjtP5SzMXuDxc/ALjgtgwX5pVdIwuM/38yp LKKznUo86bVlX59rDjyXroHjiOZvL+AtGpUoZHk0DnQ95C89JE+/sxTeuGGJnckB8HoC VJEQnpEk4dHUWSCJp8dQN4gFMynGsG5YV/fPWslpUa1DrIOtRFX2JosWeAWYkdnTlfiH dLxKgynS0YKmJ/keF3akI/92kuV3LSGR7X9ZbRma1KrkpZ4UXs5Roh91IJUTu7z/kflX Id2XesTQdVuZOz45nH25+1XbS1Wo3/36SGOZLRcE++TnZcwCpsCSXrESva2ozKweu4Rq n+1Q==
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=UqL2i4B5EzHeZKW0JWY6phcFZSo1r7E5FlSCmcpkbH0=; b=jGpoARtaAfNsjtmI6qQXjgApbR4PufB5epqjv8XHd9zsAzRsk47+JXdiiZwgk8hNuj VVEarnqcPNERkuXvFZcGhVQ9RrZMFeTik/lU0I6rHE1GGR5G46dV+Ppmjmxlbrt8p92z k/G8752USSP4YqlZPGyQZ55LEIv9T+y0YlbVyv7EqjbW3TDK+0+XkLOez0aBjQNKcX6c U5OCxViln+528/zhbHB77cz8X+98CXmBmFvoPapJmsR2F4+9m80k2bOlyPw188Ds3KSh LWa+kpr7noDMa3blMoI+GRXYh8g1LIqmJl0XIMxjQaBAGXswZ/DOEc6PUQurH2EYMIsy 6/Cw==
X-Gm-Message-State: AOAM533LOp4wz0kn6HKIXPC8Xfyb7jpSHgKte8cjrxkE4gnNnVDYyuTq WDIOULwuDrqFqeVyWTvIImNvV8O0h8tJ3ffuufSH/rSGUq4=
X-Google-Smtp-Source: ABdhPJx9tWJdeMOfT/h6bR5kP4Jv93ebXmKcZCFlbRpins/crTF15W4QG6T7xMQ2DSRxsk8F1my/78qsKyuogEjVkbk=
X-Received: by 2002:a05:651c:547:: with SMTP id q7mr32200303ljp.437.1594227338524;  Wed, 08 Jul 2020 09:55:38 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>
In-Reply-To: <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>
From: Dick Hardt 
Date: Wed, 8 Jul 2020 09:55:02 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000343e8205a9f0fa9e"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 08 Jul 2020 16:55:43 -0000

--000000000000343e8205a9f0fa9e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Justin: it is disappointing that you deflect from responding to:

It=E2=80=99s not surprising that this is the case, as the XAuth protocol wa=
s not
> designed with polymorphism as a tool to consider. This is exactly the
> reason that I say we should have polymorphism in the toolbox from the
> start, as it allows us to avoid this kind of awkwardness in many cases.
>

 What evidence do you have to make this statement? "XAuth protocol was not
designed with polymorphism as a tool to consider"

Similarly, you deflected responding to your statement:

"GNAP should make use of a polymorphic protocol structure"

How are we going to have a productive conversation when you won't
acknowledge mistakes, either intentional, or unintentional?

wrt. your proposal to represent an authorization request as an array of
scopes is overly simplistic. Both XYZ and XAuth represent the request as an
object to enable a request richer than just an array of scopes.

/Dick



On Wed, Jul 8, 2020 at 7:03 AM Justin Richer  wrote:

> I=E2=80=99m glad that you=E2=80=99re looking at polymorphism as a possibl=
e solution to
> this, though I would contend that this particular style of polymorphism i=
s
> not doing much more than pushing the mutual-exclusivity check down a laye=
r
> instead of solving it.
>
> Using multiple types can in fact solve this problem, and several others,
> as long as you=E2=80=99re willing to let go of the syntax that OAuth 2 in=
vented to
> solve a problem that we don=E2=80=99t have to solve here (passing an arra=
y-type
> value over the front channel). In XYZ=E2=80=99s syntax, the request for a=
 single
> access token would look like this:
>
> {
>   =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=
=E2=80=9D ]
> }
>
> And the request for the multiple access tokens would look like this:
>
> {
>   =E2=80=9Cresources": {
>      =E2=80=9Creader": [ =E2=80=9Cread=E2=80=9D ],
>      =E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
>   }
> }
>
> I find this to be much simpler to parse and generate, as you no longer
> need to check for a specially-reserved field name (=E2=80=9Ctype=E2=80=9D=
), and you no
> longer have to do a sub-parse on one of the values to get what you really
> want (the space-separated scope string into a set). It=E2=80=99s also a l=
ot simpler
> for the developers that need to write this.
>
>  =E2=80=94 Justin
>
> On Jul 7, 2020, at 7:30 PM, Dick Hardt  wrote:
>
>
>
> On Tue, Jul 7, 2020 at 3:40 AM Justin Richer  wrote:
>
>> I wanted to respond to this comment more fully:
>>
>> > wrt. my authorization / authorizations oddness, polymorphism would not
>> solve it as the contents of both authorization / authorizations in XAuth
>> are objects.
>>
>> It=E2=80=99s not surprising that this is the case, as the XAuth protocol=
 was not
>> designed with polymorphism as a tool to consider. This is exactly the
>> reason that I say we should have polymorphism in the toolbox from the
>> start, as it allows us to avoid this kind of awkwardness in many cases.
>>
>
>  What evidence do you have to make this statement? "XAuth protocol was no=
t
> designed with polymorphism as a tool to consider"
>
> It sounds like you are saying I did not consider polymorphism in the XAut=
h
> protocol design.
>
> I will restate my comment above about polymorphism.
>
> Using different JSON types does not solve the problem, but as I suggest i=
n
> my comments, polymorphism of different JSON objects is one solution. An
> authorization, or a dictionary of authorizations. It has the restriction
> that the string "type" cannot be used as a label in the dictionary. An
> example:
>
> {
>     "authorizations" {
>         "type": "oauth_scope",
>         "scope": "read write"
>     }
> }
>
> {
>     "authorizations" {
>         "reader": {
>             "type": "oauth_scope",
>             "scope": "read"
>         },
>         "writer": {
>             "type": "oauth_scope",
>             "scope": "write"
>         },
>     }
> }
>
>
> I am looking at making this change in XAuth and in the implementation.
>
>
>
> =E1=90=A7
>
>
>

--000000000000343e8205a9f0fa9e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Justin:=
 it is disappointing=C2=A0that you deflect from responding to:=C2=A0
It=E2=80=99s not surprising that this is the case, as the XAuth=
 protocol was not designed with polymorphism as a tool to consider. This is=
 exactly the reason that I say we should have polymorphism in the toolbox f=
rom the start, as it allows us to avoid this kind of awkwardness in many ca=
ses.

=C2=A0What evidence do you have to=
 make this statement? "XAuth protocol was not designed with polymorphi=
sm as a tool to consider"
Similarly, you deflected responding to your statement:

"GNAP should make=
 use of a polymorphic protocol structure"
<=
/font>

How are we going to have a productive conve=
rsation when you won't acknowledge mistakes, either intentional, or uni=
ntentional?

wrt. your proposal to represent an authorization=C2=A0requ=
est as an array of scopes is overly simplistic. Both XYZ and XAuth represen=
t the request as an object to enable a request richer than just an array of=
 scopes.=C2=A0

/Dick
<=
br>

<=
br>
On Wed,=
 Jul 8, 2020 at 7:03 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m glad=
 that you=E2=80=99re looking at polymorphism as a possible solution to this=
, though I would contend that this particular style of polymorphism is not =
doing much more than pushing the mutual-exclusivity check down a layer inst=
ead of solving it.=C2=A0

Using multiple types can in fac=
t solve this problem, and several others, as long as you=E2=80=99re willing=
 to let go of the syntax that OAuth 2 invented to solve a problem that we d=
on=E2=80=99t have to solve here (passing an array-type value over the front=
 channel). In XYZ=E2=80=99s syntax, the request for a single access token w=
ould look like this:

{
=C2=A0 =E2=80=9Cr=
esources=E2=80=9D: [ =E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=E2=80=9D ]
}

And the request for the multiple access to=
kens would look like this:

{
=C2=A0 =E2=
=80=9Cresources": {
=C2=A0 =C2=A0 =C2=A0=E2=80=9Creader"=
;: [ =E2=80=9Cread=E2=80=9D ],
=C2=A0 =C2=A0 =C2=A0=E2=80=9Cwrite=
r=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
=C2=A0 }
}

I find this to be much simpler to parse and generate, =
as you no longer need to check for a specially-reserved field name (=E2=80=
=9Ctype=E2=80=9D), and you no longer have to do a sub-parse on one of the v=
alues to get what you really want (the space-separated scope string into a =
set). It=E2=80=99s also a lot simpler for the developers that need to write=
 this.

=C2=A0=E2=80=94 Justin

<=
blockquote type=3D"cite">
On Jul 7, 2020, at 7:30 PM, Dick Hardt <dick.hardt@gmail.co=
m> wrote:


=

On Tue=
, Jul 7, 2020 at 3:40 AM Justin Richer <jricher@mit.edu> wrote:
I wanted to respond to this comment mor=
e fully:



> wrt. my authorization / authorizations oddness, polymorphism would not=
 solve it as the contents of both authorization / authorizations in XAuth a=
re objects. 



It=E2=80=99s not surprising that this is the case, as the XAuth protocol wa=
s not designed with polymorphism as a tool to consider. This is exactly the=
 reason that I say we should have polymorphism in the toolbox from the star=
t, as it allows us to avoid this kind of awkwardness in many cases.

=C2=A0What evidence do you have to make this s=
tatement? "XAuth protocol was not designed with polymorphism as a tool=
 to consider"

It sounds like you are sayi=
ng I did not consider polymorphism in the XAuth protocol design.
=

I will restate my comment above about polymorphism.=C2=A0

Using different JSON types does not solve the proble=
m, but as I suggest in my comments, polymorphism of different JSON objects =
is one solution. An authorization, or a dictionary of authorizations. It ha=
s the restriction that the string "type" cannot be used as a labe=
l in the dictionary. An example:

{
=C2=A0 =C2=
=A0 "authorizations" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type&=
quot;: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope&=
quot;: "read write"
=C2=A0 =C2=A0 }
}

{
=C2=A0 =
=C2=A0 "authorizations" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "re=
ader": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type"=
: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu=
ot;scope": "read"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "writer": {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "type": "oauth_scope",
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": "write"
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 }
}


I am looking at making this change in XAuth and in the=
 implementation.



3D""=E1=90=A7





--000000000000343e8205a9f0fa9e--


From nobody Wed Jul  8 10:11: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 9304B3A0FD9 for ; Wed,  8 Jul 2020 10:10: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 zAn8hx4ZI6dY for ; Wed,  8 Jul 2020 10:10:55 -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 073483A1044 for ; Wed,  8 Jul 2020 10:10:41 -0700 (PDT)
Received: by mail-ot1-x32b.google.com with SMTP id h13so16904932otr.0 for ; Wed, 08 Jul 2020 10:10: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=JvFzQvF2wNAlsK6eUTWunmxbUErSl2FxJHP6vxIKer8=; b=DnEy58abrvTsb69BLpNaxBI58PwWjfAcsQluabL9J1U5A7cCITAaVwZ4n2UvxF6zSD S79rUnBT/voBQaSxHhe4/niljDStOoShXRniVbIfUgAOEb2NEg5I/z94SWAD4yfDxUfa /QEQmO30UvTx4zx+xCX8YOdtV0EcYB551wBtJv+mIfo03JCCxuscM3MrwdShH7ms9HSL J2NKn1/ph8GX20yJvSsUwtc7/baRAdzl7RnyqDNU0J+EZ916++caDLIMclNpH6ueqrzw cLS4s2kWRiXaRBA6w6VEf8bhby8CWDq3kEjp6Kdf43DnvIW4lSX9xOWhx3gzCUDYh0HK hvaA==
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=JvFzQvF2wNAlsK6eUTWunmxbUErSl2FxJHP6vxIKer8=; b=T6J3I4XYgZ2jMEi/QhMHZ0PaJvgp/Hq/pWGQc1w/EySP/ir4EeEMZ9+62ItSPl+HEM sf1rJLv+ZUNe/6cSMj9Iun4CXbGrD9IxiygYp/lRSCR/8nmSB7gdljLs1jG6w+I7An1M iLvnXmnhdy1Mi2vXmLBfFb3GwKMsdLiGJIYyuyN3meM/5+Or3tvWUIMqK2IRBnAOkf5U uLRRZAj8C9nc/f7lahYZ1uA5Q/F/4fcFqnUqu1elbRDP+jiw9tVU6+zMmB53d2XXr1rk xEpgdujedRKisAvh2eVpXFGuuyWWV+fhNeAWtKDc26J+RJQ6ojha63HbINneGM+3Bj+Q 9s8w==
X-Gm-Message-State: AOAM530xnGVe1MNxpUZYGbyM/S3t/Akvrg7VLiaCTaLTex5uhuf7640T x6nvOh2iAVOCgOkGWi+0tnuIBaMrnWwx3cC0SXs=
X-Google-Smtp-Source: ABdhPJxxj7rN5AEaRDQHYrHGq2o8sVpEPgpFY9qcUJ6soMBdZrRs31qNjAgSwvGaTP+E2/HWZq0PWkp0N/WmTnw7csQ=
X-Received: by 2002:a9d:66ca:: with SMTP id t10mr33657650otm.358.1594228241025;  Wed, 08 Jul 2020 10:10:41 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu> 
In-Reply-To: 
From: Tom Jones 
Date: Wed, 8 Jul 2020 10:10:29 -0700
Message-ID: 
To: Dick Hardt 
Cc: Justin Richer , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ff5bdc05a9f12fc7"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 08 Jul 2020 17:11:04 -0000

--000000000000ff5bdc05a9f12fc7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

a somewhat milder response might be.
It seems that justin's proposal is not, in fact, a grant negotiation, but a
generalized token format.
So - what could that mean here?
I have a problem with the whack-a-mole approach of OAuth, with RAR JAR ad
infinitum.
That is a never-ending stream of hacks.
if Justin's proposal is to be considered seriously, it must be at some
higher level that GNAP..
I suggest  that the current approach of xauth txauth authxyz is not really
headed to a convergence.
Perhaps we need to start with an abstract set of goals and data flows.  One
that includes the user/RO.
I do have one for healthcare - but i am short of time right now to
generalize it.
One item I would like to see resolved early is to remove the dependency on
transport layer security. One that includes the handling of key roll-over.
In Kantara we focused first on the legal responsibilities of the token
maker. That problem seems to have consumed FAPI, altho they have multiple
names for it.
In the real world we have legal entities (natural and unnatural) and legal
names (brands) as well as pseudonyms. OAuth just had endpoints with SSL
keys and certs.  How about we start there?
Peace ..tom


On Wed, Jul 8, 2020 at 9:55 AM Dick Hardt  wrote:

> Justin: it is disappointing that you deflect from responding to:
>
> It=E2=80=99s not surprising that this is the case, as the XAuth protocol =
was not
>> designed with polymorphism as a tool to consider. This is exactly the
>> reason that I say we should have polymorphism in the toolbox from the
>> start, as it allows us to avoid this kind of awkwardness in many cases.
>>
>
>  What evidence do you have to make this statement? "XAuth protocol was no=
t
> designed with polymorphism as a tool to consider"
>
> Similarly, you deflected responding to your statement:
>
> "GNAP should make use of a polymorphic protocol structure"
>
> How are we going to have a productive conversation when you won't
> acknowledge mistakes, either intentional, or unintentional?
>
> wrt. your proposal to represent an authorization request as an array of
> scopes is overly simplistic. Both XYZ and XAuth represent the request as =
an
> object to enable a request richer than just an array of scopes.
>
> /Dick
>
>
>
> On Wed, Jul 8, 2020 at 7:03 AM Justin Richer  wrote:
>
>> I=E2=80=99m glad that you=E2=80=99re looking at polymorphism as a possib=
le solution to
>> this, though I would contend that this particular style of polymorphism =
is
>> not doing much more than pushing the mutual-exclusivity check down a lay=
er
>> instead of solving it.
>>
>> Using multiple types can in fact solve this problem, and several others,
>> as long as you=E2=80=99re willing to let go of the syntax that OAuth 2 i=
nvented to
>> solve a problem that we don=E2=80=99t have to solve here (passing an arr=
ay-type
>> value over the front channel). In XYZ=E2=80=99s syntax, the request for =
a single
>> access token would look like this:
>>
>> {
>>   =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=
=E2=80=9D ]
>> }
>>
>> And the request for the multiple access tokens would look like this:
>>
>> {
>>   =E2=80=9Cresources": {
>>      =E2=80=9Creader": [ =E2=80=9Cread=E2=80=9D ],
>>      =E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
>>   }
>> }
>>
>> I find this to be much simpler to parse and generate, as you no longer
>> need to check for a specially-reserved field name (=E2=80=9Ctype=E2=80=
=9D), and you no
>> longer have to do a sub-parse on one of the values to get what you reall=
y
>> want (the space-separated scope string into a set). It=E2=80=99s also a =
lot simpler
>> for the developers that need to write this.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 7, 2020, at 7:30 PM, Dick Hardt  wrote:
>>
>>
>>
>> On Tue, Jul 7, 2020 at 3:40 AM Justin Richer  wrote:
>>
>>> I wanted to respond to this comment more fully:
>>>
>>> > wrt. my authorization / authorizations oddness, polymorphism would no=
t
>>> solve it as the contents of both authorization / authorizations in XAut=
h
>>> are objects.
>>>
>>> It=E2=80=99s not surprising that this is the case, as the XAuth protoco=
l was not
>>> designed with polymorphism as a tool to consider. This is exactly the
>>> reason that I say we should have polymorphism in the toolbox from the
>>> start, as it allows us to avoid this kind of awkwardness in many cases.
>>>
>>
>>  What evidence do you have to make this statement? "XAuth protocol was
>> not designed with polymorphism as a tool to consider"
>>
>> It sounds like you are saying I did not consider polymorphism in the
>> XAuth protocol design.
>>
>> I will restate my comment above about polymorphism.
>>
>> Using different JSON types does not solve the problem, but as I suggest
>> in my comments, polymorphism of different JSON objects is one solution. =
An
>> authorization, or a dictionary of authorizations. It has the restriction
>> that the string "type" cannot be used as a label in the dictionary. An
>> example:
>>
>> {
>>     "authorizations" {
>>         "type": "oauth_scope",
>>         "scope": "read write"
>>     }
>> }
>>
>> {
>>     "authorizations" {
>>         "reader": {
>>             "type": "oauth_scope",
>>             "scope": "read"
>>         },
>>         "writer": {
>>             "type": "oauth_scope",
>>             "scope": "write"
>>         },
>>     }
>> }
>>
>>
>> I am looking at making this change in XAuth and in the implementation.
>>
>>
>>
>> =E1=90=A7
>>
>>
>> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000ff5bdc05a9f12fc7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


a somewhat milder response might be.
It seems that jus=
tin's proposal is not, in fact, a grant negotiation, but a generalized =
token format.
So - what could that mean here?
I have a =
problem with the whack-a-mole approach of OAuth, with RAR JAR ad infinitum.=

That is a never-ending stream of hacks.
if Justin'=
s proposal is to be considered seriously, it must be at some higher level t=
hat GNAP..
I suggest=C2=A0 that the current approach of xauth txa=
uth authxyz is not really headed to a convergence.
Perhaps we nee=
d to start with an abstract set of goals and data flows.=C2=A0 One that inc=
ludes the user/RO.
I do have one for healthcare - but i am short =
of time right now to generalize it.
One item I would like to see =
resolved early is to remove the dependency on transport layer security. One=
 that includes the handling of key roll-over.
In Kantara we focus=
ed first on the legal responsibilities of the token maker. That problem see=
ms to have consumed FAPI, altho they have multiple names for it.
=
In the real world we have legal entities (natural and unnatural) and legal =
names (brands) as well as pseudonyms. OAuth just had endpoints with SSL key=
s and certs.=C2=A0 How about we start there?
Peace ..tom


On Wed, Jul 8, 2020 =
at 9:55 AM Dick Hardt <dick.hard=
t@gmail.com> wrote:
Justin: it is disappointing=C2=A0that you deflect from responding to:=
=C2=A0

It=E2=80=99s not surprising that this is the case,=
 as the XAuth protocol was not designed with polymorphism as a tool to cons=
ider. This is exactly the reason that I say we should have polymorphism in =
the toolbox from the start, as it allows us to avoid this kind of awkwardne=
ss in many cases.

=C2=A0What evidence d=
o you have to make this statement? "XAuth protocol was not designed wi=
th polymorphism as a tool to consider"
<=
font color=3D"#500050">Similarly, you deflected responding to your statemen=
t:

"GNA=
P should make use of a polymorphic protocol structure"

How are we going to have a pro=
ductive conversation when you won't acknowledge mistakes, either intent=
ional, or unintentional?

wrt. your proposal to represent an authorizat=
ion=C2=A0request as an array of scopes is overly simplistic. Both XYZ and X=
Auth represent the request as an object to enable a request richer than jus=
t an array of scopes.=C2=A0

/Dick



On Wed, Jul 8, 2020 at 7:03 AM Justin Richer <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">
I=E2=80=99m glad that=
 you=E2=80=99re looking at polymorphism as a possible solution to this, tho=
ugh I would contend that this particular style of polymorphism is not doing=
 much more than pushing the mutual-exclusivity check down a layer instead o=
f solving it.=C2=A0

Using multiple types can in fact sol=
ve this problem, and several others, as long as you=E2=80=99re willing to l=
et go of the syntax that OAuth 2 invented to solve a problem that we don=E2=
=80=99t have to solve here (passing an array-type value over the front chan=
nel). In XYZ=E2=80=99s syntax, the request for a single access token would =
look like this:

{
=C2=A0 =E2=80=9Cresour=
ces=E2=80=9D: [ =E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=E2=80=9D ]
}

And the request for the multiple access tokens =
would look like this:

{
=C2=A0 =E2=80=9C=
resources": {
=C2=A0 =C2=A0 =C2=A0=E2=80=9Creader": [ =
=E2=80=9Cread=E2=80=9D ],
=C2=A0 =C2=A0 =C2=A0=E2=80=9Cwriter=E2=
=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
=C2=A0 }
}

I find this to be much simpler to parse and generate, as y=
ou no longer need to check for a specially-reserved field name (=E2=80=9Cty=
pe=E2=80=9D), and you no longer have to do a sub-parse on one of the values=
 to get what you really want (the space-separated scope string into a set).=
 It=E2=80=99s also a lot simpler for the developers that need to write this=
.

=C2=A0=E2=80=94 Justin

On Jul 7, 2020, at 7:30 PM, Dick Hardt <dick.hardt@gmail.com=
> wrote:



<=
div class=3D"gmail_quote">
On Tue, Jul=
 7, 2020 at 3:40 AM Justin Richer <jricher@mit.edu> wrote:
I wanted to respond to this comment more f=
ully:



> wrt. my authorization / authorizations oddness, polymorphism would not=
 solve it as the contents of both authorization / authorizations in XAuth a=
re objects. 



It=E2=80=99s not surprising that this is the case, as the XAuth protocol wa=
s not designed with polymorphism as a tool to consider. This is exactly the=
 reason that I say we should have polymorphism in the toolbox from the star=
t, as it allows us to avoid this kind of awkwardness in many cases.

=C2=A0What evidence do you have to make this s=
tatement? "XAuth protocol was not designed with polymorphism as a tool=
 to consider"

It sounds like you are sayi=
ng I did not consider polymorphism in the XAuth protocol design.
=

I will restate my comment above about polymorphism.=C2=A0

Using different JSON types does not solve the proble=
m, but as I suggest in my comments, polymorphism of different JSON objects =
is one solution. An authorization, or a dictionary of authorizations. It ha=
s the restriction that the string "type" cannot be used as a labe=
l in the dictionary. An example:

{
=C2=A0 =C2=
=A0 "authorizations" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type&=
quot;: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope&=
quot;: "read write"
=C2=A0 =C2=A0 }
}

{
=C2=A0 =
=C2=A0 "authorizations" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "re=
ader": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type"=
: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu=
ot;scope": "read"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "writer": {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "type": "oauth_scope",
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": "write"
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 }
}


I am looking at making this change in XAuth and in the=
 implementation.



3D""=E1=90=A7




-- 

Txauth mailing list

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



--000000000000ff5bdc05a9f12fc7--


From nobody Wed Jul  8 10:13: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 418D23A0FD0 for ; Wed,  8 Jul 2020 10:13:15 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=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 hedlKHt8t3rt for ; Wed,  8 Jul 2020 10:13: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 25FDD3A1023 for ; Wed,  8 Jul 2020 10:12:09 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d14 with ME id 0hBx230034FMSmm03hC58l; Wed, 08 Jul 2020 19:12:08 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 08 Jul 2020 19:12:08 +0200
X-ME-IP: 86.238.65.197
To: Justin Richer , Tobias Looker 
Cc: txauth@ietf.org
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <6846D2F0-5096-404B-A529-676146392F45@mit.edu>  <2D3EEF56-BD86-42DF-82D2-7595E19C5350@mit.edu>
From: Denis 
Message-ID: <9c434f67-77fa-8a80-5ac0-4061fd5bf02c@free.fr>
Date: Wed, 8 Jul 2020 19:11:52 +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: <2D3EEF56-BD86-42DF-82D2-7595E19C5350@mit.edu>
Content-Type: multipart/alternative; boundary="------------96E7F1D5B0FADA99131765CE"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 08 Jul 2020 17:13:15 -0000

This is a multi-part message in MIME format.
--------------96E7F1D5B0FADA99131765CE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Justin,
> I think there are two interesting layers here:
>
>  - Information that the client needs to know. This is what started the 
> thread, the whole “how and where am I allowed to use this token” 
> question.
> This is stuff that would be put alongside the token in the response 
> from the AS, not inside the token.

If the "how and where am I allowed to use this token” is sent alongside 
the token in the response from the AS, then you are allowing the AS
to know which RS(s) will be able to consume the access token. This 
should be prevented for privacy reasons (i.e. the AS would be able to 
act as Big Brother).

>
>  - Information that the RS needs to know. This is I think where the 
> attenuation, proofing, and the actual rights associated with the token 
> would go.
> This is stuff that would either be in the token itself or in a  return 
> from an introspection style call.

With an introspection style call you are allowing the AS to know to 
which RS(s) the access token has arrived. This should be prevented for 
privacy reasons
(i.e. the AS would be able to act as Big Brother).

Denis

>
> Both of these fit into the “consistent token model” part of GNAP, but 
> different aspects need to be communicated in different ways.
>
>  — Justin
>
>> On Jul 7, 2020, at 8:01 PM, Tobias Looker > > wrote:
>>
>> I've also been thinking about the parallels between ZCAP's and 
>> OAuth2.0 access tokens. To me a ZCAP is a less opaque, semantically 
>> richer capability format, whereas an access_token is traditionally 
>> much simpler. The key here though is I still see an access_token as a 
>> form of capability. It appears in general one of the trade offs we 
>> will be faced with is either:
>>
>> 1. Keeping the capability received from a GNAP flow (e.g an 
>> access_token) opaque to the client and externalizing any greater 
>> information about how to use the capability (such as in your proposal 
>> in the first email of this thread).
>> 2. Internalizing information about the capabilities utility and any 
>> greater context about it which means the capability is no longer opaque.
>>
>> With that aside, the notable features in general I would like GNAP to 
>> consider from ZCAP's, are the following.
>>
>> - Delegatable capabilities (bonus if this mechanism includes the 
>> ability to attenuate during delegation) - Consider the example where 
>> a client or RP (RP1) receives some form of access_token (capability) 
>> from an AS and would like to delegate this to another RP (RP2) so 
>> they can access the same resources. If including 
>> attenuation this would mean that during this delegation (RP1->RP2), 
>> RP1 could narrow the scope of the original access it received so that 
>> RP2 only gets a subset of the original scope.
>> - Bound capabilities - Similar in some ways to dPop, essentially 
>> establishing the ability to bind an access_token (capability) to the 
>> party that should be able to use it (invoker). I see this as a must 
>> have in order to be able to do attenuated delegation as described above.
>>
>> Thanks,
>> Mattr website  		
>> *Tobias Looker*
>> Mattr
>> +64 (0) 27 378 0461
>> tobias.looker@mattr.global 
>> Mattr website  	Mattr on LinkedIn 
>>  	Mattr on Twitter 
>>  	Mattr on Github 
>> 
>>
>>
>> This communication, including any attachments, is confidential. If 
>> you are not the intended recipient, you should not read it - please 
>> contact me immediately, destroy it, and do not copy or use any part 
>> of this communication or disclose anything about it. Thank you. 
>> Please note that this communication does not designate an information 
>> system for the purposes of the Electronic Transactions Act 2002.
>>
>>
>> On Wed, Jul 8, 2020 at 8:39 AM Justin Richer > > wrote:
>>
>>     I’ve been thinking more about these use cases, and it might help
>>     us to think of GNAP’s access tokens as capabilities in the
>>     computer security sense — but more specifically, capabilities
>>     that are delivered with their own context for use. In that way,
>>     an otherwise naive client can be handed an access token and
>>     simply know exactly what to do with it. This context would be
>>     delivered alongside the token, so the token material itself
>>     remains opaque to the client.
>>
>>     I wanted to bring up a W3C spec for a capabilities model based on
>>     linked data:
>>
>>     https://w3c-ccg.github.io/zcap-ld/
>>
>>     Building a fully featured capabilities context is difficult, at
>>     the very least. And unfortunately, I don’t think this spec
>>     actually gives us any viable solutions to work with. In
>>     particular the “actions” section is effectively blank, offloading
>>     the work to an external JSONLD process (side note, this is one of
>>     the problems I have with specs based on JSONLD, they externalize
>>     the important parts into local contexts and break
>>     interoperability — but I digress). But at least it’s another way
>>     of looking at the problem space that might be outside the
>>     familiar zone of many of the OAuth world.
>>
>>      — Justin
>>
>>>     On Jun 26, 2020, at 9:23 AM, Justin Richer >>     > wrote:
>>>
>>>     On Jun 25, 2020, at 9:07 PM, Tobias Looker
>>>     >
>>>     wrote:
>>>>
>>>>     I find this feature interesting and think it could be an
>>>>     important pattern going forward to enable an AS to be able to
>>>>     describe the utility of a token to the client, however as
>>>>     already pointed out in the thread I think there is some
>>>>     potential hidden complexity that would need to be ironed out
>>>>     such that it does not make the simple things complicated.
>>>>
>>>>     Justin, do you see this feature as something the client has to
>>>>     explicitly request, i.e "please give me access and instructions
>>>>     on how to use my access" or rather that the AS would just
>>>>     return this information in conjunction with the access token if
>>>>     it had it available?
>>>>
>>>
>>>     This is something that I’d brought up as a possibility on the
>>>     previous thread — something like a flag the client would set.
>>>     This would be especially important if the AS wants to return
>>>     multiple access tokens but the client requested 1, or the client
>>>     requested N and the AS wants to return M in response. Basically
>>>     any time there’s a mismatch, that’s extra complexity on the
>>>     client that I really don’t think we want to be universal. A flag
>>>     to turn that kind of direction and splitting on would be a
>>>     potential start. But there are potential snags here too, and it
>>>     comes down to how you manage the defaults...
>>>
>>>>     > This is just the start, too. Things get even more complex if
>>>>     the client can ask for multiple different kinds of resources at
>>>>     once. What if the AS decides that the client needs a
>>>>     hyper-focused directed token for one part of the API, but can
>>>>     use a general token for other stuff? Can it signal that to the
>>>>     client? And if it can, does that mean that all clients need to
>>>>     be prepared for that kind of thing?
>>>>
>>>>     Would a potential default be that if a client did for any
>>>>     reason not support processing the additional information
>>>>     returned with the access_token, just to ignore it? I think in
>>>>     the spirit of keeping the simple things simple, this
>>>>     potentially makes sense?
>>>
>>>     That’s the real trick, if you ask me. It has to be :safe: for a
>>>     client to ignore this information. Which means the AS can’t rely
>>>     on the client “doing the right thing” with the information in
>>>     the “token directions” portion of the response. Even setting
>>>     aside the advanced and related “split tokens” idea above, we
>>>     need to make sure that an AS/RS setup is built such that if the
>>>     AS tells a client “only do X with your token” and the client
>>>     does “Y”, then there are other protections and practices in
>>>     place to prevent things from going haywire if the client does
>>>     “Y” either by accident or through ignorance.
>>>
>>>     If OAuth 2 has taught us anything, it’s that client applications
>>>     are going to be the laziest participants in the security model.
>>>     And that makes sense, really — security isn’t what the client
>>>     apps are trying to do, they’re trying to use the RS to do
>>>     something. So we need to make sure that whatever system we
>>>     design will fail on the safe side as much as possible, and keep
>>>     things simple for the client.
>>>
>>>>
>>>>     > here are some worked out samples of this:
>>>>     https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
>>>>     https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
>>>>     Peace ..tom
>>>>
>>>>     As one of the authors of those mentioned drafts, I am
>>>>     interested in discussing that, but perhaps on a seperate
>>>>     thread? As at least the bound assertion spec
>>>>     is primarily concerned with binding mechanisms for the
>>>>     artifacts produced from an authorization flow (specifically
>>>>     identity claims), whereas I think directed access tokens is
>>>>     just more generally talking about whether GNAP should support
>>>>     an AS conveying how to use an access_token it produces during a
>>>>     flow with a client.
>>>>
>>>
>>>     I think that these are separate issues as well.
>>>
>>>      — Justin
>>>
>>>>     Thanks,
>>>>     Mattr website  		
>>>>     *Tobias Looker*
>>>>     Mattr
>>>>     +64 (0) 27 378 0461
>>>>     tobias.looker@mattr.global 
>>>>     Mattr website  	Mattr on LinkedIn
>>>>      	Mattr on
>>>>     Twitter  	Mattr on Github
>>>>     
>>>>
>>>>
>>>>     This communication, including any attachments, is confidential.
>>>>     If you are not the intended recipient, you should not read it -
>>>>     please contact me immediately, destroy it, and do not copy or
>>>>     use any part of this communication or disclose anything about
>>>>     it. Thank you. Please note that this communication does not
>>>>     designate an information system for the purposes of the
>>>>     Electronic Transactions Act 2002.
>>>>
>>>>
>>>>     On Wed, Jun 24, 2020 at 10:14 PM Denis >>>     > wrote:
>>>>
>>>>         Justin, I fear we are still far away from an agreement
>>>>         about what this BoF should do.
>>>>
>>>>         Tom Jones is saying " I am getting tired of the
>>>>         whack-a-mole approach ...."
>>>>
>>>>         I don't agree with you when you write: "I think it’s going
>>>>         to be overwhelmingly common that a given RS is going to
>>>>         trust exactly one AS
>>>>         that it knows about ahead of time". Such an architecture
>>>>         would have exactly the same limitations as OAuth 2.0. and
>>>>         would not be scalable.
>>>>
>>>>         Before we start, we should have a clear view of the whole
>>>>         picture rather than starting from one scenario and
>>>>         expanding it in many different directions.
>>>>         For building an architecture, a pre-requirement is to
>>>>         define ALL the trust relationships. I don't believe that we
>>>>         have an agreement at this time on what
>>>>         these trust relationships are.
>>>>
>>>>         You are also using the following wording: "methods for the
>>>>         AS and RS to communicate what the token’s good for".
>>>>         With such a paradigm, it would be impossible to protect the
>>>>         user's privacy.
>>>>
>>>>         A key question is : Will GNAP take care of the user's
>>>>         privacy or will GNAP*prevent*to take care of the user's
>>>>         privacy ?
>>>>
>>>>         About "the ability for the client to get several access
>>>>         tokens to get different resources from one request" is
>>>>         indeed a complex case.
>>>>
>>>>         No one (including ASs) is able to predict in advance which
>>>>         access tokens will be needed, since they depend upon the
>>>>         kind of operation(s)
>>>>         the client will be willing to perform. For privacy reasons,
>>>>         ASs should be kept ignorant of all the operations that a
>>>>         client is going to perform
>>>>         on one or more resource servers. I believe that every
>>>>         effort should be made to avoid the AS to be in a position
>>>>         to be able to trace the operations
>>>>         performed by its clients on various RSs.
>>>>
>>>>         To handle the complex case you envision, the full workflow
>>>>         of operations needs to be considered with a detailed focus
>>>>         on the time
>>>>         at which the user's*consent and choice*happens (/consent
>>>>         and choice/is the first privacy principle from ISO 29100).
>>>>
>>>>         First of all, an access token could be targeted to a
>>>>         service rather than to a server. This would already solve
>>>>         many cases.
>>>>
>>>>         When a RS needs to call another RS (which does not support
>>>>         the same service) then the client should be informed by the
>>>>         first RS.
>>>>         His "consent and choice" should then be obtained by the
>>>>         first RS and, when the user agrees, the client should then
>>>>         ask an access token
>>>>         to one of the ASs trusted by the second RS in order to
>>>>         perform the subsequent operation.
>>>>
>>>>         Denis
>>>>
>>>>         PS.  In an email sent on June 23 you wrote: " I think an
>>>>         on-device AS is an important use case".  I am sorry, but I
>>>>         don't understand.
>>>>                However, I do understand what "a server-based AS" is.
>>>>
>>>>
>>>>>         Denis, thanks for the great comments. I think that your
>>>>>         trust model is pretty different from what I’d laid out
>>>>>         initially, and while it’s an interesting and important
>>>>>         one, it is not what I meant by “multiple access tokens” in
>>>>>         my discussion below. I think that might be the cause of
>>>>>         some disconnect here, but that doesn’t mean it’s out of
>>>>>         reach for what the WG is after.
>>>>>
>>>>>         When I refer to multiple access tokens, and what the
>>>>>         charter calls out as multiple access tokens, is the
>>>>>         ability for the client to get several access tokens to get
>>>>>         different resources from one request. I personally see
>>>>>         this as an optimization of a specific set of use cases,
>>>>>         some of which I discussed in my original email. There are
>>>>>         others, I’m sure, but all the ones I’ve seen are around
>>>>>         the client needing to get several different kinds of
>>>>>         access through an AS.
>>>>>
>>>>>         I think it’s going to be overwhelmingly common that a
>>>>>         given RS is going to trust exactly one AS that it knows
>>>>>         about ahead of time. But for RS’s that can trust multiple
>>>>>         AS’s, then we should have a model that can accommodate
>>>>>         that as well. That’s why the charter calls out methods for
>>>>>         the AS and RS to communicate what the token’s good for. I
>>>>>         think the basis of those methods is going to start with a
>>>>>         common token model, and likely incorporate into things
>>>>>         like token formats and introspection-style token APIs.
>>>>>
>>>>>          — Justin
>>>>>
>>>>>>         On Jun 22, 2020, at 3:55 AM, Denis >>>>>         > wrote:
>>>>>>
>>>>>>         Hello Justin,
>>>>>>
>>>>>>         A few comments between the lines.
>>>>>>
>>>>>>>         One of the most important aspects to GNAP is going to be
>>>>>>>         an ability to address things that OAuth 2 can’t, or at
>>>>>>>         least can’t do without significant gymnastics. So with
>>>>>>>         that, I wanted to bring back a use case discussion that
>>>>>>>         originally came up while we were talking about the
>>>>>>>         possibility of multiple access tokens, a few months
>>>>>>>         back. I don’t know if this concept has a regular term,
>>>>>>>         so I’m going to call it “directed access tokens” until
>>>>>>>         we come up with something better — assuming we decide
>>>>>>>         this is worthwhile.
>>>>>>
>>>>>>         I don't understand what may mean "directed access tokens”
>>>>>>         but I understand what means "multiple access tokens".
>>>>>>         When speaking of "multiple access tokens", these access
>>>>>>         tokens may come from one or more ASs.
>>>>>>
>>>>>>>         In OAuth, the client’s supposed to always know where to
>>>>>>>         send its access token, and that knowledge is completely
>>>>>>>         outside the protocol. This makes a lot of sense for many
>>>>>>>         (if not most) deployments, as OAuth is really there to
>>>>>>>         enable the API access that the client already knows about.
>>>>>>>
>>>>>>>         But we’re now in a world where a client could be talking
>>>>>>>         to a generic API that could be deployed at a number of
>>>>>>>         different places, or a cloud deployment that the AS
>>>>>>>         wants to be able to dispatch the client to.
>>>>>>
>>>>>>         As soon the AS is placed (again) at the centre of the
>>>>>>         model, the AS will have the ability to act as "Big Brother".
>>>>>>         OAuth 2.0 has not taken care of privacy issues. On the
>>>>>>         contrary, GNAP should take care of them.
>>>>>>
>>>>>>>         In order to do this, the AS needs to be able to
>>>>>>>         communicate to the client not only the token information
>>>>>>>         (and any related key and presentation information), but
>>>>>>>         also a set of/directions/ about what that specific token
>>>>>>>         is good for. This needs to be information outside the
>>>>>>>         token itself, since I believe we want to keep OAuth 2’s
>>>>>>>         feature of having the token be opaque to the client.
>>>>>>>         Note: while we could map all of these to different
>>>>>>>         resource requests (in XYZ parlance) or scopes (in OAuth
>>>>>>>         2 legacy parlance) on the request side, this isn’t
>>>>>>>         enough to tell the client what to do with the token/if
>>>>>>>         it doesn’t know already/.
>>>>>>>
>>>>>>>         I know of two use cases already in the wild, where
>>>>>>>         people are addressing things using a mix of existing
>>>>>>>         standards and some proprietary extensions to address
>>>>>>>         things within their silos. I’ll try to summarize here,
>>>>>>>         but I know the folks I’ve been talking to about this are
>>>>>>>         also on the list so hopefully they can chime in with
>>>>>>>         more detail or any corrections for something I’ve missed.
>>>>>>>
>>>>>>>         (1) The client knows what resource it’s calling, but it
>>>>>>>         doesn’t know where it’s hosted. Everything is in a
>>>>>>>         single security domain controlled by the AS,
>>>>>>
>>>>>>         Speaking of "multiple access tokens" is in contradiction
>>>>>>         with single security domain "controlled" by an AS.
>>>>>>         A user may need to demonstrate some of his identity
>>>>>>         attributes granted e.g. by his bank but may also
>>>>>>         need to demonstrate one or more diplomas granted by one
>>>>>>         or more universities. The bank cannot be
>>>>>>         the "primary issuer" of a university diploma. It should
>>>>>>         not be either a "secondary issuer", because
>>>>>>         the bank does not "/need to know"/what are the diplomas
>>>>>>         of the user.
>>>>>>
>>>>>>>         but the AS needs to decide at runtime which specific
>>>>>>>         instance of the API to direct the client to. Since
>>>>>>>         things are closely tied together, the client just needs
>>>>>>>         to effectively known an identifier for the RS, and this
>>>>>>>         is currently implemented as a URI. Once the client has
>>>>>>>         that identifier, it knows how to dispatch that token to
>>>>>>>         that instance of the RS.
>>>>>>
>>>>>>         There is no good reason why the AS should be involved in
>>>>>>         that step.
>>>>>>         OAuth 2.0 is/was implicitly mandating a strong
>>>>>>         relationship between ASs and RSs which makes it non scalable.
>>>>>>         GNAP should be based on a simple trust relationship : a
>>>>>>         given RS trusts some ASs for access tokens that contains
>>>>>>         some types of attributes.
>>>>>>         An AS should not need to know in advance (or even at the
>>>>>>         time of an access token request) the RSs that are
>>>>>>         trusting it.
>>>>>>
>>>>>>         A client could first talk to a "global service provider"
>>>>>>         which has the knowledge of the different RSs affiliated
>>>>>>         to it.
>>>>>>
>>>>>>>         (2) The client knows what kind of thing it’s looking
>>>>>>>         for, but doesn’t know who to ask it from.
>>>>>>
>>>>>>         Once again, the client could first talk to a "global
>>>>>>         service provider" which has the knowledge of the
>>>>>>         different RSs affiliated to it.
>>>>>>
>>>>>>>         There’s a cross-domain trust that’s bridged by the AS,
>>>>>>>         and the AS needs to dispatch to different resources
>>>>>>>         depending on which user logged in (and possibly what the
>>>>>>>         user consented to). To make things more concrete, the
>>>>>>>         client needs to get driver’s license information, but
>>>>>>>         doesn’t know ahead of time which of the many
>>>>>>>         state/provincial bureaus to call to get that information
>>>>>>>         because it doesn’t know yet who the user is.
>>>>>>
>>>>>>         When a user has a driving license, he knows its issuer.
>>>>>>         The user can then provide some hint to the client.
>>>>>>
>>>>>>>         The AS will know who the user is once they log in and
>>>>>>>         approve things, and so it can direct the client to call
>>>>>>>         the correct RS. Since this is a relatively simple API
>>>>>>>         with a pre-negotiated cross-domain trust, the AS returns
>>>>>>>         a URL that the client presents the token at.
>>>>>>
>>>>>>          A single AS should not be aware of all the attributes a
>>>>>>         user has.
>>>>>>
>>>>>>>
>>>>>>>         As far as I know, in both of these cases, the token is
>>>>>>>         only good for that API and not others — but more on that
>>>>>>>         later.
>>>>>>>
>>>>>>>         A simple thing to do is just give back a URL with the
>>>>>>>         access token, which tells the client where to go.
>>>>>>>
>>>>>>>         {
>>>>>>>         “access_token”: {
>>>>>>>         “value”: “87yui843yfer”,
>>>>>>>         “resource_uri”: “https://example/foo"
>>>>>>>         }
>>>>>>>         }
>>>>>>>
>>>>>>>         This is good for some kinds of APIs, but it’s limiting
>>>>>>>         because not all APIs dispatch based on the URL. An AS
>>>>>>>         might want to divvy up access tokens to an API that’s
>>>>>>>         keyed on headers, or verbs, or any number of things. And
>>>>>>>         it doesn’t tell us immediately what to do about
>>>>>>>         non-exact URL matches. Can the client add query
>>>>>>>         parameters and still use the token? What about path
>>>>>>>         segments? I like that this simple approach addresses
>>>>>>>         some common deployments that we already see today (see
>>>>>>>         above), it’s not universal. Do we want or need a
>>>>>>>         universal description language for directing where
>>>>>>>         tokens go?
>>>>>>>
>>>>>>>         This also opens up a whole new set of security
>>>>>>>         questions. If the AS can now direct the client where to
>>>>>>>         use the token, could a rogue AS convince a legit client
>>>>>>>         to use a stolen token at the wrong RS? And what if the
>>>>>>>         client ignores the directions from the AS entirely?
>>>>>>>         Could this open up new avenues of attack?
>>>>>>>
>>>>>>>         This is just the start, too. Things get even more
>>>>>>>         complex if the client can ask for multiple different
>>>>>>>         kinds of resources at once. What if the AS decides that
>>>>>>>         the client needs a hyper-focused directed token for one
>>>>>>>         part of the API, but can use a general token for other
>>>>>>>         stuff? Can it signal that to the client? And if it can,
>>>>>>>         does that mean that all clients need to be prepared for
>>>>>>>         that kind of thing?
>>>>>>>
>>>>>>>         I firmly believe that whatever we build in GNAP, we need
>>>>>>>         to optimize for the overwhelmingly common use case of a
>>>>>>>         client getting a single access token to call APIs that
>>>>>>>         it already knows about. Anything we add on top of that
>>>>>>>         really can’t get in the way of this, because if it does,
>>>>>>>         there’s very small chance that people will try to use
>>>>>>>         this for everyday things. Keep the simple things simple,
>>>>>>>         and the complex things possible, after all.
>>>>>>>
>>>>>>>         I’m really looking forward to hearing what the community
>>>>>>>         thinks about these use cases, and hopefully the people
>>>>>>>         I’ve chatted with offline about this can join the
>>>>>>>         conversation and provide more light than I was able to.
>>>>>>
>>>>>>         The two use cases which are considered above are:
>>>>>>
>>>>>>             (1) The client knows what resource it’s calling, but
>>>>>>             it doesn’t know where it’s hosted.
>>>>>>             (2) The client knows what kind of thing it’s looking
>>>>>>             for, but doesn’t know who to ask it from.
>>>>>>
>>>>>>         That does not mean in any way that these two use cases
>>>>>>         should be solved by placing the AS at the centre of the
>>>>>>         solution.
>>>>>>
>>>>>>         Denis
>>>>>>
>>>>>>>
>>>>>>>          — Justin
>>>>>>>
>>>>>>
>>>>>>         --
>>>>>>         Txauth mailing list
>>>>>>         Txauth@ietf.org 
>>>>>>         https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>>
>>>>         --
>>>>         Txauth mailing list
>>>>         Txauth@ietf.org 
>>>>         https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>
>>>>     This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
>>>
>>>     --
>>>     Txauth mailing list
>>>     Txauth@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
>
>


--------------96E7F1D5B0FADA99131765CE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Justin,

    

      
      I think there are two interesting layers here: 
      


      

      
 - Information that the client needs to know. This
        is what started the thread, the whole “how and where am I
        allowed to use this token” question. 

        This is stuff that would be put alongside the token in the
        response from the AS, not inside the token.

    

    
If the "how and where am I allowed to use this token” is sent
      alongside the token in the response from the AS, then you are
      allowing the AS 

      to know which RS(s) will be able to consume the access token. This
      should be prevented for privacy reasons (i.e. the AS would be able
      to act as Big Brother).

    


      
 - Information that the RS needs to know. This is I
        think where the attenuation, proofing, and the actual rights
        associated with the token would go. 

        This is stuff that would either be in the token itself or in a
         return from an introspection style call.

    

    
With an introspection style call you are allowing the AS to know
      to which RS(s) the access token has arrived. This should be
      prevented for privacy reasons 

      (i.e. the AS would be able to act as Big Brother). 

    

    
Denis

    


      
Both of these fit into the “consistent token model”
        part of GNAP, but different aspects need to be communicated in
        different ways. 

      


      

      
 — Justin

        


          

            
On Jul 7, 2020, at 8:01 PM, Tobias Looker <tobias.looker@mattr.global>
              wrote:

            

            

              
              
I've also been thinking about the
                parallels between ZCAP's and OAuth2.0 access tokens. To
                me a ZCAP is a less opaque, semantically richer
                capability format, whereas an access_token is
                traditionally much simpler. The key here though is I
                still see an access_token as a form of capability. It
                appears in general one of the trade offs we will be
                faced with is either:
                


                

                
1. Keeping the capability received from a
                  GNAP flow (e.g an access_token) opaque to the client
                  and externalizing any greater information about how to
                  use the capability (such as in your proposal in the
                  first email of this thread).

                
2. Internalizing information about the
                  capabilities utility and any greater context about it
                  which means the capability is no longer opaque.

                

                  


                  

                  
With that aside, the notable features in
                    general I would like GNAP to consider from ZCAP's,
                    are the following.
                    


                    

                    
- Delegatable capabilities (bonus if
                      this mechanism includes the ability to attenuate
                      during delegation) - Consider the example where a
                      client or RP (RP1) receives some form of
                      access_token (capability) from an AS and would
                      like to delegate this to another RP (RP2) so they
                      can access the same resources. If including
                      attenuation this would mean that during this
                      delegation (RP1->RP2), RP1 could narrow the
                      scope of the original access it received so that
                      RP2 only gets a subset of the original scope.

                    
- Bound capabilities - Similar in some
                      ways to dPop, essentially establishing the ability
                      to bind an access_token (capability) to the party
                      that should be able to use it (invoker). I see
                      this as a must have in order to be able to do
                      attenuated delegation as described above.
                      

                        

                          

                            


                            

                            
Thanks,

                              

                                
                                  

                                    Mattr website
                                     
                                    
                                      

                                        
                                          

                                            Tobias Looker

                                            		
                                          

                                          

                                            Mattr
                                          

                                          

                                            +64 (0) 27 378
                                              0461

                                              tobias.looker@mattr.global		
                                          

                                          

                                            
                                              

                                                
                                                  

                                                    Mattr website
                                                    Mattr on
                                                          LinkedIn
                                                    Mattr on
                                                          Twitter
                                                    Mattr on
                                                          Github
                                                  

                                                
                                              

                                            		
                                          

                                        
                                      

                                    		
                                  

                                
                              

                              

                              This communication, including
                                any attachments, is confidential. If you
                                are not the intended recipient, you
                                should not read it - please contact me
                                immediately, destroy it, and do not copy
                                or use any part of this communication or
                                disclose anything about it. Thank you.
                                Please note that this communication does
                                not designate an information system for
                                the purposes of the Electronic
                                Transactions Act 2002.

                            

                          

                        

                        

                      

                    

                  

                

              

              

              

                
On Wed, Jul 8, 2020 at
                  8:39 AM Justin Richer <jricher@mit.edu>
                  wrote:

                

                

                  
I’ve
                    been thinking more about these use cases, and it
                    might help us to think of GNAP’s access tokens as
                    capabilities in the computer security sense — but
                    more specifically, capabilities that are delivered
                    with their own context for use. In that way, an
                    otherwise naive client can be handed an access token
                    and simply know exactly what to do with it. This
                    context would be delivered alongside the token, so
                    the token material itself remains opaque to the
                    client.
                    


                    

                    
I wanted to bring up a W3C spec for a
                      capabilities model based on linked data:
                      


                      

                      
                      


                      

                      
Building a fully featured
                        capabilities context is difficult, at the very
                        least. And unfortunately, I don’t think this
                        spec actually gives us any viable solutions to
                        work with. In particular the “actions” section
                        is effectively blank, offloading the work to an
                        external JSONLD process (side note, this is one
                        of the problems I have with specs based on
                        JSONLD, they externalize the important parts
                        into local contexts and break interoperability —
                        but I digress). But at least it’s another way of
                        looking at the problem space that might be
                        outside the familiar zone of many of the OAuth
                        world.

                      


                      

                      
 — Justin

                        


                          

                            
On Jun 26, 2020, at 9:23 AM,
                              Justin Richer <jricher@mit.edu>
                              wrote:

                            

                            
On Jun 25, 2020, at 9:07 PM,
                                Tobias Looker <tobias.looker@mattr.global> wrote:

                              

                                


                                  

                                    
I find this
                                      feature interesting and think it
                                      could be an important pattern
                                      going forward to enable an AS to
                                      be able to describe the utility of
                                      a token to the client, however as
                                      already pointed out in the thread
                                      I think there is some potential
                                      hidden complexity that would need
                                      to be ironed out such that it does
                                      not make the simple things
                                      complicated.
                                      


                                      

                                      
Justin, do you see
                                        this feature as something the
                                        client has to explicitly
                                        request, i.e "please give me
                                        access and instructions on how
                                        to use my access" or rather that
                                        the AS would just return this
                                        information in conjunction with
                                        the access token if it had it
                                        available?

                                      


                                      

                                    

                                  

                                

                                


                                

                                
This is something that I’d
                                  brought up as a possibility on the
                                  previous thread — something like a
                                  flag the client would set. This would
                                  be especially important if the AS
                                  wants to return multiple access tokens
                                  but the client requested 1, or the
                                  client requested N and the AS wants to
                                  return M in response. Basically any
                                  time there’s a mismatch, that’s extra
                                  complexity on the client that I really
                                  don’t think we want to be universal. A
                                  flag to turn that kind of direction
                                  and splitting on would be a potential
                                  start. But there are potential snags
                                  here too, and it comes down to how you
                                  manage the defaults...

                                

                                

                                  

                                    

                                      
> This is just
                                        the start, too. Things get even
                                        more complex if the client can
                                        ask for multiple different kinds
                                        of resources at once. What if
                                        the AS decides that the client
                                        needs a hyper-focused directed
                                        token for one part of the API,
                                        but can use a general token for
                                        other stuff? Can it signal that
                                        to the client? And if it can,
                                        does that mean that all clients
                                        need to be prepared for that
                                        kind of thing?

                                      


                                      

                                      
Would a potential
                                        default be that if a client did
                                        for any reason not support
                                        processing the additional
                                        information returned with the
                                        access_token, just to ignore it?
                                        I think in the spirit of keeping
                                        the simple things simple, this
                                        potentially makes sense?

                                    

                                  

                                

                                


                                

                                
That’s the real trick, if
                                  you ask me. It has to be :safe: for a
                                  client to ignore this information.
                                  Which means the AS can’t rely on the
                                  client “doing the right thing” with
                                  the information in the “token
                                  directions” portion of the response.
                                  Even setting aside the advanced and
                                  related “split tokens” idea above, we
                                  need to make sure that an AS/RS setup
                                  is built such that if the AS tells a
                                  client “only do X with your token” and
                                  the client does “Y”, then there are
                                  other protections and practices in
                                  place to prevent things from going
                                  haywire if the client does “Y” either
                                  by accident or through ignorance. 

                                


                                

                                
If OAuth 2 has taught us
                                  anything, it’s that client
                                  applications are going to be the
                                  laziest participants in the security
                                  model. And that makes sense, really —
                                  security isn’t what the client apps
                                  are trying to do, they’re trying to
                                  use the RS to do something. So we need
                                  to make sure that whatever system we
                                  design will fail on the safe side as
                                  much as possible, and keep things
                                  simple for the client.

                                

                                

                                  

                                    

                                      


                                      

                                      
> here are some
                                        worked out samples of this:

                                      
                                      
                                      

                                        

                                          

                                            
Peace ..tom

                                            


                                            

                                            
As one of the
                                              authors of those mentioned
                                              drafts, I am interested in
                                              discussing that, but
                                              perhaps on a seperate
                                              thread? As at least the
                                              bound assertion spec
                                              is primarily concerned
                                              with binding mechanisms
                                              for the artifacts produced
                                              from an authorization flow
                                              (specifically identity
                                              claims), whereas I think
                                              directed access tokens is
                                              just more generally
                                              talking about whether GNAP
                                              should support an AS
                                              conveying how to use an
                                              access_token it produces
                                              during a flow with a
                                              client.

                                          

                                        

                                      

                                      


                                      

                                    

                                  

                                

                                


                                

                                
I think that these are
                                  separate issues as well.

                                


                                

                                
 — Justin

                                

                                

                                  

                                    

                                      

                                        

                                          

                                            
Thanks,

                                              

                                                
                                                  

                                                    Mattr
                                                          website
                                                     
                                                    
                                                      

                                                        
                                                          

                                                          Tobias Looker

                                                          		
                                                          

                                                          

                                                          Mattr
                                                          

                                                          

                                                          +64
                                                          (0) 27 378
                                                          0461

                                                          tobias.looker@mattr.global		
                                                          

                                                          

                                                          
                                                          

                                                          
                                                          

                                                          Mattr
                                                          website
                                                          Mattr on
                                                          LinkedIn
                                                          Mattr on
                                                          Twitter
                                                          Mattr on
                                                          Github
                                                          

                                                          
                                                          

                                                          		
                                                          

                                                        
                                                      

                                                    		
                                                  

                                                
                                              

                                              

                                              This
                                                communication, including
                                                any attachments, is
                                                confidential. If you are
                                                not the intended
                                                recipient, you should
                                                not read it - please
                                                contact me immediately,
                                                destroy it, and do not
                                                copy or use any part of
                                                this communication or
                                                disclose anything about
                                                it. Thank you. Please
                                                note that this
                                                communication does not
                                                designate an information
                                                system for the purposes
                                                of the Electronic
                                                Transactions Act 2002.

                                            

                                          

                                        

                                        

                                      

                                    

                                    

                                    

                                      
On
                                        Wed, Jun 24, 2020 at 10:14 PM
                                        Denis <denis.ietf@free.fr>
                                        wrote:

                                      

                                      

                                        

                                          
Justin, I fear
                                            we are still far away from
                                            an agreement about what this
                                            BoF should do.

                                          


                                          

                                          
Tom Jones is
                                            saying " I am getting tired
                                            of the whack-a-mole approach
                                            ...."

                                          


                                          

                                          I don't agree with you when
                                          you write: "I think it’s going
                                          to be overwhelmingly common
                                          that a given RS is going to
                                          trust exactly one AS 

                                          
that it knows
                                            about ahead of time". Such
                                            an architecture would have
                                            exactly the same limitations
                                            as OAuth 2.0. and would not
                                            be scalable.

                                          


                                          

                                          

                                            
Before we
                                              start, we should have a
                                              clear view of the whole
                                              picture rather than
                                              starting from one scenario
                                              and expanding it in many
                                              different directions.

                                            
For building
                                              an architecture, a
                                              pre-requirement is to
                                              define ALL the trust
                                              relationships. I don't
                                              believe that we have an
                                              agreement at this time on
                                              what 

                                              these trust relationships
                                              are. 

                                          

                                          


                                          

                                          
You are also
                                            using the following wording:
                                            "methods for the AS and RS
                                            to communicate what the
                                            token’s good for". 

                                            With such a paradigm, it
                                            would be impossible to
                                            protect the user's privacy. 

                                          

                                          


                                          

                                          
A key question
                                            is : Will GNAP take care of
                                            the user's privacy or will
                                            GNAP prevent to
                                            take care of the user's
                                            privacy ?

                                          


                                          

                                          
About "the
                                            ability for the client to
                                            get several access tokens to
                                            get different resources from
                                            one request" is indeed a
                                            complex case.

                                          


                                          

                                          
No one
                                            (including ASs) is able to
                                            predict in advance which
                                            access tokens will be
                                            needed, since they depend
                                            upon the kind of
                                            operation(s) 

                                            the client will be willing
                                            to perform. For privacy
                                            reasons, ASs should be kept
                                            ignorant of all the
                                            operations that a client is
                                            going to perform 

                                            on one or more resource
                                            servers. I believe that
                                            every effort should be made
                                            to avoid the AS to be in a
                                            position to be able to trace
                                            the operations 

                                            performed by its clients on
                                            various RSs.

                                          


                                          

                                          
To handle the
                                            complex case you envision,
                                            the full workflow of
                                            operations needs to be
                                            considered with a detailed
                                            focus on the time 

                                            at which the user's consent and
                                              choice happens
                                            (consent and
                                              choice is
                                            the first privacy principle
                                            from ISO 29100).

                                          


                                          

                                          
First of all, an
                                            access token could be
                                            targeted to a service rather
                                            than to a server. This would
                                            already solve many cases.

                                          


                                          

                                          
When a RS needs
                                            to call another RS (which
                                            does not support the same
                                            service) then the client
                                            should be informed by the
                                            first RS.

                                          
His "consent and
                                            choice" should then be
                                            obtained by the first RS
                                            and, when the user agrees,
                                            the client should then ask
                                            an access token 

                                            to one of the ASs trusted by
                                            the second RS in order to
                                            perform the subsequent
                                            operation.  

                                          

                                          


                                          

                                          
Denis

                                          


                                          

                                          
PS.  In an email
                                            sent on June 23 you wrote: "
                                            I think an on-device AS is
                                            an important use case".  I
                                            am sorry, but I don't
                                            understand.

                                                   However, I do
                                            understand what "a
                                            server-based AS" is.

                                          

                                          


                                          

                                          


                                          

                                          
Denis, thanks for
                                            the great comments. I think
                                            that your trust model is
                                            pretty different from what
                                            I’d laid out initially, and
                                            while it’s an interesting
                                            and important one, it is not
                                            what I meant by “multiple
                                            access tokens” in my
                                            discussion below. I think
                                            that might be the cause of
                                            some disconnect here, but
                                            that doesn’t mean it’s out
                                            of reach for what the WG is
                                            after.
                                            


                                            

                                            
When I refer
                                              to multiple access tokens,
                                              and what the charter calls
                                              out as multiple access
                                              tokens, is the ability for
                                              the client to get several
                                              access tokens to get
                                              different resources from
                                              one request. I personally
                                              see this as an
                                              optimization of a specific
                                              set of use cases, some of
                                              which I discussed in my
                                              original email. There are
                                              others, I’m sure, but all
                                              the ones I’ve seen are
                                              around the client needing
                                              to get several different
                                              kinds of access through an
                                              AS. 

                                              


                                              

                                              
I think it’s
                                                going to be
                                                overwhelmingly common
                                                that a given RS is going
                                                to trust exactly one AS
                                                that it knows about
                                                ahead of time. But for
                                                RS’s that can trust
                                                multiple AS’s, then we
                                                should have a model that
                                                can accommodate that as
                                                well. That’s why the
                                                charter calls out
                                                methods for the AS and
                                                RS to communicate what
                                                the token’s good for. I
                                                think the basis of those
                                                methods is going to
                                                start with a common
                                                token model, and likely
                                                incorporate into things
                                                like token formats and
                                                introspection-style
                                                token APIs. 

                                              


                                              

                                              
 — Justin

                                                


                                                  

                                                    
On Jun
                                                      22, 2020, at 3:55
                                                      AM, Denis <denis.ietf@free.fr>
                                                      wrote:

                                                    

                                                    

                                                      
Hello
                                                        Justin,

                                                      


                                                      

                                                      
A few
                                                        comments between
                                                        the lines.

                                                      


                                                      

                                                      
One of
                                                        the most
                                                        important
                                                        aspects to GNAP
                                                        is going to be
                                                        an ability to
                                                        address things
                                                        that OAuth 2
                                                        can’t, or at
                                                        least can’t do
                                                        without
                                                        significant
                                                        gymnastics. So
                                                        with that, I
                                                        wanted to bring
                                                        back a use case
                                                        discussion that
                                                        originally came
                                                        up while we were
                                                        talking about
                                                        the possibility
                                                        of multiple
                                                        access tokens, a
                                                        few months back.
                                                        I don’t know if
                                                        this concept has
                                                        a regular term,
                                                        so I’m going to
                                                        call it
                                                        “directed access
                                                        tokens” until we
                                                        come up with
                                                        something better
                                                        — assuming we
                                                        decide this is
                                                        worthwhile. 

                                                      

                                                      
I don't
                                                        understand what
                                                        may mean
                                                        "directed access
                                                        tokens” but I
                                                        understand what
                                                        means "multiple
                                                        access tokens". 

                                                        When speaking of
                                                        "multiple access
                                                        tokens", these
                                                        access tokens
                                                        may come from
                                                        one or more ASs.

                                                      

                                                      

                                                        
In
                                                          OAuth, the
                                                          client’s
                                                          supposed to
                                                          always know
                                                          where to send
                                                          its access
                                                          token, and
                                                          that knowledge
                                                          is completely
                                                          outside the
                                                          protocol. This
                                                          makes a lot of
                                                          sense for many
                                                          (if not most)
                                                          deployments,
                                                          as OAuth is
                                                          really there
                                                          to enable the
                                                          API access
                                                          that the
                                                          client already
                                                          knows about.

                                                        


                                                        

                                                        
But
                                                          we’re now in a
                                                          world where a
                                                          client could
                                                          be talking to
                                                          a generic API
                                                          that could be
                                                          deployed at a
                                                          number of
                                                          different
                                                          places, or a
                                                          cloud
                                                          deployment
                                                          that the AS
                                                          wants to be
                                                          able to
                                                          dispatch the
                                                          client to. 

                                                      

                                                      
As soon
                                                        the AS is placed
                                                        (again) at the
                                                        centre of the
                                                        model, the AS
                                                        will have the
                                                        ability to act
                                                        as "Big
                                                        Brother".

                                                        OAuth 2.0 has
                                                        not taken care
                                                        of privacy
                                                        issues. On the
                                                        contrary, GNAP
                                                        should take care
                                                        of them.

                                                      

                                                        
In
                                                          order to do
                                                          this, the AS
                                                          needs to be
                                                          able to
                                                          communicate to
                                                          the client not
                                                          only the token
                                                          information
                                                          (and any
                                                          related key
                                                          and
                                                          presentation
                                                          information),
                                                          but also a set
                                                          of directions about
                                                          what that
                                                          specific token
                                                          is good for.
                                                          This needs to
                                                          be information
                                                          outside the
                                                          token itself,
                                                          since
                                                          I believe we
                                                          want to keep
                                                          OAuth 2’s
                                                          feature of
                                                          having the
                                                          token be
                                                          opaque to the
                                                          client. Note:
                                                          while we could
                                                          map all of
                                                          these to
                                                          different
                                                          resource
                                                          requests (in
                                                          XYZ parlance)
                                                          or scopes (in
                                                          OAuth 2 legacy
                                                          parlance) on
                                                          the request
                                                          side, this
                                                          isn’t enough
                                                          to tell the
                                                          client what to
                                                          do with the
                                                          token if it
                                                          doesn’t know
                                                          already. 

                                                        


                                                        

                                                        
I
                                                          know of two
                                                          use cases
                                                          already in the
                                                          wild, where
                                                          people are
                                                          addressing
                                                          things using a
                                                          mix of
                                                          existing
                                                          standards and
                                                          some
                                                          proprietary
                                                          extensions to
                                                          address things
                                                          within their
                                                          silos. I’ll
                                                          try to
                                                          summarize
                                                          here, but I
                                                          know the folks
                                                          I’ve been
                                                          talking to
                                                          about this are
                                                          also on the
                                                          list so
                                                          hopefully they
                                                          can chime in
                                                          with more
                                                          detail or any
                                                          corrections
                                                          for something
                                                          I’ve missed. 

                                                        


                                                        

                                                        
(1)
                                                          The client
                                                          knows what
                                                          resource it’s
                                                          calling, but
                                                          it doesn’t
                                                          know where
                                                          it’s hosted.
                                                          Everything is
                                                          in a single
                                                          security
                                                          domain
                                                          controlled by
                                                          the AS, 

                                                      

                                                      
Speaking
                                                        of "multiple
                                                        access tokens"
                                                        is in
                                                        contradiction
                                                        with single
                                                        security domain
                                                        "controlled" by
                                                        an AS. 

                                                        A user may need
                                                        to demonstrate
                                                        some of his
                                                        identity
                                                        attributes
                                                        granted e.g. by
                                                        his bank but may
                                                        also 

                                                        need to
                                                        demonstrate one
                                                        or more diplomas
                                                        granted by one
                                                        or more
                                                        universities.
                                                        The bank cannot
                                                        be 

                                                        the "primary
                                                        issuer" of a
                                                        university
                                                        diploma. It
                                                        should not be
                                                        either a
                                                        "secondary
                                                        issuer", because 

                                                        the bank does
                                                        not "need
                                                          to know" what
                                                        are the diplomas
                                                        of the user.

                                                      

                                                      

                                                        
but
                                                          the AS needs
                                                          to decide at
                                                          runtime which
                                                          specific
                                                          instance of
                                                          the API to
                                                          direct the
                                                          client to.
                                                          Since things
                                                          are closely
                                                          tied together,
                                                          the client
                                                          just needs to
                                                          effectively
                                                          known an
                                                          identifier for
                                                          the RS, and
                                                          this is
                                                          currently
                                                          implemented as
                                                          a URI. Once
                                                          the client has
                                                          that
                                                          identifier, it
                                                          knows how to
                                                          dispatch that
                                                          token to that
                                                          instance of
                                                          the RS.

                                                      

                                                      
There
                                                        is no good
                                                        reason why the
                                                        AS should be
                                                        involved in that
                                                        step. 

                                                        OAuth 2.0 is/was
                                                        implicitly
                                                        mandating a
                                                        strong
                                                        relationship
                                                        between ASs and
                                                        RSs which makes
                                                        it non scalable.

                                                        GNAP should be
                                                        based on a
                                                        simple trust
                                                        relationship : a
                                                        given RS trusts
                                                        some ASs for
                                                        access tokens
                                                        that contains
                                                        some types of
                                                        attributes.

                                                        An AS should not
                                                        need to know in
                                                        advance (or even
                                                        at the time of
                                                        an access token
                                                        request) the RSs
                                                        that are
                                                        trusting it.

                                                      

                                                      
A
                                                        client could
                                                        first talk to a
                                                        "global service
                                                        provider" which
                                                        has the
                                                        knowledge of the
                                                        different RSs
                                                        affiliated to
                                                        it. 

                                                      

                                                      

                                                        
(2)
                                                          The client
                                                          knows what
                                                          kind of thing
                                                          it’s looking
                                                          for, but
                                                          doesn’t know
                                                          who to ask it
                                                          from. 

                                                      

                                                      
Once
                                                        again, the
                                                        client could
                                                        first talk to a
                                                        "global service
                                                        provider" which
                                                        has the
                                                        knowledge of the
                                                        different RSs
                                                        affiliated to
                                                        it. 

                                                      

                                                        
There’s
                                                          a cross-domain
                                                          trust that’s
                                                          bridged by the
                                                          AS, and the AS
                                                          needs to
                                                          dispatch to
                                                          different
                                                          resources
                                                          depending on
                                                          which user
                                                          logged in (and
                                                          possibly what
                                                          the user
                                                          consented to).
                                                          To make things
                                                          more concrete,
                                                          the client
                                                          needs to get
                                                          driver’s
                                                          license
                                                          information,
                                                          but doesn’t
                                                          know ahead of
                                                          time which of
                                                          the many
                                                          state/provincial
                                                          bureaus to
                                                          call to get
                                                          that
                                                          information
                                                          because it
                                                          doesn’t know
                                                          yet who the
                                                          user is. 

                                                      

                                                      
When a
                                                        user has a
                                                        driving license,
                                                        he knows its
                                                        issuer. The user
                                                        can then provide
                                                        some hint to the
                                                        client.

                                                      

                                                        
The
                                                          AS will know
                                                          who the user
                                                          is once they
                                                          log in and
                                                          approve
                                                          things, and so
                                                          it can direct
                                                          the client to
                                                          call the
                                                          correct RS.
                                                          Since this is
                                                          a relatively
                                                          simple API
                                                          with a
                                                          pre-negotiated
                                                          cross-domain
                                                          trust, the AS
                                                          returns a URL
                                                          that the
                                                          client
                                                          presents the
                                                          token at. 

                                                        

                                                      

                                                      
 A
                                                        single AS should
                                                        not be aware of
                                                        all the
                                                        attributes a
                                                        user has. 

                                                      

                                                      

                                                        


                                                        

                                                        
As
                                                          far as I know,
                                                          in both of
                                                          these cases,
                                                          the token is
                                                          only good for
                                                          that API and
                                                          not others —
                                                          but more on
                                                          that later.

                                                        


                                                        

                                                        
A
                                                          simple thing
                                                          to do is just
                                                          give back a
                                                          URL with the
                                                          access token,
                                                          which tells
                                                          the client
                                                          where to go. 

                                                        


                                                        

                                                        
	{

                                                        
		“access_token”:
                                                          {

                                                        
			“value”:
“87yui843yfer”,

                                                        
			“resource_uri”:
                                                          “https://example/foo"

                                                        
		}

                                                        
	}

                                                        


                                                        

                                                        
This
                                                          is good for
                                                          some kinds of
                                                          APIs, but it’s
                                                          limiting
                                                          because not
                                                          all APIs
                                                          dispatch based
                                                          on the URL. An
                                                          AS might want
                                                          to divvy up
                                                          access tokens
                                                          to an API
                                                          that’s keyed
                                                          on headers, or
                                                          verbs, or any
                                                          number of
                                                          things. And it
                                                          doesn’t tell
                                                          us immediately
                                                          what to do
                                                          about
                                                          non-exact URL
                                                          matches. Can
                                                          the client add
                                                          query
                                                          parameters and
                                                          still use the
                                                          token? What
                                                          about path
                                                          segments? I
                                                          like that this
                                                          simple
                                                          approach
                                                          addresses some
                                                          common
                                                          deployments
                                                          that we
                                                          already see
                                                          today (see
                                                          above), it’s
                                                          not universal.
                                                          Do we want or
                                                          need a
                                                          universal
                                                          description
                                                          language for
                                                          directing
                                                          where tokens
                                                          go?

                                                        


                                                        

                                                        
This
                                                          also opens up
                                                          a whole new
                                                          set of
                                                          security
                                                          questions. If
                                                          the AS can now
                                                          direct the
                                                          client where
                                                          to use the
                                                          token, could a
                                                          rogue AS
                                                          convince a
                                                          legit client
                                                          to use a
                                                          stolen token
                                                          at the wrong
                                                          RS? And what
                                                          if the client
                                                          ignores the
                                                          directions
                                                          from the AS
                                                          entirely?
                                                          Could this
                                                          open up new
                                                          avenues of
                                                          attack?

                                                        


                                                        

                                                        
This
                                                          is just the
                                                          start, too.
                                                          Things get
                                                          even more
                                                          complex if the
                                                          client can ask
                                                          for multiple
                                                          different
                                                          kinds of
                                                          resources at
                                                          once. What if
                                                          the AS decides
                                                          that the
                                                          client needs a
                                                          hyper-focused
                                                          directed token
                                                          for one part
                                                          of the API,
                                                          but can use a
                                                          general token
                                                          for other
                                                          stuff? Can it
                                                          signal that to
                                                          the client?
                                                          And if it can,
                                                          does that mean
                                                          that all
                                                          clients need
                                                          to be prepared
                                                          for that kind
                                                          of thing?

                                                        


                                                        

                                                        
I
                                                          firmly believe
                                                          that whatever
                                                          we build in
                                                          GNAP, we need
                                                          to optimize
                                                          for the
                                                          overwhelmingly
                                                          common use
                                                          case of a
                                                          client getting
                                                          a single
                                                          access token
                                                          to call APIs
                                                          that it
                                                          already knows
                                                          about.
                                                          Anything we
                                                          add on top of
                                                          that really
                                                          can’t get in
                                                          the way of
                                                          this, because
                                                          if it does,
                                                          there’s very
                                                          small chance
                                                          that people
                                                          will try to
                                                          use this for
                                                          everyday
                                                          things. Keep
                                                          the simple
                                                          things simple,
                                                          and the
                                                          complex things
                                                          possible,
                                                          after all.

                                                        


                                                        

                                                        
I’m
                                                          really looking
                                                          forward to
                                                          hearing what
                                                          the community
                                                          thinks about
                                                          these use
                                                          cases, and
                                                          hopefully the
                                                          people I’ve
                                                          chatted with
                                                          offline about
                                                          this can join
                                                          the
                                                          conversation
                                                          and provide
                                                          more light
                                                          than I was
                                                          able to.

                                                      

                                                      
The two
                                                        use cases which
                                                        are considered
                                                        above are:

                                                      

                                                        
(1)
                                                          The client
                                                          knows what
                                                          resource it’s
                                                          calling, but
                                                          it doesn’t
                                                          know where
                                                          it’s hosted.

                                                          (2) The client
                                                          knows what
                                                          kind of thing
                                                          it’s looking
                                                          for, but
                                                          doesn’t know
                                                          who to ask it
                                                          from. 

                                                        

                                                      

                                                      
That
                                                        does not mean in
                                                        any way that
                                                        these two use
                                                        cases should be
                                                        solved by
                                                        placing the AS
                                                        at the centre of
                                                        the solution.

                                                      
Denis

                                                      

                                                        


                                                        

                                                        
 —
                                                          Justin

                                                        

                                                        

                                                      

                                                      


                                                      

                                                      -- 

                                                      Txauth
                                                        mailing list

                                                      Txauth@ietf.org

                                                      https://www.ietf.org/mailman/listinfo/txauth

                                                  

                                                

                                                

                                              

                                            

                                          

                                          


                                          

                                        

                                        -- 

                                        Txauth mailing list

                                        Txauth@ietf.org

                                        https://www.ietf.org/mailman/listinfo/txauth

                                      

                                    

                                    

                                    
This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

                                  

                                

                              

                              

                              -- 

                              Txauth mailing list

                              Txauth@ietf.org

                              https://www.ietf.org/mailman/listinfo/txauth

                          

                        

                        

                      

                    

                  

                

              

              

              
This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

            

          

        

        

      

      

      

    

    


    

  


--------------96E7F1D5B0FADA99131765CE--


From nobody Wed Jul  8 10: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 1BAAC3A0858 for ; Wed,  8 Jul 2020 10:39:33 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=JN1ZVbqw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WNEuEmEx
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 RE33DljJhGOb for ; Wed,  8 Jul 2020 10:39:30 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B423D3A07ED for ; Wed,  8 Jul 2020 10:39:23 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id EB0C45C00F9; Wed,  8 Jul 2020 13:39:22 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 08 Jul 2020 13:39:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=ygRKacH3QnRyUuxUuA5yKYcFpUrmynS AJfXIKaGm3Qk=; b=JN1ZVbqwQ4nl1MDbsO9ZreeC4c4kvVkDWOzlLX7GJ4wRp9Y pYulTf8DMaIdyFkxxFaD/kWQ/G02QqelTN865eSwlMj3DO727sARXs/vXsGpdvyF YWZYDgH4ox0ZBBX7MyHlaoNafPx60MQhQueGJJeD55bfm1EQk9go+e9rAnOZcFwS S9AM6xH/t3WZPaRyWkUyiJTOcthw67VYlv3NbqywmvvYoxQr1jv3FLyBNsa7VTY8 uF++eHGcecuIsTzSVL7zdSD7UVnRCKlQZwHq9jyiiPk8MK57ynq4zjfE1CtD4Vgl xaCDFinLgnNZDvXNrsxzuQzHl10CxVJkgHGL16w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=ygRKac H3QnRyUuxUuA5yKYcFpUrmynSAJfXIKaGm3Qk=; b=WNEuEmExOfrw63BW/l+ki0 U0ByAy+3mS+TEvVYD7tGTIkNpKF+Juf4zW7X1gcf4zORpr6JqeEVLZti4wu2jL6S 5/fZ7onUWoG7Ex7YpSSfEG3jKifllclmMnAOLjD4McKZgbFG4Bmk6eeqAOk0e6ii noXpZzUFrRqgmQPtRUuPVFpX/S5bB+PllajdmXoOiZjs+nPZvSaQF+h7zPSbJBTU VqqDxcIwYXG5o8VjSyUrS39wlLuxCdsx2bNt3m3lyhARGmYWKSKuWxygx5Icr051 L4BkuAp7PqGZw9PvjFXF6mkXtPONmeABqbe7sYakKWZi56XB4dqLbEe01xriHHKQ ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdghrgih nhgvucevhhgrnhhgfdcuoeifhigtsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtth gvrhhnpedtheeviedvveeltefhtefhgfetudfghfeggeekgffhkeduveeluddtgedtfefg teenucffohhmrghinhepihgvvggvrdhorhhgpdhgihhthhhusgdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeifhigtsehfrghsthhm rghilhdrfhhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BE0E1E00B3; Wed,  8 Jul 2020 13:39:22 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-601-g4bf46fa-fm-20200708.001-g4bf46fa8
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>  
Date: Wed, 08 Jul 2020 13:39:12 -0400
From: "Wayne Chang" 
To: "Tom Jones" 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary=87840f5812524e53894bd601bd8aae88
Archived-At: 
Subject: Re: [Txauth] TLS Dependency
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, 08 Jul 2020 17:39:39 -0000

--87840f5812524e53894bd601bd8aae88
Content-Type: text/plain

Shifting to a new thread based on the interesting point Tom made about removing TLS requirements. Justin, I did see that you were careful to specify "TLS or equivalent" in your drafts, and Dick commented "[Editor: too aggressive to mandate HTTP/2 and TLS 1.3?]" in his. Maybe this is a good opportunity to explore the "or equivalent" part.

Some IoT environments do not and will not support HTTP + SSL/TLS, but could benefit from this grant framework. Instead, they may use application protocols like MQTT and more recently in conjunction with single-packet authorization (SPA). https://ieeexplore.ieee.org/document/8930455

>From the DID ecosystem, I can imagine some future interoperability between DIDComm and GNAP. It is not clear that TLS will be used for all DID-to-DID communications, which aim to be transport agnostic. See discussion here: https://github.com/decentralized-identity/didcomm-messaging/issues/38

What other potential non-TLS use cases are worth mentioning?

On Wed, Jul 8, 2020, at 1:10 PM, Tom Jones wrote:
> a somewhat milder response might be.
> It seems that justin's proposal is not, in fact, a grant negotiation, but a generalized token format.
> So - what could that mean here?
> I have a problem with the whack-a-mole approach of OAuth, with RAR JAR ad infinitum.
> That is a never-ending stream of hacks.
> if Justin's proposal is to be considered seriously, it must be at some higher level that GNAP..
> I suggest that the current approach of xauth txauth authxyz is not really headed to a convergence.
> Perhaps we need to start with an abstract set of goals and data flows. One that includes the user/RO.
> I do have one for healthcare - but i am short of time right now to generalize it.
> One item I would like to see resolved early is to remove the dependency on transport layer security. One that includes the handling of key roll-over.
> In Kantara we focused first on the legal responsibilities of the token maker. That problem seems to have consumed FAPI, altho they have multiple names for it.
> In the real world we have legal entities (natural and unnatural) and legal names (brands) as well as pseudonyms. OAuth just had endpoints with SSL keys and certs. How about we start there?
> Peace ..tom

--87840f5812524e53894bd601bd8aae88
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


Shifting to a n=
ew thread based on the interesting point Tom made about removing TLS req=
uirements. Justin, I did see that you were careful to specify "TLS or eq=
uivalent" in your drafts, and Dick commented "[Editor: too aggressive to=
 mandate HTTP/2 and TLS 1.3?]" in his. Maybe this is a good opportunity =
to explore the "or equivalent" part.

Some IoT e=
nvironments do not and will not support HTTP + SSL/TLS, but could benefi=
t from this grant framework. Instead, they may use application protocols=
 like MQTT and more recently in conjunction with single-packet authoriza=
tion (SPA). https://ieeexplore.ieee.org/document/8930455

From the DID ecosystem, I can imagine some future interoperabili=
ty between DIDComm and GNAP. It is not clear that TLS will be used for a=
ll DID-to-DID communications, which aim to be transport agnostic. See di=
scussion here: https://github.com/decentralized-identity/=
didcomm-messaging/issues/38

=

What other potential non-TLS use cases are worth mentioning?

On Wed, Jul 8, 2020, at 1:10 PM, Tom Jones =
wrote:
a somewhat milder response might be.
It seems t=
hat justin's proposal is not, in fact, a grant negotiation, but a genera=
lized token format.
So - what could that mean here?
I have a problem with the whack-a-mole approach of OAuth, with R=
AR JAR ad infinitum.
That is a never-ending stream of hack=
s.
if Justin's proposal is to be considered seriously, it =
must be at some higher level that GNAP..
I suggest  t=
hat the current approach of xauth txauth authxyz is not really headed to=
 a convergence.
Perhaps we need to start with an abstract =
set of goals and data flows.  One that includes the user/RO.
I do have one for healthcare - but i am short of time right now =
to generalize it.
One item I would like to see resolved ea=
rly is to remove the dependency on transport layer security. One that in=
cludes the handling of key roll-over.
In Kantara we focuse=
d first on the legal responsibilities of the token maker. That problem s=
eems to have consumed FAPI, altho they have multiple names for it.
In the real world we have legal entities (natural and unnatural=
) and legal names (brands) as well as pseudonyms. OAuth just had endpoin=
ts with SSL keys and certs.  How about we start there?
Peace ..tom
=


--87840f5812524e53894bd601bd8aae88--


From nobody Wed Jul  8 10:46: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 3B3503A03F2 for ; Wed,  8 Jul 2020 10:46:31 -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 pcdLr7reVAxh for ; Wed,  8 Jul 2020 10:46:29 -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 9CAAF3A03F6 for ; Wed,  8 Jul 2020 10:46:28 -0700 (PDT)
Received: from [192.168.1.7] (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 068HkOoQ005513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Jul 2020 13:46:26 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_FE35A8FF-AF8A-40C2-8F85-1D2DB184EC46"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 8 Jul 2020 13:46:26 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 08 Jul 2020 17:46:31 -0000

--Apple-Mail=_FE35A8FF-AF8A-40C2-8F85-1D2DB184EC46
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I=E2=80=99m going to clip the personal attack here on the list and focus =
on the technical discussion, if that=E2=80=99s ok with everyone...

>=20
> wrt. your proposal to represent an authorization request as an array =
of scopes is overly simplistic. Both XYZ and XAuth represent the request =
as an object to enable a request richer than just an array of scopes.=20

I=E2=80=99m not sure why you think it=E2=80=99s overly simplistic: the =
example I have given is valid XYZ syntax that would exist at the root of =
the client=E2=80=99s request. Yes, XYZ also allows objects within the =
same array, to allow for richer requests, but it does not require you do =
that. This is again one of the values of doing polymorphism in this =
particular way. It=E2=80=99s as simplistic or as complex as you need it =
to be, but it=E2=80=99s consistent in its model and presentation for =
both parsing and generation. So let=E2=80=99s take your example of =
=E2=80=9Cread=E2=80=9D and =E2=80=9Cwrite=E2=80=9D scopes. If a client =
needs to do this, but also needs to do a rich request, it can put them =
all together like this:

{
  =E2=80=9Cresources=E2=80=9D: [=20
    =E2=80=9Cread=E2=80=9D,=20
    =E2=80=9Cwrite=E2=80=9D,
    {
      "type": "payment_initiation",
      "locations": [
         "https://example.com/payments"
      ],
      "instructedAmount": {
         "currency": "EUR",
         "amount": "123.50"
      },
      "creditorName": "Merchant123",
      "creditorAccount": {
         "iban": "DE02100100109307118603"
      },
      "remittanceInformationUnstructured": "Ref Number Merchant"
   }
  ]
}

Notice that the =E2=80=9Cresources=E2=80=9D element is an array here. =
The first two elements of the array are strings =E2=80=94 scopes. The =
third element of the array is an object =E2=80=94 the multi-dimensional =
request (this example taken from the RAR spec). But it=E2=80=99s always =
a =E2=80=9Clist of things that I want=E2=80=9D. Some of those things are =
references as strings, some of them are multi-dimensional specific rich =
objects.

This has been in XYZ=E2=80=99s design and implementations for well over =
a year, and it works well. This is also the basis that I=E2=80=99ve used =
for implementing XYZ on top of an old OAuth 2 server, which doesn=E2=80=99=
t speak RAR or any rich requests but knows how to dispatch against =
scopes.=20

 =E2=80=94 Justin


> /Dick
>=20
>=20
>=20
> On Wed, Jul 8, 2020 at 7:03 AM Justin Richer > wrote:
> I=E2=80=99m glad that you=E2=80=99re looking at polymorphism as a =
possible solution to this, though I would contend that this particular =
style of polymorphism is not doing much more than pushing the =
mutual-exclusivity check down a layer instead of solving it.=20
>=20
> Using multiple types can in fact solve this problem, and several =
others, as long as you=E2=80=99re willing to let go of the syntax that =
OAuth 2 invented to solve a problem that we don=E2=80=99t have to solve =
here (passing an array-type value over the front channel). In XYZ=E2=80=99=
s syntax, the request for a single access token would look like this:
>=20
> {
>   =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=E2=
=80=9D ]
> }
>=20
> And the request for the multiple access tokens would look like this:
>=20
> {
>   =E2=80=9Cresources": {
>      =E2=80=9Creader": [ =E2=80=9Cread=E2=80=9D ],
>      =E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
>   }
> }
>=20
> I find this to be much simpler to parse and generate, as you no longer =
need to check for a specially-reserved field name (=E2=80=9Ctype=E2=80=9D)=
, and you no longer have to do a sub-parse on one of the values to get =
what you really want (the space-separated scope string into a set). =
It=E2=80=99s also a lot simpler for the developers that need to write =
this.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 7, 2020, at 7:30 PM, Dick Hardt > wrote:
>>=20
>>=20
>>=20
>> On Tue, Jul 7, 2020 at 3:40 AM Justin Richer > wrote:
>> I wanted to respond to this comment more fully:
>>=20
>> > wrt. my authorization / authorizations oddness, polymorphism would =
not solve it as the contents of both authorization / authorizations in =
XAuth are objects.=20
>>=20
>> It=E2=80=99s not surprising that this is the case, as the XAuth =
protocol was not designed with polymorphism as a tool to consider. This =
is exactly the reason that I say we should have polymorphism in the =
toolbox from the start, as it allows us to avoid this kind of =
awkwardness in many cases.
>>=20
>>  What evidence do you have to make this statement? "XAuth protocol =
was not designed with polymorphism as a tool to consider"
>>=20
>> It sounds like you are saying I did not consider polymorphism in the =
XAuth protocol design.
>>=20
>> I will restate my comment above about polymorphism.=20
>>=20
>> Using different JSON types does not solve the problem, but as I =
suggest in my comments, polymorphism of different JSON objects is one =
solution. An authorization, or a dictionary of authorizations. It has =
the restriction that the string "type" cannot be used as a label in the =
dictionary. An example:
>>=20
>> {
>>     "authorizations" {
>>         "type": "oauth_scope",
>>         "scope": "read write"
>>     }
>> }
>>=20
>> {
>>     "authorizations" {
>>         "reader": {
>>             "type": "oauth_scope",
>>             "scope": "read"
>>         },
>>         "writer": {
>>             "type": "oauth_scope",
>>             "scope": "write"
>>         },
>>     }
>> }
>>=20
>>=20
>> I am looking at making this change in XAuth and in the =
implementation.
>>=20
>>=20
>>=20
>> =E1=90=A7
>=20


--Apple-Mail=_FE35A8FF-AF8A-40C2-8F85-1D2DB184EC46
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


I=E2=80=99m going to clip the personal attack here =
on the list and focus on the technical discussion, if that=E2=80=99s ok =
with everyone...


wrt. your proposal to =
represent an authorization request as an array of scopes is overly =
simplistic. Both XYZ and XAuth represent the request as an object to =
enable a request richer than just an array of =
scopes. 

I=E2=80=99m not sure why you think it=E2=80=99s =
overly simplistic: the example I have given is valid XYZ syntax that =
would exist at the root of the client=E2=80=99s request. Yes, =
XYZ also allows objects within the same =
array, to allow for richer requests, but it does not require you do =
that. This is again one of the values of doing polymorphism in this =
particular way. It=E2=80=99s as simplistic or as complex as you need it =
to be, but it=E2=80=99s consistent in its model and presentation for =
both parsing and generation. So let=E2=80=99s take your example of =
=E2=80=9Cread=E2=80=9D and =E2=80=9Cwrite=E2=80=9D scopes. If a client =
needs to do this, but also needs to do a rich request, it can put them =
all together like this:

{
  =E2=80=9Cresources=E2=80=9D: =
[ 
    =E2=80=9Cread=E2=80=9D, 
    =E2=80=9Cwrite=E2=80=9D,
    {
      =
"type": "payment_initiation",
      =
"locations": [
        =
 "https://example.com/payments"
  =
    ],
      =
"instructedAmount": {
        =
 "currency": "EUR",
      =
   "amount": "123.50"
    =
  },
      "creditorName": =
"Merchant123",
      =
"creditorAccount": {
        =
 "iban": "DE02100100109307118603"
  =
    },
      =
"remittanceInformationUnstructured": "Ref Number Merchant"
   }
  ]
}

Notice =
that the =E2=80=9Cresources=E2=80=9D element is an array here. The first =
two elements of the array are strings =E2=80=94 scopes. The third =
element of the array is an object =E2=80=94 the multi-dimensional =
request (this example taken from the RAR spec). But it=E2=80=99s always =
a =E2=80=9Clist of things that I want=E2=80=9D. Some of those things are =
references as strings, some of them are multi-dimensional specific rich =
objects.

This has been in XYZ=E2=80=99=
s design and implementations for well over a year, and it works well. =
This is also the basis that I=E2=80=99ve used for implementing XYZ on =
top of an old OAuth 2 server, which doesn=E2=80=99t speak RAR or any =
rich requests but knows how to dispatch against =
scopes. 

 =E2=80=94 =
Justin


/Dick



On Wed, Jul =
8, 2020 at 7:03 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m glad that you=E2=80=99re looking at =
polymorphism as a possible solution to this, though I would contend that =
this particular style of polymorphism is not doing much more than =
pushing the mutual-exclusivity check down a layer instead of solving =
it. 

Using =
multiple types can in fact solve this problem, and several others, as =
long as you=E2=80=99re willing to let go of the syntax that OAuth 2 =
invented to solve a problem that we don=E2=80=99t have to solve here =
(passing an array-type value over the front channel). In XYZ=E2=80=99s =
syntax, the request for a single access token would look like =
this:

{
  =E2=80=9Cresources=E2=80=9D: [ =
=E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=E2=80=9D ]
}

And=
 the request for the multiple access tokens would look like =
this:

{
  =E2=80=9Cresources": =
{
     =E2=80=9Creader": [ =
=E2=80=9Cread=E2=80=9D ],
    =
 =E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
  }
}

I find this to be much simpler to parse =
and generate, as you no longer need to check for a specially-reserved =
field name (=E2=80=9Ctype=E2=80=9D), and you no longer have to do a =
sub-parse on one of the values to get what you really want (the =
space-separated scope string into a set). It=E2=80=99s also a lot =
simpler for the developers that need to write this.

 =E2=80=94 =
Justin

On Jul 7, 2020, at 7:30 PM, =
Dick Hardt <dick.hardt@gmail.com> wrote:



On Tue, Jul 7, 2020 at 3:40 AM Justin =
Richer <jricher@mit.edu> wrote:
I wanted to respond to this =
comment more fully:



> wrt. my authorization / authorizations oddness, polymorphism would =
not solve it as the contents of both authorization / authorizations in =
XAuth are objects. 



It=E2=80=99s not surprising that this is the case, as the XAuth protocol =
was not designed with polymorphism as a tool to consider. This is =
exactly the reason that I say we should have polymorphism in the toolbox =
from the start, as it allows us to avoid this kind of awkwardness in =
many cases.

 What evidence do you have to make =
this statement? "XAuth protocol was not designed with polymorphism as a =
tool to consider"

It sounds like you are saying I did not =
consider polymorphism in the XAuth protocol design.

I will restate my =
comment above about polymorphism. 

Using different JSON types does not =
solve the problem, but as I suggest in my comments, polymorphism of =
different JSON objects is one solution. An authorization, or a =
dictionary of authorizations. It has the restriction that the string =
"type" cannot be used as a label in the dictionary. An =
example:

{
    "authorizations" {
    =
    "type": "oauth_scope",
      =
  "scope": "read write"
    }
}

{
    =
"authorizations" {
        "reader": =
{
            "type": =
"oauth_scope",
            =
"scope": "read"
        },
        "writer": {
  =
          "type": "oauth_scope",
            "scope": "write"
        },
    =
}
}


I =
am looking at making this change in XAuth and in the =
implementation.



3D""=E1=90=A7






=

--Apple-Mail=_FE35A8FF-AF8A-40C2-8F85-1D2DB184EC46--


From nobody Wed Jul  8 11:01:32 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 9198C3A0542 for ; Wed,  8 Jul 2020 11:01:30 -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_REMOTE_IMAGE=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 YRurdsNkjgyj for ; Wed,  8 Jul 2020 11:01:26 -0700 (PDT)
Received: from mail-yb1-xb42.google.com (mail-yb1-xb42.google.com [IPv6:2607:f8b0:4864:20::b42]) (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 8437A3A0544 for ; Wed,  8 Jul 2020 11:01:26 -0700 (PDT)
Received: by mail-yb1-xb42.google.com with SMTP id y17so20574703ybm.12 for ; Wed, 08 Jul 2020 11:01: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=ViC/OgjC3CuwHCjdMQZ9D/mxsVdb37/nPwU2s0o24ac=; b=VBbQ/aSKUGbynZdj7+HvvJ4y0q51+CcA935/t5R2ItNoThyUTRT9Lv8SV6dwV+qkU8 rOq3W05BgO4XkryJlSbEsG0QSNhsEswyH8oZhi3AtaV6ZT1vYgV1T6rf/6oOTLh+eOsM yH6I6Ge2g0V/udrt1Jrp1YpFiM6yi9F20Ij3brbe5JjYvLRhDOorBiwOdOFOaWHu+VB8 yX34BC4zn+KDUB90dTEDtWqqGm9IASj08GcHbjfZ5TeiMfG3rkS7ER9udLloEL/rfN3X QPVE1/fkmx1tZhmD5wxHuiuPlUIqi9m7Lb+1P/nPYyr2qj4MYseOKoHa9/g7g6CtxnQQ MhpA==
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=ViC/OgjC3CuwHCjdMQZ9D/mxsVdb37/nPwU2s0o24ac=; b=cpIW+Sz7Cp9/HG3Rpzgkkgn6ye8WKHwRgZXZatIiMEYzxbxCmulva9a6y9LuA6PXUM KEgTcdvzv8DPB+X54xLIbJw+mZOtgLZkKzkEoHk9GM8I9uafiLTQCR68/OwZzc3f2OHR NAn8DF414q37Z12omFXxli+buIGbX1w4qG9I6Ba36Za1cTpBlpqjDGgfQZQqV/6k6X76 1ztffxk7ZfLqeR2lEyMW4FL083CKUjBWvXUghqwXbkWRv1yh0o22z/JQ1x1ycOpJO7yG 1w4yVyz0ECBdhhwUzjp4lVlrlwl79Qg/i3URgnWE6nn5UsyFdmFic+ss/JfQCtcDvXFR O4nQ==
X-Gm-Message-State: AOAM532+aMYssipeQ62PvRR0JdLF3i3FxSJwLurqvOkUXg2DLtCfzXyp ItGQnUqiNf7eEX4KCoQoZdV6gcdmFwk5P/lJQpc=
X-Google-Smtp-Source: ABdhPJz0o06dfsYJ6Q8I1s81dMKLHfZIR/zoPHtAistxvybmbmxQNost9g0CocwrXa1vP0XAtA8wAss9IxQbdQsPRqA=
X-Received: by 2002:a25:6a88:: with SMTP id f130mr88327229ybc.310.1594231283890;  Wed, 08 Jul 2020 11:01:23 -0700 (PDT)
MIME-Version: 1.0
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <6846D2F0-5096-404B-A529-676146392F45@mit.edu>  <2D3EEF56-BD86-42DF-82D2-7595E19C5350@mit.edu> <9c434f67-77fa-8a80-5ac0-4061fd5bf02c@free.fr>
In-Reply-To: <9c434f67-77fa-8a80-5ac0-4061fd5bf02c@free.fr>
From: Stephen Moore 
Date: Wed, 8 Jul 2020 14:01:11 -0400
Message-ID: 
To: Denis 
Cc: Justin Richer , Tobias Looker , txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005dc1a805a9f1e5ee"
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 08 Jul 2020 18:01:31 -0000

--0000000000005dc1a805a9f1e5ee
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis, I want to point out that not all use cases care or want the AS to
not know who is using the tokens.

So while we should enable the case you are talking about, where the AS
knows absolutely nothing about where the tokens are going, we should not
prevent that ability.
After all the AS is providing 'authorization' to access a resource, it
seems very limiting to say that the AS can't know what those resources are.
I imagine that in the healthcare
and financial fields, the AS is the point of logging and auditing who was
given authorization to access various systems and resources, and I can't
see that working in your case.

Also, as Justin points out, there are two ways to look at the rights in the
token, one is introspection, which does leave a paper trail (again, might
be needed for auditing reasons), or
have the resource server decode the token itself, which wouldn't tie the
token to that RS at the AS. We can't limit to just one path here. Again in
my (currently hypothetical) use case, the RS are IoT devices that
may not have the power to decode the tokens, and in fact will want to check
against the AS due to making sure tokens were not revoked.

I'll see if I can write up what I'm thinking in terms of use case,
partially because it splits up the authorisation and the authentication
parts of things. (I don't care who does the authentication, but my local AS
will do all the policy setting and authorization.)

-Steve


On Wed, Jul 8, 2020 at 1:13 PM Denis  wrote:

> Hi Justin,
>
> I think there are two interesting layers here:
>
>  - Information that the client needs to know. This is what started the
> thread, the whole =E2=80=9Chow and where am I allowed to use this token=
=E2=80=9D question.
> This is stuff that would be put alongside the token in the response from
> the AS, not inside the token.
>
> If the "how and where am I allowed to use this token=E2=80=9D is sent alo=
ngside
> the token in the response from the AS, then you are allowing the AS
> to know which RS(s) will be able to consume the access token. This should
> be prevented for privacy reasons (i.e. the AS would be able to act as Big
> Brother).
>
>
>  - Information that the RS needs to know. This is I think where the
> attenuation, proofing, and the actual rights associated with the token
> would go.
> This is stuff that would either be in the token itself or in a  return
> from an introspection style call.
>
> With an introspection style call you are allowing the AS to know to which
> RS(s) the access token has arrived. This should be prevented for privacy
> reasons
> (i.e. the AS would be able to act as Big Brother).
>
> Denis
>
>
> Both of these fit into the =E2=80=9Cconsistent token model=E2=80=9D part =
of GNAP, but
> different aspects need to be communicated in different ways.
>
>  =E2=80=94 Justin
>
> On Jul 7, 2020, at 8:01 PM, Tobias Looker 
> wrote:
>
> I've also been thinking about the parallels between ZCAP's and OAuth2.0
> access tokens. To me a ZCAP is a less opaque, semantically richer
> capability format, whereas an access_token is traditionally much simpler.
> The key here though is I still see an access_token as a form of capabilit=
y.
> It appears in general one of the trade offs we will be faced with is
> either:
>
> 1. Keeping the capability received from a GNAP flow (e.g an access_token)
> opaque to the client and externalizing any greater information about how =
to
> use the capability (such as in your proposal in the first email of this
> thread).
> 2. Internalizing information about the capabilities utility and any
> greater context about it which means the capability is no longer opaque.
>
> With that aside, the notable features in general I would like GNAP to
> consider from ZCAP's, are the following.
>
> - Delegatable capabilities (bonus if this mechanism includes the ability
> to attenuate during delegation) - Consider the example where a client or =
RP
> (RP1) receives some form of access_token (capability) from an AS and woul=
d
> like to delegate this to another RP (RP2) so they can access the same
> resources. If including attenuation this would mean that during this
> delegation (RP1->RP2), RP1 could narrow the scope of the original access =
it
> received so that RP2 only gets a subset of the original scope.
> - Bound capabilities - Similar in some ways to dPop, essentially
> establishing the ability to bind an access_token (capability) to the part=
y
> that should be able to use it (invoker). I see this as a must have in ord=
er
> to be able to do attenuated delegation as described above.
>
> Thanks,
> [image: Mattr website] 
> *Tobias Looker*
> Mattr
> +64 (0) 27 378 0461
> tobias.looker@mattr.global
> [image: Mattr website]  [image: Mattr on LinkedIn]
>  [image: Mattr on Twitter]
>  [image: Mattr on Github]
> 
> This communication, including any attachments, is confidential. If you ar=
e
> not the intended recipient, you should not read it - please contact me
> immediately, destroy it, and do not copy or use any part of this
> communication or disclose anything about it. Thank you. Please note that
> this communication does not designate an information system for the
> purposes of the Electronic Transactions Act 2002.
>
>
> On Wed, Jul 8, 2020 at 8:39 AM Justin Richer  wrote:
>
>> I=E2=80=99ve been thinking more about these use cases, and it might help=
 us to
>> think of GNAP=E2=80=99s access tokens as capabilities in the computer se=
curity
>> sense =E2=80=94 but more specifically, capabilities that are delivered w=
ith their
>> own context for use. In that way, an otherwise naive client can be hande=
d
>> an access token and simply know exactly what to do with it. This context
>> would be delivered alongside the token, so the token material itself
>> remains opaque to the client.
>>
>> I wanted to bring up a W3C spec for a capabilities model based on linked
>> data:
>>
>> https://w3c-ccg.github.io/zcap-ld/
>>
>> Building a fully featured capabilities context is difficult, at the very
>> least. And unfortunately, I don=E2=80=99t think this spec actually gives=
 us any
>> viable solutions to work with. In particular the =E2=80=9Cactions=E2=80=
=9D section is
>> effectively blank, offloading the work to an external JSONLD process (si=
de
>> note, this is one of the problems I have with specs based on JSONLD, the=
y
>> externalize the important parts into local contexts and break
>> interoperability =E2=80=94 but I digress). But at least it=E2=80=99s ano=
ther way of looking
>> at the problem space that might be outside the familiar zone of many of =
the
>> OAuth world.
>>
>>  =E2=80=94 Justin
>>
>> On Jun 26, 2020, at 9:23 AM, Justin Richer  wrote:
>>
>> On Jun 25, 2020, at 9:07 PM, Tobias Looker 
>> wrote:
>>
>>
>> I find this feature interesting and think it could be an
>> important pattern going forward to enable an AS to be able to describe t=
he
>> utility of a token to the client, however as already pointed out in the
>> thread I think there is some potential hidden complexity that would need=
 to
>> be ironed out such that it does not make the simple things complicated.
>>
>> Justin, do you see this feature as something the client has to explicitl=
y
>> request, i.e "please give me access and instructions on how to use my
>> access" or rather that the AS would just return this information in
>> conjunction with the access token if it had it available?
>>
>>
>> This is something that I=E2=80=99d brought up as a possibility on the pr=
evious
>> thread =E2=80=94 something like a flag the client would set. This would =
be
>> especially important if the AS wants to return multiple access tokens bu=
t
>> the client requested 1, or the client requested N and the AS wants to
>> return M in response. Basically any time there=E2=80=99s a mismatch, tha=
t=E2=80=99s extra
>> complexity on the client that I really don=E2=80=99t think we want to be=
 universal.
>> A flag to turn that kind of direction and splitting on would be a potent=
ial
>> start. But there are potential snags here too, and it comes down to how =
you
>> manage the defaults...
>>
>> > This is just the start, too. Things get even more complex if the clien=
t
>> can ask for multiple different kinds of resources at once. What if the A=
S
>> decides that the client needs a hyper-focused directed token for one par=
t
>> of the API, but can use a general token for other stuff? Can it signal t=
hat
>> to the client? And if it can, does that mean that all clients need to be
>> prepared for that kind of thing?
>>
>> Would a potential default be that if a client did for any reason not
>> support processing the additional information returned with the
>> access_token, just to ignore it? I think in the spirit of keeping the
>> simple things simple, this potentially makes sense?
>>
>>
>> That=E2=80=99s the real trick, if you ask me. It has to be :safe: for a =
client to
>> ignore this information. Which means the AS can=E2=80=99t rely on the cl=
ient =E2=80=9Cdoing
>> the right thing=E2=80=9D with the information in the =E2=80=9Ctoken dire=
ctions=E2=80=9D portion of
>> the response. Even setting aside the advanced and related =E2=80=9Csplit=
 tokens=E2=80=9D
>> idea above, we need to make sure that an AS/RS setup is built such that =
if
>> the AS tells a client =E2=80=9Conly do X with your token=E2=80=9D and th=
e client does =E2=80=9CY=E2=80=9D,
>> then there are other protections and practices in place to prevent thing=
s
>> from going haywire if the client does =E2=80=9CY=E2=80=9D either by acci=
dent or through
>> ignorance.
>>
>> If OAuth 2 has taught us anything, it=E2=80=99s that client applications=
 are
>> going to be the laziest participants in the security model. And that mak=
es
>> sense, really =E2=80=94 security isn=E2=80=99t what the client apps are =
trying to do,
>> they=E2=80=99re trying to use the RS to do something. So we need to make=
 sure that
>> whatever system we design will fail on the safe side as much as possible=
,
>> and keep things simple for the client.
>>
>>
>> > here are some worked out samples of this:
>> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
>> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
>> Peace ..tom
>>
>> As one of the authors of those mentioned drafts, I am interested in
>> discussing that, but perhaps on a seperate thread? As at least the bound
>> assertion spec is primarily concerned with binding mechanisms for the
>> artifacts produced from an authorization flow (specifically identity
>> claims), whereas I think directed access tokens is just more generally
>> talking about whether GNAP should support an AS conveying how to use an
>> access_token it produces during a flow with a client.
>>
>>
>> I think that these are separate issues as well.
>>
>>  =E2=80=94 Justin
>>
>> Thanks,
>> [image: Mattr website] 
>> *Tobias Looker*
>> Mattr
>> +64 (0) 27 378 0461
>> tobias.looker@mattr.global
>> [image: Mattr website]  [image: Mattr on LinkedIn=
]
>>  [image: Mattr on Twitter]
>>  [image: Mattr on Github]
>> 
>> This communication, including any attachments, is confidential. If you
>> are not the intended recipient, you should not read it - please contact =
me
>> immediately, destroy it, and do not copy or use any part of this
>> communication or disclose anything about it. Thank you. Please note that
>> this communication does not designate an information system for the
>> purposes of the Electronic Transactions Act 2002.
>>
>>
>> On Wed, Jun 24, 2020 at 10:14 PM Denis  wrote:
>>
>>> Justin, I fear we are still far away from an agreement about what this
>>> BoF should do.
>>>
>>> Tom Jones is saying " I am getting tired of the whack-a-mole approach
>>> ...."
>>>
>>> I don't agree with you when you write: "I think it=E2=80=99s going to b=
e
>>> overwhelmingly common that a given RS is going to trust exactly one AS
>>> that it knows about ahead of time". Such an architecture would have
>>> exactly the same limitations as OAuth 2.0. and would not be scalable.
>>>
>>> Before we start, we should have a clear view of the whole picture rathe=
r
>>> than starting from one scenario and expanding it in many different
>>> directions.
>>> For building an architecture, a pre-requirement is to define ALL the
>>> trust relationships. I don't believe that we have an agreement at this =
time
>>> on what
>>> these trust relationships are.
>>>
>>> You are also using the following wording: "methods for the AS and RS to
>>> communicate what the token=E2=80=99s good for".
>>> With such a paradigm, it would be impossible to protect the user's
>>> privacy.
>>>
>>> A key question is : Will GNAP take care of the user's privacy or will
>>> GNAP *prevent *to take care of the user's privacy ?
>>>
>>> About "the ability for the client to get several access tokens to get
>>> different resources from one request" is indeed a complex case.
>>>
>>> No one (including ASs) is able to predict in advance which access token=
s
>>> will be needed, since they depend upon the kind of operation(s)
>>> the client will be willing to perform. For privacy reasons, ASs should
>>> be kept ignorant of all the operations that a client is going to perfor=
m
>>>
>>> on one or more resource servers. I believe that every effort should be
>>> made to avoid the AS to be in a position to be able to trace the operat=
ions
>>>
>>> performed by its clients on various RSs.
>>>
>>> To handle the complex case you envision, the full workflow of operation=
s
>>> needs to be considered with a detailed focus on the time
>>> at which the user's *consent and choice* happens (*consent and choice* =
is
>>> the first privacy principle from ISO 29100).
>>>
>>> First of all, an access token could be targeted to a service rather tha=
n
>>> to a server. This would already solve many cases.
>>>
>>> When a RS needs to call another RS (which does not support the same
>>> service) then the client should be informed by the first RS.
>>> His "consent and choice" should then be obtained by the first RS and,
>>> when the user agrees, the client should then ask an access token
>>> to one of the ASs trusted by the second RS in order to perform the
>>> subsequent operation.
>>>
>>> Denis
>>>
>>> PS.  In an email sent on June 23 you wrote: " I think an on-device AS i=
s
>>> an important use case".  I am sorry, but I don't understand.
>>>        However, I do understand what "a server-based AS" is.
>>>
>>>
>>> Denis, thanks for the great comments. I think that your trust model is
>>> pretty different from what I=E2=80=99d laid out initially, and while it=
=E2=80=99s an
>>> interesting and important one, it is not what I meant by =E2=80=9Cmulti=
ple access
>>> tokens=E2=80=9D in my discussion below. I think that might be the cause=
 of some
>>> disconnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of reac=
h for what the WG is
>>> after.
>>>
>>> When I refer to multiple access tokens, and what the charter calls out
>>> as multiple access tokens, is the ability for the client to get several
>>> access tokens to get different resources from one request. I personally=
 see
>>> this as an optimization of a specific set of use cases, some of which I
>>> discussed in my original email. There are others, I=E2=80=99m sure, but=
 all the
>>> ones I=E2=80=99ve seen are around the client needing to get several dif=
ferent kinds
>>> of access through an AS.
>>>
>>> I think it=E2=80=99s going to be overwhelmingly common that a given RS =
is going
>>> to trust exactly one AS that it knows about ahead of time. But for RS=
=E2=80=99s
>>> that can trust multiple AS=E2=80=99s, then we should have a model that =
can
>>> accommodate that as well. That=E2=80=99s why the charter calls out meth=
ods for the
>>> AS and RS to communicate what the token=E2=80=99s good for. I think the=
 basis of
>>> those methods is going to start with a common token model, and likely
>>> incorporate into things like token formats and introspection-style toke=
n
>>> APIs.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jun 22, 2020, at 3:55 AM, Denis  wrote:
>>>
>>> Hello Justin,
>>>
>>> A few comments between the lines.
>>>
>>> One of the most important aspects to GNAP is going to be an ability to
>>> address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do=
 without significant
>>> gymnastics. So with that, I wanted to bring back a use case discussion =
that
>>> originally came up while we were talking about the possibility of multi=
ple
>>> access tokens, a few months back. I don=E2=80=99t know if this concept =
has a
>>> regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access =
tokens=E2=80=9D until we
>>> come up with something better =E2=80=94 assuming we decide this is wort=
hwhile.
>>>
>>> I don't understand what may mean "directed access tokens=E2=80=9D but I
>>> understand what means "multiple access tokens".
>>> When speaking of "multiple access tokens", these access tokens may come
>>> from one or more ASs.
>>>
>>> In OAuth, the client=E2=80=99s supposed to always know where to send it=
s access
>>> token, and that knowledge is completely outside the protocol. This make=
s a
>>> lot of sense for many (if not most) deployments, as OAuth is really the=
re
>>> to enable the API access that the client already knows about.
>>>
>>> But we=E2=80=99re now in a world where a client could be talking to a g=
eneric
>>> API that could be deployed at a number of different places, or a cloud
>>> deployment that the AS wants to be able to dispatch the client to.
>>>
>>> As soon the AS is placed (again) at the centre of the model, the AS wil=
l
>>> have the ability to act as "Big Brother".
>>> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP
>>> should take care of them.
>>>
>>> In order to do this, the AS needs to be able to communicate to the
>>> client not only the token information (and any related key and presenta=
tion
>>> information), but also a set of *directions* about what that specific
>>> token is good for. This needs to be information outside the token itsel=
f,
>>> since I believe we want to keep OAuth 2=E2=80=99s feature of having the=
 token be
>>> opaque to the client. Note: while we could map all of these to differen=
t
>>> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlan=
ce)
>>> on the request side, this isn=E2=80=99t enough to tell the client what =
to do with
>>> the token *if it doesn=E2=80=99t know already*.
>>>
>>> I know of two use cases already in the wild, where people are addressin=
g
>>> things using a mix of existing standards and some proprietary extension=
s to
>>> address things within their silos. I=E2=80=99ll try to summarize here, =
but I know
>>> the folks I=E2=80=99ve been talking to about this are also on the list =
so hopefully
>>> they can chime in with more detail or any corrections for something I=
=E2=80=99ve
>>> missed.
>>>
>>> (1) The client knows what resource it=E2=80=99s calling, but it doesn=
=E2=80=99t know
>>> where it=E2=80=99s hosted. Everything is in a single security domain co=
ntrolled by
>>> the AS,
>>>
>>> Speaking of "multiple access tokens" is in contradiction with single
>>> security domain "controlled" by an AS.
>>> A user may need to demonstrate some of his identity attributes granted
>>> e.g. by his bank but may also
>>> need to demonstrate one or more diplomas granted by one or more
>>> universities. The bank cannot be
>>> the "primary issuer" of a university diploma. It should not be either a
>>> "secondary issuer", because
>>> the bank does not "*need to know"* what are the diplomas of the user.
>>>
>>> but the AS needs to decide at runtime which specific instance of the AP=
I
>>> to direct the client to. Since things are closely tied together, the cl=
ient
>>> just needs to effectively known an identifier for the RS, and this is
>>> currently implemented as a URI. Once the client has that identifier, it
>>> knows how to dispatch that token to that instance of the RS.
>>>
>>> There is no good reason why the AS should be involved in that step.
>>> OAuth 2.0 is/was implicitly mandating a strong relationship between ASs
>>> and RSs which makes it non scalable.
>>> GNAP should be based on a simple trust relationship : a given RS trusts
>>> some ASs for access tokens that contains some types of attributes.
>>> An AS should not need to know in advance (or even at the time of an
>>> access token request) the RSs that are trusting it.
>>>
>>> A client could first talk to a "global service provider" which has the
>>> knowledge of the different RSs affiliated to it.
>>>
>>> (2) The client knows what kind of thing it=E2=80=99s looking for, but d=
oesn=E2=80=99t
>>> know who to ask it from.
>>>
>>> Once again, the client could first talk to a "global service provider"
>>> which has the knowledge of the different RSs affiliated to it.
>>>
>>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, =
and the AS needs
>>> to dispatch to different resources depending on which user logged in (a=
nd
>>> possibly what the user consented to). To make things more concrete, the
>>> client needs to get driver=E2=80=99s license information, but doesn=E2=
=80=99t know ahead of
>>> time which of the many state/provincial bureaus to call to get that
>>> information because it doesn=E2=80=99t know yet who the user is.
>>>
>>> When a user has a driving license, he knows its issuer. The user can
>>> then provide some hint to the client.
>>>
>>> The AS will know who the user is once they log in and approve things,
>>> and so it can direct the client to call the correct RS. Since this is a
>>> relatively simple API with a pre-negotiated cross-domain trust, the AS
>>> returns a URL that the client presents the token at.
>>>
>>>  A single AS should not be aware of all the attributes a user has.
>>>
>>>
>>> As far as I know, in both of these cases, the token is only good for
>>> that API and not others =E2=80=94 but more on that later.
>>>
>>> A simple thing to do is just give back a URL with the access token,
>>> which tells the client where to go.
>>>
>>> {
>>> =E2=80=9Caccess_token=E2=80=9D: {
>>> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
>>> =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
>>> }
>>> }
>>>
>>> This is good for some kinds of APIs, but it=E2=80=99s limiting because =
not all
>>> APIs dispatch based on the URL. An AS might want to divvy up access tok=
ens
>>> to an API that=E2=80=99s keyed on headers, or verbs, or any number of t=
hings. And
>>> it doesn=E2=80=99t tell us immediately what to do about non-exact URL m=
atches. Can
>>> the client add query parameters and still use the token? What about pat=
h
>>> segments? I like that this simple approach addresses some common
>>> deployments that we already see today (see above), it=E2=80=99s not uni=
versal. Do
>>> we want or need a universal description language for directing where to=
kens
>>> go?
>>>
>>> This also opens up a whole new set of security questions. If the AS can
>>> now direct the client where to use the token, could a rogue AS convince=
 a
>>> legit client to use a stolen token at the wrong RS? And what if the cli=
ent
>>> ignores the directions from the AS entirely? Could this open up new ave=
nues
>>> of attack?
>>>
>>> This is just the start, too. Things get even more complex if the client
>>> can ask for multiple different kinds of resources at once. What if the =
AS
>>> decides that the client needs a hyper-focused directed token for one pa=
rt
>>> of the API, but can use a general token for other stuff? Can it signal =
that
>>> to the client? And if it can, does that mean that all clients need to b=
e
>>> prepared for that kind of thing?
>>>
>>> I firmly believe that whatever we build in GNAP, we need to optimize fo=
r
>>> the overwhelmingly common use case of a client getting a single access
>>> token to call APIs that it already knows about. Anything we add on top =
of
>>> that really can=E2=80=99t get in the way of this, because if it does, t=
here=E2=80=99s very
>>> small chance that people will try to use this for everyday things. Keep=
 the
>>> simple things simple, and the complex things possible, after all.
>>>
>>> I=E2=80=99m really looking forward to hearing what the community thinks=
 about
>>> these use cases, and hopefully the people I=E2=80=99ve chatted with off=
line about
>>> this can join the conversation and provide more light than I was able t=
o.
>>>
>>> The two use cases which are considered above are:
>>>
>>> (1) The client knows what resource it=E2=80=99s calling, but it doesn=
=E2=80=99t know
>>> where it=E2=80=99s hosted.
>>> (2) The client knows what kind of thing it=E2=80=99s looking for, but d=
oesn=E2=80=99t
>>> know who to ask it from.
>>>
>>> That does not mean in any way that these two use cases should be solved
>>> by placing the AS at the centre of the solution.
>>>
>>> Denis
>>>
>>>
>>>  =E2=80=94 Justin
>>>
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>> This communication, including any attachments, is confidential. If you a=
re not the intended recipient, you should not read it - please contact me i=
mmediately, destroy it, and do not copy or use any part of this communicati=
on or disclose anything about it. Thank you. Please note that this communic=
ation does not designate an information system for the purposes of the Elec=
tronic Transactions Act 2002.
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>>
> This communication, including any attachments, is confidential. If you ar=
e not the intended recipient, you should not read it - please contact me im=
mediately, destroy it, and do not copy or use any part of this communicatio=
n or disclose anything about it. Thank you. Please note that this communica=
tion does not designate an information system for the purposes of the Elect=
ronic Transactions Act 2002.
>
>
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--0000000000005dc1a805a9f1e5ee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis, I want to point out that not all use cases care =
or want the AS to not know who is using the tokens.=C2=A0

So while we should enable the case you are talking about, where the AS kn=
ows absolutely=C2=A0nothing about where the tokens are going, we should not=
 prevent that ability.
After all the AS is providing 'authori=
zation' to access a resource, it seems very limiting to say that the AS=
 can't know what those resources are. I imagine that in the healthcare<=
/div>
and financial fields, the AS is the point of logging and auditing=
 who was given authorization to access various systems and resources, and I=
 can't see that working in your case.

Also, as=
 Justin points out, there are two ways to look at the rights in the token, =
one is introspection, which does leave a paper trail (again, might be neede=
d for auditing reasons), or
have the resource server decode the t=
oken itself, which wouldn't tie the token to that RS at the AS. We can&=
#39;t limit to just one path here. Again in my (currently hypothetical) use=
 case, the RS are IoT devices that
may not have the power to deco=
de the tokens, and in fact will want to check against the AS due to making =
sure tokens were not revoked.=C2=A0

I'll see i=
f I can write up what I'm thinking in terms of use case, partially beca=
use it splits up the authorisation and the authentication parts of things. =
(I don't care who does the authentication, but my local AS will do all =
the policy setting and authorization.)

-Steve


On Wed, Jul 8, 2020 at 1:13 PM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hi Justin,

    

     =20
      I think there are two interesting layers here:=C2=A0
      


      

      
=C2=A0- Information that the client needs to know. This
        is what started the thread, the whole =E2=80=9Chow and where am I
        allowed to use this token=E2=80=9D question. 

        This is stuff that would be put alongside the token in the
        response from the AS, not inside the token.

    

    
If the "how and where am I allowed to use this token=E2=80=9D i=
s sent
      alongside the token in the response from the AS, then you are
      allowing the AS 

      to know which RS(s) will be able to consume the access token. This
      should be prevented for privacy reasons (i.e. the AS would be able
      to act as Big Brother).

    


      
=C2=A0- Information that the RS needs to know. This is I
        think where the attenuation, proofing, and the actual rights
        associated with the token would go. 

        This is stuff that would either be in the token itself or in a
        =C2=A0return from an introspection style call.

    

    
With an introspection style call you are allowing the AS to know
      to which RS(s) the access token has arrived. This should be
      prevented for privacy reasons 

      (i.e. the AS would be able to act as Big Brother). 

    

    
Denis

    


      
Both of these fit into the =E2=80=9Cconsistent token model=E2=80=
=9D
        part of GNAP, but different aspects need to be communicated in
        different ways.=C2=A0

      


      

      
=C2=A0=E2=80=94 Justin

        


          

            
On Jul 7, 2020, at 8:01 PM, Tobias Looker <tobias.looker@mattr.glo=
bal>
              wrote:

            

            

             =20
              
I've also been thinking about the
                parallels between ZCAP's and OAuth2.0 access tokens. To
                me a ZCAP is a less opaque, semantically richer
                capability format, whereas an access_token is
                traditionally much simpler. The key here though is I
                still see an access_token as a form of capability. It
                appears in general one of the trade offs we will be
                faced with is either:
                


                

                
1. Keeping the capability received=C2=A0from a
                  GNAP flow (e.g an access_token) opaque to the client
                  and externalizing any greater information about how to
                  use the capability (such as in your proposal in the
                  first email of this thread).

                
2. Internalizing information about the
                  capabilities utility and any greater context about it
                  which means the capability is no longer opaque.

                

                  


                  

                  
With that aside, the notable features in
                    general I would like GNAP to consider from ZCAP's,
                    are the following.
                    


                    

                    
- Delegatable capabilities (bonus if
                      this mechanism includes the ability to attenuate
                      during delegation) - Consider the example where a
                      client or RP (RP1) receives=C2=A0some form of
                      access_token (capability) from an AS and would
                      like to delegate this to another RP (RP2) so they
                      can access the same resources. If including
                      attenuation=C2=A0this=C2=A0would mean that during thi=
s
                      delegation (RP1->RP2), RP1 could narrow the
                      scope of the original access it received=C2=A0so that
                      RP2 only gets a subset of the original scope.

                    
- Bound capabilities - Similar in some
                      ways to dPop, essentially establishing the ability
                      to bind an access_token (capability) to the party
                      that should be able to use it (invoker). I see
                      this as a must have in order to be able to do
                      attenuated delegation as described above.
                      

                        

                          

                            


                            

                            
Thanks,

                              

                                
                                  

                                    3D"Mattr
                                    =C2=A0
                                    
                                      

                                        
                                          

                                            Tobias Looker

                                            		
                                          

                                          

                                            =
Mattr
                                          

                                          

                                            +64 (0) 27 378
                                              0461

                                              tobias.looker@mattr.global		
                                          

                                          

                                            
                                              

                                                
                                                  

                                                    3D"Mattr
                                                    3D"Mattr
                                                    3D"Mattr
                                                    3D"Mattr
                                                  

                                                
                                              

                                            		
                                          

                                        
                                      

                                    		
                                  

                                
                              

                              

                              This communication, including
                                any attachments, is confidential. If you
                                are not the intended recipient, you
                                should not read it - please contact me
                                immediately, destroy it, and do not copy
                                or use any part of this communication or
                                disclose anything about it. Thank you.
                                Please note that this communication does
                                not designate an information system for
                                the purposes of the Electronic
                                Transactions Act 2002.

                            

                          

                        

                        

                      

                    

                  

                

              

              

              

                
On Wed, Jul 8, 2020 a=
t
                  8:39 AM Justin Richer <jricher@mit.edu>
                  wrote:

                

                

                  
I=E2=80=99ve
                    been thinking more about these use cases, and it
                    might help us to think of GNAP=E2=80=99s access tokens =
as
                    capabilities in the computer security sense =E2=80=94 b=
ut
                    more specifically, capabilities that are delivered
                    with their own context for use. In that way, an
                    otherwise naive client can be handed an access token
                    and simply know exactly what to do with it. This
                    context would be delivered alongside the token, so
                    the token material itself remains opaque to the
                    client.
                    


                    

                    
I wanted to bring up a W3C spec for a
                      capabilities model based on linked data:
                      


                      

                      
                      


                      

                      
Building a fully featured
                        capabilities context is difficult, at the very
                        least. And unfortunately, I don=E2=80=99t think thi=
s
                        spec actually gives us any viable solutions to
                        work with. In particular the =E2=80=9Cactions=E2=80=
=9D section
                        is effectively blank, offloading the work to an
                        external JSONLD process (side note, this is one
                        of the problems I have with specs based on
                        JSONLD, they externalize the important parts
                        into local contexts and break interoperability =E2=
=80=94
                        but I digress). But at least it=E2=80=99s another w=
ay of
                        looking at the problem space that might be
                        outside the familiar zone of many of the OAuth
                        world.

                      


                      

                      
=C2=A0=E2=80=94 Justin

                        


                          

                            
On Jun 26, 2020, at 9:23 AM,
                              Justin Richer <jricher@mit.edu>
                              wrote:

                            

                            
On Jun 25, 2020, at 9:07 PM,
                                Tobias Looker <tobias.looker@mattr.global> wrote:

                              

                                


                                  

                                    
I find this
                                      feature interesting and think it
                                      could be an important=C2=A0pattern
                                      going=C2=A0forward to enable an AS to
                                      be able to describe the utility of
                                      a token to the client, however as
                                      already pointed out in the thread
                                      I think there is some potential
                                      hidden complexity that would need
                                      to be ironed out such that it does
                                      not make the simple things
                                      complicated.
                                      


                                      

                                      
Justin, do you see
                                        this feature as something the
                                        client has to explicitly
                                        request, i.e "please give me
                                        access and instructions on how
                                        to use my access" or rather th=
at
                                        the AS would just return this
                                        information in conjunction with
                                        the access token if it had it
                                        available?

                                      


                                      

                                    

                                  

                                

                                


                                

                                
This is something that I=E2=80=99d
                                  brought up as a possibility on the
                                  previous thread =E2=80=94 something like =
a
                                  flag the client would set. This would
                                  be especially important if the AS
                                  wants to return multiple access tokens
                                  but the client requested 1, or the
                                  client requested N and the AS wants to
                                  return M in response. Basically any
                                  time there=E2=80=99s a mismatch, that=E2=
=80=99s extra
                                  complexity on the client that I really
                                  don=E2=80=99t think we want to be univers=
al. A
                                  flag to turn that kind of direction
                                  and splitting on would be a potential
                                  start. But there are potential snags
                                  here too, and it comes down to how you
                                  manage the defaults...

                                

                                

                                  

                                    

                                      
> This is just
                                        the start, too. Things get even
                                        more complex if the client can
                                        ask for multiple different kinds
                                        of resources at once. What if
                                        the AS decides that the client
                                        needs a hyper-focused directed
                                        token for one part of the API,
                                        but can use a general token for
                                        other stuff? Can it signal that
                                        to the client? And if it can,
                                        does that mean that all clients
                                        need to be prepared for that
                                        kind of thing?

                                      


                                      

                                      
Would a potential
                                        default be that if a client did
                                        for any reason not support
                                        processing the additional
                                        information returned with the
                                        access_token, just to ignore it?
                                        I think in the spirit of keeping
                                        the simple things simple, this
                                        potentially makes sense?

                                    

                                  

                                

                                


                                

                                
That=E2=80=99s the real trick, if
                                  you ask me. It has to be :safe: for a
                                  client to ignore this information.
                                  Which means the AS can=E2=80=99t rely on =
the
                                  client =E2=80=9Cdoing the right thing=E2=
=80=9D with
                                  the information in the =E2=80=9Ctoken
                                  directions=E2=80=9D portion of the respon=
se.
                                  Even setting aside the advanced and
                                  related =E2=80=9Csplit tokens=E2=80=9D id=
ea above, we
                                  need to make sure that an AS/RS setup
                                  is built such that if the AS tells a
                                  client =E2=80=9Conly do X with your token=
=E2=80=9D and
                                  the client does =E2=80=9CY=E2=80=9D, then=
 there are
                                  other protections and practices in
                                  place to prevent things from going
                                  haywire if the client does =E2=80=9CY=E2=
=80=9D either
                                  by accident or through ignorance.=C2=A0
                                


                                

                                
If OAuth 2 has taught us
                                  anything, it=E2=80=99s that client
                                  applications are going to be the
                                  laziest participants in the security
                                  model. And that makes sense, really =E2=
=80=94
                                  security isn=E2=80=99t what the client ap=
ps
                                  are trying to do, they=E2=80=99re trying =
to
                                  use the RS to do something. So we need
                                  to make sure that whatever system we
                                  design will fail on the safe side as
                                  much as possible, and keep things
                                  simple for the client.

                                

                                

                                  

                                    

                                      


                                      

                                      
> here are some
                                        worked out samples of this:

                                      
                                      
                                      

                                        

                                          

                                            
Peace ..tom

                                            


                                            

                                            
As one of the
                                              authors of those mentioned
                                              drafts, I am interested in
                                              discussing that, but
                                              perhaps on a seperate
                                              thread? As at least=C2=A0the
                                              bound assertion spec
                                              is=C2=A0primarily=C2=A0concer=
ned
                                              with binding mechanisms
                                              for the artifacts produced
                                              from an authorization flow
                                              (specifically identity
                                              claims), whereas I think
                                              directed access tokens is
                                              just more generally
                                              talking about whether GNAP
                                              should support an AS
                                              conveying how to use an
                                              access_token it produces
                                              during a flow with a
                                              client.

                                          

                                        

                                      

                                      


                                      

                                    

                                  

                                

                                


                                

                                
I think that these are
                                  separate issues as well.

                                


                                

                                
=C2=A0=E2=80=94 Justin

                                

                                

                                  

                                    

                                      

                                        

                                          

                                            
Thanks,

                                              

                                                
                                                  

                                                    3D"Mattr
                                                    =C2=A0=

                                                    
                                                      

                                                        
                                                          

                                                          Tobias Looker

                                                          		
                                                          

                                                          

                                                          Mattr
                                                          

                                                          

                                                          +64
                                                          (0) 27 378
                                                          0461

                                                          tobias.looker@mattr.global		
                                                          

                                                          

                                                          
                                                          

                                                          
                                                          

                                                          =
3D"Mattr
                                                          =
3D"Mattr
                                                          =
3D"Mattr
                                                          =
3D"Mattr
                                                          

                                                          
                                                          

                                                          		
                                                          

                                                        
                                                      

                                                    		
                                                  

                                                
                                              

                                              

                                              This
                                                communication, including
                                                any attachments, is
                                                confidential. If you are
                                                not the intended
                                                recipient, you should
                                                not read it - please
                                                contact me immediately,
                                                destroy it, and do not
                                                copy or use any part of
                                                this communication or
                                                disclose anything about
                                                it. Thank you. Please
                                                note that this
                                                communication does not
                                                designate an information
                                                system for the purposes
                                                of the Electronic
                                                Transactions Act 2002.

                                            

                                          

                                        

                                        

                                      

                                    

                                    

                                    

                                      
On
                                        Wed, Jun 24, 2020 at 10:14 PM
                                        Denis <denis.ietf@free.fr>
                                        wrote:

                                      

                                      

                                        

                                          
Justin, I fear
                                            we are still far away from
                                            an agreement about what this
                                            BoF should do.

                                          


                                          

                                          
Tom Jones is
                                            saying " I am getting tire=
d
                                            of the whack-a-mole approach
                                            ...."

                                          


                                          

                                          I don't agree with you when
                                          you write: "I think it=E2=80=
=99s going
                                          to be overwhelmingly common
                                          that a given RS is going to
                                          trust exactly one AS=C2=A0<=
/span>

                                          
that it knows
                                            about ahead of time". Such
                                            an architecture would have
                                            exactly the same limitations
                                            as OAuth 2.0. and would not
                                            be scalable.

                                          


                                          

                                          

                                            
Before we
                                              start, we should have a
                                              clear view of the whole
                                              picture rather than
                                              starting from one scenario
                                              and expanding it in many
                                              different directions.

                                            
For building
                                              an architecture, a
                                              pre-requirement is to
                                              define ALL the trust
                                              relationships. I don't
                                              believe that we have an
                                              agreement at this time on
                                              what=C2=A0

                                              these trust relationships
                                              are.=C2=A0

                                          

                                          


                                          

                                          
You are also
                                            using the following wording:
                                            "methods for the AS and RS
                                            to communicate what the
                                            token=E2=80=99s good for".=
=C2=A0

                                            With such a paradigm, it
                                            would be impossible to
                                            protect the user's privacy.=
=C2=A0

                                          

                                          


                                          

                                          
A key question
                                            is : Will GNAP take care of
                                            the user's privacy or will
                                            GNAP=C2=A0preve=
nt=C2=A0to
                                            take care of the user's
                                            privacy ?

                                          


                                          

                                          
About "the
                                            ability for the client to
                                            get several access tokens to
                                            get different resources from
                                            one request" is indeed a
                                            complex case.

                                          


                                          

                                          
No one
                                            (including ASs) is able to
                                            predict in advance which
                                            access tokens will be
                                            needed, since they depend
                                            upon the kind of
                                            operation(s)=C2=A0=


                                            the client will be willing
                                            to perform. For privacy
                                            reasons, ASs should be kept
                                            ignorant of all the
                                            operations that a client is
                                            going to perform=C2=A0

                                            on one or more resource
                                            servers. I believe that
                                            every effort should be made
                                            to avoid the AS to be in a
                                            position to be able to trace
                                            the operations=C2=A0

                                            performed by its clients on
                                            various RSs.

                                          


                                          

                                          
To handle the
                                            complex case you envision,
                                            the full workflow of
                                            operations needs to be
                                            considered with a detailed
                                            focus on the time=C2=A0

                                            at which the user's=
=C2=A0consent and
                                              choice=C2=A0=
happens
                                            (consent and
                                              choice=C2=A0=
is
                                            the first privacy principle
                                            from ISO 29100).

                                          


                                          

                                          
First of all, an
                                            access token could be
                                            targeted to a service rather
                                            than to a server. This would
                                            already solve many cases.

                                          


                                          

                                          
When a RS needs
                                            to call another RS (which
                                            does not support the same
                                            service) then the client
                                            should be informed by the
                                            first RS.

                                          
His "consent and
                                            choice" should then be
                                            obtained by the first RS
                                            and, when the user agrees,
                                            the client should then ask
                                            an access token=C2=A0

                                            to one of the ASs trusted by
                                            the second RS in order to
                                            perform the subsequent
                                            operation.=C2=A0=C2=A0

                                          

                                          


                                          

                                          
Denis

                                          


                                          

                                          
PS.=C2=A0 In an email
                                            sent on June 23 you wrote: &quo=
t;
                                            I think an on-device AS is
                                            an important use case".=C2=
=A0 I
                                            am sorry, but I don't
                                            understand.

                                            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 However, I do
                                            understand what "a
                                            server-based AS" is.

                                          

                                          


                                          

                                          


                                          

                                          
Denis, =
thanks for
                                            the great comments. I think
                                            that your trust model is
                                            pretty different from what
                                            I=E2=80=99d laid out initially,=
 and
                                            while it=E2=80=99s an interesti=
ng
                                            and important one, it is not
                                            what I meant by =E2=80=9Cmultip=
le
                                            access tokens=E2=80=9D in my
                                            discussion below. I think
                                            that might be the cause of
                                            some disconnect here, but
                                            that doesn=E2=80=99t mean it=E2=
=80=99s out
                                            of reach for what the WG is
                                            after.
                                            


                                            

                                            
When I refer
                                              to multiple access tokens,
                                              and what the charter calls
                                              out as multiple access
                                              tokens, is the ability for
                                              the client to get several
                                              access tokens to get
                                              different resources from
                                              one request. I personally
                                              see this as an
                                              optimization of a specific
                                              set of use cases, some of
                                              which I discussed in my
                                              original email. There are
                                              others, I=E2=80=99m sure, but=
 all
                                              the ones I=E2=80=99ve seen ar=
e
                                              around the client needing
                                              to get several different
                                              kinds of access through an
                                              AS.=C2=A0

                                              


                                              

                                              
I think it=E2=80=99s
                                                going to be
                                                overwhelmingly common
                                                that a given RS is going
                                                to trust exactly one AS
                                                that it knows about
                                                ahead of time. But for
                                                RS=E2=80=99s that can trust
                                                multiple AS=E2=80=99s, then=
 we
                                                should have a model that
                                                can accommodate that as
                                                well. That=E2=80=99s why th=
e
                                                charter calls out
                                                methods for the AS and
                                                RS to communicate what
                                                the token=E2=80=99s good fo=
r. I
                                                think the basis of those
                                                methods is going to
                                                start with a common
                                                token model, and likely
                                                incorporate into things
                                                like token formats and
                                                introspection-style
                                                token APIs.=C2=A0

                                              


                                              

                                              
=C2=A0=E2=80=94 Justin
                                                


                                                  

                                                    
On Jun
                                                      22, 2020, at 3:55
                                                      AM, Denis <denis.ietf@free.fr>
                                                      wrote:

                                                    

                                                    

                                                      
=
Hello
                                                        Justin,

                                                      
=


                                                      

                                                      
=
A few
                                                        comments between
                                                        the lines.

                                                      
=


                                                      

                                                      
One of
                                                        the most
                                                        important
                                                        aspects to GNAP
                                                        is going to be
                                                        an ability to
                                                        address things
                                                        that OAuth 2
                                                        can=E2=80=99t, or a=
t
                                                        least can=E2=80=99t=
 do
                                                        without
                                                        significant
                                                        gymnastics. So
                                                        with that, I
                                                        wanted to bring
                                                        back a use case
                                                        discussion that
                                                        originally came
                                                        up while we were
                                                        talking about
                                                        the possibility
                                                        of multiple
                                                        access tokens, a
                                                        few months back.
                                                        I don=E2=80=99t kno=
w if
                                                        this concept has
                                                        a regular term,
                                                        so I=E2=80=99m goin=
g to
                                                        call it
                                                        =E2=80=9Cdirected a=
ccess
                                                        tokens=E2=80=9D unt=
il we
                                                        come up with
                                                        something better
                                                        =E2=80=94 assuming =
we
                                                        decide this is
                                                        worthwhile.=
=C2=A0

                                                      

                                                      
I =
don't
                                                        understand what
                                                        may mean
                                                        "directed acce=
ss
                                                        tokens=E2=80=9D but=
 I
                                                        understand what
                                                        means "multipl=
e
                                                        access tokens"=
.=C2=A0

                                                        When speaking of
                                                        "multiple acce=
ss
                                                        tokens", these
                                                        access tokens
                                                        may come from
                                                        one or more ASs.
                                                      

                                                      

                                                        
In
                                                          OAuth, the
                                                          client=E2=80=99s
                                                          supposed to
                                                          always know
                                                          where to send
                                                          its access
                                                          token, and
                                                          that knowledge
                                                          is completely
                                                          outside the
                                                          protocol. This
                                                          makes a lot of
                                                          sense for many
                                                          (if not most)
                                                          deployments,
                                                          as OAuth is
                                                          really there
                                                          to enable the
                                                          API access
                                                          that the
                                                          client already
                                                          knows about.
                                                        


                                                        

                                                        
But
                                                          we=E2=80=99re now=
 in a
                                                          world where a
                                                          client could
                                                          be talking to
                                                          a generic API
                                                          that could be
                                                          deployed at a
                                                          number of
                                                          different
                                                          places, or a
                                                          cloud
                                                          deployment
                                                          that the AS
                                                          wants to be
                                                          able to
                                                          dispatch the
                                                          client to.=
=C2=A0

                                                      

                                                      
As=
 soon
                                                        the AS is placed
                                                        (again) at the
                                                        centre of the
                                                        model, the AS
                                                        will have the
                                                        ability to act
                                                        as "Big
                                                        Brother".

                                                        OAuth 2.0 has
                                                        not taken care
                                                        of privacy
                                                        issues. On the
                                                        contrary, GNAP
                                                        should take care
                                                        of them.

                                                      

                                                        
In
                                                          order to do
                                                          this, the AS
                                                          needs to be
                                                          able to
                                                          communicate to
                                                          the client not
                                                          only the token
                                                          information
                                                          (and any
                                                          related key
                                                          and
                                                          presentation
                                                          information),
                                                          but also a set
                                                          of=C2=A0directions=C2=A0about
                                                          what that
                                                          specific token
                                                          is good for.
                                                          This needs to
                                                          be information
                                                          outside the
                                                          token itself,
                                                          since
                                                          I=C2=A0believe we
                                                          want to keep
                                                          OAuth 2=E2=80=99s
                                                          feature of
                                                          having the
                                                          token be
                                                          opaque to the
                                                          client. Note:
                                                          while we could
                                                          map all of
                                                          these to
                                                          different
                                                          resource
                                                          requests (in
                                                          XYZ parlance)
                                                          or scopes (in
                                                          OAuth 2 legacy
                                                          parlance) on
                                                          the request
                                                          side, this
                                                          isn=E2=80=99t eno=
ugh
                                                          to tell the
                                                          client what to
                                                          do with the
                                                          token=C2=A0=
if it
                                                          doesn=E2=80=99t k=
now
                                                          already.=C2=
=A0

                                                        


                                                        

                                                        
I
                                                          know of two
                                                          use cases
                                                          already in the
                                                          wild, where
                                                          people are
                                                          addressing
                                                          things using a
                                                          mix of
                                                          existing
                                                          standards and
                                                          some
                                                          proprietary
                                                          extensions to
                                                          address things
                                                          within their
                                                          silos. I=E2=80=99=
ll
                                                          try to
                                                          summarize
                                                          here, but I
                                                          know the folks
                                                          I=E2=80=99ve been
                                                          talking to
                                                          about this are
                                                          also on the
                                                          list so
                                                          hopefully they
                                                          can chime in
                                                          with more
                                                          detail or any
                                                          corrections
                                                          for something
                                                          I=E2=80=99ve miss=
ed.=C2=A0

                                                        


                                                        

                                                        
(1)
                                                          The client
                                                          knows what
                                                          resource it=E2=80=
=99s
                                                          calling, but
                                                          it doesn=E2=80=99=
t
                                                          know where
                                                          it=E2=80=99s host=
ed.
                                                          Everything is
                                                          in a single
                                                          security
                                                          domain
                                                          controlled by
                                                          the AS,=C2=
=A0

                                                      

                                                      
Sp=
eaking
                                                        of "multiple
                                                        access tokens"
                                                        is in
                                                        contradiction
                                                        with single
                                                        security domain
                                                        "controlled&qu=
ot; by
                                                        an AS.=C2=A0<=
/span>

                                                        A user may need
                                                        to demonstrate
                                                        some of his
                                                        identity
                                                        attributes
                                                        granted e.g. by
                                                        his bank but may
                                                        also=C2=A0

                                                        need to
                                                        demonstrate one
                                                        or more diplomas
                                                        granted by one
                                                        or more
                                                        universities.
                                                        The bank cannot
                                                        be=C2=A0

                                                        the "primary
                                                        issuer" of a
                                                        university
                                                        diploma. It
                                                        should not be
                                                        either a
                                                        "secondary
                                                        issuer", becau=
se=C2=A0

                                                        the bank does
                                                        not "need
                                                          to know"=
=C2=A0what
                                                        are the diplomas
                                                        of the user.

                                                      

                                                      

                                                        
but
                                                          the AS needs
                                                          to decide at
                                                          runtime which
                                                          specific
                                                          instance of
                                                          the API to
                                                          direct the
                                                          client to.
                                                          Since things
                                                          are closely
                                                          tied together,
                                                          the client
                                                          just needs to
                                                          effectively
                                                          known an
                                                          identifier for
                                                          the RS, and
                                                          this is
                                                          currently
                                                          implemented as
                                                          a URI. Once
                                                          the client has
                                                          that
                                                          identifier, it
                                                          knows how to
                                                          dispatch that
                                                          token to that
                                                          instance of
                                                          the RS.

                                                      

                                                      
Th=
ere
                                                        is no good
                                                        reason why the
                                                        AS should be
                                                        involved in that
                                                        step.=C2=A0

                                                        OAuth 2.0 is/was
                                                        implicitly
                                                        mandating a
                                                        strong
                                                        relationship
                                                        between ASs and
                                                        RSs which makes
                                                        it non scalable.
                                                        GNAP should be
                                                        based on a
                                                        simple trust
                                                        relationship : a
                                                        given RS trusts
                                                        some ASs for
                                                        access tokens
                                                        that contains
                                                        some types of
                                                        attributes.

                                                        An AS should not
                                                        need to know in
                                                        advance (or even
                                                        at the time of
                                                        an access token
                                                        request) the RSs
                                                        that are
                                                        trusting it.

                                                      

                                                      
A
                                                        client could
                                                        first talk to a
                                                        "global servic=
e
                                                        provider" whic=
h
                                                        has the
                                                        knowledge of the
                                                        different RSs
                                                        affiliated to
                                                        it.=C2=A0

                                                      

                                                      

                                                        
(2)
                                                          The client
                                                          knows what
                                                          kind of thing
                                                          it=E2=80=99s look=
ing
                                                          for, but
                                                          doesn=E2=80=99t k=
now
                                                          who to ask it
                                                          from.=C2=A0=


                                                      

                                                      
On=
ce
                                                        again, the
                                                        client could
                                                        first talk to a
                                                        "global servic=
e
                                                        provider" whic=
h
                                                        has the
                                                        knowledge of the
                                                        different RSs
                                                        affiliated to
                                                        it.=C2=A0

                                                      

                                                        
There=E2=80=99=
s
                                                          a cross-domain
                                                          trust that=E2=80=
=99s
                                                          bridged by the
                                                          AS, and the AS
                                                          needs to
                                                          dispatch to
                                                          different
                                                          resources
                                                          depending on
                                                          which user
                                                          logged in (and
                                                          possibly what
                                                          the user
                                                          consented to).
                                                          To make things
                                                          more concrete,
                                                          the client
                                                          needs to get
                                                          driver=E2=80=99s
                                                          license
                                                          information,
                                                          but doesn=E2=80=
=99t
                                                          know ahead of
                                                          time which of
                                                          the many
                                                          state/provincial
                                                          bureaus to
                                                          call to get
                                                          that
                                                          information
                                                          because it
                                                          doesn=E2=80=99t k=
now
                                                          yet who the
                                                          user is.=C2=
=A0

                                                      

                                                      
Wh=
en a
                                                        user has a
                                                        driving license,
                                                        he knows its
                                                        issuer. The user
                                                        can then provide
                                                        some hint to the
                                                        client.

                                                      

                                                        
The
                                                          AS will know
                                                          who the user
                                                          is once they
                                                          log in and
                                                          approve
                                                          things, and so
                                                          it can direct
                                                          the client to
                                                          call the
                                                          correct RS.
                                                          Since this is
                                                          a relatively
                                                          simple API
                                                          with a
                                                          pre-negotiated
                                                          cross-domain
                                                          trust, the AS
                                                          returns a URL
                                                          that the
                                                          client
                                                          presents the
                                                          token at.=
=C2=A0

                                                        

                                                      

                                                      
=
=C2=A0A
                                                        single AS should
                                                        not be aware of
                                                        all the
                                                        attributes a
                                                        user has.=C2=
=A0

                                                      

                                                      

                                                        


                                                        

                                                        
As
                                                          far as I know,
                                                          in both of
                                                          these cases,
                                                          the token is
                                                          only good for
                                                          that API and
                                                          not others =E2=80=
=94
                                                          but more on
                                                          that later.

                                                        


                                                        

                                                        
A
                                                          simple thing
                                                          to do is just
                                                          give back a
                                                          URL with the
                                                          access token,
                                                          which tells
                                                          the client
                                                          where to go.=C2=
=A0

                                                        


                                                        

                                                        
	{

                                                        
		=E2=80=9Caccess_token=E2=80=9D:
                                                          {

                                                        
			=E2=80=9Cvalue=E2=80=9D:
=E2=80=9C87yui843yfer=E2=80=9D,

                                                        
			=E2=80=9Cresource_uri=E2=80=9D:
                                                          =E2=80=9Chttps://example/foo"
                                                        
		}

                                                        
	}

                                                        


                                                        

                                                        
This
                                                          is good for
                                                          some kinds of
                                                          APIs, but it=E2=
=80=99s
                                                          limiting
                                                          because not
                                                          all APIs
                                                          dispatch based
                                                          on the URL. An
                                                          AS might want
                                                          to divvy up
                                                          access tokens
                                                          to an API
                                                          that=E2=80=99s ke=
yed
                                                          on headers, or
                                                          verbs, or any
                                                          number of
                                                          things. And it
                                                          doesn=E2=80=99t t=
ell
                                                          us immediately
                                                          what to do
                                                          about
                                                          non-exact URL
                                                          matches. Can
                                                          the client add
                                                          query
                                                          parameters and
                                                          still use the
                                                          token? What
                                                          about path
                                                          segments? I
                                                          like that this
                                                          simple
                                                          approach
                                                          addresses some
                                                          common
                                                          deployments
                                                          that we
                                                          already see
                                                          today (see
                                                          above), it=E2=80=
=99s
                                                          not universal.
                                                          Do we want or
                                                          need a
                                                          universal
                                                          description
                                                          language for
                                                          directing
                                                          where tokens
                                                          go?

                                                        


                                                        

                                                        
This
                                                          also opens up
                                                          a whole new
                                                          set of
                                                          security
                                                          questions. If
                                                          the AS can now
                                                          direct the
                                                          client where
                                                          to use the
                                                          token, could a
                                                          rogue AS
                                                          convince a
                                                          legit client
                                                          to use a
                                                          stolen token
                                                          at the wrong
                                                          RS? And what
                                                          if the client
                                                          ignores the
                                                          directions
                                                          from the AS
                                                          entirely?
                                                          Could this
                                                          open up new
                                                          avenues of
                                                          attack?

                                                        


                                                        

                                                        
This
                                                          is just the
                                                          start, too.
                                                          Things get
                                                          even more
                                                          complex if the
                                                          client can ask
                                                          for multiple
                                                          different
                                                          kinds of
                                                          resources at
                                                          once. What if
                                                          the AS decides
                                                          that the
                                                          client needs a
                                                          hyper-focused
                                                          directed token
                                                          for one part
                                                          of the API,
                                                          but can use a
                                                          general token
                                                          for other
                                                          stuff? Can it
                                                          signal that to
                                                          the client?
                                                          And if it can,
                                                          does that mean
                                                          that all
                                                          clients need
                                                          to be prepared
                                                          for that kind
                                                          of thing?

                                                        


                                                        

                                                        
I
                                                          firmly believe
                                                          that whatever
                                                          we build in
                                                          GNAP, we need
                                                          to optimize
                                                          for the
                                                          overwhelmingly
                                                          common use
                                                          case of a
                                                          client getting
                                                          a single
                                                          access token
                                                          to call APIs
                                                          that it
                                                          already knows
                                                          about.
                                                          Anything we
                                                          add on top of
                                                          that really
                                                          can=E2=80=99t get=
 in
                                                          the way of
                                                          this, because
                                                          if it does,
                                                          there=E2=80=99s v=
ery
                                                          small chance
                                                          that people
                                                          will try to
                                                          use this for
                                                          everyday
                                                          things. Keep
                                                          the simple
                                                          things simple,
                                                          and the
                                                          complex things
                                                          possible,
                                                          after all.

                                                        


                                                        

                                                        
I=E2=80=99m
                                                          really looking
                                                          forward to
                                                          hearing what
                                                          the community
                                                          thinks about
                                                          these use
                                                          cases, and
                                                          hopefully the
                                                          people I=E2=80=99=
ve
                                                          chatted with
                                                          offline about
                                                          this can join
                                                          the
                                                          conversation
                                                          and provide
                                                          more light
                                                          than I was
                                                          able to.

                                                      

                                                      
Th=
e two
                                                        use cases which
                                                        are considered
                                                        above are:

                                                      

                                                        
(1)
                                                          The client
                                                          knows what
                                                          resource it=E2=80=
=99s
                                                          calling, but
                                                          it doesn=E2=80=99=
t
                                                          know where
                                                          it=E2=80=99s host=
ed.

                                                          (2) The client
                                                          knows what
                                                          kind of thing
                                                          it=E2=80=99s look=
ing
                                                          for, but
                                                          doesn=E2=80=99t k=
now
                                                          who to ask it
                                                          from.=C2=A0=


                                                        

                                                      

                                                      
Th=
at
                                                        does not mean in
                                                        any way that
                                                        these two use
                                                        cases should be
                                                        solved by
                                                        placing the AS
                                                        at the centre of
                                                        the solution.

                                                      
De=
nis

                                                      

                                                        


                                                        

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

                                                        

                                                        

                                                      

                                                      

                                                      

                                                      --=C2=A0

                                                      Txauth
                                                        mailing list=


                                                      Txauth@ietf.org

                                                      https://www.ietf.org/mailm=
an/listinfo/txauth

                                                  

                                                

                                                

                                              

                                            

                                          

                                          


                                          

                                        

                                        --=C2=A0

                                        Txauth mailing list

                                        Txauth@ietf.org

                                        https://www.ietf=
.org/mailman/listinfo/txauth

                                      

                                    

                                    

                                    
=
This communication, including any attachments, is confidential. If you are =
not the intended recipient, you should not read it - please contact me imme=
diately, destroy it, and do not copy or use any part of this communication =
or disclose anything about it. Thank you. Please note that this communicati=
on does not designate an information system for the purposes of the Electro=
nic Transactions Act 2002.

                                  

                                

                              

                              

                              --=C2=A0

                              Txauth mailing list

                              Txauth@ietf.org

                              https://www.ietf.org/mailman/listinfo/txauth
                          

                        

                        

                      

                    

                  

                

              

              

              
This communication, in=
cluding any attachments, is confidential. If you are not the intended recip=
ient, you should not read it - please contact me immediately, destroy it, a=
nd do not copy or use any part of this communication or disclose anything a=
bout it. Thank you. Please note that this communication does not designate =
an information system for the purposes of the Electronic Transactions Act 2=
002.

            

          

        

        

      

      

      

    

    


    

  


-- 

Txauth mailing list

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




--0000000000005dc1a805a9f1e5ee--


From nobody Wed Jul  8 11:04: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 2FCC23A0542 for ; Wed,  8 Jul 2020 11:04:09 -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_REMOTE_IMAGE=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 FPJNatT1bli7 for ; Wed,  8 Jul 2020 11:04:05 -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 8F2DF3A07B7 for ; Wed,  8 Jul 2020 11:04:04 -0700 (PDT)
Received: by mail-ot1-x330.google.com with SMTP id e90so7057674ote.1 for ; Wed, 08 Jul 2020 11:04: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=OdhZAtPlHTnt5so7lMNevWjjtmpbpocm5XOLlOGWUNc=; b=HVPiPPu7y11XQb2F1z+QirIeQZzMSONGZmEvbwU9ss1UeE2sNqlTtVt8VDLN9uesEE TQrcRy/NDI1+QAHOwpRjNl0W8xdqm1vJudEXeztSxln1Kt6A4VpZXwav6ayhnUSZi0Mi D/JwkNsOMUKKXGm0t7DIUwqWoh6+XFj2GijcMB1rCknCTtmHEGcOmsdWJZeqKHIcL/hk Im3+isRpR9QybC8Ehlkzair8S0lb2vw1prcvFI50a7njh7AkTrX4PjSBMFOS6nUHzNqo NFLwI/zCyjSimjTomkU9d6BOcs+cFPdAHXaBM4WQmhUnSlFsINt5k96dbQA4j58ck6LF 9Q6g==
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=OdhZAtPlHTnt5so7lMNevWjjtmpbpocm5XOLlOGWUNc=; b=eIYMsFFJxaLk+0pDRZNkTlVmWkAmFIyf9ZpmYXn3GgShduZbTsqLyOsFiW0rFkPLCL x7yYXbgJe344IAqvV+PVSi/FB3ppRKl68kskYbQ9TTZX5mAf//WhyIcE5jQ+sETOBY+/ j/Qs1vryNxDH7hJCKQIcM8scnN805+GVxLIF/3fcVBIpU5mUlgew5s0vO8qcA1OS6IFu jphnbLXikNGfD4CSPADgB/nKwTOWSxEinPj0arTgcDqk7ee7ckVXBcDlXvcwrrakg6BA YSagtwaKH0yLjwuktEVjFZQt1HfECOe2xvUxwcVDCatpqaSc7CZY/aWALliKa3zcwo07 +qcA==
X-Gm-Message-State: AOAM531QIw9wLF4vDopEY9Oi25lcBmoNfFbf4RUP5nLS3VqttmW1UGZI zfbsq5Q/YedRqZ3O/3W6PSglntuMj0wL8jabqM8=
X-Google-Smtp-Source: ABdhPJz4+zsSSXU45T/g3zg66RzMSYj9Hl9UyUxImYnjIfaIdqU3sjgWRFN53baTZWq3rME/xZNNwSxfsd5zj0RshlE=
X-Received: by 2002:a9d:23b7:: with SMTP id t52mr38252265otb.87.1594231442381;  Wed, 08 Jul 2020 11:04:02 -0700 (PDT)
MIME-Version: 1.0
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <6846D2F0-5096-404B-A529-676146392F45@mit.edu>
In-Reply-To: <6846D2F0-5096-404B-A529-676146392F45@mit.edu>
From: Tom Jones 
Date: Wed, 8 Jul 2020 11:03:50 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org, Tobias Looker 
Content-Type: multipart/alternative; boundary="000000000000d0217d05a9f1eef4"
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 08 Jul 2020 18:04:09 -0000

--000000000000d0217d05a9f1eef4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I disagree with any approach that would allow the client/RP to
delegate anything that it does not own. The RP either has that
authority from the RO or AS, or not. Modifying the authority in any way
should not be permitted. New RO auth would be required.
OTOH any endpoint could be granted agency by the RO. That should not be
conflated with an AZ token. If agency is provided by a AZ token it is
unclear that it meets any of the various regulations.  Note that this
comment does not apply to :"data processors" that are disclosed to the RO.
Peace ..tom


On Tue, Jul 7, 2020 at 1:39 PM Justin Richer  wrote:

> I=E2=80=99ve been thinking more about these use cases, and it might help =
us to
> think of GNAP=E2=80=99s access tokens as capabilities in the computer sec=
urity
> sense =E2=80=94 but more specifically, capabilities that are delivered wi=
th their
> own context for use. In that way, an otherwise naive client can be handed
> an access token and simply know exactly what to do with it. This context
> would be delivered alongside the token, so the token material itself
> remains opaque to the client.
>
> I wanted to bring up a W3C spec for a capabilities model based on linked
> data:
>
> https://w3c-ccg.github.io/zcap-ld/
>
> Building a fully featured capabilities context is difficult, at the very
> least. And unfortunately, I don=E2=80=99t think this spec actually gives =
us any
> viable solutions to work with. In particular the =E2=80=9Cactions=E2=80=
=9D section is
> effectively blank, offloading the work to an external JSONLD process (sid=
e
> note, this is one of the problems I have with specs based on JSONLD, they
> externalize the important parts into local contexts and break
> interoperability =E2=80=94 but I digress). But at least it=E2=80=99s anot=
her way of looking
> at the problem space that might be outside the familiar zone of many of t=
he
> OAuth world.
>
>  =E2=80=94 Justin
>
> On Jun 26, 2020, at 9:23 AM, Justin Richer  wrote:
>
> On Jun 25, 2020, at 9:07 PM, Tobias Looker 
> wrote:
>
>
> I find this feature interesting and think it could be an important patter=
n
> going forward to enable an AS to be able to describe the utility of a tok=
en
> to the client, however as already pointed out in the thread I think there
> is some potential hidden complexity that would need to be ironed out such
> that it does not make the simple things complicated.
>
> Justin, do you see this feature as something the client has to explicitly
> request, i.e "please give me access and instructions on how to use my
> access" or rather that the AS would just return this information in
> conjunction with the access token if it had it available?
>
>
> This is something that I=E2=80=99d brought up as a possibility on the pre=
vious
> thread =E2=80=94 something like a flag the client would set. This would b=
e
> especially important if the AS wants to return multiple access tokens but
> the client requested 1, or the client requested N and the AS wants to
> return M in response. Basically any time there=E2=80=99s a mismatch, that=
=E2=80=99s extra
> complexity on the client that I really don=E2=80=99t think we want to be =
universal.
> A flag to turn that kind of direction and splitting on would be a potenti=
al
> start. But there are potential snags here too, and it comes down to how y=
ou
> manage the defaults...
>
> > This is just the start, too. Things get even more complex if the client
> can ask for multiple different kinds of resources at once. What if the AS
> decides that the client needs a hyper-focused directed token for one part
> of the API, but can use a general token for other stuff? Can it signal th=
at
> to the client? And if it can, does that mean that all clients need to be
> prepared for that kind of thing?
>
> Would a potential default be that if a client did for any reason not
> support processing the additional information returned with the
> access_token, just to ignore it? I think in the spirit of keeping the
> simple things simple, this potentially makes sense?
>
>
> That=E2=80=99s the real trick, if you ask me. It has to be :safe: for a c=
lient to
> ignore this information. Which means the AS can=E2=80=99t rely on the cli=
ent =E2=80=9Cdoing
> the right thing=E2=80=9D with the information in the =E2=80=9Ctoken direc=
tions=E2=80=9D portion of
> the response. Even setting aside the advanced and related =E2=80=9Csplit =
tokens=E2=80=9D
> idea above, we need to make sure that an AS/RS setup is built such that i=
f
> the AS tells a client =E2=80=9Conly do X with your token=E2=80=9D and the=
 client does =E2=80=9CY=E2=80=9D,
> then there are other protections and practices in place to prevent things
> from going haywire if the client does =E2=80=9CY=E2=80=9D either by accid=
ent or through
> ignorance.
>
> If OAuth 2 has taught us anything, it=E2=80=99s that client applications =
are going
> to be the laziest participants in the security model. And that makes sens=
e,
> really =E2=80=94 security isn=E2=80=99t what the client apps are trying t=
o do, they=E2=80=99re
> trying to use the RS to do something. So we need to make sure that whatev=
er
> system we design will fail on the safe side as much as possible, and keep
> things simple for the client.
>
>
> > here are some worked out samples of this:
> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
> Peace ..tom
>
> As one of the authors of those mentioned drafts, I am interested in
> discussing that, but perhaps on a seperate thread? As at least the bound
> assertion spec is primarily concerned with binding mechanisms for the
> artifacts produced from an authorization flow (specifically identity
> claims), whereas I think directed access tokens is just more generally
> talking about whether GNAP should support an AS conveying how to use an
> access_token it produces during a flow with a client.
>
>
> I think that these are separate issues as well.
>
>  =E2=80=94 Justin
>
> Thanks,
> [image: Mattr website] 
> *Tobias Looker*
> Mattr
> +64 (0) 27 378 0461
> tobias.looker@mattr.global
> [image: Mattr website]  [image: Mattr on LinkedIn]
>  [image: Mattr on Twitter]
>  [image: Mattr on Github]
> 
> This communication, including any attachments, is confidential. If you ar=
e
> not the intended recipient, you should not read it - please contact me
> immediately, destroy it, and do not copy or use any part of this
> communication or disclose anything about it. Thank you. Please note that
> this communication does not designate an information system for the
> purposes of the Electronic Transactions Act 2002.
>
>
> On Wed, Jun 24, 2020 at 10:14 PM Denis  wrote:
>
>> Justin, I fear we are still far away from an agreement about what this
>> BoF should do.
>>
>> Tom Jones is saying " I am getting tired of the whack-a-mole approach ..=
."
>>
>> I don't agree with you when you write: "I think it=E2=80=99s going to be
>> overwhelmingly common that a given RS is going to trust exactly one AS
>> that it knows about ahead of time". Such an architecture would have
>> exactly the same limitations as OAuth 2.0. and would not be scalable.
>>
>> Before we start, we should have a clear view of the whole picture rather
>> than starting from one scenario and expanding it in many different
>> directions.
>> For building an architecture, a pre-requirement is to define ALL the
>> trust relationships. I don't believe that we have an agreement at this t=
ime
>> on what
>> these trust relationships are.
>>
>> You are also using the following wording: "methods for the AS and RS to
>> communicate what the token=E2=80=99s good for".
>> With such a paradigm, it would be impossible to protect the user's
>> privacy.
>>
>> A key question is : Will GNAP take care of the user's privacy or will GN=
AP
>>  *prevent *to take care of the user's privacy ?
>>
>> About "the ability for the client to get several access tokens to get
>> different resources from one request" is indeed a complex case.
>>
>> No one (including ASs) is able to predict in advance which access tokens
>> will be needed, since they depend upon the kind of operation(s)
>> the client will be willing to perform. For privacy reasons, ASs should b=
e
>> kept ignorant of all the operations that a client is going to perform
>> on one or more resource servers. I believe that every effort should be
>> made to avoid the AS to be in a position to be able to trace the operati=
ons
>>
>> performed by its clients on various RSs.
>>
>> To handle the complex case you envision, the full workflow of operations
>> needs to be considered with a detailed focus on the time
>> at which the user's *consent and choice* happens (*consent and choice* i=
s
>> the first privacy principle from ISO 29100).
>>
>> First of all, an access token could be targeted to a service rather than
>> to a server. This would already solve many cases.
>>
>> When a RS needs to call another RS (which does not support the same
>> service) then the client should be informed by the first RS.
>> His "consent and choice" should then be obtained by the first RS and,
>> when the user agrees, the client should then ask an access token
>> to one of the ASs trusted by the second RS in order to perform the
>> subsequent operation.
>>
>> Denis
>>
>> PS.  In an email sent on June 23 you wrote: " I think an on-device AS is
>> an important use case".  I am sorry, but I don't understand.
>>        However, I do understand what "a server-based AS" is.
>>
>>
>> Denis, thanks for the great comments. I think that your trust model is
>> pretty different from what I=E2=80=99d laid out initially, and while it=
=E2=80=99s an
>> interesting and important one, it is not what I meant by =E2=80=9Cmultip=
le access
>> tokens=E2=80=9D in my discussion below. I think that might be the cause =
of some
>> disconnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of reach=
 for what the WG is
>> after.
>>
>> When I refer to multiple access tokens, and what the charter calls out a=
s
>> multiple access tokens, is the ability for the client to get several acc=
ess
>> tokens to get different resources from one request. I personally see thi=
s
>> as an optimization of a specific set of use cases, some of which I
>> discussed in my original email. There are others, I=E2=80=99m sure, but =
all the
>> ones I=E2=80=99ve seen are around the client needing to get several diff=
erent kinds
>> of access through an AS.
>>
>> I think it=E2=80=99s going to be overwhelmingly common that a given RS i=
s going
>> to trust exactly one AS that it knows about ahead of time. But for RS=E2=
=80=99s
>> that can trust multiple AS=E2=80=99s, then we should have a model that c=
an
>> accommodate that as well. That=E2=80=99s why the charter calls out metho=
ds for the
>> AS and RS to communicate what the token=E2=80=99s good for. I think the =
basis of
>> those methods is going to start with a common token model, and likely
>> incorporate into things like token formats and introspection-style token
>> APIs.
>>
>>  =E2=80=94 Justin
>>
>> On Jun 22, 2020, at 3:55 AM, Denis  wrote:
>>
>> Hello Justin,
>>
>> A few comments between the lines.
>>
>> One of the most important aspects to GNAP is going to be an ability to
>> address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do =
without significant
>> gymnastics. So with that, I wanted to bring back a use case discussion t=
hat
>> originally came up while we were talking about the possibility of multip=
le
>> access tokens, a few months back. I don=E2=80=99t know if this concept h=
as a
>> regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access t=
okens=E2=80=9D until we
>> come up with something better =E2=80=94 assuming we decide this is worth=
while.
>>
>> I don't understand what may mean "directed access tokens=E2=80=9D but I
>> understand what means "multiple access tokens".
>> When speaking of "multiple access tokens", these access tokens may come
>> from one or more ASs.
>>
>> In OAuth, the client=E2=80=99s supposed to always know where to send its=
 access
>> token, and that knowledge is completely outside the protocol. This makes=
 a
>> lot of sense for many (if not most) deployments, as OAuth is really ther=
e
>> to enable the API access that the client already knows about.
>>
>> But we=E2=80=99re now in a world where a client could be talking to a ge=
neric API
>> that could be deployed at a number of different places, or a cloud
>> deployment that the AS wants to be able to dispatch the client to.
>>
>> As soon the AS is placed (again) at the centre of the model, the AS will
>> have the ability to act as "Big Brother".
>> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP
>> should take care of them.
>>
>> In order to do this, the AS needs to be able to communicate to the clien=
t
>> not only the token information (and any related key and presentation
>> information), but also a set of *directions* about what that specific
>> token is good for. This needs to be information outside the token itself=
,
>> since I believe we want to keep OAuth 2=E2=80=99s feature of having the =
token be
>> opaque to the client. Note: while we could map all of these to different
>> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlanc=
e)
>> on the request side, this isn=E2=80=99t enough to tell the client what t=
o do with
>> the token *if it doesn=E2=80=99t know already*.
>>
>> I know of two use cases already in the wild, where people are addressing
>> things using a mix of existing standards and some proprietary extensions=
 to
>> address things within their silos. I=E2=80=99ll try to summarize here, b=
ut I know
>> the folks I=E2=80=99ve been talking to about this are also on the list s=
o hopefully
>> they can chime in with more detail or any corrections for something I=E2=
=80=99ve
>> missed.
>>
>> (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=
=80=99t know
>> where it=E2=80=99s hosted. Everything is in a single security domain con=
trolled by
>> the AS,
>>
>> Speaking of "multiple access tokens" is in contradiction with single
>> security domain "controlled" by an AS.
>> A user may need to demonstrate some of his identity attributes granted
>> e.g. by his bank but may also
>> need to demonstrate one or more diplomas granted by one or more
>> universities. The bank cannot be
>> the "primary issuer" of a university diploma. It should not be either a
>> "secondary issuer", because
>> the bank does not "*need to know"* what are the diplomas of the user.
>>
>> but the AS needs to decide at runtime which specific instance of the API
>> to direct the client to. Since things are closely tied together, the cli=
ent
>> just needs to effectively known an identifier for the RS, and this is
>> currently implemented as a URI. Once the client has that identifier, it
>> knows how to dispatch that token to that instance of the RS.
>>
>> There is no good reason why the AS should be involved in that step.
>> OAuth 2.0 is/was implicitly mandating a strong relationship between ASs
>> and RSs which makes it non scalable.
>> GNAP should be based on a simple trust relationship : a given RS trusts
>> some ASs for access tokens that contains some types of attributes.
>> An AS should not need to know in advance (or even at the time of an
>> access token request) the RSs that are trusting it.
>>
>> A client could first talk to a "global service provider" which has the
>> knowledge of the different RSs affiliated to it.
>>
>> (2) The client knows what kind of thing it=E2=80=99s looking for, but do=
esn=E2=80=99t
>> know who to ask it from.
>>
>> Once again, the client could first talk to a "global service provider"
>> which has the knowledge of the different RSs affiliated to it.
>>
>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, a=
nd the AS needs
>> to dispatch to different resources depending on which user logged in (an=
d
>> possibly what the user consented to). To make things more concrete, the
>> client needs to get driver=E2=80=99s license information, but doesn=E2=
=80=99t know ahead of
>> time which of the many state/provincial bureaus to call to get that
>> information because it doesn=E2=80=99t know yet who the user is.
>>
>> When a user has a driving license, he knows its issuer. The user can the=
n
>> provide some hint to the client.
>>
>> The AS will know who the user is once they log in and approve things, an=
d
>> so it can direct the client to call the correct RS. Since this is a
>> relatively simple API with a pre-negotiated cross-domain trust, the AS
>> returns a URL that the client presents the token at.
>>
>>  A single AS should not be aware of all the attributes a user has.
>>
>>
>> As far as I know, in both of these cases, the token is only good for tha=
t
>> API and not others =E2=80=94 but more on that later.
>>
>> A simple thing to do is just give back a URL with the access token, whic=
h
>> tells the client where to go.
>>
>> {
>> =E2=80=9Caccess_token=E2=80=9D: {
>> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
>> =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
>> }
>> }
>>
>> This is good for some kinds of APIs, but it=E2=80=99s limiting because n=
ot all
>> APIs dispatch based on the URL. An AS might want to divvy up access toke=
ns
>> to an API that=E2=80=99s keyed on headers, or verbs, or any number of th=
ings. And
>> it doesn=E2=80=99t tell us immediately what to do about non-exact URL ma=
tches. Can
>> the client add query parameters and still use the token? What about path
>> segments? I like that this simple approach addresses some common
>> deployments that we already see today (see above), it=E2=80=99s not univ=
ersal. Do
>> we want or need a universal description language for directing where tok=
ens
>> go?
>>
>> This also opens up a whole new set of security questions. If the AS can
>> now direct the client where to use the token, could a rogue AS convince =
a
>> legit client to use a stolen token at the wrong RS? And what if the clie=
nt
>> ignores the directions from the AS entirely? Could this open up new aven=
ues
>> of attack?
>>
>> This is just the start, too. Things get even more complex if the client
>> can ask for multiple different kinds of resources at once. What if the A=
S
>> decides that the client needs a hyper-focused directed token for one par=
t
>> of the API, but can use a general token for other stuff? Can it signal t=
hat
>> to the client? And if it can, does that mean that all clients need to be
>> prepared for that kind of thing?
>>
>> I firmly believe that whatever we build in GNAP, we need to optimize for
>> the overwhelmingly common use case of a client getting a single access
>> token to call APIs that it already knows about. Anything we add on top o=
f
>> that really can=E2=80=99t get in the way of this, because if it does, th=
ere=E2=80=99s very
>> small chance that people will try to use this for everyday things. Keep =
the
>> simple things simple, and the complex things possible, after all.
>>
>> I=E2=80=99m really looking forward to hearing what the community thinks =
about
>> these use cases, and hopefully the people I=E2=80=99ve chatted with offl=
ine about
>> this can join the conversation and provide more light than I was able to=
.
>>
>> The two use cases which are considered above are:
>>
>> (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=
=80=99t know
>> where it=E2=80=99s hosted.
>> (2) The client knows what kind of thing it=E2=80=99s looking for, but do=
esn=E2=80=99t
>> know who to ask it from.
>>
>> That does not mean in any way that these two use cases should be solved
>> by placing the AS at the centre of the solution.
>>
>> Denis
>>
>>
>>  =E2=80=94 Justin
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
> This communication, including any attachments, is confidential. If you ar=
e not the intended recipient, you should not read it - please contact me im=
mediately, destroy it, and do not copy or use any part of this communicatio=
n or disclose anything about it. Thank you. Please note that this communica=
tion does not designate an information system for the purposes of the Elect=
ronic Transactions Act 2002.
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000d0217d05a9f1eef4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I disagree with any approach that would allow the client/R=
P to delegate=C2=A0anything that it does not own. The RP either has that au=
thority=C2=A0from the RO or AS, or not. Modifying the authority in any way =
should not be permitted. New=C2=A0RO auth would be required.
OTOH any e=
ndpoint could be granted agency by the RO. That should not be conflated wit=
h an AZ token. If agency is provided by a AZ token it is unclear that it me=
ets any of the various regulations.=C2=A0 Note that this comment does not a=
pply to :"data processors" that are disclosed to the RO.
Peace ..tom
<=
br>

On Tue, Jul 7, 2020 at 1:39 PM Justin Richer <jricher@mit.edu> wrote:
=
I=E2=80=99ve been thinking more about these use cases, and it might help us=
 to think of GNAP=E2=80=99s access tokens as capabilities in the computer s=
ecurity sense =E2=80=94 but more specifically, capabilities that are delive=
red with their own context for use. In that way, an otherwise naive client =
can be handed an access token and simply know exactly what to do with it. T=
his context would be delivered alongside the token, so the token material i=
tself remains opaque to the client.

I wanted to bring up=
 a W3C spec for a capabilities model based on linked data:

https:/=
/w3c-ccg.github.io/zcap-ld/

Building a fully f=
eatured capabilities context is difficult, at the very least. And unfortuna=
tely, I don=E2=80=99t think this spec actually gives us any viable solution=
s to work with. In particular the =E2=80=9Cactions=E2=80=9D section is effe=
ctively blank, offloading the work to an external JSONLD process (side note=
, this is one of the problems I have with specs based on JSONLD, they exter=
nalize the important parts into local contexts and break interoperability =
=E2=80=94 but I digress). But at least it=E2=80=99s another way of looking =
at the problem space that might be outside the familiar zone of many of the=
 OAuth world.

=C2=A0=E2=80=94 Justin

<=
blockquote type=3D"cite">
On Jun 26, 2020, at 9:23 AM, Justin Richer &l=
t;jricher@mit.edu&=
gt; wrote:

On=
 Jun 25, 2020, at 9:07 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

=
I find this feature interesting and think it could be an important=C2=A0pat=
tern going=C2=A0forward to enable an AS to be able to describe the utility =
of a token to the client, however as already pointed out in the thread I th=
ink there is some potential hidden complexity that would need to be ironed =
out such that it does not make the simple things complicated.

Justin, do you see this feature as something the client has to explic=
itly request, i.e "please give me access and instructions on how to us=
e my access" or rather that the AS would just return this information =
in conjunction with the access token if it had it available?

=


This is something that I=
=E2=80=99d brought up as a possibility on the previous thread =E2=80=94 som=
ething like a flag the client would set. This would be especially important=
 if the AS wants to return multiple access tokens but the client requested =
1, or the client requested N and the AS wants to return M in response. Basi=
cally any time there=E2=80=99s a mismatch, that=E2=80=99s extra complexity =
on the client that I really don=E2=80=99t think we want to be universal. A =
flag to turn that kind of direction and splitting on would be a potential s=
tart. But there are potential snags here too, and it comes down to how you =
manage the defaults...

> This is just the start, too. Things get even more complex if=
 the client can ask for multiple different kinds of resources at once. What=
 if the AS decides that the client needs a hyper-focused directed token for=
 one part of the API, but can use a general token for other stuff? Can it s=
ignal that to the client? And if it can, does that mean that all clients ne=
ed to be prepared for that kind of thing?

Would a =
potential default be that if a client did for any reason not support proces=
sing the additional information returned with the access_token, just to ign=
ore it? I think in the spirit of keeping the simple things simple, this pot=
entially makes sense?

Tha=
t=E2=80=99s the real trick, if you ask me. It has to be :safe: for a client=
 to ignore this information. Which means the AS can=E2=80=99t rely on the c=
lient =E2=80=9Cdoing the right thing=E2=80=9D with the information in the =
=E2=80=9Ctoken directions=E2=80=9D portion of the response. Even setting as=
ide the advanced and related =E2=80=9Csplit tokens=E2=80=9D idea above, we =
need to make sure that an AS/RS setup is built such that if the AS tells a =
client =E2=80=9Conly do X with your token=E2=80=9D and the client does =E2=
=80=9CY=E2=80=9D, then there are other protections and practices in place t=
o prevent things from going haywire if the client does =E2=80=9CY=E2=80=9D =
either by accident or through ignorance.=C2=A0

If =
OAuth 2 has taught us anything, it=E2=80=99s that client applications are g=
oing to be the laziest participants in the security model. And that makes s=
ense, really =E2=80=94 security isn=E2=80=99t what the client apps are tryi=
ng to do, they=E2=80=99re trying to use the RS to do something. So we need =
to make sure that whatever system we design will fail on the safe side as m=
uch as possible, and keep things simple for the client.


> here are som=
e worked out samples of this:
https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
Peace ..tom

As one of the authors of those mentioned drafts, I am interested in=
 discussing that, but perhaps on a seperate thread? As at least=C2=A0the bo=
und assertion spec is=C2=A0primarily=C2=A0concerned with binding mechanisms=
 for the artifacts produced from an authorization flow (specifically identi=
ty claims), whereas I think directed access tokens is just more generally t=
alking about whether GNAP should support an AS conveying how to use an acce=
ss_token it produces during a flow with a client.


I t=
hink that these are separate issues as well.

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

Thanks,
3D"Mattr=C2=
=A0
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.=
global
<=
td width=3D"40">3D"Mattr
<=
a href=3D"https://www.linkedin.com/company/mattrglobal" style=3D"border:non=
e;color:rgb(51,49,50);margin-right:12px" target=3D"_blank">3D"Mattr3D"Mattr3D"Mattr

This communication, including any attachments, is confid=
ential. If you are not the intended recipient, you should not read it - ple=
ase contact me immediately, destroy it, and do not copy or use any part of =
this communication or disclose anything about it. Thank you. Please note th=
at this communication does not designate an information system for the purp=
oses of the Electronic Transactions Act 2002.
=


On Wed, Jun 24, 2020 at 10:14 PM Denis <denis.ietf@free.fr> wrote:
Justin, I fea=
r we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am getting tired of the=
 whack-a-mole approach ..."

I don't agree with=
 you when you write: "I think it=E2=80=99s going to be overwhelmingly =
common that a given RS is going to trust exactly one AS=C2=A0<=
br>
that it knows about ahead of time". Such an architecture would=
 have exactly the same limitations as OAuth 2.0. and would not be scalable.=


Before we start, we should have a clear view=
 of the whole picture rather than starting from one scenario and expanding =
it in many different directions.
For building an architecture, a =
pre-requirement is to define ALL the trust relationships. I don't belie=
ve that we have an agreement at this time on what=C2=A0
the=
se trust relationships are.=C2=A0

You are also using the following wording: "methods for the AS and R=
S to communicate what the token=E2=80=99s good for".=C2=A0
With such a paradigm, it would be impossible to protect the user's=
 privacy.=C2=A0

A key question is=
 : Will GNAP take care of the user's privacy or will GNAP=C2=A0prevent=C2=A0to take care of the user's privac=
y ?

About "the ability for the client to get =
several access tokens to get different resources from one request" is =
indeed a complex case.

No one (including ASs) is a=
ble to predict in advance which access tokens will be needed, since they de=
pend upon the kind of operation(s)=C2=A0
the client will be=
 willing to perform. For privacy reasons, ASs should be kept ignorant of al=
l the operations that a client is going to perform=C2=A0
on=
 one or more resource servers. I believe that every effort should be made t=
o avoid the AS to be in a position to be able to trace the operations=
=C2=A0
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of opera=
tions needs to be considered with a detailed focus on the time=C2=A0<=
/span>
at which the user's=C2=A0consent and choice=C2=A0happens (consent and choice=C2=A0i=
s the first privacy principle from ISO 29100).

Fir=
st of all, an access token could be targeted to a service rather than to a =
server. This would already solve many cases.

When =
a RS needs to call another RS (which does not support the same service) the=
n the client should be informed by the first RS.
His "consen=
t and choice" should then be obtained by the first RS and, when the us=
er agrees, the client should then ask an access token=C2=A0to one of the ASs trusted by the second RS in order to perform the subsequ=
ent operation.=C2=A0=C2=A0

Denis<=
/div>

PS.=C2=A0 In an email sent on June 23 you wrote: &=
quot; I think an on-device AS is an important use case".=C2=A0 I am so=
rry, but I don't understand.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ho=
wever, I do understand what "a server-based AS" is.


Denis, thanks for the g=
reat comments. I think that your trust model is pretty different from what =
I=E2=80=99d laid out initially, and while it=E2=80=99s an interesting and i=
mportant one, it is not what I meant by =E2=80=9Cmultiple access tokens=E2=
=80=9D in my discussion below. I think that might be the cause of some disc=
onnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of reach for wh=
at the WG is after.

When I refer to multiple access toke=
ns, and what the charter calls out as multiple access tokens, is the abilit=
y for the client to get several access tokens to get different resources fr=
om one request. I personally see this as an optimization of a specific set =
of use cases, some of which I discussed in my original email. There are oth=
ers, I=E2=80=99m sure, but all the ones I=E2=80=99ve seen are around the cl=
ient needing to get several different kinds of access through an AS.=C2=A0<=
br>

I think it=E2=80=99s going to be overwhelmingly comm=
on that a given RS is going to trust exactly one AS that it knows about ahe=
ad of time. But for RS=E2=80=99s that can trust multiple AS=E2=80=99s, then=
 we should have a model that can accommodate that as well. That=E2=80=99s w=
hy the charter calls out methods for the AS and RS to communicate what the =
token=E2=80=99s good for. I think the basis of those methods is going to st=
art with a common token model, and likely incorporate into things like toke=
n formats and introspection-style token APIs.=C2=A0

=C2=A0=E2=80=94 Justin

On Jun =
22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the lines.

One of the most important aspects t=
o GNAP is going to be an ability to address things that OAuth 2 can=E2=80=
=99t, or at least can=E2=80=99t do without significant gymnastics. So with =
that, I wanted to bring back a use case discussion that originally came up =
while we were talking about the possibility of multiple access tokens, a fe=
w months back. I don=E2=80=99t know if this concept has a regular term, so =
I=E2=80=99m going to call it =E2=80=9Cdirected access tokens=E2=80=9D until=
 we come up with something better =E2=80=94 assuming we decide this is wort=
hwhile.=C2=A0
I don't u=
nderstand what may mean "directed access tokens=E2=80=9D but I underst=
and what means "multiple access tokens".=C2=A0
Wh=
en speaking of "multiple access tokens", these access tokens may =
come from one or more ASs.
In OAuth, the client=E2=80=99s supposed to always know where to send =
its access token, and that knowledge is completely outside the protocol. Th=
is makes a lot of sense for many (if not most) deployments, as OAuth is rea=
lly there to enable the API access that the client already knows about.

But we=E2=80=99re now in a world where a client could=
 be talking to a generic API that could be deployed at a number of differen=
t places, or a cloud deployment that the AS wants to be able to dispatch th=
e client to.=C2=A0
As soo=
n the AS is placed (again) at the centre of the model, the AS will have the=
 ability to act as "Big Brother".
OAuth 2.0 has not taken care=
 of privacy issues. On the contrary, GNAP should take care of them.
In order to do this, the AS need=
s to be able to communicate to the client not only the token information (a=
nd any related key and presentation information), but also a set of=
=C2=A0directions=C2=A0about what that specific token is good =
for. This needs to be information outside the token itself, since I=C2=A0be=
lieve we want to keep OAuth 2=E2=80=99s feature of having the token be opaq=
ue to the client. Note: while we could map all of these to different resour=
ce requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the=
 request side, this isn=E2=80=99t enough to tell the client what to do with=
 the token=C2=A0if it doesn=E2=80=99t know already.=C2=
=A0

I know of two use cases already in the wild, w=
here people are addressing things using a mix of existing standards and som=
e proprietary extensions to address things within their silos. I=E2=80=99ll=
 try to summarize here, but I know the folks I=E2=80=99ve been talking to a=
bout this are also on the list so hopefully they can chime in with more det=
ail or any corrections for something I=E2=80=99ve missed.=C2=A0
<=
br>
(1) The client knows what resource it=E2=80=99s calling, but =
it doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a singl=
e security domain controlled by the AS,=C2=A0
Speaking of "multiple access tokens" is in c=
ontradiction with single security domain "controlled" by an AS.=C2=A0
A user may need to demonstrate some of his identity at=
tributes granted e.g. by his bank but may also=C2=A0
need t=
o demonstrate one or more diplomas granted by one or more universities. The=
 bank cannot be=C2=A0
the "primary issuer" of a u=
niversity diploma. It should not be either a "secondary issuer", =
because=C2=A0
the bank does not "need to know"=
=C2=A0what are the diplomas of the user.
but the AS needs to decide at runtime =
which specific instance of the API to direct the client to. Since things ar=
e closely tied together, the client just needs to effectively known an iden=
tifier for the RS, and this is currently implemented as a URI. Once the cli=
ent has that identifier, it knows how to dispatch that token to that instan=
ce of the RS.
There is no good reason =
why the AS should be involved in that step.=C2=A0
OAuth 2.0=
 is/was implicitly mandating a strong relationship between ASs and RSs whic=
h makes it non scalable.
GNAP should be based on a simple trust relation=
ship : a given RS trusts some ASs for access tokens that contains some type=
s of attributes.
An AS should not need to know in advance (or even at th=
e time of an access token request) the RSs that are trusting it.
A client could first talk to a "global service provide=
r" which has the knowledge of the different RSs affiliated to it.=C2=A0
(2) Th=
e client knows what kind of thing it=E2=80=99s looking for, but doesn=E2=80=
=99t know who to ask it from.=C2=A0
Once again, the client could first talk to a "global servic=
e provider" which has the knowledge of the different RSs affiliated to=
 it.=C2=A0
T=
here=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, and t=
he AS needs to dispatch to different resources depending on which user logg=
ed in (and possibly what the user consented to). To make things more concre=
te, the client needs to get driver=E2=80=99s license information, but doesn=
=E2=80=99t know ahead of time which of the many state/provincial bureaus to=
 call to get that information because it doesn=E2=80=99t know yet who the u=
ser is.=C2=A0
When a user=
 has a driving license, he knows its issuer. The user can then provide some=
 hint to the client.
The =
AS will know who the user is once they log in and approve things, and so it=
 can direct the client to call the correct RS. Since this is a relatively s=
imple API with a pre-negotiated cross-domain trust, the AS returns a URL th=
at the client presents the token at.=C2=A0
=C2=A0A single AS should not be aware of all the attr=
ibutes a user has.=C2=A0

As far as I know, in both of these cases, t=
he token is only good for that API and not others =E2=80=94 but more on tha=
t later.

A simple thing to do is just give back a =
URL with the access token, which tells the client where to go.=C2=A0
<=
div>
	{
		=E2=80=9Caccess_token=E2=80=
=9D: {
			=E2=80=9Cva=
lue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
			=E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
		}
	}

This is goo=
d for some kinds of APIs, but it=E2=80=99s limiting because not all APIs di=
spatch based on the URL. An AS might want to divvy up access tokens to an A=
PI that=E2=80=99s keyed on headers, or verbs, or any number of things. And =
it doesn=E2=80=99t tell us immediately what to do about non-exact URL match=
es. Can the client add query parameters and still use the token? What about=
 path segments? I like that this simple approach addresses some common depl=
oyments that we already see today (see above), it=E2=80=99s not universal. =
Do we want or need a universal description language for directing where tok=
ens go?

This also opens up a whole new set of secu=
rity questions. If the AS can now direct the client where to use the token,=
 could a rogue AS convince a legit client to use a stolen token at the wron=
g RS? And what if the client ignores the directions from the AS entirely? C=
ould this open up new avenues of attack?

This is j=
ust the start, too. Things get even more complex if the client can ask for =
multiple different kinds of resources at once. What if the AS decides that =
the client needs a hyper-focused directed token for one part of the API, bu=
t can use a general token for other stuff? Can it signal that to the client=
? And if it can, does that mean that all clients need to be prepared for th=
at kind of thing?

I firmly believe that whatever w=
e build in GNAP, we need to optimize for the overwhelmingly common use case=
 of a client getting a single access token to call APIs that it already kno=
ws about. Anything we add on top of that really can=E2=80=99t get in the wa=
y of this, because if it does, there=E2=80=99s very small chance that peopl=
e will try to use this for everyday things. Keep the simple things simple, =
and the complex things possible, after all.

I=E2=
=80=99m really looking forward to hearing what the community thinks about t=
hese use cases, and hopefully the people I=E2=80=99ve chatted with offline =
about this can join the conversation and provide more light than I was able=
 to.
The two use cases which are consi=
dered above are:
(1) The client knows wha=
t resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=
=99s hosted.
(2) The client knows what kind of thing it=E2=80=99s lookin=
g for, but doesn=E2=80=99t know who to ask it from.=C2=A0
<=
/p>
That does not mean in any way that these=
 two use cases should be solved by placing the AS at the centre of the solu=
tion.
Denis

=C2=A0=E2=80=94 Justin


--=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

This communication, including any attachments, is confide=
ntial. If you are not the intended recipient, you should not read it - plea=
se contact me immediately, destroy it, and do not copy or use any part of t=
his communication or disclose anything about it. Thank you. Please note tha=
t this communication does not designate an information system for the purpo=
ses of the Electronic Transactions Act 2002.
=

--=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



--000000000000d0217d05a9f1eef4--


From nobody Wed Jul  8 11:09: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 11DA73A05A0 for ; Wed,  8 Jul 2020 11:09:23 -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 Kw3mHKhVVB-5 for ; Wed,  8 Jul 2020 11:09:21 -0700 (PDT)
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 295343A059F for ; Wed,  8 Jul 2020 11:09:21 -0700 (PDT)
Received: by mail-yb1-xb2b.google.com with SMTP id g6so2740821ybo.11 for ; Wed, 08 Jul 2020 11:09: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=1F1LLnq+Hudu6s6ecnW/D85yhDBx+FzpG1dS0uJcXpI=; b=bMqjDGC++1eKhgj7bsGOJFJY1cn+AjOoH7B06rs/H9gb9JKYeyidk7L4IlYkJx/yUg V4S6IkvRTqPxvFT9urE+h5F1v4UQaQWvz0JWP/L74e1gqp9A+z+u7kH4PbvzMxPE4EtS dyvxaFTjxCRzuliv8NcCpiT18/XmjxwfXYL824waXyN373+sl2OmylpghOfABJNdDmtL mhJg3B4Qa8NsATPUK5VamNn0x1bg5YZqXqm+7xTaaOQ5CHcdY3p/weiRPg1bvpRropJY bIOKicyEB6e6WDiyhaRQorcCThnWlj5vATyBNA/GyPtAps6UiwseBWju0PwWms3h1W84 qB7g==
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=1F1LLnq+Hudu6s6ecnW/D85yhDBx+FzpG1dS0uJcXpI=; b=ihpjMMpwlhLaTuPCeAlhOVbQCP7i9YCOqgDsKgUUC7r/xIh9976Pd1vqWi4dvOON8V FKimo76yHRMKfktF7KXXQcnLAM1XslxOttzi5EywrXX7B+tnw+2yDWzCuPlVpV99yyhE 7RPhOTXVPlgdxhdcyWPTW+QxizByb1TE69K+5hcrep+dM5T9boWPDeAynvUVtQ9HB2e9 HhfLuLGGROla8O5isuQribCUysXDVirJr6B6b7Szq04+GmjyGZXUMYmo8N8w9LLWGOIN VDV6AvuAmjdlzweGCOOgYNCDNA9EPKikp+TJ0vrKFgWvgYEebmXcW8eas2FBlx2t34Tv fAfw==
X-Gm-Message-State: AOAM531SAxlj3oXZOZ/zkyS0nbUbxXWB53RMDB6mmg5P4n0i4KaOi70u GfYLZFbLUdrJznOVi5/cOTbSMue2EJkT45g33Fj7f87c
X-Google-Smtp-Source: ABdhPJyQwXOb8Qt8+uBYdue8Qtx6FXfzQ2Q8tEp2cnxHXva1Yc9ndFGXrsgO86UK/GUsRc7FQN2lTILcDTgD5hZ4pe8=
X-Received: by 2002:a25:46:: with SMTP id 67mr10680249yba.517.1594231760323; Wed, 08 Jul 2020 11:09:20 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu> 
In-Reply-To: 
From: Stephen Moore 
Date: Wed, 8 Jul 2020 14:09:08 -0400
Message-ID: 
To: Dick Hardt 
Cc: Justin Richer , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c3874305a9f201e7"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 08 Jul 2020 18:09:23 -0000

--000000000000c3874305a9f201e7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dick,
I've looked over your draft, and the emails here. You said you didn't use
polymorphism, and the draft does not appear to use polymorphism. I'd think
it is safe to say that the XAuth protocol was not built with polymorphism
in mind. I don't think that Justin meant to imply you didn't consider it,
but rather that from the discussions (up to that point) and the draft
itself, it doesn't say polymorphism is a tool that can be applied in the
tokens.

As for the "GNAP should make use of a polymorphic protocol structure",
that's just his position on what he thinks GNAP should do. I don't really
see how that is a 'mistake'.
-steve

On Wed, Jul 8, 2020 at 12:55 PM Dick Hardt  wrote:

> Justin: it is disappointing that you deflect from responding to:
>
> It=E2=80=99s not surprising that this is the case, as the XAuth protocol =
was not
>> designed with polymorphism as a tool to consider. This is exactly the
>> reason that I say we should have polymorphism in the toolbox from the
>> start, as it allows us to avoid this kind of awkwardness in many cases.
>>
>
>  What evidence do you have to make this statement? "XAuth protocol was no=
t
> designed with polymorphism as a tool to consider"
>
> Similarly, you deflected responding to your statement:
>
> "GNAP should make use of a polymorphic protocol structure"
>
> How are we going to have a productive conversation when you won't
> acknowledge mistakes, either intentional, or unintentional?
>
> wrt. your proposal to represent an authorization request as an array of
> scopes is overly simplistic. Both XYZ and XAuth represent the request as =
an
> object to enable a request richer than just an array of scopes.
>
> /Dick
>
>
>
> On Wed, Jul 8, 2020 at 7:03 AM Justin Richer  wrote:
>
>> I=E2=80=99m glad that you=E2=80=99re looking at polymorphism as a possib=
le solution to
>> this, though I would contend that this particular style of polymorphism =
is
>> not doing much more than pushing the mutual-exclusivity check down a lay=
er
>> instead of solving it.
>>
>> Using multiple types can in fact solve this problem, and several others,
>> as long as you=E2=80=99re willing to let go of the syntax that OAuth 2 i=
nvented to
>> solve a problem that we don=E2=80=99t have to solve here (passing an arr=
ay-type
>> value over the front channel). In XYZ=E2=80=99s syntax, the request for =
a single
>> access token would look like this:
>>
>> {
>>   =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=
=E2=80=9D ]
>> }
>>
>> And the request for the multiple access tokens would look like this:
>>
>> {
>>   =E2=80=9Cresources": {
>>      =E2=80=9Creader": [ =E2=80=9Cread=E2=80=9D ],
>>      =E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
>>   }
>> }
>>
>> I find this to be much simpler to parse and generate, as you no longer
>> need to check for a specially-reserved field name (=E2=80=9Ctype=E2=80=
=9D), and you no
>> longer have to do a sub-parse on one of the values to get what you reall=
y
>> want (the space-separated scope string into a set). It=E2=80=99s also a =
lot simpler
>> for the developers that need to write this.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 7, 2020, at 7:30 PM, Dick Hardt  wrote:
>>
>>
>>
>> On Tue, Jul 7, 2020 at 3:40 AM Justin Richer  wrote:
>>
>>> I wanted to respond to this comment more fully:
>>>
>>> > wrt. my authorization / authorizations oddness, polymorphism would no=
t
>>> solve it as the contents of both authorization / authorizations in XAut=
h
>>> are objects.
>>>
>>> It=E2=80=99s not surprising that this is the case, as the XAuth protoco=
l was not
>>> designed with polymorphism as a tool to consider. This is exactly the
>>> reason that I say we should have polymorphism in the toolbox from the
>>> start, as it allows us to avoid this kind of awkwardness in many cases.
>>>
>>
>>  What evidence do you have to make this statement? "XAuth protocol was
>> not designed with polymorphism as a tool to consider"
>>
>> It sounds like you are saying I did not consider polymorphism in the
>> XAuth protocol design.
>>
>> I will restate my comment above about polymorphism.
>>
>> Using different JSON types does not solve the problem, but as I suggest
>> in my comments, polymorphism of different JSON objects is one solution. =
An
>> authorization, or a dictionary of authorizations. It has the restriction
>> that the string "type" cannot be used as a label in the dictionary. An
>> example:
>>
>> {
>>     "authorizations" {
>>         "type": "oauth_scope",
>>         "scope": "read write"
>>     }
>> }
>>
>> {
>>     "authorizations" {
>>         "reader": {
>>             "type": "oauth_scope",
>>             "scope": "read"
>>         },
>>         "writer": {
>>             "type": "oauth_scope",
>>             "scope": "write"
>>         },
>>     }
>> }
>>
>>
>> I am looking at making this change in XAuth and in the implementation.
>>
>>
>>
>> =E1=90=A7
>>
>>
>> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000c3874305a9f201e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Dick,=C2=A0
I've looked over your dr=
aft, and the emails here. You said you didn't use polymorphism, and the=
 draft does not appear to use polymorphism. I'd think it is safe to say=
 that the XAuth protocol was not built with polymorphism in mind. I don'=
;t think that Justin meant to imply you didn't consider it, but rather =
that from the discussions (up to that point) and the draft itself, it doesn=
't say polymorphism is a tool that can be applied in the tokens.
<=
div>
As for the "GNAP should make use of a polymorphic p=
rotocol structure", that's just his position on what he thinks GNA=
P should do. I don't really see how that is a 'mistake'.
<=
div>-steve
On Wed, Jul 8, 2020 at 12:55 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Justin: it is disappointing=C2=A0that yo=
u deflect from responding to:=C2=A0

It=E2=80=99s not surp=
rising that this is the case, as the XAuth protocol was not designed with p=
olymorphism as a tool to consider. This is exactly the reason that I say we=
 should have polymorphism in the toolbox from the start, as it allows us to=
 avoid this kind of awkwardness in many cases.

=C2=A0What evidence do you have to make this statement? "XAuth=
 protocol was not designed with polymorphism as a tool to consider"
Similarly, you deflecte=
d responding to your statement:
"GNAP should make use of a polymorphic protocol st=
ructure"

H=
ow are we going to have a productive conversation when you won't acknow=
ledge mistakes, either intentional, or unintentional?

wrt. your propos=
al to represent an authorization=C2=A0request as an array of scopes is over=
ly simplistic. Both XYZ and XAuth represent the request as an object to ena=
ble a request richer than just an array of scopes.=C2=A0
<=
font color=3D"#500050">
/Dick<=
/font>



On Wed, Jul 8, 2020 at 7:03 AM Justin R=
icher <jricher@mit.=
edu> wrote:
I=E2=80=99m glad that you=E2=80=99re looking at polymorphism as a p=
ossible solution to this, though I would contend that this particular style=
 of polymorphism is not doing much more than pushing the mutual-exclusivity=
 check down a layer instead of solving it.=C2=A0

Using m=
ultiple types can in fact solve this problem, and several others, as long a=
s you=E2=80=99re willing to let go of the syntax that OAuth 2 invented to s=
olve a problem that we don=E2=80=99t have to solve here (passing an array-t=
ype value over the front channel). In XYZ=E2=80=99s syntax, the request for=
 a single access token would look like this:

{
=C2=A0 =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cread=E2=80=9D, =E2=80=
=9Cwrite=E2=80=9D ]
}

And the request fo=
r the multiple access tokens would look like this:

{
=C2=A0 =E2=80=9Cresources": {
=C2=A0 =C2=A0 =C2=
=A0=E2=80=9Creader": [ =E2=80=9Cread=E2=80=9D ],
=C2=A0 =C2=
=A0 =C2=A0=E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
=
=C2=A0 }
}

I find this to be much simple=
r to parse and generate, as you no longer need to check for a specially-res=
erved field name (=E2=80=9Ctype=E2=80=9D), and you no longer have to do a s=
ub-parse on one of the values to get what you really want (the space-separa=
ted scope string into a set). It=E2=80=99s also a lot simpler for the devel=
opers that need to write this.

=C2=A0=E2=80=94 Jus=
tin

On Jul 7, 2020, at 7:=
30 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Tue, Jul 7, 2020 at 3:40 AM Justin Richer <jricher@mit.edu> wrote=
:
I wanted to re=
spond to this comment more fully:



> wrt. my authorization / authorizations oddness, polymorphism would not=
 solve it as the contents of both authorization / authorizations in XAuth a=
re objects. 



It=E2=80=99s not surprising that this is the case, as the XAuth protocol wa=
s not designed with polymorphism as a tool to consider. This is exactly the=
 reason that I say we should have polymorphism in the toolbox from the star=
t, as it allows us to avoid this kind of awkwardness in many cases.

=C2=A0What evidence do you have to make this s=
tatement? "XAuth protocol was not designed with polymorphism as a tool=
 to consider"

It sounds like you are sayi=
ng I did not consider polymorphism in the XAuth protocol design.
=

I will restate my comment above about polymorphism.=C2=A0

Using different JSON types does not solve the proble=
m, but as I suggest in my comments, polymorphism of different JSON objects =
is one solution. An authorization, or a dictionary of authorizations. It ha=
s the restriction that the string "type" cannot be used as a labe=
l in the dictionary. An example:

{
=C2=A0 =C2=
=A0 "authorizations" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type&=
quot;: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope&=
quot;: "read write"
=C2=A0 =C2=A0 }
}

{
=C2=A0 =
=C2=A0 "authorizations" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "re=
ader": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type"=
: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu=
ot;scope": "read"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "writer": {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "type": "oauth_scope",
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": "write"
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 }
}


I am looking at making this change in XAuth and in the=
 implementation.



3D""=E1=90=A7




-- 

Txauth mailing list

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



--000000000000c3874305a9f201e7--


From nobody Wed Jul  8 11:59: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 A42063A00AE for ; Wed,  8 Jul 2020 11:59: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 qV68-MUVg9GD for ; Wed,  8 Jul 2020 11:59:15 -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 EBBAC3A0063 for ; Wed,  8 Jul 2020 11:59:14 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id q4so19762374lji.2 for ; Wed, 08 Jul 2020 11:59: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=DDVJKmbYoeZO+XYbKcpbEsn1NIAyLpbApgk9hs9iVQc=; b=hWyzVUK0B4OQzjkGMTiEvhm9lva8fflouQbIlLUauzNWMbV1pbOq4bFiIsupfzs1h9 JAClHYHgbGxrIRz3ZjZcse8MJmUwdexyW/wRITd6e+VAjrShQc63Dcq/mnfF4v+qYOHj zcRMiHG+o506gALeOvDu8/EjSNpsYQ3UerkAJdR/SSv8C7pyB0FZD2CabTrD5kZZRNcl pOfxMTkh5R3af8ljmqEq0TfOcFXe1X3v6R91roJ83vLq5gq7gdwEA+rbh7p4vZkVYG3O 27R6NRLqF1ChJdui6artAEN6kepT8vCNeFS7pt4fQd8S/WhZ+X8uYZYKKKx3YuRUZjkh Fabw==
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=DDVJKmbYoeZO+XYbKcpbEsn1NIAyLpbApgk9hs9iVQc=; b=NdOcx70VKmdjUKVyjoNmrwfMdXocU9dgDnKLE1Wc+TyYjeG1GR0UQJ4FNznmJDm4Yg KwWY4LHLhdwxHkKtSC4jC0QiRT7Ynr2LIFHsVGKfGSTr1Ifi0uF5Nb586O8V+1vE1cXb i/1XAcr7jKlXHB7plNqKDkZpecoHry9R0i2R1iw9cpMDpjasDaahVHv40ZT4iklyxGJB 2FiXaV0vS68rNr7gbTorvKOs33zyxtX6KOJisX8qxnztIYtI6GXZx/KoQdQRYt6GbWiH B8IXNi1VmLduYYjpjcFwd+Ynp9T4U6nUuv10uit805meREDIYi1Q/b4DoCs+A8DgDT+x Y3AQ==
X-Gm-Message-State: AOAM531viRudWi2V2URfWqk52aGeoJLx4fFvfUrRX8BmCKzQbJDwrXAu 2gyG7bJg6N44i1HwTu5zyBu4WbGHfiSsfFYbC34=
X-Google-Smtp-Source: ABdhPJzGk9jPX2nuLUKobvb12BJ5NMtN3yxeGJdfwTEADSkBpyF8ZXnFYTmMQCP4Fcj0okvkJdC7qnVJKUqVbx3vmyw=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr23002467ljh.110.1594234752566;  Wed, 08 Jul 2020 11:59:12 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>  
In-Reply-To: 
From: Dick Hardt 
Date: Wed, 8 Jul 2020 11:58:36 -0700
Message-ID: 
To: Stephen Moore 
Cc: Justin Richer , txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001d8f5f05a9f2b40f"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 08 Jul 2020 18:59:18 -0000

--0000000000001d8f5f05a9f2b40f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Steve

XAuth does make use of polymorphism, just not with JSON types. The
authorization object has a "type" property that indicates the semantics of
the rest of the authorization properties.

Justin's statement:

"the XAuth protocol was not designed with polymorphism as a tool to
consider"

seemed pretty clear to me that Justin stated that I did not consider
polymorphism in the design of the XAuth protocol, but to confirm, I asked
him to clarify, but have yet to get a response on the list.

Justin has stated:

"GNAP should make use of a polymorphic protocol structure"

and then later:

"I think polymorphism should be one of the tools in consideration from the
start."

Which statement is his position?

While my comments were personal in nature as I was commenting on Justin's
response, they were not intended as an attack on Justin. In expressing my
disappointment in not getting a response from Justin, my frustration came
through and I apologize to the list and Justin for what I see could be
construed as counter productive.


/Dick



On Wed, Jul 8, 2020 at 11:09 AM Stephen Moore  wrote:

> Hi Dick,
> I've looked over your draft, and the emails here. You said you didn't use
> polymorphism, and the draft does not appear to use polymorphism. I'd thin=
k
> it is safe to say that the XAuth protocol was not built with polymorphism
> in mind. I don't think that Justin meant to imply you didn't consider it,
> but rather that from the discussions (up to that point) and the draft
> itself, it doesn't say polymorphism is a tool that can be applied in the
> tokens.
>
> As for the "GNAP should make use of a polymorphic protocol structure",
> that's just his position on what he thinks GNAP should do. I don't really
> see how that is a 'mistake'.
> -steve
>
> On Wed, Jul 8, 2020 at 12:55 PM Dick Hardt  wrote:
>
>> Justin: it is disappointing that you deflect from responding to:
>>
>> It=E2=80=99s not surprising that this is the case, as the XAuth protocol=
 was not
>>> designed with polymorphism as a tool to consider. This is exactly the
>>> reason that I say we should have polymorphism in the toolbox from the
>>> start, as it allows us to avoid this kind of awkwardness in many cases.
>>>
>>
>>  What evidence do you have to make this statement? "XAuth protocol was
>> not designed with polymorphism as a tool to consider"
>>
>> Similarly, you deflected responding to your statement:
>>
>> "GNAP should make use of a polymorphic protocol structure"
>>
>> How are we going to have a productive conversation when you won't
>> acknowledge mistakes, either intentional, or unintentional?
>>
>> wrt. your proposal to represent an authorization request as an array of
>> scopes is overly simplistic. Both XYZ and XAuth represent the request as=
 an
>> object to enable a request richer than just an array of scopes.
>>
>> /Dick
>>
>>
>>
>> On Wed, Jul 8, 2020 at 7:03 AM Justin Richer  wrote:
>>
>>> I=E2=80=99m glad that you=E2=80=99re looking at polymorphism as a possi=
ble solution to
>>> this, though I would contend that this particular style of polymorphism=
 is
>>> not doing much more than pushing the mutual-exclusivity check down a la=
yer
>>> instead of solving it.
>>>
>>> Using multiple types can in fact solve this problem, and several others=
,
>>> as long as you=E2=80=99re willing to let go of the syntax that OAuth 2 =
invented to
>>> solve a problem that we don=E2=80=99t have to solve here (passing an ar=
ray-type
>>> value over the front channel). In XYZ=E2=80=99s syntax, the request for=
 a single
>>> access token would look like this:
>>>
>>> {
>>>   =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=
=E2=80=9D ]
>>> }
>>>
>>> And the request for the multiple access tokens would look like this:
>>>
>>> {
>>>   =E2=80=9Cresources": {
>>>      =E2=80=9Creader": [ =E2=80=9Cread=E2=80=9D ],
>>>      =E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
>>>   }
>>> }
>>>
>>> I find this to be much simpler to parse and generate, as you no longer
>>> need to check for a specially-reserved field name (=E2=80=9Ctype=E2=80=
=9D), and you no
>>> longer have to do a sub-parse on one of the values to get what you real=
ly
>>> want (the space-separated scope string into a set). It=E2=80=99s also a=
 lot simpler
>>> for the developers that need to write this.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 7, 2020, at 7:30 PM, Dick Hardt  wrote:
>>>
>>>
>>>
>>> On Tue, Jul 7, 2020 at 3:40 AM Justin Richer  wrote:
>>>
>>>> I wanted to respond to this comment more fully:
>>>>
>>>> > wrt. my authorization / authorizations oddness, polymorphism would
>>>> not solve it as the contents of both authorization / authorizations in
>>>> XAuth are objects.
>>>>
>>>> It=E2=80=99s not surprising that this is the case, as the XAuth protoc=
ol was
>>>> not designed with polymorphism as a tool to consider. This is exactly =
the
>>>> reason that I say we should have polymorphism in the toolbox from the
>>>> start, as it allows us to avoid this kind of awkwardness in many cases=
.
>>>>
>>>
>>>  What evidence do you have to make this statement? "XAuth protocol was
>>> not designed with polymorphism as a tool to consider"
>>>
>>> It sounds like you are saying I did not consider polymorphism in the
>>> XAuth protocol design.
>>>
>>> I will restate my comment above about polymorphism.
>>>
>>> Using different JSON types does not solve the problem, but as I suggest
>>> in my comments, polymorphism of different JSON objects is one solution.=
 An
>>> authorization, or a dictionary of authorizations. It has the restrictio=
n
>>> that the string "type" cannot be used as a label in the dictionary. An
>>> example:
>>>
>>> {
>>>     "authorizations" {
>>>         "type": "oauth_scope",
>>>         "scope": "read write"
>>>     }
>>> }
>>>
>>> {
>>>     "authorizations" {
>>>         "reader": {
>>>             "type": "oauth_scope",
>>>             "scope": "read"
>>>         },
>>>         "writer": {
>>>             "type": "oauth_scope",
>>>             "scope": "write"
>>>         },
>>>     }
>>> }
>>>
>>>
>>> I am looking at making this change in XAuth and in the implementation.
>>>
>>>
>>>
>>> =E1=90=A7
>>>
>>>
>>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> =E1=90=A7

--0000000000001d8f5f05a9f2b40f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Steve

XAuth does ma=
ke use of polymorphism, just not with JSON types. The authorization object =
has a "type" property that indicates the semantics of the rest of=
 the authorization properties.=C2=A0

Justin's =
statement:

"the XAuth protocol was not design=
ed with polymorphism as a tool to consider"

s=
eemed pretty clear to me that Justin stated that I did not consider polymor=
phism in the design of the XAuth protocol,=C2=A0but to confirm, I asked him=
 to clarify, but have yet to get a response on the list.

Justin has stated:

"GNAP should make u=
se of a polymorphic protocol structure"

a=
nd then later:

"I think polymorphism should b=
e one of the tools in consideration from the
start."
=

Which statement=C2=A0is his position?

While my comments were personal in nature as I was commenting on Justin&=
#39;s response, they were not intended as an attack on Justin. In expressin=
g my disappointment in not getting a response from Justin, my frustration c=
ame through and I apologize to the list and Justin for what I see could be =
construed as counter productive.


/D=
ick



On Wed, Jul 8, 2020 at 11:09 AM Step=
hen Moore <srmoore@gmail.com>=
; wrote:
Hi Dick,=C2=A0
I've looked over your draft, an=
d the emails here. You said you didn't use polymorphism, and the draft =
does not appear to use polymorphism. I'd think it is safe to say that t=
he XAuth protocol was not built with polymorphism in mind. I don't thin=
k that Justin meant to imply you didn't consider it, but rather that fr=
om the discussions (up to that point) and the draft itself, it doesn't =
say polymorphism is a tool that can be applied in the tokens.
As for the "GNAP should make use of a polymorphic protocol=
 structure", that's just his position on what he thinks GNAP shoul=
d do. I don't really see how that is a 'mistake'.
-st=
eve

On Wed, Jul 8, 2020 at 12:55 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Justin: it is disappointing=
=C2=A0that you deflect from responding to:=C2=A0

It=E2=80=
=99s not surprising that this is the case, as the XAuth protocol was not de=
signed with polymorphism as a tool to consider. This is exactly the reason =
that I say we should have polymorphism in the toolbox from the start, as it=
 allows us to avoid this kind of awkwardness in many cases.

=C2=A0What evidence do you have to make this statement=
? "XAuth protocol was not designed with polymorphism as a tool to cons=
ider"
Similarly,=
 you deflected responding to your statement:

"GNAP should make use of a polymorp=
hic protocol structure"
<=
br>
How are we going to have a productive conversation when you w=
on't acknowledge mistakes, either intentional, or unintentional?
<=
div>
w=
rt. your proposal to represent an authorization=C2=A0request as an array of=
 scopes is overly simplistic. Both XYZ and XAuth represent the request as a=
n object to enable a request richer than just an array of scopes.=C2=A0

/Dick



On Wed, Jul 8, 2020 at 7:=
03 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m glad that you=E2=80=99re looking at polym=
orphism as a possible solution to this, though I would contend that this pa=
rticular style of polymorphism is not doing much more than pushing the mutu=
al-exclusivity check down a layer instead of solving it.=C2=A0

Using multiple types can in fact solve this problem, and several oth=
ers, as long as you=E2=80=99re willing to let go of the syntax that OAuth 2=
 invented to solve a problem that we don=E2=80=99t have to solve here (pass=
ing an array-type value over the front channel). In XYZ=E2=80=99s syntax, t=
he request for a single access token would look like this:

{
=C2=A0 =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cread=E2=
=80=9D, =E2=80=9Cwrite=E2=80=9D ]
}

And =
the request for the multiple access tokens would look like this:
=

{
=C2=A0 =E2=80=9Cresources": {
=C2=
=A0 =C2=A0 =C2=A0=E2=80=9Creader": [ =E2=80=9Cread=E2=80=9D ],
=C2=A0 =C2=A0 =C2=A0=E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D =
]
=C2=A0 }
}

I find this to be=
 much simpler to parse and generate, as you no longer need to check for a s=
pecially-reserved field name (=E2=80=9Ctype=E2=80=9D), and you no longer ha=
ve to do a sub-parse on one of the values to get what you really want (the =
space-separated scope string into a set). It=E2=80=99s also a lot simpler f=
or the developers that need to write this.

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

On Jul 7=
, 2020, at 7:30 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Tue, Jul 7, 2020 at 3:40 AM Justin Richer=
 <jricher@mit.edu> wrote:
I =
wanted to respond to this comment more fully:



> wrt. my authorization / authorizations oddness, polymorphism would not=
 solve it as the contents of both authorization / authorizations in XAuth a=
re objects. 



It=E2=80=99s not surprising that this is the case, as the XAuth protocol wa=
s not designed with polymorphism as a tool to consider. This is exactly the=
 reason that I say we should have polymorphism in the toolbox from the star=
t, as it allows us to avoid this kind of awkwardness in many cases.

=C2=A0What evidence do you have to make this s=
tatement? "XAuth protocol was not designed with polymorphism as a tool=
 to consider"

It sounds like you are sayi=
ng I did not consider polymorphism in the XAuth protocol design.
=

I will restate my comment above about polymorphism.=C2=A0

Using different JSON types does not solve the proble=
m, but as I suggest in my comments, polymorphism of different JSON objects =
is one solution. An authorization, or a dictionary of authorizations. It ha=
s the restriction that the string "type" cannot be used as a labe=
l in the dictionary. An example:

{
=C2=A0 =C2=
=A0 "authorizations" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type&=
quot;: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope&=
quot;: "read write"
=C2=A0 =C2=A0 }
}

{
=C2=A0 =
=C2=A0 "authorizations" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "re=
ader": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type"=
: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu=
ot;scope": "read"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "writer": {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "type": "oauth_scope",
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": "write"
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 }
}


I am looking at making this change in XAuth and in the=
 implementation.



3D""=E1=90=A7




-- 

Txauth mailing list

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




3D""=
=E1=90=A7


--0000000000001d8f5f05a9f2b40f--


From nobody Wed Jul  8 12: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 A5A603A07B0 for ; Wed,  8 Jul 2020 12:16:42 -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 vWyBamx0RRM5 for ; Wed,  8 Jul 2020 12:16:40 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 236413A07C7 for ; Wed,  8 Jul 2020 12:16:39 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id z24so30637268ljn.8 for ; Wed, 08 Jul 2020 12:16: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=tHneHp04SrN5ZWi9JaHoTgXTkJ5AfrkEXApzY15Eun0=; b=h4y9xfdFwVU3bcuj4hz6pIT2UAgsUzcqg7XdQgEDHS3CPyMVSUQi5gXKHPaKqrZV8f LsAasOoefUk4OYoJWw/pyAJg8shROQvjlXY/0rtB8TVE6c2cpWwOqh3Fj4p60zgToqEU /t05ELKpaX1QjYys3/h5j6ZMsiOdNmfT4Khk90bb4P9F+GzLczMo1zyJwOp2bwe69N+R sMpjN6qapiON0D7LJwl1K479ljOt/9PJFLQ7yekEkaOD9nC3xeDaokP3x2O4Mm548q6w QvUs+iSehw9njvSGtT4NzIFH5C0ah754jAdq8ALeHsfbhMJX4dBzMx6y/xnKZVmlaVSl Y52Q==
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=tHneHp04SrN5ZWi9JaHoTgXTkJ5AfrkEXApzY15Eun0=; b=UeNAT/EPSAd0iIegzCfF13DU8Oheh5Npdir+1j9aXCkJA/1fI92Qb3DnFJLipD7H9L EjTcGss2B8voNKPxiBeanEwa9gpLw5FOnMwWxtLajDK0x6Vo3Tg9HajNSOqiOgoUzjbq oF39ct92nkI6HJTPRwczB17p/uc4PlTqAU0wKoe0aTDl7caO1UAup4NZ/4ZehDuPjOnJ EXi2VdeEb6G0tof+CLQ0t/5c8p9tzcwO8nTE0YSMp4DDt11w0gomSbPMDyYo8/FJZmyL 5sDFttJolHm84S0FRh5G6nTDZlAShxaAi/Q/fwQ7L0MZX794xEK8JcozlOmH1CyiK8iA GjHA==
X-Gm-Message-State: AOAM531RBpxUPiEBU/bqcbc3+/aJp43AJNjQzcpXDHCFnw9fx9wQ8TW/ NNywWHetVCLgUwnguq/qMBfXrWXFzSUWnOAvvhM=
X-Google-Smtp-Source: ABdhPJzTmsjd2KUnPyF5jKV3onSChhjR1kwiCvGXGL60O572btl6aG547Hw8969dHXJfHsDsHBVSrpxETC1LeKgM01I=
X-Received: by 2002:a2e:8316:: with SMTP id a22mr11240163ljh.246.1594235797173;  Wed, 08 Jul 2020 12:16:37 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>  
In-Reply-To: 
From: Dick Hardt 
Date: Wed, 8 Jul 2020 12:16:00 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000060fb5405a9f2f2a0"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 08 Jul 2020 19:16:49 -0000

--00000000000060fb5405a9f2f2a0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think representing the request as an array is simplistic, and complicated
at the same time.

On the simplistic front, as there is no clear mechanism for extending the
request with properties that apply to all of the request.

Using JSON type polymorphism requires the AS to test each member of the
array to determine if it is a string or an object. Only after detecting a
RAR object does the AS know the client is making a RAR request. This also
limits the request to be composed only of scope strings or RAR objects. I
don't see how other strings or objects could be used in the array, so there
is no clear extension point in the "resources" array for other query
mechanisms.

Just as RAR has a "type" property, I propose the "resources"
("authorizations" in XAuth) be an object, where the other properties are
determined by the "type" property. This allows extensions to define new
ways to query for an authorization rather than having to fit into scopes or
RAR.

/Dick



On Wed, Jul 8, 2020 at 10:46 AM Justin Richer  wrote:

> I=E2=80=99m going to clip the personal attack here on the list and focus =
on the
> technical discussion, if that=E2=80=99s ok with everyone...
>
>
> wrt. your proposal to represent an authorization request as an array of
> scopes is overly simplistic. Both XYZ and XAuth represent the request as =
an
> object to enable a request richer than just an array of scopes.
>
>
> I=E2=80=99m not sure why you think it=E2=80=99s overly simplistic: the ex=
ample I have
> given is valid XYZ syntax that would exist at the root of the client=E2=
=80=99s
> request. Yes, XYZ *also* allows objects within the same array, to allow
> for richer requests, but it does not require you do that. This is again o=
ne
> of the values of doing polymorphism in this particular way. It=E2=80=99s =
as
> simplistic or as complex as you need it to be, but it=E2=80=99s consisten=
t in its
> model and presentation for both parsing and generation. So let=E2=80=99s =
take your
> example of =E2=80=9Cread=E2=80=9D and =E2=80=9Cwrite=E2=80=9D scopes. If =
a client needs to do this, but
> also needs to do a rich request, it can put them all together like this:
>
> {
>   =E2=80=9Cresources=E2=80=9D: [
>     =E2=80=9Cread=E2=80=9D,
>     =E2=80=9Cwrite=E2=80=9D,
>     {
>       "type": "payment_initiation",
>       "locations": [
>          "https://example.com/payments"
>       ],
>       "instructedAmount": {
>          "currency": "EUR",
>          "amount": "123.50"
>       },
>       "creditorName": "Merchant123",
>       "creditorAccount": {
>          "iban": "DE02100100109307118603"
>       },
>       "remittanceInformationUnstructured": "Ref Number Merchant"
>    }
>   ]
> }
>
> Notice that the =E2=80=9Cresources=E2=80=9D element is an array here. The=
 first two
> elements of the array are strings =E2=80=94 scopes. The third element of =
the array
> is an object =E2=80=94 the multi-dimensional request (this example taken =
from the
> RAR spec). But it=E2=80=99s always a =E2=80=9Clist of things that I want=
=E2=80=9D. Some of those
> things are references as strings, some of them are multi-dimensional
> specific rich objects.
>
> This has been in XYZ=E2=80=99s design and implementations for well over a=
 year,
> and it works well. This is also the basis that I=E2=80=99ve used for impl=
ementing
> XYZ on top of an old OAuth 2 server, which doesn=E2=80=99t speak RAR or a=
ny rich
> requests but knows how to dispatch against scopes.
>
>  =E2=80=94 Justin
>
>
> /Dick
>
>
>
> On Wed, Jul 8, 2020 at 7:03 AM Justin Richer  wrote:
>
>> I=E2=80=99m glad that you=E2=80=99re looking at polymorphism as a possib=
le solution to
>> this, though I would contend that this particular style of polymorphism =
is
>> not doing much more than pushing the mutual-exclusivity check down a lay=
er
>> instead of solving it.
>>
>> Using multiple types can in fact solve this problem, and several others,
>> as long as you=E2=80=99re willing to let go of the syntax that OAuth 2 i=
nvented to
>> solve a problem that we don=E2=80=99t have to solve here (passing an arr=
ay-type
>> value over the front channel). In XYZ=E2=80=99s syntax, the request for =
a single
>> access token would look like this:
>>
>> {
>>   =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=
=E2=80=9D ]
>> }
>>
>> And the request for the multiple access tokens would look like this:
>>
>> {
>>   =E2=80=9Cresources": {
>>      =E2=80=9Creader": [ =E2=80=9Cread=E2=80=9D ],
>>      =E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
>>   }
>> }
>>
>> I find this to be much simpler to parse and generate, as you no longer
>> need to check for a specially-reserved field name (=E2=80=9Ctype=E2=80=
=9D), and you no
>> longer have to do a sub-parse on one of the values to get what you reall=
y
>> want (the space-separated scope string into a set). It=E2=80=99s also a =
lot simpler
>> for the developers that need to write this.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 7, 2020, at 7:30 PM, Dick Hardt  wrote:
>>
>>
>>
>> On Tue, Jul 7, 2020 at 3:40 AM Justin Richer  wrote:
>>
>>> I wanted to respond to this comment more fully:
>>>
>>> > wrt. my authorization / authorizations oddness, polymorphism would no=
t
>>> solve it as the contents of both authorization / authorizations in XAut=
h
>>> are objects.
>>>
>>> It=E2=80=99s not surprising that this is the case, as the XAuth protoco=
l was not
>>> designed with polymorphism as a tool to consider. This is exactly the
>>> reason that I say we should have polymorphism in the toolbox from the
>>> start, as it allows us to avoid this kind of awkwardness in many cases.
>>>
>>
>>  What evidence do you have to make this statement? "XAuth protocol was
>> not designed with polymorphism as a tool to consider"
>>
>> It sounds like you are saying I did not consider polymorphism in the
>> XAuth protocol design.
>>
>> I will restate my comment above about polymorphism.
>>
>> Using different JSON types does not solve the problem, but as I suggest
>> in my comments, polymorphism of different JSON objects is one solution. =
An
>> authorization, or a dictionary of authorizations. It has the restriction
>> that the string "type" cannot be used as a label in the dictionary. An
>> example:
>>
>> {
>>     "authorizations" {
>>         "type": "oauth_scope",
>>         "scope": "read write"
>>     }
>> }
>>
>> {
>>     "authorizations" {
>>         "reader": {
>>             "type": "oauth_scope",
>>             "scope": "read"
>>         },
>>         "writer": {
>>             "type": "oauth_scope",
>>             "scope": "write"
>>         },
>>     }
>> }
>>
>>
>> I am looking at making this change in XAuth and in the implementation.
>>
>>
>>
>> =E1=90=A7
>>
>>
>>
> =E1=90=A7

--00000000000060fb5405a9f2f2a0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think representing the request as an ar=
ray is simplistic, and complicated at the same time.

On =
the simplistic front, as there is no clear mechanism for extending the requ=
est with properties that apply to all of the request.=C2=A0

<=
/div>
Using JSON type polymorphism=C2=A0requires the AS to test each me=
mber of the array to determine if it is a string or an object. Only after d=
etecting a RAR object does the AS know the client is making a RAR request. =
This also limits the request to be composed only of scope strings or RAR ob=
jects. I don't see how other strings or objects could be used in the ar=
ray, so there is no clear extension point in the "resources" arra=
y for other query mechanisms.

Just as RAR has a &q=
uot;type" property, I propose the "resources" ("authori=
zations" in XAuth) be an object, where the other properties are determ=
ined by the "type" property. This allows extensions to define new=
 ways to query for an authorization rather than having to fit into scopes o=
r RAR.

/Dick



On=
 Wed, Jul 8, 2020 at 10:46 AM Justin Richer <jricher@mit.edu> wrote:
=
I=E2=80=99m going to clip the personal attack here on the list and focus on=
 the technical discussion, if that=E2=80=99s ok with everyone...
=


<=
font color=3D"#500050">wrt. your proposal to represent an authorization=C2=
=A0request as an array of scopes is overly simplistic. Both XYZ and XAuth r=
epresent the request as an object to enable a request richer than just an a=
rray of scopes.=C2=A0

I=E2=80=99m not sure why you think it=E2=80=99s overly simp=
listic: the example I have given is valid XYZ syntax that would exist at th=
e root of the client=E2=80=99s request. Yes, XYZ=C2=A0also=C2=A0allo=
ws objects within the same array, to allow for richer requests, but it does=
 not require you do that. This is again one of the values of doing polymorp=
hism in this particular way. It=E2=80=99s as simplistic or as complex as yo=
u need it to be, but it=E2=80=99s consistent in its model and presentation =
for both parsing and generation. So let=E2=80=99s take your example of =E2=
=80=9Cread=E2=80=9D and =E2=80=9Cwrite=E2=80=9D scopes. If a client needs t=
o do this, but also needs to do a rich request, it can put them all togethe=
r like this:

{
=C2=A0 =E2=80=9Creso=
urces=E2=80=9D: [=C2=A0
=C2=A0 =C2=A0 =E2=80=9Cread=E2=80=9D,=C2=
=A0
=C2=A0 =C2=A0 =E2=80=9Cwrite=E2=80=9D,
=C2=A0 =C2=
=A0 {
=C2=A0 =C2=A0 =C2=A0 "type": "payment_initia=
tion",
=C2=A0 =C2=A0 =C2=A0 "locations": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"https://example.com/payments"
=C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 "instructedAmo=
unt": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"currency&quo=
t;: "EUR",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"amou=
nt": "123.50"
=C2=A0 =C2=A0 =C2=A0 },
=
=C2=A0 =C2=A0 =C2=A0 "creditorName": "Merchant123",
=C2=A0 =C2=A0 =C2=A0 "creditorAccount": {
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0"iban": "DE02100100109307118603&=
quot;
=C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 &quo=
t;remittanceInformationUnstructured": "Ref Number Merchant"<=
/div>
=C2=A0 =C2=A0}
=C2=A0=C2=A0]
}

=

Notice that the =E2=80=9Cresources=E2=80=9D element is an =
array here. The first two elements of the array are strings =E2=80=94 scope=
s. The third element of the array is an object =E2=80=94 the multi-dimensio=
nal request (this example taken from the RAR spec). But it=E2=80=99s always=
 a =E2=80=9Clist of things that I want=E2=80=9D. Some of those things are r=
eferences as strings, some of them are multi-dimensional specific rich obje=
cts.

This has been in XYZ=E2=80=99s design and imp=
lementations for well over a year, and it works well. This is also the basi=
s that I=E2=80=99ve used for implementing XYZ on top of an old OAuth 2 serv=
er, which doesn=E2=80=99t speak RAR or any rich requests but knows how to d=
ispatch against scopes.=C2=A0

=C2=A0=E2=80=94 Just=
in


/Dick



On Wed, Jul 8, 2020 =
at 7:03 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m glad that you=E2=80=99re looking at =
polymorphism as a possible solution to this, though I would contend that th=
is particular style of polymorphism is not doing much more than pushing the=
 mutual-exclusivity check down a layer instead of solving it.=C2=A0
Using multiple types can in fact solve this problem, and severa=
l others, as long as you=E2=80=99re willing to let go of the syntax that OA=
uth 2 invented to solve a problem that we don=E2=80=99t have to solve here =
(passing an array-type value over the front channel). In XYZ=E2=80=99s synt=
ax, the request for a single access token would look like this:
<=
br>
{
=C2=A0 =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cre=
ad=E2=80=9D, =E2=80=9Cwrite=E2=80=9D ]
}

And the request for the multiple access tokens would look like this:
=


{
=C2=A0 =E2=80=9Cresources": {
=C2=A0 =C2=A0 =C2=A0=E2=80=9Creader": [ =E2=80=9Cread=E2=80=9D ],
=C2=A0 =C2=A0 =C2=A0=E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=
=80=9D ]
=C2=A0 }
}

I find thi=
s to be much simpler to parse and generate, as you no longer need to check =
for a specially-reserved field name (=E2=80=9Ctype=E2=80=9D), and you no lo=
nger have to do a sub-parse on one of the values to get what you really wan=
t (the space-separated scope string into a set). It=E2=80=99s also a lot si=
mpler for the developers that need to write this.

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

On=
 Jul 7, 2020, at 7:30 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

<=
div dir=3D"ltr">


<=
div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 7, 2020 at 3:40 AM Justin =
Richer <jricher@mit=
.edu> wrote:
I wanted to respond to this comment more fully:



> wrt. my authorization / authorizations oddness, polymorphism would not=
 solve it as the contents of both authorization / authorizations in XAuth a=
re objects. 



It=E2=80=99s not surprising that this is the case, as the XAuth protocol wa=
s not designed with polymorphism as a tool to consider. This is exactly the=
 reason that I say we should have polymorphism in the toolbox from the star=
t, as it allows us to avoid this kind of awkwardness in many cases.

=C2=A0What evidence do you have to make this s=
tatement? "XAuth protocol was not designed with polymorphism as a tool=
 to consider"

It sounds like you are sayi=
ng I did not consider polymorphism in the XAuth protocol design.
=

I will restate my comment above about polymorphism.=C2=A0

Using different JSON types does not solve the proble=
m, but as I suggest in my comments, polymorphism of different JSON objects =
is one solution. An authorization, or a dictionary of authorizations. It ha=
s the restriction that the string "type" cannot be used as a labe=
l in the dictionary. An example:

{
=C2=A0 =C2=
=A0 "authorizations" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type&=
quot;: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope&=
quot;: "read write"
=C2=A0 =C2=A0 }
}

{
=C2=A0 =
=C2=A0 "authorizations" {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "re=
ader": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type"=
: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu=
ot;scope": "read"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "writer": {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "type": "oauth_scope",
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": "write"
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 }
}


I am looking at making this change in XAuth and in the=
 implementation.



3D""=E1=90=A7






3D""=E1=90=
=A7


--00000000000060fb5405a9f2f2a0--


From nobody Wed Jul  8 13:02: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 B6B453A07A1 for ; Wed,  8 Jul 2020 13:02:17 -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 TFSxGltH51Nm for ; Wed,  8 Jul 2020 13:02: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 3882C3A07A2 for ; Wed,  8 Jul 2020 13:02:13 -0700 (PDT)
Received: from [192.168.1.7] (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 068K2BGH028128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Jul 2020 16:02:11 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_326DB65B-BB0B-4378-A729-BFDC20322A20"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 8 Jul 2020 16:02:11 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 08 Jul 2020 20:02:18 -0000

--Apple-Mail=_326DB65B-BB0B-4378-A729-BFDC20322A20
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Jul 8, 2020, at 3:16 PM, Dick Hardt  wrote:
>=20
> I think representing the request as an array is simplistic, and =
complicated at the same time.
>=20
> On the simplistic front, as there is no clear mechanism for extending =
the request with properties that apply to all of the request.=20

The elements of the array are taken as a set, to be tied to the same =
resulting access token. If one of those elements is defined, by the AS =
and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some or =
all of the other elements, then that=E2=80=99s up to the AS=E2=80=99s =
policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, which =
switches on all sorts of contextual stuff in the request. So to handle =
something like this, an AS can easily declare that a given scope-style =
string or a given object property applies to different parts of the =
request. You don=E2=80=99t need to externalize it here.

Do you have a concrete use case that requires that feature to be done in =
the way that you describe? I am trying to separate the driving use case =
from the proposed solutions to see what the differences are.=20

>=20
> Using JSON type polymorphism requires the AS to test each member of =
the array to determine if it is a string or an object. Only after =
detecting a RAR object does the AS know the client is making a RAR =
request.

That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole =
resources request in order to figure out what the client is asking for, =
anyway, whether it=E2=80=99s by strings or objects or whatever else =
might be defined by an extension. Is there an argument for having an AS =
do an early dispatch on a request before it=E2=80=99s fully parsed =
everything?

> This also limits the request to be composed only of scope strings or =
RAR objects. I don't see how other strings or objects could be used in =
the array, so there is no clear extension point in the "resources" array =
for other query mechanisms.

That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring =
that a string has to be an OAuth2-style scope. It can be, but ultimately =
it=E2=80=99s just a string that the AS can understand. And the objects =
are just that =E2=80=94 objects. If the AS understands what the object =
is, it can be a RAR object or it can be something completely =
API-specific with another query language entirely. (Point, though: RAR =
already pretty much allows this by letting them be extended infinitely, =
a feature it inherits from XYZ)

I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99s =
an array of strings or objects and each of those means the same thing, =
=E2=80=9Csomething the client is asking for=E2=80=9D.

>=20
> Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.
>=20

It=E2=80=99s my stance that this is an unnecessary limitation at this =
level. The objects within the array should be typed, like RAR, but it =
doesn=E2=80=99t make sense for the overall request to be typed. Instead, =
there should be one =E2=80=9Ctype" of query in the core, what XYZ calls =
the =E2=80=9Cresources=E2=80=9D request. Other query languages should be =
added as extensions either to the RAR-style objects (by defining a type =
at that level) or as a separate top-level member.

For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D query =
language. My current thought is that this really shouldn=E2=80=99t be a =
part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D part =
of the request, but instead as its own top-level member, like it is in =
the OIDC protocol today. The main reason for this is the nature of the =
OIDC claims language: it specifies targets for the resulting data, and =
those targets cross different ways to return things. So it doesn=E2=80=99t=
 actually affect just resources like the UserInfo Endpoint, or the ID =
Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.

To me, this remains much more understandable, extensible, and clean.

 =E2=80=94 Justin

> /Dick
>=20
>=20
>=20
> On Wed, Jul 8, 2020 at 10:46 AM Justin Richer > wrote:
> I=E2=80=99m going to clip the personal attack here on the list and =
focus on the technical discussion, if that=E2=80=99s ok with everyone...
>=20
>>=20
>> wrt. your proposal to represent an authorization request as an array =
of scopes is overly simplistic. Both XYZ and XAuth represent the request =
as an object to enable a request richer than just an array of scopes.=20
>=20
> I=E2=80=99m not sure why you think it=E2=80=99s overly simplistic: the =
example I have given is valid XYZ syntax that would exist at the root of =
the client=E2=80=99s request. Yes, XYZ also allows objects within the =
same array, to allow for richer requests, but it does not require you do =
that. This is again one of the values of doing polymorphism in this =
particular way. It=E2=80=99s as simplistic or as complex as you need it =
to be, but it=E2=80=99s consistent in its model and presentation for =
both parsing and generation. So let=E2=80=99s take your example of =
=E2=80=9Cread=E2=80=9D and =E2=80=9Cwrite=E2=80=9D scopes. If a client =
needs to do this, but also needs to do a rich request, it can put them =
all together like this:
>=20
> {
>   =E2=80=9Cresources=E2=80=9D: [=20
>     =E2=80=9Cread=E2=80=9D,=20
>     =E2=80=9Cwrite=E2=80=9D,
>     {
>       "type": "payment_initiation",
>       "locations": [
>          "https://example.com/payments "
>       ],
>       "instructedAmount": {
>          "currency": "EUR",
>          "amount": "123.50"
>       },
>       "creditorName": "Merchant123",
>       "creditorAccount": {
>          "iban": "DE02100100109307118603"
>       },
>       "remittanceInformationUnstructured": "Ref Number Merchant"
>    }
>   ]
> }
>=20
> Notice that the =E2=80=9Cresources=E2=80=9D element is an array here. =
The first two elements of the array are strings =E2=80=94 scopes. The =
third element of the array is an object =E2=80=94 the multi-dimensional =
request (this example taken from the RAR spec). But it=E2=80=99s always =
a =E2=80=9Clist of things that I want=E2=80=9D. Some of those things are =
references as strings, some of them are multi-dimensional specific rich =
objects.
>=20
> This has been in XYZ=E2=80=99s design and implementations for well =
over a year, and it works well. This is also the basis that I=E2=80=99ve =
used for implementing XYZ on top of an old OAuth 2 server, which =
doesn=E2=80=99t speak RAR or any rich requests but knows how to dispatch =
against scopes.=20
>=20
>  =E2=80=94 Justin
>=20
>=20
>> /Dick
>>=20
>>=20
>>=20
>> On Wed, Jul 8, 2020 at 7:03 AM Justin Richer > wrote:
>> I=E2=80=99m glad that you=E2=80=99re looking at polymorphism as a =
possible solution to this, though I would contend that this particular =
style of polymorphism is not doing much more than pushing the =
mutual-exclusivity check down a layer instead of solving it.=20
>>=20
>> Using multiple types can in fact solve this problem, and several =
others, as long as you=E2=80=99re willing to let go of the syntax that =
OAuth 2 invented to solve a problem that we don=E2=80=99t have to solve =
here (passing an array-type value over the front channel). In XYZ=E2=80=99=
s syntax, the request for a single access token would look like this:
>>=20
>> {
>>   =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=
=E2=80=9D ]
>> }
>>=20
>> And the request for the multiple access tokens would look like this:
>>=20
>> {
>>   =E2=80=9Cresources": {
>>      =E2=80=9Creader": [ =E2=80=9Cread=E2=80=9D ],
>>      =E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
>>   }
>> }
>>=20
>> I find this to be much simpler to parse and generate, as you no =
longer need to check for a specially-reserved field name (=E2=80=9Ctype=E2=
=80=9D), and you no longer have to do a sub-parse on one of the values =
to get what you really want (the space-separated scope string into a =
set). It=E2=80=99s also a lot simpler for the developers that need to =
write this.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 7, 2020, at 7:30 PM, Dick Hardt > wrote:
>>>=20
>>>=20
>>>=20
>>> On Tue, Jul 7, 2020 at 3:40 AM Justin Richer > wrote:
>>> I wanted to respond to this comment more fully:
>>>=20
>>> > wrt. my authorization / authorizations oddness, polymorphism would =
not solve it as the contents of both authorization / authorizations in =
XAuth are objects.=20
>>>=20
>>> It=E2=80=99s not surprising that this is the case, as the XAuth =
protocol was not designed with polymorphism as a tool to consider. This =
is exactly the reason that I say we should have polymorphism in the =
toolbox from the start, as it allows us to avoid this kind of =
awkwardness in many cases.
>>>=20
>>>  What evidence do you have to make this statement? "XAuth protocol =
was not designed with polymorphism as a tool to consider"
>>>=20
>>> It sounds like you are saying I did not consider polymorphism in the =
XAuth protocol design.
>>>=20
>>> I will restate my comment above about polymorphism.=20
>>>=20
>>> Using different JSON types does not solve the problem, but as I =
suggest in my comments, polymorphism of different JSON objects is one =
solution. An authorization, or a dictionary of authorizations. It has =
the restriction that the string "type" cannot be used as a label in the =
dictionary. An example:
>>>=20
>>> {
>>>     "authorizations" {
>>>         "type": "oauth_scope",
>>>         "scope": "read write"
>>>     }
>>> }
>>>=20
>>> {
>>>     "authorizations" {
>>>         "reader": {
>>>             "type": "oauth_scope",
>>>             "scope": "read"
>>>         },
>>>         "writer": {
>>>             "type": "oauth_scope",
>>>             "scope": "write"
>>>         },
>>>     }
>>> }
>>>=20
>>>=20
>>> I am looking at making this change in XAuth and in the =
implementation.
>>>=20
>>>=20
>>>=20
>>> =E1=90=A7
>>=20
>=20
> =E1=90=A7


--Apple-Mail=_326DB65B-BB0B-4378-A729-BFDC20322A20
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On =
Jul 8, 2020, at 3:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I =
think representing the request as an array is simplistic, and =
complicated at the same time.

On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the =
request. 

The elements of the array are taken as a set, to =
be tied to the same resulting access token. If one of those elements is =
defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s protecting, to =
apply across some or all of the other elements, then that=E2=80=99s up =
to the AS=E2=80=99s policy. Much like the =E2=80=9Copenid=E2=80=9D scope =
in OIDC, which switches on all sorts of contextual stuff in the request. =
So to handle something like this, an AS can easily declare that a given =
scope-style string or a given object property applies to different parts =
of the request. You don=E2=80=99t need to externalize it here.

Do you have a concrete use case =
that requires that feature to be done in the way that you describe? I am =
trying to separate the driving use case from the proposed solutions to =
see what the differences are. 


Using JSON type =
polymorphism requires the AS to test each member of the array to =
determine if it is a string or an object. Only after detecting a RAR =
object does the AS know the client is making a RAR request. =


That=E2=80=99s correct =E2=80=94 but the AS needs =
to parse the whole resources request in order to figure out what the =
client is asking for, anyway, whether it=E2=80=99s by strings or objects =
or whatever else might be defined by an extension. Is there an argument =
for having an AS do an early dispatch on a request before it=E2=80=99s =
fully parsed everything?

This also limits the request to be composed =
only of scope strings or RAR objects. I don't see how other strings or =
objects could be used in the array, so there is no clear extension point =
in the "resources" array for other query =
mechanisms.

That=E2=80=99s not the case in XYZ since we =
aren=E2=80=99t declaring that a string has to be an OAuth2-style scope. =
It can be, but ultimately it=E2=80=99s just a string that the AS can =
understand. And the objects are just that =E2=80=94 objects. If the AS =
understands what the object is, it can be a RAR object or it can be =
something completely API-specific with another query language entirely. =
(Point, though: RAR already pretty much allows this by letting them be =
extended infinitely, a feature it inherits from XYZ)

I=E2=80=99m proposing that we do the same thing =
with GNAP: it=E2=80=99s an array of strings or objects and each of those =
means the same thing, =E2=80=9Csomething the client is asking =
for=E2=80=9D.


Just as =
RAR has a "type" property, I propose the "resources" ("authorizations" =
in XAuth) be an object, where the other properties are determined by the =
"type" property. This allows extensions to define new ways to query for =
an authorization rather than having to fit into scopes or RAR.


It=E2=80=99s my stance that this is an unnecessary =
limitation at this level. The objects within the array should be typed, =
like RAR, but it doesn=E2=80=99t make sense for the overall request to =
be typed. Instead, there should be one =E2=80=9Ctype" of query in the =
core, what XYZ calls the =E2=80=9Cresources=E2=80=9D request. Other =
query languages should be added as extensions either to the RAR-style =
objects (by defining a type at that level) or as a separate top-level =
member.

For example, let=E2=80=99s =
take the OIDC =E2=80=9Cclaims=E2=80=9D query language. My current =
thought is that this really shouldn=E2=80=99t be a part of the =
=E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D part of the =
request, but instead as its own top-level member, like it is in the OIDC =
protocol today. The main reason for this is the nature of the OIDC =
claims language: it specifies targets for the resulting data, and those =
targets cross different ways to return things. So it doesn=E2=80=99t =
actually affect just resources like the UserInfo Endpoint, or the ID =
Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.

To me, this remains much more understandable, =
extensible, and clean.

 =E2=80=94=
 Justin

/Dick



On Wed, Jul =
8, 2020 at 10:46 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m =
going to clip the personal attack here on the list and focus on the =
technical discussion, if that=E2=80=99s ok with everyone...


wrt. your proposal to =
represent an authorization request as an array of scopes is overly =
simplistic. Both XYZ and XAuth represent the request as an object to =
enable a request richer than just an array of =
scopes. 

I=E2=80=99m not sure why =
you think it=E2=80=99s overly simplistic: the example I have given is =
valid XYZ syntax that would exist at the root of the client=E2=80=99s =
request. Yes, XYZ also allows objects within =
the same array, to allow for richer requests, but it does not require =
you do that. This is again one of the values of doing polymorphism in =
this particular way. It=E2=80=99s as simplistic or as complex as you =
need it to be, but it=E2=80=99s consistent in its model and presentation =
for both parsing and generation. So let=E2=80=99s take your example of =
=E2=80=9Cread=E2=80=9D and =E2=80=9Cwrite=E2=80=9D scopes. If a client =
needs to do this, but also needs to do a rich request, it can put them =
all together like this:

{
  =
=E2=80=9Cresources=E2=80=9D: [ 
    =
=E2=80=9Cread=E2=80=9D, 
    =
=E2=80=9Cwrite=E2=80=9D,
    {
      "type": "payment_initiation",
      "locations": [
 =
        "https://example.com/payments"
      ],
    =
  "instructedAmount": {
      =
   "currency": "EUR",
    =
     "amount": "123.50"
  =
    },
      =
"creditorName": "Merchant123",
      =
"creditorAccount": {
        =
 "iban": "DE02100100109307118603"
  =
    },
      =
"remittanceInformationUnstructured": "Ref Number Merchant"
   }
  ]
}

Notice that the =E2=80=9Cresources=E2=80=9D element is an =
array here. The first two elements of the array are strings =E2=80=94 =
scopes. The third element of the array is an object =E2=80=94 the =
multi-dimensional request (this example taken from the RAR spec). But =
it=E2=80=99s always a =E2=80=9Clist of things that I want=E2=80=9D. Some =
of those things are references as strings, some of them are =
multi-dimensional specific rich objects.

This has been in XYZ=E2=80=99s design =
and implementations for well over a year, and it works well. This is =
also the basis that I=E2=80=99ve used for implementing XYZ on top of an =
old OAuth 2 server, which doesn=E2=80=99t speak RAR or any rich requests =
but knows how to dispatch against scopes. 

 =E2=80=94 Justin


/Dick



On Wed, Jul 8, 2020 at 7:03 AM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m =
glad that you=E2=80=99re looking at polymorphism as a possible solution =
to this, though I would contend that this particular style of =
polymorphism is not doing much more than pushing the mutual-exclusivity =
check down a layer instead of solving it. 

Using multiple types can in fact solve =
this problem, and several others, as long as you=E2=80=99re willing to =
let go of the syntax that OAuth 2 invented to solve a problem that we =
don=E2=80=99t have to solve here (passing an array-type value over the =
front channel). In XYZ=E2=80=99s syntax, the request for a single access =
token would look like this:

{
  =E2=80=9Cresources=E2=80=9D: [ =
=E2=80=9Cread=E2=80=9D, =E2=80=9Cwrite=E2=80=9D ]
}

And=
 the request for the multiple access tokens would look like =
this:

{
  =E2=80=9Cresources": =
{
     =E2=80=9Creader": [ =
=E2=80=9Cread=E2=80=9D ],
    =
 =E2=80=9Cwriter=E2=80=9D: [ =E2=80=9Cwrite=E2=80=9D ]
  }
}

I find this to be much simpler to parse =
and generate, as you no longer need to check for a specially-reserved =
field name (=E2=80=9Ctype=E2=80=9D), and you no longer have to do a =
sub-parse on one of the values to get what you really want (the =
space-separated scope string into a set). It=E2=80=99s also a lot =
simpler for the developers that need to write this.

 =E2=80=94 =
Justin

On Jul 7, 2020, at 7:30 PM, =
Dick Hardt <dick.hardt@gmail.com> wrote:



On Tue, Jul 7, 2020 at 3:40 AM Justin =
Richer <jricher@mit.edu> wrote:
I wanted to respond to this =
comment more fully:



> wrt. my authorization / authorizations oddness, polymorphism would =
not solve it as the contents of both authorization / authorizations in =
XAuth are objects. 



It=E2=80=99s not surprising that this is the case, as the XAuth protocol =
was not designed with polymorphism as a tool to consider. This is =
exactly the reason that I say we should have polymorphism in the toolbox =
from the start, as it allows us to avoid this kind of awkwardness in =
many cases.

 What evidence do you have to make =
this statement? "XAuth protocol was not designed with polymorphism as a =
tool to consider"

It sounds like you are saying I did not =
consider polymorphism in the XAuth protocol design.

I will restate my =
comment above about polymorphism. 

Using different JSON types does not =
solve the problem, but as I suggest in my comments, polymorphism of =
different JSON objects is one solution. An authorization, or a =
dictionary of authorizations. It has the restriction that the string =
"type" cannot be used as a label in the dictionary. An =
example:

{
    "authorizations" {
    =
    "type": "oauth_scope",
      =
  "scope": "read write"
    }
}

{
    =
"authorizations" {
        "reader": =
{
            "type": =
"oauth_scope",
            =
"scope": "read"
        },
        "writer": {
  =
          "type": "oauth_scope",
            "scope": "write"
        },
    =
}
}


I =
am looking at making this change in XAuth and in the =
implementation.



3D""=E1=90=A7






3D""=E1=90=A7


=

--Apple-Mail=_326DB65B-BB0B-4378-A729-BFDC20322A20--


From nobody Wed Jul  8 15:06: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 BBB8D3A083F for ; Wed,  8 Jul 2020 15:06:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=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=mattr-global.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 2QRDExf7SVbw for ; Wed,  8 Jul 2020 15:06:31 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 8EFA93A083D for ; Wed,  8 Jul 2020 15:06:31 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id 80so43174011qko.7 for ; Wed, 08 Jul 2020 15:06:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattr-global.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZQoPP6JYtWgNSRnc+7QK/oPhZV1QMEqD5dvdu/F+GRU=; b=HM8OtMs3MBhUKebWu1d5DrKY/HYZSRP1gF7LECXoHTBBanR/6vMQigN0zzpiB5/TBb VHXGy86KaT6ScZaI8o180yRkl6a/NtwVhigizG/oYMiZkg6mryuEHqQv8iWj2fpPdRl6 GgMWQFzG+YggJFbmrRDPod7Sf274G7B6saduZnlNp9JG+PX61PRx21PUAIElaOW9kdnP XuTG8oZTLvbpphaTj2UsL0R+usdNBJumGwCHdydwxcRoDVVQRXY5OHXbzCjYaEkFvhlZ imMAyNOxPeUm+lEwraqvfStOx+BRn8bCFPCWIKmAjdUW6Db0wmOQjcORCtSq+fa2/oKs 82wg==
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=ZQoPP6JYtWgNSRnc+7QK/oPhZV1QMEqD5dvdu/F+GRU=; b=dV03UKaZKk6BDB1lFNMAVUONohwPygPCXz0c4l3ScHIDW+HtGmBokVXx+6D2FLgYao JL87lBPbHjd1HUjsgML6R7d8TCIZM0+Amnwq3SdnBL0IcarmOIoLgP3mf9zs7K0jzoAO 218JIazUCw4E87n1cfdsk1Wo84bfHPKZmCokJEiA/AcOzzMQospibyh60fUMTPNIYR6F ljiG1jmHpYTJ9D8VWKgVMHskxIi74rGQ/hQqo6fIhR6zRAT2eEaEt/UfMDHrL3CmG6El Jk/iD9LlU/tL8cP9iJfSZ57PfTkOFf18qO1ckI/I/bhy4QJy/I5ae9qMXVNP/xSN8u6t uVZQ==
X-Gm-Message-State: AOAM533uaocQRhN2ZHIKsyOogrzm6Jco3+LsFBjDcfOCisWRBxCTtQsA Z90JawC2Hwqop91j4dux8kK4WStUL52ffsUALt377q11Ha7EaAloi762ovkNHswrbL6QsXc3/ff Cxo52eo1Uz2WVq2tYmw==
X-Google-Smtp-Source: ABdhPJwfiehMMQtX6F485azLsDvapCGxinuaqGsIobSqMNhCSTLEeLxqPTcIQBOYZX1rYBaCR/SMi9SBeerbDknBU8A=
X-Received: by 2002:a37:af82:: with SMTP id y124mr59752199qke.254.1594245990186;  Wed, 08 Jul 2020 15:06:30 -0700 (PDT)
MIME-Version: 1.0
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <6846D2F0-5096-404B-A529-676146392F45@mit.edu> 
In-Reply-To: 
From: Tobias Looker 
Date: Thu, 9 Jul 2020 10:06:18 +1200
Message-ID: 
To: Tom Jones 
Cc: Justin Richer , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ee2a8505a9f55187"
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 08 Jul 2020 22:06:36 -0000

--000000000000ee2a8505a9f55187
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Tom,

By not creating a formal mechanism for delegation beyond the
RO->AS->Client, does not mean it wont or cannot occur. For instance if I as
a client get an access token from an AS today in OAuth2.0, I can delegate
this access to another client by giving them the access_token.

Thanks,
[image: Mattr website] 
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
[image: Mattr website]  [image: Mattr on LinkedIn]
 [image: Mattr on Twitter]
 [image: Mattr on Github]

This communication, including any attachments, is confidential. If you are
not the intended recipient, you should not read it - please contact me
immediately, destroy it, and do not copy or use any part of this
communication or disclose anything about it. Thank you. Please note that
this communication does not designate an information system for the
purposes of the Electronic Transactions Act 2002.


On Thu, Jul 9, 2020 at 6:04 AM Tom Jones 
wrote:

> I disagree with any approach that would allow the client/RP to
> delegate anything that it does not own. The RP either has that
> authority from the RO or AS, or not. Modifying the authority in any way
> should not be permitted. New RO auth would be required.
> OTOH any endpoint could be granted agency by the RO. That should not be
> conflated with an AZ token. If agency is provided by a AZ token it is
> unclear that it meets any of the various regulations.  Note that this
> comment does not apply to :"data processors" that are disclosed to the RO=
.
> Peace ..tom
>
>
> On Tue, Jul 7, 2020 at 1:39 PM Justin Richer  wrote:
>
>> I=E2=80=99ve been thinking more about these use cases, and it might help=
 us to
>> think of GNAP=E2=80=99s access tokens as capabilities in the computer se=
curity
>> sense =E2=80=94 but more specifically, capabilities that are delivered w=
ith their
>> own context for use. In that way, an otherwise naive client can be hande=
d
>> an access token and simply know exactly what to do with it. This context
>> would be delivered alongside the token, so the token material itself
>> remains opaque to the client.
>>
>> I wanted to bring up a W3C spec for a capabilities model based on linked
>> data:
>>
>> https://w3c-ccg.github.io/zcap-ld/
>>
>> Building a fully featured capabilities context is difficult, at the very
>> least. And unfortunately, I don=E2=80=99t think this spec actually gives=
 us any
>> viable solutions to work with. In particular the =E2=80=9Cactions=E2=80=
=9D section is
>> effectively blank, offloading the work to an external JSONLD process (si=
de
>> note, this is one of the problems I have with specs based on JSONLD, the=
y
>> externalize the important parts into local contexts and break
>> interoperability =E2=80=94 but I digress). But at least it=E2=80=99s ano=
ther way of looking
>> at the problem space that might be outside the familiar zone of many of =
the
>> OAuth world.
>>
>>  =E2=80=94 Justin
>>
>> On Jun 26, 2020, at 9:23 AM, Justin Richer  wrote:
>>
>> On Jun 25, 2020, at 9:07 PM, Tobias Looker 
>> wrote:
>>
>>
>> I find this feature interesting and think it could be an
>> important pattern going forward to enable an AS to be able to describe t=
he
>> utility of a token to the client, however as already pointed out in the
>> thread I think there is some potential hidden complexity that would need=
 to
>> be ironed out such that it does not make the simple things complicated.
>>
>> Justin, do you see this feature as something the client has to explicitl=
y
>> request, i.e "please give me access and instructions on how to use my
>> access" or rather that the AS would just return this information in
>> conjunction with the access token if it had it available?
>>
>>
>> This is something that I=E2=80=99d brought up as a possibility on the pr=
evious
>> thread =E2=80=94 something like a flag the client would set. This would =
be
>> especially important if the AS wants to return multiple access tokens bu=
t
>> the client requested 1, or the client requested N and the AS wants to
>> return M in response. Basically any time there=E2=80=99s a mismatch, tha=
t=E2=80=99s extra
>> complexity on the client that I really don=E2=80=99t think we want to be=
 universal.
>> A flag to turn that kind of direction and splitting on would be a potent=
ial
>> start. But there are potential snags here too, and it comes down to how =
you
>> manage the defaults...
>>
>> > This is just the start, too. Things get even more complex if the clien=
t
>> can ask for multiple different kinds of resources at once. What if the A=
S
>> decides that the client needs a hyper-focused directed token for one par=
t
>> of the API, but can use a general token for other stuff? Can it signal t=
hat
>> to the client? And if it can, does that mean that all clients need to be
>> prepared for that kind of thing?
>>
>> Would a potential default be that if a client did for any reason not
>> support processing the additional information returned with the
>> access_token, just to ignore it? I think in the spirit of keeping the
>> simple things simple, this potentially makes sense?
>>
>>
>> That=E2=80=99s the real trick, if you ask me. It has to be :safe: for a =
client to
>> ignore this information. Which means the AS can=E2=80=99t rely on the cl=
ient =E2=80=9Cdoing
>> the right thing=E2=80=9D with the information in the =E2=80=9Ctoken dire=
ctions=E2=80=9D portion of
>> the response. Even setting aside the advanced and related =E2=80=9Csplit=
 tokens=E2=80=9D
>> idea above, we need to make sure that an AS/RS setup is built such that =
if
>> the AS tells a client =E2=80=9Conly do X with your token=E2=80=9D and th=
e client does =E2=80=9CY=E2=80=9D,
>> then there are other protections and practices in place to prevent thing=
s
>> from going haywire if the client does =E2=80=9CY=E2=80=9D either by acci=
dent or through
>> ignorance.
>>
>> If OAuth 2 has taught us anything, it=E2=80=99s that client applications=
 are
>> going to be the laziest participants in the security model. And that mak=
es
>> sense, really =E2=80=94 security isn=E2=80=99t what the client apps are =
trying to do,
>> they=E2=80=99re trying to use the RS to do something. So we need to make=
 sure that
>> whatever system we design will fail on the safe side as much as possible=
,
>> and keep things simple for the client.
>>
>>
>> > here are some worked out samples of this:
>> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
>> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
>> Peace ..tom
>>
>> As one of the authors of those mentioned drafts, I am interested in
>> discussing that, but perhaps on a seperate thread? As at least the bound
>> assertion spec is primarily concerned with binding mechanisms for the
>> artifacts produced from an authorization flow (specifically identity
>> claims), whereas I think directed access tokens is just more generally
>> talking about whether GNAP should support an AS conveying how to use an
>> access_token it produces during a flow with a client.
>>
>>
>> I think that these are separate issues as well.
>>
>>  =E2=80=94 Justin
>>
>> Thanks,
>> [image: Mattr website] 
>> *Tobias Looker*
>> Mattr
>> +64 (0) 27 378 0461
>> tobias.looker@mattr.global
>> [image: Mattr website]  [image: Mattr on LinkedIn=
]
>>  [image: Mattr on Twitter]
>>  [image: Mattr on Github]
>> 
>> This communication, including any attachments, is confidential. If you
>> are not the intended recipient, you should not read it - please contact =
me
>> immediately, destroy it, and do not copy or use any part of this
>> communication or disclose anything about it. Thank you. Please note that
>> this communication does not designate an information system for the
>> purposes of the Electronic Transactions Act 2002.
>>
>>
>> On Wed, Jun 24, 2020 at 10:14 PM Denis  wrote:
>>
>>> Justin, I fear we are still far away from an agreement about what this
>>> BoF should do.
>>>
>>> Tom Jones is saying " I am getting tired of the whack-a-mole approach
>>> ..."
>>>
>>> I don't agree with you when you write: "I think it=E2=80=99s going to b=
e
>>> overwhelmingly common that a given RS is going to trust exactly one AS
>>> that it knows about ahead of time". Such an architecture would have
>>> exactly the same limitations as OAuth 2.0. and would not be scalable.
>>>
>>> Before we start, we should have a clear view of the whole picture rathe=
r
>>> than starting from one scenario and expanding it in many different
>>> directions.
>>> For building an architecture, a pre-requirement is to define ALL the
>>> trust relationships. I don't believe that we have an agreement at this =
time
>>> on what
>>> these trust relationships are.
>>>
>>> You are also using the following wording: "methods for the AS and RS to
>>> communicate what the token=E2=80=99s good for".
>>> With such a paradigm, it would be impossible to protect the user's
>>> privacy.
>>>
>>> A key question is : Will GNAP take care of the user's privacy or will
>>> GNAP *prevent *to take care of the user's privacy ?
>>>
>>> About "the ability for the client to get several access tokens to get
>>> different resources from one request" is indeed a complex case.
>>>
>>> No one (including ASs) is able to predict in advance which access token=
s
>>> will be needed, since they depend upon the kind of operation(s)
>>> the client will be willing to perform. For privacy reasons, ASs should
>>> be kept ignorant of all the operations that a client is going to perfor=
m
>>>
>>> on one or more resource servers. I believe that every effort should be
>>> made to avoid the AS to be in a position to be able to trace the operat=
ions
>>>
>>> performed by its clients on various RSs.
>>>
>>> To handle the complex case you envision, the full workflow of operation=
s
>>> needs to be considered with a detailed focus on the time
>>> at which the user's *consent and choice* happens (*consent and choice* =
is
>>> the first privacy principle from ISO 29100).
>>>
>>> First of all, an access token could be targeted to a service rather tha=
n
>>> to a server. This would already solve many cases.
>>>
>>> When a RS needs to call another RS (which does not support the same
>>> service) then the client should be informed by the first RS.
>>> His "consent and choice" should then be obtained by the first RS and,
>>> when the user agrees, the client should then ask an access token
>>> to one of the ASs trusted by the second RS in order to perform the
>>> subsequent operation.
>>>
>>> Denis
>>>
>>> PS.  In an email sent on June 23 you wrote: " I think an on-device AS i=
s
>>> an important use case".  I am sorry, but I don't understand.
>>>        However, I do understand what "a server-based AS" is.
>>>
>>>
>>> Denis, thanks for the great comments. I think that your trust model is
>>> pretty different from what I=E2=80=99d laid out initially, and while it=
=E2=80=99s an
>>> interesting and important one, it is not what I meant by =E2=80=9Cmulti=
ple access
>>> tokens=E2=80=9D in my discussion below. I think that might be the cause=
 of some
>>> disconnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of reac=
h for what the WG is
>>> after.
>>>
>>> When I refer to multiple access tokens, and what the charter calls out
>>> as multiple access tokens, is the ability for the client to get several
>>> access tokens to get different resources from one request. I personally=
 see
>>> this as an optimization of a specific set of use cases, some of which I
>>> discussed in my original email. There are others, I=E2=80=99m sure, but=
 all the
>>> ones I=E2=80=99ve seen are around the client needing to get several dif=
ferent kinds
>>> of access through an AS.
>>>
>>> I think it=E2=80=99s going to be overwhelmingly common that a given RS =
is going
>>> to trust exactly one AS that it knows about ahead of time. But for RS=
=E2=80=99s
>>> that can trust multiple AS=E2=80=99s, then we should have a model that =
can
>>> accommodate that as well. That=E2=80=99s why the charter calls out meth=
ods for the
>>> AS and RS to communicate what the token=E2=80=99s good for. I think the=
 basis of
>>> those methods is going to start with a common token model, and likely
>>> incorporate into things like token formats and introspection-style toke=
n
>>> APIs.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jun 22, 2020, at 3:55 AM, Denis  wrote:
>>>
>>> Hello Justin,
>>>
>>> A few comments between the lines.
>>>
>>> One of the most important aspects to GNAP is going to be an ability to
>>> address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do=
 without significant
>>> gymnastics. So with that, I wanted to bring back a use case discussion =
that
>>> originally came up while we were talking about the possibility of multi=
ple
>>> access tokens, a few months back. I don=E2=80=99t know if this concept =
has a
>>> regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access =
tokens=E2=80=9D until we
>>> come up with something better =E2=80=94 assuming we decide this is wort=
hwhile.
>>>
>>> I don't understand what may mean "directed access tokens=E2=80=9D but I
>>> understand what means "multiple access tokens".
>>> When speaking of "multiple access tokens", these access tokens may come
>>> from one or more ASs.
>>>
>>> In OAuth, the client=E2=80=99s supposed to always know where to send it=
s access
>>> token, and that knowledge is completely outside the protocol. This make=
s a
>>> lot of sense for many (if not most) deployments, as OAuth is really the=
re
>>> to enable the API access that the client already knows about.
>>>
>>> But we=E2=80=99re now in a world where a client could be talking to a g=
eneric
>>> API that could be deployed at a number of different places, or a cloud
>>> deployment that the AS wants to be able to dispatch the client to.
>>>
>>> As soon the AS is placed (again) at the centre of the model, the AS wil=
l
>>> have the ability to act as "Big Brother".
>>> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP
>>> should take care of them.
>>>
>>> In order to do this, the AS needs to be able to communicate to the
>>> client not only the token information (and any related key and presenta=
tion
>>> information), but also a set of *directions* about what that specific
>>> token is good for. This needs to be information outside the token itsel=
f,
>>> since I believe we want to keep OAuth 2=E2=80=99s feature of having the=
 token be
>>> opaque to the client. Note: while we could map all of these to differen=
t
>>> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlan=
ce)
>>> on the request side, this isn=E2=80=99t enough to tell the client what =
to do with
>>> the token *if it doesn=E2=80=99t know already*.
>>>
>>> I know of two use cases already in the wild, where people are addressin=
g
>>> things using a mix of existing standards and some proprietary extension=
s to
>>> address things within their silos. I=E2=80=99ll try to summarize here, =
but I know
>>> the folks I=E2=80=99ve been talking to about this are also on the list =
so hopefully
>>> they can chime in with more detail or any corrections for something I=
=E2=80=99ve
>>> missed.
>>>
>>> (1) The client knows what resource it=E2=80=99s calling, but it doesn=
=E2=80=99t know
>>> where it=E2=80=99s hosted. Everything is in a single security domain co=
ntrolled by
>>> the AS,
>>>
>>> Speaking of "multiple access tokens" is in contradiction with single
>>> security domain "controlled" by an AS.
>>> A user may need to demonstrate some of his identity attributes granted
>>> e.g. by his bank but may also
>>> need to demonstrate one or more diplomas granted by one or more
>>> universities. The bank cannot be
>>> the "primary issuer" of a university diploma. It should not be either a
>>> "secondary issuer", because
>>> the bank does not "*need to know"* what are the diplomas of the user.
>>>
>>> but the AS needs to decide at runtime which specific instance of the AP=
I
>>> to direct the client to. Since things are closely tied together, the cl=
ient
>>> just needs to effectively known an identifier for the RS, and this is
>>> currently implemented as a URI. Once the client has that identifier, it
>>> knows how to dispatch that token to that instance of the RS.
>>>
>>> There is no good reason why the AS should be involved in that step.
>>> OAuth 2.0 is/was implicitly mandating a strong relationship between ASs
>>> and RSs which makes it non scalable.
>>> GNAP should be based on a simple trust relationship : a given RS trusts
>>> some ASs for access tokens that contains some types of attributes.
>>> An AS should not need to know in advance (or even at the time of an
>>> access token request) the RSs that are trusting it.
>>>
>>> A client could first talk to a "global service provider" which has the
>>> knowledge of the different RSs affiliated to it.
>>>
>>> (2) The client knows what kind of thing it=E2=80=99s looking for, but d=
oesn=E2=80=99t
>>> know who to ask it from.
>>>
>>> Once again, the client could first talk to a "global service provider"
>>> which has the knowledge of the different RSs affiliated to it.
>>>
>>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, =
and the AS needs
>>> to dispatch to different resources depending on which user logged in (a=
nd
>>> possibly what the user consented to). To make things more concrete, the
>>> client needs to get driver=E2=80=99s license information, but doesn=E2=
=80=99t know ahead of
>>> time which of the many state/provincial bureaus to call to get that
>>> information because it doesn=E2=80=99t know yet who the user is.
>>>
>>> When a user has a driving license, he knows its issuer. The user can
>>> then provide some hint to the client.
>>>
>>> The AS will know who the user is once they log in and approve things,
>>> and so it can direct the client to call the correct RS. Since this is a
>>> relatively simple API with a pre-negotiated cross-domain trust, the AS
>>> returns a URL that the client presents the token at.
>>>
>>>  A single AS should not be aware of all the attributes a user has.
>>>
>>>
>>> As far as I know, in both of these cases, the token is only good for
>>> that API and not others =E2=80=94 but more on that later.
>>>
>>> A simple thing to do is just give back a URL with the access token,
>>> which tells the client where to go.
>>>
>>> {
>>> =E2=80=9Caccess_token=E2=80=9D: {
>>> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
>>> =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
>>> }
>>> }
>>>
>>> This is good for some kinds of APIs, but it=E2=80=99s limiting because =
not all
>>> APIs dispatch based on the URL. An AS might want to divvy up access tok=
ens
>>> to an API that=E2=80=99s keyed on headers, or verbs, or any number of t=
hings. And
>>> it doesn=E2=80=99t tell us immediately what to do about non-exact URL m=
atches. Can
>>> the client add query parameters and still use the token? What about pat=
h
>>> segments? I like that this simple approach addresses some common
>>> deployments that we already see today (see above), it=E2=80=99s not uni=
versal. Do
>>> we want or need a universal description language for directing where to=
kens
>>> go?
>>>
>>> This also opens up a whole new set of security questions. If the AS can
>>> now direct the client where to use the token, could a rogue AS convince=
 a
>>> legit client to use a stolen token at the wrong RS? And what if the cli=
ent
>>> ignores the directions from the AS entirely? Could this open up new ave=
nues
>>> of attack?
>>>
>>> This is just the start, too. Things get even more complex if the client
>>> can ask for multiple different kinds of resources at once. What if the =
AS
>>> decides that the client needs a hyper-focused directed token for one pa=
rt
>>> of the API, but can use a general token for other stuff? Can it signal =
that
>>> to the client? And if it can, does that mean that all clients need to b=
e
>>> prepared for that kind of thing?
>>>
>>> I firmly believe that whatever we build in GNAP, we need to optimize fo=
r
>>> the overwhelmingly common use case of a client getting a single access
>>> token to call APIs that it already knows about. Anything we add on top =
of
>>> that really can=E2=80=99t get in the way of this, because if it does, t=
here=E2=80=99s very
>>> small chance that people will try to use this for everyday things. Keep=
 the
>>> simple things simple, and the complex things possible, after all.
>>>
>>> I=E2=80=99m really looking forward to hearing what the community thinks=
 about
>>> these use cases, and hopefully the people I=E2=80=99ve chatted with off=
line about
>>> this can join the conversation and provide more light than I was able t=
o.
>>>
>>> The two use cases which are considered above are:
>>>
>>> (1) The client knows what resource it=E2=80=99s calling, but it doesn=
=E2=80=99t know
>>> where it=E2=80=99s hosted.
>>> (2) The client knows what kind of thing it=E2=80=99s looking for, but d=
oesn=E2=80=99t
>>> know who to ask it from.
>>>
>>> That does not mean in any way that these two use cases should be solved
>>> by placing the AS at the centre of the solution.
>>>
>>> Denis
>>>
>>>
>>>  =E2=80=94 Justin
>>>
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>> This communication, including any attachments, is confidential. If you a=
re not the intended recipient, you should not read it - please contact me i=
mmediately, destroy it, and do not copy or use any part of this communicati=
on or disclose anything about it. Thank you. Please note that this communic=
ation does not designate an information system for the purposes of the Elec=
tronic Transactions Act 2002.
>>
>>
>> --
>> Txauth mailing 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
This communication, including any attachments, is confidential. If you are=
=20
not the intended recipient, you should not read it - please contact me=20
immediately, destroy it, and do not copy or use any part of this=20
communication or disclose anything about it. Thank you. Please note that=20
this communication does not designate an information system for the=20
purposes of the Electronic Transactions Act 2002.

--000000000000ee2a8505a9f55187
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Tom,

By not creating a formal mechanism=
 for delegation beyond the RO->AS->Client, does not mean it wont or c=
annot occur. For instance if I as a client get an access token from an AS t=
oday=C2=A0in OAuth2.0, I can delegate this access to another client by givi=
ng them the access_token.

Thanks,
3D"Mattr=C2=A0<=
tbody>
Tobias Looker
Mattr
+64 (0) 27 378 0=
461
tobias.looker@mattr.global
<=
a href=3D"https://mattr.global" style=3D"border:none;color:rgb(51,49,50);ma=
rgin-right:12px" target=3D"_blank">3D"Mattr3D"Mattr3D"Mattr3D"Mattr

This comm=
unication, including any attachments, is confidential. If you are not the i=
ntended recipient, you should not read it - please contact me immediately, =
destroy it, and do not copy or use any part of this communication or disclo=
se anything about it. Thank you. Please note that this communication does n=
ot designate an information system for the purposes of the Electronic Trans=
actions Act 2002.


On Thu, Jul 9, 202=
0 at 6:04 AM Tom Jones <=
thomasclinganjones@gmail.com> wrote:
I disagree with any approach t=
hat would allow the client/RP to delegate=C2=A0anything that it does not ow=
n. The RP either has that authority=C2=A0from the RO or AS, or not. Modifyi=
ng the authority in any way should not be permitted. New=C2=A0RO auth would=
 be required.
OTOH any endpoint could be granted agency by the RO. That=
 should not be conflated with an AZ token. If agency is provided by a AZ to=
ken it is unclear that it meets any of the various regulations.=C2=A0 Note =
that this comment does not apply to :"data processors" that are d=
isclosed to the RO.
Peace ..tom


On Tue, Jul 7, 2020 at 1=
:39 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99ve been thinking more about these use case=
s, and it might help us to think of GNAP=E2=80=99s access tokens as capabil=
ities in the computer security sense =E2=80=94 but more specifically, capab=
ilities that are delivered with their own context for use. In that way, an =
otherwise naive client can be handed an access token and simply know exactl=
y what to do with it. This context would be delivered alongside the token, =
so the token material itself remains opaque to the client.

I wanted to bring up a W3C spec for a capabilities model based on linked=
 data:


=

Building a fully featured capabilities context is difficult, at the ve=
ry least. And unfortunately, I don=E2=80=99t think this spec actually gives=
 us any viable solutions to work with. In particular the =E2=80=9Cactions=
=E2=80=9D section is effectively blank, offloading the work to an external =
JSONLD process (side note, this is one of the problems I have with specs ba=
sed on JSONLD, they externalize the important parts into local contexts and=
 break interoperability =E2=80=94 but I digress). But at least it=E2=80=99s=
 another way of looking at the problem space that might be outside the fami=
liar zone of many of the OAuth world.

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

On Jun 26, 2020, at 9=
:23 AM, Justin Richer <jricher@mit.edu> wrote:

On Jun 25, 2020, at 9:07 PM, Tobias Looker <tobias.looker@m=
attr.global> wrote:<=
/span>
I find this feature interesting and think it could =
be an important=C2=A0pattern going=C2=A0forward to enable an AS to be able =
to describe the utility of a token to the client, however as already pointe=
d out in the thread I think there is some potential hidden complexity that =
would need to be ironed out such that it does not make the simple things co=
mplicated.

Justin, do you see this feature as something =
the client has to explicitly request, i.e "please give me access and i=
nstructions on how to use my access" or rather that the AS would just =
return this information in conjunction with the access token if it had it a=
vailable?


=
This is something that I=E2=80=99d brought up as a possibility on the previ=
ous thread =E2=80=94 something like a flag the client would set. This would=
 be especially important if the AS wants to return multiple access tokens b=
ut the client requested 1, or the client requested N and the AS wants to re=
turn M in response. Basically any time there=E2=80=99s a mismatch, that=E2=
=80=99s extra complexity on the client that I really don=E2=80=99t think we=
 want to be universal. A flag to turn that kind of direction and splitting =
on would be a potential start. But there are potential snags here too, and =
it comes down to how you manage the defaults...

> This is just the start, too. Thin=
gs get even more complex if the client can ask for multiple different kinds=
 of resources at once. What if the AS decides that the client needs a hyper=
-focused directed token for one part of the API, but can use a general toke=
n for other stuff? Can it signal that to the client? And if it can, does th=
at mean that all clients need to be prepared for that kind of thing?
<=
div>
Would a potential default be that if a client did for an=
y reason not support processing the additional information returned with th=
e access_token, just to ignore it? I think in the spirit of keeping the sim=
ple things simple, this potentially makes sense?

That=E2=80=99s the real trick, if you ask me. It ha=
s to be :safe: for a client to ignore this information. Which means the AS =
can=E2=80=99t rely on the client =E2=80=9Cdoing the right thing=E2=80=9D wi=
th the information in the =E2=80=9Ctoken directions=E2=80=9D portion of the=
 response. Even setting aside the advanced and related =E2=80=9Csplit token=
s=E2=80=9D idea above, we need to make sure that an AS/RS setup is built su=
ch that if the AS tells a client =E2=80=9Conly do X with your token=E2=80=
=9D and the client does =E2=80=9CY=E2=80=9D, then there are other protectio=
ns and practices in place to prevent things from going haywire if the clien=
t does =E2=80=9CY=E2=80=9D either by accident or through ignorance.=C2=A0

If OAuth 2 has taught us anything, it=E2=80=99s tha=
t client applications are going to be the laziest participants in the secur=
ity model. And that makes sense, really =E2=80=94 security isn=E2=80=99t wh=
at the client apps are trying to do, they=E2=80=99re trying to use the RS t=
o do something. So we need to make sure that whatever system we design will=
 fail on the safe side as much as possible, and keep things simple for the =
client.


<=
/div>
> here are some worked out samples of this:
Peace ..tom

As one of the authors of those mentio=
ned drafts, I am interested in discussing that, but perhaps on a seperate t=
hread? As at least=C2=A0the bound assertion spec is=C2=A0primarily=C2=A0con=
cerned with binding mechanisms for the artifacts produced from an authoriza=
tion flow (specifically identity claims), whereas I think directed access t=
okens is just more generally talking about whether GNAP should support an A=
S conveying how to use an access_token it produces during a flow with a cli=
ent.


I think that these are separate issues as well.<=
/div>

=C2=A0=E2=80=94 Justin

Thanks,
3D"Mattr=C2=A0
Tobias Looker
=

Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
3D"M==3D"Mattr3D"Ma=

This communication, includin=
g any attachments, is confidential. If you are not the intended recipient, =
you should not read it - please contact me immediately, destroy it, and do =
not copy or use any part of this communication or disclose anything about i=
t. Thank you. Please note that this communication does not designate an inf=
ormation system for the purposes of the Electronic Transactions Act 2002.


=

On Wed, Jun 24, 2020 at 10:14 PM Deni=
s <denis.ietf@fr=
ee.fr> wrote:
Justin, I fear we are still far away from an agreement about=
 what this BoF should do.

Tom Jones is saying &quo=
t; I am getting tired of the whack-a-mole approach ..."

=

I don't agree with you when you write: "I think it=E2=80=99s=
 going to be overwhelmingly common that a given RS is going to trust exactl=
y one AS=C2=A0
that it knows about ahead of time"=
. Such an architecture would have exactly the same limitations as OAuth 2.0=
. and would not be scalable.

Before we start,=
 we should have a clear view of the whole picture rather than starting from=
 one scenario and expanding it in many different directions.
For =
building an architecture, a pre-requirement is to define ALL the trust rela=
tionships. I don't believe that we have an agreement at this time on wh=
at=C2=A0
these trust relationships are.=C2=A0<=
/div>

You are also using the following wording: &q=
uot;methods for the AS and RS to communicate what the token=E2=80=99s good =
for".=C2=A0
With such a paradigm, it would be impossib=
le to protect the user's privacy.=C2=A0

=

A key question is : Will GNAP take care of the user's privac=
y or will GNAP=C2=A0prevent=C2=A0to take c=
are of the user's privacy ?

About "the ab=
ility for the client to get several access tokens to get different resource=
s from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens w=
ill be needed, since they depend upon the kind of operation(s)=C2=A0<=
/span>
the client will be willing to perform. For privacy reasons, ASs s=
hould be kept ignorant of all the operations that a client is going to perf=
orm=C2=A0
on one or more resource servers. I believe that e=
very effort should be made to avoid the AS to be in a position to be able t=
o trace the operations=C2=A0
performed by its clients on va=
rious RSs.

To handle the complex case you envision=
, the full workflow of operations needs to be considered with a detailed fo=
cus on the time=C2=A0
at which the user's=C2=A0consent and choice=C2=A0happens (consent and ch=
oice=C2=A0is the first privacy principle from ISO 29100).<=
/div>

First of all, an access token could be targeted to=
 a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not s=
upport the same service) then the client should be informed by the first RS=
.
His "consent and choice" should then be obtained by t=
he first RS and, when the user agrees, the client should then ask an access=
 token=C2=A0
to one of the ASs trusted by the second RS in =
order to perform the subsequent operation.=C2=A0=C2=A0

Denis

PS.=C2=A0 In an email =
sent on June 23 you wrote: " I think an on-device AS is an important u=
se case".=C2=A0 I am sorry, but I don't understand.
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 However, I do understand what "a server-ba=
sed AS" is.


Denis, thanks for the great comments. I think that your trust model =
is pretty different from what I=E2=80=99d laid out initially, and while it=
=E2=80=99s an interesting and important one, it is not what I meant by =E2=
=80=9Cmultiple access tokens=E2=80=9D in my discussion below. I think that =
might be the cause of some disconnect here, but that doesn=E2=80=99t mean i=
t=E2=80=99s out of reach for what the WG is after.

When =
I refer to multiple access tokens, and what the charter calls out as multip=
le access tokens, is the ability for the client to get several access token=
s to get different resources from one request. I personally see this as an =
optimization of a specific set of use cases, some of which I discussed in m=
y original email. There are others, I=E2=80=99m sure, but all the ones I=E2=
=80=99ve seen are around the client needing to get several different kinds =
of access through an AS.=C2=A0

I think it=E2=80=99s =
going to be overwhelmingly common that a given RS is going to trust exactly=
 one AS that it knows about ahead of time. But for RS=E2=80=99s that can tr=
ust multiple AS=E2=80=99s, then we should have a model that can accommodate=
 that as well. That=E2=80=99s why the charter calls out methods for the AS =
and RS to communicate what the token=E2=80=99s good for. I think the basis =
of those methods is going to start with a common token model, and likely in=
corporate into things like token formats and introspection-style token APIs=
.=C2=A0

=C2=A0=E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrot=
e:

Hello Justin,

A few comments between the lines.

One =
of the most important aspects to GNAP is going to be an ability to address =
things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do without sig=
nificant gymnastics. So with that, I wanted to bring back a use case discus=
sion that originally came up while we were talking about the possibility of=
 multiple access tokens, a few months back. I don=E2=80=99t know if this co=
ncept has a regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected=
 access tokens=E2=80=9D until we come up with something better =E2=80=94 as=
suming we decide this is worthwhile.=C2=A0
I don't understand what may mean "directed access =
tokens=E2=80=9D but I understand what means "multiple access tokens&qu=
ot;.=C2=A0
When speaking of "multiple access tokens&qu=
ot;, these access tokens may come from one or more ASs.
In OAuth, the client=E2=80=99s supposed =
to always know where to send its access token, and that knowledge is comple=
tely outside the protocol. This makes a lot of sense for many (if not most)=
 deployments, as OAuth is really there to enable the API access that the cl=
ient already knows about.

But we=E2=80=99re now in=
 a world where a client could be talking to a generic API that could be dep=
loyed at a number of different places, or a cloud deployment that the AS wa=
nts to be able to dispatch the client to.=C2=A0
As soon the AS is placed (again) at the centre of th=
e model, the AS will have the ability to act as "Big Brother".OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP shou=
ld take care of them.
In =
order to do this, the AS needs to be able to communicate to the client not =
only the token information (and any related key and presentation informatio=
n), but also a set of=C2=A0directions=C2=A0about what t=
hat specific token is good for. This needs to be information outside the to=
ken itself, since I=C2=A0believe we want to keep OAuth 2=E2=80=99s feature =
of having the token be opaque to the client. Note: while we could map all o=
f these to different resource requests (in XYZ parlance) or scopes (in OAut=
h 2 legacy parlance) on the request side, this isn=E2=80=99t enough to tell=
 the client what to do with the token=C2=A0if it doesn=E2=
=80=99t know already.=C2=A0

I know of two use =
cases already in the wild, where people are addressing things using a mix o=
f existing standards and some proprietary extensions to address things with=
in their silos. I=E2=80=99ll try to summarize here, but I know the folks I=
=E2=80=99ve been talking to about this are also on the list so hopefully th=
ey can chime in with more detail or any corrections for something I=E2=80=
=99ve missed.=C2=A0

(1) The client knows what reso=
urce it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s h=
osted. Everything is in a single security domain controlled by the AS,=C2=A0
Speaking of "multi=
ple access tokens" is in contradiction with single security domain &qu=
ot;controlled" by an AS.=C2=A0
A user may need to demo=
nstrate some of his identity attributes granted e.g. by his bank but may al=
so=C2=A0
need to demonstrate one or more diplomas granted b=
y one or more universities. The bank cannot be=C2=A0
the &q=
uot;primary issuer" of a university diploma. It should not be either a=
 "secondary issuer", because=C2=A0
the bank does =
not "need to know"=C2=A0what are the diplomas=
 of the user.
but the=
 AS needs to decide at runtime which specific instance of the API to direct=
 the client to. Since things are closely tied together, the client just nee=
ds to effectively known an identifier for the RS, and this is currently imp=
lemented as a URI. Once the client has that identifier, it knows how to dis=
patch that token to that instance of the RS.
There is no good reason why the AS should be involved in that step.<=
span>=C2=A0
OAuth 2.0 is/was implicitly mandating a strong relati=
onship between ASs and RSs which makes it non scalable.
GNAP should be b=
ased on a simple trust relationship : a given RS trusts some ASs for access=
 tokens that contains some types of attributes.
An AS should not need to=
 know in advance (or even at the time of an access token request) the RSs t=
hat are trusting it.
A client could first talk to=
 a "global service provider" which has the knowledge of the diffe=
rent RSs affiliated to it.=C2=A0
(2) The client knows what kind of thing it=E2=80=
=99s looking for, but doesn=E2=80=99t know who to ask it from.=C2=A0<=
/span>
Once again, the client could fi=
rst talk to a "global service provider" which has the knowledge o=
f the different RSs affiliated to it.=C2=A0
There=E2=80=99s a cross-domain trust that=
=E2=80=99s bridged by the AS, and the AS needs to dispatch to different res=
ources depending on which user logged in (and possibly what the user consen=
ted to). To make things more concrete, the client needs to get driver=E2=80=
=99s license information, but doesn=E2=80=99t know ahead of time which of t=
he many state/provincial bureaus to call to get that information because it=
 doesn=E2=80=99t know yet who the user is.=C2=A0
When a user has a driving license, he knows its iss=
uer. The user can then provide some hint to the client.
The AS will know who the user is once they l=
og in and approve things, and so it can direct the client to call the corre=
ct RS. Since this is a relatively simple API with a pre-negotiated cross-do=
main trust, the AS returns a URL that the client presents the token at.=C2=A0
=C2=A0A single AS =
should not be aware of all the attributes a user has.=C2=A0

As far a=
s I know, in both of these cases, the token is only good for that API and n=
ot others =E2=80=94 but more on that later.

A simp=
le thing to do is just give back a URL with the access token, which tells t=
he client where to go.=C2=A0

	{
		=
=E2=80=9Caccess_token=E2=80=9D: {
			=E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=
=9D,
			=E2=80=9Creso=
urce_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
		}
	}

This is good for some kinds of APIs, but it=E2=80=99=
s limiting because not all APIs dispatch based on the URL. An AS might want=
 to divvy up access tokens to an API that=E2=80=99s keyed on headers, or ve=
rbs, or any number of things. And it doesn=E2=80=99t tell us immediately wh=
at to do about non-exact URL matches. Can the client add query parameters a=
nd still use the token? What about path segments? I like that this simple a=
pproach addresses some common deployments that we already see today (see ab=
ove), it=E2=80=99s not universal. Do we want or need a universal descriptio=
n language for directing where tokens go?

This als=
o opens up a whole new set of security questions. If the AS can now direct =
the client where to use the token, could a rogue AS convince a legit client=
 to use a stolen token at the wrong RS? And what if the client ignores the =
directions from the AS entirely? Could this open up new avenues of attack?<=
/div>

This is just the start, too. Things get even more =
complex if the client can ask for multiple different kinds of resources at =
once. What if the AS decides that the client needs a hyper-focused directed=
 token for one part of the API, but can use a general token for other stuff=
? Can it signal that to the client? And if it can, does that mean that all =
clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for =
the overwhelmingly common use case of a client getting a single access toke=
n to call APIs that it already knows about. Anything we add on top of that =
really can=E2=80=99t get in the way of this, because if it does, there=E2=
=80=99s very small chance that people will try to use this for everyday thi=
ngs. Keep the simple things simple, and the complex things possible, after =
all.

I=E2=80=99m really looking forward to hearing=
 what the community thinks about these use cases, and hopefully the people =
I=E2=80=99ve chatted with offline about this can join the conversation and =
provide more light than I was able to.
The two use cases which are considered above are:
(1) The client knows what resource it=E2=80=99s calling, but it d=
oesn=E2=80=99t know where it=E2=80=99s hosted.
(2) The client knows what=
 kind of thing it=E2=80=99s looking for, but doesn=E2=80=99t know who to as=
k it from.=C2=A0
That d=
oes not mean in any way that these two use cases should be solved by placin=
g the AS at the centre of the solution.
Denis

=C2=A0=E2=80=94 J=
ustin


--=C2=A0
Txaut=
h mailing list
Txauth@ietf.org
https://www.ietf.org/mailma=
n/listinfo/txauth

=


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

This communication, incl=
uding any attachments, is confidential. If you are not the intended recipie=
nt, you should not read it - please contact me immediately, destroy it, and=
 do not copy or use any part of this communication or disclose anything abo=
ut it. Thank you. Please note that this communication does not designate an=
 information system for the purposes of the Electronic Transactions Act 200=
2.

--=C2=A0
<=
span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v=
ariant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:star=
t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;t=
ext-decoration:none;float:none;display:inline">Txauth mailing listTxauth@ie=
tf.org
https://www.ietf.org/mailman/listinfo/txauth

-- 

Txauth mailing list

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









This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.

--000000000000ee2a8505a9f55187--


From nobody Wed Jul  8 15:11: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 3B44E3A083F for ; Wed,  8 Jul 2020 15:11:15 -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 NUJ-kbaQ2JHG for ; Wed,  8 Jul 2020 15:11:12 -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 4183A3A082C for ; Wed,  8 Jul 2020 15:11:12 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id h22so45647lji.9 for ; Wed, 08 Jul 2020 15:11: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=aH2E+hyVVVpUVQZymdLyorx46KlXViBucepiJZwsQfg=; b=mDDbAf9ham2r+RmGZJjaPn7pXBd6bP7hN/LRlXdu4QVF6UrfvANpwY2zOBExJvyQFN wWyGYy2H803AfoP9wMSTGleSHHRwmIDzuF4j5WXB9y8nN3kvEi1tOkFA5oAabouNDKNC ChEdxYUkbrE/R1CXX9j9LAGYRnyO5acuyAyTplOGD8AKFwObzExOuz/q0YAD0YYGz6Hw ncbv2WJQ2sRJrQccyUvsaMkCgjFPbssUR618mU/hC5XUmwEmFW3Ka5lnVTsNZxUM9Lsl 6kRXZNDLgMrIxjPQXSuIwiYUeDvQLAc1QyQFR6lyrPq8IxgEjk5yuete73n0y86bel2s wPoQ==
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=aH2E+hyVVVpUVQZymdLyorx46KlXViBucepiJZwsQfg=; b=XBYBfYKi4TN7gMG7ymNcQ9AWyzqJgbZSaH0zZTBHe9k8Au15gToTXt9AByeOD6J+Wp TPF+bprRJ1uFCZeo/gJ+IuNBcdwM3S/Z6TwICdMFLHfkp0+FjYy/6i1Kjxk4TEXGCoa5 NUPr986ujbtzBkBa164XDpEcUbkqJ6p722oHGPknn+i+iMSfMm+go2ReCuGqU7recepi m9bQyqqFZNOrklfVjRt7ccvYClciLThOhc/ovx/9SpqLUw4kOktRzF91pflsAWFpX+zg IcIUP6kzYHctf+Jnv8NsxH2a69vfJYzyVYRTzCZt7PKnSZzj5QNcfsaPT1RQb4uqXeh/ L0nA==
X-Gm-Message-State: AOAM531mMmujtMvZUIbNU7MyCaPikc/gWE4vPktTpM1nFOSx+LILyv9q YqzbNnJAFyis5WRc7c7w+d/+aYucvUAyeffF3mA=
X-Google-Smtp-Source: ABdhPJzYspsW83OUCoTIfyHL/lZgJZ01leKOQMnfturlua1EUcUA3OpE9Uu4SzxgqLL/LfBDVtG+c6Y5iHrcXGkD+Bw=
X-Received: by 2002:a2e:8316:: with SMTP id a22mr11667401ljh.246.1594246270206;  Wed, 08 Jul 2020 15:11:10 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>    
In-Reply-To: 
From: Dick Hardt 
Date: Wed, 8 Jul 2020 15:10:33 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009ec8cb05a9f5625f"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 08 Jul 2020 22:11:15 -0000

--0000000000009ec8cb05a9f5625f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 8, 2020 at 1:02 PM Justin Richer  wrote:

> On Jul 8, 2020, at 3:16 PM, Dick Hardt  wrote:
>
>
> I think representing the request as an array is simplistic, and
> complicated at the same time.
>
> On the simplistic front, as there is no clear mechanism for extending the
> request with properties that apply to all of the request.
>
>
> The elements of the array are taken as a set, to be tied to the same
> resulting access token. If one of those elements is defined, by the AS
> and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some or =
all of the other
> elements, then that=E2=80=99s up to the AS=E2=80=99s policy. Much like th=
e =E2=80=9Copenid=E2=80=9D scope
> in OIDC, which switches on all sorts of contextual stuff in the request. =
So
> to handle something like this, an AS can easily declare that a given
> scope-style string or a given object property applies to different parts =
of
> the request. You don=E2=80=99t need to externalize it here.
>

I view the "openid" scope as an unfortunate design as OIDC was constrained
by building on top of OAuth. (a problem I hoped to avert by having
"identity" in scope for GNAP) The "openid" scope does not function as
scope per se, and I think it makes OIDC harder to understand as the
"openid" scope causes non-scope behavior.



>
> Do you have a concrete use case that requires that feature to be done in
> the way that you describe? I am trying to separate the driving use case
> from the proposed solutions to see what the differences are.
>

Perhaps the client wants access to be HIPPA compliant? The HIPPA compliance
signal applies to the scopes.

Adding other properties to an object is a well understood extension
mechanism. Adding an additional element to an array that does not act like
the other elements seems like a hack.



>
>
> Using JSON type polymorphism requires the AS to test each member of the
> array to determine if it is a string or an object. Only after detecting a
> RAR object does the AS know the client is making a RAR request.
>
>
> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole reso=
urces request in
> order to figure out what the client is asking for, anyway, whether it=E2=
=80=99s by
> strings or objects or whatever else might be defined by an extension. Is
> there an argument for having an AS do an early dispatch on a request befo=
re
> it=E2=80=99s fully parsed everything?
>

Let me clarify, the code is looking at the type of object that has been
parsed.

Determining if an item in an array is a scope or a RAR object by looking at
the type being either a string or an object seems less clear than a
property of an object explicitly declaring the type.



>
> This also limits the request to be composed only of scope strings or RAR
> objects. I don't see how other strings or objects could be used in the
> array, so there is no clear extension point in the "resources" array for
> other query mechanisms.
>
>
> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring that=
 a string has to
> be an OAuth2-style scope. It can be, but ultimately it=E2=80=99s just a s=
tring that
> the AS can understand. And the objects are just that =E2=80=94 objects. I=
f the AS
> understands what the object is, it can be a RAR object or it can be
> something completely API-specific with another query language entirely.
>

But the other query language would need a type that has been reserved in
the RAR name space for there to be interop, so it effectively is a RAR
extension.

There are query languages in other domains that may not fit nicely into RAR
such as a query for medical records.

Yes, the medical records could be yet another top level property, but per
below, I think that is confusing.


> (Point, though: RAR already pretty much allows this by letting them be
> extended infinitely, a feature it inherits from XYZ)
>
> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99s a=
n array of
> strings or objects and each of those means the same thing, =E2=80=9Csomet=
hing the
> client is asking for=E2=80=9D.
>
>
> Just as RAR has a "type" property, I propose the "resources"
> ("authorizations" in XAuth) be an object, where the other properties are
> determined by the "type" property. This allows extensions to define new
> ways to query for an authorization rather than having to fit into scopes =
or
> RAR.
>
>
> It=E2=80=99s my stance that this is an unnecessary limitation at this lev=
el. The
> objects within the array should be typed, like RAR, but it doesn=E2=80=99=
t make
> sense for the overall request to be typed. Instead, there should be one
> =E2=80=9Ctype" of query in the core, what XYZ calls the =E2=80=9Cresource=
s=E2=80=9D request. Other
> query languages should be added as extensions either to the RAR-style
> objects (by defining a type at that level) or as a separate top-level
> member.
>
> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D query l=
anguage. My current
> thought is that this really shouldn=E2=80=99t be a part of the =E2=80=9Cr=
esources=E2=80=9D or
> =E2=80=9Cclaims=E2=80=9D part of the request, but instead as its own top-=
level member, like
> it is in the OIDC protocol today. The main reason for this is the nature =
of
> the OIDC claims language: it specifies targets for the resulting data, an=
d
> those targets cross different ways to return things. So it doesn=E2=80=99=
t actually
> affect just resources like the UserInfo Endpoint, or the ID Token, but bo=
th
> and potentially others out there. If your system supported such an
> extension, it could theoretically forego both the built-in =E2=80=9Cclaim=
s=E2=80=9D and
> =E2=80=9Cresources=E2=80=9D parts of the request, and use the =E2=80=9Coi=
dc_claims_query=E2=80=9D member
> (or whatever it would be called). This would let such an extension use th=
e
> OIDC claims processing mechanism as it is today.
>
> To me, this remains much more understandable, extensible, and clean.
>

While this may be more understandable to a developer just porting an app
OIDC that only wants OIDC results, but I think it is more complicated as
soon as the developer wants other results, which is likely what prompted
the developer to use GNAP instead of ODIC.

I think it is easier to understand if all the claims are in one container,
and all the authorizations are in another container.

If a developer wants access to some resources, some claims, and an OpenID
Token, they are having to use "claims", "resources", and
"oidc_claims_query".  Now the claims and access tokens are spread across
multiple containers. There are some claims in the "claims" container, and
some "claims" in the "oidc_claims_query" container. And is the access token
response in "oidc_claims_query" the same as an access token response in
"resources"? It would seem simpler if they were, and if all the access
tokens came back in the same container.

Per Aaron's post that you have referred to, the developer can get sme bare
claims directly in the response in the "claims" object, an ID Token that
has the same or different claims, and if they want, an access token that
they can call a user_info endpoint to get the same, or different claims.

For example, an enterprise app client may want an ID Token with the email
address, bare claims for the user's name and a URI to a profile photo, and
an access token to query which groups a user belongs to.

We are still re-using the OIDC claims, but we are not mixing claims and
authorizations.

/Dick


[1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
=E1=90=A7

--0000000000009ec8cb05a9f5625f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Jul 8, 2020 at 1:02 PM Justin=
 Richer <jricher@mit.edu> wrot=
e:
On Jul 8, 2020, at 3:16 PM, Dick Hardt <dick.hardt@gmail.com=
> wrote:

I think representing the request as an array is simplisti=
c, and complicated at the same time.

On the simplistic f=
ront, as there is no clear mechanism for extending the request with propert=
ies that apply to all of the request.=C2=A0

The elements of the array are taken as a set, to b=
e tied to the same resulting access token. If one of those elements is defi=
ned, by the AS and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply ac=
ross some or all of the other elements, then that=E2=80=99s up to the AS=E2=
=80=99s policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, which=
 switches on all sorts of contextual stuff in the request. So to handle som=
ething like this, an AS can easily declare that a given scope-style string =
or a given object property applies to different parts of the request. You d=
on=E2=80=99t need to externalize it here.

I view the "openid" scope as an unfortunate desi=
gn as OIDC was constrained by building=C2=A0on top of OAuth. (a problem I h=
oped to avert by having "identity" in scope for GNAP) The "o=
penid" scope does not function as scope=C2=A0per se, and I think it ma=
kes OIDC harder to understand as the "openid" scope causes non-sc=
ope behavior.=C2=A0

=C2=A0
=


Do you have a concrete use case that requires that=
 feature to be done in the way that you describe? I am trying to separate t=
he driving use case from the proposed solutions to see what the differences=
 are.=C2=A0

Perhaps the c=
lient wants access to be HIPPA compliant? The HIPPA compliance signal appli=
es to the scopes.

Adding other properties to an ob=
ject is a well understood extension mechanism. Adding an additional element=
 to an array that does not act like the other elements seems like a hack.

=C2=A0


Using JSON type polymorphism=C2=A0requires the AS to test each memb=
er of the array to determine if it is a string or an object. Only after det=
ecting a RAR object does the AS know the client is making a RAR request. 

That=E2=80=99s corre=
ct =E2=80=94 but the AS needs to parse the whole resources request in order=
 to figure out what the client is asking for, anyway, whether it=E2=80=99s =
by strings or objects or whatever else might be defined by an extension. Is=
 there an argument for having an AS do an early dispatch on a request befor=
e it=E2=80=99s fully parsed everything?
=

Let me clarify, the code is looking at the type of object th=
at has been parsed.=C2=A0

Determining if an item i=
n an array is a scope or a RAR object by looking at the type being either a=
 string or an object seems less clear than a property of an object explicit=
ly declaring the type.

=C2=A0

This also limits the request to be composed only of scope strings=
 or RAR objects. I don't see how other strings or objects could be used=
 in the array, so there is no clear extension point in the "resources&=
quot; array for other query mechanisms.

That=E2=80=99s not the case in XYZ since we aren=E2=80=
=99t declaring that a string has to be an OAuth2-style scope. It can be, bu=
t ultimately it=E2=80=99s just a string that the AS can understand. And the=
 objects are just that =E2=80=94 objects. If the AS understands what the ob=
ject is, it can be a RAR object or it can be something completely API-speci=
fic with another query language entirely.

But the other query language would need a type that has be=
en reserved in the RAR name space for there to be interop, so it effectivel=
y is a RAR extension.

There are query languages in=
 other domains that may not fit nicely into RAR such as a query for medical=
 records.

Yes, the medical records could be yet an=
other top level property, but per below, I think that is confusing.
=C2=A0
 (Point, though: RAR already pret=
ty much allows this by letting them be extended infinitely, a feature it in=
herits from XYZ)

I=E2=80=99m proposing that we do =
the same thing with GNAP: it=E2=80=99s an array of strings or objects and e=
ach of those means the same thing, =E2=80=9Csomething the client is asking =
for=E2=80=9D.


Just as RAR has a "type" propert=
y, I propose the "resources" ("authorizations" in XAuth=
) be an object, where the other properties are determined by the "type=
" property. This allows extensions to define new ways to query for an =
authorization rather than having to fit into scopes or RAR.

<=
/div>

It=E2=80=99s my sta=
nce that this is an unnecessary limitation at this level. The objects withi=
n the array should be typed, like RAR, but it doesn=E2=80=99t make sense fo=
r the overall request to be typed. Instead, there should be one =E2=80=9Cty=
pe" of query in the core, what XYZ calls the =E2=80=9Cresources=E2=80=
=9D request. Other query languages should be added as extensions either to =
the RAR-style objects (by defining a type at that level) or as a separate t=
op-level member.

For example, let=E2=80=99s take t=
he OIDC =E2=80=9Cclaims=E2=80=9D query language. My current thought is that=
 this really shouldn=E2=80=99t be a part of the =E2=80=9Cresources=E2=80=9D=
 or =E2=80=9Cclaims=E2=80=9D part of the request, but instead as its own to=
p-level member, like it is in the OIDC protocol today. The main reason for =
this is the nature of the OIDC claims language: it specifies targets for th=
e resulting data, and those targets cross different ways to return things. =
So it doesn=E2=80=99t actually affect just resources like the UserInfo Endp=
oint, or the ID Token, but both and potentially others out there. If your s=
ystem supported such an extension, it could theoretically forego both the b=
uilt-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts of t=
he request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member (or what=
ever it would be called). This would let such an extension use the OIDC cla=
ims processing mechanism as it is today.

To me, th=
is remains much more understandable, extensible, and clean.

While this may be more understandable to=
 a developer just=C2=A0porting an app OIDC that only wants OIDC results, bu=
t I think it is more complicated as soon as the developer wants other resul=
ts, which is likely what=C2=A0prompted the developer to use GNAP instead of=
 ODIC.

I think it is easier to understand if all t=
he claims are in one container, and all the authorizations are in another c=
ontainer.

If a developer wants access to some reso=
urces, some claims, and an OpenID Token, they are having to use "claim=
s", "resources", and "oidc_claims_query".=C2=A0 No=
w the claims and access tokens are spread across multiple containers. There=
 are some claims in the "claims" container, and some "claims=
" in the "oidc_claims_query" container. And is the access to=
ken response in=C2=A0"oidc_claims_query" the same as an access to=
ken response in "resources"? It would seem simpler if they were, =
and if all the access tokens came back in the same container.
Per Aaron's post that you have referred to, the developer c=
an get sme bare claims directly in the response in the "claims" o=
bject, an ID Token that has the same or different claims, and if they want,=
 an access token that they can call a user_info endpoint to get the same, o=
r different claims.

For example, an enterprise app=
 client may want an ID Token with the email address, bare claims for the us=
er's name and a URI to a profile photo, and an access token to query wh=
ich groups a user belongs to.

We are still re-usin=
g=C2=A0the OIDC claims, but we are not mixing claims and authorizations.

/Dick


=3D""=E1=90=A7


--0000000000009ec8cb05a9f5625f--


From nobody Wed Jul  8 15:19: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 493973A0859 for ; Wed,  8 Jul 2020 15:19:19 -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 A0rcPoariRjE for ; Wed,  8 Jul 2020 15:19:17 -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 404DF3A0856 for ; Wed,  8 Jul 2020 15:19:17 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id q7so103702ljm.1 for ; Wed, 08 Jul 2020 15:19: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;  bh=mDs1IKWOI4KVeV7YR6auWzlrTuWSYq4JJv/IyaYwpXQ=; b=XWt9DgQqj6WUY/Fia0DEeZXZhOp0zK1UnLR+zBuIvl+67Mw6CNmY1OHDiNrVsdu883 Kd7i3jgWmzzlg3MhPsyCVGss/MILq/tY5Y4GaE3L1e+r2qhCFvKPjZ3vdETq4v2C64mT do6SHVcwQiiZBKLLBlAXjpxU4Hp4YAUMkKKfn3XWGY5yKTMuumTglA0DvebtKswe4QCI 5P+ESNsOfLXmJoXo8huqvcDnqo7lRLFQtnIhUwUC4kZrxVRCIEv590A1VvogqnDvFmv/ 5mVVAZ30S08jFhk1aGCgb6xBUuQuS5T+gqHRlXI/bnII9wHOi1sLhf8FzM3wBMFVPnci oCag==
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; bh=mDs1IKWOI4KVeV7YR6auWzlrTuWSYq4JJv/IyaYwpXQ=; b=kCTUnakuJShxdc3UgpqMfBucFowdvJT7+DLCfmIffXQPgGzozqdLgYuGaXFz6vk8rq q8EPgfVQ3Iz9k7dEjaQdAC7C0oc6nYyLc9PxXOZjGZYU/oNb90lL9q01rBnXFqYyxqVr W9A2iZi8JO8VFwQfrwALQSgK1/op/UoAr+pVRu7Z+V334DIJBLkX2KgUj1HK7mcO5cMk 0y/2OgS4xl6mONgcp+sdqLTWWvuWeVYFjAzMBK+uQLbcwYMXzm7IGFtO4wEU6ovJwyjd b70vOIhjmqBjDd3ZIhNXbTHs1np49UjxkcyYIwJ5d7+Bzjt52KEgE0DSPSAwxb4Ou3Te qlxA==
X-Gm-Message-State: AOAM530Chk7FLil9WKMp8h0Yy/FK6P0bc2Z7CScQscxutQZOzAHWTpSY ZbgOHOPZta38RJCLk93Q3ugiVukdDLA2LbX0f4Trq0i5vBQ=
X-Google-Smtp-Source: ABdhPJzESR0tRLCTONRxoR0pNDaXRhAEHt6zNTkoWVj4730dRVERBN0k43QrMm4WOwlFMW3xtrpUf6vewGUqtcFMD7k=
X-Received: by 2002:a2e:b70b:: with SMTP id j11mr21211153ljo.142.1594246754878;  Wed, 08 Jul 2020 15:19:14 -0700 (PDT)
MIME-Version: 1.0
References: <159424298105.25748.12030080706465290319@ietfa.amsl.com>
In-Reply-To: <159424298105.25748.12030080706465290319@ietfa.amsl.com>
From: Dick Hardt 
Date: Wed, 8 Jul 2020 15:18:38 -0700
Message-ID: 
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000824cc205a9f57fb9"
Archived-At: 
Subject: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-12.txt
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, 08 Jul 2020 22:19:19 -0000

--000000000000824cc205a9f57fb9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I have updated the XAuth authorizations request and response to be either
singular or plural.

I also updated my implementation https://github.com/dickhardt/XAuth-poc

Checking if it is a valid request is easier, as "authorization" and
"authorizations" are not mutually exclusive, and I think it cleans up the
protocol specification.

---------- Forwarded message ---------
From: 
Date: Wed, Jul 8, 2020 at 2:16 PM
Subject: New Version Notification for draft-hardt-xauth-protocol-12.txt
To: Dick Hardt 



A new version of I-D, draft-hardt-xauth-protocol-12.txt
has been successfully submitted by Dick Hardt and posted to the
IETF repository.

Name:           draft-hardt-xauth-protocol
Revision:       12
Title:          The Grant Negotiation and Authorization Protocol
Document date:  2020-07-08
Group:          Individual Submission
Pages:          38
URL:
https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-12.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol=
/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-12
Htmlized:
https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:
https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-12

Abstract:
   Client software often desires resources or identity claims that are
   independent of the client.  This protocol allows a user and/or
   resource owner to delegate resource authorization and/or release of
   identity claims to a server.  Client software can then request access
   to resources and/or identity claims by calling the server.  The
   server acquires consent and authorization from the user and/or
   resource owner if required, and then returns to the client software
   the authorization and identity claims that were approved.  This
   protocol may be extended to support alternative authorizations,
   claims, interactions, and client authentication mechanisms.




Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


=E1=90=A7

--000000000000824cc205a9f57fb9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I have updated the XAuth authorizations request and respon=
se to be either singular or plural.

I also updated my im=
plementation=C2=A0https:=
//github.com/dickhardt/XAuth-poc

Checking if i=
t is a valid request is easier, as "authorization" and "auth=
orizations" are not mutually exclusive, and I think it cleans up the p=
rotocol specification.

---------- Forwarded message ---------
From: =
<internet=
-drafts@ietf.org>
Date: Wed, Jul 8, 2020 at 2:16 PM
Sub=
ject: New Version Notification for draft-hardt-xauth-protocol-12.txt
To:=
 Dick Hardt <dick.hardt@gmail.co=
m>




A new version of I-D, draft-hardt-xauth-protocol-12.txt

has been successfully submitted by Dick Hardt and posted to the

IETF repository.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-protocol
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A012

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The Grant Negotiation and Authoriz=
ation Protocol

Document date:=C2=A0 2020-07-08

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 38

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hardt-xauth-prot=
ocol-12.txt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/=
/tools.ietf.org/html/draft-hardt-xauth-protocol-12

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0=
https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol

Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-=
12



Abstract:

=C2=A0 =C2=A0Client software often desires resources or identity claims tha=
t are

=C2=A0 =C2=A0independent of the client.=C2=A0 This protocol allows a user a=
nd/or

=C2=A0 =C2=A0resource owner to delegate resource authorization and/or relea=
se of

=C2=A0 =C2=A0identity claims to a server.=C2=A0 Client software can then re=
quest access

=C2=A0 =C2=A0to resources and/or identity claims by calling the server.=C2=
=A0 The

=C2=A0 =C2=A0server acquires consent and authorization from the user and/or=


=C2=A0 =C2=A0resource owner if required, and then returns to the client sof=
tware

=C2=A0 =C2=A0the authorization and identity claims that were approved.=C2=
=A0 This

=C2=A0 =C2=A0protocol may be extended to support alternative authorizations=
,

=C2=A0 =C2=A0claims, interactions, and client authentication mechanisms.








Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat






<=
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=3D673acf70-b873-4ede-b02c-9f6bc5afc7d7">=E1=90=A7


--000000000000824cc205a9f57fb9--


From nobody Wed Jul  8 15:25: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 32B533A0870 for ; Wed,  8 Jul 2020 15:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level: 
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 6KUY3ktwacjS for ; Wed,  8 Jul 2020 15:25:43 -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 64A103A086E for ; Wed,  8 Jul 2020 15:25:42 -0700 (PDT)
Received: from [192.168.1.7] (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 068MPcF8016489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Jul 2020 18:25:38 -0400
From: Justin Richer 
Message-Id: <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ADC01F60-190E-40C7-878A-8AB128A03E98"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 8 Jul 2020 18:25:37 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>     
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 08 Jul 2020 22:25:46 -0000

--Apple-Mail=_ADC01F60-190E-40C7-878A-8AB128A03E98
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I=E2=80=99m glad that we can agree that there are a number of things in =
legacy protocols that are unfortunate side effects of the circumstances =
in which they were built. Space-separated scope strings, for instance, =
would fall in that category, as I=E2=80=99ve previously explained.

A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request =
already mixes user claims (returned in an API) and authorization (to =
fetch user claims from an API), so that ship has sailed if you=E2=80=99re =
using it. It doesn=E2=80=99t make sense to have it under a =E2=80=9Cclaims=
=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s =
a query language that affects both. Maybe you=E2=80=99d call this =
another =E2=80=9Cunfortunate design=E2=80=9D, but the context was about =
re-using an externally-defined query language that was not made for =
GNAP.

My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=9D =
and wants to keep using it. (The vast majority of OIDC implementations, =
in my experience, don=E2=80=99t use that feature, and it=E2=80=99s not =
even required to be implemented by the AS, but again we=E2=80=99re =
talking about using this feature as an example of an external query =
language =E2=80=94 and there are others out there.) In GNAP, you should =
return claims directly in the response, and request specific elements =
from the APIs protected by the access token. These are separate things, =
and by design both XAuth and XYZ have put them into separate containers =
in the request. This is a good design, and so putting something that =
conflates these two aspects into one or the other of the containers is =
not a particularly good option, in my opinion.=20

Additionally, though this is a bit of an aside and getting into the =
specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is =
a query language bound to the full user profile. It is my stated =
position that the items coming back from the AS should only be =
identifiers, and not full profile information. The reasoning is pretty =
simple: the client doesn=E2=80=99t know what profile information it =
needs until it knows who the user is, so putting that into a protected =
API like the UserInfo Endpoint makes much more sense than putting it =
into the immediate response, where it is not needed, because the client =
already knows it. The AS doesn=E2=80=99t know what the client needs to =
know, either, so it can=E2=80=99t determine what to fulfill. OIDC=E2=80=99=
s two-stage model makes sense, and GNAP should really only focus on =
enabling this.

 =E2=80=94 Justin

> On Jul 8, 2020, at 6:10 PM, Dick Hardt  wrote:
>=20
>=20
>=20
> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer > wrote:
> On Jul 8, 2020, at 3:16 PM, Dick Hardt > wrote:
>>=20
>> I think representing the request as an array is simplistic, and =
complicated at the same time.
>>=20
>> On the simplistic front, as there is no clear mechanism for extending =
the request with properties that apply to all of the request.=20
>=20
> The elements of the array are taken as a set, to be tied to the same =
resulting access token. If one of those elements is defined, by the AS =
and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some or =
all of the other elements, then that=E2=80=99s up to the AS=E2=80=99s =
policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, which =
switches on all sorts of contextual stuff in the request. So to handle =
something like this, an AS can easily declare that a given scope-style =
string or a given object property applies to different parts of the =
request. You don=E2=80=99t need to externalize it here.
>=20
> I view the "openid" scope as an unfortunate design as OIDC was =
constrained by building on top of OAuth. (a problem I hoped to avert by =
having "identity" in scope for GNAP) The "openid" scope does not =
function as scope per se, and I think it makes OIDC harder to understand =
as the "openid" scope causes non-scope behavior.=20
>=20
> =20
>=20
> Do you have a concrete use case that requires that feature to be done =
in the way that you describe? I am trying to separate the driving use =
case from the proposed solutions to see what the differences are.=20
>=20
> Perhaps the client wants access to be HIPPA compliant? The HIPPA =
compliance signal applies to the scopes.
>=20
> Adding other properties to an object is a well understood extension =
mechanism. Adding an additional element to an array that does not act =
like the other elements seems like a hack.
>=20
> =20
>=20
>>=20
>> Using JSON type polymorphism requires the AS to test each member of =
the array to determine if it is a string or an object. Only after =
detecting a RAR object does the AS know the client is making a RAR =
request.=20
>=20
> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole =
resources request in order to figure out what the client is asking for, =
anyway, whether it=E2=80=99s by strings or objects or whatever else =
might be defined by an extension. Is there an argument for having an AS =
do an early dispatch on a request before it=E2=80=99s fully parsed =
everything?
>=20
> Let me clarify, the code is looking at the type of object that has =
been parsed.=20
>=20
> Determining if an item in an array is a scope or a RAR object by =
looking at the type being either a string or an object seems less clear =
than a property of an object explicitly declaring the type.
>=20
> =20
>=20
>> This also limits the request to be composed only of scope strings or =
RAR objects. I don't see how other strings or objects could be used in =
the array, so there is no clear extension point in the "resources" array =
for other query mechanisms.
>=20
> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring =
that a string has to be an OAuth2-style scope. It can be, but ultimately =
it=E2=80=99s just a string that the AS can understand. And the objects =
are just that =E2=80=94 objects. If the AS understands what the object =
is, it can be a RAR object or it can be something completely =
API-specific with another query language entirely.
>=20
> But the other query language would need a type that has been reserved =
in the RAR name space for there to be interop, so it effectively is a =
RAR extension.
>=20
> There are query languages in other domains that may not fit nicely =
into RAR such as a query for medical records.
>=20
> Yes, the medical records could be yet another top level property, but =
per below, I think that is confusing.
> =20
> (Point, though: RAR already pretty much allows this by letting them be =
extended infinitely, a feature it inherits from XYZ)
>=20
> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99s =
an array of strings or objects and each of those means the same thing, =
=E2=80=9Csomething the client is asking for=E2=80=9D.
>=20
>>=20
>> Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.
>>=20
>=20
> It=E2=80=99s my stance that this is an unnecessary limitation at this =
level. The objects within the array should be typed, like RAR, but it =
doesn=E2=80=99t make sense for the overall request to be typed. Instead, =
there should be one =E2=80=9Ctype" of query in the core, what XYZ calls =
the =E2=80=9Cresources=E2=80=9D request. Other query languages should be =
added as extensions either to the RAR-style objects (by defining a type =
at that level) or as a separate top-level member.
>=20
> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D =
query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.
>=20
> To me, this remains much more understandable, extensible, and clean.
>=20
> While this may be more understandable to a developer just porting an =
app OIDC that only wants OIDC results, but I think it is more =
complicated as soon as the developer wants other results, which is =
likely what prompted the developer to use GNAP instead of ODIC.
>=20
> I think it is easier to understand if all the claims are in one =
container, and all the authorizations are in another container.
>=20
> If a developer wants access to some resources, some claims, and an =
OpenID Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread across =
multiple containers. There are some claims in the "claims" container, =
and some "claims" in the "oidc_claims_query" container. And is the =
access token response in "oidc_claims_query" the same as an access token =
response in "resources"? It would seem simpler if they were, and if all =
the access tokens came back in the same container.
>=20
> Per Aaron's post that you have referred to, the developer can get sme =
bare claims directly in the response in the "claims" object, an ID Token =
that has the same or different claims, and if they want, an access token =
that they can call a user_info endpoint to get the same, or different =
claims.
>=20
> For example, an enterprise app client may want an ID Token with the =
email address, bare claims for the user's name and a URI to a profile =
photo, and an access token to query which groups a user belongs to.
>=20
> We are still re-using the OIDC claims, but we are not mixing claims =
and authorizations.
>=20
> /Dick
>=20
>=20
> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz =

> =E1=90=A7


--Apple-Mail=_ADC01F60-190E-40C7-878A-8AB128A03E98
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I=E2=80=
=99m glad that we can agree that there are a number of things in legacy =
protocols that are unfortunate side effects of the circumstances in =
which they were built. Space-separated scope strings, for instance, =
would fall in that category, as I=E2=80=99ve previously explained.

A key point in the =
below: the OIDC =E2=80=9Cclaims=E2=80=9D request already mixes user =
claims (returned in an API) and authorization (to fetch user claims from =
an API), so that ship has sailed if you=E2=80=99re using it. It =
doesn=E2=80=99t make sense to have it under a =E2=80=9Cclaims=E2=80=9D =
or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s a query =
language that affects both. Maybe you=E2=80=99d call this another =
=E2=80=9Cunfortunate design=E2=80=9D, but the context was about re-using =
an externally-defined query language that was not made for GNAP.

My scenario was for =
someone who is already using =E2=80=9Cclaims=E2=80=9D and wants to keep =
using it. (The vast majority of OIDC implementations, in my experience, =
don=E2=80=99t use that feature, and it=E2=80=99s not even required to be =
implemented by the AS, but again we=E2=80=99re talking about using this =
feature as an example of an external query language =E2=80=94 and there =
are others out there.) In GNAP, you should return claims directly in the =
response, and request specific elements from the APIs protected by the =
access token. These are separate things, and by design both XAuth and =
XYZ have put them into separate containers in the request. This is a =
good design, and so putting something that conflates these two aspects =
into one or the other of the containers is not a particularly good =
option, in my opinion. 

Additionally, though this is a bit of =
an aside and getting into the specifics of identity, the =E2=80=9Cclaims=E2=
=80=9D parameter of ODIC is a query language bound to the full user =
profile. It is my stated position that the items coming back from the AS =
should only be identifiers, and not full profile information. The =
reasoning is pretty simple: the client doesn=E2=80=99t know what profile =
information it needs until it knows who the user is, so putting that =
into a protected API like the UserInfo Endpoint makes much more sense =
than putting it into the immediate response, where it is not needed, =
because the client already knows it. The AS doesn=E2=80=99t know what =
the client needs to know, either, so it can=E2=80=99t determine what to =
fulfill. OIDC=E2=80=99s two-stage model makes sense, and GNAP should =
really only focus on enabling this.

 =E2=80=94 Justin

On Jul 8, 2020, at 6:10 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Wed, Jul =
8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at 3:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I =
think representing the request as an array is simplistic, and =
complicated at the same time.

On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the =
request. 

The elements of the array are taken as =
a set, to be tied to the same resulting access token. If one of those =
elements is defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s =
protecting, to apply across some or all of the other elements, then =
that=E2=80=99s up to the AS=E2=80=99s policy. Much like the =E2=80=9Copeni=
d=E2=80=9D scope in OIDC, which switches on all sorts of contextual =
stuff in the request. So to handle something like this, an AS can easily =
declare that a given scope-style string or a given object property =
applies to different parts of the request. You don=E2=80=99t need to =
externalize it here.

I view the "openid" scope as an =
unfortunate design as OIDC was constrained by building on top of =
OAuth. (a problem I hoped to avert by having "identity" in scope for =
GNAP) The "openid" scope does not function as scope per se, and I =
think it makes OIDC harder to understand as the "openid" scope causes =
non-scope behavior. 

 

Do you have a concrete =
use case that requires that feature to be done in the way that you =
describe? I am trying to separate the driving use case from the proposed =
solutions to see what the differences =
are. 

Perhaps the client wants access to be =
HIPPA compliant? The HIPPA compliance signal applies to the =
scopes.

Adding =
other properties to an object is a well understood extension mechanism. =
Adding an additional element to an array that does not act like the =
other elements seems like a hack.

 


Using JSON type =
polymorphism requires the AS to test each member of the array to =
determine if it is a string or an object. Only after detecting a RAR =
object does the AS know the client is making a RAR request. 

That=E2=80=99=
s correct =E2=80=94 but the AS needs to parse the whole resources =
request in order to figure out what the client is asking for, anyway, =
whether it=E2=80=99s by strings or objects or whatever else might be =
defined by an extension. Is there an argument for having an AS do an =
early dispatch on a request before it=E2=80=99s fully parsed =
everything?

Let me clarify, the code is looking at =
the type of object that has been parsed. 

Determining if an item in an array is a =
scope or a RAR object by looking at the type being either a string or an =
object seems less clear than a property of an object explicitly =
declaring the type.

 

This also limits the request to be composed =
only of scope strings or RAR objects. I don't see how other strings or =
objects could be used in the array, so there is no clear extension point =
in the "resources" array for other query =
mechanisms.

That=E2=80=99s not the case in XYZ =
since we aren=E2=80=99t declaring that a string has to be an =
OAuth2-style scope. It can be, but ultimately it=E2=80=99s just a string =
that the AS can understand. And the objects are just that =E2=80=94 =
objects. If the AS understands what the object is, it can be a RAR =
object or it can be something completely API-specific with another query =
language entirely.

But the other query language would need =
a type that has been reserved in the RAR name space for there to be =
interop, so it effectively is a RAR extension.

There are query languages in other =
domains that may not fit nicely into RAR such as a query for medical =
records.

Yes, =
the medical records could be yet another top level property, but per =
below, I think that is confusing.
 
(Point, though: RAR already pretty much allows this by =
letting them be extended infinitely, a feature it inherits from =
XYZ)

I=E2=80=99m=
 proposing that we do the same thing with GNAP: it=E2=80=99s an array of =
strings or objects and each of those means the same thing, =E2=80=9Csometh=
ing the client is asking for=E2=80=9D.


Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.


It=E2=80=99s my stance that this is an =
unnecessary limitation at this level. The objects within the array =
should be typed, like RAR, but it doesn=E2=80=99t make sense for the =
overall request to be typed. Instead, there should be one =E2=80=9Ctype" =
of query in the core, what XYZ calls the =E2=80=9Cresources=E2=80=9D =
request. Other query languages should be added as extensions either to =
the RAR-style objects (by defining a type at that level) or as a =
separate top-level member.

For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D=
 query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.

To me, this remains much =
more understandable, extensible, and =
clean.

While this may be more understandable =
to a developer just porting an app OIDC that only wants OIDC =
results, but I think it is more complicated as soon as the developer =
wants other results, which is likely what prompted the developer to =
use GNAP instead of ODIC.

I think it is easier to understand if all the claims are in =
one container, and all the authorizations are in another =
container.

If =
a developer wants access to some resources, some claims, and an OpenID =
Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread =
across multiple containers. There are some claims in the "claims" =
container, and some "claims" in the "oidc_claims_query" container. And =
is the access token response in "oidc_claims_query" the same as an =
access token response in "resources"? It would seem simpler if they =
were, and if all the access tokens came back in the same =
container.

Per =
Aaron's post that you have referred to, the developer can get sme bare =
claims directly in the response in the "claims" object, an ID Token that =
has the same or different claims, and if they want, an access token that =
they can call a user_info endpoint to get the same, or different =
claims.

For =
example, an enterprise app client may want an ID Token with the email =
address, bare claims for the user's name and a URI to a profile photo, =
and an access token to query which groups a user belongs to.

We are still =
re-using the OIDC claims, but we are not mixing claims and =
authorizations.

/Dick


[1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
3D""=E1=90=A7

=

--Apple-Mail=_ADC01F60-190E-40C7-878A-8AB128A03E98--


From nobody Wed Jul  8 15:55: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 23F613A0907 for ; Wed,  8 Jul 2020 15:55:43 -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 em811Kr9MYjG for ; Wed,  8 Jul 2020 15:55:40 -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 BF31E3A059F for ; Wed,  8 Jul 2020 15:55:39 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id b25so158756ljp.6 for ; Wed, 08 Jul 2020 15:55: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=VRkHHqhwvt1CJ7YvnS2DEYX3iYssAMNazL/kvfdaUiY=; b=p/aGLI6uT9Q0OYCtY4OL9VGsEJZBb0QalwH051tKlV+c0hB/bpzVg6uZpPcvtKLjmE KcQkas3am1OUghjKQtzbvkEKSDQimH0zICG6xzk49POIpjyxd51raNSCsln7NZ0hQXPL sn4j+mL1tBTD2Iz6f+3fNqD7hd3VRPpN6ZKIWU4TpLCKWaPnYeO8a0Ggl4NLQlAzmYQl 8VaCi4aG2YgfD+XLHjekQglCHlwpzoZyBAoA5aqXQ/82y2Y5tlaIqyW7yxZ/lwDHqaBq T/vdr8t0hTqTBzuOeMvbwLWuNd9Z7FXzWteDwi5wn0Boo2wsJawVVDIE0LQbGHGSdyod MY1g==
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=VRkHHqhwvt1CJ7YvnS2DEYX3iYssAMNazL/kvfdaUiY=; b=P2slFN5k8ofYzXMcrCaE0d1ih815aRmvPRIqzht9PNZY/4fS/ingGYV3OIxW0fUk3H Waj4cbQHo7IIEiQdGI5o1EfNq+jyBoGhWObnFEZJOKTqyDhWgFykpfyVYOOEHMRV0Yjg /38qW+XH3ekE60/wYor9ZVMlKrF73oxvQ5agxDX8jWYORZCXZ2qUhF3ivMoZDe4B0e57 fbE0O+MiJ7sv/So7IxOLqz9or0kLJTZmGHzQrEe6XwDv3ngAgS3no/xCzAu84KbOzKaZ 6ntMUbI5Cdoa6+b4H+ktiRoZYZ5ODhzervmjqAOhJKJEyfuyHlw1VMe/GGQWW8dXNa1C JmtQ==
X-Gm-Message-State: AOAM53139/wNhbjmiS7qVcL5UcmWrD3ulzazNtQ2raV+wi7wcubXKaHz E6qPcGpmf+jENDA+u+omZEl/t1LbSJtqyojZdbE=
X-Google-Smtp-Source: ABdhPJw9Dzd9VudGlUN1fG69kQyLb4OWAIja3hVyUutsAnRom3iwZGZH5IKQqSKQk/TngFEaOznbgNFyV0srcHeLKmg=
X-Received: by 2002:a2e:7f10:: with SMTP id a16mr36416149ljd.69.1594248937403;  Wed, 08 Jul 2020 15:55:37 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>
In-Reply-To: <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>
From: Dick Hardt 
Date: Wed, 8 Jul 2020 15:55:01 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000098fcd105a9f6013e"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 08 Jul 2020 22:55:43 -0000

--00000000000098fcd105a9f6013e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Justin,

Just because we are using OIDC claims, does not mean we need to mimic the
OIDC request and response.
I was envisioning a grant request could look as the following (using XAuth
syntax):

{
    "authorizations": {
        "type":"oidc",
        "claims": ["name", "picture"]
    },
    "claims":{
        "oidc": {
            "id_token" : {
                "email"          : { "essential" : true },
                "email_verified" : { "essential" : true }
            },
            "userinfo" : {
                "name"           : { "essential" : true },
                "picture"        : null
            }
        }
    }
}

Of course a developer could choose to only ask for a subset of this.

Note the new authorization type of "oidc", that takes "claims" rather than
"scope".

This keeps all the authorizations and claims in their respective request
and response containers.

We had a thread months ago on the OIDC two stage model, and I still fail to
see why forcing that has any advantage.

/Dick


On Wed, Jul 8, 2020 at 3:25 PM Justin Richer  wrote:

> I=E2=80=99m glad that we can agree that there are a number of things in l=
egacy
> protocols that are unfortunate side effects of the circumstances in which
> they were built. Space-separated scope strings, for instance, would fall =
in
> that category, as I=E2=80=99ve previously explained.
>
> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request alrea=
dy mixes user
> claims (returned in an API) and authorization (to fetch user claims from =
an
> API), so that ship has sailed if you=E2=80=99re using it. It doesn=E2=80=
=99t make sense to
> have it under a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorizations=E2=80=
=9D request, since it=E2=80=99s a query
> language that affects both. Maybe you=E2=80=99d call this another =E2=80=
=9Cunfortunate
> design=E2=80=9D, but the context was about re-using an externally-defined=
 query
> language that was not made for GNAP.
>
> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=9D=
 and wants to
> keep using it. (The vast majority of OIDC implementations, in my
> experience, don=E2=80=99t use that feature, and it=E2=80=99s not even req=
uired to be
> implemented by the AS, but again we=E2=80=99re talking about using this f=
eature as
> an example of an external query language =E2=80=94 and there are others o=
ut there.)
> In GNAP, you should return claims directly in the response, and request
> specific elements from the APIs protected by the access token. These are
> separate things, and by design both XAuth and XYZ have put them into
> separate containers in the request. This is a good design, and so putting
> something that conflates these two aspects into one or the other of the
> containers is not a particularly good option, in my opinion.
>
> Additionally, though this is a bit of an aside and getting into the
> specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is =
a query language
> bound to the full user profile. It is my stated position that the items
> coming back from the AS should only be identifiers, and not full profile
> information. The reasoning is pretty simple: the client doesn=E2=80=99t k=
now what
> profile information it needs until it knows who the user is, so putting
> that into a protected API like the UserInfo Endpoint makes much more sens=
e
> than putting it into the immediate response, where it is not needed,
> because the client already knows it. The AS doesn=E2=80=99t know what the=
 client
> needs to know, either, so it can=E2=80=99t determine what to fulfill. OID=
C=E2=80=99s
> two-stage model makes sense, and GNAP should really only focus on enablin=
g
> this.
>
>  =E2=80=94 Justin
>
> On Jul 8, 2020, at 6:10 PM, Dick Hardt  wrote:
>
>
>
> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer  wrote:
>
>> On Jul 8, 2020, at 3:16 PM, Dick Hardt  wrote:
>>
>>
>> I think representing the request as an array is simplistic, and
>> complicated at the same time.
>>
>> On the simplistic front, as there is no clear mechanism for extending th=
e
>> request with properties that apply to all of the request.
>>
>>
>> The elements of the array are taken as a set, to be tied to the same
>> resulting access token. If one of those elements is defined, by the AS
>> and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some or=
 all of the other
>> elements, then that=E2=80=99s up to the AS=E2=80=99s policy. Much like t=
he =E2=80=9Copenid=E2=80=9D scope
>> in OIDC, which switches on all sorts of contextual stuff in the request.=
 So
>> to handle something like this, an AS can easily declare that a given
>> scope-style string or a given object property applies to different parts=
 of
>> the request. You don=E2=80=99t need to externalize it here.
>>
>
> I view the "openid" scope as an unfortunate design as OIDC was constraine=
d
> by building on top of OAuth. (a problem I hoped to avert by having
> "identity" in scope for GNAP) The "openid" scope does not function as
> scope per se, and I think it makes OIDC harder to understand as the
> "openid" scope causes non-scope behavior.
>
>
>
>>
>> Do you have a concrete use case that requires that feature to be done in
>> the way that you describe? I am trying to separate the driving use case
>> from the proposed solutions to see what the differences are.
>>
>
> Perhaps the client wants access to be HIPPA compliant? The HIPPA
> compliance signal applies to the scopes.
>
> Adding other properties to an object is a well understood extension
> mechanism. Adding an additional element to an array that does not act lik=
e
> the other elements seems like a hack.
>
>
>
>>
>>
>> Using JSON type polymorphism requires the AS to test each member of the
>> array to determine if it is a string or an object. Only after detecting =
a
>> RAR object does the AS know the client is making a RAR request.
>>
>>
>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole res=
ources request in
>> order to figure out what the client is asking for, anyway, whether it=E2=
=80=99s by
>> strings or objects or whatever else might be defined by an extension. Is
>> there an argument for having an AS do an early dispatch on a request bef=
ore
>> it=E2=80=99s fully parsed everything?
>>
>
> Let me clarify, the code is looking at the type of object that has been
> parsed.
>
> Determining if an item in an array is a scope or a RAR object by looking
> at the type being either a string or an object seems less clear than a
> property of an object explicitly declaring the type.
>
>
>
>>
>> This also limits the request to be composed only of scope strings or RAR
>> objects. I don't see how other strings or objects could be used in the
>> array, so there is no clear extension point in the "resources" array for
>> other query mechanisms.
>>
>>
>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring tha=
t a string has to
>> be an OAuth2-style scope. It can be, but ultimately it=E2=80=99s just a =
string that
>> the AS can understand. And the objects are just that =E2=80=94 objects. =
If the AS
>> understands what the object is, it can be a RAR object or it can be
>> something completely API-specific with another query language entirely.
>>
>
> But the other query language would need a type that has been reserved in
> the RAR name space for there to be interop, so it effectively is a RAR
> extension.
>
> There are query languages in other domains that may not fit nicely into
> RAR such as a query for medical records.
>
> Yes, the medical records could be yet another top level property, but per
> below, I think that is confusing.
>
>
>> (Point, though: RAR already pretty much allows this by letting them be
>> extended infinitely, a feature it inherits from XYZ)
>>
>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99s =
an array of
>> strings or objects and each of those means the same thing, =E2=80=9Csome=
thing the
>> client is asking for=E2=80=9D.
>>
>>
>> Just as RAR has a "type" property, I propose the "resources"
>> ("authorizations" in XAuth) be an object, where the other properties are
>> determined by the "type" property. This allows extensions to define new
>> ways to query for an authorization rather than having to fit into scopes=
 or
>> RAR.
>>
>>
>> It=E2=80=99s my stance that this is an unnecessary limitation at this le=
vel. The
>> objects within the array should be typed, like RAR, but it doesn=E2=80=
=99t make
>> sense for the overall request to be typed. Instead, there should be one
>> =E2=80=9Ctype" of query in the core, what XYZ calls the =E2=80=9Cresourc=
es=E2=80=9D request. Other
>> query languages should be added as extensions either to the RAR-style
>> objects (by defining a type at that level) or as a separate top-level
>> member.
>>
>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D query =
language. My current
>> thought is that this really shouldn=E2=80=99t be a part of the =E2=80=9C=
resources=E2=80=9D or
>> =E2=80=9Cclaims=E2=80=9D part of the request, but instead as its own top=
-level member, like
>> it is in the OIDC protocol today. The main reason for this is the nature=
 of
>> the OIDC claims language: it specifies targets for the resulting data, a=
nd
>> those targets cross different ways to return things. So it doesn=E2=80=
=99t actually
>> affect just resources like the UserInfo Endpoint, or the ID Token, but b=
oth
>> and potentially others out there. If your system supported such an
>> extension, it could theoretically forego both the built-in =E2=80=9Cclai=
ms=E2=80=9D and
>> =E2=80=9Cresources=E2=80=9D parts of the request, and use the =E2=80=9Co=
idc_claims_query=E2=80=9D member
>> (or whatever it would be called). This would let such an extension use t=
he
>> OIDC claims processing mechanism as it is today.
>>
>> To me, this remains much more understandable, extensible, and clean.
>>
>
> While this may be more understandable to a developer just porting an app
> OIDC that only wants OIDC results, but I think it is more complicated as
> soon as the developer wants other results, which is likely what prompted
> the developer to use GNAP instead of ODIC.
>
> I think it is easier to understand if all the claims are in one container=
,
> and all the authorizations are in another container.
>
> If a developer wants access to some resources, some claims, and an OpenID
> Token, they are having to use "claims", "resources", and
> "oidc_claims_query".  Now the claims and access tokens are spread across
> multiple containers. There are some claims in the "claims" container, and
> some "claims" in the "oidc_claims_query" container. And is the access tok=
en
> response in "oidc_claims_query" the same as an access token response in
> "resources"? It would seem simpler if they were, and if all the access
> tokens came back in the same container.
>
> Per Aaron's post that you have referred to, the developer can get sme bar=
e
> claims directly in the response in the "claims" object, an ID Token that
> has the same or different claims, and if they want, an access token that
> they can call a user_info endpoint to get the same, or different claims.
>
> For example, an enterprise app client may want an ID Token with the email
> address, bare claims for the user's name and a URI to a profile photo, an=
d
> an access token to query which groups a user belongs to.
>
> We are still re-using the OIDC claims, but we are not mixing claims and
> authorizations.
>
> /Dick
>
>
> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
> =E1=90=A7
>
>
> =E1=90=A7

--00000000000098fcd105a9f6013e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey Justin,

Just becau=
se=C2=A0we are using OIDC claims, does not mean we need to mimic the OIDC r=
equest and response.
I was envisioning a grant request could look=
 as the following (using XAuth syntax):

{
=C2=A0 =
=C2=A0 "authorizations": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "t=
ype":"oidc",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "claims&quo=
t;: ["name", "picture"]
=C2=A0 =C2=A0 },
=C2=A0 =
=C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "oidc"=
: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id_token" : {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "email"=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "essential" : true },
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "email_verifie=
d" : { "essential" : true }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "userinf=
o" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &quo=
t;name" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : { "essential" :=
 true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "p=
icture" =C2=A0 =C2=A0 =C2=A0 =C2=A0: null
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=
}

Of course a developer could choose to =
only ask for a subset of this.

Note the new author=
ization type of "oidc", that takes "claims" rather than=
 "scope".=C2=A0

This keeps all the autho=
rizations and claims in their respective request and response containers.

We had a thread months ago on the OIDC two stage mo=
del, and I still fail to see why forcing that has any advantage.=C2=A0

/Dick


On Wed, Jul 8, 2020 at 3:25 =
PM Justin Richer <jricher@mit.edu=
> wrote:
I=E2=80=99m glad that we can agree th=
at there are a number of things in legacy protocols that are unfortunate si=
de effects of the circumstances in which they were built. Space-separated s=
cope strings, for instance, would fall in that category, as I=E2=80=99ve pr=
eviously explained.

A key point in the below: the OIDC =
=E2=80=9Cclaims=E2=80=9D request already mixes user claims (returned in an =
API) and authorization (to fetch user claims from an API), so that ship has=
 sailed if you=E2=80=99re using it. It doesn=E2=80=99t make sense to have i=
t under a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D requ=
est, since it=E2=80=99s a query language that affects both. Maybe you=E2=80=
=99d call this another =E2=80=9Cunfortunate design=E2=80=9D, but the contex=
t was about re-using an externally-defined query language that was not made=
 for GNAP.

My scenario was for someone who is already us=
ing =E2=80=9Cclaims=E2=80=9D and wants to keep using it. (The vast majority=
 of OIDC implementations, in my experience, don=E2=80=99t use that feature,=
 and it=E2=80=99s not even required to be implemented by the AS, but again =
we=E2=80=99re talking about using this feature as an example of an external=
 query language =E2=80=94 and there are others out there.) In GNAP, you sho=
uld return claims directly in the response, and request specific elements f=
rom the APIs protected by the access token. These are separate things, and =
by design both XAuth and XYZ have put them into separate containers in the =
request. This is a good design, and so putting something that conflates the=
se two aspects into one or the other of the containers is not a particularl=
y good option, in my opinion.=C2=A0

Additionally, =
though this is a bit of an aside and getting into the specifics of identity=
, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is a query language bound =
to the full user profile. It is my stated position that the items coming ba=
ck from the AS should only be identifiers, and not full profile information=
. The reasoning is pretty simple: the client doesn=E2=80=99t know what prof=
ile information it needs until it knows who the user is, so putting that in=
to a protected API like the UserInfo Endpoint makes much more sense than pu=
tting it into the immediate response, where it is not needed, because the c=
lient already knows it. The AS doesn=E2=80=99t know what the client needs t=
o know, either, so it can=E2=80=99t determine what to fulfill. OIDC=E2=80=
=99s two-stage model makes sense, and GNAP should really only focus on enab=
ling this.

=C2=A0=E2=80=94 Justin
<=
br>
On Jul 8, 2020, at 6:10 PM, Dick Hardt &l=
t;dick.hardt@gmai=
l.com> wrote:


On Wed, J=
ul 8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at 3:16 PM, Dick Hard=
t <dick.hardt@=
gmail.com> wrote:

I think representing the request as an array is =
simplistic, and complicated at the same time.

On the sim=
plistic front, as there is no clear mechanism for extending the request wit=
h properties that apply to all of the request.=C2=A0

The elements of the array are taken as a =
set, to be tied to the same resulting access token. If one of those element=
s is defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s protecting, to=
 apply across some or all of the other elements, then that=E2=80=99s up to =
the AS=E2=80=99s policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OI=
DC, which switches on all sorts of contextual stuff in the request. So to h=
andle something like this, an AS can easily declare that a given scope-styl=
e string or a given object property applies to different parts of the reque=
st. You don=E2=80=99t need to externalize it here.

I view the "openid" scope as an unfortu=
nate design as OIDC was constrained by building=C2=A0on top of OAuth. (a pr=
oblem I hoped to avert by having "identity" in scope for GNAP) Th=
e "openid" scope does not function as scope=C2=A0per se, and I th=
ink it makes OIDC harder to understand as the "openid" scope caus=
es non-scope behavior.=C2=A0

=C2=A0

Do y=
ou have a concrete use case that requires that feature to be done in the wa=
y that you describe? I am trying to separate the driving use case from the =
proposed solutions to see what the differences are.=C2=A0
=


Perhaps the client wants access to be HIPP=
A compliant? The HIPPA compliance signal applies to the scopes.
<=
br>
Adding other properties to an object is a well understood ext=
ension mechanism. Adding an additional element to an array that does not ac=
t like the other elements seems like a hack.

=C2=
=A0
<=
br>
<=
div>
Using JSON type polymorphism=C2=A0requires the AS to tes=
t each member of the array to determine if it is a string or an object. Onl=
y after detecting a RAR object does the AS know the client is making a RAR =
request.=C2=A0

That=E2=80=99s correct =E2=80=94 but the AS needs to parse the who=
le resources request in order to figure out what the client is asking for, =
anyway, whether it=E2=80=99s by strings or objects or whatever else might b=
e defined by an extension. Is there an argument for having an AS do an earl=
y dispatch on a request before it=E2=80=99s fully parsed everything?
<=
/div>

Let me clarify, the code is loo=
king at the type of object that has been parsed.=C2=A0

=

Determining if an item in an array is a scope or a RAR object by looki=
ng at the type being either a string or an object seems less clear than a p=
roperty of an object explicitly declaring the type.

=C2=A0

This also limits the request to be composed only of scope strings or RAR =
objects. I don't see how other strings or objects could be used in the =
array, so there is no clear extension point in the "resources" ar=
ray for other query mechanisms.
That=E2=80=99s not the case in XYZ since we aren=E2=80=99t dec=
laring that a string has to be an OAuth2-style scope. It can be, but ultima=
tely it=E2=80=99s just a string that the AS can understand. And the objects=
 are just that =E2=80=94 objects. If the AS understands what the object is,=
 it can be a RAR object or it can be something completely API-specific with=
 another query language entirely.

But the other query language would need a type that has been reser=
ved in the RAR name space for there to be interop, so it effectively is a R=
AR extension.

There are query languages in other d=
omains that may not fit nicely into RAR such as a query for medical records=
.

Yes, the medical records could be yet another to=
p level property, but per below, I think that is confusing.
=C2=
=A0
(=
Point, though: RAR already pretty much allows this by letting them be exten=
ded infinitely, a feature it inherits from XYZ)

I=
=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99s an a=
rray of strings or objects and each of those means the same thing, =E2=80=
=9Csomething the client is asking for=E2=80=9D.


Just a=
s RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other propert=
ies are determined by the "type" property. This allows extensions=
 to define new ways to query for an authorization rather than having to fit=
 into scopes or RAR.


It=E2=80=99s my stance that this is an unnecessary limitat=
ion at this level. The objects within the array should be typed, like RAR, =
but it doesn=E2=80=99t make sense for the overall request to be typed. Inst=
ead, there should be one =E2=80=9Ctype" of query in the core, what XYZ=
 calls the =E2=80=9Cresources=E2=80=9D request. Other query languages shoul=
d be added as extensions either to the RAR-style objects (by defining a typ=
e at that level) or as a separate top-level member.

For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D query l=
anguage. My current thought is that this really shouldn=E2=80=99t be a part=
 of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D part of the=
 request, but instead as its own top-level member, like it is in the OIDC p=
rotocol today. The main reason for this is the nature of the OIDC claims la=
nguage: it specifies targets for the resulting data, and those targets cros=
s different ways to return things. So it doesn=E2=80=99t actually affect ju=
st resources like the UserInfo Endpoint, or the ID Token, but both and pote=
ntially others out there. If your system supported such an extension, it co=
uld theoretically forego both the built-in =E2=80=9Cclaims=E2=80=9D and =E2=
=80=9Cresources=E2=80=9D parts of the request, and use the =E2=80=9Coidc_cl=
aims_query=E2=80=9D member (or whatever it would be called). This would let=
 such an extension use the OIDC claims processing mechanism as it is today.=


To me, this remains much more understandable, ext=
ensible, and clean.

While=
 this may be more understandable to a developer just=C2=A0porting an app OI=
DC that only wants OIDC results, but I think it is more complicated as soon=
 as the developer wants other results, which is likely what=C2=A0prompted t=
he developer to use GNAP instead of ODIC.

I think =
it is easier to understand if all the claims are in one container, and all =
the authorizations are in another container.

If a =
developer wants access to some resources, some claims, and an OpenID Token,=
 they are having to use "claims", "resources", and &quo=
t;oidc_claims_query".=C2=A0 Now the claims and access tokens are sprea=
d across multiple containers. There are some claims in the "claims&quo=
t; container, and some "claims" in the "oidc_claims_query&qu=
ot; container. And is the access token response in=C2=A0"oidc_claims_q=
uery" the same as an access token response in "resources"? I=
t would seem simpler if they were, and if all the access tokens came back i=
n the same container.

Per Aaron's post that yo=
u have referred to, the developer can get sme bare claims directly in the r=
esponse in the "claims" object, an ID Token that has the same or =
different claims, and if they want, an access token that they can call a us=
er_info endpoint to get the same, or different claims.

=

For example, an enterprise app client may want an ID Token with the em=
ail address, bare claims for the user's name and a URI to a profile pho=
to, and an access token to query which groups a user belongs to.
=

We are still re-using=C2=A0the OIDC claims, but we are not m=
ixing claims and authorizations.

/Dick
<=
br>

3D""=E1=90=A7

=

3D""=E1=90=A7


--00000000000098fcd105a9f6013e--


From nobody Wed Jul  8 16:42: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 F16243A098E for ; Wed,  8 Jul 2020 16:42:45 -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_REMOTE_IMAGE=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 wuiQefJBAI5P for ; Wed,  8 Jul 2020 16:42:41 -0700 (PDT)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0: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 AE42D3A098D for ; Wed,  8 Jul 2020 16:42:41 -0700 (PDT)
Received: by mail-oi1-x22c.google.com with SMTP id e4so441327oib.1 for ; Wed, 08 Jul 2020 16:42: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=3TxQY7D8F5iwxdC2beuUnOYl07J4hnz5ypJ1Q3oQFFA=; b=vYUtMQEeOf0HvNA1QjmJjkqwhan7Tq1ykk9KomKgeBZ2JE9i+101YQOlFdknP2kTMJ Eb6EaycSrhoR7yk+a8dM0BRU1DqRET7s1kVyMo3JKaXnXvHqtJ/FplxHaLNrbRVEZoFa xDf2Oj0o/DcZ4OjMepTdrenvnJLe08ORlqPldip2K9ZzJJ8hteGv7QZHg68goC7nAU7V AC7PXpabGo//DoDjs2UB6iwmgVPu70ZQUv6OLhh2exyiaTCL0bkm4d8nePCDSItda6Zu Z2ivE7oVn7z0n7lQ/mdxHbnK223BZtMRul7JrhM1u5t7N3b3oOVJjhXlrE0jZ24lgppO SKtA==
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=3TxQY7D8F5iwxdC2beuUnOYl07J4hnz5ypJ1Q3oQFFA=; b=KYG+9aV9q+2OfBWTCYPdkQiZgWG31aLuYwF2ntM4t8o9S3BdaeB51IUlZfYlL1IcBM I7bCjDvzT8R6ez5+ZciUVYVZV3Kwb+TTZi8GRfV53Hz3Mi4HagTDK4sucTAzBiY/qu6W Um+ZJvTmJOYQuF3tEL9LuaQV6SvHjeIiU/2sWHNoJDS9Xe0JKdJPPM5G2mKS5qcmZShA L4tcPeXhJeWg8/1aVcO6vEGKcub04uwry4wogBZFXbTR10xH3UW1pf/NFoj25uNhj4KP JqtVpXecUkFOG2w2OiUdhwKdjWwZyYpy7/M85SLfJDgolnzrsHmwcrkhxIi22Xa3GTQK rsJw==
X-Gm-Message-State: AOAM530Yf5kWtCPvXh2njN6nXsASQl09+7keXdW5Ce+bUx7iEuuWxhhT jtOlzNjw1sCk4wF6YvHMS/j9+MoYW+5e/G5UZy4=
X-Google-Smtp-Source: ABdhPJywKNvC3pQTrvWrv6yRjYn6ycM95nnbmE3Ex2y375PnkVz/8ZuPNn+tzBWtezkn37RQkO1+U/7Sr+V3IQVzyc8=
X-Received: by 2002:aca:4b50:: with SMTP id y77mr9024377oia.63.1594251760690;  Wed, 08 Jul 2020 16:42:40 -0700 (PDT)
MIME-Version: 1.0
References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu>   <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <6846D2F0-5096-404B-A529-676146392F45@mit.edu>  
In-Reply-To: 
From: Tom Jones 
Date: Wed, 8 Jul 2020 16:42:28 -0700
Message-ID: 
To: Tobias Looker 
Cc: Justin Richer , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e0ec1705a9f6a9fb"
Archived-At: 
Subject: Re: [Txauth] Use Case: Directed Tokens
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, 08 Jul 2020 23:42:46 -0000

--000000000000e0ec1705a9f6a9fb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

ahh, you mean bearer tokens. Yes, of course. I would not call that
delegation, I would call it fraud. All the more reason to abandon bearer
tokens.
Peace ..tom


On Wed, Jul 8, 2020 at 3:06 PM Tobias Looker 
wrote:

> Tom,
>
> By not creating a formal mechanism for delegation beyond the
> RO->AS->Client, does not mean it wont or cannot occur. For instance if I =
as
> a client get an access token from an AS today in OAuth2.0, I can delegate
> this access to another client by giving them the access_token.
>
> Thanks,
> [image: Mattr website] 
> *Tobias Looker*
> Mattr
> +64 (0) 27 378 0461
> tobias.looker@mattr.global
> [image: Mattr website]  [image: Mattr on LinkedIn]
>  [image: Mattr on Twitter]
>  [image: Mattr on Github]
> 
> This communication, including any attachments, is confidential. If you ar=
e
> not the intended recipient, you should not read it - please contact me
> immediately, destroy it, and do not copy or use any part of this
> communication or disclose anything about it. Thank you. Please note that
> this communication does not designate an information system for the
> purposes of the Electronic Transactions Act 2002.
>
>
> On Thu, Jul 9, 2020 at 6:04 AM Tom Jones 
> wrote:
>
>> I disagree with any approach that would allow the client/RP to
>> delegate anything that it does not own. The RP either has that
>> authority from the RO or AS, or not. Modifying the authority in any way
>> should not be permitted. New RO auth would be required.
>> OTOH any endpoint could be granted agency by the RO. That should not be
>> conflated with an AZ token. If agency is provided by a AZ token it is
>> unclear that it meets any of the various regulations.  Note that this
>> comment does not apply to :"data processors" that are disclosed to the R=
O.
>> Peace ..tom
>>
>>
>> On Tue, Jul 7, 2020 at 1:39 PM Justin Richer  wrote:
>>
>>> I=E2=80=99ve been thinking more about these use cases, and it might hel=
p us to
>>> think of GNAP=E2=80=99s access tokens as capabilities in the computer s=
ecurity
>>> sense =E2=80=94 but more specifically, capabilities that are delivered =
with their
>>> own context for use. In that way, an otherwise naive client can be hand=
ed
>>> an access token and simply know exactly what to do with it. This contex=
t
>>> would be delivered alongside the token, so the token material itself
>>> remains opaque to the client.
>>>
>>> I wanted to bring up a W3C spec for a capabilities model based on linke=
d
>>> data:
>>>
>>> https://w3c-ccg.github.io/zcap-ld/
>>>
>>> Building a fully featured capabilities context is difficult, at the ver=
y
>>> least. And unfortunately, I don=E2=80=99t think this spec actually give=
s us any
>>> viable solutions to work with. In particular the =E2=80=9Cactions=E2=80=
=9D section is
>>> effectively blank, offloading the work to an external JSONLD process (s=
ide
>>> note, this is one of the problems I have with specs based on JSONLD, th=
ey
>>> externalize the important parts into local contexts and break
>>> interoperability =E2=80=94 but I digress). But at least it=E2=80=99s an=
other way of looking
>>> at the problem space that might be outside the familiar zone of many of=
 the
>>> OAuth world.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jun 26, 2020, at 9:23 AM, Justin Richer  wrote:
>>>
>>> On Jun 25, 2020, at 9:07 PM, Tobias Looker 
>>> wrote:
>>>
>>>
>>> I find this feature interesting and think it could be an
>>> important pattern going forward to enable an AS to be able to describe =
the
>>> utility of a token to the client, however as already pointed out in the
>>> thread I think there is some potential hidden complexity that would nee=
d to
>>> be ironed out such that it does not make the simple things complicated.
>>>
>>> Justin, do you see this feature as something the client has to
>>> explicitly request, i.e "please give me access and instructions on how =
to
>>> use my access" or rather that the AS would just return this information=
 in
>>> conjunction with the access token if it had it available?
>>>
>>>
>>> This is something that I=E2=80=99d brought up as a possibility on the p=
revious
>>> thread =E2=80=94 something like a flag the client would set. This would=
 be
>>> especially important if the AS wants to return multiple access tokens b=
ut
>>> the client requested 1, or the client requested N and the AS wants to
>>> return M in response. Basically any time there=E2=80=99s a mismatch, th=
at=E2=80=99s extra
>>> complexity on the client that I really don=E2=80=99t think we want to b=
e universal.
>>> A flag to turn that kind of direction and splitting on would be a poten=
tial
>>> start. But there are potential snags here too, and it comes down to how=
 you
>>> manage the defaults...
>>>
>>> > This is just the start, too. Things get even more complex if the
>>> client can ask for multiple different kinds of resources at once. What =
if
>>> the AS decides that the client needs a hyper-focused directed token for=
 one
>>> part of the API, but can use a general token for other stuff? Can it si=
gnal
>>> that to the client? And if it can, does that mean that all clients need=
 to
>>> be prepared for that kind of thing?
>>>
>>> Would a potential default be that if a client did for any reason not
>>> support processing the additional information returned with the
>>> access_token, just to ignore it? I think in the spirit of keeping the
>>> simple things simple, this potentially makes sense?
>>>
>>>
>>> That=E2=80=99s the real trick, if you ask me. It has to be :safe: for a=
 client
>>> to ignore this information. Which means the AS can=E2=80=99t rely on th=
e client
>>> =E2=80=9Cdoing the right thing=E2=80=9D with the information in the =E2=
=80=9Ctoken directions=E2=80=9D
>>> portion of the response. Even setting aside the advanced and related =
=E2=80=9Csplit
>>> tokens=E2=80=9D idea above, we need to make sure that an AS/RS setup is=
 built such
>>> that if the AS tells a client =E2=80=9Conly do X with your token=E2=80=
=9D and the client
>>> does =E2=80=9CY=E2=80=9D, then there are other protections and practice=
s in place to
>>> prevent things from going haywire if the client does =E2=80=9CY=E2=80=
=9D either by accident
>>> or through ignorance.
>>>
>>> If OAuth 2 has taught us anything, it=E2=80=99s that client application=
s are
>>> going to be the laziest participants in the security model. And that ma=
kes
>>> sense, really =E2=80=94 security isn=E2=80=99t what the client apps are=
 trying to do,
>>> they=E2=80=99re trying to use the RS to do something. So we need to mak=
e sure that
>>> whatever system we design will fail on the safe side as much as possibl=
e,
>>> and keep things simple for the client.
>>>
>>>
>>> > here are some worked out samples of this:
>>> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
>>> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
>>> Peace ..tom
>>>
>>> As one of the authors of those mentioned drafts, I am interested in
>>> discussing that, but perhaps on a seperate thread? As at least the boun=
d
>>> assertion spec is primarily concerned with binding mechanisms for the
>>> artifacts produced from an authorization flow (specifically identity
>>> claims), whereas I think directed access tokens is just more generally
>>> talking about whether GNAP should support an AS conveying how to use an
>>> access_token it produces during a flow with a client.
>>>
>>>
>>> I think that these are separate issues as well.
>>>
>>>  =E2=80=94 Justin
>>>
>>> Thanks,
>>> [image: Mattr website] 
>>> *Tobias Looker*
>>> Mattr
>>> +64 (0) 27 378 0461
>>> tobias.looker@mattr.global
>>> [image: Mattr website]  [image: Mattr on
>>> LinkedIn]  [image: Mattr
>>> on Twitter]  [image: Mattr on Github]
>>> 
>>> This communication, including any attachments, is confidential. If you
>>> are not the intended recipient, you should not read it - please contact=
 me
>>> immediately, destroy it, and do not copy or use any part of this
>>> communication or disclose anything about it. Thank you. Please note tha=
t
>>> this communication does not designate an information system for the
>>> purposes of the Electronic Transactions Act 2002.
>>>
>>>
>>> On Wed, Jun 24, 2020 at 10:14 PM Denis  wrote:
>>>
>>>> Justin, I fear we are still far away from an agreement about what this
>>>> BoF should do.
>>>>
>>>> Tom Jones is saying " I am getting tired of the whack-a-mole approach
>>>> ..."
>>>>
>>>> I don't agree with you when you write: "I think it=E2=80=99s going to =
be
>>>> overwhelmingly common that a given RS is going to trust exactly one AS
>>>> that it knows about ahead of time". Such an architecture would have
>>>> exactly the same limitations as OAuth 2.0. and would not be scalable.
>>>>
>>>> Before we start, we should have a clear view of the whole picture
>>>> rather than starting from one scenario and expanding it in many differ=
ent
>>>> directions.
>>>> For building an architecture, a pre-requirement is to define ALL the
>>>> trust relationships. I don't believe that we have an agreement at this=
 time
>>>> on what
>>>> these trust relationships are.
>>>>
>>>> You are also using the following wording: "methods for the AS and RS t=
o
>>>> communicate what the token=E2=80=99s good for".
>>>> With such a paradigm, it would be impossible to protect the user's
>>>> privacy.
>>>>
>>>> A key question is : Will GNAP take care of the user's privacy or will
>>>> GNAP *prevent *to take care of the user's privacy ?
>>>>
>>>> About "the ability for the client to get several access tokens to get
>>>> different resources from one request" is indeed a complex case.
>>>>
>>>> No one (including ASs) is able to predict in advance which access
>>>> tokens will be needed, since they depend upon the kind of operation(s)
>>>> the client will be willing to perform. For privacy reasons, ASs should
>>>> be kept ignorant of all the operations that a client is going to perfo=
rm
>>>>
>>>> on one or more resource servers. I believe that every effort should be
>>>> made to avoid the AS to be in a position to be able to trace the opera=
tions
>>>>
>>>> performed by its clients on various RSs.
>>>>
>>>> To handle the complex case you envision, the full workflow of
>>>> operations needs to be considered with a detailed focus on the time
>>>> at which the user's *consent and choice* happens (*consent and choice*=
 is
>>>> the first privacy principle from ISO 29100).
>>>>
>>>> First of all, an access token could be targeted to a service rather
>>>> than to a server. This would already solve many cases.
>>>>
>>>> When a RS needs to call another RS (which does not support the same
>>>> service) then the client should be informed by the first RS.
>>>> His "consent and choice" should then be obtained by the first RS and,
>>>> when the user agrees, the client should then ask an access token
>>>> to one of the ASs trusted by the second RS in order to perform the
>>>> subsequent operation.
>>>>
>>>> Denis
>>>>
>>>> PS.  In an email sent on June 23 you wrote: " I think an on-device AS
>>>> is an important use case".  I am sorry, but I don't understand.
>>>>        However, I do understand what "a server-based AS" is.
>>>>
>>>>
>>>> Denis, thanks for the great comments. I think that your trust model is
>>>> pretty different from what I=E2=80=99d laid out initially, and while i=
t=E2=80=99s an
>>>> interesting and important one, it is not what I meant by =E2=80=9Cmult=
iple access
>>>> tokens=E2=80=9D in my discussion below. I think that might be the caus=
e of some
>>>> disconnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of rea=
ch for what the WG is
>>>> after.
>>>>
>>>> When I refer to multiple access tokens, and what the charter calls out
>>>> as multiple access tokens, is the ability for the client to get severa=
l
>>>> access tokens to get different resources from one request. I personall=
y see
>>>> this as an optimization of a specific set of use cases, some of which =
I
>>>> discussed in my original email. There are others, I=E2=80=99m sure, bu=
t all the
>>>> ones I=E2=80=99ve seen are around the client needing to get several di=
fferent kinds
>>>> of access through an AS.
>>>>
>>>> I think it=E2=80=99s going to be overwhelmingly common that a given RS=
 is going
>>>> to trust exactly one AS that it knows about ahead of time. But for RS=
=E2=80=99s
>>>> that can trust multiple AS=E2=80=99s, then we should have a model that=
 can
>>>> accommodate that as well. That=E2=80=99s why the charter calls out met=
hods for the
>>>> AS and RS to communicate what the token=E2=80=99s good for. I think th=
e basis of
>>>> those methods is going to start with a common token model, and likely
>>>> incorporate into things like token formats and introspection-style tok=
en
>>>> APIs.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Jun 22, 2020, at 3:55 AM, Denis  wrote:
>>>>
>>>> Hello Justin,
>>>>
>>>> A few comments between the lines.
>>>>
>>>> One of the most important aspects to GNAP is going to be an ability to
>>>> address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t d=
o without significant
>>>> gymnastics. So with that, I wanted to bring back a use case discussion=
 that
>>>> originally came up while we were talking about the possibility of mult=
iple
>>>> access tokens, a few months back. I don=E2=80=99t know if this concept=
 has a
>>>> regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access=
 tokens=E2=80=9D until we
>>>> come up with something better =E2=80=94 assuming we decide this is wor=
thwhile.
>>>>
>>>> I don't understand what may mean "directed access tokens=E2=80=9D but =
I
>>>> understand what means "multiple access tokens".
>>>> When speaking of "multiple access tokens", these access tokens may com=
e
>>>> from one or more ASs.
>>>>
>>>> In OAuth, the client=E2=80=99s supposed to always know where to send i=
ts access
>>>> token, and that knowledge is completely outside the protocol. This mak=
es a
>>>> lot of sense for many (if not most) deployments, as OAuth is really th=
ere
>>>> to enable the API access that the client already knows about.
>>>>
>>>> But we=E2=80=99re now in a world where a client could be talking to a =
generic
>>>> API that could be deployed at a number of different places, or a cloud
>>>> deployment that the AS wants to be able to dispatch the client to.
>>>>
>>>> As soon the AS is placed (again) at the centre of the model, the AS
>>>> will have the ability to act as "Big Brother".
>>>> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP
>>>> should take care of them.
>>>>
>>>> In order to do this, the AS needs to be able to communicate to the
>>>> client not only the token information (and any related key and present=
ation
>>>> information), but also a set of *directions* about what that specific
>>>> token is good for. This needs to be information outside the token itse=
lf,
>>>> since I believe we want to keep OAuth 2=E2=80=99s feature of having th=
e token be
>>>> opaque to the client. Note: while we could map all of these to differe=
nt
>>>> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parla=
nce)
>>>> on the request side, this isn=E2=80=99t enough to tell the client what=
 to do with
>>>> the token *if it doesn=E2=80=99t know already*.
>>>>
>>>> I know of two use cases already in the wild, where people are
>>>> addressing things using a mix of existing standards and some proprieta=
ry
>>>> extensions to address things within their silos. I=E2=80=99ll try to s=
ummarize
>>>> here, but I know the folks I=E2=80=99ve been talking to about this are=
 also on the
>>>> list so hopefully they can chime in with more detail or any correction=
s for
>>>> something I=E2=80=99ve missed.
>>>>
>>>> (1) The client knows what resource it=E2=80=99s calling, but it doesn=
=E2=80=99t know
>>>> where it=E2=80=99s hosted. Everything is in a single security domain c=
ontrolled by
>>>> the AS,
>>>>
>>>> Speaking of "multiple access tokens" is in contradiction with single
>>>> security domain "controlled" by an AS.
>>>> A user may need to demonstrate some of his identity attributes granted
>>>> e.g. by his bank but may also
>>>> need to demonstrate one or more diplomas granted by one or more
>>>> universities. The bank cannot be
>>>> the "primary issuer" of a university diploma. It should not be either =
a
>>>> "secondary issuer", because
>>>> the bank does not "*need to know"* what are the diplomas of the user.
>>>>
>>>> but the AS needs to decide at runtime which specific instance of the
>>>> API to direct the client to. Since things are closely tied together, t=
he
>>>> client just needs to effectively known an identifier for the RS, and t=
his
>>>> is currently implemented as a URI. Once the client has that identifier=
, it
>>>> knows how to dispatch that token to that instance of the RS.
>>>>
>>>> There is no good reason why the AS should be involved in that step.
>>>> OAuth 2.0 is/was implicitly mandating a strong relationship between AS=
s
>>>> and RSs which makes it non scalable.
>>>> GNAP should be based on a simple trust relationship : a given RS trust=
s
>>>> some ASs for access tokens that contains some types of attributes.
>>>> An AS should not need to know in advance (or even at the time of an
>>>> access token request) the RSs that are trusting it.
>>>>
>>>> A client could first talk to a "global service provider" which has the
>>>> knowledge of the different RSs affiliated to it.
>>>>
>>>> (2) The client knows what kind of thing it=E2=80=99s looking for, but =
doesn=E2=80=99t
>>>> know who to ask it from.
>>>>
>>>> Once again, the client could first talk to a "global service provider"
>>>> which has the knowledge of the different RSs affiliated to it.
>>>>
>>>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS,=
 and the AS needs
>>>> to dispatch to different resources depending on which user logged in (=
and
>>>> possibly what the user consented to). To make things more concrete, th=
e
>>>> client needs to get driver=E2=80=99s license information, but doesn=E2=
=80=99t know ahead of
>>>> time which of the many state/provincial bureaus to call to get that
>>>> information because it doesn=E2=80=99t know yet who the user is.
>>>>
>>>> When a user has a driving license, he knows its issuer. The user can
>>>> then provide some hint to the client.
>>>>
>>>> The AS will know who the user is once they log in and approve things,
>>>> and so it can direct the client to call the correct RS. Since this is =
a
>>>> relatively simple API with a pre-negotiated cross-domain trust, the AS
>>>> returns a URL that the client presents the token at.
>>>>
>>>>  A single AS should not be aware of all the attributes a user has.
>>>>
>>>>
>>>> As far as I know, in both of these cases, the token is only good for
>>>> that API and not others =E2=80=94 but more on that later.
>>>>
>>>> A simple thing to do is just give back a URL with the access token,
>>>> which tells the client where to go.
>>>>
>>>> {
>>>> =E2=80=9Caccess_token=E2=80=9D: {
>>>> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
>>>> =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
>>>> }
>>>> }
>>>>
>>>> This is good for some kinds of APIs, but it=E2=80=99s limiting because=
 not all
>>>> APIs dispatch based on the URL. An AS might want to divvy up access to=
kens
>>>> to an API that=E2=80=99s keyed on headers, or verbs, or any number of =
things. And
>>>> it doesn=E2=80=99t tell us immediately what to do about non-exact URL =
matches. Can
>>>> the client add query parameters and still use the token? What about pa=
th
>>>> segments? I like that this simple approach addresses some common
>>>> deployments that we already see today (see above), it=E2=80=99s not un=
iversal. Do
>>>> we want or need a universal description language for directing where t=
okens
>>>> go?
>>>>
>>>> This also opens up a whole new set of security questions. If the AS ca=
n
>>>> now direct the client where to use the token, could a rogue AS convinc=
e a
>>>> legit client to use a stolen token at the wrong RS? And what if the cl=
ient
>>>> ignores the directions from the AS entirely? Could this open up new av=
enues
>>>> of attack?
>>>>
>>>> This is just the start, too. Things get even more complex if the clien=
t
>>>> can ask for multiple different kinds of resources at once. What if the=
 AS
>>>> decides that the client needs a hyper-focused directed token for one p=
art
>>>> of the API, but can use a general token for other stuff? Can it signal=
 that
>>>> to the client? And if it can, does that mean that all clients need to =
be
>>>> prepared for that kind of thing?
>>>>
>>>> I firmly believe that whatever we build in GNAP, we need to optimize
>>>> for the overwhelmingly common use case of a client getting a single ac=
cess
>>>> token to call APIs that it already knows about. Anything we add on top=
 of
>>>> that really can=E2=80=99t get in the way of this, because if it does, =
there=E2=80=99s very
>>>> small chance that people will try to use this for everyday things. Kee=
p the
>>>> simple things simple, and the complex things possible, after all.
>>>>
>>>> I=E2=80=99m really looking forward to hearing what the community think=
s about
>>>> these use cases, and hopefully the people I=E2=80=99ve chatted with of=
fline about
>>>> this can join the conversation and provide more light than I was able =
to.
>>>>
>>>> The two use cases which are considered above are:
>>>>
>>>> (1) The client knows what resource it=E2=80=99s calling, but it doesn=
=E2=80=99t know
>>>> where it=E2=80=99s hosted.
>>>> (2) The client knows what kind of thing it=E2=80=99s looking for, but =
doesn=E2=80=99t
>>>> know who to ask it from.
>>>>
>>>> That does not mean in any way that these two use cases should be solve=
d
>>>> by placing the AS at the centre of the solution.
>>>>
>>>> Denis
>>>>
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>>
>>>> --
>>>> Txauth mailing list
>>>> Txauth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>
>>>>
>>>> --
>>>> Txauth mailing list
>>>> Txauth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>
>>> This communication, including any attachments, is confidential. If you =
are not the intended recipient, you should not read it - please contact me =
immediately, destroy it, and do not copy or use any part of this communicat=
ion or disclose anything about it. Thank you. Please note that this communi=
cation does not designate an information system for the purposes of the Ele=
ctronic Transactions Act 2002.
>>>
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
> This communication, including any attachments, is confidential. If you ar=
e not the intended recipient, you should not read it - please contact me im=
mediately, destroy it, and do not copy or use any part of this communicatio=
n or disclose anything about it. Thank you. Please note that this communica=
tion does not designate an information system for the purposes of the Elect=
ronic Transactions Act 2002.
>
>

--000000000000e0ec1705a9f6a9fb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


ahh, you mean bearer tokens. Yes, of course. I would not c=
all that delegation, I would call it fraud. All the more reason to abandon =
bearer tokens.
Peace ..tom


On Wed, Jul 8, 2020 at 3:06 PM Tobias Looker <=
tobias.looker@mattr.global> wrote:
Tom,

By not creat=
ing a formal mechanism for delegation beyond the RO->AS->Client, does=
 not mean it wont or cannot occur. For instance if I as a client get an acc=
ess token from an AS today=C2=A0in OAuth2.0, I can delegate this access to =
another client by giving them the access_token.

Thanks,

This communication=
, including any attachments, is confidential. If you are not the intended r=
ecipient, you should not read it - please contact me immediately, destroy i=
t, and do not copy or use any part of this communication or disclose anythi=
ng about it. Thank you. Please note that this communication does not design=
ate an information system for the purposes of the Electronic Transactions A=
ct 2002.


On Thu, Jul 9, 2020 at 6:04=
 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
I disagree with any a=
pproach that would allow the client/RP to delegate=C2=A0anything that it do=
es not own. The RP either has that authority=C2=A0from the RO or AS, or not=
. Modifying the authority in any way should not be permitted. New=C2=A0RO a=
uth would be required.
OTOH any endpoint could be granted agency by the=
 RO. That should not be conflated with an AZ token. If agency is provided b=
y a AZ token it is unclear that it meets any of the various regulations.=C2=
=A0 Note that this comment does not apply to :"data processors" t=
hat are disclosed to the RO.
Peace ..tom


On Tue, Jul 7, =
2020 at 1:39 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99ve been thinking more about these=
 use cases, and it might help us to think of GNAP=E2=80=99s access tokens a=
s capabilities in the computer security sense =E2=80=94 but more specifical=
ly, capabilities that are delivered with their own context for use. In that=
 way, an otherwise naive client can be handed an access token and simply kn=
ow exactly what to do with it. This context would be delivered alongside th=
e token, so the token material itself remains opaque to the client.
I wanted to bring up a W3C spec for a capabilities model based =
on linked data:

<=
br>
Building a fully featured capabilities context is difficult, =
at the very least. And unfortunately, I don=E2=80=99t think this spec actua=
lly gives us any viable solutions to work with. In particular the =E2=80=9C=
actions=E2=80=9D section is effectively blank, offloading the work to an ex=
ternal JSONLD process (side note, this is one of the problems I have with s=
pecs based on JSONLD, they externalize the important parts into local conte=
xts and break interoperability =E2=80=94 but I digress). But at least it=E2=
=80=99s another way of looking at the problem space that might be outside t=
he familiar zone of many of the OAuth world.

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

On Jun 26, 2=
020, at 9:23 AM, Justin Richer <jricher@mit.edu> wrote:

On Jun 25, 2020, at 9:07 PM, Tobias Looker &=
lt;tobias=
.looker@mattr.global>=
; wrote:

I find this feature interesting and think =
it could be an important=C2=A0pattern going=C2=A0forward to enable an AS to=
 be able to describe the utility of a token to the client, however as alrea=
dy pointed out in the thread I think there is some potential hidden complex=
ity that would need to be ironed out such that it does not make the simple =
things complicated.

Justin, do you see this feature as s=
omething the client has to explicitly request, i.e "please give me acc=
ess and instructions on how to use my access" or rather that the AS wo=
uld just return this information in conjunction with the access token if it=
 had it available?


This is something that I=E2=80=99d brought up as a possibility on =
the previous thread =E2=80=94 something like a flag the client would set. T=
his would be especially important if the AS wants to return multiple access=
 tokens but the client requested 1, or the client requested N and the AS wa=
nts to return M in response. Basically any time there=E2=80=99s a mismatch,=
 that=E2=80=99s extra complexity on the client that I really don=E2=80=99t =
think we want to be universal. A flag to turn that kind of direction and sp=
litting on would be a potential start. But there are potential snags here t=
oo, and it comes down to how you manage the defaults...

> This is just the start, too=
. Things get even more complex if the client can ask for multiple different=
 kinds of resources at once. What if the AS decides that the client needs a=
 hyper-focused directed token for one part of the API, but can use a genera=
l token for other stuff? Can it signal that to the client? And if it can, d=
oes that mean that all clients need to be prepared for that kind of thing?<=
/div>

Would a potential default be that if a client did =
for any reason not support processing the additional information returned w=
ith the access_token, just to ignore it? I think in the spirit of keeping t=
he simple things simple, this potentially makes sense?

That=E2=80=99s the real trick, if you ask me.=
 It has to be :safe: for a client to ignore this information. Which means t=
he AS can=E2=80=99t rely on the client =E2=80=9Cdoing the right thing=E2=80=
=9D with the information in the =E2=80=9Ctoken directions=E2=80=9D portion =
of the response. Even setting aside the advanced and related =E2=80=9Csplit=
 tokens=E2=80=9D idea above, we need to make sure that an AS/RS setup is bu=
ilt such that if the AS tells a client =E2=80=9Conly do X with your token=
=E2=80=9D and the client does =E2=80=9CY=E2=80=9D, then there are other pro=
tections and practices in place to prevent things from going haywire if the=
 client does =E2=80=9CY=E2=80=9D either by accident or through ignorance.=
=C2=A0

If OAuth 2 has taught us anything, it=E2=80=
=99s that client applications are going to be the laziest participants in t=
he security model. And that makes sense, really =E2=80=94 security isn=E2=
=80=99t what the client apps are trying to do, they=E2=80=99re trying to us=
e the RS to do something. So we need to make sure that whatever system we d=
esign will fail on the safe side as much as possible, and keep things simpl=
e for the client.

=


> here are some worked out samples of this:
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_=
Token
Peace ..tom

As one of the authors of those=
 mentioned drafts, I am interested in discussing that, but perhaps on a sep=
erate thread? As at least=C2=A0the bound assertion spec is=C2=A0primarily=
=C2=A0concerned with binding mechanisms for the artifacts produced from an =
authorization flow (specifically identity claims), whereas I think directed=
 access tokens is just more generally talking about whether GNAP should sup=
port an AS conveying how to use an access_token it produces during a flow w=
ith a client.


I think that these are separate issues =
as well.

=C2=A0=E2=80=94 Justin

Thanks,
=3D"Mattr=C2=A0
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr3D=3D"Ma=3D"Mattr
=

=
3D"Mattr=C2=A0
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
=3D"Mattr3D"Mattr3D"Mattr=3D"Mattr

This communication, in=
cluding any attachments, is confidential. If you are not the intended recip=
ient, you should not read it - please contact me immediately, destroy it, a=
nd do not copy or use any part of this communication or disclose anything a=
bout it. Thank you. Please note that this communication does not designate =
an information system for the purposes of the Electronic Transactions Act 2=
002.


On Wed, Jun 24, 2020 at 10:14 P=
M Denis <denis.i=
etf@free.fr> wrote:
Justin, I fear we are still far away from an agreement=
 about what this BoF should do.

Tom Jones is sayin=
g " I am getting tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it=E2=
=80=99s going to be overwhelmingly common that a given RS is going to trust=
 exactly one AS=C2=A0
that it knows about ahead of tim=
e". Such an architecture would have exactly the same limitations as OA=
uth 2.0. and would not be scalable.

Before we=
 start, we should have a clear view of the whole picture rather than starti=
ng from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the tru=
st relationships. I don't believe that we have an agreement at this tim=
e on what=C2=A0
these trust relationships are.=C2=A0<=
/span>

You are also using the following word=
ing: "methods for the AS and RS to communicate what the token=E2=80=99=
s good for".=C2=A0
With such a paradigm, it would be i=
mpossible to protect the user's privacy.=C2=A0

A key question is : Will GNAP take care of the user's=
 privacy or will GNAP=C2=A0prevent=C2=A0to=
 take care of the user's privacy ?

About "=
;the ability for the client to get several access tokens to get different r=
esources from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access t=
okens will be needed, since they depend upon the kind of operation(s)=
=C2=A0
the client will be willing to perform. For privacy reasons=
, ASs should be kept ignorant of all the operations that a client is going =
to perform=C2=A0
on one or more resource servers. I believe=
 that every effort should be made to avoid the AS to be in a position to be=
 able to trace the operations=C2=A0
performed by its client=
s on various RSs.

To handle the complex case you e=
nvision, the full workflow of operations needs to be considered with a deta=
iled focus on the time=C2=A0
at which the user's=
=C2=A0consent and choice=C2=A0happens (consen=
t and choice=C2=A0is the first privacy principle from ISO =
29100).

First of all, an access token could be tar=
geted to a service rather than to a server. This would already solve many c=
ases.

When a RS needs to call another RS (which do=
es not support the same service) then the client should be informed by the =
first RS.
His "consent and choice" should then be obtai=
ned by the first RS and, when the user agrees, the client should then ask a=
n access token=C2=A0
to one of the ASs trusted by the secon=
d RS in order to perform the subsequent operation.=C2=A0=C2=A0=


Denis

PS.=C2=A0 In a=
n email sent on June 23 you wrote: " I think an on-device AS is an imp=
ortant use case".=C2=A0 I am sorry, but I don't understand.
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 However, I do understand what "a ser=
ver-based AS" is.


Denis, thanks for the great comments. I think that your trust =
model is pretty different from what I=E2=80=99d laid out initially, and whi=
le it=E2=80=99s an interesting and important one, it is not what I meant by=
 =E2=80=9Cmultiple access tokens=E2=80=9D in my discussion below. I think t=
hat might be the cause of some disconnect here, but that doesn=E2=80=99t me=
an it=E2=80=99s out of reach for what the WG is after.

W=
hen I refer to multiple access tokens, and what the charter calls out as mu=
ltiple access tokens, is the ability for the client to get several access t=
okens to get different resources from one request. I personally see this as=
 an optimization of a specific set of use cases, some of which I discussed =
in my original email. There are others, I=E2=80=99m sure, but all the ones =
I=E2=80=99ve seen are around the client needing to get several different ki=
nds of access through an AS.=C2=A0

I think it=E2=80=
=99s going to be overwhelmingly common that a given RS is going to trust ex=
actly one AS that it knows about ahead of time. But for RS=E2=80=99s that c=
an trust multiple AS=E2=80=99s, then we should have a model that can accomm=
odate that as well. That=E2=80=99s why the charter calls out methods for th=
e AS and RS to communicate what the token=E2=80=99s good for. I think the b=
asis of those methods is going to start with a common token model, and like=
ly incorporate into things like token formats and introspection-style token=
 APIs.=C2=A0

=C2=A0=E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr>=
 wrote:

Hello Justin,

A few comments between the lines.

One of the most important aspects to GNAP is going to be an ability to add=
ress things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do withou=
t significant gymnastics. So with that, I wanted to bring back a use case d=
iscussion that originally came up while we were talking about the possibili=
ty of multiple access tokens, a few months back. I don=E2=80=99t know if th=
is concept has a regular term, so I=E2=80=99m going to call it =E2=80=9Cdir=
ected access tokens=E2=80=9D until we come up with something better =E2=80=
=94 assuming we decide this is worthwhile.=C2=A0
I don't understand what may mean "directed a=
ccess tokens=E2=80=9D but I understand what means "multiple access tok=
ens".=C2=A0
When speaking of "multiple access tok=
ens", these access tokens may come from one or more ASs.
In OAuth, the client=E2=80=99s sup=
posed to always know where to send its access token, and that knowledge is =
completely outside the protocol. This makes a lot of sense for many (if not=
 most) deployments, as OAuth is really there to enable the API access that =
the client already knows about.

But we=E2=80=99re =
now in a world where a client could be talking to a generic API that could =
be deployed at a number of different places, or a cloud deployment that the=
 AS wants to be able to dispatch the client to.=C2=A0
As soon the AS is placed (again) at the centre=
 of the model, the AS will have the ability to act as "Big Brother&quo=
t;.
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNA=
P should take care of them.
In order to do this, the AS needs to be able to communicate to the clien=
t not only the token information (and any related key and presentation info=
rmation), but also a set of=C2=A0directions=C2=A0about =
what that specific token is good for. This needs to be information outside =
the token itself, since I=C2=A0believe we want to keep OAuth 2=E2=80=99s fe=
ature of having the token be opaque to the client. Note: while we could map=
 all of these to different resource requests (in XYZ parlance) or scopes (i=
n OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t enough t=
o tell the client what to do with the token=C2=A0if it does=
n=E2=80=99t know already.=C2=A0

I know of two =
use cases already in the wild, where people are addressing things using a m=
ix of existing standards and some proprietary extensions to address things =
within their silos. I=E2=80=99ll try to summarize here, but I know the folk=
s I=E2=80=99ve been talking to about this are also on the list so hopefully=
 they can chime in with more detail or any corrections for something I=E2=
=80=99ve missed.=C2=A0

(1) The client knows what r=
esource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99=
s hosted. Everything is in a single security domain controlled by the AS,=C2=A0
Speaking of "mu=
ltiple access tokens" is in contradiction with single security domain =
"controlled" by an AS.=C2=A0
A user may need to d=
emonstrate some of his identity attributes granted e.g. by his bank but may=
 also=C2=A0
need to demonstrate one or more diplomas grante=
d by one or more universities. The bank cannot be=C2=A0
the=
 "primary issuer" of a university diploma. It should not be eithe=
r a "secondary issuer", because=C2=A0
the bank do=
es not "need to know"=C2=A0what are the diplo=
mas of the user.
but =
the AS needs to decide at runtime which specific instance of the API to dir=
ect the client to. Since things are closely tied together, the client just =
needs to effectively known an identifier for the RS, and this is currently =
implemented as a URI. Once the client has that identifier, it knows how to =
dispatch that token to that instance of the RS.
There is no good reason why the AS should be involved in that st=
ep.=C2=A0
OAuth 2.0 is/was implicitly mandating a strong re=
lationship between ASs and RSs which makes it non scalable.
GNAP should =
be based on a simple trust relationship : a given RS trusts some ASs for ac=
cess tokens that contains some types of attributes.
An AS should not nee=
d to know in advance (or even at the time of an access token request) the R=
Ss that are trusting it.
A client could first tal=
k to a "global service provider" which has the knowledge of the d=
ifferent RSs affiliated to it.=C2=A0
(2) The client knows what kind of thing it=
=E2=80=99s looking for, but doesn=E2=80=99t know who to ask it from.=
=C2=A0
Once again, the client c=
ould first talk to a "global service provider" which has the know=
ledge of the different RSs affiliated to it.=C2=A0
There=E2=80=99s a cross-domain trust=
 that=E2=80=99s bridged by the AS, and the AS needs to dispatch to differen=
t resources depending on which user logged in (and possibly what the user c=
onsented to). To make things more concrete, the client needs to get driver=
=E2=80=99s license information, but doesn=E2=80=99t know ahead of time whic=
h of the many state/provincial bureaus to call to get that information beca=
use it doesn=E2=80=99t know yet who the user is.=C2=A0
When a user has a driving license, he knows i=
ts issuer. The user can then provide some hint to the client.
The AS will know who the user is once =
they log in and approve things, and so it can direct the client to call the=
 correct RS. Since this is a relatively simple API with a pre-negotiated cr=
oss-domain trust, the AS returns a URL that the client presents the token a=
t.=C2=A0
=C2=A0A sing=
le AS should not be aware of all the attributes a user has.=C2=A0

As=
 far as I know, in both of these cases, the token is only good for that API=
 and not others =E2=80=94 but more on that later.

=
A simple thing to do is just give back a URL with the access token, which t=
ells the client where to go.=C2=A0

	{
		=E2=80=9Caccess_token=E2=80=9D: {
			=E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=
=E2=80=9D,
			=E2=80=
=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
		}
	}

This is good for some kinds of APIs, but it=
=E2=80=99s limiting because not all APIs dispatch based on the URL. An AS m=
ight want to divvy up access tokens to an API that=E2=80=99s keyed on heade=
rs, or verbs, or any number of things. And it doesn=E2=80=99t tell us immed=
iately what to do about non-exact URL matches. Can the client add query par=
ameters and still use the token? What about path segments? I like that this=
 simple approach addresses some common deployments that we already see toda=
y (see above), it=E2=80=99s not universal. Do we want or need a universal d=
escription language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can no=
w direct the client where to use the token, could a rogue AS convince a leg=
it client to use a stolen token at the wrong RS? And what if the client ign=
ores the directions from the AS entirely? Could this open up new avenues of=
 attack?

This is just the start, too. Things get e=
ven more complex if the client can ask for multiple different kinds of reso=
urces at once. What if the AS decides that the client needs a hyper-focused=
 directed token for one part of the API, but can use a general token for ot=
her stuff? Can it signal that to the client? And if it can, does that mean =
that all clients need to be prepared for that kind of thing?

=

I firmly believe that whatever we build in GNAP, we need to opti=
mize for the overwhelmingly common use case of a client getting a single ac=
cess token to call APIs that it already knows about. Anything we add on top=
 of that really can=E2=80=99t get in the way of this, because if it does, t=
here=E2=80=99s very small chance that people will try to use this for every=
day things. Keep the simple things simple, and the complex things possible,=
 after all.

I=E2=80=99m really looking forward to =
hearing what the community thinks about these use cases, and hopefully the =
people I=E2=80=99ve chatted with offline about this can join the conversati=
on and provide more light than I was able to.
The two use cases which are considered above are:
(1) The client knows what resource it=E2=80=99s calling, b=
ut it doesn=E2=80=99t know where it=E2=80=99s hosted.
(2) The client kno=
ws what kind of thing it=E2=80=99s looking for, but doesn=E2=80=99t know wh=
o to ask it from.=C2=A0
That does not mean in any way that these two use cases should be solved by=
 placing the AS at the centre of the solution.
Denis<=
/p>

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


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


--=C2=A0
Txauth mailing list
Txauth@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/txauth" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/txauth

This communication=
, including any attachments, is confidential. If you are not the intended r=
ecipient, you should not read it - please contact me immediately, destroy i=
t, and do not copy or use any part of this communication or disclose anythi=
ng about it. Thank you. Please note that this communication does not design=
ate an information system for the purposes of the Electronic Transactions A=
ct 2002.

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

-- 

Txauth mailing list

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







This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.


--000000000000e0ec1705a9f6a9fb--


From nobody Wed Jul  8 18:31:43 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 3838E3A0B5E for ; Wed,  8 Jul 2020 18:31:42 -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 pWZq_P0avZIK for ; Wed,  8 Jul 2020 18:31: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 1A1C53A0B5B for ; Wed,  8 Jul 2020 18:31:39 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id s9so447167ljm.11 for ; Wed, 08 Jul 2020 18:31: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=6EIWDn6Pd2qhr0KrJ7JfYiTDS27OfIEmyasJMZekISA=; b=mQUeQOFHNMdJQ6Z0x1G1Gq0xXiS7zhNd8yTCogUJEEdoQBabuz7ruh52eHIx5avDxc 1o+N3Yo1pfLQK46wHJNYaeOlHCXxodADkVUr6mqQCSvMmvFgouP6z+8eRBVNEoVNtrGn VzNIjJWMnGNCvnh9Cv8KTTlyIlJOwhOltegUxSS7hfBc2totixZ1SPe4SnJ8YVNGnxAx 1pR0pZc3y+VqHzvxmrqjrjG9oNkvVn/kZBe1i9yGMOXPIud8Qvrm0y+jQGVTo/Pa4wcR h+3BV/5vy4p1JubNy2x8mtbToIE4Vla03MW9R3gTqWflOoVNVMIzDgxqsbSrrwW2Rl+v WuHA==
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=6EIWDn6Pd2qhr0KrJ7JfYiTDS27OfIEmyasJMZekISA=; b=muu79AvHK9W2yMJqHUKlELAfyJ9vNFJ97j3PiZ16y8FJDKsoqAbOHQOs7yGtt4TXEG IEv4ee5ipq2Q1lQQtdlH5il1RKg+IhD4rxvOffyG80529LXCNz86L4jVAkrtaRl80VIJ mBkwjIg4zJxaLc8JqrRWXT4BWmIrtWcLeGwEQZg2RYpwh66jC9uZtYmUw+PYY6tAfBxX 0rYXFg3QyNoTbMpLMFA0pGUP6W7ZliRyTT7BFU0CBe2urtX0dJ9yOWyYP5DlyEv5idQQ 0rHaW/PcdRHktREkFvH9AZw1t464HJsrH0reV8lDcsNKjj8DNQMqe7i/ixPBoHLEMDvd hOyA==
X-Gm-Message-State: AOAM530LJm9t3f1PPo1B6qXb0yyqm55xYebB5luMqg+EjNHZVlsEGSaL cHdXxlN9Y6jm8dTCY+7gRvxyZ3xoQofhDXdZn4E=
X-Google-Smtp-Source: ABdhPJyYZxAowcZNJgt/8qBc+3Te2h4pSGy5gJbMTwLR9NsgGDzDx0e4AGdDUZSb53ydcGeIgYBVg/ZSuu0Cby8/PBc=
X-Received: by 2002:a05:651c:547:: with SMTP id q7mr33216448ljp.437.1594258296978;  Wed, 08 Jul 2020 18:31:36 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu> 
In-Reply-To: 
From: Dick Hardt 
Date: Wed, 8 Jul 2020 18:31:00 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000078c52b05a9f82f9e"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 09 Jul 2020 01:31:42 -0000

--00000000000078c52b05a9f82f9e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I had intended to provide a code sample comparing XYZ request type with
XAuth request type

Let's say an AS only supports OAuth scopes (does not support RAR). Here is
JS code to check:

//XYZ code

var oauth_scope =3D true;
requests.forEach( item =3D> {
    if (typeof item =3D=3D=3D "object")
        oauth_scope =3D false;
});
if (!'oauth_scope') {
    // return error
}

// XAuth code

if ('oauth_scope' !=3D authorizations.type) {
   // return error
}


Here is some JS code that for an AS that supports OAuth scopes, RAR, and
OIDC requests:

// XYZ

if (request) {
    requests.forEach( item =3D> {
        if (typeof item =3D=3D=3D "object") {
            // process a RAR item
        } else if(typeof item =3D=3D=3D 'string') {
            // process a scope item
        } else {
            // throw an error
        }
    })
   // process the whole request
}
if (oidc_claims_query) {
    // process oidc request
}

//XAuth

if (authorizations) {
    switch (authorizations?.type) {
        case 'oauth_rar':
            // process authorizations.details - RAR
        case 'oauth_scope':
            // process authorizations.scope
            // process the whole request
            break;
        case 'oidc':
            // process OIDC claims
            break;
        default:
            // error for unknown type
    }
}


Understanding what the code is doing looks much clearer in XAuth to me.

=E1=90=A7

On Wed, Jul 8, 2020 at 3:55 PM Dick Hardt  wrote:

> Hey Justin,
>
> Just because we are using OIDC claims, does not mean we need to mimic the
> OIDC request and response.
> I was envisioning a grant request could look as the following (using XAut=
h
> syntax):
>
> {
>     "authorizations": {
>         "type":"oidc",
>         "claims": ["name", "picture"]
>     },
>     "claims":{
>         "oidc": {
>             "id_token" : {
>                 "email"          : { "essential" : true },
>                 "email_verified" : { "essential" : true }
>             },
>             "userinfo" : {
>                 "name"           : { "essential" : true },
>                 "picture"        : null
>             }
>         }
>     }
> }
>
> Of course a developer could choose to only ask for a subset of this.
>
> Note the new authorization type of "oidc", that takes "claims" rather tha=
n
> "scope".
>
> This keeps all the authorizations and claims in their respective request
> and response containers.
>
> We had a thread months ago on the OIDC two stage model, and I still fail
> to see why forcing that has any advantage.
>
> /Dick
>
>
> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer  wrote:
>
>> I=E2=80=99m glad that we can agree that there are a number of things in =
legacy
>> protocols that are unfortunate side effects of the circumstances in whic=
h
>> they were built. Space-separated scope strings, for instance, would fall=
 in
>> that category, as I=E2=80=99ve previously explained.
>>
>> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request alre=
ady mixes user
>> claims (returned in an API) and authorization (to fetch user claims from=
 an
>> API), so that ship has sailed if you=E2=80=99re using it. It doesn=E2=80=
=99t make sense to
>> have it under a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorizations=E2=
=80=9D request, since it=E2=80=99s a query
>> language that affects both. Maybe you=E2=80=99d call this another =E2=80=
=9Cunfortunate
>> design=E2=80=9D, but the context was about re-using an externally-define=
d query
>> language that was not made for GNAP.
>>
>> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=
=9D and wants to
>> keep using it. (The vast majority of OIDC implementations, in my
>> experience, don=E2=80=99t use that feature, and it=E2=80=99s not even re=
quired to be
>> implemented by the AS, but again we=E2=80=99re talking about using this =
feature as
>> an example of an external query language =E2=80=94 and there are others =
out there.)
>> In GNAP, you should return claims directly in the response, and request
>> specific elements from the APIs protected by the access token. These are
>> separate things, and by design both XAuth and XYZ have put them into
>> separate containers in the request. This is a good design, and so puttin=
g
>> something that conflates these two aspects into one or the other of the
>> containers is not a particularly good option, in my opinion.
>>
>> Additionally, though this is a bit of an aside and getting into the
>> specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is=
 a query language
>> bound to the full user profile. It is my stated position that the items
>> coming back from the AS should only be identifiers, and not full profile
>> information. The reasoning is pretty simple: the client doesn=E2=80=99t =
know what
>> profile information it needs until it knows who the user is, so putting
>> that into a protected API like the UserInfo Endpoint makes much more sen=
se
>> than putting it into the immediate response, where it is not needed,
>> because the client already knows it. The AS doesn=E2=80=99t know what th=
e client
>> needs to know, either, so it can=E2=80=99t determine what to fulfill. OI=
DC=E2=80=99s
>> two-stage model makes sense, and GNAP should really only focus on enabli=
ng
>> this.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 8, 2020, at 6:10 PM, Dick Hardt  wrote:
>>
>>
>>
>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer  wrote:
>>
>>> On Jul 8, 2020, at 3:16 PM, Dick Hardt  wrote:
>>>
>>>
>>> I think representing the request as an array is simplistic, and
>>> complicated at the same time.
>>>
>>> On the simplistic front, as there is no clear mechanism for extending
>>> the request with properties that apply to all of the request.
>>>
>>>
>>> The elements of the array are taken as a set, to be tied to the same
>>> resulting access token. If one of those elements is defined, by the AS
>>> and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some o=
r all of the other
>>> elements, then that=E2=80=99s up to the AS=E2=80=99s policy. Much like =
the =E2=80=9Copenid=E2=80=9D scope
>>> in OIDC, which switches on all sorts of contextual stuff in the request=
. So
>>> to handle something like this, an AS can easily declare that a given
>>> scope-style string or a given object property applies to different part=
s of
>>> the request. You don=E2=80=99t need to externalize it here.
>>>
>>
>> I view the "openid" scope as an unfortunate design as OIDC was
>> constrained by building on top of OAuth. (a problem I hoped to avert by
>> having "identity" in scope for GNAP) The "openid" scope does not functio=
n
>> as scope per se, and I think it makes OIDC harder to understand as the
>> "openid" scope causes non-scope behavior.
>>
>>
>>
>>>
>>> Do you have a concrete use case that requires that feature to be done i=
n
>>> the way that you describe? I am trying to separate the driving use case
>>> from the proposed solutions to see what the differences are.
>>>
>>
>> Perhaps the client wants access to be HIPPA compliant? The HIPPA
>> compliance signal applies to the scopes.
>>
>> Adding other properties to an object is a well understood extension
>> mechanism. Adding an additional element to an array that does not act li=
ke
>> the other elements seems like a hack.
>>
>>
>>
>>>
>>>
>>> Using JSON type polymorphism requires the AS to test each member of the
>>> array to determine if it is a string or an object. Only after detecting=
 a
>>> RAR object does the AS know the client is making a RAR request.
>>>
>>>
>>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole re=
sources request
>>> in order to figure out what the client is asking for, anyway, whether i=
t=E2=80=99s
>>> by strings or objects or whatever else might be defined by an extension=
. Is
>>> there an argument for having an AS do an early dispatch on a request be=
fore
>>> it=E2=80=99s fully parsed everything?
>>>
>>
>> Let me clarify, the code is looking at the type of object that has been
>> parsed.
>>
>> Determining if an item in an array is a scope or a RAR object by looking
>> at the type being either a string or an object seems less clear than a
>> property of an object explicitly declaring the type.
>>
>>
>>
>>>
>>> This also limits the request to be composed only of scope strings or RA=
R
>>> objects. I don't see how other strings or objects could be used in the
>>> array, so there is no clear extension point in the "resources" array fo=
r
>>> other query mechanisms.
>>>
>>>
>>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring th=
at a string has
>>> to be an OAuth2-style scope. It can be, but ultimately it=E2=80=99s jus=
t a string
>>> that the AS can understand. And the objects are just that =E2=80=94 obj=
ects. If the
>>> AS understands what the object is, it can be a RAR object or it can be
>>> something completely API-specific with another query language entirely.
>>>
>>
>> But the other query language would need a type that has been reserved in
>> the RAR name space for there to be interop, so it effectively is a RAR
>> extension.
>>
>> There are query languages in other domains that may not fit nicely into
>> RAR such as a query for medical records.
>>
>> Yes, the medical records could be yet another top level property, but pe=
r
>> below, I think that is confusing.
>>
>>
>>> (Point, though: RAR already pretty much allows this by letting them be
>>> extended infinitely, a feature it inherits from XYZ)
>>>
>>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99s=
 an array of
>>> strings or objects and each of those means the same thing, =E2=80=9Csom=
ething the
>>> client is asking for=E2=80=9D.
>>>
>>>
>>> Just as RAR has a "type" property, I propose the "resources"
>>> ("authorizations" in XAuth) be an object, where the other properties ar=
e
>>> determined by the "type" property. This allows extensions to define new
>>> ways to query for an authorization rather than having to fit into scope=
s or
>>> RAR.
>>>
>>>
>>> It=E2=80=99s my stance that this is an unnecessary limitation at this l=
evel. The
>>> objects within the array should be typed, like RAR, but it doesn=E2=80=
=99t make
>>> sense for the overall request to be typed. Instead, there should be one
>>> =E2=80=9Ctype" of query in the core, what XYZ calls the =E2=80=9Cresour=
ces=E2=80=9D request. Other
>>> query languages should be added as extensions either to the RAR-style
>>> objects (by defining a type at that level) or as a separate top-level
>>> member.
>>>
>>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D query=
 language. My current
>>> thought is that this really shouldn=E2=80=99t be a part of the =E2=80=
=9Cresources=E2=80=9D or
>>> =E2=80=9Cclaims=E2=80=9D part of the request, but instead as its own to=
p-level member, like
>>> it is in the OIDC protocol today. The main reason for this is the natur=
e of
>>> the OIDC claims language: it specifies targets for the resulting data, =
and
>>> those targets cross different ways to return things. So it doesn=E2=80=
=99t actually
>>> affect just resources like the UserInfo Endpoint, or the ID Token, but =
both
>>> and potentially others out there. If your system supported such an
>>> extension, it could theoretically forego both the built-in =E2=80=9Ccla=
ims=E2=80=9D and
>>> =E2=80=9Cresources=E2=80=9D parts of the request, and use the =E2=80=9C=
oidc_claims_query=E2=80=9D member
>>> (or whatever it would be called). This would let such an extension use =
the
>>> OIDC claims processing mechanism as it is today.
>>>
>>> To me, this remains much more understandable, extensible, and clean.
>>>
>>
>> While this may be more understandable to a developer just porting an app
>> OIDC that only wants OIDC results, but I think it is more complicated as
>> soon as the developer wants other results, which is likely what prompted
>> the developer to use GNAP instead of ODIC.
>>
>> I think it is easier to understand if all the claims are in one
>> container, and all the authorizations are in another container.
>>
>> If a developer wants access to some resources, some claims, and an OpenI=
D
>> Token, they are having to use "claims", "resources", and
>> "oidc_claims_query".  Now the claims and access tokens are spread across
>> multiple containers. There are some claims in the "claims" container, an=
d
>> some "claims" in the "oidc_claims_query" container. And is the access to=
ken
>> response in "oidc_claims_query" the same as an access token response in
>> "resources"? It would seem simpler if they were, and if all the access
>> tokens came back in the same container.
>>
>> Per Aaron's post that you have referred to, the developer can get sme
>> bare claims directly in the response in the "claims" object, an ID Token
>> that has the same or different claims, and if they want, an access token
>> that they can call a user_info endpoint to get the same, or different
>> claims.
>>
>> For example, an enterprise app client may want an ID Token with the emai=
l
>> address, bare claims for the user's name and a URI to a profile photo, a=
nd
>> an access token to query which groups a user belongs to.
>>
>> We are still re-using the OIDC claims, but we are not mixing claims and
>> authorizations.
>>
>> /Dick
>>
>>
>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
>> =E1=90=A7
>>
>>
>> =E1=90=A7
>

--00000000000078c52b05a9f82f9e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I had intended to provide a code sample comparing XYZ requ=
est type with XAuth request type

Let's say an AS=
 only supports OAuth scopes (does not support RAR). Here is JS code to chec=
k:

//XYZ code
var oauth_scope =3D true;
requests=
.forEach( item =3D> {=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 
=C2=A0=
 =C2=A0 if (typeof item =3D=3D=3D "object")
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 oauth_scope =3D false;
});
if (!'=
oauth_scope') {
=C2=A0 =C2=A0 // return error
}

// XAuth code
if ('oauth_scope' !=3D aut=
horizations.type) {
=C2=A0 =C2=A0// return error
}

Here is some JS code that for an AS that =
supports OAuth scopes, RAR, and OIDC requests:

// XYZ
if (request) {=

=C2=A0 =C2=A0 requests.forEach( item =3D> {
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 if (typeof item =3D=3D=3D "object") {
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 // process a RAR item
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 } else if(typeof item =3D=3D=3D 'string') {
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // process a scope item
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 } else {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // throw an e=
rror
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }) =C2=A0 =C2=A0
=
=C2=A0 =C2=A0// process the whole request
}
if (oidc_claims_query) {<=
br>=C2=A0 =C2=A0 // process oidc request
}

//XAuth
if (autho=
rizations) {
=C2=A0 =C2=A0 switch (authorizations?.type) {
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 case 'oauth_rar':
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // process authorizations.details - RAR 
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 case 'oauth_scope':
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 // process authorizations.scope
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // process the whole request
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 break;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case 'oidc':=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // process OIDC claims
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 d=
efault:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // error for unknown t=
ype
=C2=A0 =C2=A0 }
}=C2=A0 =C2=A0=C2=A0


Understanding what the code is doing looks much clea=
rer in XAuth to me.

3D""=E1=90=A7
On W=
ed, Jul 8, 2020 at 3:55 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Justin,
Just because=C2=A0we are using OIDC claims, does not mean =
we need to mimic the OIDC request and response.
I was envisioning=
 a grant request could look as the following (using XAuth syntax):
=

{
=C2=A0 =C2=A0 "authorizations": {
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "type":"oidc",
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "claims": ["name", "picture"]=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "id_token" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "email" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "=
;essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 "email_verified" : { "essential" : true }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "userinfo" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "name" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 : { "essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "picture" =C2=A0 =C2=A0 =C2=A0 =C2=A0=
: null
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 }
=C2=A0 =C2=A0 }
}

Of =
course a developer could choose to only ask for a subset of this.

Note the new authorization type of "oidc", that t=
akes "claims" rather than "scope".=C2=A0

=

This keeps all the authorizations and claims in their respective=
 request and response containers.

We had a thread =
months ago on the OIDC two stage model, and I still fail to see why forcing=
 that has any advantage.=C2=A0

/Dick

On Wed, Jul 8, 2020 at 3:25 PM Justin Richer <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">
I=E2=80=99m glad that=
 we can agree that there are a number of things in legacy protocols that ar=
e unfortunate side effects of the circumstances in which they were built. S=
pace-separated scope strings, for instance, would fall in that category, as=
 I=E2=80=99ve previously explained.

A key point in the b=
elow: the OIDC =E2=80=9Cclaims=E2=80=9D request already mixes user claims (=
returned in an API) and authorization (to fetch user claims from an API), s=
o that ship has sailed if you=E2=80=99re using it. It doesn=E2=80=99t make =
sense to have it under a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorization=
s=E2=80=9D request, since it=E2=80=99s a query language that affects both. =
Maybe you=E2=80=99d call this another =E2=80=9Cunfortunate design=E2=80=9D,=
 but the context was about re-using an externally-defined query language th=
at was not made for GNAP.

My scenario was for someone wh=
o is already using =E2=80=9Cclaims=E2=80=9D and wants to keep using it. (Th=
e vast majority of OIDC implementations, in my experience, don=E2=80=99t us=
e that feature, and it=E2=80=99s not even required to be implemented by the=
 AS, but again we=E2=80=99re talking about using this feature as an example=
 of an external query language =E2=80=94 and there are others out there.) I=
n GNAP, you should return claims directly in the response, and request spec=
ific elements from the APIs protected by the access token. These are separa=
te things, and by design both XAuth and XYZ have put them into separate con=
tainers in the request. This is a good design, and so putting something tha=
t conflates these two aspects into one or the other of the containers is no=
t a particularly good option, in my opinion.=C2=A0

Additionally, though this is a bit of an aside and getting into the specif=
ics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is a query =
language bound to the full user profile. It is my stated position that the =
items coming back from the AS should only be identifiers, and not full prof=
ile information. The reasoning is pretty simple: the client doesn=E2=80=99t=
 know what profile information it needs until it knows who the user is, so =
putting that into a protected API like the UserInfo Endpoint makes much mor=
e sense than putting it into the immediate response, where it is not needed=
, because the client already knows it. The AS doesn=E2=80=99t know what the=
 client needs to know, either, so it can=E2=80=99t determine what to fulfil=
l. OIDC=E2=80=99s two-stage model makes sense, and GNAP should really only =
focus on enabling this.

=C2=A0=E2=80=94 Justin

On Jul 8, 2020, at 6:10 PM, =
Dick Hardt <di=
ck.hardt@gmail.com> wrote:



On Wed, Jul 8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at 3:16 =
PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I think representing the request as=
 an array is simplistic, and complicated at the same time.

On the simplistic front, as there is no clear mechanism for extending th=
e request with properties that apply to all of the request.=C2=A0

The elements of the array ar=
e taken as a set, to be tied to the same resulting access token. If one of =
those elements is defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s p=
rotecting, to apply across some or all of the other elements, then that=E2=
=80=99s up to the AS=E2=80=99s policy. Much like the =E2=80=9Copenid=E2=80=
=9D scope in OIDC, which switches on all sorts of contextual stuff in the r=
equest. So to handle something like this, an AS can easily declare that a g=
iven scope-style string or a given object property applies to different par=
ts of the request. You don=E2=80=99t need to externalize it here.

I view the "openid" scop=
e as an unfortunate design as OIDC was constrained by building=C2=A0on top =
of OAuth. (a problem I hoped to avert by having "identity" in sco=
pe for GNAP) The "openid" scope does not function as scope=C2=A0p=
er se, and I think it makes OIDC harder to understand as the "openid&q=
uot; scope causes non-scope behavior.=C2=A0

=C2=A0=


=

Do you have a concrete use case that requires that feature to be=
 done in the way that you describe? I am trying to separate the driving use=
 case from the proposed solutions to see what the differences are.=C2=A0

Perhaps the client wants ac=
cess to be HIPPA compliant? The HIPPA compliance signal applies to the scop=
es.

Adding other properties to an object is a well=
 understood extension mechanism. Adding an additional element to an array t=
hat does not act like the other elements seems like a hack.

<=
/div>
=C2=A0


Using JSON type polymorphism=C2=A0requires =
the AS to test each member of the array to determine if it is a string or a=
n object. Only after detecting a RAR object does the AS know the client is =
making a RAR request.=C2=A0

That=E2=80=99s correct =E2=80=94 but the AS needs to =
parse the whole resources request in order to figure out what the client is=
 asking for, anyway, whether it=E2=80=99s by strings or objects or whatever=
 else might be defined by an extension. Is there an argument for having an =
AS do an early dispatch on a request before it=E2=80=99s fully parsed every=
thing?

Let me clarify, th=
e code is looking at the type of object that has been parsed.=C2=A0

Determining if an item in an array is a scope or a RAR ob=
ject by looking at the type being either a string or an object seems less c=
lear than a property of an object explicitly declaring the type.
=

=C2=A0

This also limits the request to be composed only of scope st=
rings or RAR objects. I don't see how other strings or objects could be=
 used in the array, so there is no clear extension point in the "resou=
rces" array for other query mechanisms.

That=E2=80=99s not the case in XYZ since we aren=
=E2=80=99t declaring that a string has to be an OAuth2-style scope. It can =
be, but ultimately it=E2=80=99s just a string that the AS can understand. A=
nd the objects are just that =E2=80=94 objects. If the AS understands what =
the object is, it can be a RAR object or it can be something completely API=
-specific with another query language entirely.

But the other query language would need a type that =
has been reserved in the RAR name space for there to be interop, so it effe=
ctively is a RAR extension.

There are query langua=
ges in other domains that may not fit nicely into RAR such as a query for m=
edical records.

Yes, the medical records could be =
yet another top level property, but per below, I think that is confusing.
=C2=A0
(Point, though: RAR already pretty much allows this by letting t=
hem be extended infinitely, a feature it inherits from XYZ)

<=
/div>
I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=
=80=99s an array of strings or objects and each of those means the same thi=
ng, =E2=80=9Csomething the client is asking for=E2=80=9D.


Just as RAR has a "type" property, I propose the "resource=
s" ("authorizations" in XAuth) be an object, where the other=
 properties are determined by the "type" property. This allows ex=
tensions to define new ways to query for an authorization rather than havin=
g to fit into scopes or RAR.


It=E2=80=99s my stance that this is an unnecessary=
 limitation at this level. The objects within the array should be typed, li=
ke RAR, but it doesn=E2=80=99t make sense for the overall request to be typ=
ed. Instead, there should be one =E2=80=9Ctype" of query in the core, =
what XYZ calls the =E2=80=9Cresources=E2=80=9D request. Other query languag=
es should be added as extensions either to the RAR-style objects (by defini=
ng a type at that level) or as a separate top-level member.

<=
/div>
For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D=
 query language. My current thought is that this really shouldn=E2=80=99t b=
e a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D par=
t of the request, but instead as its own top-level member, like it is in th=
e OIDC protocol today. The main reason for this is the nature of the OIDC c=
laims language: it specifies targets for the resulting data, and those targ=
ets cross different ways to return things. So it doesn=E2=80=99t actually a=
ffect just resources like the UserInfo Endpoint, or the ID Token, but both =
and potentially others out there. If your system supported such an extensio=
n, it could theoretically forego both the built-in =E2=80=9Cclaims=E2=80=9D=
 and =E2=80=9Cresources=E2=80=9D parts of the request, and use the =E2=80=
=9Coidc_claims_query=E2=80=9D member (or whatever it would be called). This=
 would let such an extension use the OIDC claims processing mechanism as it=
 is today.

To me, this remains much more understan=
dable, extensible, and clean.

=

While this may be more understandable to a developer just=C2=A0porting=
 an app OIDC that only wants OIDC results, but I think it is more complicat=
ed as soon as the developer wants other results, which is likely what=C2=A0=
prompted the developer to use GNAP instead of ODIC.

I think it is easier to understand if all the claims are in one container=
, and all the authorizations are in another container.

=

If a developer wants access to some resources, some claims, and an Ope=
nID Token, they are having to use "claims", "resources"=
, and "oidc_claims_query".=C2=A0 Now the claims and access tokens=
 are spread across multiple containers. There are some claims in the "=
claims" container, and some "claims" in the "oidc_claim=
s_query" container. And is the access token response in=C2=A0"oid=
c_claims_query" the same as an access token response in "resource=
s"? It would seem simpler if they were, and if all the access tokens c=
ame back in the same container.

Per Aaron's po=
st that you have referred to, the developer can get sme bare claims directl=
y in the response in the "claims" object, an ID Token that has th=
e same or different claims, and if they want, an access token that they can=
 call a user_info endpoint to get the same, or different claims.
=

For example, an enterprise app client may want an ID Token w=
ith the email address, bare claims for the user's name and a URI to a p=
rofile photo, and an access token to query which groups a user belongs to.<=
/div>

We are still re-using=C2=A0the OIDC claims, but we=
 are not mixing claims and authorizations.

3D""=E1=90=A7

3D""=E1=90=A7



--00000000000078c52b05a9f82f9e--


From nobody Wed Jul  8 22:40:44 2020
Return-Path: 
X-Original-To: txauth@ietf.org
Delivered-To: txauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C16D3A0F85; Wed,  8 Jul 2020 22:40:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker 
To: "The IESG" 
Cc: gnap-chairs@ietf.org, txauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.7.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk 
Message-ID: <159427323913.26471.10476959392252244212@ietfa.amsl.com>
Date: Wed, 08 Jul 2020 22:40:39 -0700
Archived-At: 
Subject: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-08: (with COMMENT)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jul 2020 05:40:39 -0000

Benjamin Kaduk has entered the following ballot position for
charter-ietf-gnap-00-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-gnap/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There's a spurious line break in the list of extension points (unless the last
item is just a stale editing artifact?)

CoAP is usually spelled with a minuscule 'o' and majuscule 'C', 'A', and 'P'.




From nobody Thu Jul  9 03:20: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 7E5C13A080B for ; Thu,  9 Jul 2020 03:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.103
X-Spam-Level: 
X-Spam-Status: No, score=0.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.999] 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 0xRn3VBp9qqy for ; Thu,  9 Jul 2020 03:20:06 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8253A080A for ; Thu,  9 Jul 2020 03:20:05 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d73 with ME id 0yL1230064FMSmm03yL1jh; Thu, 09 Jul 2020 12:20:04 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 09 Jul 2020 12:20:04 +0200
X-ME-IP: 86.238.65.197
To: "txauth@ietf.org" 
From: Denis 
Message-ID: 
Date: Thu, 9 Jul 2020 12:19: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="------------CBAB75F9DC3790534A44EA27"
Content-Language: en-GB
Archived-At: 
Subject: [Txauth] A model with a User Consent Element
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, 09 Jul 2020 10:20:09 -0000

This is a multi-part message in MIME format.
--------------CBAB75F9DC3790534A44EA27
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

This is a new thread.

Preamble: This model is quite different from the XAuth model.
In particular, a RO has no relationship with any AS and a Client does 
not need to be associated with any AS prior to any access to a RS.

A key point of this model is that the user's consent is handled locally 
by the Client and hence no AS nor RS is handling a man machine interface
for the user consent. This allows to support locally the user consent 
for multiple ASs while keeping all ASs ignorant about the choices of the 
user
made for accessing a particular RS.
*

**+--------++------------+
|User||Resource|
||| Owner (RO) |
+--------++------------+
|\|
|\|
|\|
|\|
+-----------++---------------++------------+
||---->| Authorization |||
|| (2) |Server (AS)|||
||<----||||
|Client|+---------------+||
||-------------------------->|Resource|
|User|(1)|Server|
|Consent|<--------------------------|(RS)|
|element|||
||-------------------------->||------>
||(3)||(4)
||<--------------------------||<------
+-----------++------------+
*
The flow of operations is as follows:

The Client (which may have been previously authenticated using FIDO) 
contacts the RS and after some dialogue with the RS selects an operation
that it wants to perform on the RS (1a). Note that it may also indicate 
directly the operation that it wants to perform on the RS without any 
prior dialogue.
In return (1b), the RS informs the Client about which attributes are 
needed by the RS for performing the requested operation and from which 
Attributes Servers
they may be obtained.

This information is specifically marked to indicate that it shall be 
handled by the "User Consent element" from the Client.
The presentation of that information is up to the man machine interface 
supported by the "User Consent element" from the Client.

The user can see which attributes are requested by the RS for performing 
the requested operation and, if it consents, the Client contacts one or 
more
appropriate Authorization Servers (2a). The user consent is hence 
captured locally by the Client (i.e. there is no dialogue with any AS 
nor any RS).

When the Client got the access tokens from these authorization servers 
(2b), it sends all of them in a single request to the RS (3a).

End of the story for a simple access


Start of a subsequent story for a delegation case

Let us now suppose that the RS is unable to fulfil the request by its 
own and that it needs to contact another RS. RS1 contacts RS2 (4a) and 
indicates the operation
that it wants to perform on RS2 (that operation may not be the same as 
the original operation). In return (4b), RS2 informs RS1 about which 
attributes are needed
by RS2 for performing the requested operation and from which Attributes 
Servers they may be obtained. RS1 forwards that information to the Client.

This information is marked to indicate that it shall be handled by the 
"User Consent element" from the Client. The presentation of that 
information is up to the man machine
interface from the Client. The user can see which attributes are 
requested by RS2 for performing the new requested operation and, if it 
consents, the Client contacts one or more
appropriate Authorization Servers. The user consent is hence captured 
locally by the "User Consent element" from the Client. (i.e. there is no 
dialogue with any AS, nor RS1, nor RS2).

When the Client got the access token(s) from the authorization 
server(s), it sends all of them in a single request to RS1. RS1 then 
forwards the additional access token(s) to RS2.


Some observations:

The user nor the Client are linked with any particular AS. A user may 
use today an AS of the Bank of America and may change tomorrow to the 
Bank of Missouri.
As soon as he will be registered with the Bank of Missouri, he will be 
able to get access tokens from the AS of the Bank of Missouri. The AS of 
Bank of America
has not been able to know where its access tokens have been used. This 
will be the same for AS of the Bank of Missouri. There is no need for 
any direct dialogue
between any AS and any RS at the time a client is making an access. 
There is no need for any RO to contact any AS.

This model has been constructed following a "Privacy by Design" approach.

Denis


--------------CBAB75F9DC3790534A44EA27
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
This is a new thread.

        

        Preamble: This model is quite different from the XAuth model. 

        In particular, a RO has no relationship with any AS and a Client
        does not need
        to be associated with any AS prior to any access to a RS.

        

        A key point of this model is that the user's consent is handled
        locally by the
        Client and hence no AS nor RS is handling a man machine
        interface 

        for the user
        consent. This allows to support locally the user consent for
        multiple ASs while keeping
        all ASs ignorant about the choices of the user 

        made for accessing a
        particular RS.

        

          

               +--------+                           +------------+

                 |  User  |                           |  Resource 
          |

                 |        |                          
          | Owner (RO) |

                 +--------+                           +------------+

                     |      \                              |

                     |       \                             |

                     |        \                            |

                     |         \                           |

              +-----------+     +---------------+    
          +------------+

              |           |---->| Authorization |     |           
          |

              |           | (2) |  Server
          (AS)  |     |           
          |

              |           |<----|              
          |     |            |

              | 
          Client   |     +---------------+     |            |

              |           |-------------------------->|  Resource 
          |

              |  
          User    |           (1)             |  
          Server   |

              | 
          Consent 
          |<--------------------------|   
          (RS)    |

              | 
          element  |                           |            |

              |           |-------------------------->|            |------>

              |           |          
          (3)             |            | 
          (4)

              |           |<--------------------------|            |<------

              +-----------+                           +------------+

        

        The flow of operations is as follows:

        

        The Client (which may have been previously authenticated using
        FIDO) contacts
        the RS and after some dialogue with the RS selects an operation
        

        that it wants
        to perform on the RS (1a). Note that it may also indicate
        directly the
        operation that it wants to perform on the RS without any prior
        dialogue. 

        In
        return (1b), the RS informs the Client about which attributes
        are needed by the
        RS for performing the requested operation and from which
        Attributes Servers
        

        they may be obtained. 

        

        This information is specifically marked to indicate that it
        shall be handled by
        the "User Consent element" from the Client. 

        The presentation of that
        information is up to the man machine interface supported by the
        "User
        Consent element" from the Client. 

        

        The user can see which attributes are requested by the RS for
        performing the
        requested operation and, if it consents, the Client contacts one
        or more
        

        appropriate Authorization Servers (2a). The user consent is
        hence captured
        locally by the Client (i.e. there is no dialogue with any AS nor
        any RS).

        

        When the Client got the access tokens from these authorization
        servers (2b), it
        sends all of them in a single request to the RS (3a).

        

        End of the story for a simple access

    

        

        Start of a subsequent story for a delegation case

        

        Let us now suppose that the RS is unable to fulfil the request
        by its own and
        that it needs to contact another RS. RS1 contacts RS2 (4a) and indicates the
        operation 

        that it wants to perform on RS2 (that operation may not be the
        same
        as the original operation). In return (4b), RS2 informs RS1
        about which
        attributes are needed 

        by RS2 for performing the requested operation and from
        which Attributes Servers they may be obtained. RS1 forwards that
        information to
        the Client. 

        

        This information is marked to indicate that it shall be handled
        by
        the "User Consent element" from the Client. The presentation of
        that
        information is up to the man machine 

        interface from the Client. The user can
        see which attributes are requested by RS2 for performing the new
        requested
        operation and, if it consents, the Client contacts one or more 

        appropriate
        Authorization Servers. The user consent is hence captured
        locally by the
        "User Consent element" from the Client. (i.e. there is no
        dialogue
        with any AS, nor RS1, nor RS2). 

        

        When the Client got the access token(s) from the authorization
        server(s), it
        sends all of them in a single request to RS1. RS1 then forwards
        the additional access token(s) to RS2.

        

        

        Some observations: 

        

        The user nor the Client are linked with any particular AS. A
        user may use today an AS of the
        Bank of America and may change tomorrow to the Bank of Missouri.
        

        As soon as he
        will be registered with the Bank of Missouri, he will be able to
        get access
        tokens from the AS of the Bank of Missouri. The AS of Bank of
        America 

        has not
        been able to know where its access tokens have been used. This
        will be the same
        for AS of the Bank of Missouri. There is no need for any direct
        dialogue
        

        between any AS and any RS at the time a client is making an
        access. There is no
        need for any RO to contact any AS.

    
This model has been constructed following a
        "Privacy by Design" approach.

    
Denis

      

  


--------------CBAB75F9DC3790534A44EA27--


From nobody Thu Jul  9 03:26: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 35A0E3A080E for ; Thu,  9 Jul 2020 03:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 evJQZUJwpxD0 for ; Thu,  9 Jul 2020 03:26:06 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBAD3A0815 for ; Thu,  9 Jul 2020 03:26:05 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d73 with ME id 0yS22300T4FMSmm03yS3F9; Thu, 09 Jul 2020 12:26:04 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 09 Jul 2020 12:26:04 +0200
X-ME-IP: 86.238.65.197
From: Denis 
To: "txauth@ietf.org" 
References: 
Message-ID: 
Date: Thu, 9 Jul 2020 12:26: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="------------750D5F8691A5570FC26F1149"
Content-Language: fr
Archived-At: 
Subject: [Txauth] A model with a User Consent Element (with a clean figure)
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, 09 Jul 2020 10:26:08 -0000

This is a multi-part message in MIME format.
--------------750D5F8691A5570FC26F1149
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

This is a new thread.

Preamble: This model is quite different from the XAuth model.
In particular, a RO has no relationship with any AS and a Client does 
not need to be associated with any AS prior to any access to a RS.

A key point of this model is that the user's consent is handled locally 
by the Client and hence no AS nor RS is handling a man machine interface
for the user consent. This allows to support locally the user consent 
for multiple ASs while keeping all ASs ignorant about the choices of the 
user
made for accessing a particular RS.
*

**+--------++------------+
|User||Resource|
||| Owner (RO) |
+--------++------------+
|\|
|\|
|\|
|\|
+-----------++---------------++------------+
||---->| Authorization |||
|| (2) |Server (AS)|||
||<----||||
|Client|+---------------+||
||-------------------------->|Resource|
|User|(1)|Server|
|Consent|<--------------------------|(RS)|
|element|||
||-------------------------->||------>
||(3)||(4)
||<--------------------------||<------
+-----------++------------+
*
The flow of operations is as follows:

The Client (which may have been previously authenticated using FIDO) 
contacts the RS and after some dialogue with the RS selects an operation
that it wants to perform on the RS (1a). Note that it may also indicate 
directly the operation that it wants to perform on the RS without any 
prior dialogue.
In return (1b), the RS informs the Client about which attributes are 
needed by the RS for performing the requested operation and from which 
Attributes Servers
they may be obtained.

This information is specifically marked to indicate that it shall be 
handled by the "User Consent element" from the Client.
The presentation of that information is up to the man machine interface 
supported by the "User Consent element" from the Client.

The user can see which attributes are requested by the RS for performing 
the requested operation and, if it consents, the Client contacts one or 
more
appropriate Authorization Servers (2a). The user consent is hence 
captured locally by the Client (i.e. there is no dialogue with any AS 
nor any RS).

When the Client got the access tokens from these authorization servers 
(2b), it sends all of them in a single request to the RS (3a).

End of the story for a simple access


Start of a subsequent story for a delegation case

Let us now suppose that the RS is unable to fulfil the request by its 
own and that it needs to contact another RS. RS1 contacts RS2 (4a) and 
indicates the operation
that it wants to perform on RS2 (that operation may not be the same as 
the original operation). In return (4b), RS2 informs RS1 about which 
attributes are needed
by RS2 for performing the requested operation and from which Attributes 
Servers they may be obtained. RS1 forwards that information to the Client.

This information is marked to indicate that it shall be handled by the 
"User Consent element" from the Client. The presentation of that 
information is up to the man machine
interface from the Client. The user can see which attributes are 
requested by RS2 for performing the new requested operation and, if it 
consents, the Client contacts one or more
appropriate Authorization Servers. The user consent is hence captured 
locally by the "User Consent element" from the Client. (i.e. there is no 
dialogue with any AS, nor RS1, nor RS2).

When the Client got the access token(s) from the authorization 
server(s), it sends all of them in a single request to RS1. RS1 then 
forwards the additional access token(s) to RS2.


Some observations:

The user nor the Client are linked with any particular AS. A user may 
use today an AS of the Bank of America and may change tomorrow to the 
Bank of Missouri.
As soon as he will be registered with the Bank of Missouri, he will be 
able to get access tokens from the AS of the Bank of Missouri. The AS of 
Bank of America
has not been able to know where its access tokens have been used. This 
will be the same for AS of the Bank of Missouri. There is no need for 
any direct dialogue
between any AS and any RS at the time a client is making an access. 
There is no need for any RO to contact any AS.

This model has been constructed following a "Privacy by Design" approach.

Denis


--------------750D5F8691A5570FC26F1149
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

      
This is a new thread.

          

          Preamble: This model is quite different from the XAuth model.
          

          In particular, a RO has no relationship with any AS and a
          Client does not need to be associated with any AS prior to any
          access to a RS.

          

          A key point of this model is that the user's consent is
          handled locally by the Client and hence no AS nor RS is
          handling a man machine interface 

          for the user consent. This allows to support locally the user
          consent for multiple ASs while keeping all ASs ignorant about
          the choices of the user 

          made for accessing a particular RS.

          

            

                   +--------+                           +------------+

                     |  User  |                           |  Resource  |

                     |        |                           |
              Owner (RO) |

                     +--------+                           +------------+

                         |      \                             
              |

                         |       \                             |

                         |        \                            |

                         |         \                           |

                  +-----------+     +---------------+     +------------+

                  |           |---->|
              Authorization |     |            |

                  |           | (2) |  Server (AS)  |     |            |

                  |           |<----|               |     |            |

                  |  Client   |     +---------------+     |            |

                  |           |-------------------------->|  Resource  |

                  |   User    |           (1)             |   Server   |

                  |  Consent  |<--------------------------|    (RS)    |

                  |  element  |                           |            |

                  |           |-------------------------->|            |------>

                  |           |           (3)             |            |  (4)

                  |           |<--------------------------|            |<------

                  +-----------+                           +------------+

          

          The flow of operations is as follows:

          

          The Client (which may have been previously authenticated using
          FIDO) contacts the RS and after some dialogue with the RS
          selects an operation 

          that it wants to perform on the RS (1a). Note that it may also
          indicate directly the operation that it wants to perform on
          the RS without any prior dialogue. 

          In return (1b), the RS informs the Client about which
          attributes are needed by the RS for performing the requested
          operation and from which Attributes Servers 

          they may be obtained. 

          

          This information is specifically marked to indicate that it
          shall be handled by the "User Consent element" from the
          Client. 

          The presentation of that information is up to the man machine
          interface supported by the "User Consent element" from the
          Client. 

          

          The user can see which attributes are requested by the RS for
          performing the requested operation and, if it consents, the
          Client contacts one or more 

          appropriate Authorization Servers (2a). The user consent is
          hence captured locally by the Client (i.e. there is no
          dialogue with any AS nor any RS).

          

          When the Client got the access tokens from these authorization
          servers (2b), it sends all of them in a single request to the
          RS (3a).

          

          End of the story for a simple access

      
 

          Start of a subsequent story for a delegation case

          

          Let us now suppose that the RS is unable to fulfil the request
          by its own and that it needs to contact another RS. RS1
          contacts RS2 (4a) and indicates the operation 

          that it wants to perform on RS2 (that operation may not be the
          same as the original operation). In return (4b), RS2 informs
          RS1 about which attributes are needed 

          by RS2 for performing the requested operation and from which
          Attributes Servers they may be obtained. RS1 forwards that
          information to the Client. 

          

          This information is marked to indicate that it shall be
          handled by the "User Consent element" from the Client. The
          presentation of that information is up to the man machine 

          interface from the Client. The user can see which attributes
          are requested by RS2 for performing the new requested
          operation and, if it consents, the Client contacts one or more
          

          appropriate Authorization Servers. The user consent is hence
          captured locally by the "User Consent element" from the
          Client. (i.e. there is no dialogue with any AS, nor RS1, nor
          RS2). 

          

          When the Client got the access token(s) from the authorization
          server(s), it sends all of them in a single request to RS1.
          RS1 then forwards the additional access token(s) to RS2.

          

          

          Some observations: 

          

          The user nor the Client are linked with any particular AS. A
          user may use today an AS of the Bank of America and may change
          tomorrow to the Bank of Missouri. 

          As soon as he will be registered with the Bank of Missouri, he
          will be able to get access tokens from the AS of the Bank of
          Missouri. The AS of Bank of America 

          has not been able to know where its access tokens have been
          used. This will be the same for AS of the Bank of Missouri.
          There is no need for any direct dialogue 

          between any AS and any RS at the time a client is making an
          access. There is no need for any RO to contact any AS.

      
This model has been constructed following a
          "Privacy by Design" approach.

      Denis

    

  


--------------750D5F8691A5570FC26F1149--


From nobody Thu Jul  9 04:49: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 E85203A08C1; Thu,  9 Jul 2020 04:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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=cert.org
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 bxVsjVAxN4gS; Thu,  9 Jul 2020 04:49:03 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 68FB43A08C7; Thu,  9 Jul 2020 04:49:03 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 069Bn1kA011962; Thu, 9 Jul 2020 07:49:02 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 069Bn1kA011962
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1594295342; bh=14ogEkPItcs3USBl7y+s8lHALKEw2qCM/JckDl9I1vw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=cfWEo9CyB5CD8fIHKv0rXliiU2ZKa1OivvOdBlH3BDpghmHvK3q0/SQf+1H67OsS8 xWKUYrOdQK5p/5tXl0uzGR/YlNmLaVo9tdJ7komvrwPvCn1oJImYtOqnKeyTwlJyry LAbAunoGbrJhcR7lMvfnCse+aUtQYypMYZJANbuw=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 069Bmv8c009283; Thu, 9 Jul 2020 07:48:57 -0400
Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 9 Jul 2020 07:48:56 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 9 Jul 2020 07:48:56 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Thu, 9 Jul 2020 07:48:56 -0400
From: Roman Danyliw 
To: Benjamin Kaduk , The IESG 
CC: "gnap-chairs@ietf.org" , "txauth@ietf.org" 
Thread-Topic: Benjamin Kaduk's No Objection on charter-ietf-gnap-00-08: (with COMMENT)
Thread-Index: AQHWVbOAxrB/V9lBCkKbaWWlHVMhW6j/IPtA
Date: Thu, 9 Jul 2020 11:48:54 +0000
Message-ID: <73edaa0911144aac9e8a7b6445702058@cert.org>
References: <159427323913.26471.10476959392252244212@ietfa.amsl.com>
In-Reply-To: <159427323913.26471.10476959392252244212@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.64.202.182]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-08: (with COMMENT)
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, 09 Jul 2020 11:49:05 -0000

SGkgQmVuIQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGllc2cgPGll
c2ctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJlbmphbWluIEthZHVrIHZpYQ0KPiBE
YXRhdHJhY2tlcg0KPiBTZW50OiBUaHVyc2RheSwgSnVseSA5LCAyMDIwIDE6NDEgQU0NCj4gVG86
IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZ25hcC1jaGFpcnNAaWV0Zi5vcmc7IHR4
YXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBCZW5qYW1pbiBLYWR1aydzIE5vIE9iamVjdGlvbiBv
biBjaGFydGVyLWlldGYtZ25hcC0wMC0wODogKHdpdGgNCj4gQ09NTUVOVCkNCj4gDQo+IEJlbmph
bWluIEthZHVrIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0K
PiBjaGFydGVyLWlldGYtZ25hcC0wMC0wODogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3Bv
bmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBh
bGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChG
ZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4p
DQo+IA0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9z
aXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvY2hhcnRlci1pZXRmLWduYXAvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g
Q09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGhlcmUncyBhIHNwdXJpb3VzIGxpbmUg
YnJlYWsgaW4gdGhlIGxpc3Qgb2YgZXh0ZW5zaW9uIHBvaW50cyAodW5sZXNzIHRoZSBsYXN0IGl0
ZW0NCj4gaXMganVzdCBhIHN0YWxlIGVkaXRpbmcgYXJ0aWZhY3Q/KQ0KPiANCj4gQ29BUCBpcyB1
c3VhbGx5IHNwZWxsZWQgd2l0aCBhIG1pbnVzY3VsZSAnbycgYW5kIG1hanVzY3VsZSAnQycsICdB
JywgYW5kICdQJy4NCg0KQm90aCBmaXhlZCBpbiAtMDAtMDkuICBUaGFua3MhDQoNClJvbWFuDQoN
Cj4gDQoNCg==


From nobody Thu Jul  9 04:57: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 C014B3A08D7 for ; Thu,  9 Jul 2020 04:57:46 -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=[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_DNSWL_BLOCKED=0.001, SPF_NONE=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=danielfett.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 qjNvWMrvb1Zp for ; Thu,  9 Jul 2020 04:57:45 -0700 (PDT)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3013A08D6 for ; Thu,  9 Jul 2020 04:57:44 -0700 (PDT)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id F0727A105 for ; Thu,  9 Jul 2020 11:57:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1594295862; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LZoM8AgSGMk3KW36CTBviyCoLL/co7twtum7vgl/Q1g=; b=uLmaKyaaUqkAOv5r4RCDtJuVTJGXNTw0EkoMzveSvQHr/4ryToXS4ZoT9RiaLkrjwJHfYi 5RJIdFtRh694OZACvQiA0BygjVyV5lJzgkwHXbcrmdfd5bHFVmM+b3uwtO3mNr0E7Hx+Iy lT3tUOH3dwI4lqkKkBX1GRsZ2HIbMmU=
To: txauth@ietf.org
References:  
From: Daniel Fett 
Message-ID: <205c8bb2-516c-64a1-fe2a-8a2eac282dc3@danielfett.de>
Date: Thu, 9 Jul 2020 13:57:41 +0200
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F64A8FD6339FD8747B80D3DD"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de;  s=dkim; t=1594295862; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LZoM8AgSGMk3KW36CTBviyCoLL/co7twtum7vgl/Q1g=; b=RKPFcK0ni9s6Qspk+a+RMHvP633Ac8fK8HzrkDg+fqcyQfs+WEkhC65YERqaeOjGaYqdEC fsEOA9+3IFHLlfb4QdOMnCk6+MXju9Rqs1JnOFoysOyNOThZMS+AkLXqxY/yfH2/5cxzwk TUfZDUsF1SfHIcBCb72aR8TNEg+2yQw=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1594295862; a=rsa-sha256; cv=none; b=SZ2bZc5rrA14YE7C66hry8tgbI4yzxaQhmgaWzjlgVksbxjEeUsZgk0VDVseiOlKp99IuG aX1mUm+BBlRDttpsx2eWyC8g9sm1RdEtuapThLV3nSyY6hvJMFMqvoqa0IWX7duyFhnuPm rxbxGYXLWHR8HT2kO2LiTSKab9EJ/Hg=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 09 Jul 2020 11:57:47 -0000

This is a multi-part message in MIME format.
--------------F64A8FD6339FD8747B80D3DD
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Am 09.07.20 um 12:26 schrieb Denis:
>
> The user can see which attributes are requested by the RS for
> performing the requested operation and, if it consents, the Client
> contacts one or more
> appropriate Authorization Servers (2a). The user consent is hence
> captured locally by the Client (i.e. there is no dialogue with any AS
> nor any RS).
>
What prevents a non-compliant client from retrieving data about (or
access tokens for) arbitrary users from arbitrary authorization servers?

-Daniel


-- 
https://danielfett.de


--------------F64A8FD6339FD8747B80D3DD
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Am 09.07.20 um 12:26 schrieb Denis:

    

    

      
      

        
The user can see which attributes are requested
            by the RS for performing the requested operation and, if it
            consents, the Client contacts one or more 

            appropriate Authorization Servers (2a). The user consent is
            hence captured locally by the Client (i.e. there is no
            dialogue with any AS nor any RS).

          

      

    

    
What prevents a non-compliant client from retrieving data about
      (or access tokens for) arbitrary users from arbitrary
      authorization servers?

    
-Daniel

    

    
-- 
https://danielfett.de

  


--------------F64A8FD6339FD8747B80D3DD--


From nobody Thu Jul  9 05:34: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 04A163A099B for ; Thu,  9 Jul 2020 05:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.62
X-Spam-Level: 
X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 Jmaip8OPkJr9 for ; Thu,  9 Jul 2020 05:34:16 -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 19B743A099A for ; Thu,  9 Jul 2020 05:34:15 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d62 with ME id 10aC2300R4FMSmm030aDZz; Thu, 09 Jul 2020 14:34:14 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 09 Jul 2020 14:34:14 +0200
X-ME-IP: 86.238.65.197
To: txauth@ietf.org
References:   <205c8bb2-516c-64a1-fe2a-8a2eac282dc3@danielfett.de>
From: Denis 
Message-ID: <0f907e0c-1938-0e3d-0126-38a945ce0b9c@free.fr>
Date: Thu, 9 Jul 2020 14:34: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: <205c8bb2-516c-64a1-fe2a-8a2eac282dc3@danielfett.de>
Content-Type: multipart/alternative; boundary="------------6EFA4888B634AD8142DB08FA"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 09 Jul 2020 12:34:18 -0000

This is a multi-part message in MIME format.
--------------6EFA4888B634AD8142DB08FA
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Daniel,

The response is pretty obvious. The user must have an account with the 
AS, e.g.  logging using FIDO.

Denis

> Am 09.07.20 um 12:26 schrieb Denis:
>>
>> The user can see which attributes are requested by the RS for 
>> performing the requested operation and, if it consents, the Client 
>> contacts one or more
>> appropriate Authorization Servers (2a). The user consent is hence 
>> captured locally by the Client (i.e. there is no dialogue with any AS 
>> nor any RS).
>>
> What prevents a non-compliant client from retrieving data about (or 
> access tokens for) arbitrary users from arbitrary authorization servers?
>
> -Daniel
>
>
> -- 
> https://danielfett.de
>


--------------6EFA4888B634AD8142DB08FA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Daniel,

    


    

    
The response is pretty obvious. The
      user must have an account with the AS, e.g.  logging using FIDO.

    


    

    
Denis

    

    

    

      
      
Am 09.07.20 um 12:26 schrieb Denis:

      

      

        
        

          
The user can see which attributes are
              requested by the RS for performing the requested operation
              and, if it consents, the Client contacts one or more 

              appropriate Authorization Servers (2a). The user consent
              is hence captured locally by the Client (i.e. there is no
              dialogue with any AS nor any RS).

            

        

      

      
What prevents a non-compliant client from retrieving data about
        (or access tokens for) arbitrary users from arbitrary
        authorization servers?

      
-Daniel

      

      
-- 
https://danielfett.de

      

      

    

    


    

  


--------------6EFA4888B634AD8142DB08FA--


From nobody Thu Jul  9 08:11: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 756F93A0C32 for ; Thu,  9 Jul 2020 08:11: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, 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 l1qxQ0CxrTLm for ; Thu,  9 Jul 2020 08:11:45 -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 5BE473A0C24 for ; Thu,  9 Jul 2020 08:11:45 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id y2so2689863ioy.3 for ; Thu, 09 Jul 2020 08:11:45 -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=MQKZChuKSzefmRmF8fnsNBfjCy2jmC5GOGDOMO0Ad7Y=; b=Zkkul1uANjkPFDwbYa3MGirU6d+keTJjP5SnFxTXOaPmsoDcORFPlEkLE5XHlh8JVD SGZyH99ZDHIrcvX1QEgLYux4JPCIr6lhm1Z7d5jMiOzc59Di4IBnCdm8zbNkR/wv3t/f f4HgP9hAhbYDkdvhAMGZBVxOry+SG0DAr5HnKft+tdsn5/VA58LlRsbQSIkAZk6z1WQn VKs2br/IvbMeAofOiTZGcqbiRMcl6tw3J9I1GjNu10OJstKLGsJxGkqnSBv0SABZf37V R5HYEPqSY6/f5eieOoN1NZuoqTkl69Wi9tG9XN/9jqnb0UkZgSPnVkCnwFwT1v2aGzlk a+Uw==
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=MQKZChuKSzefmRmF8fnsNBfjCy2jmC5GOGDOMO0Ad7Y=; b=kR01foe6DgJa7ncNchBeJIyi5DJ5Q2vjcPptk2A6uIM/rraG5v1CARqcznzSoDrbOv 50ZbCsfAvqGJB324OR/5K8j1Y6Pg24Xqm0bxPiQ3a5EjFTt+HonTss6/4i7q1T4txchd 0QmljCXW3pZsQN/tG9rqbjgsX924JhVaMkDKvH30JR02Oa6RKFmzoxu3/gVpcwR2yU0u fkAvwo3FaqamrY252ZFK3P9k1rhjdoxlEk/5VXQTjwiKSIFrqFeHsVm0yw+HGPkGKbsW s/c0BUb70TaTDfMuzC3evRHHNvqxgkzToP9mkZrFG4lJTH9nyb8wkUhgEjG1BrtmQ/pG cqmQ==
X-Gm-Message-State: AOAM5326jt9sB3T4Gs5pNX4k7PQRU135ecWCxvFjTFTr7KYrmhVCDtBj 0It6RkaENUjpYVm/QchizJPXBMhjri98enOuMTgka2aPIA0=
X-Google-Smtp-Source: ABdhPJxF6pYSHdpLog2aKDJTwc9Fw7iBPnsQc7o3Dk7PjMHWSTQfBbSexGqxyPbLq8aZIVMY2N2LrvPtJX85Fx84TeI=
X-Received: by 2002:a02:c948:: with SMTP id u8mr21178441jao.124.1594307503345;  Thu, 09 Jul 2020 08:11:43 -0700 (PDT)
MIME-Version: 1.0
From: Fabien Imbault 
Date: Thu, 9 Jul 2020 17:11:32 +0200
Message-ID: 
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006651b205aa03a4a0"
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 09 Jul 2020 15:11:48 -0000

--0000000000006651b205aa03a4a0
Content-Type: text/plain; charset="UTF-8"

Hi Denis,

I think it's interesting, but also very different to XYZ/XAuth so it raises
many questions ;-)
The figure is impossible to read.

So let me try to summarize the suggested approach, with a concrete example,
to make sure we understand well:

*0. The client authN to the AS (in whatever way is supported)*
Ex : client is a corporate financing called "finapp". finapp contacts AS0
for authentication (say an openbanking service).
User is John Doe, CFO at NeedMoney Inc. (+ other identity claims if needed,
maybe some verified credential from NeedMoney Holding that John is indeed
CFO).

*Dear John, *
*to access to your finapp, please identify yourself through your prefered
openbanking account.*
*Thanks*

*1. The client contacts a RS in a discovery phase, which includes the
selection of (at least) an operation, for which the RS returns the required
authZ attributes *
Ex : finapp needs to use NeedMoney's data to evaluate how much credit it
can offer.

Op1 : compute the credit rating, from RS1 (this is outsourced to an
external credit analyst), through the external service's own AS1.
But to do that, RS needs your historic bank statements.

Op2 : get your list of banks, RS2 (as registered within finapp),
through openbanking AS0

and retrieve the bank statements :
Op3a : get historic data from his main bank, RS2a (say an international
bank), through openbanking AS0
Op3b : same from a second bank account, RS2b (say a local bank), through
openbanking AS0

*2. User consent *
RS1 aggregates the list of attributes required (from all RS) and sends it
to finapp.

*Dear John, *
*To evaluate your credit request, we need the following information: *
*- your list of bank accounts (retrieved from your finapp account)*
*- the associated banking statements over the past 12 months (from each
bank)*
*- we'll pass that data to the credit agency, which will return your credit
score *
*Do you agree ?*

John approves (or not..., maybe he'll agree only for one specific bank),
via finapp directly (I like that, albeit in a more traditional flow, I'm
also separating the UI from the rest of the protocol of XYZ, and it works
too).

*3. Requests to the protected resources *
The client gets the access tokens and uses the services for which access
was granted.


*Analysis: (maybe I didn't get everything right, if so let me know) *
The trust model is focused around the relationship between the enduser
(John) and his application (finapp), which seems fine.

=> I see some potential issues :

a. it will be really difficult for an end user to understand what AS0 and
AS1 are, why they're different, and why he needs to authenticate to each of
them. How do you enable a federated experience? (especially as there could
be many)

b. deciding what is the main RS (here RS1) to be called by the client seems
very critical, as it is the one that needs to orchestrate everything. This
seems a very hierarchical and imperative model which seems somewhat counter
intuitive in terms of developer experience (as least as it is made today,
we clearly don't go into so much details). The call hierarchy may quickly
become very complex, which may also become a problem when separate services
evolve.

c. RS1 gets all the information required to access all sub-resources, and
therefore gets also a lot of responsibility (and power). But from finapp's
point of view, it is the one that has the relationship with the user and is
providing the core value proposition, while RS1 is just an external service.

d. multi-user (common B2B scenario): John wants to authorize a read access
to his finapp account to his external auditor, Ann (who is not a direct
user of finapp herself, but might already be registered by openbanking
AS0). How do you do that? Does it require the access token itself to be
able to delegate rights?

e. more generally, a threat model would be required, as there are many more
interactions now.

Cheers,
Fabien

--0000000000006651b205aa03a4a0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



--0000000000006651b205aa03a4a0--


From nobody Thu Jul  9 08:24: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 5F2A83A0C73 for ; Thu,  9 Jul 2020 08:24:54 -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 (2048-bit key) header.d=readycomputing.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 96PLBLjHhE_u for ; Thu,  9 Jul 2020 08:24:52 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 D65253A0C71 for ; Thu,  9 Jul 2020 08:24:51 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id u12so1911509qth.12 for ; Thu, 09 Jul 2020 08:24:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=readycomputing.com; s=google; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ByoWTf8aGkP0icOteOxudG1te6J9BHxucBqHtwJU3Ko=; b=R14Iwmpo9FjUhMNhLnJYUfPoBs6PcZjOUWiIdNaeYXW54M1S/oAouStpI3kebAb9rR ZiiYw3mdTLoJDqaDfoIMvHf+ubObvqb7c2WD/cOrRAWWbpFmAnviA3IA+bo6Fe6bQAPz 1TjLMIA71J5Su0u8xFM96EUwC+WtyIwxVcMRiDoNq+HdmEnxheMJZpJFwla+lG/2HC/D 2UJc/Pv17WsZ9RmuUvVYV5PlbSMihXNobsUlWmGn4sIzWCsbDeYeXuYPIcujO2jWNHYX 2zSAEmFVu8kCLklECDuCoAIA3I2qEEQGgMCB5ef+8Tur0d0KVuShiaoViMU/MnL0k9qi kyzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ByoWTf8aGkP0icOteOxudG1te6J9BHxucBqHtwJU3Ko=; b=XZTxIy8KoVR5Pb4OujzOFtgeVzKT5991RRaKDv79lt/wPYxILgEq2gj52r16E0T2Cz 1g77WgK24g3fZRqN/w1ea5TSqupnFaVxhnMrRhCcSlqtm3Xhs2tmDaoKGmgBXMgzZ73E GsSS1DcmE75W3GQoxZ3ut7dinT6AGCnxG6EGCPCcnoqBp5ealth6JD8hVeV6Mb84Jdw7 BqeSiLRQg86RUhzNSkas82Yz2sjgnK+v5QDhouQplEcHaTWuyCY8/As6MMO4m3IQqbha Ucwerp7M6QT6vekkg1ZTHukOF8ejEjA2/gxJ+LQ2B7ANxrc9QclznDw6pafZLemnFgqn IYpQ==
X-Gm-Message-State: AOAM533/9iSHWAJJSenjCfCu2jCDE0GBUNDIDwXOG+aeS0eR2TQ6ohrq wowTeVbJUNanP4paumT1uU5vnYam1mg/yyEQGJPwlj3c+4UqYsXfQn6gcg0Ty7fnWm6rKIBY/MS 7wJIAgJfxVD5Z5TeFMiFP0MOLOEN838l9hICm4ntSegcML7WQjJaDsqyc5P5OwLXnpOr+TrBX6g ==
X-Google-Smtp-Source: ABdhPJxT/ZfVlbOLpRQjQ8pR2Owic7oIS2BOiZ5nKUnODLksR5FhUOEi4NCjgx3gXHPmkge5fD0shQ==
X-Received: by 2002:ac8:3637:: with SMTP id m52mr67653156qtb.53.1594308290358;  Thu, 09 Jul 2020 08:24:50 -0700 (PDT)
Received: from ?IPv6:2607:fea8:aa20:59d:a52f:dc99:fcd2:aefd? ([2607:fea8:aa20:59d:a52f:dc99:fcd2:aefd]) by smtp.googlemail.com with ESMTPSA id y16sm4139736qkb.116.2020.07.09.08.24.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jul 2020 08:24:49 -0700 (PDT)
From: David Pyke 
X-Google-Original-From: David Pyke 
To: Denis , "txauth@ietf.org" 
References: 
Message-ID: 
Date: Thu, 9 Jul 2020 11:24:48 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------0B13F9D2A0FB4D655FC044C4"
Content-Language: en-CA
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element
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, 09 Jul 2020 15:24:54 -0000

This is a multi-part message in MIME format.
--------------0B13F9D2A0FB4D655FC044C4
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

This is frequently done in healthcare, with the User Consent Element=20
holding a URI to a fetchable document or OID that outlines consent=20
requirements or provisions.=C2=A0 If the URI points to a (I)ACP, it can be=
=20
computable (XACML or other) consent that can be ingested automagically.

On 2020-07-09 6:19 a.m., Denis wrote:
>
> This is a new thread.
>
> Preamble: This model is quite different from the XAuth model.
> In particular, a RO has no relationship with any AS and a Client does=20
> not need to be associated with any AS prior to any access to a RS.
>
> A key point of this model is that the user's consent is handled=20
> locally by the Client and hence no AS nor RS is handling a man machine=20
> interface
> for the user consent. This allows to support locally the user consent=20
> for multiple ASs while keeping all ASs ignorant about the choices of=20
> the user
> made for accessing a particular RS.
> *
>
> **+--------++------------+
> |User||Resource|
> ||| Owner (RO) |
> +--------++------------+
> |\|
> |\|
> |\|
> |\|
> +-----------++---------------++------------+
> ||---->| Authorization |||
> || (2) |Server (AS)|||
> ||<----||||
> |Client|+---------------+||
> ||-------------------------->|Resource|
> |User|(1)|Server|
> |Consent|<--------------------------|(RS)|
> |element|||
> ||-------------------------->||------>
> ||(3)||(4)
> ||<--------------------------||<------
> +-----------++------------+
> *
> The flow of operations is as follows:
>
> The Client (which may have been previously authenticated using FIDO)=20
> contacts the RS and after some dialogue with the RS selects an operation
> that it wants to perform on the RS (1a). Note that it may also=20
> indicate directly the operation that it wants to perform on the RS=20
> without any prior dialogue.
> In return (1b), the RS informs the Client about which attributes are=20
> needed by the RS for performing the requested operation and from which=20
> Attributes Servers
> they may be obtained.
>
> This information is specifically marked to indicate that it shall be=20
> handled by the "User Consent element" from the Client.
> The presentation of that information is up to the man machine=20
> interface supported by the "User Consent element" from the Client.
>
> The user can see which attributes are requested by the RS for=20
> performing the requested operation and, if it consents, the Client=20
> contacts one or more
> appropriate Authorization Servers (2a). The user consent is hence=20
> captured locally by the Client (i.e. there is no dialogue with any AS=20
> nor any RS).
>
> When the Client got the access tokens from these authorization servers=20
> (2b), it sends all of them in a single request to the RS (3a).
>
> End of the story for a simple access
>
>
> Start of a subsequent story for a delegation case
>
> Let us now suppose that the RS is unable to fulfil the request by its=20
> own and that it needs to contact another RS. RS1 contacts RS2 (4a) and=20
> indicates the operation
> that it wants to perform on RS2 (that operation may not be the same as=20
> the original operation). In return (4b), RS2 informs RS1 about which=20
> attributes are needed
> by RS2 for performing the requested operation and from which=20
> Attributes Servers they may be obtained. RS1 forwards that information=20
> to the Client.
>
> This information is marked to indicate that it shall be handled by the=20
> "User Consent element" from the Client. The presentation of that=20
> information is up to the man machine
> interface from the Client. The user can see which attributes are=20
> requested by RS2 for performing the new requested operation and, if it=20
> consents, the Client contacts one or more
> appropriate Authorization Servers. The user consent is hence captured=20
> locally by the "User Consent element" from the Client. (i.e. there is=20
> no dialogue with any AS, nor RS1, nor RS2).
>
> When the Client got the access token(s) from the authorization=20
> server(s), it sends all of them in a single request to RS1. RS1 then=20
> forwards the additional access token(s) to RS2.
>
>
> Some observations:
>
> The user nor the Client are linked with any particular AS. A user may=20
> use today an AS of the Bank of America and may change tomorrow to the=20
> Bank of Missouri.
> As soon as he will be registered with the Bank of Missouri, he will be=20
> able to get access tokens from the AS of the Bank of Missouri. The AS=20
> of Bank of America
> has not been able to know where its access tokens have been used. This=20
> will be the same for AS of the Bank of Missouri. There is no need for=20
> any direct dialogue
> between any AS and any RS at the time a client is making an access.=20
> There is no need for any RO to contact any AS.
>
> This model has been constructed following a "Privacy by Design" approach.
>
> Denis
>
>
--=20

*David Pyke*

Manager, Strategic Consulting

---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------

Logo 

LinkedIn icon  Twitter=20
icon  Youtbue icon=20


=09

Office: +1 212 877 3307 x5001

_david.pyke@readycomputing.com _

_www.readycomputing.com _

150 Beekman Street, Floor 3, New York, NY 10038


The information in this e-mail communication together with any=20
attachments is intended only for the person or entity to which it is=20
addressed and may contain confidential and/or privileged material. If=20
you are not the intended recipient of this communication, please notify=20
us immediately. Any views expressed in this communication are those of=20
the sender, unless otherwise specifically stated. Ready Computing does=20
not represent, warrant or guarantee that the integrity of this=20
communication has been maintained or the communication is free of=20
errors, virus or interference.


--=20
This is not a secure transmission. The information contained in this=20

transmission is highly prohibited from containing privileged and=20

confidential information, including patient information protected by=20

federal and state privacy laws. It is intended only for the use of the=20

person(s) named above. If you are not the intended recipient, you are=20

hereby notified that any review, dissemination, distribution, or=20

duplication of this communication is strictly prohibited. If you are not
=20
the intended recipient, please contact the sender by reply email and=20

destroy all copies of the original message.
                       =20

--------------0B13F9D2A0FB4D655FC044C4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
This is frequently done in healthcare, with the
        User Consent Element holding a URI to a fetchable document or
        OID that outlines consent requirements or provisions.=C2=A0 If the
        URI points to a (I)ACP, it can be computable (XACML or other)
        consent that can be ingested automagically.

    

    
On 2020-07-09 6:19 a.m., Denis wrote:
    

    

      
      
This is a new thread.

          

          Preamble: This model is quite different from the XAuth model.
          

          In particular, a RO has no relationship with any AS and a
          Client does not need to be associated with any AS prior to any
          access to a RS.

          

          A key point of this model is that the user's consent is
          handled locally by the Client and hence no AS nor RS is
          handling a man machine interface 

          for the user consent. This allows to support locally the user
          consent for multiple ASs while keeping all ASs ignorant about
          the choices of the user 

          made for accessing a particular 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=C2=A0 +------------+

            =C2=A0=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0 |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
            Owner (RO) |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 +--------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
+------------+

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=


            =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

            =C2=A0=C2=A0=C2=A0 +--=
---------+=C2=A0 =C2=A0=C2=A0=C2=A0+-------=
--------+=C2=A0=C2=A0=C2=A0=C2=A0 +=
------------+

            =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---->|
            Authorization |=C2=A0=C2=A0=
=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

            =C2=A0=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) |=C2=A0 Server (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=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0 |

            =C2=A0=C2=A0=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=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=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 (1)=C2=A0=C2=A0=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=C2=A0 |=C2=A0 Consent=C2=A0 |<--------------=
------------|=C2=A0=C2=A0=C2=A0 (RS)=C2=A0=C2=A0=C2=A0 |

            =C2=A0=C2=A0=C2=A0 |=C2=A0 element=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

            =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |-------------------------->|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |------>

            =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=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 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<--------------------------|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<------

            =C2=A0=C2=A0=C2=A0 +--=
---------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 flow of operations is as follows:

          

          The Client (which may have been previously authenticated using
          FIDO) contacts the RS and after some dialogue with the RS
          selects an operation 

          that it wants to perform on the RS (1a). Note that it may also
          indicate directly the operation that it wants to perform on
          the RS without any prior dialogue. 

          In return (1b), the RS informs the Client about which
          attributes are needed by the RS for performing the requested
          operation and from which Attributes Servers 

          they may be obtained. 

          

          This information is specifically marked to indicate that it
          shall be handled by the "User Consent element" from the
          Client. 

          The presentation of that information is up to the man machine
          interface supported by the "User Consent element" from the
          Client. 

          

          The user can see which attributes are requested by the RS for
          performing the requested operation and, if it consents, the
          Client contacts one or more 

          appropriate Authorization Servers (2a). The user consent is
          hence captured locally by the Client (i.e. there is no
          dialogue with any AS nor any RS).

          

          When the Client got the access tokens from these authorization
          servers (2b), it sends all of them in a single request to the
          RS (3a).

          

          End of the story for a simple access

      
 

          Start of a subsequent story for a delegation case

          

          Let us now suppose that the RS is unable to fulfil the request
          by its own and that it needs to contact another RS. RS1
          contacts RS2 (4a) and indicates the operation 

          that it wants to perform on RS2 (that operation may not be the
          same as the original operation). In return (4b), RS2 informs
          RS1 about which attributes are needed 

          by RS2 for performing the requested operation and from which
          Attributes Servers they may be obtained. RS1 forwards that
          information to the Client. 

          

          This information is marked to indicate that it shall be
          handled by the "User Consent element" from the Client. The
          presentation of that information is up to the man machine 

          interface from the Client. The user can see which attributes
          are requested by RS2 for performing the new requested
          operation and, if it consents, the Client contacts one or more
          

          appropriate Authorization Servers. The user consent is hence
          captured locally by the "User Consent element" from the
          Client. (i.e. there is no dialogue with any AS, nor RS1, nor
          RS2). 

          

          When the Client got the access token(s) from the authorization
          server(s), it sends all of them in a single request to RS1.
          RS1 then forwards the additional access token(s) to RS2.

          

          

          Some observations: 

          

          The user nor the Client are linked with any particular AS. A
          user may use today an AS of the Bank of America and may change
          tomorrow to the Bank of Missouri. 

          As soon as he will be registered with the Bank of Missouri, he
          will be able to get access tokens from the AS of the Bank of
          Missouri. The AS of Bank of America 

          has not been able to know where its access tokens have been
          used. This will be the same for AS of the Bank of Missouri.
          There is no need for any direct dialogue 

          between any AS and any RS at the time a client is making an
          access. There is no need for any RO to contact any AS.

      
This model has been constructed following a
          "Privacy by Design" approach.

      
Denis

        

      

      

    

    
-- 

      
      
      
      
      

        

          
            

              
                

                  David Pyke
              

            

            

              
                

                  Manager,
                    Strategic Consulting

              		
            

            

              
                
 ---------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
-------------------------------------------------------------------<=
/p>
              

            

            

              
                

                  3D"Logo"

                

                  3D"LinkedIn 3D"Twitter 3D"Youtbue

              		
              
                
Offi=
ce:
                    +1 212 877 3307 x5001

                

                  
                    

                      
                        

                          
                                david.pyke@readycomputing.com

                        

                          
                                www.readycomputing.com

                      		
                    

                    

                      
                        
150
                            Beekman Street, Floor 3, New York, NY 10038

                      		
                    

                    

                      

                      		
                    

                  
                

              		
            

            

              
                

                  The
                    information in this e-mail communication together
                    with any attachments is intended only for the person
                    or entity to which it is addressed and may contain
                    confidential and/or privileged material. If you are
                    not the intended recipient of this communication,
                    please notify us immediately. Any views expressed in
                    this communication are those of the sender, unless
                    otherwise specifically stated. Ready Computing does
                    not represent, warrant or guarantee that the
                    integrity of this communication has been maintained
                    or the communication is free of errors, virus or
                    interference.

              		
            

          
        

      

    

  




This is not a secure transmission. The information contained in this=20
transmission is highly prohibited from containing privileged and=20
confidential information, including patient information protected by=20
federal and state privacy laws. It is intended only for the use of the=20
person(s) named above. If you are not the intended recipient, you are=20
hereby notified that any review, dissemination, distribution, or=20
duplication of this communication is strictly prohibited. If you are not
 the intended recipient, please contact the sender by reply email and=20
destroy all copies of the original message.
                       
--------------0B13F9D2A0FB4D655FC044C4--


From nobody Thu Jul  9 08:39:32 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 CA0403A0C74 for ; Thu,  9 Jul 2020 08:39: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=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 1mUUAHAdrlTR for ; Thu,  9 Jul 2020 08:39: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 03B173A0A49 for ; Thu,  9 Jul 2020 08:39:24 -0700 (PDT)
Received: from [192.168.1.7] (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 069FdLRT032570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jul 2020 11:39:22 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_322EC9DD-8A36-45C2-9A79-4036C9ED2779"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 9 Jul 2020 11:39:21 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>  
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 09 Jul 2020 15:39:30 -0000

--Apple-Mail=_322EC9DD-8A36-45C2-9A79-4036C9ED2779
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Declarations of which code is =E2=80=9Ceasier to understand=E2=80=9D are =
going to be subjective, and I don=E2=80=99t agree with your conclusions =
even with your examples. Even so, I don=E2=80=99t think that the =
examples you give are a good comparison. While it is of course possible =
to implement things like you have below, I think it=E2=80=99s indicative =
of thinking of things in terms of a =E2=80=9Cresource request type=E2=80=9D=
. What I=E2=80=99ve been trying to argue is that there shouldn=E2=80=99t =
be a =E2=80=9Ctype=E2=80=9D, that there should just be slightly =
different ways to do a resource request. So the code is more like:

resourcesRequested =3D requests.map( item =3D> {
   if (typeof item =3D=3D =E2=80=98object=E2=80=99) {
      return new RarStyleResourceRequest(item);
   } else if (typeof item =3D=3D =E2=80=9Cstring=E2=80=9D) {
     return new StringStyleResourceRequest(item);
   }
});
processResources(resourcesRequested);

Each of these =E2=80=9C*ResourceRequest=E2=80=9D objects would be =
something that the AS can use to decide what to put into the access =
token. Although you=E2=80=99d probably put that complexity into a =
factory constructor or something instead of a map function, this shows =
the kind of dispatch you can do based on type if you=E2=80=99re doing it =
by hand. You collect everything in the array, and turn it into an object =
that represents =E2=80=9Ca request for a resource that gets tied to an =
access token=E2=80=9D. And then you process the request based on the =
collection of resource requests. Each string-based request points to =
some set of policies, as does each object-based request. You can even =
imagine that instead of creating a separate string-based request, you =
use that string to look up a policy in a policy engine to be applied =
later.

The AS then has to figure out, as it always does, what to do with this =
collection. And if you want to do an early escape on object style =
requests, you could just throw an error when you detect that. Or, you =
just ignore that part of the request. In fact, here=E2=80=99s the code I =
wrote that handles it exactly that way, while processing the JSON by =
hand in Java on a legacy OAuth 2 server:


JsonArray resources =3D json.get("resources").getAsJsonArray();     =20
Set scopes =3D StreamSupport.stream(resources.spliterator(), =
false)
	.filter( e -> e.isJsonPrimitive() ) // filter out anything =
that's not a handle     =20
	.map( e -> e.getAsString() )     =20
	.collect(Collectors.toSet());     =20
tx.setScope(scopes);


Furthermore, your XAuth example doesn=E2=80=99t go to the same depth as =
the XYZ example, which leads to a false comparison. In your =E2=80=9Cproce=
ss scope=E2=80=9D you would need to parse the =E2=80=9Cscope=E2=80=9D =
string to split on spaces, and then have another loop to process each =
scope. For the =E2=80=9Cprocess details=E2=80=9D you=E2=80=99d need to =
iterate over the array at the root of a RAR-style request and process =
each piece. In the XYZ code, you=E2=80=99ve got all of that already. If =
you=E2=80=99re going to compare the complexity of code, they should at =
least be shown to the same point of the process.=20

On top of that, the fall-through case statement below is really =
limiting. What if the scope processing or RAR objects processing gets =
combined with something else? This kind of premature optimization is not =
something we want to encourage developers to do.=20

But ultimately, I think the disconnect is down to thinking about this in =
terms of an explicit =E2=80=9Ctype=E2=80=9D, much the way XAuth used to =
do with the interactions. I=E2=80=99m glad that your thoughts have =
shifted in that space, and I think you should strongly consider the same =
set of arguments here. A lot of the promise of GNAP is getting away from =
this type-field style design, like getting away from OAuth 2=E2=80=99s =
=E2=80=9Cgrant_type=E2=80=9D approach and into something that=E2=80=99s =
focused on interaction and client models instead. This newer model =
allows for better flexibility, better consistency, and better clarity =
throughout. It=E2=80=99s no longer =E2=80=9Cif I see this flag then I go =
down this separate code path and nothing else=E2=80=9D, it=E2=80=99s now =
=E2=80=9Cif I see this item, I go down this code path and then process =
the next item too=E2=80=9D. There=E2=80=99s power in the combinations.

 =E2=80=94 Justin

> On Jul 8, 2020, at 9:31 PM, Dick Hardt  wrote:
>=20
> I had intended to provide a code sample comparing XYZ request type =
with XAuth request type
>=20
> Let's say an AS only supports OAuth scopes (does not support RAR). =
Here is JS code to check:
>=20
> //XYZ code
> var oauth_scope =3D true;
> requests.forEach( item =3D> {       =20
>     if (typeof item =3D=3D=3D "object")
>         oauth_scope =3D false;
> });
> if (!'oauth_scope') {
>     // return error
> }
>=20
> // XAuth code
> if ('oauth_scope' !=3D authorizations.type) {
>    // return error
> }
>=20
> Here is some JS code that for an AS that supports OAuth scopes, RAR, =
and OIDC requests:
>=20
> // XYZ
> if (request) {
>     requests.forEach( item =3D> {
>         if (typeof item =3D=3D=3D "object") {
>             // process a RAR item
>         } else if(typeof item =3D=3D=3D 'string') {
>             // process a scope item
>         } else {
>             // throw an error
>         }
>     })   =20
>    // process the whole request
> }
> if (oidc_claims_query) {
>     // process oidc request
> }
>=20
> //XAuth
> if (authorizations) {
>     switch (authorizations?.type) {
>         case 'oauth_rar':
>             // process authorizations.details - RAR=20
>         case 'oauth_scope':
>             // process authorizations.scope
>             // process the whole request
>             break;
>         case 'oidc':
>             // process OIDC claims
>             break;
>         default:
>             // error for unknown type
>     }
> }   =20
>=20
>=20
> Understanding what the code is doing looks much clearer in XAuth to =
me.
>=20
> =E1=90=A7
>=20
> On Wed, Jul 8, 2020 at 3:55 PM Dick Hardt > wrote:
> Hey Justin,
>=20
> Just because we are using OIDC claims, does not mean we need to mimic =
the OIDC request and response.
> I was envisioning a grant request could look as the following (using =
XAuth syntax):
>=20
> {
>     "authorizations": {
>         "type":"oidc",
>         "claims": ["name", "picture"]
>     },
>     "claims":{
>         "oidc": {
>             "id_token" : {
>                 "email"          : { "essential" : true },
>                 "email_verified" : { "essential" : true }
>             },
>             "userinfo" : {
>                 "name"           : { "essential" : true },
>                 "picture"        : null
>             }
>         }
>     }
> }
>=20
> Of course a developer could choose to only ask for a subset of this.
>=20
> Note the new authorization type of "oidc", that takes "claims" rather =
than "scope".=20
>=20
> This keeps all the authorizations and claims in their respective =
request and response containers.
>=20
> We had a thread months ago on the OIDC two stage model, and I still =
fail to see why forcing that has any advantage.=20
>=20
> /Dick
>=20
>=20
> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer > wrote:
> I=E2=80=99m glad that we can agree that there are a number of things =
in legacy protocols that are unfortunate side effects of the =
circumstances in which they were built. Space-separated scope strings, =
for instance, would fall in that category, as I=E2=80=99ve previously =
explained.
>=20
> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request =
already mixes user claims (returned in an API) and authorization (to =
fetch user claims from an API), so that ship has sailed if you=E2=80=99re =
using it. It doesn=E2=80=99t make sense to have it under a =E2=80=9Cclaims=
=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s =
a query language that affects both. Maybe you=E2=80=99d call this =
another =E2=80=9Cunfortunate design=E2=80=9D, but the context was about =
re-using an externally-defined query language that was not made for =
GNAP.
>=20
> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=9D=
 and wants to keep using it. (The vast majority of OIDC implementations, =
in my experience, don=E2=80=99t use that feature, and it=E2=80=99s not =
even required to be implemented by the AS, but again we=E2=80=99re =
talking about using this feature as an example of an external query =
language =E2=80=94 and there are others out there.) In GNAP, you should =
return claims directly in the response, and request specific elements =
from the APIs protected by the access token. These are separate things, =
and by design both XAuth and XYZ have put them into separate containers =
in the request. This is a good design, and so putting something that =
conflates these two aspects into one or the other of the containers is =
not a particularly good option, in my opinion.=20
>=20
> Additionally, though this is a bit of an aside and getting into the =
specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is =
a query language bound to the full user profile. It is my stated =
position that the items coming back from the AS should only be =
identifiers, and not full profile information. The reasoning is pretty =
simple: the client doesn=E2=80=99t know what profile information it =
needs until it knows who the user is, so putting that into a protected =
API like the UserInfo Endpoint makes much more sense than putting it =
into the immediate response, where it is not needed, because the client =
already knows it. The AS doesn=E2=80=99t know what the client needs to =
know, either, so it can=E2=80=99t determine what to fulfill. OIDC=E2=80=99=
s two-stage model makes sense, and GNAP should really only focus on =
enabling this.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 8, 2020, at 6:10 PM, Dick Hardt > wrote:
>>=20
>>=20
>>=20
>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer > wrote:
>> On Jul 8, 2020, at 3:16 PM, Dick Hardt > wrote:
>>>=20
>>> I think representing the request as an array is simplistic, and =
complicated at the same time.
>>>=20
>>> On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the request.=20=

>>=20
>> The elements of the array are taken as a set, to be tied to the same =
resulting access token. If one of those elements is defined, by the AS =
and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some or =
all of the other elements, then that=E2=80=99s up to the AS=E2=80=99s =
policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, which =
switches on all sorts of contextual stuff in the request. So to handle =
something like this, an AS can easily declare that a given scope-style =
string or a given object property applies to different parts of the =
request. You don=E2=80=99t need to externalize it here.
>>=20
>> I view the "openid" scope as an unfortunate design as OIDC was =
constrained by building on top of OAuth. (a problem I hoped to avert by =
having "identity" in scope for GNAP) The "openid" scope does not =
function as scope per se, and I think it makes OIDC harder to understand =
as the "openid" scope causes non-scope behavior.=20
>>=20
>> =20
>>=20
>> Do you have a concrete use case that requires that feature to be done =
in the way that you describe? I am trying to separate the driving use =
case from the proposed solutions to see what the differences are.=20
>>=20
>> Perhaps the client wants access to be HIPPA compliant? The HIPPA =
compliance signal applies to the scopes.
>>=20
>> Adding other properties to an object is a well understood extension =
mechanism. Adding an additional element to an array that does not act =
like the other elements seems like a hack.
>>=20
>> =20
>>=20
>>>=20
>>> Using JSON type polymorphism requires the AS to test each member of =
the array to determine if it is a string or an object. Only after =
detecting a RAR object does the AS know the client is making a RAR =
request.=20
>>=20
>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole =
resources request in order to figure out what the client is asking for, =
anyway, whether it=E2=80=99s by strings or objects or whatever else =
might be defined by an extension. Is there an argument for having an AS =
do an early dispatch on a request before it=E2=80=99s fully parsed =
everything?
>>=20
>> Let me clarify, the code is looking at the type of object that has =
been parsed.=20
>>=20
>> Determining if an item in an array is a scope or a RAR object by =
looking at the type being either a string or an object seems less clear =
than a property of an object explicitly declaring the type.
>>=20
>> =20
>>=20
>>> This also limits the request to be composed only of scope strings or =
RAR objects. I don't see how other strings or objects could be used in =
the array, so there is no clear extension point in the "resources" array =
for other query mechanisms.
>>=20
>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring =
that a string has to be an OAuth2-style scope. It can be, but ultimately =
it=E2=80=99s just a string that the AS can understand. And the objects =
are just that =E2=80=94 objects. If the AS understands what the object =
is, it can be a RAR object or it can be something completely =
API-specific with another query language entirely.
>>=20
>> But the other query language would need a type that has been reserved =
in the RAR name space for there to be interop, so it effectively is a =
RAR extension.
>>=20
>> There are query languages in other domains that may not fit nicely =
into RAR such as a query for medical records.
>>=20
>> Yes, the medical records could be yet another top level property, but =
per below, I think that is confusing.
>> =20
>> (Point, though: RAR already pretty much allows this by letting them =
be extended infinitely, a feature it inherits from XYZ)
>>=20
>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99s=
 an array of strings or objects and each of those means the same thing, =
=E2=80=9Csomething the client is asking for=E2=80=9D.
>>=20
>>>=20
>>> Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.
>>>=20
>>=20
>> It=E2=80=99s my stance that this is an unnecessary limitation at this =
level. The objects within the array should be typed, like RAR, but it =
doesn=E2=80=99t make sense for the overall request to be typed. Instead, =
there should be one =E2=80=9Ctype" of query in the core, what XYZ calls =
the =E2=80=9Cresources=E2=80=9D request. Other query languages should be =
added as extensions either to the RAR-style objects (by defining a type =
at that level) or as a separate top-level member.
>>=20
>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D =
query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.
>>=20
>> To me, this remains much more understandable, extensible, and clean.
>>=20
>> While this may be more understandable to a developer just porting an =
app OIDC that only wants OIDC results, but I think it is more =
complicated as soon as the developer wants other results, which is =
likely what prompted the developer to use GNAP instead of ODIC.
>>=20
>> I think it is easier to understand if all the claims are in one =
container, and all the authorizations are in another container.
>>=20
>> If a developer wants access to some resources, some claims, and an =
OpenID Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread across =
multiple containers. There are some claims in the "claims" container, =
and some "claims" in the "oidc_claims_query" container. And is the =
access token response in "oidc_claims_query" the same as an access token =
response in "resources"? It would seem simpler if they were, and if all =
the access tokens came back in the same container.
>>=20
>> Per Aaron's post that you have referred to, the developer can get sme =
bare claims directly in the response in the "claims" object, an ID Token =
that has the same or different claims, and if they want, an access token =
that they can call a user_info endpoint to get the same, or different =
claims.
>>=20
>> For example, an enterprise app client may want an ID Token with the =
email address, bare claims for the user's name and a URI to a profile =
photo, and an access token to query which groups a user belongs to.
>>=20
>> We are still re-using the OIDC claims, but we are not mixing claims =
and authorizations.
>>=20
>> /Dick
>>=20
>>=20
>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz =

>> =E1=90=A7
>=20
> =E1=90=A7


--Apple-Mail=_322EC9DD-8A36-45C2-9A79-4036C9ED2779
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Declarations of which code is =E2=80=9Ceasier to =
understand=E2=80=9D are going to be subjective, and I don=E2=80=99t =
agree with your conclusions even with your examples. Even so, I don=E2=80=99=
t think that the examples you give are a good comparison. While it is of =
course possible to implement things like you have below, I think it=E2=80=99=
s indicative of thinking of things in terms of a =E2=80=9Cresource =
request type=E2=80=9D. What I=E2=80=99ve been trying to argue is that =
there shouldn=E2=80=99t be a =E2=80=9Ctype=E2=80=9D, that there should =
just be slightly different ways to do a resource request. So the code is =
more like:

resourcesRequested =3D requests.map( item =3D> =
{
   if (typeof =
item =3D=3D =E2=80=98object=E2=80=99) {
      return new =
RarStyleResourceRequest(item);
   } else if (typeof item =3D=3D =E2=80=9Cstring=E2=80=
=9D) {
    =
 return new StringStyleResourceRequest(item);
   }
});
processResources(resourcesRequested);
<=
div class=3D"">

Each =
of these =E2=80=9C*ResourceRequest=E2=80=9D objects would be something =
that the AS can use to decide what to put into the access token. =
Although you=E2=80=99d probably put that complexity into a factory =
constructor or something instead of a map function, this shows the kind =
of dispatch you can do based on type if you=E2=80=99re doing it by hand. =
You collect everything in the array, and turn it into an object that =
represents =E2=80=9Ca request for a resource that gets tied to an access =
token=E2=80=9D. And then you process the request based on the collection =
of resource requests. Each string-based request points to some set of =
policies, as does each object-based request. You can even imagine that =
instead of creating a separate string-based request, you use that string =
to look up a policy in a policy engine to be applied later.

The AS then has to =
figure out, as it always does, what to do with this collection. And if =
you want to do an early escape on object style requests, you could just =
throw an error when you detect that. Or, you just ignore that part of =
the request. In fact, here=E2=80=99s the code I wrote that handles it =
exactly that way, while processing the JSON by hand in Java on a legacy =
OAuth 2 server:


JsonArray resources =3D json.get("resources").ge=
tAsJsonArray();      
Set<String> scopes =3D StreamSupport.strea=
m(resources.spliterator(), false)
	.filter( =
e -> e.isJsonPrimitive() ) // filter out anything =
that's not a handle      
	=
.map( e -> e.getAsString() )    =
  
	=
.collect(Collectors.toSet());    =
  
tx.setScope(scopes);


Furthermore, your XAuth example doesn=E2=80=99t go to the =
same depth as the XYZ example, which leads to a false comparison. In =
your =E2=80=9Cprocess scope=E2=80=9D you would need to parse the =
=E2=80=9Cscope=E2=80=9D string to split on spaces, and then have another =
loop to process each scope. For the =E2=80=9Cprocess details=E2=80=9D =
you=E2=80=99d need to iterate over the array at the root of a RAR-style =
request and process each piece. In the XYZ code, you=E2=80=99ve got all =
of that already. If you=E2=80=99re going to compare the complexity of =
code, they should at least be shown to the same point of the =
process. 

On top of that, the fall-through case statement below is =
really limiting. What if the scope processing or RAR objects processing =
gets combined with something else? This kind of premature optimization =
is not something we want to encourage developers to do. 

But ultimately, I think =
the disconnect is down to thinking about this in terms of an explicit =
=E2=80=9Ctype=E2=80=9D, much the way XAuth used to do with the =
interactions. I=E2=80=99m glad that your thoughts have shifted in that =
space, and I think you should strongly consider the same set of =
arguments here. A lot of the promise of GNAP is getting away from this =
type-field style design, like getting away from OAuth 2=E2=80=99s =
=E2=80=9Cgrant_type=E2=80=9D approach and into something that=E2=80=99s =
focused on interaction and client models instead. This newer model =
allows for better flexibility, better consistency, and better clarity =
throughout. It=E2=80=99s no longer =E2=80=9Cif I see this flag then I go =
down this separate code path and nothing else=E2=80=9D, it=E2=80=99s now =
=E2=80=9Cif I see this item, I go down this code path and then process =
the next item too=E2=80=9D. There=E2=80=99s power in the =
combinations.

 =E2=80=94 Justin

On Jul =
8, 2020, at 9:31 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I had intended to provide a code =
sample comparing XYZ request type with XAuth request type

Let's =
say an AS only supports OAuth scopes (does not support RAR). Here is JS =
code to check:

//XYZ code
var oauth_scope =
=3D true;
requests.forEach( item =3D> =
{         
    =
if (typeof item =3D=3D=3D "object")
    =
    oauth_scope =3D false;
});
if (!'oauth_scope') {
    // =
return error
}

// XAuth code
if ('oauth_scope' !=3D authorizations.type) {
   // return error
}

Here is some JS code that for an AS that supports OAuth =
scopes, RAR, and OIDC requests:

// XYZ
if (request) {
    requests.forEach( item =3D> {
        if (typeof item =3D=3D=3D =
"object") {
            // =
process a RAR item
        } else =
if(typeof item =3D=3D=3D 'string') {
      =
      // process a scope item
    =
    } else {
          =
  // throw an error
        }
    })    
   // =
process the whole request
}
if =
(oidc_claims_query) {
    // process oidc =
request
}

//XAuth
if =
(authorizations) {
    switch =
(authorizations?.type) {
        case =
'oauth_rar':
            // =
process authorizations.details - RAR 
      =
  case 'oauth_scope':
        =
    // process authorizations.scope
  =
          // process the whole request
            break;
        case 'oidc':
  =
          // process OIDC claims
            break;
        default:
  =
          // error for unknown type
    }
}    


Understanding what the =
code is doing looks much clearer in XAuth to me.

3D""=E1=90=A7

On Wed, Jul =
8, 2020 at 3:55 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Justin,

Just because we are using OIDC =
claims, does not mean we need to mimic the OIDC request and =
response.
I was envisioning a grant request could =
look as the following (using XAuth syntax):

{
  =
  "authorizations": {
        =
"type":"oidc",
        "claims": =
["name", "picture"]
    },
  =
  "claims":{
        "oidc": {
            "id_token" : {
                =
"email"          : { "essential" : true },
                =
"email_verified" : { "essential" : true }
    =
        },
        =
    "userinfo" : {
        =
        "name"           : =
{ "essential" : true },
          =
      "picture"        : null
            }
        }
    =
}
}

Of course a developer could choose to =
only ask for a subset of this.

Note the new authorization type of =
"oidc", that takes "claims" rather than "scope". 

This keeps all the =
authorizations and claims in their respective request and response =
containers.

We =
had a thread months ago on the OIDC two stage model, and I still fail to =
see why forcing that has any advantage. 

/Dick


On Wed, Jul 8, 2020 at 3:25 PM Justin =
Richer <jricher@mit.edu> wrote:
I=E2=80=99m =
glad that we can agree that there are a number of things in legacy =
protocols that are unfortunate side effects of the circumstances in =
which they were built. Space-separated scope strings, for instance, =
would fall in that category, as I=E2=80=99ve previously explained.

A key point in the =
below: the OIDC =E2=80=9Cclaims=E2=80=9D request already mixes user =
claims (returned in an API) and authorization (to fetch user claims from =
an API), so that ship has sailed if you=E2=80=99re using it. It =
doesn=E2=80=99t make sense to have it under a =E2=80=9Cclaims=E2=80=9D =
or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s a query =
language that affects both. Maybe you=E2=80=99d call this another =
=E2=80=9Cunfortunate design=E2=80=9D, but the context was about re-using =
an externally-defined query language that was not made for GNAP.

My scenario was for =
someone who is already using =E2=80=9Cclaims=E2=80=9D and wants to keep =
using it. (The vast majority of OIDC implementations, in my experience, =
don=E2=80=99t use that feature, and it=E2=80=99s not even required to be =
implemented by the AS, but again we=E2=80=99re talking about using this =
feature as an example of an external query language =E2=80=94 and there =
are others out there.) In GNAP, you should return claims directly in the =
response, and request specific elements from the APIs protected by the =
access token. These are separate things, and by design both XAuth and =
XYZ have put them into separate containers in the request. This is a =
good design, and so putting something that conflates these two aspects =
into one or the other of the containers is not a particularly good =
option, in my opinion. 

Additionally, though this is a bit of =
an aside and getting into the specifics of identity, the =E2=80=9Cclaims=E2=
=80=9D parameter of ODIC is a query language bound to the full user =
profile. It is my stated position that the items coming back from the AS =
should only be identifiers, and not full profile information. The =
reasoning is pretty simple: the client doesn=E2=80=99t know what profile =
information it needs until it knows who the user is, so putting that =
into a protected API like the UserInfo Endpoint makes much more sense =
than putting it into the immediate response, where it is not needed, =
because the client already knows it. The AS doesn=E2=80=99t know what =
the client needs to know, either, so it can=E2=80=99t determine what to =
fulfill. OIDC=E2=80=99s two-stage model makes sense, and GNAP should =
really only focus on enabling this.

 =E2=80=94 Justin

On Jul 8, 2020, at 6:10 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Wed, Jul =
8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at =
3:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I think representing the request as an array is simplistic, =
and complicated at the same time.

On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the =
request. 

The elements of the array are taken as =
a set, to be tied to the same resulting access token. If one of those =
elements is defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s =
protecting, to apply across some or all of the other elements, then =
that=E2=80=99s up to the AS=E2=80=99s policy. Much like the =E2=80=9Copeni=
d=E2=80=9D scope in OIDC, which switches on all sorts of contextual =
stuff in the request. So to handle something like this, an AS can easily =
declare that a given scope-style string or a given object property =
applies to different parts of the request. You don=E2=80=99t need to =
externalize it here.

I view the "openid" scope as an =
unfortunate design as OIDC was constrained by building on top of =
OAuth. (a problem I hoped to avert by having "identity" in scope for =
GNAP) The "openid" scope does not function as scope per se, and I =
think it makes OIDC harder to understand as the "openid" scope causes =
non-scope behavior. 

 

Do you have a concrete =
use case that requires that feature to be done in the way that you =
describe? I am trying to separate the driving use case from the proposed =
solutions to see what the differences =
are. 

Perhaps the client wants access to be =
HIPPA compliant? The HIPPA compliance signal applies to the =
scopes.

Adding =
other properties to an object is a well understood extension mechanism. =
Adding an additional element to an array that does not act like the =
other elements seems like a hack.

 


Using =
JSON type polymorphism requires the AS to test each member of the =
array to determine if it is a string or an object. Only after detecting =
a RAR object does the AS know the client is making a RAR request. 

That=E2=80=99s correct =
=E2=80=94 but the AS needs to parse the whole resources request in order =
to figure out what the client is asking for, anyway, whether it=E2=80=99s =
by strings or objects or whatever else might be defined by an extension. =
Is there an argument for having an AS do an early dispatch on a request =
before it=E2=80=99s fully parsed =
everything?

Let me clarify, the code is looking at =
the type of object that has been parsed. 

Determining if an item in an array is a =
scope or a RAR object by looking at the type being either a string or an =
object seems less clear than a property of an object explicitly =
declaring the type.

 

This =
also limits the request to be composed only of scope strings or RAR =
objects. I don't see how other strings or objects could be used in the =
array, so there is no clear extension point in the "resources" array for =
other query mechanisms.

That=E2=80=99s not the =
case in XYZ since we aren=E2=80=99t declaring that a string has to be an =
OAuth2-style scope. It can be, but ultimately it=E2=80=99s just a string =
that the AS can understand. And the objects are just that =E2=80=94 =
objects. If the AS understands what the object is, it can be a RAR =
object or it can be something completely API-specific with another query =
language entirely.

But the other query language would need =
a type that has been reserved in the RAR name space for there to be =
interop, so it effectively is a RAR extension.

There are query languages in other =
domains that may not fit nicely into RAR such as a query for medical =
records.

Yes, =
the medical records could be yet another top level property, but per =
below, I think that is confusing.
 
(Point, though: RAR already pretty much allows this by =
letting them be extended infinitely, a feature it inherits from =
XYZ)

I=E2=80=99m=
 proposing that we do the same thing with GNAP: it=E2=80=99s an array of =
strings or objects and each of those means the same thing, =E2=80=9Csometh=
ing the client is asking for=E2=80=9D.


Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.


It=E2=80=99s my stance that this is an =
unnecessary limitation at this level. The objects within the array =
should be typed, like RAR, but it doesn=E2=80=99t make sense for the =
overall request to be typed. Instead, there should be one =E2=80=9Ctype" =
of query in the core, what XYZ calls the =E2=80=9Cresources=E2=80=9D =
request. Other query languages should be added as extensions either to =
the RAR-style objects (by defining a type at that level) or as a =
separate top-level member.

For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D=
 query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.

To me, this remains much =
more understandable, extensible, and =
clean.

While this may be more understandable =
to a developer just porting an app OIDC that only wants OIDC =
results, but I think it is more complicated as soon as the developer =
wants other results, which is likely what prompted the developer to =
use GNAP instead of ODIC.

I think it is easier to understand if all the claims are in =
one container, and all the authorizations are in another =
container.

If =
a developer wants access to some resources, some claims, and an OpenID =
Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread =
across multiple containers. There are some claims in the "claims" =
container, and some "claims" in the "oidc_claims_query" container. And =
is the access token response in "oidc_claims_query" the same as an =
access token response in "resources"? It would seem simpler if they =
were, and if all the access tokens came back in the same =
container.

Per =
Aaron's post that you have referred to, the developer can get sme bare =
claims directly in the response in the "claims" object, an ID Token that =
has the same or different claims, and if they want, an access token that =
they can call a user_info endpoint to get the same, or different =
claims.

For =
example, an enterprise app client may want an ID Token with the email =
address, bare claims for the user's name and a URI to a profile photo, =
and an access token to query which groups a user belongs to.

We are still =
re-using the OIDC claims, but we are not mixing claims and =
authorizations.

/Dick


[1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
3D""=E1=90=A7

3D""=E1=90=A7



=

--Apple-Mail=_322EC9DD-8A36-45C2-9A79-4036C9ED2779--


From nobody Thu Jul  9 08:39:43 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 676663A0A49 for ; Thu,  9 Jul 2020 08:39:31 -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 w-UNXm5pdWQj for ; Thu,  9 Jul 2020 08:39: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 4D8F63A0C73 for ; Thu,  9 Jul 2020 08:39:24 -0700 (PDT)
Received: from [192.168.1.7] (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 069FdLRU032570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jul 2020 11:39:23 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_98012DF2-8214-4074-BD18-2760AEAFB9F9"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 9 Jul 2020 11:39:22 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 09 Jul 2020 15:39:31 -0000

--Apple-Mail=_98012DF2-8214-4074-BD18-2760AEAFB9F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

But this approach doesn=E2=80=99t keep things in their respective =
containers =E2=80=94 you=E2=80=99ve explicitly got =E2=80=9Cclaims=E2=80=9D=
 underneath the =E2=80=9Cauthorizations=E2=80=9D header, and you=E2=80=99v=
e got items that come back as rights associated with the access token =
(which should be =E2=80=9Cauthorizations=E2=80=9D) in the =E2=80=9Cuserinf=
o=E2=80=9D section under the =E2=80=9Cclaims=E2=80=9D header. And as far =
as I can tell, these two sections are redundant to each other. =
Everything is everywhere.=20

Additionally, this approach and syntax makes it difficult to combine =
different kinds of requests into one. One of OpenID Connect=E2=80=99s =
biggest draws, as I=E2=80=99m sure you recall, is that it could be =
combined with a request for non-OIDC resources. This was the real =
innovation that Twitter and Facebook=E2=80=99s identity APIs brought, =
access to more than just authentication, and what Google had tried to =
replicate with the awkward OpenID 2 + OAuth 1 hybrid system. Taking a =
step back from the existing solutions of OpenID 2 and OAuth 1 let us, as =
the community, see the value in the pattern that became OIDC on top of =
OAuth 2.=20

Sure, you could say that the =E2=80=9Coidc=E2=80=9D type also can allow =
a =E2=80=9Cscopes=E2=80=9D parameter, but what about a RAR style object, =
then? And what about when someone comes up with some new way to request =
access rights, or a VC-based query language? Does every =E2=80=9Ctype=E2=80=
=9D need to now know about every other =E2=80=9Ctype=E2=80=9D in order =
for an AS to be able to figure out how they go together? This seems like =
the protocol definition limiting what combinations the AS can handle, or =
what an RS might want to use.

My stance is that GNAP should have a way to query for rights in the =
access token (=E2=80=9Cauthorizations=E2=80=9D in xauth parlance) and =
identifiers for the user (=E2=80=9Cclaims=E2=80=9D in xauth parlance), =
and anything else should be an extension with potentially different =
models. The AS would process the =E2=80=9Cauthorizations=E2=80=9D =
equivalent (for the access token) alongside any other incoming query and =
then make a policy decision based on that.

I find it interesting that you are now saying we don=E2=80=99t need to =
use the OIDC request format when previously you=E2=80=99ve made it clear =
that you were in favor of pointing at external query languages, =
including their syntax. I=E2=80=99m glad to see that you=E2=80=99re now =
looking at things in a more flexible way, but I think it=E2=80=99s =
important that we be careful and conscientious about how we reference =
any external query languages in GNAP.

 =E2=80=94 Justin

> On Jul 8, 2020, at 6:55 PM, Dick Hardt  wrote:
>=20
> Hey Justin,
>=20
> Just because we are using OIDC claims, does not mean we need to mimic =
the OIDC request and response.
> I was envisioning a grant request could look as the following (using =
XAuth syntax):
>=20
> {
>     "authorizations": {
>         "type":"oidc",
>         "claims": ["name", "picture"]
>     },
>     "claims":{
>         "oidc": {
>             "id_token" : {
>                 "email"          : { "essential" : true },
>                 "email_verified" : { "essential" : true }
>             },
>             "userinfo" : {
>                 "name"           : { "essential" : true },
>                 "picture"        : null
>             }
>         }
>     }
> }
>=20
> Of course a developer could choose to only ask for a subset of this.
>=20
> Note the new authorization type of "oidc", that takes "claims" rather =
than "scope".=20
>=20
> This keeps all the authorizations and claims in their respective =
request and response containers.
>=20
> We had a thread months ago on the OIDC two stage model, and I still =
fail to see why forcing that has any advantage.=20
>=20
> /Dick
>=20
>=20
> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer > wrote:
> I=E2=80=99m glad that we can agree that there are a number of things =
in legacy protocols that are unfortunate side effects of the =
circumstances in which they were built. Space-separated scope strings, =
for instance, would fall in that category, as I=E2=80=99ve previously =
explained.
>=20
> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request =
already mixes user claims (returned in an API) and authorization (to =
fetch user claims from an API), so that ship has sailed if you=E2=80=99re =
using it. It doesn=E2=80=99t make sense to have it under a =E2=80=9Cclaims=
=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s =
a query language that affects both. Maybe you=E2=80=99d call this =
another =E2=80=9Cunfortunate design=E2=80=9D, but the context was about =
re-using an externally-defined query language that was not made for =
GNAP.
>=20
> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=9D=
 and wants to keep using it. (The vast majority of OIDC implementations, =
in my experience, don=E2=80=99t use that feature, and it=E2=80=99s not =
even required to be implemented by the AS, but again we=E2=80=99re =
talking about using this feature as an example of an external query =
language =E2=80=94 and there are others out there.) In GNAP, you should =
return claims directly in the response, and request specific elements =
from the APIs protected by the access token. These are separate things, =
and by design both XAuth and XYZ have put them into separate containers =
in the request. This is a good design, and so putting something that =
conflates these two aspects into one or the other of the containers is =
not a particularly good option, in my opinion.=20
>=20
> Additionally, though this is a bit of an aside and getting into the =
specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is =
a query language bound to the full user profile. It is my stated =
position that the items coming back from the AS should only be =
identifiers, and not full profile information. The reasoning is pretty =
simple: the client doesn=E2=80=99t know what profile information it =
needs until it knows who the user is, so putting that into a protected =
API like the UserInfo Endpoint makes much more sense than putting it =
into the immediate response, where it is not needed, because the client =
already knows it. The AS doesn=E2=80=99t know what the client needs to =
know, either, so it can=E2=80=99t determine what to fulfill. OIDC=E2=80=99=
s two-stage model makes sense, and GNAP should really only focus on =
enabling this.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 8, 2020, at 6:10 PM, Dick Hardt > wrote:
>>=20
>>=20
>>=20
>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer > wrote:
>> On Jul 8, 2020, at 3:16 PM, Dick Hardt > wrote:
>>>=20
>>> I think representing the request as an array is simplistic, and =
complicated at the same time.
>>>=20
>>> On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the request.=20=

>>=20
>> The elements of the array are taken as a set, to be tied to the same =
resulting access token. If one of those elements is defined, by the AS =
and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some or =
all of the other elements, then that=E2=80=99s up to the AS=E2=80=99s =
policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, which =
switches on all sorts of contextual stuff in the request. So to handle =
something like this, an AS can easily declare that a given scope-style =
string or a given object property applies to different parts of the =
request. You don=E2=80=99t need to externalize it here.
>>=20
>> I view the "openid" scope as an unfortunate design as OIDC was =
constrained by building on top of OAuth. (a problem I hoped to avert by =
having "identity" in scope for GNAP) The "openid" scope does not =
function as scope per se, and I think it makes OIDC harder to understand =
as the "openid" scope causes non-scope behavior.=20
>>=20
>> =20
>>=20
>> Do you have a concrete use case that requires that feature to be done =
in the way that you describe? I am trying to separate the driving use =
case from the proposed solutions to see what the differences are.=20
>>=20
>> Perhaps the client wants access to be HIPPA compliant? The HIPPA =
compliance signal applies to the scopes.
>>=20
>> Adding other properties to an object is a well understood extension =
mechanism. Adding an additional element to an array that does not act =
like the other elements seems like a hack.
>>=20
>> =20
>>=20
>>>=20
>>> Using JSON type polymorphism requires the AS to test each member of =
the array to determine if it is a string or an object. Only after =
detecting a RAR object does the AS know the client is making a RAR =
request.=20
>>=20
>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole =
resources request in order to figure out what the client is asking for, =
anyway, whether it=E2=80=99s by strings or objects or whatever else =
might be defined by an extension. Is there an argument for having an AS =
do an early dispatch on a request before it=E2=80=99s fully parsed =
everything?
>>=20
>> Let me clarify, the code is looking at the type of object that has =
been parsed.=20
>>=20
>> Determining if an item in an array is a scope or a RAR object by =
looking at the type being either a string or an object seems less clear =
than a property of an object explicitly declaring the type.
>>=20
>> =20
>>=20
>>> This also limits the request to be composed only of scope strings or =
RAR objects. I don't see how other strings or objects could be used in =
the array, so there is no clear extension point in the "resources" array =
for other query mechanisms.
>>=20
>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring =
that a string has to be an OAuth2-style scope. It can be, but ultimately =
it=E2=80=99s just a string that the AS can understand. And the objects =
are just that =E2=80=94 objects. If the AS understands what the object =
is, it can be a RAR object or it can be something completely =
API-specific with another query language entirely.
>>=20
>> But the other query language would need a type that has been reserved =
in the RAR name space for there to be interop, so it effectively is a =
RAR extension.
>>=20
>> There are query languages in other domains that may not fit nicely =
into RAR such as a query for medical records.
>>=20
>> Yes, the medical records could be yet another top level property, but =
per below, I think that is confusing.
>> =20
>> (Point, though: RAR already pretty much allows this by letting them =
be extended infinitely, a feature it inherits from XYZ)
>>=20
>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99s=
 an array of strings or objects and each of those means the same thing, =
=E2=80=9Csomething the client is asking for=E2=80=9D.
>>=20
>>>=20
>>> Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.
>>>=20
>>=20
>> It=E2=80=99s my stance that this is an unnecessary limitation at this =
level. The objects within the array should be typed, like RAR, but it =
doesn=E2=80=99t make sense for the overall request to be typed. Instead, =
there should be one =E2=80=9Ctype" of query in the core, what XYZ calls =
the =E2=80=9Cresources=E2=80=9D request. Other query languages should be =
added as extensions either to the RAR-style objects (by defining a type =
at that level) or as a separate top-level member.
>>=20
>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D =
query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.
>>=20
>> To me, this remains much more understandable, extensible, and clean.
>>=20
>> While this may be more understandable to a developer just porting an =
app OIDC that only wants OIDC results, but I think it is more =
complicated as soon as the developer wants other results, which is =
likely what prompted the developer to use GNAP instead of ODIC.
>>=20
>> I think it is easier to understand if all the claims are in one =
container, and all the authorizations are in another container.
>>=20
>> If a developer wants access to some resources, some claims, and an =
OpenID Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread across =
multiple containers. There are some claims in the "claims" container, =
and some "claims" in the "oidc_claims_query" container. And is the =
access token response in "oidc_claims_query" the same as an access token =
response in "resources"? It would seem simpler if they were, and if all =
the access tokens came back in the same container.
>>=20
>> Per Aaron's post that you have referred to, the developer can get sme =
bare claims directly in the response in the "claims" object, an ID Token =
that has the same or different claims, and if they want, an access token =
that they can call a user_info endpoint to get the same, or different =
claims.
>>=20
>> For example, an enterprise app client may want an ID Token with the =
email address, bare claims for the user's name and a URI to a profile =
photo, and an access token to query which groups a user belongs to.
>>=20
>> We are still re-using the OIDC claims, but we are not mixing claims =
and authorizations.
>>=20
>> /Dick
>>=20
>>=20
>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz =

>> =E1=90=A7
>=20
> =E1=90=A7


--Apple-Mail=_98012DF2-8214-4074-BD18-2760AEAFB9F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


But this approach doesn=E2=80=99t keep things in their =
respective containers =E2=80=94 you=E2=80=99ve explicitly got =
=E2=80=9Cclaims=E2=80=9D underneath the =E2=80=9Cauthorizations=E2=80=9D =
header, and you=E2=80=99ve got items that come back as rights associated =
with the access token (which should be =E2=80=9Cauthorizations=E2=80=9D) =
in the =E2=80=9Cuserinfo=E2=80=9D section under the =E2=80=9Cclaims=E2=80=9D=
 header. And as far as I can tell, these two sections are redundant to =
each other. Everything is everywhere. 

Additionally, this approach and syntax =
makes it difficult to combine different kinds of requests into one. One =
of OpenID Connect=E2=80=99s biggest draws, as I=E2=80=99m sure you =
recall, is that it could be combined with a request for non-OIDC =
resources. This was the real innovation that Twitter and Facebook=E2=80=99=
s identity APIs brought, access to more than just authentication, and =
what Google had tried to replicate with the awkward OpenID 2 + OAuth 1 =
hybrid system. Taking a step back from the existing solutions of OpenID =
2 and OAuth 1 let us, as the community, see the value in the pattern =
that became OIDC on top of OAuth 2. 

Sure, you could say that the =E2=80=9Coid=
c=E2=80=9D type also can allow a =E2=80=9Cscopes=E2=80=9D parameter, but =
what about a RAR style object, then? And what about when someone comes =
up with some new way to request access rights, or a VC-based query =
language? Does every =E2=80=9Ctype=E2=80=9D need to now know about every =
other =E2=80=9Ctype=E2=80=9D in order for an AS to be able to figure out =
how they go together? This seems like the protocol definition limiting =
what combinations the AS can handle, or what an RS might want to =
use.

My stance =
is that GNAP should have a way to query for rights in the access token =
(=E2=80=9Cauthorizations=E2=80=9D in xauth parlance) and identifiers for =
the user (=E2=80=9Cclaims=E2=80=9D in xauth parlance), and anything else =
should be an extension with potentially different models. The AS would =
process the =E2=80=9Cauthorizations=E2=80=9D equivalent (for the access =
token) alongside any other incoming query and then make a policy =
decision based on that.

I find it interesting that you are now saying we don=E2=80=99t =
need to use the OIDC request format when previously you=E2=80=99ve made =
it clear that you were in favor of pointing at external query languages, =
including their syntax. I=E2=80=99m glad to see that you=E2=80=99re now =
looking at things in a more flexible way, but I think it=E2=80=99s =
important that we be careful and conscientious about how we reference =
any external query languages in GNAP.

 =E2=80=94 Justin

On Jul 8, 2020, at 6:55 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey =
Justin,

Just =
because we are using OIDC claims, does not mean we need to mimic =
the OIDC request and response.
I was envisioning a =
grant request could look as the following (using XAuth syntax):

{
    "authorizations": {
    =
    "type":"oidc",
        =
"claims": ["name", "picture"]
    },
    "claims":{
      =
  "oidc": {
            =
"id_token" : {
            =
    "email"          : { "essential" =
: true },
              =
  "email_verified" : { "essential" : true }
  =
          },
      =
      "userinfo" : {
      =
          "name"         =
  : { "essential" : true },
      =
          "picture"       =
 : null
            =
}
        }
  =
  }
}

Of course a developer could choose to =
only ask for a subset of this.

Note the new authorization type of =
"oidc", that takes "claims" rather than "scope". 

This keeps all the =
authorizations and claims in their respective request and response =
containers.

We =
had a thread months ago on the OIDC two stage model, and I still fail to =
see why forcing that has any advantage. 

/Dick


On Wed, Jul 8, 2020 at 3:25 PM Justin =
Richer <jricher@mit.edu> wrote:
I=E2=80=99m glad that we can agree that there =
are a number of things in legacy protocols that are unfortunate side =
effects of the circumstances in which they were built. Space-separated =
scope strings, for instance, would fall in that category, as I=E2=80=99ve =
previously explained.

A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D =
request already mixes user claims (returned in an API) and authorization =
(to fetch user claims from an API), so that ship has sailed if you=E2=80=99=
re using it. It doesn=E2=80=99t make sense to have it under a =
=E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D request, =
since it=E2=80=99s a query language that affects both. Maybe you=E2=80=99d=
 call this another =E2=80=9Cunfortunate design=E2=80=9D, but the context =
was about re-using an externally-defined query language that was not =
made for GNAP.

My =
scenario was for someone who is already using =E2=80=9Cclaims=E2=80=9D =
and wants to keep using it. (The vast majority of OIDC implementations, =
in my experience, don=E2=80=99t use that feature, and it=E2=80=99s not =
even required to be implemented by the AS, but again we=E2=80=99re =
talking about using this feature as an example of an external query =
language =E2=80=94 and there are others out there.) In GNAP, you should =
return claims directly in the response, and request specific elements =
from the APIs protected by the access token. These are separate things, =
and by design both XAuth and XYZ have put them into separate containers =
in the request. This is a good design, and so putting something that =
conflates these two aspects into one or the other of the containers is =
not a particularly good option, in my opinion. 

Additionally, though =
this is a bit of an aside and getting into the specifics of identity, =
the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is a query language bound =
to the full user profile. It is my stated position that the items coming =
back from the AS should only be identifiers, and not full profile =
information. The reasoning is pretty simple: the client doesn=E2=80=99t =
know what profile information it needs until it knows who the user is, =
so putting that into a protected API like the UserInfo Endpoint makes =
much more sense than putting it into the immediate response, where it is =
not needed, because the client already knows it. The AS doesn=E2=80=99t =
know what the client needs to know, either, so it can=E2=80=99t =
determine what to fulfill. OIDC=E2=80=99s two-stage model makes sense, =
and GNAP should really only focus on enabling this.

 =E2=80=94 =
Justin

On Jul 8, 2020, at 6:10 PM, =
Dick Hardt <dick.hardt@gmail.com> wrote:



On Wed, Jul =
8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at =
3:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I think representing the request as an array is simplistic, =
and complicated at the same time.

On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the =
request. 

The elements of the array are taken as =
a set, to be tied to the same resulting access token. If one of those =
elements is defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s =
protecting, to apply across some or all of the other elements, then =
that=E2=80=99s up to the AS=E2=80=99s policy. Much like the =E2=80=9Copeni=
d=E2=80=9D scope in OIDC, which switches on all sorts of contextual =
stuff in the request. So to handle something like this, an AS can easily =
declare that a given scope-style string or a given object property =
applies to different parts of the request. You don=E2=80=99t need to =
externalize it here.

I view the "openid" scope as an =
unfortunate design as OIDC was constrained by building on top of =
OAuth. (a problem I hoped to avert by having "identity" in scope for =
GNAP) The "openid" scope does not function as scope per se, and I =
think it makes OIDC harder to understand as the "openid" scope causes =
non-scope behavior. 

 

Do you have a concrete =
use case that requires that feature to be done in the way that you =
describe? I am trying to separate the driving use case from the proposed =
solutions to see what the differences =
are. 

Perhaps the client wants access to be =
HIPPA compliant? The HIPPA compliance signal applies to the =
scopes.

Adding =
other properties to an object is a well understood extension mechanism. =
Adding an additional element to an array that does not act like the =
other elements seems like a hack.

 


Using =
JSON type polymorphism requires the AS to test each member of the =
array to determine if it is a string or an object. Only after detecting =
a RAR object does the AS know the client is making a RAR request. 

That=E2=80=99s correct =
=E2=80=94 but the AS needs to parse the whole resources request in order =
to figure out what the client is asking for, anyway, whether it=E2=80=99s =
by strings or objects or whatever else might be defined by an extension. =
Is there an argument for having an AS do an early dispatch on a request =
before it=E2=80=99s fully parsed =
everything?

Let me clarify, the code is looking at =
the type of object that has been parsed. 

Determining if an item in an array is a =
scope or a RAR object by looking at the type being either a string or an =
object seems less clear than a property of an object explicitly =
declaring the type.

 

This =
also limits the request to be composed only of scope strings or RAR =
objects. I don't see how other strings or objects could be used in the =
array, so there is no clear extension point in the "resources" array for =
other query mechanisms.

That=E2=80=99s not the =
case in XYZ since we aren=E2=80=99t declaring that a string has to be an =
OAuth2-style scope. It can be, but ultimately it=E2=80=99s just a string =
that the AS can understand. And the objects are just that =E2=80=94 =
objects. If the AS understands what the object is, it can be a RAR =
object or it can be something completely API-specific with another query =
language entirely.

But the other query language would need =
a type that has been reserved in the RAR name space for there to be =
interop, so it effectively is a RAR extension.

There are query languages in other =
domains that may not fit nicely into RAR such as a query for medical =
records.

Yes, =
the medical records could be yet another top level property, but per =
below, I think that is confusing.
 
(Point, though: RAR already pretty much allows this by =
letting them be extended infinitely, a feature it inherits from =
XYZ)

I=E2=80=99m=
 proposing that we do the same thing with GNAP: it=E2=80=99s an array of =
strings or objects and each of those means the same thing, =E2=80=9Csometh=
ing the client is asking for=E2=80=9D.


Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.


It=E2=80=99s my stance that this is an =
unnecessary limitation at this level. The objects within the array =
should be typed, like RAR, but it doesn=E2=80=99t make sense for the =
overall request to be typed. Instead, there should be one =E2=80=9Ctype" =
of query in the core, what XYZ calls the =E2=80=9Cresources=E2=80=9D =
request. Other query languages should be added as extensions either to =
the RAR-style objects (by defining a type at that level) or as a =
separate top-level member.

For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D=
 query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.

To me, this remains much =
more understandable, extensible, and =
clean.

While this may be more understandable =
to a developer just porting an app OIDC that only wants OIDC =
results, but I think it is more complicated as soon as the developer =
wants other results, which is likely what prompted the developer to =
use GNAP instead of ODIC.

I think it is easier to understand if all the claims are in =
one container, and all the authorizations are in another =
container.

If =
a developer wants access to some resources, some claims, and an OpenID =
Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread =
across multiple containers. There are some claims in the "claims" =
container, and some "claims" in the "oidc_claims_query" container. And =
is the access token response in "oidc_claims_query" the same as an =
access token response in "resources"? It would seem simpler if they =
were, and if all the access tokens came back in the same =
container.

Per =
Aaron's post that you have referred to, the developer can get sme bare =
claims directly in the response in the "claims" object, an ID Token that =
has the same or different claims, and if they want, an access token that =
they can call a user_info endpoint to get the same, or different =
claims.

For =
example, an enterprise app client may want an ID Token with the email =
address, bare claims for the user's name and a URI to a profile photo, =
and an access token to query which groups a user belongs to.

We are still =
re-using the OIDC claims, but we are not mixing claims and =
authorizations.

/Dick


[1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
3D""=E1=90=A7

3D""=E1=90=A7


=

--Apple-Mail=_98012DF2-8214-4074-BD18-2760AEAFB9F9--


From nobody Thu Jul  9 08:50: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 88F433A0CCE for ; Thu,  9 Jul 2020 08:50: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 CLtDpijGJ6W1 for ; Thu,  9 Jul 2020 08:50:18 -0700 (PDT)
Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (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 0892D3A0CC7 for ; Thu,  9 Jul 2020 08:50:18 -0700 (PDT)
Received: by mail-oi1-x242.google.com with SMTP id r8so2254771oij.5 for ; Thu, 09 Jul 2020 08:50: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=3Nr5VonlMfgxy+n+jb5fBD7p8XVYgqgGOc2fva9WnmY=; b=OTCpLGzic8ovkfflnSOD+QXxmMtKibI8pn6LUIMBKO78BmJZjs0Cl7XT50QZsJyM2C pbVOV2Ub++WKlEWMlR7QIgstKizW7ZLqcSETL7X5IO/SuVjgsnSVKxbOjBQ+3gKLDZmk c+VEkq744eka/mzhiUIKq0Hv19Ne5KXHrqAmMDWRaRP2aqg1mCTfss1x5u/yssnNhgee o5etXgG0hU2Mh1z14R1/e6Szwo3vTduIH27MTQi5pbMLAjl+cSb/p+nuruU+jqAmgsuv eq1IaMxDzLyGCbrKtMj/ogTuC7yjdtx6XX6+h198zbT8EdzJOJnbYi960ybb9in/YIOY lKZA==
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=3Nr5VonlMfgxy+n+jb5fBD7p8XVYgqgGOc2fva9WnmY=; b=YuHnagl1z8Z7JN7Pq2rNwETrhzz7DZrXytf6NEU5Rn2kfHI4butCwhxEihTBHtWs6y +EGGHku5lK072ptPETAqHjqGff4fmRKwpnjF0/0Uz5jam3OZuvHZzDCKUl+bn7moBBVi Dv232Anb44HmGMjKqjAq1LTqmJTmZzJZYKTYt+ySG0y2NH/4VSeIUA0+OniGAkBJ5dbO UZU0jk1pmR5weda53pC123Q472eNNfezkipwRFDWq1JmK3+dPUHXxwrs6dKLXxWeTHXs J8EMcl84LWcy67bUylWjY2vkJ960m5AWP5pP9vyCd0aTQ6YNw9kXOkIP65R3Vx19oYBl lnlA==
X-Gm-Message-State: AOAM533BeW+bbk9Nruf84D7kZfNuIIRUciqyponUHUod6sehpSN7k+ZP FJhwhPNbvVZiZee1i2aCUZRM0O6pVory9svlRVQ=
X-Google-Smtp-Source: ABdhPJzJ7v9juZ/Jv2JkEQinlcf50xXmB2U9E7cWwmiYQok1l1XhaNOAYawXC8o0RGifJY4ygK3lzhkffxJEmIS1fLI=
X-Received: by 2002:aca:4905:: with SMTP id w5mr624038oia.172.1594309817128; Thu, 09 Jul 2020 08:50:17 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Tom Jones 
Date: Thu, 9 Jul 2020 08:50:02 -0700
Message-ID: 
To: David Pyke 
Cc: Denis , txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004fd8f605aa042e9f"
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element
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, 09 Jul 2020 15:50:21 -0000

--0000000000004fd8f605aa042e9f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

David: Kantara has been working on standardizing the health care model you
describe. Where clients are known, this model works. I would suggest that
the model requires federation of some sort to assess the parties to a
transaction, and so is fundamentally different from the more typical oauth
model where the client must be considered to be an adversary.

I doubt that a common protocol can be enabled for both models. But I am
open to hearing that both models can share message formats. That would be a
good start.

thx ..Tom (mobile)

On Thu, Jul 9, 2020, 8:25 AM David Pyke  wrote:

> This is frequently done in healthcare, with the User Consent Element
> holding a URI to a fetchable document or OID that outlines consent
> requirements or provisions.  If the URI points to a (I)ACP, it can be
> computable (XACML or other) consent that can be ingested automagically.
> On 2020-07-09 6:19 a.m., Denis wrote:
>
> This is a new thread.
>
> Preamble: This model is quite different from the XAuth model.
> In particular, a RO has no relationship with any AS and a Client does not
> need to be associated with any AS prior to any access to a RS.
>
> A key point of this model is that the user's consent is handled locally b=
y
> the Client and hence no AS nor RS is handling a man machine interface
> for the user consent. This allows to support locally the user consent for
> multiple ASs while keeping all ASs ignorant about the choices of the user
> made for accessing a particular RS.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *       +--------+                           +------------+        |
> User  |                           |  Resource  |        |
> |                           | Owner (RO) |        +--------+
>                   +------------+            |
> \                              |            |
> \                             |            |
> \                            |            |
> \                           |     +-----------+     +---------------+
> +------------+     |           |---->| Authorization |     |            |
>     |           | (2) |  Server (AS)  |     |            |     |
> |<----|               |     |            |     |  Client   |
> +---------------+     |            |     |
> |-------------------------->|  Resource  |     |   User    |
> (1)             |   Server   |     |  Consent
> |<--------------------------|    (RS)    |     |  element
> |                           |            |     |
> |-------------------------->|            |------>     |
> |           (3)             |            |  (4)     |
> |<--------------------------|            |<------
> +-----------+                           +------------+ *
> The flow of operations is as follows:
>
> The Client (which may have been previously authenticated using FIDO)
> contacts the RS and after some dialogue with the RS selects an operation
> that it wants to perform on the RS (1a). Note that it may also indicate
> directly the operation that it wants to perform on the RS without any pri=
or
> dialogue.
> In return (1b), the RS informs the Client about which attributes are
> needed by the RS for performing the requested operation and from which
> Attributes Servers
> they may be obtained.
>
> This information is specifically marked to indicate that it shall be
> handled by the "User Consent element" from the Client.
> The presentation of that information is up to the man machine interface
> supported by the "User Consent element" from the Client.
>
> The user can see which attributes are requested by the RS for performing
> the requested operation and, if it consents, the Client contacts one or
> more
> appropriate Authorization Servers (2a). The user consent is hence capture=
d
> locally by the Client (i.e. there is no dialogue with any AS nor any RS).
>
> When the Client got the access tokens from these authorization servers
> (2b), it sends all of them in a single request to the RS (3a).
>
> End of the story for a simple access
>
>
> Start of a subsequent story for a delegation case
>
> Let us now suppose that the RS is unable to fulfil the request by its own
> and that it needs to contact another RS. RS1 contacts RS2 (4a) and
> indicates the operation
> that it wants to perform on RS2 (that operation may not be the same as th=
e
> original operation). In return (4b), RS2 informs RS1 about which attribut=
es
> are needed
> by RS2 for performing the requested operation and from which Attributes
> Servers they may be obtained. RS1 forwards that information to the Client=
.
>
> This information is marked to indicate that it shall be handled by the
> "User Consent element" from the Client. The presentation of that
> information is up to the man machine
> interface from the Client. The user can see which attributes are requeste=
d
> by RS2 for performing the new requested operation and, if it consents, th=
e
> Client contacts one or more
> appropriate Authorization Servers. The user consent is hence captured
> locally by the "User Consent element" from the Client. (i.e. there is no
> dialogue with any AS, nor RS1, nor RS2).
>
> When the Client got the access token(s) from the authorization server(s),
> it sends all of them in a single request to RS1. RS1 then forwards the
> additional access token(s) to RS2.
>
>
> Some observations:
>
> The user nor the Client are linked with any particular AS. A user may use
> today an AS of the Bank of America and may change tomorrow to the Bank of
> Missouri.
> As soon as he will be registered with the Bank of Missouri, he will be
> able to get access tokens from the AS of the Bank of Missouri. The AS of
> Bank of America
> has not been able to know where its access tokens have been used. This
> will be the same for AS of the Bank of Missouri. There is no need for any
> direct dialogue
> between any AS and any RS at the time a client is making an access. There
> is no need for any RO to contact any AS.
>
> This model has been constructed following a "Privacy by Design" approach.
>
> Denis
>
> --
>
> *David Pyke*
>
> Manager, Strategic Consulting
>
>
> -------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------
>
> [image: Logo] 
>
> [image: LinkedIn icon] =
 [image:
> Twitter icon]  [image:
> Youtbue icon] 
>
> Office: +1 212 877 3307 x5001
>
> * david.pyke@readycomputing.com *
>
> * www.readycomputing.com *
>
> 150 Beekman Street, Floor 3, New York, NY 10038
>
> The information in this e-mail communication together with any attachment=
s
> is intended only for the person or entity to which it is addressed and ma=
y
> contain confidential and/or privileged material. If you are not the
> intended recipient of this communication, please notify us immediately. A=
ny
> views expressed in this communication are those of the sender, unless
> otherwise specifically stated. Ready Computing does not represent, warran=
t
> or guarantee that the integrity of this communication has been maintained
> or the communication is free of errors, virus or interference.
>
> This is not a secure transmission. The information contained in this
> transmission is highly prohibited from containing privileged and
> confidential information, including patient information protected by
> federal and state privacy laws. It is intended only for the use of the
> person(s) named above. If you are not the intended recipient, you are
> hereby notified that any review, dissemination, distribution, or
> duplication of this communication is strictly prohibited. If you are not
> the intended recipient, please contact the sender by reply email and
> destroy all copies of the original message. --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--0000000000004fd8f605aa042e9f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


David: Kantara has been working on standardizing the heal=
th care model you describe. Where clients are known, this model works. I wo=
uld suggest that the model requires federation of some sort to assess the p=
arties to a transaction, and so is fundamentally different from the more ty=
pical oauth model where the client must be considered to be an adversary.
I doubt that a common protocol =
can be enabled for both models. But I am open to hearing that both models c=
an share message formats. That would be a good start.

thx ..Tom (mobile)
=

On Thu=
, Jul 9, 2020, 8:25 AM David Pyke <david.pyke=3D40readycomputing.com@dmarc.ietf.org> =
wrote:

 =20
   =20
 =20
  

    
This is frequently done in healthcare, with the
        User Consent Element holding a URI to a fetchable document or
        OID that outlines consent requirements or provisions.=C2=A0 If the
        URI points to a (I)ACP, it can be computable (XACML or other)
        consent that can be ingested automagically.

    

    
On 2020-07-09 6:19 a.m., Denis wrote:

    

    

     =20
      
This is a new thread.

          

          Preamble: This model is quite different from the XAuth model.
          

          In particular, a RO has no relationship with any AS and a
          Client does not need to be associated with any AS prior to any
          access to a RS.

          

          A key point of this model is that the user's consent is
          handled locally by the Client and hence no AS nor RS is
          handling a man machine interface 

          for the user consent. This allows to support locally the user
          consent for multiple ASs while keeping all ASs ignorant about
          the choices of the user 

          made for accessing a particular 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=C2=A0 +------------+

            =C2=A0=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 R=
esource=C2=A0 |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
            Owner (RO) |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0+------------+

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 |

            =C2=A0=C2=A0=C2=A0 +-----------+=C2=A0 =C2=A0=C2=A0=C2=A0+---------------+=C2=A0=C2=A0=C2=A0=
=C2=A0 +------------+

            =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---->|
            Authorization |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
            =C2=A0=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) |=C2=A0 Serv=
er (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=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0 |

            =C2=A0=C2=A0=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=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 (1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 S=
erver=C2=A0=C2=A0 |

            =C2=A0=C2=A0=C2=A0 |=C2=A0 Consent=C2=A0 |<--------------------------|=C2=A0=C2=A0=C2=A0 <=
/span>(RS)=C2=A0=C2=A0=C2=A0 |

            =C2=A0=C2=A0=C2=A0 |=C2=A0 element=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

            =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |-------------------------->=
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>|------>

            =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=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 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<--------------------------=
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>|<------

            =C2=A0=C2=A0=C2=A0 +-----------+=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 flow of operations is as follows:

          

          The Client (which may have been previously authenticated using
          FIDO) contacts the RS and after some dialogue with the RS
          selects an operation 

          that it wants to perform on the RS (1a). Note that it may also
          indicate directly the operation that it wants to perform on
          the RS without any prior dialogue. 

          In return (1b), the RS informs the Client about which
          attributes are needed by the RS for performing the requested
          operation and from which Attributes Servers 

          they may be obtained. 

          

          This information is specifically marked to indicate that it
          shall be handled by the "User Consent element" from the
          Client. 

          The presentation of that information is up to the man machine
          interface supported by the "User Consent element" from =
the
          Client. 

          

          The user can see which attributes are requested by the RS for
          performing the requested operation and, if it consents, the
          Client contacts one or more 

          appropriate Authorization Servers (2a). The user consent is
          hence captured locally by the Client (i.e. there is no
          dialogue with any AS nor any RS).

          

          When the Client got the access tokens from these authorization
          servers (2b), it sends all of them in a single request to the
          RS (3a).

          

          End of the story for a simple access

      
 

          Start of a subsequent story for a delegation case

          

          Let us now suppose that the RS is unable to fulfil the request
          by its own and that it needs to contact another RS. RS1
          contacts RS2 (4a=
) and indicates the operation 

          that it wants to perform on RS2 (that operation may not be the
          same as the original operation). In return (4b), RS2 informs
          RS1 about which attributes are needed 

          by RS2 for performing the requested operation and from which
          Attributes Servers they may be obtained. RS1 forwards that
          information to the Client. 

          

          This information is marked to indicate that it shall be
          handled by the "User Consent element" from the Client. =
The
          presentation of that information is up to the man machine 

          interface from the Client. The user can see which attributes
          are requested by RS2 for performing the new requested
          operation and, if it consents, the Client contacts one or more
          

          appropriate Authorization Servers. The user consent is hence
          captured locally by the "User Consent element" from the
          Client. (i.e. there is no dialogue with any AS, nor RS1, nor
          RS2). 

          

          When the Client got the access token(s) from the authorization
          server(s), it sends all of them in a single request to RS1.
          RS1 then forwards the additional access token(s) to RS2.

          

          

          Some observations: 

          

          The user nor the Client are linked with any particular AS. A
          user may use today an AS of the Bank of America and may change
          tomorrow to the Bank of Missouri. 

          As soon as he will be registered with the Bank of Missouri, he
          will be able to get access tokens from the AS of the Bank of
          Missouri. The AS of Bank of America 

          has not been able to know where its access tokens have been
          used. This will be the same for AS of the Bank of Missouri.
          There is no need for any direct dialogue 

          between any AS and any RS at the time a client is making an
          access. There is no need for any RO to contact any AS.

      
This model has been constructed following a
          "Privacy by Design" approach.

      
Denis

        

      

      

    

    
-- 

     =20
     =20
     =20
     =20
      

        

          
            

              
                

                  David Pyke
              

            

            

              
                

                  Manager,
                    Strategic Consulting

              		
            

            

              
                
 ------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
---------------------------------------------------------------------------=
----------------------------------------------

              		
            

            

              
                

                  3D"Logo"

                

                  3D"LinkedIn 3D"T= 

              		
              
                
Offi=
ce:
                    +1 212 877 3307 x5001

                

                  
                    

                      
                        

                          
                                david.pyke@readycomputing.com

                        

                          
                                www.readycomputing.com

                      		
                    

                    

                      
                        
150
                            Beekman Street, Floor 3, New York, NY 10038

                      		
                    

                    

                      

                      		
                    

                  
                

              		
            

            

              
                

                  The
                    information in this e-mail communication together
                    with any attachments is intended only for the person
                    or entity to which it is addressed and may contain
                    confidential and/or privileged material. If you are
                    not the intended recipient of this communication,
                    please notify us immediately. Any views expressed in
                    this communication are those of the sender, unless
                    otherwise specifically stated. Ready Computing does
                    not represent, warrant or guarantee that the
                    integrity of this communication has been maintained
                    or the communication is free of errors, virus or
                    interference.

              		
            

          
        

      

    

  





This is not a secure transmission. The information contained in this=20
transmission is highly prohibited from containing privileged and=20
confidential information, including patient information protected by=20
federal and state privacy laws. It is intended only for the use of the=20
person(s) named above. If you are not the intended recipient, you are=20
hereby notified that any review, dissemination, distribution, or=20
duplication of this communication is strictly prohibited. If you are not
 the intended recipient, please contact the sender by reply email and=20
destroy all copies of the original message.
                       -- 

Txauth mailing list

Txa=
uth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth<=
/a>




--0000000000004fd8f605aa042e9f--


From nobody Thu Jul  9 10:58: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 B688F3A0DE1 for ; Thu,  9 Jul 2020 10:58:44 -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 BX_Y5Y9nk_bm for ; Thu,  9 Jul 2020 10:58:42 -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 BA7D73A0D9D for ; Thu,  9 Jul 2020 10:58:41 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id t74so1689733lff.2 for ; Thu, 09 Jul 2020 10:58: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=7xGdskrBcWKlnQ6tSP2oAE5eflZjIhBvvQCxTnw9kRw=; b=msBHplb3W6eSbDdz5oQXYiUkO3mQIuHM6bn96tZCwnhRYkFwpjV4CcJz3hrNdevAvA d2VsdbUZ4HQCXLnNX3Ip0gqSxkkZGIhtEXTEC2+GNpo1VvkDz9Oh0QgdVj7TPekok0oo T9nOuoZE8IYkJM3Ur8X+9p8ZBRcSQK3qBXtGEYxD0wLd7oDMdYS9OdodykKsDsosoHoD skceF8NzMnBzoikVPEFvEWqOkoSJQlvrsNpfvOheznl+BuY+vg611hMKJ7/QBNcUr+In 19aNROKonYGiQxO95TBfVWOGvgYa+uoCHYwGKCDu9bVKBdT9NkQQRgwtZachqwH64gWQ SdZA==
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=7xGdskrBcWKlnQ6tSP2oAE5eflZjIhBvvQCxTnw9kRw=; b=kUtMJ1m719cmkpw8ksgjoijYNu917Q42TcNcIlM7UURgILB6CcfxlUlW76rpO4ygUV 5w2WRGPIJ34n6e9VxOVoN0n0/kmPIBV7LidTB4GafwThYxkB7EdQecm/0MKspJJoKjoX aXVJDyfoIaUpDaMrgPFmSsPenQBu/utAmfeg7ig9f7sYm6bbIJkPLDYw9SygBvg4nSki O8vqP0QDPc9BW01XmkF4uZ3wn9a6UbmA6NpkMI2DlyaFGtqp83fTYpw7Ks+OBf4ghahC btisdbbQsP8ZINPvARfvMKcZElaJ0ESjRgiQKJRPq5hd0MzXZILe2SBukcsIYwuorco+ /6Jg==
X-Gm-Message-State: AOAM533qACEmfrvystwBvBL9kS7agGNINaiaP5+dZU9syjoTVb6JV6Av 2CaiVCDdr9EWrBIz1ciRFWDTdqXL6WCtuzP+XNM=
X-Google-Smtp-Source: ABdhPJyL9+BoLc7/SMCC7BwoPGm5Yx0QmHERW1pVBA0B66cFhQwcTNaIj0xi2ELy4g/Wb8mtAhNLIysKfowtDEv5PoU=
X-Received: by 2002:a19:c8a:: with SMTP id 132mr40546922lfm.23.1594317519393;  Thu, 09 Jul 2020 10:58:39 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 9 Jul 2020 10:58:00 -0700
Message-ID: 
To: Denis 
Cc: "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000006718a105aa05f9a6"
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 09 Jul 2020 17:58:49 -0000

--0000000000006718a105aa05f9a6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis, thanks for sharing the model. I don't fully understand what is
going on, questions inserted:

FWIW: having paragraphs start with the step number (1), (2) etc. would make
it easier to map between the description and the diagram.

On Thu, Jul 9, 2020 at 3:26 AM Denis  wrote:

> This is a new thread.
>
> Preamble: This model is quite different from the XAuth model.
> In particular, a RO has no relationship with any AS and a Client does not
> need to be associated with any AS prior to any access to a RS.
>
> A key point of this model is that the user's consent is handled locally b=
y
> the Client and hence no AS nor RS is handling a man machine interface
> for the user consent. This allows to support locally the user consent for
> multiple ASs while keeping all ASs ignorant about the choices of the user
> made for accessing a particular RS.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *       +--------+                           +------------+        |
> User  |                           |  Resource  |        |
> |                           | Owner (RO) |        +--------+
>                   +------------+            |
> \                              |            |
> \                             |            |
> \                            |            |
> \                           |     +-----------+     +---------------+
> +------------+     |           |---->| Authorization |     |            |
>     |           | (2) |  Server (AS)  |     |            |     |
> |<----|               |     |            |     |  Client   |
> +---------------+     |            |     |
> |-------------------------->|  Resource  |     |   User    |
> (1)             |   Server   |     |  Consent
> |<--------------------------|    (RS)    |     |  element
> |                           |            |     |
> |-------------------------->|            |------>     |
> |           (3)             |            |  (4)     |
> |<--------------------------|            |<------
> +-----------+                           +------------+ *
> The flow of operations is as follows:
>
> The Client (which may have been previously authenticated using FIDO)
>
Which party has the client authenticated to? The client authenticating with
FIDO is confusing to me. FIDO is usually how a user authenticates.


> contacts the RS and after some dialogue with the RS selects an operation
>
How does the client know which RS to contact?


> that it wants to perform on the RS (1a). Note that it may also indicate
> directly the operation that it wants to perform on the RS without any pri=
or
> dialogue.
> In return (1b), the RS informs the Client about which attributes are
> needed by the RS for performing the requested operation and from which
> Attributes Servers
> they may be obtained.
>

(1a) and (1b) are not labeled. There is only (1)

>
> This information is specifically marked to indicate that it shall be
> handled by the "User Consent element" from the Client.
>
Why? What is the significance of this? Which information is marked?


> The presentation of that information is up to the man machine interface
> supported by the "User Consent element" from the Client.
>

Which information?

>
> The user can see which attributes are requested by the RS for performing
> the requested operation and, if it consents, the Client contacts one or
> more
> appropriate Authorization Servers (2a).
>
How does the client know which AS(s) to contact?


> The user consent is hence captured locally by the Client (i.e. there is n=
o
> dialogue with any AS nor any RS).
>

No dialogue with who? The client is calling the AS is it not?

>
> When the Client got the access tokens from these authorization servers
> (2b), it sends all of them in a single request to the RS (3a).
>

So the RS must trust the AS that issued the tokens. And the AS must trust
the Client to have gathered consent. And the AS must have a relationship
with the user. It is unclear what role the RO is playing in this though.
The RO and RS look to be the same entity from all the other parties.

>From my current understanding, at a high level, this looks like it is
supported by GNAP with the addition of the discovery step (1). There have
been a number of proposals for doing this discovery, and perhaps now there
are enough use cases to look at standardizing something.  No interaction is
needed between the AS and the  User as the Client is providing enough
"information" in the user object of the Grant Request to satisfy the AS
releasing the access tokens.

Perhaps as I understand the model in more detail I will understand what is
missing from GNAP (besides the discovery step).

/Dick

(I've skipped reviewing the delegation use case below until I understand
the simple use case)


> End of the story for a simple access
>
>
> Start of a subsequent story for a delegation case
>
> Let us now suppose that the RS is unable to fulfil the request by its own
> and that it needs to contact another RS. RS1 contacts RS2 (4a) and
> indicates the operation
> that it wants to perform on RS2 (that operation may not be the same as th=
e
> original operation). In return (4b), RS2 informs RS1 about which attribut=
es
> are needed
> by RS2 for performing the requested operation and from which Attributes
> Servers they may be obtained. RS1 forwards that information to the Client=
.
>
> This information is marked to indicate that it shall be handled by the
> "User Consent element" from the Client. The presentation of that
> information is up to the man machine
> interface from the Client. The user can see which attributes are requeste=
d
> by RS2 for performing the new requested operation and, if it consents, th=
e
> Client contacts one or more
> appropriate Authorization Servers. The user consent is hence captured
> locally by the "User Consent element" from the Client. (i.e. there is no
> dialogue with any AS, nor RS1, nor RS2).
>
> When the Client got the access token(s) from the authorization server(s),
> it sends all of them in a single request to RS1. RS1 then forwards the
> additional access token(s) to RS2.
>
>
> Some observations:
>
> The user nor the Client are linked with any particular AS. A user may use
> today an AS of the Bank of America and may change tomorrow to the Bank of
> Missouri.
> As soon as he will be registered with the Bank of Missouri, he will be
> able to get access tokens from the AS of the Bank of Missouri. The AS of
> Bank of America
> has not been able to know where its access tokens have been used. This
> will be the same for AS of the Bank of Missouri. There is no need for any
> direct dialogue
> between any AS and any RS at the time a client is making an access. There
> is no need for any RO to contact any AS.
>
> This model has been constructed following a "Privacy by Design" approach.
> Denis
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
=E1=90=A7

--0000000000006718a105aa05f9a6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis, thanks for sharing the model. I=
 don't fully understand what is going on, questions inserted:

<=
/div>
FWIW: having paragraphs start with the step number (1), (2) etc. =
would make it easier to map between the description and the diagram.
<=
/div>
O=
n Thu, Jul 9, 2020 at 3:26 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    

      
This is a new thread.

          

          Preamble: This model is quite different from the XAuth model.
          

          In particular, a RO has no relationship with any AS and a
          Client does not need to be associated with any AS prior to any
          access to a RS.

          

          A key point of this model is that the user's consent is
          handled locally by the Client and hence no AS nor RS is
          handling a man machine interface 

          for the user consent. This allows to support locally the user
          consent for multiple ASs while keeping all ASs ignorant about
          the choices of the user 

          made for accessing a particular 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=C2=A0 +------------+

              =C2=A0=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0 |

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
              Owner (RO) |

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+<=
span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0+------------+

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
              |

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |

              =C2=A0=C2=A0=C2=A0 +-----------+=C2=A0 =C2=A0=C2=A0=C2=A0+---------------+=C2=A0=C2=A0=C2=
=A0=C2=A0 +------------+

              =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---->|
              Authorization |=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=


              =C2=A0=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) |=C2=A0 S=
erver (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=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0 |

              =C2=A0=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 Resource=C2=A0 |

              =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 Us=
er=C2=A0=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)=C2=A0=C2=A0=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=C2=A0 |=C2=A0 Consent<=
span>=C2=A0 |<--------------------------|=C2=A0=C2=A0=C2=A0=
 (RS)=C2=A0=C2=A0=C2=A0 |

              =C2=A0=C2=A0=C2=A0 |=C2=A0 element<=
span>=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

              =C2=A0=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 (3)=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=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 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<-----------------------=
---|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 |<------

              =C2=A0=C2=A0=C2=A0 +-----------+=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=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 flow of operations is as follows:

          

          The Client (which may have been previously authenticated using
          FIDO) 
Which party has th=
e client authenticated to? The client authenticating with FIDO is confusing=
 to me. FIDO is usually how a user authenticates.
=C2=A0
contacts the RS and after some dialogue with the RS
          selects an operation 
How does the client know which RS to contact?
=C2=A0

          that it wants to perform on the RS (1a). Note that it may also
          indicate directly the operation that it wants to perform on
          the RS without any prior dialogue. 

          In return (1b), the RS informs the Client about which
          attributes are needed by the RS for performing the requested
          operation and from which Attributes Servers 

          they may be obtained. 

(1a) and (1b) are not labeled. There is only (1)=C2=A0

          

          This information is specifically marked to indicate that it
          shall be handled by the "User Consent element" from the
          Client. 
Why? What is=
 the significance of this? Which information is marked?
=C2=A0

          The presentation of that information is up to the man machine
          interface supported by the "User Consent element" from =
the
          Client. 

Which information?=C2=A0

          

          The user can see which attributes are requested by the RS for
          performing the requested operation and, if it consents, the
          Client contacts one or more 

          appropriate Authorization Servers (2a). 
How does the client know which AS(s) to contact?
=
=C2=A0
=
The user consent is
          hence captured locally by the Client (i.e. there is no
          dialogue with any AS nor any RS).

No dialogue with who? The client is calling the=
 AS is it not?=C2=A0

          

          When the Client got the access tokens from these authorization
          servers (2b), it sends all of them in a single request to the
          RS (3a).

So the RS must trust the AS that issued the tokens. And the AS must trus=
t the Client to have gathered consent. And the AS must have a relationship =
with the user. It is unclear what role the RO is playing in this though. Th=
e RO and RS look to be the same entity from all the other parties.

From my current understanding, at a high level, this looks=
 like it is supported by GNAP with the addition of the discovery step (1). =
There have been a number of proposals for doing this discovery, and perhaps=
 now there are enough use cases to look at standardizing something.=C2=A0 N=
o interaction=C2=A0is needed between the AS and the=C2=A0 User as the Clien=
t is providing enough "information" in the user object of the Gra=
nt Request to satisfy the AS releasing the access tokens.=C2=A0
<=
br>
Perhaps as I understand the model in more detail I will under=
stand what is missing from GNAP (besides the discovery step).
/Dick

(I've skipped reviewing the =
delegation use case below until I understand the simple use case)

<=
span lang=3D"EN-US">
          

          End of the story for a simple access

      
 

          Start of a subsequent story for a delegation case

          

          Let us now suppose that the RS is unable to fulfil the request
          by its own and that it needs to contact another RS. RS1
          contacts RS2 (4a=
) and indicates the operation 

          that it wants to perform on RS2 (that operation may not be the
          same as the original operation). In return (4b), RS2 informs
          RS1 about which attributes are needed 

          by RS2 for performing the requested operation and from which
          Attributes Servers they may be obtained. RS1 forwards that
          information to the Client. 

          

          This information is marked to indicate that it shall be
          handled by the "User Consent element" from the Client. =
The
          presentation of that information is up to the man machine 

          interface from the Client. The user can see which attributes
          are requested by RS2 for performing the new requested
          operation and, if it consents, the Client contacts one or more
          

          appropriate Authorization Servers. The user consent is hence
          captured locally by the "User Consent element" from the
          Client. (i.e. there is no dialogue with any AS, nor RS1, nor
          RS2). 

          

          When the Client got the access token(s) from the authorization
          server(s), it sends all of them in a single request to RS1.
          RS1 then forwards the additional access token(s) to RS2.

          

          

          Some observations: 

          

          The user nor the Client are linked with any particular AS. A
          user may use today an AS of the Bank of America and may change
          tomorrow to the Bank of Missouri. 

          As soon as he will be registered with the Bank of Missouri, he
          will be able to get access tokens from the AS of the Bank of
          Missouri. The AS of Bank of America 

          has not been able to know where its access tokens have been
          used. This will be the same for AS of the Bank of Missouri.
          There is no need for any direct dialogue 

          between any AS and any RS at the time a client is making an
          access. There is no need for any RO to contact any AS.

      
This model has been constructed following a
          "Privacy by Design" approach.

      Denis

    

  


-- 

Txauth mailing list

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


3D""=
=E1=90=A7


--0000000000006718a105aa05f9a6--


From nobody Thu Jul  9 11:33:32 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 706513A0DAA for ; Thu,  9 Jul 2020 11:33:30 -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 dCSt5pKBz3A6 for ; Thu,  9 Jul 2020 11:33:26 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 2C1E93A0DAC for ; Thu,  9 Jul 2020 11:33:26 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id t9so1743874lfl.5 for ; Thu, 09 Jul 2020 11:33: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=bhAvsyWjEKKquzbsXYDp5mDbAAe27EmjNAWGi6MmhrE=; b=vDk8jGxen2inYky1O2gUPJw8aCNniuZ1GqOZwvlhJB9cp/+ra/nAK0m6bVHdhhf6AG a6tvV7aEGu0Cx4ygnxRG3D7wn68z87xW14IJqHrqKqG1HhRwpA+00c8WfkM+Mt4506+K U7OIfBaFQTXbt19JMe2kNjRtLDtpyKU34apcDA2LtZekPI97nSQXnNUNeLErT9RnRv4H cj0pxdvj3y3Q9i6S6CVYXmn+7C884sbnPvr5g5xXo4z4zz+9KnfRUWYSLZS6ziCuwqME 6M/B9c04W0z3O1Af68pVRJO5LYC1WWciJ4067MnQHNEK+qW1JgBcdhQSgHKZL0rdaCb/ V0Mw==
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=bhAvsyWjEKKquzbsXYDp5mDbAAe27EmjNAWGi6MmhrE=; b=AnHVvlGWMFxusq1v+qDwbRxgbb5+EtqJDoq8o1vyG+2d6QBV3aol+mEfLWCCkPrHiM b73UL4z3+dDNehZN6Skq/HQYEWloD7NjXNi7vnUMTEgQFRgMl7J/demKhGahdFG5Irjv 1UZaHNWSArreUi2ZBbqFyDUs5uRSWw2XMhWA/2LKqkBZXv4qFlTZR1qVBYoeQ0qkLpQm 7JGQ1Sbgu9anOjsvLqXIdKXKt4K9CLCqstC+EDu7Vbp1szIfQmfANACSUERnBb0Vt+WW U2CWX1KP+cilPb8W9XXadGUR61jRdfu812SZiokLeZ6gWtgwpa8FimUSJcyD7qS9iwwM kc+A==
X-Gm-Message-State: AOAM530TakUT7KUwLRR1lAUNsiN7IX/0MVgmlTa7ZkH0PMUTixdJ2wTu a2Se2/XfC+KTR6yQUccmtGdc4NlBCZLlZX1ugno=
X-Google-Smtp-Source: ABdhPJzoVDilGg1JEucjN3XOcD9GK/C0zmMZMU5NiTpzXuFlvtW9iFyP18qyA10r7F6yoNc9s8YoWP3iW3fDNW9MAbE=
X-Received: by 2002:a19:4143:: with SMTP id o64mr40348459lfa.157.1594319604127;  Thu, 09 Jul 2020 11:33:24 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>   
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 9 Jul 2020 11:32:47 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a99ddd05aa06754a"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 09 Jul 2020 18:33:31 -0000

--000000000000a99ddd05aa06754a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Looks like you missed the point of my code example, as your response is
focussed on the aspects I had in comments, so let me clarify.

This line (which is determining the type of the item in the array):

if (typeof item =3D=3D=3D string')


is implicitly stating that the item is an oauth scope. Whereas it is
explicit in this statement

if (authorizations.type =3D=3D=3D 'oauth_scope')


which I think it easier to understand what is happening (in my opinion of
course).

XYZ has types, they are just implicit. RAR has explicit types, and that
does not look to be holding back RAR. I don't understand why you think
having explicit types will hold us back. Do you want to let the string and
object be anything the AS and RS decide they could mean? That would make
GNAP more of a framework than a protocol, and a key aspect of the request
would be undefined.

My thoughts have not shifted on "types" in interactions. I just changed the
name to 'mode'. I did shift my thinking that a negotiation of interaction
modes is useful, and added that.

We still have an unfinished discussion there. When you have a chance, would
you respond to that thread?

/Dick

On Thu, Jul 9, 2020 at 8:39 AM Justin Richer  wrote:

> Declarations of which code is =E2=80=9Ceasier to understand=E2=80=9D are =
going to be
> subjective, and I don=E2=80=99t agree with your conclusions even with you=
r
> examples. Even so, I don=E2=80=99t think that the examples you give are a=
 good
> comparison. While it is of course possible to implement things like you
> have below, I think it=E2=80=99s indicative of thinking of things in term=
s of a
> =E2=80=9Cresource request type=E2=80=9D. What I=E2=80=99ve been trying to=
 argue is that there
> shouldn=E2=80=99t be a =E2=80=9Ctype=E2=80=9D, that there should just be =
slightly different ways to
> do a resource request. So the code is more like:
>
> resourcesRequested =3D requests.map( item =3D> {
>    if (typeof item =3D=3D =E2=80=98object=E2=80=99) {
>       return new RarStyleResourceRequest(item);
>    } else if (typeof item =3D=3D =E2=80=9Cstring=E2=80=9D) {
>      return new StringStyleResourceRequest(item);
>    }
> });
> processResources(resourcesRequested);
>
>
> Each of these =E2=80=9C*ResourceRequest=E2=80=9D objects would be somethi=
ng that the AS
> can use to decide what to put into the access token. Although you=E2=80=
=99d
> probably put that complexity into a factory constructor or something
> instead of a map function, this shows the kind of dispatch you can do bas=
ed
> on type if you=E2=80=99re doing it by hand. You collect everything in the=
 array,
> and turn it into an object that represents =E2=80=9Ca request for a resou=
rce that
> gets tied to an access token=E2=80=9D. And then you process the request b=
ased on
> the collection of resource requests. Each string-based request points to
> some set of policies, as does each object-based request. You can even
> imagine that instead of creating a separate string-based request, you use
> that string to look up a policy in a policy engine to be applied later.
>
> The AS then has to figure out, as it always does, what to do with this
> collection. And if you want to do an early escape on object style request=
s,
> you could just throw an error when you detect that. Or, you just ignore
> that part of the request. In fact, here=E2=80=99s the code I wrote that h=
andles it
> exactly that way, while processing the JSON by hand in Java on a legacy
> OAuth 2 server:
>
>
> JsonArray resources =3D json.get("resources").getAsJsonArray();
> Set scopes =3D StreamSupport.stream(resources.spliterator(), fals=
e)
> .filter( e -> e.isJsonPrimitive() ) // filter out anything that's not a
> handle
> .map( e -> e.getAsString() )
> .collect(Collectors.toSet());
> tx.setScope(scopes);
>
>
>
> Furthermore, your XAuth example doesn=E2=80=99t go to the same depth as t=
he XYZ
> example, which leads to a false comparison. In your =E2=80=9Cprocess scop=
e=E2=80=9D you
> would need to parse the =E2=80=9Cscope=E2=80=9D string to split on spaces=
, and then have
> another loop to process each scope. For the =E2=80=9Cprocess details=E2=
=80=9D you=E2=80=99d need to
> iterate over the array at the root of a RAR-style request and process eac=
h
> piece. In the XYZ code, you=E2=80=99ve got all of that already. If you=E2=
=80=99re going to
> compare the complexity of code, they should at least be shown to the same
> point of the process.
>
> On top of that, the fall-through case statement below is really limiting.
> What if the scope processing or RAR objects processing gets combined with
> something else? This kind of premature optimization is not something we
> want to encourage developers to do.
>
> But ultimately, I think the disconnect is down to thinking about this in
> terms of an explicit =E2=80=9Ctype=E2=80=9D, much the way XAuth used to d=
o with the
> interactions. I=E2=80=99m glad that your thoughts have shifted in that sp=
ace, and I
> think you should strongly consider the same set of arguments here. A lot =
of
> the promise of GNAP is getting away from this type-field style design, li=
ke
> getting away from OAuth 2=E2=80=99s =E2=80=9Cgrant_type=E2=80=9D approach=
 and into something that=E2=80=99s
> focused on interaction and client models instead. This newer model allows
> for better flexibility, better consistency, and better clarity throughout=
.
> It=E2=80=99s no longer =E2=80=9Cif I see this flag then I go down this se=
parate code path
> and nothing else=E2=80=9D, it=E2=80=99s now =E2=80=9Cif I see this item, =
I go down this code path
> and then process the next item too=E2=80=9D. There=E2=80=99s power in the=
 combinations.
>
>  =E2=80=94 Justin
>
> On Jul 8, 2020, at 9:31 PM, Dick Hardt  wrote:
>
> I had intended to provide a code sample comparing XYZ request type with
> XAuth request type
>
> Let's say an AS only supports OAuth scopes (does not support RAR). Here i=
s
> JS code to check:
>
> //XYZ code
>
> var oauth_scope =3D true;
> requests.forEach( item =3D> {
>     if (typeof item =3D=3D=3D "object")
>         oauth_scope =3D false;
> });
> if (!'oauth_scope') {
>     // return error
> }
>
> // XAuth code
>
> if ('oauth_scope' !=3D authorizations.type) {
>    // return error
> }
>
>
> Here is some JS code that for an AS that supports OAuth scopes, RAR, and
> OIDC requests:
>
> // XYZ
>
> if (request) {
>     requests.forEach( item =3D> {
>         if (typeof item =3D=3D=3D "object") {
>             // process a RAR item
>         } else if(typeof item =3D=3D=3D 'string') {
>             // process a scope item
>         } else {
>             // throw an error
>         }
>     })
>    // process the whole request
> }
> if (oidc_claims_query) {
>     // process oidc request
> }
>
> //XAuth
>
> if (authorizations) {
>     switch (authorizations?.type) {
>         case 'oauth_rar':
>             // process authorizations.details - RAR
>         case 'oauth_scope':
>             // process authorizations.scope
>             // process the whole request
>             break;
>         case 'oidc':
>             // process OIDC claims
>             break;
>         default:
>             // error for unknown type
>     }
> }
>
>
> Understanding what the code is doing looks much clearer in XAuth to me.
>
> =E1=90=A7
>
> On Wed, Jul 8, 2020 at 3:55 PM Dick Hardt  wrote:
>
>> Hey Justin,
>>
>> Just because we are using OIDC claims, does not mean we need to mimic th=
e
>> OIDC request and response.
>> I was envisioning a grant request could look as the following (using
>> XAuth syntax):
>>
>> {
>>     "authorizations": {
>>         "type":"oidc",
>>         "claims": ["name", "picture"]
>>     },
>>     "claims":{
>>         "oidc": {
>>             "id_token" : {
>>                 "email"          : { "essential" : true },
>>                 "email_verified" : { "essential" : true }
>>             },
>>             "userinfo" : {
>>                 "name"           : { "essential" : true },
>>                 "picture"        : null
>>             }
>>         }
>>     }
>> }
>>
>> Of course a developer could choose to only ask for a subset of this.
>>
>> Note the new authorization type of "oidc", that takes "claims" rather
>> than "scope".
>>
>> This keeps all the authorizations and claims in their respective request
>> and response containers.
>>
>> We had a thread months ago on the OIDC two stage model, and I still fail
>> to see why forcing that has any advantage.
>>
>> /Dick
>>
>>
>> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer  wrote:
>>
>>> I=E2=80=99m glad that we can agree that there are a number of things in=
 legacy
>>> protocols that are unfortunate side effects of the circumstances in whi=
ch
>>> they were built. Space-separated scope strings, for instance, would fal=
l in
>>> that category, as I=E2=80=99ve previously explained.
>>>
>>> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request alr=
eady mixes user
>>> claims (returned in an API) and authorization (to fetch user claims fro=
m an
>>> API), so that ship has sailed if you=E2=80=99re using it. It doesn=E2=
=80=99t make sense to
>>> have it under a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorizations=E2=
=80=9D request, since it=E2=80=99s a query
>>> language that affects both. Maybe you=E2=80=99d call this another =E2=
=80=9Cunfortunate
>>> design=E2=80=9D, but the context was about re-using an externally-defin=
ed query
>>> language that was not made for GNAP.
>>>
>>> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=
=9D and wants to
>>> keep using it. (The vast majority of OIDC implementations, in my
>>> experience, don=E2=80=99t use that feature, and it=E2=80=99s not even r=
equired to be
>>> implemented by the AS, but again we=E2=80=99re talking about using this=
 feature as
>>> an example of an external query language =E2=80=94 and there are others=
 out there.)
>>> In GNAP, you should return claims directly in the response, and request
>>> specific elements from the APIs protected by the access token. These ar=
e
>>> separate things, and by design both XAuth and XYZ have put them into
>>> separate containers in the request. This is a good design, and so putti=
ng
>>> something that conflates these two aspects into one or the other of the
>>> containers is not a particularly good option, in my opinion.
>>>
>>> Additionally, though this is a bit of an aside and getting into the
>>> specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC i=
s a query language
>>> bound to the full user profile. It is my stated position that the items
>>> coming back from the AS should only be identifiers, and not full profil=
e
>>> information. The reasoning is pretty simple: the client doesn=E2=80=99t=
 know what
>>> profile information it needs until it knows who the user is, so putting
>>> that into a protected API like the UserInfo Endpoint makes much more se=
nse
>>> than putting it into the immediate response, where it is not needed,
>>> because the client already knows it. The AS doesn=E2=80=99t know what t=
he client
>>> needs to know, either, so it can=E2=80=99t determine what to fulfill. O=
IDC=E2=80=99s
>>> two-stage model makes sense, and GNAP should really only focus on enabl=
ing
>>> this.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 8, 2020, at 6:10 PM, Dick Hardt  wrote:
>>>
>>>
>>>
>>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer  wrote:
>>>
>>>> On Jul 8, 2020, at 3:16 PM, Dick Hardt  wrote:
>>>>
>>>>
>>>> I think representing the request as an array is simplistic, and
>>>> complicated at the same time.
>>>>
>>>> On the simplistic front, as there is no clear mechanism for extending
>>>> the request with properties that apply to all of the request.
>>>>
>>>>
>>>> The elements of the array are taken as a set, to be tied to the same
>>>> resulting access token. If one of those elements is defined, by the AS
>>>> and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some =
or all of the other
>>>> elements, then that=E2=80=99s up to the AS=E2=80=99s policy. Much like=
 the =E2=80=9Copenid=E2=80=9D scope
>>>> in OIDC, which switches on all sorts of contextual stuff in the reques=
t. So
>>>> to handle something like this, an AS can easily declare that a given
>>>> scope-style string or a given object property applies to different par=
ts of
>>>> the request. You don=E2=80=99t need to externalize it here.
>>>>
>>>
>>> I view the "openid" scope as an unfortunate design as OIDC was
>>> constrained by building on top of OAuth. (a problem I hoped to avert by
>>> having "identity" in scope for GNAP) The "openid" scope does not functi=
on
>>> as scope per se, and I think it makes OIDC harder to understand as the
>>> "openid" scope causes non-scope behavior.
>>>
>>>
>>>
>>>>
>>>> Do you have a concrete use case that requires that feature to be done
>>>> in the way that you describe? I am trying to separate the driving use =
case
>>>> from the proposed solutions to see what the differences are.
>>>>
>>>
>>> Perhaps the client wants access to be HIPPA compliant? The HIPPA
>>> compliance signal applies to the scopes.
>>>
>>> Adding other properties to an object is a well understood extension
>>> mechanism. Adding an additional element to an array that does not act l=
ike
>>> the other elements seems like a hack.
>>>
>>>
>>>
>>>>
>>>>
>>>> Using JSON type polymorphism requires the AS to test each member of th=
e
>>>> array to determine if it is a string or an object. Only after detectin=
g a
>>>> RAR object does the AS know the client is making a RAR request.
>>>>
>>>>
>>>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole r=
esources request
>>>> in order to figure out what the client is asking for, anyway, whether =
it=E2=80=99s
>>>> by strings or objects or whatever else might be defined by an extensio=
n. Is
>>>> there an argument for having an AS do an early dispatch on a request b=
efore
>>>> it=E2=80=99s fully parsed everything?
>>>>
>>>
>>> Let me clarify, the code is looking at the type of object that has been
>>> parsed.
>>>
>>> Determining if an item in an array is a scope or a RAR object by lookin=
g
>>> at the type being either a string or an object seems less clear than a
>>> property of an object explicitly declaring the type.
>>>
>>>
>>>
>>>>
>>>> This also limits the request to be composed only of scope strings or
>>>> RAR objects. I don't see how other strings or objects could be used in=
 the
>>>> array, so there is no clear extension point in the "resources" array f=
or
>>>> other query mechanisms.
>>>>
>>>>
>>>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring t=
hat a string has
>>>> to be an OAuth2-style scope. It can be, but ultimately it=E2=80=99s ju=
st a string
>>>> that the AS can understand. And the objects are just that =E2=80=94 ob=
jects. If the
>>>> AS understands what the object is, it can be a RAR object or it can be
>>>> something completely API-specific with another query language entirely=
.
>>>>
>>>
>>> But the other query language would need a type that has been reserved i=
n
>>> the RAR name space for there to be interop, so it effectively is a RAR
>>> extension.
>>>
>>> There are query languages in other domains that may not fit nicely into
>>> RAR such as a query for medical records.
>>>
>>> Yes, the medical records could be yet another top level property, but
>>> per below, I think that is confusing.
>>>
>>>
>>>> (Point, though: RAR already pretty much allows this by letting them be
>>>> extended infinitely, a feature it inherits from XYZ)
>>>>
>>>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99=
s an array of
>>>> strings or objects and each of those means the same thing, =E2=80=9Cso=
mething the
>>>> client is asking for=E2=80=9D.
>>>>
>>>>
>>>> Just as RAR has a "type" property, I propose the "resources"
>>>> ("authorizations" in XAuth) be an object, where the other properties a=
re
>>>> determined by the "type" property. This allows extensions to define ne=
w
>>>> ways to query for an authorization rather than having to fit into scop=
es or
>>>> RAR.
>>>>
>>>>
>>>> It=E2=80=99s my stance that this is an unnecessary limitation at this =
level.
>>>> The objects within the array should be typed, like RAR, but it doesn=
=E2=80=99t make
>>>> sense for the overall request to be typed. Instead, there should be on=
e
>>>> =E2=80=9Ctype" of query in the core, what XYZ calls the =E2=80=9Cresou=
rces=E2=80=9D request. Other
>>>> query languages should be added as extensions either to the RAR-style
>>>> objects (by defining a type at that level) or as a separate top-level
>>>> member.
>>>>
>>>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D quer=
y language. My current
>>>> thought is that this really shouldn=E2=80=99t be a part of the =E2=80=
=9Cresources=E2=80=9D or
>>>> =E2=80=9Cclaims=E2=80=9D part of the request, but instead as its own t=
op-level member, like
>>>> it is in the OIDC protocol today. The main reason for this is the natu=
re of
>>>> the OIDC claims language: it specifies targets for the resulting data,=
 and
>>>> those targets cross different ways to return things. So it doesn=E2=80=
=99t actually
>>>> affect just resources like the UserInfo Endpoint, or the ID Token, but=
 both
>>>> and potentially others out there. If your system supported such an
>>>> extension, it could theoretically forego both the built-in =E2=80=9Ccl=
aims=E2=80=9D and
>>>> =E2=80=9Cresources=E2=80=9D parts of the request, and use the =E2=80=
=9Coidc_claims_query=E2=80=9D member
>>>> (or whatever it would be called). This would let such an extension use=
 the
>>>> OIDC claims processing mechanism as it is today.
>>>>
>>>> To me, this remains much more understandable, extensible, and clean.
>>>>
>>>
>>> While this may be more understandable to a developer just porting an ap=
p
>>> OIDC that only wants OIDC results, but I think it is more complicated a=
s
>>> soon as the developer wants other results, which is likely what prompte=
d
>>> the developer to use GNAP instead of ODIC.
>>>
>>> I think it is easier to understand if all the claims are in one
>>> container, and all the authorizations are in another container.
>>>
>>> If a developer wants access to some resources, some claims, and an
>>> OpenID Token, they are having to use "claims", "resources", and
>>> "oidc_claims_query".  Now the claims and access tokens are spread acros=
s
>>> multiple containers. There are some claims in the "claims" container, a=
nd
>>> some "claims" in the "oidc_claims_query" container. And is the access t=
oken
>>> response in "oidc_claims_query" the same as an access token response in
>>> "resources"? It would seem simpler if they were, and if all the access
>>> tokens came back in the same container.
>>>
>>> Per Aaron's post that you have referred to, the developer can get sme
>>> bare claims directly in the response in the "claims" object, an ID Toke=
n
>>> that has the same or different claims, and if they want, an access toke=
n
>>> that they can call a user_info endpoint to get the same, or different
>>> claims.
>>>
>>> For example, an enterprise app client may want an ID Token with the
>>> email address, bare claims for the user's name and a URI to a profile
>>> photo, and an access token to query which groups a user belongs to.
>>>
>>> We are still re-using the OIDC claims, but we are not mixing claims and
>>> authorizations.
>>>
>>> /Dick
>>>
>>>
>>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
>>> =E1=90=A7
>>>
>>>
>>> =E1=90=A7
>>
>
> =E1=90=A7

--000000000000a99ddd05aa06754a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Looks like you missed the point of m=
y code example, as your response is focussed on the aspects I had in=C2=A0c=
omments, so let me clarify.=C2=A0

This line (which=
 is determining=C2=A0the type of the item in the array):

if (typeof item =3D=3D=3D string')

is implicitly stating=C2=A0that=
 the item is an oauth scope. Whereas it is explicit in this statement
=


if (authorizations.type =3D=3D=3D 'oaut=
h_scope')

=
which I think it easier to understand what is happening (in my opinion of c=
ourse).

XYZ has types, they are just implicit. RAR=
 has explicit types, and that does not look to be holding back RAR. I don&#=
39;t understand why you think having explicit types will hold us back. Do y=
ou want to let the string and object be anything the AS and RS decide they =
could mean? That would make GNAP more of a framework than a protocol, and a=
 key aspect of the request would be undefined.

My =
thoughts have not shifted on "types" in interactions. I just chan=
ged the name to 'mode'.=C2=A0I did shift my thinking that a negotia=
tion=C2=A0of interaction modes is useful, and added that.

We still have an unfinished discussion there. When you have a chanc=
e, would you respond to that thread?

/Dick

On=
 Thu, Jul 9, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wrote:
Declaration=
s of which code is =E2=80=9Ceasier to understand=E2=80=9D are going to be s=
ubjective, and I don=E2=80=99t agree with your conclusions even with your e=
xamples. Even so, I don=E2=80=99t think that the examples you give are a go=
od comparison. While it is of course possible to implement things like you =
have below, I think it=E2=80=99s indicative of thinking of things in terms =
of a =E2=80=9Cresource request type=E2=80=9D. What I=E2=80=99ve been trying=
 to argue is that there shouldn=E2=80=99t be a =E2=80=9Ctype=E2=80=9D, that=
 there should just be slightly different ways to do a resource request. So =
the code is more like:

resourcesRequested =3D=
 requests.map( item =3D> {
=C2=A0 =C2=A0if (typeof =
item =3D=3D =E2=80=98object=E2=80=99) {
=C2=A0 =C2=A0 =
=C2=A0 return new RarStyleResourceRequest(item);
=C2=
=A0 =C2=A0} else if (typeof item =3D=3D =E2=80=9Cstring=E2=80=9D) {
=C2=A0 =C2=A0 =C2=A0return new StringStyleResourceRequest(ite=
m);
=C2=A0 =C2=A0}
});
processResources(resourcesRequested);

Each of these =E2=80=9C*ResourceRequest=E2=80=9D obj=
ects would be something that the AS can use to decide what to put into the =
access token. Although you=E2=80=99d probably put that complexity into a fa=
ctory constructor or something instead of a map function, this shows the ki=
nd of dispatch you can do based on type if you=E2=80=99re doing it by hand.=
 You collect everything in the array, and turn it into an object that repre=
sents =E2=80=9Ca request for a resource that gets tied to an access token=
=E2=80=9D. And then you process the request based on the collection of reso=
urce requests. Each string-based request points to some set of policies, as=
 does each object-based request. You can even imagine that instead of creat=
ing a separate string-based request, you use that string to look up a polic=
y in a policy engine to be applied later.

The AS t=
hen has to figure out, as it always does, what to do with this collection. =
And if you want to do an early escape on object style requests, you could j=
ust throw an error when you detect that. Or, you just ignore that part of t=
he request. In fact, here=E2=80=99s the code I wrote that handles it exactl=
y that way, while processing the JSON by hand in Java on a legacy OAuth 2 s=
erver:


JsonArray=C2=A0resources=C2=A0=3D=
=C2=A0json.get("resources").getAsJsonArray();=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0
Set<String>=C2=A0scopes=C2=A0=3D=C2=A0StreamSu=
pport.stream(resources.spliterator(),=C2=A0false)
	.filter( e=C2=A0->=C2=A0e.isJsonPrimitive(=
) )=C2=A0//=C2=A0filter out anything that's not a handle=C2=A0=C2=A0=C2=
=A0 =C2=A0=C2=A0
	.ma=
p( e=C2=A0->=C2=A0e.getAsString() )=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0
=

	.collect(Collectors.toSet=
());=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0
tx.setScope(scopes);


Furthermore, your XAuth e=
xample doesn=E2=80=99t go to the same depth as the XYZ example, which leads=
 to a false comparison. In your =E2=80=9Cprocess scope=E2=80=9D you would n=
eed to parse the =E2=80=9Cscope=E2=80=9D string to split on spaces, and the=
n have another loop to process each scope. For the =E2=80=9Cprocess details=
=E2=80=9D you=E2=80=99d need to iterate over the array at the root of a RAR=
-style request and process each piece. In the XYZ code, you=E2=80=99ve got =
all of that already. If you=E2=80=99re going to compare the complexity of c=
ode, they should at least be shown to the same point of the process.=C2=A0<=
/div>

On top of that, the fall-through case statement be=
low is really limiting. What if the scope processing or RAR objects process=
ing gets combined with something else? This kind of premature optimization =
is not something we want to encourage developers to do.=C2=A0
But ultimately, I think the disconnect is down to thinking abou=
t this in terms of an explicit =E2=80=9Ctype=E2=80=9D, much the way XAuth u=
sed to do with the interactions. I=E2=80=99m glad that your thoughts have s=
hifted in that space, and I think you should strongly consider the same set=
 of arguments here. A lot of the promise of GNAP is getting away from this =
type-field style design, like getting away from OAuth 2=E2=80=99s =E2=80=9C=
grant_type=E2=80=9D approach and into something that=E2=80=99s focused on i=
nteraction and client models instead. This newer model allows for better fl=
exibility, better consistency, and better clarity throughout. It=E2=80=99s =
no longer =E2=80=9Cif I see this flag then I go down this separate code pat=
h and nothing else=E2=80=9D, it=E2=80=99s now =E2=80=9Cif I see this item, =
I go down this code path and then process the next item too=E2=80=9D. There=
=E2=80=99s power in the combinations.

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

On Jul 8, 2020, at 9:=
31 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I h=
ad intended to provide a code sample comparing XYZ request type with XAuth =
request type

Let's say an AS only supports OAuth=
 scopes (does not support RAR). Here is JS code to check:

//XYZ code
var oauth_scope =3D true;
requests.forEach( item=
 =3D> {=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 
=C2=A0 =C2=A0 if (ty=
peof item =3D=3D=3D "object")
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 oauth_scope =3D false;
});
if (!'oauth_scope=
9;) {
=C2=A0 =C2=A0 // return error
}

// XAuth code
if ('oauth_scope' !=3D authorizati=
ons.type) {
=C2=A0 =C2=A0// return error
}

Here is some JS code that for an AS that supports=
 OAuth scopes, RAR, and OIDC requests:

// XYZ
if (reques=
t) {
=C2=A0 =C2=A0 requests.forEach( item =3D> {
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 if (typeof item =3D=3D=3D "object") {
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // process a RAR item
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 } else if(typeof item =3D=3D=3D 'string') {
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // process a scope item
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 } else {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // throw a=
n error
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }) =C2=A0 =C2=A0<=
br>=C2=A0 =C2=A0// process the whole request
}
if (oidc_claims_query)=
 {
=C2=A0 =C2=A0 // process oidc request
}

//XAut=
h
=
if (authorizations) {
=C2=A0 =C2=A0 switch (authorizations?.type) {
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case 'oauth_rar':
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 // process authorizations.details - RAR 
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 case 'oauth_scope':
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 // process authorizations.scope
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 // process the whole request
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 break;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case 'oi=
dc':
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // process OIDC claim=
s
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 default:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // error f=
or unknown type
=C2=A0 =C2=A0 }
}=C2=A0 =C2=A0=C2=A0


Understanding what the code is doing loo=
ks much clearer in XAuth to me.

3D""=
=E1=90=A7

On Wed, Jul 8, 2020 at 3:55 PM Dick Hardt <dick.hardt@gmail.com> w=
rote:
Hey Justin,

Just because=C2=A0=
we are using OIDC claims, does not mean we need to mimic the OIDC request a=
nd response.
I was envisioning a grant request could look as the =
following (using XAuth syntax):

{
=C2=A0 =C2=A0 &=
quot;authorizations": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type"=
;:"oidc",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "claims": [&qu=
ot;name", "picture"]
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 &q=
uot;claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "oidc": {
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id_token" : {
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "email" =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "essential" : true },
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "email_verified&q=
uot; : { "essential" : true }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "userinfo&q=
uot; : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "n=
ame" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : { "essential" : tr=
ue },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "pict=
ure" =C2=A0 =C2=A0 =C2=A0 =C2=A0: null
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
}

Of course a developer could choose to only=
 ask for a subset of this.

Note the new authorizat=
ion type of "oidc", that takes "claims" rather than &qu=
ot;scope".=C2=A0

This keeps all the authoriza=
tions and claims in their respective request and response containers.
=


We had a thread months ago on the OIDC two stage model,=
 and I still fail to see why forcing that has any advantage.=C2=A0

/Dick


On Wed, Jul 8, 2020 at 3:25 PM J=
ustin Richer <jrich=
er@mit.edu> wrote:
I=E2=80=99m glad that we can agree that there are a number =
of things in legacy protocols that are unfortunate side effects of the circ=
umstances in which they were built. Space-separated scope strings, for inst=
ance, would fall in that category, as I=E2=80=99ve previously explained.
A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=
=9D request already mixes user claims (returned in an API) and authorizatio=
n (to fetch user claims from an API), so that ship has sailed if you=E2=80=
=99re using it. It doesn=E2=80=99t make sense to have it under a =E2=80=9Cc=
laims=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=
=99s a query language that affects both. Maybe you=E2=80=99d call this anot=
her =E2=80=9Cunfortunate design=E2=80=9D, but the context was about re-usin=
g an externally-defined query language that was not made for GNAP.

=

My scenario was for someone who is already using =E2=80=9Cclaims=
=E2=80=9D and wants to keep using it. (The vast majority of OIDC implementa=
tions, in my experience, don=E2=80=99t use that feature, and it=E2=80=99s n=
ot even required to be implemented by the AS, but again we=E2=80=99re talki=
ng about using this feature as an example of an external query language =E2=
=80=94 and there are others out there.) In GNAP, you should return claims d=
irectly in the response, and request specific elements from the APIs protec=
ted by the access token. These are separate things, and by design both XAut=
h and XYZ have put them into separate containers in the request. This is a =
good design, and so putting something that conflates these two aspects into=
 one or the other of the containers is not a particularly good option, in m=
y opinion.=C2=A0

Additionally, though this is a bi=
t of an aside and getting into the specifics of identity, the =E2=80=9Cclai=
ms=E2=80=9D parameter of ODIC is a query language bound to the full user pr=
ofile. It is my stated position that the items coming back from the AS shou=
ld only be identifiers, and not full profile information. The reasoning is =
pretty simple: the client doesn=E2=80=99t know what profile information it =
needs until it knows who the user is, so putting that into a protected API =
like the UserInfo Endpoint makes much more sense than putting it into the i=
mmediate response, where it is not needed, because the client already knows=
 it. The AS doesn=E2=80=99t know what the client needs to know, either, so =
it can=E2=80=99t determine what to fulfill. OIDC=E2=80=99s two-stage model =
makes sense, and GNAP should really only focus on enabling this.
=

=C2=A0=E2=80=94 Justin

On Jul 8, 2020, at 6:10 PM, Dick Hardt <dick.hardt@gmail.com> wrote=
:



On Wed, Jul 8, 2020 at 1:02 =
PM Justin Richer <j=
richer@mit.edu> wrote:
On Jul 8, 2020, at 3:16 PM, Dick Hardt <dick.hardt@gmail.com> w=
rote:

I think representing the request as an array is simplistic, and co=
mplicated at the same time.

On the simplistic front, as =
there is no clear mechanism for extending the request with properties that =
apply to all of the request.=C2=A0

The elements of the array are taken as a set, to be tied to=
 the same resulting access token. If one of those elements is defined, by t=
he AS and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some=
 or all of the other elements, then that=E2=80=99s up to the AS=E2=80=99s p=
olicy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, which switches=
 on all sorts of contextual stuff in the request. So to handle something li=
ke this, an AS can easily declare that a given scope-style string or a give=
n object property applies to different parts of the request. You don=E2=80=
=99t need to externalize it here.

I view the "openid" scope as an unfortunate design as OI=
DC was constrained by building=C2=A0on top of OAuth. (a problem I hoped to =
avert by having "identity" in scope for GNAP) The "openid&qu=
ot; scope does not function as scope=C2=A0per se, and I think it makes OIDC=
 harder to understand as the "openid" scope causes non-scope beha=
vior.=C2=A0

=C2=A0

Do you have a concret=
e use case that requires that feature to be done in the way that you descri=
be? I am trying to separate the driving use case from the proposed solution=
s to see what the differences are.=C2=A0

Perhaps the client wants access to be HIPPA compliant? The =
HIPPA compliance signal applies to the scopes.

Add=
ing other properties to an object is a well understood extension mechanism.=
 Adding an additional element to an array that does not act like the other =
elements seems like a hack.

=C2=A0


=
Using JSON type polymorphism=C2=A0requires the AS to test each member of th=
e array to determine if it is a string or an object. Only after detecting a=
 RAR object does the AS know the client is making a RAR request.=C2=
=A0

That=E2=
=80=99s correct =E2=80=94 but the AS needs to parse the whole resources req=
uest in order to figure out what the client is asking for, anyway, whether =
it=E2=80=99s by strings or objects or whatever else might be defined by an =
extension. Is there an argument for having an AS do an early dispatch on a =
request before it=E2=80=99s fully parsed everything?

Let me clarify, the code is looking at the type=
 of object that has been parsed.=C2=A0

Determining=
 if an item in an array is a scope or a RAR object by looking at the type b=
eing either a string or an object seems less clear than a property of an ob=
ject explicitly declaring the type.

=C2=A0

This also limi=
ts the request to be composed only of scope strings or RAR objects. I don&#=
39;t see how other strings or objects could be used in the array, so there =
is no clear extension point in the "resources" array for other qu=
ery mechanisms.

Tha=
t=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring that a st=
ring has to be an OAuth2-style scope. It can be, but ultimately it=E2=80=99=
s just a string that the AS can understand. And the objects are just that =
=E2=80=94 objects. If the AS understands what the object is, it can be a RA=
R object or it can be something completely API-specific with another query =
language entirely.

But th=
e other query language would need a type that has been reserved in the RAR =
name space for there to be interop, so it effectively is a RAR extension.

There are query languages in other domains that may=
 not fit nicely into RAR such as a query for medical records.
Yes, the medical records could be yet another top level propert=
y, but per below, I think that is confusing.
=C2=A0
(Point, though: RA=
R already pretty much allows this by letting them be extended infinitely, a=
 feature it inherits from XYZ)

I=E2=80=99m proposi=
ng that we do the same thing with GNAP: it=E2=80=99s an array of strings or=
 objects and each of those means the same thing, =E2=80=9Csomething the cli=
ent is asking for=E2=80=9D.


Just as RAR has a "type=
" property, I propose the "resources" ("authorizations&=
quot; in XAuth) be an object, where the other properties are determined by =
the "type" property. This allows extensions to define new ways to=
 query for an authorization rather than having to fit into scopes or RAR.


It=E2=
=80=99s my stance that this is an unnecessary limitation at this level. The=
 objects within the array should be typed, like RAR, but it doesn=E2=80=99t=
 make sense for the overall request to be typed. Instead, there should be o=
ne =E2=80=9Ctype" of query in the core, what XYZ calls the =E2=80=9Cre=
sources=E2=80=9D request. Other query languages should be added as extensio=
ns either to the RAR-style objects (by defining a type at that level) or as=
 a separate top-level member.

For example, let=E2=
=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D query language. My current t=
hought is that this really shouldn=E2=80=99t be a part of the =E2=80=9Creso=
urces=E2=80=9D or =E2=80=9Cclaims=E2=80=9D part of the request, but instead=
 as its own top-level member, like it is in the OIDC protocol today. The ma=
in reason for this is the nature of the OIDC claims language: it specifies =
targets for the resulting data, and those targets cross different ways to r=
eturn things. So it doesn=E2=80=99t actually affect just resources like the=
 UserInfo Endpoint, or the ID Token, but both and potentially others out th=
ere. If your system supported such an extension, it could theoretically for=
ego both the built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=
=9D parts of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D m=
ember (or whatever it would be called). This would let such an extension us=
e the OIDC claims processing mechanism as it is today.

=

To me, this remains much more understandable, extensible, and clean.

While this may be more und=
erstandable to a developer just=C2=A0porting an app OIDC that only wants OI=
DC results, but I think it is more complicated as soon as the developer wan=
ts other results, which is likely what=C2=A0prompted the developer to use G=
NAP instead of ODIC.

I think it is easier to under=
stand if all the claims are in one container, and all the authorizations ar=
e in another container.

If a developer wants acces=
s to some resources, some claims, and an OpenID Token, they are having to u=
se "claims", "resources", and "oidc_claims_query&q=
uot;.=C2=A0 Now the claims and access tokens are spread across multiple con=
tainers. There are some claims in the "claims" container, and som=
e "claims" in the "oidc_claims_query" container. And is=
 the access token response in=C2=A0"oidc_claims_query" the same a=
s an access token response in "resources"? It would seem simpler =
if they were, and if all the access tokens came back in the same container.=


Per Aaron's post that you have referred to, t=
he developer can get sme bare claims directly in the response in the "=
claims" object, an ID Token that has the same or different claims, and=
 if they want, an access token that they can call a user_info endpoint to g=
et the same, or different claims.

For example, an =
enterprise app client may want an ID Token with the email address, bare cla=
ims for the user's name and a URI to a profile photo, and an access tok=
en to query which groups a user belongs to.

We are=
 still re-using=C2=A0the OIDC claims, but we are not mixing claims and auth=
orizations.

/Dick

3D""=E1=90=A7

Hi Denis,=C2=A0

I think it's intere=
sting, but also very different to XYZ/XAuth so it raises many questions ;-)=

The figure is impossible to read.

So le=
t me try to summarize the suggested approach, with a concrete example, to m=
ake sure we understand well:

0. The client auth=
N to the AS (in whatever way is supported)
Ex : client is a c=
orporate=C2=A0financing called "finapp". finapp contacts AS0 for =
authentication (say an openbanking service).=C2=A0=C2=A0
User is =
John Doe, CFO at NeedMoney Inc. (+ other identity claims if needed, maybe s=
ome verified credential from NeedMoney Holding that John is indeed CFO).

Dear John,=C2=A0
to access to yo=
ur finapp, please identify yourself through your prefered openbanking accou=
nt.
Thanks

1. The client c=
ontacts a RS in a discovery phase, which includes the selection of (at leas=
t) an operation, for which the RS returns the required authZ attributes=C2=
=A0
Ex : finapp needs to use NeedMoney's data to evaluate=
 how much credit it can offer.

Op1 : compute the c=
redit rating, from RS1 (this is outsourced to an external credit analyst), =
through the external service's own AS1.
But to do that, R=
S needs your historic bank statements.

Op2 : get y=
our list of banks, RS2 (as registered within finapp), through=C2=A0openbank=
ing AS0

and retrieve the bank statements :=C2=A0
Op3a : get historic data from his main bank, RS2a (say an internat=
ional bank), through openbanking AS0
Op3b : same from a second ba=
nk account, RS2b (say a local bank), through openbanking AS0=C2=A0

2. User consent=C2=A0
RS1 aggregates the =
list of attributes required (from all RS) and sends it to finapp.

Dear John,=C2=A0
To evaluate your credi=
t request, we need the following information:=C2=A0
- your=
 list of bank accounts (retrieved from your finapp account)
<=
i>- the associated banking statements over the past 12 months (from each ba=
nk)
- we'll pass that data to the credit agency, which=
 will return your credit score=C2=A0
Do you agree ?

John approves (or not..., maybe he'll agree only=
 for one specific bank), via finapp directly (I like that, albeit in a more=
 traditional flow, I'm also separating the UI from the rest of the prot=
ocol of XYZ, and it works too).

3. Reque=
sts to the protected resources=C2=A0
The client gets the acce=
ss tokens and uses the services for which access was granted.

Analysis: (maybe I didn't get everything =
right, if so let me know)=C2=A0
The trust model is focused ar=
ound the relationship between the enduser (John) and his application (finap=
p), which seems fine.

=3D> I see some potential=
 issues :=C2=A0

a. it will be really difficult for=
 an end user to understand what AS0 and AS1 are, why they're different,=
 and why he needs to authenticate to each of them. How do you enable a fede=
rated experience? (especially as there could be many)

<=
div>b. deciding what is the main RS (here RS1) to be called by the client s=
eems very critical, as it is the one that needs to orchestrate everything. =
This seems a very hierarchical and imperative model which seems somewhat co=
unter intuitive in terms of developer experience (as least as it is made to=
day, we clearly don't go into so much details). The call hierarchy may =
quickly become very complex, which may also become a problem when separate =
services evolve.

c. RS1 gets all the information r=
equired to access all sub-resources, and therefore gets also a lot of respo=
nsibility (and power). But from finapp's point of view, it is the one t=
hat has the relationship with the user and is providing the core value prop=
osition, while RS1 is just an external service.

d.=
 multi-user (common B2B scenario): John wants to authorize a read access to=
 his finapp account to his external auditor, Ann (who is not a direct user =
of finapp herself, but might already be registered by openbanking AS0). How=
 do you do that? Does it require the access token itself to be able to dele=
gate rights?

e. more generally, a threat model wou=
ld be required, as there are many more interactions now.

Cheers,=C2=A0
Fabien








On Mon, Jul 6, 2=
020 at 8:08 PM Roman Danyliw <rdd@cert.o=
rg> wrote:




Hi Denis!


=C2=A0


Thanks for the feedback and for repeating your revie=
w on the revised text.=C2=A0 More inline =E2=80=A6


=C2=A0








From: iesg <iesg-bounces@ietf.org> On Behalf Of =

Denis

Sent: Monday, July 6, 2020 10:55 AM

To: iesg@ietf.org=


Cc: txauth@ietf=
.org

Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization=
 Protocol (gnap)






=C2=A0




Since i=
t is today the last day to send back comments, you will find hereafter my c=
omments on the last charter version-05.






charter-ietf-gnap-00-05<=
u>


This group=
 is chartered to develop a fine-grained delegation protocol for authorizati=
on, API access, user identifiers, and identity assertions. 


=C2=
=A0


[Denis] Fine.


=C2=
=A0


The protoc=
ol will also allow the client to present unverified identifiers and verifia=
ble assertions to the AS as part of its request. 

=C2=A0


[Denis] This sentence is too vague because "as part of its request&qu=
ot; is not explicit enough. If it means=C2=A0 "as part as an access to=
ken request" 


this should be explicitly said. If, it is not the case, then it should be =
clearly explained. The AS should know as little as possible (including noth=
ing)


about what the client is doing.


=C2=
=A0


[Roman] =
The =E2=80=9Crequest=E2=80=9D here is the =E2=80=9Caccess token request=E2=
=80=9D.=C2=A0 That can be made clearer.


=
=C2=A0


This proto=
col will allow an authorizing party to delegate access to client software t=
hrough an authorization server. 


=C2=A0


[Denis] The word "privacy" is still missing in the charte=
r. "Delegating access to client software through an authorization serv=
er" 


is negating the fact that the user's privacy will ever be considered. =
IMHO, I believe that a RS may delegate some operation to another RS, 


but I don't believe that an AS should be concerned by any form of dele=
gation, otherwise it would have the ability to act as "Big Brother&quo=
t;.


OAuth has not been constructed taking into consideration the user's pr=
ivacy. The major difference with it should be that GNAP has been =



constructed along "privacy by design" principles.<=
u>


=
=C2=A0


[Roman]=
=C2=A0 I don=E2=80=99t exactly follow how considerations for privacy are be=
ing negated.=C2=A0 Above and beyond use-case specific considerations that w=
ould be defined later, RFC6973 is the IETF consensus design guidance that w=
ill guide the privacy threats and mitigations of the work.=C2=A0 What desig=
n guidance would you recommend that the WG should consider that aren=E2=80=
=99t captured in RFC6973?


=C2=
=A0


It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID=
 Connect (itself an extension of OAuth 2.0) to support authorizations 


scoped as =
narrowly as a single transaction, provide a clear framework for interaction=
 among all parties involved in the protocol flow, and remove =



unnecessar=
y dependence on a browser or user-agent for coordinating interactions.


=C2=
=A0


[Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. Some ex=
isting uses cases (i.e. "non-expanded" use cases) should b=
e supported 


differently from OAuth 2.0 and OpenID Connect, in particular to support th=
e user's privacy.


=C2=
=A0


[Roman] =
I=E2=80=99d want to hear others on this rescoping.=C2=A0 Building upon the =
use cases of OAuth 2.0 and OpenID Connect has been core, consensus-validate=
d tenant for some time now.


=
=C2=A0


The delega=
tion process will be acted upon by multiple parties in the protocol, each p=
erforming a specific role. The protocol will decouple the channels used =



by the pro=
tocol participants to communicate from the delegation channel, which happen=
s directly between the client and the authorization server (in contrast =



with OAuth=
 2.0, which is initiated by the client redirecting the user=E2=80=99s brows=
er). 


=C2=
=A0


[Denis] Here again, the delegation process, if any, should be handled by R=
Ss and not by ASs. 


The term "delegation channel" is being used but it is left undef=
ined. It is not understandable.


=
=C2=A0


[Roman] =
This sentence was just added into -05 address Security AD feedback.=C2=A0 I=
n this case, it was made to distinguish between in-band signaling and the n=
ew purpose-to-be-built channel.


=C2=
=A0


The protoc=
ol will include a means of specifying how the user can potentially be invol=
ved in an interactive fashion during the delegation process. =



The client=
 and Authorization Server (AS) will use these interaction mechanisms to inv=
olve the user, as necessary, to make authorization decisions.=



=C2=
=A0


[Denis] Here again, the delegation process, if any, should=
 be handled by RSs and not by ASs. The AS should know as little as possible=
 (including nothing)


about what the client is doing.


=C2=
=A0


[Roman] =
Understood =E2=80=93 as I understand it, you have concern with the scope of=
 the AS behavior.=C2=A0 I=E2=80=99d be interesting in hearing additional su=
pport for this rescoping.=C2=A0 


=
=C2=A0


This decou=
pling avoids many of the security concerns and technical challenges of OAut=
h 2.0 and provides a non-invasive path for supporting future types <=
u>


of clients=
 and interaction channels.


=C2=
=A0


[Denis] This is not understandable to me. Is such a sentence really needed=
 in a charter ?


=
=C2=A0


[Roman] =
Can someone on the TxAuth mailing list remind us on why this sentence is he=
re?=C2=A0 With a fresh read, I also can=E2=80=99t remember why we need it.<=
u>


=C2=
=A0


The group =
will define interoperability for this protocol between different parties, i=
ncluding


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client and authori=
zation server;


-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client and resourc=
e server; and


=C2=A0=C2=
=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authorization server and re=
source server.


=C2=
=A0


[Denis] In order to support the user's privacy, there should be no int=
eraction at all between an authorization server and a resource server 


at the time of a client request.


=
=C2=A0


The group =
will seek to minimize assumptions about the form of client applications, al=
lowing for:


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Fine-grained specification of access


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Approval of AS attestation to identifiers and other =
identity claims


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Approval of access to multiple resources and APIs in=
 a single interaction


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Multiple access tokens in a single request and respo=
nse


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 AS-directed dispatch of access tokens to the appropr=
iate RS


[Denis] As-directed dispatch does not allow to su=
pport the user's privacy. However, RS-directed dispatch allows to suppo=
rt the user's privacy.


It should be explicitly mentioned.<=
/span>


[Roman] As above (per the AS vs. RS behavior)


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Separation between the party authorizing access and =
the party operating the client requesting access 

<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">=C2=A0=



=
[Den=
is] It is questionable whether such a separation would be really beneficial=
. In doubt, this item should be removed.


[Roman] Could you say more on why this flexibility wouldn=
=E2=80=99t be worth it?=C2=A0 


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">The group will d=
efine extension points for this protocol to allow for flexibility in areas =
including:


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">=C2=A0=



<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">Cryptographic ag=
ility for keys, message signatures, and proof of possession


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 User interaction mechanisms including web and non-we=
b methods


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mechanisms for conveying user, software, organizatio=
n, and other information used in authorization decisions <=
/u>


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mechanisms for presenting tokens to resource servers=
 and binding resource requests to tokens and associated cryptographic keys =



Optimized =
inclusion of additional information (including identifiers and identity ass=
ertions) through the delegation process 


=C2=
=A0


Additional=
ly, the group will provide mechanisms for management of the protocol lifecy=
cle including:


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Discovery of the authorization server<=
u>


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Revocation of active tokens

Data model=
 for granted access and mechanisms for the AS and RS to communicate the gra=
nted access model


=C2=
=A0


[Denis] While it is the duty for the RS to communicate the granted access =
model to the client at the appropriate instant of time, 


the AS should be kept fully ignorant of it.


=C2=
=A0


Although t=
he artifacts for this work are not intended or expected to be backwards-com=
patible with OAuth 2.0 or OpenID Connect, 


the group =
will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the=
 new protocol where possible.


=C2=
=A0


This group=
 is not chartered to develop extensions to OAuth 2.0, and as such will focu=
s on new technological solutions not necessarily 

compatible=
 with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be di=
rected to the OAuth Working Group, including 


functional=
ity back-ported from the protocol developed here to OAuth 2.0.


=C2=
=A0


The group =
is chartered to develop mechanisms for applying cryptographic methods, such=
 as JOSE and COSE, to the delegation process. 


This group=
 is not chartered to develop new cryptographic methods.


=C2=
=A0


The group =
is chartered to develop mechanisms for conveying identity information withi=
n the protocol including existing identifiers 


(such as e=
mail addresses, phone numbers, usernames, and subject identifiers) and asse=
rtions (such as OpenID Connect ID Tokens, 


SAML Asser=
tions, and Verifiable Credentials). The group is not chartered to develop n=
ew formats for identifiers or assertions, nor is the group 


chartered =
to develop schemas for user information, profiles, or other identity attrib=
utes, unless a viable existing format is not available.


=C2=
=A0


The initia=
l work will focus on using HTTPS for communication between the client and t=
he authorization server, taking advantage 


of optimiz=
ation features of HTTP/2 and HTTP/3 where possible, and will strive to enab=
le simple mapping to other protocols such as COAP 

when doing=
 so does not conflict with the primary focus.


=C2=
=A0


Milestones=
 to include:


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Core delegation protocol


[Denis] Before defining a "Core delegation p=
rotocol", a simple client server-protocol involving the presentation o=
f several access tokens to one RS should be defined. <=
/pre>

Privacy principles should be applied when definin=
g the protocol. Then after, a delegation mechanism allowing one RS to forwa=
rd an operation to another RS should be defined.


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Key presentation mechanism bindings to the core prot=
ocol including TLS, detached HTTP signature, and embedded HTTP signatures <=
/span>


[Denis] Bindings to TLS are now deprecated, why s=
hould they be maintained ? 


Signatures may be needed but they do not necessar=
ily need to be "detached HTTP signature, and embedded HTTP signatures&=
quot;. 


This item should be either removed or reworded.=



[Roman] Noted.=C2=A0 I=E2=80=99d want to hear others on th=
is rescoping.


=C2=A0


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Conveyance mechanisms for identifiers and assertions=
 


<=
span style=3D"font-size:12pt;font-family:Arial,sans-serif">-=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Guidelines for use of protocol extension points (if =
needed) 


=C2=A0=
=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0 Guidelines on migration paths, imple=
mentation, and operations



[Denis] The above three lines are rather mysterious.



[Roman] The guidelines on migration paths came from the initial IESG review=
 in order to have a named activity to action the design goal of =E2=80=9C=
=E2=80=A6 the group will attempt to simplify migrating from OAuth 2.0 and O=
penID Connect to the new protocol where possible=E2=80=9D
 a bit earlier in the text.


Where p=
ossible, the group will seek to make use of tools to guide and inform the s=
tandardization process including formal analysis,


architecture documents, and use case documents. These artifacts will not be=
 considered as working group milestones or deliverables.


The wor=
king group will cooperate and coordinate with other IETF WGs such as OAUTH,=
 and work with external organizations,


such as the OpenID Foundation, as appropriate.


[Denis] The charter should be shorter.


=C2=A0


[Roman] Definitely.=C2=A0 Nevertheless, we have the =
current text through rough consensus process achieved from two BoFs and mul=
tiple mailing list consensus calls.


=C2=A0


Regards,


Roman 






=C2=A0






/Denis






=C2=A0






A new IETF WG has been proposed in the Security Area. The IESG has not=
 made


any determination yet. The following draft charter was submitted, and =
is


provided for informational purposes only. Please send your comments to=
 the


IESG mailing list (=
iesg@ietf.org) by 2020-07-06.


=C2=A0


Grant Negotiation and Authorization Protocol (gnap)

----------------------------------------------------------------------=
-


Current status: Proposed WG


=C2=A0


Chairs:


=C2=A0 Yaron Sheffer <yaronf.ietf@gmail.com>


=C2=A0 Leif Johansson <leifj@sunet.se>


=C2=A0


Assigned Area Director:


=C2=A0 Roman Danyliw <rdd@cert.org>


=C2=A0


Security Area Directors:


=C2=A0 Benjamin Kaduk <kaduk@mit.edu>


=C2=A0 Roman Danyliw <rdd@cert.org>


=C2=A0


Mailing list:


=C2=A0 Address: t=
xauth@ietf.org


=C2=A0 To subscribe: =E2=80=8Bhttps://www.ietf.org/mailman/listinfo/txauth<=
u>


=C2=A0 Archive: https://mailarchive.ietf.org/arch/browse/txauth/


=C2=A0


Group page: https://datatracker.ietf.org/group/gnap/

=C2=A0


Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/


=C2=A0


This group is chartered to develop a fine-grained delegation protocol =
for


authorization and API access, as well as requesting and providing user=



identifiers and claims. This protocol will allow an authorizing party =
to


delegate access to client software through an authorization server. It=
 will


expand upon the uses cases currently supported by OAuth 2.0 and OpenID=
 Connect


(itself an extension of OAuth 2.0) to support authorizations scoped as=



narrowly as a single transaction, provide a clear framework for intera=
ction


among all parties involved in the protocol flow, and remove unnecessar=
y


dependence on a browser or user-agent for coordinating interactions.


=C2=A0


The delegation process will be acted upon by multiple parties in the p=
rotocol,


each performing a specific role. The protocol will decouple the intera=
ction


channels, such as the end user=E2=80=99s browser, from the delegation =
channel, which


happens directly between the client and the authorization server (in c=
ontrast


with OAuth 2.0, which is initiated by the client redirecting the user=
=E2=80=99s


browser). The protocol will include a means of specifying how the user=
 can


potentially be involved in an interactive fashion during the delegatio=
n


process. The client and Authorization Server (AS) will use these inter=
action


mechanisms to involve the user, as necessary, to make authorization de=
cisions.


This decoupling avoids many of the security concerns and technical cha=
llenges


of OAuth 2.0 and provides a non-invasive path for supporting future ty=
pes of


clients and interaction channels.


=C2=A0


The group will define interoperability for this protocol between diffe=
rent


parties, including


 - client and authorization server;


 - client and resource server; and


 - authorization server and resource server.


=C2=A0


The group will seek to minimize assumptions about the form of client


applications, allowing for:


- Fine-grained specification of access


- Approval of AS attestation to identifiers and other identity claims<=
u>


- Approval of access to multiple resources and APIs in a single intera=
ction


- Support for multiple access tokens in a single request and response<=
u>


- Support for directed, audience-restricted access tokens


- Separation between the party authorizing access and the party operat=
ing the


client requesting access


=C2=A0


The group will define extension points for this protocol to allow for<=
u>


flexibility in areas including:


=C2=A0


- Cryptographic agility for keys, message signatures, and proof of pos=
session


- User interaction mechanisms including web and non-web methods=



- Mechanisms for conveying user, software, organization, and other<=
/u>


information used in authorization decisions


- Mechanisms for presenting tokens to resource servers and binding res=
ource


requests to tokens and associated cryptographic keys

- Optimized inclusion of additional information (including identifiers=
 and


identity assertions) through the delegation process

=C2=A0


Additionally, the group will provide mechanisms for management of the =
protocol


lifecycle including:


=C2=A0


- Discovery of the authorization server


- Revocation of active tokens


- Mechanisms for the AS and RS to communicate the access granted by an=
 access


token


=C2=A0


Although the artifacts for this work are not intended or expected to b=
e


backwards-compatible with OAuth 2.0 or OpenID Connect, the group will =
attempt


to simplify migrating from OAuth 2.0 and OpenID Connect to the new pro=
tocol


where possible.


=C2=A0


This group is not chartered to develop extensions to OAuth 2.0, and as=
 such


will focus on new technological solutions not necessarily compatible w=
ith


OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be dir=
ected


to the OAuth Working Group, including functionality back-ported from t=
he


protocol developed here to OAuth 2.0.


=C2=A0


The group is chartered to develop mechanisms for applying cryptographi=
c


methods, such as JOSE and COSE, to the delegation process. This group =
is not


chartered to develop new cryptographic methods.


=C2=A0


The group is chartered to develop mechanisms for conveying identity=



information within the protocol including existing identifiers (such a=
s email


addresses, phone numbers, usernames, and subject identifiers) and asse=
rtions


(such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable<=
/u>


Credentials). The group is not chartered to develop new formats for=



identifiers or assertions, nor is the group chartered to develop schem=
as for


user information, profiles, or other identity attributes, unless a via=
ble


existing format is not available.


=C2=A0


The initial work will focus on using HTTPS for communication between t=
he


client and the authorization server, taking advantage of optimization<=
u>


features of HTTP/2 and HTTP/3 where possible, and will strive to enabl=
e


simple mapping to other protocols such as COAP when doing so does not<=
u>


conflict with the primary focus.


=C2=A0


Milestones to include:


- Core delegation protocol


- Key presentation mechanism bindings to the core protocol including T=
LS,


detached HTTP signature, and embedded HTTP signatures

- Conveyance mechanisms for identifiers and assertions

- Guidelines for use of protocol extension points


- (if needed) Guidelines on migration paths, implementation, and opera=
tions


=C2=A0


Where possible, the group will seek to make use of tools to guide and =
inform


the standardization process including formal analysis, architecture do=
cuments,


and use case documents. These artifacts will not be considered as work=
ing


group milestones or deliverables.


=C2=A0


The working group will cooperate and coordinate with other IETF WGs su=
ch as


OAUTH, and work with external organizations, such as the OpenID Founda=
tion,


as appropriate.


=C2=A0


Milestones:


=C2=A0


=C2=A0 Jul 2021 - Core delegation protocol in WGLC


=C2=A0


=C2=A0 Oct 2021 - Key presentation mechanism binding to the core proto=
col, TLS, to


=C2=A0 WGLC


=C2=A0


=C2=A0 Oct 2021 - Key presentation mechanism binding to the core proto=
col, 


=C2=A0=C2=A0detached HTTP signatures, to WGLC


=C2=A0


=C2=A0 Oct 2021 - Key presentation mechanism binding to the core proto=
col,


=C2=A0 embedded HTTP signature, to WGLC


=C2=A0


=C2=A0 Dec 2021 - Guidelines for use of protocol extension points to W=
GLC


=C2=A0


=C2=A0 Feb 2022 - Guidelines on migration paths, implementation, and o=
perations to


=C2=A0=C2=A0 WGLC


=C2=A0


=C2=A0


=C2=A0




=C2=A0






3D"==E1=90=A7



3D""=E1=90=A7


--000000000000a99ddd05aa06754a--


From nobody Thu Jul  9 12:16: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 103973A0DFC for ; Thu,  9 Jul 2020 12:16: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 OEiE6Wn0x2qi for ; Thu,  9 Jul 2020 12:16:02 -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 63DFB3A0E00 for ; Thu,  9 Jul 2020 12:16:00 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id h19so3640480ljg.13 for ; Thu, 09 Jul 2020 12: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=ird7UDmYDvw/kBjvthG1Ralid6Q2qu7oQASsvox3nok=; b=g7+NGh/RroslV1K2XEzGQAgNN2Pdr2Gcln6gXagSUf1agTOf9cddoMMuvshlWIYyDw gnUAJBkyjROnLmLNIP2RgbikWoS46ftbaafbqZNfrecLs3EmjVQUmBSrhrPXXsoKqiXT +qkXLUk9iRNyxMmWxvFo/6/2f9j+0T9Zb1GjUeToQh0KF8pxTql+qZNDFrDgkjP3Jg+C Aynal3BlM0ZrU9c6DdG5EpJ/0xdvue6Zd5v436Vd5L3QTp0P6jmCPvcIEcAc/Z1XMsvq 2vy13MbMYLt4wY8gZ3TtOFgieiY0/OAbDo95eyE7YFvqDu4/DgqqqKX7nDHO5W+XpHb+ 2ROA==
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=ird7UDmYDvw/kBjvthG1Ralid6Q2qu7oQASsvox3nok=; b=i1v7FDw9gSttzWHweS5f3xg74BcW18DZVQxl1wDMc+YI8a6M8OORT4V7rid33dBABI o2zibUiiIdDbBQhEn0IXpqI77h2hD+xwIk28U7PQXlO7xOodo5PxR8tL7eyfGGgSv+Zp dplyr2ENvTYgWEQZc5DuzlwQklRMOkd5lZJ4I+BYftnhw7lzGLUXCa/OyPyB34frzeUK EeRQ0rUsPoj6FExS935M2rlGV+mQziUlMdubZEHgi6Ro51/2GzXlFyH7ebGvHsPdxkDg dfdf7XSErA9aZC5rM5suZM5CuvP5zSqnkryfrODUErBst8Hm6riej1VFMLMc8A+f1zWe z9OQ==
X-Gm-Message-State: AOAM530uFfyQ4JSHOtsw/vPGVtQ8Bm96U1vL73oqmFNEaBt0p9ko7Pnc r49ShPCsPE1AUAPGXFRuRZLLnRKd0k/ti8EPyHkEUjRmKk8=
X-Google-Smtp-Source: ABdhPJwLR97nkCMbcEGRUvqa9XuV8j2inTGKsl82PjBmDGa1HvCwmchdWMKCgK+sw6zysMNCR5ITZCloaeq8WVvux/4=
X-Received: by 2002:a2e:900a:: with SMTP id h10mr39413127ljg.242.1594322158271;  Thu, 09 Jul 2020 12:15:58 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>  
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 9 Jul 2020 12:15:21 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e6c38005aa070df5"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 09 Jul 2020 19:16:07 -0000

--000000000000e6c38005aa070df5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You are jumping to many conclusions below. Let me break down the proposal
into some bite size chunks.

The developer would like to get some plain text OIDC claims about the user:

    "claims":{
        "oidc": {
            "userinfo" : {
                "name" : { "essential" : true },
                "photo" : { "essential" : false }
            },

The developer would like to get an OIDC ID Token:

    "claims":{
        "oidc": {
            "id_token" : {
                "email"          : { "essential" : true },
                "email_verified" : { "essential" : true }
            }
    }

The developer would like to get an access token to acquire OIDC claims:

"authorizations": {
        "type":"oidc",
        "claims": ["name", "picture"]
    }

The developer would like to get an access token to access photos:

"authorizations": {
        "type":"oauth_scope",
        "scope": "read_photos"*
    }

The developer would like to get some VC claims:

"claims" {
        "vc": {
            "some_vc": "query_mechanism"
        }
}

The developer would like to do all of the above at once:

{
    "authorizations": {
        "userinfo": {
            "type":"oidc",
            "claims": ["name", "picture"]
        },
        "photos": {
            "type":"oauth_scope",
            "scope": "read_photos"
        }
    },
    "claims":{
        "oidc": {
            "id_token" : {
                "email"          : { "essential" : true },
                "email_verified" : { "essential" : true }
            },
            "userinfo" : {
                "name" : { "essential" : true },
                "photo" : { "essential" : false }
            }
        },
    "vc": {
        "some_vc": "query_mechanism"
        }
    }
}

In the results, the developer gets claims back in the response claims
object, and access tokens etc. back in the authorizations object. Just
because an access token returns claims, it is still an access token.

Yes, the developer can't get a single access token that can both acquire
OIDC claims, and access photos (there are separate tokens for each), but I
would argue that separating the access is a positive security property, as
a client component accessing the user profile has a token independent of
the client component accessing photos. And at the AS, there is no
requirement for the userinfo endpoint to take the same token as the photo
endpoint.

Somewhat of a tangent, I'm thinking that

    "claims":{
        "oidc": {
            "id_token" : {},
            "userinfo" : {}
        },

is a little verbose, and:

    "claims":{
        "oidc_token": {},
        "oidc_info": {}
    },

works better and makes it easier to distinguish support for ID tokens vs
plain claims.

wrt. my position on reusing OIDC -- it has not changed. I have viewed the
OIDC claims as the "query language". No need to reinvent that. We are
creating a new protocol, so no need to use the OAuth or OIDC protocols.

* OAuth scopes could be a space separates string to be consistent with
OAuth 2, or an array of strings so that it is more JSON like. I have no
strong opinion.

scope.split(' ').forEach()

is not that much more complex than

scope.forEach()



On Thu, Jul 9, 2020 at 8:39 AM Justin Richer  wrote:

> But this approach doesn=E2=80=99t keep things in their respective contain=
ers =E2=80=94
> you=E2=80=99ve explicitly got =E2=80=9Cclaims=E2=80=9D underneath the =E2=
=80=9Cauthorizations=E2=80=9D header, and
> you=E2=80=99ve got items that come back as rights associated with the acc=
ess token
> (which should be =E2=80=9Cauthorizations=E2=80=9D) in the =E2=80=9Cuserin=
fo=E2=80=9D section under the
> =E2=80=9Cclaims=E2=80=9D header. And as far as I can tell, these two sect=
ions are redundant
> to each other. Everything is everywhere.
>
> Additionally, this approach and syntax makes it difficult to combine
> different kinds of requests into one. One of OpenID Connect=E2=80=99s big=
gest
> draws, as I=E2=80=99m sure you recall, is that it could be combined with =
a request
> for non-OIDC resources. This was the real innovation that Twitter and
> Facebook=E2=80=99s identity APIs brought, access to more than just authen=
tication,
> and what Google had tried to replicate with the awkward OpenID 2 + OAuth =
1
> hybrid system. Taking a step back from the existing solutions of OpenID 2
> and OAuth 1 let us, as the community, see the value in the pattern that
> became OIDC on top of OAuth 2.
>
> Sure, you could say that the =E2=80=9Coidc=E2=80=9D type also can allow a=
 =E2=80=9Cscopes=E2=80=9D
> parameter, but what about a RAR style object, then? And what about when
> someone comes up with some new way to request access rights, or a VC-base=
d
> query language? Does every =E2=80=9Ctype=E2=80=9D need to now know about =
every other =E2=80=9Ctype=E2=80=9D
> in order for an AS to be able to figure out how they go together? This
> seems like the protocol definition limiting what combinations the AS can
> handle, or what an RS might want to use.
>
> My stance is that GNAP should have a way to query for rights in the acces=
s
> token (=E2=80=9Cauthorizations=E2=80=9D in xauth parlance) and identifier=
s for the user
> (=E2=80=9Cclaims=E2=80=9D in xauth parlance), and anything else should be=
 an extension with
> potentially different models. The AS would process the =E2=80=9Cauthoriza=
tions=E2=80=9D
> equivalent (for the access token) alongside any other incoming query and
> then make a policy decision based on that.
>
> I find it interesting that you are now saying we don=E2=80=99t need to us=
e the
> OIDC request format when previously you=E2=80=99ve made it clear that you=
 were in
> favor of pointing at external query languages, including their syntax. I=
=E2=80=99m
> glad to see that you=E2=80=99re now looking at things in a more flexible =
way, but I
> think it=E2=80=99s important that we be careful and conscientious about h=
ow we
> reference any external query languages in GNAP.
>
>  =E2=80=94 Justin
>
> On Jul 8, 2020, at 6:55 PM, Dick Hardt  wrote:
>
> Hey Justin,
>
> Just because we are using OIDC claims, does not mean we need to mimic the
> OIDC request and response.
> I was envisioning a grant request could look as the following (using XAut=
h
> syntax):
>
> {
>     "authorizations": {
>         "type":"oidc",
>         "claims": ["name", "picture"]
>     },
>     "claims":{
>         "oidc": {
>             "id_token" : {
>                 "email"          : { "essential" : true },
>                 "email_verified" : { "essential" : true }
>             },
>             "userinfo" : {
>                 "name"           : { "essential" : true },
>                 "picture"        : null
>             }
>         }
>     }
> }
>
> Of course a developer could choose to only ask for a subset of this.
>
> Note the new authorization type of "oidc", that takes "claims" rather tha=
n
> "scope".
>
> This keeps all the authorizations and claims in their respective request
> and response containers.
>
> We had a thread months ago on the OIDC two stage model, and I still fail
> to see why forcing that has any advantage.
>
> /Dick
>
>
> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer  wrote:
>
>> I=E2=80=99m glad that we can agree that there are a number of things in =
legacy
>> protocols that are unfortunate side effects of the circumstances in whic=
h
>> they were built. Space-separated scope strings, for instance, would fall=
 in
>> that category, as I=E2=80=99ve previously explained.
>>
>> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request alre=
ady mixes user
>> claims (returned in an API) and authorization (to fetch user claims from=
 an
>> API), so that ship has sailed if you=E2=80=99re using it. It doesn=E2=80=
=99t make sense to
>> have it under a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorizations=E2=
=80=9D request, since it=E2=80=99s a query
>> language that affects both. Maybe you=E2=80=99d call this another =E2=80=
=9Cunfortunate
>> design=E2=80=9D, but the context was about re-using an externally-define=
d query
>> language that was not made for GNAP.
>>
>> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=
=9D and wants to
>> keep using it. (The vast majority of OIDC implementations, in my
>> experience, don=E2=80=99t use that feature, and it=E2=80=99s not even re=
quired to be
>> implemented by the AS, but again we=E2=80=99re talking about using this =
feature as
>> an example of an external query language =E2=80=94 and there are others =
out there.)
>> In GNAP, you should return claims directly in the response, and request
>> specific elements from the APIs protected by the access token. These are
>> separate things, and by design both XAuth and XYZ have put them into
>> separate containers in the request. This is a good design, and so puttin=
g
>> something that conflates these two aspects into one or the other of the
>> containers is not a particularly good option, in my opinion.
>>
>> Additionally, though this is a bit of an aside and getting into the
>> specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is=
 a query language
>> bound to the full user profile. It is my stated position that the items
>> coming back from the AS should only be identifiers, and not full profile
>> information. The reasoning is pretty simple: the client doesn=E2=80=99t =
know what
>> profile information it needs until it knows who the user is, so putting
>> that into a protected API like the UserInfo Endpoint makes much more sen=
se
>> than putting it into the immediate response, where it is not needed,
>> because the client already knows it. The AS doesn=E2=80=99t know what th=
e client
>> needs to know, either, so it can=E2=80=99t determine what to fulfill. OI=
DC=E2=80=99s
>> two-stage model makes sense, and GNAP should really only focus on enabli=
ng
>> this.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 8, 2020, at 6:10 PM, Dick Hardt  wrote:
>>
>>
>>
>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer  wrote:
>>
>>> On Jul 8, 2020, at 3:16 PM, Dick Hardt  wrote:
>>>
>>>
>>> I think representing the request as an array is simplistic, and
>>> complicated at the same time.
>>>
>>> On the simplistic front, as there is no clear mechanism for extending
>>> the request with properties that apply to all of the request.
>>>
>>>
>>> The elements of the array are taken as a set, to be tied to the same
>>> resulting access token. If one of those elements is defined, by the AS
>>> and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some o=
r all of the other
>>> elements, then that=E2=80=99s up to the AS=E2=80=99s policy. Much like =
the =E2=80=9Copenid=E2=80=9D scope
>>> in OIDC, which switches on all sorts of contextual stuff in the request=
. So
>>> to handle something like this, an AS can easily declare that a given
>>> scope-style string or a given object property applies to different part=
s of
>>> the request. You don=E2=80=99t need to externalize it here.
>>>
>>
>> I view the "openid" scope as an unfortunate design as OIDC was
>> constrained by building on top of OAuth. (a problem I hoped to avert by
>> having "identity" in scope for GNAP) The "openid" scope does not functio=
n
>> as scope per se, and I think it makes OIDC harder to understand as the
>> "openid" scope causes non-scope behavior.
>>
>>
>>
>>>
>>> Do you have a concrete use case that requires that feature to be done i=
n
>>> the way that you describe? I am trying to separate the driving use case
>>> from the proposed solutions to see what the differences are.
>>>
>>
>> Perhaps the client wants access to be HIPPA compliant? The HIPPA
>> compliance signal applies to the scopes.
>>
>> Adding other properties to an object is a well understood extension
>> mechanism. Adding an additional element to an array that does not act li=
ke
>> the other elements seems like a hack.
>>
>>
>>
>>>
>>>
>>> Using JSON type polymorphism requires the AS to test each member of the
>>> array to determine if it is a string or an object. Only after detecting=
 a
>>> RAR object does the AS know the client is making a RAR request.
>>>
>>>
>>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole re=
sources request
>>> in order to figure out what the client is asking for, anyway, whether i=
t=E2=80=99s
>>> by strings or objects or whatever else might be defined by an extension=
. Is
>>> there an argument for having an AS do an early dispatch on a request be=
fore
>>> it=E2=80=99s fully parsed everything?
>>>
>>
>> Let me clarify, the code is looking at the type of object that has been
>> parsed.
>>
>> Determining if an item in an array is a scope or a RAR object by looking
>> at the type being either a string or an object seems less clear than a
>> property of an object explicitly declaring the type.
>>
>>
>>
>>>
>>> This also limits the request to be composed only of scope strings or RA=
R
>>> objects. I don't see how other strings or objects could be used in the
>>> array, so there is no clear extension point in the "resources" array fo=
r
>>> other query mechanisms.
>>>
>>>
>>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring th=
at a string has
>>> to be an OAuth2-style scope. It can be, but ultimately it=E2=80=99s jus=
t a string
>>> that the AS can understand. And the objects are just that =E2=80=94 obj=
ects. If the
>>> AS understands what the object is, it can be a RAR object or it can be
>>> something completely API-specific with another query language entirely.
>>>
>>
>> But the other query language would need a type that has been reserved in
>> the RAR name space for there to be interop, so it effectively is a RAR
>> extension.
>>
>> There are query languages in other domains that may not fit nicely into
>> RAR such as a query for medical records.
>>
>> Yes, the medical records could be yet another top level property, but pe=
r
>> below, I think that is confusing.
>>
>>
>>> (Point, though: RAR already pretty much allows this by letting them be
>>> extended infinitely, a feature it inherits from XYZ)
>>>
>>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99s=
 an array of
>>> strings or objects and each of those means the same thing, =E2=80=9Csom=
ething the
>>> client is asking for=E2=80=9D.
>>>
>>>
>>> Just as RAR has a "type" property, I propose the "resources"
>>> ("authorizations" in XAuth) be an object, where the other properties ar=
e
>>> determined by the "type" property. This allows extensions to define new
>>> ways to query for an authorization rather than having to fit into scope=
s or
>>> RAR.
>>>
>>>
>>> It=E2=80=99s my stance that this is an unnecessary limitation at this l=
evel. The
>>> objects within the array should be typed, like RAR, but it doesn=E2=80=
=99t make
>>> sense for the overall request to be typed. Instead, there should be one
>>> =E2=80=9Ctype" of query in the core, what XYZ calls the =E2=80=9Cresour=
ces=E2=80=9D request. Other
>>> query languages should be added as extensions either to the RAR-style
>>> objects (by defining a type at that level) or as a separate top-level
>>> member.
>>>
>>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D query=
 language. My current
>>> thought is that this really shouldn=E2=80=99t be a part of the =E2=80=
=9Cresources=E2=80=9D or
>>> =E2=80=9Cclaims=E2=80=9D part of the request, but instead as its own to=
p-level member, like
>>> it is in the OIDC protocol today. The main reason for this is the natur=
e of
>>> the OIDC claims language: it specifies targets for the resulting data, =
and
>>> those targets cross different ways to return things. So it doesn=E2=80=
=99t actually
>>> affect just resources like the UserInfo Endpoint, or the ID Token, but =
both
>>> and potentially others out there. If your system supported such an
>>> extension, it could theoretically forego both the built-in =E2=80=9Ccla=
ims=E2=80=9D and
>>> =E2=80=9Cresources=E2=80=9D parts of the request, and use the =E2=80=9C=
oidc_claims_query=E2=80=9D member
>>> (or whatever it would be called). This would let such an extension use =
the
>>> OIDC claims processing mechanism as it is today.
>>>
>>> To me, this remains much more understandable, extensible, and clean.
>>>
>>
>> While this may be more understandable to a developer just porting an app
>> OIDC that only wants OIDC results, but I think it is more complicated as
>> soon as the developer wants other results, which is likely what prompted
>> the developer to use GNAP instead of ODIC.
>>
>> I think it is easier to understand if all the claims are in one
>> container, and all the authorizations are in another container.
>>
>> If a developer wants access to some resources, some claims, and an OpenI=
D
>> Token, they are having to use "claims", "resources", and
>> "oidc_claims_query".  Now the claims and access tokens are spread across
>> multiple containers. There are some claims in the "claims" container, an=
d
>> some "claims" in the "oidc_claims_query" container. And is the access to=
ken
>> response in "oidc_claims_query" the same as an access token response in
>> "resources"? It would seem simpler if they were, and if all the access
>> tokens came back in the same container.
>>
>> Per Aaron's post that you have referred to, the developer can get sme
>> bare claims directly in the response in the "claims" object, an ID Token
>> that has the same or different claims, and if they want, an access token
>> that they can call a user_info endpoint to get the same, or different
>> claims.
>>
>> For example, an enterprise app client may want an ID Token with the emai=
l
>> address, bare claims for the user's name and a URI to a profile photo, a=
nd
>> an access token to query which groups a user belongs to.
>>
>> We are still re-using the OIDC claims, but we are not mixing claims and
>> authorizations.
>>
>> /Dick
>>
>>
>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
>> =E1=90=A7
>>
>>
>> =E1=90=A7
>
>
> =E1=90=A7

--000000000000e6c38005aa070df5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


You are=
 jumping to many conclusions below. Let me break down the proposal into som=
e bite size chunks.

The developer would like to ge=
t some plain text OIDC claims about the user:

=C2=
=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "oidc&q=
uot;: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "userinfo" :=
 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name&qu=
ot; : { "essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "photo" : { "essential" : fals=
e }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },

The developer would like to get an OIDC ID Token:

=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu=
ot;oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id_toke=
n" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &quo=
t;email" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "essential" :=
 true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "e=
mail_verified" : { "essential" : true }
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }

The developer would like to get an access token to acquire OIDC clai=
ms:

"authorizati=
ons": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type":"oidc&q=
uot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "claims": ["name",=
 "picture"]
=C2=A0 =C2=A0 }

The developer would like to get an access token to access=
 photos:

"authorizations&quo=
t;: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type":"oauth_scope&q=
uot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": "read_photos&q=
uot;*
=C2=A0 =C2=A0 }

The developer would like =
to get some VC claims:

"claims" {
<=
div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "vc": {
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "some_vc": "query_mechanism&=
quot;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
}

=

The developer would like to do all of the above at once:
{
=C2=A0 =C2=A0 "authorizations": {
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "userinfo": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "type":"oidc",
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "claims": ["name", "picture&q=
uot;]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &quo=
t;photos": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type&q=
uot;:"oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
"scope": "read_photos"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }=

=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 "oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 "id_token" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "email" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { &=
quot;essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 "email_verified" : { "essential" : true =
}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "userinfo" : {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name" : { "essential" =
: true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
photo" : { "essential" : false }
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 &quo=
t;vc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "some_vc": "que=
ry_mechanism"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } =C2=A0 
=C2=A0 =C2=
=A0 }
}

In the results, the developer gets =
claims back in the response claims object, and access tokens etc. back in t=
he authorizations object. Just because an access token returns claims, it i=
s still an access token.

Yes, the developer=C2=A0c=
an't get a single access token that can both acquire OIDC claims, and a=
ccess photos (there are separate tokens for each), but I would argue that s=
eparating the access is a positive security property, as a client component=
 accessing the user profile has a token independent of the client component=
 accessing photos. And at the AS, there is no requirement for the userinfo =
endpoint to take the same token as the photo endpoint.

=

Somewhat of a tangent, I'm thinking that=C2=A0

=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu=
ot;oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id_toke=
n" : {},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "userinfo&q=
uot; : {}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },

is a little verbose, and=
:

=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 "oidc_token": {},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "oid=
c_info": {}
=C2=A0 =C2=A0 },

works bet=
ter and makes it easier to distinguish=C2=A0support for ID tokens vs plain =
claims.

wrt. my position on reusing OIDC -- it has=
 not changed. I have viewed the OIDC claims as the "query language&quo=
t;. No need to reinvent that. We are creating a new protocol, so no need to=
 use the OAuth or OIDC protocols.

* OAuth sco=
pes could be a space separates string to be consistent with OAuth 2, or an =
array of strings so that it is more JSON like. I have no strong opinion.=C2=
=A0

scope.split(' ').forEach()=C2=A0=


is not that much more complex than=C2=A0

scope.forEach()



On Thu, Jul 9=
, 2020 at 8:39 AM Justin Richer <jric=
her@mit.edu> wrote:
But this approach=
 doesn=E2=80=99t keep things in their respective containers =E2=80=94 you=
=E2=80=99ve explicitly got =E2=80=9Cclaims=E2=80=9D underneath the =E2=80=
=9Cauthorizations=E2=80=9D header, and you=E2=80=99ve got items that come b=
ack as rights associated with the access token (which should be =E2=80=9Cau=
thorizations=E2=80=9D) in the =E2=80=9Cuserinfo=E2=80=9D section under the =
=E2=80=9Cclaims=E2=80=9D header. And as far as I can tell, these two sectio=
ns are redundant to each other. Everything is everywhere.=C2=A0
<=
br>
Additionally, this approach and syntax makes it difficult to =
combine different kinds of requests into one. One of OpenID Connect=E2=80=
=99s biggest draws, as I=E2=80=99m sure you recall, is that it could be com=
bined with a request for non-OIDC resources. This was the real innovation t=
hat Twitter and Facebook=E2=80=99s identity APIs brought, access to more th=
an just authentication, and what Google had tried to replicate with the awk=
ward OpenID 2 + OAuth 1 hybrid system. Taking a step back from the existing=
 solutions of OpenID 2 and OAuth 1 let us, as the community, see the value =
in the pattern that became OIDC on top of OAuth 2.=C2=A0

Sure, you could say that the =E2=80=9Coidc=E2=80=9D type also can al=
low a =E2=80=9Cscopes=E2=80=9D parameter, but what about a RAR style object=
, then? And what about when someone comes up with some new way to request a=
ccess rights, or a VC-based query language? Does every =E2=80=9Ctype=E2=80=
=9D need to now know about every other =E2=80=9Ctype=E2=80=9D in order for =
an AS to be able to figure out how they go together? This seems like the pr=
otocol definition limiting what combinations the AS can handle, or what an =
RS might want to use.

My stance is that GNAP shoul=
d have a way to query for rights in the access token (=E2=80=9Cauthorizatio=
ns=E2=80=9D in xauth parlance) and identifiers for the user (=E2=80=9Cclaim=
s=E2=80=9D in xauth parlance), and anything else should be an extension wit=
h potentially different models. The AS would process the =E2=80=9Cauthoriza=
tions=E2=80=9D equivalent (for the access token) alongside any other incomi=
ng query and then make a policy decision based on that.

I find it interesting that you are now saying we don=E2=80=99t need t=
o use the OIDC request format when previously you=E2=80=99ve made it clear =
that you were in favor of pointing at external query languages, including t=
heir syntax. I=E2=80=99m glad to see that you=E2=80=99re now looking at thi=
ngs in a more flexible way, but I think it=E2=80=99s important that we be c=
areful and conscientious about how we reference any external query language=
s in GNAP.

=C2=A0=E2=80=94 Justin

On Jul 8, 2020, at 6:55 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey Justin,
Just because=C2=A0we are using OIDC claims, does not mean=
 we need to mimic the OIDC request and response.
I was envisionin=
g a grant request could look as the following (using XAuth syntax):

{
=C2=A0 =C2=A0 "authorizations": {
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "type":"oidc",
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "claims": ["name", "picture"]=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "id_token" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "email" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "=
;essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 "email_verified" : { "essential" : true }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "userinfo" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "name" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 : { "essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "picture" =C2=A0 =C2=A0 =C2=A0 =C2=A0=
: null
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 }
=C2=A0 =C2=A0 }
}

Of =
course a developer could choose to only ask for a subset of this.

Note the new authorization type of "oidc", that t=
akes "claims" rather than "scope".=C2=A0

=

This keeps all the authorizations and claims in their respective=
 request and response containers.

We had a thread =
months ago on the OIDC two stage model, and I still fail to see why forcing=
 that has any advantage.=C2=A0

/Dick

On Wed, Jul 8, 2020 at 3:25 PM Justin Richer <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">
I=E2=80=99m glad that=
 we can agree that there are a number of things in legacy protocols that ar=
e unfortunate side effects of the circumstances in which they were built. S=
pace-separated scope strings, for instance, would fall in that category, as=
 I=E2=80=99ve previously explained.

A key point in the b=
elow: the OIDC =E2=80=9Cclaims=E2=80=9D request already mixes user claims (=
returned in an API) and authorization (to fetch user claims from an API), s=
o that ship has sailed if you=E2=80=99re using it. It doesn=E2=80=99t make =
sense to have it under a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorization=
s=E2=80=9D request, since it=E2=80=99s a query language that affects both. =
Maybe you=E2=80=99d call this another =E2=80=9Cunfortunate design=E2=80=9D,=
 but the context was about re-using an externally-defined query language th=
at was not made for GNAP.

My scenario was for someone wh=
o is already using =E2=80=9Cclaims=E2=80=9D and wants to keep using it. (Th=
e vast majority of OIDC implementations, in my experience, don=E2=80=99t us=
e that feature, and it=E2=80=99s not even required to be implemented by the=
 AS, but again we=E2=80=99re talking about using this feature as an example=
 of an external query language =E2=80=94 and there are others out there.) I=
n GNAP, you should return claims directly in the response, and request spec=
ific elements from the APIs protected by the access token. These are separa=
te things, and by design both XAuth and XYZ have put them into separate con=
tainers in the request. This is a good design, and so putting something tha=
t conflates these two aspects into one or the other of the containers is no=
t a particularly good option, in my opinion.=C2=A0

Additionally, though this is a bit of an aside and getting into the specif=
ics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is a query =
language bound to the full user profile. It is my stated position that the =
items coming back from the AS should only be identifiers, and not full prof=
ile information. The reasoning is pretty simple: the client doesn=E2=80=99t=
 know what profile information it needs until it knows who the user is, so =
putting that into a protected API like the UserInfo Endpoint makes much mor=
e sense than putting it into the immediate response, where it is not needed=
, because the client already knows it. The AS doesn=E2=80=99t know what the=
 client needs to know, either, so it can=E2=80=99t determine what to fulfil=
l. OIDC=E2=80=99s two-stage model makes sense, and GNAP should really only =
focus on enabling this.

=C2=A0=E2=80=94 Justin

On Jul 8, 2020, at 6:10 PM, =
Dick Hardt <di=
ck.hardt@gmail.com> wrote:



On Wed, Jul 8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at 3:16 =
PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I think representing the request as=
 an array is simplistic, and complicated at the same time.

On the simplistic front, as there is no clear mechanism for extending th=
e request with properties that apply to all of the request.=C2=A0

The elements of the array ar=
e taken as a set, to be tied to the same resulting access token. If one of =
those elements is defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s p=
rotecting, to apply across some or all of the other elements, then that=E2=
=80=99s up to the AS=E2=80=99s policy. Much like the =E2=80=9Copenid=E2=80=
=9D scope in OIDC, which switches on all sorts of contextual stuff in the r=
equest. So to handle something like this, an AS can easily declare that a g=
iven scope-style string or a given object property applies to different par=
ts of the request. You don=E2=80=99t need to externalize it here.

I view the "openid" scop=
e as an unfortunate design as OIDC was constrained by building=C2=A0on top =
of OAuth. (a problem I hoped to avert by having "identity" in sco=
pe for GNAP) The "openid" scope does not function as scope=C2=A0p=
er se, and I think it makes OIDC harder to understand as the "openid&q=
uot; scope causes non-scope behavior.=C2=A0

=C2=A0=


=

Do you have a concrete use case that requires that feature to be=
 done in the way that you describe? I am trying to separate the driving use=
 case from the proposed solutions to see what the differences are.=C2=A0

Perhaps the client wants ac=
cess to be HIPPA compliant? The HIPPA compliance signal applies to the scop=
es.

Adding other properties to an object is a well=
 understood extension mechanism. Adding an additional element to an array t=
hat does not act like the other elements seems like a hack.

<=
/div>
=C2=A0


Using JSON type polymorphism=C2=A0requires =
the AS to test each member of the array to determine if it is a string or a=
n object. Only after detecting a RAR object does the AS know the client is =
making a RAR request.=C2=A0

That=E2=80=99s correct =E2=80=94 but the AS needs to =
parse the whole resources request in order to figure out what the client is=
 asking for, anyway, whether it=E2=80=99s by strings or objects or whatever=
 else might be defined by an extension. Is there an argument for having an =
AS do an early dispatch on a request before it=E2=80=99s fully parsed every=
thing?

Let me clarify, th=
e code is looking at the type of object that has been parsed.=C2=A0

Determining if an item in an array is a scope or a RAR ob=
ject by looking at the type being either a string or an object seems less c=
lear than a property of an object explicitly declaring the type.
=

=C2=A0

This also limits the request to be composed only of scope st=
rings or RAR objects. I don't see how other strings or objects could be=
 used in the array, so there is no clear extension point in the "resou=
rces" array for other query mechanisms.

That=E2=80=99s not the case in XYZ since we aren=
=E2=80=99t declaring that a string has to be an OAuth2-style scope. It can =
be, but ultimately it=E2=80=99s just a string that the AS can understand. A=
nd the objects are just that =E2=80=94 objects. If the AS understands what =
the object is, it can be a RAR object or it can be something completely API=
-specific with another query language entirely.

But the other query language would need a type that =
has been reserved in the RAR name space for there to be interop, so it effe=
ctively is a RAR extension.

There are query langua=
ges in other domains that may not fit nicely into RAR such as a query for m=
edical records.

Yes, the medical records could be =
yet another top level property, but per below, I think that is confusing.
=C2=A0
(Point, though: RAR already pretty much allows this by letting t=
hem be extended infinitely, a feature it inherits from XYZ)

<=
/div>
I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=
=80=99s an array of strings or objects and each of those means the same thi=
ng, =E2=80=9Csomething the client is asking for=E2=80=9D.


Just as RAR has a "type" property, I propose the "resource=
s" ("authorizations" in XAuth) be an object, where the other=
 properties are determined by the "type" property. This allows ex=
tensions to define new ways to query for an authorization rather than havin=
g to fit into scopes or RAR.


It=E2=80=99s my stance that this is an unnecessary=
 limitation at this level. The objects within the array should be typed, li=
ke RAR, but it doesn=E2=80=99t make sense for the overall request to be typ=
ed. Instead, there should be one =E2=80=9Ctype" of query in the core, =
what XYZ calls the =E2=80=9Cresources=E2=80=9D request. Other query languag=
es should be added as extensions either to the RAR-style objects (by defini=
ng a type at that level) or as a separate top-level member.

<=
/div>
For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D=
 query language. My current thought is that this really shouldn=E2=80=99t b=
e a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D par=
t of the request, but instead as its own top-level member, like it is in th=
e OIDC protocol today. The main reason for this is the nature of the OIDC c=
laims language: it specifies targets for the resulting data, and those targ=
ets cross different ways to return things. So it doesn=E2=80=99t actually a=
ffect just resources like the UserInfo Endpoint, or the ID Token, but both =
and potentially others out there. If your system supported such an extensio=
n, it could theoretically forego both the built-in =E2=80=9Cclaims=E2=80=9D=
 and =E2=80=9Cresources=E2=80=9D parts of the request, and use the =E2=80=
=9Coidc_claims_query=E2=80=9D member (or whatever it would be called). This=
 would let such an extension use the OIDC claims processing mechanism as it=
 is today.

To me, this remains much more understan=
dable, extensible, and clean.

=

While this may be more understandable to a developer just=C2=A0porting=
 an app OIDC that only wants OIDC results, but I think it is more complicat=
ed as soon as the developer wants other results, which is likely what=C2=A0=
prompted the developer to use GNAP instead of ODIC.

I think it is easier to understand if all the claims are in one container=
, and all the authorizations are in another container.

=

If a developer wants access to some resources, some claims, and an Ope=
nID Token, they are having to use "claims", "resources"=
, and "oidc_claims_query".=C2=A0 Now the claims and access tokens=
 are spread across multiple containers. There are some claims in the "=
claims" container, and some "claims" in the "oidc_claim=
s_query" container. And is the access token response in=C2=A0"oid=
c_claims_query" the same as an access token response in "resource=
s"? It would seem simpler if they were, and if all the access tokens c=
ame back in the same container.

Per Aaron's po=
st that you have referred to, the developer can get sme bare claims directl=
y in the response in the "claims" object, an ID Token that has th=
e same or different claims, and if they want, an access token that they can=
 call a user_info endpoint to get the same, or different claims.
=

For example, an enterprise app client may want an ID Token w=
ith the email address, bare claims for the user's name and a URI to a p=
rofile photo, and an access token to query which groups a user belongs to.<=
/div>

We are still re-using=C2=A0the OIDC claims, but we=
 are not mixing claims and authorizations.

3D""=E1=90=A7

3D""=E1=90=A7


3D""=E1=90=A7


--000000000000e6c38005aa070df5--


From nobody Thu Jul  9 12:17: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 62FA93A0E26 for ; Thu,  9 Jul 2020 12:17:52 -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 ou8A1LaNWTq5 for ; Thu,  9 Jul 2020 12:17:47 -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 785663A0E22 for ; Thu,  9 Jul 2020 12:17:47 -0700 (PDT)
Received: from [192.168.1.7] (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 069JHiIw020761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jul 2020 15:17:44 -0400
From: Justin Richer 
Message-Id: <69082870-1A99-4912-95EA-D1B7A1C967E5@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EBFFBF87-B018-494A-BFB1-ED159AED9724"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 9 Jul 2020 15:17:44 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 09 Jul 2020 19:17:52 -0000

--Apple-Mail=_EBFFBF87-B018-494A-BFB1-ED159AED9724
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Jul 9, 2020, at 2:32 PM, Dick Hardt  wrote:
>=20
> Looks like you missed the point of my code example, as your response =
is focussed on the aspects I had in comments, so let me clarify.=20

The point seemed to be about the overall complexity and readability, and =
that=E2=80=99s what I responded to.

>=20
> This line (which is determining the type of the item in the array):
>=20
> if (typeof item =3D=3D=3D string')
>=20
> is implicitly stating that the item is an oauth scope.

No, it is not. It is saying that it is a resource request represented as =
a string. One way to represent a resource request as a string is an =
OAuth 2 style scope. And if you=E2=80=99re building up from an existing =
OAuth 2 system, then you could use a scope there. But that=E2=80=99s not =
the same as stating =E2=80=9Cthe item is a scope=E2=80=9D. In my =
examples, I had been trying to use the terminology that you were using, =
but I=E2=80=99m afraid that made things more unclear.

> Whereas it is explicit in this statement
>=20
> if (authorizations.type =3D=3D=3D 'oauth_scope')
>=20
> which I think it easier to understand what is happening (in my opinion =
of course).
>=20
> XYZ has types, they are just implicit. RAR has explicit types, and =
that does not look to be holding back RAR. I don't understand why you =
think having explicit types will hold us back.

The =E2=80=9Ctype=E2=80=9D in RAR is a name spacing device to allow =
extensibility in different aspects of the request. This is at a lower =
layer than how they=E2=80=99re being applied here, and it therefore =
makes more sense at that layer. It=E2=80=99s a way for a particular API =
to define the dimensions that it cares about in its request. It=E2=80=99s =
not really an even comparison.

> Do you want to let the string and object be anything the AS and RS =
decide they could mean?

Yes. Just like the AS can decide that an OAuth scope could mean any =
number of things.

> That would make GNAP more of a framework than a protocol, and a key =
aspect of the request would be undefined.

I don=E2=80=99t see how this would make things a framework and not a =
protocol. We=E2=80=99re not debating the ability to send a set of =
strings or a set of objects to the AS, which the AS will interpret in =
the request. We=E2=80=99re debating the syntax for sending those values.

>=20
> My thoughts have not shifted on "types" in interactions. I just =
changed the name to 'mode'. I did shift my thinking that a negotiation =
of interaction modes is useful, and added that.

The important shift is the removal of a single =E2=80=9Ctype=E2=80=9D =
field that meant you could only send one thing at a time, and now you =
can send multiple things in various combinations as need allows. =
That=E2=80=99s the kind of thing that I=E2=80=99m saying is problematic =
here as well, for many of the same reasons.

>=20
> We still have an unfinished discussion there. When you have a chance, =
would you respond to that thread?

I believe the thread you=E2=80=99re referring to was commented on by =
several people, including an AD, as not being a helpful conversation for =
the group. I stopped responding to that thread when that was brought up, =
in order to respect that position and hopefully move the conversation =
along. I=E2=80=99m beginning to think that this conversation thread is =
itself going off the rails in a similar way, since we seem to be =
repeating things at each other. It=E2=80=99s become a comparison of =
solutions in detail and not a discussion of what the driving use cases =
are. I understand that you think your proposal is better, and I disagree =
and have pointed out what I see as several major flaws in it.

My goal here isn=E2=80=99t to convince you as an individual that I=E2=80=99=
m right. My goal here is to present my ideas and explain the thought =
process behind them so that we all, as a group, can make the best =
decisions going forward based on that.=20

 =E2=80=94 Justin

>=20
> /Dick
>=20
> On Thu, Jul 9, 2020 at 8:39 AM Justin Richer > wrote:
> Declarations of which code is =E2=80=9Ceasier to understand=E2=80=9D =
are going to be subjective, and I don=E2=80=99t agree with your =
conclusions even with your examples. Even so, I don=E2=80=99t think that =
the examples you give are a good comparison. While it is of course =
possible to implement things like you have below, I think it=E2=80=99s =
indicative of thinking of things in terms of a =E2=80=9Cresource request =
type=E2=80=9D. What I=E2=80=99ve been trying to argue is that there =
shouldn=E2=80=99t be a =E2=80=9Ctype=E2=80=9D, that there should just be =
slightly different ways to do a resource request. So the code is more =
like:
>=20
> resourcesRequested =3D requests.map( item =3D> {
>    if (typeof item =3D=3D =E2=80=98object=E2=80=99) {
>       return new RarStyleResourceRequest(item);
>    } else if (typeof item =3D=3D =E2=80=9Cstring=E2=80=9D) {
>      return new StringStyleResourceRequest(item);
>    }
> });
> processResources(resourcesRequested);
>=20
> Each of these =E2=80=9C*ResourceRequest=E2=80=9D objects would be =
something that the AS can use to decide what to put into the access =
token. Although you=E2=80=99d probably put that complexity into a =
factory constructor or something instead of a map function, this shows =
the kind of dispatch you can do based on type if you=E2=80=99re doing it =
by hand. You collect everything in the array, and turn it into an object =
that represents =E2=80=9Ca request for a resource that gets tied to an =
access token=E2=80=9D. And then you process the request based on the =
collection of resource requests. Each string-based request points to =
some set of policies, as does each object-based request. You can even =
imagine that instead of creating a separate string-based request, you =
use that string to look up a policy in a policy engine to be applied =
later.
>=20
> The AS then has to figure out, as it always does, what to do with this =
collection. And if you want to do an early escape on object style =
requests, you could just throw an error when you detect that. Or, you =
just ignore that part of the request. In fact, here=E2=80=99s the code I =
wrote that handles it exactly that way, while processing the JSON by =
hand in Java on a legacy OAuth 2 server:
>=20
>=20
> JsonArray resources =3D json.get("resources").getAsJsonArray();     =20=

> Set scopes =3D StreamSupport.stream(resources.spliterator(), =
false)
> 	.filter( e -> e.isJsonPrimitive() ) // filter out anything =
that's not a handle     =20
> 	.map( e -> e.getAsString() )     =20
> 	.collect(Collectors.toSet());     =20
> tx.setScope(scopes);
>=20
>=20
> Furthermore, your XAuth example doesn=E2=80=99t go to the same depth =
as the XYZ example, which leads to a false comparison. In your =
=E2=80=9Cprocess scope=E2=80=9D you would need to parse the =E2=80=9Cscope=
=E2=80=9D string to split on spaces, and then have another loop to =
process each scope. For the =E2=80=9Cprocess details=E2=80=9D you=E2=80=99=
d need to iterate over the array at the root of a RAR-style request and =
process each piece. In the XYZ code, you=E2=80=99ve got all of that =
already. If you=E2=80=99re going to compare the complexity of code, they =
should at least be shown to the same point of the process.=20
>=20
> On top of that, the fall-through case statement below is really =
limiting. What if the scope processing or RAR objects processing gets =
combined with something else? This kind of premature optimization is not =
something we want to encourage developers to do.=20
>=20
> But ultimately, I think the disconnect is down to thinking about this =
in terms of an explicit =E2=80=9Ctype=E2=80=9D, much the way XAuth used =
to do with the interactions. I=E2=80=99m glad that your thoughts have =
shifted in that space, and I think you should strongly consider the same =
set of arguments here. A lot of the promise of GNAP is getting away from =
this type-field style design, like getting away from OAuth 2=E2=80=99s =
=E2=80=9Cgrant_type=E2=80=9D approach and into something that=E2=80=99s =
focused on interaction and client models instead. This newer model =
allows for better flexibility, better consistency, and better clarity =
throughout. It=E2=80=99s no longer =E2=80=9Cif I see this flag then I go =
down this separate code path and nothing else=E2=80=9D, it=E2=80=99s now =
=E2=80=9Cif I see this item, I go down this code path and then process =
the next item too=E2=80=9D. There=E2=80=99s power in the combinations.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 8, 2020, at 9:31 PM, Dick Hardt > wrote:
>>=20
>> I had intended to provide a code sample comparing XYZ request type =
with XAuth request type
>>=20
>> Let's say an AS only supports OAuth scopes (does not support RAR). =
Here is JS code to check:
>>=20
>> //XYZ code
>> var oauth_scope =3D true;
>> requests.forEach( item =3D> {        =20
>>     if (typeof item =3D=3D=3D "object")
>>         oauth_scope =3D false;
>> });
>> if (!'oauth_scope') {
>>     // return error
>> }
>>=20
>> // XAuth code
>> if ('oauth_scope' !=3D authorizations.type) {
>>    // return error
>> }
>>=20
>> Here is some JS code that for an AS that supports OAuth scopes, RAR, =
and OIDC requests:
>>=20
>> // XYZ
>> if (request) {
>>     requests.forEach( item =3D> {
>>         if (typeof item =3D=3D=3D "object") {
>>             // process a RAR item
>>         } else if(typeof item =3D=3D=3D 'string') {
>>             // process a scope item
>>         } else {
>>             // throw an error
>>         }
>>     })   =20
>>    // process the whole request
>> }
>> if (oidc_claims_query) {
>>     // process oidc request
>> }
>>=20
>> //XAuth
>> if (authorizations) {
>>     switch (authorizations?.type) {
>>         case 'oauth_rar':
>>             // process authorizations.details - RAR=20
>>         case 'oauth_scope':
>>             // process authorizations.scope
>>             // process the whole request
>>             break;
>>         case 'oidc':
>>             // process OIDC claims
>>             break;
>>         default:
>>             // error for unknown type
>>     }
>> }   =20
>>=20
>>=20
>> Understanding what the code is doing looks much clearer in XAuth to =
me.
>>=20
>> =E1=90=A7
>>=20
>> On Wed, Jul 8, 2020 at 3:55 PM Dick Hardt > wrote:
>> Hey Justin,
>>=20
>> Just because we are using OIDC claims, does not mean we need to mimic =
the OIDC request and response.
>> I was envisioning a grant request could look as the following (using =
XAuth syntax):
>>=20
>> {
>>     "authorizations": {
>>         "type":"oidc",
>>         "claims": ["name", "picture"]
>>     },
>>     "claims":{
>>         "oidc": {
>>             "id_token" : {
>>                 "email"          : { "essential" : true },
>>                 "email_verified" : { "essential" : true }
>>             },
>>             "userinfo" : {
>>                 "name"           : { "essential" : true },
>>                 "picture"        : null
>>             }
>>         }
>>     }
>> }
>>=20
>> Of course a developer could choose to only ask for a subset of this.
>>=20
>> Note the new authorization type of "oidc", that takes "claims" rather =
than "scope".=20
>>=20
>> This keeps all the authorizations and claims in their respective =
request and response containers.
>>=20
>> We had a thread months ago on the OIDC two stage model, and I still =
fail to see why forcing that has any advantage.=20
>>=20
>> /Dick
>>=20
>>=20
>> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer > wrote:
>> I=E2=80=99m glad that we can agree that there are a number of things =
in legacy protocols that are unfortunate side effects of the =
circumstances in which they were built. Space-separated scope strings, =
for instance, would fall in that category, as I=E2=80=99ve previously =
explained.
>>=20
>> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request =
already mixes user claims (returned in an API) and authorization (to =
fetch user claims from an API), so that ship has sailed if you=E2=80=99re =
using it. It doesn=E2=80=99t make sense to have it under a =E2=80=9Cclaims=
=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s =
a query language that affects both. Maybe you=E2=80=99d call this =
another =E2=80=9Cunfortunate design=E2=80=9D, but the context was about =
re-using an externally-defined query language that was not made for =
GNAP.
>>=20
>> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=9D=
 and wants to keep using it. (The vast majority of OIDC implementations, =
in my experience, don=E2=80=99t use that feature, and it=E2=80=99s not =
even required to be implemented by the AS, but again we=E2=80=99re =
talking about using this feature as an example of an external query =
language =E2=80=94 and there are others out there.) In GNAP, you should =
return claims directly in the response, and request specific elements =
from the APIs protected by the access token. These are separate things, =
and by design both XAuth and XYZ have put them into separate containers =
in the request. This is a good design, and so putting something that =
conflates these two aspects into one or the other of the containers is =
not a particularly good option, in my opinion.=20
>>=20
>> Additionally, though this is a bit of an aside and getting into the =
specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is =
a query language bound to the full user profile. It is my stated =
position that the items coming back from the AS should only be =
identifiers, and not full profile information. The reasoning is pretty =
simple: the client doesn=E2=80=99t know what profile information it =
needs until it knows who the user is, so putting that into a protected =
API like the UserInfo Endpoint makes much more sense than putting it =
into the immediate response, where it is not needed, because the client =
already knows it. The AS doesn=E2=80=99t know what the client needs to =
know, either, so it can=E2=80=99t determine what to fulfill. OIDC=E2=80=99=
s two-stage model makes sense, and GNAP should really only focus on =
enabling this.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 8, 2020, at 6:10 PM, Dick Hardt > wrote:
>>>=20
>>>=20
>>>=20
>>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer > wrote:
>>> On Jul 8, 2020, at 3:16 PM, Dick Hardt > wrote:
>>>>=20
>>>> I think representing the request as an array is simplistic, and =
complicated at the same time.
>>>>=20
>>>> On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the request.=20=

>>>=20
>>> The elements of the array are taken as a set, to be tied to the same =
resulting access token. If one of those elements is defined, by the AS =
and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some or =
all of the other elements, then that=E2=80=99s up to the AS=E2=80=99s =
policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, which =
switches on all sorts of contextual stuff in the request. So to handle =
something like this, an AS can easily declare that a given scope-style =
string or a given object property applies to different parts of the =
request. You don=E2=80=99t need to externalize it here.
>>>=20
>>> I view the "openid" scope as an unfortunate design as OIDC was =
constrained by building on top of OAuth. (a problem I hoped to avert by =
having "identity" in scope for GNAP) The "openid" scope does not =
function as scope per se, and I think it makes OIDC harder to understand =
as the "openid" scope causes non-scope behavior.=20
>>>=20
>>> =20
>>>=20
>>> Do you have a concrete use case that requires that feature to be =
done in the way that you describe? I am trying to separate the driving =
use case from the proposed solutions to see what the differences are.=20
>>>=20
>>> Perhaps the client wants access to be HIPPA compliant? The HIPPA =
compliance signal applies to the scopes.
>>>=20
>>> Adding other properties to an object is a well understood extension =
mechanism. Adding an additional element to an array that does not act =
like the other elements seems like a hack.
>>>=20
>>> =20
>>>=20
>>>>=20
>>>> Using JSON type polymorphism requires the AS to test each member of =
the array to determine if it is a string or an object. Only after =
detecting a RAR object does the AS know the client is making a RAR =
request.=20
>>>=20
>>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole =
resources request in order to figure out what the client is asking for, =
anyway, whether it=E2=80=99s by strings or objects or whatever else =
might be defined by an extension. Is there an argument for having an AS =
do an early dispatch on a request before it=E2=80=99s fully parsed =
everything?
>>>=20
>>> Let me clarify, the code is looking at the type of object that has =
been parsed.=20
>>>=20
>>> Determining if an item in an array is a scope or a RAR object by =
looking at the type being either a string or an object seems less clear =
than a property of an object explicitly declaring the type.
>>>=20
>>> =20
>>>=20
>>>> This also limits the request to be composed only of scope strings =
or RAR objects. I don't see how other strings or objects could be used =
in the array, so there is no clear extension point in the "resources" =
array for other query mechanisms.
>>>=20
>>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring =
that a string has to be an OAuth2-style scope. It can be, but ultimately =
it=E2=80=99s just a string that the AS can understand. And the objects =
are just that =E2=80=94 objects. If the AS understands what the object =
is, it can be a RAR object or it can be something completely =
API-specific with another query language entirely.
>>>=20
>>> But the other query language would need a type that has been =
reserved in the RAR name space for there to be interop, so it =
effectively is a RAR extension.
>>>=20
>>> There are query languages in other domains that may not fit nicely =
into RAR such as a query for medical records.
>>>=20
>>> Yes, the medical records could be yet another top level property, =
but per below, I think that is confusing.
>>> =20
>>> (Point, though: RAR already pretty much allows this by letting them =
be extended infinitely, a feature it inherits from XYZ)
>>>=20
>>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99=
s an array of strings or objects and each of those means the same thing, =
=E2=80=9Csomething the client is asking for=E2=80=9D.
>>>=20
>>>>=20
>>>> Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.
>>>>=20
>>>=20
>>> It=E2=80=99s my stance that this is an unnecessary limitation at =
this level. The objects within the array should be typed, like RAR, but =
it doesn=E2=80=99t make sense for the overall request to be typed. =
Instead, there should be one =E2=80=9Ctype" of query in the core, what =
XYZ calls the =E2=80=9Cresources=E2=80=9D request. Other query languages =
should be added as extensions either to the RAR-style objects (by =
defining a type at that level) or as a separate top-level member.
>>>=20
>>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D =
query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.
>>>=20
>>> To me, this remains much more understandable, extensible, and clean.
>>>=20
>>> While this may be more understandable to a developer just porting an =
app OIDC that only wants OIDC results, but I think it is more =
complicated as soon as the developer wants other results, which is =
likely what prompted the developer to use GNAP instead of ODIC.
>>>=20
>>> I think it is easier to understand if all the claims are in one =
container, and all the authorizations are in another container.
>>>=20
>>> If a developer wants access to some resources, some claims, and an =
OpenID Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread across =
multiple containers. There are some claims in the "claims" container, =
and some "claims" in the "oidc_claims_query" container. And is the =
access token response in "oidc_claims_query" the same as an access token =
response in "resources"? It would seem simpler if they were, and if all =
the access tokens came back in the same container.
>>>=20
>>> Per Aaron's post that you have referred to, the developer can get =
sme bare claims directly in the response in the "claims" object, an ID =
Token that has the same or different claims, and if they want, an access =
token that they can call a user_info endpoint to get the same, or =
different claims.
>>>=20
>>> For example, an enterprise app client may want an ID Token with the =
email address, bare claims for the user's name and a URI to a profile =
photo, and an access token to query which groups a user belongs to.
>>>=20
>>> We are still re-using the OIDC claims, but we are not mixing claims =
and authorizations.
>>>=20
>>> /Dick
>>>=20
>>>=20
>>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz =

>>> =E1=90=A7
>>=20
>> =E1=90=A7
>=20
> =E1=90=A7


--Apple-Mail=_EBFFBF87-B018-494A-BFB1-ED159AED9724
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Jul 9, 2020, at 2:32 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Looks like you missed the point of my code example, as your =
response is focussed on the aspects I had in comments, so let me =
clarify. 

The point seemed to be about the overall =
complexity and readability, and that=E2=80=99s what I responded =
to.


This line (which is =
determining the type of the item in the array):

if (typeof item =3D=3D=3D =
string')

is implicitly =
stating that the item is an oauth scope. =


No, =
it is not. It is saying that it is a resource request represented as a =
string. One way to represent a resource request as a string is an OAuth =
2 style scope. And if you=E2=80=99re building up from an existing OAuth =
2 system, then you could use a scope there. But that=E2=80=99s not the =
same as stating =E2=80=9Cthe item is a scope=E2=80=9D. In my examples, I =
had been trying to use the terminology that you were using, but I=E2=80=99=
m afraid that made things more unclear.

Whereas it is explicit in this =
statement

if =
(authorizations.type =3D=3D=3D =
'oauth_scope')

which I think it easier =
to understand what is happening (in my opinion of course).

XYZ has types, they are =
just implicit. RAR has explicit types, and that does not look to be =
holding back RAR. I don't understand why you think having explicit types =
will hold us back. 

The =E2=80=9Ctype=E2=80=9D in RAR is a name =
spacing device to allow extensibility in different aspects of the =
request. This is at a lower layer than how they=E2=80=99re being applied =
here, and it therefore makes more sense at that layer. It=E2=80=99s a =
way for a particular API to define the dimensions that it cares about in =
its request. It=E2=80=99s not really an even comparison.

Do you =
want to let the string and object be anything the AS and RS decide they =
could mean? 

Yes. Just like the AS can decide that an OAuth =
scope could mean any number of things.

That would make GNAP more of a =
framework than a protocol, and a key aspect of the request would be =
undefined.

I don=E2=80=99t see how this would make things a =
framework and not a protocol. We=E2=80=99re not debating the ability to =
send a set of strings or a set of objects to the AS, which the AS will =
interpret in the request. We=E2=80=99re debating the syntax for sending =
those values.


My thoughts have not =
shifted on "types" in interactions. I just changed the name to =
'mode'. I did shift my thinking that a negotiation of =
interaction modes is useful, and added =
that.

The important shift is the removal of a single =
=E2=80=9Ctype=E2=80=9D field that meant you could only send one thing at =
a time, and now you can send multiple things in various combinations as =
need allows. That=E2=80=99s the kind of thing that I=E2=80=99m saying is =
problematic here as well, for many of the same reasons.


We still have an unfinished discussion =
there. When you have a chance, would you respond to that =
thread?

I believe the thread you=E2=80=99re referring to =
was commented on by several people, including an AD, as not being a =
helpful conversation for the group. I stopped responding to that thread =
when that was brought up, in order to respect that position and =
hopefully move the conversation along. I=E2=80=99m beginning to think =
that this conversation thread is itself going off the rails in a similar =
way, since we seem to be repeating things at each other. It=E2=80=99s =
become a comparison of solutions in detail and not a discussion of what =
the driving use cases are. I understand that you think your proposal is =
better, and I disagree and have pointed out what I see as several major =
flaws in it.

My goal here isn=E2=80=99=
t to convince you as an individual that I=E2=80=99m right. My goal here =
is to present my ideas and explain the thought process behind them so =
that we all, as a group, can make the best decisions going forward based =
on that. 

 =E2=80=94 =
Justin


/Dick

On Thu, Jul 9, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> =
wrote:
Declarations of which code is =E2=80=9Ceasier to =
understand=E2=80=9D are going to be subjective, and I don=E2=80=99t =
agree with your conclusions even with your examples. Even so, I don=E2=80=99=
t think that the examples you give are a good comparison. While it is of =
course possible to implement things like you have below, I think it=E2=80=99=
s indicative of thinking of things in terms of a =E2=80=9Cresource =
request type=E2=80=9D. What I=E2=80=99ve been trying to argue is that =
there shouldn=E2=80=99t be a =E2=80=9Ctype=E2=80=9D, that there should =
just be slightly different ways to do a resource request. So the code is =
more like:

resourcesRequested =3D requests.map( item =3D> =
{
   if (typeof =
item =3D=3D =E2=80=98object=E2=80=99) {
      return new =
RarStyleResourceRequest(item);
   } else if (typeof item =3D=3D =E2=80=9Cstring=E2=80=
=9D) {
    =
 return new StringStyleResourceRequest(item);
   }
});
processResources(resourcesRequested);
<=
div class=3D"">

Each =
of these =E2=80=9C*ResourceRequest=E2=80=9D objects would be something =
that the AS can use to decide what to put into the access token. =
Although you=E2=80=99d probably put that complexity into a factory =
constructor or something instead of a map function, this shows the kind =
of dispatch you can do based on type if you=E2=80=99re doing it by hand. =
You collect everything in the array, and turn it into an object that =
represents =E2=80=9Ca request for a resource that gets tied to an access =
token=E2=80=9D. And then you process the request based on the collection =
of resource requests. Each string-based request points to some set of =
policies, as does each object-based request. You can even imagine that =
instead of creating a separate string-based request, you use that string =
to look up a policy in a policy engine to be applied later.

The AS then has to =
figure out, as it always does, what to do with this collection. And if =
you want to do an early escape on object style requests, you could just =
throw an error when you detect that. Or, you just ignore that part of =
the request. In fact, here=E2=80=99s the code I wrote that handles it =
exactly that way, while processing the JSON by hand in Java on a legacy =
OAuth 2 server:


JsonArray resources =3D json.get("resources").ge=
tAsJsonArray();      
Set<String> scopes =3D StreamSupport.strea=
m(resources.spliterator(), false)
	.filter( =
e -> e.isJsonPrimitive() ) // filter out anything =
that's not a handle      
	=
.map( e -> e.getAsString() )    =
  
	.collect(Collectors.toSet());    =
  
tx.setScope(scopes);


Furthermore, your XAuth example doesn=E2=80=99t go to the =
same depth as the XYZ example, which leads to a false comparison. In =
your =E2=80=9Cprocess scope=E2=80=9D you would need to parse the =
=E2=80=9Cscope=E2=80=9D string to split on spaces, and then have another =
loop to process each scope. For the =E2=80=9Cprocess details=E2=80=9D =
you=E2=80=99d need to iterate over the array at the root of a RAR-style =
request and process each piece. In the XYZ code, you=E2=80=99ve got all =
of that already. If you=E2=80=99re going to compare the complexity of =
code, they should at least be shown to the same point of the =
process. 

On top of that, the fall-through case statement below is =
really limiting. What if the scope processing or RAR objects processing =
gets combined with something else? This kind of premature optimization =
is not something we want to encourage developers to do. 

But ultimately, I think =
the disconnect is down to thinking about this in terms of an explicit =
=E2=80=9Ctype=E2=80=9D, much the way XAuth used to do with the =
interactions. I=E2=80=99m glad that your thoughts have shifted in that =
space, and I think you should strongly consider the same set of =
arguments here. A lot of the promise of GNAP is getting away from this =
type-field style design, like getting away from OAuth 2=E2=80=99s =
=E2=80=9Cgrant_type=E2=80=9D approach and into something that=E2=80=99s =
focused on interaction and client models instead. This newer model =
allows for better flexibility, better consistency, and better clarity =
throughout. It=E2=80=99s no longer =E2=80=9Cif I see this flag then I go =
down this separate code path and nothing else=E2=80=9D, it=E2=80=99s now =
=E2=80=9Cif I see this item, I go down this code path and then process =
the next item too=E2=80=9D. There=E2=80=99s power in the =
combinations.

 =E2=80=94 Justin

On Jul =
8, 2020, at 9:31 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I had intended to provide a code =
sample comparing XYZ request type with XAuth request type

Let's =
say an AS only supports OAuth scopes (does not support RAR). Here is JS =
code to check:

//XYZ code
var oauth_scope =3D =
true;
requests.forEach( item =3D> {   =
      
  =
  if (typeof item =3D=3D=3D "object")
  =
      oauth_scope =3D false;
});
if (!'oauth_scope') {
    // return error
}

// XAuth code
if ('oauth_scope' !=3D =
authorizations.type) {
   // return =
error
}

Here is some JS code that for an AS =
that supports OAuth scopes, RAR, and OIDC requests:

// XYZ
if (request) {
    =
requests.forEach( item =3D> {
      =
  if (typeof item =3D=3D=3D "object") {
    =
        // process a RAR item
  =
      } else if(typeof item =3D=3D=3D 'string') {
            // process a scope =
item
        } else {
            // throw an =
error
        }
  =
  })    
   // process the whole =
request
}
if (oidc_claims_query) {
    // process oidc request
}

//XAuth
if (authorizations) {
    switch =
(authorizations?.type) {
        case =
'oauth_rar':
            // =
process authorizations.details - RAR 
  =
      case 'oauth_scope':
    =
        // process authorizations.scope
            // process the =
whole request
            =
break;
        case 'oidc':
            // process OIDC =
claims
            break;
        default:
  =
          // error for unknown type
    }
}    


Understanding what the =
code is doing looks much clearer in XAuth to me.

3D""=E1=90=A7

On Wed, Jul =
8, 2020 at 3:55 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Justin,

Just because we are =
using OIDC claims, does not mean we need to mimic the OIDC request and =
response.
I was envisioning a grant request could =
look as the following (using XAuth syntax):

{
  =
  "authorizations": {
        =
"type":"oidc",
        "claims": =
["name", "picture"]
    },
  =
  "claims":{
        "oidc": {
            "id_token" : {
                =
"email"          : { "essential" : true },
                =
"email_verified" : { "essential" : true }
    =
        },
        =
    "userinfo" : {
        =
        "name"           : =
{ "essential" : true },
          =
      "picture"        : null
            }
        }
    =
}
}

Of course a developer could choose to =
only ask for a subset of this.

Note the new authorization type of =
"oidc", that takes "claims" rather than "scope". 

This keeps all the =
authorizations and claims in their respective request and response =
containers.

We =
had a thread months ago on the OIDC two stage model, and I still fail to =
see why forcing that has any advantage. 

/Dick


On Wed, Jul 8, 2020 at 3:25 PM Justin =
Richer <jricher@mit.edu> wrote:
I=E2=80=99m glad =
that we can agree that there are a number of things in legacy protocols =
that are unfortunate side effects of the circumstances in which they =
were built. Space-separated scope strings, for instance, would fall in =
that category, as I=E2=80=99ve previously explained.

A key point in the below: the OIDC =
=E2=80=9Cclaims=E2=80=9D request already mixes user claims (returned in =
an API) and authorization (to fetch user claims from an API), so that =
ship has sailed if you=E2=80=99re using it. It doesn=E2=80=99t make =
sense to have it under a =E2=80=9Cclaims=E2=80=9D or =
=E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s a query =
language that affects both. Maybe you=E2=80=99d call this another =
=E2=80=9Cunfortunate design=E2=80=9D, but the context was about re-using =
an externally-defined query language that was not made for GNAP.

My scenario was for =
someone who is already using =E2=80=9Cclaims=E2=80=9D and wants to keep =
using it. (The vast majority of OIDC implementations, in my experience, =
don=E2=80=99t use that feature, and it=E2=80=99s not even required to be =
implemented by the AS, but again we=E2=80=99re talking about using this =
feature as an example of an external query language =E2=80=94 and there =
are others out there.) In GNAP, you should return claims directly in the =
response, and request specific elements from the APIs protected by the =
access token. These are separate things, and by design both XAuth and =
XYZ have put them into separate containers in the request. This is a =
good design, and so putting something that conflates these two aspects =
into one or the other of the containers is not a particularly good =
option, in my opinion. 

Additionally, though this is a bit of =
an aside and getting into the specifics of identity, the =E2=80=9Cclaims=E2=
=80=9D parameter of ODIC is a query language bound to the full user =
profile. It is my stated position that the items coming back from the AS =
should only be identifiers, and not full profile information. The =
reasoning is pretty simple: the client doesn=E2=80=99t know what profile =
information it needs until it knows who the user is, so putting that =
into a protected API like the UserInfo Endpoint makes much more sense =
than putting it into the immediate response, where it is not needed, =
because the client already knows it. The AS doesn=E2=80=99t know what =
the client needs to know, either, so it can=E2=80=99t determine what to =
fulfill. OIDC=E2=80=99s two-stage model makes sense, and GNAP should =
really only focus on enabling this.

 =E2=80=94 Justin

On Jul 8, 2020, at 6:10 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Wed, Jul =
8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at 3:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I =
think representing the request as an array is simplistic, and =
complicated at the same time.

On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the =
request. 

The elements of the array are taken as =
a set, to be tied to the same resulting access token. If one of those =
elements is defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s =
protecting, to apply across some or all of the other elements, then =
that=E2=80=99s up to the AS=E2=80=99s policy. Much like the =E2=80=9Copeni=
d=E2=80=9D scope in OIDC, which switches on all sorts of contextual =
stuff in the request. So to handle something like this, an AS can easily =
declare that a given scope-style string or a given object property =
applies to different parts of the request. You don=E2=80=99t need to =
externalize it here.

I view the "openid" scope as an =
unfortunate design as OIDC was constrained by building on top of =
OAuth. (a problem I hoped to avert by having "identity" in scope for =
GNAP) The "openid" scope does not function as scope per se, and I =
think it makes OIDC harder to understand as the "openid" scope causes =
non-scope behavior. 

 

Do you have a concrete use case that requires that feature to =
be done in the way that you describe? I am trying to separate the =
driving use case from the proposed solutions to see what the differences =
are. 

Perhaps the client wants access to be =
HIPPA compliant? The HIPPA compliance signal applies to the =
scopes.

Adding =
other properties to an object is a well understood extension mechanism. =
Adding an additional element to an array that does not act like the =
other elements seems like a hack.

 


Using =
JSON type polymorphism requires the AS to test each member of the =
array to determine if it is a string or an object. Only after detecting =
a RAR object does the AS know the client is making a RAR request. 

That=E2=80=99s correct =
=E2=80=94 but the AS needs to parse the whole resources request in order =
to figure out what the client is asking for, anyway, whether it=E2=80=99s =
by strings or objects or whatever else might be defined by an extension. =
Is there an argument for having an AS do an early dispatch on a request =
before it=E2=80=99s fully parsed =
everything?

Let me clarify, the code is looking at =
the type of object that has been parsed. 

Determining if an item in an array is a =
scope or a RAR object by looking at the type being either a string or an =
object seems less clear than a property of an object explicitly =
declaring the type.

 

This =
also limits the request to be composed only of scope strings or RAR =
objects. I don't see how other strings or objects could be used in the =
array, so there is no clear extension point in the "resources" array for =
other query mechanisms.

That=E2=80=99s not the =
case in XYZ since we aren=E2=80=99t declaring that a string has to be an =
OAuth2-style scope. It can be, but ultimately it=E2=80=99s just a string =
that the AS can understand. And the objects are just that =E2=80=94 =
objects. If the AS understands what the object is, it can be a RAR =
object or it can be something completely API-specific with another query =
language entirely.

But the other query language would need =
a type that has been reserved in the RAR name space for there to be =
interop, so it effectively is a RAR extension.

There are query languages in other =
domains that may not fit nicely into RAR such as a query for medical =
records.

Yes, =
the medical records could be yet another top level property, but per =
below, I think that is confusing.
 
(Point, though: RAR already =
pretty much allows this by letting them be extended infinitely, a =
feature it inherits from XYZ)

I=E2=80=99m proposing that we do the =
same thing with GNAP: it=E2=80=99s an array of strings or objects and =
each of those means the same thing, =E2=80=9Csomething the client is =
asking for=E2=80=9D.


Just as =
RAR has a "type" property, I propose the "resources" ("authorizations" =
in XAuth) be an object, where the other properties are determined by the =
"type" property. This allows extensions to define new ways to query for =
an authorization rather than having to fit into scopes or RAR.


It=E2=80=99s my stance =
that this is an unnecessary limitation at this level. The objects within =
the array should be typed, like RAR, but it doesn=E2=80=99t make sense =
for the overall request to be typed. Instead, there should be one =
=E2=80=9Ctype" of query in the core, what XYZ calls the =E2=80=9Cresources=
=E2=80=9D request. Other query languages should be added as extensions =
either to the RAR-style objects (by defining a type at that level) or as =
a separate top-level member.

For example, let=E2=80=99s take the =
OIDC =E2=80=9Cclaims=E2=80=9D query language. My current thought is that =
this really shouldn=E2=80=99t be a part of the =E2=80=9Cresources=E2=80=9D=
 or =E2=80=9Cclaims=E2=80=9D part of the request, but instead as its own =
top-level member, like it is in the OIDC protocol today. The main reason =
for this is the nature of the OIDC claims language: it specifies targets =
for the resulting data, and those targets cross different ways to return =
things. So it doesn=E2=80=99t actually affect just resources like the =
UserInfo Endpoint, or the ID Token, but both and potentially others out =
there. If your system supported such an extension, it could =
theoretically forego both the built-in =E2=80=9Cclaims=E2=80=9D and =
=E2=80=9Cresources=E2=80=9D parts of the request, and use the =
=E2=80=9Coidc_claims_query=E2=80=9D member (or whatever it would be =
called). This would let such an extension use the OIDC claims processing =
mechanism as it is today.

To me, this remains much more understandable, extensible, and =
clean.

While this may be more understandable =
to a developer just porting an app OIDC that only wants OIDC =
results, but I think it is more complicated as soon as the developer =
wants other results, which is likely what prompted the developer to =
use GNAP instead of ODIC.

I think it is easier to understand if all the claims are in =
one container, and all the authorizations are in another =
container.

If =
a developer wants access to some resources, some claims, and an OpenID =
Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread =
across multiple containers. There are some claims in the "claims" =
container, and some "claims" in the "oidc_claims_query" container. And =
is the access token response in "oidc_claims_query" the same as an =
access token response in "resources"? It would seem simpler if they =
were, and if all the access tokens came back in the same =
container.

Per =
Aaron's post that you have referred to, the developer can get sme bare =
claims directly in the response in the "claims" object, an ID Token that =
has the same or different claims, and if they want, an access token that =
they can call a user_info endpoint to get the same, or different =
claims.

For =
example, an enterprise app client may want an ID Token with the email =
address, bare claims for the user's name and a URI to a profile photo, =
and an access token to query which groups a user belongs to.

We are still =
re-using the OIDC claims, but we are not mixing claims and =
authorizations.

/Dick


[1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

3D""=E1=90=A7

3D""=E1=90=A7

=

--Apple-Mail=_EBFFBF87-B018-494A-BFB1-ED159AED9724--


From nobody Thu Jul  9 12:21: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 712183A0E30 for ; Thu,  9 Jul 2020 12:21:28 -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 yjtjsjakL6aN for ; Thu,  9 Jul 2020 12:21:24 -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 316973A0E2A for ; Thu,  9 Jul 2020 12:21:23 -0700 (PDT)
Received: from [192.168.1.7] (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 069JLL7H022078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jul 2020 15:21:21 -0400
From: Justin Richer 
Message-Id: <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8F1E4FA6-B835-4714-AF46-5E444B159EBB"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 9 Jul 2020 15:21:21 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 09 Jul 2020 19:21:29 -0000

--Apple-Mail=_8F1E4FA6-B835-4714-AF46-5E444B159EBB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Ah, so you=E2=80=99re saying that the =E2=80=9Cuserinfo=E2=80=9D claims =
would be returned directly? I didn=E2=80=99t realize that you had =
intended to change how the OIDC claims query language functioned in your =
examples, and had assumed it would work the same was as the spec you =
were referencing. Your example of splitting it up makes that more clear. =
Though I would argue at that point, you=E2=80=99re creating a new query =
language since you=E2=80=99re not using the top-level functionality from =
ODIC=E2=80=99s definition.

 =E2=80=94 Justin

> On Jul 9, 2020, at 3:15 PM, Dick Hardt  wrote:
>=20
> You are jumping to many conclusions below. Let me break down the =
proposal into some bite size chunks.
>=20
> The developer would like to get some plain text OIDC claims about the =
user:
>=20
>     "claims":{
>         "oidc": {
>             "userinfo" : {
>                 "name" : { "essential" : true },
>                 "photo" : { "essential" : false }
>             },
>=20
> The developer would like to get an OIDC ID Token:
>=20
>     "claims":{
>         "oidc": {
>             "id_token" : {
>                 "email"          : { "essential" : true },
>                 "email_verified" : { "essential" : true }
>             }
>     }
>=20
> The developer would like to get an access token to acquire OIDC =
claims:
>=20
> "authorizations": {
>         "type":"oidc",
>         "claims": ["name", "picture"]
>     }
>=20
> The developer would like to get an access token to access photos:
>=20
> "authorizations": {
>         "type":"oauth_scope",
>         "scope": "read_photos"*
>     }
>=20
> The developer would like to get some VC claims:
>=20
> "claims" {
>         "vc": {
>             "some_vc": "query_mechanism"
>         }
> }
>=20
> The developer would like to do all of the above at once:
>=20
> {
>     "authorizations": {
>         "userinfo": {
>             "type":"oidc",
>             "claims": ["name", "picture"]
>         },
>         "photos": {
>             "type":"oauth_scope",
>             "scope": "read_photos"
>         }
>     },
>     "claims":{
>         "oidc": {
>             "id_token" : {
>                 "email"          : { "essential" : true },
>                 "email_verified" : { "essential" : true }
>             },
>             "userinfo" : {
>                 "name" : { "essential" : true },
>                 "photo" : { "essential" : false }
>             }
>         },
>     "vc": {
>         "some_vc": "query_mechanism"
>         }  =20
>     }
> }
>=20
> In the results, the developer gets claims back in the response claims =
object, and access tokens etc. back in the authorizations object. Just =
because an access token returns claims, it is still an access token.
>=20
> Yes, the developer can't get a single access token that can both =
acquire OIDC claims, and access photos (there are separate tokens for =
each), but I would argue that separating the access is a positive =
security property, as a client component accessing the user profile has =
a token independent of the client component accessing photos. And at the =
AS, there is no requirement for the userinfo endpoint to take the same =
token as the photo endpoint.
>=20
> Somewhat of a tangent, I'm thinking that=20
>=20
>     "claims":{
>         "oidc": {
>             "id_token" : {},
>             "userinfo" : {}
>         },
>=20
> is a little verbose, and:
>=20
>     "claims":{
>         "oidc_token": {},
>         "oidc_info": {}
>     },
>=20
> works better and makes it easier to distinguish support for ID tokens =
vs plain claims.
>=20
> wrt. my position on reusing OIDC -- it has not changed. I have viewed =
the OIDC claims as the "query language". No need to reinvent that. We =
are creating a new protocol, so no need to use the OAuth or OIDC =
protocols.
>=20
> * OAuth scopes could be a space separates string to be consistent with =
OAuth 2, or an array of strings so that it is more JSON like. I have no =
strong opinion.=20
>=20
> scope.split(' ').forEach()=20
>=20
> is not that much more complex than=20
>=20
> scope.forEach()
>=20
>=20
>=20
> On Thu, Jul 9, 2020 at 8:39 AM Justin Richer > wrote:
> But this approach doesn=E2=80=99t keep things in their respective =
containers =E2=80=94 you=E2=80=99ve explicitly got =E2=80=9Cclaims=E2=80=9D=
 underneath the =E2=80=9Cauthorizations=E2=80=9D header, and you=E2=80=99v=
e got items that come back as rights associated with the access token =
(which should be =E2=80=9Cauthorizations=E2=80=9D) in the =E2=80=9Cuserinf=
o=E2=80=9D section under the =E2=80=9Cclaims=E2=80=9D header. And as far =
as I can tell, these two sections are redundant to each other. =
Everything is everywhere.=20
>=20
> Additionally, this approach and syntax makes it difficult to combine =
different kinds of requests into one. One of OpenID Connect=E2=80=99s =
biggest draws, as I=E2=80=99m sure you recall, is that it could be =
combined with a request for non-OIDC resources. This was the real =
innovation that Twitter and Facebook=E2=80=99s identity APIs brought, =
access to more than just authentication, and what Google had tried to =
replicate with the awkward OpenID 2 + OAuth 1 hybrid system. Taking a =
step back from the existing solutions of OpenID 2 and OAuth 1 let us, as =
the community, see the value in the pattern that became OIDC on top of =
OAuth 2.=20
>=20
> Sure, you could say that the =E2=80=9Coidc=E2=80=9D type also can =
allow a =E2=80=9Cscopes=E2=80=9D parameter, but what about a RAR style =
object, then? And what about when someone comes up with some new way to =
request access rights, or a VC-based query language? Does every =
=E2=80=9Ctype=E2=80=9D need to now know about every other =E2=80=9Ctype=E2=
=80=9D in order for an AS to be able to figure out how they go together? =
This seems like the protocol definition limiting what combinations the =
AS can handle, or what an RS might want to use.
>=20
> My stance is that GNAP should have a way to query for rights in the =
access token (=E2=80=9Cauthorizations=E2=80=9D in xauth parlance) and =
identifiers for the user (=E2=80=9Cclaims=E2=80=9D in xauth parlance), =
and anything else should be an extension with potentially different =
models. The AS would process the =E2=80=9Cauthorizations=E2=80=9D =
equivalent (for the access token) alongside any other incoming query and =
then make a policy decision based on that.
>=20
> I find it interesting that you are now saying we don=E2=80=99t need to =
use the OIDC request format when previously you=E2=80=99ve made it clear =
that you were in favor of pointing at external query languages, =
including their syntax. I=E2=80=99m glad to see that you=E2=80=99re now =
looking at things in a more flexible way, but I think it=E2=80=99s =
important that we be careful and conscientious about how we reference =
any external query languages in GNAP.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 8, 2020, at 6:55 PM, Dick Hardt > wrote:
>>=20
>> Hey Justin,
>>=20
>> Just because we are using OIDC claims, does not mean we need to mimic =
the OIDC request and response.
>> I was envisioning a grant request could look as the following (using =
XAuth syntax):
>>=20
>> {
>>     "authorizations": {
>>         "type":"oidc",
>>         "claims": ["name", "picture"]
>>     },
>>     "claims":{
>>         "oidc": {
>>             "id_token" : {
>>                 "email"          : { "essential" : true },
>>                 "email_verified" : { "essential" : true }
>>             },
>>             "userinfo" : {
>>                 "name"           : { "essential" : true },
>>                 "picture"        : null
>>             }
>>         }
>>     }
>> }
>>=20
>> Of course a developer could choose to only ask for a subset of this.
>>=20
>> Note the new authorization type of "oidc", that takes "claims" rather =
than "scope".=20
>>=20
>> This keeps all the authorizations and claims in their respective =
request and response containers.
>>=20
>> We had a thread months ago on the OIDC two stage model, and I still =
fail to see why forcing that has any advantage.=20
>>=20
>> /Dick
>>=20
>>=20
>> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer > wrote:
>> I=E2=80=99m glad that we can agree that there are a number of things =
in legacy protocols that are unfortunate side effects of the =
circumstances in which they were built. Space-separated scope strings, =
for instance, would fall in that category, as I=E2=80=99ve previously =
explained.
>>=20
>> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request =
already mixes user claims (returned in an API) and authorization (to =
fetch user claims from an API), so that ship has sailed if you=E2=80=99re =
using it. It doesn=E2=80=99t make sense to have it under a =E2=80=9Cclaims=
=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s =
a query language that affects both. Maybe you=E2=80=99d call this =
another =E2=80=9Cunfortunate design=E2=80=9D, but the context was about =
re-using an externally-defined query language that was not made for =
GNAP.
>>=20
>> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=9D=
 and wants to keep using it. (The vast majority of OIDC implementations, =
in my experience, don=E2=80=99t use that feature, and it=E2=80=99s not =
even required to be implemented by the AS, but again we=E2=80=99re =
talking about using this feature as an example of an external query =
language =E2=80=94 and there are others out there.) In GNAP, you should =
return claims directly in the response, and request specific elements =
from the APIs protected by the access token. These are separate things, =
and by design both XAuth and XYZ have put them into separate containers =
in the request. This is a good design, and so putting something that =
conflates these two aspects into one or the other of the containers is =
not a particularly good option, in my opinion.=20
>>=20
>> Additionally, though this is a bit of an aside and getting into the =
specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is =
a query language bound to the full user profile. It is my stated =
position that the items coming back from the AS should only be =
identifiers, and not full profile information. The reasoning is pretty =
simple: the client doesn=E2=80=99t know what profile information it =
needs until it knows who the user is, so putting that into a protected =
API like the UserInfo Endpoint makes much more sense than putting it =
into the immediate response, where it is not needed, because the client =
already knows it. The AS doesn=E2=80=99t know what the client needs to =
know, either, so it can=E2=80=99t determine what to fulfill. OIDC=E2=80=99=
s two-stage model makes sense, and GNAP should really only focus on =
enabling this.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 8, 2020, at 6:10 PM, Dick Hardt > wrote:
>>>=20
>>>=20
>>>=20
>>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer > wrote:
>>> On Jul 8, 2020, at 3:16 PM, Dick Hardt > wrote:
>>>>=20
>>>> I think representing the request as an array is simplistic, and =
complicated at the same time.
>>>>=20
>>>> On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the request.=20=

>>>=20
>>> The elements of the array are taken as a set, to be tied to the same =
resulting access token. If one of those elements is defined, by the AS =
and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some or =
all of the other elements, then that=E2=80=99s up to the AS=E2=80=99s =
policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, which =
switches on all sorts of contextual stuff in the request. So to handle =
something like this, an AS can easily declare that a given scope-style =
string or a given object property applies to different parts of the =
request. You don=E2=80=99t need to externalize it here.
>>>=20
>>> I view the "openid" scope as an unfortunate design as OIDC was =
constrained by building on top of OAuth. (a problem I hoped to avert by =
having "identity" in scope for GNAP) The "openid" scope does not =
function as scope per se, and I think it makes OIDC harder to understand =
as the "openid" scope causes non-scope behavior.=20
>>>=20
>>> =20
>>>=20
>>> Do you have a concrete use case that requires that feature to be =
done in the way that you describe? I am trying to separate the driving =
use case from the proposed solutions to see what the differences are.=20
>>>=20
>>> Perhaps the client wants access to be HIPPA compliant? The HIPPA =
compliance signal applies to the scopes.
>>>=20
>>> Adding other properties to an object is a well understood extension =
mechanism. Adding an additional element to an array that does not act =
like the other elements seems like a hack.
>>>=20
>>> =20
>>>=20
>>>>=20
>>>> Using JSON type polymorphism requires the AS to test each member of =
the array to determine if it is a string or an object. Only after =
detecting a RAR object does the AS know the client is making a RAR =
request.=20
>>>=20
>>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole =
resources request in order to figure out what the client is asking for, =
anyway, whether it=E2=80=99s by strings or objects or whatever else =
might be defined by an extension. Is there an argument for having an AS =
do an early dispatch on a request before it=E2=80=99s fully parsed =
everything?
>>>=20
>>> Let me clarify, the code is looking at the type of object that has =
been parsed.=20
>>>=20
>>> Determining if an item in an array is a scope or a RAR object by =
looking at the type being either a string or an object seems less clear =
than a property of an object explicitly declaring the type.
>>>=20
>>> =20
>>>=20
>>>> This also limits the request to be composed only of scope strings =
or RAR objects. I don't see how other strings or objects could be used =
in the array, so there is no clear extension point in the "resources" =
array for other query mechanisms.
>>>=20
>>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring =
that a string has to be an OAuth2-style scope. It can be, but ultimately =
it=E2=80=99s just a string that the AS can understand. And the objects =
are just that =E2=80=94 objects. If the AS understands what the object =
is, it can be a RAR object or it can be something completely =
API-specific with another query language entirely.
>>>=20
>>> But the other query language would need a type that has been =
reserved in the RAR name space for there to be interop, so it =
effectively is a RAR extension.
>>>=20
>>> There are query languages in other domains that may not fit nicely =
into RAR such as a query for medical records.
>>>=20
>>> Yes, the medical records could be yet another top level property, =
but per below, I think that is confusing.
>>> =20
>>> (Point, though: RAR already pretty much allows this by letting them =
be extended infinitely, a feature it inherits from XYZ)
>>>=20
>>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99=
s an array of strings or objects and each of those means the same thing, =
=E2=80=9Csomething the client is asking for=E2=80=9D.
>>>=20
>>>>=20
>>>> Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.
>>>>=20
>>>=20
>>> It=E2=80=99s my stance that this is an unnecessary limitation at =
this level. The objects within the array should be typed, like RAR, but =
it doesn=E2=80=99t make sense for the overall request to be typed. =
Instead, there should be one =E2=80=9Ctype" of query in the core, what =
XYZ calls the =E2=80=9Cresources=E2=80=9D request. Other query languages =
should be added as extensions either to the RAR-style objects (by =
defining a type at that level) or as a separate top-level member.
>>>=20
>>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D =
query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.
>>>=20
>>> To me, this remains much more understandable, extensible, and clean.
>>>=20
>>> While this may be more understandable to a developer just porting an =
app OIDC that only wants OIDC results, but I think it is more =
complicated as soon as the developer wants other results, which is =
likely what prompted the developer to use GNAP instead of ODIC.
>>>=20
>>> I think it is easier to understand if all the claims are in one =
container, and all the authorizations are in another container.
>>>=20
>>> If a developer wants access to some resources, some claims, and an =
OpenID Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread across =
multiple containers. There are some claims in the "claims" container, =
and some "claims" in the "oidc_claims_query" container. And is the =
access token response in "oidc_claims_query" the same as an access token =
response in "resources"? It would seem simpler if they were, and if all =
the access tokens came back in the same container.
>>>=20
>>> Per Aaron's post that you have referred to, the developer can get =
sme bare claims directly in the response in the "claims" object, an ID =
Token that has the same or different claims, and if they want, an access =
token that they can call a user_info endpoint to get the same, or =
different claims.
>>>=20
>>> For example, an enterprise app client may want an ID Token with the =
email address, bare claims for the user's name and a URI to a profile =
photo, and an access token to query which groups a user belongs to.
>>>=20
>>> We are still re-using the OIDC claims, but we are not mixing claims =
and authorizations.
>>>=20
>>> /Dick
>>>=20
>>>=20
>>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz =

>>> =E1=90=A7
>>=20
>> =E1=90=A7
>=20
> =E1=90=A7


--Apple-Mail=_8F1E4FA6-B835-4714-AF46-5E444B159EBB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Ah, =
so you=E2=80=99re saying that the =E2=80=9Cuserinfo=E2=80=9D claims =
would be returned directly? I didn=E2=80=99t realize that you had =
intended to change how the OIDC claims query language functioned in your =
examples, and had assumed it would work the same was as the spec you =
were referencing. Your example of splitting it up makes that more clear. =
Though I would argue at that point, you=E2=80=99re creating a new query =
language since you=E2=80=99re not using the top-level functionality from =
ODIC=E2=80=99s definition.

 =E2=80=94 Justin

On Jul =
9, 2020, at 3:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

You are jumping to many conclusions below. Let me break down =
the proposal into some bite size chunks.

The developer would like to get some =
plain text OIDC claims about the user:

    "claims":{
        "oidc": {
  =
          "userinfo" : {
  =
              "name" : { "essential" =
: true },
              =
  "photo" : { "essential" : false }
    =
        },

The developer would like to get an OIDC =
ID Token:

 =
   "claims":{
        "oidc": =
{
            "id_token" : =
{
                =
"email"          : { "essential" : true },
                =
"email_verified" : { "essential" : true }
    =
        }
  =
  }

The =
developer would like to get an access token to acquire OIDC =
claims:

"authorizations": =
{
        "type":"oidc",
  =
      "claims": ["name", "picture"]
  =
  }

The developer would like =
to get an access token to access photos:

"authorizations": {
        =
"type":"oauth_scope",
        "scope": =
"read_photos"*
    }

The developer would like to get some VC =
claims:

"claims"=
 {
        "vc": {
          =
  "some_vc": "query_mechanism"
      =
  }
}

The developer would like to do all of =
the above at once:

{
    "authorizations": {
        "userinfo": {
  =
          "type":"oidc",
  =
          "claims": ["name", "picture"]
        },
    =
    "photos": {
        =
    "type":"oauth_scope",
      =
      "scope": "read_photos"
    =
    }
    },
  =
  "claims":{
        "oidc": {
            "id_token" : {
                =
"email"          : { "essential" : true },
                =
"email_verified" : { "essential" : true }
    =
        },
        =
    "userinfo" : {
        =
        "name" : { "essential" : true },
                =
"photo" : { "essential" : false }
      =
      }
        },
    "vc": {
      =
  "some_vc": "query_mechanism"
      =
  }   
    }
}

In the results, the =
developer gets claims back in the response claims object, and access =
tokens etc. back in the authorizations object. Just because an access =
token returns claims, it is still an access token.

Yes, the =
developer can't get a single access token that can both acquire =
OIDC claims, and access photos (there are separate tokens for each), but =
I would argue that separating the access is a positive security =
property, as a client component accessing the user profile has a token =
independent of the client component accessing photos. And at the AS, =
there is no requirement for the userinfo endpoint to take the same token =
as the photo endpoint.

Somewhat of a tangent, I'm thinking that 

    =
"claims":{
        "oidc": {
            "id_token" : {},
            "userinfo" : {}
        },

is =
a little verbose, and:

    =
"claims":{
        "oidc_token": =
{},
        "oidc_info": {}
    },

works better and makes it easier to =
distinguish support for ID tokens vs plain claims.

wrt. my position on =
reusing OIDC -- it has not changed. I have viewed the OIDC claims as the =
"query language". No need to reinvent that. We are creating a new =
protocol, so no need to use the OAuth or OIDC protocols.

* OAuth =
scopes could be a space separates string to be consistent with OAuth 2, =
or an array of strings so that it is more JSON like. I have no strong =
opinion. 

scope.split(' ').forEach() 

is not that much more complex =
than 

scope.forEach()



On Thu, Jul =
9, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wrote:
But this approach doesn=E2=80=99t =
keep things in their respective containers =E2=80=94 you=E2=80=99ve =
explicitly got =E2=80=9Cclaims=E2=80=9D underneath the =
=E2=80=9Cauthorizations=E2=80=9D header, and you=E2=80=99ve got items =
that come back as rights associated with the access token (which should =
be =E2=80=9Cauthorizations=E2=80=9D) in the =E2=80=9Cuserinfo=E2=80=9D =
section under the =E2=80=9Cclaims=E2=80=9D header. And as far as I can =
tell, these two sections are redundant to each other. Everything is =
everywhere. 

Additionally, this approach and syntax makes it difficult to =
combine different kinds of requests into one. One of OpenID Connect=E2=80=99=
s biggest draws, as I=E2=80=99m sure you recall, is that it could be =
combined with a request for non-OIDC resources. This was the real =
innovation that Twitter and Facebook=E2=80=99s identity APIs brought, =
access to more than just authentication, and what Google had tried to =
replicate with the awkward OpenID 2 + OAuth 1 hybrid system. Taking a =
step back from the existing solutions of OpenID 2 and OAuth 1 let us, as =
the community, see the value in the pattern that became OIDC on top of =
OAuth 2. 

Sure, you could say that the =E2=80=9Coidc=E2=80=9D type also =
can allow a =E2=80=9Cscopes=E2=80=9D parameter, but what about a RAR =
style object, then? And what about when someone comes up with some new =
way to request access rights, or a VC-based query language? Does every =
=E2=80=9Ctype=E2=80=9D need to now know about every other =E2=80=9Ctype=E2=
=80=9D in order for an AS to be able to figure out how they go together? =
This seems like the protocol definition limiting what combinations the =
AS can handle, or what an RS might want to use.

My stance is that GNAP should have a =
way to query for rights in the access token (=E2=80=9Cauthorizations=E2=80=
=9D in xauth parlance) and identifiers for the user (=E2=80=9Cclaims=E2=80=
=9D in xauth parlance), and anything else should be an extension with =
potentially different models. The AS would process the =
=E2=80=9Cauthorizations=E2=80=9D equivalent (for the access token) =
alongside any other incoming query and then make a policy decision based =
on that.

I =
find it interesting that you are now saying we don=E2=80=99t need to use =
the OIDC request format when previously you=E2=80=99ve made it clear =
that you were in favor of pointing at external query languages, =
including their syntax. I=E2=80=99m glad to see that you=E2=80=99re now =
looking at things in a more flexible way, but I think it=E2=80=99s =
important that we be careful and conscientious about how we reference =
any external query languages in GNAP.

 =E2=80=94 Justin

On Jul 8, 2020, at 6:55 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey =
Justin,

Just =
because we are using OIDC claims, does not mean we need to mimic =
the OIDC request and response.
I was envisioning a =
grant request could look as the following (using XAuth syntax):

{
    "authorizations": {
    =
    "type":"oidc",
        =
"claims": ["name", "picture"]
    },
    "claims":{
      =
  "oidc": {
            =
"id_token" : {
            =
    "email"          : { "essential" =
: true },
              =
  "email_verified" : { "essential" : true }
  =
          },
      =
      "userinfo" : {
      =
          "name"         =
  : { "essential" : true },
      =
          "picture"       =
 : null
            =
}
        }
  =
  }
}

Of course a developer could choose to =
only ask for a subset of this.

Note the new authorization type of =
"oidc", that takes "claims" rather than "scope". 

This keeps all the =
authorizations and claims in their respective request and response =
containers.

We =
had a thread months ago on the OIDC two stage model, and I still fail to =
see why forcing that has any advantage. 

/Dick


On Wed, Jul 8, 2020 at 3:25 PM Justin =
Richer <jricher@mit.edu> wrote:
I=E2=80=99m glad =
that we can agree that there are a number of things in legacy protocols =
that are unfortunate side effects of the circumstances in which they =
were built. Space-separated scope strings, for instance, would fall in =
that category, as I=E2=80=99ve previously explained.

A key point in the below: the OIDC =
=E2=80=9Cclaims=E2=80=9D request already mixes user claims (returned in =
an API) and authorization (to fetch user claims from an API), so that =
ship has sailed if you=E2=80=99re using it. It doesn=E2=80=99t make =
sense to have it under a =E2=80=9Cclaims=E2=80=9D or =
=E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s a query =
language that affects both. Maybe you=E2=80=99d call this another =
=E2=80=9Cunfortunate design=E2=80=9D, but the context was about re-using =
an externally-defined query language that was not made for GNAP.

My scenario was for =
someone who is already using =E2=80=9Cclaims=E2=80=9D and wants to keep =
using it. (The vast majority of OIDC implementations, in my experience, =
don=E2=80=99t use that feature, and it=E2=80=99s not even required to be =
implemented by the AS, but again we=E2=80=99re talking about using this =
feature as an example of an external query language =E2=80=94 and there =
are others out there.) In GNAP, you should return claims directly in the =
response, and request specific elements from the APIs protected by the =
access token. These are separate things, and by design both XAuth and =
XYZ have put them into separate containers in the request. This is a =
good design, and so putting something that conflates these two aspects =
into one or the other of the containers is not a particularly good =
option, in my opinion. 

Additionally, though this is a bit of =
an aside and getting into the specifics of identity, the =E2=80=9Cclaims=E2=
=80=9D parameter of ODIC is a query language bound to the full user =
profile. It is my stated position that the items coming back from the AS =
should only be identifiers, and not full profile information. The =
reasoning is pretty simple: the client doesn=E2=80=99t know what profile =
information it needs until it knows who the user is, so putting that =
into a protected API like the UserInfo Endpoint makes much more sense =
than putting it into the immediate response, where it is not needed, =
because the client already knows it. The AS doesn=E2=80=99t know what =
the client needs to know, either, so it can=E2=80=99t determine what to =
fulfill. OIDC=E2=80=99s two-stage model makes sense, and GNAP should =
really only focus on enabling this.

 =E2=80=94 Justin

On Jul 8, 2020, at 6:10 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Wed, Jul =
8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at 3:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I =
think representing the request as an array is simplistic, and =
complicated at the same time.

On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the =
request. 

The elements of the array are taken as =
a set, to be tied to the same resulting access token. If one of those =
elements is defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s =
protecting, to apply across some or all of the other elements, then =
that=E2=80=99s up to the AS=E2=80=99s policy. Much like the =E2=80=9Copeni=
d=E2=80=9D scope in OIDC, which switches on all sorts of contextual =
stuff in the request. So to handle something like this, an AS can easily =
declare that a given scope-style string or a given object property =
applies to different parts of the request. You don=E2=80=99t need to =
externalize it here.

I view the "openid" scope as an =
unfortunate design as OIDC was constrained by building on top of =
OAuth. (a problem I hoped to avert by having "identity" in scope for =
GNAP) The "openid" scope does not function as scope per se, and I =
think it makes OIDC harder to understand as the "openid" scope causes =
non-scope behavior. 

 

Do you have a concrete use case that requires that feature to =
be done in the way that you describe? I am trying to separate the =
driving use case from the proposed solutions to see what the differences =
are. 

Perhaps the client wants access to be =
HIPPA compliant? The HIPPA compliance signal applies to the =
scopes.

Adding =
other properties to an object is a well understood extension mechanism. =
Adding an additional element to an array that does not act like the =
other elements seems like a hack.

 


Using =
JSON type polymorphism requires the AS to test each member of the =
array to determine if it is a string or an object. Only after detecting =
a RAR object does the AS know the client is making a RAR request. 

That=E2=80=99s correct =
=E2=80=94 but the AS needs to parse the whole resources request in order =
to figure out what the client is asking for, anyway, whether it=E2=80=99s =
by strings or objects or whatever else might be defined by an extension. =
Is there an argument for having an AS do an early dispatch on a request =
before it=E2=80=99s fully parsed =
everything?

Let me clarify, the code is looking at =
the type of object that has been parsed. 

Determining if an item in an array is a =
scope or a RAR object by looking at the type being either a string or an =
object seems less clear than a property of an object explicitly =
declaring the type.

 

This =
also limits the request to be composed only of scope strings or RAR =
objects. I don't see how other strings or objects could be used in the =
array, so there is no clear extension point in the "resources" array for =
other query mechanisms.

That=E2=80=99s not the =
case in XYZ since we aren=E2=80=99t declaring that a string has to be an =
OAuth2-style scope. It can be, but ultimately it=E2=80=99s just a string =
that the AS can understand. And the objects are just that =E2=80=94 =
objects. If the AS understands what the object is, it can be a RAR =
object or it can be something completely API-specific with another query =
language entirely.

But the other query language would need =
a type that has been reserved in the RAR name space for there to be =
interop, so it effectively is a RAR extension.

There are query languages in other =
domains that may not fit nicely into RAR such as a query for medical =
records.

Yes, =
the medical records could be yet another top level property, but per =
below, I think that is confusing.
 
(Point, though: RAR already =
pretty much allows this by letting them be extended infinitely, a =
feature it inherits from XYZ)

I=E2=80=99m proposing that we do the =
same thing with GNAP: it=E2=80=99s an array of strings or objects and =
each of those means the same thing, =E2=80=9Csomething the client is =
asking for=E2=80=9D.


Just as =
RAR has a "type" property, I propose the "resources" ("authorizations" =
in XAuth) be an object, where the other properties are determined by the =
"type" property. This allows extensions to define new ways to query for =
an authorization rather than having to fit into scopes or RAR.


It=E2=80=99s my stance =
that this is an unnecessary limitation at this level. The objects within =
the array should be typed, like RAR, but it doesn=E2=80=99t make sense =
for the overall request to be typed. Instead, there should be one =
=E2=80=9Ctype" of query in the core, what XYZ calls the =E2=80=9Cresources=
=E2=80=9D request. Other query languages should be added as extensions =
either to the RAR-style objects (by defining a type at that level) or as =
a separate top-level member.

For example, let=E2=80=99s take the =
OIDC =E2=80=9Cclaims=E2=80=9D query language. My current thought is that =
this really shouldn=E2=80=99t be a part of the =E2=80=9Cresources=E2=80=9D=
 or =E2=80=9Cclaims=E2=80=9D part of the request, but instead as its own =
top-level member, like it is in the OIDC protocol today. The main reason =
for this is the nature of the OIDC claims language: it specifies targets =
for the resulting data, and those targets cross different ways to return =
things. So it doesn=E2=80=99t actually affect just resources like the =
UserInfo Endpoint, or the ID Token, but both and potentially others out =
there. If your system supported such an extension, it could =
theoretically forego both the built-in =E2=80=9Cclaims=E2=80=9D and =
=E2=80=9Cresources=E2=80=9D parts of the request, and use the =
=E2=80=9Coidc_claims_query=E2=80=9D member (or whatever it would be =
called). This would let such an extension use the OIDC claims processing =
mechanism as it is today.

To me, this remains much more understandable, extensible, and =
clean.

While this may be more understandable =
to a developer just porting an app OIDC that only wants OIDC =
results, but I think it is more complicated as soon as the developer =
wants other results, which is likely what prompted the developer to =
use GNAP instead of ODIC.

I think it is easier to understand if all the claims are in =
one container, and all the authorizations are in another =
container.

If =
a developer wants access to some resources, some claims, and an OpenID =
Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread =
across multiple containers. There are some claims in the "claims" =
container, and some "claims" in the "oidc_claims_query" container. And =
is the access token response in "oidc_claims_query" the same as an =
access token response in "resources"? It would seem simpler if they =
were, and if all the access tokens came back in the same =
container.

Per =
Aaron's post that you have referred to, the developer can get sme bare =
claims directly in the response in the "claims" object, an ID Token that =
has the same or different claims, and if they want, an access token that =
they can call a user_info endpoint to get the same, or different =
claims.

For =
example, an enterprise app client may want an ID Token with the email =
address, bare claims for the user's name and a URI to a profile photo, =
and an access token to query which groups a user belongs to.

We are still =
re-using the OIDC claims, but we are not mixing claims and =
authorizations.

/Dick


[1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

3D""=E1=90=A7

3D""=E1=90=A7

=

--Apple-Mail=_8F1E4FA6-B835-4714-AF46-5E444B159EBB--


From nobody Thu Jul  9 12:30: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 A3FEB3A0E43 for ; Thu,  9 Jul 2020 12:30:21 -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 3iNruRFd82w1 for ; Thu,  9 Jul 2020 12:30:18 -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 DDA523A0E27 for ; Thu,  9 Jul 2020 12:30:17 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id j11so3715189ljo.7 for ; Thu, 09 Jul 2020 12:30: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=gqVou8OQSNDhq0VbTaxicflhqEjhFNI3crixoDNy9Rk=; b=eb+pq88RPBPbTiHWsSmFPZLB7G8T6ItXwc6U69voWrJwVUmYY45ii3L7gQI2Zab46P RBl3OE3A8nVD3/0Gh7iAX3VW9oVctXy3yYwHrPKZVR6UxZmcFstjJHEPtWJyxPQCvfAw Ty7SfPH4tAEIj64gYTwC+O9fS/uzdZcqOcsOJICW8C3/2dCjtJAkr846RHgXWb8wxMx+ +DQugcYw55i/hfGLdL5Aqil2nonVV54uGhoyN2JOaRm2c6ivxGNdQyoSbrOXTF5OppAv UIl77D+4T2IlbR+b8+ko48YLGUUpHOe47a65N5sNGbnlC2ookK5aEY0NsKI5kbE9h0T2 Qdtg==
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=gqVou8OQSNDhq0VbTaxicflhqEjhFNI3crixoDNy9Rk=; b=q3o16pHHWMgD8nCr6ISy8BOn9U0vjmrkjaPSXEbIXiAkmz24GJw/3ASDikeKP04P2M /tzLFLhyMtFVjHzCjgPga40r187fR6xG9mGsfFNkT856CTeyUmN4IJpybpMWPPXUtCD/ SBvp4iBhHnh1QWq0hlvo7c3CrOtgBpStyOAM+C0UPtJ4jzCB+h2vTa9iMG6DmnkfWJ2O 7kBl04BvjVaZzQyqrsyJpn4BVDBarvsTavwpuPNZQnNeuSBZFmQ38VQfwgFYiFLgvzsM GxVNrQFNpRgo+1INSJIFOtEwKRAKwGX3ncaeOFUgJWqDg5B4wzpP5aUX4JUyadJV65+W HlYQ==
X-Gm-Message-State: AOAM532+OzufsLgrjgF4eA6bB4GkVI2XxA8aJqdy08HUDTZN0jxWKgJZ qecI2jVh4MNPMfqL1NVQ7GZSg4Tf/nwICCvhXF4=
X-Google-Smtp-Source: ABdhPJwpeeO0KBOoA2fIvdd/4adcEScXhGb398HoavqAEWVZ5jqZvinT+L0BGpuDrdNMcuZC4HBVxYa/yitvV0SZ7AM=
X-Received: by 2002:a05:651c:547:: with SMTP id q7mr35482397ljp.437.1594323015584;  Thu, 09 Jul 2020 12:30:15 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>
In-Reply-To: <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>
From: Dick Hardt 
Date: Thu, 9 Jul 2020 12:29:38 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000052f605aa074161"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 09 Jul 2020 19:30:22 -0000

--0000000000000052f605aa074161
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes. Which is why I referred to Aaron's post originally which calls out for
returning plain text claims.

I don't really understand what you mean by "OIDC claims query language".
The claims mean the same thing. And I was also reusing the modifiers such
as {"essential": true}. What top level functionality are you referring to?

On Thu, Jul 9, 2020 at 12:21 PM Justin Richer  wrote:

> Ah, so you=E2=80=99re saying that the =E2=80=9Cuserinfo=E2=80=9D claims w=
ould be returned
> directly? I didn=E2=80=99t realize that you had intended to change how th=
e OIDC
> claims query language functioned in your examples, and had assumed it wou=
ld
> work the same was as the spec you were referencing. Your example of
> splitting it up makes that more clear. Though I would argue at that point=
,
> you=E2=80=99re creating a new query language since you=E2=80=99re not usi=
ng the top-level
> functionality from ODIC=E2=80=99s definition.
>
>  =E2=80=94 Justin
>
> On Jul 9, 2020, at 3:15 PM, Dick Hardt  wrote:
>
> You are jumping to many conclusions below. Let me break down the proposal
> into some bite size chunks.
>
> The developer would like to get some plain text OIDC claims about the use=
r:
>
>     "claims":{
>         "oidc": {
>             "userinfo" : {
>                 "name" : { "essential" : true },
>                 "photo" : { "essential" : false }
>             },
>
> The developer would like to get an OIDC ID Token:
>
>     "claims":{
>         "oidc": {
>             "id_token" : {
>                 "email"          : { "essential" : true },
>                 "email_verified" : { "essential" : true }
>             }
>     }
>
> The developer would like to get an access token to acquire OIDC claims:
>
> "authorizations": {
>         "type":"oidc",
>         "claims": ["name", "picture"]
>     }
>
> The developer would like to get an access token to access photos:
>
> "authorizations": {
>         "type":"oauth_scope",
>         "scope": "read_photos"*
>     }
>
> The developer would like to get some VC claims:
>
> "claims" {
>         "vc": {
>             "some_vc": "query_mechanism"
>         }
> }
>
> The developer would like to do all of the above at once:
>
> {
>     "authorizations": {
>         "userinfo": {
>             "type":"oidc",
>             "claims": ["name", "picture"]
>         },
>         "photos": {
>             "type":"oauth_scope",
>             "scope": "read_photos"
>         }
>     },
>     "claims":{
>         "oidc": {
>             "id_token" : {
>                 "email"          : { "essential" : true },
>                 "email_verified" : { "essential" : true }
>             },
>             "userinfo" : {
>                 "name" : { "essential" : true },
>                 "photo" : { "essential" : false }
>             }
>         },
>     "vc": {
>         "some_vc": "query_mechanism"
>         }
>     }
> }
>
> In the results, the developer gets claims back in the response claims
> object, and access tokens etc. back in the authorizations object. Just
> because an access token returns claims, it is still an access token.
>
> Yes, the developer can't get a single access token that can both acquire
> OIDC claims, and access photos (there are separate tokens for each), but =
I
> would argue that separating the access is a positive security property, a=
s
> a client component accessing the user profile has a token independent of
> the client component accessing photos. And at the AS, there is no
> requirement for the userinfo endpoint to take the same token as the photo
> endpoint.
>
> Somewhat of a tangent, I'm thinking that
>
>     "claims":{
>         "oidc": {
>             "id_token" : {},
>             "userinfo" : {}
>         },
>
> is a little verbose, and:
>
>     "claims":{
>         "oidc_token": {},
>         "oidc_info": {}
>     },
>
> works better and makes it easier to distinguish support for ID tokens vs
> plain claims.
>
> wrt. my position on reusing OIDC -- it has not changed. I have viewed the
> OIDC claims as the "query language". No need to reinvent that. We are
> creating a new protocol, so no need to use the OAuth or OIDC protocols.
>
> * OAuth scopes could be a space separates string to be consistent with
> OAuth 2, or an array of strings so that it is more JSON like. I have no
> strong opinion.
>
> scope.split(' ').forEach()
>
> is not that much more complex than
>
> scope.forEach()
>
>
>
> On Thu, Jul 9, 2020 at 8:39 AM Justin Richer  wrote:
>
>> But this approach doesn=E2=80=99t keep things in their respective contai=
ners =E2=80=94
>> you=E2=80=99ve explicitly got =E2=80=9Cclaims=E2=80=9D underneath the =
=E2=80=9Cauthorizations=E2=80=9D header, and
>> you=E2=80=99ve got items that come back as rights associated with the ac=
cess token
>> (which should be =E2=80=9Cauthorizations=E2=80=9D) in the =E2=80=9Cuseri=
nfo=E2=80=9D section under the
>> =E2=80=9Cclaims=E2=80=9D header. And as far as I can tell, these two sec=
tions are redundant
>> to each other. Everything is everywhere.
>>
>> Additionally, this approach and syntax makes it difficult to combine
>> different kinds of requests into one. One of OpenID Connect=E2=80=99s bi=
ggest
>> draws, as I=E2=80=99m sure you recall, is that it could be combined with=
 a request
>> for non-OIDC resources. This was the real innovation that Twitter and
>> Facebook=E2=80=99s identity APIs brought, access to more than just authe=
ntication,
>> and what Google had tried to replicate with the awkward OpenID 2 + OAuth=
 1
>> hybrid system. Taking a step back from the existing solutions of OpenID =
2
>> and OAuth 1 let us, as the community, see the value in the pattern that
>> became OIDC on top of OAuth 2.
>>
>> Sure, you could say that the =E2=80=9Coidc=E2=80=9D type also can allow =
a =E2=80=9Cscopes=E2=80=9D
>> parameter, but what about a RAR style object, then? And what about when
>> someone comes up with some new way to request access rights, or a VC-bas=
ed
>> query language? Does every =E2=80=9Ctype=E2=80=9D need to now know about=
 every other =E2=80=9Ctype=E2=80=9D
>> in order for an AS to be able to figure out how they go together? This
>> seems like the protocol definition limiting what combinations the AS can
>> handle, or what an RS might want to use.
>>
>> My stance is that GNAP should have a way to query for rights in the
>> access token (=E2=80=9Cauthorizations=E2=80=9D in xauth parlance) and id=
entifiers for the
>> user (=E2=80=9Cclaims=E2=80=9D in xauth parlance), and anything else sho=
uld be an extension
>> with potentially different models. The AS would process the
>> =E2=80=9Cauthorizations=E2=80=9D equivalent (for the access token) along=
side any other
>> incoming query and then make a policy decision based on that.
>>
>> I find it interesting that you are now saying we don=E2=80=99t need to u=
se the
>> OIDC request format when previously you=E2=80=99ve made it clear that yo=
u were in
>> favor of pointing at external query languages, including their syntax. I=
=E2=80=99m
>> glad to see that you=E2=80=99re now looking at things in a more flexible=
 way, but I
>> think it=E2=80=99s important that we be careful and conscientious about =
how we
>> reference any external query languages in GNAP.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 8, 2020, at 6:55 PM, Dick Hardt  wrote:
>>
>> Hey Justin,
>>
>> Just because we are using OIDC claims, does not mean we need to mimic th=
e
>> OIDC request and response.
>> I was envisioning a grant request could look as the following (using
>> XAuth syntax):
>>
>> {
>>     "authorizations": {
>>         "type":"oidc",
>>         "claims": ["name", "picture"]
>>     },
>>     "claims":{
>>         "oidc": {
>>             "id_token" : {
>>                 "email"          : { "essential" : true },
>>                 "email_verified" : { "essential" : true }
>>             },
>>             "userinfo" : {
>>                 "name"           : { "essential" : true },
>>                 "picture"        : null
>>             }
>>         }
>>     }
>> }
>>
>> Of course a developer could choose to only ask for a subset of this.
>>
>> Note the new authorization type of "oidc", that takes "claims" rather
>> than "scope".
>>
>> This keeps all the authorizations and claims in their respective request
>> and response containers.
>>
>> We had a thread months ago on the OIDC two stage model, and I still fail
>> to see why forcing that has any advantage.
>>
>> /Dick
>>
>>
>> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer  wrote:
>>
>>> I=E2=80=99m glad that we can agree that there are a number of things in=
 legacy
>>> protocols that are unfortunate side effects of the circumstances in whi=
ch
>>> they were built. Space-separated scope strings, for instance, would fal=
l in
>>> that category, as I=E2=80=99ve previously explained.
>>>
>>> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request alr=
eady mixes user
>>> claims (returned in an API) and authorization (to fetch user claims fro=
m an
>>> API), so that ship has sailed if you=E2=80=99re using it. It doesn=E2=
=80=99t make sense to
>>> have it under a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorizations=E2=
=80=9D request, since it=E2=80=99s a query
>>> language that affects both. Maybe you=E2=80=99d call this another =E2=
=80=9Cunfortunate
>>> design=E2=80=9D, but the context was about re-using an externally-defin=
ed query
>>> language that was not made for GNAP.
>>>
>>> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=
=9D and wants to
>>> keep using it. (The vast majority of OIDC implementations, in my
>>> experience, don=E2=80=99t use that feature, and it=E2=80=99s not even r=
equired to be
>>> implemented by the AS, but again we=E2=80=99re talking about using this=
 feature as
>>> an example of an external query language =E2=80=94 and there are others=
 out there.)
>>> In GNAP, you should return claims directly in the response, and request
>>> specific elements from the APIs protected by the access token. These ar=
e
>>> separate things, and by design both XAuth and XYZ have put them into
>>> separate containers in the request. This is a good design, and so putti=
ng
>>> something that conflates these two aspects into one or the other of the
>>> containers is not a particularly good option, in my opinion.
>>>
>>> Additionally, though this is a bit of an aside and getting into the
>>> specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC i=
s a query language
>>> bound to the full user profile. It is my stated position that the items
>>> coming back from the AS should only be identifiers, and not full profil=
e
>>> information. The reasoning is pretty simple: the client doesn=E2=80=99t=
 know what
>>> profile information it needs until it knows who the user is, so putting
>>> that into a protected API like the UserInfo Endpoint makes much more se=
nse
>>> than putting it into the immediate response, where it is not needed,
>>> because the client already knows it. The AS doesn=E2=80=99t know what t=
he client
>>> needs to know, either, so it can=E2=80=99t determine what to fulfill. O=
IDC=E2=80=99s
>>> two-stage model makes sense, and GNAP should really only focus on enabl=
ing
>>> this.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 8, 2020, at 6:10 PM, Dick Hardt  wrote:
>>>
>>>
>>>
>>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer  wrote:
>>>
>>>> On Jul 8, 2020, at 3:16 PM, Dick Hardt  wrote:
>>>>
>>>>
>>>> I think representing the request as an array is simplistic, and
>>>> complicated at the same time.
>>>>
>>>> On the simplistic front, as there is no clear mechanism for extending
>>>> the request with properties that apply to all of the request.
>>>>
>>>>
>>>> The elements of the array are taken as a set, to be tied to the same
>>>> resulting access token. If one of those elements is defined, by the AS
>>>> and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some =
or all of the other
>>>> elements, then that=E2=80=99s up to the AS=E2=80=99s policy. Much like=
 the =E2=80=9Copenid=E2=80=9D scope
>>>> in OIDC, which switches on all sorts of contextual stuff in the reques=
t. So
>>>> to handle something like this, an AS can easily declare that a given
>>>> scope-style string or a given object property applies to different par=
ts of
>>>> the request. You don=E2=80=99t need to externalize it here.
>>>>
>>>
>>> I view the "openid" scope as an unfortunate design as OIDC was
>>> constrained by building on top of OAuth. (a problem I hoped to avert by
>>> having "identity" in scope for GNAP) The "openid" scope does not functi=
on
>>> as scope per se, and I think it makes OIDC harder to understand as the
>>> "openid" scope causes non-scope behavior.
>>>
>>>
>>>
>>>>
>>>> Do you have a concrete use case that requires that feature to be done
>>>> in the way that you describe? I am trying to separate the driving use =
case
>>>> from the proposed solutions to see what the differences are.
>>>>
>>>
>>> Perhaps the client wants access to be HIPPA compliant? The HIPPA
>>> compliance signal applies to the scopes.
>>>
>>> Adding other properties to an object is a well understood extension
>>> mechanism. Adding an additional element to an array that does not act l=
ike
>>> the other elements seems like a hack.
>>>
>>>
>>>
>>>>
>>>>
>>>> Using JSON type polymorphism requires the AS to test each member of th=
e
>>>> array to determine if it is a string or an object. Only after detectin=
g a
>>>> RAR object does the AS know the client is making a RAR request.
>>>>
>>>>
>>>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole r=
esources request
>>>> in order to figure out what the client is asking for, anyway, whether =
it=E2=80=99s
>>>> by strings or objects or whatever else might be defined by an extensio=
n. Is
>>>> there an argument for having an AS do an early dispatch on a request b=
efore
>>>> it=E2=80=99s fully parsed everything?
>>>>
>>>
>>> Let me clarify, the code is looking at the type of object that has been
>>> parsed.
>>>
>>> Determining if an item in an array is a scope or a RAR object by lookin=
g
>>> at the type being either a string or an object seems less clear than a
>>> property of an object explicitly declaring the type.
>>>
>>>
>>>
>>>>
>>>> This also limits the request to be composed only of scope strings or
>>>> RAR objects. I don't see how other strings or objects could be used in=
 the
>>>> array, so there is no clear extension point in the "resources" array f=
or
>>>> other query mechanisms.
>>>>
>>>>
>>>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring t=
hat a string has
>>>> to be an OAuth2-style scope. It can be, but ultimately it=E2=80=99s ju=
st a string
>>>> that the AS can understand. And the objects are just that =E2=80=94 ob=
jects. If the
>>>> AS understands what the object is, it can be a RAR object or it can be
>>>> something completely API-specific with another query language entirely=
.
>>>>
>>>
>>> But the other query language would need a type that has been reserved i=
n
>>> the RAR name space for there to be interop, so it effectively is a RAR
>>> extension.
>>>
>>> There are query languages in other domains that may not fit nicely into
>>> RAR such as a query for medical records.
>>>
>>> Yes, the medical records could be yet another top level property, but
>>> per below, I think that is confusing.
>>>
>>>
>>>> (Point, though: RAR already pretty much allows this by letting them be
>>>> extended infinitely, a feature it inherits from XYZ)
>>>>
>>>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99=
s an array of
>>>> strings or objects and each of those means the same thing, =E2=80=9Cso=
mething the
>>>> client is asking for=E2=80=9D.
>>>>
>>>>
>>>> Just as RAR has a "type" property, I propose the "resources"
>>>> ("authorizations" in XAuth) be an object, where the other properties a=
re
>>>> determined by the "type" property. This allows extensions to define ne=
w
>>>> ways to query for an authorization rather than having to fit into scop=
es or
>>>> RAR.
>>>>
>>>>
>>>> It=E2=80=99s my stance that this is an unnecessary limitation at this =
level.
>>>> The objects within the array should be typed, like RAR, but it doesn=
=E2=80=99t make
>>>> sense for the overall request to be typed. Instead, there should be on=
e
>>>> =E2=80=9Ctype" of query in the core, what XYZ calls the =E2=80=9Cresou=
rces=E2=80=9D request. Other
>>>> query languages should be added as extensions either to the RAR-style
>>>> objects (by defining a type at that level) or as a separate top-level
>>>> member.
>>>>
>>>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D quer=
y language. My current
>>>> thought is that this really shouldn=E2=80=99t be a part of the =E2=80=
=9Cresources=E2=80=9D or
>>>> =E2=80=9Cclaims=E2=80=9D part of the request, but instead as its own t=
op-level member, like
>>>> it is in the OIDC protocol today. The main reason for this is the natu=
re of
>>>> the OIDC claims language: it specifies targets for the resulting data,=
 and
>>>> those targets cross different ways to return things. So it doesn=E2=80=
=99t actually
>>>> affect just resources like the UserInfo Endpoint, or the ID Token, but=
 both
>>>> and potentially others out there. If your system supported such an
>>>> extension, it could theoretically forego both the built-in =E2=80=9Ccl=
aims=E2=80=9D and
>>>> =E2=80=9Cresources=E2=80=9D parts of the request, and use the =E2=80=
=9Coidc_claims_query=E2=80=9D member
>>>> (or whatever it would be called). This would let such an extension use=
 the
>>>> OIDC claims processing mechanism as it is today.
>>>>
>>>> To me, this remains much more understandable, extensible, and clean.
>>>>
>>>
>>> While this may be more understandable to a developer just porting an ap=
p
>>> OIDC that only wants OIDC results, but I think it is more complicated a=
s
>>> soon as the developer wants other results, which is likely what prompte=
d
>>> the developer to use GNAP instead of ODIC.
>>>
>>> I think it is easier to understand if all the claims are in one
>>> container, and all the authorizations are in another container.
>>>
>>> If a developer wants access to some resources, some claims, and an
>>> OpenID Token, they are having to use "claims", "resources", and
>>> "oidc_claims_query".  Now the claims and access tokens are spread acros=
s
>>> multiple containers. There are some claims in the "claims" container, a=
nd
>>> some "claims" in the "oidc_claims_query" container. And is the access t=
oken
>>> response in "oidc_claims_query" the same as an access token response in
>>> "resources"? It would seem simpler if they were, and if all the access
>>> tokens came back in the same container.
>>>
>>> Per Aaron's post that you have referred to, the developer can get sme
>>> bare claims directly in the response in the "claims" object, an ID Toke=
n
>>> that has the same or different claims, and if they want, an access toke=
n
>>> that they can call a user_info endpoint to get the same, or different
>>> claims.
>>>
>>> For example, an enterprise app client may want an ID Token with the
>>> email address, bare claims for the user's name and a URI to a profile
>>> photo, and an access token to query which groups a user belongs to.
>>>
>>> We are still re-using the OIDC claims, but we are not mixing claims and
>>> authorizations.
>>>
>>> /Dick
>>>
>>>
>>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
>>> =E1=90=A7
>>>
>>>
>>> =E1=90=A7
>>
>>
>> =E1=90=A7
>
>
> =E1=90=A7

--0000000000000052f605aa074161
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Yes. Which is why I referred to Aaron's post orig=
inally which calls out for returning plain text claims.

I don't really understand what you mean by "OIDC claims quer=
y language". The claims mean the same thing. And I was also reusing th=
e modifiers such as {"essential": true}. What top level functiona=
lity are=C2=A0you referring to?

On Thu, Jul 9, 2020 at 12:21 PM J=
ustin Richer <jricher@mit.edu>=
 wrote:
Ah, so you=E2=80=99re saying that the =E2=
=80=9Cuserinfo=E2=80=9D claims would be returned directly? I didn=E2=80=99t=
 realize that you had intended to change how the OIDC claims query language=
 functioned in your examples, and had assumed it would work the same was as=
 the spec you were referencing. Your example of splitting it up makes that =
more clear. Though I would argue at that point, you=E2=80=99re creating a n=
ew query language since you=E2=80=99re not using the top-level functionalit=
y from ODIC=E2=80=99s definition.

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


On Jul 9, 2020, at 3:15 PM, Dic=
k Hardt <dick.=
hardt@gmail.com> wrote:

You are jumping to ma=
ny conclusions below. Let me break down the proposal into some bite size ch=
unks.

The developer would like to get some plain t=
ext OIDC claims about the user:

=C2=A0 =C2=A0 &quo=
t;claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "oidc": {
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "userinfo" : {
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name" : { "=
;essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 "photo" : { "essential" : false }
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },

The deve=
loper would like to get an OIDC ID Token:

=C2=A0 =
=C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "oidc"=
: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id_token" : {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "email"=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "essential" : true },
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "email_verifie=
d" : { "essential" : true }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }

The =
developer would like to get an access token to acquire OIDC claims:

"authorizations": =
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type":"oidc",
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "claims": ["name", "pi=
cture"]
=C2=A0 =C2=A0 }

The developer would like to get an access token to access photos:<=
/div>

"authorizations": {=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type":"oauth_scope",
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": "read_photos"*
=
=C2=A0 =C2=A0 }

The developer would like to get so=
me VC claims:

"claims" {
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "vc": {
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "some_vc": "query_mechanism"=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
}

Th=
e developer would like to do all of the above at once:

=

{
=C2=A0 =C2=A0 "authorizations": {
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 "userinfo": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 "type":"oidc",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "claims": ["name", "picture"]=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "photo=
s": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type":&q=
uot;oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "s=
cope": "read_photos"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=
=A0 =C2=A0 },
=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 "oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &q=
uot;id_token" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 "email" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "essent=
ial" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "email_verified" : { "essential" : true }
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 "userinfo" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "name" : { "essential" : true },=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "photo"=
 : { "essential" : false }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 "vc":=
 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "some_vc": "query_mechanis=
m"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } =C2=A0=C2=A0
=C2=
=A0 =C2=A0 }
}

In the results, the develope=
r gets claims back in the response claims object, and access tokens etc. ba=
ck in the authorizations object. Just because an access token returns claim=
s, it is still an access token.

Yes, the developer=
=C2=A0can't get a single access token that can both acquire OIDC claims=
, and access photos (there are separate tokens for each), but I would argue=
 that separating the access is a positive security property, as a client co=
mponent accessing the user profile has a token independent of the client co=
mponent accessing photos. And at the AS, there is no requirement for the us=
erinfo endpoint to take the same token as the photo endpoint.
Somewhat of a tangent, I'm thinking that=C2=A0
=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
id_token" : {},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "use=
rinfo" : {}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },

is a little verbo=
se, and:

=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "oidc_token": {},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &q=
uot;oidc_info": {}
=C2=A0 =C2=A0 },

wo=
rks better and makes it easier to distinguish=C2=A0support for ID tokens vs=
 plain claims.

wrt. my position on reusing OIDC --=
 it has not changed. I have viewed the OIDC claims as the "query langu=
age". No need to reinvent that. We are creating a new protocol, so no =
need to use the OAuth or OIDC protocols.

* OA=
uth scopes could be a space separates string to be consistent with OAuth 2,=
 or an array of strings so that it is more JSON like. I have no strong opin=
ion.=C2=A0

scope.split(' ').forEach(=
)=C2=A0

is not that much more complex than=C2=A0

scope.forEach()


=

On Thu=
, Jul 9, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wrote:
But this approach doesn=E2=80=
=99t keep things in their respective containers =E2=80=94 you=E2=80=99ve ex=
plicitly got =E2=80=9Cclaims=E2=80=9D underneath the =E2=80=9Cauthorization=
s=E2=80=9D header, and you=E2=80=99ve got items that come back as rights as=
sociated with the access token (which should be =E2=80=9Cauthorizations=E2=
=80=9D) in the =E2=80=9Cuserinfo=E2=80=9D section under the =E2=80=9Cclaims=
=E2=80=9D header. And as far as I can tell, these two sections are redundan=
t to each other. Everything is everywhere.=C2=A0

A=
dditionally, this approach and syntax makes it difficult to combine differe=
nt kinds of requests into one. One of OpenID Connect=E2=80=99s biggest draw=
s, as I=E2=80=99m sure you recall, is that it could be combined with a requ=
est for non-OIDC resources. This was the real innovation that Twitter and F=
acebook=E2=80=99s identity APIs brought, access to more than just authentic=
ation, and what Google had tried to replicate with the awkward OpenID 2 + O=
Auth 1 hybrid system. Taking a step back from the existing solutions of Ope=
nID 2 and OAuth 1 let us, as the community, see the value in the pattern th=
at became OIDC on top of OAuth 2.=C2=A0

Sure, you =
could say that the =E2=80=9Coidc=E2=80=9D type also can allow a =E2=80=9Csc=
opes=E2=80=9D parameter, but what about a RAR style object, then? And what =
about when someone comes up with some new way to request access rights, or =
a VC-based query language? Does every =E2=80=9Ctype=E2=80=9D need to now kn=
ow about every other =E2=80=9Ctype=E2=80=9D in order for an AS to be able t=
o figure out how they go together? This seems like the protocol definition =
limiting what combinations the AS can handle, or what an RS might want to u=
se.

My stance is that GNAP should have a way to qu=
ery for rights in the access token (=E2=80=9Cauthorizations=E2=80=9D in xau=
th parlance) and identifiers for the user (=E2=80=9Cclaims=E2=80=9D in xaut=
h parlance), and anything else should be an extension with potentially diff=
erent models. The AS would process the =E2=80=9Cauthorizations=E2=80=9D equ=
ivalent (for the access token) alongside any other incoming query and then =
make a policy decision based on that.

I find it in=
teresting that you are now saying we don=E2=80=99t need to use the OIDC req=
uest format when previously you=E2=80=99ve made it clear that you were in f=
avor of pointing at external query languages, including their syntax. I=E2=
=80=99m glad to see that you=E2=80=99re now looking at things in a more fle=
xible way, but I think it=E2=80=99s important that we be careful and consci=
entious about how we reference any external query languages in GNAP.
<=
div>
=C2=A0=E2=80=94 Justin

On Jul 8, 2020, at 6:55 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Justin,

Just because=C2=A0we are using OIDC claims, does not mean we need to mimic=
 the OIDC request and response.
I was envisioning a grant request=
 could look as the following (using XAuth syntax):

{=

=C2=A0 =C2=A0 "authorizations": {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "type":"oidc",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
;claims": ["name", "picture"]
=C2=A0 =C2=A0 },<=
br>=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id_token&q=
uot; : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "e=
mail" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "essential" : tr=
ue },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "emai=
l_verified" : { "essential" : true }
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
;userinfo" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "name" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : { "essential=
" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 "picture" =C2=A0 =C2=A0 =C2=A0 =C2=A0: null
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=
=A0 }
}

Of course a developer could c=
hoose to only ask for a subset of this.

Note the n=
ew authorization type of "oidc", that takes "claims" ra=
ther than "scope".=C2=A0

This keeps all =
the authorizations and claims in their respective request and response cont=
ainers.

We had a thread months ago on the OIDC two=
 stage model, and I still fail to see why forcing that has any advantage.=
=C2=A0

/Dick


On Wed, Jul 8, 20=
20 at 3:25 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m glad that we can agree that the=
re are a number of things in legacy protocols that are unfortunate side eff=
ects of the circumstances in which they were built. Space-separated scope s=
trings, for instance, would fall in that category, as I=E2=80=99ve previous=
ly explained.

A key point in the below: the OIDC =E2=80=
=9Cclaims=E2=80=9D request already mixes user claims (returned in an API) a=
nd authorization (to fetch user claims from an API), so that ship has saile=
d if you=E2=80=99re using it. It doesn=E2=80=99t make sense to have it unde=
r a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D request, s=
ince it=E2=80=99s a query language that affects both. Maybe you=E2=80=99d c=
all this another =E2=80=9Cunfortunate design=E2=80=9D, but the context was =
about re-using an externally-defined query language that was not made for G=
NAP.

My scenario was for someone who is already using =
=E2=80=9Cclaims=E2=80=9D and wants to keep using it. (The vast majority of =
OIDC implementations, in my experience, don=E2=80=99t use that feature, and=
 it=E2=80=99s not even required to be implemented by the AS, but again we=
=E2=80=99re talking about using this feature as an example of an external q=
uery language =E2=80=94 and there are others out there.) In GNAP, you shoul=
d return claims directly in the response, and request specific elements fro=
m the APIs protected by the access token. These are separate things, and by=
 design both XAuth and XYZ have put them into separate containers in the re=
quest. This is a good design, and so putting something that conflates these=
 two aspects into one or the other of the containers is not a particularly =
good option, in my opinion.=C2=A0

Additionally, th=
ough this is a bit of an aside and getting into the specifics of identity, =
the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is a query language bound to=
 the full user profile. It is my stated position that the items coming back=
 from the AS should only be identifiers, and not full profile information. =
The reasoning is pretty simple: the client doesn=E2=80=99t know what profil=
e information it needs until it knows who the user is, so putting that into=
 a protected API like the UserInfo Endpoint makes much more sense than putt=
ing it into the immediate response, where it is not needed, because the cli=
ent already knows it. The AS doesn=E2=80=99t know what the client needs to =
know, either, so it can=E2=80=99t determine what to fulfill. OIDC=E2=80=99s=
 two-stage model makes sense, and GNAP should really only focus on enabling=
 this.

=C2=A0=E2=80=94 Justin

<=
blockquote type=3D"cite">
On Jul 8, 2020, at 6:10 PM, Dick Hardt <dick.hardt@gmail.co=
m> wrote:



On Wed, Jul 8=
, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at 3:16 PM, Dick Hardt &l=
t;dick.hardt@gmai=
l.com> wrote:

I think representing the request as an array is simp=
listic, and complicated at the same time.

On the simplis=
tic front, as there is no clear mechanism for extending the request with pr=
operties that apply to all of the request.=C2=A0

The elements of the array are taken as a set,=
 to be tied to the same resulting access token. If one of those elements is=
 defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s protecting, to app=
ly across some or all of the other elements, then that=E2=80=99s up to the =
AS=E2=80=99s policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, =
which switches on all sorts of contextual stuff in the request. So to handl=
e something like this, an AS can easily declare that a given scope-style st=
ring or a given object property applies to different parts of the request. =
You don=E2=80=99t need to externalize it here.

I view the "openid" scope as an unfortunate=
 design as OIDC was constrained by building=C2=A0on top of OAuth. (a proble=
m I hoped to avert by having "identity" in scope for GNAP) The &q=
uot;openid" scope does not function as scope=C2=A0per se, and I think =
it makes OIDC harder to understand as the "openid" scope causes n=
on-scope behavior.=C2=A0

=C2=A0

Do you h=
ave a concrete use case that requires that feature to be done in the way th=
at you describe? I am trying to separate the driving use case from the prop=
osed solutions to see what the differences are.=C2=A0

Perhaps the client wants access to be HIPPA co=
mpliant? The HIPPA compliance signal applies to the scopes.

<=
/div>
Adding other properties to an object is a well understood extensi=
on mechanism. Adding an additional element to an array that does not act li=
ke the other elements seems like a hack.

=C2=A0

Using JSON type polymorphism=C2=A0requires the AS to test each=
 member of the array to determine if it is a string or an object. Only afte=
r detecting a RAR object does the AS know the client is making a RAR reques=
t.=C2=A0

That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole res=
ources request in order to figure out what the client is asking for, anyway=
, whether it=E2=80=99s by strings or objects or whatever else might be defi=
ned by an extension. Is there an argument for having an AS do an early disp=
atch on a request before it=E2=80=99s fully parsed everything?
<=
/div>

Let me clarify, the code is looking a=
t the type of object that has been parsed.=C2=A0

D=
etermining if an item in an array is a scope or a RAR object by looking at =
the type being either a string or an object seems less clear than a propert=
y of an object explicitly declaring the type.

=C2=
=A0
Thi=
s also limits the request to be composed only of scope strings or RAR objec=
ts. I don't see how other strings or objects could be used in the array=
, so there is no clear extension point in the "resources" array f=
or other query mechanisms.

That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declarin=
g that a string has to be an OAuth2-style scope. It can be, but ultimately =
it=E2=80=99s just a string that the AS can understand. And the objects are =
just that =E2=80=94 objects. If the AS understands what the object is, it c=
an be a RAR object or it can be something completely API-specific with anot=
her query language entirely.

<=
div>But the other query language would need a type that has been reserved i=
n the RAR name space for there to be interop, so it effectively is a RAR ex=
tension.

There are query languages in other domain=
s that may not fit nicely into RAR such as a query for medical records.

Yes, the medical records could be yet another top lev=
el property, but per below, I think that is confusing.
=C2=A0
(Point, =
though: RAR already pretty much allows this by letting them be extended inf=
initely, a feature it inherits from XYZ)

I=E2=80=
=99m proposing that we do the same thing with GNAP: it=E2=80=99s an array o=
f strings or objects and each of those means the same thing, =E2=80=9Csomet=
hing the client is asking for=E2=80=9D.

=


Just as RAR has =
a "type" property, I propose the "resources" ("aut=
horizations" in XAuth) be an object, where the other properties are de=
termined by the "type" property. This allows extensions to define=
 new ways to query for an authorization rather than having to fit into scop=
es or RAR.


It=E2=80=99s my stance that this is an unnecessary limitation at thi=
s level. The objects within the array should be typed, like RAR, but it doe=
sn=E2=80=99t make sense for the overall request to be typed. Instead, there=
 should be one =E2=80=9Ctype" of query in the core, what XYZ calls the=
 =E2=80=9Cresources=E2=80=9D request. Other query languages should be added=
 as extensions either to the RAR-style objects (by defining a type at that =
level) or as a separate top-level member.

For exam=
ple, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D query language. M=
y current thought is that this really shouldn=E2=80=99t be a part of the =
=E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D part of the request=
, but instead as its own top-level member, like it is in the OIDC protocol =
today. The main reason for this is the nature of the OIDC claims language: =
it specifies targets for the resulting data, and those targets cross differ=
ent ways to return things. So it doesn=E2=80=99t actually affect just resou=
rces like the UserInfo Endpoint, or the ID Token, but both and potentially =
others out there. If your system supported such an extension, it could theo=
retically forego both the built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cre=
sources=E2=80=9D parts of the request, and use the =E2=80=9Coidc_claims_que=
ry=E2=80=9D member (or whatever it would be called). This would let such an=
 extension use the OIDC claims processing mechanism as it is today.

To me, this remains much more understandable, extensible,=
 and clean.

While this ma=
y be more understandable to a developer just=C2=A0porting an app OIDC that =
only wants OIDC results, but I think it is more complicated as soon as the =
developer wants other results, which is likely what=C2=A0prompted the devel=
oper to use GNAP instead of ODIC.

I think it is ea=
sier to understand if all the claims are in one container, and all the auth=
orizations are in another container.

If a develope=
r wants access to some resources, some claims, and an OpenID Token, they ar=
e having to use "claims", "resources", and "oidc_c=
laims_query".=C2=A0 Now the claims and access tokens are spread across=
 multiple containers. There are some claims in the "claims" conta=
iner, and some "claims" in the "oidc_claims_query" cont=
ainer. And is the access token response in=C2=A0"oidc_claims_query&quo=
t; the same as an access token response in "resources"? It would =
seem simpler if they were, and if all the access tokens came back in the sa=
me container.

Per Aaron's post that you have r=
eferred to, the developer can get sme bare claims directly in the response =
in the "claims" object, an ID Token that has the same or differen=
t claims, and if they want, an access token that they can call a user_info =
endpoint to get the same, or different claims.

For=
 example, an enterprise app client may want an ID Token with the email addr=
ess, bare claims for the user's name and a URI to a profile photo, and =
an access token to query which groups a user belongs to.

We are still re-using=C2=A0the OIDC claims, but we are not mixing cl=
aims and authorizations.

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

3D""=
=E1=90=A7

3D""=E1=90=A7

3D""=E1=90=A7


--0000000000000052f605aa074161--


From nobody Thu Jul  9 13:04: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 C9BDD3A05A4 for ; Thu,  9 Jul 2020 13:04:17 -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 moSdJcGLDmRc for ; Thu,  9 Jul 2020 13:04:13 -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 A78883A0744 for ; Thu,  9 Jul 2020 13:04:12 -0700 (PDT)
Received: from [192.168.1.7] (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 069K48R5006278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jul 2020 16:04:09 -0400
From: Justin Richer 
Message-Id: <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F257C6A5-3E87-4DC2-84FF-665EC442F134"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 9 Jul 2020 16:04:08 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 09 Jul 2020 20:04:18 -0000

--Apple-Mail=_F257C6A5-3E87-4DC2-84FF-665EC442F134
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

In Aaron=E2=80=99s post he doesn=E2=80=99t talk about how the request =
would be made, just what the response could look like, and we are =
talking about how to request that. Aaron=E2=80=99s post specifically =
calls out that this is just an identifier for the user and states:

If the application needs to know profile information about the user, it =
can get that from the userinfo endpoint using the access token it just =
obtained.

And I think that=E2=80=99s a good design pattern to follow. This isn=E2=80=
=99t =E2=80=9Cuserinfo=E2=80=9D being returned alongside the access =
token.=20

The top level functionality of the OIDC claims query language is this:


The top-level members of the Claims request JSON object are:

userinfo
OPTIONAL. Requests that the listed individual Claims be returned from =
the UserInfo Endpoint. If present, the listed Claims are being requested =
to be added to any Claims that are being requested using scope values. =
If not present, the Claims being requested from the UserInfo Endpoint =
are only those requested using scope values.
When the userinfo member is used, the request MUST also use a =
response_type value that results in an Access Token being issued to the =
Client for use at the UserInfo Endpoint.

id_token
OPTIONAL. Requests that the listed individual Claims be returned in the =
ID Token. If present, the listed Claims are being requested to be added =
to the default Claims in the ID Token. If not present, the default ID =
Token Claims are requested, as per the ID Token definition in Section 2 =
and per the additional per-flow ID Token requirements in Sections =
3.1.3.6, 3.2.2.10, 3.3.2.11, and 3.3.3.6.

Since you had re-used the =E2=80=9Cuserinfo=E2=80=9D and =E2=80=9Cid_token=
=E2=80=9D top-level claims, I had assumed that they meant the same thing =
as in the OIDC spec. It=E2=80=99s clear to me, now, that this isn=E2=80=99=
t what you meant, but this is why I=E2=80=99m saying you=E2=80=99re not =
using the whole query language.=20

There are proposed extensions to the OIDC claims query that would put =
returned data into a different place[1], and so it would be possible to =
use the claims structures to handle this. But at that point if the goal =
is just to use the internal query format, then I think that we can do =
better using =E2=80=A6 polymorphic JSON. :)

My stance is that we allow the client to ask for a small set of =
identifiers about the user, or even just ask to =E2=80=9Cidentify the =
user=E2=80=9D, and leave everything else to a higher level identity =
protocol. I do not think that having an identity and profile =
query/response language at the core of GNAP is a good idea, and it=E2=80=99=
s certainly not in our charter.

 =E2=80=94 Justin

[1] https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ =
 =
defines a =E2=80=9Ccredential=E2=80=99 target.

> On Jul 9, 2020, at 3:29 PM, Dick Hardt  wrote:
>=20
> Yes. Which is why I referred to Aaron's post originally which calls =
out for returning plain text claims.
>=20
> I don't really understand what you mean by "OIDC claims query =
language". The claims mean the same thing. And I was also reusing the =
modifiers such as {"essential": true}. What top level functionality are =
you referring to?
>=20
> On Thu, Jul 9, 2020 at 12:21 PM Justin Richer > wrote:
> Ah, so you=E2=80=99re saying that the =E2=80=9Cuserinfo=E2=80=9D =
claims would be returned directly? I didn=E2=80=99t realize that you had =
intended to change how the OIDC claims query language functioned in your =
examples, and had assumed it would work the same was as the spec you =
were referencing. Your example of splitting it up makes that more clear. =
Though I would argue at that point, you=E2=80=99re creating a new query =
language since you=E2=80=99re not using the top-level functionality from =
ODIC=E2=80=99s definition.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 9, 2020, at 3:15 PM, Dick Hardt > wrote:
>>=20
>> You are jumping to many conclusions below. Let me break down the =
proposal into some bite size chunks.
>>=20
>> The developer would like to get some plain text OIDC claims about the =
user:
>>=20
>>     "claims":{
>>         "oidc": {
>>             "userinfo" : {
>>                 "name" : { "essential" : true },
>>                 "photo" : { "essential" : false }
>>             },
>>=20
>> The developer would like to get an OIDC ID Token:
>>=20
>>     "claims":{
>>         "oidc": {
>>             "id_token" : {
>>                 "email"          : { "essential" : true },
>>                 "email_verified" : { "essential" : true }
>>             }
>>     }
>>=20
>> The developer would like to get an access token to acquire OIDC =
claims:
>>=20
>> "authorizations": {
>>         "type":"oidc",
>>         "claims": ["name", "picture"]
>>     }
>>=20
>> The developer would like to get an access token to access photos:
>>=20
>> "authorizations": {
>>         "type":"oauth_scope",
>>         "scope": "read_photos"*
>>     }
>>=20
>> The developer would like to get some VC claims:
>>=20
>> "claims" {
>>         "vc": {
>>             "some_vc": "query_mechanism"
>>         }
>> }
>>=20
>> The developer would like to do all of the above at once:
>>=20
>> {
>>     "authorizations": {
>>         "userinfo": {
>>             "type":"oidc",
>>             "claims": ["name", "picture"]
>>         },
>>         "photos": {
>>             "type":"oauth_scope",
>>             "scope": "read_photos"
>>         }
>>     },
>>     "claims":{
>>         "oidc": {
>>             "id_token" : {
>>                 "email"          : { "essential" : true },
>>                 "email_verified" : { "essential" : true }
>>             },
>>             "userinfo" : {
>>                 "name" : { "essential" : true },
>>                 "photo" : { "essential" : false }
>>             }
>>         },
>>     "vc": {
>>         "some_vc": "query_mechanism"
>>         }  =20
>>     }
>> }
>>=20
>> In the results, the developer gets claims back in the response claims =
object, and access tokens etc. back in the authorizations object. Just =
because an access token returns claims, it is still an access token.
>>=20
>> Yes, the developer can't get a single access token that can both =
acquire OIDC claims, and access photos (there are separate tokens for =
each), but I would argue that separating the access is a positive =
security property, as a client component accessing the user profile has =
a token independent of the client component accessing photos. And at the =
AS, there is no requirement for the userinfo endpoint to take the same =
token as the photo endpoint.
>>=20
>> Somewhat of a tangent, I'm thinking that=20
>>=20
>>     "claims":{
>>         "oidc": {
>>             "id_token" : {},
>>             "userinfo" : {}
>>         },
>>=20
>> is a little verbose, and:
>>=20
>>     "claims":{
>>         "oidc_token": {},
>>         "oidc_info": {}
>>     },
>>=20
>> works better and makes it easier to distinguish support for ID tokens =
vs plain claims.
>>=20
>> wrt. my position on reusing OIDC -- it has not changed. I have viewed =
the OIDC claims as the "query language". No need to reinvent that. We =
are creating a new protocol, so no need to use the OAuth or OIDC =
protocols.
>>=20
>> * OAuth scopes could be a space separates string to be consistent =
with OAuth 2, or an array of strings so that it is more JSON like. I =
have no strong opinion.=20
>>=20
>> scope.split(' ').forEach()=20
>>=20
>> is not that much more complex than=20
>>=20
>> scope.forEach()
>>=20
>>=20
>>=20
>> On Thu, Jul 9, 2020 at 8:39 AM Justin Richer > wrote:
>> But this approach doesn=E2=80=99t keep things in their respective =
containers =E2=80=94 you=E2=80=99ve explicitly got =E2=80=9Cclaims=E2=80=9D=
 underneath the =E2=80=9Cauthorizations=E2=80=9D header, and you=E2=80=99v=
e got items that come back as rights associated with the access token =
(which should be =E2=80=9Cauthorizations=E2=80=9D) in the =E2=80=9Cuserinf=
o=E2=80=9D section under the =E2=80=9Cclaims=E2=80=9D header. And as far =
as I can tell, these two sections are redundant to each other. =
Everything is everywhere.=20
>>=20
>> Additionally, this approach and syntax makes it difficult to combine =
different kinds of requests into one. One of OpenID Connect=E2=80=99s =
biggest draws, as I=E2=80=99m sure you recall, is that it could be =
combined with a request for non-OIDC resources. This was the real =
innovation that Twitter and Facebook=E2=80=99s identity APIs brought, =
access to more than just authentication, and what Google had tried to =
replicate with the awkward OpenID 2 + OAuth 1 hybrid system. Taking a =
step back from the existing solutions of OpenID 2 and OAuth 1 let us, as =
the community, see the value in the pattern that became OIDC on top of =
OAuth 2.=20
>>=20
>> Sure, you could say that the =E2=80=9Coidc=E2=80=9D type also can =
allow a =E2=80=9Cscopes=E2=80=9D parameter, but what about a RAR style =
object, then? And what about when someone comes up with some new way to =
request access rights, or a VC-based query language? Does every =
=E2=80=9Ctype=E2=80=9D need to now know about every other =E2=80=9Ctype=E2=
=80=9D in order for an AS to be able to figure out how they go together? =
This seems like the protocol definition limiting what combinations the =
AS can handle, or what an RS might want to use.
>>=20
>> My stance is that GNAP should have a way to query for rights in the =
access token (=E2=80=9Cauthorizations=E2=80=9D in xauth parlance) and =
identifiers for the user (=E2=80=9Cclaims=E2=80=9D in xauth parlance), =
and anything else should be an extension with potentially different =
models. The AS would process the =E2=80=9Cauthorizations=E2=80=9D =
equivalent (for the access token) alongside any other incoming query and =
then make a policy decision based on that.
>>=20
>> I find it interesting that you are now saying we don=E2=80=99t need =
to use the OIDC request format when previously you=E2=80=99ve made it =
clear that you were in favor of pointing at external query languages, =
including their syntax. I=E2=80=99m glad to see that you=E2=80=99re now =
looking at things in a more flexible way, but I think it=E2=80=99s =
important that we be careful and conscientious about how we reference =
any external query languages in GNAP.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 8, 2020, at 6:55 PM, Dick Hardt > wrote:
>>>=20
>>> Hey Justin,
>>>=20
>>> Just because we are using OIDC claims, does not mean we need to =
mimic the OIDC request and response.
>>> I was envisioning a grant request could look as the following (using =
XAuth syntax):
>>>=20
>>> {
>>>     "authorizations": {
>>>         "type":"oidc",
>>>         "claims": ["name", "picture"]
>>>     },
>>>     "claims":{
>>>         "oidc": {
>>>             "id_token" : {
>>>                 "email"          : { "essential" : true },
>>>                 "email_verified" : { "essential" : true }
>>>             },
>>>             "userinfo" : {
>>>                 "name"           : { "essential" : true },
>>>                 "picture"        : null
>>>             }
>>>         }
>>>     }
>>> }
>>>=20
>>> Of course a developer could choose to only ask for a subset of this.
>>>=20
>>> Note the new authorization type of "oidc", that takes "claims" =
rather than "scope".=20
>>>=20
>>> This keeps all the authorizations and claims in their respective =
request and response containers.
>>>=20
>>> We had a thread months ago on the OIDC two stage model, and I still =
fail to see why forcing that has any advantage.=20
>>>=20
>>> /Dick
>>>=20
>>>=20
>>> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer > wrote:
>>> I=E2=80=99m glad that we can agree that there are a number of things =
in legacy protocols that are unfortunate side effects of the =
circumstances in which they were built. Space-separated scope strings, =
for instance, would fall in that category, as I=E2=80=99ve previously =
explained.
>>>=20
>>> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request =
already mixes user claims (returned in an API) and authorization (to =
fetch user claims from an API), so that ship has sailed if you=E2=80=99re =
using it. It doesn=E2=80=99t make sense to have it under a =E2=80=9Cclaims=
=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s =
a query language that affects both. Maybe you=E2=80=99d call this =
another =E2=80=9Cunfortunate design=E2=80=9D, but the context was about =
re-using an externally-defined query language that was not made for =
GNAP.
>>>=20
>>> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=
=9D and wants to keep using it. (The vast majority of OIDC =
implementations, in my experience, don=E2=80=99t use that feature, and =
it=E2=80=99s not even required to be implemented by the AS, but again =
we=E2=80=99re talking about using this feature as an example of an =
external query language =E2=80=94 and there are others out there.) In =
GNAP, you should return claims directly in the response, and request =
specific elements from the APIs protected by the access token. These are =
separate things, and by design both XAuth and XYZ have put them into =
separate containers in the request. This is a good design, and so =
putting something that conflates these two aspects into one or the other =
of the containers is not a particularly good option, in my opinion.=20
>>>=20
>>> Additionally, though this is a bit of an aside and getting into the =
specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is =
a query language bound to the full user profile. It is my stated =
position that the items coming back from the AS should only be =
identifiers, and not full profile information. The reasoning is pretty =
simple: the client doesn=E2=80=99t know what profile information it =
needs until it knows who the user is, so putting that into a protected =
API like the UserInfo Endpoint makes much more sense than putting it =
into the immediate response, where it is not needed, because the client =
already knows it. The AS doesn=E2=80=99t know what the client needs to =
know, either, so it can=E2=80=99t determine what to fulfill. OIDC=E2=80=99=
s two-stage model makes sense, and GNAP should really only focus on =
enabling this.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>> On Jul 8, 2020, at 6:10 PM, Dick Hardt > wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer > wrote:
>>>> On Jul 8, 2020, at 3:16 PM, Dick Hardt > wrote:
>>>>>=20
>>>>> I think representing the request as an array is simplistic, and =
complicated at the same time.
>>>>>=20
>>>>> On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the request.=20=

>>>>=20
>>>> The elements of the array are taken as a set, to be tied to the =
same resulting access token. If one of those elements is defined, by the =
AS and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some =
or all of the other elements, then that=E2=80=99s up to the AS=E2=80=99s =
policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, which =
switches on all sorts of contextual stuff in the request. So to handle =
something like this, an AS can easily declare that a given scope-style =
string or a given object property applies to different parts of the =
request. You don=E2=80=99t need to externalize it here.
>>>>=20
>>>> I view the "openid" scope as an unfortunate design as OIDC was =
constrained by building on top of OAuth. (a problem I hoped to avert by =
having "identity" in scope for GNAP) The "openid" scope does not =
function as scope per se, and I think it makes OIDC harder to understand =
as the "openid" scope causes non-scope behavior.=20
>>>>=20
>>>> =20
>>>>=20
>>>> Do you have a concrete use case that requires that feature to be =
done in the way that you describe? I am trying to separate the driving =
use case from the proposed solutions to see what the differences are.=20
>>>>=20
>>>> Perhaps the client wants access to be HIPPA compliant? The HIPPA =
compliance signal applies to the scopes.
>>>>=20
>>>> Adding other properties to an object is a well understood extension =
mechanism. Adding an additional element to an array that does not act =
like the other elements seems like a hack.
>>>>=20
>>>> =20
>>>>=20
>>>>>=20
>>>>> Using JSON type polymorphism requires the AS to test each member =
of the array to determine if it is a string or an object. Only after =
detecting a RAR object does the AS know the client is making a RAR =
request.=20
>>>>=20
>>>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the =
whole resources request in order to figure out what the client is asking =
for, anyway, whether it=E2=80=99s by strings or objects or whatever else =
might be defined by an extension. Is there an argument for having an AS =
do an early dispatch on a request before it=E2=80=99s fully parsed =
everything?
>>>>=20
>>>> Let me clarify, the code is looking at the type of object that has =
been parsed.=20
>>>>=20
>>>> Determining if an item in an array is a scope or a RAR object by =
looking at the type being either a string or an object seems less clear =
than a property of an object explicitly declaring the type.
>>>>=20
>>>> =20
>>>>=20
>>>>> This also limits the request to be composed only of scope strings =
or RAR objects. I don't see how other strings or objects could be used =
in the array, so there is no clear extension point in the "resources" =
array for other query mechanisms.
>>>>=20
>>>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t =
declaring that a string has to be an OAuth2-style scope. It can be, but =
ultimately it=E2=80=99s just a string that the AS can understand. And =
the objects are just that =E2=80=94 objects. If the AS understands what =
the object is, it can be a RAR object or it can be something completely =
API-specific with another query language entirely.
>>>>=20
>>>> But the other query language would need a type that has been =
reserved in the RAR name space for there to be interop, so it =
effectively is a RAR extension.
>>>>=20
>>>> There are query languages in other domains that may not fit nicely =
into RAR such as a query for medical records.
>>>>=20
>>>> Yes, the medical records could be yet another top level property, =
but per below, I think that is confusing.
>>>> =20
>>>> (Point, though: RAR already pretty much allows this by letting them =
be extended infinitely, a feature it inherits from XYZ)
>>>>=20
>>>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99=
s an array of strings or objects and each of those means the same thing, =
=E2=80=9Csomething the client is asking for=E2=80=9D.
>>>>=20
>>>>>=20
>>>>> Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.
>>>>>=20
>>>>=20
>>>> It=E2=80=99s my stance that this is an unnecessary limitation at =
this level. The objects within the array should be typed, like RAR, but =
it doesn=E2=80=99t make sense for the overall request to be typed. =
Instead, there should be one =E2=80=9Ctype" of query in the core, what =
XYZ calls the =E2=80=9Cresources=E2=80=9D request. Other query languages =
should be added as extensions either to the RAR-style objects (by =
defining a type at that level) or as a separate top-level member.
>>>>=20
>>>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D =
query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.
>>>>=20
>>>> To me, this remains much more understandable, extensible, and =
clean.
>>>>=20
>>>> While this may be more understandable to a developer just porting =
an app OIDC that only wants OIDC results, but I think it is more =
complicated as soon as the developer wants other results, which is =
likely what prompted the developer to use GNAP instead of ODIC.
>>>>=20
>>>> I think it is easier to understand if all the claims are in one =
container, and all the authorizations are in another container.
>>>>=20
>>>> If a developer wants access to some resources, some claims, and an =
OpenID Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread across =
multiple containers. There are some claims in the "claims" container, =
and some "claims" in the "oidc_claims_query" container. And is the =
access token response in "oidc_claims_query" the same as an access token =
response in "resources"? It would seem simpler if they were, and if all =
the access tokens came back in the same container.
>>>>=20
>>>> Per Aaron's post that you have referred to, the developer can get =
sme bare claims directly in the response in the "claims" object, an ID =
Token that has the same or different claims, and if they want, an access =
token that they can call a user_info endpoint to get the same, or =
different claims.
>>>>=20
>>>> For example, an enterprise app client may want an ID Token with the =
email address, bare claims for the user's name and a URI to a profile =
photo, and an access token to query which groups a user belongs to.
>>>>=20
>>>> We are still re-using the OIDC claims, but we are not mixing claims =
and authorizations.
>>>>=20
>>>> /Dick
>>>>=20
>>>>=20
>>>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz =

>>>> =E1=90=A7
>>>=20
>>> =E1=90=A7
>>=20
>> =E1=90=A7
>=20
> =E1=90=A7


--Apple-Mail=_F257C6A5-3E87-4DC2-84FF-665EC442F134
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

In =
Aaron=E2=80=99s post he doesn=E2=80=99t talk about how the request would =
be made, just what the response could look like, and we are talking =
about how to request that. Aaron=E2=80=99s post specifically calls out =
that this is just an identifier for the user and states:

If the =
application needs to know profile information about the user, =
it can get that from the userinfo endpoint using the access =
token it just obtained.

And I think that=E2=80=99s a good =
design pattern to follow. This isn=E2=80=99t =E2=80=9Cuserinfo=E2=80=9D =
being returned alongside the access token. 

The top level functionality of the OIDC =
claims query language is this:


The top-level members of the Claims request JSON object =
are:

userinfo
OPTIONAL. Requests that =
the listed individual Claims be returned from =
the UserInfo Endpoint. If present, the listed Claims are =
being requested to be added to any Claims that are being =
requested using scope values. If not present, the =
Claims being requested from the UserInfo Endpoint are =
only those requested using scope values.
When the userinfo member is used, the request =
MUST also use a response_type value that results in an Access Token being issued to the Client for use at =
the UserInfo Endpoint.

id_token
OPTIONAL. Requests that =
the listed individual Claims be returned in the =
ID Token. If present, the listed Claims are being requested to =
be added to the default Claims in the ID Token. If not =
present, the default ID Token Claims are requested, as per the =
ID Token definition in Section 2 and per the additional =
per-flow ID Token requirements in =
Sections 3.1.3.6, 3.2.2.10, 3.3.2.11, and 3.3.3.6=
.

Since =
you had re-used the =E2=80=9Cuserinfo=E2=80=9D and =E2=80=9Cid_token=E2=80=
=9D top-level claims, I had assumed that they meant the same thing as in =
the OIDC spec. It=E2=80=99s clear to me, now, that this isn=E2=80=99t =
what you meant, but this is why I=E2=80=99m saying you=E2=80=99re not =
using the whole query language. 

There are proposed extensions to the OIDC claims =
query that would put returned data into a different place[1], and so it =
would be possible to use the claims structures to handle this. But at =
that point if the goal is just to use the internal query format, then I =
think that we can do better using =E2=80=A6 polymorphic JSON. =
:)

My stance is that we allow the =
client to ask for a small set of identifiers about the user, or even =
just ask to =E2=80=9Cidentify the user=E2=80=9D, and leave everything =
else to a higher level identity protocol. I do not think that having an =
identity and profile query/response language at the core of GNAP is a =
good idea, and it=E2=80=99s certainly not in our charter.

 =E2=80=94 Justin

[1] https://mattrglobal.github.io/oidc-client-bound-assertions-spec=
/ defines a =E2=80=9Ccredential=E2=80=99 target.

On Jul =
9, 2020, at 3:29 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Yes. Which is why =
I referred to Aaron's post originally which calls out for returning =
plain text claims.

I don't really understand what you mean by "OIDC claims query =
language". The claims mean the same thing. And I was also reusing the =
modifiers such as {"essential": true}. What top level functionality =
are you referring to?

On Thu, Jul =
9, 2020 at 12:21 PM Justin Richer <jricher@mit.edu> wrote:
Ah, so you=E2=80=99re saying that the =
=E2=80=9Cuserinfo=E2=80=9D claims would be returned directly? I didn=E2=80=
=99t realize that you had intended to change how the OIDC claims query =
language functioned in your examples, and had assumed it would work the =
same was as the spec you were referencing. Your example of splitting it =
up makes that more clear. Though I would argue at that point, you=E2=80=99=
re creating a new query language since you=E2=80=99re not using the =
top-level functionality from ODIC=E2=80=99s definition.
 =E2=80=94 Justin

On Jul 9, 2020, at 3:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

You are jumping to many =
conclusions below. Let me break down the proposal into some bite size =
chunks.

The =
developer would like to get some plain text OIDC claims about the =
user:

  =
  "claims":{
        "oidc": {
            "userinfo" : {
                =
"name" : { "essential" : true },
      =
          "photo" : { "essential" : false }
            },

The =
developer would like to get an OIDC ID Token:

    "claims":{
        "oidc": {
  =
          "id_token" : {
  =
              "email"     =
     : { "essential" : true },
  =
              "email_verified" : { =
"essential" : true }
          =
  }
    }

The developer would like =
to get an access token to acquire OIDC claims:

"authorizations": {
        =
"type":"oidc",
        "claims": =
["name", "picture"]
    }

The developer would like to get an =
access token to access photos:

"authorizations": {
        =
"type":"oauth_scope",
        "scope": =
"read_photos"*
    }

The developer would like to get some VC =
claims:

"claims"=
 {
        "vc": {
          =
  "some_vc": "query_mechanism"
      =
  }
}

The developer would like to do all of =
the above at once:

{
    "authorizations": {
        "userinfo": {
  =
          "type":"oidc",
  =
          "claims": ["name", "picture"]
        },
    =
    "photos": {
        =
    "type":"oauth_scope",
      =
      "scope": "read_photos"
    =
    }
    },
  =
  "claims":{
        "oidc": {
            "id_token" : {
                =
"email"          : { "essential" : true },
                =
"email_verified" : { "essential" : true }
    =
        },
        =
    "userinfo" : {
        =
        "name" : { "essential" : true },
                =
"photo" : { "essential" : false }
      =
      }
        },
    "vc": {
      =
  "some_vc": "query_mechanism"
      =
  }   
  =
  }
}

In the results, the developer gets =
claims back in the response claims object, and access tokens etc. back =
in the authorizations object. Just because an access token returns =
claims, it is still an access token.

Yes, the developer can't get a =
single access token that can both acquire OIDC claims, and access photos =
(there are separate tokens for each), but I would argue that separating =
the access is a positive security property, as a client component =
accessing the user profile has a token independent of the client =
component accessing photos. And at the AS, there is no requirement for =
the userinfo endpoint to take the same token as the photo =
endpoint.

Somewhat of a tangent, I'm thinking that 

    =
"claims":{
        "oidc": {
            "id_token" : {},
            "userinfo" : {}
        },

is =
a little verbose, and:

    =
"claims":{
        "oidc_token": =
{},
        "oidc_info": {}
    },

works better and makes it easier to =
distinguish support for ID tokens vs plain claims.

wrt. my position on =
reusing OIDC -- it has not changed. I have viewed the OIDC claims as the =
"query language". No need to reinvent that. We are creating a new =
protocol, so no need to use the OAuth or OIDC protocols.

* OAuth =
scopes could be a space separates string to be consistent with OAuth 2, =
or an array of strings so that it is more JSON like. I have no strong =
opinion. 

scope.split(' ').forEach() 

is not that much more complex =
than 

scope.forEach()



On Thu, Jul =
9, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wrote:
But =
this approach doesn=E2=80=99t keep things in their respective containers =
=E2=80=94 you=E2=80=99ve explicitly got =E2=80=9Cclaims=E2=80=9D =
underneath the =E2=80=9Cauthorizations=E2=80=9D header, and you=E2=80=99ve=
 got items that come back as rights associated with the access token =
(which should be =E2=80=9Cauthorizations=E2=80=9D) in the =E2=80=9Cuserinf=
o=E2=80=9D section under the =E2=80=9Cclaims=E2=80=9D header. And as far =
as I can tell, these two sections are redundant to each other. =
Everything is everywhere. 

Additionally, this approach and syntax =
makes it difficult to combine different kinds of requests into one. One =
of OpenID Connect=E2=80=99s biggest draws, as I=E2=80=99m sure you =
recall, is that it could be combined with a request for non-OIDC =
resources. This was the real innovation that Twitter and Facebook=E2=80=99=
s identity APIs brought, access to more than just authentication, and =
what Google had tried to replicate with the awkward OpenID 2 + OAuth 1 =
hybrid system. Taking a step back from the existing solutions of OpenID =
2 and OAuth 1 let us, as the community, see the value in the pattern =
that became OIDC on top of OAuth 2. 

Sure, you could say that the =E2=80=9Coid=
c=E2=80=9D type also can allow a =E2=80=9Cscopes=E2=80=9D parameter, but =
what about a RAR style object, then? And what about when someone comes =
up with some new way to request access rights, or a VC-based query =
language? Does every =E2=80=9Ctype=E2=80=9D need to now know about every =
other =E2=80=9Ctype=E2=80=9D in order for an AS to be able to figure out =
how they go together? This seems like the protocol definition limiting =
what combinations the AS can handle, or what an RS might want to =
use.

My stance =
is that GNAP should have a way to query for rights in the access token =
(=E2=80=9Cauthorizations=E2=80=9D in xauth parlance) and identifiers for =
the user (=E2=80=9Cclaims=E2=80=9D in xauth parlance), and anything else =
should be an extension with potentially different models. The AS would =
process the =E2=80=9Cauthorizations=E2=80=9D equivalent (for the access =
token) alongside any other incoming query and then make a policy =
decision based on that.

I find it interesting that you are now saying we don=E2=80=99t =
need to use the OIDC request format when previously you=E2=80=99ve made =
it clear that you were in favor of pointing at external query languages, =
including their syntax. I=E2=80=99m glad to see that you=E2=80=99re now =
looking at things in a more flexible way, but I think it=E2=80=99s =
important that we be careful and conscientious about how we reference =
any external query languages in GNAP.

 =E2=80=94 Justin

On Jul 8, 2020, at 6:55 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey =
Justin,

Just =
because we are using OIDC claims, does not mean we need to mimic =
the OIDC request and response.
I was envisioning a =
grant request could look as the following (using XAuth syntax):

{
    "authorizations": {
    =
    "type":"oidc",
        =
"claims": ["name", "picture"]
    },
    "claims":{
      =
  "oidc": {
            =
"id_token" : {
            =
    "email"          : { "essential" =
: true },
              =
  "email_verified" : { "essential" : true }
  =
          },
      =
      "userinfo" : {
      =
          "name"         =
  : { "essential" : true },
      =
          "picture"       =
 : null
            =
}
        }
  =
  }
}

Of course a developer could choose to =
only ask for a subset of this.

Note the new authorization type of =
"oidc", that takes "claims" rather than "scope". 

This keeps all the =
authorizations and claims in their respective request and response =
containers.

We =
had a thread months ago on the OIDC two stage model, and I still fail to =
see why forcing that has any advantage. 

/Dick


On Wed, Jul 8, 2020 at 3:25 PM Justin =
Richer <jricher@mit.edu> wrote:
I=E2=80=99m =
glad that we can agree that there are a number of things in legacy =
protocols that are unfortunate side effects of the circumstances in =
which they were built. Space-separated scope strings, for instance, =
would fall in that category, as I=E2=80=99ve previously explained.

A key point in the =
below: the OIDC =E2=80=9Cclaims=E2=80=9D request already mixes user =
claims (returned in an API) and authorization (to fetch user claims from =
an API), so that ship has sailed if you=E2=80=99re using it. It =
doesn=E2=80=99t make sense to have it under a =E2=80=9Cclaims=E2=80=9D =
or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s a query =
language that affects both. Maybe you=E2=80=99d call this another =
=E2=80=9Cunfortunate design=E2=80=9D, but the context was about re-using =
an externally-defined query language that was not made for GNAP.

My scenario was for =
someone who is already using =E2=80=9Cclaims=E2=80=9D and wants to keep =
using it. (The vast majority of OIDC implementations, in my experience, =
don=E2=80=99t use that feature, and it=E2=80=99s not even required to be =
implemented by the AS, but again we=E2=80=99re talking about using this =
feature as an example of an external query language =E2=80=94 and there =
are others out there.) In GNAP, you should return claims directly in the =
response, and request specific elements from the APIs protected by the =
access token. These are separate things, and by design both XAuth and =
XYZ have put them into separate containers in the request. This is a =
good design, and so putting something that conflates these two aspects =
into one or the other of the containers is not a particularly good =
option, in my opinion. 

Additionally, though this is a bit of =
an aside and getting into the specifics of identity, the =E2=80=9Cclaims=E2=
=80=9D parameter of ODIC is a query language bound to the full user =
profile. It is my stated position that the items coming back from the AS =
should only be identifiers, and not full profile information. The =
reasoning is pretty simple: the client doesn=E2=80=99t know what profile =
information it needs until it knows who the user is, so putting that =
into a protected API like the UserInfo Endpoint makes much more sense =
than putting it into the immediate response, where it is not needed, =
because the client already knows it. The AS doesn=E2=80=99t know what =
the client needs to know, either, so it can=E2=80=99t determine what to =
fulfill. OIDC=E2=80=99s two-stage model makes sense, and GNAP should =
really only focus on enabling this.

 =E2=80=94 Justin

On Jul 8, 2020, at 6:10 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Wed, Jul =
8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at =
3:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I think representing the request as an array is simplistic, =
and complicated at the same time.

On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the =
request. 

The elements of the array are taken as =
a set, to be tied to the same resulting access token. If one of those =
elements is defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s =
protecting, to apply across some or all of the other elements, then =
that=E2=80=99s up to the AS=E2=80=99s policy. Much like the =E2=80=9Copeni=
d=E2=80=9D scope in OIDC, which switches on all sorts of contextual =
stuff in the request. So to handle something like this, an AS can easily =
declare that a given scope-style string or a given object property =
applies to different parts of the request. You don=E2=80=99t need to =
externalize it here.

I view the "openid" scope as an =
unfortunate design as OIDC was constrained by building on top of =
OAuth. (a problem I hoped to avert by having "identity" in scope for =
GNAP) The "openid" scope does not function as scope per se, and I =
think it makes OIDC harder to understand as the "openid" scope causes =
non-scope behavior. 

 

Do you have a concrete =
use case that requires that feature to be done in the way that you =
describe? I am trying to separate the driving use case from the proposed =
solutions to see what the differences =
are. 

Perhaps the client wants access to be =
HIPPA compliant? The HIPPA compliance signal applies to the =
scopes.

Adding =
other properties to an object is a well understood extension mechanism. =
Adding an additional element to an array that does not act like the =
other elements seems like a hack.

 


Using =
JSON type polymorphism requires the AS to test each member of the =
array to determine if it is a string or an object. Only after detecting =
a RAR object does the AS know the client is making a RAR request. 

That=E2=80=99s correct =
=E2=80=94 but the AS needs to parse the whole resources request in order =
to figure out what the client is asking for, anyway, whether it=E2=80=99s =
by strings or objects or whatever else might be defined by an extension. =
Is there an argument for having an AS do an early dispatch on a request =
before it=E2=80=99s fully parsed =
everything?

Let me clarify, the code is looking at =
the type of object that has been parsed. 

Determining if an item in an array is a =
scope or a RAR object by looking at the type being either a string or an =
object seems less clear than a property of an object explicitly =
declaring the type.

 

This =
also limits the request to be composed only of scope strings or RAR =
objects. I don't see how other strings or objects could be used in the =
array, so there is no clear extension point in the "resources" array for =
other query mechanisms.

That=E2=80=99s not the =
case in XYZ since we aren=E2=80=99t declaring that a string has to be an =
OAuth2-style scope. It can be, but ultimately it=E2=80=99s just a string =
that the AS can understand. And the objects are just that =E2=80=94 =
objects. If the AS understands what the object is, it can be a RAR =
object or it can be something completely API-specific with another query =
language entirely.

But the other query language would need =
a type that has been reserved in the RAR name space for there to be =
interop, so it effectively is a RAR extension.

There are query languages in other =
domains that may not fit nicely into RAR such as a query for medical =
records.

Yes, =
the medical records could be yet another top level property, but per =
below, I think that is confusing.
 
(Point, though: RAR already pretty much allows this by =
letting them be extended infinitely, a feature it inherits from =
XYZ)

I=E2=80=99m=
 proposing that we do the same thing with GNAP: it=E2=80=99s an array of =
strings or objects and each of those means the same thing, =E2=80=9Csometh=
ing the client is asking for=E2=80=9D.


Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.


It=E2=80=99s my stance that this is an =
unnecessary limitation at this level. The objects within the array =
should be typed, like RAR, but it doesn=E2=80=99t make sense for the =
overall request to be typed. Instead, there should be one =E2=80=9Ctype" =
of query in the core, what XYZ calls the =E2=80=9Cresources=E2=80=9D =
request. Other query languages should be added as extensions either to =
the RAR-style objects (by defining a type at that level) or as a =
separate top-level member.

For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D=
 query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.

To me, this remains much =
more understandable, extensible, and =
clean.

While this may be more understandable =
to a developer just porting an app OIDC that only wants OIDC =
results, but I think it is more complicated as soon as the developer =
wants other results, which is likely what prompted the developer to =
use GNAP instead of ODIC.

I think it is easier to understand if all the claims are in =
one container, and all the authorizations are in another =
container.

If =
a developer wants access to some resources, some claims, and an OpenID =
Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread =
across multiple containers. There are some claims in the "claims" =
container, and some "claims" in the "oidc_claims_query" container. And =
is the access token response in "oidc_claims_query" the same as an =
access token response in "resources"? It would seem simpler if they =
were, and if all the access tokens came back in the same =
container.

Per =
Aaron's post that you have referred to, the developer can get sme bare =
claims directly in the response in the "claims" object, an ID Token that =
has the same or different claims, and if they want, an access token that =
they can call a user_info endpoint to get the same, or different =
claims.

For =
example, an enterprise app client may want an ID Token with the email =
address, bare claims for the user's name and a URI to a profile photo, =
and an access token to query which groups a user belongs to.

We are still =
re-using the OIDC claims, but we are not mixing claims and =
authorizations.

/Dick


[1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
3D""=E1=90=A7

3D""=E1=90=A7

3D""=E1=90=A7

3D""=E1=90=A7


=

--Apple-Mail=_F257C6A5-3E87-4DC2-84FF-665EC442F134--


From nobody Thu Jul  9 14:56:32 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 AD8D13A08F0 for ; Thu,  9 Jul 2020 14:56:30 -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_FILL_THIS_FORM_SHORT=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 kwuPic-Sh9oQ for ; Thu,  9 Jul 2020 14:56:25 -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 E51F53A08ED for ; Thu,  9 Jul 2020 14:56:24 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id h22so4106756lji.9 for ; Thu, 09 Jul 2020 14:56: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=m10WMVS2cvRpoM7XOSEY3IlzXE665dVrF3AdKPk3OK4=; b=q6ALcFYASA9460yZJJU6Uj/YI40Rms56JLXlOOte1RAXFtXghzpJCSg00CxgQrXAC/ A5Do8zOQs5bXDxuZQFcHg8YEeZv/6HlbrVQK6a7qfDezft/b7aJWzVnh6hDzQV0/D/YE 9XftG3sPUZqhtyV0DgcccBW6Ah4HWPhND85C0lYndkJnXDWEAv4N9rekc8lJjkKwiWy8 Mx6GJRa+A7ISmLYdBFneHBJaaYP6RzBWFZoknJ0U/3H+v6eyzBnftru0zqTHdQcT35IV DJTB4u8++25D580ljh3IDIc6TS+7v5yLfPFJCDMINOTDItRwguV0hHryVwr6AGJ0MhTY 6l/A==
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=m10WMVS2cvRpoM7XOSEY3IlzXE665dVrF3AdKPk3OK4=; b=gbLfEzRXj1vQAzDN0SaSoU+/O7PzTDdNoE5U9niZ5DfnPO/utL2oWpQtIjOtyeU2e4 pHjy/fGwyEBwL7ztpuc26ppXwtIduCTtZ/g3boFArAhHckhZ+W74f81iMLjX1IWG1qH1 W/vDoqL9/cQHWRrSBIhBXI78t4QTtyMBeSW09msnge0sq3EjVt9ECS+d4lM20xfN3T0n yLDEls6zRxiglEnfZRx2i7zvZOMYQKv1Dv7btBxGnBFycgcrnD0+94ok2BYJzB1HrzXM WcC/LTrGrQsuG2lIFIG0bKl+BNQCjehKOeirlajR5lphArAT57ZMkSLv6odn/OpngoKz y/kw==
X-Gm-Message-State: AOAM5309xJersIlwFrROIi6LtuG5jujyiMvU/Mgyzv1IH0QtC/oYG2uM YPeU9KvXZUgma4UU2mD49Zb2X1Z9zw1NyPAZncaIvxPdUTs=
X-Google-Smtp-Source: ABdhPJzuXzEwyIK5cwavUeFkY6Eg6y03NWx7QC2FGiJ1LcMKSeLBxGYeKGaKYJJvXSnioTErOGVSkV8ggdXd2I2m/EA=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr32956281ljn.5.1594331782673; Thu, 09 Jul 2020 14:56:22 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>
In-Reply-To: <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>
From: Dick Hardt 
Date: Thu, 9 Jul 2020 14:55:46 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008f808d05aa094bf4"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 09 Jul 2020 21:56:31 -0000

--0000000000008f808d05aa094bf4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for the clarifications. I had chatted to Aaron about his post, and
my understanding is not what is in the post on a closer read. My takeaway
was why make the developer parse the ID_Token, why not give them the
information directly.

I have interpreted the userinfo and id_token top level elements to be how
the client wanted the query results, not part of the query. I had thought
my example and definition of a Grant Response in XAuth [1] would have
clearly communicated what I meant, but I see that I should call out that
userinfo in XAuth returns the claims, rather than userinfo in OIDC returns
an access token for the claims. Given GNAP is more expressive, and learning
from the past, I'm proposing we offer the developer (and AS) a choice in
how to acquire the claims.

While acquiring user information through an API at any time is appropriate
in some use cases, in others why not give the client the info it needs
right away rather than having to make another API call to get it? This
would be appropriate when the user is making a purchase and wanting to
provide shipping information. The user does not want to authorize the
client to fetch their shipping address in the future.

I'm surprised by your stance:

My stance is that we allow the client to ask for a small set of identifiers
about the user, or even just ask to =E2=80=9Cidentify the user=E2=80=9D, an=
d leave
everything else to a higher level identity protocol. I do not think that
having an identity and profile query/response language at the core of GNAP
is a good idea, and it=E2=80=99s certainly not in our charter.


Since the charter states:

The group is chartered to develop mechanisms for conveying identity
information
within the protocol including existing identifiers (such as email addresses=
,
phone numbers, usernames, and subject identifiers) and assertions (such as
OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The
group is not chartered to develop new formats for identifiers or assertions=
,
nor is the group chartered to develop schemas for user information,
profiles,
or other identity attributes.


More than identifiers about the user are clearly in scope of the WG
charter, as are mechanisms for conveying identity information. Your stance
and the charter look in conflict to me. What am I missing?

/Dick

[1] https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-4.1



On Thu, Jul 9, 2020 at 1:04 PM Justin Richer  wrote:

> In Aaron=E2=80=99s post he doesn=E2=80=99t talk about how the request wou=
ld be made, just
> what the response could look like, and we are talking about how to reques=
t
> that. Aaron=E2=80=99s post specifically calls out that this is just an id=
entifier
> for the user and states:
>
> If the application needs to know profile information about the user,
> it can get that from the userinfo endpoint using the access token it
> just obtained.
>
>
> And I think that=E2=80=99s a good design pattern to follow. This isn=E2=
=80=99t =E2=80=9Cuserinfo=E2=80=9D
> being returned alongside the access token.
>
> The top level functionality of the OIDC claims query language is this:
>
>
> The top-level members of the Claims request JSON object are:
>
> userinfo
> OPTIONAL. Requests that the listed individual Claims *be returned from
> the UserInfo Endpoint*. If present, the listed Claims are being requested
> to be added to any Claims that are being requested using scope values. If
> not present, the Claims being requested from the UserInfo Endpoint are
> only those requested using scope values.
> When the userinfo member is used, the request MUST also use
> a response_type value that results in an *Access Token being issued to
> the Client for use at the UserInfo Endpoint*.
>
> id_token
> OPTIONAL. Requests that the listed individual Claims be returned in the
> ID Token. If present, the listed Claims are being requested to be added
> to the default Claims in the ID Token. If not present, the default ID Tok=
en
> Claims are requested, as per the ID Token definition in Section 2 and per
> the additional per-flow ID Token requirements in
> Sections 3.1.3.6, 3.2.2.10, 3.3.2.11, and 3.3.3.6.
>
>
> Since you had re-used the =E2=80=9Cuserinfo=E2=80=9D and =E2=80=9Cid_toke=
n=E2=80=9D top-level claims, I
> had assumed that they meant the same thing as in the OIDC spec. It=E2=80=
=99s clear
> to me, now, that this isn=E2=80=99t what you meant, but this is why I=E2=
=80=99m saying
> you=E2=80=99re not using the whole query language.
>
> There are proposed extensions to the OIDC claims query that would put
> returned data into a different place[1], and so it would be possible to u=
se
> the claims structures to handle this. But at that point if the goal is ju=
st
> to use the internal query format, then I think that we can do better usin=
g
> =E2=80=A6 polymorphic JSON. :)
>
> My stance is that we allow the client to ask for a small set of
> identifiers about the user, or even just ask to =E2=80=9Cidentify the use=
r=E2=80=9D, and
> leave everything else to a higher level identity protocol. I do not think
> that having an identity and profile query/response language at the core o=
f
> GNAP is a good idea, and it=E2=80=99s certainly not in our charter.
>
>  =E2=80=94 Justin
>
> [1] https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ defi=
nes
> a =E2=80=9Ccredential=E2=80=99 target.
>
> On Jul 9, 2020, at 3:29 PM, Dick Hardt  wrote:
>
> Yes. Which is why I referred to Aaron's post originally which calls out
> for returning plain text claims.
>
> I don't really understand what you mean by "OIDC claims query language".
> The claims mean the same thing. And I was also reusing the modifiers such
> as {"essential": true}. What top level functionality are you referring to=
?
>
> On Thu, Jul 9, 2020 at 12:21 PM Justin Richer  wrote:
>
>> Ah, so you=E2=80=99re saying that the =E2=80=9Cuserinfo=E2=80=9D claims =
would be returned
>> directly? I didn=E2=80=99t realize that you had intended to change how t=
he OIDC
>> claims query language functioned in your examples, and had assumed it wo=
uld
>> work the same was as the spec you were referencing. Your example of
>> splitting it up makes that more clear. Though I would argue at that poin=
t,
>> you=E2=80=99re creating a new query language since you=E2=80=99re not us=
ing the top-level
>> functionality from ODIC=E2=80=99s definition.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 9, 2020, at 3:15 PM, Dick Hardt  wrote:
>>
>> You are jumping to many conclusions below. Let me break down the proposa=
l
>> into some bite size chunks.
>>
>> The developer would like to get some plain text OIDC claims about the
>> user:
>>
>>     "claims":{
>>         "oidc": {
>>             "userinfo" : {
>>                 "name" : { "essential" : true },
>>                 "photo" : { "essential" : false }
>>             },
>>
>> The developer would like to get an OIDC ID Token:
>>
>>     "claims":{
>>         "oidc": {
>>             "id_token" : {
>>                 "email"          : { "essential" : true },
>>                 "email_verified" : { "essential" : true }
>>             }
>>     }
>>
>> The developer would like to get an access token to acquire OIDC claims:
>>
>> "authorizations": {
>>         "type":"oidc",
>>         "claims": ["name", "picture"]
>>     }
>>
>> The developer would like to get an access token to access photos:
>>
>> "authorizations": {
>>         "type":"oauth_scope",
>>         "scope": "read_photos"*
>>     }
>>
>> The developer would like to get some VC claims:
>>
>> "claims" {
>>         "vc": {
>>             "some_vc": "query_mechanism"
>>         }
>> }
>>
>> The developer would like to do all of the above at once:
>>
>> {
>>     "authorizations": {
>>         "userinfo": {
>>             "type":"oidc",
>>             "claims": ["name", "picture"]
>>         },
>>         "photos": {
>>             "type":"oauth_scope",
>>             "scope": "read_photos"
>>         }
>>     },
>>     "claims":{
>>         "oidc": {
>>             "id_token" : {
>>                 "email"          : { "essential" : true },
>>                 "email_verified" : { "essential" : true }
>>             },
>>             "userinfo" : {
>>                 "name" : { "essential" : true },
>>                 "photo" : { "essential" : false }
>>             }
>>         },
>>     "vc": {
>>         "some_vc": "query_mechanism"
>>         }
>>     }
>> }
>>
>> In the results, the developer gets claims back in the response claims
>> object, and access tokens etc. back in the authorizations object. Just
>> because an access token returns claims, it is still an access token.
>>
>> Yes, the developer can't get a single access token that can both acquire
>> OIDC claims, and access photos (there are separate tokens for each), but=
 I
>> would argue that separating the access is a positive security property, =
as
>> a client component accessing the user profile has a token independent of
>> the client component accessing photos. And at the AS, there is no
>> requirement for the userinfo endpoint to take the same token as the phot=
o
>> endpoint.
>>
>> Somewhat of a tangent, I'm thinking that
>>
>>     "claims":{
>>         "oidc": {
>>             "id_token" : {},
>>             "userinfo" : {}
>>         },
>>
>> is a little verbose, and:
>>
>>     "claims":{
>>         "oidc_token": {},
>>         "oidc_info": {}
>>     },
>>
>> works better and makes it easier to distinguish support for ID tokens vs
>> plain claims.
>>
>> wrt. my position on reusing OIDC -- it has not changed. I have viewed th=
e
>> OIDC claims as the "query language". No need to reinvent that. We are
>> creating a new protocol, so no need to use the OAuth or OIDC protocols.
>>
>> * OAuth scopes could be a space separates string to be consistent with
>> OAuth 2, or an array of strings so that it is more JSON like. I have no
>> strong opinion.
>>
>> scope.split(' ').forEach()
>>
>> is not that much more complex than
>>
>> scope.forEach()
>>
>>
>>
>> On Thu, Jul 9, 2020 at 8:39 AM Justin Richer  wrote:
>>
>>> But this approach doesn=E2=80=99t keep things in their respective conta=
iners =E2=80=94
>>> you=E2=80=99ve explicitly got =E2=80=9Cclaims=E2=80=9D underneath the =
=E2=80=9Cauthorizations=E2=80=9D header, and
>>> you=E2=80=99ve got items that come back as rights associated with the a=
ccess token
>>> (which should be =E2=80=9Cauthorizations=E2=80=9D) in the =E2=80=9Cuser=
info=E2=80=9D section under the
>>> =E2=80=9Cclaims=E2=80=9D header. And as far as I can tell, these two se=
ctions are redundant
>>> to each other. Everything is everywhere.
>>>
>>> Additionally, this approach and syntax makes it difficult to combine
>>> different kinds of requests into one. One of OpenID Connect=E2=80=99s b=
iggest
>>> draws, as I=E2=80=99m sure you recall, is that it could be combined wit=
h a request
>>> for non-OIDC resources. This was the real innovation that Twitter and
>>> Facebook=E2=80=99s identity APIs brought, access to more than just auth=
entication,
>>> and what Google had tried to replicate with the awkward OpenID 2 + OAut=
h 1
>>> hybrid system. Taking a step back from the existing solutions of OpenID=
 2
>>> and OAuth 1 let us, as the community, see the value in the pattern that
>>> became OIDC on top of OAuth 2.
>>>
>>> Sure, you could say that the =E2=80=9Coidc=E2=80=9D type also can allow=
 a =E2=80=9Cscopes=E2=80=9D
>>> parameter, but what about a RAR style object, then? And what about when
>>> someone comes up with some new way to request access rights, or a VC-ba=
sed
>>> query language? Does every =E2=80=9Ctype=E2=80=9D need to now know abou=
t every other =E2=80=9Ctype=E2=80=9D
>>> in order for an AS to be able to figure out how they go together? This
>>> seems like the protocol definition limiting what combinations the AS ca=
n
>>> handle, or what an RS might want to use.
>>>
>>> My stance is that GNAP should have a way to query for rights in the
>>> access token (=E2=80=9Cauthorizations=E2=80=9D in xauth parlance) and i=
dentifiers for the
>>> user (=E2=80=9Cclaims=E2=80=9D in xauth parlance), and anything else sh=
ould be an extension
>>> with potentially different models. The AS would process the
>>> =E2=80=9Cauthorizations=E2=80=9D equivalent (for the access token) alon=
gside any other
>>> incoming query and then make a policy decision based on that.
>>>
>>> I find it interesting that you are now saying we don=E2=80=99t need to =
use the
>>> OIDC request format when previously you=E2=80=99ve made it clear that y=
ou were in
>>> favor of pointing at external query languages, including their syntax. =
I=E2=80=99m
>>> glad to see that you=E2=80=99re now looking at things in a more flexibl=
e way, but I
>>> think it=E2=80=99s important that we be careful and conscientious about=
 how we
>>> reference any external query languages in GNAP.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 8, 2020, at 6:55 PM, Dick Hardt  wrote:
>>>
>>> Hey Justin,
>>>
>>> Just because we are using OIDC claims, does not mean we need to mimic
>>> the OIDC request and response.
>>> I was envisioning a grant request could look as the following (using
>>> XAuth syntax):
>>>
>>> {
>>>     "authorizations": {
>>>         "type":"oidc",
>>>         "claims": ["name", "picture"]
>>>     },
>>>     "claims":{
>>>         "oidc": {
>>>             "id_token" : {
>>>                 "email"          : { "essential" : true },
>>>                 "email_verified" : { "essential" : true }
>>>             },
>>>             "userinfo" : {
>>>                 "name"           : { "essential" : true },
>>>                 "picture"        : null
>>>             }
>>>         }
>>>     }
>>> }
>>>
>>> Of course a developer could choose to only ask for a subset of this.
>>>
>>> Note the new authorization type of "oidc", that takes "claims" rather
>>> than "scope".
>>>
>>> This keeps all the authorizations and claims in their respective reques=
t
>>> and response containers.
>>>
>>> We had a thread months ago on the OIDC two stage model, and I still fai=
l
>>> to see why forcing that has any advantage.
>>>
>>> /Dick
>>>
>>>
>>> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer  wrote:
>>>
>>>> I=E2=80=99m glad that we can agree that there are a number of things i=
n legacy
>>>> protocols that are unfortunate side effects of the circumstances in wh=
ich
>>>> they were built. Space-separated scope strings, for instance, would fa=
ll in
>>>> that category, as I=E2=80=99ve previously explained.
>>>>
>>>> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request al=
ready mixes user
>>>> claims (returned in an API) and authorization (to fetch user claims fr=
om an
>>>> API), so that ship has sailed if you=E2=80=99re using it. It doesn=E2=
=80=99t make sense to
>>>> have it under a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorizations=E2=
=80=9D request, since it=E2=80=99s a query
>>>> language that affects both. Maybe you=E2=80=99d call this another =E2=
=80=9Cunfortunate
>>>> design=E2=80=9D, but the context was about re-using an externally-defi=
ned query
>>>> language that was not made for GNAP.
>>>>
>>>> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=
=9D and wants to
>>>> keep using it. (The vast majority of OIDC implementations, in my
>>>> experience, don=E2=80=99t use that feature, and it=E2=80=99s not even =
required to be
>>>> implemented by the AS, but again we=E2=80=99re talking about using thi=
s feature as
>>>> an example of an external query language =E2=80=94 and there are other=
s out there.)
>>>> In GNAP, you should return claims directly in the response, and reques=
t
>>>> specific elements from the APIs protected by the access token. These a=
re
>>>> separate things, and by design both XAuth and XYZ have put them into
>>>> separate containers in the request. This is a good design, and so putt=
ing
>>>> something that conflates these two aspects into one or the other of th=
e
>>>> containers is not a particularly good option, in my opinion.
>>>>
>>>> Additionally, though this is a bit of an aside and getting into the
>>>> specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC =
is a query language
>>>> bound to the full user profile. It is my stated position that the item=
s
>>>> coming back from the AS should only be identifiers, and not full profi=
le
>>>> information. The reasoning is pretty simple: the client doesn=E2=80=99=
t know what
>>>> profile information it needs until it knows who the user is, so puttin=
g
>>>> that into a protected API like the UserInfo Endpoint makes much more s=
ense
>>>> than putting it into the immediate response, where it is not needed,
>>>> because the client already knows it. The AS doesn=E2=80=99t know what =
the client
>>>> needs to know, either, so it can=E2=80=99t determine what to fulfill. =
OIDC=E2=80=99s
>>>> two-stage model makes sense, and GNAP should really only focus on enab=
ling
>>>> this.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Jul 8, 2020, at 6:10 PM, Dick Hardt  wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer  wrote:
>>>>
>>>>> On Jul 8, 2020, at 3:16 PM, Dick Hardt  wrote:
>>>>>
>>>>>
>>>>> I think representing the request as an array is simplistic, and
>>>>> complicated at the same time.
>>>>>
>>>>> On the simplistic front, as there is no clear mechanism for extending
>>>>> the request with properties that apply to all of the request.
>>>>>
>>>>>
>>>>> The elements of the array are taken as a set, to be tied to the same
>>>>> resulting access token. If one of those elements is defined, by the A=
S
>>>>> and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some=
 or all of the other
>>>>> elements, then that=E2=80=99s up to the AS=E2=80=99s policy. Much lik=
e the =E2=80=9Copenid=E2=80=9D scope
>>>>> in OIDC, which switches on all sorts of contextual stuff in the reque=
st. So
>>>>> to handle something like this, an AS can easily declare that a given
>>>>> scope-style string or a given object property applies to different pa=
rts of
>>>>> the request. You don=E2=80=99t need to externalize it here.
>>>>>
>>>>
>>>> I view the "openid" scope as an unfortunate design as OIDC was
>>>> constrained by building on top of OAuth. (a problem I hoped to avert b=
y
>>>> having "identity" in scope for GNAP) The "openid" scope does not funct=
ion
>>>> as scope per se, and I think it makes OIDC harder to understand as the
>>>> "openid" scope causes non-scope behavior.
>>>>
>>>>
>>>>
>>>>>
>>>>> Do you have a concrete use case that requires that feature to be done
>>>>> in the way that you describe? I am trying to separate the driving use=
 case
>>>>> from the proposed solutions to see what the differences are.
>>>>>
>>>>
>>>> Perhaps the client wants access to be HIPPA compliant? The HIPPA
>>>> compliance signal applies to the scopes.
>>>>
>>>> Adding other properties to an object is a well understood extension
>>>> mechanism. Adding an additional element to an array that does not act =
like
>>>> the other elements seems like a hack.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> Using JSON type polymorphism requires the AS to test each member of
>>>>> the array to determine if it is a string or an object. Only after det=
ecting
>>>>> a RAR object does the AS know the client is making a RAR request.
>>>>>
>>>>>
>>>>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole =
resources request
>>>>> in order to figure out what the client is asking for, anyway, whether=
 it=E2=80=99s
>>>>> by strings or objects or whatever else might be defined by an extensi=
on. Is
>>>>> there an argument for having an AS do an early dispatch on a request =
before
>>>>> it=E2=80=99s fully parsed everything?
>>>>>
>>>>
>>>> Let me clarify, the code is looking at the type of object that has bee=
n
>>>> parsed.
>>>>
>>>> Determining if an item in an array is a scope or a RAR object by
>>>> looking at the type being either a string or an object seems less clea=
r
>>>> than a property of an object explicitly declaring the type.
>>>>
>>>>
>>>>
>>>>>
>>>>> This also limits the request to be composed only of scope strings or
>>>>> RAR objects. I don't see how other strings or objects could be used i=
n the
>>>>> array, so there is no clear extension point in the "resources" array =
for
>>>>> other query mechanisms.
>>>>>
>>>>>
>>>>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring =
that a string has
>>>>> to be an OAuth2-style scope. It can be, but ultimately it=E2=80=99s j=
ust a string
>>>>> that the AS can understand. And the objects are just that =E2=80=94 o=
bjects. If the
>>>>> AS understands what the object is, it can be a RAR object or it can b=
e
>>>>> something completely API-specific with another query language entirel=
y.
>>>>>
>>>>
>>>> But the other query language would need a type that has been reserved
>>>> in the RAR name space for there to be interop, so it effectively is a =
RAR
>>>> extension.
>>>>
>>>> There are query languages in other domains that may not fit nicely int=
o
>>>> RAR such as a query for medical records.
>>>>
>>>> Yes, the medical records could be yet another top level property, but
>>>> per below, I think that is confusing.
>>>>
>>>>
>>>>> (Point, though: RAR already pretty much allows this by letting them b=
e
>>>>> extended infinitely, a feature it inherits from XYZ)
>>>>>
>>>>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=
=99s an array of
>>>>> strings or objects and each of those means the same thing, =E2=80=9Cs=
omething the
>>>>> client is asking for=E2=80=9D.
>>>>>
>>>>>
>>>>> Just as RAR has a "type" property, I propose the "resources"
>>>>> ("authorizations" in XAuth) be an object, where the other properties =
are
>>>>> determined by the "type" property. This allows extensions to define n=
ew
>>>>> ways to query for an authorization rather than having to fit into sco=
pes or
>>>>> RAR.
>>>>>
>>>>>
>>>>> It=E2=80=99s my stance that this is an unnecessary limitation at this=
 level.
>>>>> The objects within the array should be typed, like RAR, but it doesn=
=E2=80=99t make
>>>>> sense for the overall request to be typed. Instead, there should be o=
ne
>>>>> =E2=80=9Ctype" of query in the core, what XYZ calls the =E2=80=9Creso=
urces=E2=80=9D request. Other
>>>>> query languages should be added as extensions either to the RAR-style
>>>>> objects (by defining a type at that level) or as a separate top-level
>>>>> member.
>>>>>
>>>>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D que=
ry language. My current
>>>>> thought is that this really shouldn=E2=80=99t be a part of the =E2=80=
=9Cresources=E2=80=9D or
>>>>> =E2=80=9Cclaims=E2=80=9D part of the request, but instead as its own =
top-level member, like
>>>>> it is in the OIDC protocol today. The main reason for this is the nat=
ure of
>>>>> the OIDC claims language: it specifies targets for the resulting data=
, and
>>>>> those targets cross different ways to return things. So it doesn=E2=
=80=99t actually
>>>>> affect just resources like the UserInfo Endpoint, or the ID Token, bu=
t both
>>>>> and potentially others out there. If your system supported such an
>>>>> extension, it could theoretically forego both the built-in =E2=80=9Cc=
laims=E2=80=9D and
>>>>> =E2=80=9Cresources=E2=80=9D parts of the request, and use the =E2=80=
=9Coidc_claims_query=E2=80=9D member
>>>>> (or whatever it would be called). This would let such an extension us=
e the
>>>>> OIDC claims processing mechanism as it is today.
>>>>>
>>>>> To me, this remains much more understandable, extensible, and clean.
>>>>>
>>>>
>>>> While this may be more understandable to a developer just porting an
>>>> app OIDC that only wants OIDC results, but I think it is more complica=
ted
>>>> as soon as the developer wants other results, which is likely what pro=
mpted
>>>> the developer to use GNAP instead of ODIC.
>>>>
>>>> I think it is easier to understand if all the claims are in one
>>>> container, and all the authorizations are in another container.
>>>>
>>>> If a developer wants access to some resources, some claims, and an
>>>> OpenID Token, they are having to use "claims", "resources", and
>>>> "oidc_claims_query".  Now the claims and access tokens are spread acro=
ss
>>>> multiple containers. There are some claims in the "claims" container, =
and
>>>> some "claims" in the "oidc_claims_query" container. And is the access =
token
>>>> response in "oidc_claims_query" the same as an access token response i=
n
>>>> "resources"? It would seem simpler if they were, and if all the access
>>>> tokens came back in the same container.
>>>>
>>>> Per Aaron's post that you have referred to, the developer can get sme
>>>> bare claims directly in the response in the "claims" object, an ID Tok=
en
>>>> that has the same or different claims, and if they want, an access tok=
en
>>>> that they can call a user_info endpoint to get the same, or different
>>>> claims.
>>>>
>>>> For example, an enterprise app client may want an ID Token with the
>>>> email address, bare claims for the user's name and a URI to a profile
>>>> photo, and an access token to query which groups a user belongs to.
>>>>
>>>> We are still re-using the OIDC claims, but we are not mixing claims an=
d
>>>> authorizations.
>>>>
>>>> /Dick
>>>>
>>>>
>>>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
>>>> =E1=90=A7
>>>>
>>>>
>>>> =E1=90=A7
>>>
>>>
>>> =E1=90=A7
>>
>>
>> =E1=90=A7
>
>
>

--0000000000008f808d05aa094bf4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for the clarifications. I had chatted to =
Aaron about his post, and my understanding is not what is in the post on a =
closer read. My takeaway was why make the developer parse the ID_Token, why=
 not give them the information directly.

I have interpre=
ted the userinfo and id_token top level elements to be how the client wante=
d the query results, not part of the query. I had thought my example and de=
finition of=C2=A0a Grant Response in XAuth [1] would have clearly communica=
ted what I meant, but I see that I should call out that userinfo in XAuth r=
eturns the claims, rather than userinfo in OIDC returns an access token for=
 the claims. Given GNAP is more expressive, and learning from the past, I&#=
39;m proposing we offer the developer (and AS) a choice in how to acquire t=
he claims.

While acquiring user information=C2=A0t=
hrough an API at any time is appropriate in some use cases, in others why n=
ot give the client the info it needs right away rather than having to make =
another API call to get it? This would be appropriate when the user is maki=
ng a purchase and wanting to provide shipping information. The user does no=
t want to authorize the client to fetch their shipping address in the futur=
e.=C2=A0

I'm surprised by your stance:=C2=A0

My stance is that we allow the client to ask for a small set =
of identifiers about the user, or even just ask to =E2=80=9Cidentify the us=
er=E2=80=9D, and leave everything else to a higher level identity protocol.=
 I do not think that having an identity and profile query/response language=
 at the core of GNAP is a good idea, and it=E2=80=99s certainly not in our =
charter.

Since the charter states:

The group is chartered to develop mechanisms=
 for conveying identity information
within the protocol including=
 existing identifiers (such as email addresses,
phone numbers, us=
ernames, and subject identifiers) and assertions (such as
OpenID =
Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The
<=
div>group is not chartered to develop new formats for identifiers or assert=
ions,
nor is the group chartered to develop schemas for user info=
rmation, profiles,
or other identity attributes.

On Thu, Jul 9, 2020 =
at 1:04 PM Justin Richer <jricher@mit=
.edu> wrote:
In Aaron=E2=80=99s post he do=
esn=E2=80=99t talk about how the request would be made, just what the respo=
nse could look like, and we are talking about how to request that. Aaron=E2=
=80=99s post specifically calls out that this is just an identifier for the=
 user and states:

If the application needs to know profile in=
formation about the user, it=C2=A0can get that from the userinfo=C2=A0endpo=
int using the access token it just=C2=A0obtained.
And I think that=E2=80=99s a good design pattern to follow. Th=
is isn=E2=80=99t =E2=80=9Cuserinfo=E2=80=9D being returned alongside the ac=
cess token.=C2=A0

The top level functionality of t=
he OIDC claims query language is this:


<=
blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">
T=
he top-level members of the Claims request JSON object are:

<=
/div>
userinfo
OPTIONAL.=C2=A0Requests that the listed indivi=
dual Claims be returned=C2=A0from the=C2=A0UserInfo Endpoint.=C2=A0I=
f present, the listed Claims are being requested to be=C2=A0added to=C2=A0a=
ny Claims that are being requested using=C2=A0scope=C2=A0values.=C2=A0If no=
t=C2=A0present, the Claims being requested from the UserInfo Endpoint=C2=A0=
are only=C2=A0those requested using=C2=A0scope=C2=A0values.
When =
the=C2=A0userinfo=C2=A0member is used,=C2=A0the request MUST also use a=C2=
=A0response_type=C2=A0value that results in an Access Token being issued=
 to the=C2=A0Client=C2=A0for use at the UserInfo Endpoint.
id_token
OPTIONAL.=C2=A0Requests that the listed ind=
ividual Claims be returned=C2=A0in the ID=C2=A0Token.=C2=A0If present, the =
listed Claims are being requested to be added to=C2=A0the=C2=A0default Clai=
ms in the ID Token.=C2=A0If not present, the default ID Token Claims=C2=A0a=
re requested,=C2=A0as per the ID Token definition in=C2=A0Section 2=C2=A0an=
d per the=C2=A0additional per-flow ID Token requirements in Sections=C2=A03=
.1.3.6,=C2=A03.2.2.10,=C2=A03.3.2.11,=C2=A0and=C2=A03.3.3.6.

Since you had re-used the =E2=80=9Cuserinfo=E2=
=80=9D and =E2=80=9Cid_token=E2=80=9D top-level claims, I had assumed that =
they meant the same thing as in the OIDC spec. It=E2=80=99s clear to me, no=
w, that this isn=E2=80=99t what you meant, but this is why I=E2=80=99m sayi=
ng you=E2=80=99re not using the whole query language.=C2=A0

<=
/div>
There are proposed extensions to the OIDC claims query that would=
 put returned data into a different place[1], and so it would be possible t=
o use the claims structures to handle this. But at that point if the goal i=
s just to use the internal query format, then I think that we can do better=
 using =E2=80=A6 polymorphic JSON. :)

My stance is=
 that we allow the client to ask for a small set of identifiers about the u=
ser, or even just ask to =E2=80=9Cidentify the user=E2=80=9D, and leave eve=
rything else to a higher level identity protocol. I do not think that havin=
g an identity and profile query/response language at the core of GNAP is a =
good idea, and it=E2=80=99s certainly not in our charter.

=C2=A0=E2=80=94 Justin

[1]=C2=A0https://mattrglobal.github.io/oidc-client-bound-assertions-spec=
/=C2=A0defines a =E2=80=9Ccredential=E2=80=99 target.

On Jul 9, 2020, at 3:29 PM, Dick Hardt <dick.hardt@gmail.com<=
/a>> wrote:

Yes. Which is why I refe=
rred to Aaron's post originally which calls out for returning plain tex=
t claims.

I don't really understand what you m=
ean by "OIDC claims query language". The claims mean the same thi=
ng. And I was also reusing the modifiers such as {"essential": tr=
ue}. What top level functionality are=C2=A0you referring to?

=

On T=
hu, Jul 9, 2020 at 12:21 PM Justin Richer <jricher@mit.edu> wrote:
Ah, so you=E2=80=99re saying th=
at the =E2=80=9Cuserinfo=E2=80=9D claims would be returned directly? I didn=
=E2=80=99t realize that you had intended to change how the OIDC claims quer=
y language functioned in your examples, and had assumed it would work the s=
ame was as the spec you were referencing. Your example of splitting it up m=
akes that more clear. Though I would argue at that point, you=E2=80=99re cr=
eating a new query language since you=E2=80=99re not using the top-level fu=
nctionality from ODIC=E2=80=99s definition.

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

On Jul 9, 2020, at 3:=
15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

You are jum=
ping to many conclusions below. Let me break down the proposal into some bi=
te size chunks.

The developer would like to get so=
me plain text OIDC claims about the user:

=C2=A0 =
=C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "oidc"=
: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "userinfo" : {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name" =
: { "essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "photo" : { "essential" : false }<=
br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },

The developer would like to get an OIDC ID Token:

=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "o=
idc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id_token&qu=
ot; : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "em=
ail" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "essential" : tru=
e },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "email=
_verified" : { "essential" : true }
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }

The developer would like to get an access token to acquire OIDC claims:<=
/div>

"authorizations&=
quot;: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type":"oidc"=
,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "claims": ["name", &qu=
ot;picture"]
=C2=A0 =C2=A0 }
<=
br>
The developer would like to get an access token to access pho=
tos:

"authorizations": =
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type":"oauth_scope"=
,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": "read_photos"=
*
=C2=A0 =C2=A0 }

The developer would like to g=
et some VC claims:

"claims" {
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "vc": {
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "some_vc": "query_mechanism"=
;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
}

The developer would like to do all of the above at once:

{
=C2=A0 =C2=A0 "authorizations": {
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "userinfo": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 "type":"oidc",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "claims": ["name", "picture"]=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "photo=
s": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type":&q=
uot;oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "s=
cope": "read_photos"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=
=A0 =C2=A0 },
=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 "oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &q=
uot;id_token" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 "email" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "essent=
ial" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "email_verified" : { "essential" : true }
=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 "userinfo" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "name" : { "essential" : true },=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "photo"=
 : { "essential" : false }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 "vc":=
 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "some_vc": "query_mechanis=
m"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } =C2=A0=C2=A0
=C2=
=A0 =C2=A0 }
}

In the results, the develope=
r gets claims back in the response claims object, and access tokens etc. ba=
ck in the authorizations object. Just because an access token returns claim=
s, it is still an access token.

Yes, the developer=
=C2=A0can't get a single access token that can both acquire OIDC claims=
, and access photos (there are separate tokens for each), but I would argue=
 that separating the access is a positive security property, as a client co=
mponent accessing the user profile has a token independent of the client co=
mponent accessing photos. And at the AS, there is no requirement for the us=
erinfo endpoint to take the same token as the photo endpoint.
Somewhat of a tangent, I'm thinking that=C2=A0
=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
id_token" : {},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "use=
rinfo" : {}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },

is a little verbo=
se, and:

=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "oidc_token": {},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &q=
uot;oidc_info": {}
=C2=A0 =C2=A0 },

wo=
rks better and makes it easier to distinguish=C2=A0support for ID tokens vs=
 plain claims.

wrt. my position on reusing OIDC --=
 it has not changed. I have viewed the OIDC claims as the "query langu=
age". No need to reinvent that. We are creating a new protocol, so no =
need to use the OAuth or OIDC protocols.

* OA=
uth scopes could be a space separates string to be consistent with OAuth 2,=
 or an array of strings so that it is more JSON like. I have no strong opin=
ion.=C2=A0

scope.split(' ').forEach(=
)=C2=A0

is not that much more complex than=C2=A0

scope.forEach()


=

On Thu=
, Jul 9, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wrote:
But this approach doesn=E2=80=
=99t keep things in their respective containers =E2=80=94 you=E2=80=99ve ex=
plicitly got =E2=80=9Cclaims=E2=80=9D underneath the =E2=80=9Cauthorization=
s=E2=80=9D header, and you=E2=80=99ve got items that come back as rights as=
sociated with the access token (which should be =E2=80=9Cauthorizations=E2=
=80=9D) in the =E2=80=9Cuserinfo=E2=80=9D section under the =E2=80=9Cclaims=
=E2=80=9D header. And as far as I can tell, these two sections are redundan=
t to each other. Everything is everywhere.=C2=A0

A=
dditionally, this approach and syntax makes it difficult to combine differe=
nt kinds of requests into one. One of OpenID Connect=E2=80=99s biggest draw=
s, as I=E2=80=99m sure you recall, is that it could be combined with a requ=
est for non-OIDC resources. This was the real innovation that Twitter and F=
acebook=E2=80=99s identity APIs brought, access to more than just authentic=
ation, and what Google had tried to replicate with the awkward OpenID 2 + O=
Auth 1 hybrid system. Taking a step back from the existing solutions of Ope=
nID 2 and OAuth 1 let us, as the community, see the value in the pattern th=
at became OIDC on top of OAuth 2.=C2=A0

Sure, you =
could say that the =E2=80=9Coidc=E2=80=9D type also can allow a =E2=80=9Csc=
opes=E2=80=9D parameter, but what about a RAR style object, then? And what =
about when someone comes up with some new way to request access rights, or =
a VC-based query language? Does every =E2=80=9Ctype=E2=80=9D need to now kn=
ow about every other =E2=80=9Ctype=E2=80=9D in order for an AS to be able t=
o figure out how they go together? This seems like the protocol definition =
limiting what combinations the AS can handle, or what an RS might want to u=
se.

My stance is that GNAP should have a way to qu=
ery for rights in the access token (=E2=80=9Cauthorizations=E2=80=9D in xau=
th parlance) and identifiers for the user (=E2=80=9Cclaims=E2=80=9D in xaut=
h parlance), and anything else should be an extension with potentially diff=
erent models. The AS would process the =E2=80=9Cauthorizations=E2=80=9D equ=
ivalent (for the access token) alongside any other incoming query and then =
make a policy decision based on that.

I find it in=
teresting that you are now saying we don=E2=80=99t need to use the OIDC req=
uest format when previously you=E2=80=99ve made it clear that you were in f=
avor of pointing at external query languages, including their syntax. I=E2=
=80=99m glad to see that you=E2=80=99re now looking at things in a more fle=
xible way, but I think it=E2=80=99s important that we be careful and consci=
entious about how we reference any external query languages in GNAP.
<=
div>
=C2=A0=E2=80=94 Justin

On Jul 8, 2020, at 6:55 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Justin,

Just because=C2=A0we are using OIDC claims, does not mean we need to mimic=
 the OIDC request and response.
I was envisioning a grant request=
 could look as the following (using XAuth syntax):

{=

=C2=A0 =C2=A0 "authorizations": {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "type":"oidc",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
;claims": ["name", "picture"]
=C2=A0 =C2=A0 },<=
br>=C2=A0 =C2=A0 "claims":{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id_token&q=
uot; : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "e=
mail" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "essential" : tr=
ue },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "emai=
l_verified" : { "essential" : true }
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
;userinfo" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "name" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : { "essential=
" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 "picture" =C2=A0 =C2=A0 =C2=A0 =C2=A0: null
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=
=A0 }
}

Of course a developer could c=
hoose to only ask for a subset of this.

Note the n=
ew authorization type of "oidc", that takes "claims" ra=
ther than "scope".=C2=A0

This keeps all =
the authorizations and claims in their respective request and response cont=
ainers.

We had a thread months ago on the OIDC two=
 stage model, and I still fail to see why forcing that has any advantage.=
=C2=A0

/Dick


On Wed, Jul 8, 20=
20 at 3:25 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m glad that we can agree that the=
re are a number of things in legacy protocols that are unfortunate side eff=
ects of the circumstances in which they were built. Space-separated scope s=
trings, for instance, would fall in that category, as I=E2=80=99ve previous=
ly explained.

A key point in the below: the OIDC =E2=80=
=9Cclaims=E2=80=9D request already mixes user claims (returned in an API) a=
nd authorization (to fetch user claims from an API), so that ship has saile=
d if you=E2=80=99re using it. It doesn=E2=80=99t make sense to have it unde=
r a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D request, s=
ince it=E2=80=99s a query language that affects both. Maybe you=E2=80=99d c=
all this another =E2=80=9Cunfortunate design=E2=80=9D, but the context was =
about re-using an externally-defined query language that was not made for G=
NAP.

My scenario was for someone who is already using =
=E2=80=9Cclaims=E2=80=9D and wants to keep using it. (The vast majority of =
OIDC implementations, in my experience, don=E2=80=99t use that feature, and=
 it=E2=80=99s not even required to be implemented by the AS, but again we=
=E2=80=99re talking about using this feature as an example of an external q=
uery language =E2=80=94 and there are others out there.) In GNAP, you shoul=
d return claims directly in the response, and request specific elements fro=
m the APIs protected by the access token. These are separate things, and by=
 design both XAuth and XYZ have put them into separate containers in the re=
quest. This is a good design, and so putting something that conflates these=
 two aspects into one or the other of the containers is not a particularly =
good option, in my opinion.=C2=A0

Additionally, th=
ough this is a bit of an aside and getting into the specifics of identity, =
the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is a query language bound to=
 the full user profile. It is my stated position that the items coming back=
 from the AS should only be identifiers, and not full profile information. =
The reasoning is pretty simple: the client doesn=E2=80=99t know what profil=
e information it needs until it knows who the user is, so putting that into=
 a protected API like the UserInfo Endpoint makes much more sense than putt=
ing it into the immediate response, where it is not needed, because the cli=
ent already knows it. The AS doesn=E2=80=99t know what the client needs to =
know, either, so it can=E2=80=99t determine what to fulfill. OIDC=E2=80=99s=
 two-stage model makes sense, and GNAP should really only focus on enabling=
 this.

=C2=A0=E2=80=94 Justin

<=
blockquote type=3D"cite">
On Jul 8, 2020, at 6:10 PM, Dick Hardt <dick.hardt@gmail.co=
m> wrote:



On Wed, Jul 8=
, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at 3:16 PM, Dick Hardt &l=
t;dick.hardt@gmai=
l.com> wrote:

I think representing the request as an array is simp=
listic, and complicated at the same time.

On the simplis=
tic front, as there is no clear mechanism for extending the request with pr=
operties that apply to all of the request.=C2=A0

The elements of the array are taken as a set,=
 to be tied to the same resulting access token. If one of those elements is=
 defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s protecting, to app=
ly across some or all of the other elements, then that=E2=80=99s up to the =
AS=E2=80=99s policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, =
which switches on all sorts of contextual stuff in the request. So to handl=
e something like this, an AS can easily declare that a given scope-style st=
ring or a given object property applies to different parts of the request. =
You don=E2=80=99t need to externalize it here.

I view the "openid" scope as an unfortunate=
 design as OIDC was constrained by building=C2=A0on top of OAuth. (a proble=
m I hoped to avert by having "identity" in scope for GNAP) The &q=
uot;openid" scope does not function as scope=C2=A0per se, and I think =
it makes OIDC harder to understand as the "openid" scope causes n=
on-scope behavior.=C2=A0

=C2=A0

Do you h=
ave a concrete use case that requires that feature to be done in the way th=
at you describe? I am trying to separate the driving use case from the prop=
osed solutions to see what the differences are.=C2=A0

Perhaps the client wants access to be HIPPA co=
mpliant? The HIPPA compliance signal applies to the scopes.

<=
/div>
Adding other properties to an object is a well understood extensi=
on mechanism. Adding an additional element to an array that does not act li=
ke the other elements seems like a hack.

=C2=A0

Using JSON type polymorphism=C2=A0requires the AS to test each=
 member of the array to determine if it is a string or an object. Only afte=
r detecting a RAR object does the AS know the client is making a RAR reques=
t.=C2=A0

That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole res=
ources request in order to figure out what the client is asking for, anyway=
, whether it=E2=80=99s by strings or objects or whatever else might be defi=
ned by an extension. Is there an argument for having an AS do an early disp=
atch on a request before it=E2=80=99s fully parsed everything?
<=
/div>

Let me clarify, the code is looking a=
t the type of object that has been parsed.=C2=A0

D=
etermining if an item in an array is a scope or a RAR object by looking at =
the type being either a string or an object seems less clear than a propert=
y of an object explicitly declaring the type.

=C2=
=A0
Thi=
s also limits the request to be composed only of scope strings or RAR objec=
ts. I don't see how other strings or objects could be used in the array=
, so there is no clear extension point in the "resources" array f=
or other query mechanisms.

That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declarin=
g that a string has to be an OAuth2-style scope. It can be, but ultimately =
it=E2=80=99s just a string that the AS can understand. And the objects are =
just that =E2=80=94 objects. If the AS understands what the object is, it c=
an be a RAR object or it can be something completely API-specific with anot=
her query language entirely.

<=
div>But the other query language would need a type that has been reserved i=
n the RAR name space for there to be interop, so it effectively is a RAR ex=
tension.

There are query languages in other domain=
s that may not fit nicely into RAR such as a query for medical records.

Yes, the medical records could be yet another top lev=
el property, but per below, I think that is confusing.
=C2=A0
(Point, =
though: RAR already pretty much allows this by letting them be extended inf=
initely, a feature it inherits from XYZ)

I=E2=80=
=99m proposing that we do the same thing with GNAP: it=E2=80=99s an array o=
f strings or objects and each of those means the same thing, =E2=80=9Csomet=
hing the client is asking for=E2=80=9D.

=


Just as RAR has =
a "type" property, I propose the "resources" ("aut=
horizations" in XAuth) be an object, where the other properties are de=
termined by the "type" property. This allows extensions to define=
 new ways to query for an authorization rather than having to fit into scop=
es or RAR.


It=E2=80=99s my stance that this is an unnecessary limitation at thi=
s level. The objects within the array should be typed, like RAR, but it doe=
sn=E2=80=99t make sense for the overall request to be typed. Instead, there=
 should be one =E2=80=9Ctype" of query in the core, what XYZ calls the=
 =E2=80=9Cresources=E2=80=9D request. Other query languages should be added=
 as extensions either to the RAR-style objects (by defining a type at that =
level) or as a separate top-level member.

For exam=
ple, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D query language. M=
y current thought is that this really shouldn=E2=80=99t be a part of the =
=E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D part of the request=
, but instead as its own top-level member, like it is in the OIDC protocol =
today. The main reason for this is the nature of the OIDC claims language: =
it specifies targets for the resulting data, and those targets cross differ=
ent ways to return things. So it doesn=E2=80=99t actually affect just resou=
rces like the UserInfo Endpoint, or the ID Token, but both and potentially =
others out there. If your system supported such an extension, it could theo=
retically forego both the built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cre=
sources=E2=80=9D parts of the request, and use the =E2=80=9Coidc_claims_que=
ry=E2=80=9D member (or whatever it would be called). This would let such an=
 extension use the OIDC claims processing mechanism as it is today.

To me, this remains much more understandable, extensible,=
 and clean.

While this ma=
y be more understandable to a developer just=C2=A0porting an app OIDC that =
only wants OIDC results, but I think it is more complicated as soon as the =
developer wants other results, which is likely what=C2=A0prompted the devel=
oper to use GNAP instead of ODIC.

I think it is ea=
sier to understand if all the claims are in one container, and all the auth=
orizations are in another container.

If a develope=
r wants access to some resources, some claims, and an OpenID Token, they ar=
e having to use "claims", "resources", and "oidc_c=
laims_query".=C2=A0 Now the claims and access tokens are spread across=
 multiple containers. There are some claims in the "claims" conta=
iner, and some "claims" in the "oidc_claims_query" cont=
ainer. And is the access token response in=C2=A0"oidc_claims_query&quo=
t; the same as an access token response in "resources"? It would =
seem simpler if they were, and if all the access tokens came back in the sa=
me container.

Per Aaron's post that you have r=
eferred to, the developer can get sme bare claims directly in the response =
in the "claims" object, an ID Token that has the same or differen=
t claims, and if they want, an access token that they can call a user_info =
endpoint to get the same, or different claims.

For=
 example, an enterprise app client may want an ID Token with the email addr=
ess, bare claims for the user's name and a URI to a profile photo, and =
an access token to query which groups a user belongs to.

We are still re-using=C2=A0the OIDC claims, but we are not mixing cl=
aims and authorizations.

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

3D""=
=E1=90=A7

3D""=E1=90=A7

3D""=
=E1=90=A7




--0000000000008f808d05aa094bf4--


From nobody Thu Jul  9 15:51: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 D0F7E3A095B for ; Thu,  9 Jul 2020 15:51:12 -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 SFvwAXE3iGnD for ; Thu,  9 Jul 2020 15:51:08 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 EA01F3A094F for ; Thu,  9 Jul 2020 15:51:07 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id h22so4225132lji.9 for ; Thu, 09 Jul 2020 15:51: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=i55VCcK9H29QOUtwsJQLjc6Qv0lyhntErNpca2ARBSs=; b=L/0vUPl9gmoIX2aU+ZNfItVQ+LsyyJCtF76naYwBJM5yDhMCx6QG0N3JP/yUvEkYUU jhp676fSUbp6GRKXxwvDK9vlCqCpO7BEn0JvDXOnEP09loOZAQDgY0m8h66r7gn+tfJ1 d6vVItVMBxyr/sL27LFal0qeY6kVuNoJyK7snPbPNKwS70uo16u99XuXVz4EGNuqp28Y Htw+Z9PlYhRgR2h8Uvz3dpnCCHkNZeBHbYDlpcBgJdfoZRrWMQHbbH1FJT/PiGDiYpYt N1n3hXdKVtghYBJKii1h404k82v2mOolnScUOEIrpS0qmbY9AjvFoMu3V2UNmOh+AL+Z BWoA==
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=i55VCcK9H29QOUtwsJQLjc6Qv0lyhntErNpca2ARBSs=; b=G90aDfPMzMg0q1Sgc/OQXCQGKFsrGOq+/OZ9XZFQEAvKT7yfVnkSMwHrs4Du5hlAxR rVXRTFOebjMARI+xBw0Kh+TeRq9Jye5y59dP7uGugkoqiwa7PphHawBE8HNc+HV/pZ/O h94DIIJaW4ctmXgUwE6dgYAl06GZ27V4BtGU6ZA58GacK7SvVPoIoKEf7rKcmGmLoKjs aT27DrxjKdiHilMZuOS67P+lnThMBxl4ytsMxLeyQdJqubVLH/C0zdjnU6JAP3UkQL8I NjF8yftJ/V7Roz4MUKhObcKzw70o25asv77bc9xaZHDmZiXPDuDIatWNKvWsdI7S0rdn pjfQ==
X-Gm-Message-State: AOAM5318jRPBEZTRgNYb9D54QTxNERh6b3bAmoCipVLJ5nL9JF3aMHJd a8HZ15TKr0sMgAQtwwRLXitkM8dz9W8TJOF98XM=
X-Google-Smtp-Source: ABdhPJx5h3eOrNrkZudwsJ+M0qtyLBUsEA4s6n7e68dy1pGgi/RsncTd0dlxtMWNtNduzEbw7gFzF9fqLrYzsCbAg3g=
X-Received: by 2002:a2e:900a:: with SMTP id h10mr39978239ljg.242.1594335065810;  Thu, 09 Jul 2020 15:51:05 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>     <69082870-1A99-4912-95EA-D1B7A1C967E5@mit.edu>
In-Reply-To: <69082870-1A99-4912-95EA-D1B7A1C967E5@mit.edu>
From: Dick Hardt 
Date: Thu, 9 Jul 2020 15:50:29 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000402bc505aa0a0f61"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 09 Jul 2020 22:51:13 -0000

--000000000000402bc505aa0a0f61
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 9, 2020 at 12:17 PM Justin Richer  wrote:

> On Jul 9, 2020, at 2:32 PM, Dick Hardt  wrote:
>
>
> Looks like you missed the point of my code example, as your response is
> focussed on the aspects I had in comments, so let me clarify.
>
>
> The point seemed to be about the overall complexity and readability, and
> that=E2=80=99s what I responded to.
>

It was about the complexity and readability -- of those specific lines of
code.

I've used JS type polymorphism to provide a cleaner API. For example,
making an HTTP request. If I'm good with all the defaults, I can just
provide the URI as a string, if I want to change a default, I provide an
object and the URI is now a property of the object. Polymorphism allows the
caller to have a simpler interface when it is a simple operation.

Do you have any examples of JSON polymorphism used in other protocols
besides in a JWT?


>
>
> This line (which is determining the type of the item in the array):
>
> if (typeof item =3D=3D=3D string')
>
>
> is implicitly stating that the item is an oauth scope.
>
>
> No, it is not. It is saying that it is a resource request represented as =
a
> string. One way to represent a resource request as a string is an OAuth 2
> style scope. And if you=E2=80=99re building up from an existing OAuth 2 s=
ystem,
> then you could use a scope there. But that=E2=80=99s not the same as stat=
ing =E2=80=9Cthe
> item is a scope=E2=80=9D. In my examples, I had been trying to use the te=
rminology
> that you were using, but I=E2=80=99m afraid that made things more unclear=
.
>

We are comparing how to do it in XYZ vs XAuth -- so to make it apples and
apples, the string is a scope, since that is the use case we are looking at=
.


>
> Whereas it is explicit in this statement
>
> if (authorizations.type =3D=3D=3D 'oauth_scope')
>
>
> which I think it easier to understand what is happening (in my opinion of
> course).
>
> XYZ has types, they are just implicit. RAR has explicit types, and that
> does not look to be holding back RAR. I don't understand why you think
> having explicit types will hold us back.
>
>
> The =E2=80=9Ctype=E2=80=9D in RAR is a name spacing device to allow exten=
sibility in
> different aspects of the request. This is at a lower layer than how they=
=E2=80=99re
> being applied here, and it therefore makes more sense at that layer. It=
=E2=80=99s a
> way for a particular API to define the dimensions that it cares about in
> its request. It=E2=80=99s not really an even comparison.
>

And the type in XAuth authorizations is different schemas for making a
request. "oauth_scope", "oauth_rar", and now "oidc". I would expect that
there may be more in the future, and we have a clear way of adding schemas,
and for the client and AS to know they are talking the same "language".


>
> Do you want to let the string and object be anything the AS and RS decide
> they could mean?
>
>
> Yes. Just like the AS can decide that an OAuth scope could mean any numbe=
r
> of things.
>

That was what I was afraid of. While an OAuth scope could mean whatever the
AS decides it wants to be, the Client and AS know it is an OAuth scope.


>
> That would make GNAP more of a framework than a protocol, and a key aspec=
t
> of the request would be undefined.
>
>
> I don=E2=80=99t see how this would make things a framework and not a prot=
ocol.
> We=E2=80=99re not debating the ability to send a set of strings or a set =
of objects
> to the AS, which the AS will interpret in the request. We=E2=80=99re deba=
ting the
> syntax for sending those values.
>



>
>
> My thoughts have not shifted on "types" in interactions. I just changed
> the name to 'mode'. I did shift my thinking that a negotiation of
> interaction modes is useful, and added that.
>
>
> The important shift is the removal of a single =E2=80=9Ctype=E2=80=9D fie=
ld that meant you
> could only send one thing at a time, and now you can send multiple things
> in various combinations as need allows. That=E2=80=99s the kind of thing =
that I=E2=80=99m
> saying is problematic here as well, for many of the same reasons.
>
>
> We still have an unfinished discussion there. When you have a chance,
> would you respond to that thread?
>
>
> I believe the thread you=E2=80=99re referring to was commented on by seve=
ral
> people, including an AD, as not being a helpful conversation for the grou=
p.
> I stopped responding to that thread when that was brought up, in order to
> respect that position and hopefully move the conversation along.
>

This is the thread I am referring to:

https://mailarchive.ietf.org/arch/msg/txauth/ECfShOtiN1WA1QiI77CBId4_VXg/

And I don't think Ben was saying the conversation was not helpful, but
wanted to clarify the goal:

https://mailarchive.ietf.org/arch/msg/txauth/qOF5Wl3uYQ9rdzEz7ORftYAAHc4/


> I=E2=80=99m beginning to think that this conversation thread is itself go=
ing off
> the rails in a similar way, since we seem to be repeating things at each
> other.
>

Seems later messages in this thread indicate otherwise as there seems to be
some additional understanding.


> It=E2=80=99s become a comparison of solutions in detail and not a discuss=
ion of
> what the driving use cases are. I understand that you think your proposal
> is better, and I disagree and have pointed out what I see as several majo=
r
> flaws in it.
>

Would you list those for me so I have a better idea of what they are? What
aspect of the XAuth authorizations could you not live with?


>
> My goal here isn=E2=80=99t to convince you as an individual that I=E2=80=
=99m right. My
> goal here is to present my ideas and explain the thought process behind
> them so that we all, as a group, can make the best decisions going forwar=
d
> based on that.
>

Well it seems we have different goals. I'm trying to get a better
understanding of your proposals, explain my concerns, and offer a solution
to arrive at some rough consensus. You only want to present your ideas.

 /Dick


>  =E2=80=94 Justin
>
>
> /Dick
>
> On Thu, Jul 9, 2020 at 8:39 AM Justin Richer  wrote:
>
>> Declarations of which code is =E2=80=9Ceasier to understand=E2=80=9D are=
 going to be
>> subjective, and I don=E2=80=99t agree with your conclusions even with yo=
ur
>> examples. Even so, I don=E2=80=99t think that the examples you give are =
a good
>> comparison. While it is of course possible to implement things like you
>> have below, I think it=E2=80=99s indicative of thinking of things in ter=
ms of a
>> =E2=80=9Cresource request type=E2=80=9D. What I=E2=80=99ve been trying t=
o argue is that there
>> shouldn=E2=80=99t be a =E2=80=9Ctype=E2=80=9D, that there should just be=
 slightly different ways to
>> do a resource request. So the code is more like:
>>
>> resourcesRequested =3D requests.map( item =3D> {
>>    if (typeof item =3D=3D =E2=80=98object=E2=80=99) {
>>       return new RarStyleResourceRequest(item);
>>    } else if (typeof item =3D=3D =E2=80=9Cstring=E2=80=9D) {
>>      return new StringStyleResourceRequest(item);
>>    }
>> });
>> processResources(resourcesRequested);
>>
>>
>> Each of these =E2=80=9C*ResourceRequest=E2=80=9D objects would be someth=
ing that the AS
>> can use to decide what to put into the access token. Although you=E2=80=
=99d
>> probably put that complexity into a factory constructor or something
>> instead of a map function, this shows the kind of dispatch you can do ba=
sed
>> on type if you=E2=80=99re doing it by hand. You collect everything in th=
e array,
>> and turn it into an object that represents =E2=80=9Ca request for a reso=
urce that
>> gets tied to an access token=E2=80=9D. And then you process the request =
based on
>> the collection of resource requests. Each string-based request points to
>> some set of policies, as does each object-based request. You can even
>> imagine that instead of creating a separate string-based request, you us=
e
>> that string to look up a policy in a policy engine to be applied later.
>>
>> The AS then has to figure out, as it always does, what to do with this
>> collection. And if you want to do an early escape on object style reques=
ts,
>> you could just throw an error when you detect that. Or, you just ignore
>> that part of the request. In fact, here=E2=80=99s the code I wrote that =
handles it
>> exactly that way, while processing the JSON by hand in Java on a legacy
>> OAuth 2 server:
>>
>>
>> JsonArray resources =3D json.get("resources").getAsJsonArray();
>> Set scopes =3D StreamSupport.stream(resources.spliterator(), fal=
se)
>> .filter( e -> e.isJsonPrimitive() ) // filter out anything that's not a
>> handle
>> .map( e -> e.getAsString() )
>> .collect(Collectors.toSet());
>> tx.setScope(scopes);
>>
>>
>>
>> Furthermore, your XAuth example doesn=E2=80=99t go to the same depth as =
the XYZ
>> example, which leads to a false comparison. In your =E2=80=9Cprocess sco=
pe=E2=80=9D you
>> would need to parse the =E2=80=9Cscope=E2=80=9D string to split on space=
s, and then have
>> another loop to process each scope. For the =E2=80=9Cprocess details=E2=
=80=9D you=E2=80=99d need to
>> iterate over the array at the root of a RAR-style request and process ea=
ch
>> piece. In the XYZ code, you=E2=80=99ve got all of that already. If you=
=E2=80=99re going to
>> compare the complexity of code, they should at least be shown to the sam=
e
>> point of the process.
>>
>> On top of that, the fall-through case statement below is really limiting=
.
>> What if the scope processing or RAR objects processing gets combined wit=
h
>> something else? This kind of premature optimization is not something we
>> want to encourage developers to do.
>>
>> But ultimately, I think the disconnect is down to thinking about this in
>> terms of an explicit =E2=80=9Ctype=E2=80=9D, much the way XAuth used to =
do with the
>> interactions. I=E2=80=99m glad that your thoughts have shifted in that s=
pace, and I
>> think you should strongly consider the same set of arguments here. A lot=
 of
>> the promise of GNAP is getting away from this type-field style design, l=
ike
>> getting away from OAuth 2=E2=80=99s =E2=80=9Cgrant_type=E2=80=9D approac=
h and into something that=E2=80=99s
>> focused on interaction and client models instead. This newer model allow=
s
>> for better flexibility, better consistency, and better clarity throughou=
t.
>> It=E2=80=99s no longer =E2=80=9Cif I see this flag then I go down this s=
eparate code path
>> and nothing else=E2=80=9D, it=E2=80=99s now =E2=80=9Cif I see this item,=
 I go down this code path
>> and then process the next item too=E2=80=9D. There=E2=80=99s power in th=
e combinations.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 8, 2020, at 9:31 PM, Dick Hardt  wrote:
>>
>> I had intended to provide a code sample comparing XYZ request type with
>> XAuth request type
>>
>> Let's say an AS only supports OAuth scopes (does not support RAR). Here
>> is JS code to check:
>>
>> //XYZ code
>>
>> var oauth_scope =3D true;
>> requests.forEach( item =3D> {
>>     if (typeof item =3D=3D=3D "object")
>>         oauth_scope =3D false;
>> });
>> if (!'oauth_scope') {
>>     // return error
>> }
>>
>> // XAuth code
>>
>> if ('oauth_scope' !=3D authorizations.type) {
>>    // return error
>> }
>>
>>
>> Here is some JS code that for an AS that supports OAuth scopes, RAR, and
>> OIDC requests:
>>
>> // XYZ
>>
>> if (request) {
>>     requests.forEach( item =3D> {
>>         if (typeof item =3D=3D=3D "object") {
>>             // process a RAR item
>>         } else if(typeof item =3D=3D=3D 'string') {
>>             // process a scope item
>>         } else {
>>             // throw an error
>>         }
>>     })
>>    // process the whole request
>> }
>> if (oidc_claims_query) {
>>     // process oidc request
>> }
>>
>> //XAuth
>>
>> if (authorizations) {
>>     switch (authorizations?.type) {
>>         case 'oauth_rar':
>>             // process authorizations.details - RAR
>>         case 'oauth_scope':
>>             // process authorizations.scope
>>             // process the whole request
>>             break;
>>         case 'oidc':
>>             // process OIDC claims
>>             break;
>>         default:
>>             // error for unknown type
>>     }
>> }
>>
>>
>> Understanding what the code is doing looks much clearer in XAuth to me.
>>
>> =E1=90=A7
>>
>> On Wed, Jul 8, 2020 at 3:55 PM Dick Hardt  wrote:
>>
>>> Hey Justin,
>>>
>>> Just because we are using OIDC claims, does not mean we need to mimic
>>> the OIDC request and response.
>>> I was envisioning a grant request could look as the following (using
>>> XAuth syntax):
>>>
>>> {
>>>     "authorizations": {
>>>         "type":"oidc",
>>>         "claims": ["name", "picture"]
>>>     },
>>>     "claims":{
>>>         "oidc": {
>>>             "id_token" : {
>>>                 "email"          : { "essential" : true },
>>>                 "email_verified" : { "essential" : true }
>>>             },
>>>             "userinfo" : {
>>>                 "name"           : { "essential" : true },
>>>                 "picture"        : null
>>>             }
>>>         }
>>>     }
>>> }
>>>
>>> Of course a developer could choose to only ask for a subset of this.
>>>
>>> Note the new authorization type of "oidc", that takes "claims" rather
>>> than "scope".
>>>
>>> This keeps all the authorizations and claims in their respective reques=
t
>>> and response containers.
>>>
>>> We had a thread months ago on the OIDC two stage model, and I still fai=
l
>>> to see why forcing that has any advantage.
>>>
>>> /Dick
>>>
>>>
>>> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer  wrote:
>>>
>>>> I=E2=80=99m glad that we can agree that there are a number of things i=
n legacy
>>>> protocols that are unfortunate side effects of the circumstances in wh=
ich
>>>> they were built. Space-separated scope strings, for instance, would fa=
ll in
>>>> that category, as I=E2=80=99ve previously explained.
>>>>
>>>> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request al=
ready mixes user
>>>> claims (returned in an API) and authorization (to fetch user claims fr=
om an
>>>> API), so that ship has sailed if you=E2=80=99re using it. It doesn=E2=
=80=99t make sense to
>>>> have it under a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Cauthorizations=E2=
=80=9D request, since it=E2=80=99s a query
>>>> language that affects both. Maybe you=E2=80=99d call this another =E2=
=80=9Cunfortunate
>>>> design=E2=80=9D, but the context was about re-using an externally-defi=
ned query
>>>> language that was not made for GNAP.
>>>>
>>>> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=
=9D and wants to
>>>> keep using it. (The vast majority of OIDC implementations, in my
>>>> experience, don=E2=80=99t use that feature, and it=E2=80=99s not even =
required to be
>>>> implemented by the AS, but again we=E2=80=99re talking about using thi=
s feature as
>>>> an example of an external query language =E2=80=94 and there are other=
s out there.)
>>>> In GNAP, you should return claims directly in the response, and reques=
t
>>>> specific elements from the APIs protected by the access token. These a=
re
>>>> separate things, and by design both XAuth and XYZ have put them into
>>>> separate containers in the request. This is a good design, and so putt=
ing
>>>> something that conflates these two aspects into one or the other of th=
e
>>>> containers is not a particularly good option, in my opinion.
>>>>
>>>> Additionally, though this is a bit of an aside and getting into the
>>>> specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC =
is a query language
>>>> bound to the full user profile. It is my stated position that the item=
s
>>>> coming back from the AS should only be identifiers, and not full profi=
le
>>>> information. The reasoning is pretty simple: the client doesn=E2=80=99=
t know what
>>>> profile information it needs until it knows who the user is, so puttin=
g
>>>> that into a protected API like the UserInfo Endpoint makes much more s=
ense
>>>> than putting it into the immediate response, where it is not needed,
>>>> because the client already knows it. The AS doesn=E2=80=99t know what =
the client
>>>> needs to know, either, so it can=E2=80=99t determine what to fulfill. =
OIDC=E2=80=99s
>>>> two-stage model makes sense, and GNAP should really only focus on enab=
ling
>>>> this.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Jul 8, 2020, at 6:10 PM, Dick Hardt  wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer  wrote:
>>>>
>>>>> On Jul 8, 2020, at 3:16 PM, Dick Hardt  wrote:
>>>>>
>>>>>
>>>>> I think representing the request as an array is simplistic, and
>>>>> complicated at the same time.
>>>>>
>>>>> On the simplistic front, as there is no clear mechanism for extending
>>>>> the request with properties that apply to all of the request.
>>>>>
>>>>>
>>>>> The elements of the array are taken as a set, to be tied to the same
>>>>> resulting access token. If one of those elements is defined, by the A=
S
>>>>> and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some=
 or all of the other
>>>>> elements, then that=E2=80=99s up to the AS=E2=80=99s policy. Much lik=
e the =E2=80=9Copenid=E2=80=9D scope
>>>>> in OIDC, which switches on all sorts of contextual stuff in the reque=
st. So
>>>>> to handle something like this, an AS can easily declare that a given
>>>>> scope-style string or a given object property applies to different pa=
rts of
>>>>> the request. You don=E2=80=99t need to externalize it here.
>>>>>
>>>>
>>>> I view the "openid" scope as an unfortunate design as OIDC was
>>>> constrained by building on top of OAuth. (a problem I hoped to avert b=
y
>>>> having "identity" in scope for GNAP) The "openid" scope does not funct=
ion
>>>> as scope per se, and I think it makes OIDC harder to understand as the
>>>> "openid" scope causes non-scope behavior.
>>>>
>>>>
>>>>
>>>>>
>>>>> Do you have a concrete use case that requires that feature to be done
>>>>> in the way that you describe? I am trying to separate the driving use=
 case
>>>>> from the proposed solutions to see what the differences are.
>>>>>
>>>>
>>>> Perhaps the client wants access to be HIPPA compliant? The HIPPA
>>>> compliance signal applies to the scopes.
>>>>
>>>> Adding other properties to an object is a well understood extension
>>>> mechanism. Adding an additional element to an array that does not act =
like
>>>> the other elements seems like a hack.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> Using JSON type polymorphism requires the AS to test each member of
>>>>> the array to determine if it is a string or an object. Only after det=
ecting
>>>>> a RAR object does the AS know the client is making a RAR request.
>>>>>
>>>>>
>>>>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the whole =
resources request
>>>>> in order to figure out what the client is asking for, anyway, whether=
 it=E2=80=99s
>>>>> by strings or objects or whatever else might be defined by an extensi=
on. Is
>>>>> there an argument for having an AS do an early dispatch on a request =
before
>>>>> it=E2=80=99s fully parsed everything?
>>>>>
>>>>
>>>> Let me clarify, the code is looking at the type of object that has bee=
n
>>>> parsed.
>>>>
>>>> Determining if an item in an array is a scope or a RAR object by
>>>> looking at the type being either a string or an object seems less clea=
r
>>>> than a property of an object explicitly declaring the type.
>>>>
>>>>
>>>>
>>>>>
>>>>> This also limits the request to be composed only of scope strings or
>>>>> RAR objects. I don't see how other strings or objects could be used i=
n the
>>>>> array, so there is no clear extension point in the "resources" array =
for
>>>>> other query mechanisms.
>>>>>
>>>>>
>>>>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t declaring =
that a string has
>>>>> to be an OAuth2-style scope. It can be, but ultimately it=E2=80=99s j=
ust a string
>>>>> that the AS can understand. And the objects are just that =E2=80=94 o=
bjects. If the
>>>>> AS understands what the object is, it can be a RAR object or it can b=
e
>>>>> something completely API-specific with another query language entirel=
y.
>>>>>
>>>>
>>>> But the other query language would need a type that has been reserved
>>>> in the RAR name space for there to be interop, so it effectively is a =
RAR
>>>> extension.
>>>>
>>>> There are query languages in other domains that may not fit nicely int=
o
>>>> RAR such as a query for medical records.
>>>>
>>>> Yes, the medical records could be yet another top level property, but
>>>> per below, I think that is confusing.
>>>>
>>>>
>>>>> (Point, though: RAR already pretty much allows this by letting them b=
e
>>>>> extended infinitely, a feature it inherits from XYZ)
>>>>>
>>>>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=
=99s an array of
>>>>> strings or objects and each of those means the same thing, =E2=80=9Cs=
omething the
>>>>> client is asking for=E2=80=9D.
>>>>>
>>>>>
>>>>> Just as RAR has a "type" property, I propose the "resources"
>>>>> ("authorizations" in XAuth) be an object, where the other properties =
are
>>>>> determined by the "type" property. This allows extensions to define n=
ew
>>>>> ways to query for an authorization rather than having to fit into sco=
pes or
>>>>> RAR.
>>>>>
>>>>>
>>>>> It=E2=80=99s my stance that this is an unnecessary limitation at this=
 level.
>>>>> The objects within the array should be typed, like RAR, but it doesn=
=E2=80=99t make
>>>>> sense for the overall request to be typed. Instead, there should be o=
ne
>>>>> =E2=80=9Ctype" of query in the core, what XYZ calls the =E2=80=9Creso=
urces=E2=80=9D request. Other
>>>>> query languages should be added as extensions either to the RAR-style
>>>>> objects (by defining a type at that level) or as a separate top-level
>>>>> member.
>>>>>
>>>>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D que=
ry language. My current
>>>>> thought is that this really shouldn=E2=80=99t be a part of the =E2=80=
=9Cresources=E2=80=9D or
>>>>> =E2=80=9Cclaims=E2=80=9D part of the request, but instead as its own =
top-level member, like
>>>>> it is in the OIDC protocol today. The main reason for this is the nat=
ure of
>>>>> the OIDC claims language: it specifies targets for the resulting data=
, and
>>>>> those targets cross different ways to return things. So it doesn=E2=
=80=99t actually
>>>>> affect just resources like the UserInfo Endpoint, or the ID Token, bu=
t both
>>>>> and potentially others out there. If your system supported such an
>>>>> extension, it could theoretically forego both the built-in =E2=80=9Cc=
laims=E2=80=9D and
>>>>> =E2=80=9Cresources=E2=80=9D parts of the request, and use the =E2=80=
=9Coidc_claims_query=E2=80=9D member
>>>>> (or whatever it would be called). This would let such an extension us=
e the
>>>>> OIDC claims processing mechanism as it is today.
>>>>>
>>>>> To me, this remains much more understandable, extensible, and clean.
>>>>>
>>>>
>>>> While this may be more understandable to a developer just porting an
>>>> app OIDC that only wants OIDC results, but I think it is more complica=
ted
>>>> as soon as the developer wants other results, which is likely what pro=
mpted
>>>> the developer to use GNAP instead of ODIC.
>>>>
>>>> I think it is easier to understand if all the claims are in one
>>>> container, and all the authorizations are in another container.
>>>>
>>>> If a developer wants access to some resources, some claims, and an
>>>> OpenID Token, they are having to use "claims", "resources", and
>>>> "oidc_claims_query".  Now the claims and access tokens are spread acro=
ss
>>>> multiple containers. There are some claims in the "claims" container, =
and
>>>> some "claims" in the "oidc_claims_query" container. And is the access =
token
>>>> response in "oidc_claims_query" the same as an access token response i=
n
>>>> "resources"? It would seem simpler if they were, and if all the access
>>>> tokens came back in the same container.
>>>>
>>>> Per Aaron's post that you have referred to, the developer can get sme
>>>> bare claims directly in the response in the "claims" object, an ID Tok=
en
>>>> that has the same or different claims, and if they want, an access tok=
en
>>>> that they can call a user_info endpoint to get the same, or different
>>>> claims.
>>>>
>>>> For example, an enterprise app client may want an ID Token with the
>>>> email address, bare claims for the user's name and a URI to a profile
>>>> photo, and an access token to query which groups a user belongs to.
>>>>
>>>> We are still re-using the OIDC claims, but we are not mixing claims an=
d
>>>> authorizations.
>>>>
>>>> /Dick
>>>>
>>>>
>>>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
>>>> =E1=90=A7
>>>>
>>>>
>>>> =E1=90=A7
>>>
>>
>> =E1=90=A7
>
>
>

--000000000000402bc505aa0a0f61
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On =
Thu, Jul 9, 2020 at 12:17 PM Justin Richer <jricher@mit.edu> wrote:
On Jul=
 9, 2020, at 2:32 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

L=
ooks like you missed the point of my code example, as your response is focu=
ssed on the aspects I had in=C2=A0comments, so let me clarify.=C2=A0
<=
/div>

The point seemed to be ab=
out the overall complexity and readability, and that=E2=80=99s what I respo=
nded to.

It was about the=
 complexity and readability -- of those specific lines of code.
<=
br>
I've used JS type polymorphism to provide a cleaner API. =
For example, making an HTTP request. If I'm good with all the defaults,=
 I can just provide the URI as a string, if I want to change a default, I p=
rovide an object and the URI is now a property of the object. Polymorphism =
allows the caller to have a simpler interface when it is a simple operation=
.

Do you have any=C2=A0examples of JSON polymorphi=
sm used in other protocols besides in a JWT?
=C2=A0


This line (which is determining=
=C2=A0the type of the item in the array):

if (typeof item =3D=3D=3D string')

is implicitly stating=C2=A0that the item=
 is an oauth scope. 

No, it is not. It is saying that it is a resource request represented as =
a string. One way to represent a resource request as a string is an OAuth 2=
 style scope. And if you=E2=80=99re building up from an existing OAuth 2 sy=
stem, then you could use a scope there. But that=E2=80=99s not the same as =
stating =E2=80=9Cthe item is a scope=E2=80=9D. In my examples, I had been t=
rying to use the terminology that you were using, but I=E2=80=99m afraid th=
at made things more unclear.

<=
div>We are comparing how to do it in XYZ vs XAuth -- so to make it apples a=
nd apples, the string is a scope, since that is the use case we are looking=
 at.
=C2=A0

Whereas it =
is explicit in this statement

=
if (authorizations.type =3D=3D=3D 'oauth_scope')

which I think it easier to under=
stand what is happening (in my opinion of course).

XYZ has types, they are just implicit. RAR has explicit types, and that do=
es not look to be holding back RAR. I don't understand why you think ha=
ving explicit types will hold us back. 

The =E2=80=9Ctype=E2=80=9D in RAR is a name spacing de=
vice to allow extensibility in different aspects of the request. This is at=
 a lower layer than how they=E2=80=99re being applied here, and it therefor=
e makes more sense at that layer. It=E2=80=99s a way for a particular API t=
o define the dimensions that it cares about in its request. It=E2=80=99s no=
t really an even comparison.

<=
div>And the type in XAuth authorizations=C2=A0is different schemas for maki=
ng a request. "oauth_scope", "oauth_rar", and now "=
;oidc". I would expect that there may be more in the future, and we ha=
ve a clear way of adding schemas, and for the client and AS to know they ar=
e talking the same "language".
=C2=A0

Do you want to let the string and object be anythi=
ng the AS and RS decide they could mean? 

Yes. Just like the AS can decide that an OAuth scope=
 could mean any number of things.

That was what I was afraid of. While an OAuth scope could mean wha=
tever the AS decides it wants to be, the Client and AS know it is an OAuth =
scope.
=C2=A0

That woul=
d make GNAP more of a framework than a protocol, and a key aspect of the re=
quest would be undefined.

I don=E2=80=99t see how this would make things a framework and not a=
 protocol. We=E2=80=99re not debating the ability to send a set of strings =
or a set of objects to the AS, which the AS will interpret in the request. =
We=E2=80=99re debating the syntax for sending those values.

=C2=A0


My thoughts have not shifted on "types" i=
n interactions. I just changed the name to 'mode'.=C2=A0I did shift=
 my thinking that a negotiation=C2=A0of interaction modes is useful, and ad=
ded that.

The impor=
tant shift is the removal of a single =E2=80=9Ctype=E2=80=9D field that mea=
nt you could only send one thing at a time, and now you can send multiple t=
hings in various combinations as need allows. That=E2=80=99s the kind of th=
ing that I=E2=80=99m saying is problematic here as well, for many of the sa=
me reasons.


We still have an =
unfinished discussion there. When you have a chance, would you respond to t=
hat thread?

I belie=
ve the thread you=E2=80=99re referring to was commented on by several peopl=
e, including an AD, as not being a helpful conversation for the group. I st=
opped responding to that thread when that was brought up, in order to respe=
ct that position and hopefully move the conversation along.

This is the thread I am referring to:


And I don'=
;t think Ben was saying the conversation was not helpful, but wanted to cla=
rify the goal:

=C2=A0<=
/div>
 I=E2=80=99m beginning to think that this c=
onversation thread is itself going off the rails in a similar way, since we=
 seem to be repeating things at each other. 
=


Seems later messages in this thread indicate otherwise =
as there seems to be some additional understanding.
=C2=A0
It=E2=80=99s become a comparison of solutions=
 in detail and not a discussion of what the driving use cases are. I unders=
tand that you think your proposal is better, and I disagree and have pointe=
d out what I see as several major flaws in it.

Would you list those for me so I have a better idea o=
f what they are? What aspect of the XAuth authorizations could you not live=
 with?
=C2=A0

My g=
oal here isn=E2=80=99t to convince you as an individual that I=E2=80=99m ri=
ght. My goal here is to present my ideas and explain the thought process be=
hind them so that we all, as a group, can make the best decisions going for=
ward based on that.=C2=A0

Well it seems we have different goals. I'm trying to get a better unde=
rstanding of your=C2=A0proposals, explain my concerns, and offer a solution=
 to arrive at some rough consensus. You only want to present your ideas.

=C2=A0/Dick


=C2=A0=E2=80=94 Justin


<=
/div>
/Dick

On Thu, Jul 9, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wro=
te:
Declara=
tions of which code is =E2=80=9Ceasier to understand=E2=80=9D are going to =
be subjective, and I don=E2=80=99t agree with your conclusions even with yo=
ur examples. Even so, I don=E2=80=99t think that the examples you give are =
a good comparison. While it is of course possible to implement things like =
you have below, I think it=E2=80=99s indicative of thinking of things in te=
rms of a =E2=80=9Cresource request type=E2=80=9D. What I=E2=80=99ve been tr=
ying to argue is that there shouldn=E2=80=99t be a =E2=80=9Ctype=E2=80=9D, =
that there should just be slightly different ways to do a resource request.=
 So the code is more like:

resourcesRequested=
 =3D requests.map( item =3D> {
=C2=A0 =C2=A0if (typ=
eof item =3D=3D =E2=80=98object=E2=80=99) {
=C2=A0 =C2=
=A0 =C2=A0 return new RarStyleResourceRequest(item);
=
=C2=A0 =C2=A0} else if (typeof item =3D=3D =E2=80=9Cstring=E2=80=9D) {
=C2=A0 =C2=A0 =C2=A0return new StringStyleResourceRequest(=
item);
=C2=A0 =C2=A0}
});
processResources(resourcesRequested);

Each of these =E2=80=9C*ResourceRequest=E2=80=9D =
objects would be something that the AS can use to decide what to put into t=
he access token. Although you=E2=80=99d probably put that complexity into a=
 factory constructor or something instead of a map function, this shows the=
 kind of dispatch you can do based on type if you=E2=80=99re doing it by ha=
nd. You collect everything in the array, and turn it into an object that re=
presents =E2=80=9Ca request for a resource that gets tied to an access toke=
n=E2=80=9D. And then you process the request based on the collection of res=
ource requests. Each string-based request points to some set of policies, a=
s does each object-based request. You can even imagine that instead of crea=
ting a separate string-based request, you use that string to look up a poli=
cy in a policy engine to be applied later.

The AS =
then has to figure out, as it always does, what to do with this collection.=
 And if you want to do an early escape on object style requests, you could =
just throw an error when you detect that. Or, you just ignore that part of =
the request. In fact, here=E2=80=99s the code I wrote that handles it exact=
ly that way, while processing the JSON by hand in Java on a legacy OAuth 2 =
server:


JsonArray=C2=A0resources=C2=A0=
=3D=C2=A0json.get("resources").getAsJsonArray();=C2=A0=C2=A0=C2=
=A0 =C2=A0=C2=A0
Set<String>=C2=A0scopes=C2=A0=3D=C2=A0Stre=
amSupport.stream(resources.spliterator(),=C2=A0false)
	.filter( e=C2=A0->=C2=A0e.isJsonPrimit=
ive() )=C2=A0//=C2=A0filter out anything that's not a handle=C2=A0=C2=
=A0=C2=A0 =C2=A0=C2=A0
	.map( e=C2=A0->=C2=A0e.getAsString() )=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=

	.collect(Collectors=
.toSet());=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0
tx.setScope(scopes);


Furthermore, your X=
Auth example doesn=E2=80=99t go to the same depth as the XYZ example, which=
 leads to a false comparison. In your =E2=80=9Cprocess scope=E2=80=9D you w=
ould need to parse the =E2=80=9Cscope=E2=80=9D string to split on spaces, a=
nd then have another loop to process each scope. For the =E2=80=9Cprocess d=
etails=E2=80=9D you=E2=80=99d need to iterate over the array at the root of=
 a RAR-style request and process each piece. In the XYZ code, you=E2=80=99v=
e got all of that already. If you=E2=80=99re going to compare the complexit=
y of code, they should at least be shown to the same point of the process.=
=C2=A0

On top of that, the fall-through case state=
ment below is really limiting. What if the scope processing or RAR objects =
processing gets combined with something else? This kind of premature optimi=
zation is not something we want to encourage developers to do.=C2=A0
<=
div>
But ultimately, I think the disconnect is down to thinki=
ng about this in terms of an explicit =E2=80=9Ctype=E2=80=9D, much the way =
XAuth used to do with the interactions. I=E2=80=99m glad that your thoughts=
 have shifted in that space, and I think you should strongly consider the s=
ame set of arguments here. A lot of the promise of GNAP is getting away fro=
m this type-field style design, like getting away from OAuth 2=E2=80=99s =
=E2=80=9Cgrant_type=E2=80=9D approach and into something that=E2=80=99s foc=
used on interaction and client models instead. This newer model allows for =
better flexibility, better consistency, and better clarity throughout. It=
=E2=80=99s no longer =E2=80=9Cif I see this flag then I go down this separa=
te code path and nothing else=E2=80=9D, it=E2=80=99s now =E2=80=9Cif I see =
this item, I go down this code path and then process the next item too=E2=
=80=9D. There=E2=80=99s power in the combinations.

=C2=A0=E2=80=94 Justin

On Jul 8=
, 2020, at 9:31 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I had intended to provide a code sample comparing XYZ request typ=
e with XAuth request type

Let's say an AS only s=
upports OAuth scopes (does not support RAR). Here is JS code to check:

//XYZ code
var oauth_scope =3D true;
requests.=
forEach( item =3D> {=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=

=C2=A0 =C2=A0 if (typeof item =3D=3D=3D "object")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth_scope =3D false;
});
if (!'oauth_scope') {
=C2=A0 =C2=A0 // return error=

}

// XAuth code
if ('oau=
th_scope' !=3D authorizations.type) {
=C2=A0 =C2=A0// return =
error
}

Here is some JS cod=
e that for an AS that supports OAuth scopes, RAR, and OIDC requests:
if (request) {
=C2=A0 =C2=A0 requests.forEach( item =
=3D> {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (typeof item =3D=3D=3D "ob=
ject") {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // process a RAR=
 item
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } else if(typeof item =3D=3D=3D 's=
tring') {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // process a sco=
pe item
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } else {
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 // throw an error
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=
=A0 =C2=A0 }) =C2=A0 =C2=A0
=C2=A0 =C2=A0// process the whole request}
if (oidc_claims_query) {
=C2=A0 =C2=A0 // process oidc request
=
}

//XAuth
if (authorizations) {
=C2=A0 =C2=A0 switch (=
authorizations?.type) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case 'oauth_rar&=
#39;:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // process authorization=
s.details - RAR=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case '=
;oauth_scope':
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // process =
authorizations.scope
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // proces=
s the whole request
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 case 'oidc':
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 // process OIDC claims
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 break;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 default:
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // error for unknown type
=C2=A0 =C2=A0 =
}
}=C2=A0 =C2=A0=C2=A0


Understanding what the code is doing looks much clearer in XAuth to me.

3D""=E1=90=A7

On Wed, Jul 8, 2020=
 at 3:55 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Just=
in,

Just because=C2=A0we are using OIDC claims, does not=
 mean we need to mimic the OIDC request and response.
I was envis=
ioning a grant request could look as the following (using XAuth syntax):

{
=C2=A0 =C2=A0 "authorizations": {
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type":"oidc",
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "claims": ["name", "picture&q=
uot;]
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 "claims":{
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 "id_token" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "email" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: =
{ "essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "email_verified" : { "essential" : tr=
ue }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "userinfo" : {
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name" =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 : { "essential" : true },
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "picture" =C2=A0 =C2=A0 =C2=A0=
 =C2=A0: null
=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>Of course a developer could choose to only ask for a subset of this.

Note the new authorization type of "oidc",=
 that takes "claims" rather than "scope".=C2=A0

This keeps all the authorizations and claims in their res=
pective request and response containers.

We had a =
thread months ago on the OIDC two stage model, and I still fail to see why =
forcing that has any advantage.=C2=A0

/Dick
<=
div>

On Wed, Jul 8, 2020 at 3:25 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m =
glad that we can agree that there are a number of things in legacy protocol=
s that are unfortunate side effects of the circumstances in which they were=
 built. Space-separated scope strings, for instance, would fall in that cat=
egory, as I=E2=80=99ve previously explained.

A key point=
 in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request already mixes user=
 claims (returned in an API) and authorization (to fetch user claims from a=
n API), so that ship has sailed if you=E2=80=99re using it. It doesn=E2=80=
=99t make sense to have it under a =E2=80=9Cclaims=E2=80=9D or =E2=80=9Caut=
horizations=E2=80=9D request, since it=E2=80=99s a query language that affe=
cts both. Maybe you=E2=80=99d call this another =E2=80=9Cunfortunate design=
=E2=80=9D, but the context was about re-using an externally-defined query l=
anguage that was not made for GNAP.

My scenario was for =
someone who is already using =E2=80=9Cclaims=E2=80=9D and wants to keep usi=
ng it. (The vast majority of OIDC implementations, in my experience, don=E2=
=80=99t use that feature, and it=E2=80=99s not even required to be implemen=
ted by the AS, but again we=E2=80=99re talking about using this feature as =
an example of an external query language =E2=80=94 and there are others out=
 there.) In GNAP, you should return claims directly in the response, and re=
quest specific elements from the APIs protected by the access token. These =
are separate things, and by design both XAuth and XYZ have put them into se=
parate containers in the request. This is a good design, and so putting som=
ething that conflates these two aspects into one or the other of the contai=
ners is not a particularly good option, in my opinion.=C2=A0

=

Additionally, though this is a bit of an aside and getting into =
the specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC i=
s a query language bound to the full user profile. It is my stated position=
 that the items coming back from the AS should only be identifiers, and not=
 full profile information. The reasoning is pretty simple: the client doesn=
=E2=80=99t know what profile information it needs until it knows who the us=
er is, so putting that into a protected API like the UserInfo Endpoint make=
s much more sense than putting it into the immediate response, where it is =
not needed, because the client already knows it. The AS doesn=E2=80=99t kno=
w what the client needs to know, either, so it can=E2=80=99t determine what=
 to fulfill. OIDC=E2=80=99s two-stage model makes sense, and GNAP should re=
ally only focus on enabling this.

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

On Jul 8, 2020, at=
 6:10 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Wed, Jul 8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 20=
20, at 3:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I think representing t=
he request as an array is simplistic, and complicated at the same time.
On the simplistic front, as there is no clear mechanism for=
 extending the request with properties that apply to all of the request.=C2=
=A0

The elements of=
 the array are taken as a set, to be tied to the same resulting access toke=
n. If one of those elements is defined, by the AS and/or the RS=E2=80=99s i=
t=E2=80=99s protecting, to apply across some or all of the other elements, =
then that=E2=80=99s up to the AS=E2=80=99s policy. Much like the =E2=80=9Co=
penid=E2=80=9D scope in OIDC, which switches on all sorts of contextual stu=
ff in the request. So to handle something like this, an AS can easily decla=
re that a given scope-style string or a given object property applies to di=
fferent parts of the request. You don=E2=80=99t need to externalize it here=
.

I view the "openid=
" scope as an unfortunate design as OIDC was constrained by building=
=C2=A0on top of OAuth. (a problem I hoped to avert by having "identity=
" in scope for GNAP) The "openid" scope does not function as=
 scope=C2=A0per se, and I think it makes OIDC harder to understand as the &=
quot;openid" scope causes non-scope behavior.=C2=A0

=C2=A0
<=
div>

Do you have a concrete use case that requires that =
feature to be done in the way that you describe? I am trying to separate th=
e driving use case from the proposed solutions to see what the differences =
are.=C2=A0

Perhaps the cl=
ient wants access to be HIPPA compliant? The HIPPA compliance signal applie=
s to the scopes.

Adding other properties to an obj=
ect is a well understood extension mechanism. Adding an additional element =
to an array that does not act like the other elements seems like a hack.

=C2=A0


Using JSON type polymorphism=
=C2=A0requires the AS to test each member of the array to determine if it i=
s a string or an object. Only after detecting a RAR object does the AS know=
 the client is making a RAR request.=C2=A0

That=E2=80=99s correct =E2=80=94 but t=
he AS needs to parse the whole resources request in order to figure out wha=
t the client is asking for, anyway, whether it=E2=80=99s by strings or obje=
cts or whatever else might be defined by an extension. Is there an argument=
 for having an AS do an early dispatch on a request before it=E2=80=99s ful=
ly parsed everything?

Let=
 me clarify, the code is looking at the type of object that has been parsed=
.=C2=A0

Determining if an item in an array is a sc=
ope or a RAR object by looking at the type being either a string or an obje=
ct seems less clear than a property of an object explicitly declaring the t=
ype.

=C2=A0

This also limits the request to be composed =
only of scope strings or RAR objects. I don't see how other strings or =
objects could be used in the array, so there is no clear extension point in=
 the "resources" array for other query mechanisms.

That=E2=80=99s not the case in XY=
Z since we aren=E2=80=99t declaring that a string has to be an OAuth2-style=
 scope. It can be, but ultimately it=E2=80=99s just a string that the AS ca=
n understand. And the objects are just that =E2=80=94 objects. If the AS un=
derstands what the object is, it can be a RAR object or it can be something=
 completely API-specific with another query language entirely.
<=
/div>

But the other query language would ne=
ed a type that has been reserved in the RAR name space for there to be inte=
rop, so it effectively is a RAR extension.

There a=
re query languages in other domains that may not fit nicely into RAR such a=
s a query for medical records.

Yes, the medical re=
cords could be yet another top level property, but per below, I think that =
is confusing.
=C2=A0
(Point, though: RAR already pretty much allows th=
is by letting them be extended infinitely, a feature it inherits from XYZ)<=
/div>

I=E2=80=99m proposing that we do the same thing wi=
th GNAP: it=E2=80=99s an array of strings or objects and each of those mean=
s the same thing, =E2=80=9Csomething the client is asking for=E2=80=9D.

Just as RAR has a "type" property, I propose the =
"resources" ("authorizations" in XAuth) be an object, w=
here the other properties are determined by the "type" property. =
This allows extensions to define new ways to query for an authorization rat=
her than having to fit into scopes or RAR.

=


It=E2=80=99s my stance that this is =
an unnecessary limitation at this level. The objects within the array shoul=
d be typed, like RAR, but it doesn=E2=80=99t make sense for the overall req=
uest to be typed. Instead, there should be one =E2=80=9Ctype" of query=
 in the core, what XYZ calls the =E2=80=9Cresources=E2=80=9D request. Other=
 query languages should be added as extensions either to the RAR-style obje=
cts (by defining a type at that level) or as a separate top-level member.

For example, let=E2=80=99s take the OIDC =E2=80=9Cc=
laims=E2=80=9D query language. My current thought is that this really shoul=
dn=E2=80=99t be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaim=
s=E2=80=9D part of the request, but instead as its own top-level member, li=
ke it is in the OIDC protocol today. The main reason for this is the nature=
 of the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the ID T=
oken, but both and potentially others out there. If your system supported s=
uch an extension, it could theoretically forego both the built-in =E2=80=9C=
claims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts of the request, and u=
se the =E2=80=9Coidc_claims_query=E2=80=9D member (or whatever it would be =
called). This would let such an extension use the OIDC claims processing me=
chanism as it is today.

To me, this remains much m=
ore understandable, extensible, and clean.

While this may be more understandable to a developer just=
=C2=A0porting an app OIDC that only wants OIDC results, but I think it is m=
ore complicated as soon as the developer wants other results, which is like=
ly what=C2=A0prompted the developer to use GNAP instead of ODIC.
=

I think it is easier to understand if all the claims are in =
one container, and all the authorizations are in another container.

If a developer wants access to some resources, some claim=
s, and an OpenID Token, they are having to use "claims", "re=
sources", and "oidc_claims_query".=C2=A0 Now the claims and =
access tokens are spread across multiple containers. There are some claims =
in the "claims" container, and some "claims" in the &qu=
ot;oidc_claims_query" container. And is the access token response in=
=C2=A0"oidc_claims_query" the same as an access token response in=
 "resources"? It would seem simpler if they were, and if all the =
access tokens came back in the same container.

Per=
 Aaron's post that you have referred to, the developer can get sme bare=
 claims directly in the response in the "claims" object, an ID To=
ken that has the same or different claims, and if they want, an access toke=
n that they can call a user_info endpoint to get the same, or different cla=
ims.

For example, an enterprise app client may wan=
t an ID Token with the email address, bare claims for the user's name a=
nd a URI to a profile photo, and an access token to query which groups a us=
er belongs to.

We are still re-using=C2=A0the OIDC=
 claims, but we are not mixing claims and authorizations.
=
3D""<=
font color=3D"#ffffff" size=3D"1">=E1=90=A7
=


3D""=E1=90=
=A7

3D""=E1=90=A7



--000000000000402bc505aa0a0f61--


From nobody Thu Jul  9 17:44: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 39C0A3A0A93 for ; Thu,  9 Jul 2020 17:44: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 yegRYBp4as96 for ; Thu,  9 Jul 2020 17:44: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 D69253A0A85 for ; Thu,  9 Jul 2020 17:44:31 -0700 (PDT)
Received: from [192.168.1.7] (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 06A0iStu001941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jul 2020 20:44:29 -0400
From: Justin Richer 
Message-Id: <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_57F9ED78-09D8-4713-B613-16E683F5E47D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 9 Jul 2020 20:44:28 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 10 Jul 2020 00:44:38 -0000

--Apple-Mail=_57F9ED78-09D8-4713-B613-16E683F5E47D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes, the core idea is to not have to parse an assertion to get back the =
core authentication information, which consists of an identifier =
(iss/sub pair in OIDC, but could be a number of things). Sometimes the =
client is going to want the rest of the identity information, but If the =
user=E2=80=99s logged into the client before, the client has likely =
cached that info and probably won=E2=80=99t need it, and sending it =
would be a violation of privacy principles.. The client would want the =
info pretty much just in these cases:

 1. The client has never seen the user before.=20
 2. The user=E2=80=99s information has been updated since the last time =
the client saw it.

Now for case (1), how would the client know if it wants to request the =
user=E2=80=99s profile info or not, since it doesn=E2=80=99t know who =
the user is? And the AS won=E2=80=99t know if client is going to want =
the profile info, since the AS won=E2=80=99t know if the client has the =
user=E2=80=99s info or not. Sure, the AS might have seen that client and =
that user combo previously, but it doesn=E2=80=99t know if the client =
needs an update.

And for (2), the client won=E2=80=99t know if the user=E2=80=99s info =
has been updated or not because it doesn=E2=80=99t know who the user is =
yet. If the AS can provide some time of updated stamp to the client, the =
client can pull the new info when it needs it.

If you ignore both of these cases and put all the user information =
inline with the main request/response, you end up in a situation where =
the client always requests everything and the server always provides =
everything, since you can=E2=80=99t be sure you=E2=80=99re not in =
situation (1) or (2) ahead of time.

This is really what I mean about the two-stage identity protocol. In the =
first stage, you push the bare minimum of what you need to get the user =
known to the client. In the second stage, the client uses its access =
token to call an API to get whatever else it needs to know about the =
user. This API could be an OIDC UserInfoEndpoint, a SCIM resource, a =
FHIR resource, or any number of other user APIs, and standardizing that =
information is not what GNAP should be focused on. OIDC does a really =
good job of letting developers log people in using this kind of =
protocol. While it=E2=80=99s possible to cram everything into an ID =
token on every request, there=E2=80=99s no need for it, and it=E2=80=99s =
likely a bad pattern to follow.

I=E2=80=99m sorry that you are surprised by my stance, but it hasn=E2=80=99=
t changed since I helped write the section of the charter that you =
quoted below. A big reason that I chose that wording was to support this =
use case but not to go in depth with an identity protocol, which I never =
really wanted us to do. However, it seems as soon as =E2=80=9Cidentity=E2=80=
=9D was brought up previously, people immediately jumped into talking =
about a full stack of user attributes and profile information. That =
wasn=E2=80=99t my intent in talking about identity, and I don=E2=80=99t =
think it=E2=80=99s something GNAP ought to do, at least not on its own.=20=


I do think there=E2=80=99s room for us to provide identifiers alongside =
the access token, so that=E2=80=99s there. There was stated interest in =
providing signed assertions as well, so I made sure that was enumerated =
for those who want to do such work. And I think it makes sense for us to =
provide a way to describe what kinds of things I want to get from an =
access token by defining a general purpose syntax for describing those =
things (notably, as a combination of reference strings and =
multi-dimensional objects). With these two, we can get most of what we =
need for a basic login system. Anything beyond that is going to need =
user profiles, authentication contexts, session control, and a lot of =
other identity-protocol stuff that GNAP shouldn=E2=80=99t be focusing =
on. We should keep it in mind as we build GNAP, but I think that like =
OIDC all that important extra stuff should be built separately. To me, =
that=E2=80=99s what not defining schemas and formats means.=20

I don=E2=80=99t see any conflict with the charter here, and I=E2=80=99m =
surprised that you do.

 =E2=80=94 Justin

> On Jul 9, 2020, at 5:55 PM, Dick Hardt  wrote:
>=20
> Thanks for the clarifications. I had chatted to Aaron about his post, =
and my understanding is not what is in the post on a closer read. My =
takeaway was why make the developer parse the ID_Token, why not give =
them the information directly.
>=20
> I have interpreted the userinfo and id_token top level elements to be =
how the client wanted the query results, not part of the query. I had =
thought my example and definition of a Grant Response in XAuth [1] would =
have clearly communicated what I meant, but I see that I should call out =
that userinfo in XAuth returns the claims, rather than userinfo in OIDC =
returns an access token for the claims. Given GNAP is more expressive, =
and learning from the past, I'm proposing we offer the developer (and =
AS) a choice in how to acquire the claims.
>=20
> While acquiring user information through an API at any time is =
appropriate in some use cases, in others why not give the client the =
info it needs right away rather than having to make another API call to =
get it? This would be appropriate when the user is making a purchase and =
wanting to provide shipping information. The user does not want to =
authorize the client to fetch their shipping address in the future.=20
>=20
> I'm surprised by your stance:=20
>=20
> My stance is that we allow the client to ask for a small set of =
identifiers about the user, or even just ask to =E2=80=9Cidentify the =
user=E2=80=9D, and leave everything else to a higher level identity =
protocol. I do not think that having an identity and profile =
query/response language at the core of GNAP is a good idea, and it=E2=80=99=
s certainly not in our charter.
>=20
> Since the charter states:
>=20
> The group is chartered to develop mechanisms for conveying identity =
information
> within the protocol including existing identifiers (such as email =
addresses,
> phone numbers, usernames, and subject identifiers) and assertions =
(such as
> OpenID Connect ID Tokens, SAML Assertions, and Verifiable =
Credentials). The
> group is not chartered to develop new formats for identifiers or =
assertions,
> nor is the group chartered to develop schemas for user information, =
profiles,
> or other identity attributes.
>=20
> More than identifiers about the user are clearly in scope of the WG =
charter, as are mechanisms for conveying identity information. Your =
stance and the charter look in conflict to me. What am I missing?
>=20
> /Dick
>=20
> [1] =
https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-4.1 =

>=20
>=20
>=20
> On Thu, Jul 9, 2020 at 1:04 PM Justin Richer > wrote:
> In Aaron=E2=80=99s post he doesn=E2=80=99t talk about how the request =
would be made, just what the response could look like, and we are =
talking about how to request that. Aaron=E2=80=99s post specifically =
calls out that this is just an identifier for the user and states:
>=20
> If the application needs to know profile information about the user, =
it can get that from the userinfo endpoint using the access token it =
just obtained.
>=20
> And I think that=E2=80=99s a good design pattern to follow. This =
isn=E2=80=99t =E2=80=9Cuserinfo=E2=80=9D being returned alongside the =
access token.=20
>=20
> The top level functionality of the OIDC claims query language is this:
>=20
>=20
> The top-level members of the Claims request JSON object are:
>=20
> userinfo
> OPTIONAL. Requests that the listed individual Claims be returned from =
the UserInfo Endpoint. If present, the listed Claims are being requested =
to be added to any Claims that are being requested using scope values. =
If not present, the Claims being requested from the UserInfo Endpoint =
are only those requested using scope values.
> When the userinfo member is used, the request MUST also use a =
response_type value that results in an Access Token being issued to the =
Client for use at the UserInfo Endpoint.
>=20
> id_token
> OPTIONAL. Requests that the listed individual Claims be returned in =
the ID Token. If present, the listed Claims are being requested to be =
added to the default Claims in the ID Token. If not present, the default =
ID Token Claims are requested, as per the ID Token definition in Section =
2 and per the additional per-flow ID Token requirements in Sections =
3.1.3.6, 3.2.2.10, 3.3.2.11, and 3.3.3.6.
>=20
> Since you had re-used the =E2=80=9Cuserinfo=E2=80=9D and =
=E2=80=9Cid_token=E2=80=9D top-level claims, I had assumed that they =
meant the same thing as in the OIDC spec. It=E2=80=99s clear to me, now, =
that this isn=E2=80=99t what you meant, but this is why I=E2=80=99m =
saying you=E2=80=99re not using the whole query language.=20
>=20
> There are proposed extensions to the OIDC claims query that would put =
returned data into a different place[1], and so it would be possible to =
use the claims structures to handle this. But at that point if the goal =
is just to use the internal query format, then I think that we can do =
better using =E2=80=A6 polymorphic JSON. :)
>=20
> My stance is that we allow the client to ask for a small set of =
identifiers about the user, or even just ask to =E2=80=9Cidentify the =
user=E2=80=9D, and leave everything else to a higher level identity =
protocol. I do not think that having an identity and profile =
query/response language at the core of GNAP is a good idea, and it=E2=80=99=
s certainly not in our charter.
>=20
>  =E2=80=94 Justin
>=20
> [1] https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ =
 =
defines a =E2=80=9Ccredential=E2=80=99 target.
>=20
>> On Jul 9, 2020, at 3:29 PM, Dick Hardt > wrote:
>>=20
>> Yes. Which is why I referred to Aaron's post originally which calls =
out for returning plain text claims.
>>=20
>> I don't really understand what you mean by "OIDC claims query =
language". The claims mean the same thing. And I was also reusing the =
modifiers such as {"essential": true}. What top level functionality are =
you referring to?
>>=20
>> On Thu, Jul 9, 2020 at 12:21 PM Justin Richer > wrote:
>> Ah, so you=E2=80=99re saying that the =E2=80=9Cuserinfo=E2=80=9D =
claims would be returned directly? I didn=E2=80=99t realize that you had =
intended to change how the OIDC claims query language functioned in your =
examples, and had assumed it would work the same was as the spec you =
were referencing. Your example of splitting it up makes that more clear. =
Though I would argue at that point, you=E2=80=99re creating a new query =
language since you=E2=80=99re not using the top-level functionality from =
ODIC=E2=80=99s definition.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 9, 2020, at 3:15 PM, Dick Hardt > wrote:
>>>=20
>>> You are jumping to many conclusions below. Let me break down the =
proposal into some bite size chunks.
>>>=20
>>> The developer would like to get some plain text OIDC claims about =
the user:
>>>=20
>>>     "claims":{
>>>         "oidc": {
>>>             "userinfo" : {
>>>                 "name" : { "essential" : true },
>>>                 "photo" : { "essential" : false }
>>>             },
>>>=20
>>> The developer would like to get an OIDC ID Token:
>>>=20
>>>     "claims":{
>>>         "oidc": {
>>>             "id_token" : {
>>>                 "email"          : { "essential" : true },
>>>                 "email_verified" : { "essential" : true }
>>>             }
>>>     }
>>>=20
>>> The developer would like to get an access token to acquire OIDC =
claims:
>>>=20
>>> "authorizations": {
>>>         "type":"oidc",
>>>         "claims": ["name", "picture"]
>>>     }
>>>=20
>>> The developer would like to get an access token to access photos:
>>>=20
>>> "authorizations": {
>>>         "type":"oauth_scope",
>>>         "scope": "read_photos"*
>>>     }
>>>=20
>>> The developer would like to get some VC claims:
>>>=20
>>> "claims" {
>>>         "vc": {
>>>             "some_vc": "query_mechanism"
>>>         }
>>> }
>>>=20
>>> The developer would like to do all of the above at once:
>>>=20
>>> {
>>>     "authorizations": {
>>>         "userinfo": {
>>>             "type":"oidc",
>>>             "claims": ["name", "picture"]
>>>         },
>>>         "photos": {
>>>             "type":"oauth_scope",
>>>             "scope": "read_photos"
>>>         }
>>>     },
>>>     "claims":{
>>>         "oidc": {
>>>             "id_token" : {
>>>                 "email"          : { "essential" : true },
>>>                 "email_verified" : { "essential" : true }
>>>             },
>>>             "userinfo" : {
>>>                 "name" : { "essential" : true },
>>>                 "photo" : { "essential" : false }
>>>             }
>>>         },
>>>     "vc": {
>>>         "some_vc": "query_mechanism"
>>>         }  =20
>>>     }
>>> }
>>>=20
>>> In the results, the developer gets claims back in the response =
claims object, and access tokens etc. back in the authorizations object. =
Just because an access token returns claims, it is still an access =
token.
>>>=20
>>> Yes, the developer can't get a single access token that can both =
acquire OIDC claims, and access photos (there are separate tokens for =
each), but I would argue that separating the access is a positive =
security property, as a client component accessing the user profile has =
a token independent of the client component accessing photos. And at the =
AS, there is no requirement for the userinfo endpoint to take the same =
token as the photo endpoint.
>>>=20
>>> Somewhat of a tangent, I'm thinking that=20
>>>=20
>>>     "claims":{
>>>         "oidc": {
>>>             "id_token" : {},
>>>             "userinfo" : {}
>>>         },
>>>=20
>>> is a little verbose, and:
>>>=20
>>>     "claims":{
>>>         "oidc_token": {},
>>>         "oidc_info": {}
>>>     },
>>>=20
>>> works better and makes it easier to distinguish support for ID =
tokens vs plain claims.
>>>=20
>>> wrt. my position on reusing OIDC -- it has not changed. I have =
viewed the OIDC claims as the "query language". No need to reinvent =
that. We are creating a new protocol, so no need to use the OAuth or =
OIDC protocols.
>>>=20
>>> * OAuth scopes could be a space separates string to be consistent =
with OAuth 2, or an array of strings so that it is more JSON like. I =
have no strong opinion.=20
>>>=20
>>> scope.split(' ').forEach()=20
>>>=20
>>> is not that much more complex than=20
>>>=20
>>> scope.forEach()
>>>=20
>>>=20
>>>=20
>>> On Thu, Jul 9, 2020 at 8:39 AM Justin Richer > wrote:
>>> But this approach doesn=E2=80=99t keep things in their respective =
containers =E2=80=94 you=E2=80=99ve explicitly got =E2=80=9Cclaims=E2=80=9D=
 underneath the =E2=80=9Cauthorizations=E2=80=9D header, and you=E2=80=99v=
e got items that come back as rights associated with the access token =
(which should be =E2=80=9Cauthorizations=E2=80=9D) in the =E2=80=9Cuserinf=
o=E2=80=9D section under the =E2=80=9Cclaims=E2=80=9D header. And as far =
as I can tell, these two sections are redundant to each other. =
Everything is everywhere.=20
>>>=20
>>> Additionally, this approach and syntax makes it difficult to combine =
different kinds of requests into one. One of OpenID Connect=E2=80=99s =
biggest draws, as I=E2=80=99m sure you recall, is that it could be =
combined with a request for non-OIDC resources. This was the real =
innovation that Twitter and Facebook=E2=80=99s identity APIs brought, =
access to more than just authentication, and what Google had tried to =
replicate with the awkward OpenID 2 + OAuth 1 hybrid system. Taking a =
step back from the existing solutions of OpenID 2 and OAuth 1 let us, as =
the community, see the value in the pattern that became OIDC on top of =
OAuth 2.=20
>>>=20
>>> Sure, you could say that the =E2=80=9Coidc=E2=80=9D type also can =
allow a =E2=80=9Cscopes=E2=80=9D parameter, but what about a RAR style =
object, then? And what about when someone comes up with some new way to =
request access rights, or a VC-based query language? Does every =
=E2=80=9Ctype=E2=80=9D need to now know about every other =E2=80=9Ctype=E2=
=80=9D in order for an AS to be able to figure out how they go together? =
This seems like the protocol definition limiting what combinations the =
AS can handle, or what an RS might want to use.
>>>=20
>>> My stance is that GNAP should have a way to query for rights in the =
access token (=E2=80=9Cauthorizations=E2=80=9D in xauth parlance) and =
identifiers for the user (=E2=80=9Cclaims=E2=80=9D in xauth parlance), =
and anything else should be an extension with potentially different =
models. The AS would process the =E2=80=9Cauthorizations=E2=80=9D =
equivalent (for the access token) alongside any other incoming query and =
then make a policy decision based on that.
>>>=20
>>> I find it interesting that you are now saying we don=E2=80=99t need =
to use the OIDC request format when previously you=E2=80=99ve made it =
clear that you were in favor of pointing at external query languages, =
including their syntax. I=E2=80=99m glad to see that you=E2=80=99re now =
looking at things in a more flexible way, but I think it=E2=80=99s =
important that we be careful and conscientious about how we reference =
any external query languages in GNAP.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>> On Jul 8, 2020, at 6:55 PM, Dick Hardt > wrote:
>>>>=20
>>>> Hey Justin,
>>>>=20
>>>> Just because we are using OIDC claims, does not mean we need to =
mimic the OIDC request and response.
>>>> I was envisioning a grant request could look as the following =
(using XAuth syntax):
>>>>=20
>>>> {
>>>>     "authorizations": {
>>>>         "type":"oidc",
>>>>         "claims": ["name", "picture"]
>>>>     },
>>>>     "claims":{
>>>>         "oidc": {
>>>>             "id_token" : {
>>>>                 "email"          : { "essential" : true },
>>>>                 "email_verified" : { "essential" : true }
>>>>             },
>>>>             "userinfo" : {
>>>>                 "name"           : { "essential" : true },
>>>>                 "picture"        : null
>>>>             }
>>>>         }
>>>>     }
>>>> }
>>>>=20
>>>> Of course a developer could choose to only ask for a subset of =
this.
>>>>=20
>>>> Note the new authorization type of "oidc", that takes "claims" =
rather than "scope".=20
>>>>=20
>>>> This keeps all the authorizations and claims in their respective =
request and response containers.
>>>>=20
>>>> We had a thread months ago on the OIDC two stage model, and I still =
fail to see why forcing that has any advantage.=20
>>>>=20
>>>> /Dick
>>>>=20
>>>>=20
>>>> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer > wrote:
>>>> I=E2=80=99m glad that we can agree that there are a number of =
things in legacy protocols that are unfortunate side effects of the =
circumstances in which they were built. Space-separated scope strings, =
for instance, would fall in that category, as I=E2=80=99ve previously =
explained.
>>>>=20
>>>> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request =
already mixes user claims (returned in an API) and authorization (to =
fetch user claims from an API), so that ship has sailed if you=E2=80=99re =
using it. It doesn=E2=80=99t make sense to have it under a =E2=80=9Cclaims=
=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s =
a query language that affects both. Maybe you=E2=80=99d call this =
another =E2=80=9Cunfortunate design=E2=80=9D, but the context was about =
re-using an externally-defined query language that was not made for =
GNAP.
>>>>=20
>>>> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=
=9D and wants to keep using it. (The vast majority of OIDC =
implementations, in my experience, don=E2=80=99t use that feature, and =
it=E2=80=99s not even required to be implemented by the AS, but again =
we=E2=80=99re talking about using this feature as an example of an =
external query language =E2=80=94 and there are others out there.) In =
GNAP, you should return claims directly in the response, and request =
specific elements from the APIs protected by the access token. These are =
separate things, and by design both XAuth and XYZ have put them into =
separate containers in the request. This is a good design, and so =
putting something that conflates these two aspects into one or the other =
of the containers is not a particularly good option, in my opinion.=20
>>>>=20
>>>> Additionally, though this is a bit of an aside and getting into the =
specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is =
a query language bound to the full user profile. It is my stated =
position that the items coming back from the AS should only be =
identifiers, and not full profile information. The reasoning is pretty =
simple: the client doesn=E2=80=99t know what profile information it =
needs until it knows who the user is, so putting that into a protected =
API like the UserInfo Endpoint makes much more sense than putting it =
into the immediate response, where it is not needed, because the client =
already knows it. The AS doesn=E2=80=99t know what the client needs to =
know, either, so it can=E2=80=99t determine what to fulfill. OIDC=E2=80=99=
s two-stage model makes sense, and GNAP should really only focus on =
enabling this.
>>>>=20
>>>>  =E2=80=94 Justin
>>>>=20
>>>>> On Jul 8, 2020, at 6:10 PM, Dick Hardt > wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer > wrote:
>>>>> On Jul 8, 2020, at 3:16 PM, Dick Hardt > wrote:
>>>>>>=20
>>>>>> I think representing the request as an array is simplistic, and =
complicated at the same time.
>>>>>>=20
>>>>>> On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the request.=20=

>>>>>=20
>>>>> The elements of the array are taken as a set, to be tied to the =
same resulting access token. If one of those elements is defined, by the =
AS and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some =
or all of the other elements, then that=E2=80=99s up to the AS=E2=80=99s =
policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, which =
switches on all sorts of contextual stuff in the request. So to handle =
something like this, an AS can easily declare that a given scope-style =
string or a given object property applies to different parts of the =
request. You don=E2=80=99t need to externalize it here.
>>>>>=20
>>>>> I view the "openid" scope as an unfortunate design as OIDC was =
constrained by building on top of OAuth. (a problem I hoped to avert by =
having "identity" in scope for GNAP) The "openid" scope does not =
function as scope per se, and I think it makes OIDC harder to understand =
as the "openid" scope causes non-scope behavior.=20
>>>>>=20
>>>>> =20
>>>>>=20
>>>>> Do you have a concrete use case that requires that feature to be =
done in the way that you describe? I am trying to separate the driving =
use case from the proposed solutions to see what the differences are.=20
>>>>>=20
>>>>> Perhaps the client wants access to be HIPPA compliant? The HIPPA =
compliance signal applies to the scopes.
>>>>>=20
>>>>> Adding other properties to an object is a well understood =
extension mechanism. Adding an additional element to an array that does =
not act like the other elements seems like a hack.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>>=20
>>>>>> Using JSON type polymorphism requires the AS to test each member =
of the array to determine if it is a string or an object. Only after =
detecting a RAR object does the AS know the client is making a RAR =
request.=20
>>>>>=20
>>>>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the =
whole resources request in order to figure out what the client is asking =
for, anyway, whether it=E2=80=99s by strings or objects or whatever else =
might be defined by an extension. Is there an argument for having an AS =
do an early dispatch on a request before it=E2=80=99s fully parsed =
everything?
>>>>>=20
>>>>> Let me clarify, the code is looking at the type of object that has =
been parsed.=20
>>>>>=20
>>>>> Determining if an item in an array is a scope or a RAR object by =
looking at the type being either a string or an object seems less clear =
than a property of an object explicitly declaring the type.
>>>>>=20
>>>>> =20
>>>>>=20
>>>>>> This also limits the request to be composed only of scope strings =
or RAR objects. I don't see how other strings or objects could be used =
in the array, so there is no clear extension point in the "resources" =
array for other query mechanisms.
>>>>>=20
>>>>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t =
declaring that a string has to be an OAuth2-style scope. It can be, but =
ultimately it=E2=80=99s just a string that the AS can understand. And =
the objects are just that =E2=80=94 objects. If the AS understands what =
the object is, it can be a RAR object or it can be something completely =
API-specific with another query language entirely.
>>>>>=20
>>>>> But the other query language would need a type that has been =
reserved in the RAR name space for there to be interop, so it =
effectively is a RAR extension.
>>>>>=20
>>>>> There are query languages in other domains that may not fit nicely =
into RAR such as a query for medical records.
>>>>>=20
>>>>> Yes, the medical records could be yet another top level property, =
but per below, I think that is confusing.
>>>>> =20
>>>>> (Point, though: RAR already pretty much allows this by letting =
them be extended infinitely, a feature it inherits from XYZ)
>>>>>=20
>>>>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99=
s an array of strings or objects and each of those means the same thing, =
=E2=80=9Csomething the client is asking for=E2=80=9D.
>>>>>=20
>>>>>>=20
>>>>>> Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.
>>>>>>=20
>>>>>=20
>>>>> It=E2=80=99s my stance that this is an unnecessary limitation at =
this level. The objects within the array should be typed, like RAR, but =
it doesn=E2=80=99t make sense for the overall request to be typed. =
Instead, there should be one =E2=80=9Ctype" of query in the core, what =
XYZ calls the =E2=80=9Cresources=E2=80=9D request. Other query languages =
should be added as extensions either to the RAR-style objects (by =
defining a type at that level) or as a separate top-level member.
>>>>>=20
>>>>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D =
query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.
>>>>>=20
>>>>> To me, this remains much more understandable, extensible, and =
clean.
>>>>>=20
>>>>> While this may be more understandable to a developer just porting =
an app OIDC that only wants OIDC results, but I think it is more =
complicated as soon as the developer wants other results, which is =
likely what prompted the developer to use GNAP instead of ODIC.
>>>>>=20
>>>>> I think it is easier to understand if all the claims are in one =
container, and all the authorizations are in another container.
>>>>>=20
>>>>> If a developer wants access to some resources, some claims, and an =
OpenID Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread across =
multiple containers. There are some claims in the "claims" container, =
and some "claims" in the "oidc_claims_query" container. And is the =
access token response in "oidc_claims_query" the same as an access token =
response in "resources"? It would seem simpler if they were, and if all =
the access tokens came back in the same container.
>>>>>=20
>>>>> Per Aaron's post that you have referred to, the developer can get =
sme bare claims directly in the response in the "claims" object, an ID =
Token that has the same or different claims, and if they want, an access =
token that they can call a user_info endpoint to get the same, or =
different claims.
>>>>>=20
>>>>> For example, an enterprise app client may want an ID Token with =
the email address, bare claims for the user's name and a URI to a =
profile photo, and an access token to query which groups a user belongs =
to.
>>>>>=20
>>>>> We are still re-using the OIDC claims, but we are not mixing =
claims and authorizations.
>>>>>=20
>>>>> /Dick
>>>>>=20
>>>>>=20
>>>>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz =

>>>>> =E1=90=A7
>>>>=20
>>>> =E1=90=A7
>>>=20
>>> =E1=90=A7
>>=20
>> =E1=90=A7
>=20


--Apple-Mail=_57F9ED78-09D8-4713-B613-16E683F5E47D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes, =
the core idea is to not have to parse an assertion to get back the core =
authentication information, which consists of an identifier (iss/sub =
pair in OIDC, but could be a number of things). Sometimes the client is =
going to want the rest of the identity information, but If the =
user=E2=80=99s logged into the client before, the client has likely =
cached that info and probably won=E2=80=99t need it, and sending it =
would be a violation of privacy principles.. The client would want the =
info pretty much just in these cases:

 1. The client has never seen the =
user before. 
 2. The user=E2=80=99s =
information has been updated since the last time the client saw =
it.

Now for =
case (1), how would the client know if it wants to request the user=E2=80=99=
s profile info or not, since it doesn=E2=80=99t know who the user is? =
And the AS won=E2=80=99t know if client is going to want the profile =
info, since the AS won=E2=80=99t know if the client has the user=E2=80=99s=
 info or not. Sure, the AS might have seen that client and that user =
combo previously, but it doesn=E2=80=99t know if the client needs an =
update.

And =
for (2), the client won=E2=80=99t know if the user=E2=80=99s info has =
been updated or not because it doesn=E2=80=99t know who the user is yet. =
If the AS can provide some time of updated stamp to the client, the =
client can pull the new info when it needs it.

If you ignore both of these cases and =
put all the user information inline with the main request/response, you =
end up in a situation where the client always requests everything and =
the server always provides everything, since you can=E2=80=99t be sure =
you=E2=80=99re not in situation (1) or (2) ahead of time.

This is really what I =
mean about the two-stage identity protocol. In the first stage, you push =
the bare minimum of what you need to get the user known to the client. =
In the second stage, the client uses its access token to call an API to =
get whatever else it needs to know about the user. This API could be an =
OIDC UserInfoEndpoint, a SCIM resource, a FHIR resource, or any number =
of other user APIs, and standardizing that information is not what GNAP =
should be focused on. OIDC does a really good job of letting developers =
log people in using this kind of protocol. While it=E2=80=99s possible =
to cram everything into an ID token on every request, there=E2=80=99s no =
need for it, and it=E2=80=99s likely a bad pattern to follow.

I=E2=80=99m sorry that you are surprised by my stance, but it =
hasn=E2=80=99t changed since I helped write the section of the charter =
that you quoted below. A big reason that I chose that wording was to =
support this use case but not to go in depth with an identity protocol, =
which I never really wanted us to do. However, it seems as soon as =
=E2=80=9Cidentity=E2=80=9D was brought up previously, people immediately =
jumped into talking about a full stack of user attributes and profile =
information. That wasn=E2=80=99t my intent in talking about identity, =
and I don=E2=80=99t think it=E2=80=99s something GNAP ought to do, at =
least not on its own. 

I do think there=E2=80=99s room for us to provide =
identifiers alongside the access token, so that=E2=80=99s there. There =
was stated interest in providing signed assertions as well, so I made =
sure that was enumerated for those who want to do such work. And I think =
it makes sense for us to provide a way to describe what kinds of things =
I want to get from an access token by defining a general purpose syntax =
for describing those things (notably, as a combination of reference =
strings and multi-dimensional objects). With these two, we can get most =
of what we need for a basic login system. Anything beyond that is going =
to need user profiles, authentication contexts, session control, and a =
lot of other identity-protocol stuff that GNAP shouldn=E2=80=99t be =
focusing on. We should keep it in mind as we build GNAP, but I think =
that like OIDC all that important extra stuff should be built =
separately. To me, that=E2=80=99s what not defining schemas and formats =
means. 

I =
don=E2=80=99t see any conflict with the charter here, and I=E2=80=99m =
surprised that you do.

 =E2=80=94 Justin

On Jul =
9, 2020, at 5:55 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Thanks for the clarifications. I =
had chatted to Aaron about his post, and my understanding is not what is =
in the post on a closer read. My takeaway was why make the developer =
parse the ID_Token, why not give them the information directly.

I have interpreted the =
userinfo and id_token top level elements to be how the client wanted the =
query results, not part of the query. I had thought my example and =
definition of a Grant Response in XAuth [1] would have clearly =
communicated what I meant, but I see that I should call out that =
userinfo in XAuth returns the claims, rather than userinfo in OIDC =
returns an access token for the claims. Given GNAP is more expressive, =
and learning from the past, I'm proposing we offer the developer (and =
AS) a choice in how to acquire the claims.

While acquiring user =
information through an API at any time is appropriate in some use =
cases, in others why not give the client the info it needs right away =
rather than having to make another API call to get it? This would be =
appropriate when the user is making a purchase and wanting to provide =
shipping information. The user does not want to authorize the client to =
fetch their shipping address in the future. 
I'm surprised by your =
stance: 

My stance is that we allow the client to ask for a small set =
of identifiers about the user, or even just ask to =E2=80=9Cidentify the =
user=E2=80=9D, and leave everything else to a higher level identity =
protocol. I do not think that having an identity and profile =
query/response language at the core of GNAP is a good idea, and it=E2=80=99=
s certainly not in our charter.

Since =
the charter states:

The group is chartered to develop =
mechanisms for conveying identity information
within =
the protocol including existing identifiers (such as email =
addresses,
phone numbers, usernames, and subject =
identifiers) and assertions (such as
OpenID Connect =
ID Tokens, SAML Assertions, and Verifiable Credentials). The
group is not chartered to develop new formats for identifiers =
or assertions,
nor is the group chartered to =
develop schemas for user information, profiles,
or =
other identity =
attributes.

More than identifiers about the user are clearly in scope of =
the WG charter, as are mechanisms for conveying identity information. =
Your stance and the charter look in conflict to me. What am I =
missing?

/Dick

[1] https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#secti=
on-4.1



On Thu, Jul =
9, 2020 at 1:04 PM Justin Richer <jricher@mit.edu> wrote:
In Aaron=E2=80=99s post he doesn=E2=80=99t talk =
about how the request would be made, just what the response could look =
like, and we are talking about how to request that. Aaron=E2=80=99s post =
specifically calls out that this is just an identifier for the user and =
states:

If the application needs to know profile information about =
the user, it can get that from the userinfo endpoint using the =
access token it just obtained.

And I think that=E2=80=99s a good =
design pattern to follow. This isn=E2=80=99t =E2=80=9Cuserinfo=E2=80=9D =
being returned alongside the access token. 

The top level functionality of the OIDC =
claims query language is this:


The top-level members of the Claims request JSON object =
are:

userinfo
OPTIONAL. Requests that =
the listed individual Claims be returned from =
the UserInfo Endpoint. If present, the listed Claims are =
being requested to be added to any Claims that are being =
requested using scope values. If not present, the =
Claims being requested from the UserInfo Endpoint are =
only those requested using scope values.
When the userinfo member is used, the request =
MUST also use a response_type value that results in an Access Token being issued to the Client for use at =
the UserInfo Endpoint.

id_token
OPTIONAL. Requests that =
the listed individual Claims be returned in the =
ID Token. If present, the listed Claims are being requested to =
be added to the default Claims in the ID Token. If not =
present, the default ID Token Claims are requested, as per the =
ID Token definition in Section 2 and per the additional =
per-flow ID Token requirements in =
Sections 3.1.3.6, 3.2.2.10, 3.3.2.11, and 3.3.3.6=
.

Since you had re-used the =
=E2=80=9Cuserinfo=E2=80=9D and =E2=80=9Cid_token=E2=80=9D top-level =
claims, I had assumed that they meant the same thing as in the OIDC =
spec. It=E2=80=99s clear to me, now, that this isn=E2=80=99t what you =
meant, but this is why I=E2=80=99m saying you=E2=80=99re not using the =
whole query language. 

There are proposed extensions to the OIDC claims query that =
would put returned data into a different place[1], and so it would be =
possible to use the claims structures to handle this. But at that point =
if the goal is just to use the internal query format, then I think that =
we can do better using =E2=80=A6 polymorphic JSON. :)

My stance is that we =
allow the client to ask for a small set of identifiers about the user, =
or even just ask to =E2=80=9Cidentify the user=E2=80=9D, and leave =
everything else to a higher level identity protocol. I do not think that =
having an identity and profile query/response language at the core of =
GNAP is a good idea, and it=E2=80=99s certainly not in our =
charter.

 =E2=80=94 Justin

[1] https://mattrglobal.github.io/oidc-client-bound-assertions-spec=
/ defines a =E2=80=9Ccredential=E2=80=99 target.

On Jul 9, 2020, at 3:29 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Yes. Which is why =
I referred to Aaron's post originally which calls out for returning =
plain text claims.

I don't really understand what you mean by "OIDC claims query =
language". The claims mean the same thing. And I was also reusing the =
modifiers such as {"essential": true}. What top level functionality =
are you referring to?

On Thu, Jul =
9, 2020 at 12:21 PM Justin Richer <jricher@mit.edu> wrote:
Ah, so you=E2=80=99re =
saying that the =E2=80=9Cuserinfo=E2=80=9D claims would be returned =
directly? I didn=E2=80=99t realize that you had intended to change how =
the OIDC claims query language functioned in your examples, and had =
assumed it would work the same was as the spec you were referencing. =
Your example of splitting it up makes that more clear. Though I would =
argue at that point, you=E2=80=99re creating a new query language since =
you=E2=80=99re not using the top-level functionality from ODIC=E2=80=99s =
definition.

 =E2=80=
=94 Justin

On Jul 9, 2020, at 3:15 PM, =
Dick Hardt <dick.hardt@gmail.com> wrote:

You are jumping to many =
conclusions below. Let me break down the proposal into some bite size =
chunks.

The =
developer would like to get some plain text OIDC claims about the =
user:

  =
  "claims":{
        "oidc": {
            "userinfo" : {
                =
"name" : { "essential" : true },
      =
          "photo" : { "essential" : false }
            },

The =
developer would like to get an OIDC ID Token:

    "claims":{
        "oidc": {
  =
          "id_token" : {
  =
              "email"     =
     : { "essential" : true },
  =
              "email_verified" : { =
"essential" : true }
          =
  }
    }

The developer would like =
to get an access token to acquire OIDC claims:

"authorizations": {
        =
"type":"oidc",
        "claims": =
["name", "picture"]
    }

The developer would like to get an =
access token to access photos:

"authorizations": {
        =
"type":"oauth_scope",
        "scope": =
"read_photos"*
    }

The developer would like to get some VC =
claims:

"claims"=
 {
        "vc": {
          =
  "some_vc": "query_mechanism"
      =
  }
}

The developer would like to do all of =
the above at once:

{
    "authorizations": {
        "userinfo": {
  =
          "type":"oidc",
  =
          "claims": ["name", "picture"]
        },
    =
    "photos": {
        =
    "type":"oauth_scope",
      =
      "scope": "read_photos"
    =
    }
    },
  =
  "claims":{
        "oidc": {
            "id_token" : {
                =
"email"          : { "essential" : true },
                =
"email_verified" : { "essential" : true }
    =
        },
        =
    "userinfo" : {
        =
        "name" : { "essential" : true },
                =
"photo" : { "essential" : false }
      =
      }
        },
    "vc": {
      =
  "some_vc": "query_mechanism"
      =
  }   
  =
  }
}

In the results, the developer gets =
claims back in the response claims object, and access tokens etc. back =
in the authorizations object. Just because an access token returns =
claims, it is still an access token.

Yes, the developer can't get a =
single access token that can both acquire OIDC claims, and access photos =
(there are separate tokens for each), but I would argue that separating =
the access is a positive security property, as a client component =
accessing the user profile has a token independent of the client =
component accessing photos. And at the AS, there is no requirement for =
the userinfo endpoint to take the same token as the photo =
endpoint.

Somewhat of a tangent, I'm thinking that 

    =
"claims":{
        "oidc": {
            "id_token" : {},
            "userinfo" : {}
        },

is =
a little verbose, and:

    =
"claims":{
        "oidc_token": =
{},
        "oidc_info": {}
    },

works better and makes it easier to =
distinguish support for ID tokens vs plain claims.

wrt. my position on =
reusing OIDC -- it has not changed. I have viewed the OIDC claims as the =
"query language". No need to reinvent that. We are creating a new =
protocol, so no need to use the OAuth or OIDC protocols.

* OAuth =
scopes could be a space separates string to be consistent with OAuth 2, =
or an array of strings so that it is more JSON like. I have no strong =
opinion. 

scope.split(' ').forEach() 

is not that much more complex =
than 

scope.forEach()



On Thu, Jul =
9, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wrote:
But =
this approach doesn=E2=80=99t keep things in their respective containers =
=E2=80=94 you=E2=80=99ve explicitly got =E2=80=9Cclaims=E2=80=9D =
underneath the =E2=80=9Cauthorizations=E2=80=9D header, and you=E2=80=99ve=
 got items that come back as rights associated with the access token =
(which should be =E2=80=9Cauthorizations=E2=80=9D) in the =E2=80=9Cuserinf=
o=E2=80=9D section under the =E2=80=9Cclaims=E2=80=9D header. And as far =
as I can tell, these two sections are redundant to each other. =
Everything is everywhere. 

Additionally, this approach and syntax =
makes it difficult to combine different kinds of requests into one. One =
of OpenID Connect=E2=80=99s biggest draws, as I=E2=80=99m sure you =
recall, is that it could be combined with a request for non-OIDC =
resources. This was the real innovation that Twitter and Facebook=E2=80=99=
s identity APIs brought, access to more than just authentication, and =
what Google had tried to replicate with the awkward OpenID 2 + OAuth 1 =
hybrid system. Taking a step back from the existing solutions of OpenID =
2 and OAuth 1 let us, as the community, see the value in the pattern =
that became OIDC on top of OAuth 2. 

Sure, you could say that the =E2=80=9Coid=
c=E2=80=9D type also can allow a =E2=80=9Cscopes=E2=80=9D parameter, but =
what about a RAR style object, then? And what about when someone comes =
up with some new way to request access rights, or a VC-based query =
language? Does every =E2=80=9Ctype=E2=80=9D need to now know about every =
other =E2=80=9Ctype=E2=80=9D in order for an AS to be able to figure out =
how they go together? This seems like the protocol definition limiting =
what combinations the AS can handle, or what an RS might want to =
use.

My stance =
is that GNAP should have a way to query for rights in the access token =
(=E2=80=9Cauthorizations=E2=80=9D in xauth parlance) and identifiers for =
the user (=E2=80=9Cclaims=E2=80=9D in xauth parlance), and anything else =
should be an extension with potentially different models. The AS would =
process the =E2=80=9Cauthorizations=E2=80=9D equivalent (for the access =
token) alongside any other incoming query and then make a policy =
decision based on that.

I find it interesting that you are now saying we don=E2=80=99t =
need to use the OIDC request format when previously you=E2=80=99ve made =
it clear that you were in favor of pointing at external query languages, =
including their syntax. I=E2=80=99m glad to see that you=E2=80=99re now =
looking at things in a more flexible way, but I think it=E2=80=99s =
important that we be careful and conscientious about how we reference =
any external query languages in GNAP.

 =E2=80=94 Justin

On Jul 8, 2020, at 6:55 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey =
Justin,

Just =
because we are using OIDC claims, does not mean we need to mimic =
the OIDC request and response.
I was envisioning a =
grant request could look as the following (using XAuth syntax):

{
    "authorizations": {
    =
    "type":"oidc",
        =
"claims": ["name", "picture"]
    },
    "claims":{
      =
  "oidc": {
            =
"id_token" : {
            =
    "email"          : { "essential" =
: true },
              =
  "email_verified" : { "essential" : true }
  =
          },
      =
      "userinfo" : {
      =
          "name"         =
  : { "essential" : true },
      =
          "picture"       =
 : null
            =
}
        }
  =
  }
}

Of course a developer could choose to =
only ask for a subset of this.

Note the new authorization type of =
"oidc", that takes "claims" rather than "scope". 

This keeps all the =
authorizations and claims in their respective request and response =
containers.

We =
had a thread months ago on the OIDC two stage model, and I still fail to =
see why forcing that has any advantage. 

/Dick


On Wed, Jul 8, 2020 at 3:25 PM Justin =
Richer <jricher@mit.edu> wrote:
I=E2=80=99m =
glad that we can agree that there are a number of things in legacy =
protocols that are unfortunate side effects of the circumstances in =
which they were built. Space-separated scope strings, for instance, =
would fall in that category, as I=E2=80=99ve previously explained.

A key point in the =
below: the OIDC =E2=80=9Cclaims=E2=80=9D request already mixes user =
claims (returned in an API) and authorization (to fetch user claims from =
an API), so that ship has sailed if you=E2=80=99re using it. It =
doesn=E2=80=99t make sense to have it under a =E2=80=9Cclaims=E2=80=9D =
or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s a query =
language that affects both. Maybe you=E2=80=99d call this another =
=E2=80=9Cunfortunate design=E2=80=9D, but the context was about re-using =
an externally-defined query language that was not made for GNAP.

My scenario was for =
someone who is already using =E2=80=9Cclaims=E2=80=9D and wants to keep =
using it. (The vast majority of OIDC implementations, in my experience, =
don=E2=80=99t use that feature, and it=E2=80=99s not even required to be =
implemented by the AS, but again we=E2=80=99re talking about using this =
feature as an example of an external query language =E2=80=94 and there =
are others out there.) In GNAP, you should return claims directly in the =
response, and request specific elements from the APIs protected by the =
access token. These are separate things, and by design both XAuth and =
XYZ have put them into separate containers in the request. This is a =
good design, and so putting something that conflates these two aspects =
into one or the other of the containers is not a particularly good =
option, in my opinion. 

Additionally, though this is a bit of =
an aside and getting into the specifics of identity, the =E2=80=9Cclaims=E2=
=80=9D parameter of ODIC is a query language bound to the full user =
profile. It is my stated position that the items coming back from the AS =
should only be identifiers, and not full profile information. The =
reasoning is pretty simple: the client doesn=E2=80=99t know what profile =
information it needs until it knows who the user is, so putting that =
into a protected API like the UserInfo Endpoint makes much more sense =
than putting it into the immediate response, where it is not needed, =
because the client already knows it. The AS doesn=E2=80=99t know what =
the client needs to know, either, so it can=E2=80=99t determine what to =
fulfill. OIDC=E2=80=99s two-stage model makes sense, and GNAP should =
really only focus on enabling this.

 =E2=80=94 Justin

On Jul 8, 2020, at 6:10 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Wed, Jul =
8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at =
3:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I think representing the request as an array is simplistic, =
and complicated at the same time.

On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the =
request. 

The elements of the array are taken as =
a set, to be tied to the same resulting access token. If one of those =
elements is defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s =
protecting, to apply across some or all of the other elements, then =
that=E2=80=99s up to the AS=E2=80=99s policy. Much like the =E2=80=9Copeni=
d=E2=80=9D scope in OIDC, which switches on all sorts of contextual =
stuff in the request. So to handle something like this, an AS can easily =
declare that a given scope-style string or a given object property =
applies to different parts of the request. You don=E2=80=99t need to =
externalize it here.

I view the "openid" scope as an =
unfortunate design as OIDC was constrained by building on top of =
OAuth. (a problem I hoped to avert by having "identity" in scope for =
GNAP) The "openid" scope does not function as scope per se, and I =
think it makes OIDC harder to understand as the "openid" scope causes =
non-scope behavior. 

 

Do you have a concrete =
use case that requires that feature to be done in the way that you =
describe? I am trying to separate the driving use case from the proposed =
solutions to see what the differences =
are. 

Perhaps the client wants access to be =
HIPPA compliant? The HIPPA compliance signal applies to the =
scopes.

Adding =
other properties to an object is a well understood extension mechanism. =
Adding an additional element to an array that does not act like the =
other elements seems like a hack.

 


Using =
JSON type polymorphism requires the AS to test each member of the =
array to determine if it is a string or an object. Only after detecting =
a RAR object does the AS know the client is making a RAR request. 

That=E2=80=99s correct =
=E2=80=94 but the AS needs to parse the whole resources request in order =
to figure out what the client is asking for, anyway, whether it=E2=80=99s =
by strings or objects or whatever else might be defined by an extension. =
Is there an argument for having an AS do an early dispatch on a request =
before it=E2=80=99s fully parsed =
everything?

Let me clarify, the code is looking at =
the type of object that has been parsed. 

Determining if an item in an array is a =
scope or a RAR object by looking at the type being either a string or an =
object seems less clear than a property of an object explicitly =
declaring the type.

 

This =
also limits the request to be composed only of scope strings or RAR =
objects. I don't see how other strings or objects could be used in the =
array, so there is no clear extension point in the "resources" array for =
other query mechanisms.

That=E2=80=99s not the =
case in XYZ since we aren=E2=80=99t declaring that a string has to be an =
OAuth2-style scope. It can be, but ultimately it=E2=80=99s just a string =
that the AS can understand. And the objects are just that =E2=80=94 =
objects. If the AS understands what the object is, it can be a RAR =
object or it can be something completely API-specific with another query =
language entirely.

But the other query language would need =
a type that has been reserved in the RAR name space for there to be =
interop, so it effectively is a RAR extension.

There are query languages in other =
domains that may not fit nicely into RAR such as a query for medical =
records.

Yes, =
the medical records could be yet another top level property, but per =
below, I think that is confusing.
 
(Point, though: RAR already pretty much allows this by =
letting them be extended infinitely, a feature it inherits from =
XYZ)

I=E2=80=99m=
 proposing that we do the same thing with GNAP: it=E2=80=99s an array of =
strings or objects and each of those means the same thing, =E2=80=9Csometh=
ing the client is asking for=E2=80=9D.


Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.


It=E2=80=99s my stance that this is an =
unnecessary limitation at this level. The objects within the array =
should be typed, like RAR, but it doesn=E2=80=99t make sense for the =
overall request to be typed. Instead, there should be one =E2=80=9Ctype" =
of query in the core, what XYZ calls the =E2=80=9Cresources=E2=80=9D =
request. Other query languages should be added as extensions either to =
the RAR-style objects (by defining a type at that level) or as a =
separate top-level member.

For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D=
 query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.

To me, this remains much =
more understandable, extensible, and =
clean.

While this may be more understandable =
to a developer just porting an app OIDC that only wants OIDC =
results, but I think it is more complicated as soon as the developer =
wants other results, which is likely what prompted the developer to =
use GNAP instead of ODIC.

I think it is easier to understand if all the claims are in =
one container, and all the authorizations are in another =
container.

If =
a developer wants access to some resources, some claims, and an OpenID =
Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread =
across multiple containers. There are some claims in the "claims" =
container, and some "claims" in the "oidc_claims_query" container. And =
is the access token response in "oidc_claims_query" the same as an =
access token response in "resources"? It would seem simpler if they =
were, and if all the access tokens came back in the same =
container.

Per =
Aaron's post that you have referred to, the developer can get sme bare =
claims directly in the response in the "claims" object, an ID Token that =
has the same or different claims, and if they want, an access token that =
they can call a user_info endpoint to get the same, or different =
claims.

For =
example, an enterprise app client may want an ID Token with the email =
address, bare claims for the user's name and a URI to a profile photo, =
and an access token to query which groups a user belongs to.

We are still =
re-using the OIDC claims, but we are not mixing claims and =
authorizations.

/Dick


[1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
3D""=E1=90=A7

3D""=E1=90=A7

3D""=E1=90=A7

3D""=E1=90=A7





=

--Apple-Mail=_57F9ED78-09D8-4713-B613-16E683F5E47D--


From nobody Thu Jul  9 17:46: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 ED0073A09F3 for ; Thu,  9 Jul 2020 17:46:44 -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 4POgfiwi87vb for ; Thu,  9 Jul 2020 17:46:40 -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 C7EF53A09F2 for ; Thu,  9 Jul 2020 17:46:39 -0700 (PDT)
Received: from [192.168.1.7] (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 06A0ka7a003115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jul 2020 20:46:37 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_73758EB5-19BD-464D-8860-F312D367F9EB"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 9 Jul 2020 20:46:36 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>     <69082870-1A99-4912-95EA-D1B7A1C967E5@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 10 Jul 2020 00:46:45 -0000

--Apple-Mail=_73758EB5-19BD-464D-8860-F312D367F9EB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Jul 9, 2020, at 6:50 PM, Dick Hardt  wrote:
>=20
>=20
>=20
> On Thu, Jul 9, 2020 at 12:17 PM Justin Richer > wrote:
> On Jul 9, 2020, at 2:32 PM, Dick Hardt > wrote:
>>=20
>> Looks like you missed the point of my code example, as your response =
is focussed on the aspects I had in comments, so let me clarify.=20
>=20
> The point seemed to be about the overall complexity and readability, =
and that=E2=80=99s what I responded to.
>=20
> It was about the complexity and readability -- of those specific lines =
of code.

But it=E2=80=99s not just about those lines, it=E2=80=99s about the =
context that those lines are in and the follow-on code paths that they =
cause. A lot of what you had =E2=80=9Cin comments=E2=80=9D for the XAuth =
example would have repeated what was already included in the XYZ =
example, as I pointed out.

>=20
> I've used JS type polymorphism to provide a cleaner API. For example, =
making an HTTP request. If I'm good with all the defaults, I can just =
provide the URI as a string, if I want to change a default, I provide an =
object and the URI is now a property of the object. Polymorphism allows =
the caller to have a simpler interface when it is a simple operation.
>=20
> Do you have any examples of JSON polymorphism used in other protocols =
besides in a JWT?

Sounds to me like you=E2=80=99re describing exactly the kind of =
polymorphism that I=E2=80=99m talking about here. Use a string where it =
makes sense and an object where it makes sense, and there=E2=80=99s no =
ambiguity in calling the function. As you say, it's all about providing =
a cleaner API for the caller, and making things consistent in the model =
that the caller and provider are using. It takes a little bit of extra =
effort on the part of the API provider, but that=E2=80=99s where the =
complexity cost should be paid.

> =20
>=20
>>=20
>> This line (which is determining the type of the item in the array):
>>=20
>> if (typeof item =3D=3D=3D string')
>>=20
>> is implicitly stating that the item is an oauth scope.=20
>=20
> No, it is not. It is saying that it is a resource request represented =
as a string. One way to represent a resource request as a string is an =
OAuth 2 style scope. And if you=E2=80=99re building up from an existing =
OAuth 2 system, then you could use a scope there. But that=E2=80=99s not =
the same as stating =E2=80=9Cthe item is a scope=E2=80=9D. In my =
examples, I had been trying to use the terminology that you were using, =
but I=E2=80=99m afraid that made things more unclear.
>=20
> We are comparing how to do it in XYZ vs XAuth -- so to make it apples =
and apples, the string is a scope, since that is the use case we are =
looking at.

You can use a scope as the string, and if you want to think of all =
string values in this request as all being =E2=80=9Cscopes", that=E2=80=99=
s fine, but only if you can concede that the scope can mean whatever the =
AS wants. I think that perhaps you=E2=80=99re putting a certain amount =
of semantic weight to =E2=80=9Cscope=E2=80=9D that I=E2=80=99m missing, =
though.

> =20
>=20
>> Whereas it is explicit in this statement
>>=20
>> if (authorizations.type =3D=3D=3D 'oauth_scope')
>>=20
>> which I think it easier to understand what is happening (in my =
opinion of course).
>>=20
>> XYZ has types, they are just implicit. RAR has explicit types, and =
that does not look to be holding back RAR. I don't understand why you =
think having explicit types will hold us back.=20
>=20
> The =E2=80=9Ctype=E2=80=9D in RAR is a name spacing device to allow =
extensibility in different aspects of the request. This is at a lower =
layer than how they=E2=80=99re being applied here, and it therefore =
makes more sense at that layer. It=E2=80=99s a way for a particular API =
to define the dimensions that it cares about in its request. It=E2=80=99s =
not really an even comparison.
>=20
> And the type in XAuth authorizations is different schemas for making a =
request. "oauth_scope", "oauth_rar", and now "oidc". I would expect that =
there may be more in the future, and we have a clear way of adding =
schemas, and for the client and AS to know they are talking the same =
"language".

And I=E2=80=99m saying that additional =E2=80=9Cschemas=E2=80=9D for =
requesting information should be defined separately from the GNAP =
schema. We disagree on this topic and we=E2=80=99re repeating ourselves.=20=


> =20
>=20
>> Do you want to let the string and object be anything the AS and RS =
decide they could mean?=20
>=20
> Yes. Just like the AS can decide that an OAuth scope could mean any =
number of things.
>=20
> That was what I was afraid of. While an OAuth scope could mean =
whatever the AS decides it wants to be, the Client and AS know it is an =
OAuth scope.

How is that any different? I=E2=80=99m confused as to why you think =
it=E2=80=99s important to call this item a =E2=80=9Cscope=E2=80=9D so =
that you =E2=80=9Cknow what it is=E2=80=9D, but then you=E2=80=99re OK =
with =E2=80=9Cscope=E2=80=9D meaning literally anything.

> =20
>=20
>> That would make GNAP more of a framework than a protocol, and a key =
aspect of the request would be undefined.
>=20
> I don=E2=80=99t see how this would make things a framework and not a =
protocol. We=E2=80=99re not debating the ability to send a set of =
strings or a set of objects to the AS, which the AS will interpret in =
the request. We=E2=80=99re debating the syntax for sending those values.
>=20
> =20
>=20
>>=20
>> My thoughts have not shifted on "types" in interactions. I just =
changed the name to 'mode'. I did shift my thinking that a negotiation =
of interaction modes is useful, and added that.
>=20
> The important shift is the removal of a single =E2=80=9Ctype=E2=80=9D =
field that meant you could only send one thing at a time, and now you =
can send multiple things in various combinations as need allows. =
That=E2=80=99s the kind of thing that I=E2=80=99m saying is problematic =
here as well, for many of the same reasons.
>=20
>>=20
>> We still have an unfinished discussion there. When you have a chance, =
would you respond to that thread?
>=20
> I believe the thread you=E2=80=99re referring to was commented on by =
several people, including an AD, as not being a helpful conversation for =
the group. I stopped responding to that thread when that was brought up, =
in order to respect that position and hopefully move the conversation =
along.
>=20
> This is the thread I am referring to:
>=20
> =
https://mailarchive.ietf.org/arch/msg/txauth/ECfShOtiN1WA1QiI77CBId4_VXg/ =

>=20
> And I don't think Ben was saying the conversation was not helpful, but =
wanted to clarify the goal:
>=20
> =
https://mailarchive.ietf.org/arch/msg/txauth/qOF5Wl3uYQ9rdzEz7ORftYAAHc4/ =

> =20
> I=E2=80=99m beginning to think that this conversation thread is itself =
going off the rails in a similar way, since we seem to be repeating =
things at each other.=20
>=20
> Seems later messages in this thread indicate otherwise as there seems =
to be some additional understanding.
> =20
> It=E2=80=99s become a comparison of solutions in detail and not a =
discussion of what the driving use cases are. I understand that you =
think your proposal is better, and I disagree and have pointed out what =
I see as several major flaws in it.
>=20
> Would you list those for me so I have a better idea of what they are? =
What aspect of the XAuth authorizations could you not live with?

Haven=E2=80=99t we been talking about them all along in all of these =
threads? Isn=E2=80=99t that what this conversation is largely about? I =
think I=E2=80=99ve been pretty clear, but my concerns include, but are =
not limited to, the following:

 - Use of a =E2=80=99type=E2=80=99 field to indicate sub-schemas to be =
parsed and understood
 - Separation of string-style =E2=80=9Cscope=E2=80=9D parameters from =
object-style =E2=80=9Crich=E2=80=99 parameters
 - Lack of ability to cleanly define combinations of different =
approaches
 - Outsourcing of query schema to external specs, specifically reliance =
on OAuth 2 technologies that come with OAuth 2 limitations
 - Overly verbose and awkward syntax to specify simple requests
 - Larger possibility of error conditions based on syntax alone (for =
example per the recent update, if someone asks for a multi-token =
response named =E2=80=9Ctype=E2=80=9D, that=E2=80=99s a class of error; =
if someone puts a =E2=80=9Cclaims=E2=80=9D field in an =E2=80=9Coauth_scop=
e=E2=80=9D typed request, that=E2=80=99s an error, etc)

I have talked about all of these concerns, asked for clarification and =
detail on them, and provided alternatives for all of them. I=E2=80=99ve =
got concerns with other parts of the Xauth proposal as well, as I know =
you=E2=80=99ve got concerns with many parts of the XYZ proposal. But =
ours aren=E2=80=99t the only opinions that matter, and they=E2=80=99re =
not even the most important ones as we are both too close to our own =
solutions to see the truth. That=E2=80=99s the reason I originally =
brought my work into a standards body, and why I have such high hopes =
for GNAP even now.

> =20
>=20
> My goal here isn=E2=80=99t to convince you as an individual that I=E2=80=
=99m right. My goal here is to present my ideas and explain the thought =
process behind them so that we all, as a group, can make the best =
decisions going forward based on that.=20
>=20
> Well it seems we have different goals. I'm trying to get a better =
understanding of your proposals, explain my concerns, and offer a =
solution to arrive at some rough consensus. You only want to present =
your ideas.

Wow, that=E2=80=99s a really bold accusation, and it ignores the end of =
the sentence: "so that we all, as a group, can make the best decisions =
going forward=E2=80=9D. I=E2=80=99ve been doing everything you claim to =
be doing as well =E2=80=94 understanding your proposal, explaining my =
concerns, and offering solutions to those concerns.=20

But it worries me that these threads have time and again devolved into =
just the two of us talking past each other, and not gathering consensus =
within the group. Ultimately, the group doesn=E2=80=99t have to pick =
either approach, but we aren=E2=80=99t really seeing input from others =
at this time. I would love to get away from this back and forth =
explanation and onto the real work of deciding what this protocol needs =
to do and how it needs to do it.

I=E2=80=99m not here to attack your proposal, but I will continue to =
make the best technical arguments I can for good design and engineering =
so that we can make GNAP the best protocol that it can be. I truly =
believe that it is possible we are building the next revolution in =
security protocols here, and that=E2=80=99s going to require a lot of =
hard engineering work.

 =E2=80=94 Justin


>=20
>  /Dick
>=20
>=20
>  =E2=80=94 Justin
>=20
>>=20
>> /Dick
>>=20
>> On Thu, Jul 9, 2020 at 8:39 AM Justin Richer > wrote:
>> Declarations of which code is =E2=80=9Ceasier to understand=E2=80=9D =
are going to be subjective, and I don=E2=80=99t agree with your =
conclusions even with your examples. Even so, I don=E2=80=99t think that =
the examples you give are a good comparison. While it is of course =
possible to implement things like you have below, I think it=E2=80=99s =
indicative of thinking of things in terms of a =E2=80=9Cresource request =
type=E2=80=9D. What I=E2=80=99ve been trying to argue is that there =
shouldn=E2=80=99t be a =E2=80=9Ctype=E2=80=9D, that there should just be =
slightly different ways to do a resource request. So the code is more =
like:
>>=20
>> resourcesRequested =3D requests.map( item =3D> {
>>    if (typeof item =3D=3D =E2=80=98object=E2=80=99) {
>>       return new RarStyleResourceRequest(item);
>>    } else if (typeof item =3D=3D =E2=80=9Cstring=E2=80=9D) {
>>      return new StringStyleResourceRequest(item);
>>    }
>> });
>> processResources(resourcesRequested);
>>=20
>> Each of these =E2=80=9C*ResourceRequest=E2=80=9D objects would be =
something that the AS can use to decide what to put into the access =
token. Although you=E2=80=99d probably put that complexity into a =
factory constructor or something instead of a map function, this shows =
the kind of dispatch you can do based on type if you=E2=80=99re doing it =
by hand. You collect everything in the array, and turn it into an object =
that represents =E2=80=9Ca request for a resource that gets tied to an =
access token=E2=80=9D. And then you process the request based on the =
collection of resource requests. Each string-based request points to =
some set of policies, as does each object-based request. You can even =
imagine that instead of creating a separate string-based request, you =
use that string to look up a policy in a policy engine to be applied =
later.
>>=20
>> The AS then has to figure out, as it always does, what to do with =
this collection. And if you want to do an early escape on object style =
requests, you could just throw an error when you detect that. Or, you =
just ignore that part of the request. In fact, here=E2=80=99s the code I =
wrote that handles it exactly that way, while processing the JSON by =
hand in Java on a legacy OAuth 2 server:
>>=20
>>=20
>> JsonArray resources =3D json.get("resources").getAsJsonArray();     =20=

>> Set scopes =3D StreamSupport.stream(resources.spliterator(), =
false)
>> 	.filter( e -> e.isJsonPrimitive() ) // filter out anything =
that's not a handle     =20
>> 	.map( e -> e.getAsString() )     =20
>> 	.collect(Collectors.toSet());     =20
>> tx.setScope(scopes);
>>=20
>>=20
>> Furthermore, your XAuth example doesn=E2=80=99t go to the same depth =
as the XYZ example, which leads to a false comparison. In your =
=E2=80=9Cprocess scope=E2=80=9D you would need to parse the =E2=80=9Cscope=
=E2=80=9D string to split on spaces, and then have another loop to =
process each scope. For the =E2=80=9Cprocess details=E2=80=9D you=E2=80=99=
d need to iterate over the array at the root of a RAR-style request and =
process each piece. In the XYZ code, you=E2=80=99ve got all of that =
already. If you=E2=80=99re going to compare the complexity of code, they =
should at least be shown to the same point of the process.=20
>>=20
>> On top of that, the fall-through case statement below is really =
limiting. What if the scope processing or RAR objects processing gets =
combined with something else? This kind of premature optimization is not =
something we want to encourage developers to do.=20
>>=20
>> But ultimately, I think the disconnect is down to thinking about this =
in terms of an explicit =E2=80=9Ctype=E2=80=9D, much the way XAuth used =
to do with the interactions. I=E2=80=99m glad that your thoughts have =
shifted in that space, and I think you should strongly consider the same =
set of arguments here. A lot of the promise of GNAP is getting away from =
this type-field style design, like getting away from OAuth 2=E2=80=99s =
=E2=80=9Cgrant_type=E2=80=9D approach and into something that=E2=80=99s =
focused on interaction and client models instead. This newer model =
allows for better flexibility, better consistency, and better clarity =
throughout. It=E2=80=99s no longer =E2=80=9Cif I see this flag then I go =
down this separate code path and nothing else=E2=80=9D, it=E2=80=99s now =
=E2=80=9Cif I see this item, I go down this code path and then process =
the next item too=E2=80=9D. There=E2=80=99s power in the combinations.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 8, 2020, at 9:31 PM, Dick Hardt > wrote:
>>>=20
>>> I had intended to provide a code sample comparing XYZ request type =
with XAuth request type
>>>=20
>>> Let's say an AS only supports OAuth scopes (does not support RAR). =
Here is JS code to check:
>>>=20
>>> //XYZ code
>>> var oauth_scope =3D true;
>>> requests.forEach( item =3D> {        =20
>>>     if (typeof item =3D=3D=3D "object")
>>>         oauth_scope =3D false;
>>> });
>>> if (!'oauth_scope') {
>>>     // return error
>>> }
>>>=20
>>> // XAuth code
>>> if ('oauth_scope' !=3D authorizations.type) {
>>>    // return error
>>> }
>>>=20
>>> Here is some JS code that for an AS that supports OAuth scopes, RAR, =
and OIDC requests:
>>>=20
>>> // XYZ
>>> if (request) {
>>>     requests.forEach( item =3D> {
>>>         if (typeof item =3D=3D=3D "object") {
>>>             // process a RAR item
>>>         } else if(typeof item =3D=3D=3D 'string') {
>>>             // process a scope item
>>>         } else {
>>>             // throw an error
>>>         }
>>>     })   =20
>>>    // process the whole request
>>> }
>>> if (oidc_claims_query) {
>>>     // process oidc request
>>> }
>>>=20
>>> //XAuth
>>> if (authorizations) {
>>>     switch (authorizations?.type) {
>>>         case 'oauth_rar':
>>>             // process authorizations.details - RAR=20
>>>         case 'oauth_scope':
>>>             // process authorizations.scope
>>>             // process the whole request
>>>             break;
>>>         case 'oidc':
>>>             // process OIDC claims
>>>             break;
>>>         default:
>>>             // error for unknown type
>>>     }
>>> }   =20
>>>=20
>>>=20
>>> Understanding what the code is doing looks much clearer in XAuth to =
me.
>>>=20
>>> =E1=90=A7
>>>=20
>>> On Wed, Jul 8, 2020 at 3:55 PM Dick Hardt > wrote:
>>> Hey Justin,
>>>=20
>>> Just because we are using OIDC claims, does not mean we need to =
mimic the OIDC request and response.
>>> I was envisioning a grant request could look as the following (using =
XAuth syntax):
>>>=20
>>> {
>>>     "authorizations": {
>>>         "type":"oidc",
>>>         "claims": ["name", "picture"]
>>>     },
>>>     "claims":{
>>>         "oidc": {
>>>             "id_token" : {
>>>                 "email"          : { "essential" : true },
>>>                 "email_verified" : { "essential" : true }
>>>             },
>>>             "userinfo" : {
>>>                 "name"           : { "essential" : true },
>>>                 "picture"        : null
>>>             }
>>>         }
>>>     }
>>> }
>>>=20
>>> Of course a developer could choose to only ask for a subset of this.
>>>=20
>>> Note the new authorization type of "oidc", that takes "claims" =
rather than "scope".=20
>>>=20
>>> This keeps all the authorizations and claims in their respective =
request and response containers.
>>>=20
>>> We had a thread months ago on the OIDC two stage model, and I still =
fail to see why forcing that has any advantage.=20
>>>=20
>>> /Dick
>>>=20
>>>=20
>>> On Wed, Jul 8, 2020 at 3:25 PM Justin Richer > wrote:
>>> I=E2=80=99m glad that we can agree that there are a number of things =
in legacy protocols that are unfortunate side effects of the =
circumstances in which they were built. Space-separated scope strings, =
for instance, would fall in that category, as I=E2=80=99ve previously =
explained.
>>>=20
>>> A key point in the below: the OIDC =E2=80=9Cclaims=E2=80=9D request =
already mixes user claims (returned in an API) and authorization (to =
fetch user claims from an API), so that ship has sailed if you=E2=80=99re =
using it. It doesn=E2=80=99t make sense to have it under a =E2=80=9Cclaims=
=E2=80=9D or =E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s =
a query language that affects both. Maybe you=E2=80=99d call this =
another =E2=80=9Cunfortunate design=E2=80=9D, but the context was about =
re-using an externally-defined query language that was not made for =
GNAP.
>>>=20
>>> My scenario was for someone who is already using =E2=80=9Cclaims=E2=80=
=9D and wants to keep using it. (The vast majority of OIDC =
implementations, in my experience, don=E2=80=99t use that feature, and =
it=E2=80=99s not even required to be implemented by the AS, but again =
we=E2=80=99re talking about using this feature as an example of an =
external query language =E2=80=94 and there are others out there.) In =
GNAP, you should return claims directly in the response, and request =
specific elements from the APIs protected by the access token. These are =
separate things, and by design both XAuth and XYZ have put them into =
separate containers in the request. This is a good design, and so =
putting something that conflates these two aspects into one or the other =
of the containers is not a particularly good option, in my opinion.=20
>>>=20
>>> Additionally, though this is a bit of an aside and getting into the =
specifics of identity, the =E2=80=9Cclaims=E2=80=9D parameter of ODIC is =
a query language bound to the full user profile. It is my stated =
position that the items coming back from the AS should only be =
identifiers, and not full profile information. The reasoning is pretty =
simple: the client doesn=E2=80=99t know what profile information it =
needs until it knows who the user is, so putting that into a protected =
API like the UserInfo Endpoint makes much more sense than putting it =
into the immediate response, where it is not needed, because the client =
already knows it. The AS doesn=E2=80=99t know what the client needs to =
know, either, so it can=E2=80=99t determine what to fulfill. OIDC=E2=80=99=
s two-stage model makes sense, and GNAP should really only focus on =
enabling this.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>> On Jul 8, 2020, at 6:10 PM, Dick Hardt > wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> On Wed, Jul 8, 2020 at 1:02 PM Justin Richer > wrote:
>>>> On Jul 8, 2020, at 3:16 PM, Dick Hardt > wrote:
>>>>>=20
>>>>> I think representing the request as an array is simplistic, and =
complicated at the same time.
>>>>>=20
>>>>> On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the request.=20=

>>>>=20
>>>> The elements of the array are taken as a set, to be tied to the =
same resulting access token. If one of those elements is defined, by the =
AS and/or the RS=E2=80=99s it=E2=80=99s protecting, to apply across some =
or all of the other elements, then that=E2=80=99s up to the AS=E2=80=99s =
policy. Much like the =E2=80=9Copenid=E2=80=9D scope in OIDC, which =
switches on all sorts of contextual stuff in the request. So to handle =
something like this, an AS can easily declare that a given scope-style =
string or a given object property applies to different parts of the =
request. You don=E2=80=99t need to externalize it here.
>>>>=20
>>>> I view the "openid" scope as an unfortunate design as OIDC was =
constrained by building on top of OAuth. (a problem I hoped to avert by =
having "identity" in scope for GNAP) The "openid" scope does not =
function as scope per se, and I think it makes OIDC harder to understand =
as the "openid" scope causes non-scope behavior.=20
>>>>=20
>>>> =20
>>>>=20
>>>> Do you have a concrete use case that requires that feature to be =
done in the way that you describe? I am trying to separate the driving =
use case from the proposed solutions to see what the differences are.=20
>>>>=20
>>>> Perhaps the client wants access to be HIPPA compliant? The HIPPA =
compliance signal applies to the scopes.
>>>>=20
>>>> Adding other properties to an object is a well understood extension =
mechanism. Adding an additional element to an array that does not act =
like the other elements seems like a hack.
>>>>=20
>>>> =20
>>>>=20
>>>>>=20
>>>>> Using JSON type polymorphism requires the AS to test each member =
of the array to determine if it is a string or an object. Only after =
detecting a RAR object does the AS know the client is making a RAR =
request.=20
>>>>=20
>>>> That=E2=80=99s correct =E2=80=94 but the AS needs to parse the =
whole resources request in order to figure out what the client is asking =
for, anyway, whether it=E2=80=99s by strings or objects or whatever else =
might be defined by an extension. Is there an argument for having an AS =
do an early dispatch on a request before it=E2=80=99s fully parsed =
everything?
>>>>=20
>>>> Let me clarify, the code is looking at the type of object that has =
been parsed.=20
>>>>=20
>>>> Determining if an item in an array is a scope or a RAR object by =
looking at the type being either a string or an object seems less clear =
than a property of an object explicitly declaring the type.
>>>>=20
>>>> =20
>>>>=20
>>>>> This also limits the request to be composed only of scope strings =
or RAR objects. I don't see how other strings or objects could be used =
in the array, so there is no clear extension point in the "resources" =
array for other query mechanisms.
>>>>=20
>>>> That=E2=80=99s not the case in XYZ since we aren=E2=80=99t =
declaring that a string has to be an OAuth2-style scope. It can be, but =
ultimately it=E2=80=99s just a string that the AS can understand. And =
the objects are just that =E2=80=94 objects. If the AS understands what =
the object is, it can be a RAR object or it can be something completely =
API-specific with another query language entirely.
>>>>=20
>>>> But the other query language would need a type that has been =
reserved in the RAR name space for there to be interop, so it =
effectively is a RAR extension.
>>>>=20
>>>> There are query languages in other domains that may not fit nicely =
into RAR such as a query for medical records.
>>>>=20
>>>> Yes, the medical records could be yet another top level property, =
but per below, I think that is confusing.
>>>> =20
>>>> (Point, though: RAR already pretty much allows this by letting them =
be extended infinitely, a feature it inherits from XYZ)
>>>>=20
>>>> I=E2=80=99m proposing that we do the same thing with GNAP: it=E2=80=99=
s an array of strings or objects and each of those means the same thing, =
=E2=80=9Csomething the client is asking for=E2=80=9D.
>>>>=20
>>>>>=20
>>>>> Just as RAR has a "type" property, I propose the "resources" =
("authorizations" in XAuth) be an object, where the other properties are =
determined by the "type" property. This allows extensions to define new =
ways to query for an authorization rather than having to fit into scopes =
or RAR.
>>>>>=20
>>>>=20
>>>> It=E2=80=99s my stance that this is an unnecessary limitation at =
this level. The objects within the array should be typed, like RAR, but =
it doesn=E2=80=99t make sense for the overall request to be typed. =
Instead, there should be one =E2=80=9Ctype" of query in the core, what =
XYZ calls the =E2=80=9Cresources=E2=80=9D request. Other query languages =
should be added as extensions either to the RAR-style objects (by =
defining a type at that level) or as a separate top-level member.
>>>>=20
>>>> For example, let=E2=80=99s take the OIDC =E2=80=9Cclaims=E2=80=9D =
query language. My current thought is that this really shouldn=E2=80=99t =
be a part of the =E2=80=9Cresources=E2=80=9D or =E2=80=9Cclaims=E2=80=9D =
part of the request, but instead as its own top-level member, like it is =
in the OIDC protocol today. The main reason for this is the nature of =
the OIDC claims language: it specifies targets for the resulting data, =
and those targets cross different ways to return things. So it doesn=E2=80=
=99t actually affect just resources like the UserInfo Endpoint, or the =
ID Token, but both and potentially others out there. If your system =
supported such an extension, it could theoretically forego both the =
built-in =E2=80=9Cclaims=E2=80=9D and =E2=80=9Cresources=E2=80=9D parts =
of the request, and use the =E2=80=9Coidc_claims_query=E2=80=9D member =
(or whatever it would be called). This would let such an extension use =
the OIDC claims processing mechanism as it is today.
>>>>=20
>>>> To me, this remains much more understandable, extensible, and =
clean.
>>>>=20
>>>> While this may be more understandable to a developer just porting =
an app OIDC that only wants OIDC results, but I think it is more =
complicated as soon as the developer wants other results, which is =
likely what prompted the developer to use GNAP instead of ODIC.
>>>>=20
>>>> I think it is easier to understand if all the claims are in one =
container, and all the authorizations are in another container.
>>>>=20
>>>> If a developer wants access to some resources, some claims, and an =
OpenID Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread across =
multiple containers. There are some claims in the "claims" container, =
and some "claims" in the "oidc_claims_query" container. And is the =
access token response in "oidc_claims_query" the same as an access token =
response in "resources"? It would seem simpler if they were, and if all =
the access tokens came back in the same container.
>>>>=20
>>>> Per Aaron's post that you have referred to, the developer can get =
sme bare claims directly in the response in the "claims" object, an ID =
Token that has the same or different claims, and if they want, an access =
token that they can call a user_info endpoint to get the same, or =
different claims.
>>>>=20
>>>> For example, an enterprise app client may want an ID Token with the =
email address, bare claims for the user's name and a URI to a profile =
photo, and an access token to query which groups a user belongs to.
>>>>=20
>>>> We are still re-using the OIDC claims, but we are not mixing claims =
and authorizations.
>>>>=20
>>>> /Dick
>>>>=20
>>>>=20
>>>> [1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz =

>>>> =E1=90=A7
>>>=20
>>> =E1=90=A7
>>=20
>> =E1=90=A7


--Apple-Mail=_73758EB5-19BD-464D-8860-F312D367F9EB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Jul 9, 2020, at 6:50 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, Jul 9, 2020 at 12:17 PM Justin Richer =
<jricher@mit.edu> =
wrote:
On Jul 9, 2020, at 2:32 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Looks like you missed the point =
of my code example, as your response is focussed on the aspects I had =
in comments, so let me =
clarify. 

The point seemed to be about the =
overall complexity and readability, and that=E2=80=99s what I responded =
to.

It was about the complexity and =
readability -- of those specific lines of =
code.

But =
it=E2=80=99s not just about those lines, it=E2=80=99s about the context =
that those lines are in and the follow-on code paths that they cause. A =
lot of what you had =E2=80=9Cin comments=E2=80=9D for the XAuth example =
would have repeated what was already included in the XYZ example, as I =
pointed out.


I've used JS type polymorphism to provide a cleaner API. For =
example, making an HTTP request. If I'm good with all the defaults, I =
can just provide the URI as a string, if I want to change a default, I =
provide an object and the URI is now a property of the object. =
Polymorphism allows the caller to have a simpler interface when it is a =
simple operation.

Do you have any examples of JSON polymorphism used in =
other protocols besides in a JWT?

Sounds to me like you=E2=80=99re describing =
exactly the kind of polymorphism that I=E2=80=99m talking about here. =
Use a string where it makes sense and an object where it makes sense, =
and there=E2=80=99s no ambiguity in calling the function. As you say, =
it's all about providing a cleaner API for the caller, and making things =
consistent in the model that the caller and provider are using. It takes =
a little bit of extra effort on the part of the API provider, but =
that=E2=80=99s where the complexity cost should be paid.

 


This =
line (which is determining the type of the item in the =
array):

if (typeof item =
=3D=3D=3D string')

is =
implicitly stating that the item is an oauth scope. 

No, it is =
not. It is saying that it is a resource request represented as a string. =
One way to represent a resource request as a string is an OAuth 2 style =
scope. And if you=E2=80=99re building up from an existing OAuth 2 =
system, then you could use a scope there. But that=E2=80=99s not the =
same as stating =E2=80=9Cthe item is a scope=E2=80=9D. In my examples, I =
had been trying to use the terminology that you were using, but I=E2=80=99=
m afraid that made things more =
unclear.

We are comparing how to do it in XYZ vs =
XAuth -- so to make it apples and apples, the string is a scope, since =
that is the use case we are looking =
at.

You can =
use a scope as the string, and if you want to think of all string values =
in this request as all being =E2=80=9Cscopes", that=E2=80=99s fine, but =
only if you can concede that the scope can mean whatever the AS wants. I =
think that perhaps you=E2=80=99re putting a certain amount of semantic =
weight to =E2=80=9Cscope=E2=80=9D that I=E2=80=99m missing, =
though.

 

Whereas it is explicit in this =
statement

if =
(authorizations.type =3D=3D=3D =
'oauth_scope')

which I think it easier =
to understand what is happening (in my opinion of course).

XYZ has types, they are =
just implicit. RAR has explicit types, and that does not look to be =
holding back RAR. I don't understand why you think having explicit types =
will hold us back. 

The =
=E2=80=9Ctype=E2=80=9D in RAR is a name spacing device to allow =
extensibility in different aspects of the request. This is at a lower =
layer than how they=E2=80=99re being applied here, and it therefore =
makes more sense at that layer. It=E2=80=99s a way for a particular API =
to define the dimensions that it cares about in its request. It=E2=80=99s =
not really an even comparison.

And the type in XAuth =
authorizations is different schemas for making a request. =
"oauth_scope", "oauth_rar", and now "oidc". I would expect that there =
may be more in the future, and we have a clear way of adding schemas, =
and for the client and AS to know they are talking the same =
"language".

And I=E2=80=99m saying that additional =
=E2=80=9Cschemas=E2=80=9D for requesting information should be defined =
separately from the GNAP schema. We disagree on this topic and we=E2=80=99=
re repeating ourselves. 

 

Do you want to let the string and object be anything the AS =
and RS decide they could mean? 

Yes. Just =
like the AS can decide that an OAuth scope could mean any number of =
things.

That was what I was afraid of. While an =
OAuth scope could mean whatever the AS decides it wants to be, the =
Client and AS know it is an OAuth =
scope.

How =
is that any different? I=E2=80=99m confused as to why you think it=E2=80=99=
s important to call this item a =E2=80=9Cscope=E2=80=9D so that you =
=E2=80=9Cknow what it is=E2=80=9D, but then you=E2=80=99re OK with =
=E2=80=9Cscope=E2=80=9D meaning literally anything.

 

That would make GNAP more of a framework than =
a protocol, and a key aspect of the request would be =
undefined.

I don=E2=80=99t see how this would make =
things a framework and not a protocol. We=E2=80=99re not debating the =
ability to send a set of strings or a set of objects to the AS, which =
the AS will interpret in the request. We=E2=80=99re debating the syntax =
for sending those values.

 


My thoughts have not shifted on "types" in interactions. I =
just changed the name to 'mode'. I did shift my thinking that a =
negotiation of interaction modes is useful, and added =
that.

The important shift is the removal of a =
single =E2=80=9Ctype=E2=80=9D field that meant you could only send one =
thing at a time, and now you can send multiple things in various =
combinations as need allows. That=E2=80=99s the kind of thing that I=E2=80=
=99m saying is problematic here as well, for many of the same =
reasons.


We still have an unfinished discussion there. When you have a =
chance, would you respond to that =
thread?

I believe the thread you=E2=80=99re =
referring to was commented on by several people, including an AD, as not =
being a helpful conversation for the group. I stopped responding to that =
thread when that was brought up, in order to respect that position and =
hopefully move the conversation =
along.

This is the thread I am referring =
to:

https://mailarchive.ietf.org/arch/msg/txauth/ECfShOtiN1WA1QiI77=
CBId4_VXg/

And I don't think Ben was saying the conversation was not =
helpful, but wanted to clarify the goal:

https://mailarchive.ietf.org/arch/msg/txauth/qOF5Wl3uYQ9rdzEz7O=
RftYAAHc4/
 
I=E2=80=99m =
beginning to think that this conversation thread is itself going off the =
rails in a similar way, since we seem to be repeating things at each =
other. 

Seems later =
messages in this thread indicate otherwise as there seems to be some =
additional understanding.
 
It=E2=80=99s become a comparison of solutions in detail and =
not a discussion of what the driving use cases are. I understand that =
you think your proposal is better, and I disagree and have pointed out =
what I see as several major flaws in =
it.

Would you list those for me so I have a =
better idea of what they are? What aspect of the XAuth authorizations =
could you not live with?

Haven=E2=80=99t we been talking about them all =
along in all of these threads? Isn=E2=80=99t that what this conversation =
is largely about? I think I=E2=80=99ve been pretty clear, but my =
concerns include, but are not limited to, the following:

 - Use of a =E2=80=99type=E2=80=99 field to =
indicate sub-schemas to be parsed and understood
 - =
Separation of string-style =E2=80=9Cscope=E2=80=9D parameters from =
object-style =E2=80=9Crich=E2=80=99 parameters
 - Lack of =
ability to cleanly define combinations of different =
approaches
 - Outsourcing of query schema to external =
specs, specifically reliance on OAuth 2 technologies that come with =
OAuth 2 limitations
 - Overly verbose and awkward syntax =
to specify simple requests
 - Larger possibility of error =
conditions based on syntax alone (for example per the recent update, if =
someone asks for a multi-token response named =E2=80=9Ctype=E2=80=9D, =
that=E2=80=99s a class of error; if someone puts a =E2=80=9Cclaims=E2=80=9D=
 field in an =E2=80=9Coauth_scope=E2=80=9D typed request, that=E2=80=99s =
an error, etc)

I have talked about =
all of these concerns, asked for clarification and detail on them, and =
provided alternatives for all of them. I=E2=80=99ve got concerns with =
other parts of the Xauth proposal as well, as I know you=E2=80=99ve got =
concerns with many parts of the XYZ proposal. But ours aren=E2=80=99t =
the only opinions that matter, and they=E2=80=99re not even the most =
important ones as we are both too close to our own solutions to see the =
truth. That=E2=80=99s the reason I originally brought my work into a =
standards body, and why I have such high hopes for GNAP even =
now.

 

My goal here isn=E2=80=99t to convince =
you as an individual that I=E2=80=99m right. My goal here is to present =
my ideas and explain the thought process behind them so that we all, as =
a group, can make the best decisions going forward based on =
that. 

Well it seems we have different goals. =
I'm trying to get a better understanding of your proposals, explain =
my concerns, and offer a solution to arrive at some rough consensus. You =
only want to present your ideas.

Wow, that=E2=80=99s a really bold accusation, and =
it ignores the end of the sentence: "so that we all, as a group, can =
make the best decisions going forward=E2=80=9D. I=E2=80=99ve been doing =
everything you claim to be doing as well =E2=80=94 understanding your =
proposal, explaining my concerns, and offering solutions to those =
concerns. 

But it worries me =
that these threads have time and again devolved into just the two of us =
talking past each other, and not gathering consensus within the group. =
Ultimately, the group doesn=E2=80=99t have to pick either approach, but =
we aren=E2=80=99t really seeing input from others at this time. I would =
love to get away from this back and forth explanation and onto the real =
work of deciding what this protocol needs to do and how it needs to do =
it.

I=E2=80=99m not here to attack =
your proposal, but I will continue to make the best technical arguments =
I can for good design and engineering so that we can make GNAP the best =
protocol that it can be. I truly believe that it is possible we are =
building the next revolution in security protocols here, and that=E2=80=99=
s going to require a lot of hard engineering work.

 =E2=80=94 Justin



 /Dick


 =E2=80=94 =
Justin


/Dick

On Thu, Jul 9, 2020 at 8:39 AM Justin Richer <jricher@mit.edu> wrote:
Declarations of =
which code is =E2=80=9Ceasier to understand=E2=80=9D are going to be =
subjective, and I don=E2=80=99t agree with your conclusions even with =
your examples. Even so, I don=E2=80=99t think that the examples you give =
are a good comparison. While it is of course possible to implement =
things like you have below, I think it=E2=80=99s indicative of thinking =
of things in terms of a =E2=80=9Cresource request type=E2=80=9D. What =
I=E2=80=99ve been trying to argue is that there shouldn=E2=80=99t be a =
=E2=80=9Ctype=E2=80=9D, that there should just be slightly different =
ways to do a resource request. So the code is more like:

resourcesRequested =3D =
requests.map( item =3D> {
   if (typeof item =3D=3D =E2=80=98object=E2=80=99) =
{
      return =
new RarStyleResourceRequest(item);
   } else if (typeof item =3D=3D =E2=80=9Cstring=E2=80=
=9D) {
    =
 return new StringStyleResourceRequest(item);
   }
});
processResources(resourcesRequested);
<=
div class=3D"">

Each =
of these =E2=80=9C*ResourceRequest=E2=80=9D objects would be something =
that the AS can use to decide what to put into the access token. =
Although you=E2=80=99d probably put that complexity into a factory =
constructor or something instead of a map function, this shows the kind =
of dispatch you can do based on type if you=E2=80=99re doing it by hand. =
You collect everything in the array, and turn it into an object that =
represents =E2=80=9Ca request for a resource that gets tied to an access =
token=E2=80=9D. And then you process the request based on the collection =
of resource requests. Each string-based request points to some set of =
policies, as does each object-based request. You can even imagine that =
instead of creating a separate string-based request, you use that string =
to look up a policy in a policy engine to be applied later.

The AS then has to =
figure out, as it always does, what to do with this collection. And if =
you want to do an early escape on object style requests, you could just =
throw an error when you detect that. Or, you just ignore that part of =
the request. In fact, here=E2=80=99s the code I wrote that handles it =
exactly that way, while processing the JSON by hand in Java on a legacy =
OAuth 2 server:


JsonArray resources =3D json.get("resources").ge=
tAsJsonArray();      
Set<String> scopes =3D StreamSupport.strea=
m(resources.spliterator(), false)
	.filter( =
e -> e.isJsonPrimitive() ) // filter out anything =
that's not a handle      
	=
.map( e -> e.getAsString() )    =
  
	.collect(Collectors.toSet());    =
  
tx.setScope(scopes);


Furthermore, your XAuth example doesn=E2=80=99t go to the =
same depth as the XYZ example, which leads to a false comparison. In =
your =E2=80=9Cprocess scope=E2=80=9D you would need to parse the =
=E2=80=9Cscope=E2=80=9D string to split on spaces, and then have another =
loop to process each scope. For the =E2=80=9Cprocess details=E2=80=9D =
you=E2=80=99d need to iterate over the array at the root of a RAR-style =
request and process each piece. In the XYZ code, you=E2=80=99ve got all =
of that already. If you=E2=80=99re going to compare the complexity of =
code, they should at least be shown to the same point of the =
process. 

On top of that, the fall-through case statement below is =
really limiting. What if the scope processing or RAR objects processing =
gets combined with something else? This kind of premature optimization =
is not something we want to encourage developers to do. 

But ultimately, I think =
the disconnect is down to thinking about this in terms of an explicit =
=E2=80=9Ctype=E2=80=9D, much the way XAuth used to do with the =
interactions. I=E2=80=99m glad that your thoughts have shifted in that =
space, and I think you should strongly consider the same set of =
arguments here. A lot of the promise of GNAP is getting away from this =
type-field style design, like getting away from OAuth 2=E2=80=99s =
=E2=80=9Cgrant_type=E2=80=9D approach and into something that=E2=80=99s =
focused on interaction and client models instead. This newer model =
allows for better flexibility, better consistency, and better clarity =
throughout. It=E2=80=99s no longer =E2=80=9Cif I see this flag then I go =
down this separate code path and nothing else=E2=80=9D, it=E2=80=99s now =
=E2=80=9Cif I see this item, I go down this code path and then process =
the next item too=E2=80=9D. There=E2=80=99s power in the =
combinations.

 =E2=80=94 Justin

On Jul =
8, 2020, at 9:31 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I had intended to provide a code =
sample comparing XYZ request type with XAuth request type

Let's =
say an AS only supports OAuth scopes (does not support RAR). Here is JS =
code to check:

//XYZ code
var oauth_scope =3D =
true;
requests.forEach( item =3D> {   =
      
    if (typeof item =3D=3D=3D "object")
        oauth_scope =3D false;
});
if (!'oauth_scope') {
    // return error
}

// XAuth code
if ('oauth_scope' !=3D =
authorizations.type) {
   // return =
error
}

Here is some JS code that for an AS =
that supports OAuth scopes, RAR, and OIDC requests:

// XYZ
if (request) {
    =
requests.forEach( item =3D> {
      =
  if (typeof item =3D=3D=3D "object") {
    =
        // process a RAR item
  =
      } else if(typeof item =3D=3D=3D 'string') {
            // process a scope =
item
        } else {
            // throw an =
error
        }
  =
  })    
   // process the whole =
request
}
if (oidc_claims_query) {
    // process oidc request
}

//XAuth
if (authorizations) {
    switch =
(authorizations?.type) {
        case =
'oauth_rar':
            // =
process authorizations.details - RAR 
        case 'oauth_scope':
            // process =
authorizations.scope
          =
  // process the whole request
      =
      break;
        =
case 'oidc':
            // =
process OIDC claims
          =
  break;
        default:
            // error for =
unknown type
    }
}  =
  


Understanding what the code is doing looks much clearer in =
XAuth to me.

3D""=E1=90=A7

On Wed, Jul =
8, 2020 at 3:55 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Justin,

Just because we are =
using OIDC claims, does not mean we need to mimic the OIDC request and =
response.
I was envisioning a grant request could =
look as the following (using XAuth syntax):

{
  =
  "authorizations": {
        =
"type":"oidc",
        "claims": =
["name", "picture"]
    },
  =
  "claims":{
        "oidc": {
            "id_token" : {
                =
"email"          : { "essential" : true },
                =
"email_verified" : { "essential" : true }
    =
        },
        =
    "userinfo" : {
        =
        "name"           : =
{ "essential" : true },
          =
      "picture"        : null
            }
        }
    =
}
}

Of course a developer could choose to =
only ask for a subset of this.

Note the new authorization type of =
"oidc", that takes "claims" rather than "scope". 

This keeps all the =
authorizations and claims in their respective request and response =
containers.

We =
had a thread months ago on the OIDC two stage model, and I still fail to =
see why forcing that has any advantage. 

/Dick


On Wed, Jul 8, 2020 at 3:25 PM Justin =
Richer <jricher@mit.edu> wrote:
I=E2=80=99m glad =
that we can agree that there are a number of things in legacy protocols =
that are unfortunate side effects of the circumstances in which they =
were built. Space-separated scope strings, for instance, would fall in =
that category, as I=E2=80=99ve previously explained.

A key point in the below: the OIDC =
=E2=80=9Cclaims=E2=80=9D request already mixes user claims (returned in =
an API) and authorization (to fetch user claims from an API), so that =
ship has sailed if you=E2=80=99re using it. It doesn=E2=80=99t make =
sense to have it under a =E2=80=9Cclaims=E2=80=9D or =
=E2=80=9Cauthorizations=E2=80=9D request, since it=E2=80=99s a query =
language that affects both. Maybe you=E2=80=99d call this another =
=E2=80=9Cunfortunate design=E2=80=9D, but the context was about re-using =
an externally-defined query language that was not made for GNAP.

My scenario was for =
someone who is already using =E2=80=9Cclaims=E2=80=9D and wants to keep =
using it. (The vast majority of OIDC implementations, in my experience, =
don=E2=80=99t use that feature, and it=E2=80=99s not even required to be =
implemented by the AS, but again we=E2=80=99re talking about using this =
feature as an example of an external query language =E2=80=94 and there =
are others out there.) In GNAP, you should return claims directly in the =
response, and request specific elements from the APIs protected by the =
access token. These are separate things, and by design both XAuth and =
XYZ have put them into separate containers in the request. This is a =
good design, and so putting something that conflates these two aspects =
into one or the other of the containers is not a particularly good =
option, in my opinion. 

Additionally, though this is a bit of =
an aside and getting into the specifics of identity, the =E2=80=9Cclaims=E2=
=80=9D parameter of ODIC is a query language bound to the full user =
profile. It is my stated position that the items coming back from the AS =
should only be identifiers, and not full profile information. The =
reasoning is pretty simple: the client doesn=E2=80=99t know what profile =
information it needs until it knows who the user is, so putting that =
into a protected API like the UserInfo Endpoint makes much more sense =
than putting it into the immediate response, where it is not needed, =
because the client already knows it. The AS doesn=E2=80=99t know what =
the client needs to know, either, so it can=E2=80=99t determine what to =
fulfill. OIDC=E2=80=99s two-stage model makes sense, and GNAP should =
really only focus on enabling this.

 =E2=80=94 Justin

On Jul 8, 2020, at 6:10 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Wed, Jul =
8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 8, 2020, at 3:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I =
think representing the request as an array is simplistic, and =
complicated at the same time.

On the simplistic front, as there is no clear mechanism for =
extending the request with properties that apply to all of the =
request. 

The elements of the array are taken as =
a set, to be tied to the same resulting access token. If one of those =
elements is defined, by the AS and/or the RS=E2=80=99s it=E2=80=99s =
protecting, to apply across some or all of the other elements, then =
that=E2=80=99s up to the AS=E2=80=99s policy. Much like the =E2=80=9Copeni=
d=E2=80=9D scope in OIDC, which switches on all sorts of contextual =
stuff in the request. So to handle something like this, an AS can easily =
declare that a given scope-style string or a given object property =
applies to different parts of the request. You don=E2=80=99t need to =
externalize it here.

I view the "openid" scope as an =
unfortunate design as OIDC was constrained by building on top of =
OAuth. (a problem I hoped to avert by having "identity" in scope for =
GNAP) The "openid" scope does not function as scope per se, and I =
think it makes OIDC harder to understand as the "openid" scope causes =
non-scope behavior. 

 

Do you have a concrete use case that requires that feature to =
be done in the way that you describe? I am trying to separate the =
driving use case from the proposed solutions to see what the differences =
are. 

Perhaps the client wants access to be =
HIPPA compliant? The HIPPA compliance signal applies to the =
scopes.

Adding =
other properties to an object is a well understood extension mechanism. =
Adding an additional element to an array that does not act like the =
other elements seems like a hack.

 


Using =
JSON type polymorphism requires the AS to test each member of the =
array to determine if it is a string or an object. Only after detecting =
a RAR object does the AS know the client is making a RAR request. 

That=E2=80=99s correct =
=E2=80=94 but the AS needs to parse the whole resources request in order =
to figure out what the client is asking for, anyway, whether it=E2=80=99s =
by strings or objects or whatever else might be defined by an extension. =
Is there an argument for having an AS do an early dispatch on a request =
before it=E2=80=99s fully parsed =
everything?

Let me clarify, the code is looking at =
the type of object that has been parsed. 

Determining if an item in an array is a =
scope or a RAR object by looking at the type being either a string or an =
object seems less clear than a property of an object explicitly =
declaring the type.

 

This =
also limits the request to be composed only of scope strings or RAR =
objects. I don't see how other strings or objects could be used in the =
array, so there is no clear extension point in the "resources" array for =
other query mechanisms.

That=E2=80=99s not the =
case in XYZ since we aren=E2=80=99t declaring that a string has to be an =
OAuth2-style scope. It can be, but ultimately it=E2=80=99s just a string =
that the AS can understand. And the objects are just that =E2=80=94 =
objects. If the AS understands what the object is, it can be a RAR =
object or it can be something completely API-specific with another query =
language entirely.

But the other query language would need =
a type that has been reserved in the RAR name space for there to be =
interop, so it effectively is a RAR extension.

There are query languages in other =
domains that may not fit nicely into RAR such as a query for medical =
records.

Yes, =
the medical records could be yet another top level property, but per =
below, I think that is confusing.
 
(Point, though: RAR already =
pretty much allows this by letting them be extended infinitely, a =
feature it inherits from XYZ)

I=E2=80=99m proposing that we do the =
same thing with GNAP: it=E2=80=99s an array of strings or objects and =
each of those means the same thing, =E2=80=9Csomething the client is =
asking for=E2=80=9D.


Just as =
RAR has a "type" property, I propose the "resources" ("authorizations" =
in XAuth) be an object, where the other properties are determined by the =
"type" property. This allows extensions to define new ways to query for =
an authorization rather than having to fit into scopes or RAR.


It=E2=80=99s my stance =
that this is an unnecessary limitation at this level. The objects within =
the array should be typed, like RAR, but it doesn=E2=80=99t make sense =
for the overall request to be typed. Instead, there should be one =
=E2=80=9Ctype" of query in the core, what XYZ calls the =E2=80=9Cresources=
=E2=80=9D request. Other query languages should be added as extensions =
either to the RAR-style objects (by defining a type at that level) or as =
a separate top-level member.

For example, let=E2=80=99s take the =
OIDC =E2=80=9Cclaims=E2=80=9D query language. My current thought is that =
this really shouldn=E2=80=99t be a part of the =E2=80=9Cresources=E2=80=9D=
 or =E2=80=9Cclaims=E2=80=9D part of the request, but instead as its own =
top-level member, like it is in the OIDC protocol today. The main reason =
for this is the nature of the OIDC claims language: it specifies targets =
for the resulting data, and those targets cross different ways to return =
things. So it doesn=E2=80=99t actually affect just resources like the =
UserInfo Endpoint, or the ID Token, but both and potentially others out =
there. If your system supported such an extension, it could =
theoretically forego both the built-in =E2=80=9Cclaims=E2=80=9D and =
=E2=80=9Cresources=E2=80=9D parts of the request, and use the =
=E2=80=9Coidc_claims_query=E2=80=9D member (or whatever it would be =
called). This would let such an extension use the OIDC claims processing =
mechanism as it is today.

To me, this remains much more understandable, extensible, and =
clean.

While this may be more understandable =
to a developer just porting an app OIDC that only wants OIDC =
results, but I think it is more complicated as soon as the developer =
wants other results, which is likely what prompted the developer to =
use GNAP instead of ODIC.

I think it is easier to understand if all the claims are in =
one container, and all the authorizations are in another =
container.

If =
a developer wants access to some resources, some claims, and an OpenID =
Token, they are having to use "claims", "resources", and =
"oidc_claims_query".  Now the claims and access tokens are spread =
across multiple containers. There are some claims in the "claims" =
container, and some "claims" in the "oidc_claims_query" container. And =
is the access token response in "oidc_claims_query" the same as an =
access token response in "resources"? It would seem simpler if they =
were, and if all the access tokens came back in the same =
container.

Per =
Aaron's post that you have referred to, the developer can get sme bare =
claims directly in the response in the "claims" object, an ID Token that =
has the same or different claims, and if they want, an access token that =
they can call a user_info endpoint to get the same, or different =
claims.

For =
example, an enterprise app client may want an ID Token with the email =
address, bare claims for the user's name and a URI to a profile photo, =
and an access token to query which groups a user belongs to.

We are still =
re-using the OIDC claims, but we are not mixing claims and =
authorizations.

/Dick


[1] https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

3D""=E1=90=A7

3D""=E1=90=A7

=

--Apple-Mail=_73758EB5-19BD-464D-8860-F312D367F9EB--


From nobody Fri Jul 10 06:06: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 18BCA3A0C67 for ; Fri, 10 Jul 2020 06:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level: 
X-Spam-Status: No, score=-1.619 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.276, 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 kz2AIM8z4KLX for ; Fri, 10 Jul 2020 06:06:29 -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 34EAE3A096E for ; Fri, 10 Jul 2020 06:06:28 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d14 with ME id 1R6Q2300R4FMSmm03R6R2x; Fri, 10 Jul 2020 15:06:26 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 10 Jul 2020 15:06:26 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt 
Cc: "txauth@ietf.org" 
References:   
From: Denis 
Message-ID: <325bc015-1547-c56c-c1fe-67a97165785d@free.fr>
Date: Fri, 10 Jul 2020 15:06:23 +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="------------83A657885843F6D818CFB3F5"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 10 Jul 2020 13:06:32 -0000

This is a multi-part message in MIME format.
--------------83A657885843F6D818CFB3F5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Dick,

> Hi Denis, thanks for sharing the model. I don't fully understand what 
> is going on, questions inserted:
Responses are inserted.
>
> FWIW: having paragraphs start with the step number (1), (2) etc. would 
> make it easier to map between the description and the diagram.
>
> On Thu, Jul 9, 2020 at 3:26 AM Denis  > wrote:
>
>     This is a new thread.
>
>     Preamble: This model is quite different from the XAuth model.
>     In particular, a RO has no relationship with any AS and a Client
>     does not need to be associated with any AS prior to any access to
>     a RS.
>
>     A key point of this model is that the user's consent is handled
>     locally by the Client and hence no AS nor RS is handling a man
>     machine interface
>     for the user consent. This allows to support locally the user
>     consent for multiple ASs while keeping all ASs ignorant about the
>     choices of the user
>     made for accessing a particular RS.
>     *
>
>     **+--------++------------+
>     |User||Resource|
>     ||| Owner (RO) |
>     +--------++------------+
>     |\|
>     |\|
>     |\|
>     |\|
>     +-----------++---------------++------------+
>     ||---->| Authorization |||
>     || (2) |Server (AS)|||
>     ||<----||||
>     |Client|+---------------+||
>     ||-------------------------->|Resource|
>     |User|(1)|Server|
>     |Consent|<--------------------------|(RS)|
>     |element|||
>     ||-------------------------->||------>
>     ||(3)||(4)
>     ||<--------------------------||<------
>     +-----------++------------+
>     *
>     The flow of operations is as follows:
>
>     The Client (which may have been previously authenticated using FIDO)
>
> Which party has the client authenticated to? The client authenticating 
> with FIDO is confusing to me. FIDO is usually how a user authenticates.

If the user has previously opened a user account with the RS using FIDO, 
then the client may be authenticated by the RS using FIDO.
In such a case, the user is already known to the RS under a pseudonym 
specific to the RS. It may (or may not) have previously presented access 
tokens
to that RS.

> contacts the RS and after some dialogue with the RS selects an operation
> How does the client know which RS to contact?

For a private usage, the user may use DuckDuckGo, while for business he 
may use an application from his company which lists various services
available in the context of his job or his position. Some services may 
be freely available to all the employees of the company with any 
authentication,
e.g. the phone book of the employees may be freely available on the 
intranet of the company, while some other services may require the user
to authenticate to the AS from the company.

> that it wants to perform on the RS (1a). Note that it may also 
> indicate directly the operation that it wants to perform on the RS 
> without any prior dialogue.
>
>     In return (1b), the RS informs the Client about which attributes
>     are needed by the RS for performing the requested operation and
>     from which Attributes Servers
>     they may be obtained.
>
> (1a) and (1b) are not labeled. There is only (1)

(1a) is the first exchange for (1) with the arrow from left to right, 
while (1b) is the response with the arrow from right to left.
The same applies to the other exchanges i.e. (2) , (3) and (4).

>
>     This information is specifically marked to indicate that it shall
>     be handled by the "User Consent element" from the Client.
>
> Why? What is the significance of this? Which information is marked?

In the response, a specific identifier or a magic number is used to 
indicate the start and the length of the information block
to be sent to the "User Consent element" supported by the Client.

> The presentation of that information is up to the man machine 
> interface supported by the "User Consent element" from the Client.
>
>
> Which information?

The attributes that are needed by the RS for performing a requested 
operation and from which Attributes Servers they may be obtained.

>
>     The user can see which attributes are requested by the RS for
>     performing the requested operation and, if it consents, the Client
>     contacts one or more
>     appropriate Authorization Servers (2a).
>
> How does the client know which AS(s) to contact?

For each AS trusted by the RS to perfom a given operation, the RS should 
indicate a user-friendly name and a URL of the AS.

>     The user consent is hence captured locally by the Client (i.e.
>     there is no dialogue with any AS nor any RS).
>
>
> No dialogue with who? The client is calling the AS is it not?

For the user consent, there is no external call since it is handled 
locally. Afterwards, there is a call to the AS(s) selected by the user.

>
>     When the Client got the access tokens from these authorization
>     servers (2b), it sends all of them in a single request to the RS (3a).
>
>
> So the RS must trust the AS that issued the tokens. And the AS must 
> trust the Client to have gathered consent.
Theses two assertions are correct.
> And the AS must have a relationship with the user.

Only when the user chooses one AS while giving its consent, then the 
user must have a relationship with the selected AS.

> It is unclear what role the RO is playing in this though. The RO and 
> RS look to be the same entity from all the other parties.

A RO, as indicated on the figure, has only a relationship with one RS: 
it has no relationship with any AS.
The RS trusts the AS but the AS does not know which RSs are trusting it.

>
> From my current understanding, at a high level, this looks like it is 
> supported by GNAP with the addition of the discovery step (1).

Well, it is fairly different :

    1) The first major difference is that there is no arrow between the
    RO and the AS. No protocol or "out-of-bands" means are necessary.

    2) The second major difference is that there is no arrow between the
    AS and the RS. No protocol is necessary.

    3) The third major difference is that the AS does not know any RS.
    Note: for backward compatibility reasons, an exception might exist
    for "old" Auth 2.0 ASs.

    4) The fourth major difference is that the XAuth spec. is rather
    vague to describe when and by who the user consent is captured:
         XAuth states on page 4: "User consent is /often /required at
    the GS". In that case, the GS is able to act as Big Brother. No
    other case is described.

    5) The fifth major difference is that the data that is transferred
    to a "User Consent Element" to capture the user consent. That data
    can be standardized.
         Moreover, it will also be possible to standardize the dialogue
    between the RO and the RS. The RO will then be able to manage
    remotely the authorization tables.
         See my email sent on June 6, with the following subject:
    "Support of FIDO and data minimization by RSs".

    6) Another difference is the following: since there is no
    interaction between the RO and the AS, "authorizations from the RO"
    as described in XAuth do not exist. 

> There have been a number of proposals for doing this discovery, and 
> perhaps now there are enough use cases to look at standardizing 
> something.
> No interaction is needed between the AS and the User as the Client is 
> providing enough "information" in the user object of the Grant Request
> to satisfy the AS releasing the access tokens.
Not sure I understand correctly this last sentence.
>
> Perhaps as I understand the model in more detail I will understand 
> what is missing from GNAP (besides the discovery step).

It would be hard to say "what is missing" from XAuth since the 
foundations are not the same.

In order to compare different architectures, there is the need to start 
with the trust relationships.
Unfortunately, the word "trust" is absent in the main body of 
draft-hardt-xauth-protocol-12. Hence,
the description of the trust relationships is missing.

Denis

>
> /Dick
>
> (I've skipped reviewing the delegation use case below until I 
> understand the simple use case)
>
>
>     End of the story for a simple access
>
>
>     Start of a subsequent story for a delegation case
>
>     Let us now suppose that the RS is unable to fulfil the request by
>     its own and that it needs to contact another RS. RS1 contacts RS2
>     (4a) and indicates the operation
>     that it wants to perform on RS2 (that operation may not be the
>     same as the original operation). In return (4b), RS2 informs RS1
>     about which attributes are needed
>     by RS2 for performing the requested operation and from which
>     Attributes Servers they may be obtained. RS1 forwards that
>     information to the Client.
>
>     This information is marked to indicate that it shall be handled by
>     the "User Consent element" from the Client. The presentation of
>     that information is up to the man machine
>     interface from the Client. The user can see which attributes are
>     requested by RS2 for performing the new requested operation and,
>     if it consents, the Client contacts one or more
>     appropriate Authorization Servers. The user consent is hence
>     captured locally by the "User Consent element" from the Client.
>     (i.e. there is no dialogue with any AS, nor RS1, nor RS2).
>
>     When the Client got the access token(s) from the authorization
>     server(s), it sends all of them in a single request to RS1. RS1
>     then forwards the additional access token(s) to RS2.
>
>
>     Some observations:
>
>     The user nor the Client are linked with any particular AS. A user
>     may use today an AS of the Bank of America and may change tomorrow
>     to the Bank of Missouri.
>     As soon as he will be registered with the Bank of Missouri, he
>     will be able to get access tokens from the AS of the Bank of
>     Missouri. The AS of Bank of America
>     has not been able to know where its access tokens have been used.
>     This will be the same for AS of the Bank of Missouri. There is no
>     need for any direct dialogue
>     between any AS and any RS at the time a client is making an
>     access. There is no need for any RO to contact any AS.
>
>     This model has been constructed following a "Privacy by Design"
>     approach.
>
>     Denis
>
>     -- 
>     Txauth mailing list
>     Txauth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/txauth
>
> ᐧ



--------------83A657885843F6D818CFB3F5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Dick,

    


    

    

      
      

        
Hi Denis, thanks for sharing the model. I don't
          fully understand what is going on, questions inserted:

      

    

    Responses are inserted.

    

      

        

          


          

          
FWIW: having paragraphs start with the step number (1),
            (2) etc. would make it easier to map between the description
            and the diagram.

        

        

        

          
On Thu, Jul 9, 2020 at 3:26
            AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              

                
This is a new thread.

                    

                    Preamble: This model is quite different from the
                    XAuth model. 

                    In particular, a RO has no relationship with any AS
                    and a Client does not need to be associated with any
                    AS prior to any access to a RS.

                    

                    A key point of this model is that the user's consent
                    is handled locally by the Client and hence no AS nor
                    RS is handling a man machine interface 

                    for the user consent. This allows to support locally
                    the user consent for multiple ASs while keeping all
                    ASs ignorant about the choices of the user 

                    made for accessing a particular RS.

                    

                      

                            
                        +--------+                          
                        +------------+

                               |  User 
                        |                           | 
                        Resource  |

                               |        |                          
                        | Owner (RO) |

                               +--------+                           +------------+

                                   |      \                             
                        |

                                   |       \                            
                        |

                                   |        \                           
                        |

                                   |         \                          
                        |

                            +-----------+     +---------------+    
                        +------------+

                            |           |---->|
                        Authorization |     |           
                        |

                            |           |
                        (2) |  Server (AS)  |    
                        |            |

                            |           |<----|              
                        |     |            |

                            |  Client  
                        |     +---------------+    
                        |            |

                            |           |-------------------------->| 
                        Resource  |

                            |   User   
                        |           (1)            
                        |   Server   |

                            |  Consent 
                        |<--------------------------|   
                        (RS)    |

                            |  element 
                        |                           |           
                        |

                            |           |-------------------------->|           
                        |------>

                            |           |          
                        (3)             |           
                        |  (4)

                            |           |<--------------------------|           
                        |<------

                            +-----------+                          
                        +------------+

                    

                    The flow of operations is as follows:

                    

                    The Client (which may have been previously
                    authenticated using FIDO) 

              

            

          

          
Which party has the client authenticated to? The client
            authenticating with FIDO is confusing to me. FIDO is usually
            how a user authenticates.

        

      

    

    
If the user has previously opened a user account with the RS
      using FIDO, then the client may be authenticated by the RS using
      FIDO.

      In such a case, the user is already known to the RS under a
      pseudonym specific to the RS. It may (or may not) have previously
      presented access tokens 

      to that RS.

    

    

      

        

          
 contacts the RS and after some
              dialogue with the RS selects an operation 

            

          
How does the client know which RS to contact?

        

      

    

    
For a private usage, the user may use DuckDuckGo, while for
      business he may use an application from his company which lists
      various services 

      available in the context of his job or his position. Some services
      may be freely available to all the employees of the company with
      any authentication,

      e.g. the phone book of the employees may be freely available on
      the intranet of the company, while some other services may require
      the user 

      to authenticate to the AS from the company.

    

      

        

          
 that it wants to perform on the RS
              (1a). Note that it may also indicate directly the
              operation that it wants to perform on the RS without any
              prior dialogue. 

            

          

            

              

                
 In return (1b), the RS informs
                    the Client about which attributes are needed by the
                    RS for performing the requested operation and from
                    which Attributes Servers 

                    they may be obtained. 

                  

              

            

          

          
(1a) and (1b) are not labeled. There is only (1) 

          

        

      

    

    
(1a) is the first exchange for (1) with the arrow from left to
      right, while (1b) is the response with the arrow from right to
      left. 

      The same applies to the other exchanges i.e. (2) , (3) and (4).

    

    

      

        

          

            

              

                
 

                    This information is specifically marked to indicate
                    that it shall be handled by the "User Consent
                    element" from the Client. 

                  

              

            

          

          
Why? What is the significance of this? Which information
            is marked?

        

      

    

    
In the response, a specific identifier or a magic number is used
      to indicate the start and the length of the information block  

      to be sent to the "User Consent element"
        supported by the Client.

    

    

      

        

          

            
The presentation of that information
                is up to the man machine interface supported by the
                "User Consent element" from the Client. 

              

          

          


          

          
Which information? 

          

        

      

    

    
The attributes that are needed by the RS for
        performing a requested operation and from which Attributes
        Servers they may be obtained.

    

      

        

          

            

              

                
 

                    The user can see which attributes are requested by
                    the RS for performing the requested operation and,
                    if it consents, the Client contacts one or more 

                    appropriate Authorization Servers (2a). 

              

            

          

          
How does the client know which AS(s) to contact?

        

      

    

    
For each AS trusted by the RS to perfom a given operation, the RS
      should indicate a user-friendly name and a URL of the AS. 

    

    

      

        

          

            

              

                
The user consent is hence captured
                    locally by the Client (i.e. there is no dialogue
                    with any AS nor any RS).

                  

              

            

          

          


          

          
No dialogue with who? The client is calling the AS is it
            not? 

          

        

      

    

    
For the user consent, there is no external call since it is
      handled locally. Afterwards, there is a call to the AS(s) selected
      by the user.

    

      

        

          

            

              

                
 

                    When the Client got the access tokens from these
                    authorization servers (2b), it sends all of them in
                    a single request to the RS (3a).

                  

              

            

          

          


          

          
So the RS must trust the AS that issued the tokens. And
            the AS must trust the Client to have gathered consent.

        

      

    

    Theses two assertions are correct.

    

      

        

          
 And the AS must have a relationship with the user. 

        

      

    

    
Only when the user chooses one AS while giving its consent, then
      the user must have a relationship with the selected AS.

    

      

        

          
It is unclear what role the RO is playing in this though.
            The RO and RS look to be the same entity from all the other
            parties.

        

      

    

    
A RO, as indicated on the figure, has only a relationship with
      one RS: it has no relationship with any AS. 

      The RS trusts the AS but the AS does not know which RSs are
      trusting it.

    

      

        

          


          

          
From my current understanding, at a high level, this
            looks like it is supported by GNAP with the addition of the
            discovery step (1). 

        

      

    

    
Well, it is fairly different : 

    

    

      
1) The first major difference is that there is no arrow between
        the RO and the AS. No protocol or "out-of-bands" means are
        necessary. 

      

      
2) The second major difference is that there is no arrow
        between the AS and the RS. No protocol is necessary. 

      
3) The third major difference is that the AS does not know any
        RS. Note: for backward compatibility reasons, an exception might
        exist for "old" Auth 2.0 ASs.

      

      
4) The fourth major difference is that the XAuth spec. is
        rather vague to describe when and by who the user consent is
        captured: 

            XAuth states on page 4: "User consent is often required
        at the GS". In that case, the GS is able to act as Big Brother.
        No other case is described.

      

      5) The fifth major difference is that the data that is transferred
      to a "User Consent Element" to capture the user consent. That data
      can be standardized. 

          Moreover, it will also be possible to standardize the dialogue
      between the RO and the RS. The RO will then be able to manage
      remotely the authorization tables.

          See my email sent on June 6, with the following subject:
      "Support of FIDO and data minimization by RSs".

      

      6) Another difference is the following: since there is no
      interaction between the RO and the AS, "authorizations from the
      RO" as described in XAuth do not exist.
         

    

      

        

          
There have been a number of proposals for doing this
            discovery, and perhaps now there are enough use cases to
            look at standardizing something.  

            No interaction is needed between the AS and the User as the
            Client is providing enough "information" in the user object
            of the Grant Request 

            to satisfy the AS releasing the access tokens. 

          

        

      

    

    Not sure I understand correctly this last sentence.

    

      

        

          


          

          
Perhaps as I understand the model in more detail I will
            understand what is missing from GNAP (besides the discovery
            step).

        

      

    

    
It would be hard to say "what is missing" from XAuth since the
      foundations are not the same.

    
In order to compare different architectures, there is the need to
      start with the trust relationships. 

      Unfortunately, the word "trust" is absent in the main body of
      draft-hardt-xauth-protocol-12. Hence, 

      the description of the trust relationships is missing.

    

    
Denis

    

      

        

          


          

          
/Dick

          


          

          
(I've skipped reviewing the delegation use case below
            until I understand the simple use case)

          


          

          

            

              

                
 

                    End of the story for a simple access

                
 

                    Start of a subsequent story for a delegation case

                    

                    Let us now suppose that the RS is unable to fulfil
                    the request by its own and that it needs to contact
                    another RS. RS1 contacts RS2 (4a) and
                    indicates the operation 

                    that it wants to perform on RS2 (that operation may
                    not be the same as the original operation). In
                    return (4b), RS2 informs RS1 about which attributes
                    are needed 

                    by RS2 for performing the requested operation and
                    from which Attributes Servers they may be obtained.
                    RS1 forwards that information to the Client. 

                    

                    This information is marked to indicate that it shall
                    be handled by the "User Consent element" from the
                    Client. The presentation of that information is up
                    to the man machine 

                    interface from the Client. The user can see which
                    attributes are requested by RS2 for performing the
                    new requested operation and, if it consents, the
                    Client contacts one or more 

                    appropriate Authorization Servers. The user consent
                    is hence captured locally by the "User Consent
                    element" from the Client. (i.e. there is no dialogue
                    with any AS, nor RS1, nor RS2). 

                    

                    When the Client got the access token(s) from the
                    authorization server(s), it sends all of them in a
                    single request to RS1. RS1 then forwards the
                    additional access token(s) to RS2.

                    

                    

                    Some observations: 

                    

                    The user nor the Client are linked with any
                    particular AS. A user may use today an AS of the
                    Bank of America and may change tomorrow to the Bank
                    of Missouri. 

                    As soon as he will be registered with the Bank of
                    Missouri, he will be able to get access tokens from
                    the AS of the Bank of Missouri. The AS of Bank of
                    America 

                    has not been able to know where its access tokens
                    have been used. This will be the same for AS of the
                    Bank of Missouri. There is no need for any direct
                    dialogue 

                    between any AS and any RS at the time a client is
                    making an access. There is no need for any RO to
                    contact any AS.

                
This model has been constructed
                    following a "Privacy by Design" approach.

                Denis

              

            

            -- 

            Txauth mailing list

            Txauth@ietf.org

            https://www.ietf.org/mailman/listinfo/txauth

          

        

      

      
ᐧ

    

    


    

  


--------------83A657885843F6D818CFB3F5--


From nobody Fri Jul 10 07:06: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 6EF123A0F01 for ; Fri, 10 Jul 2020 07:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.619
X-Spam-Level: 
X-Spam-Status: No, score=-0.619 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.276, 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 bvlIwgsTBO_9 for ; Fri, 10 Jul 2020 07:05:54 -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 A93B23A0D01 for ; Fri, 10 Jul 2020 07:05:04 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d14 with ME id 1S522300B4FMSmm03S528o; Fri, 10 Jul 2020 16:05:02 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 10 Jul 2020 16:05:02 +0200
X-ME-IP: 86.238.65.197
To: Justin Richer 
Cc: Dick Hardt , txauth@ietf.org
References:  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>
From: Denis 
Message-ID: <437457fa-54bc-4001-c00e-b3067cfcdb87@free.fr>
Date: Fri, 10 Jul 2020 16:04: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
In-Reply-To: <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>
Content-Type: multipart/alternative; boundary="------------7255F332E568B62442703DFC"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 10 Jul 2020 14:06:04 -0000

This is a multi-part message in MIME format.
--------------7255F332E568B62442703DFC
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Justin,

I dare to jump into this dialogue. I have two closely related questions:

    1) What kind of polymorphism do you intent to support ?
    2) What are the basic reasons for supporting "polymorphism" ?

Some help: Wikipedia states 
(https://en.wikipedia.org/wiki/Polymorphism_(computer_science)) :

    In programming languages and type theory, polymorphism is the
    provision of a single interface to entities of different types
    or the use of a single symbol to represent multiple different types.

    The most commonly recognized major classes of polymorphism are:

      *      Ad hoc polymorphism: defines a common interface for an
        arbitrary set of individually specified types.
      *      Parametric polymorphism: when one or more types are not
        specified by name but by abstract symbols that can represent any
        type.
      *      Subtyping (also called subtype polymorphism or inclusion
        polymorphism): when a name denotes instances of many different
        classes
             related by some common superclass.

Before answering to these two questions, please consider the following 
observations that follow.

> Yes, the core idea is to not have to parse an assertion to get back 
> the core authentication information, which consists of an identifier
> (iss/sub pair in OIDC, but could be a number of things). Sometimes the 
> client is going to want the rest of the identity information,
> but If the user’s logged into the client before, the client has likely 
> cached that info and probably won’t need it, and sending it would be
> a violation of privacy principles.. The client would want the info 
> pretty much just in these cases:
>
>  1. The client has never seen the user before.
>  2. The user’s information has been updated since the last time the 
> client saw it.
>
> Now for case (1), how would the client know if it wants to request the 
> user’s profile info or not, since it doesn’t know who the user is? And 
> the AS won’t know
> if client is going to want the profile info, since the AS won’t know 
> if the client has the user’s info or not. Sure, the AS might have seen 
> that client and that
> user combo previously, but it doesn’t know if the client needs an update.

For cases (1) and (2), as long as the user has not yet decided to 
attempt to reach a RS, the client has nothing to do.

  * When the user selects a RS and if FIDO is supported, the client
    should check whether the user has a FIDO account with that RS.
    If he does, it should connect transparently to the RS.  If he does
    not have a FIDO account with that RS, the client should check
    whether the RS supports FIDO or some attributes from some AS are
    requested. If FIDO is supported by the RS, it should propose
    to the user to create a FIDO account. If some attributes from some
    AS are requested, it should check whether the user has
    an account with one or more of these ASs. If he has, the user should
    select the appropriate AS and after his consent the client
    should contact that AS to obtain the requested attributes in order
    to get them inside an access token. Finally the client should send
    the access token to the RS. What happens next depends upon what the
    user is willing to do.

  * When the user selects a RS and if FIDO is NOT supported, the client
    should connect to the RS and the RS should report to the client
    the means of authentication that it supports. This may be FIDO
    and/or some access tokens with specific attributes from specific ASs.
    If the user believes that the requested authentication means is
    adequate according to what he wants to do on the RS, he may then /
    locally /choose the most appropriate means.

>
> And for (2), the client won’t know if the user’s info has been updated 
> or not because it doesn’t know who the user is yet.
> If the AS can provide some time of updated stamp to the client, the 
> client can pull the new info when it needs it.
>
> If you ignore both of these cases and put all the user information 
> inline with the main request/response, you end up in a situation
> where the client always requests everything and the server always 
> provides everything, since you can’t be sure you’re not in situation
> (1) or (2) ahead of time.

The RS should inform the client about what it needs to present, at 
latest at the time of the first access attempt.
As long as the client has not yet attempted to reach a RS, the client 
has nothing to do.

> This is really what I mean about the two-stage identity protocol.
> In the first stage, you push the bare minimum of what you need to get 
> the user known to the client.
> In the second stage, the client uses its access token to call an API 
> to get whatever else it needs to know about the user.

Since the RS is not yet identified, the AS(s) that is/are trusted by the 
RS is/are still unknown.
The client should not contact any AS before it knows which RS the user 
is willing to access.

Last questions:

Since these two stages should not happen, why is "polymorphism" really 
or still needed ? If yes, for which purpose(s) ?

Denis

> This API could be an OIDC UserInfoEndpoint, a SCIM resource, a FHIR 
> resource, or any number of other user APIs, and standardizing that 
> information is not what GNAP should be focused on. OIDC does a really 
> good job of letting developers log people in using this kind of 
> protocol. While it’s possible to cram everything into an ID token on 
> every request, there’s no need for it, and it’s likely a bad pattern 
> to follow.
>
> I’m sorry that you are surprised by my stance, but it hasn’t changed 
> since I helped write the section of the charter that you quoted below. 
> A big reason that I chose that wording was to support this use case 
> but not to go in depth with an identity protocol, which I never really 
> wanted us to do. However, it seems as soon as “identity” was brought 
> up previously, people immediately jumped into talking about a full 
> stack of user attributes and profile information. That wasn’t my 
> intent in talking about identity, and I don’t think it’s something 
> GNAP ought to do, at least not on its own.
>
> I do think there’s room for us to provide identifiers alongside the 
> access token, so that’s there. There was stated interest in providing 
> signed assertions as well, so I made sure that was enumerated for 
> those who want to do such work. And I think it makes sense for us to 
> provide a way to describe what kinds of things I want to get from an 
> access token by defining a general purpose syntax for describing those 
> things (notably, as a combination of reference strings and 
> multi-dimensional objects). With these two, we can get most of what we 
> need for a basic login system. Anything beyond that is going to need 
> user profiles, authentication contexts, session control, and a lot of 
> other identity-protocol stuff that GNAP shouldn’t be focusing on. We 
> should keep it in mind as we build GNAP, but I think that like OIDC 
> all that important extra stuff should be built separately. To me, 
> that’s what not defining schemas and formats means.
>
> I don’t see any conflict with the charter here, and I’m surprised that 
> you do.
>
>  — Justin
>
>> On Jul 9, 2020, at 5:55 PM, Dick Hardt > > wrote:
>>
>> Thanks for the clarifications. I had chatted to Aaron about his post, 
>> and my understanding is not what is in the post on a closer read. My 
>> takeaway was why make the developer parse the ID_Token, why not give 
>> them the information directly.
>>
>> I have interpreted the userinfo and id_token top level elements to be 
>> how the client wanted the query results, not part of the query. I had 
>> thought my example and definition of a Grant Response in XAuth [1] 
>> would have clearly communicated what I meant, but I see that I should 
>> call out that userinfo in XAuth returns the claims, rather than 
>> userinfo in OIDC returns an access token for the claims. Given GNAP 
>> is more expressive, and learning from the past, I'm proposing we 
>> offer the developer (and AS) a choice in how to acquire the claims.
>>
>> While acquiring user information through an API at any time is 
>> appropriate in some use cases, in others why not give the client the 
>> info it needs right away rather than having to make another API call 
>> to get it? This would be appropriate when the user is making a 
>> purchase and wanting to provide shipping information. The user does 
>> not want to authorize the client to fetch their shipping address in 
>> the future.
>>
>> I'm surprised by your stance:
>>
>>     My stance is that we allow the client to ask for a small set of
>>     identifiers about the user, or even just ask to “identify the
>>     user”, and leave everything else to a higher level identity
>>     protocol. I do not think that having an identity and profile
>>     query/response language at the core of GNAP is a good idea, and
>>     it’s certainly not in our charter.
>>
>>
>> Since the charter states:
>>
>>     The group is chartered to develop mechanisms for conveying
>>     identity information
>>     within the protocol including existing identifiers (such as email
>>     addresses,
>>     phone numbers, usernames, and subject identifiers) and assertions
>>     (such as
>>     OpenID Connect ID Tokens, SAML Assertions, and Verifiable
>>     Credentials). The
>>     group is not chartered to develop new formats for identifiers or
>>     assertions,
>>     nor is the group chartered to develop schemas for user
>>     information, profiles,
>>     or other identity attributes.
>>
>>
>> More than identifiers about the user are clearly in scope of the WG 
>> charter, as are mechanisms for conveying identity information. Your 
>> stance and the charter look in conflict to me. What am I missing?
>>
>> /Dick
>>
>> [1] https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-4.1
>>
>>
>>
>> On Thu, Jul 9, 2020 at 1:04 PM Justin Richer > > wrote:
>>
>>     In Aaron’s post he doesn’t talk about how the request would be
>>     made, just what the response could look like, and we are talking
>>     about how to request that. Aaron’s post specifically calls out
>>     that this is just an identifier for the user and states:
>>
>>         If the application needs to know profile information about
>>         the user, it can get that from the userinfo endpoint using
>>         the access token it just obtained.
>>
>>
>>     And I think that’s a good design pattern to follow. This isn’t
>>     “userinfo” being returned alongside the access token.
>>
>>     The top level functionality of the OIDC claims query language is
>>     this:
>>
>>
>>         The top-level members of the Claims request JSON object are:
>>
>>         userinfo
>>         OPTIONAL. Requests that the listed individual Claims *be
>>         returned from the UserInfo Endpoint*. If present, the listed
>>         Claims are being requested to be added to any Claims that are
>>         being requested using scope values. If not present, the
>>         Claims being requested from the UserInfo Endpoint are
>>         only those requested using scope values.
>>         When the userinfo member is used, the request MUST also use
>>         a response_type value that results in an *Access Token being
>>         issued to the Client for use at the UserInfo Endpoint*.
>>
>>         id_token
>>         OPTIONAL. Requests that the listed individual Claims be
>>         returned in the ID Token. If present, the listed Claims are
>>         being requested to be added to the default Claims in the ID
>>         Token. If not present, the default ID Token Claims are
>>         requested, as per the ID Token definition in Section 2 and
>>         per the additional per-flow ID Token requirements in
>>         Sections 3.1.3.6, 3.2.2.10, 3.3.2.11, and 3.3.3.6..
>>
>>
>>     Since you had re-used the “userinfo” and “id_token” top-level
>>     claims, I had assumed that they meant the same thing as in the
>>     OIDC spec. It’s clear to me, now, that this isn’t what you meant,
>>     but this is why I’m saying you’re not using the whole query
>>     language.
>>
>>     There are proposed extensions to the OIDC claims query that would
>>     put returned data into a different place[1], and so it would be
>>     possible to use the claims structures to handle this. But at that
>>     point if the goal is just to use the internal query format, then
>>     I think that we can do better using … polymorphic JSON. :)
>>
>>     My stance is that we allow the client to ask for a small set of
>>     identifiers about the user, or even just ask to “identify the
>>     user”, and leave everything else to a higher level identity
>>     protocol. I do not think that having an identity and profile
>>     query/response language at the core of GNAP is a good idea, and
>>     it’s certainly not in our charter.
>>
>>      — Justin
>>
>>     [1]
>>     https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ defines
>>     a “credential’ target.
>>
>>>     On Jul 9, 2020, at 3:29 PM, Dick Hardt >>     > wrote:
>>>
>>>     Yes. Which is why I referred to Aaron's post originally which
>>>     calls out for returning plain text claims.
>>>
>>>     I don't really understand what you mean by "OIDC claims query
>>>     language". The claims mean the same thing. And I was also
>>>     reusing the modifiers such as {"essential": true}. What top
>>>     level functionality are you referring to?
>>>
>>>     On Thu, Jul 9, 2020 at 12:21 PM Justin Richer >>     > wrote:
>>>
>>>         Ah, so you’re saying that the “userinfo” claims would be
>>>         returned directly? I didn’t realize that you had intended to
>>>         change how the OIDC claims query language functioned in your
>>>         examples, and had assumed it would work the same was as the
>>>         spec you were referencing. Your example of splitting it up
>>>         makes that more clear. Though I would argue at that point,
>>>         you’re creating a new query language since you’re not using
>>>         the top-level functionality from ODIC’s definition.
>>>
>>>          — Justin
>>>
>>>>         On Jul 9, 2020, at 3:15 PM, Dick Hardt
>>>>         > wrote:
>>>>
>>>>         You are jumping to many conclusions below. Let me break
>>>>         down the proposal into some bite size chunks.
>>>>
>>>>         The developer would like to get some plain text OIDC claims
>>>>         about the user:
>>>>
>>>>           "claims":{
>>>>         "oidc": {
>>>>         "userinfo" : {
>>>>           "name" : { "essential" : true },
>>>>           "photo" : { "essential" : false }
>>>>                     },
>>>>
>>>>         The developer would like to get an OIDC ID Token:
>>>>
>>>>           "claims":{
>>>>         "oidc": {
>>>>         "id_token" : {
>>>>           "email"      : { "essential" : true },
>>>>         "email_verified" : { "essential" : true }
>>>>                     }
>>>>           }
>>>>
>>>>         The developer would like to get an access token to acquire
>>>>         OIDC claims:
>>>>
>>>>         "authorizations": {
>>>>         "type":"oidc",
>>>>         "claims": ["name", "picture"]
>>>>             }
>>>>
>>>>         The developer would like to get an access token to access
>>>>         photos:
>>>>
>>>>         "authorizations": {
>>>>         "type":"oauth_scope",
>>>>         "scope": "read_photos"*
>>>>             }
>>>>
>>>>         The developer would like to get some VC claims:
>>>>
>>>>         "claims" {
>>>>               "vc": {
>>>>         "some_vc": "query_mechanism"
>>>>                 }
>>>>         }
>>>>
>>>>         The developer would like to do all of the above at once:
>>>>
>>>>         {
>>>>         "authorizations": {
>>>>         "userinfo": {
>>>>         "type":"oidc",
>>>>         "claims": ["name", "picture"]
>>>>                 },
>>>>         "photos": {
>>>>         "type":"oauth_scope",
>>>>         "scope": "read_photos"
>>>>                 }
>>>>             },
>>>>             "claims":{
>>>>         "oidc": {
>>>>         "id_token" : {
>>>>           "email"      : { "essential" : true },
>>>>         "email_verified" : { "essential" : true }
>>>>                     },
>>>>         "userinfo" : {
>>>>           "name" : { "essential" : true },
>>>>           "photo" : { "essential" : false }
>>>>                     }
>>>>                 },
>>>>             "vc": {
>>>>         "some_vc": "query_mechanism"
>>>>                 }
>>>>             }
>>>>         }
>>>>
>>>>         In the results, the developer gets claims back in the
>>>>         response claims object, and access tokens etc. back in the
>>>>         authorizations object. Just because an access token returns
>>>>         claims, it is still an access token.
>>>>
>>>>         Yes, the developer can't get a single access token that can
>>>>         both acquire OIDC claims, and access photos (there are
>>>>         separate tokens for each), but I would argue that
>>>>         separating the access is a positive security property, as a
>>>>         client component accessing the user profile has a token
>>>>         independent of the client component accessing photos. And
>>>>         at the AS, there is no requirement for the userinfo
>>>>         endpoint to take the same token as the photo endpoint.
>>>>
>>>>         Somewhat of a tangent, I'm thinking that
>>>>
>>>>           "claims":{
>>>>         "oidc": {
>>>>         "id_token" : {},
>>>>         "userinfo" : {}
>>>>                 },
>>>>
>>>>         is a little verbose, and:
>>>>
>>>>             "claims":{
>>>>         "oidc_token": {},
>>>>         "oidc_info": {}
>>>>             },
>>>>
>>>>         works better and makes it easier to distinguish support for
>>>>         ID tokens vs plain claims.
>>>>
>>>>         wrt. my position on reusing OIDC -- it has not changed. I
>>>>         have viewed the OIDC claims as the "query language". No
>>>>         need to reinvent that. We are creating a new protocol, so
>>>>         no need to use the OAuth or OIDC protocols.
>>>>
>>>>         * OAuth scopes could be a space separates string to be
>>>>         consistent with OAuth 2, or an array of strings so that it
>>>>         is more JSON like. I have no strong opinion.
>>>>
>>>>         scope.split(' ').forEach()
>>>>
>>>>         is not that much more complex than
>>>>
>>>>         scope.forEach()
>>>>
>>>>
>>>>
>>>>         On Thu, Jul 9, 2020 at 8:39 AM Justin Richer
>>>>         > wrote:
>>>>
>>>>             But this approach doesn’t keep things in their
>>>>             respective containers — you’ve explicitly got “claims”
>>>>             underneath the “authorizations” header, and you’ve got
>>>>             items that come back as rights associated with the
>>>>             access token (which should be “authorizations”) in the
>>>>             “userinfo” section under the “claims” header. And as
>>>>             far as I can tell, these two sections are redundant to
>>>>             each other. Everything is everywhere.
>>>>
>>>>             Additionally, this approach and syntax makes it
>>>>             difficult to combine different kinds of requests into
>>>>             one. One of OpenID Connect’s biggest draws, as I’m sure
>>>>             you recall, is that it could be combined with a request
>>>>             for non-OIDC resources. This was the real innovation
>>>>             that Twitter and Facebook’s identity APIs brought,
>>>>             access to more than just authentication, and what
>>>>             Google had tried to replicate with the awkward OpenID 2
>>>>             + OAuth 1 hybrid system. Taking a step back from the
>>>>             existing solutions of OpenID 2 and OAuth 1 let us, as
>>>>             the community, see the value in the pattern that became
>>>>             OIDC on top of OAuth 2.
>>>>
>>>>             Sure, you could say that the “oidc” type also can allow
>>>>             a “scopes” parameter, but what about a RAR style
>>>>             object, then? And what about when someone comes up with
>>>>             some new way to request access rights, or a VC-based
>>>>             query language? Does every “type” need to now know
>>>>             about every other “type” in order for an AS to be able
>>>>             to figure out how they go together? This seems like the
>>>>             protocol definition limiting what combinations the AS
>>>>             can handle, or what an RS might want to use.
>>>>
>>>>             My stance is that GNAP should have a way to query for
>>>>             rights in the access token (“authorizations” in xauth
>>>>             parlance) and identifiers for the user (“claims” in
>>>>             xauth parlance), and anything else should be an
>>>>             extension with potentially different models. The AS
>>>>             would process the “authorizations” equivalent (for the
>>>>             access token) alongside any other incoming query and
>>>>             then make a policy decision based on that.
>>>>
>>>>             I find it interesting that you are now saying we don’t
>>>>             need to use the OIDC request format when previously
>>>>             you’ve made it clear that you were in favor of pointing
>>>>             at external query languages, including their syntax.
>>>>             I’m glad to see that you’re now looking at things in a
>>>>             more flexible way, but I think it’s important that we
>>>>             be careful and conscientious about how we reference any
>>>>             external query languages in GNAP.
>>>>
>>>>              — Justin
>>>>
>>>>>             On Jul 8, 2020, at 6:55 PM, Dick Hardt
>>>>>             >
>>>>>             wrote:
>>>>>
>>>>>             Hey Justin,
>>>>>
>>>>>             Just because we are using OIDC claims, does not mean
>>>>>             we need to mimic the OIDC request and response.
>>>>>             I was envisioning a grant request could look as the
>>>>>             following (using XAuth syntax):
>>>>>
>>>>>             {
>>>>>             "authorizations": {
>>>>>             "type":"oidc",
>>>>>             "claims": ["name", "picture"]
>>>>>                 },
>>>>>                 "claims":{
>>>>>             "oidc": {
>>>>>             "id_token" : {
>>>>>               "email"      : { "essential" : true },
>>>>>             "email_verified" : { "essential" : true }
>>>>>                         },
>>>>>             "userinfo" : {
>>>>>               "name"     : { "essential" : true },
>>>>>               "picture"      : null
>>>>>                         }
>>>>>                     }
>>>>>                 }
>>>>>             }
>>>>>
>>>>>             Of course a developer could choose to only ask for a
>>>>>             subset of this.
>>>>>
>>>>>             Note the new authorization type of "oidc", that takes
>>>>>             "claims" rather than "scope".
>>>>>
>>>>>             This keeps all the authorizations and claims in their
>>>>>             respective request and response containers.
>>>>>
>>>>>             We had a thread months ago on the OIDC two stage
>>>>>             model, and I still fail to see why forcing that has
>>>>>             any advantage.
>>>>>
>>>>>             /Dick
>>>>>
>>>>>
>>>>>             On Wed, Jul 8, 2020 at 3:25 PM Justin Richer
>>>>>             > wrote:
>>>>>
>>>>>                 I’m glad that we can agree that there are a number
>>>>>                 of things in legacy protocols that are unfortunate
>>>>>                 side effects of the circumstances in which they
>>>>>                 were built. Space-separated scope strings, for
>>>>>                 instance, would fall in that category, as I’ve
>>>>>                 previously explained.
>>>>>
>>>>>                 A key point in the below: the OIDC “claims”
>>>>>                 request already mixes user claims (returned in an
>>>>>                 API) and authorization (to fetch user claims from
>>>>>                 an API), so that ship has sailed if you’re using
>>>>>                 it. It doesn’t make sense to have it under a
>>>>>                 “claims” or “authorizations” request, since it’s a
>>>>>                 query language that affects both. Maybe you’d call
>>>>>                 this another “unfortunate design”, but the context
>>>>>                 was about re-using an externally-defined query
>>>>>                 language that was not made for GNAP.
>>>>>
>>>>>                 My scenario was for someone who is already using
>>>>>                 “claims” and wants to keep using it. (The vast
>>>>>                 majority of OIDC implementations, in my
>>>>>                 experience, don’t use that feature, and it’s not
>>>>>                 even required to be implemented by the AS, but
>>>>>                 again we’re talking about using this feature as an
>>>>>                 example of an external query language — and there
>>>>>                 are others out there.) In GNAP, you should return
>>>>>                 claims directly in the response, and request
>>>>>                 specific elements from the APIs protected by the
>>>>>                 access token. These are separate things, and by
>>>>>                 design both XAuth and XYZ have put them into
>>>>>                 separate containers in the request. This is a good
>>>>>                 design, and so putting something that conflates
>>>>>                 these two aspects into one or the other of the
>>>>>                 containers is not a particularly good option, in
>>>>>                 my opinion.
>>>>>
>>>>>                 Additionally, though this is a bit of an aside and
>>>>>                 getting into the specifics of identity, the
>>>>>                 “claims” parameter of ODIC is a query language
>>>>>                 bound to the full user profile. It is my stated
>>>>>                 position that the items coming back from the AS
>>>>>                 should only be identifiers, and not full profile
>>>>>                 information. The reasoning is pretty simple: the
>>>>>                 client doesn’t know what profile information it
>>>>>                 needs until it knows who the user is, so putting
>>>>>                 that into a protected API like the UserInfo
>>>>>                 Endpoint makes much more sense than putting it
>>>>>                 into the immediate response, where it is not
>>>>>                 needed, because the client already knows it. The
>>>>>                 AS doesn’t know what the client needs to know,
>>>>>                 either, so it can’t determine what to fulfill.
>>>>>                 OIDC’s two-stage model makes sense, and GNAP
>>>>>                 should really only focus on enabling this.
>>>>>
>>>>>                  — Justin
>>>>>
>>>>>>                 On Jul 8, 2020, at 6:10 PM, Dick Hardt
>>>>>>                 >>>>>                 > wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>                 On Wed, Jul 8, 2020 at 1:02 PM Justin Richer
>>>>>>                 > wrote:
>>>>>>
>>>>>>                     On Jul 8, 2020, at 3:16 PM, Dick Hardt
>>>>>>                     >>>>>                     > wrote:
>>>>>>>
>>>>>>>                     I think representing the request as an array
>>>>>>>                     is simplistic, and complicated at the same
>>>>>>>                     time.
>>>>>>>
>>>>>>>                     On the simplistic front, as there is no
>>>>>>>                     clear mechanism for extending the request
>>>>>>>                     with properties that apply to all of the
>>>>>>>                     request.
>>>>>>
>>>>>>                     The elements of the array are taken as a set,
>>>>>>                     to be tied to the same resulting access
>>>>>>                     token. If one of those elements is defined,
>>>>>>                     by the AS and/or the RS’s it’s protecting, to
>>>>>>                     apply across some or all of the other
>>>>>>                     elements, then that’s up to the AS’s policy.
>>>>>>                     Much like the “openid” scope in OIDC, which
>>>>>>                     switches on all sorts of contextual stuff in
>>>>>>                     the request. So to handle something like
>>>>>>                     this, an AS can easily declare that a given
>>>>>>                     scope-style string or a given object property
>>>>>>                     applies to different parts of the request.
>>>>>>                     You don’t need to externalize it here.
>>>>>>
>>>>>>
>>>>>>                 I view the "openid" scope as an unfortunate
>>>>>>                 design as OIDC was constrained by building on top
>>>>>>                 of OAuth. (a problem I hoped to avert by having
>>>>>>                 "identity" in scope for GNAP) The "openid" scope
>>>>>>                 does not function as scope per se, and I think it
>>>>>>                 makes OIDC harder to understand as the "openid"
>>>>>>                 scope causes non-scope behavior.
>>>>>>
>>>>>>
>>>>>>                     Do you have a concrete use case that requires
>>>>>>                     that feature to be done in the way that you
>>>>>>                     describe? I am trying to separate the driving
>>>>>>                     use case from the proposed solutions to see
>>>>>>                     what the differences are.
>>>>>>
>>>>>>
>>>>>>                 Perhaps the client wants access to be HIPPA
>>>>>>                 compliant? The HIPPA compliance signal applies to
>>>>>>                 the scopes.
>>>>>>
>>>>>>                 Adding other properties to an object is a well
>>>>>>                 understood extension mechanism. Adding an
>>>>>>                 additional element to an array that does not act
>>>>>>                 like the other elements seems like a hack.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>                     Using JSON type polymorphism requires the AS
>>>>>>>                     to test each member of the array to
>>>>>>>                     determine if it is a string or an object.
>>>>>>>                     Only after detecting a RAR object does the
>>>>>>>                     AS know the client is making a RAR request.
>>>>>>
>>>>>>                     That’s correct — but the AS needs to parse
>>>>>>                     the whole resources request in order to
>>>>>>                     figure out what the client is asking for,
>>>>>>                     anyway, whether it’s by strings or objects or
>>>>>>                     whatever else might be defined by an
>>>>>>                     extension. Is there an argument for having an
>>>>>>                     AS do an early dispatch on a request before
>>>>>>                     it’s fully parsed everything?
>>>>>>
>>>>>>
>>>>>>                 Let me clarify, the code is looking at the type
>>>>>>                 of object that has been parsed.
>>>>>>
>>>>>>                 Determining if an item in an array is a scope or
>>>>>>                 a RAR object by looking at the type being either
>>>>>>                 a string or an object seems less clear than a
>>>>>>                 property of an object explicitly declaring the type.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>                     This also limits the request to be composed
>>>>>>>                     only of scope strings or RAR objects. I
>>>>>>>                     don't see how other strings or objects could
>>>>>>>                     be used in the array, so there is no clear
>>>>>>>                     extension point in the "resources" array for
>>>>>>>                     other query mechanisms.
>>>>>>
>>>>>>                     That’s not the case in XYZ since we aren’t
>>>>>>                     declaring that a string has to be an
>>>>>>                     OAuth2-style scope. It can be, but ultimately
>>>>>>                     it’s just a string that the AS can
>>>>>>                     understand. And the objects are just that —
>>>>>>                     objects. If the AS understands what the
>>>>>>                     object is, it can be a RAR object or it can
>>>>>>                     be something completely API-specific with
>>>>>>                     another query language entirely.
>>>>>>
>>>>>>
>>>>>>                 But the other query language would need a type
>>>>>>                 that has been reserved in the RAR name space for
>>>>>>                 there to be interop, so it effectively is a RAR
>>>>>>                 extension.
>>>>>>
>>>>>>                 There are query languages in other domains that
>>>>>>                 may not fit nicely into RAR such as a query for
>>>>>>                 medical records.
>>>>>>
>>>>>>                 Yes, the medical records could be yet another top
>>>>>>                 level property, but per below, I think that is
>>>>>>                 confusing.
>>>>>>
>>>>>>                     (Point, though: RAR already pretty much
>>>>>>                     allows this by letting them be extended
>>>>>>                     infinitely, a feature it inherits from XYZ)
>>>>>>
>>>>>>                     I’m proposing that we do the same thing with
>>>>>>                     GNAP: it’s an array of strings or objects and
>>>>>>                     each of those means the same thing,
>>>>>>                     “something the client is asking for”.
>>>>>>
>>>>>>>
>>>>>>>                     Just as RAR has a "type" property, I propose
>>>>>>>                     the "resources" ("authorizations" in XAuth)
>>>>>>>                     be an object, where the other properties are
>>>>>>>                     determined by the "type" property. This
>>>>>>>                     allows extensions to define new ways to
>>>>>>>                     query for an authorization rather than
>>>>>>>                     having to fit into scopes or RAR.
>>>>>>>
>>>>>>
>>>>>>                     It’s my stance that this is an unnecessary
>>>>>>                     limitation at this level. The objects within
>>>>>>                     the array should be typed, like RAR, but it
>>>>>>                     doesn’t make sense for the overall request to
>>>>>>                     be typed. Instead, there should be one “type"
>>>>>>                     of query in the core, what XYZ calls the
>>>>>>                     “resources” request. Other query languages
>>>>>>                     should be added as extensions either to the
>>>>>>                     RAR-style objects (by defining a type at that
>>>>>>                     level) or as a separate top-level member.
>>>>>>
>>>>>>                     For example, let’s take the OIDC “claims”
>>>>>>                     query language. My current thought is that
>>>>>>                     this really shouldn’t be a part of the
>>>>>>                     “resources” or “claims” part of the request,
>>>>>>                     but instead as its own top-level member, like
>>>>>>                     it is in the OIDC protocol today. The main
>>>>>>                     reason for this is the nature of the OIDC
>>>>>>                     claims language: it specifies targets for the
>>>>>>                     resulting data, and those targets cross
>>>>>>                     different ways to return things. So it
>>>>>>                     doesn’t actually affect just resources like
>>>>>>                     the UserInfo Endpoint, or the ID Token, but
>>>>>>                     both and potentially others out there. If
>>>>>>                     your system supported such an extension, it
>>>>>>                     could theoretically forego both the built-in
>>>>>>                     “claims” and “resources” parts of the
>>>>>>                     request, and use the “oidc_claims_query”
>>>>>>                     member (or whatever it would be called). This
>>>>>>                     would let such an extension use the OIDC
>>>>>>                     claims processing mechanism as it is today.
>>>>>>
>>>>>>                     To me, this remains much more understandable,
>>>>>>                     extensible, and clean.
>>>>>>
>>>>>>
>>>>>>                 While this may be more understandable to a
>>>>>>                 developer just porting an app OIDC that only
>>>>>>                 wants OIDC results, but I think it is more
>>>>>>                 complicated as soon as the developer wants other
>>>>>>                 results, which is likely what prompted the
>>>>>>                 developer to use GNAP instead of ODIC.
>>>>>>
>>>>>>                 I think it is easier to understand if all the
>>>>>>                 claims are in one container, and all the
>>>>>>                 authorizations are in another container.
>>>>>>
>>>>>>                 If a developer wants access to some resources,
>>>>>>                 some claims, and an OpenID Token, they are having
>>>>>>                 to use "claims", "resources", and
>>>>>>                 "oidc_claims_query". Now the claims and access
>>>>>>                 tokens are spread across multiple containers.
>>>>>>                 There are some claims in the "claims" container,
>>>>>>                 and some "claims" in the "oidc_claims_query"
>>>>>>                 container. And is the access token response
>>>>>>                 in "oidc_claims_query" the same as an access
>>>>>>                 token response in "resources"? It would seem
>>>>>>                 simpler if they were, and if all the access
>>>>>>                 tokens came back in the same container.
>>>>>>
>>>>>>                 Per Aaron's post that you have referred to, the
>>>>>>                 developer can get sme bare claims directly in the
>>>>>>                 response in the "claims" object, an ID Token that
>>>>>>                 has the same or different claims, and if they
>>>>>>                 want, an access token that they can call a
>>>>>>                 user_info endpoint to get the same, or different
>>>>>>                 claims.
>>>>>>
>>>>>>                 For example, an enterprise app client may want an
>>>>>>                 ID Token with the email address, bare claims for
>>>>>>                 the user's name and a URI to a profile photo, and
>>>>>>                 an access token to query which groups a user
>>>>>>                 belongs to.
>>>>>>
>>>>>>                 We are still re-using the OIDC claims, but we are
>>>>>>                 not mixing claims and authorizations.
>>>>>>
>>>>>>                 /Dick
>>>>>>
>>>>>>
>>>>>>                 [1]
>>>>>>                 https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
>>>>>>                 ᐧ
>>>>>
>>>>>             ᐧ
>>>>
>>>>         ᐧ
>>>
>>>     ᐧ
>>
>
>


--------------7255F332E568B62442703DFC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Justin,

    


    

    
I dare to jump into this dialogue. I
      have two closely related questions:

    

      
1) What kind of polymorphism do you
        intent to support ?

      
2) What are the basic reasons for
        supporting "polymorphism" ?

    

    
Some help: Wikipedia states (https://en.wikipedia.org/wiki/Polymorphism_(computer_science))
      : 

    

    

      
In programming languages and type
        theory, polymorphism is the provision of a single interface to
        entities of different types 

        or the use of a single symbol to represent multiple different
        types.

        

        The most commonly recognized major classes of polymorphism are:

        
    
          
  •     Ad hoc polymorphism: defines a common interface for an
            arbitrary set of individually specified types.
    • 
          
  •     Parametric polymorphism: when one or more types are
            not specified by name but by abstract symbols that can
            represent any type.
    • 
          
  •     Subtyping (also called subtype polymorphism or
            inclusion polymorphism): when a name denotes instances of
            many different classes 
    
                related by some common superclass.
    • 
        

      

    

    
Before answering to these two
      questions, please consider the following observations that follow.

    


    

    

      
      Yes, the core idea is to not have to parse an assertion to get
      back the core authentication information, which consists of an
      identifier 

      (iss/sub pair in OIDC, but could be a number of things). Sometimes
      the client is going to want the rest of the identity information,
      

      but If the user’s logged into the client before, the client has
      likely cached that info and probably won’t need it, and sending it
      would be 

      a violation of privacy principles.. The client would want the info
      pretty much just in these cases:
      


      

      
 1. The client has never seen the user before. 

      
 2. The user’s information has been updated since
        the last time the client saw it.

      


      

      
Now for case (1), how would the client know if it
        wants to request the user’s profile info or not, since it
        doesn’t know who the user is? And the AS won’t know 

        if client is going to want the profile info, since the AS won’t
        know if the client has the user’s info or not. Sure, the AS
        might have seen that client and that 

        user combo previously, but it doesn’t know if the client needs
        an update.

    

    
For cases (1) and (2), as long as the user has not yet decided to
      attempt to reach a RS, the client has nothing to do.

    

    
    
      
  • When the user selects a RS and if FIDO is supported, the
        client should check whether the user has a FIDO account with
        that RS.
    
        If he does, it should connect transparently to the RS.  If he
        does not have a FIDO account with that RS, the client should
        check 
    
        whether the RS supports FIDO or some attributes from some AS are
        requested. If FIDO is supported by the RS, it should propose 
    
        to the user to create a FIDO account. If some attributes from
        some AS are requested, it should check whether the user has 
    
        an account with one or more of these ASs. If he has, the user
        should select the appropriate AS and after his consent the
        client 
    
        should contact that AS to obtain the requested attributes in
        order to get them inside an access token. Finally the client
        should send 
    
        the access token to the RS. What happens next depends upon what
        the user is willing to do. 
    
        
    
      
    • 
      
  • 
        When the user selects a RS and if FIDO is NOT supported, the
        client should connect to the RS and the RS should report to the
        client
    
        the means of authentication that it supports. This may be FIDO
        and/or some access tokens with specific attributes from specific
        ASs.
    
        If the user believes that the requested authentication means is
        adequate according to what he wants to do on the RS, he may then
        
    
          locally     choose the most appropriate means. 
    
      
    • 
    

    

      


      

      
And for (2), the client won’t know if the user’s
        info has been updated or not because it doesn’t know who the
        user is yet. 

        If the AS can provide some time of updated stamp to the client,
        the client can pull the new info when it needs it.

      


      

      
If you ignore both of these cases and put all the
        user information inline with the main request/response, you end
        up in a situation 

        where the client always requests everything and the server
        always provides everything, since you can’t be sure you’re not
        in situation 

        (1) or (2) ahead of time.

    

    
The RS should inform the client about what it needs to present,
      at latest at the time of the first access attempt. 

      As long as the client has not yet attempted to reach a RS, the
      client has nothing to do. 

    

    

      
This is really what I mean about the two-stage
        identity protocol. 

        In the first stage, you push the bare minimum of what you need
        to get the user known to the client.

        In the second stage, the client uses its access token to call an
        API to get whatever else it needs to know about the user. 

    

    
Since the RS is not yet identified, the AS(s) that is/are trusted
      by the RS is/are still unknown. 

      The client should not contact any AS before it knows which RS the
      user is willing to access.

    
Last questions: 

    

    
Since these two stages should not happen, why is "polymorphism"
      really or still needed ? If yes, for which purpose(s) ?

    

    
Denis

    

    

      
This API could be an OIDC UserInfoEndpoint, a SCIM
        resource, a FHIR resource, or any number of other user APIs, and
        standardizing that information is not what GNAP should be
        focused on. OIDC does a really good job of letting developers
        log people in using this kind of protocol. While it’s possible
        to cram everything into an ID token on every request, there’s no
        need for it, and it’s likely a bad pattern to follow.

      

        

          


          

          
I’m sorry that you are surprised by my stance,
            but it hasn’t changed since I helped write the section of
            the charter that you quoted below. A big reason that I chose
            that wording was to support this use case but not to go in
            depth with an identity protocol, which I never really wanted
            us to do. However, it seems as soon as “identity” was
            brought up previously, people immediately jumped into
            talking about a full stack of user attributes and profile
            information. That wasn’t my intent in talking about
            identity, and I don’t think it’s something GNAP ought to do,
            at least not on its own. 

          


          

          
I do think there’s room for us to provide
            identifiers alongside the access token, so that’s there.
            There was stated interest in providing signed assertions as
            well, so I made sure that was enumerated for those who want
            to do such work. And I think it makes sense for us to
            provide a way to describe what kinds of things I want to get
            from an access token by defining a general purpose syntax
            for describing those things (notably, as a combination of
            reference strings and multi-dimensional objects). With these
            two, we can get most of what we need for a basic login
            system. Anything beyond that is going to need user profiles,
            authentication contexts, session control, and a lot of other
            identity-protocol stuff that GNAP shouldn’t be focusing on.
            We should keep it in mind as we build GNAP, but I think that
            like OIDC all that important extra stuff should be built
            separately. To me, that’s what not defining schemas and
            formats means. 

          


          

          
I don’t see any conflict with the charter here,
            and I’m surprised that you do.

          


          

          
 — Justin

            


              

                
On Jul 9, 2020, at 5:55 PM, Dick Hardt
                  <dick.hardt@gmail.com>
                  wrote:

                

                

                  
                  

                    

                      

                        

                          

                            
Thanks for the
                              clarifications. I had chatted to Aaron
                              about his post, and my understanding is
                              not what is in the post on a closer read.
                              My takeaway was why make the developer
                              parse the ID_Token, why not give them the
                              information directly.
                              


                              

                              
I have interpreted the
                                userinfo and id_token top level elements
                                to be how the client wanted the query
                                results, not part of the query. I had
                                thought my example and definition of a
                                Grant Response in XAuth [1] would have
                                clearly communicated what I meant, but I
                                see that I should call out that userinfo
                                in XAuth returns the claims, rather than
                                userinfo in OIDC returns an access token
                                for the claims. Given GNAP is more
                                expressive, and learning from the past,
                                I'm proposing we offer the developer
                                (and AS) a choice in how to acquire the
                                claims.

                              


                              

                              
While acquiring user
                                information through an API at any time
                                is appropriate in some use cases, in
                                others why not give the client the info
                                it needs right away rather than having
                                to make another API call to get it? This
                                would be appropriate when the user is
                                making a purchase and wanting to provide
                                shipping information. The user does not
                                want to authorize the client to fetch
                                their shipping address in the future. 

                              


                              

                              
I'm surprised by your
                                stance: 

                              


                              

                            

                          

                        

                        

                          

                            

                              

                                
My stance is that we allow
                                  the client to ask for a small set of
                                  identifiers about the user, or even
                                  just ask to “identify the user”, and
                                  leave everything else to a higher
                                  level identity protocol. I do not
                                  think that having an identity and
                                  profile query/response language at the
                                  core of GNAP is a good idea, and it’s
                                  certainly not in our charter.

                              

                            

                          

                        

                        

                          

                            

                              


                              

                              
Since the charter states:

                              


                              

                            

                          

                        

                      

                      

                        

                          

                            

                              

                                
The group is chartered to
                                  develop mechanisms for conveying
                                  identity information

                                
within the protocol
                                  including existing identifiers (such
                                  as email addresses,

                                
phone numbers, usernames,
                                  and subject identifiers) and
                                  assertions (such as

                                
OpenID Connect ID Tokens,
                                  SAML Assertions, and Verifiable
                                  Credentials). The

                                
group is not chartered to
                                  develop new formats for identifiers or
                                  assertions,

                                
nor is the group chartered
                                  to develop schemas for user
                                  information, profiles,

                                
or other identity
                                  attributes.

                              

                            

                          

                        

                      

                      

                        

                          

                            

                              


                              

                              
More than identifiers about
                                the user are clearly in scope of the WG
                                charter, as are mechanisms for conveying
                                identity information. Your stance and
                                the charter look in conflict to me. What
                                am I missing?

                              


                              

                              
/Dick

                              


                              

                              
                              


                              

                              


                              

                            

                          

                          

                          

                            
On Thu,
                              Jul 9, 2020 at 1:04 PM Justin Richer <jricher@mit.edu>
                              wrote:

                            

                            

                              
In Aaron’s post he doesn’t talk
                                about how the request would be made,
                                just what the response could look like,
                                and we are talking about how to request
                                that. Aaron’s post specifically calls
                                out that this is just an identifier for
                                the user and states:
                                


                                

                                

                                  
If the application needs
                                    to know profile information about
                                    the user, it can get that from the
                                    userinfo endpoint using the access
                                    token it just obtained.

                                

                                


                                

                                
And I think that’s a good
                                  design pattern to follow. This isn’t
                                  “userinfo” being returned alongside
                                  the access token. 

                                


                                

                                
The top level
                                  functionality of the OIDC claims query
                                  language is this:

                                


                                

                                


                                

                                

                                  
The top-level members of
                                    the Claims request JSON object are:

                                  


                                  

                                  
userinfo

                                  
OPTIONAL. Requests that
                                    the listed individual Claims be returned from
                                      the UserInfo Endpoint. If
                                    present, the listed Claims are being
                                    requested to be added to any Claims
                                    that are being requested
                                    using scope values. If not present,
                                    the Claims being requested from the
                                    UserInfo Endpoint are only those
                                    requested using scope values.

                                  
When the userinfo member
                                    is used, the request MUST also use
                                    a response_type value that results
                                    in an Access Token
                                      being issued to the Client for use
                                      at the UserInfo Endpoint.

                                  


                                  

                                  
id_token

                                  
OPTIONAL. Requests that
                                    the listed individual Claims be
                                    returned in the ID Token. If
                                    present, the listed Claims are being
                                    requested to be added to the default
                                    Claims in the ID Token. If not
                                    present, the default ID Token
                                    Claims are requested, as per the ID
                                    Token definition in Section 2 and
                                    per the additional per-flow ID Token
                                    requirements in
                                    Sections 3.1.3.6, 3.2.2.10, 3.3.2.11, and 3.3.3.6..

                                

                                

                                  


                                  

                                  
Since you had re-used
                                    the “userinfo” and “id_token”
                                    top-level claims, I had assumed that
                                    they meant the same thing as in the
                                    OIDC spec. It’s clear to me, now,
                                    that this isn’t what you meant, but
                                    this is why I’m saying you’re not
                                    using the whole query language. 

                                  


                                  

                                  
There are proposed
                                    extensions to the OIDC claims query
                                    that would put returned data into a
                                    different place[1], and so it would
                                    be possible to use the claims
                                    structures to handle this. But at
                                    that point if the goal is just to
                                    use the internal query format, then
                                    I think that we can do better using
                                    … polymorphic JSON. :)

                                  


                                  

                                  
My stance is that we
                                    allow the client to ask for a small
                                    set of identifiers about the user,
                                    or even just ask to “identify the
                                    user”, and leave everything else to
                                    a higher level identity protocol. I
                                    do not think that having an identity
                                    and profile query/response language
                                    at the core of GNAP is a good idea,
                                    and it’s certainly not in our
                                    charter.

                                  


                                  

                                  
 — Justin

                                  


                                  

                                  
                                  


                                    

                                      
On Jul 9, 2020, at
                                        3:29 PM, Dick Hardt <dick.hardt@gmail.com>
                                        wrote:

                                      

                                      

                                        

                                          
Yes. Which is
                                            why I referred to Aaron's
                                            post originally which calls
                                            out for returning plain text
                                            claims.

                                          


                                          

                                          
I don't really
                                            understand what you mean by
                                            "OIDC claims query
                                            language". The claims mean
                                            the same thing. And I was
                                            also reusing the modifiers
                                            such as {"essential": true}.
                                            What top level functionality
                                            are you referring to?

                                          


                                          

                                          

                                            
On Thu,
                                              Jul 9, 2020 at 12:21 PM
                                              Justin Richer <jricher@mit.edu>
                                              wrote:

                                            

                                            

                                              
Ah, so
                                                you’re saying that the
                                                “userinfo” claims would
                                                be returned directly? I
                                                didn’t realize that you
                                                had intended to change
                                                how the OIDC claims
                                                query language
                                                functioned in your
                                                examples, and had
                                                assumed it would work
                                                the same was as the spec
                                                you were referencing.
                                                Your example of
                                                splitting it up makes
                                                that more clear. Though
                                                I would argue at that
                                                point, you’re creating a
                                                new query language since
                                                you’re not using the
                                                top-level functionality
                                                from ODIC’s definition.
                                                


                                                

                                                
 — Justin

                                                  


                                                    

                                                      
On
                                                        Jul 9, 2020, at
                                                        3:15 PM, Dick
                                                        Hardt <dick.hardt@gmail.com>
                                                        wrote:

                                                      

                                                      

                                                        

                                                          

                                                          

                                                          
You
                                                          are jumping to
                                                          many
                                                          conclusions
                                                          below. Let me
                                                          break down the
                                                          proposal into
                                                          some bite size
                                                          chunks.

                                                          


                                                          

                                                          
The
                                                          developer
                                                          would like to
                                                          get some plain
                                                          text OIDC
                                                          claims about
                                                          the user:

                                                          


                                                          

                                                          
 
                                                            "claims":{

                                                                 
                                                          "oidc": {

                                                                     
                                                          "userinfo" : {

                                                                       
                                                            "name" : {
                                                          "essential" :
                                                          true },

                                                                       
                                                            "photo" : {
                                                          "essential" :
                                                          false }

                                                                      },

                                                          

                                                          


                                                          

                                                          
The
                                                          developer
                                                          would like to
                                                          get an OIDC ID
                                                          Token:

                                                          


                                                          

                                                          
 
                                                            "claims":{

                                                                 
                                                          "oidc": {

                                                                     
                                                          "id_token" : {

                                                                       
                                                            "email"    
                                                               : {
                                                          "essential" :
                                                          true },

                                                                       
                                                           
                                                          "email_verified"
                                                          : {
                                                          "essential" :
                                                          true }

                                                                      }

                                                          

                                                          
 
                                                            }

                                                          


                                                          

                                                          
The
                                                          developer
                                                          would like to
                                                          get an access
                                                          token to
                                                          acquire OIDC
                                                          claims:

                                                          

                                                          


                                                          

                                                          
"authorizations":
                                                          {

                                                                 
                                                          "type":"oidc",

                                                                 
                                                          "claims":
                                                          ["name",
                                                          "picture"]

                                                              }

                                                          

                                                          


                                                          

                                                          
The
                                                          developer
                                                          would like to
                                                          get an access
                                                          token to
                                                          access photos:

                                                          


                                                          

                                                          

                                                          
"authorizations":
                                                          {

                                                                 
                                                          "type":"oauth_scope",

                                                                 
                                                          "scope":
                                                          "read_photos"*

                                                              }

                                                          


                                                          

                                                          
The
                                                          developer
                                                          would like to
                                                          get some VC
                                                          claims:

                                                          


                                                          

                                                          
"claims"
                                                          {

                                                          
 
                                                                "vc": {

                                                          

                                                          
 
                                                                   
                                                          "some_vc":
                                                          "query_mechanism"

                                                                  }

                                                          

                                                          
}

                                                          


                                                          

                                                          
The
                                                          developer
                                                          would like to
                                                          do all of the
                                                          above at once:

                                                          


                                                          

                                                          
{

                                                             
                                                          "authorizations":
                                                          {

                                                                 
                                                          "userinfo": {

                                                                     
                                                          "type":"oidc",

                                                                     
                                                          "claims":
                                                          ["name",
                                                          "picture"]

                                                                  },

                                                                 
                                                          "photos": {

                                                                     
                                                          "type":"oauth_scope",

                                                                     
                                                          "scope":
                                                          "read_photos"

                                                                  }

                                                              },

                                                              "claims":{

                                                                 
                                                          "oidc": {

                                                                     
                                                          "id_token" : {

                                                                       
                                                            "email"    
                                                               : {
                                                          "essential" :
                                                          true },

                                                                       
                                                           
                                                          "email_verified"
                                                          : {
                                                          "essential" :
                                                          true }

                                                                      },

                                                                     
                                                          "userinfo" : {

                                                                       
                                                            "name" : {
                                                          "essential" :
                                                          true },

                                                                       
                                                            "photo" : {
                                                          "essential" :
                                                          false }

                                                                      }

                                                                  },

                                                              "vc": {

                                                                 
                                                          "some_vc":
                                                          "query_mechanism"

                                                                  }   

                                                              }

                                                          }

                                                          

                                                          


                                                          

                                                          
In
                                                          the results,
                                                          the developer
                                                          gets claims
                                                          back in the
                                                          response
                                                          claims object,
                                                          and access
                                                          tokens etc.
                                                          back in the
                                                          authorizations
                                                          object. Just
                                                          because an
                                                          access token
                                                          returns
                                                          claims, it is
                                                          still an
                                                          access token.

                                                          


                                                          

                                                          
Yes,
                                                          the
                                                          developer can't
                                                          get a single
                                                          access token
                                                          that can both
                                                          acquire OIDC
                                                          claims, and
                                                          access photos
                                                          (there are
                                                          separate
                                                          tokens for
                                                          each), but I
                                                          would argue
                                                          that
                                                          separating the
                                                          access is a
                                                          positive
                                                          security
                                                          property, as a
                                                          client
                                                          component
                                                          accessing the
                                                          user profile
                                                          has a token
                                                          independent of
                                                          the client
                                                          component
                                                          accessing
                                                          photos. And at
                                                          the AS, there
                                                          is no
                                                          requirement
                                                          for the
                                                          userinfo
                                                          endpoint to
                                                          take the same
                                                          token as the
                                                          photo
                                                          endpoint.

                                                          


                                                          

                                                          
Somewhat
                                                          of a tangent,
                                                          I'm thinking
                                                          that 

                                                          


                                                          

                                                          
 
                                                            "claims":{

                                                                 
                                                          "oidc": {

                                                                     
                                                          "id_token" :
                                                          {},

                                                                     
                                                          "userinfo" :
                                                          {}

                                                                  },

                                                          

                                                          is a little
                                                          verbose, and:

                                                          


                                                              "claims":{

                                                                 
                                                          "oidc_token":
                                                          {},

                                                                 
                                                          "oidc_info":
                                                          {}

                                                              },

                                                          

                                                          


                                                          

                                                          
works
                                                          better and
                                                          makes it
                                                          easier to
                                                          distinguish support
                                                          for ID tokens
                                                          vs plain
                                                          claims.

                                                          


                                                          

                                                          
wrt.
                                                          my position on
                                                          reusing OIDC
                                                          -- it has not
                                                          changed. I
                                                          have viewed
                                                          the OIDC
                                                          claims as the
                                                          "query
                                                          language". No
                                                          need to
                                                          reinvent that.
                                                          We are
                                                          creating a new
                                                          protocol, so
                                                          no need to use
                                                          the OAuth or
                                                          OIDC
                                                          protocols.

                                                          


                                                          

                                                          

                                                          
*
                                                          OAuth scopes
                                                          could be a
                                                          space
                                                          separates
                                                          string to be
                                                          consistent
                                                          with OAuth 2,
                                                          or an array of
                                                          strings so
                                                          that it is
                                                          more JSON
                                                          like. I have
                                                          no strong
                                                          opinion. 

                                                          

                                                          


                                                          

                                                          
scope.split('
                                                          ').forEach() 

                                                          


                                                          

                                                          
is
                                                          not that much
                                                          more complex
                                                          than 

                                                          


                                                          

                                                          
scope.forEach()

                                                          


                                                          

                                                          


                                                          

                                                          

                                                          

                                                          
On Thu, Jul 9, 2020 at 8:39 AM Justin Richer <jricher@mit.edu>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
But
                                                          this approach
                                                          doesn’t keep
                                                          things in
                                                          their
                                                          respective
                                                          containers —
                                                          you’ve
                                                          explicitly got
                                                          “claims”
                                                          underneath the
“authorizations” header, and you’ve got items that come back as rights
                                                          associated
                                                          with the
                                                          access token
                                                          (which should
                                                          be
                                                          “authorizations”)
                                                          in the
                                                          “userinfo”
                                                          section under
                                                          the “claims”
                                                          header. And as
                                                          far as I can
                                                          tell, these
                                                          two sections
                                                          are redundant
                                                          to each other.
                                                          Everything is
                                                          everywhere. 

                                                          


                                                          

                                                          
Additionally,
                                                          this approach
                                                          and syntax
                                                          makes it
                                                          difficult to
                                                          combine
                                                          different
                                                          kinds of
                                                          requests into
                                                          one. One of
                                                          OpenID
                                                          Connect’s
                                                          biggest draws,
                                                          as I’m sure
                                                          you recall, is
                                                          that it could
                                                          be combined
                                                          with a request
                                                          for non-OIDC
                                                          resources.
                                                          This was the
                                                          real
                                                          innovation
                                                          that Twitter
                                                          and Facebook’s
                                                          identity APIs
                                                          brought,
                                                          access to more
                                                          than just
                                                          authentication,
                                                          and what
                                                          Google had
                                                          tried to
                                                          replicate with
                                                          the awkward
                                                          OpenID 2 +
                                                          OAuth 1 hybrid
                                                          system. Taking
                                                          a step back
                                                          from the
                                                          existing
                                                          solutions of
                                                          OpenID 2 and
                                                          OAuth 1 let
                                                          us, as the
                                                          community, see
                                                          the value in
                                                          the pattern
                                                          that became
                                                          OIDC on top of
                                                          OAuth 2. 

                                                          


                                                          

                                                          
Sure,
                                                          you could say
                                                          that the
                                                          “oidc” type
                                                          also can allow
                                                          a “scopes”
                                                          parameter, but
                                                          what about a
                                                          RAR style
                                                          object, then?
                                                          And what about
                                                          when someone
                                                          comes up with
                                                          some new way
                                                          to request
                                                          access rights,
                                                          or a VC-based
                                                          query
                                                          language? Does
                                                          every “type”
                                                          need to now
                                                          know about
                                                          every other
                                                          “type” in
                                                          order for an
                                                          AS to be able
                                                          to figure out
                                                          how they go
                                                          together? This
                                                          seems like the
                                                          protocol
                                                          definition
                                                          limiting what
                                                          combinations
                                                          the AS can
                                                          handle, or
                                                          what an RS
                                                          might want to
                                                          use.

                                                          


                                                          

                                                          
My
                                                          stance is that
                                                          GNAP should
                                                          have a way to
                                                          query for
                                                          rights in the
                                                          access token
                                                          (“authorizations”
                                                          in xauth
                                                          parlance) and
                                                          identifiers
                                                          for the user
                                                          (“claims” in
                                                          xauth
                                                          parlance), and
                                                          anything else
                                                          should be an
                                                          extension with
                                                          potentially
                                                          different
                                                          models. The AS
                                                          would process
                                                          the
                                                          “authorizations”
                                                          equivalent
                                                          (for the
                                                          access token)
                                                          alongside any
                                                          other incoming
                                                          query and then
                                                          make a policy
                                                          decision based
                                                          on that.

                                                          


                                                          

                                                          
I
                                                          find it
                                                          interesting
                                                          that you are
                                                          now saying we
                                                          don’t need to
                                                          use the OIDC
                                                          request format
                                                          when
                                                          previously
                                                          you’ve made it
                                                          clear that you
                                                          were in favor
                                                          of pointing at
                                                          external query
                                                          languages,
                                                          including
                                                          their syntax.
                                                          I’m glad to
                                                          see that
                                                          you’re now
                                                          looking at
                                                          things in a
                                                          more flexible
                                                          way, but I
                                                          think it’s
                                                          important that
                                                          we be careful
                                                          and
                                                          conscientious
                                                          about how we
                                                          reference any
                                                          external query
                                                          languages in
                                                          GNAP.

                                                          


                                                          

                                                          
 —
                                                          Justin

                                                          


                                                          

                                                          
On
                                                          Jul 8, 2020,
                                                          at 6:55 PM,
                                                          Dick Hardt
                                                          <dick.hardt@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hey
                                                          Justin,
                                                          


                                                          

                                                          
Just
                                                          because we are
                                                          using OIDC
                                                          claims, does
                                                          not mean we
                                                          need to mimic
                                                          the OIDC
                                                          request and
                                                          response.

                                                          
I
                                                          was
                                                          envisioning a
                                                          grant request
                                                          could look as
                                                          the following
                                                          (using XAuth
                                                          syntax):

                                                          


                                                          

                                                          
{

                                                             
                                                          "authorizations":
                                                          {

                                                                 
                                                          "type":"oidc",

                                                                 
                                                          "claims":
                                                          ["name",
                                                          "picture"]

                                                              },

                                                              "claims":{

                                                                 
                                                          "oidc": {

                                                                     
                                                          "id_token" : {

                                                                       
                                                            "email"    
                                                               : {
                                                          "essential" :
                                                          true },

                                                                       
                                                           
                                                          "email_verified"
                                                          : {
                                                          "essential" :
                                                          true }

                                                                      },

                                                                     
                                                          "userinfo" : {

                                                                       
                                                            "name"      
                                                              : {
                                                          "essential" :
                                                          true },

                                                                       
                                                            "picture"  
                                                               : null

                                                                      }

                                                                  }

                                                              }

                                                          }

                                                          

                                                          

                                                          


                                                          

                                                          
Of
                                                          course a
                                                          developer
                                                          could choose
                                                          to only ask
                                                          for a subset
                                                          of this.

                                                          


                                                          

                                                          
Note
                                                          the new
                                                          authorization
                                                          type of
                                                          "oidc", that
                                                          takes "claims"
                                                          rather than
                                                          "scope". 

                                                          


                                                          

                                                          
This
                                                          keeps all the
                                                          authorizations
                                                          and claims in
                                                          their
                                                          respective
                                                          request and
                                                          response
                                                          containers.

                                                          


                                                          

                                                          
We
                                                          had a thread
                                                          months ago on
                                                          the OIDC two
                                                          stage model,
                                                          and I still
                                                          fail to see
                                                          why forcing
                                                          that has any
                                                          advantage. 

                                                          


                                                          

                                                          
/Dick

                                                          


                                                          

                                                          

                                                          

                                                          

                                                          
On Wed, Jul 8, 2020 at 3:25 PM Justin Richer <jricher@mit.edu>
                                                          wrote:

                                                          

                                                          

                                                          
I’m
                                                          glad that we
                                                          can agree that
                                                          there are a
                                                          number of
                                                          things in
                                                          legacy
                                                          protocols that
                                                          are
                                                          unfortunate
                                                          side effects
                                                          of the
                                                          circumstances
                                                          in which they
                                                          were built.
                                                          Space-separated
                                                          scope strings,
                                                          for instance,
                                                          would fall in
                                                          that category,
                                                          as I’ve
                                                          previously
                                                          explained.
                                                          


                                                          

                                                          
A
                                                          key point in
                                                          the below: the
                                                          OIDC “claims”
                                                          request
                                                          already mixes
                                                          user claims
                                                          (returned in
                                                          an API) and
                                                          authorization
                                                          (to fetch user
                                                          claims from an
                                                          API), so that
                                                          ship has
                                                          sailed if
                                                          you’re using
                                                          it. It doesn’t
                                                          make sense to
                                                          have it under
                                                          a “claims” or
“authorizations” request, since it’s a query language that affects both.
                                                          Maybe you’d
                                                          call this
                                                          another
                                                          “unfortunate
                                                          design”, but
                                                          the context
                                                          was about
                                                          re-using an
                                                          externally-defined
                                                          query language
                                                          that was not
                                                          made for GNAP.
                                                          


                                                          

                                                          
My
                                                          scenario was
                                                          for someone
                                                          who is already
                                                          using “claims”
                                                          and wants to
                                                          keep using it.
                                                          (The vast
                                                          majority of
                                                          OIDC
                                                          implementations,
                                                          in my
                                                          experience,
                                                          don’t use that
                                                          feature, and
                                                          it’s not even
                                                          required to be
                                                          implemented by
                                                          the AS, but
                                                          again we’re
                                                          talking about
                                                          using this
                                                          feature as an
                                                          example of an
                                                          external query
                                                          language — and
                                                          there are
                                                          others out
                                                          there.) In
                                                          GNAP, you
                                                          should return
                                                          claims
                                                          directly in
                                                          the response,
                                                          and request
                                                          specific
                                                          elements from
                                                          the APIs
                                                          protected by
                                                          the access
                                                          token. These
                                                          are separate
                                                          things, and by
                                                          design both
                                                          XAuth and XYZ
                                                          have put them
                                                          into separate
                                                          containers in
                                                          the request.
                                                          This is a good
                                                          design, and so
                                                          putting
                                                          something that
                                                          conflates
                                                          these two
                                                          aspects into
                                                          one or the
                                                          other of the
                                                          containers is
                                                          not a
                                                          particularly
                                                          good option,
                                                          in my
                                                          opinion. 

                                                          


                                                          

                                                          
Additionally,
                                                          though this is
                                                          a bit of an
                                                          aside and
                                                          getting into
                                                          the specifics
                                                          of identity,
                                                          the “claims”
                                                          parameter of
                                                          ODIC is a
                                                          query language
                                                          bound to the
                                                          full user
                                                          profile. It is
                                                          my stated
                                                          position that
                                                          the items
                                                          coming back
                                                          from the AS
                                                          should only be
                                                          identifiers,
                                                          and not full
                                                          profile
                                                          information.
                                                          The reasoning
                                                          is pretty
                                                          simple: the
                                                          client doesn’t
                                                          know what
                                                          profile
                                                          information it
                                                          needs until it
                                                          knows who the
                                                          user is, so
                                                          putting that
                                                          into a
                                                          protected API
                                                          like the
                                                          UserInfo
                                                          Endpoint makes
                                                          much more
                                                          sense than
                                                          putting it
                                                          into the
                                                          immediate
                                                          response,
                                                          where it is
                                                          not needed,
                                                          because the
                                                          client already
                                                          knows it. The
                                                          AS doesn’t
                                                          know what the
                                                          client needs
                                                          to know,
                                                          either, so it
                                                          can’t
                                                          determine what
                                                          to fulfill.
                                                          OIDC’s
                                                          two-stage
                                                          model makes
                                                          sense, and
                                                          GNAP should
                                                          really only
                                                          focus on
                                                          enabling this.

                                                          


                                                          

                                                          
 —
                                                          Justin

                                                          

                                                          


                                                          

                                                          
On
                                                          Jul 8, 2020,
                                                          at 6:10 PM,
                                                          Dick Hardt
                                                          <dick.hardt@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          


                                                          

                                                          

                                                          
On Wed, Jul 8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu>
                                                          wrote:

                                                          

                                                          

                                                          
On
                                                          Jul 8, 2020,
                                                          at 3:16 PM,
                                                          Dick Hardt
                                                          <dick.hardt@gmail.com>
                                                          wrote:

                                                          

                                                          


                                                          

                                                          

                                                          
I
                                                          think
                                                          representing
                                                          the request as
                                                          an array is
                                                          simplistic,
                                                          and
                                                          complicated at
                                                          the same time.
                                                          


                                                          

                                                          
On
                                                          the simplistic
                                                          front, as
                                                          there is no
                                                          clear
                                                          mechanism for
                                                          extending the
                                                          request with
                                                          properties
                                                          that apply to
                                                          all of the
                                                          request. 

                                                          

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
The
                                                          elements of
                                                          the array are
                                                          taken as a
                                                          set, to be
                                                          tied to the
                                                          same resulting
                                                          access token.
                                                          If one of
                                                          those elements
                                                          is defined, by
                                                          the AS and/or
                                                          the RS’s it’s
                                                          protecting, to
                                                          apply across
                                                          some or all of
                                                          the other
                                                          elements, then
                                                          that’s up to
                                                          the AS’s
                                                          policy. Much
                                                          like the
                                                          “openid” scope
                                                          in OIDC, which
                                                          switches on
                                                          all sorts of
                                                          contextual
                                                          stuff in the
                                                          request. So to
                                                          handle
                                                          something like
                                                          this, an AS
                                                          can easily
                                                          declare that a
                                                          given
                                                          scope-style
                                                          string or a
                                                          given object
                                                          property
                                                          applies to
                                                          different
                                                          parts of the
                                                          request. You
                                                          don’t need to
                                                          externalize it
                                                          here.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
I
                                                          view the
                                                          "openid" scope
                                                          as an
                                                          unfortunate
                                                          design as OIDC
                                                          was
                                                          constrained by
                                                          building on
                                                          top of OAuth.
                                                          (a problem I
                                                          hoped to avert
                                                          by having
                                                          "identity" in
                                                          scope for
                                                          GNAP) The
                                                          "openid" scope
                                                          does not
                                                          function as
                                                          scope per se,
                                                          and I think it
                                                          makes OIDC
                                                          harder to
                                                          understand as
                                                          the "openid"
                                                          scope causes
                                                          non-scope
                                                          behavior. 

                                                          


                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
Do
                                                          you have a
                                                          concrete use
                                                          case that
                                                          requires that
                                                          feature to be
                                                          done in the
                                                          way that you
                                                          describe? I am
                                                          trying to
                                                          separate the
                                                          driving use
                                                          case from the
                                                          proposed
                                                          solutions to
                                                          see what the
                                                          differences
                                                          are. 

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
Perhaps
                                                          the client
                                                          wants access
                                                          to be HIPPA
                                                          compliant? The
                                                          HIPPA
                                                          compliance
                                                          signal applies
                                                          to the scopes.

                                                          


                                                          

                                                          
Adding
                                                          other
                                                          properties to
                                                          an object is a
                                                          well
                                                          understood
                                                          extension
                                                          mechanism.
                                                          Adding an
                                                          additional
                                                          element to an
                                                          array that
                                                          does not act
                                                          like the other
                                                          elements seems
                                                          like a hack.

                                                          


                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
Using
                                                          JSON type
                                                          polymorphism requires
                                                          the AS to test
                                                          each member of
                                                          the array to
                                                          determine if
                                                          it is a string
                                                          or an object.
                                                          Only after
                                                          detecting a
                                                          RAR object
                                                          does the AS
                                                          know the
                                                          client is
                                                          making a RAR
                                                          request. 

                                                          

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
That’s
                                                          correct — but
                                                          the AS needs
                                                          to parse the
                                                          whole
                                                          resources
                                                          request in
                                                          order to
                                                          figure out
                                                          what the
                                                          client is
                                                          asking for,
                                                          anyway,
                                                          whether it’s
                                                          by strings or
                                                          objects or
                                                          whatever else
                                                          might be
                                                          defined by an
                                                          extension. Is
                                                          there an
                                                          argument for
                                                          having an AS
                                                          do an early
                                                          dispatch on a
                                                          request before
                                                          it’s fully
                                                          parsed
                                                          everything?

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
Let
                                                          me clarify,
                                                          the code is
                                                          looking at the
                                                          type of object
                                                          that has been
                                                          parsed. 

                                                          


                                                          

                                                          
Determining
                                                          if an item in
                                                          an array is a
                                                          scope or a RAR
                                                          object by
                                                          looking at the
                                                          type being
                                                          either a
                                                          string or an
                                                          object seems
                                                          less clear
                                                          than a
                                                          property of an
                                                          object
                                                          explicitly
                                                          declaring the
                                                          type.

                                                          


                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          

                                                          

                                                          

                                                          
This
                                                          also limits
                                                          the request to
                                                          be composed
                                                          only of scope
                                                          strings or RAR
                                                          objects. I
                                                          don't see how
                                                          other strings
                                                          or objects
                                                          could be used
                                                          in the array,
                                                          so there is no
                                                          clear
                                                          extension
                                                          point in the
                                                          "resources"
                                                          array for
                                                          other query
                                                          mechanisms.

                                                          

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
That’s
                                                          not the case
                                                          in XYZ since
                                                          we aren’t
                                                          declaring that
                                                          a string has
                                                          to be an
                                                          OAuth2-style
                                                          scope. It can
                                                          be, but
                                                          ultimately
                                                          it’s just a
                                                          string that
                                                          the AS can
                                                          understand.
                                                          And the
                                                          objects are
                                                          just that —
                                                          objects. If
                                                          the AS
                                                          understands
                                                          what the
                                                          object is, it
                                                          can be a RAR
                                                          object or it
                                                          can be
                                                          something
                                                          completely
                                                          API-specific
                                                          with another
                                                          query language
                                                          entirely.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
But
                                                          the other
                                                          query language
                                                          would need a
                                                          type that has
                                                          been reserved
                                                          in the RAR
                                                          name space for
                                                          there to be
                                                          interop, so it
                                                          effectively is
                                                          a RAR
                                                          extension.

                                                          


                                                          

                                                          
There
                                                          are query
                                                          languages in
                                                          other domains
                                                          that may not
                                                          fit nicely
                                                          into RAR such
                                                          as a query for
                                                          medical
                                                          records.

                                                          


                                                          

                                                          
Yes,
                                                          the medical
                                                          records could
                                                          be yet another
                                                          top level
                                                          property, but
                                                          per below, I
                                                          think that is
                                                          confusing.

                                                          
 

                                                          

                                                          

                                                          

                                                          
(Point,
                                                          though: RAR
                                                          already pretty
                                                          much allows
                                                          this by
                                                          letting them
                                                          be extended
                                                          infinitely, a
                                                          feature it
                                                          inherits from
                                                          XYZ)

                                                          


                                                          

                                                          
I’m
                                                          proposing that
                                                          we do the same
                                                          thing with
                                                          GNAP: it’s an
                                                          array of
                                                          strings or
                                                          objects and
                                                          each of those
                                                          means the same
                                                          thing,
                                                          “something the
                                                          client is
                                                          asking for”.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
Just
                                                          as RAR has a
                                                          "type"
                                                          property, I
                                                          propose the
                                                          "resources"
                                                          ("authorizations"
                                                          in XAuth) be
                                                          an object,
                                                          where the
                                                          other
                                                          properties are
                                                          determined by
                                                          the "type"
                                                          property. This
                                                          allows
                                                          extensions to
                                                          define new
                                                          ways to query
                                                          for an
                                                          authorization
                                                          rather than
                                                          having to fit
                                                          into scopes or
                                                          RAR.

                                                          


                                                          

                                                          

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
It’s
                                                          my stance that
                                                          this is an
                                                          unnecessary
                                                          limitation at
                                                          this level.
                                                          The objects
                                                          within the
                                                          array should
                                                          be typed, like
                                                          RAR, but it
                                                          doesn’t make
                                                          sense for the
                                                          overall
                                                          request to be
                                                          typed.
                                                          Instead, there
                                                          should be one
                                                          “type" of
                                                          query in the
                                                          core, what XYZ
                                                          calls the
                                                          “resources”
                                                          request. Other
                                                          query
                                                          languages
                                                          should be
                                                          added as
                                                          extensions
                                                          either to the
                                                          RAR-style
                                                          objects (by
                                                          defining a
                                                          type at that
                                                          level) or as a
                                                          separate
                                                          top-level
                                                          member.

                                                          


                                                          

                                                          
For
                                                          example, let’s
                                                          take the OIDC
                                                          “claims” query
                                                          language. My
                                                          current
                                                          thought is
                                                          that this
                                                          really
                                                          shouldn’t be a
                                                          part of the
                                                          “resources” or
                                                          “claims” part
                                                          of the
                                                          request, but
                                                          instead as its
                                                          own top-level
                                                          member, like
                                                          it is in the
                                                          OIDC protocol
                                                          today. The
                                                          main reason
                                                          for this is
                                                          the nature of
                                                          the OIDC
                                                          claims
                                                          language: it
                                                          specifies
                                                          targets for
                                                          the resulting
                                                          data, and
                                                          those targets
                                                          cross
                                                          different ways
                                                          to return
                                                          things. So it
                                                          doesn’t
                                                          actually
                                                          affect just
                                                          resources like
                                                          the UserInfo
                                                          Endpoint, or
                                                          the ID Token,
                                                          but both and
                                                          potentially
                                                          others out
                                                          there. If your
                                                          system
                                                          supported such
                                                          an extension,
                                                          it could
                                                          theoretically
                                                          forego both
                                                          the built-in
                                                          “claims” and
                                                          “resources”
                                                          parts of the
                                                          request, and
                                                          use the
                                                          “oidc_claims_query”
                                                          member (or
                                                          whatever it
                                                          would be
                                                          called). This
                                                          would let such
                                                          an extension
                                                          use the OIDC
                                                          claims
                                                          processing
                                                          mechanism as
                                                          it is today.

                                                          


                                                          

                                                          
To
                                                          me, this
                                                          remains much
                                                          more
                                                          understandable,
                                                          extensible,
                                                          and clean.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
While
                                                          this may be
                                                          more
                                                          understandable
                                                          to a developer
                                                          just porting
                                                          an app OIDC
                                                          that only
                                                          wants OIDC
                                                          results, but I
                                                          think it is
                                                          more
                                                          complicated as
                                                          soon as the
                                                          developer
                                                          wants other
                                                          results, which
                                                          is likely
                                                          what prompted
                                                          the developer
                                                          to use GNAP
                                                          instead of
                                                          ODIC.

                                                          


                                                          

                                                          
I
                                                          think it is
                                                          easier to
                                                          understand if
                                                          all the claims
                                                          are in one
                                                          container, and
                                                          all the
                                                          authorizations
                                                          are in another
                                                          container.

                                                          


                                                          

                                                          
If
                                                          a developer
                                                          wants access
                                                          to some
                                                          resources,
                                                          some claims,
                                                          and an OpenID
                                                          Token, they
                                                          are having to
                                                          use "claims",
                                                          "resources",
                                                          and
                                                          "oidc_claims_query". 
                                                          Now the claims
                                                          and access
                                                          tokens are
                                                          spread across
                                                          multiple
                                                          containers.
                                                          There are some
                                                          claims in the
                                                          "claims"
                                                          container, and
                                                          some "claims"
                                                          in the
                                                          "oidc_claims_query"
                                                          container. And
                                                          is the access
                                                          token response
in "oidc_claims_query" the same as an access token response in
                                                          "resources"?
                                                          It would seem
                                                          simpler if
                                                          they were, and
                                                          if all the
                                                          access tokens
                                                          came back in
                                                          the same
                                                          container.

                                                          


                                                          

                                                          
Per
                                                          Aaron's post
                                                          that you have
                                                          referred to,
                                                          the developer
                                                          can get sme
                                                          bare claims
                                                          directly in
                                                          the response
                                                          in the
                                                          "claims"
                                                          object, an ID
                                                          Token that has
                                                          the same or
                                                          different
                                                          claims, and if
                                                          they want, an
                                                          access token
                                                          that they can
                                                          call a
                                                          user_info
                                                          endpoint to
                                                          get the same,
                                                          or different
                                                          claims.

                                                          


                                                          

                                                          
For
                                                          example, an
                                                          enterprise app
                                                          client may
                                                          want an ID
                                                          Token with the
                                                          email address,
                                                          bare claims
                                                          for the user's
                                                          name and a URI
                                                          to a profile
                                                          photo, and an
                                                          access token
                                                          to query which
                                                          groups a user
                                                          belongs to.

                                                          


                                                          

                                                          
We
                                                          are still
                                                          re-using the
                                                          OIDC claims,
                                                          but we are not
                                                          mixing claims
                                                          and
                                                          authorizations.

                                                          


                                                          

                                                          
/Dick

                                                          


                                                          

                                                          


                                                          

                                                          
                                                          

                                                          

                                                          
ᐧ

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
ᐧ

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                        

                                                        
ᐧ

                                                      

                                                    

                                                  

                                                  

                                                

                                              

                                            

                                          

                                        

                                        
ᐧ

                                      

                                    

                                  

                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

            

          

        

      

      

      

    

    


    

  


--------------7255F332E568B62442703DFC--


From nobody Fri Jul 10 08:46: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 2DCA63A0EAF for ; Fri, 10 Jul 2020 08:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, 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 Qd1YmlRsKxmQ for ; Fri, 10 Jul 2020 08:45:56 -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 761163A0C50 for ; Fri, 10 Jul 2020 08:45:55 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d64 with ME id 1Tlr2300C4FMSmm03TlrpR; Fri, 10 Jul 2020 17:45:53 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 10 Jul 2020 17:45:53 +0200
X-ME-IP: 86.238.65.197
To: Fabien Imbault , txauth@ietf.org
References: 
From: Denis 
Message-ID: <382b5f57-6825-3537-c66b-fb2c38e5140c@free.fr>
Date: Fri, 10 Jul 2020 17:45:50 +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="------------BDADE35EBB5A0A7B8B673C7A"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 10 Jul 2020 15:46:00 -0000

This is a multi-part message in MIME format.
--------------BDADE35EBB5A0A7B8B673C7A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Fabien,

It would have been appreciated that you kept the original message in 
your response. I have copied it again at the end of this email.

Comments are between the lines.

> Hi Denis,
>
> I think it's interesting, but also very different to XYZ/XAuth so it 
> raises many questions ;-)
> The figure is impossible to read.

Use a PC. Copy and paste and then use the Courier font. On my PC (with 
the clear figure) it was perfect.

> So let me try to summarize the suggested approach, with a concrete 
> example, to make sure we understand well:
>
> *0. The client authN to the AS (in whatever way is supported)*
> Ex : client is a corporate financing called "finapp". finapp contacts 
> AS0 for authentication (say an openbanking service).
> User is John Doe, CFO at NeedMoney Inc. (+ other identity claims if 
> needed, maybe some verified credential from NeedMoney Holding that 
> John is indeed CFO).
>
> /Dear John, /
> /to access to your finapp, please identify yourself through your 
> prefered openbanking account./
> /Thanks/

If I understand you correctly,  finapp is a local application e.g. on 
your smartphone.

> *1. The client contacts a RS in a discovery phase, which includes the 
> selection of (at least) an operation, for which the RS returns the 
> required authZ attributes *
> Ex : finapp needs to use NeedMoney's data to evaluate how much credit 
> it can offer.
>
> Op1 : compute the credit rating, from RS1 (this is outsourced to an 
> external credit analyst), through the external service's own AS1.
> But to do that, RS needs your historic bank statements.
> Op2 : get your list of banks, RS2 (as registered within finapp), 
> through openbanking AS0 and retrieve the bank statements :
> Op3a : get historic data from his main bank, RS2a (say an 
> international bank), through openbanking AS0
> Op3b : same from a second bank account, RS2b (say a local bank), 
> through openbanking AS0

Why don't you make your very first example a little bit more complicated 
? with RS1, RS2a, RS2b, ... AS0, AS1, ...

:-)

The intent of the /first /email was to discuss a /basic /model and to 
place the highlights on the way to capture the *user's consent*
in an interoperable manner without letting know to any RS or AS the 
choices of the user. This is a fundamental feature of the model.
In XAuth, the user's consent is not formalized in the protocol : "User 
consent is /often /required at the GS".

> *2. User consent *
> RS1 aggregates the list of attributes required (from all RS) and sends 
> it to finapp.
> /Dear John, /
> /To evaluate your credit request, we need the following information: /
> /- your list of bank accounts (retrieved from your finapp account)/
> /- the associated banking statements over the past 12 months (from 
> each bank)/
> /- we'll pass that data to the credit agency, which will return your 
> credit score /
> /Do you agree ?/
>
> John approves (or not..., maybe he'll agree only for one specific 
> bank), via finapp directly
> (I like that, albeit in a more traditional flow, I'm also separating 
> the UI from the rest of the protocol of XYZ, and it works too).

As described, the user could simply push to the RS the banking 
statements over the past 12 months (from each bank).
The user consent is not about : "/Do you agree that/ /we pass the data 
to the credit agency, which will return your credit score"
/since no attributes nor ASs are involved in the question./
/

I guess you want the user to get access tokens targeted for RS2x so that 
each bank will accept to disclose his banking statements over the past 
12 months.

The consent is whether the user accepts to get access tokens from some 
of his banks targeted for RS2x for the following operation:
"Retrieval of the past 12 months banking statements" which corresponds 
to an API for each bank and then to send these access tokens to RS1.

In practice, the client (e.g. using FIDO) will connect transparently to 
each of the appropriate AS from the banks and will get the requested 
access tokens
with a requested validity period of about 5 minutes.

> *3. Requests to the protected resources *
> The client gets the access tokens and uses the services for which 
> access was granted.
>
> *Analysis: (maybe I didn't get everything right, if so let me know) *
> The trust model is focused around the relationship between the enduser 
> (John) and his application (finapp), which seems fine.

No. The trust model is not making a focus on that specific relationship. 
BTW, no access token is necessarily needed by the user to be able to use 
finapp.

> => I see some potential issues :
>
> a. it will be really difficult for an end user to understand what AS0 
> and AS1 are, why they're different, and why he needs to authenticate 
> to each of them.
> How do you enable a federated experience? (especially as there could 
> be many)

I fear that you have not fully captured what the user consent is about. 
See the above explanations. In addition, there is no concept of federation.

> b. deciding what is the main RS (here RS1) to be called by the client 
> seems very critical, as it is the one that needs to orchestrate 
> everything.
> This seems a very hierarchical and imperative model which seems 
> somewhat counter intuitive in terms of developer experience (as least
> as it is made today, we clearly don't go into so much details). The 
> call hierarchy may quickly become very complex, which may also become
> a problem when separate services evolve.

The client calls the main RS (here RS1). What may happen next is fully 
dependant upon the operation that the user is willing to perform and
this is unpredictable (since the back end service may change at any 
point of time).

> c. RS1 gets all the information required to access all sub-resources, 
> and therefore gets also a lot of responsibility (and power). But from 
> finapp's
> point of view, it is the one that has the relationship with the user 
> and is providing the core value proposition, while RS1 is just an 
> external service.

  So is it really a problem ?

> d. multi-user (common B2B scenario): John wants to authorize a read 
> access to his finapp account to his external auditor, Ann (who is not 
> a direct user
> of finapp herself, but might already be registered by openbanking 
> AS0). How do you do that? Does it require the access token itself to 
> be able to delegate rights?

The intent of the short description I sent was to describe two simple 
scenarios, so that we could start discussing about them.
At this point, the intent is not to cover all the scenarios you may 
dream of.

> e. more generally, a threat model would be required, as there are many 
> more interactions now.

There are less interactions than in XAuth: there is no protocol between 
ASs and RSs, nor between ROs and ASs.

Before a threat model, a trust model is needed. Do we have a trust model 
for XAuth ?
Unfortunately not, since the word "trust" is absent in the main body of 
draft-hardt-xauth-protocol-12.

In this model, the trust relationships are as follows:

  * The user trusts its client.
  * If a user has an account opened with an AS, then he trusts that AS
    to deliver the requested and genuine attributes into an access token.
  * A RS may trust one or more ASs for one or more types of attributes
    _and_ for performing a given operation.
  * A RS may be administered remotely by one or more RO.

_Note_: for authentication, a RS may accept either FIDO or one or more 
types of attributes from one or more ASs.

Denis

> Cheers,
> Fabien
>

This is a new thread.


Preamble: This model is quite different from the XAuth model.
In particular, a RO has no relationship with any AS and a Client does 
not need to be associated with any AS prior to any access to a RS.

A key point of this model is that the user's consent is handled locally 
by the Client and hence no AS nor RS is handling a man machine interface
for the user consent. This allows to support locally the user consent 
for multiple ASs while keeping all ASs ignorant about the choices of the 
user
made for accessing a particular RS.
*

**+--------++------------+
|User||Resource|
||| Owner (RO) |
+--------++------------+
|\|
|\|
|\|
|\|
+-----------++---------------++------------+
||---->| Authorization |||
|| (2) |Server (AS)|||
||<----||||
|Client|+---------------+||
||-------------------------->|Resource|
|User|(1)|Server|
|Consent|<--------------------------|(RS)|
|element|||
||-------------------------->||------>
||(3)||(4)
||<--------------------------||<------
+-----------++------------+
*
The flow of operations is as follows:

The Client (which may have been previously authenticated using FIDO) 
contacts the RS and after some dialogue with the RS selects an operation
that it wants to perform on the RS (1a). Note that it may also indicate 
directly the operation that it wants to perform on the RS without any 
prior dialogue.
In return (1b), the RS informs the Client about which attributes are 
needed by the RS for performing the requested operation and from which 
Attributes Servers
they may be obtained.

This information is specifically marked to indicate that it shall be 
handled by the "User Consent element" from the Client.
The presentation of that information is up to the man machine interface 
supported by the "User Consent element" from the Client.

The user can see which attributes are requested by the RS for performing 
the requested operation and, if it consents, the Client contacts one or 
more
appropriate Authorization Servers (2a). The user consent is hence 
captured locally by the Client (i.e. there is no dialogue with any AS 
nor any RS).

When the Client got the access tokens from these authorization servers 
(2b), it sends all of them in a single request to the RS (3a).

End of the story for a simple access


Start of a subsequent story for a delegation case

Let us now suppose that the RS is unable to fulfil the request by its 
own and that it needs to contact another RS. RS1 contacts RS2 (4a) and 
indicates the operation
that it wants to perform on RS2 (that operation may not be the same as 
the original operation). In return (4b), RS2 informs RS1 about which 
attributes are needed
by RS2 for performing the requested operation and from which Attributes 
Servers they may be obtained. RS1 forwards that information to the Client.

This information is marked to indicate that it shall be handled by the 
"User Consent element" from the Client. The presentation of that 
information is up to the man machine
interface from the Client. The user can see which attributes are 
requested by RS2 for performing the new requested operation and, if it 
consents, the Client contacts one or more
appropriate Authorization Servers. The user consent is hence captured 
locally by the "User Consent element" from the Client. (i.e. there is no 
dialogue with any AS, nor RS1, nor RS2).

When the Client got the access token(s) from the authorization 
server(s), it sends all of them in a single request to RS1. RS1 then 
forwards the additional access token(s) to RS2.


Some observations:

The user nor the Client are linked with any particular AS. A user may 
use today an AS of the Bank of America and may change tomorrow to the 
Bank of Missouri.
As soon as he will be registered with the Bank of Missouri, he will be 
able to get access tokens from the AS of the Bank of Missouri. The AS of 
Bank of America
has not been able to know where its access tokens have been used. This 
will be the same for AS of the Bank of Missouri. There is no need for 
any direct dialogue
between any AS and any RS at the time a client is making an access. 
There is no need for any RO to contact any AS.

This model has been constructed following a "Privacy by Design" approach.

Denis

--------------BDADE35EBB5A0A7B8B673C7A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Fabien,

    


    

    
It would have been appreciated that you
      kept the original message in your response. I have copied it again
      at the end of this email.

    

    


    

    
Comments are between the lines.

    


    

    

      
      
Hi Denis, 
        


        

        
I think it's interesting, but also very different to
          XYZ/XAuth so it raises many questions ;-)

        
The figure is impossible to read.

      

    

    
Use a PC. Copy and paste and then use the Courier font. On my PC
      (with the clear figure) it was perfect.

    

      

        
So let me try to summarize the suggested approach, with a
          concrete example, to make sure we understand well:

        


        

        
0. The client authN to the AS (in whatever way is
            supported)

        
Ex : client is a corporate financing called "finapp".
          finapp contacts AS0 for authentication (say an openbanking
          service).  

        
User is John Doe, CFO at NeedMoney Inc. (+ other identity
          claims if needed, maybe some verified credential from
          NeedMoney Holding that John is indeed CFO).

        


        

        
Dear John, 

        
to access to your finapp, please identify yourself
            through your prefered openbanking account.

        
Thanks

      

    

    
If I understand you correctly,  finapp is a local application
      e.g. on your smartphone.

    

    

      
1. The client contacts a RS in a discovery
          phase, which includes the selection of (at least) an
          operation, for which the RS returns the required authZ
          attributes 
        
Ex : finapp needs to use NeedMoney's data to evaluate how
          much credit it can offer.

        


        

        
Op1 : compute the credit rating, from RS1 (this is
          outsourced to an external credit analyst), through the
          external service's own AS1.

        

        
But to do that, RS needs your historic bank statements.

        
Op2 : get your list of banks, RS2 (as registered within
          finapp), through openbanking AS0 and retrieve the bank
          statements : 

        
Op3a : get historic data from his main bank, RS2a (say an
          international bank), through openbanking AS0

        
Op3b : same from a second bank account, RS2b (say a local
          bank), through openbanking AS0

      

    

    
Why don't you make your very first example a little bit more
      complicated ? with RS1, RS2a, RS2b, ... AS0, AS1, ... 

    

    
:-)

      

      The intent of the first email was to discuss a basic
      model and to place the highlights on the way to capture the user's
        consent 

      in an interoperable manner without letting know to any RS or AS
      the choices of the user. This is a fundamental feature of the
      model.

      In XAuth, the user's consent is not formalized in the protocol :
      "User consent is often required at the GS".

    

    

      

        
2. User consent 

        
RS1 aggregates the list of attributes required (from all
          RS) and sends it to finapp.

      

    

    

      

        
Dear John, 

        
To evaluate your credit request, we need the following
            information: 

        
- your list of bank accounts (retrieved from your finapp
            account)

        
- the associated banking statements over the past 12
            months (from each bank)

        
- we'll pass that data to the credit agency, which will
            return your credit score 

        
Do you agree ?

        


        

        
John approves (or not..., maybe he'll agree only for one
          specific bank), via finapp directly 

          (I like that, albeit in a more traditional flow, I'm also
          separating the UI from the rest of the protocol of XYZ, and it
          works too).

      

    

    
As described, the user could simply push to the RS the banking
      statements over the past 12 months (from each bank).

      The user consent is not about : "Do you agree that  we
        pass the data to the credit agency, which will return your
        credit score"

      since no attributes nor ASs are involved in the question.

      

    
I guess you want the user to get access tokens targeted for RS2x
      so that each bank will accept to disclose his banking statements
      over the past 12 months.

    
The consent is whether the user accepts to get access tokens from
      some of his banks targeted for RS2x for the following operation: 

      "Retrieval of the past 12 months banking statements" which
      corresponds to an API for each bank and then to send these access
      tokens to RS1.

    
In practice, the client (e.g. using FIDO) will connect
      transparently to each of the appropriate AS from the banks and
      will get the requested access tokens 

      with a requested validity period of about 5 minutes.

    

      

        
3. Requests to the protected resources 

        
The client gets the access tokens and uses the services for
          which access was granted.

        


        

        
Analysis: (maybe I didn't get everything right, if so
            let me know) 

        
The trust model is focused around the relationship between
          the enduser (John) and his application (finapp), which seems
          fine.

      

    

    
No. The trust model is not making a focus on that specific
      relationship. BTW, no access token is necessarily needed by the
      user to be able to use finapp.

    

    

      
=> I see some potential issues : 
        


        

        
a. it will be really difficult for an end user to
          understand what AS0 and AS1 are, why they're different, and
          why he needs to authenticate to each of them. 

          How do you enable a federated experience? (especially as there
          could be many)

      

    

    
I fear that you have not fully captured what the user consent is
      about. See the above explanations. In addition, there is no
      concept of federation. 

    

    

      

        
b. deciding what is the main RS (here RS1) to be called by
          the client seems very critical, as it is the one that needs to
          orchestrate everything. 

          This seems a very hierarchical and imperative model which
          seems somewhat counter intuitive in terms of developer
          experience (as least 

          as it is made today, we clearly don't go into so much
          details). The call hierarchy may quickly become very complex,
          which may also become 

          a problem when separate services evolve.

      

    

    
The client calls the main RS (here RS1). What may happen next is
      fully dependant upon the operation that the user is willing to
      perform and 

      this is unpredictable (since the back end service may change at
      any point of time).

    

      

        
c. RS1 gets all the information required to access all
          sub-resources, and therefore gets also a lot of responsibility
          (and power). But from finapp's 

          point of view, it is the one that has the relationship with
          the user and is providing the core value proposition, while
          RS1 is just an external service.

      

    

    
 So is it really a problem ? 

    

    

      

        
d. multi-user (common B2B scenario): John wants to
          authorize a read access to his finapp account to his external
          auditor, Ann (who is not a direct user 

          of finapp herself, but might already be registered by
          openbanking AS0). How do you do that? Does it require the
          access token itself to be able to delegate rights?

      

    

    
The intent of the short description I sent was to describe two
      simple scenarios, so that we could start discussing about them.

      At this point, the intent is not to cover all the scenarios you
      may dream of.

    

      

        
e. more generally, a threat model would be required, as
          there are many more interactions now.

      

    

    
There are less interactions than in XAuth: there is no protocol
      between ASs and RSs, nor between ROs and ASs.

      

      Before a threat model, a trust model is needed. Do we have a trust
      model for XAuth ? 

      Unfortunately not, since the word "trust" is absent in the main
      body of draft-hardt-xauth-protocol-12.

    
In this model, the trust relationships are as follows:

    
    
      
  • The user trusts its client.
    • 
      
  • If a user has an account opened with an AS, then he trusts
        that AS to deliver the requested and genuine attributes into an
        access token.
    • 
      
  • A RS may trust one or more ASs for one or more types of
        attributes and for performing a given operation.
    • 
      
  • A RS may be administered remotely by one or more RO.
    
      
    • 
    

    
Note: for authentication, a RS may accept either FIDO or
      one or more types of attributes from one or more ASs. 

    
Denis

    

      

        
Cheers, 

        
Fabien

        

      

      

    

    

      This is a new thread.

    
    

      
 

          Preamble: This model is quite different from the XAuth model.
          

          In particular, a RO has no relationship with any AS and a
          Client does not need to be associated with any AS prior to any
          access to a RS.

          

          A key point of this model is that the user's consent is
          handled locally by the Client and hence no AS nor RS is
          handling a man machine interface 

          for the user consent. This allows to support locally the user
          consent for multiple ASs while keeping all ASs ignorant about
          the choices of the user 

          made for accessing a particular RS.

          

            

                   +--------+                           +------------+

                     |  User  |                           |  Resource  |

                     |        |                           |
              Owner (RO) |

                     +--------+                           +------------+

                         |      \                             
              |

                         |       \                             |

                         |        \                            |

                         |         \                           |

                  +-----------+     +---------------+     +------------+

                  |           |---->|
              Authorization |     |            |

                  |           | (2) |  Server (AS)  |     |            |

                  |           |<----|               |     |            |

                  |  Client   |     +---------------+     |            |

                  |           |-------------------------->|  Resource  |

                  |   User    |           (1)             |   Server   |

                  |  Consent  |<--------------------------|    (RS)    |

                  |  element  |                           |            |

                  |           |-------------------------->|            |------>

                  |           |           (3)             |            |  (4)

                  |           |<--------------------------|            |<------

                  +-----------+                           +------------+

          

          The flow of operations is as follows:

          

          The Client (which may have been previously authenticated using
          FIDO) contacts the RS and after some dialogue with the RS
          selects an operation 

          that it wants to perform on the RS (1a). Note that it may also
          indicate directly the operation that it wants to perform on
          the RS without any prior dialogue. 

          In return (1b), the RS informs the Client about which
          attributes are needed by the RS for performing the requested
          operation and from which Attributes Servers 

          they may be obtained. 

          

          This information is specifically marked to indicate that it
          shall be handled by the "User Consent element" from the
          Client. 

          The presentation of that information is up to the man machine
          interface supported by the "User Consent element" from the
          Client. 

          

          The user can see which attributes are requested by the RS for
          performing the requested operation and, if it consents, the
          Client contacts one or more 

          appropriate Authorization Servers (2a). The user consent is
          hence captured locally by the Client (i.e. there is no
          dialogue with any AS nor any RS).

          

          When the Client got the access tokens from these authorization
          servers (2b), it sends all of them in a single request to the
          RS (3a).

          

          End of the story for a simple access

      
 

          Start of a subsequent story for a delegation case

          

          Let us now suppose that the RS is unable to fulfil the request
          by its own and that it needs to contact another RS. RS1
          contacts RS2 (4a) and indicates the operation 

          that it wants to perform on RS2 (that operation may not be the
          same as the original operation). In return (4b), RS2 informs
          RS1 about which attributes are needed 

          by RS2 for performing the requested operation and from which
          Attributes Servers they may be obtained. RS1 forwards that
          information to the Client. 

          

          This information is marked to indicate that it shall be
          handled by the "User Consent element" from the Client. The
          presentation of that information is up to the man machine 

          interface from the Client. The user can see which attributes
          are requested by RS2 for performing the new requested
          operation and, if it consents, the Client contacts one or more
          

          appropriate Authorization Servers. The user consent is hence
          captured locally by the "User Consent element" from the
          Client. (i.e. there is no dialogue with any AS, nor RS1, nor
          RS2). 

          

          When the Client got the access token(s) from the authorization
          server(s), it sends all of them in a single request to RS1.
          RS1 then forwards the additional access token(s) to RS2.

          

          

          Some observations: 

          

          The user nor the Client are linked with any particular AS. A
          user may use today an AS of the Bank of America and may change
          tomorrow to the Bank of Missouri. 

          As soon as he will be registered with the Bank of Missouri, he
          will be able to get access tokens from the AS of the Bank of
          Missouri. The AS of Bank of America 

          has not been able to know where its access tokens have been
          used. This will be the same for AS of the Bank of Missouri.
          There is no need for any direct dialogue 

          between any AS and any RS at the time a client is making an
          access. There is no need for any RO to contact any AS.

      
This model has been constructed following a
          "Privacy by Design" approach.

      Denis

      

  


--------------BDADE35EBB5A0A7B8B673C7A--


From nobody Fri Jul 10 09:32:28 2020
Return-Path: 
X-Original-To: txauth@ietf.org
Delivered-To: txauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD483A0F08; Fri, 10 Jul 2020 09:32:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 7.7.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: txauth@ietf.org, gnap-chairs@ietf.org, The IESG 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-ID: <159439873228.11770.15361342021563935869@ietfa.amsl.com>
Date: Fri, 10 Jul 2020 09:32:12 -0700
Archived-At: 
Subject: [Txauth] WG Action: Formed Grant Negotiation and Authorization Protocol (gnap)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jul 2020 16:32:20 -0000

A new IETF WG has been formed in the Security Area. For additional
information, please contact the Area Directors or the WG Chairs.

Grant Negotiation and Authorization Protocol (gnap)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Yaron Sheffer 
  Leif Johansson 

Assigned Area Director:
  Roman Danyliw 

Security Area Directors:
  Benjamin Kaduk 
  Roman Danyliw 

Mailing list:
  Address: txauth@ietf.org
  To subscribe: ​https://www.ietf.org/mailman/listinfo/txauth
  Archive: https://mailarchive.ietf.org/arch/browse/txauth/

Group page: https://datatracker.ietf.org/group/gnap/

Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/

This group is chartered to develop a fine-grained delegation protocol for
authorization, API access, user identifiers, and identity assertions. The
protocol will also allow the client to present unverified identifiers and
verifiable assertions to the Authorization Server (AS) as part of its
request. This protocol enables an authorizing party to delegate access
to client software to use a Resource Server (RS) with this token. It will
expand upon the uses cases currently supported by OAuth 2.0 and OpenID
Connect (itself an extension of OAuth 2.0) to support authorizations
scoped as narrowly as a single transaction, provide a clear framework for
interaction among all parties involved in the protocol flow, and remove
unnecessary dependence on a browser or user-agent for coordinating
interactions.

The delegation process will be acted upon by multiple parties in the protocol,
each performing a specific role. The protocol will decouple the channels used
by the protocol participants to communicate from the delegation channel, which
happens directly between the client and the authorization server (in contrast
with OAuth 2.0, which is initiated by the client redirecting the user’s
browser). The protocol will include a means of specifying how the user can
potentially be involved in an interactive fashion during the delegation
process. The client and AS will use these interaction mechanisms to involve
the user, as necessary, to make authorization decisions. This decoupling
avoids many of the security concerns and technical challenges of OAuth 2.0
and provides a non-invasive path for supporting future types of clients
and interaction channels.

The group will define interoperability for this protocol between different
parties, including
 - client and authorization server;
 - client and resource server; and
 - authorization server and resource server.

The group will seek to minimize assumptions about the form of client
applications, allowing for:
- Fine-grained specification of access
- Approval of AS attestation to identifiers and other identity claims
- Approval of access to multiple resources and APIs in a single interaction
- Multiple access tokens in a single request and response
- AS-directed dispatch of access tokens to the appropriate RS
- Separation between the party authorizing access and the party operating the
client requesting access

The group will define extension points for this protocol to allow for
flexibility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possession
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other
information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource
requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information related to the identifiers
and identity assertions about the client
- Optimized inclusion of additional information (including identifiers and
identity assertions) through the delegation process

Additionally, the group will provide mechanisms for management of the protocol
lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Data model for granted access and mechanisms for the AS and RS to
communicate the granted access model

Although the artifacts for this work are not intended or expected to be
backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt
to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol
where possible.

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. Functionality that builds directly on OAuth 2.0 will be directed
to the OAuth Working Group, including functionality back-ported from the
protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic
methods, such as JOSE and COSE, to the delegation process. This group is not
chartered to develop new cryptographic methods.

The group is chartered to develop mechanisms for conveying identity
information within the protocol including existing identifiers (such as email
addresses, phone numbers, usernames, and subject identifiers) and assertions
(such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
Credentials). The group is not chartered to develop new formats for
identifiers or assertions, nor is the group chartered to develop schemas for
user information, profiles, or other identity attributes.

The initial work will focus on using HTTPS for communication between the
client and the authorization server, taking advantage of optimization
features of HTTP/2 and HTTP/3 where possible, and will strive to enable
simple mapping to other protocols such as CoAP when doing so does not
conflict with the primary focus.

Milestones to include:
- Core delegation protocol
- Key presentation mechanism bindings to the core protocol including TLS,
detached HTTP signature, and embedded HTTP signatures
- Conveyance mechanisms for identifiers and assertions
- Guidelines for use of protocol extension points
- (if needed) Guidelines on migration paths, implementation, and operations

Where possible, the group will seek to make use of tools to guide and inform
the standardization process including formal analysis, architecture documents,
and use case documents. These artifacts will not be considered as working
group milestones or deliverables.

The working group will cooperate and coordinate with other IETF WGs such as
OAUTH, and work with external organizations, such as the OpenID Foundation,
as appropriate.

Milestones:

  Jul 2021 - Core delegation protocol to Working Group Last Call

  Oct 2021 - Key presentation mechanism binding for each communication
  channel to Working Group Last Call

  Dec 2021 - Guidelines for use of protocol extension points to Working Group
  Last Call

  Feb 2022 - Guidelines on migration paths, implementation, and operations to
  Working Group Last Call




From nobody Fri Jul 10 10:39: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 A373E3A0789 for ; Fri, 10 Jul 2020 10: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 66eJtMjgzRKk for ; Fri, 10 Jul 2020 10: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 529DE3A0544 for ; Fri, 10 Jul 2020 10:39:53 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id h19so7342973ljg.13 for ; Fri, 10 Jul 2020 10:39: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=bATqocGimeWDCUYxRROx+ovciRXoAPDNNDHqy7F8a+o=; b=G/AD4uuPH3UpQrBWJZnGNRrPNnPZymkE3kYJMDGXXYeV6aAyXXZ4X4EtV2dvYjtT2+ 4PxnPtZEBNgl8N10S6rGTGjWQJze2BahZh7YF2i2QDaKq3FglCdZ+jzNMiVq+D2wryed bvasqF3I7fyXQmAtTZLgUIzql3qGnnk5KjNfMCg9bJEiH+6dy2QG4MGfMYyqYqf8da65 K14boKZpjjF2A9g0GcXY8p7KiXNnnGRaIxUYJmWIVPLwKbaw3dLAz9iewMgOadorLFNf pxMMoN7OO8mVpFvmxqdhRNIJ2o7nwpAzH5I9zxzoTslt4IibfrHIkjKgeCK7QfLL+WYP QRYg==
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=bATqocGimeWDCUYxRROx+ovciRXoAPDNNDHqy7F8a+o=; b=Ubi2N3Rn5tQUpW2VhpmbfT/FsV6F21ir5GVwGeXsr17xfSxDGQ83VSidCD1mhY12hz 6c3URQILapgC1ZZE6c8hVjtYXt8qrZCoeEMphwjQ/3BgVrQy4DWhFLJKFWfD/HhnvA/B gBw1rpBcg0KlprJCkhzIvw9wL8OhrFSVH3JOyot9OhOduLU1022vgwYyF4aXDaTztAxT +AftS0fjDJ/kHbTVut7NUWn2KQs6F8sPCVsSjbEOkI11z8OAJSNVWwwzV3PZxK9p6zjd ptFA+eLluR5co8ecqMfPNQu+aMQldd6FNCgilRA45EsnulynI4hMzmw0lzodzfEEKXoG XeRQ==
X-Gm-Message-State: AOAM533HcEpNbBDGVbwFtS8wi7PrYVk19gLIc5fVHMJsTtxFsHTocUrp 9Kd87HnErmdgT7WrDRt40+3dVFAswO9CZ0UftfI=
X-Google-Smtp-Source: ABdhPJxAylnN30f7YPIWi0YWir4lX9WxoGMXIFlrV2vnrobj0aWFeKVsmUp1D8kqqde3jocPBIogMG3Vbl3jC47WpIk=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr3471822ljg.69.1594402790511; Fri, 10 Jul 2020 10:39:50 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>     <69082870-1A99-4912-95EA-D1B7A1C967E5@mit.edu>  
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 10 Jul 2020 10:39:13 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f5186605aa19d35e"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 10 Jul 2020 17:39:57 -0000

--000000000000f5186605aa19d35e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 9, 2020 at 5:46 PM Justin Richer  wrote:

>
>
> On Jul 9, 2020, at 6:50 PM, Dick Hardt  wrote:
>
>
>
> On Thu, Jul 9, 2020 at 12:17 PM Justin Richer  wrote:
>
>> On Jul 9, 2020, at 2:32 PM, Dick Hardt  wrote:
>>
>>
>> Looks like you missed the point of my code example, as your response is
>> focussed on the aspects I had in comments, so let me clarify.
>>
>>
>> The point seemed to be about the overall complexity and readability, and
>> that=E2=80=99s what I responded to.
>>
>
> It was about the complexity and readability -- of those specific lines of
> code.
>
>
> But it=E2=80=99s not just about those lines, it=E2=80=99s about the conte=
xt that those
> lines are in and the follow-on code paths that they cause. A lot of what
> you had =E2=80=9Cin comments=E2=80=9D for the XAuth example would have re=
peated what was
> already included in the XYZ example, as I pointed out.
>

The context between those lines is pretty much the same. Yes, the XAuth
example would have had to loop over each scope and RAR object, which is not
that different than XYZ looping over each item, and the deciding how to
process each item. My point is that checking the object type to decide what
to do is an opaque decision vs checking an explicit type.


>
>
> I've used JS type polymorphism to provide a cleaner API. For example,
> making an HTTP request. If I'm good with all the defaults, I can just
> provide the URI as a string, if I want to change a default, I provide an
> object and the URI is now a property of the object. Polymorphism allows t=
he
> caller to have a simpler interface when it is a simple operation.
>
> Do you have any examples of JSON polymorphism used in other protocols
> besides in a JWT?
>
>
> Sounds to me like you=E2=80=99re describing exactly the kind of polymorph=
ism that
> I=E2=80=99m talking about here. Use a string where it makes sense and an =
object
> where it makes sense, and there=E2=80=99s no ambiguity in calling the fun=
ction. As
> you say, it's all about providing a cleaner API for the caller, and makin=
g
> things consistent in the model that the caller and provider are using. It
> takes a little bit of extra effort on the part of the API provider, but
> that=E2=80=99s where the complexity cost should be paid.
>

My examples are not the same at all. The caller has a simpler version of
passing the same object. XYZ is passing two different types, where a string
means one thing, and an object means something else. The string is not a
shorthand for the object.

In polymorphic APIs, it makes the code cleaner to pass a singular item when
the API takes an array, or the API takes a string for the common property
of the object which is the parameter. Here are some code examples for both:


// passing a singular item, a simpler version of foo(['string'])
foo('string')
// passing a plurality of the same item
foo(['string1','string2','string3'])

// implementation

foo =3D ( param ) =3D> {
    var a =3D []
    if (typeof param =3D=3D=3D 'string') {
        a[0] =3D param;
    } else if (typeof param =3D=3D=3D 'array') {
        a =3D param;
    }
    // process array a
}


// pass a uri as string and accept all defaults, a simpler version of
bar({uri:'uri'})
bar('uri')
// pass an object with uri and method
bar({uri: 'uri', method: 'POST'})

// implementation
bar =3D ( param ) =3D> {
    var p =3D DEFAULT_OBJ;
    if (typeof param =3D=3D=3D 'string') {
        p.uri =3D param;
    } else if (typeof param =3D=3D=3D 'object') {
        Object.keys(param).forEach( item =3D> {
            p[item] =3D param[item];
        });
    }
    // process p object
}


In GNAP, we could take a string rather than an array for a scope parameter,
for example:

"scope": "read"


instead of

"scope": ["read"]


OIDC uses the latter polymorphism for

{
  "name": {"essential": true},
  "photo": null
}

as being shorthand for

{
  "name": {"essential": true},
  "photo": {"essential": false}
}



>
>
>
>>
>>
>> This line (which is determining the type of the item in the array):
>>
>> if (typeof item =3D=3D=3D string')
>>
>>
>> is implicitly stating that the item is an oauth scope.
>>
>>
>> No, it is not. It is saying that it is a resource request represented as
>> a string. One way to represent a resource request as a string is an OAut=
h 2
>> style scope. And if you=E2=80=99re building up from an existing OAuth 2 =
system,
>> then you could use a scope there. But that=E2=80=99s not the same as sta=
ting =E2=80=9Cthe
>> item is a scope=E2=80=9D. In my examples, I had been trying to use the t=
erminology
>> that you were using, but I=E2=80=99m afraid that made things more unclea=
r.
>>
>
> We are comparing how to do it in XYZ vs XAuth -- so to make it apples and
> apples, the string is a scope, since that is the use case we are looking =
at.
>
>
> You can use a scope as the string, and if you want to think of all string
> values in this request as all being =E2=80=9Cscopes", that=E2=80=99s fine=
, but only if you
> can concede that the scope can mean whatever the AS wants. I think that
> perhaps you=E2=80=99re putting a certain amount of semantic weight to =E2=
=80=9Cscope=E2=80=9D that
> I=E2=80=99m missing, though.
>

The string could be a scope, or it could be a claim such as in my "oidc"
type example. The AS could support both scope and claims, and they could
have overlapping string values.



>
>
>
>>
>> Whereas it is explicit in this statement
>>
>> if (authorizations.type =3D=3D=3D 'oauth_scope')
>>
>>
>> which I think it easier to understand what is happening (in my opinion o=
f
>> course).
>>
>> XYZ has types, they are just implicit. RAR has explicit types, and that
>> does not look to be holding back RAR. I don't understand why you think
>> having explicit types will hold us back.
>>
>>
>> The =E2=80=9Ctype=E2=80=9D in RAR is a name spacing device to allow exte=
nsibility in
>> different aspects of the request. This is at a lower layer than how they=
=E2=80=99re
>> being applied here, and it therefore makes more sense at that layer. It=
=E2=80=99s a
>> way for a particular API to define the dimensions that it cares about in
>> its request. It=E2=80=99s not really an even comparison.
>>
>
> And the type in XAuth authorizations is different schemas for making a
> request. "oauth_scope", "oauth_rar", and now "oidc". I would expect that
> there may be more in the future, and we have a clear way of adding schema=
s,
> and for the client and AS to know they are talking the same "language".
>
>
> And I=E2=80=99m saying that additional =E2=80=9Cschemas=E2=80=9D for requ=
esting information should
> be defined separately from the GNAP schema. We disagree on this topic and
> we=E2=80=99re repeating ourselves.
>

The charter is pretty clear that GNAP should not define schemas, so I don't
know what you mean by the "the GNAP schema"


>
>
>
>>
>> Do you want to let the string and object be anything the AS and RS decid=
e
>> they could mean?
>>
>>
>> Yes. Just like the AS can decide that an OAuth scope could mean any
>> number of things.
>>
>
> That was what I was afraid of. While an OAuth scope could mean whatever
> the AS decides it wants to be, the Client and AS know it is an OAuth scop=
e.
>
>
> How is that any different? I=E2=80=99m confused as to why you think it=E2=
=80=99s important
> to call this item a =E2=80=9Cscope=E2=80=9D so that you =E2=80=9Cknow wha=
t it is=E2=80=9D, but then you=E2=80=99re
> OK with =E2=80=9Cscope=E2=80=9D meaning literally anything.
>

A scope string is one of a set of strings defined by the AS.

The AS may use strings to define a different schema, such as which claims
to return from a userinfo endpoint.

 I'm going to separate the my other responses into separate threads as they
are different topics.

/Dick

>
> =E1=90=A7

--000000000000f5186605aa19d35e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Jul 9, 2020 at 5:46 PM Justin=
 Richer <jricher@mi=
t.edu> wrote:


On Jul 9, 2020, at 6:=
50 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, Jul 9, 2020 at 12:17 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 9, 20=
20, at 2:32 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Looks l=
ike you missed the point of my code example, as your response is focussed o=
n the aspects I had in=C2=A0comments, so let me clarify.=C2=A0
<=
/div>

The point seemed to be about th=
e overall complexity and readability, and that=E2=80=99s what I responded t=
o.

It was about the compl=
exity and readability -- of those specific lines of code.
=


But it=E2=80=99s not just about those line=
s, it=E2=80=99s about the context that those lines are in and the follow-on=
 code paths that they cause. A lot of what you had =E2=80=9Cin comments=E2=
=80=9D for the XAuth example would have repeated what was already included =
in the XYZ example, as I pointed out.
The context between those lines is pretty much the same. Yes, =
the XAuth example would have had to loop over each scope and RAR object, wh=
ich is not that different than XYZ looping over each item, and the deciding=
 how to process each item. My point is that checking the object type to dec=
ide what to do is an opaque decision vs checking an explicit type.
=C2=A0
<=
br>

// passing a si=
ngular item, a simpler version of foo(['string'])
foo('string')
// passing a plurality of the same item
foo(['string1','string2','strin=
g3'])

// implementation
foo =3D ( param ) =3D> {
=C2=A0 =C2=A0 var a =3D []
=C2=A0 =C2=A0 if (typeof param =3D=3D=3D 'string') {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a[0] =3D pa=
ram;
=C2=A0 =C2=A0 } else if (ty=
peof param =3D=3D=3D 'array') {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a =3D param;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 // process array a
}


// pa=
ss a uri as string and accept all defaults, a simpler version of bar({uri:&=
#39;uri'})
bar('uri'=
)
// pass an object with uri and=
 method
bar({uri: 'uri',=
 method: 'POST'})

// implementation
bar =3D ( param ) =3D> {
=C2=A0 =C2=A0 var p =3D DEFAULT_OBJ;
=C2=A0 =C2=A0 if (typeof param =3D=3D=3D '=
string') {
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 p.uri =3D param;
=C2=
=A0 =C2=A0 } else if (typeof param =3D=3D=3D 'object') {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Object.keys(pa=
ram).forEach( item =3D> {
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 p[item] =3D param[item];
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 });
=

=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 // process p object
}

In GNAP, we could take a string rather than an array for a =
scope parameter, for example:

<=
div>"scope": "read"

instead of=C2=A0

<=
/div>
"scope": ["read"]
=


OIDC uses the l=
atter polymorphism for=C2=A0

{=C2=A0
=C2=
=A0 "name": {"essential": true},
=C2=A0 "=
;photo": null
}

as being shorthand =
for=C2=A0

{=C2=A0
=C2=A0 "name"=
;: {"essential": true},
=C2=A0 "photo": {&quo=
t;essential": false}
}

=
=C2=A0
=

=C2=A0


This line (which is determining=C2=A0the ty=
pe of the item in the array):

=
if (typeof item =3D=3D=3D string')

is implicitly stating=C2=A0that the item is an oau=
th scope.=C2=A0

<=
/div>
No, it is not. It is saying that it is a resource request represe=
nted as a string. One way to represent a resource request as a string is an=
 OAuth 2 style scope. And if you=E2=80=99re building up from an existing OA=
uth 2 system, then you could use a scope there. But that=E2=80=99s not the =
same as stating =E2=80=9Cthe item is a scope=E2=80=9D. In my examples, I ha=
d been trying to use the terminology that you were using, but I=E2=80=99m a=
fraid that made things more unclear.
We are comparing how to do it in XYZ vs XAuth -- so to make it =
apples and apples, the string is a scope, since that is the use case we are=
 looking at.

You can use =
a scope as the string, and if you want to think of all string values in thi=
s request as all being =E2=80=9Cscopes", that=E2=80=99s fine, but only=
 if you can concede that the scope can mean whatever the AS wants. I think =
that perhaps you=E2=80=99re putting a certain amount of semantic weight to =
=E2=80=9Cscope=E2=80=9D that I=E2=80=99m missing, though.
=


The string could be a scope, or it could b=
e a claim such as in my "oidc" type example. The AS could support=
 both scope and claims, and they could have overlapping string values.=C2=
=A0

=C2=A0

=C2=A0

Whereas it is explicit in th=
is statement

if (authorizations.=
type =3D=3D=3D 'oauth_scope')

which I think it easier to understand what is happe=
ning (in my opinion of course).

XYZ has types, the=
y are just implicit. RAR has explicit types, and that does not look to be h=
olding back RAR. I don't understand why you think having explicit types=
 will hold us back.=C2=A0
=


The =E2=80=9Ctype=E2=80=9D in RAR is a name spacing dev=
ice to allow extensibility in different aspects of the request. This is at =
a lower layer than how they=E2=80=99re being applied here, and it therefore=
 makes more sense at that layer. It=E2=80=99s a way for a particular API to=
 define the dimensions that it cares about in its request. It=E2=80=99s not=
 really an even comparison.

And the type in XAuth authorizations=C2=A0is different schemas for makin=
g a request. "oauth_scope", "oauth_rar", and now "=
oidc". I would expect that there may be more in the future, and we hav=
e a clear way of adding schemas, and for the client and AS to know they are=
 talking the same "language".
=

And I=E2=80=99m saying that additional =E2=80=9Cschemas=E2=
=80=9D for requesting information should be defined separately from the GNA=
P schema. We disagree on this topic and we=E2=80=99re repeating ourselves.=
=C2=A0

The charter is pre=
tty clear that GNAP should not define schemas, so I don't know what you=
 mean by the "the GNAP schema"
=C2=A0

=C2=A0

Do yo=
u want to let the string and object be anything the AS and RS decide they c=
ould mean?=C2=A0

=

Yes. Just like the AS can decide that an OAuth scope could mean =
any number of things.

Tha=
t was what I was afraid of. While an OAuth scope could mean whatever the AS=
 decides it wants to be, the Client and AS know it is an OAuth scope.
=


How is that any different? I=
=E2=80=99m confused as to why you think it=E2=80=99s important to call this=
 item a =E2=80=9Cscope=E2=80=9D so that you =E2=80=9Cknow what it is=E2=80=
=9D, but then you=E2=80=99re OK with =E2=80=9Cscope=E2=80=9D meaning litera=
lly anything.

A scope str=
ing is one of a set of strings defined by the AS.

=
The AS may use strings to define a different schema, such as which claims t=
o return from a userinfo endpoint.

=C2=A0I'm g=
oing to separate the my other responses into separate threads as they are d=
ifferent topics.

/Dick

3D""=E1=90=A7


--000000000000f5186605aa19d35e--


From nobody Fri Jul 10 10:59: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 8CB8F3A07D6 for ; Fri, 10 Jul 2020 10:59:22 -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 eRPgRGSbnB91 for ; Fri, 10 Jul 2020 10:59:20 -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 2CF843A07D4 for ; Fri, 10 Jul 2020 10:59:20 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id e4so7448152ljn.4 for ; Fri, 10 Jul 2020 10:59:20 -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=A3xRoOSoBSQSl3zXxyYOimU1a05M9mP7UCIohSSU+rA=; b=AGUwE+cv7c0HSgdgyEsPME5SFvwBULwahE+RKHoMYSo0b77EV8Tbp/IJCjFXZHpo4s 6KAGGWPTIywlQfMH6xxWfBOyjwcn53tWcUGuofCAWP/DF8kFVYtXXQEz5vWN4Hv0VGj7 6yE+DcRWdjYJiMKVkfnSObBAUvjCAkyMh5yHhpLMw09mqPkjqG4bNSeCuuL0YAFoe61p ihjGJhEBrlaebEgRJp5vSdcOWBQkEyuo3hyYRFvm6I9TmBRT1CkbxunRl/KhjNX2g7CD ROwmcGaaEjO9V8UuPFChZPpC3NF6/aEL2fQ4QsdxyTHRShkfWFFp+2OzXw9VBjgdbO/D 79fQ==
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=A3xRoOSoBSQSl3zXxyYOimU1a05M9mP7UCIohSSU+rA=; b=AO+TO2fph/Ww2f+7yJnGU7+rY5cDLz0i9RhyGb4Ldj9ucJzDn+iESmY7nqGKqxH0L8 iJU6W4ZWovQjYvWfaPm/b2qJcejNwWjWf/zcf8N54R/n8IB1AFfar+rZAj2QD/Ep6qL/ L0EPeyOKmMzY9KXWrveOwNzkmsGvNkG+JLIXuj15LKd3hQva2WZTLr6zJMchhzLBsjZD duyJuPeCCkT1oNSXUIUaDiNpmAOkYmOt5ZoEirBJDCakbGk+vKOhc3jWHc5bnYiDjKmT oxrWjecJKLZuMuP1mdlmNP10ohKpOVaGXFNoqDTqMYUkWBLKMRlIK4OuT8IVnSEgpbLz XvLA==
X-Gm-Message-State: AOAM530UBLNdJMnOd3grCf+RMaLDkzvbWgp4l1xKGLGs4O8z+BTSEqKX 2G8ij1HZLZZPLA7ldOCEGHgzhRNoiv+1fN3zBtDu+CPy
X-Google-Smtp-Source: ABdhPJzNKSqnnvdJYGl5qbxr5JJDH0d0t/lS4JEDqndtNi8e5IzfmFazY7cPtpxRSgKoijb+rfd91CNdLgUKuSb2SjM=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr29547445ljh.110.1594403958129;  Fri, 10 Jul 2020 10:59:18 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>     <69082870-1A99-4912-95EA-D1B7A1C967E5@mit.edu>  
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 10 Jul 2020 10:58:42 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008d8afb05aa1a19ba"
Archived-At: 
Subject: [Txauth] XAuth "flaws" (Was: Polymorphism (Was: JSON Schema?))
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, 10 Jul 2020 17:59:23 -0000

--0000000000008d8afb05aa1a19ba
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for listing what you consider flaws in XAuth. It simplifies having a
disussion on them, and I hope to get a better idea of your concerns
On Thu, Jul 9, 2020 at 5:46 PM Justin Richer  wrote:

>
> Haven=E2=80=99t we been talking about them all along in all of these thre=
ads?
> Isn=E2=80=99t that what this conversation is largely about? I think I=E2=
=80=99ve been
> pretty clear, but my concerns include, but are not limited to, the
> following:
>
>  - Use of a =E2=80=99type=E2=80=99 field to indicate sub-schemas to be pa=
rsed and
> understood
>

What is your concern with this? What use case does it prevent you from
doing?


>  - Separation of string-style =E2=80=9Cscope=E2=80=9D parameters from obj=
ect-style =E2=80=9Crich=E2=80=99
> parameters
>

Do you mean that they are not in the same array? Both of these parameters
are in the "oauth_rich" type, but are in their own
"array"


>  - Lack of ability to cleanly define combinations of different approaches
>

This is too vague. Would you provide more clarity?


>  - Outsourcing of query schema to external specs, specifically reliance o=
n
> OAuth 2 technologies that come with OAuth 2 limitations
>

Outsourcing schemas is in the charter. OAuth 2 is just one of those
schemas. If other domains have their own schema, they can use it in GNAP as
well.


>  - Overly verbose and awkward syntax to specify simple requests
>

There is a balance between clarity and brevity. What use case does this
prevent you from solving? This sounds like a stylistic concerns rather than
a "flaw".


>  - Larger possibility of error conditions based on syntax alone (for
> example per the recent update,
>

"larger possibility"? Have you done an analysis of the error conditions in
both?


> if someone asks for a multi-token response named =E2=80=9Ctype=E2=80=9D, =
that=E2=80=99s a class of
> error;
>

Agreed. And it is a compromise doing that, but looked like the best of the
options.

It is a visible error that the client will get immediately in response to
the request. I think an error message specifically about this error would
be really useful.


> if someone puts a =E2=80=9Cclaims=E2=80=9D field in an =E2=80=9Coauth_sco=
pe=E2=80=9D typed request, that=E2=80=99s
> an error, etc)
>

Are you saying putting an ignored property in an object? I don't know what
you mean with this one.

/Dick
=E1=90=A7

--0000000000008d8afb05aa1a19ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

Thanks for listing what you consider =
flaws in XAuth. It simplifies having a disussion on them, and I hope to get=
 a better idea of your concerns
=
On Thu, Jul 9, 2020 at 5:46 PM Justin Richer <jricher@mit.edu> wrote:

Haven=E2=80=99t we been talking about them all along in all=
 of these threads? Isn=E2=80=99t that what this conversation is largely abo=
ut? I think I=E2=80=99ve been pretty clear, but my concerns include, but ar=
e not limited to, the following:

=C2=A0- Use of a =
=E2=80=99type=E2=80=99 field to indicate sub-schemas to be parsed and under=
stood

What is your concer=
n with this? What use case does it prevent you from doing?
=C2=A0=

=C2=A0- Separation of string-style =E2=80=
=9Cscope=E2=80=9D parameters from object-style =E2=80=9Crich=E2=80=99 param=
eters

Do you mean that th=
ey are not in the same array? Both of these parameters are in the "oau=
th_rich" type, but are in their own 
"array"
=
=C2=A0
=C2=A0- Lack of ability to cleanly d=
efine combinations of different approaches

This is too vague. Would you provide more clarity?
<=
div>=C2=A0
=C2=A0- Outsourcing of query sch=
ema to external specs, specifically reliance on OAuth 2 technologies that c=
ome with OAuth 2 limitations

<=
div>Outsourcing schemas is in the charter. OAuth 2 is just one of those sch=
emas. If other domains have their own schema, they can use it in GNAP as we=
ll.
=C2=A0
=C2=A0- Overly verbose=
 and awkward syntax to specify simple requests

There is a balance between clarity and brevity. What =
use case does this prevent you from solving? This sounds like a stylistic c=
oncerns rather than a "flaw".
=C2=A0
=C2=A0- Larger possibility of error conditions based on synta=
x alone (for example per the recent update, 
=


"larger possibility"? Have you done an analys=
is of the error conditions in both?
=C2=A0
=

if someone asks for a multi-token response named =E2=80=9Ctype=E2=
=80=9D, that=E2=80=99s a class of error; 

Agreed. And it is a compromise doing that, but looked like=
 the best of the options.

It is a visible error th=
at the client will get immediately in response to the request. I think an e=
rror message specifically about this error would be really useful.
=C2=A0
if someone puts a =E2=80=9Ccla=
ims=E2=80=9D field in an =E2=80=9Coauth_scope=E2=80=9D typed request, that=
=E2=80=99s an error, etc)

Are you saying putting an ignored property in an object? I don't know =
what you mean with this one.

/Dick=C2=A0
3D==E1=90=A7


--0000000000008d8afb05aa1a19ba--


From nobody Fri Jul 10 11:16: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 89DD33A07F3 for ; Fri, 10 Jul 2020 11:16: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 MNLcTWd1cjMr for ; Fri, 10 Jul 2020 11:16:24 -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 483B83A07F2 for ; Fri, 10 Jul 2020 11:16:24 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id q7so7534659ljm.1 for ; Fri, 10 Jul 2020 11:16: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=H1j+gRtGguZiwvV1kaXT609M/iNPeQ7zP8rhKcBUA90=; b=HH1npHUDYMI2kye+MOIFv9OLs5ocVnDvBOkazJ72Awd7kJ4I+/7W21BgDDeo+5PHqe 8HR6gga1948BQauwtzfZgpyQoAQ1fvF4LVDFZxfhhxMsLGd2c4eAX3VgmUyZh+BvhHsQ 2wbXGiVc9Duv9YJeOjSu8rZ+qz+7+pY7GfjKj4NkZz9TxmTbn4vVZSOrAvJ5UqpW8XmK obkbAqY+D5OAAyg6AID1ehJBqY+jrvBuTTpZaQK3rcHWdGNNRRQsnn96mvaXXn54uigF KUG6DzAlghExlIShObx+nGUnI8YoqglH4t+zCpEAd7Yx6iSx/L2yxgTp310Z1Puntz9A hfMQ==
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=H1j+gRtGguZiwvV1kaXT609M/iNPeQ7zP8rhKcBUA90=; b=qettp1bNIi5zZJJLG33uuXShsVKnc5IivNKyyPv6Rt9Br7RIiPR2bzU6ZDu22OrRB5 XcqYN+VJzakbimDUOafQasEcFdmQV8v7C2L3t2V14wwucJEyW0rCSUWIF1lPgSzieD3S WzytPCQm9/zOAmcinAtB0m8g4adMe+Md4M7nLhXBOWIoZUHbHW7hty7NBcto71vN5eyH 7pV363UjH6JpuzUGIsHCWLq63BMipzPm2mJV8JDMAIugGiAV5R4HTssHP6V+YLuNLktC 42ikIrCZT8CvvjNdlTtYuiLcqKvzJld3y8XZU2gmc66TorRV5h+P+h1pjQSZhOqbqjGi PxfQ==
X-Gm-Message-State: AOAM530U54p1iHAUqvaa5/89nPgOPseXzrA/gHvUKpbBY4enbbT8rZS3 Q/kJ+yFcMmWAVsSFIaE279zQolYKdlYPbyMIu34=
X-Google-Smtp-Source: ABdhPJy/Hx6nv1rqpxYrrgkSFKZ57u0sOzlPV0Z4SVyRME9OgMtQ45K/wnAmcaNpglou85yPwbqZdqTx2fuO5J9YPYA=
X-Received: by 2002:a05:651c:547:: with SMTP id q7mr38514519ljp.437.1594404982126;  Fri, 10 Jul 2020 11:16:22 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>
In-Reply-To: <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>
From: Dick Hardt 
Date: Fri, 10 Jul 2020 11:15:46 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000967b1d05aa1a5663"
Archived-At: 
Subject: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 10 Jul 2020 18:16:27 -0000

--000000000000967b1d05aa1a5663
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

inline ...

On Thu, Jul 9, 2020 at 5:44 PM Justin Richer  wrote:

> Yes, the core idea is to not have to parse an assertion to get back the
> core authentication information, which consists of an identifier (iss/sub
> pair in OIDC, but could be a number of things). Sometimes the client is
> going to want the rest of the identity information, but If the user=E2=80=
=99s
> logged into the client before, the client has likely cached that info and
> probably won=E2=80=99t need it, and sending it would be a violation of pr=
ivacy
> principles.. The client would want the info pretty much just in these cas=
es:
>
>  1. The client has never seen the user before.
>  2. The user=E2=80=99s information has been updated since the last time t=
he client
> saw it.
>

Agreed


>
> Now for case (1), how would the client know if it wants to request the
> user=E2=80=99s profile info or not, since it doesn=E2=80=99t know who the=
 user is?
>

But the client could know who the user is. The client may have used a
different AS to authenticate the user. The User may have self identified to
the client. The client may have a cookie saying who the user was and the
user said that was them. While the latter cases are really a strong hint,
they are likely right most of the time and can lead to a user experience
basde on that hint


> And the AS won=E2=80=99t know if client is going to want the profile info=
, since
> the AS won=E2=80=99t know if the client has the user=E2=80=99s info or no=
t. Sure, the AS
> might have seen that client and that user combo previously, but it doesn=
=E2=80=99t
> know if the client needs an update.
>

The client can share with the AS the user it knows or thinks it is dealing
with, which could let the AS respond if the information was new. This could
be the case for an AS that is providing claims, but not authentication, and
could happen silently. The user would only interact if the user information
had changed, and the client wanted the updated information.


>
> And for (2), the client won=E2=80=99t know if the user=E2=80=99s info has=
 been updated or
> not because it doesn=E2=80=99t know who the user is yet. If the AS can pr=
ovide some
> time of updated stamp to the client, the client can pull the new info whe=
n
> it needs it.
>

See above.


>
> If you ignore both of these cases and put all the user information inline
> with the main request/response, you end up in a situation where the clien=
t
> always requests everything and the server always provides everything, sin=
ce
> you can=E2=80=99t be sure you=E2=80=99re not in situation (1) or (2) ahea=
d of time.
>

See above. There are a number of other states the client could be in.

For example, the client could be stateless about user information, so it
knows it is ALWAYS in state 1.


>
> This is really what I mean about the two-stage identity protocol.
>

I know what it is. Per above, GNAP lets us support a wider set of use
cases. Why limit ourselves to what OIDC supported?


> In the first stage, you push the bare minimum of what you need to get the
> user known to the client. In the second stage, the client uses its access
> token to call an API to get whatever else it needs to know about the user=
.
>

>From a privacy perspective in non-enterprise use cases, I think the user
should give consent to any updated personal information to a client. In
general, the client should not be able to get the latest information about
a user whenever it wants.

/Dick
=E1=90=A7

--000000000000967b1d05aa1a5663
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



inline ...=C2=A0

On Thu, Jul 9, 2=
020 at 5:44 PM Justin Richer <jricher=
@mit.edu> wrote:
Yes, the core idea is to =
not have to parse an assertion to get back the core authentication informat=
ion, which consists of an identifier (iss/sub pair in OIDC, but could be a =
number of things). Sometimes the client is going to want the rest of the id=
entity information, but=C2=A0If the user=E2=80=99s logged into the client b=
efore, the client has likely cached that info and probably won=E2=80=99t ne=
ed it, and sending it would be a violation of privacy principles.. The clie=
nt would want the info pretty much just in these cases:

=
=C2=A01. The client has never seen the user before.=C2=A0
=C2=A02=
. The user=E2=80=99s information has been updated since the last time the c=
lient saw it.

Agreed
=
=C2=A0

Now for case (1), how woul=
d the client know if it wants to request the user=E2=80=99s profile info or=
 not, since it doesn=E2=80=99t know who the user is? 

But the client could know who the user is. The clien=
t may have used a different AS to authenticate the user. The User may have =
self identified to the client. The client may have a cookie saying who the =
user was and the user said that was them. While the latter cases are really=
 a strong hint, they are likely right most of the time and can lead to a us=
er experience basde on that hint
=C2=A0
And the AS won=E2=80=99t know if client is going to want the profile info=
, since the AS won=E2=80=99t know if the client has the user=E2=80=99s info=
 or not. Sure, the AS might have seen that client and that user combo previ=
ously, but it doesn=E2=80=99t know if the client needs an update.

The client can share with the AS the use=
r it knows or thinks it is dealing with, which could let the AS respond if =
the information was new. This could be the case for an AS that is providing=
 claims, but not authentication, and could happen silently. The user would =
only interact if the user information had changed, and the client wanted th=
e updated information.
=C2=A0

And for (2), the client won=E2=80=99t know if the user=E2=80=99s inf=
o has been updated or not because it doesn=E2=80=99t know who the user is y=
et. If the AS can provide some time of updated stamp to the client, the cli=
ent can pull the new info when it needs it.
See above.
=C2=A0

If you ignore both of these cases and put all the user information =
inline with the main request/response, you end up in a situation where the =
client always requests everything and the server always provides everything=
, since you can=E2=80=99t be sure you=E2=80=99re not in situation (1) or (2=
) ahead of time.

See above. The=
re are a number of other states the client could be in.

For example, the client could be stateless about user information, so=
 it knows it is ALWAYS in state 1.
=C2=A0
=


This is really what I mean about the two-stage identity=
 protocol. 

I know what it is. =
Per above, GNAP lets us support a wider set of use cases. Why limit ourselv=
es to what OIDC supported?
=C2=A0
In t=
he first stage, you push the bare minimum of what you need to get the user =
known to the client. In the second stage, the client uses its access token =
to call an API to get whatever else it needs to know about the user. 
=


From a privacy perspective in non-en=
terprise use cases, I think the user should give consent to any updated per=
sonal information to a client. In general, the=C2=A0client should not be ab=
le to get the latest information about a user whenever it wants.
=
=C2=A0
/Dick
3D""=E1=90=A7

--000000000000967b1d05aa1a5663--


From nobody Fri Jul 10 11:34: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 7104F3A080F for ; Fri, 10 Jul 2020 11:34: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 f9d3u_4sl927 for ; Fri, 10 Jul 2020 11:34:02 -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 8B9203A07FB for ; Fri, 10 Jul 2020 11:34:02 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id z24so7532045ljn.8 for ; Fri, 10 Jul 2020 11:34: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=dIEdN0ZFntIuOpQWFZo7abo2nUHM6HHMkcByKqrp1lY=; b=vadVpyDYv0J4dr8D/xOfqoNiZcHZB/qtmeL0zkJljumJ2VckrqvbMH9N8gIjAqqrDx onnqOkBBU1eKM0ymgVWNh1WKtwiV76qStotc1jtkVBaDDJ/ZOfwSqBeMHATxXYEW3l72 uY1IYIzLDJPotg79a8XT5FHxwBfaptGgTxHdsMHklNPNxBNyDleMLPamTeZLfkH6q6w5 bK6MMsP4vJbJ3FrZuDGb/F+rxqlLJioL/uvL3gOmRfZRw/xz1f9aMqPHhv/BqEqSXWp9 i/hE+l7GKWmWR+7acwm2lOflrc0dkjZm0+fgDjw+I5aRFFiDxTKYN4jmIx1JCB1vUx0J oGlQ==
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=dIEdN0ZFntIuOpQWFZo7abo2nUHM6HHMkcByKqrp1lY=; b=tWw7+7yOmhIifaOWFZK+SK9C7QJPt1gPhv8FfUaPelPwSAWZ+qIQeCv7yInKCa6zxl xGwem7WV7uqO60B2qG5TvcJWWB+JYWvRV+aHPo89Qkvv3Wx1X4l5dizfMWf2LQvDYEnT JbogIJwRy3CT9TlcDi4+PfaDJAZHMcMKrYQ1+w9XHtvivQqTx00/rUACkqh+YuB0hUR3 27einrrI5QBinFF6w5xwbTEaw61ojMofV1vtPd4YlLuQemOBRF1MgdVuW9m0dZfA2q6R xGlvGakrsq6gE5/6xR1NM85dSalxxe4HHjBRAWZoNu/F8fs4pIdHEQVAhOJJi51PeRCx rD0Q==
X-Gm-Message-State: AOAM533IblDDFV79lGe3eMDeJ8/mhAiJ5vS3WLLGESiNF0n5rMBJ0Hhe m08nNGzYVHAFw4gqY92liNT3aXtFl0Q5Kst5Y7GQk4LE5Gk=
X-Google-Smtp-Source: ABdhPJziTiTBwUusHNC7273wIwCojzJYoZ1ND6H1h9gXn5PKxI0odwPKy1Lkq6wYG+YXAhsiPhjXw5GkriUsgWus0wk=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr3574659ljg.69.1594406040321; Fri, 10 Jul 2020 11:34:00 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>
In-Reply-To: <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>
From: Dick Hardt 
Date: Fri, 10 Jul 2020 11:33:24 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a946e005aa1a95d6"
Archived-At: 
Subject: [Txauth] WG scope wrt. identity (Was: Polymorphism (Was: JSON Schema?))
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, 10 Jul 2020 18:34:12 -0000

--000000000000a946e005aa1a95d6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Justin, your stance is surprising for the following reasons:

1) Both XYZ and XAuth use the term claims, rather than identifiers. "A
claim is a statement that one subject, such as a person or organization,
makes about itself or another subject."[1]. A claim is clearly more than an
identifier.

2) XAuth has had non-identifier claims in the examples since -01 (name,
photo).

3) The charter does not state that ONLY identifiers will be returned,
identifiers are one of the examples, as are OIDC ID Tokens, SAML
assertions, and Verifiable Credentials. All of these often bind
non-identifiers to one or more identifiers.

[1] https://en.wikipedia.org/wiki/Claims-based_identity#Identity_and_claims

Justin's stance earlier in the discussion:


My stance is that we allow the client to ask for a small set of identifiers
about the user, or even just ask to =E2=80=9Cidentify the user=E2=80=9D, an=
d leave
everything else to a higher level identity protocol. I do not think that
having an identity and profile query/response language at the core of GNAP
is a good idea, and it=E2=80=99s certainly not in our charter.


On Thu, Jul 9, 2020 at 5:44 PM Justin Richer  wrote:


> I=E2=80=99m sorry that you are surprised by my stance, but it hasn=E2=80=
=99t changed since
> I helped write the section of the charter that you quoted below. A big
> reason that I chose that wording was to support this use case but not to =
go
> in depth with an identity protocol, which I never really wanted us to do.
> However, it seems as soon as =E2=80=9Cidentity=E2=80=9D was brought up pr=
eviously, people
> immediately jumped into talking about a full stack of user attributes and
> profile information. That wasn=E2=80=99t my intent in talking about ident=
ity, and I
> don=E2=80=99t think it=E2=80=99s something GNAP ought to do, at least not=
 on its own.
>
> I do think there=E2=80=99s room for us to provide identifiers alongside t=
he access
> token, so that=E2=80=99s there. There was stated interest in providing si=
gned
> assertions as well, so I made sure that was enumerated for those who want
> to do such work. And I think it makes sense for us to provide a way to
> describe what kinds of things I want to get from an access token by
> defining a general purpose syntax for describing those things (notably, a=
s
> a combination of reference strings and multi-dimensional objects). With
> these two, we can get most of what we need for a basic login system.
> Anything beyond that is going to need user profiles, authentication
> contexts, session control, and a lot of other identity-protocol stuff tha=
t
> GNAP shouldn=E2=80=99t be focusing on. We should keep it in mind as we bu=
ild GNAP,
> but I think that like OIDC all that important extra stuff should be built
> separately. To me, that=E2=80=99s what not defining schemas and formats m=
eans.
>
> I don=E2=80=99t see any conflict with the charter here, and I=E2=80=99m s=
urprised that you
> do.
>
> =E1=90=A7

--000000000000a946e005aa1a95d6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Justin, your stance is surprising for the following r=
easons:

1) Both XYZ and XAuth use the term claims,=
 rather than identifiers. "A claim is a statement that one subject, s=
uch as a person or organization, makes about itself or another subject.&quo=
t;[1]. A claim is clearly more than an identifier.

2) XAuth has had non-identifier claims=C2=A0in the examples=
 since -01 (name, photo).

3) The charter does not =
state that ONLY identifiers will be returned, identifiers are one of the ex=
amples, as are OIDC ID Tokens, SAML assertions, and Verifiable Credentials.=
 All of these often bind non-identifiers to one or more identifiers.=C2=A0=
=C2=A0


Justin's stan=
ce earlier in the discussion:

My stance is that we allow the clie=
nt to ask for a small set of identifiers about the user, or even just ask t=
o =E2=80=9Cidentify the user=E2=80=9D, and leave everything else to a highe=
r level identity protocol. I do not think that having an identity and profi=
le query/response language at the core of GNAP is a good idea, and it=E2=80=
=99s certainly not in our charter.

=

On Thu, Jul 9, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:
<snip>=C2=A0
I=E2=80=
=99m sorry that you are surprised by my stance, but it hasn=E2=80=99t chang=
ed since I helped write the section of the charter that you quoted below. A=
 big reason that I chose that wording was to support this use case but not =
to go in depth with an identity protocol, which I never really wanted us to=
 do. However, it seems as soon as =E2=80=9Cidentity=E2=80=9D was brought up=
 previously, people immediately jumped into talking about a full stack of u=
ser attributes and profile information. That wasn=E2=80=99t my intent in ta=
lking about identity, and I don=E2=80=99t think it=E2=80=99s something GNAP=
 ought to do, at least not on its own.=C2=A0

I do =
think there=E2=80=99s room for us to provide identifiers alongside the acce=
ss token, so that=E2=80=99s there. There was stated interest in providing s=
igned assertions as well, so I made sure that was enumerated for those who =
want to do such work. And I think it makes sense for us to provide a way to=
 describe what kinds of things I want to get from an access token by defini=
ng a general purpose syntax for describing those things (notably, as a comb=
ination of reference strings and multi-dimensional objects). With these two=
, we can get most of what we need for a basic login system. Anything beyond=
 that is going to need user profiles, authentication contexts, session cont=
rol, and a lot of other identity-protocol stuff that GNAP shouldn=E2=80=99t=
 be focusing on. We should keep it in mind as we build GNAP, but I think th=
at like OIDC all that important extra stuff should be built separately. To =
me, that=E2=80=99s what not defining schemas and formats means.=C2=A0
=


I don=E2=80=99t see any conflict with the charter here,=
 and I=E2=80=99m surprised that you do.

3D""=E1=90=A7


--000000000000a946e005aa1a95d6--


From nobody Fri Jul 10 11:43: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 CD7983A083E for ; Fri, 10 Jul 2020 11:43:20 -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 CKvDtvfsqvlQ for ; Fri, 10 Jul 2020 11:43:19 -0700 (PDT)
Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0: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 4073C3A083D for ; Fri, 10 Jul 2020 11:43:19 -0700 (PDT)
Received: by mail-oi1-x233.google.com with SMTP id l63so5564364oih.13 for ; Fri, 10 Jul 2020 11:43:19 -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=Pr1cU2IA6e7DAPC1kNpaVa1Av5f1NTlLE0htLQ7Hnx0=; b=BuOIjx6alNq9yX6HOWpdhGe9k+lbu/29BVdtaTt50BNbt+jHjI6Xy+XzPTFQn6jowS w1aj9xU3RRyWhwkXsKN4btaSy9dm3dPv3jLurzapn1RMBOH4hngiZ2H9vtd1/eFH3UAU 1X3cTsue5jVaR7Vm8syLWkOGhjLi2PGrOD2b/nvjU7GDOYfSWsah4xPo1cvauWawWBoU YGN8k1OK91KFGPN/ngm1W7Qwcbsj4PLyEQqd83If0kcq7MCFi5WAbaabm/y+UpdYr5CQ E3B6BQwdsB7aFjftlZeNvas/6kdBj5KB+N/0B2tNDE0RQQ2DIbQAQeIJW6JjK18GIrwm La4w==
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=Pr1cU2IA6e7DAPC1kNpaVa1Av5f1NTlLE0htLQ7Hnx0=; b=Ob5qlPW3xByeb3AWFh9Mwx8p9gGFcBodh2VftcALLNiUU0dFzZHZbia6xdMeeUdgxj 6GHRTieMR1ggKlBqi0JPcm9fj9utXBUbZ2Ax5IiOx43xsphW20NF7mPT9H/HEPUSrhos YjwrkABAM3IqeB+V75bgpbk4fx+sPM07Y5wU20p70EeGG7Xv4XWraVRgxvEftIkXq+WT I1HlnN/oXYIFaHRVmIdR2/aiN7LyqEMt9F8OgiLYB/vTaGMUwYKue9N0/eecbjHnXhL7 KcQM0kuw9Bu25cCchpN+lHYaJQeXYhmGkPw5ExawZKYAd+b22kSJS1PDTfbZIYQKhBVA SCGA==
X-Gm-Message-State: AOAM530LWCTxFIl57uWhJqbWe2+lujy58ldpxMwuGmzxcwoBC36TuzBH L3bTHHuUhg3c2DvcCX8F2AtgzOiuvVQrl2u3swVFXw==
X-Google-Smtp-Source: ABdhPJyuWg4EtbGvWhc9XiRP9jm35ZwKQRi8VttDfyTAn84eLIuzvpXgC5nqDXK6rpVn0+ZwzMFUUCArUqrgr2rMIZs=
X-Received: by 2002:aca:aa57:: with SMTP id t84mr5349639oie.131.1594406597940;  Fri, 10 Jul 2020 11:43:17 -0700 (PDT)
MIME-Version: 1.0
From: Tom Jones 
Date: Fri, 10 Jul 2020 11:43:06 -0700
Message-ID: 
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e5db6a05aa1ab65b"
Archived-At: 
Subject: [Txauth] 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, 10 Jul 2020 18:43:21 -0000

--000000000000e5db6a05aa1ab65b
Content-Type: text/plain; charset="UTF-8"

Dick said:
>From a privacy perspective in non-enterprise use cases, I think the user
should give consent to any updated personal information to a client. In
general, the client should not be able to get the latest information about
a user whenever it wants.

My statement about user consent from kantara perspective:
The above statement is not machine proccessible. This can only be fixed if
the as or rs knows what the user consented to. One element of consent needs
to be the expiration time. Could this group create the minimum viable
consent?
U
thx ..Tom (mobile)

--000000000000e5db6a05aa1ab65b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dick said:
From a privacy perspective in non-enterprise use=
 cases, I think the user should give consent to any updated personal inform=
ation to a client. In general, the=C2=A0client should not be able to get th=
e latest information about a user whenever it wants.

My statement about user consent from kantara perspective:<=
/font>
The above statement is not machine proccessible. This can onl=
y be fixed if the as or rs knows what the user consented to. One element of=
 consent needs to be the expiration time. Could this group create the minim=
um viable consent?
U
thx ..Tom (mobile)


--000000000000e5db6a05aa1ab65b--


From nobody Fri Jul 10 11:48: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 282BC3A0849 for ; Fri, 10 Jul 2020 11:48: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 yoau5GYUOEKH for ; Fri, 10 Jul 2020 11:48:53 -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 B3EF03A0843 for ; Fri, 10 Jul 2020 11:48:52 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id t9so3768516lfl.5 for ; Fri, 10 Jul 2020 11:48: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=UU+miLzuj7EBBW/+eMzyJdNbwJG4pbGXopvamwMtIY4=; b=AEEqeTxHq6Da8h5S6MXjNLw3jaZHYJRoR/6sKCVtlHUo+Xw3TPpo+giySvbEvgZkgr M2t8gHC+VN2C9Oc6XYVExtwc2KuK14BdS7ETYvOOcWG+zk6FYQ0qzKNntrtHCe692Cm5 qrwJUC7Bb1EqLRRrlS+vv+zpQ1y2lSClUpwI/jkawsGAOxWXPH3vlUyXEcQWkWaJzx7N sCPlYontBjc1NrPZgr8oIbEpntj5EsTrecwoyRraxE9LZii+VWCf/ft1Zl66n13ILcKy mhrjWrmyYFiGgA0Gp5GY+jWTHyMRETtA8sZEBCUNcZFh4EFT5sZn7Rd4rSOWcgXLAV1u 3XXQ==
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=UU+miLzuj7EBBW/+eMzyJdNbwJG4pbGXopvamwMtIY4=; b=pGpV5bxs9DMJepYHQ8oDZ/tULQXdcnXuJgEF9Dzc73yxFqbACZMNCTTKHU3AryUPF0 bMHSZoiBwUMaPWLptQRKuVDlhgB/uCkIT3uHj36jSrk2+IJARKYlaqAHZYibqfU2q4wW 9PDgDEGY8V87fQ4I8TvLsErh4IbGKs8QjiM2313jAMO3JJf4U4isQ5vDzu3syiErrzmz HEUVx08fGaSONXGAqre4I/4ofbHhsUf2GB4IkTByMk4CL7YlHL827ZQ71aBW6INjxg6z pn28K7NSLOKmnzAeOQ3Bkoa1eP28r98U+4UaynC4V8PsNUNvvFyPAZQIz64rPpQqW9vS vYag==
X-Gm-Message-State: AOAM530Uo1Tux+Vo8eRi0Bz5G4RePqsE2sFWj0VV97tZ+kzCP7y2RanO ki3EE5a8lE6T19z7loebJcnxS1qlN10wP+e2Az0=
X-Google-Smtp-Source: ABdhPJwUvbg7XJgWUupX4Q1P4UvmOp4TxNVLW7N+t+YCM1FRCtZxejIZx5T4iTSRBpFhFIs60fn/oTQOZuqYBZFwQKk=
X-Received: by 2002:a19:4a94:: with SMTP id x142mr45271965lfa.207.1594406930606;  Fri, 10 Jul 2020 11:48:50 -0700 (PDT)
MIME-Version: 1.0
References:    <325bc015-1547-c56c-c1fe-67a97165785d@free.fr>
In-Reply-To: <325bc015-1547-c56c-c1fe-67a97165785d@free.fr>
From: Dick Hardt 
Date: Fri, 10 Jul 2020 11:48:14 -0700
Message-ID: 
To: Denis 
Cc: "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000b9f0a005aa1acaf5"
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 10 Jul 2020 18:48:56 -0000

--000000000000b9f0a005aa1acaf5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>From https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1

1.1 =
.
Parties

   The parties and their relationships to each other:


       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+


The lines without arrows represent relationships.
The User trusts the Client
The User trusts the GS
The RO trusts the GS to issue access tokens for the RS
The RS trusts the tokens issued by the RS
The RO controls the RS

The Client makes calls to the GS (1)
The Client makes calls to the RS (2)

This looks pretty similar to your protocol drawing.

What looks to be missing from your proposal is:

A) The Client making a call to the RS to discover what it needs from a GS,
and which GS to ask, prior to (1).
B) A mechanism for the Client to prove to the GS that it has gathered
consent from the User.

The current protocol does not require the GS to interact with either the
User, the RO, or the RS -- which looks to me to meet your privacy goals.

=E1=90=A7

On Fri, Jul 10, 2020 at 6:06 AM Denis  wrote:

> Hi Dick,
>
> Hi Denis, thanks for sharing the model. I don't fully understand what is
> going on, questions inserted:
>
> Responses are inserted.
>
>
> FWIW: having paragraphs start with the step number (1), (2) etc. would
> make it easier to map between the description and the diagram.
>
> On Thu, Jul 9, 2020 at 3:26 AM Denis  wrote:
>
>> This is a new thread.
>>
>> Preamble: This model is quite different from the XAuth model.
>> In particular, a RO has no relationship with any AS and a Client does no=
t
>> need to be associated with any AS prior to any access to a RS.
>>
>> A key point of this model is that the user's consent is handled locally
>> by the Client and hence no AS nor RS is handling a man machine interface
>> for the user consent. This allows to support locally the user consent fo=
r
>> multiple ASs while keeping all ASs ignorant about the choices of the use=
r
>> made for accessing a particular RS.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *       +--------+                           +------------+        |
>> User  |                           |  Resource  |        |
>> |                           | Owner (RO) |        +--------+
>>                   +------------+            |
>> \                              |            |
>> \                             |            |
>> \                            |            |
>> \                           |     +-----------+     +---------------+
>> +------------+     |           |---->| Authorization |     |            =
|
>>     |           | (2) |  Server (AS)  |     |            |     |
>> |<----|               |     |            |     |  Client   |
>> +---------------+     |            |     |
>> |-------------------------->|  Resource  |     |   User    |
>> (1)             |   Server   |     |  Consent
>> |<--------------------------|    (RS)    |     |  element
>> |                           |            |     |
>> |-------------------------->|            |------>     |
>> |           (3)             |            |  (4)     |
>> |<--------------------------|            |<------
>> +-----------+                           +------------+ *
>> The flow of operations is as follows:
>>
>> The Client (which may have been previously authenticated using FIDO)
>>
> Which party has the client authenticated to? The client authenticating
> with FIDO is confusing to me. FIDO is usually how a user authenticates.
>
> If the user has previously opened a user account with the RS using FIDO,
> then the client may be authenticated by the RS using FIDO.
> In such a case, the user is already known to the RS under a pseudonym
> specific to the RS. It may (or may not) have previously presented access
> tokens
> to that RS.
>
>  contacts the RS and after some dialogue with the RS selects an operation
> How does the client know which RS to contact?
>
> For a private usage, the user may use DuckDuckGo, while for business he
> may use an application from his company which lists various services
> available in the context of his job or his position. Some services may be
> freely available to all the employees of the company with any
> authentication,
> e.g. the phone book of the employees may be freely available on the
> intranet of the company, while some other services may require the user
> to authenticate to the AS from the company.
>
>  that it wants to perform on the RS (1a). Note that it may also indicate
> directly the operation that it wants to perform on the RS without any pri=
or
> dialogue.
>
>> In return (1b), the RS informs the Client about which attributes are
>> needed by the RS for performing the requested operation and from which
>> Attributes Servers
>> they may be obtained.
>>
> (1a) and (1b) are not labeled. There is only (1)
>
> (1a) is the first exchange for (1) with the arrow from left to right,
> while (1b) is the response with the arrow from right to left.
> The same applies to the other exchanges i.e. (2) , (3) and (4).
>
>
>> This information is specifically marked to indicate that it shall be
>> handled by the "User Consent element" from the Client.
>>
> Why? What is the significance of this? Which information is marked?
>
> In the response, a specific identifier or a magic number is used to
> indicate the start and the length of the information block
> to be sent to the "User Consent element" supported by the Client.
>
> The presentation of that information is up to the man machine interface
> supported by the "User Consent element" from the Client.
>
> Which information?
>
> The attributes that are needed by the RS for performing a requested
> operation and from which Attributes Servers they may be obtained.
>
>
>> The user can see which attributes are requested by the RS for performing
>> the requested operation and, if it consents, the Client contacts one or
>> more
>> appropriate Authorization Servers (2a).
>>
> How does the client know which AS(s) to contact?
>
> For each AS trusted by the RS to perfom a given operation, the RS should
> indicate a user-friendly name and a URL of the AS.
>
> The user consent is hence captured locally by the Client (i.e. there is n=
o
>> dialogue with any AS nor any RS).
>>
>
> No dialogue with who? The client is calling the AS is it not?
>
> For the user consent, there is no external call since it is handled
> locally. Afterwards, there is a call to the AS(s) selected by the user.
>
>
>> When the Client got the access tokens from these authorization servers
>> (2b), it sends all of them in a single request to the RS (3a).
>>
>
> So the RS must trust the AS that issued the tokens. And the AS must trust
> the Client to have gathered consent.
>
> Theses two assertions are correct.
>
> And the AS must have a relationship with the user.
>
> Only when the user chooses one AS while giving its consent, then the user
> must have a relationship with the selected AS.
>
> It is unclear what role the RO is playing in this though. The RO and RS
> look to be the same entity from all the other parties.
>
> A RO, as indicated on the figure, has only a relationship with one RS: it
> has no relationship with any AS.
> The RS trusts the AS but the AS does not know which RSs are trusting it.
>
>
> From my current understanding, at a high level, this looks like it is
> supported by GNAP with the addition of the discovery step (1).
>
> Well, it is fairly different :
>
> 1) The first major difference is that there is no arrow between the RO an=
d
> the AS. No protocol or "out-of-bands" means are necessary.
>
> 2) The second major difference is that there is no arrow between the AS
> and the RS. No protocol is necessary.
>
> 3) The third major difference is that the AS does not know any RS. Note:
> for backward compatibility reasons, an exception might exist for "old" Au=
th
> 2.0 ASs.
>
> 4) The fourth major difference is that the XAuth spec. is rather vague to
> describe when and by who the user consent is captured:
>     XAuth states on page 4: "User consent is *often *required at the GS".
> In that case, the GS is able to act as Big Brother. No other case is
> described.
> 5) The fifth major difference is that the data that is transferred to a
> "User Consent Element" to capture the user consent. That data can be
> standardized.
>     Moreover, it will also be possible to standardize the dialogue betwee=
n
> the RO and the RS. The RO will then be able to manage remotely the
> authorization tables.
>     See my email sent on June 6, with the following subject: "Support of
> FIDO and data minimization by RSs".
>
> 6) Another difference is the following: since there is no interaction
> between the RO and the AS, "authorizations from the RO" as described in
> XAuth do not exist.
>
> There have been a number of proposals for doing this discovery, and
> perhaps now there are enough use cases to look at standardizing something=
.
> No interaction is needed between the AS and the User as the Client is
> providing enough "information" in the user object of the Grant Request
> to satisfy the AS releasing the access tokens.
>
> Not sure I understand correctly this last sentence.
>
>
> Perhaps as I understand the model in more detail I will understand what i=
s
> missing from GNAP (besides the discovery step).
>
> It would be hard to say "what is missing" from XAuth since the foundation=
s
> are not the same.
>
> In order to compare different architectures, there is the need to start
> with the trust relationships.
> Unfortunately, the word "trust" is absent in the main body of
> draft-hardt-xauth-protocol-12. Hence,
> the description of the trust relationships is missing.
>
> Denis
>
>
> /Dick
>
> (I've skipped reviewing the delegation use case below until I understand
> the simple use case)
>
>
>> End of the story for a simple access
>>
>>
>> Start of a subsequent story for a delegation case
>>
>> Let us now suppose that the RS is unable to fulfil the request by its ow=
n
>> and that it needs to contact another RS. RS1 contacts RS2 (4a) and
>> indicates the operation
>> that it wants to perform on RS2 (that operation may not be the same as
>> the original operation). In return (4b), RS2 informs RS1 about which
>> attributes are needed
>> by RS2 for performing the requested operation and from which Attributes
>> Servers they may be obtained. RS1 forwards that information to the Clien=
t.
>>
>> This information is marked to indicate that it shall be handled by the
>> "User Consent element" from the Client. The presentation of that
>> information is up to the man machine
>> interface from the Client. The user can see which attributes are
>> requested by RS2 for performing the new requested operation and, if it
>> consents, the Client contacts one or more
>> appropriate Authorization Servers. The user consent is hence captured
>> locally by the "User Consent element" from the Client. (i.e. there is no
>> dialogue with any AS, nor RS1, nor RS2).
>>
>> When the Client got the access token(s) from the authorization server(s)=
,
>> it sends all of them in a single request to RS1. RS1 then forwards the
>> additional access token(s) to RS2.
>>
>>
>> Some observations:
>>
>> The user nor the Client are linked with any particular AS. A user may us=
e
>> today an AS of the Bank of America and may change tomorrow to the Bank o=
f
>> Missouri.
>> As soon as he will be registered with the Bank of Missouri, he will be
>> able to get access tokens from the AS of the Bank of Missouri. The AS of
>> Bank of America
>> has not been able to know where its access tokens have been used. This
>> will be the same for AS of the Bank of Missouri. There is no need for an=
y
>> direct dialogue
>> between any AS and any RS at the time a client is making an access. Ther=
e
>> is no need for any RO to contact any AS.
>>
>> This model has been constructed following a "Privacy by Design" approach=
.
>> Denis
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> =E1=90=A7
>
>
>

--000000000000b9f0a005aa1acaf5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


From=C2=A0https://tools.ietf.org/html/draft-hardt-x=
auth-protocol-10#section-1.1

1.1.  Parties


   The parties and their relationships to each other:


       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+



The lines without arrows represent rel=
ationships.=C2=A0
The User trusts the Client
The User trusts the GS
The RO trusts the GS to issue access tok=
ens for the RS
The RS trusts the tokens issued by the RS
The RO controls the RS

The Client makes calls to=
 the GS (1)
The Client makes calls to the RS (2)

This looks pretty similar to your protocol drawing.

=

What looks to be missing from your proposal is:

A) The Client making a call to the RS to discover what it needs fr=
om a GS, and which GS to ask, prior to (1).
B) A mechanism for th=
e Client to prove to the GS that it has gathered consent from the User.

The current protocol does not require the GS to inter=
act with either the User, the RO, or the RS -- which looks to me to meet yo=
ur privacy=C2=A0goals.

3D""=E1=90=A7<=
/div>
O=
n Fri, Jul 10, 2020 at 6:06 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hi Dick,

    


    

    

     =20
      

        
Hi Denis, thanks for sharing the model. I don'=
t
          fully understand what is going on, questions inserted:

      

    

    Responses are inserted.

    

      

        

          


          

          
FWIW: having paragraphs start with the step number (1),
            (2) etc. would make it easier to map between the description
            and the diagram.

        

        

        

          
On Thu, Jul 9, 2020 at 3:26
            AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              

                
This is a new thread.

                    

                    Preamble: This model is quite different from the
                    XAuth model. 

                    In particular, a RO has no relationship with any AS
                    and a Client does not need to be associated with any
                    AS prior to any access to a RS.

                    

                    A key point of this model is that the user's consen=
t
                    is handled locally by the Client and hence no AS nor
                    RS is handling a man machine interface 

                    for the user consent. This allows to support locally
                    the user consent for multiple ASs while keeping all
                    ASs ignorant about the choices of the user 

                    made for accessing a particular 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=C2=A0
                        +------------+

                        =C2=A0=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0 |

                        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                        | Owner (RO) |

                        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +=
--------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+------------+

                        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
                        |

                        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
                        |

                        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
                        |

                        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
                        |

                        =C2=A0=C2=A0=C2=A0 +-----------+=
=C2=A0 =C2=A0=C2=A0=C2=A0+---------------+=C2=A0=
=C2=A0=C2=A0=C2=A0
                        +------------+

                        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---->|
                        Authorization |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                        |

                        =C2=A0=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) |=C2=A0 Server (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=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0 |

                        =C2=A0=C2=A0=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=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=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 (1)=C2=A0=C2=A0=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=C2=A0 |=C2=A0 Consent=C2=A0
                        |<--------------------------|=C2=A0=
=C2=A0=C2=A0
                        (RS)=C2=A0=C2=A0=C2=A0 |

                        =C2=A0=C2=A0=C2=A0 |=C2=A0 element=C2=A0
                        |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                        |

                        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |------------------=
-------->|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
                        |------>

                        =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=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 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<--------------=
------------|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
                        |<------

                        =C2=A0=C2=A0=C2=A0 +-----------+=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=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 flow of operations is as follows:

                    

                    The Client (which may have been previously
                    authenticated using FIDO) 

              

            

          

          
Which party has the client authenticated to? The client
            authenticating with FIDO is confusing to me. FIDO is usually
            how a user authenticates.

        

      

    

    
If the user has previously opened a user account with the RS
      using FIDO, then the client may be authenticated by the RS using
      FIDO.

      In such a case, the user is already known to the RS under a
      pseudonym specific to the RS. It may (or may not) have previously
      presented access tokens 

      to that RS.

    

    

      

        

          
=C2=A0contacts the RS and after some
              dialogue with the RS selects an operation 

            

          
How does the client know which RS to contact?

        

      

    

    
For a private usage, the user may use DuckDuckGo, while for
      business he may use an application from his company which lists
      various services 

      available in the context of his job or his position. Some services
      may be freely available to all the employees of the company with
      any authentication,

      e.g. the phone book of the employees may be freely available on
      the intranet of the company, while some other services may require
      the user 

      to authenticate to the AS from the company.

    

      

        

          
=C2=A0that it wants to perform on the R=
S
              (1a). Note that it may also indicate directly the
              operation that it wants to perform on the RS without any
              prior dialogue. 

            

          

            

              

                
 In return (1b), the RS informs
                    the Client about which attributes are needed by the
                    RS for performing the requested operation and from
                    which Attributes Servers 

                    they may be obtained. 

                  

              

            

          

          
(1a) and (1b) are not labeled. There is only (1) 

          

        

      

    

    
(1a) is the first exchange for (1) with the arrow from left to
      right, while (1b) is the response with the arrow from right to
      left. 

      The same applies to the other exchanges i.e. (2) , (3) and (4).

    

    

      

        

          

            

              

                
 

                    This information is specifically marked to indicate
                    that it shall be handled by the "User Consent
                    element" from the Client. 

                  

              

            

          

          
Why? What is the significance of this? Which information
            is marked?

        

      

    

    
In the response, a specific identifier or a magic number is used
      to indicate the start and the length of the information block=C2=A0 <=
br>
      to be sent to the "User Consent element&quo=
t;
        supported by the Client.

    

    

      

        

          

            
The presentation of that information
                is up to the man machine interface supported by the
                "User Consent element" from the Client. 

              

          

          


          

          
Which information? 

          

        

      

    

    
The attributes that are needed by the RS for
        performing a requested operation and from which Attributes
        Servers they may be obtained.

    

      

        

          

            

              

                
 

                    The user can see which attributes are requested by
                    the RS for performing the requested operation and,
                    if it consents, the Client contacts one or more 

                    appropriate Authorization Servers (2a). 

              

            

          

          
How does the client know which AS(s) to contact?

        

      

    

    
For each AS trusted by the RS to perfom a given operation, the RS
      should indicate a user-friendly name and a URL of the AS. 

    

    

      

        

          

            

              

                
The user consent is hence captured
                    locally by the Client (i.e. there is no dialogue
                    with any AS nor any RS).

                  

              

            

          

          


          

          
No dialogue with who? The client is calling the AS is it
            not? 

          

        

      

    

    
For the user consent, there is no external call since it is
      handled locally. Afterwards, there is a call to the AS(s) selected
      by the user.

    

      

        

          

            

              

                
 

                    When the Client got the access tokens from these
                    authorization servers (2b), it sends all of them in
                    a single request to the RS (3a).

                  

              

            

          

          


          

          
So the RS must trust the AS that issued the tokens. And
            the AS must trust the Client to have gathered consent.

        

      

    

    Theses two assertions are correct.

    

      

        

          
 And the AS must have a relationship with the user. 

        

      

    

    
Only when the user chooses one AS while giving its consent, then
      the user must have a relationship with the selected AS.

    

      

        

          
It is unclear what role the RO is playing in this though.
            The RO and RS look to be the same entity from all the other
            parties.

        

      

    

    
A RO, as indicated on the figure, has only a relationship with
      one RS: it has no relationship with any AS. 

      The RS trusts the AS but the AS does not know which RSs are
      trusting it.

    

      

        

          


          

          
From my current understanding, at a high level, this
            looks like it is supported by GNAP with the addition of the
            discovery step (1). 

        

      

    

    
Well, it is fairly different : 

    

    

      
1) The first major difference is that there is no arrow between
        the RO and the AS. No protocol or "out-of-bands" means ar=
e
        necessary. 

      

      
2) The second major difference is that there is no arrow
        between the AS and the RS. No protocol is necessary. 

      
3) The third major difference is that the AS does not know any
        RS. Note: for backward compatibility reasons, an exception might
        exist for "old" Auth 2.0 ASs.

      

      
4) The fourth major difference is that the XAuth spec. is
        rather vague to describe when and by who the user consent is
        captured: 

        =C2=A0=C2=A0=C2=A0 XAuth states on page 4: "User consent is often required
        at the GS". In that case, the GS is able to act as Big Brother=
.
        No other case is described.

      

      5) The fifth major difference is that the data that is transferred
      to a "User Consent Element" to capture the user consent. Th=
at data
      can be standardized. 

      =C2=A0=C2=A0=C2=A0 Moreover, it will also be possible to standardize =
the dialogue
      between the RO and the RS. The RO will then be able to manage
      remotely the authorization tables.

      =C2=A0=C2=A0=C2=A0 See my email sent on June 6, with the following su=
bject:
      "Support of FIDO and data minimization by RSs".

      

      6) Another difference is the following: since there is no
      interaction between the RO and the AS, "authorizations from the
      RO" as described in XAuth do not exist.
       =C2=A0 

    

      

        

          
There have been a number of proposals for doing this
            discovery, and perhaps now there are enough use cases to
            look at standardizing something.=C2=A0 

            No interaction=C2=A0is needed between the AS and the User as th=
e
            Client is providing enough "information" in the user =
object
            of the Grant Request 

            to satisfy the AS releasing the access tokens. 

          

        

      

    

    Not sure I understand correctly this last sentence.

    

      

        

          


          

          
Perhaps as I understand the model in more detail I will
            understand what is missing from GNAP (besides the discovery
            step).

        

      

    

    
It would be hard to say "what is missing" from XAuth since=
 the
      foundations are not the same.

    
In order to compare different architectures, there is the need to
      start with the trust relationships. 

      Unfortunately, the word "trust" is absent in the main body =
of
      draft-hardt-xauth-protocol-12. Hence, 

      the description of the trust relationships is missing.

    

    
Denis

    

      

        

          


          

          
/Dick

          


          

          
(I've skipped reviewing the delegation use case below
            until I understand the simple use case)

          


          

          

            

              

                
 

                    End of the story for a simple access

                
 

                    Start of a subsequent story for a delegation case

                    

                    Let us now suppose that the RS is unable to fulfil
                    the request by its own and that it needs to contact
                    another RS. RS1 contacts RS2 (4a) and
                    indicates the operation 

                    that it wants to perform on RS2 (that operation may
                    not be the same as the original operation). In
                    return (4b), RS2 informs RS1 about which attributes
                    are needed 

                    by RS2 for performing the requested operation and
                    from which Attributes Servers they may be obtained.
                    RS1 forwards that information to the Client. 

                    

                    This information is marked to indicate that it shall
                    be handled by the "User Consent element" from=
 the
                    Client. The presentation of that information is up
                    to the man machine 

                    interface from the Client. The user can see which
                    attributes are requested by RS2 for performing the
                    new requested operation and, if it consents, the
                    Client contacts one or more 

                    appropriate Authorization Servers. The user consent
                    is hence captured locally by the "User Consent
                    element" from the Client. (i.e. there is no dialog=
ue
                    with any AS, nor RS1, nor RS2). 

                    

                    When the Client got the access token(s) from the
                    authorization server(s), it sends all of them in a
                    single request to RS1. RS1 then forwards the
                    additional access token(s) to RS2.

                    

                    

                    Some observations: 

                    

                    The user nor the Client are linked with any
                    particular AS. A user may use today an AS of the
                    Bank of America and may change tomorrow to the Bank
                    of Missouri. 

                    As soon as he will be registered with the Bank of
                    Missouri, he will be able to get access tokens from
                    the AS of the Bank of Missouri. The AS of Bank of
                    America 

                    has not been able to know where its access tokens
                    have been used. This will be the same for AS of the
                    Bank of Missouri. There is no need for any direct
                    dialogue 

                    between any AS and any RS at the time a client is
                    making an access. There is no need for any RO to
                    contact any AS.

                
This model has been constructed
                    following a "Privacy by Design" approach.

                Denis

              

            

            -- 

            Txauth mailing list

            Txauth@iet=
f.org

            https://www.ietf.org/mailman/listinfo/txauth=


          

        

      

      
3D""==E1=90=A7

    

    


    

  





--000000000000b9f0a005aa1acaf5--


From nobody Fri Jul 10 11:52: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 8AD723A08B6 for ; Fri, 10 Jul 2020 11:52:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.468
X-Spam-Level: 
X-Spam-Status: No, score=-0.468 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_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 eQ8V3tvr5q5n for ; Fri, 10 Jul 2020 11:52:19 -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 CCB2F3A0884 for ; Fri, 10 Jul 2020 11:52:18 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id y18so3764521lfh.11 for ; Fri, 10 Jul 2020 11:52: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=jcuFtTbIMfkdG7hJGN1he+sk6aWctuEpRg0P5Pu2FLc=; b=IfNNo5+1Q2hLj8fvi8qfOrYQqxDPk6B5x/rxdil6XBil6O7OShZ1z7OtZ7Cw78sgPh a2sL0gxb5vaqi9/a/ErMdM/TX51z4lsugnMjECQHtFlyCJUhKQ5SqzpJOB2WywmrhQrs 4oyC14yavSRk/Iu18iacEo6CZCRJ+cLp3qfwL9l0aVHb7YI2eBUoWFtyQpSYIekq9d0n AAGPmwWZMrE9ieq+3Q5BB5/JjeRBpwrkNBtdlnjqrq0o1KqQgcc+uGUUK1EMw5PcFd1H jzYMzf0u4EoT9l6N4ycwLJR9QNfMevq+zSVOvGeI1frhAsibaVYBwwwoa7tTT40kDcm2 sfcA==
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=jcuFtTbIMfkdG7hJGN1he+sk6aWctuEpRg0P5Pu2FLc=; b=WJY5zR2XSOwEsbQRCbB+e0E8e/aaN/N8WdKaC+vCzOdsOjg2/VG1AP0vbZ15NMRbYJ sTgR+TQTdOZusfJwo17MhQZDG4NPjqQjlPmTbDYFim6Rw/DLQ7xutrMDW1G+kZkv1fJ5 DlKtBAeQCWasLmMguMVq3Bghja4i7EmpIIVjKuso9SFy9ZT+4sLkW4tVX+8vquJBeKT/ oaKesdPapZqBk0MfvMWHFIQeSMfzbaKkPNVqRkKhae9Awd9pZILAS1+2jIy+y/MhQaFZ R7kxSY0mIY0x/7YTrB3v8OKKbP/twrmfxmHW9uRtsgZwcEauRzb3bTGGQOg1qglW3deQ eOLQ==
X-Gm-Message-State: AOAM530JjlI0WGNLas6h7EjjJ2Vh/vW0XEV0GuORXjYPm3rlQy1C0I7m cKSsMmlC56fqsSLR6zNF7/07iGmBf/T5hmJGYQVAmQH3
X-Google-Smtp-Source: ABdhPJzZbYEQqOsT0WLWJQi/bRyylGpN8L2THzsE8xjFJzvvuLyz0EFN4scZU8FTN46dK9EcyLuIkCLNvEb9fhR7uI0=
X-Received: by 2002:a19:4143:: with SMTP id o64mr43903871lfa.157.1594407136935;  Fri, 10 Jul 2020 11:52:16 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 10 Jul 2020 11:51:40 -0700
Message-ID: 
To: Tom Jones 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000006434605aa1ad72c"
Archived-At: 
Subject: Re: [Txauth] 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, 10 Jul 2020 18:52:26 -0000

--00000000000006434605aa1ad72c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Tom

As you know, consent is currently gathered by a user experience between the
user and the party needing consent.

I think a machine readable consent artifact is interesting, but it does not
appear to be in the groups charter at this time. Do you know of any other
bodies working no this?

=E1=90=A7

On Fri, Jul 10, 2020 at 11:43 AM Tom Jones 
wrote:

> Dick said:
> From a privacy perspective in non-enterprise use cases, I think the user
> should give consent to any updated personal information to a client. In
> general, the client should not be able to get the latest information abou=
t
> a user whenever it wants.
>
> My statement about user consent from kantara perspective:
> The above statement is not machine proccessible. This can only be fixed i=
f
> the as or rs knows what the user consented to. One element of consent nee=
ds
> to be the expiration time. Could this group create the minimum viable
> consent?
> U
> thx ..Tom (mobile)
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--00000000000006434605aa1ad72c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey Tom

As you know, consent is current=
ly gathered by a user experience between the user and the party needing con=
sent.

I think a machine readable consent artifact =
is interesting, but it does not appear to be in the groups charter at this =
time. Do you know of any other bodies working no this?

=

3D""==E1=90=A7

On Fri, Jul 10, 2020 at 11:43 AM Tom Jones &=
lt;thomasclinganjones@gmail=
.com> wrote:
Dick said:
From a privacy perspective in non-enterprise=
 use cases, I think the user should give consent to any updated personal in=
formation to a client. In general, the=C2=A0client should not be able to ge=
t the latest information about a user whenever it wants.

My statement about user consent from kantara perspective:
The above statement is not machine proccessible. This can o=
nly be fixed if the as or rs knows what the user consented to. One element =
of consent needs to be the expiration time. Could this group create the min=
imum viable consent?
U
thx ..Tom (mob=
ile)

-- 

Txauth mailing list

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




--00000000000006434605aa1ad72c--


From nobody Fri Jul 10 12:47: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 149833A08E7 for ; Fri, 10 Jul 2020 12:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.682
X-Spam-Level: 
X-Spam-Status: No, score=-0.682 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_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 giJl5_Pk2sBn for ; Fri, 10 Jul 2020 12:47:36 -0700 (PDT)
Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 910BC3A08E5 for ; Fri, 10 Jul 2020 12:47:36 -0700 (PDT)
Received: by mail-oo1-xc2c.google.com with SMTP id o36so1205939ooi.11 for ; Fri, 10 Jul 2020 12:47: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=Il6oIcMNqvgmuMZkWdzfnPrXpCF38ov+0J2VDluPlpQ=; b=S055zfncYTyOjd5rpygiKH5b1iZbmrjTNriNqspC6W44VYLpTvtE4hMT4TStzSvXv4 NKTEEmKeSB4/mmJic5Om6YtpuexQZvVPELb48my73KIBxnkKgsAe2vAELbMyD3ikQLjN S0/jAIHchqJMEjleo+NKTcGqSjd0xGYfnB3nq9UKHdO5P7VHe/Qzce7EjS8dh0W2csCL lLACqpvo3yyIcSD12teOfgu5VUe4FJyob0ikTuD39Sjgm0II96OzP31k+dkzrOwfTOPR 6VuMdoWIQDTRHCMrN7xUQosb4W4oTQ9wPD4aurfVUsqy74zza6lJwCbWqcPYvT5dRkE/ iCFg==
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=Il6oIcMNqvgmuMZkWdzfnPrXpCF38ov+0J2VDluPlpQ=; b=qVbsbBTr/euuIlYXb89jIhf6dIOEJ+GHvxSXPpiRX/FJdjqWGombmSLPR3gDlATKq3 ZEYt9COT48F6ZUG8wlmDL0UWnWV6Er4VOrUbyuVhue/cBpfC4XNIVHe3RkJCQZ6JAB7o 9riuQLXgMha8/9292IE5CWVb/6KJzyTpKh/x6zjpuz7cDyuWTO0MHJv8AefuoubRKd9x r7DZHR/bMo5YBs115eLK042mTiY+o3UURneNe0PGz57C0czz1xB6fCysI+BMOcD7BzX0 b1ooGMwKtGDW5lGwlE4Z06nQUF31uCZd2N0PJ+5Hp92xduiVPu1oeeWFMbZudHNCOKbX DXsQ==
X-Gm-Message-State: AOAM532oBLe8Ac2VQYGevQo/O+QGSwtQmqK9T/vbwZwoDIEmVBd7WWQU SdlOZoR7g0b7alCAJ7CFDH7c276J+JihlzqsyXc=
X-Google-Smtp-Source: ABdhPJyBXpHnvmQgl5q/18BqsK5h8sJldEOnE6kAeO/W6jNHTEfGw368BgB6QRxKnkqvxGi2+ZAf4jnG5F+ugPOHCd0=
X-Received: by 2002:a4a:dfb5:: with SMTP id k21mr52327608ook.27.1594410455591;  Fri, 10 Jul 2020 12:47:35 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Tom Jones 
Date: Fri, 10 Jul 2020 12:47:22 -0700
Message-ID: 
To: Dick Hardt 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d4ee5c05aa1b9ca0"
Archived-At: 
Subject: Re: [Txauth] 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, 10 Jul 2020 19:47:38 -0000

--000000000000d4ee5c05aa1b9ca0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I was afraid that was the case. Let me goad kantara into creating one.

thx ..Tom (mobile)

On Fri, Jul 10, 2020, 11:52 AM Dick Hardt  wrote:

> Hey Tom
>
> As you know, consent is currently gathered by a user experience between
> the user and the party needing consent.
>
> I think a machine readable consent artifact is interesting, but it does
> not appear to be in the groups charter at this time. Do you know of any
> other bodies working no this?
>
> =E1=90=A7
>
> On Fri, Jul 10, 2020 at 11:43 AM Tom Jones 
> wrote:
>
>> Dick said:
>> From a privacy perspective in non-enterprise use cases, I think the user
>> should give consent to any updated personal information to a client. In
>> general, the client should not be able to get the latest information abo=
ut
>> a user whenever it wants.
>>
>> My statement about user consent from kantara perspective:
>> The above statement is not machine proccessible. This can only be fixed
>> if the as or rs knows what the user consented to. One element of consent
>> needs to be the expiration time. Could this group create the minimum via=
ble
>> consent?
>> U
>> thx ..Tom (mobile)
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>

--000000000000d4ee5c05aa1b9ca0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I was afraid that was the case. Let me goad kantara into =
creating one.

thx ..Tom (mob=
ile)

On Fri, Jul 10, 2020, 11:52 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Tom

As you kn=
ow, consent is currently gathered by a user experience between the user and=
 the party needing consent.

I think a machine read=
able consent artifact is interesting, but it does not appear to be in the g=
roups charter at this time. Do you know of any other bodies working no this=
?

3D""=E1=90=A7

On Fri, Jul 10, 2020=
 at 11:43 AM Tom Jones <thomasclinganjones@gmail.com> w=
rote:
Dick said:
From a privacy perspective in non-enterprise use cases, =
I think the user should give consent to any updated personal information to=
 a client. In general, the=C2=A0client should not be able to get the latest=
 information about a user whenever it wants.
=

=
My statement about user consent from kantara perspective:
The above statement is not machine proccessible. This can only be fixed=
 if the as or rs knows what the user consented to. One element of consent n=
eeds to be the expiration time. Could this group create the minimum viable =
consent?
U
thx ..Tom (mobile)

-- 

Txauth mailing list

Txa=
uth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth<=
/a>






--000000000000d4ee5c05aa1b9ca0--


From nobody Fri Jul 10 13: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 D32343A08EC for ; Fri, 10 Jul 2020 13:03:22 -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 X1x3sbVnuQ9J for ; Fri, 10 Jul 2020 13:03:20 -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 235153A08F6 for ; Fri, 10 Jul 2020 13:03:20 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id r19so7766087ljn.12 for ; Fri, 10 Jul 2020 13:03: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=znKtju4DOEbo6l3Z4nGEd0rJ/4K5ae2obTqhwNSG54Y=; b=qr5wpWJUabYF5eKT+vHXOqgZrd5QhpSB4qKyoT4o3Y3xFKevT5eE5lz4q6jIkMGUlp VgXrPiPgSRTsbmbzSdxre1aKu1oI44cun2tiovH4uFyI74hTpZVD6WSyqcC5e8ID1xcV cWmHgK85egHCeoVfTHKp8zmv9zoMl4sOLnoi6XScHmFlnKZEJL+FWWPwdns2TTbqxTqk IBE6XntPKNUQOTrfKYr8tKerprrhrpczcJ+0mf/esiFFsJHG5btlhQDzpGV4fXFnaWzC 5QLGI0INJ8NLywrAYpfvn14u1cToQmIE6L4e2JCZaf693JQvZSeBZXrGpIgBmqTew57U Dmwg==
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=znKtju4DOEbo6l3Z4nGEd0rJ/4K5ae2obTqhwNSG54Y=; b=IjVTbsX8c5+0mllrtnj7w3zrvpOTCofqLwq4kR0bJyXiaIJ6I3H+OuraRCE/79acDE +Wk1nPtCNSXe1wL+Vw6DsfPfstOP6lEWu0wGe5is+N8TF2cXF8GNEQoc3AIYMu1jchHi GFQ9lGFuYwzjAsE1NlqlpTjcwroxKaIgPK8X2Avt21O7kJ8bVlKiBQAO+Csia57Znkbm +lgrQQLRIQL6xwS7OPupdftQdGVjmZwTjii3A7jXuHKyryRLvwArN86IPlqPyaUilJ80 hdK9cnbJ7RG4JqMrbhYDLAOmJ2+H27m0tpDqj2InnyH+ZeRIDX39wA+DZ6EmIwTCl+ve ob7Q==
X-Gm-Message-State: AOAM531UTzqiH0e+MVJtocA7EMZE1d3IYncH0A5yCQDe568DjATGLMdA 5WsuewI95i5ThNmrJZU1eIW+kvZCtOF0NNQb6ZA=
X-Google-Smtp-Source: ABdhPJxntjpaIuDFFmfIVW2dJGECiUcr9Pa531RhetIDC719avQVUTe7RA/0cgDPJEyvF7bNZMQhaUX0jCehU53OsiY=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr3822701ljg.69.1594411397859; Fri, 10 Jul 2020 13:03:17 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 10 Jul 2020 13:02:41 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org, Daniel Fett 
Content-Type: multipart/alternative; boundary="000000000000fecdd905aa1bd4b7"
Archived-At: 
Subject: Re: [Txauth] Interaction capabilities vs modes (was: XYZ-08 vs XAuth-08)
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, 10 Jul 2020 20:03:23 -0000

--000000000000fecdd905aa1bd4b7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Justin,

Bringing this discussion back up to the top of your stack.

In my implementation, the AS has a policy that 'write' access is only
available if the mode is 'redirect'. It was easy to not provide an mode
request, and it was clear to the Client that a 'redirect' mode is all that
is required.

Additionally, my implementation had different pre-fix paths for inbound
'redirect' and 'indirect' flows, so I could use the router to invoke
different functions depending on the use case. This is possible as the
'redirect' and 'indirect' responses from the AS each have their own URIs.

In your Medium article on interactions[1] you talk about the app to app
communication. Currently, the major two platforms are using https as a
means for the calling app to clearly identify the recipient app, and for
the platform to bind app identity to a URI. I don't see how GNAP is
going to change mobile platform behavior.

If your model is that the client is not invoking the AS app, but the AS is
invoking its own app, then there is no need for the client to know about
the interaction, although the client does need to confidently communicate
which user it is interacting with so that the AS knows which app install to
interact with. But the AS is all first party in this case, and the
interaction between the two does not need to be specified for interop.

As for the AS sending a push notification to a Client, that looks very
tricky to do. I don't know of any support for an app to specify which other
apps can send it a push. All push notifications I know of are 1st party.
3rd party pushes would require an agreement between parties, otherwise any
app could send a push to any other app.



[1] https://medium.com/@justinsecurity/xyz-interaction-a84091d2a8c8





On Tue, Jun 16, 2020 at 10:03 AM Dick Hardt  wrote:

> Forking this thread to a new subject ...
>
> + Daniel for the security concern on preventing a session fixation attack=
.
>
> On Mon, Jun 15, 2020 at 5:19 PM Dick Hardt  wrote:
>
>>
>> On Wed, Jun 10, 2020 at 7:54 AM Justin Richer  wrote:
>>
>>> On Jun 9, 2020, at 4:11 PM, Dick Hardt  wrote:
>>>
>>>
>>> On Tue, Jun 9, 2020 at 9:10 AM Justin Richer  wrote:
>>>
>>>>
>>>>
>>>> On Jun 8, 2020, at 5:33 PM, Dick Hardt  wrote:
>>>>
>>>> 
>
>> In XAuth, if the server wants to protect itself from a session fixation
>>>> attack in a given request, and it wants to support both "redirect" and
>>>> "user_code" modes,
>>>> the server will return only those two modes and not "indirect". The
>>>>
>>>> In XAuth, if the server wants to protect itself from a session fixatio=
n
>>>> attack in a given request, and it wants to support both "redirect" and
>>>> "user_code" modes,
>>>> the server MUST return callback, redirect, and user_code. The client
>>>> does not know that the "indirect" mode is not supported, and may try t=
hat.
>>>>
>>>>
>>>> In XYZ, if the server wants to protect against a session fixation
>>>> attack, it will reject a request that doesn=E2=80=99t have a =E2=80=9C=
callback=E2=80=9D field in
>>>> it. The AS always gets to choose which things it supports for any give=
n
>>>> request. If the client wants to support both =E2=80=9Credirect=E2=80=
=9D and =E2=80=9Cuser_code=E2=80=99
>>>> modes AND has the ability to handle session fixation issues, it sends =
the
>>>> =E2=80=9Credirect=E2=80=9D, =E2=80=9Cuser_code=E2=80=99, and =E2=80=9C=
callback=E2=80=9D fields in its interaction request.
>>>>
>>>
>>> If the client chooses to present the interaction_url as a scannable
>>> barcode, which is an option if it receives one, it will then get an err=
or
>>> when it tries to do a transaction continue request as the AS protects
>>> itself. Unfortunately the user has scanned the barcode and is now at th=
e
>>> AS. I don't see how the client learns it is not able to do what I call =
an
>>> "indirect" mode interaction. Would you explain how this situation is
>>> prevented in XYZ?
>>>
>>>
>>> If the client has made a request with =E2=80=9Credirect=E2=80=9D and =
=E2=80=9Ccallback=E2=80=9D in its
>>> request, and then decides to display the interaction URL as a scannable
>>> code, then the AS will just redirect to the client=E2=80=99s callback U=
RL when it=E2=80=99s
>>> done, whatever that URL was. If the client sends a =E2=80=9Ccallback=E2=
=80=9D URL that it
>>> can=E2=80=99t get information from, then that=E2=80=99s a poorly-writte=
n client, isn=E2=80=99t it?
>>>
>>
>> Let me provide more clarity on the scenario.
>>
>> The client is a web app that can redirect the user to the AS, and receiv=
e
>> a callback, it can display a code and URI to enter the code, or it can s=
how
>> a scannable code for the user to scan on their mobile phone. The user ma=
y
>> be using the web app on a PC, and the AS is on their phone. The user
>> chooses to scan the barcode with their phone. After authenticating with =
the
>> AS, the AS redirects back to the callback URL. But the webpage is now on
>> the user's mobile device, not the web app on the PC.
>>
>>
>>>
>>> If the client can=E2=80=99t get to the information in the callback URL =
unless
>>> it=E2=80=99s on the same device, then the client isn=E2=80=99t going to=
 show the user a
>>> scannable code to be read by a secondary device. Why would it?
>>>
>>
>> Because it is a better experience for the user per above.
>>
>> The AS parameters don't differentiate between a scannable URL and a URL
>> that can only be redirected, so the client will think it can do anything=
.
>>
>> Additionally, in XAuth, the client can provide an informational URI for
>> the AS to redirect after a scannable code or a user code flow.
>>
>>
> I'll add additional clarity on what happens when the user experience
> switches between the PC browser and the mobile browser. The client loses
> context of which user the client is interacting with. An attacker can tak=
e
> the interaction URL and trick a victim user into clicking on it (a sessio=
n
> fixation attack). The client does not know the difference between a real
> user on the mobile device, and a victim on a mobile device. Neither
> scenario has any session state from the original user interaction at the
> client.
>
> Providing a clear signal to the client that the AS won't support a
> scannable code (or any other redirection to the AS that does not have a
> redirection back to the same instance of the client).
>
> /Dick
>
>
>

--000000000000fecdd905aa1bd4b7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey Justin,

Bringi=
ng this discussion back up to the top of your stack.

In my implementation, the AS has a policy that 'write' access is=
 only available if the mode is 'redirect'. It was easy to not provi=
de an mode request, and it was clear to the Client that a 'redirect'=
; mode is all that is required.

Additionally, my i=
mplementation had different pre-fix=C2=A0paths for inbound 'redirect=
9; and 'indirect' flows, so I could use the router to invoke differ=
ent functions depending on the use case. This is possible=C2=A0as the '=
redirect' and 'indirect' responses from the AS each have their =
own URIs.

In your Medium article on interactions[1=
] you talk about the app to app communication. Currently, the major two pla=
tforms are using https as a means for the calling app to clearly identify t=
he recipient app, and for the platform to bind app identity to a URI. I don=
't see how GNAP is going=C2=A0to change mobile platform behavior.=C2=A0=


If your model is that the client is not invoking =
the AS app, but the AS is invoking its own app, then there is no need for t=
he client to know about the interaction, although the client does need to c=
onfidently communicate which user it is interacting with so that the AS kno=
ws which app install to interact with. But the AS is all first party in thi=
s case, and the interaction between the two does not need to be specified f=
or interop.

As for the AS sending a push notificat=
ion to a Client, that looks very tricky to do. I don't know of any supp=
ort for an app to specify which other apps can send it a push. All push not=
ifications I know of are 1st party. 3rd party pushes would require an agree=
ment between parties, otherwise any app could send a push to any other app.=
=C2=A0



=





On Tue, Jun 16=
, 2020 at 10:03 AM Dick Hardt <d=
ick.hardt@gmail.com> wrote:
Forking this thread to=
 a new subject ...

+ Daniel for th=
e security concern on preventing a session fixation attack.

On Mon, Jun =
15, 2020 at 5:19 PM Dick Hardt <dick.hardt@gmail.com> wrote:
On =
Wed, Jun 10, 2020 at 7:54 AM Justin Richer <jricher@mit.edu> wrote:
On Jun 9=
, 2020, at 4:11 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


On Tue, Jun 9, 2020 at 9:10 AM Justin Richer <jricher@mit.edu> wrot=
e:


On Jun 8, 2020, at 5:33 PM, Dick Hardt =
<dick.hardt@gm=
ail.com> wrote:
<snip&g=
t;=C2=A0
In XAuth, if the server wants to protect itself f=
rom a session fixation attack in a given request, and it wants to support b=
oth "redirect" and "user_code" modes,=C2=A0
t=
he server will return only those two modes and not "indirect". Th=
e=C2=A0

In XAuth, if the server wants to prot=
ect itself from a session fixation attack in a given request, and it wants =
to support both "redirect" and "user_code" modes,=C2=A0=

the server MUST return=C2=A0callback, redirect,=
 and user_code. The client does not know that the "indirect" mode=
 is not supported, and may try that.

=


In XYZ, if the server wants to protect aga=
inst a session fixation attack, it will reject a request that doesn=E2=80=
=99t have a =E2=80=9Ccallback=E2=80=9D field in it. The AS always gets to c=
hoose which things it supports for any given request. If the client wants t=
o support both =E2=80=9Credirect=E2=80=9D and =E2=80=9Cuser_code=E2=80=99 m=
odes AND has the ability to handle session fixation issues, it sends the =
=E2=80=9Credirect=E2=80=9D, =E2=80=9Cuser_code=E2=80=99, and =E2=80=9Ccallb=
ack=E2=80=9D fields in its interaction request.=C2=A0

If the client chooses to present the interacti=
on_url as a scannable barcode, which is an option if it receives=C2=A0one, =
it will then get an error when it tries to do a transaction continue reques=
t as the AS protects itself. Unfortunately the user has scanned the barcode=
 and is now at the AS. I don't see how the client learns it is not able=
 to do what I call an "indirect" mode interaction. Would you expl=
ain how this situation is prevented in XYZ?

If the client has made a request with =E2=80=9Cred=
irect=E2=80=9D and =E2=80=9Ccallback=E2=80=9D in its request, and then deci=
des to display the interaction URL as a scannable code, then the AS will ju=
st redirect to the client=E2=80=99s callback URL when it=E2=80=99s done, wh=
atever that URL was. If the client sends a =E2=80=9Ccallback=E2=80=9D URL t=
hat it can=E2=80=99t get information from, then that=E2=80=99s a poorly-wri=
tten client, isn=E2=80=99t it?

Let me provide more clarity on the scenario.

The client is a web app that can redirect the user to the AS, and receive =
a callback, it can display a code and URI to enter the code, or it can show=
 a scannable code for the user to scan on their mobile phone. The user may =
be using the web app on a PC, and the AS is on their phone. The user choose=
s to scan the barcode=C2=A0with their phone. After authenticating with the =
AS, the AS redirects back to the callback URL. But the webpage is now on th=
e user's mobile device, not the web app on the PC.
=C2=A0

If the client can=E2=80=99t get to the information in the callback U=
RL unless it=E2=80=99s on the same device, then the client isn=E2=80=99t go=
ing to show the user a scannable code to be read by a secondary device. Why=
 would it?

Because it is =
a better experience for the user per above.=C2=A0

=
The AS parameters don't differentiate between a scannable URL and a URL=
 that can only be redirected, so the client will think it can do anything.=
=C2=A0

Additionally, in XAuth, the client can prov=
ide an informational URI for the AS to redirect after a scannable code or a=
 user code flow.=C2=A0

I'll add additional clarity on what happens when the user =
experience switches between the PC browser and the mobile browser. The clie=
nt loses context of which user the client is interacting with. An attacker =
can take the interaction URL and trick a victim user into clicking on it (a=
 session fixation attack). The client does not know the difference between =
a real user on the mobile device, and a victim on a mobile device. Neither =
scenario has any session state from the original user interaction at the cl=
ient.=C2=A0

Providing a clear signal to the client=
 that the AS won't support a scannable code (or any other redirection t=
o the AS that does not have a redirection back to the same instance of the =
client).

/Dick


=



--000000000000fecdd905aa1bd4b7--


From nobody Fri Jul 10 13:09: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 9C6233A08FE for ; Fri, 10 Jul 2020 13:09:40 -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 eVcvX-P-0Cod for ; Fri, 10 Jul 2020 13:09:35 -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 4440C3A08FA for ; Fri, 10 Jul 2020 13:09:35 -0700 (PDT)
Received: from [192.168.1.7] (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 06AK9V07021189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jul 2020 16:09:33 -0400
From: Justin Richer 
Message-Id: <4A77832C-9613-48BD-9CB2-EE3121E44DB0@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_24794DCE-3DB3-4185-A116-EA42F204C2EF"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 10 Jul 2020 16:09:31 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>     <69082870-1A99-4912-95EA-D1B7A1C967E5@mit.edu>   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 10 Jul 2020 20:09:41 -0000

--Apple-Mail=_24794DCE-3DB3-4185-A116-EA42F204C2EF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Jul 10, 2020, at 1:39 PM, Dick Hardt  wrote:
>=20
>=20
>=20
> On Thu, Jul 9, 2020 at 5:46 PM Justin Richer > wrote:
>=20
>=20
>> On Jul 9, 2020, at 6:50 PM, Dick Hardt > wrote:
>>=20
>>=20
>>=20
>> On Thu, Jul 9, 2020 at 12:17 PM Justin Richer > wrote:
>> On Jul 9, 2020, at 2:32 PM, Dick Hardt > wrote:
>>>=20
>>> Looks like you missed the point of my code example, as your response =
is focussed on the aspects I had in comments, so let me clarify.=20
>>=20
>> The point seemed to be about the overall complexity and readability, =
and that=E2=80=99s what I responded to.
>>=20
>> It was about the complexity and readability -- of those specific =
lines of code.
>=20
> But it=E2=80=99s not just about those lines, it=E2=80=99s about the =
context that those lines are in and the follow-on code paths that they =
cause. A lot of what you had =E2=80=9Cin comments=E2=80=9D for the XAuth =
example would have repeated what was already included in the XYZ =
example, as I pointed out.
>=20
> The context between those lines is pretty much the same. Yes, the =
XAuth example would have had to loop over each scope and RAR object, =
which is not that different than XYZ looping over each item, and the =
deciding how to process each item. My point is that checking the object =
type to decide what to do is an opaque decision vs checking an explicit =
type.

The context is really not the same though, as you actually  point out =
here, and calling one style of type checking =E2=80=9Copaque=E2=80=9D =
vs. =E2=80=9Cexplicit=E2=80=9D is stylistic and not a helpful =
comparison. I=E2=80=99m not surprised to find that you think the way you =
did it is easier, especially given the disconnect we have of what the =
components of the array represent. I started with some of the =
type-field-based structures in early versions of XYZ and moved away from =
them after having bad experiences with building it. There are still a =
few parts of the XYZ protocol that have that style (the =E2=80=9Cuser=E2=80=
=9D section, for example) that I think need to be changed. I think that =
the data-type based style of polymorphism, coupled with using the =
left-hand-side value of object members to indicate type or identifier, =
is significantly simpler in design and implementation.

Instead, I realized that we could get a cleaner protocol and better =
underlying code by dispatching based on the type within the protocol =
itself. I=E2=80=99ve gotten comments from a number of implementers that =
they like this design aspect, and I really like it myself.

> =20
>=20
>>=20
>> I've used JS type polymorphism to provide a cleaner API. For example, =
making an HTTP request. If I'm good with all the defaults, I can just =
provide the URI as a string, if I want to change a default, I provide an =
object and the URI is now a property of the object. Polymorphism allows =
the caller to have a simpler interface when it is a simple operation.
>>=20
>> Do you have any examples of JSON polymorphism used in other protocols =
besides in a JWT?
>=20
> Sounds to me like you=E2=80=99re describing exactly the kind of =
polymorphism that I=E2=80=99m talking about here. Use a string where it =
makes sense and an object where it makes sense, and there=E2=80=99s no =
ambiguity in calling the function. As you say, it's all about providing =
a cleaner API for the caller, and making things consistent in the model =
that the caller and provider are using. It takes a little bit of extra =
effort on the part of the API provider, but that=E2=80=99s where the =
complexity cost should be paid.
>=20
> My examples are not the same at all. The caller has a simpler version =
of passing the same object. XYZ is passing two different types, where a =
string means one thing, and an object means something else. The string =
is not a shorthand for the object.

The string is, semantically, a shorthand for the object. That=E2=80=99s =
what I=E2=80=99ve been saying from the beginning, and I=E2=80=99ve put =
into several examples so far. There are two ways to add rights to an =
access token resulting from the request. So:

{
  =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cphoto=E2=80=9D ]
}

Can really be thought of as a shorthand, for example it could expand to =
this:

{
  =E2=80=9Cresources=E2=80=9D: [
   {
     =E2=80=9Cdatatypes=E2=80=9D: [ =E2=80=9Cpohoto=E2=80=9D ],
     =E2=80=9Cactions=E2=80=9D: [ =E2=80=9Cread=E2=80=9D ],
     =E2=80=9Clocations=E2=80=9D: [ =E2=80=9Chttps://server/photoapi/ =
=E2=80=9C ]
   }
}

In this straw man, if the client wants write access to the API, it needs =
to use the object-style request to do so.

It=E2=80=99s up to the AS, or really the API that it=E2=80=99s =
protecting, to figure out what that expansion really looks like, and how =
much of the more complex policy to expose. My example of processing only =
string-based resource requests was for the case where the AS only gives =
the shorthand version, and doesn=E2=80=99t allow detailed access into =
its protection policies. It=E2=80=99s not a different kind of request, =
it=E2=80=99s a shorthand, much like passing an identifier in lieu of a =
key to identify the client software instance making the call.

But really, the point is that in both cases the string and the object =
both represent the same kind of thing: a piece of access rights that the =
client is requesting at the AS which gets put into the access token. =
Thus, having them together in a single array and processing them =
together makes sense to me. If you are thinking of strings and objects =
as completely different from each other,  you=E2=80=99d expect them to =
be handled separately, but I don=E2=80=99t think they are actually =
different because they both represent a view of the same underlying =
thing.


>=20
> In polymorphic APIs, it makes the code cleaner to pass a singular item =
when the API takes an array, or the API takes a string for the common =
property of the object which is the parameter.

Yes, those are two examples of why it can be good. There are other =
reasons to apply it, like having an array with differently typed items =
that represent the same kind of thing underneath.

> Here are some code examples for both:
>=20
> // passing a singular item, a simpler version of foo(['string'])
> foo('string')
> // passing a plurality of the same item
> foo(['string1','string2','string3'])
>=20
> // implementation
> foo =3D ( param ) =3D> {
>     var a =3D []
>     if (typeof param =3D=3D=3D 'string') {
>         a[0] =3D param;
>     } else if (typeof param =3D=3D=3D 'array') {
>         a =3D param;
>     }
>     // process array a
> }
>=20
>=20
> // pass a uri as string and accept all defaults, a simpler version of =
bar({uri:'uri'})
> bar('uri')
> // pass an object with uri and method
> bar({uri: 'uri', method: 'POST'})
>=20
> // implementation
> bar =3D ( param ) =3D> {
>     var p =3D DEFAULT_OBJ;
>     if (typeof param =3D=3D=3D 'string') {
>         p.uri =3D param;
>     } else if (typeof param =3D=3D=3D 'object') {
>         Object.keys(param).forEach( item =3D> {
>             p[item] =3D param[item];
>         });
>     }
>     // process p object
> }
>=20
> In GNAP, we could take a string rather than an array for a scope =
parameter, for example:
>=20
> "scope": "read"
>=20
> instead of=20
>=20
> "scope": ["read"]
>=20
> OIDC uses the latter polymorphism for=20
>=20
> {=20
>   "name": {"essential": true},
>   "photo": null
> }
>=20
> as being shorthand for=20
>=20
> {=20
>   "name": {"essential": true},
>   "photo": {"essential": false}
> }
>=20

All of these are great examples of why object-type-based polymorphism is =
a good and powerful thing, and that=E2=80=99s the approach I=E2=80=99m =
saying we should use within the GNAP protocol. I would argue that the =
last one isn=E2=80=99t polymorphism so much as a default based on a null =
value (often taken as a special class of an =E2=80=9Cobject=E2=80=9D =
value anyway), but that=E2=80=99s splitting hairs.

> =20
>=20
>> =20
>>=20
>>>=20
>>> This line (which is determining the type of the item in the array):
>>>=20
>>> if (typeof item =3D=3D=3D string')
>>>=20
>>> is implicitly stating that the item is an oauth scope.=20
>>=20
>> No, it is not. It is saying that it is a resource request represented =
as a string. One way to represent a resource request as a string is an =
OAuth 2 style scope. And if you=E2=80=99re building up from an existing =
OAuth 2 system, then you could use a scope there. But that=E2=80=99s not =
the same as stating =E2=80=9Cthe item is a scope=E2=80=9D. In my =
examples, I had been trying to use the terminology that you were using, =
but I=E2=80=99m afraid that made things more unclear.
>>=20
>> We are comparing how to do it in XYZ vs XAuth -- so to make it apples =
and apples, the string is a scope, since that is the use case we are =
looking at.
>=20
> You can use a scope as the string, and if you want to think of all =
string values in this request as all being =E2=80=9Cscopes", that=E2=80=99=
s fine, but only if you can concede that the scope can mean whatever the =
AS wants. I think that perhaps you=E2=80=99re putting a certain amount =
of semantic weight to =E2=80=9Cscope=E2=80=9D that I=E2=80=99m missing, =
though.
>=20
> The string could be a scope, or it could be a claim such as in my =
"oidc" type example. The AS could support both scope and claims, and =
they could have overlapping string values.=20

Both would represent =E2=80=9Cthings that the client wants back in the =
access token=E2=80=9D, and therefore the AS would need to differentiate. =
In that case I think it actually makes a lot more sense for the AS to =
define a more rich mechanism to request user information. In XYZ it =
could look like this:

{
   =E2=80=9Cresources=E2=80=9D: [
     {
        =E2=80=9Ctype=E2=80=9D: =E2=80=9Coidc_userinfo=E2=80=9D,
        =E2=80=9Cdatatypes=E2=80=9D: [ =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Cphone=E2=80=9D, =E2=80=9Caddress=E2=80=9D, =E2=80=9Cprofile.photo=
" ]
     }
   ]
}

But defining the details of that kind of query is clearly outside the =
scope of GNAP (see below), and I think better suited to an identity =
protocol built on top of GNAP.

>=20
> =20
>=20
>> =20
>>=20
>>> Whereas it is explicit in this statement
>>>=20
>>> if (authorizations.type =3D=3D=3D 'oauth_scope')
>>>=20
>>> which I think it easier to understand what is happening (in my =
opinion of course).
>>>=20
>>> XYZ has types, they are just implicit. RAR has explicit types, and =
that does not look to be holding back RAR. I don't understand why you =
think having explicit types will hold us back.=20
>>=20
>> The =E2=80=9Ctype=E2=80=9D in RAR is a name spacing device to allow =
extensibility in different aspects of the request. This is at a lower =
layer than how they=E2=80=99re being applied here, and it therefore =
makes more sense at that layer. It=E2=80=99s a way for a particular API =
to define the dimensions that it cares about in its request. It=E2=80=99s =
not really an even comparison.
>>=20
>> And the type in XAuth authorizations is different schemas for making =
a request. "oauth_scope", "oauth_rar", and now "oidc". I would expect =
that there may be more in the future, and we have a clear way of adding =
schemas, and for the client and AS to know they are talking the same =
"language".
>=20
> And I=E2=80=99m saying that additional =E2=80=9Cschemas=E2=80=9D for =
requesting information should be defined separately from the GNAP =
schema. We disagree on this topic and we=E2=80=99re repeating ourselves.=20=

>=20
> The charter is pretty clear that GNAP should not define schemas, so I =
don't know what you mean by the "the GNAP schema"
> =20

That=E2=80=99s not true. The charter is clear that "nor is the group =
chartered to develop schemas for user information, profiles, or other =
identity attributes=E2=80=9D, but not that it=E2=80=99s not defining =
schemas for the other parts of the protocol. I=E2=80=99ve been clear on =
the other thread that we shouldn=E2=80=99t be defining a user schema, =
for attachment either to the access token or non-identifier items =
returned directly as plaintext or in assertions.=20

By my read, we are fully within our charter to define schemas for =
authorization requests and responses, including both coarse and =
fine-grained access. I understand that it=E2=80=99s your stance that we =
should simply re-use OAuth 2=E2=80=99s =E2=80=9Cscope=E2=80=9D parameter =
for this, and I disagree with that. My proposed approach is to have a =
place within the GNAP protocol to plug in a =E2=80=9Cscope=E2=80=9D =
value if you have one, and for the AS to interpret it, but not to have =
that value always be a =E2=80=9Cscope=E2=80=9D.=20

>=20
>> =20
>>=20
>>> Do you want to let the string and object be anything the AS and RS =
decide they could mean?=20
>>=20
>> Yes. Just like the AS can decide that an OAuth scope could mean any =
number of things.
>>=20
>> That was what I was afraid of. While an OAuth scope could mean =
whatever the AS decides it wants to be, the Client and AS know it is an =
OAuth scope.
>=20
> How is that any different? I=E2=80=99m confused as to why you think =
it=E2=80=99s important to call this item a =E2=80=9Cscope=E2=80=9D so =
that you =E2=80=9Cknow what it is=E2=80=9D, but then you=E2=80=99re OK =
with =E2=80=9Cscope=E2=80=9D meaning literally anything.
>=20
> A scope string is one of a set of strings defined by the AS.
>=20
> The AS may use strings to define a different schema, such as which =
claims to return from a userinfo endpoint.
>=20

Exactly. A scope is a string that represents access to something =
controlled by the AS. The object also represents that same thing, but in =
multiple, more specific dimensions.=20

>  I'm going to separate the my other responses into separate threads as =
they are different topics.
>=20
> /Dick
>=20
> =E1=90=A7


 - Justin=

--Apple-Mail=_24794DCE-3DB3-4185-A116-EA42F204C2EF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Jul 10, 2020, at 1:39 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, Jul =
9, 2020 at 5:46 PM Justin Richer <jricher@mit.edu> wrote:


On Jul 9, 2020, at 6:50 PM, =
Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, =
Jul 9, 2020 at 12:17 PM Justin Richer <jricher@mit.edu> wrote:
On=
 Jul 9, 2020, at 2:32 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Looks like you missed the point =
of my code example, as your response is focussed on the aspects I had =
in comments, so let me =
clarify. 

The point seemed to be about the =
overall complexity and readability, and that=E2=80=99s what I responded =
to.

It was about the complexity and =
readability -- of those specific lines of =
code.

But it=E2=80=99s not just about those =
lines, it=E2=80=99s about the context that those lines are in and the =
follow-on code paths that they cause. A lot of what you had =E2=80=9Cin =
comments=E2=80=9D for the XAuth example would have repeated what was =
already included in the XYZ example, as I pointed =
out.

The context between those lines is =
pretty much the same. Yes, the XAuth example would have had to loop over =
each scope and RAR object, which is not that different than XYZ looping =
over each item, and the deciding how to process each item. My point is =
that checking the object type to decide what to do is an opaque decision =
vs checking an explicit =
type.

The context is really not the same though, as you =
actually  point out here, and calling one style of type checking =
=E2=80=9Copaque=E2=80=9D vs. =E2=80=9Cexplicit=E2=80=9D is stylistic and =
not a helpful comparison. I=E2=80=99m not surprised to find that you =
think the way you did it is easier, especially given the disconnect we =
have of what the components of the array represent. I started with some =
of the type-field-based structures in early versions of XYZ and moved =
away from them after having bad experiences with building it. There are =
still a few parts of the XYZ protocol that have that style (the =
=E2=80=9Cuser=E2=80=9D section, for example) that I think need to be =
changed. I think that the data-type based style of polymorphism, coupled =
with using the left-hand-side value of object members to indicate type =
or identifier, is significantly simpler in design and =
implementation.

Instead, I realized =
that we could get a cleaner protocol and better underlying code by =
dispatching based on the type within the protocol itself. I=E2=80=99ve =
gotten comments from a number of implementers that they like this design =
aspect, and I really like it myself.

 


I've used JS type polymorphism to =
provide a cleaner API. For example, making an HTTP request. If I'm good =
with all the defaults, I can just provide the URI as a string, if I want =
to change a default, I provide an object and the URI is now a property =
of the object. Polymorphism allows the caller to have a simpler =
interface when it is a simple operation.

Do you have any examples of JSON =
polymorphism used in other protocols besides in a =
JWT?

Sounds to me like you=E2=80=99re =
describing exactly the kind of polymorphism that I=E2=80=99m talking =
about here. Use a string where it makes sense and an object where it =
makes sense, and there=E2=80=99s no ambiguity in calling the function. =
As you say, it's all about providing a cleaner API for the caller, and =
making things consistent in the model that the caller and provider are =
using. It takes a little bit of extra effort on the part of the API =
provider, but that=E2=80=99s where the complexity cost should be =
paid.

My examples are not the same at all. =
The caller has a simpler version of passing the same object. XYZ is =
passing two different types, where a string means one thing, and an =
object means something else. The string is not a shorthand for the =
object.

The string is, semantically, a shorthand for the =
object. That=E2=80=99s what I=E2=80=99ve been saying from the beginning, =
and I=E2=80=99ve put into several examples so far. There are two ways to =
add rights to an access token resulting from the request. =
So:

{
  =
=E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cphoto=E2=80=9D =
]
}

Can really be thought =
of as a shorthand, for example it could expand to this:

{
  =E2=80=9Cresources=E2=80=9D: =
[
   {
    =
 =E2=80=9Cdatatypes=E2=80=9D: [ =E2=80=9Cpohoto=E2=80=9D =
],
     =E2=80=9Cactions=E2=80=9D: [ =E2=80=9Crea=
d=E2=80=9D ],
     =E2=80=9Clocations=E2=80=9D: =
[ =E2=80=9Chttps://server/photoapi/=E2=80=9C ]
  =
 }
}

In this straw =
man, if the client wants write access to the API, it needs to use the =
object-style request to do so.

It=E2=80=
=99s up to the AS, or really the API that it=E2=80=99s protecting, to =
figure out what that expansion really looks like, and how much of the =
more complex policy to expose. My example of processing only =
string-based resource requests was for the case where the AS only gives =
the shorthand version, and doesn=E2=80=99t allow detailed access into =
its protection policies. It=E2=80=99s not a different kind of request, =
it=E2=80=99s a shorthand, much like passing an identifier in lieu of a =
key to identify the client software instance making the call.

But really, the point is that in =
both cases the string and the object both represent the =
same kind of thing: a piece of access rights that the =
client is requesting at the AS which gets put into the access token. =
Thus, having them together in a single array and processing them =
together makes sense to me. If you are thinking of strings and objects =
as completely different from each other,  you=E2=80=99d expect them =
to be handled separately, but I don=E2=80=99t think they are actually =
different because they both represent a view of the same underlying =
thing.



In polymorphic APIs, it makes the code =
cleaner to pass a singular item when the API takes an array, or the API =
takes a string for the common property of the object which is the =
parameter. 

Yes, those are two examples of why it can be good. =
There are other reasons to apply it, like having an array with =
differently typed items that represent the same kind of thing =
underneath.

Here are some code examples for both:

// =
passing a singular item, a simpler version of =
foo(['string'])
foo('string')
// passing a plurality of the same item
foo(['string1','string2','string3'])

// =
implementation
foo =3D ( param ) =3D> =
{
    =
var a =3D []
  =
  if (typeof param =3D=3D=3D 'string') {
        a[0] =3D=
 param;
  =
  } else if (typeof param =3D=3D=3D 'array') {
        a =3D =
param;
  =
  }
  =
  // process array a
}


// =
pass a uri as string and accept all defaults, a simpler version of =
bar({uri:'uri'})
bar('uri')
// pass an object with uri and method
bar({uri: 'uri', method: =
'POST'})

// =
implementation
bar =
=3D ( param ) =3D> {
    var p =3D DEFAULT_OBJ;
    if (typeof param =3D=3D=
=3D 'string') {
        p.uri =3D param;
    } else if (typeof =
param =3D=3D=3D 'object') {
        Object.keys(param).forEach( item =
=3D> {
  =
          p[item] =3D =
param[item];
  =
      });
    }
    // process p object
}

In GNAP, we could take a string rather than an array for a =
scope parameter, for example:

"scope": "read"

instead of 

"scope": ["read"]

OIDC uses the latter polymorphism for 

{ 
  "name": {"essential": true},
 =
 "photo": null
}

as being shorthand for 

{ 
  "name": {"essential": true},
 =
 "photo": {"essential": false}
}


All of these are great examples of why =
object-type-based polymorphism is a good and powerful thing, and =
that=E2=80=99s the approach I=E2=80=99m saying we should use within the =
GNAP protocol. I would argue that the last one isn=E2=80=99t =
polymorphism so much as a default based on a null value (often taken as =
a special class of an =E2=80=9Cobject=E2=80=9D value anyway), but =
that=E2=80=99s splitting hairs.

 

 


This =
line (which is determining the type of the item in the =
array):

if (typeof item =
=3D=3D=3D string')

is =
implicitly stating that the item is an oauth scope. 

No, it is not. It is =
saying that it is a resource request represented as a string. One way to =
represent a resource request as a string is an OAuth 2 style scope. And =
if you=E2=80=99re building up from an existing OAuth 2 system, then you =
could use a scope there. But that=E2=80=99s not the same as stating =
=E2=80=9Cthe item is a scope=E2=80=9D. In my examples, I had been trying =
to use the terminology that you were using, but I=E2=80=99m afraid that =
made things more unclear.

We are comparing how to =
do it in XYZ vs XAuth -- so to make it apples and apples, the string is =
a scope, since that is the use case we are looking =
at.

You can use a scope as the string, and =
if you want to think of all string values in this request as all being =
=E2=80=9Cscopes", that=E2=80=99s fine, but only if you can concede that =
the scope can mean whatever the AS wants. I think that perhaps you=E2=80=99=
re putting a certain amount of semantic weight to =E2=80=9Cscope=E2=80=9D =
that I=E2=80=99m missing, though.

The string could be a =
scope, or it could be a claim such as in my "oidc" type example. The AS =
could support both scope and claims, and they could have overlapping =
string values. 

Both would represent =E2=80=9Cthings that the =
client wants back in the access token=E2=80=9D, and therefore the AS =
would need to differentiate. In that case I think it actually makes a =
lot more sense for the AS to define a more rich mechanism to request =
user information. In XYZ it could look like this:

{
   =E2=80=9Cresources=E2=80=9D=
: [
     {
      =
  =E2=80=9Ctype=E2=80=9D: =E2=80=9Coidc_userinfo=E2=80=9D,
=
        =E2=80=9Cdatatypes=E2=80=9D: [ =E2=80=9Cemail=E2=
=80=9D, =E2=80=9Cphone=E2=80=9D, =E2=80=9Caddress=E2=80=9D, =
=E2=80=9Cprofile.photo" ]
    =
 }
   ]
}

But defining the details of that kind of query is =
clearly outside the scope of GNAP (see below), and I think better suited =
to an identity protocol built on top of GNAP.


 

 

Whereas it is explicit in this =
statement

if =
(authorizations.type =3D=3D=3D =
'oauth_scope')

which I think it easier =
to understand what is happening (in my opinion of course).

XYZ has types, they are =
just implicit. RAR has explicit types, and that does not look to be =
holding back RAR. I don't understand why you think having explicit types =
will hold us back. 

The =E2=80=9Ctype=E2=80=9D=
 in RAR is a name spacing device to allow extensibility in different =
aspects of the request. This is at a lower layer than how they=E2=80=99re =
being applied here, and it therefore makes more sense at that layer. =
It=E2=80=99s a way for a particular API to define the dimensions that it =
cares about in its request. It=E2=80=99s not really an even =
comparison.

And the type in XAuth =
authorizations is different schemas for making a request. =
"oauth_scope", "oauth_rar", and now "oidc". I would expect that there =
may be more in the future, and we have a clear way of adding schemas, =
and for the client and AS to know they are talking the same =
"language".

And I=E2=80=99m saying that additional =
=E2=80=9Cschemas=E2=80=9D for requesting information should be defined =
separately from the GNAP schema. We disagree on this topic and we=E2=80=99=
re repeating ourselves. 

The charter is pretty =
clear that GNAP should not define schemas, so I don't know what you mean =
by the "the GNAP schema"
 

That=E2=80=99s not true. The charter is clear that =
"nor is the group chartered to develop schemas for user information, =
profiles, or other identity attributes=E2=80=9D, but not that it=E2=80=99s=
 not defining schemas for the other parts of the protocol. I=E2=80=99ve =
been clear on the other thread that we shouldn=E2=80=99t be defining a =
user schema, for attachment either to the access token or non-identifier =
items returned directly as plaintext or in =
assertions. 

By my read, we are =
fully within our charter to define schemas for authorization requests =
and responses, including both coarse and fine-grained access. I =
understand that it=E2=80=99s your stance that we should simply re-use =
OAuth 2=E2=80=99s =E2=80=9Cscope=E2=80=9D parameter for this, and I =
disagree with that. My proposed approach is to have a place within the =
GNAP protocol to plug in a =E2=80=9Cscope=E2=80=9D value if you have =
one, and for the AS to interpret it, but not to have that value always =
be a =E2=80=9Cscope=E2=80=9D. 


 

Do you want to let the string and object be =
anything the AS and RS decide they could mean? 

Yes. Just like the AS =
can decide that an OAuth scope could mean any number of =
things.

That was what I was afraid of. While an =
OAuth scope could mean whatever the AS decides it wants to be, the =
Client and AS know it is an OAuth =
scope.

How is that any different? I=E2=80=99m =
confused as to why you think it=E2=80=99s important to call this item a =
=E2=80=9Cscope=E2=80=9D so that you =E2=80=9Cknow what it is=E2=80=9D, =
but then you=E2=80=99re OK with =E2=80=9Cscope=E2=80=9D meaning =
literally anything.

A scope string is one of a set of =
strings defined by the AS.

The AS may use strings to define a different schema, such as =
which claims to return from a userinfo endpoint.


Exactly. A scope is a string that represents =
access to something controlled by the AS. The object also represents =
that same thing, but in multiple, more specific =
dimensions. 

 I'm going to separate the my other responses into =
separate threads as they are different topics.

/Dick

3D""=E1=90=A7


 - =
Justin
=

--Apple-Mail=_24794DCE-3DB3-4185-A116-EA42F204C2EF--


From nobody Fri Jul 10 13:09: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 728F53A0909 for ; Fri, 10 Jul 2020 13:09:42 -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 hsr4LldlVHpm for ; Fri, 10 Jul 2020 13:09:39 -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 52BA03A08FC for ; Fri, 10 Jul 2020 13:09:38 -0700 (PDT)
Received: from [192.168.1.7] (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 06AK9V08021189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jul 2020 16:09:37 -0400
From: Justin Richer 
Message-Id: <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3D2C14C8-B931-40D5-A077-DFBB5DB44928"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 10 Jul 2020 16:09:36 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 10 Jul 2020 20:09:43 -0000

--Apple-Mail=_3D2C14C8-B931-40D5-A077-DFBB5DB44928
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Jul 10, 2020, at 2:15 PM, Dick Hardt  wrote:
>=20
>=20
> inline ...=20
>=20
> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer > wrote:
> Yes, the core idea is to not have to parse an assertion to get back =
the core authentication information, which consists of an identifier =
(iss/sub pair in OIDC, but could be a number of things). Sometimes the =
client is going to want the rest of the identity information, but If the =
user=E2=80=99s logged into the client before, the client has likely =
cached that info and probably won=E2=80=99t need it, and sending it =
would be a violation of privacy principles.. The client would want the =
info pretty much just in these cases:
>=20
>  1. The client has never seen the user before.=20
>  2. The user=E2=80=99s information has been updated since the last =
time the client saw it.
>=20
> Agreed
> =20
>=20
> Now for case (1), how would the client know if it wants to request the =
user=E2=80=99s profile info or not, since it doesn=E2=80=99t know who =
the user is?
>=20
> But the client could know who the user is. The client may have used a =
different AS to authenticate the user.

In these cases, the client is not going to be requesting identity =
information from the AS to log the user in, so it=E2=80=99s not relevant =
to the use case. The client will have an opportunity to push that =
information to the AS.

> The User may have self identified to the client. The client may have a =
cookie saying who the user was and the user said that was them. While =
the latter cases are really a strong hint, they are likely right most of =
the time and can lead to a user experience basde on that hint

In these cases, the AS might be able to guess if the client has info =
about the user already, but probably not. And the assumptions fall apart =
if it=E2=80=99s in fact a different user that ends up logging in, which =
is of course possible (the hint you gave doesn=E2=80=99t match the =
identity of the current user after the AS validates them). This =
possibility leads to clients always asking for everything every time and =
the server providing everything every time. That=E2=80=99s a pattern I =
think we should avoid in an ultimate solution =E2=80=94 but ultimately, =
I don=E2=80=99t think that this kind of protocol decision is inside of =
GNAP.

> =20
> And the AS won=E2=80=99t know if client is going to want the profile =
info, since the AS won=E2=80=99t know if the client has the user=E2=80=99s=
 info or not. Sure, the AS might have seen that client and that user =
combo previously, but it doesn=E2=80=99t know if the client needs an =
update.
>=20
> The client can share with the AS the user it knows or thinks it is =
dealing with, which could let the AS respond if the information was new. =
This could be the case for an AS that is providing claims, but not =
authentication, and could happen silently. The user would only interact =
if the user information had changed, and the client wanted the updated =
information.
> =20

See above.

>=20
> And for (2), the client won=E2=80=99t know if the user=E2=80=99s info =
has been updated or not because it doesn=E2=80=99t know who the user is =
yet. If the AS can provide some time of updated stamp to the client, the =
client can pull the new info when it needs it.
>=20
> See above.

See above.

> =20
>=20
> If you ignore both of these cases and put all the user information =
inline with the main request/response, you end up in a situation where =
the client always requests everything and the server always provides =
everything, since you can=E2=80=99t be sure you=E2=80=99re not in =
situation (1) or (2) ahead of time.
>=20
> See above. There are a number of other states the client could be in.
>=20
> For example, the client could be stateless about user information, so =
it knows it is ALWAYS in state 1.

A stateless client would need to fetch appropriate user information =
every time, then. But that=E2=80=99s an optimization for a very specific =
case.

> =20
>=20
> This is really what I mean about the two-stage identity protocol.
>=20
> I know what it is. Per above, GNAP lets us support a wider set of use =
cases. Why limit ourselves to what OIDC supported?

We aren=E2=80=99t limiting the protocol, but instead limiting the scope =
of what we define internal to the GNAP protocol. There=E2=80=99s a lot =
of room for innovation on top of it.

> =20
> In the first stage, you push the bare minimum of what you need to get =
the user known to the client. In the second stage, the client uses its =
access token to call an API to get whatever else it needs to know about =
the user.
>=20
> =46rom a privacy perspective in non-enterprise use cases, I think the =
user should give consent to any updated personal information to a =
client. In general, the client should not be able to get the latest =
information about a user whenever it wants.

This is about the rights associated with the access token, then. And an =
access token doesn=E2=80=99t have to keep working if the AS has a policy =
that says it won=E2=80=99t. The AS/RS could easily decide that a =
particular access token will only return data that hasn=E2=80=99t been =
changed. Maybe it stops working after the data changes, or it just =
returns old data, or any number of things. This is for the AS/RS to =
decide and this is pretty standard interpretation of the token, nothing =
special here because we=E2=80=99re dealing with identity.

 =E2=80=94 Justin

> =20
> /Dick
> =E1=90=A7


--Apple-Mail=_3D2C14C8-B931-40D5-A077-DFBB5DB44928
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Jul 10, 2020, at 2:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


inline ... 

On Thu, Jul =
9, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea is to not have to parse an =
assertion to get back the core authentication information, which =
consists of an identifier (iss/sub pair in OIDC, but could be a number =
of things). Sometimes the client is going to want the rest of the =
identity information, but If the user=E2=80=99s logged into the =
client before, the client has likely cached that info and probably =
won=E2=80=99t need it, and sending it would be a violation of privacy =
principles.. The client would want the info pretty much just in these =
cases:

 1. The =
client has never seen the user before. 
 2.=
 The user=E2=80=99s information has been updated since the last time the =
client saw it.

Agreed
 

Now for case (1), how would the client know if it wants to =
request the user=E2=80=99s profile info or not, since it doesn=E2=80=99t =
know who the user is? 

But the client could know who the user =
is. The client may have used a different AS to authenticate the user. =


In these cases, the client is not going to be =
requesting identity information from the AS to log the user in, so =
it=E2=80=99s not relevant to the use case. The client will have an =
opportunity to push that information to the AS.

The User may have self identified to the client. The client =
may have a cookie saying who the user was and the user said that was =
them. While the latter cases are really a strong hint, they are likely =
right most of the time and can lead to a user experience basde on that =
hint

In these cases, the AS might be able to guess if =
the client has info about the user already, but probably not. And the =
assumptions fall apart if it=E2=80=99s in fact a different user that =
ends up logging in, which is of course possible (the hint you gave =
doesn=E2=80=99t match the identity of the current user after the AS =
validates them). This possibility leads to clients always asking for =
everything every time and the server providing everything every time. =
That=E2=80=99s a pattern I think we should avoid in an ultimate solution =
=E2=80=94 but ultimately, I don=E2=80=99t think that this kind of =
protocol decision is inside of GNAP.

 
And the AS won=E2=80=99t know if =
client is going to want the profile info, since the AS won=E2=80=99t =
know if the client has the user=E2=80=99s info or not. Sure, the AS =
might have seen that client and that user combo previously, but it =
doesn=E2=80=99t know if the client needs an =
update.

The client can share with the AS the user it knows or thinks =
it is dealing with, which could let the AS respond if the information =
was new. This could be the case for an AS that is providing claims, but =
not authentication, and could happen silently. The user would only =
interact if the user information had changed, and the client wanted the =
updated information.
 

See above.


And for (2), the client won=E2=80=99t know if the user=E2=80=99=
s info has been updated or not because it doesn=E2=80=99t know who the =
user is yet. If the AS can provide some time of updated stamp to the =
client, the client can pull the new info when it needs =
it.

See above.

See above.

 

If you ignore both of these cases and put all the user =
information inline with the main request/response, you end up in a =
situation where the client always requests everything and the server =
always provides everything, since you can=E2=80=99t be sure you=E2=80=99re=
 not in situation (1) or (2) ahead of time.

See above. There are a =
number of other states the client could be in.

For example, the client could be =
stateless about user information, so it knows it is ALWAYS in state =
1.

A stateless client would need to fetch appropriate =
user information every time, then. But that=E2=80=99s an optimization =
for a very specific case.

 

This is really what I mean about the two-stage identity =
protocol. 

I know what it is. Per above, GNAP lets =
us support a wider set of use cases. Why limit ourselves to what OIDC =
supported?

We aren=E2=80=99t limiting the protocol, but =
instead limiting the scope of what we define internal to the GNAP =
protocol. There=E2=80=99s a lot of room for innovation on top of =
it.

 
In the first stage, you push the =
bare minimum of what you need to get the user known to the client. In =
the second stage, the client uses its access token to call an API to get =
whatever else it needs to know about the user. =


=46rom a privacy perspective in non-enterprise use cases, I =
think the user should give consent to any updated personal information =
to a client. In general, the client should not be able to get the =
latest information about a user whenever it =
wants.

This is about the rights associated with the =
access token, then. And an access token doesn=E2=80=99t have to keep =
working if the AS has a policy that says it won=E2=80=99t. The AS/RS =
could easily decide that a particular access token will only return data =
that hasn=E2=80=99t been changed. Maybe it stops working after the data =
changes, or it just returns old data, or any number of things. This is =
for the AS/RS to decide and this is pretty standard interpretation of =
the token, nothing special here because we=E2=80=99re dealing with =
identity.

 =E2=80=94 =
Justin

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



=

--Apple-Mail=_3D2C14C8-B931-40D5-A077-DFBB5DB44928--


From nobody Fri Jul 10 13:11: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 C77923A08FA for ; Fri, 10 Jul 2020 13:11:47 -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 J81M-mQMr3Yu for ; Fri, 10 Jul 2020 13:11: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 1B6DB3A08FE for ; Fri, 10 Jul 2020 13:11:44 -0700 (PDT)
Received: from [192.168.1.7] (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 06AK9V09021189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jul 2020 16:09:40 -0400
From: Justin Richer 
Message-Id: <89945398-E404-4FAE-91D0-5C5E8F202CDE@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_45E34E26-28C2-4BB4-9F59-4A80DD311892"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 10 Jul 2020 16:09:40 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] WG scope wrt. identity (Was: Polymorphism (Was: JSON Schema?))
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, 10 Jul 2020 20:11:48 -0000

--Apple-Mail=_45E34E26-28C2-4BB4-9F59-4A80DD311892
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

It seems to be pretty clear that you and I are interpreting the charter =
text differently, so I=E2=80=99d like to hear what the chairs think the =
best approach will be when we finally get to defining what=E2=80=99s =
included in GNAP. This should perhaps be a discussion point for the =
group in the upcoming meeting. Until then, I can hopefully expand on =
what I interpret.

The charter uses the term =E2=80=9Cidentity information within the =
protocol including existing identifiers ... and assertions=E2=80=9D and =
not =E2=80=9Cclaims=E2=80=9D, which I think is more precise and that =
GNAP should use language instead of =E2=80=9Cclaims=E2=80=9D for this =
reason. I think the XYZ use of the term =E2=80=9Cclaims=E2=80=9D is a =
mistake and it should change because it=E2=80=99s confusing.

The only time =E2=80=9Cclaims=E2=80=9D are mentioned in the charter is =
in the section about not making assumptions about the client and having =
a protocol =E2=80=9Callowing for =E2=80=A6 Approval of AS attestation to =
identifiers and other identity claims=E2=80=9D. To me, this does not say =
that the protocol should have room for more advanced identity stuff, not =
that GNAP should specify how it=E2=80=99s requested or returned.

There are use cases for getting signed assertions back from the AS as =
well, and so the protocol should allow for that. While assertions can =
often contain non-identifier claims, it=E2=80=99s not up to GNAP to =
define what those claims are, how they=E2=80=99re requested, or how =
they=E2=80=99re returned. There are also lots of valid use cases for the =
client requesting a specific set of non-identifier claims about the =
user. The question is, how much of that detail should we be solving =
directly here in GNAP? I think it=E2=80=99s pretty clear that the answer =
is =E2=80=9Cnot much at all=E2=80=9D.

My original XYZ proposal didn=E2=80=99t have any identity information in =
it, much like OAuth 2. After talking with Aaron and a few others, I was =
convinced that we could have a very small delta to let the client know =
who the user is. When writing the charter text, that=E2=80=99s what I =
originally had in mind by the =E2=80=9Cidentity=E2=80=9D language =
throughout. Several people spoke up and said that they would like space =
left to return signed assertions as well, and there seemed to be enough =
support to have that as an option in the charter so it was added. What I =
did not see support for, and in fact saw explicit pushback against, was =
defining ways to return additional user information in the GNAP =
response, at least as defined internally by GNAP. That seems to be what =
you=E2=80=99re arguing for doing here.

I think there will be room, and need, for a protocol on top of GNAP to =
define identity schemas, assertions, session handling, authentication =
contexts, and identity-based APIs in a standard way. It=E2=80=99s my =
understanding that all of this is outside of GNAP=E2=80=99s core focus, =
but that GNAP should keep this kind of work in mind in its design. So =
that, for instance, we don=E2=80=99t accidentally design a protocol that =
prevents an AS from tying both identity information and=20

I realize that Xauth had non-identifier claims since early drafts, and I =
disagree with their inclusion. I think that the group is going to have =
to decide how far down this identity road we really want to go with =
GNAP, and I don=E2=80=99t think that=E2=80=99s an answered question yet.=20=


 =E2=80=94 Justin


> On Jul 10, 2020, at 2:33 PM, Dick Hardt  wrote:
>=20
> Justin, your stance is surprising for the following reasons:
>=20
> 1) Both XYZ and XAuth use the term claims, rather than identifiers. "A =
claim is a statement that one subject, such as a person or organization, =
makes about itself or another subject."[1]. A claim is clearly more than =
an identifier.
>=20
> 2) XAuth has had non-identifier claims in the examples since -01 =
(name, photo).
>=20
> 3) The charter does not state that ONLY identifiers will be returned, =
identifiers are one of the examples, as are OIDC ID Tokens, SAML =
assertions, and Verifiable Credentials. All of these often bind =
non-identifiers to one or more identifiers. =20
>=20
> [1] =
https://en.wikipedia.org/wiki/Claims-based_identity#Identity_and_claims =

>=20
> Justin's stance earlier in the discussion:
>=20
> My stance is that we allow the client to ask for a small set of =
identifiers about the user, or even just ask to =E2=80=9Cidentify the =
user=E2=80=9D, and leave everything else to a higher level identity =
protocol. I do not think that having an identity and profile =
query/response language at the core of GNAP is a good idea, and it=E2=80=99=
s certainly not in our charter.
>=20
> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer > wrote:
> =20
> I=E2=80=99m sorry that you are surprised by my stance, but it hasn=E2=80=
=99t changed since I helped write the section of the charter that you =
quoted below. A big reason that I chose that wording was to support this =
use case but not to go in depth with an identity protocol, which I never =
really wanted us to do. However, it seems as soon as =E2=80=9Cidentity=E2=80=
=9D was brought up previously, people immediately jumped into talking =
about a full stack of user attributes and profile information. That =
wasn=E2=80=99t my intent in talking about identity, and I don=E2=80=99t =
think it=E2=80=99s something GNAP ought to do, at least not on its own.=20=

>=20
> I do think there=E2=80=99s room for us to provide identifiers =
alongside the access token, so that=E2=80=99s there. There was stated =
interest in providing signed assertions as well, so I made sure that was =
enumerated for those who want to do such work. And I think it makes =
sense for us to provide a way to describe what kinds of things I want to =
get from an access token by defining a general purpose syntax for =
describing those things (notably, as a combination of reference strings =
and multi-dimensional objects). With these two, we can get most of what =
we need for a basic login system. Anything beyond that is going to need =
user profiles, authentication contexts, session control, and a lot of =
other identity-protocol stuff that GNAP shouldn=E2=80=99t be focusing =
on. We should keep it in mind as we build GNAP, but I think that like =
OIDC all that important extra stuff should be built separately. To me, =
that=E2=80=99s what not defining schemas and formats means.=20
>=20
> I don=E2=80=99t see any conflict with the charter here, and I=E2=80=99m =
surprised that you do.
>=20
> =E1=90=A7


--Apple-Mail=_45E34E26-28C2-4BB4-9F59-4A80DD311892
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

It =
seems to be pretty clear that you and I are interpreting the charter =
text differently, so I=E2=80=99d like to hear what the chairs think the =
best approach will be when we finally get to defining what=E2=80=99s =
included in GNAP. This should perhaps be a discussion point for the =
group in the upcoming meeting. Until then, I can hopefully expand on =
what I interpret.

The =
charter uses the term =E2=80=9Cidentity information within the protocol =
including existing identifiers ... and assertions=E2=80=9D and not =
=E2=80=9Cclaims=E2=80=9D, which I think is more precise and that GNAP =
should use language instead of =E2=80=9Cclaims=E2=80=9D for this reason. =
I think the XYZ use of the term =E2=80=9Cclaims=E2=80=9D is a mistake =
and it should change because it=E2=80=99s confusing.

The only time =E2=80=9Cclaims=E2=80=9D =
are mentioned in the charter is in the section about not making =
assumptions about the client and having a protocol =E2=80=9Callowing for =
=E2=80=A6 Approval of AS attestation to identifiers and other identity =
claims=E2=80=9D. To me, this does not say that the protocol should have =
room for more advanced identity stuff, not that GNAP should specify how =
it=E2=80=99s requested or returned.

There are use cases for getting signed =
assertions back from the AS as well, and so the protocol should allow =
for that. While assertions can often contain non-identifier claims, =
it=E2=80=99s not up to GNAP to define what those claims are, how =
they=E2=80=99re requested, or how they=E2=80=99re returned. There are =
also lots of valid use cases for the client requesting a specific set of =
non-identifier claims about the user. The question is, how much of that =
detail should we be solving directly here in GNAP? I think it=E2=80=99s =
pretty clear that the answer is =E2=80=9Cnot much at all=E2=80=9D.

My original XYZ =
proposal didn=E2=80=99t have any identity information in it, much like =
OAuth 2. After talking with Aaron and a few others, I was convinced that =
we could have a very small delta to let the client know who the user is. =
When writing the charter text, that=E2=80=99s what I originally had in =
mind by the =E2=80=9Cidentity=E2=80=9D language throughout. Several =
people spoke up and said that they would like space left to return =
signed assertions as well, and there seemed to be enough support to have =
that as an option in the charter so it was added. What I did not see =
support for, and in fact saw explicit pushback against, was defining =
ways to return additional user information in the GNAP response, at =
least as defined internally by GNAP. That seems to be what you=E2=80=99re =
arguing for doing here.

I think there will be room, and need, for a protocol on top =
of GNAP to define identity schemas, assertions, session handling, =
authentication contexts, and identity-based APIs in a standard way. =
It=E2=80=99s my understanding that all of this is outside of GNAP=E2=80=99=
s core focus, but that GNAP should keep this kind of work in mind in its =
design. So that, for instance, we don=E2=80=99t accidentally design a =
protocol that prevents an AS from tying both identity information =
and 

I =
realize that Xauth had non-identifier claims since early drafts, and I =
disagree with their inclusion. I think that the group is going to have =
to decide how far down this identity road we really want to go with =
GNAP, and I don=E2=80=99t think that=E2=80=99s an answered question =
yet. 

 =E2=80=94 Justin

On Jul 10, 2020, at 2:33 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

Justin, your =
stance is surprising for the following reasons:

1) Both XYZ and XAuth use the term =
claims, rather than identifiers. "A claim is a statement that one subject, such as a person or =
organization, makes about itself or another subject."[1]. A claim is =
clearly more than an identifier.

2) XAuth has had =
non-identifier claims in the examples since -01 (name, =
photo).

3) The =
charter does not state that ONLY identifiers will be returned, =
identifiers are one of the examples, as are OIDC ID Tokens, SAML =
assertions, and Verifiable Credentials. All of these often bind =
non-identifiers to one or more identifiers.  

[1] https://en.wikipedia.org/wiki/Claims-based_identity#Identity_an=
d_claims

Justin's stance earlier in the =
discussion:

My =
stance is that we allow the client to ask for a small set of identifiers =
about the user, or even just ask to =E2=80=9Cidentify the user=E2=80=9D, =
and leave everything else to a higher level identity protocol. I do not =
think that having an identity and profile query/response language at the =
core of GNAP is a good idea, and it=E2=80=99s certainly not in our =
charter.

On Thu, Jul =
9, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:
<snip> 
I=E2=80=99m sorry that you are surprised by my stance, but it =
hasn=E2=80=99t changed since I helped write the section of the charter =
that you quoted below. A big reason that I chose that wording was to =
support this use case but not to go in depth with an identity protocol, =
which I never really wanted us to do. However, it seems as soon as =
=E2=80=9Cidentity=E2=80=9D was brought up previously, people immediately =
jumped into talking about a full stack of user attributes and profile =
information. That wasn=E2=80=99t my intent in talking about identity, =
and I don=E2=80=99t think it=E2=80=99s something GNAP ought to do, at =
least not on its own. 

I do think there=E2=80=99s room for us to provide =
identifiers alongside the access token, so that=E2=80=99s there. There =
was stated interest in providing signed assertions as well, so I made =
sure that was enumerated for those who want to do such work. And I think =
it makes sense for us to provide a way to describe what kinds of things =
I want to get from an access token by defining a general purpose syntax =
for describing those things (notably, as a combination of reference =
strings and multi-dimensional objects). With these two, we can get most =
of what we need for a basic login system. Anything beyond that is going =
to need user profiles, authentication contexts, session control, and a =
lot of other identity-protocol stuff that GNAP shouldn=E2=80=99t be =
focusing on. We should keep it in mind as we build GNAP, but I think =
that like OIDC all that important extra stuff should be built =
separately. To me, that=E2=80=99s what not defining schemas and formats =
means. 

I =
don=E2=80=99t see any conflict with the charter here, and I=E2=80=99m =
surprised that you do.

3D""=E1=90=A7


=

--Apple-Mail=_45E34E26-28C2-4BB4-9F59-4A80DD311892--


From nobody Fri Jul 10 13:17: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 629DF3A091D for ; Fri, 10 Jul 2020 13:17: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 jBZjHWDosWgp for ; Fri, 10 Jul 2020 13:17: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 997703A0920 for ; Fri, 10 Jul 2020 13:17:12 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id o4so3880931lfi.7 for ; Fri, 10 Jul 2020 13:17:12 -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=0WKxvrenDIbKvd+ZgJ61ehGpKXGBNJezsr8zJ++2/Tc=; b=T0P9s8cQLdeohTzVQxL40AKKMdh647HGS+7cKy7giZIs0KW4IeDI3VqTyCUwCHhvsw jU8bGcMiq7KJRgTrw5zsJP4erC7rnYL/2MLlSB+EidRjw50WCz118cl5ho0eoBzRPTMN wBMvXDS92lH3DMksvGpK8dcVlOuuscFppXISQsnRkoVpgVfzhEnywVi4Meml17ny3hVb vrgmLvvXWhjJCTrm/op/6NfcX4vS6/vJbx+G8cPlRk2xsgix8U/WS2c5VwRKjcB0mBZ5 Au0wYnaBb7IpF1eYF0B3xePM342JFde4/pAmV+NUWJVuyVN8USs2zL1DGgrkbaNY9H6H RdNQ==
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=0WKxvrenDIbKvd+ZgJ61ehGpKXGBNJezsr8zJ++2/Tc=; b=L+QctWfjcTIrSHEDUWQPCoGM5sSkZx4aR0mXswRP0GR8AovFfELQZhvBFtcyPO4fK2 Pe1/+HZP7fxgMdAPVXiNhJXenVyxx7FhO/e+hAjFoi63/D1yKz5v7L9kFxQrKKk1G6cB /LceBiX+QzAlH7Bsx+DmptMh8he6k8me/1UaK1ViB7+vFXg4Zl/b7V6hZfXrCnPftbcR EW5bv+XCFoPWF1I97FFmvuOb06nOa8OdRqJXvdc10Y2ZHkiMqeQQdcjkzqO/ycWSE0U5 GUOfHSAMr1xKm/A88P1bgKezc8QHPdonBvLLj5K/ocSawH4N/3Xg125fZbGTRjZNEWse nQ7Q==
X-Gm-Message-State: AOAM532nUwelGY29i0nuGv7a5lZdRB+nLT7QpHLUx2mFd4Pux9rSDuO2 YSdxVZy0fnIxQCiy/xZfzW+6mRzBAhOObjsz/Qg/vxGo
X-Google-Smtp-Source: ABdhPJx+VBpihhTlEQpS5QUCCElkY9aQ720FLjS+oF9MaawmQ4tj/B4HMwGJzZlu1bFKV8YmDew0cJqCgKHwFSH90/Y=
X-Received: by 2002:ac2:5093:: with SMTP id f19mr45146094lfm.10.1594412230321;  Fri, 10 Jul 2020 13:17:10 -0700 (PDT)
MIME-Version: 1.0
From: Dick Hardt 
Date: Fri, 10 Jul 2020 13:16:34 -0700
Message-ID: 
To: txauth@ietf.org, Justin Richer ,  Mike Jones 
Content-Type: multipart/alternative; boundary="0000000000009d2a8705aa1c0607"
Archived-At: 
Subject: [Txauth] Key handle vs client id & handle
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, 10 Jul 2020 20:17:16 -0000

--0000000000009d2a8705aa1c0607
Content-Type: text/plain; charset="UTF-8"

+ Mike as he had interest in this topic

My understanding is that an existing OAuth 2 client would use their current
client id as their key handle, and a dynamic client (one that was not
pre-registered) would be given a key handle by the AS.

There are potentially some significant differences between a registered
client, and a dynamic client to an AS.

The AS is likely to know the identity of a registered client, and have
different policies between the two types of clients. For example, a
registered client may have access to a 'write" scope, while a dynamic
client does not.

The AS may have 100s or 1000s of registered clients, but a dynamic client
may have 10Ms or 100Ms of instances, which may dictate separate storage
services. Additionally, internal to the AS, which systems can write to the
registered client store is going to be different than the dynamic
client store.

In XYZ, subsequent calls to the AS, both registered clients and dynamic
clients pass a key handle, so there is no easy way to differentiate between
the two.

While the AS could embed semantics in the key handle identifier to indicate
which identifiers are pre-registered vs dynamic, there are many cases where
the AS does need to know the difference, so making the difference a feature
of GNAP seems like a better path.

--0000000000009d2a8705aa1c0607
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


+ Mike as he had interest in this topic

My un=
derstanding is that an existing OAuth 2 client would use their current clie=
nt id as their key handle, and a dynamic client (one that was not pre-regis=
tered) would be given a key handle by the AS.

Ther=
e are potentially some significant differences between a registered client,=
 and a dynamic client to an AS.

The AS is likely t=
o know the identity of a registered client, and have different policies bet=
ween the two types of clients. For example, a registered client may have ac=
cess to a 'write" scope, while a dynamic client does not.

The AS may have 100s or 1000s of registered clients, but a=
 dynamic client may have 10Ms or 100Ms of instances, which may dictate sepa=
rate=C2=A0storage services. Additionally, internal to the AS, which systems=
 can write to the registered=C2=A0client store is going to be different tha=
n the dynamic client=C2=A0store.

In XYZ, subsequen=
t calls to the AS, both registered clients and dynamic clients pass a key h=
andle, so there is no easy way to differentiate between the two.
=

While the AS could embed semantics in the key handle identif=
ier to indicate which identifiers are pre-registered vs dynamic, there are =
many cases where the AS does need to know the difference, so making=C2=A0th=
e difference a feature of GNAP seems like a better path.



--0000000000009d2a8705aa1c0607--


From nobody Fri Jul 10 13:33: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 6CF513A0955 for ; Fri, 10 Jul 2020 13:33:09 -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 6hQQnx1TmlQ8 for ; Fri, 10 Jul 2020 13:33:06 -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 87E8B3A094F for ; Fri, 10 Jul 2020 13:33:06 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id j11so7860665ljo.7 for ; Fri, 10 Jul 2020 13:33: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=VvMhB/FWet+7MRH4jTTcq66zEhMqMWaD/pLU39az49E=; b=Wuut2tzWOtfNk22qlAnZ3RjHa/FJ4Wi60aXT7+V1NwAEjdn8bR17qU3f/s1xk2s3Fc 8Pbjfr83smKNpoAL8rQmaEkHkMFwBtdnCtcV7Z1jBo9a+srF5RVIAzeavNVvtKQs1E4m thCGWlQrnQ4o23MkPTb5H2fh2AXKvvCH6mt7uCr5gDFuiB/gtWRyYnVr9b6cTbovZ2iE cWmK6UI3eeaQYCH89XwiXkNVvcsJN9Mc99nNw1VFRbgIS78pYky1iN/dakD697od4YdU d9xou9Cg+3BExlnQp/YBvmSKT11CFh3X2eLKfTaYGbg1NL2N2tXKWezZczPONXyktJnI cCmA==
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=VvMhB/FWet+7MRH4jTTcq66zEhMqMWaD/pLU39az49E=; b=iBqekh5GCHuoIvt0B9t2GcSaztq/UfxgAq0FYrYRMvVxwn5LkRNlvCrIlqVQ+YtKcG oXflZHHnEBHzK/L/dlFhbI+XrKQHL2fQvwELNjWEX9F3+YoChLy8th9yYXYNAPChXYqC RDHFUg21RgprUon9vaMtIDF1oeEdDvVx2b6Se4DeD9sfjvp3Q/ZtjgS65XGoC3PmmMnB gxpVcYanEN+ofSWKMiQJFH7jSi6FzJuucmi/8xAYXkW8DI8mmzoiZepF34T2DshZHT/5 SpHl8pK55YxLL/o61qOWS2z1+p9SXIUtGXBpyJg3bA4TyN+ByqpvZt8C3R7yBCTqAQoO /rhw==
X-Gm-Message-State: AOAM533Mt1XsXgYSRWJELE3ulEkKsB/jBoN7adrFzzDN67A3O/BV4D1C AVVBsSy04OecEAH6ba7mqXc3Va+SCHZrRT4s3v4=
X-Google-Smtp-Source: ABdhPJzHQfX9hnZMykgRTheAZ3tEJJPhZ5CwCGYKsD1j5I022MIn0t9jfEni0BUkoXGDuHb0x9mrQfpJO329f/WO2bo=
X-Received: by 2002:a2e:900a:: with SMTP id h10mr43086128ljg.242.1594413184327;  Fri, 10 Jul 2020 13:33:04 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <89945398-E404-4FAE-91D0-5C5E8F202CDE@mit.edu>
In-Reply-To: <89945398-E404-4FAE-91D0-5C5E8F202CDE@mit.edu>
From: Dick Hardt 
Date: Fri, 10 Jul 2020 13:32:28 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007a23e005aa1c3fbb"
Archived-At: 
Subject: Re: [Txauth] WG scope wrt. identity (Was: Polymorphism (Was: JSON Schema?))
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, 10 Jul 2020 20:33:10 -0000

--0000000000007a23e005aa1c3fbb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

My interpretation is pretty straight forward:

1) GNAP should be able to return ANY claim, not just identifiers.

2) GNAP should not define any claim schema, contrary to what XZY does

The pushback in the group, which I am pretty familiar with having been a
BoF chair at the time, and I personally worked to resolve, was that
"identity" was too broad, and there was concern the scope included defining
new schemas. The revised charter made that clarification. I don't recall
ANY discussion that GNAP should only return identifiers. The charter reads
that identifiers are included in what could be returned.

If you did not agree with non-identifier claims being in XAuth since the
beginning, why did you not say anything? I have not agreed with XYZ
defining a new schema, and have voiced that concern a number of times.

The above reasons are why I was surprised to suddenly learn your position.






On Fri, Jul 10, 2020 at 1:09 PM Justin Richer  wrote:

> It seems to be pretty clear that you and I are interpreting the charter
> text differently, so I=E2=80=99d like to hear what the chairs think the b=
est
> approach will be when we finally get to defining what=E2=80=99s included =
in GNAP.
> This should perhaps be a discussion point for the group in the upcoming
> meeting. Until then, I can hopefully expand on what I interpret.
>
> The charter uses the term =E2=80=9Cidentity information within the protoc=
ol
> including existing identifiers ... and assertions=E2=80=9D and not =E2=80=
=9Cclaims=E2=80=9D, which
> I think is more precise and that GNAP should use language instead of
> =E2=80=9Cclaims=E2=80=9D for this reason. I think the XYZ use of the term=
 =E2=80=9Cclaims=E2=80=9D is a
> mistake and it should change because it=E2=80=99s confusing.
>
> The only time =E2=80=9Cclaims=E2=80=9D are mentioned in the charter is in=
 the section
> about not making assumptions about the client and having a protocol
> =E2=80=9Callowing for =E2=80=A6 Approval of AS attestation to identifiers=
 and other
> identity claims=E2=80=9D. To me, this does not say that the protocol shou=
ld have
> room for more advanced identity stuff, not that GNAP should specify how
> it=E2=80=99s requested or returned.
>
> There are use cases for getting signed assertions back from the AS as
> well, and so the protocol should allow for that. While assertions can oft=
en
> contain non-identifier claims, it=E2=80=99s not up to GNAP to define what=
 those
> claims are, how they=E2=80=99re requested, or how they=E2=80=99re returne=
d. There are also
> lots of valid use cases for the client requesting a specific set of
> non-identifier claims about the user. The question is, how much of that
> detail should we be solving directly here in GNAP? I think it=E2=80=99s p=
retty
> clear that the answer is =E2=80=9Cnot much at all=E2=80=9D.
>
> My original XYZ proposal didn=E2=80=99t have any identity information in =
it, much
> like OAuth 2. After talking with Aaron and a few others, I was convinced
> that we could have a very small delta to let the client know who the user
> is. When writing the charter text, that=E2=80=99s what I originally had i=
n mind by
> the =E2=80=9Cidentity=E2=80=9D language throughout. Several people spoke =
up and said that
> they would like space left to return signed assertions as well, and there
> seemed to be enough support to have that as an option in the charter so i=
t
> was added. What I did not see support for, and in fact saw explicit
> pushback against, was defining ways to return additional user information
> in the GNAP response, at least as defined internally by GNAP. That seems =
to
> be what you=E2=80=99re arguing for doing here.
>
> I think there will be room, and need, for a protocol on top of GNAP to
> define identity schemas, assertions, session handling, authentication
> contexts, and identity-based APIs in a standard way. It=E2=80=99s my unde=
rstanding
> that all of this is outside of GNAP=E2=80=99s core focus, but that GNAP s=
hould keep
> this kind of work in mind in its design. So that, for instance, we don=E2=
=80=99t
> accidentally design a protocol that prevents an AS from tying both identi=
ty
> information and
>
> I realize that Xauth had non-identifier claims since early drafts, and I
> disagree with their inclusion. I think that the group is going to have to
> decide how far down this identity road we really want to go with GNAP, an=
d
> I don=E2=80=99t think that=E2=80=99s an answered question yet.
>
>  =E2=80=94 Justin
>
>
> On Jul 10, 2020, at 2:33 PM, Dick Hardt  wrote:
>
> Justin, your stance is surprising for the following reasons:
>
> 1) Both XYZ and XAuth use the term claims, rather than identifiers. "A
> claim is a statement that one subject, such as a person or organization,
> makes about itself or another subject."[1]. A claim is clearly more than =
an
> identifier.
>
> 2) XAuth has had non-identifier claims in the examples since -01 (name,
> photo).
>
> 3) The charter does not state that ONLY identifiers will be returned,
> identifiers are one of the examples, as are OIDC ID Tokens, SAML
> assertions, and Verifiable Credentials. All of these often bind
> non-identifiers to one or more identifiers.
>
> [1]
> https://en.wikipedia.org/wiki/Claims-based_identity#Identity_and_claims
>
> Justin's stance earlier in the discussion:
>
>
> My stance is that we allow the client to ask for a small set of
> identifiers about the user, or even just ask to =E2=80=9Cidentify the use=
r=E2=80=9D, and
> leave everything else to a higher level identity protocol. I do not think
> that having an identity and profile query/response language at the core o=
f
> GNAP is a good idea, and it=E2=80=99s certainly not in our charter.
>
>
> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer  wrote:
> 
>
>> I=E2=80=99m sorry that you are surprised by my stance, but it hasn=E2=80=
=99t changed
>> since I helped write the section of the charter that you quoted below. A
>> big reason that I chose that wording was to support this use case but no=
t
>> to go in depth with an identity protocol, which I never really wanted us=
 to
>> do. However, it seems as soon as =E2=80=9Cidentity=E2=80=9D was brought =
up previously,
>> people immediately jumped into talking about a full stack of user
>> attributes and profile information. That wasn=E2=80=99t my intent in tal=
king about
>> identity, and I don=E2=80=99t think it=E2=80=99s something GNAP ought to=
 do, at least not
>> on its own.
>>
>> I do think there=E2=80=99s room for us to provide identifiers alongside =
the
>> access token, so that=E2=80=99s there. There was stated interest in prov=
iding
>> signed assertions as well, so I made sure that was enumerated for those =
who
>> want to do such work. And I think it makes sense for us to provide a way=
 to
>> describe what kinds of things I want to get from an access token by
>> defining a general purpose syntax for describing those things (notably, =
as
>> a combination of reference strings and multi-dimensional objects). With
>> these two, we can get most of what we need for a basic login system.
>> Anything beyond that is going to need user profiles, authentication
>> contexts, session control, and a lot of other identity-protocol stuff th=
at
>> GNAP shouldn=E2=80=99t be focusing on. We should keep it in mind as we b=
uild GNAP,
>> but I think that like OIDC all that important extra stuff should be buil=
t
>> separately. To me, that=E2=80=99s what not defining schemas and formats =
means.
>>
>> I don=E2=80=99t see any conflict with the charter here, and I=E2=80=99m =
surprised that
>> you do.
>>
>> =E1=90=A7
>
>
>

--0000000000007a23e005aa1c3fbb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


My interpretation is pretty straight forward:

1) GNAP should be able to return ANY claim, not just identifiers.

2) GNAP should not define any claim schema, contrary=
 to what XZY does

The pushback in the group, which=
=C2=A0I am pretty familiar with having been a BoF chair at the time, and I =
personally worked to resolve, was that "identity" was too broad, =
and there was concern the scope included defining new schemas. The revised =
charter made that clarification. I don't recall ANY discussion that GNA=
P should only return identifiers. The charter reads that identifiers are in=
cluded in what could be returned.

If you did not a=
gree with non-identifier claims being in XAuth since the beginning, why did=
 you not say anything? I have not agreed with XYZ defining a new schema, an=
d have voiced that concern a number of times.=C2=A0

The above reasons are why I was surprised=C2=A0to suddenly learn your pos=
ition.






On Fri, Jul 10, 2020 at 1:09 PM Justin Richer <jricher@mit.edu> wrote:
It seems to be pretty clear that you and I are interpreting the charter=
 text differently, so I=E2=80=99d like to hear what the chairs think the be=
st approach will be when we finally get to defining what=E2=80=99s included=
 in GNAP. This should perhaps be a discussion point for the group in the up=
coming meeting. Until then, I can hopefully expand on what I interpret.
The charter uses the term =E2=80=9Cidentity information wit=
hin the protocol including existing identifiers ... and assertions=E2=80=9D=
 and not =E2=80=9Cclaims=E2=80=9D, which I think is more precise and that G=
NAP should use language instead of =E2=80=9Cclaims=E2=80=9D for this reason=
. I think the XYZ use of the term =E2=80=9Cclaims=E2=80=9D is a mistake and=
 it should change because it=E2=80=99s confusing.

The on=
ly time =E2=80=9Cclaims=E2=80=9D are mentioned in the charter is in the sec=
tion about not making assumptions about the client and having a protocol =
=E2=80=9Callowing for =E2=80=A6 Approval of AS attestation to identifiers a=
nd other identity claims=E2=80=9D. To me, this does not say that the protoc=
ol should have room for more advanced identity stuff, not that GNAP should =
specify how it=E2=80=99s requested or returned.

Th=
ere are use cases for getting signed assertions back from the AS as well, a=
nd so the protocol should allow for that. While assertions can often contai=
n non-identifier claims, it=E2=80=99s not up to GNAP to define what those c=
laims are, how they=E2=80=99re requested, or how they=E2=80=99re returned. =
There are also lots of valid use cases for the client requesting a specific=
 set of non-identifier claims about the user. The question is, how much of =
that detail should we be solving directly here in GNAP? I think it=E2=80=99=
s pretty clear that the answer is =E2=80=9Cnot much at all=E2=80=9D.
<=
div>
My original XYZ proposal didn=E2=80=99t have any identit=
y information in it, much like OAuth 2. After talking with Aaron and a few =
others, I was convinced that we could have a very small delta to let the cl=
ient know who the user is. When writing the charter text, that=E2=80=99s wh=
at I originally had in mind by the =E2=80=9Cidentity=E2=80=9D language thro=
ughout. Several people spoke up and said that they would like space left to=
 return signed assertions as well, and there seemed to be enough support to=
 have that as an option in the charter so it was added. What I did not see =
support for, and in fact saw explicit pushback against, was defining ways t=
o return additional user information in the GNAP response, at least as defi=
ned internally by GNAP. That seems to be what you=E2=80=99re arguing for do=
ing here.

I think there will be room, and need, fo=
r a protocol on top of GNAP to define identity schemas, assertions, session=
 handling, authentication contexts, and identity-based APIs in a standard w=
ay. It=E2=80=99s my understanding that all of this is outside of GNAP=E2=80=
=99s core focus, but that GNAP should keep this kind of work in mind in its=
 design. So that, for instance, we don=E2=80=99t accidentally design a prot=
ocol that prevents an AS from tying both identity information and=C2=A0

I realize that Xauth had non-identifier claims since =
early drafts, and I disagree with their inclusion. I think that the group i=
s going to have to decide how far down this identity road we really want to=
 go with GNAP, and I don=E2=80=99t think that=E2=80=99s an answered questio=
n yet.=C2=A0

=C2=A0=E2=80=94 Justin


On Jul 10, 2020, at 2:33=
 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

=
Justin, your stance is surprising for the following reasons:

=

1) Both XYZ and XAuth use the term claims, rather than identifie=
rs. "A claim is a statement that one subject, such as a person or org=
anization, makes about itself or another subject."[1]. A claim is clea=
rly more than an identifier.

2) XAu=
th has had non-identifier claims=C2=A0in the examples since -01 (name, phot=
o).

3) The charter does not state that ONLY identi=
fiers will be returned, identifiers are one of the examples, as are OIDC ID=
 Tokens, SAML assertions, and Verifiable Credentials. All of these often bi=
nd non-identifiers to one or more identifiers.=C2=A0=C2=A0


Justin's sta=
nce earlier in the discussion:

=

My stance is that we allow the client to ask for a sm=
all set of identifiers about the user, or even just ask to =E2=80=9Cidentif=
y the user=E2=80=9D, and leave everything else to a higher level identity p=
rotocol. I do not think that having an identity and profile query/response =
language at the core of GNAP is a good idea, and it=E2=80=99s certainly not=
 in our charter.

=

On T=
hu, Jul 9, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:
<snip>=C2=A0
I=E2=80=99m sorry that you are surprised by =
my stance, but it hasn=E2=80=99t changed since I helped write the section o=
f the charter that you quoted below. A big reason that I chose that wording=
 was to support this use case but not to go in depth with an identity proto=
col, which I never really wanted us to do. However, it seems as soon as =E2=
=80=9Cidentity=E2=80=9D was brought up previously, people immediately jumpe=
d into talking about a full stack of user attributes and profile informatio=
n. That wasn=E2=80=99t my intent in talking about identity, and I don=E2=80=
=99t think it=E2=80=99s something GNAP ought to do, at least not on its own=
.=C2=A0

I do think there=E2=80=99s room for us to =
provide identifiers alongside the access token, so that=E2=80=99s there. Th=
ere was stated interest in providing signed assertions as well, so I made s=
ure that was enumerated for those who want to do such work. And I think it =
makes sense for us to provide a way to describe what kinds of things I want=
 to get from an access token by defining a general purpose syntax for descr=
ibing those things (notably, as a combination of reference strings and mult=
i-dimensional objects). With these two, we can get most of what we need for=
 a basic login system. Anything beyond that is going to need user profiles,=
 authentication contexts, session control, and a lot of other identity-prot=
ocol stuff that GNAP shouldn=E2=80=99t be focusing on. We should keep it in=
 mind as we build GNAP, but I think that like OIDC all that important extra=
 stuff should be built separately. To me, that=E2=80=99s what not defining =
schemas and formats means.=C2=A0

I don=E2=80=99t s=
ee any conflict with the charter here, and I=E2=80=99m surprised that you d=
o.

3D""=E1=90=A7





--0000000000007a23e005aa1c3fbb--


From nobody Fri Jul 10 13:54: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 AC71F3A097E for ; Fri, 10 Jul 2020 13:54: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 LaguzcgRR1Ii for ; Fri, 10 Jul 2020 13:54:17 -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 A06193A097B for ; Fri, 10 Jul 2020 13:54:16 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id h19so7884852ljg.13 for ; Fri, 10 Jul 2020 13:54:16 -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=tt6KyIMwupfCU0+vDpomwY7K5lnHLUKrXijGvRQO5/8=; b=QrU8fjj2vy5L3Reocp9+i7HJlDHlECwVDwEve3rBngyQW+T/smhQpcUzRi1VMQUOBZ NoGb3R2wGQBdaAoIirsTRfMkZALUm9gkC5ubtUI9Y1bWmpB83VgsfA+gXIe24u4WkqyM k7G+l9FwwEBOXQI7ovsAR6Vowue1glfBxvvp8gH4jON514niD9d6Tz11LtgCZQu6cBAA PKDqdJBxij8IsrnHNHHY8L3wUS3qPNPVTdUygZ7Xq0d0Ps8/q0I/UIkr4RCDf53ogPGk 3Yr8Iiwozlx8QnugQeT0xP3d42jYfFc4DOcCZUCqmK+pj6ha+u+t2VK2EU0y/gk7VTkq RfHQ==
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=tt6KyIMwupfCU0+vDpomwY7K5lnHLUKrXijGvRQO5/8=; b=DDjlu7viQCTe35Q80d8iinPvptkW2DfcfnAzvQE7WD+GWrn9XQ0C93CgFy1FDcoKi3 uA+7iDrFi6xqgVoMuR/cb07EM3v5uKHKo30DghkVADibnF24u+IkLytU4njmCtfduoM1 EW6uNmkOLjiKSy9GFieIwPEuXEdNAFtpSEfMShvEA4qFIx2kN4BODAulYNvJwFocubXu R7507++f45UqI9ncUABpU1vlVz2ZwtCqY+f1BQxeAWkPZ1P1LDD9wGgX5+etzcfKh3Sg FoYAW4UAUmGjgwHbC09TrSj7+NacxqozxE1eJ6UYhwTIelP/4a3TvjOOOwZzI7fs7E1n RPrw==
X-Gm-Message-State: AOAM530ERbyRUKsZMk5yKEOwkG5ePZE3aYutcl1/9dd12x2Zpz0X7JTU KsAUyjgwijFJaudo/ryXdzCAAWNl6N5hzZ07Cn4=
X-Google-Smtp-Source: ABdhPJyy1Oj2fox/QTWjf2cuvu1Mzo5mp/m47sovuluwvc5+thYrIou0FpJ4dMOM2eR+uzMohuXm6Z/UC7wtEEsood0=
X-Received: by 2002:a2e:b70b:: with SMTP id j11mr27602946ljo.142.1594414454165;  Fri, 10 Jul 2020 13:54:14 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>     <69082870-1A99-4912-95EA-D1B7A1C967E5@mit.edu>    <4A77832C-9613-48BD-9CB2-EE3121E44DB0@mit.edu>
In-Reply-To: <4A77832C-9613-48BD-9CB2-EE3121E44DB0@mit.edu>
From: Dick Hardt 
Date: Fri, 10 Jul 2020 13:53:37 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002a56d505aa1c8bbf"
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 10 Jul 2020 20:54:21 -0000

--0000000000002a56d505aa1c8bbf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Now that you are saying that the scope string is short hand for the object,
the polymorphism makes sense. There is only one type in the array, and a
string is shorthand for it. In this thread, you have talked about them
being separate things.

I just reread XYZ-08 section on resources, and there is no mention of
polymorphism, or an example of it. Given your comments that XAuth should
support both scopes and RAR, and that your proposed schema was based on
RAR, that scopes and RAR objects were different things.

Now it is clear that you are proposing that GNAP have a brand new schema
for authorization queries. And on closer inspection of your examples in
XYZ, there is no "type" in the property in the object.

So now I see the choice being:

A) reinvent a new, GNAP specific schema for requesting access to resources
(XYZ)
B) reuse the RAR and OAuth scope schemas (XAuth)

If and when another resource requesting schemas is developed, you propose
that it be a new, top level object. I'm proposing it be a new type in the
authorizations container.

Have I captured this accurately?

/Dick





On Fri, Jul 10, 2020 at 1:09 PM Justin Richer  wrote:

>
>
> On Jul 10, 2020, at 1:39 PM, Dick Hardt  wrote:
>
>
>
> On Thu, Jul 9, 2020 at 5:46 PM Justin Richer  wrote:
>
>>
>>
>> On Jul 9, 2020, at 6:50 PM, Dick Hardt  wrote:
>>
>>
>>
>> On Thu, Jul 9, 2020 at 12:17 PM Justin Richer  wrote:
>>
>>> On Jul 9, 2020, at 2:32 PM, Dick Hardt  wrote:
>>>
>>>
>>> Looks like you missed the point of my code example, as your response is
>>> focussed on the aspects I had in comments, so let me clarify.
>>>
>>>
>>> The point seemed to be about the overall complexity and readability, an=
d
>>> that=E2=80=99s what I responded to.
>>>
>>
>> It was about the complexity and readability -- of those specific lines o=
f
>> code.
>>
>>
>> But it=E2=80=99s not just about those lines, it=E2=80=99s about the cont=
ext that those
>> lines are in and the follow-on code paths that they cause. A lot of what
>> you had =E2=80=9Cin comments=E2=80=9D for the XAuth example would have r=
epeated what was
>> already included in the XYZ example, as I pointed out.
>>
>
> The context between those lines is pretty much the same. Yes, the XAuth
> example would have had to loop over each scope and RAR object, which is n=
ot
> that different than XYZ looping over each item, and the deciding how to
> process each item. My point is that checking the object type to decide wh=
at
> to do is an opaque decision vs checking an explicit type.
>
>
> The context is really not the same though, as you actually  point out
> here, and calling one style of type checking =E2=80=9Copaque=E2=80=9D vs.=
 =E2=80=9Cexplicit=E2=80=9D is
> stylistic and not a helpful comparison. I=E2=80=99m not surprised to find=
 that you
> think the way you did it is easier, especially given the disconnect we ha=
ve
> of what the components of the array represent. I started with some of the
> type-field-based structures in early versions of XYZ and moved away from
> them after having bad experiences with building it. There are still a few
> parts of the XYZ protocol that have that style (the =E2=80=9Cuser=E2=80=
=9D section, for
> example) that I think need to be changed. I think that the data-type base=
d
> style of polymorphism, coupled with using the left-hand-side value of
> object members to indicate type or identifier, is significantly simpler i=
n
> design and implementation.
>
> Instead, I realized that we could get a cleaner protocol and better
> underlying code by dispatching based on the type within the protocol
> itself. I=E2=80=99ve gotten comments from a number of implementers that t=
hey like
> this design aspect, and I really like it myself.
>
>
>
>>
>>
>> I've used JS type polymorphism to provide a cleaner API. For example,
>> making an HTTP request. If I'm good with all the defaults, I can just
>> provide the URI as a string, if I want to change a default, I provide an
>> object and the URI is now a property of the object. Polymorphism allows =
the
>> caller to have a simpler interface when it is a simple operation.
>>
>> Do you have any examples of JSON polymorphism used in other protocols
>> besides in a JWT?
>>
>>
>> Sounds to me like you=E2=80=99re describing exactly the kind of polymorp=
hism that
>> I=E2=80=99m talking about here. Use a string where it makes sense and an=
 object
>> where it makes sense, and there=E2=80=99s no ambiguity in calling the fu=
nction. As
>> you say, it's all about providing a cleaner API for the caller, and maki=
ng
>> things consistent in the model that the caller and provider are using. I=
t
>> takes a little bit of extra effort on the part of the API provider, but
>> that=E2=80=99s where the complexity cost should be paid.
>>
>
> My examples are not the same at all. The caller has a simpler version of
> passing the same object. XYZ is passing two different types, where a stri=
ng
> means one thing, and an object means something else. The string is not a
> shorthand for the object.
>
>
> The string is, semantically, a shorthand for the object. That=E2=80=99s w=
hat I=E2=80=99ve
> been saying from the beginning, and I=E2=80=99ve put into several example=
s so far.
> There are two ways to add rights to an access token resulting from the
> request. So:
>
> {
>   =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cphoto=E2=80=9D ]
> }
>
> Can really be thought of as a shorthand, for example it could expand to
> this:
>
> {
>   =E2=80=9Cresources=E2=80=9D: [
>    {
>      =E2=80=9Cdatatypes=E2=80=9D: [ =E2=80=9Cpohoto=E2=80=9D ],
>      =E2=80=9Cactions=E2=80=9D: [ =E2=80=9Cread=E2=80=9D ],
>      =E2=80=9Clocations=E2=80=9D: [ =E2=80=9Chttps://server/photoapi/=E2=
=80=9C ]
>    }
> }
>
> In this straw man, if the client wants write access to the API, it needs
> to use the object-style request to do so.
>
> It=E2=80=99s up to the AS, or really the API that it=E2=80=99s protecting=
, to figure out
> what that expansion really looks like, and how much of the more complex
> policy to expose. My example of processing only string-based resource
> requests was for the case where the AS only gives the shorthand version,
> and doesn=E2=80=99t allow detailed access into its protection policies. I=
t=E2=80=99s not a
> different kind of request, it=E2=80=99s a shorthand, much like passing an
> identifier in lieu of a key to identify the client software instance maki=
ng
> the call.
>
> But really, the point is that in both cases the string and the object *bo=
th
> represent the same kind of thing*: *a piece of access rights that the
> client is requesting at the AS which gets put into the access token.*
> Thus, having them together in a single array and processing them together
> makes sense to me. If you are thinking of strings and objects as complete=
ly
> different from each other,  you=E2=80=99d expect them to be handled separ=
ately, but
> I don=E2=80=99t think they are actually different because they both repre=
sent a
> view of the same underlying thing.
>
>
>
> In polymorphic APIs, it makes the code cleaner to pass a singular item
> when the API takes an array, or the API takes a string for the common
> property of the object which is the parameter.
>
>
> Yes, those are two examples of why it can be good. There are other reason=
s
> to apply it, like having an array with differently typed items that
> represent the same kind of thing underneath.
>
> Here are some code examples for both:
>
>
> // passing a singular item, a simpler version of foo(['string'])
> foo('string')
> // passing a plurality of the same item
> foo(['string1','string2','string3'])
>
> // implementation
>
> foo =3D ( param ) =3D> {
>     var a =3D []
>     if (typeof param =3D=3D=3D 'string') {
>         a[0] =3D param;
>     } else if (typeof param =3D=3D=3D 'array') {
>         a =3D param;
>     }
>     // process array a
> }
>
>
> // pass a uri as string and accept all defaults, a simpler version of
> bar({uri:'uri'})
> bar('uri')
> // pass an object with uri and method
> bar({uri: 'uri', method: 'POST'})
>
> // implementation
> bar =3D ( param ) =3D> {
>     var p =3D DEFAULT_OBJ;
>     if (typeof param =3D=3D=3D 'string') {
>         p.uri =3D param;
>     } else if (typeof param =3D=3D=3D 'object') {
>         Object.keys(param).forEach( item =3D> {
>             p[item] =3D param[item];
>         });
>     }
>     // process p object
> }
>
>
> In GNAP, we could take a string rather than an array for a scope
> parameter, for example:
>
> "scope": "read"
>
>
> instead of
>
> "scope": ["read"]
>
>
> OIDC uses the latter polymorphism for
>
> {
>   "name": {"essential": true},
>   "photo": null
> }
>
> as being shorthand for
>
> {
>   "name": {"essential": true},
>   "photo": {"essential": false}
> }
>
>
> All of these are great examples of why object-type-based polymorphism is =
a
> good and powerful thing, and that=E2=80=99s the approach I=E2=80=99m sayi=
ng we should use
> within the GNAP protocol. I would argue that the last one isn=E2=80=99t
> polymorphism so much as a default based on a null value (often taken as a
> special class of an =E2=80=9Cobject=E2=80=9D value anyway), but that=E2=
=80=99s splitting hairs.
>
>
>
>>
>>
>>
>>>
>>>
>>> This line (which is determining the type of the item in the array):
>>>
>>> if (typeof item =3D=3D=3D string')
>>>
>>>
>>> is implicitly stating that the item is an oauth scope.
>>>
>>>
>>> No, it is not. It is saying that it is a resource request represented a=
s
>>> a string. One way to represent a resource request as a string is an OAu=
th 2
>>> style scope. And if you=E2=80=99re building up from an existing OAuth 2=
 system,
>>> then you could use a scope there. But that=E2=80=99s not the same as st=
ating =E2=80=9Cthe
>>> item is a scope=E2=80=9D. In my examples, I had been trying to use the =
terminology
>>> that you were using, but I=E2=80=99m afraid that made things more uncle=
ar.
>>>
>>
>> We are comparing how to do it in XYZ vs XAuth -- so to make it apples an=
d
>> apples, the string is a scope, since that is the use case we are looking=
 at.
>>
>>
>> You can use a scope as the string, and if you want to think of all strin=
g
>> values in this request as all being =E2=80=9Cscopes", that=E2=80=99s fin=
e, but only if you
>> can concede that the scope can mean whatever the AS wants. I think that
>> perhaps you=E2=80=99re putting a certain amount of semantic weight to =
=E2=80=9Cscope=E2=80=9D that
>> I=E2=80=99m missing, though.
>>
>
> The string could be a scope, or it could be a claim such as in my "oidc"
> type example. The AS could support both scope and claims, and they could
> have overlapping string values.
>
>
> Both would represent =E2=80=9Cthings that the client wants back in the ac=
cess
> token=E2=80=9D, and therefore the AS would need to differentiate. In that=
 case I
> think it actually makes a lot more sense for the AS to define a more rich
> mechanism to request user information. In XYZ it could look like this:
>
> {
>    =E2=80=9Cresources=E2=80=9D: [
>      {
>         =E2=80=9Ctype=E2=80=9D: =E2=80=9Coidc_userinfo=E2=80=9D,
>         =E2=80=9Cdatatypes=E2=80=9D: [ =E2=80=9Cemail=E2=80=9D, =E2=80=9C=
phone=E2=80=9D, =E2=80=9Caddress=E2=80=9D, =E2=80=9Cprofile.photo" ]
>      }
>    ]
> }
>
> But defining the details of that kind of query is clearly outside the
> scope of GNAP (see below), and I think better suited to an identity
> protocol built on top of GNAP.
>
>
>
>
>>
>>
>>
>>>
>>> Whereas it is explicit in this statement
>>>
>>> if (authorizations.type =3D=3D=3D 'oauth_scope')
>>>
>>>
>>> which I think it easier to understand what is happening (in my opinion
>>> of course).
>>>
>>> XYZ has types, they are just implicit. RAR has explicit types, and that
>>> does not look to be holding back RAR. I don't understand why you think
>>> having explicit types will hold us back.
>>>
>>>
>>> The =E2=80=9Ctype=E2=80=9D in RAR is a name spacing device to allow ext=
ensibility in
>>> different aspects of the request. This is at a lower layer than how the=
y=E2=80=99re
>>> being applied here, and it therefore makes more sense at that layer. It=
=E2=80=99s a
>>> way for a particular API to define the dimensions that it cares about i=
n
>>> its request. It=E2=80=99s not really an even comparison.
>>>
>>
>> And the type in XAuth authorizations is different schemas for making a
>> request. "oauth_scope", "oauth_rar", and now "oidc". I would expect that
>> there may be more in the future, and we have a clear way of adding schem=
as,
>> and for the client and AS to know they are talking the same "language".
>>
>>
>> And I=E2=80=99m saying that additional =E2=80=9Cschemas=E2=80=9D for req=
uesting information
>> should be defined separately from the GNAP schema. We disagree on this
>> topic and we=E2=80=99re repeating ourselves.
>>
>
> The charter is pretty clear that GNAP should not define schemas, so I
> don't know what you mean by the "the GNAP schema"
>
>
>
> That=E2=80=99s not true. The charter is clear that "nor is the group char=
tered to
> develop schemas for user information, profiles, or other identity
> attributes=E2=80=9D, but not that it=E2=80=99s not defining schemas for t=
he other parts of
> the protocol. I=E2=80=99ve been clear on the other thread that we shouldn=
=E2=80=99t be
> defining a user schema, for attachment either to the access token or
> non-identifier items returned directly as plaintext or in assertions.
>
> By my read, we are fully within our charter to define schemas for
> authorization requests and responses, including both coarse and
> fine-grained access. I understand that it=E2=80=99s your stance that we s=
hould
> simply re-use OAuth 2=E2=80=99s =E2=80=9Cscope=E2=80=9D parameter for thi=
s, and I disagree with
> that. My proposed approach is to have a place within the GNAP protocol to
> plug in a =E2=80=9Cscope=E2=80=9D value if you have one, and for the AS t=
o interpret it,
> but not to have that value always be a =E2=80=9Cscope=E2=80=9D.
>
>
>>
>>
>>>
>>> Do you want to let the string and object be anything the AS and RS
>>> decide they could mean?
>>>
>>>
>>> Yes. Just like the AS can decide that an OAuth scope could mean any
>>> number of things.
>>>
>>
>> That was what I was afraid of. While an OAuth scope could mean whatever
>> the AS decides it wants to be, the Client and AS know it is an OAuth sco=
pe.
>>
>>
>> How is that any different? I=E2=80=99m confused as to why you think it=
=E2=80=99s
>> important to call this item a =E2=80=9Cscope=E2=80=9D so that you =E2=80=
=9Cknow what it is=E2=80=9D, but
>> then you=E2=80=99re OK with =E2=80=9Cscope=E2=80=9D meaning literally an=
ything.
>>
>
> A scope string is one of a set of strings defined by the AS.
>
> The AS may use strings to define a different schema, such as which claims
> to return from a userinfo endpoint.
>
>
> Exactly. A scope is a string that represents access to something
> controlled by the AS. The object also represents that same thing, but in
> multiple, more specific dimensions.
>
>  I'm going to separate the my other responses into separate threads as
> they are different topics.
>
> /Dick
>
>>
>> =E1=90=A7
>
>
>
>  - Justin
>

--0000000000002a56d505aa1c8bbf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Now that you are saying that the scope string is short han=
d for the object, the polymorphism makes sense. There is only one type in t=
he array, and a string is shorthand for it. In this thread, you have talked=
 about them being separate things.

I just reread XYZ-08 =
section on resources, and there is no mention of polymorphism, or an exampl=
e of it. Given your comments that XAuth should support both scopes and RAR,=
 and that your proposed schema was based on RAR, that scopes and RAR object=
s were different things.

Now it is clear that you =
are proposing that GNAP have a brand new schema for authorization queries. =
And on closer inspection of your examples in XYZ, there is no "type&qu=
ot; in the property in the object.

So now I see th=
e choice=C2=A0being:=C2=A0

A) reinvent a new, GNAP=
 specific schema for requesting access to resources (XYZ)
B) reus=
e the RAR and OAuth scope schemas (XAuth)

If and w=
hen another resource requesting schemas is developed, you propose that it b=
e a new, top level object. I'm proposing it be a new type in the author=
izations container.

Have I captured this accuratel=
y?

/Dick


<=
br>


On Fri, Jul 10, 2020 at 1:09 PM Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>=
 wrote:

On Jul 10, 2020, at 1:39 PM, Dick =
Hardt <dick.ha=
rdt@gmail.com> wrote:



O=
n Thu, Jul 9, 2020 at 5:46 PM Justin Richer <jricher@mit.edu> wrote:


On Jul 9, 2020, at 6:50 PM, Dick Hardt <dick.hardt@gmail.com> wrote=
:



On Thu, Jul 9, 2020 at 12:17 =
PM Justin Richer <j=
richer@mit.edu> wrote:
On Jul 9, 2020, at 2:32 PM, Dick Hardt <dick.hardt@gmail.com=
> wrote:

Looks like you missed the point of my code ex=
ample, as your response is focussed on the aspects I had in=C2=A0comments, =
so let me clarify.=C2=A0

The point seemed to be about the overall complexity and readability, =
and that=E2=80=99s what I responded to.
=

It was about the complexity and readability -- of those spec=
ific lines of code.

But i=
t=E2=80=99s not just about those lines, it=E2=80=99s about the context that=
 those lines are in and the follow-on code paths that they cause. A lot of =
what you had =E2=80=9Cin comments=E2=80=9D for the XAuth example would have=
 repeated what was already included in the XYZ example, as I pointed out.

The context between those =
lines is pretty much the same. Yes, the XAuth example would have had to loo=
p over each scope and RAR object, which is not that different than XYZ loop=
ing over each item, and the deciding how to process each item. My point is =
that checking the object type to decide what to do is an opaque decision vs=
 checking an explicit type.

The context is really not the same though, as you actually =C2=A0p=
oint out here, and calling one style of type checking =E2=80=9Copaque=E2=80=
=9D vs. =E2=80=9Cexplicit=E2=80=9D is stylistic and not a helpful compariso=
n. I=E2=80=99m not surprised to find that you think the way you did it is e=
asier, especially given the disconnect we have of what the components of th=
e array represent. I started with some of the type-field-based structures i=
n early versions of XYZ and moved away from them after having bad experienc=
es with building it. There are still a few parts of the XYZ protocol that h=
ave that style (the =E2=80=9Cuser=E2=80=9D section, for example) that I thi=
nk need to be changed. I think that the data-type based style of polymorphi=
sm, coupled with using the left-hand-side value of object members to indica=
te type or identifier, is significantly simpler in design and implementatio=
n.

Instead, I realized that we could get a cleaner=
 protocol and better underlying code by dispatching based on the type withi=
n the protocol itself. I=E2=80=99ve gotten comments from a number of implem=
enters that they like this design aspect, and I really like it myself.
=C2=A0


I've used JS type polymor=
phism to provide a cleaner API. For example, making an HTTP request. If I&#=
39;m good with all the defaults, I can just provide the URI as a string, if=
 I want to change a default, I provide an object and the URI is now a prope=
rty of the object. Polymorphism allows the caller to have a simpler interfa=
ce when it is a simple operation.

Do you have any=
=C2=A0examples of JSON polymorphism used in other protocols besides in a JW=
T?

Sounds to me like you=
=E2=80=99re describing exactly the kind of polymorphism that I=E2=80=99m ta=
lking about here. Use a string where it makes sense and an object where it =
makes sense, and there=E2=80=99s no ambiguity in calling the function. As y=
ou say, it's all about providing a cleaner API for the caller, and maki=
ng things consistent in the model that the caller and provider are using. I=
t takes a little bit of extra effort on the part of the API provider, but t=
hat=E2=80=99s where the complexity cost should be paid.

My examples are not the same at all. The cal=
ler has a simpler version of passing the same object. XYZ is passing two di=
fferent types, where a string means one thing, and an object means somethin=
g else. The string is not a shorthand for the object.

The string is, semantically, a shorthand=
 for the object. That=E2=80=99s what I=E2=80=99ve been saying from the begi=
nning, and I=E2=80=99ve put into several examples so far. There are two way=
s to add rights to an access token resulting from the request. So:

{
=C2=A0 =E2=80=9Cresources=E2=80=9D: [ =E2=80=
=9Cphoto=E2=80=9D ]
}

Can really be thou=
ght of as a shorthand, for example it could expand to this:

<=
/div>
{
=C2=A0 =E2=80=9Cresources=E2=80=9D: [
=C2=
=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0=E2=80=9Cdatatypes=E2=80=9D: [ =
=E2=80=9Cpohoto=E2=80=9D ],
=C2=A0 =C2=A0 =C2=A0=E2=80=9Cactions=
=E2=80=9D: [ =E2=80=9Cread=E2=80=9D ],
=C2=A0 =C2=A0 =C2=A0=E2=80=
=9Clocations=E2=80=9D: [ =E2=80=9Chttps://server/photoapi/=E2=80=9C ]
=C2=A0 =C2=
=A0}
}

In this straw man, if the client =
wants write access to the API, it needs to use the object-style request to =
do so.

It=E2=80=99s up to the AS, or really the AP=
I that it=E2=80=99s protecting, to figure out what that expansion really lo=
oks like, and how much of the more complex policy to expose. My example of =
processing only string-based resource requests was for the case where the A=
S only gives the shorthand version, and doesn=E2=80=99t allow detailed acce=
ss into its protection policies. It=E2=80=99s not a different kind of reque=
st, it=E2=80=99s a shorthand, much like passing an identifier in lieu of a =
key to identify the client software instance making the call.
But really, the point is that in both cases the string and the =
object both represent the same kind of thing: a piece of access r=
ights that the client is requesting at the AS which gets put into the acces=
s token. Thus, having them together in a single array and processing th=
em together makes sense to me. If you are thinking of strings and objects a=
s completely different from each other, =C2=A0you=E2=80=99d expect them to =
be handled separately, but I don=E2=80=99t think they are actually differen=
t because they both represent a view of the same underlying thing.



In polymorph=
ic APIs, it makes the code cleaner to pass a singular item when the API tak=
es an array, or the API takes a string for the common property of the objec=
t which is the parameter. 

Yes, those are two examples of why it can be good. There are other =
reasons to apply it, like having an array with differently typed items that=
 represent the same kind of thing underneath.

Here are some code examples for both:

// passing a singular ite=
m, a simpler version of foo(['string'])
foo('string')
// passing a plurality of the same item
foo(['string1','string2','string3'])<=
/div>

// implementation
foo =3D ( param ) =3D> {
=C2=A0 =C2=A0 var a =3D []
=C2=A0 =C2=A0 if (typeof param =3D=3D=3D 'string') {
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 a[0] =3D =
param;
=C2=A0 =C2=A0 } else if (=
typeof param =3D=3D=3D 'array') {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a =3D param;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 // process array a
<=
div>}


// pa=
ss a uri as string and accept all defaults, a simpler version of bar({uri:&=
#39;uri'})
bar('uri'=
)
// pass an object with uri and=
 method
bar({uri: 'uri',=
 method: 'POST'})

// implementation
bar =3D ( param ) =3D> {
=C2=A0 =C2=A0 var p =3D DEFAULT_OBJ;
=C2=A0 =C2=A0 if (typeof param =3D=3D=3D '=
string') {
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 p.uri =3D param;
=C2=
=A0 =C2=A0 } else if (typeof param =3D=3D=3D 'object') {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Object.keys(pa=
ram).forEach( item =3D> {
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 p[item] =3D param[item];
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 });
=

=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 // process p object
}

In GNAP, we could take a string rather than an array for a =
scope parameter, for example:

"scope": "read"

instead of=C2=A0

"scope": ["read"]<=
/div>

OIDC=
 uses the latter polymorphism for=C2=A0

{=C2=A0
=C2=A0 "name": {"essential": true},
=
=C2=A0 "photo": null
}

as bein=
g shorthand for=C2=A0

{=C2=A0
=C2=A0 &qu=
ot;name": {"essential": true},
=C2=A0 "photo&=
quot;: {"essential": false}
}


All of these are great exampl=
es of why object-type-based polymorphism is a good and powerful thing, and =
that=E2=80=99s the approach I=E2=80=99m saying we should use within the GNA=
P protocol. I would argue that the last one isn=E2=80=99t polymorphism so m=
uch as a default based on a null value (often taken as a special class of a=
n =E2=80=9Cobject=E2=80=9D value anyway), but that=E2=80=99s splitting hair=
s.

=C2=A0

=C2=A0


This line (which is determining=C2=A0the type of the item in the array):=


if (typeof item =3D=3D=3D strin=
g')

is imp=
licitly stating=C2=A0that the item is an oauth scope.=C2=A0

No, it is not. It is =
saying that it is a resource request represented as a string. One way to re=
present a resource request as a string is an OAuth 2 style scope. And if yo=
u=E2=80=99re building up from an existing OAuth 2 system, then you could us=
e a scope there. But that=E2=80=99s not the same as stating =E2=80=9Cthe it=
em is a scope=E2=80=9D. In my examples, I had been trying to use the termin=
ology that you were using, but I=E2=80=99m afraid that made things more unc=
lear.

We are comparing ho=
w to do it in XYZ vs XAuth -- so to make it apples and apples, the string i=
s a scope, since that is the use case we are looking at.
<=
/blockquote>

You can use a scope as the string, and if y=
ou want to think of all string values in this request as all being =E2=80=
=9Cscopes", that=E2=80=99s fine, but only if you can concede that the =
scope can mean whatever the AS wants. I think that perhaps you=E2=80=99re p=
utting a certain amount of semantic weight to =E2=80=9Cscope=E2=80=9D that =
I=E2=80=99m missing, though.

<=
div>The string could be a scope, or it could be a claim such as in my "=
;oidc" type example. The AS could support both scope and claims, and t=
hey could have overlapping string values.=C2=A0

Both would represent =E2=80=9Cthings that the =
client wants back in the access token=E2=80=9D, and therefore the AS would =
need to differentiate. In that case I think it actually makes a lot more se=
nse for the AS to define a more rich mechanism to request user information.=
 In XYZ it could look like this:

{
=C2=
=A0 =C2=A0=E2=80=9Cresources=E2=80=9D: [
=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9Ctype=E2=80=9D: =E2=80=9Coidc_u=
serinfo=E2=80=9D,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdatatypes=
=E2=80=9D: [ =E2=80=9Cemail=E2=80=9D, =E2=80=9Cphone=E2=80=9D, =E2=80=9Cadd=
ress=E2=80=9D, =E2=80=9Cprofile.photo" ]
=C2=A0 =C2=A0 =C2=
=A0}
=C2=A0 =C2=A0]
}

But defi=
ning the details of that kind of query is clearly outside the scope of GNAP=
 (see below), and I think better suited to an identity protocol built on to=
p of GNAP.


=C2=A0

=C2=A0
=


=
Whereas it is explicit in this statement

if (authorizations.type =3D=3D=3D 'oauth_scope')

which I think it easier=
 to understand what is happening (in my opinion of course).

<=
/div>
XYZ has types, they are just implicit. RAR has explicit types, an=
d that does not look to be holding back RAR. I don't understand why you=
 think having explicit types will hold us back.=C2=A0

The =E2=80=9Ctype=E2=80=9D =
in RAR is a name spacing device to allow extensibility in different aspects=
 of the request. This is at a lower layer than how they=E2=80=99re being ap=
plied here, and it therefore makes more sense at that layer. It=E2=80=99s a=
 way for a particular API to define the dimensions that it cares about in i=
ts request. It=E2=80=99s not really an even comparison.

And the type in XAuth authorizations=C2=A0is=
 different schemas for making a request. "oauth_scope", "oau=
th_rar", and now "oidc". I would expect that there may be mo=
re in the future, and we have a clear way of adding schemas, and for the cl=
ient and AS to know they are talking the same "language".

And I=E2=80=99m saying that addi=
tional =E2=80=9Cschemas=E2=80=9D for requesting information should be defin=
ed separately from the GNAP schema. We disagree on this topic and we=E2=80=
=99re repeating ourselves.=C2=A0

The charter is pretty clear that GNAP should not define schemas, so=
 I don't know what you mean by the "the GNAP schema"
=C2=A0

That=E2=80=
=99s not true. The charter is clear that "nor is the group chartered t=
o develop schemas for user information, profiles, or other identity attribu=
tes=E2=80=9D, but not that it=E2=80=99s not defining schemas for the other =
parts of the protocol. I=E2=80=99ve been clear on the other thread that we =
shouldn=E2=80=99t be defining a user schema, for attachment either to the a=
ccess token or non-identifier items returned directly as plaintext or in as=
sertions.=C2=A0

By my read, we are fully within ou=
r charter to define schemas for authorization requests and responses, inclu=
ding both coarse and fine-grained access. I understand that it=E2=80=99s yo=
ur stance that we should simply re-use OAuth 2=E2=80=99s =E2=80=9Cscope=E2=
=80=9D parameter for this, and I disagree with that. My proposed approach i=
s to have a place within the GNAP protocol to plug in a =E2=80=9Cscope=E2=
=80=9D value if you have one, and for the AS to interpret it, but not to ha=
ve that value always be a =E2=80=9Cscope=E2=80=9D.=C2=A0


=
=C2=A0
Do you want to let the string and object be anything the AS a=
nd RS decide they could mean?=C2=A0

Yes. Just like the AS can decide that an OAut=
h scope could mean any number of things.

That was what I was afraid of. While an OAuth scope could m=
ean whatever the AS decides it wants to be, the Client and AS know it is an=
 OAuth scope.

How is that=
 any different? I=E2=80=99m confused as to why you think it=E2=80=99s impor=
tant to call this item a =E2=80=9Cscope=E2=80=9D so that you =E2=80=9Cknow =
what it is=E2=80=9D, but then you=E2=80=99re OK with =E2=80=9Cscope=E2=80=
=9D meaning literally anything.

A scope string is one of a set of strings defined by the AS.

The AS may use strings to define a different schema, such=
 as which claims to return from a userinfo endpoint.


Exactly. A scope is a stri=
ng that represents access to something controlled by the AS. The object als=
o represents that same thing, but in multiple, more specific dimensions.=C2=
=A0

=C2=A0I'm going to separate the my ot=
her responses into separate threads as they are different topics.

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


=C2=A0- Justin


--0000000000002a56d505aa1c8bbf--


From nobody Fri Jul 10 14:00:43 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 53F0B3A097E for ; Fri, 10 Jul 2020 14:00:41 -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 B2P097I6jTmv for ; Fri, 10 Jul 2020 14:00:39 -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 AC6BE3A085B for ; Fri, 10 Jul 2020 14:00:38 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id q7so7978097ljm.1 for ; Fri, 10 Jul 2020 14:00: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=Uct02jPXsnSA7dXHyK71/3drMEtRs6i8/CV2+l+VltQ=; b=l4Xr5HXWcRMINWBKODS302MLs5Tc7ipFVmfXjQZsIxpodE6Tana+81proluM5i5ZBz +frMpFHVpen4eWqGFY+L06yeDt/zMdI27tMVhwPcEVcGunRWX8R3jHZ7cYujFWV4Ujmw Yd2KyFs1zePdxg+lwWT4VyS8xZLo0Ia0kF/6sPlBZo6nlvQeMjF0IM1EpPNW+Ms3+sLh L3290kBb+aOZQuNz1h7ZNaUBwxWofdekZpccrsn1PFO+h/B1/uSZhqBm0vjyoIpxV3gI 1dXwuhMT9O+FjjdWQ0/9+M9Y9pCCCn75L/hEmaz3s3Va62Eo2DH5riJy4IVQIL5QSJo0 B/zg==
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=Uct02jPXsnSA7dXHyK71/3drMEtRs6i8/CV2+l+VltQ=; b=O5yowxJF2hoHYaomnjKUoqQubX6pfjRwAfjZaXB9SqgYyEaH/W9ZQqdoJEzS7XLoFj NxritVQd062tClrlgFpX9xQ5xK/b8awnzdpXFwu0KByQi/h9zuyNOll8fqWoqymzJOOe dR5dEIrr0qoILTu6fG58OER7xhl/P+Mo8g97xnqc4GPlFtoR5HZ+y8ZObYnc6U21Lrku qNyC8hrL3n6ZJXrdPVszFCaxODYXMUI3zjG2J+yOIwTNHYbzT3ZfAo0Qik+q5bM24K15 zjRsu7QZ6Tv8DpCvhN9JGUJHQfXSV/fyRrQ2fTANC+zuIAFfJLgOBoP0EENuJEyYqeoL LQ/A==
X-Gm-Message-State: AOAM532MPV/FHumREjp7dkUnbE7Lvg9yYlK+5optrhbaDHBf0k9KLPum 1JZZdxisiE2GT//JkYc41CVDbsXzRi8OCtDkZwA=
X-Google-Smtp-Source: ABdhPJxpgw4Z7dEWLpAKNqB8HbFK6FzFfn2Q09RVgWLQ7ZXr4rjLZGmjwNXQP+7uoT/6LzG6W0HwFJ5xTZCo3ZbSmSo=
X-Received: by 2002:a2e:900a:: with SMTP id h10mr43174055ljg.242.1594414836739;  Fri, 10 Jul 2020 14:00:36 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu>
In-Reply-To: <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu>
From: Dick Hardt 
Date: Fri, 10 Jul 2020 14:00:00 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f7f51c05aa1ca186"
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 10 Jul 2020 21:00:41 -0000

--000000000000f7f51c05aa1ca186
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It looks to me that our different views of what is in scope for GNAP are
the differences below.

Per the subject line, I'm looking at how the client acquires claims about
the user. You don't think that is in scope, and that a different layer will
solve that.

I think we should learn from OIDC being on top of OAuth, and GNAP should be
able return ANY claim, not just identifier claims. There are use cases that
may be difficult to support if we do not have that functionality in scope,
such as some of the ones I list below, and it seems pretty straightforward
to support ANY claim if we are supporting identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09 PM Justin Richer  wrote:

>
>
> On Jul 10, 2020, at 2:15 PM, Dick Hardt  wrote:
>
>
> inline ...
>
> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer  wrote:
>
>> Yes, the core idea is to not have to parse an assertion to get back the
>> core authentication information, which consists of an identifier (iss/su=
b
>> pair in OIDC, but could be a number of things). Sometimes the client is
>> going to want the rest of the identity information, but If the user=E2=
=80=99s
>> logged into the client before, the client has likely cached that info an=
d
>> probably won=E2=80=99t need it, and sending it would be a violation of p=
rivacy
>> principles.. The client would want the info pretty much just in these ca=
ses:
>>
>>  1. The client has never seen the user before.
>>  2. The user=E2=80=99s information has been updated since the last time =
the
>> client saw it.
>>
>
> Agreed
>
>
>>
>> Now for case (1), how would the client know if it wants to request the
>> user=E2=80=99s profile info or not, since it doesn=E2=80=99t know who th=
e user is?
>>
>
> But the client could know who the user is. The client may have used a
> different AS to authenticate the user.
>
>
> In these cases, the client is not going to be requesting identity
> information from the AS to log the user in, so it=E2=80=99s not relevant =
to the use
> case. The client will have an opportunity to push that information to the
> AS.
>
> The User may have self identified to the client. The client may have a
> cookie saying who the user was and the user said that was them. While the
> latter cases are really a strong hint, they are likely right most of the
> time and can lead to a user experience basde on that hint
>
>
> In these cases, the AS might be able to guess if the client has info abou=
t
> the user already, but probably not. And the assumptions fall apart if it=
=E2=80=99s
> in fact a different user that ends up logging in, which is of course
> possible (the hint you gave doesn=E2=80=99t match the identity of the cur=
rent user
> after the AS validates them). This possibility leads to clients always
> asking for everything every time and the server providing everything ever=
y
> time. That=E2=80=99s a pattern I think we should avoid in an ultimate sol=
ution =E2=80=94
> but ultimately, I don=E2=80=99t think that this kind of protocol decision=
 is inside
> of GNAP.
>
>
>
>> And the AS won=E2=80=99t know if client is going to want the profile inf=
o, since
>> the AS won=E2=80=99t know if the client has the user=E2=80=99s info or n=
ot. Sure, the AS
>> might have seen that client and that user combo previously, but it doesn=
=E2=80=99t
>> know if the client needs an update.
>>
>
> The client can share with the AS the user it knows or thinks it is dealin=
g
> with, which could let the AS respond if the information was new. This cou=
ld
> be the case for an AS that is providing claims, but not authentication, a=
nd
> could happen silently. The user would only interact if the user informati=
on
> had changed, and the client wanted the updated information.
>
>
>
> See above.
>
>
>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s info ha=
s been updated or
>> not because it doesn=E2=80=99t know who the user is yet. If the AS can p=
rovide some
>> time of updated stamp to the client, the client can pull the new info wh=
en
>> it needs it.
>>
>
> See above.
>
>
> See above.
>
>
>
>>
>> If you ignore both of these cases and put all the user information inlin=
e
>> with the main request/response, you end up in a situation where the clie=
nt
>> always requests everything and the server always provides everything, si=
nce
>> you can=E2=80=99t be sure you=E2=80=99re not in situation (1) or (2) ahe=
ad of time.
>>
>
> See above. There are a number of other states the client could be in.
>
> For example, the client could be stateless about user information, so it
> knows it is ALWAYS in state 1.
>
>
> A stateless client would need to fetch appropriate user information every
> time, then. But that=E2=80=99s an optimization for a very specific case.
>
>
>
>>
>> This is really what I mean about the two-stage identity protocol.
>>
>
> I know what it is. Per above, GNAP lets us support a wider set of use
> cases. Why limit ourselves to what OIDC supported?
>
>
> We aren=E2=80=99t limiting the protocol, but instead limiting the scope o=
f what we
> define internal to the GNAP protocol. There=E2=80=99s a lot of room for i=
nnovation
> on top of it.
>
>
>
>> In the first stage, you push the bare minimum of what you need to get th=
e
>> user known to the client. In the second stage, the client uses its acces=
s
>> token to call an API to get whatever else it needs to know about the use=
r.
>>
>
> From a privacy perspective in non-enterprise use cases, I think the user
> should give consent to any updated personal information to a client. In
> general, the client should not be able to get the latest information abou=
t
> a user whenever it wants.
>
>
> This is about the rights associated with the access token, then. And an
> access token doesn=E2=80=99t have to keep working if the AS has a policy =
that says
> it won=E2=80=99t. The AS/RS could easily decide that a particular access =
token will
> only return data that hasn=E2=80=99t been changed. Maybe it stops working=
 after the
> data changes, or it just returns old data, or any number of things. This =
is
> for the AS/RS to decide and this is pretty standard interpretation of the
> token, nothing special here because we=E2=80=99re dealing with identity.
>
>  =E2=80=94 Justin
>
>
> /Dick
> =E1=90=A7
>
>
>

--000000000000f7f51c05aa1ca186
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


It looks to me that our different views of what is in scop=
e for GNAP are the differences below.

Per the subject li=
ne, I'm looking at how the client acquires claims about the user. You d=
on't think that is in scope, and that a different layer will solve that=
.

I think we should learn from OIDC being on top o=
f OAuth, and GNAP should be able return ANY claim, not just identifier clai=
ms. There are use cases that may be difficult to support if we do not have =
that functionality in scope, such as some of the ones I list below, and it =
seems pretty straightforward to support ANY claim if we are supporting iden=
tifiers.

/Dick


On Fri, Jul 10,=
 2020 at 1:09 PM Justin Richer <jrich=
er@mit.edu> wrote:


On Jul 10, 2020, at 2:15 PM, Dick Hardt <dick.hardt@gmail.com=
> wrote:


inlin=
e ...=C2=A0

On Thu, Jul 9, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea=
 is to not have to parse an assertion to get back the core authentication i=
nformation, which consists of an identifier (iss/sub pair in OIDC, but coul=
d be a number of things). Sometimes the client is going to want the rest of=
 the identity information, but=C2=A0If the user=E2=80=99s logged into the c=
lient before, the client has likely cached that info and probably won=E2=80=
=99t need it, and sending it would be a violation of privacy principles.. T=
he client would want the info pretty much just in these cases:

=C2=A01. The client has never seen the user before.=C2=A0
=
=C2=A02. The user=E2=80=99s information has been updated since the last tim=
e the client saw it.

Agreed
=C2=A0
<=
div>
Now for case (1), how would the client know if it wants =
to request the user=E2=80=99s profile info or not, since it doesn=E2=80=99t=
 know who the user is? 

But the=
 client could know who the user is. The client may have used a different AS=
 to authenticate the user. 
=

In these cases, the client is not going to be requesting ide=
ntity information from the AS to log the user in, so it=E2=80=99s not relev=
ant to the use case. The client will have an opportunity to push that infor=
mation to the AS.

=

The User may have self identified to t=
he client. The client may have a cookie saying who the user was and the use=
r said that was them. While the latter cases are really a strong hint, they=
 are likely right most of the time and can lead to a user experience basde =
on that hint

=
In these cases, the AS might be able to guess if the client has info about =
the user already, but probably not. And the assumptions fall apart if it=E2=
=80=99s in fact a different user that ends up logging in, which is of cours=
e possible (the hint you gave doesn=E2=80=99t match the identity of the cur=
rent user after the AS validates them). This possibility leads to clients a=
lways asking for everything every time and the server providing everything =
every time. That=E2=80=99s a pattern I think we should avoid in an ultimate=
 solution =E2=80=94 but ultimately, I don=E2=80=99t think that this kind of=
 protocol decision is inside of GNAP.

=C2=A0
And the AS won=E2=80=
=99t know if client is going to want the profile info, since the AS won=E2=
=80=99t know if the client has the user=E2=80=99s info or not. Sure, the AS=
 might have seen that client and that user combo previously, but it doesn=
=E2=80=99t know if the client needs an update.

The client can share with the AS the user it knows or think=
s it is dealing with, which could let the AS respond if the information was=
 new. This could be the case for an AS that is providing claims, but not au=
thentication, and could happen silently. The user would only interact if th=
e user information had changed, and the client wanted the updated informati=
on.
=C2=A0

See above.


And for (2), the client won=E2=80=99t know=
 if the user=E2=80=99s info has been updated or not because it doesn=E2=80=
=99t know who the user is yet. If the AS can provide some time of updated s=
tamp to the client, the client can pull the new info when it needs it.

See above.
<=
/div>

See above.

=C2=A0=


If you ignore both of these cases and put all the user information in=
line with the main request/response, you end up in a situation where the cl=
ient always requests everything and the server always provides everything, =
since you can=E2=80=99t be sure you=E2=80=99re not in situation (1) or (2) =
ahead of time.

See above. There=
 are a number of other states the client could be in.

<=
div>For example, the client could be stateless about user information, so i=
t knows it is ALWAYS in state 1.
=


A stateless client would need to fetch appropriate user=
 information every time, then. But that=E2=80=99s an optimization for a ver=
y specific case.

<=
div>
=C2=A0

This is really what I mean =
about the two-stage identity protocol. 

I know what it is. Per above, GNAP lets us support a wider set of =
use cases. Why limit ourselves to what OIDC supported?

We aren=E2=80=99t limiting the pr=
otocol, but instead limiting the scope of what we define internal to the GN=
AP protocol. There=E2=80=99s a lot of room for innovation on top of it.
=C2=A0
In the first stage, you push the bare minimum of what you need=
 to get the user known to the client. In the second stage, the client uses =
its access token to call an API to get whatever else it needs to know about=
 the user. 

From a privacy pers=
pective in non-enterprise use cases, I think the user should give consent t=
o any updated personal information to a client. In general, the=C2=A0client=
 should not be able to get the latest information about a user whenever it =
wants.

This i=
s about the rights associated with the access token, then. And an access to=
ken doesn=E2=80=99t have to keep working if the AS has a policy that says i=
t won=E2=80=99t. The AS/RS could easily decide that a particular access tok=
en will only return data that hasn=E2=80=99t been changed. Maybe it stops w=
orking after the data changes, or it just returns old data, or any number o=
f things. This is for the AS/RS to decide and this is pretty standard inter=
pretation of the token, nothing special here because we=E2=80=99re dealing =
with identity.

=C2=A0=E2=80=94 Justin

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





--000000000000f7f51c05aa1ca186--


From nobody Fri Jul 10 14:19:43 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 1397D3A09BC for ; Fri, 10 Jul 2020 14:19: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 V2zsLi6mUW_R for ; Fri, 10 Jul 2020 14:19:38 -0700 (PDT)
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 EB7D43A09B9 for ; Fri, 10 Jul 2020 14:19:37 -0700 (PDT)
Received: by mail-il1-x129.google.com with SMTP id s21so6270935ilk.5 for ; Fri, 10 Jul 2020 14:19:37 -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=BBKa/pfFzI1ayCU7hRcfpgS4cD5NlVqEbaMibM7W1qk=; b=RGL6f9IrdWrhgs7FZE8J030mY13wdrhXSbi4TLoYILgh5f3SB4MDk+gSb0I0JoyIDW lHziW/TYUDZJRtHjGlFYLr50B2LVnCgtbYdFJm3KIMtPcTHMUI8aX38yDxDrAJsl/uaI CxtgvMuCD5krcEQattfLOnIy3Xon/P5ca/tv3PhBrzZjoXPo/5IjzWkaEh6j9IvMYdVO d1VS4jr/6gcItgHhRUO58/jbc1PvuIJmS0BDrJm5KqNXLn7El+nB2g5jvXm6RK5BKHt0 8wuOoo4HrO8RNKAOsCUBAscGRNoLXXpkiarOTqqebmLcIVCj1xRiKxpS/gKTmUtXhKV9 3qWw==
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=BBKa/pfFzI1ayCU7hRcfpgS4cD5NlVqEbaMibM7W1qk=; b=KdIpv9M2TI3fX6B6y9+UxWKj0V9pYCpmMKTLerjnyWkJLYy0SkLzaZDnrWdpk6Au7X AZKGmFG+d4cMHI/g+E7RJ0uD7iR0mMiW+upCyR8ywFXn5NWkGoR8I9CPN/Aki4K5yRYp CjuCRbzy/4uKoEBTo0cPN00j6SIq30g9OHNoSZdmNJjXnNllRBLUQeb5ycVG6xvW5dhA gZbzZWPJK5PedlNJhl1ezj5DYsoz3lZrflp8wsV84rxjzZ2ZQxdImsg4fPxXi1E+R5Uq rFkL3TJUe9ReSa/yXrqjcMOzl5jxRw/5qJJ7RPWQrw977OZsrIKETuqAqS0I9Y9RQdSr U8gQ==
X-Gm-Message-State: AOAM531gQxvZNvHFhKqDrDQOi5WIpdeeAkpeFLldL0uPHDpwfrCzcyGG SwpgCAj4pfF9jvCEC8PoJZX/dux+X8tPvGTq6fjJFg==
X-Google-Smtp-Source: ABdhPJyAUO3JOAowhxd9d3CJNAOGKMAw3GDo2N6G14W9Dtji7t2zLSDfuXa5tHikDoOmc8Z+WBVQV48CDQyN5cnRFJo=
X-Received: by 2002:a05:6e02:682:: with SMTP id o2mr49824504ils.188.1594415977080;  Fri, 10 Jul 2020 14:19:37 -0700 (PDT)
MIME-Version: 1.0
References:  <382b5f57-6825-3537-c66b-fb2c38e5140c@free.fr>
In-Reply-To: <382b5f57-6825-3537-c66b-fb2c38e5140c@free.fr>
From: Fabien Imbault 
Date: Fri, 10 Jul 2020 23:19:09 +0200
Message-ID: 
To: Denis 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f02d9c05aa1ce5e2"
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 10 Jul 2020 21:19:41 -0000

--000000000000f02d9c05aa1ce5e2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

Thanks for your answer.

My comments are embedded in the text, marked with FI.

Fabien


Le ven. 10 juil. 2020 =C3=A0 17:53, Denis  a =C3=A9crit=
 :

> Hi Fabien,
>
> It would have been appreciated that you kept the original message in your
> response. I have copied it again at the end of this email.
>

FI : sorry, not always easy on a mobile. Will make sure that's the case
next time.

>
> Comments are between the lines.
>
> Hi Denis,
>
> I think it's interesting, but also very different to XYZ/XAuth so it
> raises many questions ;-)
> The figure is impossible to read.
>
> Use a PC. Copy and paste and then use the Courier font. On my PC (with th=
e
> clear figure) it was perfect.
>
> So let me try to summarize the suggested approach, with a concrete
> example, to make sure we understand well:
>
> *0. The client authN to the AS (in whatever way is supported)*
> Ex : client is a corporate financing called "finapp". finapp contacts AS0
> for authentication (say an openbanking service).
> User is John Doe, CFO at NeedMoney Inc. (+ other identity claims if
> needed, maybe some verified credential from NeedMoney Holding that John i=
s
> indeed CFO).
>
> *Dear John, *
> *to access to your finapp, please identify yourself through your prefered
> openbanking account.*
> *Thanks*
>
> If I understand you correctly,  finapp is a local application e.g. on you=
r
> smartphone.
>
FI : not necessarily, the client could be a mobile app, a web app, etc.,
making api calls to backend protected services.

> *1. The client contacts a RS in a discovery phase, which includes the
> selection of (at least) an operation, for which the RS returns the requir=
ed
> authZ attributes *
> Ex : finapp needs to use NeedMoney's data to evaluate how much credit it
> can offer.
>
> Op1 : compute the credit rating, from RS1 (this is outsourced to an
> external credit analyst), through the external service's own AS1.
> But to do that, RS needs your historic bank statements.
> Op2 : get your list of banks, RS2 (as registered within finapp),
> through openbanking AS0 and retrieve the bank statements :
> Op3a : get historic data from his main bank, RS2a (say an international
> bank), through openbanking AS0
> Op3b : same from a second bank account, RS2b (say a local bank), through
> openbanking AS0
>
> Why don't you make your very first example a little bit more complicated =
?
> with RS1, RS2a, RS2b, ... AS0, AS1, ...
>
> :-)
>
FI : fair point. But i believe it's important to grasp what it means on a
realistic example, especially as the proposed protocol would be very much
dependant on the way RS calls are made.

>
> The intent of the *first *email was to discuss a *basic *model and to
> place the highlights on the way to capture the *user's consent*
> in an interoperable manner without letting know to any RS or AS the
> choices of the user. This is a fundamental feature of the model.
> In XAuth, the user's consent is not formalized in the protocol : "User
> consent is *often *required at the GS".
>
FI : in the context of xauth, this seems pretty clear I think.

> *2. User consent *
> RS1 aggregates the list of attributes required (from all RS) and sends it
> to finapp.
>
> *Dear John, *
> *To evaluate your credit request, we need the following information: *
> *- your list of bank accounts (retrieved from your finapp account)*
> *- the associated banking statements over the past 12 months (from each
> bank)*
> *- we'll pass that data to the credit agency, which will return your
> credit score *
> *Do you agree ?*
>
> John approves (or not..., maybe he'll agree only for one specific bank),
> via finapp directly
> (I like that, albeit in a more traditional flow, I'm also separating the
> UI from the rest of the protocol of XYZ, and it works too).
>
> As described, the user could simply push to the RS the banking statements
> over the past 12 months (from each bank).
> The user consent is not about : "*Do you agree that*
> * we pass the data to the credit agency, which will return your credit
> score" *since no attributes nor ASs are involved in the question.
>
FI : this is possible of course, but pretty surprising. Today most
implementations are using oauth to delegate the implementation to some
specialized component, while here each RS would be responsible for
authentication. That is not an innocent choice from an implementation and
deployment perspective.

>
> I guess you want the user to get access tokens targeted for RS2x so that
> each bank will accept to disclose his banking statements over the past 12
> months.
>
> The consent is whether the user accepts to get access tokens from some of
> his banks targeted for RS2x for the following operation:
> "Retrieval of the past 12 months banking statements" which corresponds to
> an API for each bank and then to send these access tokens to RS1.
>
> In practice, the client (e.g. using FIDO) will connect transparently to
> each of the appropriate AS from the banks and will get the requested acce=
ss
> tokens
> with a requested validity period of about 5 minutes.
>
FI : yes.

> *3. Requests to the protected resources *
> The client gets the access tokens and uses the services for which access
> was granted.
>
> *Analysis: (maybe I didn't get everything right, if so let me know) *
> The trust model is focused around the relationship between the enduser
> (John) and his application (finapp), which seems fine.
>
> No. The trust model is not making a focus on that specific relationship.
> BTW, no access token is necessarily needed by the user to be able to use
> finapp.
>
FI : maybe, maybe not. As soon as I want to fetch api calls, I need access
tokens.

> =3D> I see some potential issues :
>
> a. it will be really difficult for an end user to understand what AS0 and
> AS1 are, why they're different, and why he needs to authenticate to each =
of
> them.
> How do you enable a federated experience? (especially as there could be
> many)
>
> I fear that you have not fully captured what the user consent is about.
> See the above explanations. In addition, there is no concept of federatio=
n.
>
FI : your notion of consent is very specific to what you have in mind. It
would require a kind of automated system to work.
As for the concept of federation, this is required in practice in you don't
hypothesize a dependancy on FIDO. The Uma2 standard is probably the closest
to some of your ideas and focuses a lot on federation.

> b. deciding what is the main RS (here RS1) to be called by the client
> seems very critical, as it is the one that needs to orchestrate everythin=
g.
> This seems a very hierarchical and imperative model which seems somewhat
> counter intuitive in terms of developer experience (as least
> as it is made today, we clearly don't go into so much details). The call
> hierarchy may quickly become very complex, which may also become
> a problem when separate services evolve.
>
> The client calls the main RS (here RS1). What may happen next is fully
> dependant upon the operation that the user is willing to perform and
> this is unpredictable (since the back end service may change at any point
> of time).
>
FI : OK, but is it good engineering practice to have to deal with the
internals of service calls? The reason why people delegate APIs is
precisely to avoid that complexity. Today with OAuth, and tomorrow with
XYZ/Xauth, the programming model is way simpler. Privacy may be a good
reason to change that, but we need to be very thoughtful about that.

> c. RS1 gets all the information required to access all sub-resources, and
> therefore gets also a lot of responsibility (and power). But from finapp'=
s
> point of view, it is the one that has the relationship with the user and
> is providing the core value proposition, while RS1 is just an external
> service.
>
>  So is it really a problem ?
>
FI : I think so. If I'm finapp, I don't want to be this dependant on RS1
for a lot of good and bad reasons. What I hope the example conveys is that
there's no reason why RS1 would suddenly become the center of orchestration
for all queries, while all the underlying data is actually elsewhere.
The fact that the proposed protocol mandates this behaviour is surprising
and I don't see why that is.

> d. multi-user (common B2B scenario): John wants to authorize a read acces=
s
> to his finapp account to his external auditor, Ann (who is not a direct
> user
> of finapp herself, but might already be registered by openbanking AS0).
> How do you do that? Does it require the access token itself to be able to
> delegate rights?
>
> The intent of the short description I sent was to describe two simple
> scenarios, so that we could start discussing about them.
> At this point, the intent is not to cover all the scenarios you may dream
> of.
>
FI : fair point. However, as previously discussed, this is a big concern as
we don't know whether you think this is a valid use case or whether this is
out of scope (so far, I understood it was more, if we can't do it with
maximum privacy, then we won't do it; which is a design choice, but
standards are usually about consensus with people that need to deal with
real life problems).

> e. more generally, a threat model would be required, as there are many
> more interactions now.
>
> There are less interactions than in XAuth: there is no protocol between
> ASs and RSs, nor between ROs and ASs.
>
FI : as far as I'm concerned, there are many more interactions than
Oauth/XYZ/Xauth. Your view seems to be that it is simpler because AS are
way less central, but it seems to me that RS are much more complex to
implement correctly.

>
> Before a threat model, a trust model is needed. Do we have a trust model
> for XAuth ?
> Unfortunately not, since the word "trust" is absent in the main body of
> draft-hardt-xauth-protocol-12.
>
FI : sorry but I don't need the word trust to do threat modeling...

> In this model, the trust relationships are as follows:
>
>    - The user trusts its client.
>    - If a user has an account opened with an AS, then he trusts that AS
>    to deliver the requested and genuine attributes into an access token.
>    - A RS may trust one or more ASs for one or more types of attributes
>    *and* for performing a given operation.
>    - A RS may be administered remotely by one or more RO.
>
> *Note*: for authentication, a RS may accept either FIDO or one or more
> types of attributes from one or more ASs.
>
Denis
>
> Cheers,
> Fabien
>
>
> This is a new thread.
>
>
> Preamble: This model is quite different from the XAuth model.
> In particular, a RO has no relationship with any AS and a Client does not
> need to be associated with any AS prior to any access to a RS.
>
> A key point of this model is that the user's consent is handled locally b=
y
> the Client and hence no AS nor RS is handling a man machine interface
> for the user consent. This allows to support locally the user consent for
> multiple ASs while keeping all ASs ignorant about the choices of the user
> made for accessing a particular RS.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *       +--------+                           +------------+        |
> User  |                           |  Resource  |        |
> |                           | Owner (RO) |        +--------+
>                   +------------+            |
> \                              |            |
> \                             |            |
> \                            |            |
> \                           |     +-----------+     +---------------+
> +------------+     |           |---->| Authorization |     |            |
>     |           | (2) |  Server (AS)  |     |            |     |
> |<----|               |     |            |     |  Client   |
> +---------------+     |            |     |
> |-------------------------->|  Resource  |     |   User    |
> (1)             |   Server   |     |  Consent
> |<--------------------------|    (RS)    |     |  element
> |                           |            |     |
> |-------------------------->|            |------>     |
> |           (3)             |            |  (4)     |
> |<--------------------------|            |<------
> +-----------+                           +------------+ *
> The flow of operations is as follows:
>
> The Client (which may have been previously authenticated using FIDO)
> contacts the RS and after some dialogue with the RS selects an operation
> that it wants to perform on the RS (1a). Note that it may also indicate
> directly the operation that it wants to perform on the RS without any pri=
or
> dialogue.
> In return (1b), the RS informs the Client about which attributes are
> needed by the RS for performing the requested operation and from which
> Attributes Servers
> they may be obtained.
>
> This information is specifically marked to indicate that it shall be
> handled by the "User Consent element" from the Client.
> The presentation of that information is up to the man machine interface
> supported by the "User Consent element" from the Client.
>
> The user can see which attributes are requested by the RS for performing
> the requested operation and, if it consents, the Client contacts one or
> more
> appropriate Authorization Servers (2a). The user consent is hence capture=
d
> locally by the Client (i.e. there is no dialogue with any AS nor any RS).
>
> When the Client got the access tokens from these authorization servers
> (2b), it sends all of them in a single request to the RS (3a).
>
> End of the story for a simple access
>
>
> Start of a subsequent story for a delegation case
>
> Let us now suppose that the RS is unable to fulfil the request by its own
> and that it needs to contact another RS. RS1 contacts RS2 (4a) and
> indicates the operation
> that it wants to perform on RS2 (that operation may not be the same as th=
e
> original operation). In return (4b), RS2 informs RS1 about which attribut=
es
> are needed
> by RS2 for performing the requested operation and from which Attributes
> Servers they may be obtained. RS1 forwards that information to the Client=
.
>
> This information is marked to indicate that it shall be handled by the
> "User Consent element" from the Client. The presentation of that
> information is up to the man machine
> interface from the Client. The user can see which attributes are requeste=
d
> by RS2 for performing the new requested operation and, if it consents, th=
e
> Client contacts one or more
> appropriate Authorization Servers. The user consent is hence captured
> locally by the "User Consent element" from the Client. (i.e. there is no
> dialogue with any AS, nor RS1, nor RS2).
>
> When the Client got the access token(s) from the authorization server(s),
> it sends all of them in a single request to RS1. RS1 then forwards the
> additional access token(s) to RS2.
>
>
> Some observations:
>
> The user nor the Client are linked with any particular AS. A user may use
> today an AS of the Bank of America and may change tomorrow to the Bank of
> Missouri.
> As soon as he will be registered with the Bank of Missouri, he will be
> able to get access tokens from the AS of the Bank of Missouri. The AS of
> Bank of America
> has not been able to know where its access tokens have been used. This
> will be the same for AS of the Bank of Missouri. There is no need for any
> direct dialogue
> between any AS and any RS at the time a client is making an access. There
> is no need for any RO to contact any AS.
>
> This model has been constructed following a "Privacy by Design" approach.
> Denis
>

--000000000000f02d9c05aa1ce5e2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis,

Thanks for your answer.=C2=A0

My comments are embedded in the text, marked with FI.=C2=A0
=


Fabien=C2=A0


Le ven. 10 ju=
il. 2020 =C3=A0 17:53, Denis <deni=
s.ietf@free.fr> a =C3=A9crit=C2=A0:

 =20
   =20
 =20
  

    
Hi Fabien,

    


    

    
It would have been appreciated that you
      kept the original message in your response. I have copied it again
      at the end of this email.

FI : sorry, not always easy on a=
 mobile. Will make sure that's the case next time.=C2=A0

    

    


    

    
Comments are between the lines.

    


    

    

     =20
      
Hi Denis,=C2=A0
        


        

        
I think it's interesting, but also very different to
          XYZ/XAuth so it raises many questions ;-)

        
The figure is impossible to read.

      

    

    
Use a PC. Copy and paste and then use the Courier font. On my PC
      (with the clear figure) it was perfect.

    

      

        
So let me try to summarize the suggested approach, with a
          concrete example, to make sure we understand well:

        


        

        
0. The client authN to the AS (in whatever way is
            supported)

        
Ex : client is a corporate=C2=A0financing called "finapp&=
quot;.
          finapp contacts AS0 for authentication (say an openbanking
          service).=C2=A0=C2=A0

        
User is John Doe, CFO at NeedMoney Inc. (+ other identity
          claims if needed, maybe some verified credential from
          NeedMoney Holding that John is indeed CFO).

        


        

        
Dear John,=C2=A0

        
to access to your finapp, please identify yourself
            through your prefered openbanking account.

        
Thanks

      

    

    
If I understand you correctly,=C2=A0 finapp is a local application
      e.g. on your smartphone.
FI : not necessarily, the client could be a mobile app, a web a=
pp, etc., making api calls to backend protected services.=C2=A0
=


    

    

      
1. The client contacts a RS in a discovery
          phase, which includes the selection of (at least) an
          operation, for which the RS returns the required authZ
          attributes=C2=A0
        
Ex : finapp needs to use NeedMoney's data to evaluate how
          much credit it can offer.

        


        

        
Op1 : compute the credit rating, from RS1 (this is
          outsourced to an external credit analyst), through the
          external service's own AS1.

        

        
But to do that, RS needs your historic bank statements.

        
Op2 : get your list of banks, RS2 (as registered within
          finapp), through=C2=A0openbanking AS0 and retrieve the bank
          statements :=C2=A0

        
Op3a : get historic data from his main bank, RS2a (say an
          international bank), through openbanking AS0

        
Op3b : same from a second bank account, RS2b (say a local
          bank), through openbanking AS0

      

    

    
Why don't you make your very first example a little bit more
      complicated ? with RS1, RS2a, RS2b, ... AS0, AS1, ... 

    

    
:-)

      
FI : fair point.=
 But i believe it's important to grasp what it means on a realistic exa=
mple, especially as the proposed protocol would be very much dependant on t=
he way RS calls are made.=C2=A0


      The intent of the first email was to discuss a basic
      model and to place the highlights on the way to capture the us=
er's
        consent 

      in an interoperable manner without letting know to any RS or AS
      the choices of the user. This is a fundamental feature of the
      model.

      In XAuth, the user's consent is not formalized in the protocol :
      "User consent is often required at the GS".
<=
/div>
FI : in the context of xaut=
h, this seems pretty clear I think.=C2=A0

    

    

      

        
2. User consent=C2=A0

        
RS1 aggregates the list of attributes required (from all
          RS) and sends it to finapp.

      

    

    

      

        
Dear John,=C2=A0

        
To evaluate your credit request, we need the following
            information:=C2=A0

        
- your list of bank accounts (retrieved from your finapp
            account)

        
- the associated banking statements over the past 12
            months (from each bank)

        
- we'll pass that data to the credit agency, which will
            return your credit score=C2=A0

        
Do you agree ?

        


        

        
John approves (or not..., maybe he'll agree only for one
          specific bank), via finapp directly 

          (I like that, albeit in a more traditional flow, I'm also
          separating the UI from the rest of the protocol of XYZ, and it
          works too).

      

    

    
As described, the user could simply push to the RS the banking
      statements over the past 12 months (from each bank).

      The user consent is not about : "Do you agree that  we
        pass the data to the credit agency, which will return your
        credit score"

      since no attributes nor ASs are involved in the question.
FI : this is possible of cours=
e, but pretty surprising. Today most implementations are using oauth to del=
egate the implementation to some specialized component, while here each RS =
would be responsible for authentication. That is not an innocent choice fro=
m an implementation and deployment perspective.=C2=A0


      

    
I guess you want the user to get access tokens targeted for RS2x
      so that each bank will accept to disclose his banking statements
      over the past 12 months.

    
The consent is whether the user accepts to get access tokens from
      some of his banks targeted for RS2x for the following operation: 

      "Retrieval of the past 12 months banking statements" which
      corresponds to an API for each bank and then to send these access
      tokens to RS1.

    
In practice, the client (e.g. using FIDO) will connect
      transparently to each of the appropriate AS from the banks and
      will get the requested access tokens 

      with a requested validity period of about 5 minutes.
FI : yes.=C2=A0
=


    

      

        
3. Requests to the protected resources=C2=A0

        
The client gets the access tokens and uses the services for
          which access was granted.

        


        

        
Analysis: (maybe I didn't get everything right, if so
            let me know)=C2=A0

        
The trust model is focused around the relationship between
          the enduser (John) and his application (finapp), which seems
          fine.

      

    

    
No. The trust model is not making a focus on that specific
      relationship. BTW, no access token is necessarily needed by the
      user to be able to use finapp.
=

FI : maybe, maybe not. As soon as I want to fetch api cal=
ls, I need access tokens.=C2=A0

    

    

      
=3D> I see some potential issues :=C2=A0
        


        

        
a. it will be really difficult for an end user to
          understand what AS0 and AS1 are, why they're different, and
          why he needs to authenticate to each of them. 

          How do you enable a federated experience? (especially as there
          could be many)

      

    

    
I fear that you have not fully captured what the user consent is
      about. See the above explanations. In addition, there is no
      concept of federation. 
FI : your notion of consent is very specific to what you have in=
 mind. It would require a kind of automated system to work.=C2=A0
As for the concept of federation, this is required in practic=
e in you don't hypothesize a dependancy on FIDO. The Uma2 standard is p=
robably the closest to some of your ideas and focuses a lot on federation.=
=C2=A0

    

    

      

        
b. deciding what is the main RS (here RS1) to be called by
          the client seems very critical, as it is the one that needs to
          orchestrate everything. 

          This seems a very hierarchical and imperative model which
          seems somewhat counter intuitive in terms of developer
          experience (as least 

          as it is made today, we clearly don't go into so much
          details). The call hierarchy may quickly become very complex,
          which may also become 

          a problem when separate services evolve.

      

    

    
The client calls the main RS (here RS1). What may happen next is
      fully dependant upon the operation that the user is willing to
      perform and 

      this is unpredictable (since the back end service may change at
      any point of time).
FI : OK, but is it good engineering practice to have to deal with the in=
ternals of service calls? The reason why people delegate APIs is precisely =
to avoid that complexity. Today with OAuth, and tomorrow with XYZ/Xauth, th=
e programming model is way simpler. Privacy may be a good reason to change =
that, but we need to be very thoughtful about that.=C2=A0

    

      

        
c. RS1 gets all the information required to access all
          sub-resources, and therefore gets also a lot of responsibility
          (and power). But from finapp's 

          point of view, it is the one that has the relationship with
          the user and is providing the core value proposition, while
          RS1 is just an external service.

      

    

    
=C2=A0So is it really a problem ? 
<=
/div>
FI : I think so. If I'm finapp, I don't want=
 to be this dependant on RS1 for a lot of good and bad reasons. What I hope=
 the example conveys is that there's no reason why RS1 would suddenly b=
ecome the center of orchestration for all queries, while all the underlying=
 data is actually elsewhere.=C2=A0
The fact that the=
 proposed protocol mandates this behaviour is surprising and I don't se=
e why that is.=C2=A0

    

    

      

        
d. multi-user (common B2B scenario): John wants to
          authorize a read access to his finapp account to his external
          auditor, Ann (who is not a direct user 

          of finapp herself, but might already be registered by
          openbanking AS0). How do you do that? Does it require the
          access token itself to be able to delegate rights?

      

    

    
The intent of the short description I sent was to describe two
      simple scenarios, so that we could start discussing about them.

      At this point, the intent is not to cover all the scenarios you
      may dream of.
FI =
: fair point. However, as previously discussed, this is a big concern as we=
 don't know whether you think this is a valid use case or whether this =
is out of scope (so far, I understood it was more, if we can't do it wi=
th maximum privacy, then we won't do it; which is a design choice, but =
standards are usually about consensus with people that need to deal with re=
al life problems).=C2=A0
=


    

      

        
e. more generally, a threat model would be required, as
          there are many more interactions now.

      

    

    
There are less interactions than in XAuth: there is no protocol
      between ASs and RSs, nor between ROs and ASs.
FI : as far as I'm concerned, there ar=
e many more interactions than Oauth/XYZ/Xauth. Your view seems to be that i=
t is simpler because AS are way less central, but it seems to me that RS ar=
e much more complex to implement correctly.=C2=A0

      

      Before a threat model, a trust model is needed. Do we have a trust
      model for XAuth ? 

      Unfortunately not, since the word "trust" is absent in the =
main
      body of draft-hardt-xauth-protocol-12.
FI : sorry but I don't need the word trust to do =
threat modeling...=C2=A0
=


    
In this model, the trust relationships are as follows:

    
    
      
  • The user trusts its client.
    • 
      
  • If a user has an account opened with an AS, then he trusts
        that AS to deliver the requested and genuine attributes into an
        access token.
    • 
      
  • A RS may trust one or more ASs for one or more types of
        attributes and for performing a given operation.
    • 
      
  • A RS may be administered remotely by one or more RO.
    
      
    • 
    

    
Note: for authentication, a RS may accept either FIDO or
      one or more types of attributes from one or more ASs.=C2=A0
=

 

    
Denis

    

      

        
Cheers,=C2=A0

        
Fabien

        

      

      

    

    

      This is a new thread.

    
    

      
 

          Preamble: This model is quite different from the XAuth model.
          

          In particular, a RO has no relationship with any AS and a
          Client does not need to be associated with any AS prior to any
          access to a RS.

          

          A key point of this model is that the user's consent is
          handled locally by the Client and hence no AS nor RS is
          handling a man machine interface 

          for the user consent. This allows to support locally the user
          consent for multiple ASs while keeping all ASs ignorant about
          the choices of the user 

          made for accessing a particular 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=C2=A0 +------------+

              =C2=A0=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0 |

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
              Owner (RO) |

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+<=
span>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0+------------+

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
              |

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |

              =C2=A0=C2=A0=C2=A0 +-----------+=C2=A0 =C2=A0=C2=A0=C2=A0+---------------+=C2=A0=C2=A0=C2=
=A0=C2=A0 +------------+

              =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---->|
              Authorization |=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=


              =C2=A0=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) |=C2=A0 S=
erver (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=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0 |

              =C2=A0=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 Resource=C2=A0 |

              =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 Us=
er=C2=A0=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)=C2=A0=C2=A0=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=C2=A0 |=C2=A0 Consent<=
span>=C2=A0 |<--------------------------|=C2=A0=C2=A0=C2=A0=
 (RS)=C2=A0=C2=A0=C2=A0 |

              =C2=A0=C2=A0=C2=A0 |=C2=A0 element<=
span>=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

              =C2=A0=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 (3)=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=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 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<-----------------------=
---|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 |<------

              =C2=A0=C2=A0=C2=A0 +-----------+=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=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 flow of operations is as follows:

          

          The Client (which may have been previously authenticated using
          FIDO) contacts the RS and after some dialogue with the RS
          selects an operation 

          that it wants to perform on the RS (1a). Note that it may also
          indicate directly the operation that it wants to perform on
          the RS without any prior dialogue. 

          In return (1b), the RS informs the Client about which
          attributes are needed by the RS for performing the requested
          operation and from which Attributes Servers 

          they may be obtained. 

          

          This information is specifically marked to indicate that it
          shall be handled by the "User Consent element" from the
          Client. 

          The presentation of that information is up to the man machine
          interface supported by the "User Consent element" from =
the
          Client. 

          

          The user can see which attributes are requested by the RS for
          performing the requested operation and, if it consents, the
          Client contacts one or more 

          appropriate Authorization Servers (2a). The user consent is
          hence captured locally by the Client (i.e. there is no
          dialogue with any AS nor any RS).

          

          When the Client got the access tokens from these authorization
          servers (2b), it sends all of them in a single request to the
          RS (3a).

          

          End of the story for a simple access

      
 

          Start of a subsequent story for a delegation case

          

          Let us now suppose that the RS is unable to fulfil the request
          by its own and that it needs to contact another RS. RS1
          contacts RS2 (4a=
) and indicates the operation 

          that it wants to perform on RS2 (that operation may not be the
          same as the original operation). In return (4b), RS2 informs
          RS1 about which attributes are needed 

          by RS2 for performing the requested operation and from which
          Attributes Servers they may be obtained. RS1 forwards that
          information to the Client. 

          

          This information is marked to indicate that it shall be
          handled by the "User Consent element" from the Client. =
The
          presentation of that information is up to the man machine 

          interface from the Client. The user can see which attributes
          are requested by RS2 for performing the new requested
          operation and, if it consents, the Client contacts one or more
          

          appropriate Authorization Servers. The user consent is hence
          captured locally by the "User Consent element" from the
          Client. (i.e. there is no dialogue with any AS, nor RS1, nor
          RS2). 

          

          When the Client got the access token(s) from the authorization
          server(s), it sends all of them in a single request to RS1.
          RS1 then forwards the additional access token(s) to RS2.

          

          

          Some observations: 

          

          The user nor the Client are linked with any particular AS. A
          user may use today an AS of the Bank of America and may change
          tomorrow to the Bank of Missouri. 

          As soon as he will be registered with the Bank of Missouri, he
          will be able to get access tokens from the AS of the Bank of
          Missouri. The AS of Bank of America 

          has not been able to know where its access tokens have been
          used. This will be the same for AS of the Bank of Missouri.
          There is no need for any direct dialogue 

          between any AS and any RS at the time a client is making an
          access. There is no need for any RO to contact any AS.

      
This model has been constructed following a
          "Privacy by Design" approach.

      Denis

      

  





--000000000000f02d9c05aa1ce5e2--


From nobody Fri Jul 10 18:01: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 5656D3A09BD for ; Fri, 10 Jul 2020 18:01:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 mUq6l4mJyfNn for ; Fri, 10 Jul 2020 18:01:56 -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 4A33D3A09B8 for ; Fri, 10 Jul 2020 18:01:56 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id q7so8417700ljm.1 for ; Fri, 10 Jul 2020 18:01:56 -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=WvSceiRDau3zUkowMcYP7iYxjUn9H8uOosSf8em46cI=; b=KVmZnnLlUNgyUu3t4zB2UFyzavA+uxgCRONxrUc0zUvvHmjyg8PXmfNS2wEd4hmALj /RQ8cLrakidsreFzuHKNALY8IFb1ESIVlcJ713msBMJIxoKNEXBgZNHiUNRPiJn+ACqm mDMKaNK/A3pELCVe4zj9Sjqj4C1tn19hcacfTbkxWKaZjjWUUQT3MmWKgzZs/RGsW9Oa LsPeR7GQvxmlw6UpamL/XtRmidJHZ/hkyT2kBUf37dGFGTgf8tG/nSdmEdYF6uGbNsd5 FOzt9ucVwm8gPPjhD38ZaGrGMvVsgCGH/71/w27LhwUiWLC+gFM/Ax51wrncCWsTyKcj 67fg==
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=WvSceiRDau3zUkowMcYP7iYxjUn9H8uOosSf8em46cI=; b=OjChfbD6xZWETDbalPrQhmNnpa8JHMGzkguf2l3FmA/A+zxj8H03dSnBQs5MVVGgcr 0/dib4ThFpK9XD9YNIRrFH3LdT4vA6hKtDKInT6ro0tVAqjqJj0CyImA1wlsik5R3mGC MS1B0sdYNhNTxmNyoWffpMc9IFCYYeZ0zyXPVHtwUGd68JPaJmFJRtBCuabkpj2uo8a6 UKSgIGqd0ELZMfh8nnbD4+o2yig94r0sZyROYY3xQ6vrTem2A4ifPtOquYYg0ZQ+lPEt STX/FKMSQI/rxksEGd9mrEDF1jFLQgcyl5NYka/oKum56alvoiwap8d6yjeFpZWr1XtV FEQA==
X-Gm-Message-State: AOAM531Op5m5+dVbf3D9QaMVQ8tpXAz4iIfiBTaAhkBUOWOD0s5p+o83 QI0L9Z88S0dCi93STIWpIlpbuUjrnujhrBmd90NBvMDpoxw=
X-Google-Smtp-Source: ABdhPJxOw+UZkDTFPa/MIKEvKa86F3U+2shdEXhckkJH9PvBfYygRdJ1s4dEmrE6JEzTlKFH0DkN5Pg3q7dtlckNZk8=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr36865255ljn.5.1594429313802; Fri, 10 Jul 2020 18:01:53 -0700 (PDT)
MIME-Version: 1.0
From: Dick Hardt 
Date: Fri, 10 Jul 2020 18:01:17 -0700
Message-ID: 
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000de6aa705aa2000a2"
Archived-At: 
Subject: [Txauth] Turning polymorphism up to 11 (P11)
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, 11 Jul 2020 01:01:58 -0000

--000000000000de6aa705aa2000a2
Content-Type: text/plain; charset="UTF-8"

Taking Justin's model of strings being shortened versions of OAuth scopes,
adding in the "type" property from RAR, and defining a default type, we
*could* add a bunch of polymorphism. (I have not implemented the code
below, but it looks doable assuming I have not overloaded a type in the
same context)

/Dick


Let's start with a request for 2 authorizations using OAuth scopes, one for
writing and the other for reading:

(1)
{
    "authorizations": {
        "writer": [
            {
                "type": "oauth_scope",
                "scope": ["create","update","delete"]
            }
        ],
        "reader": [
            {
                "type": "oauth_scope",
                "scope": ["read","list"]
            }
        ]
    }
}

We can ask for just one token with all the same capabilities:
(2)
{
    "authorizations": [
        {
            "type": "oauth_scope",
            "scope": ["create","update","delete"]
        },
        {
            "type": "oauth_scope",
            "scope": ["read","list"]
        }
    ]
}

Of course (2) can be simplified as:
(3)
{
    "authorizations": [
        {
            "type": "oauth_scope",
            "scope": ["create","update","delete","read","list"]
        }
    ]
}

Now let's say that in "oauth_scope", the array of scopes can also be a
space separated string. So the following is equivalent:
(4)
{
    "authorizations": [
        {
            "type": "oauth_scope",
            "scope": "create update delete read list"
        }
    ]
}

Now let's say that the "oauth_scope" type is the default, so we can express
it as:
(5)
{
    "authorizations": ["create","update","delete","read","list"]
}

Or use a space separated string instead of an array:
(6)
{
    "authorizations": "create update delete read list"
}

In summary, (2) - (6) will give the exact same result.

Let's add another authorization type to the request, "customer_information":
(7)
{
    "authorizations": [
        "create update delete read list",
        {
            "type": "customer_information",
            "locations": [
                "https://example.com/customers",
            ],
            "actions": [
                "read"
            ],
            "datatypes": [
                "contacts",
                "photos"
            ]
        }
    ]
}

And the space separated strings can be turned into individual strings and
we have the equivalent request:
(8)
{
    "authorizations": [
        "create",
        "update",
        "delete",
        "read",
        "list",
        {
            "type": "customer_information",
            "locations": [
                "https://example.com/customers",
            ],
            "actions": [
                "read"
            ],
            "datatypes": [
                "contacts",
                "photos"
            ]
        }
    ]
}

Let's go back to our first example, and ask for 3 separate tokens:
(9)
{
    "authorizations": {
        "writer": "create update delete",
        "reader": "read list",
        "customer": [
            {
                "type": "customer_information",
                "locations": [
                    "https://example.com/customers",
                ],
                "actions": [
                    "read"
                ],
                "datatypes": [
                    "contacts",
                    "photos"
                ]
            }
        ]
    }
}

In a multi token request, if there is only one item in the array, we can
shorten (9) to the following:
(10)
{
    "authorizations": {
        "writer": "create update delete",
        "reader": "read list",
        "customer": {
            "type": "customer_information",
            "locations": [
                "https://example.com/customers",
            ],
            "actions": [
                "read"
            ],
            "datatypes": [
                "contacts",
                "photos"
            ]
        }
    }
}

--000000000000de6aa705aa2000a2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Taking Justin's model of strings=
 being shortened versions of OAuth scopes, adding in the "type" p=
roperty from RAR, and defining a default type, we *could* add a bunch of po=
lymorphism. (I have not implemented the code below, but it looks doable ass=
uming I have not overloaded a type in the same context)

/Dick


Let's start with a =
request for 2 authorizations using OAuth scopes, one for writing and the ot=
her for reading:

(1)
{
=C2=A0 =
=C2=A0 "authorizations": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
"writer": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {=
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &q=
uot;type": "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": ["create",&quo=
t;update","delete"]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "reader": [
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "type": "oauth_scope",
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": =
["read","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 }
}

We can ask for just one token=
 with all the same capabilities:
(2)
{
=C2=A0=
 =C2=A0 "authorizations": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type&quo=
t;: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 "scope": ["create","update","dele=
te"]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
quot;type": "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "scope": ["read","list"]=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 ]
}

Of course (2) can be simplified as:
=
(3)
{
=C2=A0 =C2=A0 "authorizations": [
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "type": "oauth_scope",
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": ["create&quo=
t;,"update","delete","read","list"]=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 ]
}

Now let's say that in "oauth_scope&qu=
ot;, the array of scopes can also be a space separated string. So the follo=
wing is equivalent:
(4)
{
=C2=A0 =C2=A0 "=
;authorizations": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type": "oau=
th_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "s=
cope": "create update delete read list"
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 ]
}

Now let's say that the "oauth_scope" type is the defa=
ult, so we can express it as:
(5)
{
=C2=A0 =
=C2=A0 "authorizations": ["create","update",&=
quot;delete","read","list"]
}
=

Or use a space separated string instead of an array:
(6)
{
=C2=A0 =C2=A0 "authorizations": &quo=
t;create update delete read list"
}

In summary, (2) - (6) will give the exact same result.

Let's add another authorization type to the request, "custom=
er_information":
(7)
{
=C2=A0 =C2=A0 &qu=
ot;authorizations": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "crea=
te update delete read list",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type": "=
customer_information",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 "locations": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "ht=
tps://example.com/customers",
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &q=
uot;actions": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "read"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "dataty=
pes": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "contacts",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "photos"
=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 the space separated strin=
gs can be turned into individual strings and we have the equivalent request=
:
(8)
{
=C2=A0 =C2=A0 "authorizations&qu=
ot;: [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "create",
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "update",
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 "delete",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
read",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "list",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 "type": "customer_information",
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "locations": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "https://example.com/customers",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "actions": [
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "read"
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "datatypes": [
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "contacts",
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "photos"
=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>Let's go back to our first example, and ask for 3 separate tokens:<=
/div>
(9)
{
=C2=A0 =C2=A0 "authorizations"=
;: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "writer": "create=
 update delete",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "reader&qu=
ot;: "read list",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "cus=
tomer": [
=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 "type"=
;: "customer_information",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "locations": [
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "https://example.com/customers",=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "actions&=
quot;: [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "read"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "datatypes": [
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "contacts",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 "photos"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 ]
=C2=A0 =C2=A0 =C2=A0 =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 a multi token request, if the=
re is only one item in the array, we can shorten (9) to the following:
(10)
{
=C2=A0 =C2=A0 "authorizations": =
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "writer": "create up=
date delete",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "reader"=
: "read list",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "custom=
er": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type&=
quot;: "customer_information",
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "locations": [
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "https://example.com/customers",
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 "actions": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 "read"
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &q=
uot;datatypes": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "contacts",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "photos"
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }=C2=A0 =
=C2=A0=C2=A0
=C2=A0 =C2=A0 }
}


--000000000000de6aa705aa2000a2--


From nobody Sat Jul 11 10:05: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 C19BE3A1106 for ; Sat, 11 Jul 2020 10:04:58 -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 BGoR74EwS4gY for ; Sat, 11 Jul 2020 10:04:56 -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 516453A0F06 for ; Sat, 11 Jul 2020 10:04:56 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id q5so8992639wru.6 for ; Sat, 11 Jul 2020 10:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google;  h=mime-version:from:date:message-id:subject:to; bh=frcmXX+jeJ+m82OIVFYggTDUCmans7XNvzAkeBup0Vc=; b=W8AZDlDVC8gmC0ooOqA0VkZpfOkO/CecryldhQ1fS1bcW+oXXxmohWDk0aiX2aG+0p Tg101bQkZqUxR/hC9rXqm2J6BYRZB8bo5w1hUFrakVGRAAlZF9dXTIDZuhfWtU9k2w3N xgE0lTxvKN8CkLFZGiFNhyurMUbIT7Pmxsac0=
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=frcmXX+jeJ+m82OIVFYggTDUCmans7XNvzAkeBup0Vc=; b=VABbB+xg9lJx7q1b/XeFT2ZZXgN9jO4y+T44NviH6eurglCzsNmqiR8ye7JJnTH5M1 v5TSRH7DOVZ/lcnsyjHdP08ag5sArvCCIQQgYjU/ZNzM4wkenH4OT8VfowxT3pRoJ8Py oUspNwdeFfF+/LVva0xN6vpGAnj28VofsJLFYB4n1KV/KjrVuhpAjpfuYX7lZPLtZoIe 1xrzfOb2jH3KCi92tHSQp2tfx1LFDiaW/9nlPxqhT+KIfL0tQgdQp5xB4d90xBNZ6dZz N5GCbUfrCxoCtqNBuSzrwaH0y4FdcBOxUOOqNb9TcI3FtrG3yiaCO8vs1lN6BarfDtFU awcw==
X-Gm-Message-State: AOAM532C3FluQqqOmUjEeC4uA9RxVjR5N8jwZ7/ZANmy5jfksYGLDgMn Dyl87RjAttfXDj+9DJUo5s0oxNw62ktbBO1EVFIQUVkRhmE=
X-Google-Smtp-Source: ABdhPJzmB9AVZw2Qn77pds6RiAJG4P3A5e0WUwgT2Dp9mriugTh1NC70rTmuVoQq15GXIA6qHiKN6zePqODLk0BJCnQ=
X-Received: by 2002:adf:fd8b:: with SMTP id d11mr79609952wrr.371.1594487093094;  Sat, 11 Jul 2020 10:04:53 -0700 (PDT)
MIME-Version: 1.0
From: Francis Pouatcha 
Date: Sat, 11 Jul 2020 13:04:42 -0400
Message-ID: 
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c8828d05aa2d741b"
Archived-At: 
Subject: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 11 Jul 2020 17:04:59 -0000

--000000000000c8828d05aa2d741b
Content-Type: text/plain; charset="UTF-8"

Some points raised here might match what I wrote before after reviewing the
last draft of XYZ.

1. Dictionary
I do like sections 1.x dealing with terms but this is kept too short. I
have noticed that most of the discussion conducted on the list results from
different understanding of terms used.

2. Abstract Protocol Flow

I am missing an abstract protocol flow like the one defined in
https://tools.ietf.org/html/rfc6749#section-1.2.

3. Parties
a) graphical illustration (#section-1.1)
I do like the graphical illustration in #section-1.1. The main difference
to the picture in https://tools.ietf.org/html/rfc6749#section-1.2 is the
clear separation between the "User" and the "Resource Owner" (RO). To help
transition the understanding of current oAuth2 implementers, it is
essential to illustrate and highlight the rationale behind this design.

b) Dynamic Client (#section-1.1)
I would like to mention that the dynamic client can present a certificate
issued by some authorities known to the GS. This is the case of QSeal
certificates designed by European eiDas.

c) Grant Server (GS)
If the GS is a SIOP running on the user device, how does it influence the
protocol design?

4. Interaction Modes (Protocol Flows)
And mentioned in my review of the XYZ protocol, I am missing a grouping of
interaction models. We need an abstraction layer in which we define groups
of flows based on key interaction between parties. I am expecting at least:

- "redirect" Interaction
here the GS instructs the Client to redirect the RO/User to the given
interaction
URL. This is well covered in #section-2.1. But for transparency this
picture must also display the "User". Shall the redirect interaction
presume that the "User" and the "Ro" are represented by the same party,
then it is worth mentioning this. In this case we can draw a single box to
represent both.

- "decoupled" Interaction
This interaction model is currently represented by the "user_code"
Interaction (#section-2.2) and the "indirect" Interaction (#section-2.3 and
#section-5.2). Both of these are forms of "decoupled" Interactions. Main
characteristic of a decoupled interaction shall be that the device used by
the RO to interact with the GS shall be separated from the. device used by
the "User" to interact with the "Client".

- "embedded" Interaction
With the evolving of smart end user devices that can keep private keys,
perform cryptographic operations, it is essential to include the "embedded"
Interaction in which RO/User device send authorization grant to "Client"
that in turns takes it to the GS in exchange of the authorization token. In
XYZ I found this hidden behind the didcom interaction.
The "embedded" interaction shall open room for different types of
synchronous transaction authorization requests in which the "RO/User" gives
a verifiable assertion (inkl. proof of possession) to the "Client" for use
at the GS in exchange for the seeked access token.

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--000000000000c8828d05aa2d741b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Some points raised here =
might match what I wrote before after reviewing the last draft of XYZ.=C2=
=A0

1. Dictionary
I do like sections 1.x deali=
ng with terms but this is kept too short. I have noticed that most of the d=
iscussion conducted on the list results from different=C2=A0understanding o=
f terms used.

2. Abstract Protocol Flow







I am missing an abstr=
act protocol flow like the one defined in https://tools.ietf.org/html/rfc6749#section-1.2<=
/a>.

I do like the graphical illustration in #se=
ction-1.1. The main difference to the picture in=C2=A0https://tools.ietf.org/html/rfc6749#=
section-1.2 is the clear separation between=C2=A0the "User" a=
nd the "Resource Owner" (RO). To help transition the understandin=
g of current oAuth2 implementers, it is essential to illustrate and highlig=
ht the rationale behind this design.

b) Dynam=
ic Client (#section-1.1)
I would like to mention that the dynamic client=
 can present a certificate issued by some authorities known to the GS. This=
 is the case of QSeal certificates designed by European eiDas.

c)=C2=A0Grant Server (GS)
If the GS is a SIOP =
running on the user device, how does it influence the protocol design?

4. In=
teraction Modes (Protocol Flows)
And mentioned=C2=A0in my review =
of the XYZ protocol, I am missing a grouping of interaction models. We need=
 an abstraction layer in which we define groups of flows based on key inter=
action between parties. I am expecting at least:

<=
div>- "redirect" Interaction
here the GS instructs the =
Client to redirect the RO/User to the given=C2=A0interaction URL. This is well=C2=A0covere=
d in=C2=A0#section-2.1.=C2=A0But for transparency this picture must also di=
splay the "User". Shall the=C2=A0redirect interaction presume tha=
t the "User" and the "Ro" are represented by the same p=
arty, then it=C2=A0is worth=C2=A0mentioning this. In this case we can draw=
=C2=A0a single box to represent both.

- "deco=
upled" Interaction
This=C2=A0interaction model is currently =
represented by the=C2=A0"user_code" Interaction (#section-2.2) an=
d the=C2=A0"indirect" Interaction (#section-2.3 and #section-5.2)=
. Both of these are forms of "decoupled" Interactions. Main chara=
cteristic of a decoupled interaction shall be that=C2=A0the device used by =
the RO to interact with the GS shall be separated from the. device used by =
the "User" to interact with the "Client".
- "embedded" Interaction
With the evolving =
of smart end user devices that can keep private keys, perform=C2=A0cryptogr=
aphic operations, it is=C2=A0essential=C2=A0to include the "embedded&q=
uot; Interaction in which RO/User device send authorization grant to "=
Client" that in turns takes it to the GS in exchange of the authorizat=
ion token. In XYZ I found this hidden behind=C2=A0the didcom interaction.
The "embedded" interaction shall open room for different=
 types of synchronous transaction authorization requests in which the "=
;RO/User" gives a verifiable assertion (inkl. proof of possession) to =
the "Client" for use at the GS in exchange for the seeked access =
token.
=C2=A0
-- 
=

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



--000000000000c8828d05aa2d741b--


From nobody Sat Jul 11 11:11: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 4AE293A1141 for ; Sat, 11 Jul 2020 11:11:14 -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, MIME_QP_LONG_LINE=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 HiZaoyOz2Rrb for ; Sat, 11 Jul 2020 11:11:12 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 133343A113F for ; Sat, 11 Jul 2020 11:11:12 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id s10so9038403wrw.12 for ; Sat, 11 Jul 2020 11:11:11 -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:content-transfer-encoding; bh=d1VA0VZ9sV8ZeDumtx5C7HmtLRZNgnx+lrB7qQtBa/8=; b=UZLm9Fl9vSYKF4gQ4L1z5bFHIxmvqOeFhF4TXEtiogmrWS8Gz7SJd6dw+TrQ+Tprce OKX9TNiJpHjcX4n0lJ6NJQCJDG3TXXKJGoJXglAMbq3xZN1eCUM1CYs9iwo46cawnT1w +hzWJCUXH1LiAHP/6G7Yquy7y2XJaMV+9NVoH8n9yueW/ZQoNiI6dTvzFC7M/DBfQFxC wje1kcdbX5n+varPL+mRdISAHod4pI3EyoQlASljFJtYTyIuznnOQ4MaGNJdpi9/F3fV 4+wui5lQc02uzTbgfpS99BpKZ8e6wN9zDelq8QCw4TWu6yOA/c8BhGkX9Bpbp7fRZBwG Nc9g==
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 :content-transfer-encoding; bh=d1VA0VZ9sV8ZeDumtx5C7HmtLRZNgnx+lrB7qQtBa/8=; b=qLysWNPnLcJX0ZRBulbAVRqHZvBv5jDtXlquSMe23m7fGFxTGvfa7+BSNVaeOyt4LM TTK6luPAWCJ7uyAz7Vba08oPKjAwxbYKKxDNL6/2LiFt68t3zMXl6x5DVY5WaMZlMf/7 tCYrlwPTSy2e9rLzxvfcV2JRFVZrq+Ejv4aRc4DmFvUtL7T/02meWvgwu1jl5k/morGY mR5krV611gaARbaLu52YA0ZQ+46bv+5mxal8ihdWVDw7ezoLh+hDp8FMypflN/CXB3Kc zylbYRFhuSu9KBNT7hz8mwgRU5HhdfEaJIfqLlNEjf+MAYoJJBfvS4BsNIbbUHkg7Te2 TqIA==
X-Gm-Message-State: AOAM531rQPhf17NjDOyP7H/NsBWvC47IuwP+5q3wvJqmQEwoZY+JEQum rGb45rQM2NSUkAEPHgHjkrg=
X-Google-Smtp-Source: ABdhPJxFUgcbZNLuyyptcWFL70Tdw7dVCk9rcXcJN9m3lwTOSxtJnHTYAYbmI2XqDERARrSbA/GuRQ==
X-Received: by 2002:adf:f2c5:: with SMTP id d5mr74448190wrp.96.1594491070161;  Sat, 11 Jul 2020 11:11:10 -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 v9sm16583326wri.3.2020.07.11.11.11.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Jul 2020 11:11:09 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.38.20061401
Date: Sat, 11 Jul 2020 21:11:08 +0300
From: Yaron Sheffer 
To: Benjamin Kaduk , Dick Hardt 
CC: , Justin Richer 
Message-ID: <45BD1429-11C6-441E-8DCA-45B00010A2BE@gmail.com>
Thread-Topic: [Txauth] JSON Schema?
References:     <20200707053048.GV16335@kduck.mit.edu>
In-Reply-To: <20200707053048.GV16335@kduck.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [Txauth] JSON Schema?
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, 11 Jul 2020 18:11:14 -0000

As far as I can see JSON Schema is the clear winner, from an industry point=
 of view. There's lots of implementations on their web site, although sadly =
with varying support for different versions. It's actually an IETF miss that=
 this technology is not being standardized here yet. Tim is obviously the ex=
pert here, but JSON Schema has the "running code".

The JSON Schema folks tried to bring it into IETF and didn't like the react=
ion they received (though I looked at the mail archive and it was nothing ou=
t of the ordinary). So they took a step back. I talked to them recently and =
tried to have them re-engage, they may be ready to do that now.

Thanks,
	Yaron

=EF=BB=BFOn 7/7/20, 08:31, "Txauth on behalf of Benjamin Kaduk"  wrote:

    On Mon, Jul 06, 2020 at 01:16:27PM -0700, Dick Hardt wrote:
    > Thanks Wayne and Justin.
    >=20
    > I agree that we would not want to make it an implementation requireme=
nt.
    >=20
    > I asked Tim Bray his thoughts (edited the IETF JSON specs, one of XML
    > creators)
    >=20
    > Tim has written a number of blog posts on JSON Schema. TL;DR: he is n=
ot a
    > huge fan.
    >=20
    > He pointed out the IETF JSON Type Definition ID [2]. This looks much
    > simpler and addresses many of the concerns Tim had expressed with JSO=
N
    > Schema. It also has a more recent draft published on the IETF.

    FWIW, draft-ucarion-json-type-definition is in the RFC Editor's queue a=
s a
    document published via the ISE stream, as can be seen at
    https://www.rfc-editor.org/current_queue.php and
    https://datatracker.ietf.org/doc/draft-ucarion-json-type-definition/

    It's only been at the RFC Editor for a week or so, and we're running 10
    weeks minimum to publication, it will not be an RFC for anouther couple
    months at least.

    -Ben

    > Unfortunately there do not seem to be many implementations, and the w=
ebsite
    > [3] is missing the promised docs [4]. The latest ID [5] looks to be d=
erived
    > from CDDL (RFC 8610) [6].
    >=20
    > I reached out to the core JSON Schema people, and they are focussed o=
n
    > making JSON Schema changes to support efforts for the next version of=
 Open
    > API [7]
    >=20
    > My take: I may use Open Schema in my PoC implementation not unlike wh=
at
    > Wayne did, but it does not look like either JSON Schema or JSON Type
    > Definition is ready for the WG to use at this point.
    >=20
    > /Dick
    >=20
    > [1]
    > https://www.google.com/search?as_q=3Djson+schema&hl=3Den&ie=3DUTF-8&btnG=3DGo=
ogle%2BSearch&as_qdr=3Dall&as_occt=3Dany&as_dt=3Di&as_sitesearch=3Dtbray.org
    > 
    >=20
    > [2] https://datatracker.ietf.org/doc/draft-ucarion-json-type-definiti=
on/
    >=20
    > [3] https://jsontypedef.com/
    >=20
    > [4] https://jsontypedef.com/docs/getting-started/overview
    >=20
    > [5] https://tools.ietf.org/html/draft-ucarion-json-type-definition-04
    >=20
    > [6] https://tools.ietf.org/html/rfc8610
    >=20
    > [7] https://github.com/OAI/OpenAPI-Specification
    >=20
    >=20
    > On Mon, Jul 6, 2020 at 12:55 PM Justin Richer  wrote=
:
    >=20
    > >
    > > On Jul 6, 2020, at 3:54 PM, Justin Richer  wrote:
    > >
    > > I think it=E2=80=99s potentially ok for defining the specification and it=
s
    > > boundaries, but it is not ok if it ends up requiring client and AS
    > > developers to use JSON Schema directly to implement anything. In ot=
her
    > > words, you should be a able to still write a bunch of hand-crafted
    > > validation code to make it work, or to use a parser that drops thin=
gs into
    > > structured objects for you (like my Java implementation of XYZ does=
). Much
    > > like my argument against JSONLD, I think anything beyond a JSON par=
ser
    > >
    > >
    > > =E2=80=A6 and generator is too much to ask. (Sorry, hit send too early.)
    > >
    > >
    > > Another aspect that I don=E2=80=99t like about JSON schema is that it mak=
es it
    > > difficult to describe things in terms of polymorphic data types.
    > > Polymorphism in the protocol is an important part of the XYZ propos=
al=E2=80=99s
    > > design, and as a feature it directly addresses a number of the item=
s you
    > > found when doing your XAuth implementation, like parsing OAuth scop=
es and
    > > dealing with the authorization/authorizations mutually-exclusive od=
dness
    > > that you mentioned. I strongly believe that GNAP should make use of=
 a
    > > polymorphic protocol structure for these and other reasons. Polymor=
phism is
    > > a built-in feature of the JSON data model, and it=E2=80=99s also fully po=
ssible to
    > > support under CBOR and other data serialization languages. Even JWT=
 most
    > > famously uses polymorphism for the =E2=80=9Caud=E2=80=9D field, which can be a =
string or an
    > > array of strings depending on context, all with clear semantics. De=
fining
    > > that in JSON schema is not impossible, but it=E2=80=99s not easy.
    > >
    > > So overall, I think JSON schema is probably not a good fit here.
    > >
    > >  =E2=80=94 Justin
    > >
    > > On Jul 6, 2020, at 3:00 PM, Dick Hardt  wrote=
:
    > >
    > > Hey
    > >
    > > Does anyone have experience and/or opinions on JSON Schema [1]?
    > >
    > > When implementing XAuth [2], I wrote a bunch of hand crafted JSON
    > > validation code. JSON schema looks like it could be a great way to =
validate
    > > input, and to create automated tests for output. It may also be a g=
reat way
    > > to document the Grant Response JSON.
    > >
    > > / Dick
    > >
    > > [1] https://json-schema.org/
    > > [2] https://github.com/dickhardt/XAuth-poc
    > >
    > >
    > > --
    > > Txauth mailing 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

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



From nobody Sun Jul 12 12:00: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 43C093A0869 for ; Sun, 12 Jul 2020 12:00:15 -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 MUx6Wld951pX for ; Sun, 12 Jul 2020 12:00:12 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450: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 A365F3A0893 for ; Sun, 12 Jul 2020 12:00:11 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id c11so6513182lfh.8 for ; Sun, 12 Jul 2020 12:00: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=6OYPls3zLqQMWI8Ro4BNxfiBQRBYXhDBH0Ne8BXcC90=; b=iK3aSM2ZsCqazJ75WZR6iOrRIVO9lYZNRNX4vn2CbOs80Ya0oSrl59SvN9jrd3rKwj bVpw3zqrVM1m2Wj0Iq+fkWs9zVDuYopkZDnMAoTZLeJzN329dnHrBP0fW9dBGdKVl5Nv BsdmOS0KWUX+7L8HbJEQcTnZUCoqThD0QASIO9fzB9SE50L+gET/OOtrhXEgW9IOCCpo WNUWa+fNr/OhUqrPi4YY20C/dE3xp9RAykAODB1YxgjZQ4tuEUozd/QvipMKkTA3DAC8 gOnWHBXvFDAcw40AnDr7/wTzscApp7ZEHd5YGJNZq6zkkr8Put55qZqrlPCop1FtcQt4 4Z0w==
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=6OYPls3zLqQMWI8Ro4BNxfiBQRBYXhDBH0Ne8BXcC90=; b=YVKgKxEh8qnSAIUQzzawjuy4FfjeeN6n3zODFnZD4hpLkyDtKhp0DxqHJ/oCUTYWmr Yb+cOmUdq2Hkel8Z7DGWVGjeFB7xAk6Da4EZyZVAXswuBePQK2PxW1sggjrctkd4WN47 pNiTKkJUeVisXqZjbXkrBXYE77dz8m4c/YvWdNQqD9LlnOFiSC7+W54NycyxKzvQS+vU YmCppFKlH39HTijauVt6Oy5haJ94LSUVYqoVQtSHVElu4Gf0RFdnETxAiA98UAf8Ye+R Qv9S56JZ7rXKVJCPDAUPbe2hd2/97QP2HGFk597a9sAVUDr22lGpxEWNQ/Uo6KZZTAR4 T1NA==
X-Gm-Message-State: AOAM532xKeKAhMOi21VIE3BRoDeopdge8jtghkYmZpUwd6WFUEWzCvVq dkiIwLAIQEKyo7bKkseZNKS08nsGRUhHVAqLTRnZDjTv2Cc=
X-Google-Smtp-Source: ABdhPJwGmZkhrf9E3n2OdeSoip8TN2pWO1T6wwi38u2V1+Pq6b5S3QU3Bm/L2HSdx8bqJ4onMZ438GvqZMpLtduM0ho=
X-Received: by 2002:a2e:8316:: with SMTP id a22mr23150942ljh.246.1594580074740;  Sun, 12 Jul 2020 11:54:34 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Sun, 12 Jul 2020 11:53:58 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ebc19905aa431a60"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 12 Jul 2020 19:00:22 -0000

--000000000000ebc19905aa431a60
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Francis, thanks for the review ... questions and comments inserted ...

On Sat, Jul 11, 2020 at 10:05 AM Francis Pouatcha  wrote:

> Some points raised here might match what I wrote before after reviewing
> the last draft of XYZ.
>

I'm assuming you are referring to this post:

https://mailarchive.ietf.org/arch/msg/txauth/v-iH5ID8VaOojx7fGniffrxCQdo/

Correct?


> 1. Dictionary
> I do like sections 1.x dealing with terms but this is kept too short. I
> have noticed that most of the discussion conducted on the list results fr=
om
> different understanding of terms used.
>

Are terms missing, are the definitions too short, or both?
If you provide specific examples I can work on addressing them!


>
> 2. Abstract Protocol Flow
>
> I am missing an abstract protocol flow like the one defined in
> https://tools.ietf.org/html/rfc6749#section-1.2.
>

That's an interesting point. GNAP also has identity claims, so the abstract
flow is somewhat different (there is no Authorization Grant from the RO),
and not all steps always happen. (there may not be steps (E) and (F) with a
Resource Server)

Would you elaborate on what you think would be useful here, that is not in
the specific flows?


>
> 3. Parties
> a) graphical illustration (#section-1.1)
> I do like the graphical illustration in #section-1.1. The main difference
> to the picture in https://tools.ietf.org/html/rfc6749#section-1.2 is the
> clear separation between the "User" and the "Resource Owner" (RO). To hel=
p
> transition the understanding of current oAuth2 implementers, it is
> essential to illustrate and highlight the rationale behind this design.
>

Would a reference to #section-2.3
 in
the RO definition, and more explanation in #section-2-3 on the rationale
address your concern?



>
> b) Dynamic Client (#section-1.1)
> I would like to mention that the dynamic client can present a certificate
> issued by some authorities known to the GS. This is the case of QSeal
> certificates designed by European eiDas.
>

I agree.

If we do mention that, we should specify how the certificate would be
presented and work. We can do that in the core GNAP document, in an GNAP
extension, or reference another specification. I'm not that familiar with
QSeal. Is it specified somewhere?


>
> c) Grant Server (GS)
> If the GS is a SIOP running on the user device, how does it influence the
> protocol design?
>

With mobile apps having URIs bound to specific apps, I think the protocol
would work the same, but I've not worked with SIOPs. Do you have any
concerns?


>
>
> 4. Interaction Modes (Protocol Flows)
> And mentioned in my review of the XYZ protocol, I am missing a grouping o=
f
> interaction models. We need an abstraction layer in which we define group=
s
> of flows based on key interaction between parties. I am expecting at leas=
t:
>
> - "redirect" Interaction
> here the GS instructs the Client to redirect the RO/User to the given int=
eraction
> URL. This is well covered in #section-2.1. But for transparency this
> picture must also display the "User". Shall the redirect interaction
> presume that the "User" and the "Ro" are represented by the same party,
> then it is worth mentioning this. In this case we can draw a single box t=
o
> represent both.
>

Did you mean to say '... the picture must also display the "RO"'?

There could be a separate RO in a more complex flow, but we could define
this flow to represent where the User and RO are the same party.


> - "decoupled" Interaction
> This interaction model is currently represented by the "user_code"
> Interaction (#section-2.2) and the "indirect" Interaction (#section-2.3 a=
nd
> #section-5.2).. Both of these are forms of "decoupled" Interactions. Main
> characteristic of a decoupled interaction shall be that the device used b=
y
> the RO to interact with the GS shall be separated from the. device used b=
y
> the "User" to interact with the "Client".
>

I like the word "decoupled" -- would "redirect" then be named "coupled"? Or
renamed "indirect" to "decoupled"?

While "user_code" and "indirect" are both decoupled, the "indirect" has
different security properties as it uses a link, which an attacker can
trick a user into clicking on wherever a link may be used.

I do agree that "user_code" and "indirect" are both a decoupled
interaction, and calling that out would be useful.



>
> - "embedded" Interaction
> With the evolving of smart end user devices that can keep private keys,
> perform cryptographic operations, it is essential to include the "embedde=
d"
> Interaction in which RO/User device send authorization grant to "Client"
> that in turns takes it to the GS in exchange of the authorization token. =
In
> XYZ I found this hidden behind the didcom interaction.
> The "embedded" interaction shall open room for different types of
> synchronous transaction authorization requests in which the "RO/User" giv=
es
> a verifiable assertion (inkl. proof of possession) to the "Client" for us=
e
> at the GS in exchange for the seeked access token.
>

I have been thinking that the functionality you describe above would be in
the "user" object rather than in the "interaction" object as it is not an
interaction between the GS and the User. IE, the Client presents some
artifact to the GS that establishes the User in the GS context so that a GS
/ User interaction is not needed.

That looks similar to me to what Denis was proposing in

https://mailarchive.ietf.org/arch/msg/txauth/kgTKFHZDRDsXJlwW95Gqv_-LctA/

Does that work, or am I missing something?




>
> --
> 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
>
=E1=90=A7

--000000000000ebc19905aa431a60
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Francis, thanks for the review ... questions and comm=
ents inserted ...=C2=A0

On Sat, Jul 11, 2020 at 10:05 AM Francis Pouatcha &l=
t;fpo=3D40adorsys.de@dmarc.i=
etf.org> wrote:
Some points raise=
d here might match what I wrote before after reviewing the last draft of XY=
Z.=C2=A0

I'm assuming=
 you are referring to this post:
<=
div>
<=
/blockquote>

Are terms missing, are the definitions too =
short, or both?
If you provide specific examples I can work on ad=
dressing them!
=C2=A0


=C2=A0<=
/div>

3. Parties
a)=C2=A0graphical illustration (#section-1.1)
I do like the gra=
phical illustration in #section-1.1. The main difference to the picture in=
=C2=A0https://tools.ietf.org/html/rfc6749#section-1.2 is the clear s=
eparation between=C2=A0the "User" and the "Resource Owner&qu=
ot; (RO). To help transition the understanding of current oAuth2 implemente=
rs, it is essential to illustrate and highlight the rationale behind this d=
esign.

Would =
a reference to #section-2.3 in the RO definition, and more expla=
nation in #section-2-3 on the rationale address your concern?
=C2=A0

<=
div>
b) Dynamic Client (#section-1.1)
I would like to mention that t=
he dynamic client can present a certificate issued by some authorities know=
n to the GS. This is the case of QSeal certificates designed by European ei=
Das.

I agree.=C2=A0

If we do mention that, we should =
specify how the certificate would be presented and work. We can do that in =
the core GNAP document, in an GNAP extension, or reference another specific=
ation. I'm not that familiar with QSeal. Is it specified somewhere?
=C2=A0
=


c)=C2=A0Grant Server (GS)
If the GS is a SIOP ru=
nning on the user device, how does it influence the protocol design?
<=
/div>

With mobile apps ha=
ving URIs bound to specific apps, I think the=C2=A0protocol would work the =
same, but I've not worked with SIOPs. Do you have any concerns?=C2=A0
=C2=A0


4. Interaction Mod=
es (Protocol Flows)
And mentioned=C2=A0in my review of the XYZ pr=
otocol, I am missing a grouping of interaction models. We need an abstracti=
on layer in which we define groups of flows based on key interaction betwee=
n parties. I am expecting at least:

- "r=
edirect" Interaction
here the GS instructs the Client to red=
irect the RO/User to the given=C2=A0interaction URL. This is well=C2=A0covered in=C2=A0#se=
ction-2.1.=C2=A0But for transparency this picture must also display the &qu=
ot;User". Shall the=C2=A0redirect interaction presume that the "U=
ser" and the "Ro" are represented by the same party, then it=
=C2=A0is worth=C2=A0mentioning this. In this case we can draw=C2=A0a single=
 box to represent both.

Did you mean=C2=A0to say '... the picture must also di=
splay the "RO"'?=C2=A0

There could b=
e a separate RO in a more complex flow, but we could define this flow to re=
present where the User and RO are the same party.


- "decoupled" =
Interaction
This=C2=A0interaction model is currently represented =
by the=C2=A0"user_code" Interaction (#section-2.2) and the=C2=A0&=
quot;indirect" Interaction (#section-2.3 and #section-5.2).. Both of t=
hese are forms of "decoupled" Interactions. Main characteristic o=
f a decoupled interaction shall be that=C2=A0the device used by the RO to i=
nteract with the GS shall be separated from the. device used by the "U=
ser" to interact with the "Client".
<=
/div>

I like the word "decoupled=
" -- would "redirect" then be named "coupled"? Or =
renamed "indirect" to "decoupled"?

=

While "user_code" and "indirect" are both decouple=
d, the "indirect" has different security properties as it uses a =
link, which an attacker can trick a user into clicking on wherever a link m=
ay be used.=C2=A0

I do agree that "user_code&=
quot; and "indirect" are both a decoupled interaction, and callin=
g that out would be useful.

=C2=A0
<=
div dir=3D"ltr">

- "embedded" Intera=
ction
With the evolving of smart end user devices that can keep p=
rivate keys, perform=C2=A0cryptographic operations, it is=C2=A0essential=C2=
=A0to include the "embedded" Interaction in which RO/User device =
send authorization grant to "Client" that in turns takes it to th=
e GS in exchange of the authorization token. In XYZ I found this hidden beh=
ind=C2=A0the didcom interaction.
The "embedded" interac=
tion shall open room for different types of synchronous transaction authori=
zation requests in which the "RO/User" gives a verifiable asserti=
on (inkl. proof of possession) to the "Client" for use at the GS =
in exchange for the seeked access token.

I have been thinking that the functionali=
ty you describe above would be in the "user" object rather than i=
n the "interaction" object as it is not an interaction between th=
e GS and the User. IE, the Client presents some artifact to the GS that est=
ablishes the User in the GS context so that a GS / User interaction is not =
needed.

That looks similar=C2=A0to me to what Deni=
s was proposing in=C2=A0


Does that work, or am I missing something?

=


=C2=A0
<=
div>=C2=A0
-- 
Francis=
 Pouatcha
Co-Founder and Technical Lead
adorsys GmbH &a=
mp; Co. KG
=


-- 

Txauth mailing list

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


3D""=
=E1=90=A7


--000000000000ebc19905aa431a60--


From nobody Sun Jul 12 13:47: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 E57733A07F2 for ; Sun, 12 Jul 2020 13:47:53 -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 GE_OeKyYm9Mm for ; Sun, 12 Jul 2020 13:47:51 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 8024B3A07F4 for ; Sun, 12 Jul 2020 13:47:51 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id c25so8079191otf.7 for ; Sun, 12 Jul 2020 13:47: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=UgfvlZMRIhU5eGRS5iaFHedsTuJFwxipiGwQrq262zA=; b=QwEZU+ZMHY6aDD6HfKUs4DgkeTqi/yAu5xgDcsEd0jwK6w85p1x8sKk419x/yMyqli CsPLhZT0uluOJDM3ocZ81c398D7iNu8H/mV9M2W2HrBdVzXfW6IKKZ9jVLq3AqBPaT2A 4inAyFv0ezasHJBNoYwAOKE66G1DIiYSRGY3htJHTd94hTPzCmSz4sJ0ELzCRDkG4BRd heWlLGWv69NJkgPc/gkeDb0pgs9lpdA1FUF1JVZXHNatOaXJSLcA9lnH0niFlWlqgnkZ u9EubtF++hNSAqCxdEU2L48G1c/H5ZvJNjam5mlYKU2ZXEaG5NWGm/D1whXI+3Nb03dY hRmA==
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=UgfvlZMRIhU5eGRS5iaFHedsTuJFwxipiGwQrq262zA=; b=jgzpr5j4qwXhr2EHhrNtpce9QOCG0+iRKtAkuQyz54WNzpZlcRXbacxqtihBVJEyut GyNL/8oW98VTN/ncdl9Kp21mSoXkuze3qun6HHK7FbwFFcj3crSZvUFOrOufG8ukW3qf wLu/TyrvCscMi3AHZGkFD8kNkMbqTp2DcclMCc7cLETnpSqkFC4ADuiNo2hmry24EWfJ a12FVsT2l/2Y5Vh5g5zRmqMb1gDMw2igrOplv2uFZhh9uZevP0DkY43WtzcpCgdP6X0M KGRixVekNP17P94JnkeNq872JKiJetOO8DO+hp0MhdW7S/VTlpY6pkCp8HFb5fv8+v+E NHgQ==
X-Gm-Message-State: AOAM531ZrXenJ1Ycm0RQcTVs5Aq9RUNUU8aOoUX4aj/h5gnh5yGKoRkc d3c8YJL6G/hJSDkbVB71QYeuoCS5HAxT7ci/N/Y=
X-Google-Smtp-Source: ABdhPJxtVnILqnrcg8ckq9pw/sFvW9bPTeU61gAFARRy0lfvZnRoLH/eO3BT+ApRFhV9YU1lLe3BU3TBF0y6Qu56f1I=
X-Received: by 2002:a9d:66ca:: with SMTP id t10mr49305613otm.358.1594586870549;  Sun, 12 Jul 2020 13:47:50 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Tom Jones 
Date: Sun, 12 Jul 2020 13:47:38 -0700
Message-ID: 
To: Dick Hardt 
Cc: Francis Pouatcha , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fb911c05aa44af09"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 12 Jul 2020 20:47:54 -0000

--000000000000fb911c05aa44af09
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Our health care solution is aligned quite well with Francis' design.  WRT
the client to GS assertion i recommend the use of the entity statement from
the OpenID federation spec.

The major issue with SIOP is getting some assertion that the user
device/app is trustworthy.  Kantara is working that problem right now. The
issue there is creation of some sort of "software statement" that could be
attested.

Peace ..tom


On Sun, Jul 12, 2020 at 12:01 PM Dick Hardt  wrote:

> Francis, thanks for the review ... questions and comments inserted ...
>
> On Sat, Jul 11, 2020 at 10:05 AM Francis Pouatcha  40adorsys.de@dmarc.ietf.org> wrote:
>
>> Some points raised here might match what I wrote before after reviewing
>> the last draft of XYZ.
>>
>
> I'm assuming you are referring to this post:
>
> https://mailarchive.ietf.org/arch/msg/txauth/v-iH5ID8VaOojx7fGniffrxCQdo/
>
> Correct?
>
>
>> 1. Dictionary
>> I do like sections 1.x dealing with terms but this is kept too short. I
>> have noticed that most of the discussion conducted on the list results f=
rom
>> different understanding of terms used.
>>
>
> Are terms missing, are the definitions too short, or both?
> If you provide specific examples I can work on addressing them!
>
>
>>
>> 2. Abstract Protocol Flow
>>
>> I am missing an abstract protocol flow like the one defined in
>> https://tools.ietf.org/html/rfc6749#section-1.2.
>>
>
> That's an interesting point. GNAP also has identity claims, so the
> abstract flow is somewhat different (there is no Authorization Grant from
> the RO), and not all steps always happen. (there may not be steps (E) and
> (F) with a Resource Server)
>
> Would you elaborate on what you think would be useful here, that is not i=
n
> the specific flows?
>
>
>>
>> 3. Parties
>> a) graphical illustration (#section-1.1)
>> I do like the graphical illustration in #section-1.1. The main differenc=
e
>> to the picture in https://tools.ietf.org/html/rfc6749#section-1.2 is the
>> clear separation between the "User" and the "Resource Owner" (RO). To he=
lp
>> transition the understanding of current oAuth2 implementers, it is
>> essential to illustrate and highlight the rationale behind this design.
>>
>
> Would a reference to #section-2.3
> 
> in the RO definition, and more explanation in #section-2-3 on the rationa=
le
> address your concern?
>
>
>
>>
>> b) Dynamic Client (#section-1.1)
>> I would like to mention that the dynamic client can present a certificat=
e
>> issued by some authorities known to the GS. This is the case of QSeal
>> certificates designed by European eiDas.
>>
>
> I agree.
>
> If we do mention that, we should specify how the certificate would be
> presented and work. We can do that in the core GNAP document, in an GNAP
> extension, or reference another specification. I'm not that familiar with
> QSeal. Is it specified somewhere?
>
>
>>
>> c) Grant Server (GS)
>> If the GS is a SIOP running on the user device, how does it influence th=
e
>> protocol design?
>>
>
> With mobile apps having URIs bound to specific apps, I think the protocol
> would work the same, but I've not worked with SIOPs. Do you have any
> concerns?
>
>
>>
>>
>> 4. Interaction Modes (Protocol Flows)
>> And mentioned in my review of the XYZ protocol, I am missing a grouping
>> of interaction models. We need an abstraction layer in which we define
>> groups of flows based on key interaction between parties. I am expecting=
 at
>> least:
>>
>> - "redirect" Interaction
>> here the GS instructs the Client to redirect the RO/User to the given in=
teraction
>> URL. This is well covered in #section-2.1. But for transparency this
>> picture must also display the "User". Shall the redirect interaction
>> presume that the "User" and the "Ro" are represented by the same party,
>> then it is worth mentioning this. In this case we can draw a single box =
to
>> represent both.
>>
>
> Did you mean to say '... the picture must also display the "RO"'?
>
> There could be a separate RO in a more complex flow, but we could define
> this flow to represent where the User and RO are the same party.
>
>
>> - "decoupled" Interaction
>> This interaction model is currently represented by the "user_code"
>> Interaction (#section-2.2) and the "indirect" Interaction (#section-2.3 =
and
>> #section-5.2).. Both of these are forms of "decoupled" Interactions. Mai=
n
>> characteristic of a decoupled interaction shall be that the device used =
by
>> the RO to interact with the GS shall be separated from the. device used =
by
>> the "User" to interact with the "Client".
>>
>
> I like the word "decoupled" -- would "redirect" then be named "coupled"?
> Or renamed "indirect" to "decoupled"?
>
> While "user_code" and "indirect" are both decoupled, the "indirect" has
> different security properties as it uses a link, which an attacker can
> trick a user into clicking on wherever a link may be used.
>
> I do agree that "user_code" and "indirect" are both a decoupled
> interaction, and calling that out would be useful.
>
>
>
>>
>> - "embedded" Interaction
>> With the evolving of smart end user devices that can keep private keys,
>> perform cryptographic operations, it is essential to include the "embedd=
ed"
>> Interaction in which RO/User device send authorization grant to "Client"
>> that in turns takes it to the GS in exchange of the authorization token.=
 In
>> XYZ I found this hidden behind the didcom interaction.
>> The "embedded" interaction shall open room for different types of
>> synchronous transaction authorization requests in which the "RO/User" gi=
ves
>> a verifiable assertion (inkl. proof of possession) to the "Client" for u=
se
>> at the GS in exchange for the seeked access token.
>>
>
> I have been thinking that the functionality you describe above would be i=
n
> the "user" object rather than in the "interaction" object as it is not an
> interaction between the GS and the User. IE, the Client presents some
> artifact to the GS that establishes the User in the GS context so that a =
GS
> / User interaction is not needed.
>
> That looks similar to me to what Denis was proposing in
>
> https://mailarchive.ietf.org/arch/msg/txauth/kgTKFHZDRDsXJlwW95Gqv_-LctA/
>
> Does that work, or am I missing something?
>
>
>
>
>>
>> --
>> 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
>>
> =E1=90=A7
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000fb911c05aa44af09
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Our health care solution=C2=A0is aligned quite well with F=
rancis' design.=C2=A0 WRT the client=C2=A0to GS assertion i recommend t=
he use of the entity statement from the OpenID federation spec.

The major issue with SIOP is getting some assertion=C2=A0that the u=
ser device/app is trustworthy.=C2=A0 Kantara is working that problem right =
now. The issue there is creation of some sort of "software statement&q=
uot; that could be attested.

Peace ..tom


On Sun, Jul 12, =
2020 at 12:01 PM Dick Hardt <dic=
k.hardt@gmail.com> wrote:
Francis, thanks for the review ... q=
uestions and comments inserted ...=C2=A0

On Sat, Jul 11, 2020 at 10:05 AM Fr=
ancis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
Some points raised here might match what I wrote before a=
fter reviewing the last draft of XYZ.=C2=A0
<=
div>
I'm assuming you are referring to this post:
<=
div class=3D"gmail_quote">
<=
/blockquote>
Correct?


1. Dictionary
I do =
like sections 1.x dealing with terms but this is kept too short. I have not=
iced that most of the discussion conducted on the list results from differe=
nt=C2=A0understanding of terms used.

Are terms missing, are the definitions too short, or both=
?
If you provide specific examples I can work on addressing them!=

=C2=A0

2. Abs=
tract Protocol Flow







I am missing an abstract protocol flow l=
ike the one defined in https://tools.ietf.org/html/rfc6749#section-1.2.


=C2=A0<=
/div>

3. Parties
a)=C2=A0graphical illustration (#section-1.1)
I do like the gra=
phical illustration in #section-1.1. The main difference to the picture in=
=C2=A0https://tools.ietf.org/html/rfc6749#section-1.2 is the clear s=
eparation between=C2=A0the "User" and the "Resource Owner&qu=
ot; (RO). To help transition the understanding of current oAuth2 implemente=
rs, it is essential to illustrate and highlight the rationale behind this d=
esign.

Would =
a reference to #section-2.3 in the RO definiti=
on, and more explanation in #section-2-3 on the rationale address your conc=
ern?

=C2=A0

b) Dynamic Client (#section-1.1)
I would like=
 to mention that the dynamic client can present a certificate issued by som=
e authorities known to the GS. This is the case of QSeal certificates desig=
ned by European eiDas.
=


I agree.=C2=A0

If we do mentio=
n that, we should specify how the certificate would be presented and work. =
We can do that in the core GNAP document, in an GNAP extension, or referenc=
e another specification. I'm not that familiar with QSeal. Is it specif=
ied somewhere?
=C2=A0

c)=C2=A0Grant Server (GS)
If t=
he GS is a SIOP running on the user device, how does it influence the proto=
col design?

W=
ith mobile apps having URIs bound to specific apps, I think the=C2=A0protoc=
ol would work the same, but I've not worked with SIOPs. Do you have any=
 concerns?=C2=A0
=C2=A0
=

=

=
4. Interaction Modes (Protocol Flows)
And mentioned=C2=A0in my re=
view of the XYZ protocol, I am missing a grouping of interaction models. We=
 need an abstraction layer in which we define groups of flows based on key =
interaction between parties. I am expecting at least:

- "redirect" Interaction
here the GS instructs=
 the Client to redirect the RO/User to the given=C2=A0interaction URL. This is well=C2=A0c=
overed in=C2=A0#section-2.1.=C2=A0But for transparency this picture must al=
so display the "User". Shall the=C2=A0redirect interaction presum=
e that the "User" and the "Ro" are represented by the s=
ame party, then it=C2=A0is worth=C2=A0mentioning this. In this case we can =
draw=C2=A0a single box to represent both.

Did you mean=C2=A0to say '... the pi=
cture must also display the "RO"'?=C2=A0

=

There could be a separate RO in a more complex flow, but we could defi=
ne this flow to represent where the User and RO are the same party.


- &quo=
t;decoupled" Interaction
This=C2=A0interaction model is curr=
ently represented by the=C2=A0"user_code" Interaction (#section-2=
.2) and the=C2=A0"indirect" Interaction (#section-2.3 and #sectio=
n-5.2).. Both of these are forms of "decoupled" Interactions. Mai=
n characteristic of a decoupled interaction shall be that=C2=A0the device u=
sed by the RO to interact with the GS shall be separated from the. device u=
sed by the "User" to interact with the "Client".
<=
/div>

I like the wo=
rd "decoupled" -- would "redirect" then be named "=
coupled"? Or renamed "indirect" to "decoupled"?

While "user_code" and "indirect"=
 are both decoupled, the "indirect" has different security proper=
ties as it uses a link, which an attacker can trick a user into clicking on=
 wherever a link may be used.=C2=A0

I do agree tha=
t "user_code" and "indirect" are both a decoupled inter=
action, and calling that out would be useful.

=C2=
=A0

- "em=
bedded" Interaction
With the evolving of smart end user devi=
ces that can keep private keys, perform=C2=A0cryptographic operations, it i=
s=C2=A0essential=C2=A0to include the "embedded" Interaction in wh=
ich RO/User device send authorization grant to "Client" that in t=
urns takes it to the GS in exchange of the authorization token. In XYZ I fo=
und this hidden behind=C2=A0the didcom interaction.
The "emb=
edded" interaction shall open room for different types of synchronous =
transaction authorization requests in which the "RO/User" gives a=
 verifiable assertion (inkl. proof of possession) to the "Client"=
 for use at the GS in exchange for the seeked access token.

I have been thinking t=
hat the functionality you describe above would be in the "user" o=
bject rather than in the "interaction" object as it is not an int=
eraction between the GS and the User. IE, the Client presents some artifact=
 to the GS that establishes the User in the GS context so that a GS / User =
interaction is not needed.

That looks similar=C2=
=A0to me to what Denis was proposing in=C2=A0


Does that work, or=
 am I missing something?


=C2=A0
=C2=A0
-- 
=

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


-- 

Txauth mailing list

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


3D""=E1=90=A7

-- 

Txauth mailing list

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



--000000000000fb911c05aa44af09--


From nobody Sun Jul 12 17:56: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 DFE0F3A0062 for ; Sun, 12 Jul 2020 17:55: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 gr2VKj7xzl3V for ; Sun, 12 Jul 2020 17:55:58 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450: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 C87903A0044 for ; Sun, 12 Jul 2020 17:55:57 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id t74so7216169lff.2 for ; Sun, 12 Jul 2020 17:55: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;  bh=rnEa/7tYthKI/y5f4/oWMWE+M+ydvc40htHC8TetAck=; b=qFLS5dEoYF0ltHkreYmHqZevGD7KPxVC4U4RWylg+RkP5zhTkV22aCcWdEr7A6O+iZ xCgIOx9IFJWxS3zWM/96SObaV7glirTAoGCjl2W+ET7DuJyNIc3e/RkfD65jYZvsDSXi y2hcK+Fbc9Tm6aVSi7MhMmlHNx5w+7xuooLS5flacT9StuJ7R9UYe09vS6q1tH4VByfj kAQX/dNVFuVApgYlbXcRspmfPIl+duPqF6NPXJzI2FK9oa/271vmQ5x8rcUwsga5cuiW yqHIIwQIIOviufbEuW68CMEDGy3RSuszqL15Ho+Ix/OAf6rVDCO3gWM7atFIbYZIHVEx PatQ==
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; bh=rnEa/7tYthKI/y5f4/oWMWE+M+ydvc40htHC8TetAck=; b=nMBW9x7b9oCVtY8NMe8MepH4U836acxUtcAN8YUxWEchPosoOgMgNfDSstuQfkz2Sy Qi1dhSyDkUA1oKZeTFBGao9c96/MHqCy797T8gXDxHKEK5ikc/2LxeL83XnUevCDHBP8 BmiKCuATozqfqZIOWmiAy5dABrnVK/y+NO+dWy0TWhHLv2miYltpdW21WSMs/GisEu67 yTvO9LP+FRg+ltp6SeyW0COyaf5jh404NCU6VUfKNJDyhcytP1rA3cjjSHjv3M1J9OFT A0Z43jt2/6bNRTwNIbLPdA8RyFyZVb3snIrRNV+TC/kFU6oQ1CcG7Q+Fa6Ot5TItTnm9 q63w==
X-Gm-Message-State: AOAM53325LQeHyA3xiiuRd1Dbq72CHrL4m9QFMbTUAg5yZCLJH/aiMyM gCDaMOyxGyViyt1ZMgqgFpfFlul+MaJUH+7kpIKIsfsa9LE=
X-Google-Smtp-Source: ABdhPJygS+YM7AlmrH3dkbErceHiQcaQvQKmKZkJNzs0h1+i8TPPfmTO1fIqSZBxT0gqJ3+m+Dw6lcYMv8/rkEoOrLc=
X-Received: by 2002:a19:c8a:: with SMTP id 132mr50932528lfm.23.1594601755522;  Sun, 12 Jul 2020 17:55:55 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Sun, 12 Jul 2020 17:55:19 -0700
Message-ID: 
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000323c4b05aa4827ac"
Archived-At: 
Subject: Re: [Txauth] Turning polymorphism up to 11 (P11)
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, 13 Jul 2020 00:56:00 -0000

--000000000000323c4b05aa4827ac
Content-Type: text/plain; charset="UTF-8"

For those not familiar with "turning up to 11"
https://en.wikipedia.org/wiki/Up_to_eleven

A counter argument to all of this polymorphism is that the AS is sending
back the granted authorization. While pushing type detection to the AS to
provide a simpler interface for the Client, it seems counterproductive if
the Client has to do the same. A consistent response from the AS will be
simpler for the Client, but would then also be different then what the
Client originally requested from the GS.

On Fri, Jul 10, 2020 at 6:01 PM Dick Hardt  wrote:

> Taking Justin's model of strings being shortened versions of OAuth scopes,
> adding in the "type" property from RAR, and defining a default type, we
> *could* add a bunch of polymorphism. (I have not implemented the code
> below, but it looks doable assuming I have not overloaded a type in the
> same context)
>
> /Dick
>
>
> Let's start with a request for 2 authorizations using OAuth scopes, one
> for writing and the other for reading:
>
> (1)
> {
>     "authorizations": {
>         "writer": [
>             {
>                 "type": "oauth_scope",
>                 "scope": ["create","update","delete"]
>             }
>         ],
>         "reader": [
>             {
>                 "type": "oauth_scope",
>                 "scope": ["read","list"]
>             }
>         ]
>     }
> }
>
> We can ask for just one token with all the same capabilities:
> (2)
> {
>     "authorizations": [
>         {
>             "type": "oauth_scope",
>             "scope": ["create","update","delete"]
>         },
>         {
>             "type": "oauth_scope",
>             "scope": ["read","list"]
>         }
>     ]
> }
>
> Of course (2) can be simplified as:
> (3)
> {
>     "authorizations": [
>         {
>             "type": "oauth_scope",
>             "scope": ["create","update","delete","read","list"]
>         }
>     ]
> }
>
> Now let's say that in "oauth_scope", the array of scopes can also be a
> space separated string. So the following is equivalent:
> (4)
> {
>     "authorizations": [
>         {
>             "type": "oauth_scope",
>             "scope": "create update delete read list"
>         }
>     ]
> }
>
> Now let's say that the "oauth_scope" type is the default, so we can
> express it as:
> (5)
> {
>     "authorizations": ["create","update","delete","read","list"]
> }
>
> Or use a space separated string instead of an array:
> (6)
> {
>     "authorizations": "create update delete read list"
> }
>
> In summary, (2) - (6) will give the exact same result.
>
> Let's add another authorization type to the request,
> "customer_information":
> (7)
> {
>     "authorizations": [
>         "create update delete read list",
>         {
>             "type": "customer_information",
>             "locations": [
>                 "https://example.com/customers",
>             ],
>             "actions": [
>                 "read"
>             ],
>             "datatypes": [
>                 "contacts",
>                 "photos"
>             ]
>         }
>     ]
> }
>
> And the space separated strings can be turned into individual strings and
> we have the equivalent request:
> (8)
> {
>     "authorizations": [
>         "create",
>         "update",
>         "delete",
>         "read",
>         "list",
>         {
>             "type": "customer_information",
>             "locations": [
>                 "https://example.com/customers",
>             ],
>             "actions": [
>                 "read"
>             ],
>             "datatypes": [
>                 "contacts",
>                 "photos"
>             ]
>         }
>     ]
> }
>
> Let's go back to our first example, and ask for 3 separate tokens:
> (9)
> {
>     "authorizations": {
>         "writer": "create update delete",
>         "reader": "read list",
>         "customer": [
>             {
>                 "type": "customer_information",
>                 "locations": [
>                     "https://example.com/customers",
>                 ],
>                 "actions": [
>                     "read"
>                 ],
>                 "datatypes": [
>                     "contacts",
>                     "photos"
>                 ]
>             }
>         ]
>     }
> }
>
> In a multi token request, if there is only one item in the array, we can
> shorten (9) to the following:
> (10)
> {
>     "authorizations": {
>         "writer": "create update delete",
>         "reader": "read list",
>         "customer": {
>             "type": "customer_information",
>             "locations": [
>                 "https://example.com/customers",
>             ],
>             "actions": [
>                 "read"
>             ],
>             "datatypes": [
>                 "contacts",
>                 "photos"
>             ]
>         }
>     }
> }
>

--000000000000323c4b05aa4827ac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


For those not familiar with "turning=
 up to 11"=C2=A0https://en.wikipedia.org/wiki/Up_to_eleven

<=
/div>
A counter argument=C2=A0to all of this polymorphism=C2=A0is that =
the AS is sending back the granted authorization. While pushing type detect=
ion to the AS to provide a simpler interface for the Client, it seems count=
erproductive if the Client has to do the same. A consistent response from t=
he AS will be simpler for the Client, but would then also be different then=
 what=C2=A0the Client originally requested from the GS.

On Fri, Jul 10=
, 2020 at 6:01 PM Dick Hardt <di=
ck.hardt@gmail.com> wrote:
Taking Justin'=
s model of strings being shortened versions of OAuth scopes, adding in the =
"type" property from RAR, and defining a default type, we *could*=
 add a bunch of polymorphism. (I have not implemented the code below, but i=
t looks doable assuming I have not overloaded a type in the same context)

/Dick


Let&#=
39;s start with a request for 2 authorizations using OAuth scopes, one for =
writing and the other for reading:

(1)
{=

=C2=A0 =C2=A0 "authorizations": {
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "writer": [
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "type": "oauth_scope",
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": [&q=
uot;create","update","delete"]
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "reader": [
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type": "oauth_sco=
pe",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 "scope": ["read","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 }
}

We can ask=
 for just one token with all the same capabilities:
(2)
{
=C2=A0 =C2=A0 "authorizations": [
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 "type": "oauth_scope",
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": ["create","up=
date","delete"]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "type": "oauth_scope",
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": ["read&qu=
ot;,"list"]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=
=A0 =C2=A0 ]
}

Of course (2) can be simp=
lified as:
(3)
{
=C2=A0 =C2=A0 "authoriz=
ations": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {=C2=A0
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type": "oauth_scope&=
quot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope"=
;: ["create","update","delete","read&quo=
t;,"list"]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=
=A0 =C2=A0 ]
}

Now let's say that in=
 "oauth_scope", the array of scopes can also be a space separated=
 string. So the following is equivalent:
(4)
{
=C2=A0 =C2=A0 "authorizations": [
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &quo=
t;type": "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "scope": "create update delete read list&q=
uot;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 ]
}

Now let's say that the "oauth_sco=
pe" type is the default, so we can express it as:
(5)
<=
div>{
=C2=A0 =C2=A0 "authorizations": ["create&quo=
t;,"update","delete","read","list"]=

}

Or use a space separated string inste=
ad of an array:
(6)
{
=C2=A0 =C2=A0 "aut=
horizations": "create update delete read list"
}

In summary, (2) - (6) will give the exact same resu=
lt.

Let's add another authorization type to th=
e request, "customer_information":
(7)
{
=C2=A0 =C2=A0 "authorizations": [
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "create update delete read list",
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
"type": "customer_information",
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "locations": [
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "https://example.com/customers"=
;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "actions": [
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "read"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "datatypes": [
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "contacts",
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "photos"<=
/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 ]
}

And the space separated strings can be turned into individual strin=
gs and we have the equivalent request:
(8)
{
=
=C2=A0 =C2=A0 "authorizations": [
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 "create",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "upda=
te",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "delete",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "read",
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "list",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type": "cu=
stomer_information",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "locations": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "https://example.com/customers",
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "actions": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "read"
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 "datatypes": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "contacts",
=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "photos"
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 ]
}

Let's go =
back to our first example, and ask for 3 separate tokens:
(9)
{
=C2=A0 =C2=A0 "authorizations": {
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "writer": "create update delete&=
quot;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "reader": "read=
 list",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "customer": [<=
/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 "type": "custo=
mer_information",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "locations": [
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "https://example.com/customers"=
;,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "action=
s": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 "read"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 "datatypes": [
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "contacts",<=
/div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 "photos"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 =C2=A0 =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 a multi token request,=
 if there is only one item in the array, we can shorten (9) to the followin=
g:
(10)
{
=C2=A0 =C2=A0 "authorizations&=
quot;: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "writer": "cr=
eate update delete",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "reade=
r": "read list",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
;customer": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &quo=
t;type": "customer_information",
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 "locations": [
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "https://example.com/customers",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "actions": [
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "read"
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 "datatypes": [
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "contacts",
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "photos"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 }=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 }
}




--000000000000323c4b05aa4827ac--


From nobody Sun Jul 12 19:31: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 7C3A43A090E for ; Sun, 12 Jul 2020 19:31:52 -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, 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 dKjIKs8RMQmd for ; Sun, 12 Jul 2020 19:31:50 -0700 (PDT)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 BA4153A0908 for ; Sun, 12 Jul 2020 19:31:49 -0700 (PDT)
Received: by mail-wm1-x32f.google.com with SMTP id 17so11547809wmo.1 for ; Sun, 12 Jul 2020 19:31:49 -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=p1TDUGcujcJNE/hHpqoW803UrxfzkxfUlSn8Mx0dwTU=; b=QM46mhohXxsF5vA1lYoMSPuuJAo1to56wLJs/jypPcD3E5bqDK+WQNzuMbG03EQZkC QvZnmnQYENAA+0gPyxECmioA2TeQUX+DVC1d0F8sFptxScjEeKuy4CzBbBkuc7hL8/Xq SpiF1UFgpl72NrRI87a0+qJZ8Y5pRHhxLj/h8=
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=p1TDUGcujcJNE/hHpqoW803UrxfzkxfUlSn8Mx0dwTU=; b=rpJbSoEOuzz03hWpNFANVyA6x/3fwHhuY3PIrN0RAszQnODuo98EEhG7B2KWxygsPa OUddt5YNYAEQmxl1qBJV7O89A2/WLLCfaUp6YKAH5wEx+AmkWrVs2YsMyhnMChCXbGtO NYhEeZdLhggrzKN3VyfR1YeIZCcJtPY14G7LnE0vPW4NmVgLOwAkm9tBLP9QJ2pMjtTI yM1sBlYae7bRIX3HyVr24aaHNGZ6lGkVVI7gA00zf9ZXQvkULqCYxCIuET7srxMim7gw CN5SmIGMRJEsLav6thnvHuq8gsSKkua3xXpDq1mpue/XTFg3EcwmfKr3UJieVLnb88uE XvEQ==
X-Gm-Message-State: AOAM530mIX2kuH6fbWMK+Ajw+wmYGfDimYsntzWSBXWGZZlcDeC6Zcum WjQRPl0XFr0QtqDVebbDaWvYoKYEW6kT7GnqrgUz8w==
X-Google-Smtp-Source: ABdhPJzOojnQbHLnl2t01sRyxCHQTkuSnu1yjuie2cSq/VWMwgdG1h+1W+3DAaruiG9l8UXDp+LzTpF/VwSQtKq/jMM=
X-Received: by 2002:a1c:f407:: with SMTP id z7mr16635587wma.8.1594607507860; Sun, 12 Jul 2020 19:31:47 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Francis Pouatcha 
Date: Sun, 12 Jul 2020 22:31:37 -0400
Message-ID: 
To: Dick Hardt 
Cc: Francis Pouatcha , txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000010011105aa497e5e"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 13 Jul 2020 02:31:52 -0000

--00000000000010011105aa497e5e
Content-Type: text/plain; charset="UTF-8"

Dick, my response inline

On Sun, Jul 12, 2020 at 3:01 PM Dick Hardt  wrote:

> Francis, thanks for the review ... questions and comments inserted ...
>
> On Sat, Jul 11, 2020 at 10:05 AM Francis Pouatcha  40adorsys.de@dmarc.ietf.org> wrote:
>
>> Some points raised here might match what I wrote before after reviewing
>> the last draft of XYZ.
>>
>
> I'm assuming you are referring to this post:
>
> https://mailarchive.ietf.org/arch/msg/txauth/v-iH5ID8VaOojx7fGniffrxCQdo/
>
> Correct?
>
Yes.

>
>
>> 1. Dictionary
>> I do like sections 1.x dealing with terms but this is kept too short. I
>> have noticed that most of the discussion conducted on the list results from
>> different understanding of terms used.
>>
>
> Are terms missing, are the definitions too short, or both?
> If you provide specific examples I can work on addressing them!
>
Definitions are too short. I will provide a proper mail with my proposal of
what we might need to clarify and als limit each term.

>
>
>>
>> 2. Abstract Protocol Flow
>>
>> I am missing an abstract protocol flow like the one defined in
>> https://tools.ietf.org/html/rfc6749#section-1.2.
>>
>
> That's an interesting point. GNAP also has identity claims, so the
> abstract flow is somewhat different (there is no Authorization Grant from
> the RO), and not all steps always happen. (there may not be steps (E) and
> (F) with a Resource Server)
>
> Would you elaborate on what you think would be useful here, that is not in
> the specific flows?
>
A diagram that generalizes the steps, independently of interaction mode is
essential for the reader's navigation of the rest of the document. This is
what #section-1.2 of RFC6749 does. I hope we can produce a similar diagram.

A subsection of
https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1 could
be defined for this.

>
>
>>
>> 3. Parties
>> a) graphical illustration (#section-1.1)
>> I do like the graphical illustration in #section-1.1. The main difference
>> to the picture in https://tools.ietf.org/html/rfc6749#section-1.2 is the
>> clear separation between the "User" and the "Resource Owner" (RO). To help
>> transition the understanding of current oAuth2 implementers, it is
>> essential to illustrate and highlight the rationale behind this design.
>>
>
> Would a reference to #section-2.3
> 
> in the RO definition, and more explanation in #section-2-3 on the rationale
> address your concern?
>
A subsection of
https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1 with
the RO vs. User clarification and some example interactions where they
diverge.

>
>
>
>>
>> b) Dynamic Client (#section-1.1)
>> I would like to mention that the dynamic client can present a certificate
>> issued by some authorities known to the GS. This is the case of QSeal
>> certificates designed by European eiDas.
>>
>
> I agree.
>
> If we do mention that, we should specify how the certificate would be
> presented and work. We can do that in the core GNAP document, in an GNAP
> extension, or reference another specification. I'm not that familiar with
> QSeal. Is it specified somewhere?
>
This is the ETSI standard used by the European PSD2:
https://www.etsi.org/deliver/etsi_ts/119400_119499/119495/01.04.01_60/ts_119495v010401p.pdf
.
There is a well managed infrastructure in the European Economic Area that
allows for "Certificate Based Dynamic Client".

>
>
>>
>> c) Grant Server (GS)
>> If the GS is a SIOP running on the user device, how does it influence the
>> protocol design?
>>
>
> With mobile apps having URIs bound to specific apps, I think the protocol
> would work the same, but I've not worked with SIOPs. Do you have any
> concerns?
>
Yes. As the protocol flow designs inbound connectivity from Client to GS.
How does a client initiate a connection to the user device? Or we might
have alternative interactions without inbound connectivity to the GS?

>
>
>>
>>
>> 4. Interaction Modes (Protocol Flows)
>> And mentioned in my review of the XYZ protocol, I am missing a grouping
>> of interaction models. We need an abstraction layer in which we define
>> groups of flows based on key interaction between parties. I am expecting at
>> least:
>>
>> - "redirect" Interaction
>> here the GS instructs the Client to redirect the RO/User to the given interaction
>> URL. This is well covered in #section-2.1. But for transparency this
>> picture must also display the "User". Shall the redirect interaction
>> presume that the "User" and the "Ro" are represented by the same party,
>> then it is worth mentioning this. In this case we can draw a single box to
>> represent both.
>>
>
> Did you mean to say '... the picture must also display the "RO"'?
>
Yes. For transparency, even if they are both in the same box.

>
> There could be a separate RO in a more complex flow, but we could define
> this flow to represent where the User and RO are the same party.
>
Yes.

>
>
>> - "decoupled" Interaction
>> This interaction model is currently represented by the "user_code"
>> Interaction (#section-2.2) and the "indirect" Interaction (#section-2.3 and
>> #section-5.2).. Both of these are forms of "decoupled" Interactions. Main
>> characteristic of a decoupled interaction shall be that the device used by
>> the RO to interact with the GS shall be separated from the. device used by
>> the "User" to interact with the "Client".
>>
>
> I like the word "decoupled" -- would "redirect" then be named "coupled"?
> Or renamed "indirect" to "decoupled"?
>
Not sure.
- Let us use redirect, decoupled and embedded to refer to "families/types
of interaction". In which case "Indirect" will be an interaction mode of
the "decoupled family".
- I wouldn't call "redirect" and interaction mode, as there are many
variants of redirect. Let us keep the keyword for the family and specify
known variants of redirect interaction for more precision.


> While "user_code" and "indirect" are both decoupled, the "indirect" has
> different security properties as it uses a link, which an attacker can
> trick a user into clicking on wherever a link may be used.
>
> I do agree that "user_code" and "indirect" are both a decoupled
> interaction, and calling that out would be useful.
>
Yes.

>
>
>
>>
>> - "embedded" Interaction
>> With the evolving of smart end user devices that can keep private keys,
>> perform cryptographic operations, it is essential to include the "embedded"
>> Interaction in which RO/User device send authorization grant to "Client"
>> that in turns takes it to the GS in exchange of the authorization token. In
>> XYZ I found this hidden behind the didcom interaction.
>> The "embedded" interaction shall open room for different types of
>> synchronous transaction authorization requests in which the "RO/User" gives
>> a verifiable assertion (inkl. proof of possession) to the "Client" for use
>> at the GS in exchange for the seeked access token.
>>
>
> I have been thinking that the functionality you describe above would be in
> the "user" object rather than in the "interaction" object as it is not an
> interaction between the GS and the User. IE, the Client presents some
> artifact to the GS that establishes the User in the GS context so that a GS
> / User interaction is not needed.
>
> That looks similar to me to what Denis was proposing in
>
> https://mailarchive.ietf.org/arch/msg/txauth/kgTKFHZDRDsXJlwW95Gqv_-LctA/
>
No. It is different.

>
>
> Does that work, or am I missing something?
>
Embedded in the sense above is about embedding the interaction RO <-> GS
into the communication path User <-> Client <-> GS.
The main purpose is to keep the Link User <-> Client uninterrupted (by any
type of redirect or decoupled interaction).

Best regards,
-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--00000000000010011105aa497e5e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Dick, my response inline

On Sun, Jul 12, 2=
020 at 3:01 PM Dick Hardt <dick.=
hardt@gmail.com> wrote:
Francis, thanks for the review ... que=
stions and comments inserted ...=C2=A0

=

On Sat, Jul 11, 2020 at 10:05 AM Fran=
cis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
<=
div dir=3D"ltr">Some points raised here might match what I wrote before aft=
er reviewing the last draft of XYZ.=C2=A0

I'm assuming you are referring to this post:
Correct?
Yes.=C2=A0


1. Dictionary
I do like sections =
1.x dealing with terms but this is kept too short. I have noticed that most=
 of the discussion conducted on the list results from different=C2=A0unders=
tanding of terms used.

<=
div>Are terms missing, are the definitions too short, or both?
If=
 you provide specific examples I can work on addressing them!
Definitions are too short. I will provide a proper ma=
il with my proposal of what we might need to clarify and als limit each ter=
m.
=


=C2=A0<=
/div>

3. Parties
a)=C2=A0graphical illustration (#section-1.1)
I do like the gra=
phical illustration in #section-1.1. The main difference to the picture in=
=C2=A0https://tools.ietf.org/html/rfc6749#section-1.2 is the clear s=
eparation between=C2=A0the "User" and the "Resource Owner&qu=
ot; (RO). To help transition the understanding of current oAuth2 implemente=
rs, it is essential to illustrate and highlight the rationale behind this d=
esign.

Would =
a reference to #section-2.3 in the RO definiti=
on, and more explanation in #section-2-3 on the rationale address your conc=
ern?
A subsection of https://tool=
s.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1 with the RO v=
s. User clarification and some example interactions where they diverge.

=C2=A0

b) Dynamic Client (#section-1.1)
=
I would like to mention that the dynamic client can present a certificate i=
ssued by some authorities known to the GS. This is the case of QSeal certif=
icates designed by European eiDas.
<=
/blockquote>

I agree.=C2=A0

If =
we do mention that, we should specify how the certificate would be presente=
d and work. We can do that in the core GNAP document, in an GNAP extension,=
 or reference another specification. I'm not that familiar with QSeal. =
Is it specified somewhere?
This is the E=
TSI standard used by the European PSD2:=C2=A0h=
ttps://www.etsi.org/deliver/etsi_ts/119400_119499/119495/01.04.01_60/ts_119=
495v010401p.pdf.=C2=A0
There is a well managed infrastructure=
 in the European Economic Area that allows for "Certificate Based=C2=
=A0Dynamic Client".
=C2=A0

<=
div>c)=C2=A0Grant Serv=
er (GS)
If the GS is a SIOP running on the user device, ho=
w does it influence the protocol design?

With mobile apps having URIs bound to specific =
apps, I think the=C2=A0protocol would work the same, but I've not worke=
d with SIOPs. Do you have any concerns?=C2=A0
Yes. As the protocol flow designs inbound connectivity from Client to=
 GS. How does=C2=A0a=C2=A0client initiate=C2=A0a connection to the user dev=
ice? Or we might have alternative interactions without=C2=A0inbound connect=
ivity to the GS?
=C2=A0
4. Interaction Modes (Protocol Flows)
And ment=
ioned=C2=A0in my review of the XYZ protocol, I am missing a grouping of int=
eraction models. We need an abstraction layer in which we define groups of =
flows based on key interaction between parties. I am expecting at least:

- "redirect" Interaction
he=
re the GS instructs the Client to redirect the RO/User to the given=C2=A0interaction URL. This is=
 well=C2=A0covered in=C2=A0#section-2.1.=C2=A0But for transparency t=
his picture must also display the "User". Shall the=C2=A0redirect=
 interaction presume that the "User" and the "Ro" are r=
epresented by the same party, then it=C2=A0is worth=C2=A0mentioning this. I=
n this case we can draw=C2=A0a single box to represent both.

Did you mean=C2=A0to =
say '... the picture must also display the "RO"'?=C2=A0
Yes. For transparency, even if they are b=
oth in the same box.=C2=A0

Ther=
e could be a separate RO in a more complex flow, but we could define this f=
low to represent where the User and RO are the same party.
Yes.=C2=A0


- "decoupled" =
Interaction
This=C2=A0interaction model is currently represented =
by the=C2=A0"user_code" Interaction (#section-2.2) and the=C2=A0&=
quot;indirect" Interaction (#section-2.3 and #section-5.2).. Both of t=
hese are forms of "decoupled" Interactions. Main characteristic o=
f a decoupled interaction shall be that=C2=A0the device used by the RO to i=
nteract with the GS shall be separated from the. device used by the "U=
ser" to interact with the "Client".
<=
/div>

I like the word "decoupled=
" -- would "redirect" then be named "coupled"? Or =
renamed "indirect" to "decoupled"?
Not sure.
- Let us use redirect, decoupled and emb=
edded to refer to "families/types of interaction". In which case =
"Indirect" will be an interaction mode of the "decoupled fam=
ily".
- I wouldn't call "redirect" and interac=
tion mode, as there are many variants of redirect. Let us keep the keyword =
for the family and specify known variants of redirect interaction for more =
precision.


While=
 "user_code" and "indirect" are both decoupled, the &qu=
ot;indirect" has different security properties as it uses a link, whic=
h an attacker can trick a user into clicking on wherever a link may be used=
.=C2=A0

I do agree that "user_code" and =
"indirect" are both a decoupled interaction, and calling that out=
 would be useful.
Yes.=C2=A0

=C2=A0

- "embedded" Interaction
With=
 the evolving of smart end user devices that can keep private keys, perform=
=C2=A0cryptographic operations, it is=C2=A0essential=C2=A0to include the &q=
uot;embedded" Interaction in which RO/User device send authorization g=
rant to "Client" that in turns takes it to the GS in exchange of =
the authorization token. In XYZ I found this hidden behind=C2=A0the didcom =
interaction.
The "embedded" interaction shall open room=
 for different types of synchronous transaction authorization requests in w=
hich the "RO/User" gives a verifiable assertion (inkl. proof of p=
ossession) to the "Client" for use at the GS in exchange for the =
seeked access token.
<=
br>
I have been thinking that the functionality you describe abov=
e would be in the "user" object rather than in the "interact=
ion" object as it is not an interaction between the GS and the User. I=
E, the Client presents some artifact to the GS that establishes the User in=
 the GS context so that a GS / User interaction is not needed.
That looks similar=C2=A0to me to what Denis was proposing in=
=C2=A0

=

No. It is different.=C2=A0


Does that work, or am I missing someth=
ing?
Embedded in the sense above is abou=
t embedding the interaction RO <-> GS into the communication path Use=
r <-> Client <-> GS.=C2=A0
The main purpose is to kee=
p the Link User <-> Client uninterrupted (by any type of redirect or =
decoupled interaction).

Best regards,
-=
- 
Francis =
Pouatcha
Co-Founder and Technical Lead
adorsys GmbH &am=
p; Co. KG
<=
/div>


--00000000000010011105aa497e5e--


From nobody Mon Jul 13 01: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 0D8463A0C1C for ; Mon, 13 Jul 2020 01:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.269
X-Spam-Level: 
X-Spam-Status: No, score=0.269 tagged_above=-999 required=5 tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, 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 LSSAZNOyw6sn for ; Mon, 13 Jul 2020 01:40:31 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A023A0C1B for ; Mon, 13 Jul 2020 01:40:30 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d84 with ME id 2YgU230014FMSmm03YgUlm; Mon, 13 Jul 2020 10:40:28 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 13 Jul 2020 10:40:28 +0200
X-ME-IP: 86.238.65.197
To: Fabien Imbault 
Cc: txauth@ietf.org
References:  <382b5f57-6825-3537-c66b-fb2c38e5140c@free.fr> 
From: Denis 
Message-ID: 
Date: Mon, 13 Jul 2020 10:40:25 +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="------------6CC65718C8A5F1213A46987F"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 13 Jul 2020 08:40:35 -0000

This is a multi-part message in MIME format.
--------------6CC65718C8A5F1213A46987F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Fabien,

Thank you for your responses. Rather than responding in the text, I will 
pick up two of your comments:

    FI : as far as I'm concerned, there are many more interactions than
    Oauth/XYZ/Xauth.
    Your view seems to be that it is simpler because AS are way less
    central, but it seems to me
    that RS are much more complex to implement correctly.

In XYZ/Xauth there is a protocol needed between the GS and many ROs. 
This protocol is "out of the scope" of these drafts and this is where 
the complexity is hidden.
So it looks simpler for the client but it is much more complicated for 
the management of the delegation at the GS. This also makes the 
assumption that a single GS
will be able to handle the delegation case because all the RSs are 
supposed to be in the same domain which is a very restrictive case. My 
proposal is able to handle
the multi-domain case.

Every RS is best placed to know where to forward an operation when it 
can't respond to it of its own. A RO should not need to inform a GS to 
tell what its relationships
with other RSs are. A GS should not be in a position to know everything 
about the relationships between RSs and to be informed in real time of 
any change about these
relationships.

In term of trust, I mentioned:

  * If a user has an account opened with an AS, then he trusts that AS
    to deliver the requested and genuine attributes into an access token.

This is it. There is no other trust relationship. The user does not 
trust or rely on any collaboration between a RO and a GS.


A second of your comments:

    FI: if we can't do it with maximum privacy, then we won't do it;
    which is a design choice,

I would rather say: If we can do it with maximum privacy, let us do it. 
At this time :

  * in draft-hardt-xauth-protocol-12, the word "privacy" does not even
    exist.
  * in draft-richer-transactional-authz-06, there is a single sentence
    in the privacy considerations section:

          Handles are passed between parties and therefore should be 
stateful and not contain any internal structure or information,
          which could leak private data.

About the user consent. At this time :

  * in draft-richer-transactional-authz-06, the user consent is never
    addressed.
  * in draft-hardt-xauth-protocol-12, the user consent is captured by
    the GS whereas it should be captured by the Client.

          The client has no way to verify that the user consent has 
indeed been followed by the GS because the client
          cannot verify that what happens "behind the scenery" at the GS 
is conformant with what the user has consented.

Denis

> Hi Denis,
>
> Thanks for your answer.
>
> My comments are embedded in the text, marked with FI.
>
> Fabien
>
>
> Le ven. 10 juil. 2020 à 17:53, Denis  > a écrit :
>
>     Hi Fabien,
>
>     It would have been appreciated that you kept the original message
>     in your response. I have copied it again at the end of this email.
>
>
> FI : sorry, not always easy on a mobile. Will make sure that's the 
> case next time.
>
>
>     Comments are between the lines.
>
>>     Hi Denis,
>>
>>     I think it's interesting, but also very different to XYZ/XAuth so
>>     it raises many questions ;-)
>>     The figure is impossible to read.
>
>     Use a PC. Copy and paste and then use the Courier font. On my PC
>     (with the clear figure) it was perfect.
>
>>     So let me try to summarize the suggested approach, with a
>>     concrete example, to make sure we understand well:
>>
>>     *0. The client authN to the AS (in whatever way is supported)*
>>     Ex : client is a corporate financing called "finapp". finapp
>>     contacts AS0 for authentication (say an openbanking service).
>>     User is John Doe, CFO at NeedMoney Inc. (+ other identity claims
>>     if needed, maybe some verified credential from NeedMoney Holding
>>     that John is indeed CFO).
>>
>>     /Dear John, /
>>     /to access to your finapp, please identify yourself through your
>>     prefered openbanking account./
>>     /Thanks/
>
>     If I understand you correctly,  finapp is a local application e.g.
>     on your smartphone.
>
> FI : not necessarily, the client could be a mobile app, a web app, 
> etc., making api calls to backend protected services.
>
>>     *1. The client contacts a RS in a discovery phase, which includes
>>     the selection of (at least) an operation, for which the RS
>>     returns the required authZ attributes *
>>     Ex : finapp needs to use NeedMoney's data to evaluate how much
>>     credit it can offer.
>>
>>     Op1 : compute the credit rating, from RS1 (this is outsourced to
>>     an external credit analyst), through the external service's own AS1.
>>     But to do that, RS needs your historic bank statements.
>>     Op2 : get your list of banks, RS2 (as registered within finapp),
>>     through openbanking AS0 and retrieve the bank statements :
>>     Op3a : get historic data from his main bank, RS2a (say an
>>     international bank), through openbanking AS0
>>     Op3b : same from a second bank account, RS2b (say a local bank),
>>     through openbanking AS0
>
>     Why don't you make your very first example a little bit more
>     complicated ? with RS1, RS2a, RS2b, ... AS0, AS1, ...
>
>     :-)
>
> FI : fair point. But i believe it's important to grasp what it means 
> on a realistic example, especially as the proposed protocol would be 
> very much dependant on the way RS calls are made.
>
>
>     The intent of the /first /email was to discuss a /basic /model and
>     to place the highlights on the way to capture the *user's consent*
>     in an interoperable manner without letting know to any RS or AS
>     the choices of the user. This is a fundamental feature of the model.
>     In XAuth, the user's consent is not formalized in the protocol :
>     "User consent is /often /required at the GS".
>
> FI : in the context of xauth, this seems pretty clear I think.
>
>>     *2. User consent *
>>     RS1 aggregates the list of attributes required (from all RS) and
>>     sends it to finapp.
>>     /Dear John, /
>>     /To evaluate your credit request, we need the following
>>     information: /
>>     /- your list of bank accounts (retrieved from your finapp account)/
>>     /- the associated banking statements over the past 12 months
>>     (from each bank)/
>>     /- we'll pass that data to the credit agency, which will return
>>     your credit score /
>>     /Do you agree ?/
>>
>>     John approves (or not..., maybe he'll agree only for one specific
>>     bank), via finapp directly
>>     (I like that, albeit in a more traditional flow, I'm also
>>     separating the UI from the rest of the protocol of XYZ, and it
>>     works too).
>
>     As described, the user could simply push to the RS the banking
>     statements over the past 12 months (from each bank).
>     The user consent is not about : "/Do you agree that/ /we pass the
>     data to the credit agency, which will return your credit score"
>     /since no attributes nor ASs are involved in the question.
>
> FI : this is possible of course, but pretty surprising. Today most 
> implementations are using oauth to delegate the implementation to some 
> specialized component, while here each RS would be responsible for 
> authentication. That is not an innocent choice from an implementation 
> and deployment perspective.
>
>     /
>     /
>
>     I guess you want the user to get access tokens targeted for RS2x
>     so that each bank will accept to disclose his banking statements
>     over the past 12 months.
>
>     The consent is whether the user accepts to get access tokens from
>     some of his banks targeted for RS2x for the following operation:
>     "Retrieval of the past 12 months banking statements" which
>     corresponds to an API for each bank and then to send these access
>     tokens to RS1.
>
>     In practice, the client (e.g. using FIDO) will connect
>     transparently to each of the appropriate AS from the banks and
>     will get the requested access tokens
>     with a requested validity period of about 5 minutes.
>
> FI : yes.
>
>>     *3. Requests to the protected resources *
>>     The client gets the access tokens and uses the services for which
>>     access was granted.
>>
>>     *Analysis: (maybe I didn't get everything right, if so let me know) *
>>     The trust model is focused around the relationship between the
>>     enduser (John) and his application (finapp), which seems fine.
>
>     No. The trust model is not making a focus on that specific
>     relationship. BTW, no access token is necessarily needed by the
>     user to be able to use finapp.
>
> FI : maybe, maybe not. As soon as I want to fetch api calls, I need 
> access tokens.
>
>>     => I see some potential issues :
>>
>>     a. it will be really difficult for an end user to understand what
>>     AS0 and AS1 are, why they're different, and why he needs to
>>     authenticate to each of them.
>>     How do you enable a federated experience? (especially as there
>>     could be many)
>
>     I fear that you have not fully captured what the user consent is
>     about. See the above explanations. In addition, there is no
>     concept of federation.
>
> FI : your notion of consent is very specific to what you have in mind. 
> It would require a kind of automated system to work.
> As for the concept of federation, this is required in practice in you 
> don't hypothesize a dependancy on FIDO. The Uma2 standard is probably 
> the closest to some of your ideas and focuses a lot on federation.
>
>>     b. deciding what is the main RS (here RS1) to be called by the
>>     client seems very critical, as it is the one that needs to
>>     orchestrate everything.
>>     This seems a very hierarchical and imperative model which seems
>>     somewhat counter intuitive in terms of developer experience (as
>>     least
>>     as it is made today, we clearly don't go into so much details).
>>     The call hierarchy may quickly become very complex, which may
>>     also become
>>     a problem when separate services evolve.
>
>     The client calls the main RS (here RS1). What may happen next is
>     fully dependant upon the operation that the user is willing to
>     perform and
>     this is unpredictable (since the back end service may change at
>     any point of time).
>
> FI : OK, but is it good engineering practice to have to deal with the 
> internals of service calls? The reason why people delegate APIs is 
> precisely to avoid that complexity. Today with OAuth, and tomorrow 
> with XYZ/Xauth, the programming model is way simpler. Privacy may be a 
> good reason to change that, but we need to be very thoughtful about that.
>
>>     c. RS1 gets all the information required to access all
>>     sub-resources, and therefore gets also a lot of responsibility
>>     (and power). But from finapp's
>>     point of view, it is the one that has the relationship with the
>>     user and is providing the core value proposition, while RS1 is
>>     just an external service.
>
>      So is it really a problem ?
>
> FI : I think so. If I'm finapp, I don't want to be this dependant on 
> RS1 for a lot of good and bad reasons. What I hope the example conveys 
> is that there's no reason why RS1 would suddenly become the center of 
> orchestration for all queries, while all the underlying data is 
> actually elsewhere.
> The fact that the proposed protocol mandates this behaviour is 
> surprising and I don't see why that is.
>
>>     d. multi-user (common B2B scenario): John wants to authorize a
>>     read access to his finapp account to his external auditor, Ann
>>     (who is not a direct user
>>     of finapp herself, but might already be registered by openbanking
>>     AS0). How do you do that? Does it require the access token itself
>>     to be able to delegate rights?
>
>     The intent of the short description I sent was to describe two
>     simple scenarios, so that we could start discussing about them.
>     At this point, the intent is not to cover all the scenarios you
>     may dream of.
>
> FI : fair point. However, as previously discussed, this is a big 
> concern as we don't know whether you think this is a valid use case or 
> whether this is out of scope (so far, I understood it was more, if we 
> can't do it with maximum privacy, then we won't do it; which is a 
> design choice, but standards are usually about consensus with people 
> that need to deal with real life problems).
>
>>     e. more generally, a threat model would be required, as there are
>>     many more interactions now.
>
>     There are less interactions than in XAuth: there is no protocol
>     between ASs and RSs, nor between ROs and ASs.
>
> FI : as far as I'm concerned, there are many more interactions than 
> Oauth/XYZ/Xauth. Your view seems to be that it is simpler because AS 
> are way less central, but it seems to me that RS are much more complex 
> to implement correctly.
>
>
>     Before a threat model, a trust model is needed. Do we have a trust
>     model for XAuth ?
>     Unfortunately not, since the word "trust" is absent in the main
>     body of draft-hardt-xauth-protocol-12.
>
> FI : sorry but I don't need the word trust to do threat modeling...
>
>     In this model, the trust relationships are as follows:
>
>       * The user trusts its client.
>       * If a user has an account opened with an AS, then he trusts
>         that AS to deliver the requested and genuine attributes into
>         an access token.
>       * A RS may trust one or more ASs for one or more types of
>         attributes _and_ for performing a given operation.
>       * A RS may be administered remotely by one or more RO.
>
>     _Note_: for authentication, a RS may accept either FIDO or one or
>     more types of attributes from one or more ASs.
>
>     Denis
>
>>     Cheers,
>>     Fabien
>>
>
>     This is a new thread.
>
>
>     Preamble: This model is quite different from the XAuth model.
>     In particular, a RO has no relationship with any AS and a Client
>     does not need to be associated with any AS prior to any access to
>     a RS.
>
>     A key point of this model is that the user's consent is handled
>     locally by the Client and hence no AS nor RS is handling a man
>     machine interface
>     for the user consent. This allows to support locally the user
>     consent for multiple ASs while keeping all ASs ignorant about the
>     choices of the user
>     made for accessing a particular RS.
>     *
>
>     **+--------++------------+
>     |User||Resource|
>     ||| Owner (RO) |
>     +--------++------------+
>     |\|
>     |\|
>     |\|
>     |\|
>     +-----------++---------------++------------+
>     ||---->| Authorization |||
>     || (2) |Server (AS)|||
>     ||<----||||
>     |Client|+---------------+||
>     ||-------------------------->|Resource|
>     |User|(1)|Server|
>     |Consent|<--------------------------|(RS)|
>     |element|||
>     ||-------------------------->||------>
>     ||(3)||(4)
>     ||<--------------------------||<------
>     +-----------++------------+
>     *
>     The flow of operations is as follows:
>
>     The Client (which may have been previously authenticated using
>     FIDO) contacts the RS and after some dialogue with the RS selects
>     an operation
>     that it wants to perform on the RS (1a). Note that it may also
>     indicate directly the operation that it wants to perform on the RS
>     without any prior dialogue.
>     In return (1b), the RS informs the Client about which attributes
>     are needed by the RS for performing the requested operation and
>     from which Attributes Servers
>     they may be obtained.
>
>     This information is specifically marked to indicate that it shall
>     be handled by the "User Consent element" from the Client.
>     The presentation of that information is up to the man machine
>     interface supported by the "User Consent element" from the Client.
>
>     The user can see which attributes are requested by the RS for
>     performing the requested operation and, if it consents, the Client
>     contacts one or more
>     appropriate Authorization Servers (2a). The user consent is hence
>     captured locally by the Client (i.e. there is no dialogue with any
>     AS nor any RS).
>
>     When the Client got the access tokens from these authorization
>     servers (2b), it sends all of them in a single request to the RS (3a).
>
>     End of the story for a simple access
>
>
>     Start of a subsequent story for a delegation case
>
>     Let us now suppose that the RS is unable to fulfil the request by
>     its own and that it needs to contact another RS. RS1 contacts RS2
>     (4a) and indicates the operation
>     that it wants to perform on RS2 (that operation may not be the
>     same as the original operation). In return (4b), RS2 informs RS1
>     about which attributes are needed
>     by RS2 for performing the requested operation and from which
>     Attributes Servers they may be obtained. RS1 forwards that
>     information to the Client.
>
>     This information is marked to indicate that it shall be handled by
>     the "User Consent element" from the Client. The presentation of
>     that information is up to the man machine
>     interface from the Client. The user can see which attributes are
>     requested by RS2 for performing the new requested operation and,
>     if it consents, the Client contacts one or more
>     appropriate Authorization Servers. The user consent is hence
>     captured locally by the "User Consent element" from the Client.
>     (i.e. there is no dialogue with any AS, nor RS1, nor RS2).
>
>     When the Client got the access token(s) from the authorization
>     server(s), it sends all of them in a single request to RS1. RS1
>     then forwards the additional access token(s) to RS2.
>
>
>     Some observations:
>
>     The user nor the Client are linked with any particular AS. A user
>     may use today an AS of the Bank of America and may change tomorrow
>     to the Bank of Missouri.
>     As soon as he will be registered with the Bank of Missouri, he
>     will be able to get access tokens from the AS of the Bank of
>     Missouri. The AS of Bank of America
>     has not been able to know where its access tokens have been used.
>     This will be the same for AS of the Bank of Missouri. There is no
>     need for any direct dialogue
>     between any AS and any RS at the time a client is making an
>     access. There is no need for any RO to contact any AS.
>
>     This model has been constructed following a "Privacy by Design"
>     approach.
>
>     Denis
>


--------------6CC65718C8A5F1213A46987F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Fabien,

    


    

    
Thank you for your responses. Rather
      than responding in the text, I will pick up two of your comments:

    

      
FI : as far as I'm concerned, there
        are many more interactions than Oauth/XYZ/Xauth. 

        Your view seems to be that it is simpler because AS are way less
        central, but it seems to me 

        that RS are much more complex to implement correctly. 

      

    

    
In XYZ/Xauth there is a protocol needed
      between the GS and many ROs. This protocol is "out of the scope"
      of these drafts and this is where the complexity is hidden. 

      So it looks simpler for the client but it is much more complicated
      for the management of the delegation at the GS. This also makes
      the assumption that a single GS 

      will be able to handle the delegation case because all the RSs are
      supposed to be in the same domain which is a very restrictive
      case. My proposal is able to handle 

      the multi-domain case.

    

    


    

    
Every RS is best placed to know where
      to forward an operation when it can't respond to it of its own. A
      RO should not need to inform a GS to tell what its relationships 

      with other RSs are. A GS should not be in a position to know
      everything about the relationships between RSs and to be informed
      in real time of any change about these

      relationships.

    


    

    
In term of trust, I mentioned:

    

      
    
        
  • If a user has an account opened with an AS, then he trusts
          that AS to deliver the requested and genuine attributes into
          an access token.
    • 
      

    

    
This is it. There is no other trust
      relationship. The user does not trust or rely on any collaboration
      between a RO and a GS.

    
 

    

    


    

    
A second of your comments:

    

      
FI: if we can't do it with maximum privacy, then we won't do
        it; which is a design choice,

    

    
I would rather say: If we can do it with maximum privacy, let us
      do it. At this time :

    
    
      
  • in draft-hardt-xauth-protocol-12, the word "privacy" does not
        even exist.
    • 
      
  • in draft-richer-transactional-authz-06, there is a single
        sentence in the privacy considerations section:
    • 
    

    
         Handles are passed between parties and therefore should
      be stateful and not contain any internal structure or information,
      

               which could leak private data.

    
About the user consent. At this time :

    
    
      
  • in draft-richer-transactional-authz-06, the user consent is
        never addressed.
    • 
      
  • in draft-hardt-xauth-protocol-12, the user consent is captured
        by the GS whereas it should be captured by the Client.
    
      
    • 
    

    
         The client has no way to verify that the user consent
      has indeed been followed by the GS because the client 

               cannot verify that what happens "behind the scenery" at
      the GS is conformant with what the user has consented.

    
 Denis

    

    

      
      

        
Hi Denis,
          


          

          
Thanks for your answer. 

          


          

          
My comments are embedded in the text, marked
            with FI. 

          


          

          
Fabien 

          

          

          

            
Le ven. 10 juil. 2020 à
              17:53, Denis <denis.ietf@free.fr> a
              écrit :

            

            

              

                
Hi Fabien,

                


                

                
It would have been appreciated that you kept the
                  original message in your response. I have copied it
                  again at the end of this email.

                

              

            

          

        

        


        

        
FI : sorry, not always easy on a mobile. Will
          make sure that's the case next time. 

        

          

            

              

                
 

                


                

                
Comments are between the lines.

                


                

                

                  
Hi Denis, 
                    


                    

                    
I think it's interesting, but also very
                      different to XYZ/XAuth so it raises many questions
                      ;-)

                    
The figure is impossible to read.

                  

                

                
Use a PC. Copy and paste and then use the Courier
                  font. On my PC (with the clear figure) it was perfect.

                

                  

                    
So let me try to summarize the suggested
                      approach, with a concrete example, to make sure we
                      understand well:

                    


                    

                    
0. The client authN to the AS (in whatever
                        way is supported)

                    
Ex : client is a corporate financing called
                      "finapp". finapp contacts AS0 for authentication
                      (say an openbanking service).  

                    
User is John Doe, CFO at NeedMoney Inc. (+
                      other identity claims if needed, maybe some
                      verified credential from NeedMoney Holding that
                      John is indeed CFO).

                    


                    

                    
Dear John, 

                    
to access to your finapp, please identify
                        yourself through your prefered openbanking
                        account.

                    
Thanks

                  

                

                
If I understand you correctly,  finapp is a local
                  application e.g. on your smartphone.

                

              

            

          

        

        
FI : not necessarily, the client could be a
          mobile app, a web app, etc., making api calls to backend
          protected services. 

        

          

            

              

                
 

                

                  
1. The client contacts a RS in a
                      discovery phase, which includes the selection of
                      (at least) an operation, for which the RS returns
                      the required authZ attributes 
                    
Ex : finapp needs to use NeedMoney's data to
                      evaluate how much credit it can offer.

                    


                    

                    
Op1 : compute the credit rating, from RS1 (this
                      is outsourced to an external credit analyst),
                      through the external service's own AS1.

                    

                    
But to do that, RS needs your historic bank
                      statements.

                    
Op2 : get your list of banks, RS2 (as
                      registered within finapp), through openbanking AS0
                      and retrieve the bank statements : 

                    
Op3a : get historic data from his main bank,
                      RS2a (say an international bank), through
                      openbanking AS0

                    
Op3b : same from a second bank account, RS2b
                      (say a local bank), through openbanking AS0

                  

                

                
Why don't you make your very first example a little
                  bit more complicated ? with RS1, RS2a, RS2b, ... AS0,
                  AS1, ... 

                

                
:-)

                

              

            

          

        

        
FI : fair point. But i believe it's important to
          grasp what it means on a realistic example, especially as the
          proposed protocol would be very much dependant on the way RS
          calls are made. 

        

          

            

              

                


                  The intent of the first email was to discuss
                  a basic model and to place the highlights on
                  the way to capture the user's consent 

                  in an interoperable manner without letting know to any
                  RS or AS the choices of the user. This is a
                  fundamental feature of the model.

                  In XAuth, the user's consent is not formalized in the
                  protocol : "User consent is often required at
                  the GS".

                

              

            

          

        

        
FI : in the context of xauth, this seems pretty
          clear I think. 

        

          

            

              

                
 

                

                  

                    
2. User consent 

                    
RS1 aggregates the list of attributes required
                      (from all RS) and sends it to finapp.

                  

                

                

                  

                    
Dear John, 

                    
To evaluate your credit request, we need the
                        following information: 

                    
- your list of bank accounts (retrieved from
                        your finapp account)

                    
- the associated banking statements over the
                        past 12 months (from each bank)

                    
- we'll pass that data to the credit agency,
                        which will return your credit score 

                    
Do you agree ?

                    


                    

                    
John approves (or not..., maybe he'll agree
                      only for one specific bank), via finapp directly 

                      (I like that, albeit in a more traditional flow,
                      I'm also separating the UI from the rest of the
                      protocol of XYZ, and it works too).

                  

                

                
As described, the user could simply push to the RS
                  the banking statements over the past 12 months (from
                  each bank).

                  The user consent is not about : "Do you agree that
                   we pass the data to the credit agency, which will
                    return your credit score"

                  since no attributes nor ASs are involved in the
                  question.

              

            

          

        

        
FI : this is possible of course, but pretty
          surprising. Today most implementations are using oauth to
          delegate the implementation to some specialized component,
          while here each RS would be responsible for authentication.
          That is not an innocent choice from an implementation and
          deployment perspective. 

        

          

            

              

                


                  

                
I guess you want the user to get access tokens
                  targeted for RS2x so that each bank will accept to
                  disclose his banking statements over the past 12
                  months.

                
The consent is whether the user accepts to get access
                  tokens from some of his banks targeted for RS2x for
                  the following operation: 

                  "Retrieval of the past 12 months banking statements"
                  which corresponds to an API for each bank and then to
                  send these access tokens to RS1.

                
In practice, the client (e.g. using FIDO) will
                  connect transparently to each of the appropriate AS
                  from the banks and will get the requested access
                  tokens 

                  with a requested validity period of about 5 minutes.

              

            

          

        

        
FI : yes. 

        

          

            

              

                

                  

                    
3. Requests to the protected resources 

                    
The client gets the access tokens and uses the
                      services for which access was granted.

                    


                    

                    
Analysis: (maybe I didn't get everything
                        right, if so let me know) 

                    
The trust model is focused around the
                      relationship between the enduser (John) and his
                      application (finapp), which seems fine.

                  

                

                
No. The trust model is not making a focus on that
                  specific relationship. BTW, no access token is
                  necessarily needed by the user to be able to use
                  finapp.

                

              

            

          

        

        
FI : maybe, maybe not. As soon as I want to
          fetch api calls, I need access tokens. 

        

          

            

              

                
 

                

                  
=> I see some potential issues : 
                    


                    

                    
a. it will be really difficult for an end user
                      to understand what AS0 and AS1 are, why they're
                      different, and why he needs to authenticate to
                      each of them. 

                      How do you enable a federated experience?
                      (especially as there could be many)

                  

                

                
I fear that you have not fully captured what the user
                  consent is about. See the above explanations. In
                  addition, there is no concept of federation. 

                

              

            

          

        

        
FI : your notion of consent is very specific to
          what you have in mind. It would require a kind of automated
          system to work. 

        
As for the concept of federation, this is
          required in practice in you don't hypothesize a dependancy on
          FIDO. The Uma2 standard is probably the closest to some of
          your ideas and focuses a lot on federation. 

        

          

            

              

                
 

                

                  

                    
b. deciding what is the main RS (here RS1) to
                      be called by the client seems very critical, as it
                      is the one that needs to orchestrate everything. 

                      This seems a very hierarchical and imperative
                      model which seems somewhat counter intuitive in
                      terms of developer experience (as least 

                      as it is made today, we clearly don't go into so
                      much details). The call hierarchy may quickly
                      become very complex, which may also become 

                      a problem when separate services evolve.

                  

                

                
The client calls the main RS (here RS1). What may
                  happen next is fully dependant upon the operation that
                  the user is willing to perform and 

                  this is unpredictable (since the back end service may
                  change at any point of time).

              

            

          

        

        
FI : OK, but is it good engineering practice to
          have to deal with the internals of service calls? The reason
          why people delegate APIs is precisely to avoid that
          complexity. Today with OAuth, and tomorrow with XYZ/Xauth, the
          programming model is way simpler. Privacy may be a good reason
          to change that, but we need to be very thoughtful about that. 

        

          

            

              

                

                  

                    
c. RS1 gets all the information required to
                      access all sub-resources, and therefore gets also
                      a lot of responsibility (and power). But from
                      finapp's 

                      point of view, it is the one that has the
                      relationship with the user and is providing the
                      core value proposition, while RS1 is just an
                      external service.

                  

                

                
 So is it really a problem ? 

                

              

            

          

        

        
FI : I think so. If I'm finapp, I don't want to
          be this dependant on RS1 for a lot of good and bad reasons.
          What I hope the example conveys is that there's no reason why
          RS1 would suddenly become the center of orchestration for all
          queries, while all the underlying data is actually elsewhere. 

        
The fact that the proposed protocol mandates
          this behaviour is surprising and I don't see why that is. 

        

          

            

              

                
 

                

                  

                    
d. multi-user (common B2B scenario): John wants
                      to authorize a read access to his finapp account
                      to his external auditor, Ann (who is not a direct
                      user 

                      of finapp herself, but might already be registered
                      by openbanking AS0). How do you do that? Does it
                      require the access token itself to be able to
                      delegate rights?

                  

                

                
The intent of the short description I sent was to
                  describe two simple scenarios, so that we could start
                  discussing about them.

                  At this point, the intent is not to cover all the
                  scenarios you may dream of.

              

            

          

        

        
FI : fair point. However, as previously
          discussed, this is a big concern as we don't know whether you
          think this is a valid use case or whether this is out of scope
          (so far, I understood it was more, if we can't do it with
          maximum privacy, then we won't do it; which is a design
          choice, but standards are usually about consensus with people
          that need to deal with real life problems). 

        

          

            

              

                

                  

                    
e. more generally, a threat model would be
                      required, as there are many more interactions now.

                  

                

                
There are less interactions than in XAuth: there is
                  no protocol between ASs and RSs, nor between ROs and
                  ASs.

                

              

            

          

        

        
FI : as far as I'm concerned, there are many
          more interactions than Oauth/XYZ/Xauth. Your view seems to be
          that it is simpler because AS are way less central, but it
          seems to me that RS are much more complex to implement
          correctly. 

        

          

            

              

                
 

                  Before a threat model, a trust model is needed. Do we
                  have a trust model for XAuth ? 

                  Unfortunately not, since the word "trust" is absent in
                  the main body of draft-hardt-xauth-protocol-12.

              

            

          

        

        
FI : sorry but I don't need the word trust to do
          threat modeling... 

        

          

            

              

                
In this model, the trust relationships are as
                  follows:

                
    
                  
  • The user trusts its client.
    • 
                  
  • If a user has an account opened with an AS, then
                    he trusts that AS to deliver the requested and
                    genuine attributes into an access token.
    • 
                  
  • A RS may trust one or more ASs for one or more
                    types of attributes and for performing a
                    given operation.
    • 
                  
  • A RS may be administered remotely by one or more
                    RO.
    
                  
    • 
                

                
Note: for authentication, a RS may accept
                  either FIDO or one or more types of attributes from
                  one or more ASs. 

              

            

          

        

        

          

            

              

                
 

                
Denis

                

                  

                    
Cheers, 

                    
Fabien

                    

                  

                  

                

                

                  This is a new thread.

                
                

                  
 

                      Preamble: This model is quite different from the
                      XAuth model. 

                      In particular, a RO has no relationship with any
                      AS and a Client does not need to be associated
                      with any AS prior to any access to a RS.

                      

                      A key point of this model is that the user's
                      consent is handled locally by the Client and hence
                      no AS nor RS is handling a man machine interface 

                      for the user consent. This allows to support
                      locally the user consent for multiple ASs while
                      keeping all ASs ignorant about the choices of the
                      user 

                      made for accessing a particular RS.

                      

                        

                              
                          +--------+                          
                          +------------+

                                 |  User 
                          |                           | 
                          Resource  |

                                 |        |                          
                          | Owner (RO) |

                                 +--------+        
                                            +------------+

                                     |      \                             
                          |

                                     |       \                            
                          |

                                     |        \                           
                          |

                                     |         \                          
                          |

                              +-----------+     +---------------+    
                          +------------+

                              |           |---->|
                          Authorization |     |           
                          |

                              |           |
                          (2) |  Server (AS)  |    
                          |            |

                              |           |<----|              
                          |     |           
                          |

                              |  Client  
                          |     +---------------+    
                          |            |

                              |           |-------------------------->| 
                          Resource  |

                              |   User   
                          |           (1)            
                          |   Server   |

                              |  Consent 
                          |<--------------------------|   
                          (RS)    |

                              |  element 
                          |                           |           
                          |

                              |           |-------------------------->|           
                          |------>

                              |           |          
                          (3)             |           
                          |  (4)

                              |           |<--------------------------|           
                          |<------

                              +-----------+                          
                          +------------+

                      

                      The flow of operations is as follows:

                      

                      The Client (which may have been previously
                      authenticated using FIDO) contacts the RS and
                      after some dialogue with the RS selects an
                      operation 

                      that it wants to perform on the RS (1a). Note that
                      it may also indicate directly the operation that
                      it wants to perform on the RS without any prior
                      dialogue. 

                      In return (1b), the RS informs the Client about
                      which attributes are needed by the RS for
                      performing the requested operation and from which
                      Attributes Servers 

                      they may be obtained. 

                      

                      This information is specifically marked to
                      indicate that it shall be handled by the "User
                      Consent element" from the Client. 

                      The presentation of that information is up to the
                      man machine interface supported by the "User
                      Consent element" from the Client. 

                      

                      The user can see which attributes are requested by
                      the RS for performing the requested operation and,
                      if it consents, the Client contacts one or more 

                      appropriate Authorization Servers (2a). The user
                      consent is hence captured locally by the Client
                      (i.e. there is no dialogue with any AS nor any
                      RS).

                      

                      When the Client got the access tokens from these
                      authorization servers (2b), it sends all of them
                      in a single request to the RS (3a).

                      

                      End of the story for a simple access

                  
 

                      Start of a subsequent story for a delegation case

                      

                      Let us now suppose that the RS is unable to fulfil
                      the request by its own and that it needs to
                      contact another RS. RS1 contacts RS2 (4a) and
                      indicates the operation 

                      that it wants to perform on RS2 (that operation
                      may not be the same as the original operation). In
                      return (4b), RS2 informs RS1 about which
                      attributes are needed 

                      by RS2 for performing the requested operation and
                      from which Attributes Servers they may be
                      obtained. RS1 forwards that information to the
                      Client. 

                      

                      This information is marked to indicate that it
                      shall be handled by the "User Consent element"
                      from the Client. The presentation of that
                      information is up to the man machine 

                      interface from the Client. The user can see which
                      attributes are requested by RS2 for performing the
                      new requested operation and, if it consents, the
                      Client contacts one or more 

                      appropriate Authorization Servers. The user
                      consent is hence captured locally by the "User
                      Consent element" from the Client. (i.e. there is
                      no dialogue with any AS, nor RS1, nor RS2). 

                      

                      When the Client got the access token(s) from the
                      authorization server(s), it sends all of them in a
                      single request to RS1. RS1 then forwards the
                      additional access token(s) to RS2.

                      

                      

                      Some observations: 

                      

                      The user nor the Client are linked with any
                      particular AS. A user may use today an AS of the
                      Bank of America and may change tomorrow to the
                      Bank of Missouri. 

                      As soon as he will be registered with the Bank of
                      Missouri, he will be able to get access tokens
                      from the AS of the Bank of Missouri. The AS of
                      Bank of America 

                      has not been able to know where its access tokens
                      have been used. This will be the same for AS of
                      the Bank of Missouri. There is no need for any
                      direct dialogue 

                      between any AS and any RS at the time a client is
                      making an access. There is no need for any RO to
                      contact any AS.

                  
This model has been constructed
                      following a "Privacy by Design" approach.

                  Denis

                  

              

            

          

        

      

    

    


    

  


--------------6CC65718C8A5F1213A46987F--


From nobody Mon Jul 13 02:02: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 AD71F3A0C6A for ; Mon, 13 Jul 2020 02:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.08
X-Spam-Level: 
X-Spam-Status: No, score=-0.08 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=0.116, MIME_QP_LONG_LINE=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 qZlOTQ1XDjFz for ; Mon, 13 Jul 2020 02:02:54 -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 BD4A23A0C61 for ; Mon, 13 Jul 2020 02:02:53 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id z13so15126642wrw.5 for ; Mon, 13 Jul 2020 02:02:53 -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:references :in-reply-to:mime-version; bh=gtIGTHoMxgxbkgvPmMMJnAubKCA+EoJLjmC+bTSN3Vo=; b=KF481GKKoflUD58n+Kw44JkFn8AlSxUih24nsAfYTNAgCbFFWUgcE0X6gJT7nbv/Gl EiUSgd1F8OTK9LSSspJDqY5pyYa7djviKuLw0cTgYKZ9kgFKArhuLDyTj/mBIw7PrwZF 7tSBHHXU9rHlsZY0uF1CPOw47+W7ItGuIsEkb+aazlArdMPg3xC0dMWI4g+YnuZJOhvK hiXaq3lMOqFg7n3ycfm7bA59Y+L3b2MxL1QqFMZs/LRB96cuafd16N4KlbxmCNCAVcQ2 hH4wolEKtcZuYheKJ5DsfGCXJcb2Ip1dwYT96Gqc3/wA0S59uxtemE+EG0fKefV0ebij 1KTw==
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:references:in-reply-to:mime-version; bh=gtIGTHoMxgxbkgvPmMMJnAubKCA+EoJLjmC+bTSN3Vo=; b=TOnbBTw34uH7EQTNbwaOzbHQnidJIN+ciDfEBDEZgFAU5qKmwhWPU9OyDhXFXG3gjs HJw3En1IcHIm0NlFBgcE+H4A27bYqVqU55uIT9//ahtijz3ynRrUmWbCqQuKYH6zTQh5 CtsVxBFSPS6DOIYRENqr0qk0lYKMr8oKDi7kK8a5YmXBoKN2MM3nCPcAue4m4iheGv0G LbylhZHAfJf4lTNCcB8F9WEe1Kv5BDC1hw+chxgga8zolZ/dGFWWs0q6JVvhsevYXXjT S9mMSpXl3jRmvg5IQaYoyIO/F/EGuNUbrrq5aR1Bzrv1L4W67n21CU2KNvIoOnORhG+Q TVkQ==
X-Gm-Message-State: AOAM532LgM1QQB2L5ZzK365mUAMT4Nj1dx0D5QRewe8GXqbF8a3KdMDh LWHl+UGnrJxdTDWB7kQAACQ=
X-Google-Smtp-Source: ABdhPJymS674DlWhl0HBzXQqqGM8Bvd/vMWRsXC+0nbsMVnuG2vd23w7SAuklK55vKki7YpXMLovGw==
X-Received: by 2002:adf:ee4d:: with SMTP id w13mr49385287wro.245.1594630971997;  Mon, 13 Jul 2020 02:02:51 -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 w13sm23074861wrr.67.2020.07.13.02.02.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2020 02:02:51 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.38.20061401
Date: Mon, 13 Jul 2020 12:02:50 +0300
From: Yaron Sheffer 
To: Dick Hardt , 
Message-ID: 
Thread-Topic: [Txauth] Turning polymorphism up to 11 (P11)
References:  
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3677486570_793933616"
Archived-At: 
Subject: Re: [Txauth] Turning polymorphism up to 11 (P11)
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, 13 Jul 2020 09:02:56 -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_3677486570_793933616
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable



=20

The issue of polymorphism is somewhat religious, similarly to strong vs. we=
ak typing in programming languages, and I am of the non-polymorphic (unimorp=
hic?) persuasion. Specifically when it comes to security protocols, where a =
recipient misunderstanding a value can easily result in a vulnerability.

=20

With respect to a schema language, IMO the fact that it is difficult to exp=
ress some polymorphic constructs in JSON Schema is a reason to avoid these c=
onstructs, rather than go looking for a different schema language.

=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: Txauth  on behalf of Dick Hardt 
Date: Monday, July 13, 2020 at 03:56
To: 
Subject: Re: [Txauth] Turning polymorphism up to 11 (P11)

=20

For those not familiar with "turning up to 11" https://en.wikipedia.org/wik=
i/Up_to_eleven

=20

A counter argument to all of this polymorphism is that the AS is sending ba=
ck the granted authorization. While pushing type detection to the AS to prov=
ide a simpler interface for the Client, it seems counterproductive if the Cl=
ient has to do the same. A consistent response from the AS will be simpler f=
or the Client, but would then also be different then what the Client origina=
lly requested from the GS.

=20

On Fri, Jul 10, 2020 at 6:01 PM Dick Hardt  wrote:

Taking Justin's model of strings being shortened versions of OAuth scopes, =
adding in the "type" property from RAR, and defining a default type, we *cou=
ld* add a bunch of polymorphism. (I have not implemented the code below, but=
 it looks doable assuming I have not overloaded a type in the same context)

=20

/Dick

=20

=20

Let's start with a request for 2 authorizations using OAuth scopes, one for=
 writing and the other for reading:

=20

(1)

{

    "authorizations": {

        "writer": [

            {=20

                "type": "oauth_scope",

                "scope": ["create","update","delete"]

            }

        ],

        "reader": [

            {=20

                "type": "oauth_scope",

                "scope": ["read","list"]

            }

        ]

    }

}

=20

We can ask for just one token with all the same capabilities:

(2)

{

    "authorizations": [

        {=20

            "type": "oauth_scope",

            "scope": ["create","update","delete"]

        },

        {=20

            "type": "oauth_scope",

            "scope": ["read","list"]

        }

    ]

}

=20

Of course (2) can be simplified as:

(3)

{

    "authorizations": [

        {=20

            "type": "oauth_scope",

            "scope": ["create","update","delete","read","list"]

        }

    ]

}

=20

Now let's say that in "oauth_scope", the array of scopes can also be a spac=
e separated string. So the following is equivalent:

(4)

{

    "authorizations": [

        {=20

            "type": "oauth_scope",

            "scope": "create update delete read list"

        }

    ]

}

=20

Now let's say that the "oauth_scope" type is the default, so we can express=
 it as:

(5)

{

    "authorizations": ["create","update","delete","read","list"]

}

=20

Or use a space separated string instead of an array:

(6)

{

    "authorizations": "create update delete read list"

}

=20

In summary, (2) - (6) will give the exact same result.

=20

Let's add another authorization type to the request, "customer_information"=
:

(7)

{

    "authorizations": [

        "create update delete read list",

        {

            "type": "customer_information",

            "locations": [

                "https://example.com/customers",

            ],

            "actions": [

                "read"

            ],

            "datatypes": [

                "contacts",

                "photos"

            ]

        }

    ]

}

=20

And the space separated strings can be turned into individual strings and w=
e have the equivalent request:

(8)

{

    "authorizations": [

        "create",

        "update",

        "delete",

        "read",

        "list",

        {

            "type": "customer_information",

            "locations": [

                "https://example.com/customers",

            ],

            "actions": [

                "read"

            ],

            "datatypes": [

                "contacts",

                "photos"

            ]

        }

    ]

}

=20

Let's go back to our first example, and ask for 3 separate tokens:

(9)

{

    "authorizations": {

        "writer": "create update delete",

        "reader": "read list",

        "customer": [

            {

                "type": "customer_information",

                "locations": [

                    "https://example.com/customers",

                ],

                "actions": [

                    "read"

                ],

                "datatypes": [

                    "contacts",

                    "photos"

                ]

            }   =20

        ]

    }

}

=20

In a multi token request, if there is only one item in the array, we can sh=
orten (9) to the following:

(10)

{

    "authorizations": {

        "writer": "create update delete",

        "reader": "read list",

        "customer": {

            "type": "customer_information",

            "locations": [

                "https://example.com/customers",

            ],

            "actions": [

                "read"

            ],

            "datatypes": [

                "contacts",

                "photos"

            ]

        }   =20

    }

}

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf=
o/txauth=20


--B_3677486570_793933616
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


<no hats>
<=
o:p> 
The issue of polymorphism is somewhat=
 religious, similarly to strong vs. weak typing in programming languages, an=
d I am of the non-polymorphic (unimorphic?) persuasion. Specifically when it=
 comes to security protocols, where a recipient misunderstanding a value can=
 easily result in a vulnerability.
&nb=
sp;
With respect to a schema language, IMO the f=
act that it is difficult to express some polymorphic constructs in JSON Sche=
ma is a reason to avoid these constructs, rather than go looking for a diffe=
rent schema language.
 
=

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
 
<=
div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in =
0in'>
From: =
Txauth <txauth-boun=
ces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
=
Date: Monday, July 13, 2020 at 03:56
To: <txauth@ietf.org&g=
t;
Subject: Re: [Txauth] Turning polymorphism up to 11 (P11)<=
/o:p>
 
For those not familiar with "turning up to 11=
" https://en.=
wikipedia.org/wiki/Up_to_eleven
 
A counter argument&nb=
sp;to all of this polymorphism is that the AS is sending back the grant=
ed authorization. While pushing type detection to the AS to provide a simple=
r interface for the Client, it seems counterproductive if the Client has to =
do the same. A consistent response from the AS will be simpler for the Clien=
t, but would then also be different then what the Client originally req=
uested from the GS.
 =

On Fri, Jul 10, 2020 at 6:01 PM Dick =
Hardt <dick.hardt@gmail.com>=
 wrote:
Taking Justin's model of strings being sh=
ortened versions of OAuth scopes, adding in the "type" property fr=
om RAR, and defining a default type, we *could* add a bunch of polymorphism.=
 (I have not implemented the code below, but it looks doable assuming I have=
 not overloaded a type in the same context)
 
/Dick
 
 
Let's start w=
ith a request for 2 authorizations using OAuth scopes, one for writing and t=
he other for reading:
 =
;
(1)
{
    &qu=
ot;authorizations": {
 =
;       "writer": [
            { 
            &nb=
sp;   "type": "oauth_scope",
               =
; "scope": ["create","update","delete&quo=
t;]
        =
    }
    &n=
bsp;   ],
    &nb=
sp;   "reader": [
            { 
=

                &=
quot;type": "oauth_scope",
                "scop=
e": ["read","list"]
            }
        ]
<=
div>
    }
}
 
We can ask for just one token with all the same =
capabilities:
(2)
=

{
=
    "authorizations": [
        { 
            "type": =
"oauth_scope",
  =
          "scope": ["create",&q=
uot;update","delete"]
        },
        { 
            "type": "oa=
uth_scope",
    &=
nbsp;       "scope": ["read","list&q=
uot;]
       =
; }
    ]
}
 
Of course (2) can be si=
mplified as:
(3)
<=
/div>
{
&=
nbsp;   "authorizations": [
        { 
            "type": &=
quot;oauth_scope",
  &=
nbsp;         "scope": ["create",&qu=
ot;update","delete","read","list"]
        }
    ]
}
 =
;
Now let's say that in "oauth_s=
cope", the array of scopes can also be a space separated string. So the=
 following is equivalent:
(4)
{
    "authorizations": [
=

        { 
            "=
type": "oauth_scope",
            "scope": "crea=
te update delete read list"
        }
&=
nbsp;   ]
}
<=
/div>
 
Now let's say that the "oauth_scope" type is the default, so w=
e can express it as:
(5)
{
    "authorizations": ["create","u=
pdate","delete","read","list"]=

}
 
Or use a space separa=
ted string instead of an array:
=
(6)
{
<=
p class=3DMsoNormal>    "authorizations": "create upd=
ate delete read list"
}
 
In summary, (2) - (6) will give the exact same result.<=
/o:p>
 
Let's add another authorization type to the request, "cus=
tomer_information":
(7)
{
    "authorizations": [
<=
div>
        "create update delet=
e read list",
   =
     {
    &=
nbsp;       "type": "customer_information"=
;,
        &=
nbsp;   "locations": [
                "https://example.com/customer=
s",
     =
;       ],
 =
           "actions": [
              =
  "read"
  &=
nbsp;         ],
            "datatypes": [=

          &=
nbsp;     "contacts",
                "phot=
os"
      &n=
bsp;     ]
  &nbs=
p;     }
   =
 ]
}
 
And the =
space separated strings can be turned into individual strings and we have th=
e equivalent request:
(8)
{
    "authorizations": [
        "create",
        "update=
",
      &nb=
sp; "delete",
  &=
nbsp;     "read",
        "list",
        {
<=
p class=3DMsoNormal>            "type"=
: "customer_information",
            "locations": [<=
/o:p>
          &n=
bsp;     "https://example.com/customers",
            ],
            "a=
ctions": [
    &n=
bsp;           "read"
            ],
          &nb=
sp; "datatypes": [
&nb=
sp;               "contacts",
         =
;       "photos"
            ]
        }
    ]
}
 
Let's go back to our first example, and ask for 3 s=
eparate tokens:
(9)
{
    "authorizations": {
        "writer": "create u=
pdate delete",
   =
;     "reader": "read list",
        "customer":=
 [
        &=
nbsp;   {
    &nb=
sp;           "type": "customer_info=
rmation",
    &nb=
sp;           "locations": [
            &n=
bsp;       "https://example.com/customers",
               =
 ],
        =
        "actions": [
=

                &=
nbsp;   "read"
&n=
bsp;               ],
              &n=
bsp; "datatypes": [
&n=
bsp;                   "co=
ntacts",
    &nbs=
p;               "photos"<=
/o:p>
          &n=
bsp;     ]
  &nbs=
p;         }    
        ]
<=
p class=3DMsoNormal>    }
}
 
<=
div>
In a multi token request, if there is only one item i=
n the array, we can shorten (9) to the following:
<=
p class=3DMsoNormal>(10)
{
    "authorizations"=
;: {
       =
 "writer": "create update delete",
<=
div>
        "reader": "=
;read list",
    =
    "customer": {
            "type": "cust=
omer_information",
  &=
nbsp;         "locations": [
              =
  "https:/=
/example.com/customers",
            ],
            "actions"=
: [
        =
        "read"
            ],
            "da=
tatypes": [
    &=
nbsp;           "contacts",
            &nb=
sp;   "photos"
&n=
bsp;           ]
        }    
    }
}
-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/l=
istinfo/txauth 


--B_3677486570_793933616--



From nobody Mon Jul 13 06:27: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 751F53A11CE for ; Mon, 13 Jul 2020 06:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 mE8k9yfGeVyg for ; Mon, 13 Jul 2020 06:27:53 -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 6254C3A117C for ; Mon, 13 Jul 2020 06:27:53 -0700 (PDT)
Received: from [192.168.1.7] (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 06DDRopm028354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jul 2020 09:27:51 -0400
From: Justin Richer 
Message-Id: <33EB90F0-D7FB-4C15-B5C4-0B265A818007@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_82D2C698-5D4C-4AAC-908B-92B6976C7696"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 13 Jul 2020 09:27:50 -0400
In-Reply-To: 
Cc: Dick Hardt , txauth@ietf.org
To: Yaron Sheffer 
References:   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Turning polymorphism up to 11 (P11)
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, 13 Jul 2020 13:27:55 -0000

--Apple-Mail=_82D2C698-5D4C-4AAC-908B-92B6976C7696
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yaron,

Just as a data point: As it turns out, the type of polymorphism that I =
am proposing is in fact expressible in JSON Schema. I was unaware of =
this construct previously, since I don=E2=80=99t use JSON Schema with =
any regularity:

=
https://json-schema.org/understanding-json-schema/reference/combining.html=
#anyof =


I am unaware of the exact expression capabilities in any of the other =
half-dozen JSON-based schema definition languages, though. :)=20

As for misunderstanding values, avoiding such things is actually the =
motivation behind the design I am proposing. A given data type in a =
particular place should have one and only one interpretation at all =
times.

And finally, as for the comment about the client needing to understand =
the response, perhaps the AS shouldn=E2=80=99t be the one doing the =
transformations when it returns data back to the client, and that should =
be restricted for exactly this reason. Additionally, I know of few OAuth =
clients that actively check the returned =E2=80=9Cscope=E2=80=9D value =
in the wild. I know they are out there, but the common practice, in my =
experience, is to ask for stuff and use whatever comes back. I think the =
conversation on =E2=80=9Cdirected tokens=E2=80=9D might help us change =
this in a clear way, and it could include rules on how the AS is allowed =
to return information.

Thanks,
 =E2=80=94 Justin

> On Jul 13, 2020, at 5:02 AM, Yaron Sheffer  =
wrote:
>=20
> 
> =20
> The issue of polymorphism is somewhat religious, similarly to strong =
vs. weak typing in programming languages, and I am of the =
non-polymorphic (unimorphic?) persuasion. Specifically when it comes to =
security protocols, where a recipient misunderstanding a value can =
easily result in a vulnerability.
> =20
> With respect to a schema language, IMO the fact that it is difficult =
to express some polymorphic constructs in JSON Schema is a reason to =
avoid these constructs, rather than go looking for a different schema =
language.
> =20
> Thanks,
>                 Yaron
> =20
> From: Txauth  on behalf of Dick Hardt =

> Date: Monday, July 13, 2020 at 03:56
> To: 
> Subject: Re: [Txauth] Turning polymorphism up to 11 (P11)
> =20
> For those not familiar with "turning up to 11" =
https://en.wikipedia.org/wiki/Up_to_eleven =

> =20
> A counter argument to all of this polymorphism is that the AS is =
sending back the granted authorization. While pushing type detection to =
the AS to provide a simpler interface for the Client, it seems =
counterproductive if the Client has to do the same. A consistent =
response from the AS will be simpler for the Client, but would then also =
be different then what the Client originally requested from the GS.
> =20
> On Fri, Jul 10, 2020 at 6:01 PM Dick Hardt > wrote:
>> Taking Justin's model of strings being shortened versions of OAuth =
scopes, adding in the "type" property from RAR, and defining a default =
type, we *could* add a bunch of polymorphism. (I have not implemented =
the code below, but it looks doable assuming I have not overloaded a =
type in the same context)
>> =20
>> /Dick
>> =20
>> =20
>> Let's start with a request for 2 authorizations using OAuth scopes, =
one for writing and the other for reading:
>> =20
>> (1)
>> {
>>     "authorizations": {
>>         "writer": [
>>             {=20
>>                 "type": "oauth_scope",
>>                 "scope": ["create","update","delete"]
>>             }
>>         ],
>>         "reader": [
>>             {=20
>>                 "type": "oauth_scope",
>>                 "scope": ["read","list"]
>>             }
>>         ]
>>     }
>> }
>> =20
>> We can ask for just one token with all the same capabilities:
>> (2)
>> {
>>     "authorizations": [
>>         {=20
>>             "type": "oauth_scope",
>>             "scope": ["create","update","delete"]
>>         },
>>         {=20
>>             "type": "oauth_scope",
>>             "scope": ["read","list"]
>>         }
>>     ]
>> }
>> =20
>> Of course (2) can be simplified as:
>> (3)
>> {
>>     "authorizations": [
>>         {=20
>>             "type": "oauth_scope",
>>             "scope": ["create","update","delete","read","list"]
>>         }
>>     ]
>> }
>> =20
>> Now let's say that in "oauth_scope", the array of scopes can also be =
a space separated string. So the following is equivalent:
>> (4)
>> {
>>     "authorizations": [
>>         {=20
>>             "type": "oauth_scope",
>>             "scope": "create update delete read list"
>>         }
>>     ]
>> }
>> =20
>> Now let's say that the "oauth_scope" type is the default, so we can =
express it as:
>> (5)
>> {
>>     "authorizations": ["create","update","delete","read","list"]
>> }
>> =20
>> Or use a space separated string instead of an array:
>> (6)
>> {
>>     "authorizations": "create update delete read list"
>> }
>> =20
>> In summary, (2) - (6) will give the exact same result.
>> =20
>> Let's add another authorization type to the request, =
"customer_information":
>> (7)
>> {
>>     "authorizations": [
>>         "create update delete read list",
>>         {
>>             "type": "customer_information",
>>             "locations": [
>>                 "https://example.com/customers =
",
>>             ],
>>             "actions": [
>>                 "read"
>>             ],
>>             "datatypes": [
>>                 "contacts",
>>                 "photos"
>>             ]
>>         }
>>     ]
>> }
>> =20
>> And the space separated strings can be turned into individual strings =
and we have the equivalent request:
>> (8)
>> {
>>     "authorizations": [
>>         "create",
>>         "update",
>>         "delete",
>>         "read",
>>         "list",
>>         {
>>             "type": "customer_information",
>>             "locations": [
>>                 "https://example.com/customers =
",
>>             ],
>>             "actions": [
>>                 "read"
>>             ],
>>             "datatypes": [
>>                 "contacts",
>>                 "photos"
>>             ]
>>         }
>>     ]
>> }
>> =20
>> Let's go back to our first example, and ask for 3 separate tokens:
>> (9)
>> {
>>     "authorizations": {
>>         "writer": "create update delete",
>>         "reader": "read list",
>>         "customer": [
>>             {
>>                 "type": "customer_information",
>>                 "locations": [
>>                     "https://example.com/customers =
",
>>                 ],
>>                 "actions": [
>>                     "read"
>>                 ],
>>                 "datatypes": [
>>                     "contacts",
>>                     "photos"
>>                 ]
>>             }   =20
>>         ]
>>     }
>> }
>> =20
>> In a multi token request, if there is only one item in the array, we =
can shorten (9) to the following:
>> (10)
>> {
>>     "authorizations": {
>>         "writer": "create update delete",
>>         "reader": "read list",
>>         "customer": {
>>             "type": "customer_information",
>>             "locations": [
>>                 "https://example.com/customers =
",
>>             ],
>>             "actions": [
>>                 "read"
>>             ],
>>             "datatypes": [
>>                 "contacts",
>>                 "photos"
>>             ]
>>         }   =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=_82D2C698-5D4C-4AAC-908B-92B6976C7696
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yaron,

Just=
 as a data point: As it turns out, the type of polymorphism that I am =
proposing is in fact expressible in JSON Schema. I was unaware of this =
construct previously, since I don=E2=80=99t use JSON Schema with any =
regularity:

https://json-schema.org/understanding-json-schema/reference/com=
bining.html#anyof

I am unaware of the exact expression capabilities in any of =
the other half-dozen JSON-based schema definition languages, though. =
:) 

As =
for misunderstanding values, avoiding such things is actually the =
motivation behind the design I am proposing. A given data type in a =
particular place should have one and only one interpretation at all =
times.

And =
finally, as for the comment about the client needing to understand the =
response, perhaps the AS shouldn=E2=80=99t be the one doing the =
transformations when it returns data back to the client, and that should =
be restricted for exactly this reason. Additionally, I know of few OAuth =
clients that actively check the returned =E2=80=9Cscope=E2=80=9D value =
in the wild. I know they are out there, but the common practice, in my =
experience, is to ask for stuff and use whatever comes back. I think the =
conversation on =E2=80=9Cdirected tokens=E2=80=9D might help us change =
this in a clear way, and it could include rules on how the AS is allowed =
to return information.

Thanks,
 =E2=80=94 Justin

On Jul 13, 2020, at 5:02 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

<no =
hats>
 
The issue of polymorphism is somewhat religious, similarly to =
strong vs. weak typing in programming languages, and I am of the =
non-polymorphic (unimorphic?) persuasion. Specifically when it comes to =
security protocols, where a recipient misunderstanding a value can =
easily result in a vulnerability.
 
With respect to a schema language, IMO =
the fact that it is difficult to express some polymorphic constructs in =
JSON Schema is a reason to avoid these constructs, rather than go =
looking for a different schema language.
 
Thanks,
          &nb=
sp;     Yaron
 
From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt =
<dick.hardt@gmail.com>
Date: Monday, July 13, 2020 =
at 03:56
To: <txauth@ietf.org>
Subject: Re: [Txauth] Turning =
polymorphism up to 11 (P11)
 
For those not familiar with "turning up =
to 11" https://en.wikipedia.org/wiki/Up_to_eleven
 
A counter argument to all of this =
polymorphism is that the AS is sending back the granted =
authorization. While pushing type detection to the AS to provide a =
simpler interface for the Client, it seems counterproductive if the =
Client has to do the same. A consistent response from the AS will be =
simpler for the Client, but would then also be different then =
what the Client originally requested from the GS.
 
On Fri, Jul 10, 2020 at =
6:01 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Taking Justin's model of =
strings being shortened versions of OAuth scopes, adding in the "type" =
property from RAR, and defining a default type, we *could* add a bunch =
of polymorphism. (I have not implemented the code below, but it looks =
doable assuming I have not overloaded a type in the same context)
 
/Dick
 
 
Let's start with a request for 2 authorizations using OAuth =
scopes, one for writing and the other for reading:
 
(1)
{
    "authorizations": {
        "writer": [
            { 
                =
"type": "oauth_scope",
      =
          "scope": =
["create","update","delete"]
      =
      }
      =
  ],
        "reader": =
[
            { 
                =
"type": "oauth_scope",
      =
          "scope": ["read","list"]
            }
        ]
    }
}
 
We can ask for just one token with all =
the same capabilities:
(2)
{
    "authorizations": [
        { 
            "type": =
"oauth_scope",
          =
  "scope": ["create","update","delete"]
        },
        { 
            "type": =
"oauth_scope",
          =
  "scope": ["read","list"]
      =
  }
    ]
}
 
Of course (2) can be simplified as:
(3)
{
    =
"authorizations": [
        { 
            "type": =
"oauth_scope",
          =
  "scope": ["create","update","delete","read","list"]
        }
    ]
}
 
Now let's say that in "oauth_scope", =
the array of scopes can also be a space separated string. So the =
following is equivalent:
(4)
{
    "authorizations": [
        { 
            "type": =
"oauth_scope",
          =
  "scope": "create update delete read list"
        }
    ]
}
 
Now let's say that the "oauth_scope" =
type is the default, so we can express it as:
(5)
{
    =
"authorizations": ["create","update","delete","read","list"]
}
 
Or use a space separated string instead of an array:
(6)
{
    =
"authorizations": "create update delete read list"
}
 
In summary, (2) - (6) will give the exact same result.
 
Let's add another authorization type to =
the request, "customer_information":
(7)
{
    "authorizations": [
        "create update delete read =
list",
        {
            "type": =
"customer_information",
      =
      "locations": [
      =
          "https://example.com/customers",
            ],
            "actions": [
                =
"read"
          =
  ],
          =
  "datatypes": [
      =
          "contacts",
                =
"photos"
          =
  ]
        }
    ]
}
 
And the space separated strings can be =
turned into individual strings and we have the equivalent request:
(8)
{
    =
"authorizations": [
        =
"create",
        =
"update",
        =
"delete",
        "read",
        "list",
        {
            "type": =
"customer_information",
      =
      "locations": [
      =
          "https://example.com/customers",
            ],
            "actions": [
                =
"read"
          =
  ],
          =
  "datatypes": [
      =
          "contacts",
                =
"photos"
          =
  ]
        }
    ]
}
 
Let's go back to our first example, and =
ask for 3 separate tokens:
(9)
{
    "authorizations": {
        "writer": "create update =
delete",
        "reader": =
"read list",
        "customer": =
[
            {
                =
"type": "customer_information",
      =
          "locations": [
                =
    "https://example.com/customers",
                =
],
                =
"actions": [
          =
          "read"
                =
],
                =
"datatypes": [
          =
          "contacts",
                =
    "photos"
      =
          ]
      =
      }    
        ]
    }
}
 
In a multi token request, if there is =
only one item in the array, we can shorten (9) to the following:
(10)
{
    =
"authorizations": {
        "writer": =
"create update delete",
      =
  "reader": "read list",
      =
  "customer": {
          =
  "type": "customer_information",
            "locations": [
                "https://example.com/customers",
            ],
            "actions": [
                =
"read"
          =
  ],
          =
  "datatypes": [
      =
          "contacts",
                =
"photos"
          =
  ]
        }  =
  
    }
}
-- Txauth mailing 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=_82D2C698-5D4C-4AAC-908B-92B6976C7696--


From nobody Mon Jul 13 06:48: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 2F2343A11F1 for ; Mon, 13 Jul 2020 06:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 FTDUaoiINGkZ for ; Mon, 13 Jul 2020 06:48:35 -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 740BB3A11EF for ; Mon, 13 Jul 2020 06:48:35 -0700 (PDT)
Received: from [192.168.1.7] (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 06DDmTNr005598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jul 2020 09:48:30 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Justin Richer 
In-Reply-To: 
Date: Mon, 13 Jul 2020 09:48:29 -0400
Cc: txauth@ietf.org, Mike Jones 
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C9868E7-0F82-42AC-AA0A-4D348F946320@mit.edu>
References: 
To: Dick Hardt 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 13 Jul 2020 13:48:37 -0000

The problem I have with this approach is that it artificially encodes =
two, and only two, tiers of client within the protocol needlessly. In my =
experience with systems that support dynamic registration, it=E2=80=99s =
not a black and white world like that. There are clients who can present =
:some: form of proof that they=E2=80=99re legit, but they haven=E2=80=99t =
been statically registered with the AS. (See MODRNA and OBUK, for =
instance.) There are clients whose identities are tied explicitly to the =
current user (like a Solid pod). There are clients who are =
=E2=80=9Cstatically=E2=80=9D registered but through a developer-facing =
portal, vs clients that are registered through an admin-only interface.=20=


As you say below, if the AS needs to differentiate between classes, it =
can decide to do so based on the key or identifier and the policies =
associated with it. I disagree with encoding these two tiers, or any =
tiers, into the protocol itself. This is ultimately a matter of the AS =
and its policy. In OAuth 2 there is no differentiation between a =
=E2=80=9Cstatic=E2=80=9D or =E2=80=9Cdynamic=E2=80=9D client ID, and yet =
an AS today can still differentiate between them =E2=80=94 because it =
knows the context in which the client ID was generated. It=E2=80=99s the =
same with the =E2=80=9Ckey handle=E2=80=9D concept in XYZ: the AS knows =
where the handle came from and can apply different policies regardless.=20=


Now, it=E2=80=99s a bigger question what the =E2=80=9Chandle=E2=80=9D =
refers to. XYZ started with it being tied to =E2=80=9Call client =
software information=E2=80=9D and then broke it into pieces, with the =
=E2=80=9Ckey=E2=80=9D portion being the cornerstone piece. While I still =
think this makes sense, I think that=E2=80=99s something that GNAP needs =
to figure out with more input from the community than just my own =
experience.

 =E2=80=94 Justin

> On Jul 10, 2020, at 4:16 PM, Dick Hardt  wrote:
>=20
> + Mike as he had interest in this topic
>=20
> My understanding is that an existing OAuth 2 client would use their =
current client id as their key handle, and a dynamic client (one that =
was not pre-registered) would be given a key handle by the AS.
>=20
> There are potentially some significant differences between a =
registered client, and a dynamic client to an AS.
>=20
> The AS is likely to know the identity of a registered client, and have =
different policies between the two types of clients. For example, a =
registered client may have access to a 'write" scope, while a dynamic =
client does not.
>=20
> The AS may have 100s or 1000s of registered clients, but a dynamic =
client may have 10Ms or 100Ms of instances, which may dictate separate =
storage services. Additionally, internal to the AS, which systems can =
write to the registered client store is going to be different than the =
dynamic client store.
>=20
> In XYZ, subsequent calls to the AS, both registered clients and =
dynamic clients pass a key handle, so there is no easy way to =
differentiate between the two.
>=20
> While the AS could embed semantics in the key handle identifier to =
indicate which identifiers are pre-registered vs dynamic, there are many =
cases where the AS does need to know the difference, so making the =
difference a feature of GNAP seems like a better path.
>=20
>=20


From nobody Mon Jul 13 06: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 EAAE63A11F9 for ; Mon, 13 Jul 2020 06:52:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 VAbL7Crk9lxm for ; Mon, 13 Jul 2020 06:52: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 A07CF3A11F1 for ; Mon, 13 Jul 2020 06:52:24 -0700 (PDT)
Received: from [192.168.1.7] (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 06DDqKMT007273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jul 2020 09:52:21 -0400
From: Justin Richer 
Message-Id: <1C24A62A-EDAA-4D70-988A-E121B0F9F27D@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7535ADB8-3B88-4F21-929F-3FD89193E2C7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 13 Jul 2020 09:52:20 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>     <69082870-1A99-4912-95EA-D1B7A1C967E5@mit.edu>    <4A77832C-9613-48BD-9CB2-EE3121E44DB0@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Polymorphism (Was: JSON Schema?)
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, 13 Jul 2020 13:52:28 -0000

--Apple-Mail=_7535ADB8-3B88-4F21-929F-3FD89193E2C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

An important data-point: RAR is a back-port of the functionality in XYZ =
to OAuth 2, and Torsten and I intended from the outset that the internal =
structure be kept in synch. In an ideal world, GNAP=E2=80=99s request =
data structure would be finished already and RAR would refer to it.

So I am actually proposing:

C) GNAP create a GNAP-specific schema for requesting resources (that =
allows expression in objects and strings), and that this be developed in =
concert with RAR in OAuth2 so that data structures that fit into a RAR =
query will also fit into a GNAP query.

The GNAP query should be a proper superset of OAuth scope and OAuth RAR.

Similarly how an OAuth =E2=80=9Cscope=E2=80=9D string should fit into a =
GNAP query, an OAuth =E2=80=9CRAR=E2=80=9D object should fit into a GNAP =
query. But that doesn=E2=80=99t mean that a GNAP query has to live with =
all of the limitations and contexts of those. For example, the string =
values in a GNAP query should be allowed to include spaces. OAuth scopes =
can=E2=80=99t have spaces because of an unfortunate limitation caused by =
the encoding in a query parameter, and they also can=E2=80=99t have =
non-ASCII characters without being encoded. We shouldn=E2=80=99t inherit =
those limitations here, and any JSON String should be allowed. =
Similarly, RAR objects need to make sense in the context of the OAuth =
=E2=80=9Cresource=E2=80=9D parameter, but that constraints doesn=E2=80=99t=
 apply to GNAP.

And yes, if a new query language is developed, I am saying it should be =
in a top-level parameter, as we should not be placing limitations on =
what that query language can affect. The GNAP language for requesting =
things in the access token should be scoped (pun intended) exactly to =
the access token(s) that it creates. A new query language could affect =
non-access-token responses as well, and that should be allowed. =
Combining these is obviously going to be tricky, but that happens any =
time you cross query languages. Putting them all into a lower-level =
bucket doesn=E2=80=99t make that go away.

 =E2=80=94 Justin

> On Jul 10, 2020, at 4:53 PM, Dick Hardt  wrote:
>=20
> Now that you are saying that the scope string is short hand for the =
object, the polymorphism makes sense. There is only one type in the =
array, and a string is shorthand for it. In this thread, you have talked =
about them being separate things.
>=20
> I just reread XYZ-08 section on resources, and there is no mention of =
polymorphism, or an example of it. Given your comments that XAuth should =
support both scopes and RAR, and that your proposed schema was based on =
RAR, that scopes and RAR objects were different things.
>=20
> Now it is clear that you are proposing that GNAP have a brand new =
schema for authorization queries. And on closer inspection of your =
examples in XYZ, there is no "type" in the property in the object.
>=20
> So now I see the choice being:=20
>=20
> A) reinvent a new, GNAP specific schema for requesting access to =
resources (XYZ)
> B) reuse the RAR and OAuth scope schemas (XAuth)
>=20
> If and when another resource requesting schemas is developed, you =
propose that it be a new, top level object. I'm proposing it be a new =
type in the authorizations container.
>=20
> Have I captured this accurately?
>=20
> /Dick
>=20
>=20
>=20
>=20
>=20
> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer > wrote:
>=20
>=20
>> On Jul 10, 2020, at 1:39 PM, Dick Hardt > wrote:
>>=20
>>=20
>>=20
>> On Thu, Jul 9, 2020 at 5:46 PM Justin Richer > wrote:
>>=20
>>=20
>>> On Jul 9, 2020, at 6:50 PM, Dick Hardt > wrote:
>>>=20
>>>=20
>>>=20
>>> On Thu, Jul 9, 2020 at 12:17 PM Justin Richer > wrote:
>>> On Jul 9, 2020, at 2:32 PM, Dick Hardt > wrote:
>>>>=20
>>>> Looks like you missed the point of my code example, as your =
response is focussed on the aspects I had in comments, so let me =
clarify.=20
>>>=20
>>> The point seemed to be about the overall complexity and readability, =
and that=E2=80=99s what I responded to.
>>>=20
>>> It was about the complexity and readability -- of those specific =
lines of code.
>>=20
>> But it=E2=80=99s not just about those lines, it=E2=80=99s about the =
context that those lines are in and the follow-on code paths that they =
cause. A lot of what you had =E2=80=9Cin comments=E2=80=9D for the XAuth =
example would have repeated what was already included in the XYZ =
example, as I pointed out.
>>=20
>> The context between those lines is pretty much the same. Yes, the =
XAuth example would have had to loop over each scope and RAR object, =
which is not that different than XYZ looping over each item, and the =
deciding how to process each item. My point is that checking the object =
type to decide what to do is an opaque decision vs checking an explicit =
type.
>=20
> The context is really not the same though, as you actually  point out =
here, and calling one style of type checking =E2=80=9Copaque=E2=80=9D =
vs. =E2=80=9Cexplicit=E2=80=9D is stylistic and not a helpful =
comparison. I=E2=80=99m not surprised to find that you think the way you =
did it is easier, especially given the disconnect we have of what the =
components of the array represent. I started with some of the =
type-field-based structures in early versions of XYZ and moved away from =
them after having bad experiences with building it. There are still a =
few parts of the XYZ protocol that have that style (the =E2=80=9Cuser=E2=80=
=9D section, for example) that I think need to be changed. I think that =
the data-type based style of polymorphism, coupled with using the =
left-hand-side value of object members to indicate type or identifier, =
is significantly simpler in design and implementation.
>=20
> Instead, I realized that we could get a cleaner protocol and better =
underlying code by dispatching based on the type within the protocol =
itself. I=E2=80=99ve gotten comments from a number of implementers that =
they like this design aspect, and I really like it myself.
>=20
>> =20
>>=20
>>>=20
>>> I've used JS type polymorphism to provide a cleaner API. For =
example, making an HTTP request. If I'm good with all the defaults, I =
can just provide the URI as a string, if I want to change a default, I =
provide an object and the URI is now a property of the object. =
Polymorphism allows the caller to have a simpler interface when it is a =
simple operation.
>>>=20
>>> Do you have any examples of JSON polymorphism used in other =
protocols besides in a JWT?
>>=20
>> Sounds to me like you=E2=80=99re describing exactly the kind of =
polymorphism that I=E2=80=99m talking about here. Use a string where it =
makes sense and an object where it makes sense, and there=E2=80=99s no =
ambiguity in calling the function. As you say, it's all about providing =
a cleaner API for the caller, and making things consistent in the model =
that the caller and provider are using. It takes a little bit of extra =
effort on the part of the API provider, but that=E2=80=99s where the =
complexity cost should be paid.
>>=20
>> My examples are not the same at all. The caller has a simpler version =
of passing the same object. XYZ is passing two different types, where a =
string means one thing, and an object means something else. The string =
is not a shorthand for the object.
>=20
> The string is, semantically, a shorthand for the object. That=E2=80=99s =
what I=E2=80=99ve been saying from the beginning, and I=E2=80=99ve put =
into several examples so far. There are two ways to add rights to an =
access token resulting from the request. So:
>=20
> {
>   =E2=80=9Cresources=E2=80=9D: [ =E2=80=9Cphoto=E2=80=9D ]
> }
>=20
> Can really be thought of as a shorthand, for example it could expand =
to this:
>=20
> {
>   =E2=80=9Cresources=E2=80=9D: [
>    {
>      =E2=80=9Cdatatypes=E2=80=9D: [ =E2=80=9Cpohoto=E2=80=9D ],
>      =E2=80=9Cactions=E2=80=9D: [ =E2=80=9Cread=E2=80=9D ],
>      =E2=80=9Clocations=E2=80=9D: [ =E2=80=9Chttps://server/photoapi/ =
=E2=80=9C ]
>    }
> }
>=20
> In this straw man, if the client wants write access to the API, it =
needs to use the object-style request to do so.
>=20
> It=E2=80=99s up to the AS, or really the API that it=E2=80=99s =
protecting, to figure out what that expansion really looks like, and how =
much of the more complex policy to expose. My example of processing only =
string-based resource requests was for the case where the AS only gives =
the shorthand version, and doesn=E2=80=99t allow detailed access into =
its protection policies. It=E2=80=99s not a different kind of request, =
it=E2=80=99s a shorthand, much like passing an identifier in lieu of a =
key to identify the client software instance making the call.
>=20
> But really, the point is that in both cases the string and the object =
both represent the same kind of thing: a piece of access rights that the =
client is requesting at the AS which gets put into the access token. =
Thus, having them together in a single array and processing them =
together makes sense to me. If you are thinking of strings and objects =
as completely different from each other,  you=E2=80=99d expect them to =
be handled separately, but I don=E2=80=99t think they are actually =
different because they both represent a view of the same underlying =
thing.
>=20
>=20
>>=20
>> In polymorphic APIs, it makes the code cleaner to pass a singular =
item when the API takes an array, or the API takes a string for the =
common property of the object which is the parameter.
>=20
> Yes, those are two examples of why it can be good. There are other =
reasons to apply it, like having an array with differently typed items =
that represent the same kind of thing underneath.
>=20
>> Here are some code examples for both:
>>=20
>> // passing a singular item, a simpler version of foo(['string'])
>> foo('string')
>> // passing a plurality of the same item
>> foo(['string1','string2','string3'])
>>=20
>> // implementation
>> foo =3D ( param ) =3D> {
>>     var a =3D []
>>     if (typeof param =3D=3D=3D 'string') {
>>         a[0] =3D param;
>>     } else if (typeof param =3D=3D=3D 'array') {
>>         a =3D param;
>>     }
>>     // process array a
>> }
>>=20
>>=20
>> // pass a uri as string and accept all defaults, a simpler version of =
bar({uri:'uri'})
>> bar('uri')
>> // pass an object with uri and method
>> bar({uri: 'uri', method: 'POST'})
>>=20
>> // implementation
>> bar =3D ( param ) =3D> {
>>     var p =3D DEFAULT_OBJ;
>>     if (typeof param =3D=3D=3D 'string') {
>>         p.uri =3D param;
>>     } else if (typeof param =3D=3D=3D 'object') {
>>         Object.keys(param).forEach( item =3D> {
>>             p[item] =3D param[item];
>>         });
>>     }
>>     // process p object
>> }
>>=20
>> In GNAP, we could take a string rather than an array for a scope =
parameter, for example:
>>=20
>> "scope": "read"
>>=20
>> instead of=20
>>=20
>> "scope": ["read"]
>>=20
>> OIDC uses the latter polymorphism for=20
>>=20
>> {=20
>>   "name": {"essential": true},
>>   "photo": null
>> }
>>=20
>> as being shorthand for=20
>>=20
>> {=20
>>   "name": {"essential": true},
>>   "photo": {"essential": false}
>> }
>>=20
>=20
> All of these are great examples of why object-type-based polymorphism =
is a good and powerful thing, and that=E2=80=99s the approach I=E2=80=99m =
saying we should use within the GNAP protocol. I would argue that the =
last one isn=E2=80=99t polymorphism so much as a default based on a null =
value (often taken as a special class of an =E2=80=9Cobject=E2=80=9D =
value anyway), but that=E2=80=99s splitting hairs.
>=20
>> =20
>>=20
>>> =20
>>>=20
>>>>=20
>>>> This line (which is determining the type of the item in the array):
>>>>=20
>>>> if (typeof item =3D=3D=3D string')
>>>>=20
>>>> is implicitly stating that the item is an oauth scope.=20
>>>=20
>>> No, it is not. It is saying that it is a resource request =
represented as a string. One way to represent a resource request as a =
string is an OAuth 2 style scope. And if you=E2=80=99re building up from =
an existing OAuth 2 system, then you could use a scope there. But =
that=E2=80=99s not the same as stating =E2=80=9Cthe item is a scope=E2=80=9D=
. In my examples, I had been trying to use the terminology that you were =
using, but I=E2=80=99m afraid that made things more unclear.
>>>=20
>>> We are comparing how to do it in XYZ vs XAuth -- so to make it =
apples and apples, the string is a scope, since that is the use case we =
are looking at.
>>=20
>> You can use a scope as the string, and if you want to think of all =
string values in this request as all being =E2=80=9Cscopes", that=E2=80=99=
s fine, but only if you can concede that the scope can mean whatever the =
AS wants. I think that perhaps you=E2=80=99re putting a certain amount =
of semantic weight to =E2=80=9Cscope=E2=80=9D that I=E2=80=99m missing, =
though.
>>=20
>> The string could be a scope, or it could be a claim such as in my =
"oidc" type example. The AS could support both scope and claims, and =
they could have overlapping string values.=20
>=20
> Both would represent =E2=80=9Cthings that the client wants back in the =
access token=E2=80=9D, and therefore the AS would need to differentiate. =
In that case I think it actually makes a lot more sense for the AS to =
define a more rich mechanism to request user information. In XYZ it =
could look like this:
>=20
> {
>    =E2=80=9Cresources=E2=80=9D: [
>      {
>         =E2=80=9Ctype=E2=80=9D: =E2=80=9Coidc_userinfo=E2=80=9D,
>         =E2=80=9Cdatatypes=E2=80=9D: [ =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Cphone=E2=80=9D, =E2=80=9Caddress=E2=80=9D, =E2=80=9Cprofile.photo=
" ]
>      }
>    ]
> }
>=20
> But defining the details of that kind of query is clearly outside the =
scope of GNAP (see below), and I think better suited to an identity =
protocol built on top of GNAP.
>=20
>>=20
>> =20
>>=20
>>> =20
>>>=20
>>>> Whereas it is explicit in this statement
>>>>=20
>>>> if (authorizations.type =3D=3D=3D 'oauth_scope')
>>>>=20
>>>> which I think it easier to understand what is happening (in my =
opinion of course).
>>>>=20
>>>> XYZ has types, they are just implicit. RAR has explicit types, and =
that does not look to be holding back RAR. I don't understand why you =
think having explicit types will hold us back.=20
>>>=20
>>> The =E2=80=9Ctype=E2=80=9D in RAR is a name spacing device to allow =
extensibility in different aspects of the request. This is at a lower =
layer than how they=E2=80=99re being applied here, and it therefore =
makes more sense at that layer. It=E2=80=99s a way for a particular API =
to define the dimensions that it cares about in its request. It=E2=80=99s =
not really an even comparison.
>>>=20
>>> And the type in XAuth authorizations is different schemas for making =
a request. "oauth_scope", "oauth_rar", and now "oidc". I would expect =
that there may be more in the future, and we have a clear way of adding =
schemas, and for the client and AS to know they are talking the same =
"language".
>>=20
>> And I=E2=80=99m saying that additional =E2=80=9Cschemas=E2=80=9D for =
requesting information should be defined separately from the GNAP =
schema. We disagree on this topic and we=E2=80=99re repeating ourselves.=20=

>>=20
>> The charter is pretty clear that GNAP should not define schemas, so I =
don't know what you mean by the "the GNAP schema"
>> =20
>=20
> That=E2=80=99s not true. The charter is clear that "nor is the group =
chartered to develop schemas for user information, profiles, or other =
identity attributes=E2=80=9D, but not that it=E2=80=99s not defining =
schemas for the other parts of the protocol. I=E2=80=99ve been clear on =
the other thread that we shouldn=E2=80=99t be defining a user schema, =
for attachment either to the access token or non-identifier items =
returned directly as plaintext or in assertions.=20
>=20
> By my read, we are fully within our charter to define schemas for =
authorization requests and responses, including both coarse and =
fine-grained access. I understand that it=E2=80=99s your stance that we =
should simply re-use OAuth 2=E2=80=99s =E2=80=9Cscope=E2=80=9D parameter =
for this, and I disagree with that. My proposed approach is to have a =
place within the GNAP protocol to plug in a =E2=80=9Cscope=E2=80=9D =
value if you have one, and for the AS to interpret it, but not to have =
that value always be a =E2=80=9Cscope=E2=80=9D.=20
>=20
>>=20
>>> =20
>>>=20
>>>> Do you want to let the string and object be anything the AS and RS =
decide they could mean?=20
>>>=20
>>> Yes. Just like the AS can decide that an OAuth scope could mean any =
number of things.
>>>=20
>>> That was what I was afraid of. While an OAuth scope could mean =
whatever the AS decides it wants to be, the Client and AS know it is an =
OAuth scope.
>>=20
>> How is that any different? I=E2=80=99m confused as to why you think =
it=E2=80=99s important to call this item a =E2=80=9Cscope=E2=80=9D so =
that you =E2=80=9Cknow what it is=E2=80=9D, but then you=E2=80=99re OK =
with =E2=80=9Cscope=E2=80=9D meaning literally anything.
>>=20
>> A scope string is one of a set of strings defined by the AS.
>>=20
>> The AS may use strings to define a different schema, such as which =
claims to return from a userinfo endpoint.
>>=20
>=20
> Exactly. A scope is a string that represents access to something =
controlled by the AS. The object also represents that same thing, but in =
multiple, more specific dimensions.=20
>=20
>>  I'm going to separate the my other responses into separate threads =
as they are different topics.
>>=20
>> /Dick
>>=20
>> =E1=90=A7
>=20
>=20
>  - Justin


--Apple-Mail=_7535ADB8-3B88-4F21-929F-3FD89193E2C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

An =
important data-point: RAR is a back-port of the functionality in XYZ to =
OAuth 2, and Torsten and I intended from the outset that the internal =
structure be kept in synch. In an ideal world, GNAP=E2=80=99s request =
data structure would be finished already and RAR would refer to it.

So I am actually =
proposing:

C) =
GNAP create a GNAP-specific schema for requesting resources (that allows =
expression in objects and strings), and that this be developed in =
concert with RAR in OAuth2 so that data structures that fit into a RAR =
query will also fit into a GNAP query.

The GNAP query should be =
a proper superset of OAuth scope and OAuth =
RAR.

Similarly how an OAuth =E2=80=9Cscope=E2=80=9D string should =
fit into a GNAP query, an OAuth =E2=80=9CRAR=E2=80=9D object should fit =
into a GNAP query. But that doesn=E2=80=99t mean that a GNAP query has =
to live with all of the limitations and contexts of those. For example, =
the string values in a GNAP query should be allowed to include spaces. =
OAuth scopes can=E2=80=99t have spaces because of an unfortunate =
limitation caused by the encoding in a query parameter, and they also =
can=E2=80=99t have non-ASCII characters without being encoded. We =
shouldn=E2=80=99t inherit those limitations here, and any JSON String =
should be allowed. Similarly, RAR objects need to make sense in the =
context of the OAuth =E2=80=9Cresource=E2=80=9D parameter, but that =
constraints doesn=E2=80=99t apply to GNAP.

And yes, if a new query language is =
developed, I am saying it should be in a top-level parameter, as we =
should not be placing limitations on what that query language can =
affect. The GNAP language for requesting things in the access token =
should be scoped (pun intended) exactly to the access token(s) that it =
creates. A new query language could affect non-access-token responses as =
well, and that should be allowed. Combining these is obviously going to =
be tricky, but that happens any time you cross query languages. Putting =
them all into a lower-level bucket doesn=E2=80=99t make that go =
away.

 =E2=80=
=94 Justin

On Jul 10, 2020, at 4:53 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

Now that you are saying that the =
scope string is short hand for the object, the polymorphism makes sense. =
There is only one type in the array, and a string is shorthand for it. =
In this thread, you have talked about them being separate things.

I just reread XYZ-08 =
section on resources, and there is no mention of polymorphism, or an =
example of it. Given your comments that XAuth should support both scopes =
and RAR, and that your proposed schema was based on RAR, that scopes and =
RAR objects were different things.

Now it is clear that you are proposing =
that GNAP have a brand new schema for authorization queries. And on =
closer inspection of your examples in XYZ, there is no "type" in the =
property in the object.

So now I see the choice being: 

A) reinvent a new, GNAP =
specific schema for requesting access to resources (XYZ)
B) reuse the RAR and OAuth scope schemas (XAuth)

If and when another =
resource requesting schemas is developed, you propose that it be a new, =
top level object. I'm proposing it be a new type in the authorizations =
container.

Have =
I captured this accurately?

/Dick





On Fri, Jul =
10, 2020 at 1:09 PM Justin Richer <jricher@mit.edu> wrote:


On Jul 10, 2020, at 1:39 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, Jul =
9, 2020 at 5:46 PM Justin Richer <jricher@mit.edu> wrote:


On Jul 9, 2020, at 6:50 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Thu, Jul 9, =
2020 at 12:17 PM Justin Richer <jricher@mit.edu> wrote:
On =
Jul 9, 2020, at 2:32 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Looks like you missed the point of my code example, as your =
response is focussed on the aspects I had in comments, so let me =
clarify. 

The point seemed to be about the =
overall complexity and readability, and that=E2=80=99s what I responded =
to.

It was about the complexity and =
readability -- of those specific lines of =
code.

But it=E2=80=99s not just about those =
lines, it=E2=80=99s about the context that those lines are in and the =
follow-on code paths that they cause. A lot of what you had =E2=80=9Cin =
comments=E2=80=9D for the XAuth example would have repeated what was =
already included in the XYZ example, as I pointed =
out.

The context between those lines is =
pretty much the same. Yes, the XAuth example would have had to loop over =
each scope and RAR object, which is not that different than XYZ looping =
over each item, and the deciding how to process each item. My point is =
that checking the object type to decide what to do is an opaque decision =
vs checking an explicit type.

The context is really =
not the same though, as you actually  point out here, and calling =
one style of type checking =E2=80=9Copaque=E2=80=9D vs. =E2=80=9Cexplicit=E2=
=80=9D is stylistic and not a helpful comparison. I=E2=80=99m not =
surprised to find that you think the way you did it is easier, =
especially given the disconnect we have of what the components of the =
array represent. I started with some of the type-field-based structures =
in early versions of XYZ and moved away from them after having bad =
experiences with building it. There are still a few parts of the XYZ =
protocol that have that style (the =E2=80=9Cuser=E2=80=9D section, for =
example) that I think need to be changed. I think that the data-type =
based style of polymorphism, coupled with using the left-hand-side value =
of object members to indicate type or identifier, is significantly =
simpler in design and implementation.

Instead, I realized that we could get a =
cleaner protocol and better underlying code by dispatching based on the =
type within the protocol itself. I=E2=80=99ve gotten comments from a =
number of implementers that they like this design aspect, and I really =
like it myself.

 


I've used JS type polymorphism to provide a cleaner API. For =
example, making an HTTP request. If I'm good with all the defaults, I =
can just provide the URI as a string, if I want to change a default, I =
provide an object and the URI is now a property of the object. =
Polymorphism allows the caller to have a simpler interface when it is a =
simple operation.

Do you have any examples of JSON polymorphism used in =
other protocols besides in a JWT?

Sounds to me like =
you=E2=80=99re describing exactly the kind of polymorphism that I=E2=80=99=
m talking about here. Use a string where it makes sense and an object =
where it makes sense, and there=E2=80=99s no ambiguity in calling the =
function. As you say, it's all about providing a cleaner API for the =
caller, and making things consistent in the model that the caller and =
provider are using. It takes a little bit of extra effort on the part of =
the API provider, but that=E2=80=99s where the complexity cost should be =
paid.

My examples are not the same at all. =
The caller has a simpler version of passing the same object. XYZ is =
passing two different types, where a string means one thing, and an =
object means something else. The string is not a shorthand for the =
object.

The string is, semantically, a =
shorthand for the object. That=E2=80=99s what I=E2=80=99ve been saying =
from the beginning, and I=E2=80=99ve put into several examples so far. =
There are two ways to add rights to an access token resulting from the =
request. So:

{
  =E2=80=9Cresources=E2=80=9D: [ =
=E2=80=9Cphoto=E2=80=9D ]
}

Can really be thought of as a =
shorthand, for example it could expand to this:

{
  =
=E2=80=9Cresources=E2=80=9D: [
  =
 {
     =E2=80=9Cdatatypes=E2=80=9D=
: [ =E2=80=9Cpohoto=E2=80=9D ],
    =
 =E2=80=9Cactions=E2=80=9D: [ =E2=80=9Cread=E2=80=9D ],
     =E2=80=9Clocations=E2=80=9D: [ =E2=80=9Chttps://server/photoapi/=E2=80=9C ]
   }
}

In this straw man, if the client wants =
write access to the API, it needs to use the object-style request to do =
so.

It=E2=80=99s=
 up to the AS, or really the API that it=E2=80=99s protecting, to figure =
out what that expansion really looks like, and how much of the more =
complex policy to expose. My example of processing only string-based =
resource requests was for the case where the AS only gives the shorthand =
version, and doesn=E2=80=99t allow detailed access into its protection =
policies. It=E2=80=99s not a different kind of request, it=E2=80=99s a =
shorthand, much like passing an identifier in lieu of a key to identify =
the client software instance making the call.

But really, the point is that in both =
cases the string and the object both represent the same =
kind of thing: a piece of access rights that the =
client is requesting at the AS which gets put into the access token. =
Thus, having them together in a single array and processing them =
together makes sense to me. If you are thinking of strings and objects =
as completely different from each other,  you=E2=80=99d expect them =
to be handled separately, but I don=E2=80=99t think they are actually =
different because they both represent a view of the same underlying =
thing.



In polymorphic APIs, it =
makes the code cleaner to pass a singular item when the API takes an =
array, or the API takes a string for the common property of the object =
which is the parameter. 

Yes, those are two =
examples of why it can be good. There are other reasons to apply it, =
like having an array with differently typed items that represent the =
same kind of thing underneath.

Here are some code examples for both:

// passing a singular item, a =
simpler version of foo(['string'])
foo('string')
// passing a plurality of the same =
item
foo(['string1','string2','string3'])

// =
implementation
foo =3D ( param ) =3D> =
{
    =
var a =3D []
  =
  if (typeof param =3D=3D=3D 'string') {
        a[0] =3D=
 param;
  =
  } else if (typeof param =3D=3D=3D 'array') {
        a =3D =
param;
  =
  }
  =
  // process array a
}


// =
pass a uri as string and accept all defaults, a simpler version of =
bar({uri:'uri'})
bar('uri')
// pass an object with uri and method
bar({uri: 'uri', method: =
'POST'})

// =
implementation
bar =
=3D ( param ) =3D> {
    var p =3D DEFAULT_OBJ;
    if (typeof param =3D=3D=
=3D 'string') {
        p.uri =3D param;
    } else if (typeof =
param =3D=3D=3D 'object') {
        Object.keys(param).forEach( item =
=3D> {
  =
          p[item] =3D =
param[item];
  =
      });
    }
    // process p object
}

In GNAP, we could take a string rather than an array for a =
scope parameter, for example:

"scope": "read"

instead of 

"scope": ["read"]

OIDC uses the latter polymorphism for 

{ 
  "name": {"essential": true},
 =
 "photo": null
}

as being shorthand for 

{ 
  "name": {"essential": true},
 =
 "photo": {"essential": false}
}


All of these are great =
examples of why object-type-based polymorphism is a good and powerful =
thing, and that=E2=80=99s the approach I=E2=80=99m saying we should use =
within the GNAP protocol. I would argue that the last one isn=E2=80=99t =
polymorphism so much as a default based on a null value (often taken as =
a special class of an =E2=80=9Cobject=E2=80=9D value anyway), but =
that=E2=80=99s splitting hairs.

 

 


This line (which is =
determining the type of the item in the array):

if (typeof item =3D=3D=3D =
string')

is implicitly =
stating that the item is an oauth scope. 

No, it is not. It is =
saying that it is a resource request represented as a string. One way to =
represent a resource request as a string is an OAuth 2 style scope. And =
if you=E2=80=99re building up from an existing OAuth 2 system, then you =
could use a scope there. But that=E2=80=99s not the same as stating =
=E2=80=9Cthe item is a scope=E2=80=9D. In my examples, I had been trying =
to use the terminology that you were using, but I=E2=80=99m afraid that =
made things more unclear.

We are comparing how to =
do it in XYZ vs XAuth -- so to make it apples and apples, the string is =
a scope, since that is the use case we are looking =
at.

You can use a scope as the string, and =
if you want to think of all string values in this request as all being =
=E2=80=9Cscopes", that=E2=80=99s fine, but only if you can concede that =
the scope can mean whatever the AS wants. I think that perhaps you=E2=80=99=
re putting a certain amount of semantic weight to =E2=80=9Cscope=E2=80=9D =
that I=E2=80=99m missing, though.

The string could be a =
scope, or it could be a claim such as in my "oidc" type example. The AS =
could support both scope and claims, and they could have overlapping =
string values. 

Both would represent =
=E2=80=9Cthings that the client wants back in the access token=E2=80=9D, =
and therefore the AS would need to differentiate. In that case I think =
it actually makes a lot more sense for the AS to define a more rich =
mechanism to request user information. In XYZ it could look like =
this:

{
   =E2=80=9Cresources=E2=80=9D=
: [
     {
 =
       =E2=80=9Ctype=E2=80=9D: =
=E2=80=9Coidc_userinfo=E2=80=9D,
    =
    =E2=80=9Cdatatypes=E2=80=9D: [ =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Cphone=E2=80=9D, =E2=80=9Caddress=E2=80=9D, =E2=80=9Cprofile.photo=
" ]
     }
 =
  ]
}

But defining the details of that kind =
of query is clearly outside the scope of GNAP (see below), and I think =
better suited to an identity protocol built on top of GNAP.


 

 

Whereas it is explicit in this statement

if (authorizations.type =3D=3D=3D =
'oauth_scope')

which I think it easier =
to understand what is happening (in my opinion of course).

XYZ has types, they are =
just implicit. RAR has explicit types, and that does not look to be =
holding back RAR. I don't understand why you think having explicit types =
will hold us back. 

The =E2=80=9Ctype=E2=80=9D=
 in RAR is a name spacing device to allow extensibility in different =
aspects of the request. This is at a lower layer than how they=E2=80=99re =
being applied here, and it therefore makes more sense at that layer. =
It=E2=80=99s a way for a particular API to define the dimensions that it =
cares about in its request. It=E2=80=99s not really an even =
comparison.

And the type in XAuth =
authorizations is different schemas for making a request. =
"oauth_scope", "oauth_rar", and now "oidc". I would expect that there =
may be more in the future, and we have a clear way of adding schemas, =
and for the client and AS to know they are talking the same =
"language".

And I=E2=80=99m saying that additional =
=E2=80=9Cschemas=E2=80=9D for requesting information should be defined =
separately from the GNAP schema. We disagree on this topic and we=E2=80=99=
re repeating ourselves. 

The charter is pretty =
clear that GNAP should not define schemas, so I don't know what you mean =
by the "the GNAP schema"
 

That=E2=80=99s not true. The charter is =
clear that "nor is the group chartered to develop schemas for user =
information, profiles, or other identity attributes=E2=80=9D, but not =
that it=E2=80=99s not defining schemas for the other parts of the =
protocol. I=E2=80=99ve been clear on the other thread that we =
shouldn=E2=80=99t be defining a user schema, for attachment either to =
the access token or non-identifier items returned directly as plaintext =
or in assertions. 

By my read, we are fully within our charter to define schemas =
for authorization requests and responses, including both coarse and =
fine-grained access. I understand that it=E2=80=99s your stance that we =
should simply re-use OAuth 2=E2=80=99s =E2=80=9Cscope=E2=80=9D parameter =
for this, and I disagree with that. My proposed approach is to have a =
place within the GNAP protocol to plug in a =E2=80=9Cscope=E2=80=9D =
value if you have one, and for the AS to interpret it, but not to have =
that value always be a =E2=80=9Cscope=E2=80=9D. 


 

Do you want to let the string and object be anything the AS =
and RS decide they could mean? 

Yes. Just like the AS =
can decide that an OAuth scope could mean any number of =
things.

That was what I was afraid of. While an =
OAuth scope could mean whatever the AS decides it wants to be, the =
Client and AS know it is an OAuth =
scope.

How is that any different? I=E2=80=99m =
confused as to why you think it=E2=80=99s important to call this item a =
=E2=80=9Cscope=E2=80=9D so that you =E2=80=9Cknow what it is=E2=80=9D, =
but then you=E2=80=99re OK with =E2=80=9Cscope=E2=80=9D meaning =
literally anything.

A scope string is one of a set of =
strings defined by the AS.

The AS may use strings to define a different schema, such as =
which claims to return from a userinfo endpoint.


Exactly. A scope is a string that =
represents access to something controlled by the AS. The object also =
represents that same thing, but in multiple, more specific =
dimensions. 

 I'm going to separate the my other responses into =
separate threads as they are different topics.

/Dick

3D""=E1=90=A7


 - =
Justin


=

--Apple-Mail=_7535ADB8-3B88-4F21-929F-3FD89193E2C7--


From nobody Mon Jul 13 07:08: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 E6E4A3A121D for ; Mon, 13 Jul 2020 07:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.629
X-Spam-Level: 
X-Spam-Status: No, score=-1.629 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.267, NICE_REPLY_A=-0.001, 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 5cHkj2YlfNsb for ; Mon, 13 Jul 2020 07:08:18 -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 B65F43A121B for ; Mon, 13 Jul 2020 07:08:17 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d21 with ME id 2e8E230044FMSmm03e8EnQ; Mon, 13 Jul 2020 16:08:15 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 13 Jul 2020 16:08:15 +0200
X-ME-IP: 86.238.65.197
From: Denis 
To: Dick Hardt 
Cc: "txauth@ietf.org" 
References:    <325bc015-1547-c56c-c1fe-67a97165785d@free.fr> 
Message-ID: <83480ab0-03bc-7cc9-d166-ece4c6b63861@free.fr>
Date: Mon, 13 Jul 2020 16:08: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="------------C727181D255E2393EAA81030"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 13 Jul 2020 14:08:22 -0000

This is a multi-part message in MIME format.
--------------C727181D255E2393EAA81030
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Dick,

You wrote: "This looks pretty similar to your protocol drawing".

No. There is a fundamental difference with the sequencing of the flow of 
the exchanges where the (1) and (2) flows are inverted.

In your figure:

    The Client makes calls to the GS (1)
    The Client makes calls to the RS (2)

while in my figure:

    The Client makes calls to the RS (1)
    The Client makes calls to the AS (2)

In your figure, the first flow is with the GS, whereas in my figure the 
first flow is with the RS and there is a good reason for that:
the client first contacts the RS to know what the RS expects. The client 
indicates in its first exchange to the RS whether it wants to authenticate
or to perform another operation.  In the case of an authentication 
operation, the RS may respond to the client that is supports FIDO U2F
or that it is willing the client to present some attribute(s) from one 
or more AS.

Then after the client has to figure out whether the user is using FIDO 
and if not whether the user has an account with one of the AS.
In the later case, if there is a match then the client,/*after having 
received the user consent*/, may contact the appropriate AS to ask
for some attribute(s).

The same fundamental difference applies with 
draft-richer-transactional-authz-06 (XYZ) where the first exchange is 
done with the AS:
"The RC creates a transaction request and sends it to the AS".

This answers also in details to one of your comments:

    What looks to be missing from your proposal is:
    A) The Client making a call to the RS to discover what it needs from
    a GS, and which GS to ask, prior to (1).

This is not missing since this is the foundation of the architecture. 
The discovery mechanism at the RS has been described
in details in an earlier email with the following title: "Support of 
FIDO and data minimization by RSs".

The main figures are copied below (using ASCII):**

*+-----------------------------------+---------------------------------+
+Operation+Mathematical expression+
+-----------------------------------+---------------------------------+
+ Authentication+ Condition 1 OR Condition 2+
+-----------------------------------+---------------------------------+
+ Operation A OR Operation Z+ Condition 3 AND Condition 4+
+-----------------------------------+---------------------------------+

**Conditions table: **

+-------------+--------------+-----------------------------+----------+
+ Condition 1 + FIDO U2F 1.2 +++
+-------------+--------------+-----------------------------+----------+
+ Condition 2 + AS 1+ set 1 of a attributes types + +
+-------------+--------------+-----------------------------+----------+
+ Condition 3 + AS 2+ set 2 of a attributes types + Scope 21 +
   +-------------+--------------+-----------------------------+----------+
+ Condition 4 + AS 9+ set 3 of a attributes types-+ +
+-------------+--------------+-----------------------------+----------+
*
According to the operation announced by the Client, the RS returns to 
the Client both the mathematical expression
associated with that operation and the conditions included in that 
mathematical expression. The Client may then
present that information to the user in order to obtain the user consent 
in a standardized manner.

Another comment you made is:

    What looks to be missing from your proposal is:
    B) A mechanism for the Client to prove to the GS that it has
    gathered consent from the User.

The user consent should not be captured *by the GS*, since the GS would 
be in a position to apply a different consent decision
without letting it know to the user (or to the client).

The user consent must be captured *by the Client* and the Client must be 
able to verify that this consent has indeed been followed by the AS.

The authorization data managed at the RS by the RO is used by the Client 
to query the consent of the user in a standardized manner.
When, later on, the access token is returned to the Client by the AS, 
the Client (not the user) using that authorization data as well as
the decision of the user is able to verify that the requested attributes 
(and no more) are indeed present into the access token.

This is why access tokens may *not* be considered to be opaque to the 
Clients.

In my earlier email copied below, six major differences with XAuth from 
1) to 6) are listed.

Denis

> From 
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1
>
>
>       1.1
>       .
>       Parties
>
>
>
>     The parties and their relationships to each other:
>         +--------+                           +------------+
>         |  User  |                           |  Resource  |
>         |        |                           | Owner (RO) |
>         +--------+                           +------------+
>             |      \                       /      |
>             |       \                     /       |
>             |        \                   /        |
>             |         \                 /         |
>         +--------+     +---------------+     +------------+
>         | Client |---->|     Grant     |     |  Resource  |
>         |        | (1) |  Server (GS)  | _ _ |   Server   |
>         |        |<----|               |     |    (RS)    |
>         |        |     +---------------+     |            |
>         |        |-------------------------->|            |
>         |        |           (2)             |            |
>         |        |<--------------------------|            |
>         +--------+                           +------------+
>
>
> The lines without arrows represent relationships.
> The User trusts the Client
> The User trusts the GS
> The RO trusts the GS to issue access tokens for the RS
> The RS trusts the tokens issued by the RS
> The RO controls the RS
>
> The Client makes calls to the GS (1)
> The Client makes calls to the RS (2)
>
> This looks pretty similar to your protocol drawing.
>
> What looks to be missing from your proposal is:
>
> A) The Client making a call to the RS to discover what it needs from a 
> GS, and which GS to ask, prior to (1).
> B) A mechanism for the Client to prove to the GS that it has gathered 
> consent from the User.
>
> The current protocol does not require the GS to interact with either 
> the User, the RO, or the RS -- which looks to me to meet your 
> privacy goals.
>
> ᐧ
>
> On Fri, Jul 10, 2020 at 6:06 AM Denis  > wrote:
>
>     Hi Dick,
>
>>     Hi Denis, thanks for sharing the model. I don't fully understand
>>     what is going on, questions inserted:
>     Responses are inserted.
>>
>>     FWIW: having paragraphs start with the step number (1), (2) etc.
>>     would make it easier to map between the description and the diagram.
>>
>>     On Thu, Jul 9, 2020 at 3:26 AM Denis >     > wrote:
>>
>>         This is a new thread.
>>
>>         Preamble: This model is quite different from the XAuth model.
>>         In particular, a RO has no relationship with any AS and a
>>         Client does not need to be associated with any AS prior to
>>         any access to a RS.
>>
>>         A key point of this model is that the user's consent is
>>         handled locally by the Client and hence no AS nor RS is
>>         handling a man machine interface
>>         for the user consent. This allows to support locally the user
>>         consent for multiple ASs while keeping all ASs ignorant about
>>         the choices of the user
>>         made for accessing a particular RS.
>>         *
>>
>>         **+--------++------------+
>>         |User||Resource|
>>         ||| Owner (RO) |
>>         +--------++------------+
>>         |\|
>>         |\|
>>         |\|
>>         |\|
>>         +-----------++---------------++------------+
>>         ||---->| Authorization |||
>>         || (2) |Server (AS)|||
>>         ||<----||||
>>         |Client|+---------------+||
>>         ||-------------------------->|Resource|
>>         |User|(1)|Server|
>>         |Consent|<--------------------------|(RS)|
>>         |element|||
>>         ||-------------------------->||------>
>>         ||(3)||(4)
>>         ||<--------------------------||<------
>>         +-----------++------------+
>>         *
>>         The flow of operations is as follows:
>>
>>         The Client (which may have been previously authenticated
>>         using FIDO)
>>
>>     Which party has the client authenticated to? The client
>>     authenticating with FIDO is confusing to me. FIDO is usually how
>>     a user authenticates.
>
>     If the user has previously opened a user account with the RS using
>     FIDO, then the client may be authenticated by the RS using FIDO.
>     In such a case, the user is already known to the RS under a
>     pseudonym specific to the RS. It may (or may not) have previously
>     presented access tokens
>     to that RS.
>
>>     contacts the RS and after some dialogue with the RS selects an
>>     operation
>>     How does the client know which RS to contact?
>
>     For a private usage, the user may use DuckDuckGo, while for
>     business he may use an application from his company which lists
>     various services
>     available in the context of his job or his position. Some services
>     may be freely available to all the employees of the company with
>     any authentication,
>     e.g. the phone book of the employees may be freely available on
>     the intranet of the company, while some other services may require
>     the user
>     to authenticate to the AS from the company.
>
>>     that it wants to perform on the RS (1a). Note that it may also
>>     indicate directly the operation that it wants to perform on the
>>     RS without any prior dialogue.
>>
>>         In return (1b), the RS informs the Client about which
>>         attributes are needed by the RS for performing the requested
>>         operation and from which Attributes Servers
>>         they may be obtained.
>>
>>     (1a) and (1b) are not labeled. There is only (1)
>
>     (1a) is the first exchange for (1) with the arrow from left to
>     right, while (1b) is the response with the arrow from right to left.
>     The same applies to the other exchanges i.e. (2) , (3) and (4).
>
>>
>>         This information is specifically marked to indicate that it
>>         shall be handled by the "User Consent element" from the Client.
>>
>>     Why? What is the significance of this? Which information is marked?
>
>     In the response, a specific identifier or a magic number is used
>     to indicate the start and the length of the information block
>     to be sent to the "User Consent element" supported by the Client.
>
>>     The presentation of that information is up to the man machine
>>     interface supported by the "User Consent element" from the Client.
>>
>>
>>     Which information?
>
>     The attributes that are needed by the RS for performing a
>     requested operation and from which Attributes Servers they may be
>     obtained.
>
>>
>>         The user can see which attributes are requested by the RS for
>>         performing the requested operation and, if it consents, the
>>         Client contacts one or more
>>         appropriate Authorization Servers (2a).
>>
>>     How does the client know which AS(s) to contact?
>
>     For each AS trusted by the RS to perfom a given operation, the RS
>     should indicate a user-friendly name and a URL of the AS.
>
>>         The user consent is hence captured locally by the Client
>>         (i.e. there is no dialogue with any AS nor any RS).
>>
>>
>>     No dialogue with who? The client is calling the AS is it not?
>
>     For the user consent, there is no external call since it is
>     handled locally. Afterwards, there is a call to the AS(s) selected
>     by the user.
>
>>
>>         When the Client got the access tokens from these
>>         authorization servers (2b), it sends all of them in a single
>>         request to the RS (3a).
>>
>>
>>     So the RS must trust the AS that issued the tokens. And the AS
>>     must trust the Client to have gathered consent.
>     Theses two assertions are correct.
>>     And the AS must have a relationship with the user.
>
>     Only when the user chooses one AS while giving its consent, then
>     the user must have a relationship with the selected AS.
>
>>     It is unclear what role the RO is playing in this though. The RO
>>     and RS look to be the same entity from all the other parties.
>
>     A RO, as indicated on the figure, has only a relationship with one
>     RS: it has no relationship with any AS.
>     The RS trusts the AS but the AS does not know which RSs are
>     trusting it.
>
>>
>>     From my current understanding, at a high level, this looks like
>>     it is supported by GNAP with the addition of the discovery step (1).
>
>     Well, it is fairly different :
>
>         1) The first major difference is that there is no arrow
>         between the RO and the AS. No protocol or "out-of-bands" means
>         are necessary.
>
>         2) The second major difference is that there is no arrow
>         between the AS and the RS. No protocol is necessary.
>
>         3) The third major difference is that the AS does not know any
>         RS. Note: for backward compatibility reasons, an exception
>         might exist for "old" Auth 2.0 ASs.
>
>         4) The fourth major difference is that the XAuth spec. is
>         rather vague to describe when and by who the user consent is
>         captured:
>             XAuth states on page 4: "User consent is /often /required
>         at the GS". In that case, the GS is able to act as Big
>         Brother. No other case is described.
>
>         5) The fifth major difference is that the data that is
>         transferred to a "User Consent Element" to capture the user
>         consent. That data can be standardized.
>             Moreover, it will also be possible to standardize the
>         dialogue between the RO and the RS. The RO will then be able
>         to manage remotely the authorization tables.
>             See my email sent on June 6, with the following subject:
>         "Support of FIDO and data minimization by RSs".
>
>         6) Another difference is the following: since there is no
>         interaction between the RO and the AS, "authorizations from
>         the RO" as described in XAuth do not exist. 
>
>>     There have been a number of proposals for doing this discovery,
>>     and perhaps now there are enough use cases to look at
>>     standardizing something.
>>     No interaction is needed between the AS and the User as the
>>     Client is providing enough "information" in the user object of
>>     the Grant Request
>>     to satisfy the AS releasing the access tokens.
>     Not sure I understand correctly this last sentence.
>>
>>     Perhaps as I understand the model in more detail I will
>>     understand what is missing from GNAP (besides the discovery step).
>
>     It would be hard to say "what is missing" from XAuth since the
>     foundations are not the same.
>
>     In order to compare different architectures, there is the need to
>     start with the trust relationships.
>     Unfortunately, the word "trust" is absent in the main body of
>     draft-hardt-xauth-protocol-12. Hence,
>     the description of the trust relationships is missing.
>
>     Denis
>
>>
>>     /Dick
>>
>>     (I've skipped reviewing the delegation use case below until I
>>     understand the simple use case)
>>
>>
>>         End of the story for a simple access
>>
>>
>>         Start of a subsequent story for a delegation case
>>
>>         Let us now suppose that the RS is unable to fulfil the
>>         request by its own and that it needs to contact another RS.
>>         RS1 contacts RS2 (4a) and indicates the operation
>>         that it wants to perform on RS2 (that operation may not be
>>         the same as the original operation). In return (4b), RS2
>>         informs RS1 about which attributes are needed
>>         by RS2 for performing the requested operation and from which
>>         Attributes Servers they may be obtained. RS1 forwards that
>>         information to the Client.
>>
>>         This information is marked to indicate that it shall be
>>         handled by the "User Consent element" from the Client. The
>>         presentation of that information is up to the man machine
>>         interface from the Client. The user can see which attributes
>>         are requested by RS2 for performing the new requested
>>         operation and, if it consents, the Client contacts one or more
>>         appropriate Authorization Servers. The user consent is hence
>>         captured locally by the "User Consent element" from the
>>         Client. (i.e. there is no dialogue with any AS, nor RS1, nor
>>         RS2).
>>
>>         When the Client got the access token(s) from the
>>         authorization server(s), it sends all of them in a single
>>         request to RS1. RS1 then forwards the additional access
>>         token(s) to RS2.
>>
>>
>>         Some observations:
>>
>>         The user nor the Client are linked with any particular AS. A
>>         user may use today an AS of the Bank of America and may
>>         change tomorrow to the Bank of Missouri.
>>         As soon as he will be registered with the Bank of Missouri,
>>         he will be able to get access tokens from the AS of the Bank
>>         of Missouri. The AS of Bank of America
>>         has not been able to know where its access tokens have been
>>         used. This will be the same for AS of the Bank of Missouri.
>>         There is no need for any direct dialogue
>>         between any AS and any RS at the time a client is making an
>>         access. There is no need for any RO to contact any AS.
>>
>>         This model has been constructed following a "Privacy by
>>         Design" approach.
>>
>>         Denis
>>
>>         -- 
>>         Txauth mailing list
>>         Txauth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/txauth
>>
>>     ᐧ
>
>


--------------C727181D255E2393EAA81030
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Dick,

    


    

    
You wrote: "This looks pretty similar
      to your protocol drawing".

      

    

    
No. There is a fundamental difference
      with the sequencing of the flow of the exchanges where the (1) and
      (2) flows are inverted. 

    

    


    

    
In your figure:

    

    

      

        
The Client makes calls to the GS (1)

        
The Client makes calls to the RS (2)

      

      
while in my figure:

      

        

          
The Client makes calls to the RS (1)

          
The Client makes calls to the AS (2)

        

      

    

    
In your figure, the first flow is with
      the GS, whereas in my figure the first flow is with the RS and
      there is a good reason for that: 

      the client first contacts the RS to know what the RS expects. The
      client indicates in its first exchange to the RS whether it wants
      to authenticate 

      or to perform another operation.  In the case of an authentication
      operation, the RS may respond to the client that is supports FIDO
      U2F 

      or that it is willing the client to present some attribute(s) from
      one or more AS.

    


    

    
Then after the client has to figure out
      whether the user is using FIDO and if not whether the user has an
      account with one of the AS.

    
In the later case, if there is a match
      then the client, *after having received the user consent*,
      may contact the appropriate AS to ask 

      for some attribute(s). 

    

    


    

    
The same fundamental difference applies
      with draft-richer-transactional-authz-06 (XYZ) where the first
      exchange is done with the AS:

    
"The RC creates a transaction request
      and sends it to the AS".

    


    

    
This answers also in details to one of
      your comments:

    

      

        
What looks to be missing from your proposal is:

        
A) The Client making a call to the RS to discover what it
          needs from a GS, and which GS to ask, prior to (1).

      

    

    
This is not missing since this is the
      foundation of the architecture. The discovery mechanism at the RS
      has been described 

      in details in an earlier email with the following title: "Support
      of FIDO and data minimization by RSs".

    


    

    

    
The main figures are copied below
      (using ASCII):
      
 
              +-----------------------------------+---------------------------------+

                +           Operation               +      Mathematical
              expression    +

                +-----------------------------------+---------------------------------+

                + Authentication                    +
              Condition 1 OR Condition 2     
              +

                +-----------------------------------+---------------------------------+

                + Operation A OR
              Operation Z        +
              Condition 3 AND Condition 4    
              +

                +-----------------------------------+---------------------------------+

              

            Conditions
              table: 

              

                +-------------+--------------+-----------------------------+----------+

                + Condition 1 +
              FIDO U2F 1.2 +                            
              +          +

                +-------------+--------------+-----------------------------+----------+

                + Condition 2 +
              AS 1         + set
              1 of a attributes types +          +

                +-------------+--------------+-----------------------------+----------+

                + Condition 3 +
              AS 2         + set
              2 of a attributes types + Scope 21 +

                +-------------+--------------+-----------------------------+----------+

                + Condition 4 +
              AS 9         + set
              3 of a attributes types-+          +

                +-------------+--------------+-----------------------------+----------+

          

        According to the operation announced by the Client, the RS
        returns to the Client both the mathematical expression 

        associated with that operation and the conditions included in
        that mathematical expression. The Client may then 

        present that information to the user in order to obtain the user
        consent in a standardized manner.

      

    

    
Another comment you made is:

    

      
What looks to be missing from your proposal is:

      
B) A mechanism for the Client to prove to the GS that it has
        gathered consent from the User.

    

    
The user consent should not be captured *by the GS*, since the
      GS would be in a position to apply a different consent decision 

      without letting it know to the user (or to the client).

    


      The user consent must be captured *by the Client* and the Client
      must be able to verify that this consent has indeed been followed
      by the AS. 

    

    


    

    
The authorization data managed at the RS by the RO is used by
      the Client to query the consent of the user in a standardized
      manner.

    
When, later on, the access token is returned to the Client by
      the AS, the Client (not the user) using that authorization data as
      well as 

      the decision of the user is able to verify that the requested
      attributes (and no more) are indeed present into the access token.
      

      

      This is why access tokens may *not* be considered to be opaque to
      the Clients.

    


    

    
In my earlier email copied below, six major differences with
      XAuth from 1) to 6) are listed.

    


    

    
Denis

      

    

    

      
      
From https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1
        


          

            
1.1.  Parties


   The parties and their relationships to each other:


            
       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+



          

          

            


            

            
The lines without arrows represent relationships. 

          

        

        
The User trusts the Client

        
The User trusts the GS

        
The RO trusts the GS to issue access tokens for the RS

        
The RS trusts the tokens issued by the RS

        
The RO controls the RS

        


        

        
The Client makes calls to the GS (1)

        
The Client makes calls to the RS (2)

        


        

        
This looks pretty similar to your protocol drawing.

        


        

        
What looks to be missing from your proposal is:

        


        

        
A) The Client making a call to the RS to discover what it
          needs from a GS, and which GS to ask, prior to (1).

        
B) A mechanism for the Client to prove to the GS that it
          has gathered consent from the User.

        


        

        
The current protocol does not require the GS to interact
          with either the User, the RO, or the RS -- which looks to me
          to meet your privacy goals.

        


        

      

      
ᐧ

      

      

        
On Fri, Jul 10, 2020 at 6:06
          AM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hi Dick,

            


            

            

              

                
Hi Denis, thanks for sharing the model. I
                  don't fully understand what is going on, questions
                  inserted:

              

            

            Responses are inserted.

            

              

                

                  


                  

                  
FWIW: having paragraphs start with the step
                    number (1), (2) etc. would make it easier to map
                    between the description and the diagram.

                

                

                

                  
On Thu, Jul 9, 2020
                    at 3:26 AM Denis <denis.ietf@free.fr>
                    wrote:

                  

                  

                    

                      

                        
This is a new thread.

                            

                            Preamble: This model is quite different from
                            the XAuth model. 

                            In particular, a RO has no relationship with
                            any AS and a Client does not need to be
                            associated with any AS prior to any access
                            to a RS.

                            

                            A key point of this model is that the user's
                            consent is handled locally by the Client and
                            hence no AS nor RS is handling a man machine
                            interface 

                            for the user consent. This allows to support
                            locally the user consent for multiple ASs
                            while keeping all ASs ignorant about the
                            choices of the user 

                            made for accessing a particular RS.

                            

                              

                                    
                                +--------+                          
                                +------------+

                                       |  User 
                                |                          
                                |  Resource 
                                |

                                       |        |                          
                                | Owner (RO) |

                                       +--------+        
                                                  +------------+

                                           |      \                             
                                |

                                           |       \                            
                                |

                                           |       
                                \                           
                                |

                                           |        
                                \                          
                                |

                                    +-----------+     +---------------+    
                                +------------+

                                    |           |---->|
                                Authorization |     |           
                                |

                                    |           |
                                (2) |  Server (AS) 
                                |     |           
                                |

                                    |           |<----|              
                                |     |           
                                |

                                    |  Client  
                                |     +---------------+    
                                |            |

                                    |           |-------------------------->| 
                                Resource  |

                                    |   User   
                                |           (1)            
                                |   Server  
                                |

                                    |  Consent 
                                |<--------------------------|   
                                (RS)    |

                                    |  element 
                                |                          
                                |            |

                                    |           |-------------------------->|           
                                |------>

                                    |           |          
                                (3)             |           
                                |  (4)

                                    |           |<--------------------------|           
                                |<------

                                    +-----------+                          
                                +------------+

                            

                            The flow of operations is as follows:

                            

                            The Client (which may have been previously
                            authenticated using FIDO) 

                      

                    

                  

                  
Which party has the client authenticated to? The
                    client authenticating with FIDO is confusing to me.
                    FIDO is usually how a user authenticates.

                

              

            

            
If the user has previously opened a user account with the
              RS using FIDO, then the client may be authenticated by the
              RS using FIDO.

              In such a case, the user is already known to the RS under
              a pseudonym specific to the RS. It may (or may not) have
              previously presented access tokens 

              to that RS.

            

            

              

                

                  
 contacts the RS and after
                      some dialogue with the RS selects an operation 

                    

                  
How does the client know which RS to contact?

                

              

            

            
For a private usage, the user may use DuckDuckGo, while
              for business he may use an application from his company
              which lists various services 

              available in the context of his job or his position. Some
              services may be freely available to all the employees of
              the company with any authentication,

              e.g. the phone book of the employees may be freely
              available on the intranet of the company, while some other
              services may require the user 

              to authenticate to the AS from the company.

            

              

                

                  
 that it wants to perform on
                      the RS (1a). Note that it may also indicate
                      directly the operation that it wants to perform on
                      the RS without any prior dialogue. 

                    

                  

                    

                      

                        
 In return (1b), the RS
                            informs the Client about which attributes
                            are needed by the RS for performing the
                            requested operation and from which
                            Attributes Servers 

                            they may be obtained. 

                          

                      

                    

                  

                  
(1a) and (1b) are not labeled. There is only (1)
                    

                  

                

              

            

            
(1a) is the first exchange for (1) with the arrow from
              left to right, while (1b) is the response with the arrow
              from right to left. 

              The same applies to the other exchanges i.e. (2) , (3) and
              (4).

            

            

              

                

                  

                    

                      

                        
 

                            This information is specifically marked to
                            indicate that it shall be handled by the
                            "User Consent element" from the Client. 

                          

                      

                    

                  

                  
Why? What is the significance of this? Which
                    information is marked?

                

              

            

            
In the response, a specific identifier or a magic number
              is used to indicate the start and the length of the
              information block  

              to be sent to the "User Consent
                element" supported by the Client.

            

            

              

                

                  

                    
The presentation of that
                        information is up to the man machine interface
                        supported by the "User Consent element" from the
                        Client. 

                      

                  

                  


                  

                  
Which information? 

                  

                

              

            

            
The attributes that are needed by the
                RS for performing a requested operation and from which
                Attributes Servers they may be obtained.

            

              

                

                  

                    

                      

                        
 

                            The user can see which attributes are
                            requested by the RS for performing the
                            requested operation and, if it consents, the
                            Client contacts one or more 

                            appropriate Authorization Servers (2a). 

                      

                    

                  

                  
How does the client know which AS(s) to contact?

                

              

            

            
For each AS trusted by the RS to perfom a given
              operation, the RS should indicate a user-friendly name and
              a URL of the AS. 

            

            

              

                

                  

                    

                      

                        
The user consent is hence
                            captured locally by the Client (i.e. there
                            is no dialogue with any AS nor any RS).

                          

                      

                    

                  

                  


                  

                  
No dialogue with who? The client is calling the
                    AS is it not? 

                  

                

              

            

            
For the user consent, there is no external call since it
              is handled locally. Afterwards, there is a call to the
              AS(s) selected by the user.

            

              

                

                  

                    

                      

                        
 

                            When the Client got the access tokens from
                            these authorization servers (2b), it sends
                            all of them in a single request to the RS
                            (3a).

                          

                      

                    

                  

                  


                  

                  
So the RS must trust the AS that issued the
                    tokens. And the AS must trust the Client to have
                    gathered consent.

                

              

            

            Theses two assertions are correct.

            

              

                

                  
 And the AS must have a relationship with the
                    user. 

                

              

            

            
Only when the user chooses one AS while giving its
              consent, then the user must have a relationship with the
              selected AS.

            

              

                

                  
It is unclear what role the RO is playing in this
                    though. The RO and RS look to be the same entity
                    from all the other parties.

                

              

            

            
A RO, as indicated on the figure, has only a relationship
              with one RS: it has no relationship with any AS. 

              The RS trusts the AS but the AS does not know which RSs
              are trusting it.

            

              

                

                  


                  

                  
From my current understanding, at a high level,
                    this looks like it is supported by GNAP with the
                    addition of the discovery step (1). 

                

              

            

            
Well, it is fairly different : 

            

            

              
1) The first major difference is that there is no arrow
                between the RO and the AS. No protocol or "out-of-bands"
                means are necessary. 

              

              
2) The second major difference is that there is no
                arrow between the AS and the RS. No protocol is
                necessary. 

              
3) The third major difference is that the AS does not
                know any RS. Note: for backward compatibility reasons,
                an exception might exist for "old" Auth 2.0 ASs.

              

              
4) The fourth major difference is that the XAuth spec.
                is rather vague to describe when and by who the user
                consent is captured: 

                    XAuth states on page 4: "User consent is often required
                at the GS". In that case, the GS is able to act as Big
                Brother. No other case is described.

              

              5) The fifth major difference is that the data that is
              transferred to a "User Consent Element" to capture the
              user consent. That data can be standardized. 

                  Moreover, it will also be possible to standardize the
              dialogue between the RO and the RS. The RO will then be
              able to manage remotely the authorization tables.

                  See my email sent on June 6, with the following
              subject: "Support of FIDO and data minimization by RSs".

              

              6) Another difference is the following: since there is no
              interaction between the RO and the AS, "authorizations
              from the RO" as described in XAuth do not exist.   

            

              

                

                  
There have been a number of proposals for doing
                    this discovery, and perhaps now there are enough use
                    cases to look at standardizing something.  

                    No interaction is needed between the AS and the User
                    as the Client is providing enough "information" in
                    the user object of the Grant Request 

                    to satisfy the AS releasing the access tokens. 

                  

                

              

            

            Not sure I understand correctly this last sentence.

            

              

                

                  


                  

                  
Perhaps as I understand the model in more detail
                    I will understand what is missing from GNAP (besides
                    the discovery step).

                

              

            

            
It would be hard to say "what is missing" from XAuth
              since the foundations are not the same.

            
In order to compare different architectures, there is the
              need to start with the trust relationships. 

              Unfortunately, the word "trust" is absent in the main body
              of draft-hardt-xauth-protocol-12. Hence, 

              the description of the trust relationships is missing.

            

            
Denis

            

              

                

                  


                  

                  
/Dick

                  


                  

                  
(I've skipped reviewing the delegation use case
                    below until I understand the simple use case)

                  


                  

                  

                    

                      

                        
 

                            End of the story for a simple access

                        
 

                            Start of a subsequent story for a delegation
                            case

                            

                            Let us now suppose that the RS is unable to
                            fulfil the request by its own and that it
                            needs to contact another RS. RS1 contacts
                            RS2 (4a) and indicates
                            the operation 

                            that it wants to perform on RS2 (that
                            operation may not be the same as the
                            original operation). In return (4b), RS2
                            informs RS1 about which attributes are
                            needed 

                            by RS2 for performing the requested
                            operation and from which Attributes Servers
                            they may be obtained. RS1 forwards that
                            information to the Client. 

                            

                            This information is marked to indicate that
                            it shall be handled by the "User Consent
                            element" from the Client. The presentation
                            of that information is up to the man machine
                            

                            interface from the Client. The user can see
                            which attributes are requested by RS2 for
                            performing the new requested operation and,
                            if it consents, the Client contacts one or
                            more 

                            appropriate Authorization Servers. The user
                            consent is hence captured locally by the
                            "User Consent element" from the Client.
                            (i.e. there is no dialogue with any AS, nor
                            RS1, nor RS2). 

                            

                            When the Client got the access token(s) from
                            the authorization server(s), it sends all of
                            them in a single request to RS1. RS1 then
                            forwards the additional access token(s) to
                            RS2.

                            

                            

                            Some observations: 

                            

                            The user nor the Client are linked with any
                            particular AS. A user may use today an AS of
                            the Bank of America and may change tomorrow
                            to the Bank of Missouri. 

                            As soon as he will be registered with the
                            Bank of Missouri, he will be able to get
                            access tokens from the AS of the Bank of
                            Missouri. The AS of Bank of America 

                            has not been able to know where its access
                            tokens have been used. This will be the same
                            for AS of the Bank of Missouri. There is no
                            need for any direct dialogue 

                            between any AS and any RS at the time a
                            client is making an access. There is no need
                            for any RO to contact any AS.

                        
This model has been
                            constructed following a "Privacy by Design"
                            approach.

                        Denis

                      

                    

                    -- 

                    Txauth mailing list

                    Txauth@ietf.org

                    https://www.ietf.org/mailman/listinfo/txauth

                  

                

              

              
ᐧ

            

            


            

          

        

      

    

    


    

  


--------------C727181D255E2393EAA81030--


From nobody Mon Jul 13 07:16: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 B850F3A124C for ; Mon, 13 Jul 2020 07:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 TKVsVh5563dF for ; Mon, 13 Jul 2020 07:16:44 -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 4F1D23A12A2 for ; Mon, 13 Jul 2020 07:16:42 -0700 (PDT)
Received: from [192.168.1.7] (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 06DEGdCw017646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jul 2020 10:16:40 -0400
From: Justin Richer 
Message-Id: <174F2061-3F0F-49B2-A18F-58DF658E4473@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_82D23593-6D37-4DC4-BBBE-6EB48388E48D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 13 Jul 2020 10:16:39 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 13 Jul 2020 14:16:51 -0000

--Apple-Mail=_82D23593-6D37-4DC4-BBBE-6EB48388E48D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

One thing I think we should learn from OIDC is that returning claims =
from an API, and not just an assertion or direct response, is a powerful =
and useful pattern. We have an opportunity to separate these cleanly, =
where OIDC didn=E2=80=99t have the opportunity in defining the =
=E2=80=9Cclaims=E2=80=9D request parameter.

As an alternative to the current XYZ and XAuth syntaxes, over the =
weekend I=E2=80=99ve been playing with something that would look like =
this strawman in the request:


{
   subject: {
      id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
      assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =
=E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
   }
}

This request says that I=E2=80=99d like some subset of these identifiers =
(as plain text in the response) and some subset of signed assertions in =
the given formats. Each one would have an associated space in the =
return. I=E2=80=99m not picturing that the =E2=80=9Cid=E2=80=9D field =
values would affect the contents of the assertions: so I could ask for =
an email address identifier but get back an ID token that had only the =
subject identifier. Maybe that=E2=80=99s not the right model? But it=E2=80=
=99s at least simple and deterministic this way, and it=E2=80=99s =
something to play with.

Note: The =E2=80=9Cid=E2=80=9D names are taken from =
https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.html =
, the =E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=99t =
see a source that collected them. If you wanted specific bundles of =
claims about the user from a UserInfoEndpoint, for example, you=E2=80=99d =
have something like:

{
   subject: {
      id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
      assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =
=E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
   },
   resources: [{
       type: =E2=80=9Cuserinfo=E2=80=9D,
       datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =
=E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
  }]
}

This is an example for a specific kind of resource, and I don=E2=80=99t =
think that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema =
here, or the datatype values therein. That should be work outside of =
GNAP, probably for the OIDF.

This approach is extensible in several ways, each of them for a specific =
reason that I think is clear:

 - new values in the =E2=80=9Cid=E2=80=9D field to give new identifiers
 - new values in the =E2=80=9Cassertion=E2=80=9D field to give new =
assertion formats
 - new fields under the =E2=80=9Csubject=E2=80=9D heading=20
 - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =
=E2=80=9Cscim-v1=E2=80=9D or =E2=80=9Cfacebook-profile=E2=80=9D for =
instance)
 - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource type
 - new top-level request parameters

As per the other thread, if you wanted to use the OIDC query language, =
you=E2=80=99d package it separately as a top-level request parameter =
since it can include both the ID token response and the access token =
response and we shouldn=E2=80=99t be encouraging mixing these things =
together.

 =E2=80=94 Justin

> On Jul 10, 2020, at 5:00 PM, Dick Hardt  wrote:
>=20
> It looks to me that our different views of what is in scope for GNAP =
are the differences below.
>=20
> Per the subject line, I'm looking at how the client acquires claims =
about the user. You don't think that is in scope, and that a different =
layer will solve that.
>=20
> I think we should learn from OIDC being on top of OAuth, and GNAP =
should be able return ANY claim, not just identifier claims. There are =
use cases that may be difficult to support if we do not have that =
functionality in scope, such as some of the ones I list below, and it =
seems pretty straightforward to support ANY claim if we are supporting =
identifiers.
>=20
> /Dick
>=20
>=20
> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer > wrote:
>=20
>=20
>> On Jul 10, 2020, at 2:15 PM, Dick Hardt > wrote:
>>=20
>>=20
>> inline ...=20
>>=20
>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer > wrote:
>> Yes, the core idea is to not have to parse an assertion to get back =
the core authentication information, which consists of an identifier =
(iss/sub pair in OIDC, but could be a number of things). Sometimes the =
client is going to want the rest of the identity information, but If the =
user=E2=80=99s logged into the client before, the client has likely =
cached that info and probably won=E2=80=99t need it, and sending it =
would be a violation of privacy principles.. The client would want the =
info pretty much just in these cases:
>>=20
>>  1. The client has never seen the user before.=20
>>  2. The user=E2=80=99s information has been updated since the last =
time the client saw it.
>>=20
>> Agreed
>> =20
>>=20
>> Now for case (1), how would the client know if it wants to request =
the user=E2=80=99s profile info or not, since it doesn=E2=80=99t know =
who the user is?
>>=20
>> But the client could know who the user is. The client may have used a =
different AS to authenticate the user.
>=20
> In these cases, the client is not going to be requesting identity =
information from the AS to log the user in, so it=E2=80=99s not relevant =
to the use case. The client will have an opportunity to push that =
information to the AS.
>=20
>> The User may have self identified to the client. The client may have =
a cookie saying who the user was and the user said that was them. While =
the latter cases are really a strong hint, they are likely right most of =
the time and can lead to a user experience basde on that hint
>=20
> In these cases, the AS might be able to guess if the client has info =
about the user already, but probably not. And the assumptions fall apart =
if it=E2=80=99s in fact a different user that ends up logging in, which =
is of course possible (the hint you gave doesn=E2=80=99t match the =
identity of the current user after the AS validates them). This =
possibility leads to clients always asking for everything every time and =
the server providing everything every time. That=E2=80=99s a pattern I =
think we should avoid in an ultimate solution =E2=80=94 but ultimately, =
I don=E2=80=99t think that this kind of protocol decision is inside of =
GNAP.
>=20
>> =20
>> And the AS won=E2=80=99t know if client is going to want the profile =
info, since the AS won=E2=80=99t know if the client has the user=E2=80=99s=
 info or not. Sure, the AS might have seen that client and that user =
combo previously, but it doesn=E2=80=99t know if the client needs an =
update.
>>=20
>> The client can share with the AS the user it knows or thinks it is =
dealing with, which could let the AS respond if the information was new. =
This could be the case for an AS that is providing claims, but not =
authentication, and could happen silently. The user would only interact =
if the user information had changed, and the client wanted the updated =
information.
>> =20
>=20
> See above.
>=20
>>=20
>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s info =
has been updated or not because it doesn=E2=80=99t know who the user is =
yet. If the AS can provide some time of updated stamp to the client, the =
client can pull the new info when it needs it.
>>=20
>> See above.
>=20
> See above.
>=20
>> =20
>>=20
>> If you ignore both of these cases and put all the user information =
inline with the main request/response, you end up in a situation where =
the client always requests everything and the server always provides =
everything, since you can=E2=80=99t be sure you=E2=80=99re not in =
situation (1) or (2) ahead of time.
>>=20
>> See above. There are a number of other states the client could be in.
>>=20
>> For example, the client could be stateless about user information, so =
it knows it is ALWAYS in state 1.
>=20
> A stateless client would need to fetch appropriate user information =
every time, then. But that=E2=80=99s an optimization for a very specific =
case.
>=20
>> =20
>>=20
>> This is really what I mean about the two-stage identity protocol.
>>=20
>> I know what it is. Per above, GNAP lets us support a wider set of use =
cases. Why limit ourselves to what OIDC supported?
>=20
> We aren=E2=80=99t limiting the protocol, but instead limiting the =
scope of what we define internal to the GNAP protocol. There=E2=80=99s a =
lot of room for innovation on top of it.
>=20
>> =20
>> In the first stage, you push the bare minimum of what you need to get =
the user known to the client. In the second stage, the client uses its =
access token to call an API to get whatever else it needs to know about =
the user.
>>=20
>> =46rom a privacy perspective in non-enterprise use cases, I think the =
user should give consent to any updated personal information to a =
client. In general, the client should not be able to get the latest =
information about a user whenever it wants.
>=20
> This is about the rights associated with the access token, then. And =
an access token doesn=E2=80=99t have to keep working if the AS has a =
policy that says it won=E2=80=99t. The AS/RS could easily decide that a =
particular access token will only return data that hasn=E2=80=99t been =
changed. Maybe it stops working after the data changes, or it just =
returns old data, or any number of things. This is for the AS/RS to =
decide and this is pretty standard interpretation of the token, nothing =
special here because we=E2=80=99re dealing with identity.
>=20
>  =E2=80=94 Justin
>=20
>> =20
>> /Dick
>> =E1=90=A7
>=20


--Apple-Mail=_82D23593-6D37-4DC4-BBBE-6EB48388E48D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

One =
thing I think we should learn from OIDC is that returning claims from an =
API, and not just an assertion or direct response, is a powerful and =
useful pattern. We have an opportunity to separate these cleanly, where =
OIDC didn=E2=80=99t have the opportunity in defining the =E2=80=9Cclaims=E2=
=80=9D request parameter.

As an alternative to the current XYZ and XAuth syntaxes, over =
the weekend I=E2=80=99ve been playing with something that would look =
like this strawman in the request:


{
   subject: {
      id: [ =E2=80=9Caccount=E2=80=9D, =
=E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=80=9D],
      assertion: [ =E2=80=9Codic_id_token=E2=80=9D=
, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
   }
}

This request says that =
I=E2=80=99d like some subset of these identifiers (as plain text in the =
response) and some subset of signed assertions in the given formats. =
Each one would have an associated space in the return. I=E2=80=99m not =
picturing that the =E2=80=9Cid=E2=80=9D field values would affect the =
contents of the assertions: so I could ask for an email address =
identifier but get back an ID token that had only the subject =
identifier. Maybe that=E2=80=99s not the right model? But it=E2=80=99s =
at least simple and deterministic this way, and it=E2=80=99s something =
to play with.

Note: The =E2=80=9Cid=E2=80=9D names are taken from https://tools.ietf.org/id/draft-ietf-secevent-subject-identifie=
rs-05.html, the =E2=80=9Cassertion=E2=80=9D names are made up as I =
didn=E2=80=99t see a source that collected them. If you wanted specific =
bundles of claims about the user from a UserInfoEndpoint, for example, =
you=E2=80=99d have something like:

{
  =
 subject: {
  =
    id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
      assertion: [ =E2=80=9Codic_id_token=E2=80=9D=
, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" =
]
  =
 },
  =
 resources: [{
  =
     type: =E2=80=9Cuserinfo=E2=80=9D,
       datatypes: [ =
=E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =E2=80=9Cphone=E2=80=9D=
, =E2=80=9Cemail=E2=80=9D ]
  }]
}

This is an example for a specific kind =
of resource, and I don=E2=80=99t think that GNAP should define the =
=E2=80=9Cuserinfo=E2=80=9D schema here, or the datatype values therein. =
That should be work outside of GNAP, probably for the OIDF.

This approach is =
extensible in several ways, each of them for a specific reason that I =
think is clear:

 - new values in the =E2=80=9Cid=E2=80=9D field to give =
new identifiers
 - new values in the =
=E2=80=9Cassertion=E2=80=9D field to give new assertion =
formats
 - new fields under the =E2=80=9Csubject=
=E2=80=9D heading 
 - new resource types =
besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or =
=E2=80=9Cfacebook-profile=E2=80=9D for instance)
 - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D =
resource type
 - new top-level request =
parameters

As =
per the other thread, if you wanted to use the OIDC query language, =
you=E2=80=99d package it separately as a top-level request parameter =
since it can include both the ID token response and the access token =
response and we shouldn=E2=80=99t be encouraging mixing these things =
together.

 =E2=80=94 Justin

On Jul =
10, 2020, at 5:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It looks to me that our different =
views of what is in scope for GNAP are the differences below.

Per the subject line, =
I'm looking at how the client acquires claims about the user. You don't =
think that is in scope, and that a different layer will solve =
that.

I think =
we should learn from OIDC being on top of OAuth, and GNAP should be able =
return ANY claim, not just identifier claims. There are use cases that =
may be difficult to support if we do not have that functionality in =
scope, such as some of the ones I list below, and it seems pretty =
straightforward to support ANY claim if we are supporting =
identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09 PM Justin Richer =
<jricher@mit.edu> =
wrote:


On Jul =
10, 2020, at 2:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


inline ... 

On Thu, Jul =
9, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea is =
to not have to parse an assertion to get back the core authentication =
information, which consists of an identifier (iss/sub pair in OIDC, but =
could be a number of things). Sometimes the client is going to want the =
rest of the identity information, but If the user=E2=80=99s logged =
into the client before, the client has likely cached that info and =
probably won=E2=80=99t need it, and sending it would be a violation of =
privacy principles.. The client would want the info pretty much just in =
these cases:

 1. =
The client has never seen the user before. 
 2. The user=E2=80=99s information has been updated =
since the last time the client saw it.

Agreed
 

Now for case (1), how would the client =
know if it wants to request the user=E2=80=99s profile info or not, =
since it doesn=E2=80=99t know who the user is? =


But the client could know who the user is. The client may =
have used a different AS to authenticate the user. =


In these cases, the client is not going =
to be requesting identity information from the AS to log the user in, so =
it=E2=80=99s not relevant to the use case. The client will have an =
opportunity to push that information to the AS.

The User may have self identified to the client. The client =
may have a cookie saying who the user was and the user said that was =
them. While the latter cases are really a strong hint, they are likely =
right most of the time and can lead to a user experience basde on that =
hint

In these cases, the AS might be able to =
guess if the client has info about the user already, but probably not. =
And the assumptions fall apart if it=E2=80=99s in fact a different user =
that ends up logging in, which is of course possible (the hint you gave =
doesn=E2=80=99t match the identity of the current user after the AS =
validates them). This possibility leads to clients always asking for =
everything every time and the server providing everything every time. =
That=E2=80=99s a pattern I think we should avoid in an ultimate solution =
=E2=80=94 but ultimately, I don=E2=80=99t think that this kind of =
protocol decision is inside of GNAP.

 
And =
the AS won=E2=80=99t know if client is going to want the profile info, =
since the AS won=E2=80=99t know if the client has the user=E2=80=99s =
info or not. Sure, the AS might have seen that client and that user =
combo previously, but it doesn=E2=80=99t know if the client needs an =
update.

The client can share with the AS the user it knows or thinks =
it is dealing with, which could let the AS respond if the information =
was new. This could be the case for an AS that is providing claims, but =
not authentication, and could happen silently. The user would only =
interact if the user information had changed, and the client wanted the =
updated information.
 

See above.


And for (2), the client won=E2=80=99t =
know if the user=E2=80=99s info has been updated or not because it =
doesn=E2=80=99t know who the user is yet. If the AS can provide some =
time of updated stamp to the client, the client can pull the new info =
when it needs it.

See =
above.

See above.

 

If you ignore both of these cases and =
put all the user information inline with the main request/response, you =
end up in a situation where the client always requests everything and =
the server always provides everything, since you can=E2=80=99t be sure =
you=E2=80=99re not in situation (1) or (2) ahead of =
time.

See above. There are a number of other states the client =
could be in.

For=
 example, the client could be stateless about user information, so it =
knows it is ALWAYS in state =
1.

A stateless client would need to fetch =
appropriate user information every time, then. But that=E2=80=99s an =
optimization for a very specific case.

 

This is really what I mean about the =
two-stage identity protocol. 

I know what it is. Per above, GNAP lets =
us support a wider set of use cases. Why limit ourselves to what OIDC =
supported?

We aren=E2=80=99t limiting the =
protocol, but instead limiting the scope of what we define internal to =
the GNAP protocol. There=E2=80=99s a lot of room for innovation on top =
of it.

 
In the first stage, you push the bare minimum of what you =
need to get the user known to the client. In the second stage, the =
client uses its access token to call an API to get whatever else it =
needs to know about the user. 
=46rom a privacy perspective in =
non-enterprise use cases, I think the user should give consent to any =
updated personal information to a client. In general, the client =
should not be able to get the latest information about a user whenever =
it wants.

This is about the rights associated =
with the access token, then. And an access token doesn=E2=80=99t have to =
keep working if the AS has a policy that says it won=E2=80=99t. The =
AS/RS could easily decide that a particular access token will only =
return data that hasn=E2=80=99t been changed. Maybe it stops working =
after the data changes, or it just returns old data, or any number of =
things. This is for the AS/RS to decide and this is pretty standard =
interpretation of the token, nothing special here because we=E2=80=99re =
dealing with identity.

 =E2=80=94 Justin

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






=

--Apple-Mail=_82D23593-6D37-4DC4-BBBE-6EB48388E48D--


From nobody Mon Jul 13 10:51: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 AD2DA3A160D for ; Mon, 13 Jul 2020 10:51: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 kBxKIn8Lprru for ; Mon, 13 Jul 2020 10:51:11 -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 E984E3A1A19 for ; Mon, 13 Jul 2020 10:49:48 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id j11so18972257ljo.7 for ; Mon, 13 Jul 2020 10:49: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=M4iftb4NHGXJ4b7Etmajum0U7BDOnaLesrDmpwn9FOM=; b=dRWSU7GHdujgNtPKM31xKQa6Sk9yEzvjASH+ScX83DBFLN7M+W5gMaIJrghsBJNqv1 l6VhMvtpO6kvtFfRyr+G6eho1HukhsnItZkGhZCddD2CCZjaOvLJbn8/cdujnwqgbxpV K39/IB6DyxRn/5GDUItalMrQDA6F03CMOyT/COW7tgAVuzQVqeWYnnDuH7gjF/ETsMu2 r96bXYJDEZbviHWqMhnKZY7jgpjlQaMlZApUNimrJHJria6ood/nnOaeMYIfih+vxBMp YpvuioQxGs8zao/J8HBPz90EAfxd3OORyyQBXHnspf477+VQCgNAvlEsYF1rNrgHNe6W B23w==
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=M4iftb4NHGXJ4b7Etmajum0U7BDOnaLesrDmpwn9FOM=; b=kluPYuJ6b6iHf78C6hso26ZLhKVBrz3FuR40omPxvX1p/FNSbZ0prdDTmTjGllnswD 7x/bQGp8VvBzdi2X7s4YMcXxs8rKLUrYXr5DmQ6IymVn80i6CsGFR0tKJPYKF5pHlH3+ gYyABryZQ1b/XYhFpZKyzkwOFJyO/9rT2G6khXPPPX2vqi9Qy5d3KRsfj+F+nE8xGcoa 30wm6B135tnMYqlIufq1WMUHatdDHgi1rXyIH8x9fUx/VLUJlvXTAh8yGtDx0V7Gkfjk 9moRotJACz7P0JaITe6L9rVZoU1+jSCPWWd2Inwk6dHOUu058TI0VIsn9M165w3vFJA7 FG7g==
X-Gm-Message-State: AOAM533rQCQKYS/SAkyyO3tqLLdeG4PziLBQ0iXCq9m/y+7LQM5fHvYG ihADcRhOuUkKpp3DWUfsYEGk6GIntMuwggL0l+M=
X-Google-Smtp-Source: ABdhPJwqqa41h9h9riBEL/Ud2dQ792uA4b8dcSUGcqo26U8GIrhydGJTEyPKepTHhI4UVvtQnRvnZa4+JftSDZDgs+o=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr401950ljg.69.1594662586800; Mon, 13 Jul 2020 10:49:46 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 13 Jul 2020 10:49:10 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: Francis Pouatcha , txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000005df3005aa565182"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 13 Jul 2020 17:51:14 -0000

--00000000000005df3005aa565182
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This was helpful! ... but I have more questions inline ...

On Sun, Jul 12, 2020 at 7:31 PM Francis Pouatcha  wrote:

> Dick, my response inline
>
> On Sun, Jul 12, 2020 at 3:01 PM Dick Hardt  wrote:
>
>> Francis, thanks for the review ... questions and comments inserted ...
>>
>> On Sat, Jul 11, 2020 at 10:05 AM Francis Pouatcha > 40adorsys.de@dmarc.ietf.org> wrote:
>>
> 

>
>>> 1. Dictionary
>>> I do like sections 1.x dealing with terms but this is kept too short. I
>>> have noticed that most of the discussion conducted on the list results =
from
>>> different understanding of terms used.
>>>
>>
>> Are terms missing, are the definitions too short, or both?
>> If you provide specific examples I can work on addressing them!
>>
> Definitions are too short. I will provide a proper mail with my proposal
> of what we might need to clarify and als limit each term.
>

Great, thanks!


>
>>
>>>
>>> 2. Abstract Protocol Flow
>>>
>>> I am missing an abstract protocol flow like the one defined in
>>> https://tools.ietf.org/html/rfc6749#section-1.2.
>>>
>>
>> That's an interesting point. GNAP also has identity claims, so the
>> abstract flow is somewhat different (there is no Authorization Grant fro=
m
>> the RO), and not all steps always happen. (there may not be steps (E) an=
d
>> (F) with a Resource Server)
>>
>> Would you elaborate on what you think would be useful here, that is not
>> in the specific flows?
>>
> A diagram that generalizes the steps, independently of interaction mode i=
s
> essential for the reader's navigation of the rest of the document. This i=
s
> what #section-1.2 of RFC6749 does. I hope we can produce a similar diagra=
m.
>
> A subsection of
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
> could be defined for this.
>

Interaction modes are one dimension where the steps could be generalized,
but some steps are optional. For example, the User may not interact with
the GS, and the GS may interact with the RO. The Client may only want
claims, and there would be no step of the Client calling the RS.

A generalized diagram would need to include all optional steps so that it
did not mislead a reader into thinking the diagram included all general
steps, but it does not seem that is what you are asking for as you wrote:

A subsection of
https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1 could
be defined for this."

Perhaps you can share how you think the diagram would look?


>
>>
>>>
>>> 3. Parties
>>> a) graphical illustration (#section-1.1)
>>> I do like the graphical illustration in #section-1.1. The main
>>> difference to the picture in
>>> https://tools.ietf.org/html/rfc6749#section-1.2 is the clear separation
>>> between the "User" and the "Resource Owner" (RO). To help transition th=
e
>>> understanding of current oAuth2 implementers, it is essential to illust=
rate
>>> and highlight the rationale behind this design.
>>>
>>
>> Would a reference to #section-2.3
>> 
>> in the RO definition, and more explanation in #section-2-3 on the ration=
ale
>> address your concern?
>>
> A subsection of
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
> with the RO vs. User clarification and some example interactions where th=
ey
> diverge.
>

ok


>
>>
>>
>>>
>>> b) Dynamic Client (#section-1.1)
>>> I would like to mention that the dynamic client can present a
>>> certificate issued by some authorities known to the GS. This is the cas=
e of
>>> QSeal certificates designed by European eiDas.
>>>
>>
>> I agree.
>>
>> If we do mention that, we should specify how the certificate would be
>> presented and work. We can do that in the core GNAP document, in an GNAP
>> extension, or reference another specification. I'm not that familiar wit=
h
>> QSeal. Is it specified somewhere?
>>
> This is the ETSI standard used by the European PSD2:
> https://www.etsi.org/deliver/etsi_ts/119400_119499/119495/01.04.01_60/ts_=
119495v010401p.pdf
> .
> There is a well managed infrastructure in the European Economic Area that
> allows for "Certificate Based Dynamic Client".
>

Thanks! I'll look into that.


>
>>
>>>
>>> c) Grant Server (GS)
>>> If the GS is a SIOP running on the user device, how does it influence
>>> the protocol design?
>>>
>>
>> With mobile apps having URIs bound to specific apps, I think the protoco=
l
>> would work the same, but I've not worked with SIOPs. Do you have any
>> concerns?
>>
> Yes. As the protocol flow designs inbound connectivity from Client to GS.
> How does a client initiate a connection to the user device? Or we might
> have alternative interactions without inbound connectivity to the GS?
>

Now I think I understand. How does the Client make the Grant Request if the
Client is running locally on the User's device. Correct?



>
>>
>>>
>>>
>>> 4. Interaction Modes (Protocol Flows)
>>> And mentioned in my review of the XYZ protocol, I am missing a grouping
>>> of interaction models. We need an abstraction layer in which we define
>>> groups of flows based on key interaction between parties. I am expectin=
g at
>>> least:
>>>
>>> - "redirect" Interaction
>>> here the GS instructs the Client to redirect the RO/User to the given i=
nteraction
>>> URL. This is well covered in #section-2.1. But for transparency this
>>> picture must also display the "User". Shall the redirect interaction
>>> presume that the "User" and the "Ro" are represented by the same party,
>>> then it is worth mentioning this. In this case we can draw a single box=
 to
>>> represent both.
>>>
>>
>> Did you mean to say '... the picture must also display the "RO"'?
>>
> Yes. For transparency, even if they are both in the same box.
>

Got it. Will add it to next version.


>
>> There could be a separate RO in a more complex flow, but we could define
>> this flow to represent where the User and RO are the same party.
>>
> Yes.
>
>>
>>
>>> - "decoupled" Interaction
>>> This interaction model is currently represented by the "user_code"
>>> Interaction (#section-2.2) and the "indirect" Interaction (#section-2.3=
 and
>>> #section-5.2).. Both of these are forms of "decoupled" Interactions. Ma=
in
>>> characteristic of a decoupled interaction shall be that the device used=
 by
>>> the RO to interact with the GS shall be separated from the. device used=
 by
>>> the "User" to interact with the "Client".
>>>
>>
>> I like the word "decoupled" -- would "redirect" then be named "coupled"?
>> Or renamed "indirect" to "decoupled"?
>>
> Not sure.
> - Let us use redirect, decoupled and embedded to refer to "families/types
> of interaction". In which case "Indirect" will be an interaction mode of
> the "decoupled family".
> - I wouldn't call "redirect" and interaction mode, as there are many
> variants of redirect. Let us keep the keyword for the family and specify
> known variants of redirect interaction for more precision.
>

I had not thought there were variants to "redirect". Would you elaborate on
the variants?



>
>
>> While "user_code" and "indirect" are both decoupled, the "indirect" has
>> different security properties as it uses a link, which an attacker can
>> trick a user into clicking on wherever a link may be used.
>>
>> I do agree that "user_code" and "indirect" are both a decoupled
>> interaction, and calling that out would be useful.
>>
> Yes.
>
>>
>>
>>
>>>
>>> - "embedded" Interaction
>>> With the evolving of smart end user devices that can keep private keys,
>>> perform cryptographic operations, it is essential to include the "embed=
ded"
>>> Interaction in which RO/User device send authorization grant to "Client=
"
>>> that in turns takes it to the GS in exchange of the authorization token=
. In
>>> XYZ I found this hidden behind the didcom interaction.
>>> The "embedded" interaction shall open room for different types of
>>> synchronous transaction authorization requests in which the "RO/User" g=
ives
>>> a verifiable assertion (inkl. proof of possession) to the "Client" for =
use
>>> at the GS in exchange for the seeked access token.
>>>
>>
>> I have been thinking that the functionality you describe above would be
>> in the "user" object rather than in the "interaction" object as it is no=
t
>> an interaction between the GS and the User. IE, the Client presents some
>> artifact to the GS that establishes the User in the GS context so that a=
 GS
>> / User interaction is not needed.
>>
>> That looks similar to me to what Denis was proposing in
>>
>> https://mailarchive.ietf.org/arch/msg/txauth/kgTKFHZDRDsXJlwW95Gqv_-LctA=
/
>>
> No. It is different.
>

How is it different?


>
>>
>> Does that work, or am I missing something?
>>
> Embedded in the sense above is about embedding the interaction RO <-> GS
> into the communication path User <-> Client <-> GS.
> The main purpose is to keep the Link User <-> Client uninterrupted (by an=
y
> type of redirect or decoupled interaction).
>

I'm sorry, I'm not following what you are getting at.
Would you elaborate more on what you are envisioning here?
Perhaps in a new thread so that others with interest in the same subject
are more likely to participate?

/Dick

=E1=90=A7

--00000000000005df3005aa565182
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This was helpful! ... but I have=C2=A0more questions =
inline ...=C2=A0

On Sun, Jul 12, 2020 at 7:31 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Dick, my response inline

On Sun, Jul 12, 2020 at 3:01 PM Dick Hardt <dick.hardt@gmail.com=
> wrote:
=

Francis, thanks for the review ... questions and comm=
ents inserted ...=C2=A0

On Sat, Jul 11, 2020 at 10:05 AM Francis Pouatcha &l=
t;fpo=3D40=
adorsys.de@dmarc.ietf.org> wrote:
<snip>=C2=A0

1. Dictionary
I do like sections 1.x dealing with terms but this is kept too shor=
t. I have noticed that most of the discussion conducted on the list results=
 from different=C2=A0understanding of terms used.

Are terms missing, are the definitions too s=
hort, or both?
If you provide specific examples I can work on add=
ressing them!
Definitions are too short.=
 I will provide a proper mail with my proposal of what we might need to cla=
rify and als limit each term.

=

Great, thanks!
=C2=A0
=


<=
/blockquote>

Interaction modes are one dimension where t=
he steps could be generalized, but some steps are optional. For example, th=
e User may not interact with the GS, and the GS may interact with the RO. T=
he Client may only want claims, and there would be no step of the Client ca=
lling the RS.

A generalized diagram would need to =
include all optional steps so that it did not mislead a reader into thinkin=
g the diagram included all general steps, but it does not seem that is what=
 you are asking for as you wrote:

A subsection of=
=C2=A0https://tools.ietf.org/html/draft-hardt-xaut=
h-protocol-12#section-1.1 could be defined for this."

Perhaps you can share how you think the diagram would look=
?
=C2=A0
<=
div dir=3D"ltr">
=C2=A0

3. Parties
a)=C2=A0graphical illustration (#section-1.1)
I do like the grap=
hical illustration in #section-1.1. The main difference to the picture in=
=C2=A0https://tools.ietf.org/html/rfc6749#section-1.2 is the clear s=
eparation between=C2=A0the "User" and the "Resource Owner&qu=
ot; (RO). To help transition the understanding of current oAuth2 implemente=
rs, it is essential to illustrate and highlight the rationale behind this d=
esign.

Would =
a reference to #section-2.3 in the RO definiti=
on, and more explanation in #section-2-3 on the rationale address your conc=
ern?
A subsection of https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1=
 with the RO vs. User clarification and some example interactions where=
 they diverge.

ok
=C2=A0

=
=C2=A0

b)=
 Dynamic Client (#section-1.1)
I would like to mention that the dynamic =
client can present a certificate issued by some authorities known to the GS=
. This is the case of QSeal certificates designed by European eiDas.

I agree.=
=C2=A0

If we do mention that, we should specify ho=
w the certificate would be presented and work. We can do that in the core G=
NAP document, in an GNAP extension, or reference another specification. I&#=
39;m not that familiar with QSeal. Is it specified somewhere?
This is the ETSI standard used by the European PSD2:=
=C2=A0https://www.etsi.org/d=
eliver/etsi_ts/119400_119499/119495/01.04.01_60/ts_119495v010401p.pdf.=
=C2=A0
There is a well managed infrastructure in the European Eco=
nomic Area that allows for "Certificate Based=C2=A0Dynamic Client"=
;.

Thanks! I'll look =
into that.
=C2=A0
=C2=A0
=


c)=C2=A0Grant Server (GS)
If the GS is a SIOP running =
on the user device, how does it influence the protocol design?
<=
/div>

With mobile apps having U=
RIs bound to specific apps, I think the=C2=A0protocol would work the same, =
but I've not worked with SIOPs. Do you have any concerns?=C2=A0
Yes. As the protocol flow designs inbound conne=
ctivity from Client to GS. How does=C2=A0a=C2=A0client initiate=C2=A0a conn=
ection to the user device? Or we might have alternative interactions withou=
t=C2=A0inbound connectivity to the GS?
<=
br>
Now I think I understand. How does the Client make the Grant =
Request if the Client is running locally on the User's device.=C2=A0Cor=
rect?

=C2=A0
=C2=A0


4. Interaction M=
odes (Protocol Flows)
And mentioned=C2=A0in my review of the XYZ =
protocol, I am missing a grouping of interaction models. We need an abstrac=
tion layer in which we define groups of flows based on key interaction betw=
een parties. I am expecting at least:

- "=
;redirect" Interaction
here the GS instructs the Client to r=
edirect the RO/User to the given=C2=A0interaction URL. This is well=C2=A0covered in=C2=A0#=
section-2.1.=C2=A0But for transparency this picture must also display the &=
quot;User". Shall the=C2=A0redirect interaction presume that the "=
;User" and the "Ro" are represented by the same party, then =
it=C2=A0is worth=C2=A0mentioning this. In this case we can draw=C2=A0a sing=
le box to represent both.
<=
div>
Did you mean=C2=A0to say '... the picture must also =
display the "RO"'?=C2=A0
Y=
es. For transparency, even if they are both in the same box.=C2=A0

Got it. Will add it to next versi=
on.
=C2=A0

There could be a separate RO in a more complex flow, but we could =
define this flow to represent where the User and RO are the same party.
Yes.=C2=A0
<=
div dir=3D"ltr">

- "deco=
upled" Interaction
This=C2=A0interaction model is currently =
represented by the=C2=A0"user_code" Interaction (#section-2.2) an=
d the=C2=A0"indirect" Interaction (#section-2.3 and #section-5.2)=
.. Both of these are forms of "decoupled" Interactions. Main char=
acteristic of a decoupled interaction shall be that=C2=A0the device used by=
 the RO to interact with the GS shall be separated from the. device used by=
 the "User" to interact with the "Client".
<=
/div>

I like the word &qu=
ot;decoupled" -- would "redirect" then be named "couple=
d"? Or renamed "indirect" to "decoupled"?
Not sure.
- Let us use redirect, decou=
pled and embedded to refer to "families/types of interaction". In=
 which case "Indirect" will be an interaction mode of the "d=
ecoupled family".
- I wouldn't call "redirect"=
 and interaction mode, as there are many variants of redirect. Let us keep =
the keyword for the family and specify known variants of redirect interacti=
on for more precision.

I =
had not thought there were variants to "redirect". Would you elab=
orate on the variants?

=C2=A0


While "user_=
code" and "indirect" are both decoupled, the "indirect&=
quot; has different security properties as it uses a link, which an attacke=
r can trick a user into clicking on wherever a link may be used.=C2=A0

I do agree that "user_code" and "indire=
ct" are both a decoupled interaction, and calling that out would be us=
eful.
Yes.=C2=A0

=C2=A0

- "embedded" Interaction
With the evol=
ving of smart end user devices that can keep private keys, perform=C2=A0cry=
ptographic operations, it is=C2=A0essential=C2=A0to include the "embed=
ded" Interaction in which RO/User device send authorization grant to &=
quot;Client" that in turns takes it to the GS in exchange of the autho=
rization token. In XYZ I found this hidden behind=C2=A0the didcom interacti=
on.
The "embedded" interaction shall open room for diff=
erent types of synchronous transaction authorization requests in which the =
"RO/User" gives a verifiable assertion (inkl. proof of possession=
) to the "Client" for use at the GS in exchange for the seeked ac=
cess token.

=

I have been thinking that the functionality you describe above would b=
e in the "user" object rather than in the "interaction"=
 object as it is not an interaction between the GS and the User. IE, the Cl=
ient presents some artifact to the GS that establishes the User in the GS c=
ontext so that a GS / User interaction is not needed.

<=
div>That looks similar=C2=A0to me to what Denis was proposing in=C2=A0

No. It is different.=C2=A0
=

How is it different?=C2=A0
=C2=A0
=



Does that wor=
k, or am I missing something?
Embedded i=
n the sense above is about embedding the interaction RO <-> GS into t=
he communication path User <-> Client <-> GS.=C2=A0
T=
he main purpose is to keep the Link User <-> Client uninterrupted (by=
 any type of redirect or decoupled interaction).

I'm sorry, I'm not following what you are g=
etting at.
Would you elaborate more on what you are envisioni=
ng here? 
Perhaps in a new thread so that others with interest in=
 the same subject are more likely to participate?

=
/Dick

<=
div>


3D""=
=E1=90=A7


--00000000000005df3005aa565182--


From nobody Mon Jul 13 11:04: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 5F4B23A1618 for ; Mon, 13 Jul 2020 11:04:18 -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 8dDHyE-pEA2X for ; Mon, 13 Jul 2020 11:04:13 -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 6E4353A1647 for ; Mon, 13 Jul 2020 11:03:28 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id z24so19029092ljn.8 for ; Mon, 13 Jul 2020 11:03: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=9k/PYWvx9abCyurO/0Dkr8xdBrbLJhBnDZvx9rjCcIk=; b=Ms6QU3RT8QIG3QOPRvLaMt2AmFuW/L1c/fkUflzrVl6e0Nt3W/FXBctqz3fZu8ux6U yTpus0lcaiZtThaOjV+7oQ5oYni5k1wYGxosuErx4wnRz3ZiPYHM1C42LGRYEhIxyYiE Jd9P+Y3fKqOpEoIn3AXVSaLyD8DOQEaYT087wa2GgJUMq6wi29hoS5p9cT7pkrEI++UD VvbGPcWqS6WhNPo1MTgPN6sRgFNi6FbaQOMnV7tAY7OVHkYpYnVmNqqNIF7FL+Teboxp TJ3BOZ/VLKC/ALsRQerrEhrg2zoYlARsL4xL8LjvgPpBffd9lEMqwFMiV29hYHHNm7qe bZbw==
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=9k/PYWvx9abCyurO/0Dkr8xdBrbLJhBnDZvx9rjCcIk=; b=KcHozboS31Il/BISxOpw3ebqsN+3AMsua+Zvg+koqsK1Qtwuhw3LauHM9LFROuPuEJ 5osYmHFhoWk2oC5z7+w59AiRXw3j3gXuwWXRG+2TiAuH0LWkD+jISzK/fDLDYkQDv5Z9 97IMfReARnHdaurYF34b1cU6UW5BXqyCw+lR7lgXUEqrCh3bdOry4dJXNk2JJPNgyorZ /gKME1gBFy6hC6nXNmsubzui2W+0h3S5LnklO5+1BozH2N6JHksv0pWKyKv7Qw4KWSaS YqU/kV3HjEW78H70a/G4gJnHzHuBusVRc4XtTnAkQPne6N9+ryJmdS96Rxla0XMk5yAZ +CrQ==
X-Gm-Message-State: AOAM532aaWqhPa+DP8Ff2HtHK2AjY28hfeUuJe6LyPzLyJlhvsGOk++m vPHU7RTKw9bF2VkBxdwWzp1aPNGj5xbFRie3tqA=
X-Google-Smtp-Source: ABdhPJxeKjgU/qzTr5OhyrLpXBYZ8256Wa9xBzGBAI0NNPTh1bljBU3+rep+U697BLWhEOG4HLzvMzHaWvK33OZyMWg=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr456703ljh.110.1594663406310;  Mon, 13 Jul 2020 11:03:26 -0700 (PDT)
MIME-Version: 1.0
References:    <325bc015-1547-c56c-c1fe-67a97165785d@free.fr>  <83480ab0-03bc-7cc9-d166-ece4c6b63861@free.fr>
In-Reply-To: <83480ab0-03bc-7cc9-d166-ece4c6b63861@free.fr>
From: Dick Hardt 
Date: Mon, 13 Jul 2020 11:02:49 -0700
Message-ID: 
To: Denis 
Cc: "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000de98d405aa568132"
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 13 Jul 2020 18:04:18 -0000

--000000000000de98d405aa568132
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm going to just address the first part of your response so that we can
get clarity on that before diving into your later comments.

The calls between your proposal and XAuth are not inverted, your proposal
has a prior step. Step 1 in XAuth maps to Step 2 in your proposal, and Step
2 in XAuth is Step 3 in your proposal.

Below are 2 diagrams showing the same steps, the first keeping the existing
step labels for XAuth, the latter renaming the steps to correspond to your
proposal. This looks pretty similar to your diagram. What am I missing?

/Dick

DIAGRAM 1 (steps start at 0)

       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (0)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+



DIAGRAM 2 (steps start at 1)

       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (2) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (3)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (1)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+

=E1=90=A7

On Mon, Jul 13, 2020 at 7:08 AM Denis  wrote:

> Hello Dick,
>
> You wrote: "This looks pretty similar to your protocol drawing".
>
> No. There is a fundamental difference with the sequencing of the flow of
> the exchanges where the (1) and (2) flows are inverted.
>
> In your figure:
>
> The Client makes calls to the GS (1)
> The Client makes calls to the RS (2)
>
> while in my figure:
>
> The Client makes calls to the RS (1)
> The Client makes calls to the AS (2)
>
> In your figure, the first flow is with the GS, whereas in my figure the
> first flow is with the RS and there is a good reason for that:
> the client first contacts the RS to know what the RS expects. The client
> indicates in its first exchange to the RS whether it wants to authenticat=
e
> or to perform another operation.  In the case of an authentication
> operation, the RS may respond to the client that is supports FIDO U2F
> or that it is willing the client to present some attribute(s) from one or
> more AS.
>
> Then after the client has to figure out whether the user is using FIDO an=
d
> if not whether the user has an account with one of the AS.
> In the later case, if there is a match then the client,* *after having
> received the user consent**, may contact the appropriate AS to ask
> for some attribute(s).
>
> The same fundamental difference applies with
> draft-richer-transactional-authz-06 (XYZ) where the first exchange is don=
e
> with the AS:
> "The RC creates a transaction request and sends it to the AS".
>
> This answers also in details to one of your comments:
>
> What looks to be missing from your proposal is:
> A) The Client making a call to the RS to discover what it needs from a GS=
,
> and which GS to ask, prior to (1).
>
> This is not missing since this is the foundation of the architecture. The
> discovery mechanism at the RS has been described
> in details in an earlier email with the following title: "Support of FIDO
> and data minimization by RSs".
>
> The main figures are copied below (using ASCII):
>
>
>
>
>
>
>
>
>
> *  +-----------------------------------+---------------------------------=
+
>   +           Operation               +      Mathematical expression    +
> +-----------------------------------+---------------------------------+  =
 +
> Authentication                    + Condition 1 OR Condition 2      +
> +-----------------------------------+---------------------------------+  =
 +
> Operation A OR Operation Z        + Condition 3 AND Condition 4     +
> +-----------------------------------+---------------------------------+ *=
*Conditions
> table: *
>
>
>
>
>
>
>
>
>
>
> *
> +-------------+--------------+-----------------------------+----------+  =
 +
> Condition 1 + FIDO U2F 1.2 +                             +          +
> +-------------+--------------+-----------------------------+----------+  =
 +
> Condition 2 + AS 1         + set 1 of a attributes types +          +
> +-------------+--------------+-----------------------------+----------+  =
 +
> Condition 3 + AS 2         + set 2 of a attributes types + Scope 21 +
> +-------------+--------------+-----------------------------+----------+  =
 +
> Condition 4 + AS 9         + set 3 of a attributes types-+          +
> +-------------+--------------+-----------------------------+----------+ *
> According to the operation announced by the Client, the RS returns to the
> Client both the mathematical expression
> associated with that operation and the conditions included in that
> mathematical expression. The Client may then
> present that information to the user in order to obtain the user consent
> in a standardized manner.
> Another comment you made is:
>
> What looks to be missing from your proposal is:
> B) A mechanism for the Client to prove to the GS that it has gathered
> consent from the User.
>
> The user consent should not be captured *by the GS*, since the GS would b=
e
> in a position to apply a different consent decision
> without letting it know to the user (or to the client).
>
> The user consent must be captured *by the Client* and the Client must be
> able to verify that this consent has indeed been followed by the AS.
>
> The authorization data managed at the RS by the RO is used by the Client
> to query the consent of the user in a standardized manner.
> When, later on, the access token is returned to the Client by the AS, the
> Client (not the user) using that authorization data as well as
> the decision of the user is able to verify that the requested attributes
> (and no more) are indeed present into the access token.
>
> This is why access tokens may *not* be considered to be opaque to the
> Clients.
>
> In my earlier email copied below, six major differences with XAuth from 1=
)
> to 6) are listed.
>
> Denis
>
> From https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.=
1
>
> 1.1 .  Parties
>
>    The parties and their relationships to each other:
>
>        +--------+                           +------------+
>        |  User  |                           |  Resource  |
>        |        |                           | Owner (RO) |
>        +--------+                           +------------+
>            |      \                       /      |
>            |       \                     /       |
>            |        \                   /        |
>            |         \                 /         |
>        +--------+     +---------------+     +------------+
>        | Client |---->|     Grant     |     |  Resource  |
>        |        | (1) |  Server (GS)  | _ _ |   Server   |
>        |        |<----|               |     |    (RS)    |
>        |        |     +---------------+     |            |
>        |        |-------------------------->|            |
>        |        |           (2)             |            |
>        |        |<--------------------------|            |
>        +--------+                           +------------+
>
>
> The lines without arrows represent relationships.
> The User trusts the Client
> The User trusts the GS
> The RO trusts the GS to issue access tokens for the RS
> The RS trusts the tokens issued by the RS
> The RO controls the RS
>
> The Client makes calls to the GS (1)
> The Client makes calls to the RS (2)
>
> This looks pretty similar to your protocol drawing.
>
> What looks to be missing from your proposal is:
>
> A) The Client making a call to the RS to discover what it needs from a GS=
,
> and which GS to ask, prior to (1).
> B) A mechanism for the Client to prove to the GS that it has gathered
> consent from the User.
>
> The current protocol does not require the GS to interact with either the
> User, the RO, or the RS -- which looks to me to meet your privacy goals.
>
> =E1=90=A7
>
> On Fri, Jul 10, 2020 at 6:06 AM Denis  wrote:
>
>> Hi Dick,
>>
>> Hi Denis, thanks for sharing the model. I don't fully understand what is
>> going on, questions inserted:
>>
>> Responses are inserted.
>>
>>
>> FWIW: having paragraphs start with the step number (1), (2) etc. would
>> make it easier to map between the description and the diagram.
>>
>> On Thu, Jul 9, 2020 at 3:26 AM Denis  wrote:
>>
>>> This is a new thread.
>>>
>>> Preamble: This model is quite different from the XAuth model.
>>> In particular, a RO has no relationship with any AS and a Client does
>>> not need to be associated with any AS prior to any access to a RS.
>>>
>>> A key point of this model is that the user's consent is handled locally
>>> by the Client and hence no AS nor RS is handling a man machine interfac=
e
>>> for the user consent. This allows to support locally the user consent
>>> for multiple ASs while keeping all ASs ignorant about the choices of th=
e
>>> user
>>> made for accessing a particular RS.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *       +--------+                           +------------+        |
>>> User  |                           |  Resource  |        |
>>> |                           | Owner (RO) |        +--------+
>>>                   +------------+            |
>>> \                              |            |
>>> \                             |            |
>>> \                            |            |
>>> \                           |     +-----------+     +---------------+
>>> +------------+     |           |---->| Authorization |     |           =
 |
>>>     |           | (2) |  Server (AS)  |     |            |     |
>>> |<----|               |     |            |     |  Client   |
>>> +---------------+     |            |     |
>>> |-------------------------->|  Resource  |     |   User    |
>>> (1)             |   Server   |     |  Consent
>>> |<--------------------------|    (RS)    |     |  element
>>> |                           |            |     |
>>> |-------------------------->|            |------>     |
>>> |           (3)             |            |  (4)     |
>>> |<--------------------------|            |<------
>>> +-----------+                           +------------+ *
>>> The flow of operations is as follows:
>>>
>>> The Client (which may have been previously authenticated using FIDO)
>>>
>> Which party has the client authenticated to? The client authenticating
>> with FIDO is confusing to me. FIDO is usually how a user authenticates.
>>
>> If the user has previously opened a user account with the RS using FIDO,
>> then the client may be authenticated by the RS using FIDO.
>> In such a case, the user is already known to the RS under a pseudonym
>> specific to the RS. It may (or may not) have previously presented access
>> tokens
>> to that RS.
>>
>>  contacts the RS and after some dialogue with the RS selects an
>> operation
>> How does the client know which RS to contact?
>>
>> For a private usage, the user may use DuckDuckGo, while for business he
>> may use an application from his company which lists various services
>> available in the context of his job or his position. Some services may b=
e
>> freely available to all the employees of the company with any
>> authentication,
>> e.g. the phone book of the employees may be freely available on the
>> intranet of the company, while some other services may require the user
>> to authenticate to the AS from the company.
>>
>>  that it wants to perform on the RS (1a). Note that it may also indicate
>> directly the operation that it wants to perform on the RS without any pr=
ior
>> dialogue.
>>
>>> In return (1b), the RS informs the Client about which attributes are
>>> needed by the RS for performing the requested operation and from which
>>> Attributes Servers
>>> they may be obtained.
>>>
>> (1a) and (1b) are not labeled. There is only (1)
>>
>> (1a) is the first exchange for (1) with the arrow from left to right,
>> while (1b) is the response with the arrow from right to left.
>> The same applies to the other exchanges i.e. (2) , (3) and (4).
>>
>>
>>> This information is specifically marked to indicate that it shall be
>>> handled by the "User Consent element" from the Client.
>>>
>> Why? What is the significance of this? Which information is marked?
>>
>> In the response, a specific identifier or a magic number is used to
>> indicate the start and the length of the information block
>> to be sent to the "User Consent element" supported by the Client.
>>
>> The presentation of that information is up to the man machine interface
>> supported by the "User Consent element" from the Client.
>>
>> Which information?
>>
>> The attributes that are needed by the RS for performing a requested
>> operation and from which Attributes Servers they may be obtained.
>>
>>
>>> The user can see which attributes are requested by the RS for performin=
g
>>> the requested operation and, if it consents, the Client contacts one or
>>> more
>>> appropriate Authorization Servers (2a).
>>>
>> How does the client know which AS(s) to contact?
>>
>> For each AS trusted by the RS to perfom a given operation, the RS should
>> indicate a user-friendly name and a URL of the AS.
>>
>> The user consent is hence captured locally by the Client (i.e. there is
>>> no dialogue with any AS nor any RS).
>>>
>>
>> No dialogue with who? The client is calling the AS is it not?
>>
>> For the user consent, there is no external call since it is handled
>> locally. Afterwards, there is a call to the AS(s) selected by the user.
>>
>>
>>> When the Client got the access tokens from these authorization servers
>>> (2b), it sends all of them in a single request to the RS (3a).
>>>
>>
>> So the RS must trust the AS that issued the tokens. And the AS must trus=
t
>> the Client to have gathered consent.
>>
>> Theses two assertions are correct.
>>
>> And the AS must have a relationship with the user.
>>
>> Only when the user chooses one AS while giving its consent, then the use=
r
>> must have a relationship with the selected AS.
>>
>> It is unclear what role the RO is playing in this though. The RO and RS
>> look to be the same entity from all the other parties.
>>
>> A RO, as indicated on the figure, has only a relationship with one RS: i=
t
>> has no relationship with any AS.
>> The RS trusts the AS but the AS does not know which RSs are trusting it.
>>
>>
>> From my current understanding, at a high level, this looks like it is
>> supported by GNAP with the addition of the discovery step (1).
>>
>> Well, it is fairly different :
>>
>> 1) The first major difference is that there is no arrow between the RO
>> and the AS. No protocol or "out-of-bands" means are necessary.
>>
>> 2) The second major difference is that there is no arrow between the AS
>> and the RS. No protocol is necessary.
>>
>> 3) The third major difference is that the AS does not know any RS. Note:
>> for backward compatibility reasons, an exception might exist for "old" A=
uth
>> 2.0 ASs.
>>
>> 4) The fourth major difference is that the XAuth spec. is rather vague t=
o
>> describe when and by who the user consent is captured:
>>     XAuth states on page 4: "User consent is *often *required at the
>> GS". In that case, the GS is able to act as Big Brother. No other case i=
s
>> described.
>> 5) The fifth major difference is that the data that is transferred to a
>> "User Consent Element" to capture the user consent. That data can be
>> standardized.
>>     Moreover, it will also be possible to standardize the dialogue
>> between the RO and the RS. The RO will then be able to manage remotely t=
he
>> authorization tables.
>>     See my email sent on June 6, with the following subject: "Support of
>> FIDO and data minimization by RSs".
>>
>> 6) Another difference is the following: since there is no interaction
>> between the RO and the AS, "authorizations from the RO" as described in
>> XAuth do not exist.
>>
>> There have been a number of proposals for doing this discovery, and
>> perhaps now there are enough use cases to look at standardizing somethin=
g.
>> No interaction is needed between the AS and the User as the Client is
>> providing enough "information" in the user object of the Grant Request
>> to satisfy the AS releasing the access tokens.
>>
>> Not sure I understand correctly this last sentence.
>>
>>
>> Perhaps as I understand the model in more detail I will understand what
>> is missing from GNAP (besides the discovery step).
>>
>> It would be hard to say "what is missing" from XAuth since the
>> foundations are not the same.
>>
>> In order to compare different architectures, there is the need to start
>> with the trust relationships.
>> Unfortunately, the word "trust" is absent in the main body of
>> draft-hardt-xauth-protocol-12. Hence,
>> the description of the trust relationships is missing.
>>
>> Denis
>>
>>
>> /Dick
>>
>> (I've skipped reviewing the delegation use case below until I understand
>> the simple use case)
>>
>>
>>> End of the story for a simple access
>>>
>>>
>>> Start of a subsequent story for a delegation case
>>>
>>> Let us now suppose that the RS is unable to fulfil the request by its
>>> own and that it needs to contact another RS. RS1 contacts RS2 (4a) and
>>> indicates the operation
>>> that it wants to perform on RS2 (that operation may not be the same as
>>> the original operation). In return (4b), RS2 informs RS1 about which
>>> attributes are needed
>>> by RS2 for performing the requested operation and from which Attributes
>>> Servers they may be obtained. RS1 forwards that information to the Clie=
nt.
>>>
>>> This information is marked to indicate that it shall be handled by the
>>> "User Consent element" from the Client. The presentation of that
>>> information is up to the man machine
>>> interface from the Client. The user can see which attributes are
>>> requested by RS2 for performing the new requested operation and, if it
>>> consents, the Client contacts one or more
>>> appropriate Authorization Servers. The user consent is hence captured
>>> locally by the "User Consent element" from the Client. (i.e. there is n=
o
>>> dialogue with any AS, nor RS1, nor RS2).
>>>
>>> When the Client got the access token(s) from the authorization
>>> server(s), it sends all of them in a single request to RS1. RS1 then
>>> forwards the additional access token(s) to RS2.
>>>
>>>
>>> Some observations:
>>>
>>> The user nor the Client are linked with any particular AS. A user may
>>> use today an AS of the Bank of America and may change tomorrow to the B=
ank
>>> of Missouri.
>>> As soon as he will be registered with the Bank of Missouri, he will be
>>> able to get access tokens from the AS of the Bank of Missouri. The AS o=
f
>>> Bank of America
>>> has not been able to know where its access tokens have been used. This
>>> will be the same for AS of the Bank of Missouri. There is no need for a=
ny
>>> direct dialogue
>>> between any AS and any RS at the time a client is making an access.
>>> There is no need for any RO to contact any AS.
>>>
>>> This model has been constructed following a "Privacy by Design" approac=
h.
>>> Denis
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>> =E1=90=A7
>>
>>
>>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000de98d405aa568132
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



I'm going to just address the first part of y=
our response so that we can get clarity on that before diving into your lat=
er comments.

The calls between your proposal and X=
Auth are not inverted, your proposal has a prior step. Step 1 in XAuth maps=
 to Step 2 in your proposal, and Step 2 in XAuth is Step 3 in your proposal=
.

Below are 2 diagrams showing the same steps, the=
 first keeping the existing step labels for XAuth, the latter renaming the =
steps to correspond to your proposal. This looks pretty similar to your dia=
gram. What am I missing?

/Dick

DIAGRAM 1 (steps sta=
rt at 0)
       +----=
----+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (0)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+


DIAGRAM 2 (steps start at 1)
       +--------+           =
                +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (2) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (3)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (1)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+
3D""=E1=90=A7
On M=
on, Jul 13, 2020 at 7:08 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hello Dick,

    


    

    
You wrote: "This looks pretty similar
      to your protocol drawing".

      

    

    
No. There is a fundamental difference
      with the sequencing of the flow of the exchanges where the (1) and
      (2) flows are inverted. 

    

    


    

    
In your figure:

    

    

      

        
The Client makes calls to the GS (1)

        
The Client makes calls to the RS (2)

      

      
while in my figure:

      

        

          
The Client makes calls to the RS (1)

          
The Client makes calls to the AS (2)

        

      

    

    
In your figure, the first flow is with
      the GS, whereas in my figure the first flow is with the RS and
      there is a good reason for that: 

      the client first contacts the RS to know what the RS expects. The
      client indicates in its first exchange to the RS whether it wants
      to authenticate 

      or to perform another operation.=C2=A0 In the case of an authenticati=
on
      operation, the RS may respond to the client that is supports FIDO
      U2F 

      or that it is willing the client to present some attribute(s) from
      one or more AS.

    


    

    
Then after the client has to figure out
      whether the user is using FIDO and if not whether the user has an
      account with one of the AS.

    
In the later case, if there is a match
      then the client, *after having received the user consent*,
      may contact the appropriate AS to ask 

      for some attribute(s). 

    

    


    

    
The same fundamental difference applies
      with draft-richer-transactional-authz-06 (XYZ) where the first
      exchange is done with the AS:

    
"The RC creates a transaction request
      and sends it to the AS".

    


    

    
This answers also in details to one of
      your comments:

    

      

        
What looks to be missing from your proposal is:

        
A) The Client making a call to the RS to discover what it
          needs from a GS, and which GS to ask, prior to (1).

      

    

    
This is not missing since this is the
      foundation of the architecture. The discovery mechanism at the RS
      has been described 

      in details in an earlier email with the following title: "Suppor=
t
      of FIDO and data minimization by RSs".

    


    

    

    
The main figures are copied below
      (using ASCII):
      
=C2=A0
              +-----------------------------------+-----------------=
----------------+

              =C2=A0 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 Operation=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mathematical
              expression=C2=A0=C2=A0=C2=A0 +

              =C2=A0 +-----------------------------------+----=
-----------------------------+

              =C2=A0 + Authentication=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 +
              Condition 1 OR Condition 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
              +

              =C2=A0 +-----------------------------------+----=
-----------------------------+

              =C2=A0 + Operation A OR
              Operation Z=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <=
/span>+
              Condition 3 AND Condition 4=C2=A0=C2=A0=C2=A0=C2=A0
              +

              =C2=A0 +-----------------------------------+----=
-----------------------------+

              

            Con=
ditions
              table: =


              

              =C2=A0 +-------------+--------------+-----------=
------------------+----------+

              =C2=A0 + Condition 1 +
              FIDO U2F 1.2 +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
              +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 +

              =C2=A0 +-------------+--------------+-----------=
------------------+----------+

              =C2=A0 + Condition 2 +
              AS 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 + set
              1 of a attributes types + =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+

              =C2=A0 +-------------+--------------+-----------=
------------------+----------+

              =C2=A0 + Condition 3 +
              AS 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 + set
              2 of a attributes types + Scope 21 +

              =C2=A0 +-------------+--------------+-----------=
------------------+----------+

              =C2=A0 + Condition 4 +
              AS 9=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 + set
              3 of a attributes types-+ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+

              =C2=A0 +-------------+--------------+-----------=
------------------+----------+

          

        According to the operation announced by the Client, the RS
        returns to the Client both the mathematical expression 

        associated with that operation and the conditions included in
        that mathematical expression. The Client may then 

        present that information to the user in order to obtain the user
        consent in a standardized manner.

      

    

    
Another comment you made is:

    

      
What looks to be missing from your proposal is:

      
B) A mechanism for the Client to prove to the GS that it has
        gathered consent from the User.

    

    
The user consent should not be captured *by the GS*, since the
      GS would be in a position to apply a different consent decision 

      without letting it know to the user (or to the client).

    


      The user consent must be captured *by the Client* and the Client
      must be able to verify that this consent has indeed been followed
      by the AS. 

    

    


    

    
The authorization data managed at the RS by the RO is used by
      the Client to query the consent of the user in a standardized
      manner.

    
When, later on, the access token is returned to the Client by
      the AS, the Client (not the user) using that authorization data as
      well as 

      the decision of the user is able to verify that the requested
      attributes (and no more) are indeed present into the access token.
      

      

      This is why access tokens may *not* be considered to be opaque to
      the Clients.

    


    

    
In my earlier email copied below, six major differences with
      XAuth from 1) to 6) are listed.

    


    

    
Denis

      

    

    

     =20
      
From=C2=A0https://tools.iet=
f.org/html/draft-hardt-xauth-protocol-10#section-1.1
        


          

            
1.1.  Parties


   The parties and their relationships to each other:


            
       +--------+       =
                    +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+



          

          

            


            

            
The lines without arrows represent relationships.=C2=A0
          

        

        
The User trusts the Client

        
The User trusts the GS

        
The RO trusts the GS to issue access tokens for the RS

        
The RS trusts the tokens issued by the RS

        
The RO controls the RS

        


        

        
The Client makes calls to the GS (1)

        
The Client makes calls to the RS (2)

        


        

        
This looks pretty similar to your protocol drawing.

        


        

        
What looks to be missing from your proposal is:

        


        

        
A) The Client making a call to the RS to discover what it
          needs from a GS, and which GS to ask, prior to (1).

        
B) A mechanism for the Client to prove to the GS that it
          has gathered consent from the User.

        


        

        
The current protocol does not require the GS to interact
          with either the User, the RO, or the RS -- which looks to me
          to meet your privacy=C2=A0goals.

        


        

      

      
3D""==E1=90=A7

      

      

        
On Fri, Jul 10, 2020 at 6:06
          AM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hi Dick,

            


            

            

              

                
Hi Denis, thanks for sharing the model. I
                  don't fully understand what is going on, questions
                  inserted:

              

            

            Responses are inserted.

            

              

                

                  


                  

                  
FWIW: having paragraphs start with the step
                    number (1), (2) etc. would make it easier to map
                    between the description and the diagram.

                

                

                

                  
On Thu, Jul 9, 2020
                    at 3:26 AM Denis <denis.ietf@free.fr>
                    wrote:

                  

                  

                    

                      

                        
This is a new thread.

                            

                            Preamble: This model is quite different from
                            the XAuth model. 

                            In particular, a RO has no relationship with
                            any AS and a Client does not need to be
                            associated with any AS prior to any access
                            to a RS.

                            

                            A key point of this model is that the user'=
s
                            consent is handled locally by the Client and
                            hence no AS nor RS is handling a man machine
                            interface 

                            for the user consent. This allows to support
                            locally the user consent for multiple ASs
                            while keeping all ASs ignorant about the
                            choices of the user 

                            made for accessing a particular 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=C2=A0
                                +------------+

                                =C2=A0=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=
=C2=A0
                                |

                                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
                                | Owner (RO) |

                                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
+--------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0+------------+

                                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                |

                                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                |

                                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0
                                \=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                |

                                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
                                \=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                |

                                =C2=A0=C2=A0=C2=A0 +----------=
-+=C2=A0 =C2=A0=C2=A0=C2=A0+---------------+=C2=A0=C2=A0=C2=A0=C2=A0
                                +------------+

                                =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---->|
                                Authorization |=C2=A0=C2=A0=C2=A0=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                                |

                                =C2=A0=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) |=C2=A0 Server (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=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0 |

                                =C2=A0=C2=A0=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=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=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (1)=C2=A0=C2=A0=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=C2=A0 |=C2=
=A0 Consent=C2=A0
                                |<--------------------------|=C2=A0=C2=A0=C2=A0
                                (RS)=C2=A0=C2=A0=C2=A0 =
|

                                =C2=A0=C2=A0=C2=A0 |=C2=
=A0 element=C2=A0
                                |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

                                =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---------=
----------------->|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0
                                |------>

                                =C2=A0=C2=A0=C2=A0 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=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 |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<-----=
---------------------|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0
                                |<------

                                =C2=A0=C2=A0=C2=A0 +----------=
-+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=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 flow of operations is as follows:

                            

                            The Client (which may have been previously
                            authenticated using FIDO) 

                      

                    

                  

                  
Which party has the client authenticated to? The
                    client authenticating with FIDO is confusing to me.
                    FIDO is usually how a user authenticates.

                

              

            

            
If the user has previously opened a user account with the
              RS using FIDO, then the client may be authenticated by the
              RS using FIDO.

              In such a case, the user is already known to the RS under
              a pseudonym specific to the RS. It may (or may not) have
              previously presented access tokens 

              to that RS.

            

            

              

                

                  
=C2=A0contacts the RS and after
                      some dialogue with the RS selects an operation 

                    

                  
How does the client know which RS to contact?

                

              

            

            
For a private usage, the user may use DuckDuckGo, while
              for business he may use an application from his company
              which lists various services 

              available in the context of his job or his position. Some
              services may be freely available to all the employees of
              the company with any authentication,

              e.g. the phone book of the employees may be freely
              available on the intranet of the company, while some other
              services may require the user 

              to authenticate to the AS from the company.

            

              

                

                  
=C2=A0that it wants to perform =
on
                      the RS (1a). Note that it may also indicate
                      directly the operation that it wants to perform on
                      the RS without any prior dialogue. 

                    

                  

                    

                      

                        
 In return (1b), the RS
                            informs the Client about which attributes
                            are needed by the RS for performing the
                            requested operation and from which
                            Attributes Servers 

                            they may be obtained. 

                          

                      

                    

                  

                  
(1a) and (1b) are not labeled. There is only (1)
                    

                  

                

              

            

            
(1a) is the first exchange for (1) with the arrow from
              left to right, while (1b) is the response with the arrow
              from right to left. 

              The same applies to the other exchanges i.e. (2) , (3) and
              (4).

            

            

              

                

                  

                    

                      

                        
 

                            This information is specifically marked to
                            indicate that it shall be handled by the
                            "User Consent element" from the Clien=
t. 

                          

                      

                    

                  

                  
Why? What is the significance of this? Which
                    information is marked?

                

              

            

            
In the response, a specific identifier or a magic number
              is used to indicate the start and the length of the
              information block=C2=A0 

              to be sent to the "User Consent
                element" supported by the Client.

            

            

              

                

                  

                    
The presentation of that
                        information is up to the man machine interface
                        supported by the "User Consent element" f=
rom the
                        Client. 

                      

                  

                  


                  

                  
Which information? 

                  

                

              

            

            
The attributes that are needed by the
                RS for performing a requested operation and from which
                Attributes Servers they may be obtained.

            

              

                

                  

                    

                      

                        
 

                            The user can see which attributes are
                            requested by the RS for performing the
                            requested operation and, if it consents, the
                            Client contacts one or more 

                            appropriate Authorization Servers (2a). =


                      

                    

                  

                  
How does the client know which AS(s) to contact?
                

              

            

            
For each AS trusted by the RS to perfom a given
              operation, the RS should indicate a user-friendly name and
              a URL of the AS. 

            

            

              

                

                  

                    

                      

                        
The user consent is hence
                            captured locally by the Client (i.e. there
                            is no dialogue with any AS nor any RS).

                          

                      

                    

                  

                  


                  

                  
No dialogue with who? The client is calling the
                    AS is it not? 

                  

                

              

            

            
For the user consent, there is no external call since it
              is handled locally. Afterwards, there is a call to the
              AS(s) selected by the user.

            

              

                

                  

                    

                      

                        
 

                            When the Client got the access tokens from
                            these authorization servers (2b), it sends
                            all of them in a single request to the RS
                            (3a).

                          

                      

                    

                  

                  


                  

                  
So the RS must trust the AS that issued the
                    tokens. And the AS must trust the Client to have
                    gathered consent.

                

              

            

            Theses two assertions are correct.

            

              

                

                  
 And the AS must have a relationship with the
                    user. 

                

              

            

            
Only when the user chooses one AS while giving its
              consent, then the user must have a relationship with the
              selected AS.

            

              

                

                  
It is unclear what role the RO is playing in this
                    though. The RO and RS look to be the same entity
                    from all the other parties.

                

              

            

            
A RO, as indicated on the figure, has only a relationship
              with one RS: it has no relationship with any AS. 

              The RS trusts the AS but the AS does not know which RSs
              are trusting it.

            

              

                

                  


                  

                  
From my current understanding, at a high level,
                    this looks like it is supported by GNAP with the
                    addition of the discovery step (1). 

                

              

            

            
Well, it is fairly different : 

            

            

              
1) The first major difference is that there is no arrow
                between the RO and the AS. No protocol or "out-of-band=
s"
                means are necessary. 

              

              
2) The second major difference is that there is no
                arrow between the AS and the RS. No protocol is
                necessary. 

              
3) The third major difference is that the AS does not
                know any RS. Note: for backward compatibility reasons,
                an exception might exist for "old" Auth 2.0 ASs.<=
br>
              

              
4) The fourth major difference is that the XAuth spec.
                is rather vague to describe when and by who the user
                consent is captured: 

                =C2=A0=C2=A0=C2=A0 XAuth states on page 4: "User conse=
nt is often required
                at the GS". In that case, the GS is able to act as Big
                Brother. No other case is described.

              

              5) The fifth major difference is that the data that is
              transferred to a "User Consent Element" to capture =
the
              user consent. That data can be standardized. 

              =C2=A0=C2=A0=C2=A0 Moreover, it will also be possible to stan=
dardize the
              dialogue between the RO and the RS. The RO will then be
              able to manage remotely the authorization tables.

              =C2=A0=C2=A0=C2=A0 See my email sent on June 6, with the foll=
owing
              subject: "Support of FIDO and data minimization by RSs&q=
uot;.

              

              6) Another difference is the following: since there is no
              interaction between the RO and the AS, "authorizations
              from the RO" as described in XAuth do not exist. =C2=A0 =


            

              

                

                  
There have been a number of proposals for doing
                    this discovery, and perhaps now there are enough use
                    cases to look at standardizing something.=C2=A0 

                    No interaction=C2=A0is needed between the AS and the Us=
er
                    as the Client is providing enough "information&quo=
t; in
                    the user object of the Grant Request 

                    to satisfy the AS releasing the access tokens. 

                  

                

              

            

            Not sure I understand correctly this last sentence.

            

              

                

                  


                  

                  
Perhaps as I understand the model in more detail
                    I will understand what is missing from GNAP (besides
                    the discovery step).

                

              

            

            
It would be hard to say "what is missing" from XAu=
th
              since the foundations are not the same.

            
In order to compare different architectures, there is the
              need to start with the trust relationships. 

              Unfortunately, the word "trust" is absent in the ma=
in body
              of draft-hardt-xauth-protocol-12. Hence, 

              the description of the trust relationships is missing.

            

            
Denis

            

              

                

                  


                  

                  
/Dick

                  


                  

                  
(I've skipped reviewing the delegation use case
                    below until I understand the simple use case)

                  


                  

                  

                    

                      

                        
 

                            End of the story for a simple access

                        
 

                            Start of a subsequent story for a delegation
                            case

                            

                            Let us now suppose that the RS is unable to
                            fulfil the request by its own and that it
                            needs to contact another RS. RS1 contacts
                            RS2 (4a) and indicates
                            the operation 

                            that it wants to perform on RS2 (that
                            operation may not be the same as the
                            original operation). In return (4b), RS2
                            informs RS1 about which attributes are
                            needed 

                            by RS2 for performing the requested
                            operation and from which Attributes Servers
                            they may be obtained. RS1 forwards that
                            information to the Client. 

                            

                            This information is marked to indicate that
                            it shall be handled by the "User Consent
                            element" from the Client. The presentation
                            of that information is up to the man machine
                            

                            interface from the Client. The user can see
                            which attributes are requested by RS2 for
                            performing the new requested operation and,
                            if it consents, the Client contacts one or
                            more 

                            appropriate Authorization Servers. The user
                            consent is hence captured locally by the
                            "User Consent element" from the Clien=
t.
                            (i.e. there is no dialogue with any AS, nor
                            RS1, nor RS2). 

                            

                            When the Client got the access token(s) from
                            the authorization server(s), it sends all of
                            them in a single request to RS1. RS1 then
                            forwards the additional access token(s) to
                            RS2.

                            

                            

                            Some observations: 

                            

                            The user nor the Client are linked with any
                            particular AS. A user may use today an AS of
                            the Bank of America and may change tomorrow
                            to the Bank of Missouri. 

                            As soon as he will be registered with the
                            Bank of Missouri, he will be able to get
                            access tokens from the AS of the Bank of
                            Missouri. The AS of Bank of America 

                            has not been able to know where its access
                            tokens have been used. This will be the same
                            for AS of the Bank of Missouri. There is no
                            need for any direct dialogue 

                            between any AS and any RS at the time a
                            client is making an access. There is no need
                            for any RO to contact any AS.

                        
This model has been
                            constructed following a "Privacy by Design=
"
                            approach.

                        Denis

                      

                    

                    -- 

                    Txauth mailing list

                    Tx=
auth@ietf.org

                    https://www.ietf.org/mailman/listinf=
o/txauth

                  

                

              

              
3D""=E1=90=A7

            

            


            

          

        

      

    

    


    

  


-- 

Txauth mailing list

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




--000000000000de98d405aa568132--


From nobody Mon Jul 13 11:13: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 64FDB3A18C6 for ; Mon, 13 Jul 2020 11:13:09 -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 zrhDU3HAl-PL for ; Mon, 13 Jul 2020 11:13:07 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 C89973A1767 for ; Mon, 13 Jul 2020 11:12:44 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id h19so19050024ljg.13 for ; Mon, 13 Jul 2020 11:12: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=mXHvxCfhKSurLI1wbmltitwpSOF4JuO9og7aOU0hb6w=; b=XAkgiQSPyl4mxiUzp/LmvzlEfAxHETCDfQPibpZ0hwD+/t45Fc7eiZ8daDTzdaJERG GFlcbHlJjslD/5R3rYL6zF1MBBnh+Fsv5MrRKJ0sCX2SJSwVbSMYu25RmAMz9NoKlM7i IqtOwBwWI5f2pLgckDLmZEESz95utKBue4UMwveuwHrV1jCp3DK8TXr5smusoVbRIFuy wTtNUpBhffG7xoswDVFJPZi3OhadEfohHkKh1eSiCckBrXIfoISb0ce3qkNVHWoLXZRQ 6iiVoW0SrTCdTVHvQm4W6KuOhqtJbLycgLDZ2f4QOt9cCbNXg8JVpE1nbF9DguCCrEuB qmGw==
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=mXHvxCfhKSurLI1wbmltitwpSOF4JuO9og7aOU0hb6w=; b=BbzUJjI9WljlTOXS+xlou+sJdCVkJc/t7gtKEq2iKpIc4k7c7HfPCEMOhktXE6K/du fCJCmU9tPgJI5eovTssvrB5CsAmi3Vjm/VlS+9diHEL+RQ0Sco8ZKSyNm+64oKcWxm84 Ufsu24gkqfdpFrBNBthNqnspNTzqaZbwYgwvd8l4BI0aZ6hThno98KzBZweIo0qQexu+ m4JKyc4lN62jV7Cj6FCiXcjHYAVuqOHBUuD8XsK/eWDaYFaF0AfFekeyIORvNFtkK2eJ GWtNt3k0DjvGSOKjNj+MsWfkixLY2WltRwepApMRdPxTK1zidLB37G1qJpdgS+stk7Y4 0Wxg==
X-Gm-Message-State: AOAM530y9kspezVBIQTVVYMNfGUSvWL+hZE+geFCcnvXlPo3qSgpkgga 4fiuwvj9JPP2IKYI7tGn/9APhAlKZiwiCymJ3OQ=
X-Google-Smtp-Source: ABdhPJxK1ZYI0xnig3FIPVIrvOzZ+C0EMNAn39cpE+lAWDU21fnh4PHvAsStLZiWjM7cwsRarchkQEp4bURAfpkuvjg=
X-Received: by 2002:a2e:8316:: with SMTP id a22mr417816ljh.246.1594663962714;  Mon, 13 Jul 2020 11:12:42 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu>  <174F2061-3F0F-49B2-A18F-58DF658E4473@mit.edu>
In-Reply-To: <174F2061-3F0F-49B2-A18F-58DF658E4473@mit.edu>
From: Dick Hardt 
Date: Mon, 13 Jul 2020 11:12:06 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000008a92805aa56a30c"
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 13 Jul 2020 18:13:12 -0000

--00000000000008a92805aa56a30c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree that an API to return claims is useful. I think we have agreed on
that.

Using the SubjectIdentifiers schema is another schema that would be useful
for GNAP to support.

I disagree that GNAP should be limited to identifier claims.

=E1=90=A7

On Mon, Jul 13, 2020 at 7:16 AM Justin Richer  wrote:

> One thing I think we should learn from OIDC is that returning claims from
> an API, and not just an assertion or direct response, is a powerful and
> useful pattern. We have an opportunity to separate these cleanly, where
> OIDC didn=E2=80=99t have the opportunity in defining the =E2=80=9Cclaims=
=E2=80=9D request parameter.
>
> As an alternative to the current XYZ and XAuth syntaxes, over the weekend
> I=E2=80=99ve been playing with something that would look like this strawm=
an in the
> request:
>
>
> {
>    subject: {
>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9C=
iss-sub=E2=80=9D],
>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifiable_c=
redential=E2=80=9D, =E2=80=9Csaml" ]
>    }
> }
>
>
> This request says that I=E2=80=99d like some subset of these identifiers =
(as plain
> text in the response) and some subset of signed assertions in the given
> formats. Each one would have an associated space in the return. I=E2=80=
=99m not
> picturing that the =E2=80=9Cid=E2=80=9D field values would affect the con=
tents of the
> assertions: so I could ask for an email address identifier but get back a=
n
> ID token that had only the subject identifier. Maybe that=E2=80=99s not t=
he right
> model? But it=E2=80=99s at least simple and deterministic this way, and i=
t=E2=80=99s
> something to play with.
>
> Note: The =E2=80=9Cid=E2=80=9D names are taken from
> https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.html=
,
> the =E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=99t see=
 a source that collected
> them. If you wanted specific bundles of claims about the user from a
> UserInfoEndpoint, for example, you=E2=80=99d have something like:
>
> {
>    subject: {
>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9C=
iss-sub=E2=80=9D],
>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifiable_c=
redential=E2=80=9D, =E2=80=9Csaml" ]
>    },
>    resources: [{
>        type: =E2=80=9Cuserinfo=E2=80=9D,
>        datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =
=E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
>   }]
> }
>
>
> This is an example for a specific kind of resource, and I don=E2=80=99t t=
hink that
> GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, or the dat=
atype values
> therein. That should be work outside of GNAP, probably for the OIDF.
>
> This approach is extensible in several ways, each of them for a specific
> reason that I think is clear:
>
>  - new values in the =E2=80=9Cid=E2=80=9D field to give new identifiers
>  - new values in the =E2=80=9Cassertion=E2=80=9D field to give new assert=
ion formats
>  - new fields under the =E2=80=9Csubject=E2=80=9D heading
>  - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cs=
cim-v1=E2=80=9D or
> =E2=80=9Cfacebook-profile=E2=80=9D for instance)
>  - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource type
>  - new top-level request parameters
>
> As per the other thread, if you wanted to use the OIDC query language,
> you=E2=80=99d package it separately as a top-level request parameter sinc=
e it can
> include both the ID token response and the access token response and we
> shouldn=E2=80=99t be encouraging mixing these things together.
>
>  =E2=80=94 Justin
>
> On Jul 10, 2020, at 5:00 PM, Dick Hardt  wrote:
>
> It looks to me that our different views of what is in scope for GNAP are
> the differences below.
>
> Per the subject line, I'm looking at how the client acquires claims about
> the user. You don't think that is in scope, and that a different layer wi=
ll
> solve that.
>
> I think we should learn from OIDC being on top of OAuth, and GNAP should
> be able return ANY claim, not just identifier claims. There are use cases
> that may be difficult to support if we do not have that functionality in
> scope, such as some of the ones I list below, and it seems pretty
> straightforward to support ANY claim if we are supporting identifiers.
>
> /Dick
>
>
> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer  wrote:
>
>>
>>
>> On Jul 10, 2020, at 2:15 PM, Dick Hardt  wrote:
>>
>>
>> inline ...
>>
>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer  wrote:
>>
>>> Yes, the core idea is to not have to parse an assertion to get back the
>>> core authentication information, which consists of an identifier (iss/s=
ub
>>> pair in OIDC, but could be a number of things). Sometimes the client is
>>> going to want the rest of the identity information, but If the user=E2=
=80=99s
>>> logged into the client before, the client has likely cached that info a=
nd
>>> probably won=E2=80=99t need it, and sending it would be a violation of =
privacy
>>> principles.. The client would want the info pretty much just in these c=
ases:
>>>
>>>  1. The client has never seen the user before.
>>>  2. The user=E2=80=99s information has been updated since the last time=
 the
>>> client saw it.
>>>
>>
>> Agreed
>>
>>
>>>
>>> Now for case (1), how would the client know if it wants to request the
>>> user=E2=80=99s profile info or not, since it doesn=E2=80=99t know who t=
he user is?
>>>
>>
>> But the client could know who the user is. The client may have used a
>> different AS to authenticate the user.
>>
>>
>> In these cases, the client is not going to be requesting identity
>> information from the AS to log the user in, so it=E2=80=99s not relevant=
 to the use
>> case. The client will have an opportunity to push that information to th=
e
>> AS.
>>
>> The User may have self identified to the client. The client may have a
>> cookie saying who the user was and the user said that was them. While th=
e
>> latter cases are really a strong hint, they are likely right most of the
>> time and can lead to a user experience basde on that hint
>>
>>
>> In these cases, the AS might be able to guess if the client has info
>> about the user already, but probably not. And the assumptions fall apart=
 if
>> it=E2=80=99s in fact a different user that ends up logging in, which is =
of course
>> possible (the hint you gave doesn=E2=80=99t match the identity of the cu=
rrent user
>> after the AS validates them). This possibility leads to clients always
>> asking for everything every time and the server providing everything eve=
ry
>> time. That=E2=80=99s a pattern I think we should avoid in an ultimate so=
lution =E2=80=94
>> but ultimately, I don=E2=80=99t think that this kind of protocol decisio=
n is inside
>> of GNAP.
>>
>>
>>
>>> And the AS won=E2=80=99t know if client is going to want the profile in=
fo, since
>>> the AS won=E2=80=99t know if the client has the user=E2=80=99s info or =
not. Sure, the AS
>>> might have seen that client and that user combo previously, but it does=
n=E2=80=99t
>>> know if the client needs an update.
>>>
>>
>> The client can share with the AS the user it knows or thinks it is
>> dealing with, which could let the AS respond if the information was new.
>> This could be the case for an AS that is providing claims, but not
>> authentication, and could happen silently. The user would only interact =
if
>> the user information had changed, and the client wanted the updated
>> information.
>>
>>
>>
>> See above.
>>
>>
>>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s info h=
as been updated
>>> or not because it doesn=E2=80=99t know who the user is yet. If the AS c=
an provide
>>> some time of updated stamp to the client, the client can pull the new i=
nfo
>>> when it needs it.
>>>
>>
>> See above.
>>
>>
>> See above.
>>
>>
>>
>>>
>>> If you ignore both of these cases and put all the user information
>>> inline with the main request/response, you end up in a situation where =
the
>>> client always requests everything and the server always provides
>>> everything, since you can=E2=80=99t be sure you=E2=80=99re not in situa=
tion (1) or (2)
>>> ahead of time.
>>>
>>
>> See above. There are a number of other states the client could be in.
>>
>> For example, the client could be stateless about user information, so it
>> knows it is ALWAYS in state 1.
>>
>>
>> A stateless client would need to fetch appropriate user information ever=
y
>> time, then. But that=E2=80=99s an optimization for a very specific case.
>>
>>
>>
>>>
>>> This is really what I mean about the two-stage identity protocol.
>>>
>>
>> I know what it is. Per above, GNAP lets us support a wider set of use
>> cases. Why limit ourselves to what OIDC supported?
>>
>>
>> We aren=E2=80=99t limiting the protocol, but instead limiting the scope =
of what
>> we define internal to the GNAP protocol. There=E2=80=99s a lot of room f=
or
>> innovation on top of it.
>>
>>
>>
>>> In the first stage, you push the bare minimum of what you need to get
>>> the user known to the client. In the second stage, the client uses its
>>> access token to call an API to get whatever else it needs to know about=
 the
>>> user.
>>>
>>
>> From a privacy perspective in non-enterprise use cases, I think the user
>> should give consent to any updated personal information to a client. In
>> general, the client should not be able to get the latest information abo=
ut
>> a user whenever it wants.
>>
>>
>> This is about the rights associated with the access token, then. And an
>> access token doesn=E2=80=99t have to keep working if the AS has a policy=
 that says
>> it won=E2=80=99t. The AS/RS could easily decide that a particular access=
 token will
>> only return data that hasn=E2=80=99t been changed. Maybe it stops workin=
g after the
>> data changes, or it just returns old data, or any number of things. This=
 is
>> for the AS/RS to decide and this is pretty standard interpretation of th=
e
>> token, nothing special here because we=E2=80=99re dealing with identity.
>>
>>  =E2=80=94 Justin
>>
>>
>> /Dick
>> =E1=90=A7
>>
>>
>>
>

--00000000000008a92805aa56a30c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I agree that an API to return claims is useful. I think we=
 have agreed on that.=C2=A0

Using the SubjectIdentifiers=
 schema is another schema that would be useful for GNAP to support.=C2=A0

I disagree=C2=A0that GNAP should be limited to iden=
tifier claims.=C2=A0

3D""=E1=90=A7
On =
Mon, Jul 13, 2020 at 7:16 AM Justin Richer <jricher@mit.edu> wrote:
One thing I=
 think we should learn from OIDC is that returning claims from an API, and =
not just an assertion or direct response, is a powerful and useful pattern.=
 We have an opportunity to separate these cleanly, where OIDC didn=E2=80=99=
t have the opportunity in defining the =E2=80=9Cclaims=E2=80=9D request par=
ameter.

As an alternative to the current XYZ and XAuth s=
yntaxes, over the weekend I=E2=80=99ve been playing with something that wou=
ld look like this strawman in the request:


{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id: [=
 =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=80=
=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Codic_id_token=E2=
=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
=C2=A0 =C2=A0}
}

This=
 request says that I=E2=80=99d like some subset of these identifiers (as pl=
ain text in the response) and some subset of signed assertions in the given=
 formats. Each one would have an associated space in the return. I=E2=80=99=
m not picturing that the =E2=80=9Cid=E2=80=9D field values would affect the=
 contents of the assertions: so I could ask for an email address identifier=
 but get back an ID token that had only the subject identifier. Maybe that=
=E2=80=99s not the right model? But it=E2=80=99s at least simple and determ=
inistic this way, and it=E2=80=99s something to play with.

Note: The =E2=80=9Cid=E2=80=9D names are taken from=C2=A0https://tools.ietf.org/id/draft-ietf-secevent-subject=
-identifiers-05.html, the =E2=80=9Cassertion=E2=80=9D names are made up=
 as I didn=E2=80=99t see a source that collected them. If you wanted specif=
ic bundles of claims about the user from a UserInfoEndpoint, for example, y=
ou=E2=80=99d have something like:

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Cod=
ic_id_token=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csam=
l" ]
=C2=A0 =C2=A0},
=C2=A0 =
=C2=A0resources: [{
=C2=A0 =C2=A0 =C2=A0 =C2=A0type: =
=E2=80=9Cuserinfo=E2=80=9D,
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =E2=80=
=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
=C2=A0 }]=

}

This is=
 an example for a specific kind of resource, and I don=E2=80=99t think that=
 GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, or the data=
type values therein. That should be work outside of GNAP, probably for the =
OIDF.

This approach is extensible in several ways,=
 each of them for a specific reason that I think is clear:

=C2=A0- new values in the =E2=80=9Cid=E2=80=9D field to give new i=
dentifiers
=C2=A0- new values in the =E2=80=9Cassertion=E2=80=9D =
field to give new assertion formats
=C2=A0- new fields under the =
=E2=80=9Csubject=E2=80=9D heading=C2=A0
=C2=A0- new resource type=
s besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or =E2=
=80=9Cfacebook-profile=E2=80=9D for instance)
=C2=A0- new datatyp=
es within the =E2=80=9Cuserinfo=E2=80=9D resource type
=C2=A0- ne=
w top-level request parameters

As per the other th=
read, if you wanted to use the OIDC query language, you=E2=80=99d package i=
t separately as a top-level request parameter since it can include both the=
 ID token response and the access token response and we shouldn=E2=80=99t b=
e encouraging mixing these things together.

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

On Jul 10, 2020=
, at 5:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It looks to me that our different views of what is in scope for GNAP ar=
e the differences below.

Per the subject line, I'm l=
ooking at how the client acquires claims about the user. You don't thin=
k that is in scope, and that a different layer will solve that.
<=
br>
I think we should learn from OIDC being on top of OAuth, and =
GNAP should be able return ANY claim, not just identifier claims. There are=
 use cases that may be difficult to support if we do not have that function=
ality in scope, such as some of the ones I list below, and it seems pretty =
straightforward to support ANY claim if we are supporting identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09=
 PM Justin Richer <=
jricher@mit.edu> wrote:


On Jul 10, =
2020, at 2:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


inline ...=C2=A0

On Thu, Jul 9, 2020 at 5=
:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea is to not have to parse an assert=
ion to get back the core authentication information, which consists of an i=
dentifier (iss/sub pair in OIDC, but could be a number of things). Sometime=
s the client is going to want the rest of the identity information, but=C2=
=A0If the user=E2=80=99s logged into the client before, the client has like=
ly cached that info and probably won=E2=80=99t need it, and sending it woul=
d be a violation of privacy principles.. The client would want the info pre=
tty much just in these cases:

=C2=A01. The client has ne=
ver seen the user before.=C2=A0
=C2=A02. The user=E2=80=99s infor=
mation has been updated since the last time the client saw it.
<=
/blockquote>

Agreed
=C2=A0

Now for case (=
1), how would the client know if it wants to request the user=E2=80=99s pro=
file info or not, since it doesn=E2=80=99t know who the user is? 

But the client could know who the user i=
s. The client may have used a different AS to authenticate the user. 
=


In these cases, th=
e client is not going to be requesting identity information from the AS to =
log the user in, so it=E2=80=99s not relevant to the use case. The client w=
ill have an opportunity to push that information to the AS.

<=
div>The User may have self identified to the client. The client may have a =
cookie saying who the user was and the user said that was them. While the l=
atter cases are really a strong hint, they are likely right most of the tim=
e and can lead to a user experience basde on that hint

In these cases, the AS might be a=
ble to guess if the client has info about the user already, but probably no=
t. And the assumptions fall apart if it=E2=80=99s in fact a different user =
that ends up logging in, which is of course possible (the hint you gave doe=
sn=E2=80=99t match the identity of the current user after the AS validates =
them). This possibility leads to clients always asking for everything every=
 time and the server providing everything every time. That=E2=80=99s a patt=
ern I think we should avoid in an ultimate solution =E2=80=94 but ultimatel=
y, I don=E2=80=99t think that this kind of protocol decision is inside of G=
NAP.

=C2=A0
And the AS won=E2=80=99t know if client is going to wa=
nt the profile info, since the AS won=E2=80=99t know if the client has the =
user=E2=80=99s info or not. Sure, the AS might have seen that client and th=
at user combo previously, but it doesn=E2=80=99t know if the client needs a=
n update.

The client can share =
with the AS the user it knows or thinks it is dealing with, which could let=
 the AS respond if the information was new. This could be the case for an A=
S that is providing claims, but not authentication, and could happen silent=
ly. The user would only interact if the user information had changed, and t=
he client wanted the updated information.
=C2=A0

See above.


And =
for (2), the client won=E2=80=99t know if the user=E2=80=99s info has been =
updated or not because it doesn=E2=80=99t know who the user is yet. If the =
AS can provide some time of updated stamp to the client, the client can pul=
l the new info when it needs it.

See above.

See a=
bove.

=C2=A0

If you ignore both of these cases=
 and put all the user information inline with the main request/response, yo=
u end up in a situation where the client always requests everything and the=
 server always provides everything, since you can=E2=80=99t be sure you=E2=
=80=99re not in situation (1) or (2) ahead of time.

See above. There are a number of other states the clie=
nt could be in.

For example, the client could be s=
tateless about user information, so it knows it is ALWAYS in state 1.
=


A stateless client=
 would need to fetch appropriate user information every time, then. But tha=
t=E2=80=99s an optimization for a very specific case.

=
=C2=A0
This is really what I mean about the two-stage identity protoco=
l. 

I know what it is. Per abov=
e, GNAP lets us support a wider set of use cases. Why limit ourselves to wh=
at OIDC supported?

We aren=E2=80=99t limiting the protocol, but instead limiting the sco=
pe of what we define internal to the GNAP protocol. There=E2=80=99s a lot o=
f room for innovation on top of it.

=C2=A0
In the first stage, you=
 push the bare minimum of what you need to get the user known to the client=
. In the second stage, the client uses its access token to call an API to g=
et whatever else it needs to know about the user. 
=


From a privacy perspective in non-enterprise use cases,=
 I think the user should give consent to any updated personal information t=
o a client. In general, the=C2=A0client should not be able to get the lates=
t information about a user whenever it wants.
=


This is about the rights associated with t=
he access token, then. And an access token doesn=E2=80=99t have to keep wor=
king if the AS has a policy that says it won=E2=80=99t. The AS/RS could eas=
ily decide that a particular access token will only return data that hasn=
=E2=80=99t been changed. Maybe it stops working after the data changes, or =
it just returns old data, or any number of things. This is for the AS/RS to=
 decide and this is pretty standard interpretation of the token, nothing sp=
ecial here because we=E2=80=99re dealing with identity.

=C2=A0=E2=80=94 Justin

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







--00000000000008a92805aa56a30c--


From nobody Mon Jul 13 11:51: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 927213A1762 for ; Mon, 13 Jul 2020 11:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 lCERut2Jf7tm for ; Mon, 13 Jul 2020 11:51:24 -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 941593A172A for ; Mon, 13 Jul 2020 11:51:24 -0700 (PDT)
Received: from [192.168.1.7] (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 06DIpMCY001025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jul 2020 14:51:23 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_0A159823-E591-453E-A38E-9D0C5B4F34F7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 13 Jul 2020 14:51:22 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu>  <174F2061-3F0F-49B2-A18F-58DF658E4473@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 13 Jul 2020 18:51:31 -0000

--Apple-Mail=_0A159823-E591-453E-A38E-9D0C5B4F34F7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I am saying that GNAP, it its definition within this working group, =
should be limited to identifier claims. Other claims can come from other =
protocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop =
them from being built, but in my opinion we shouldn=E2=80=99t be =
defining those here. See the discussion below on the extensibility =
avenues of this approach.

 =E2=80=94 Justin

> On Jul 13, 2020, at 2:12 PM, Dick Hardt  wrote:
>=20
> I agree that an API to return claims is useful. I think we have agreed =
on that.=20
>=20
> Using the SubjectIdentifiers schema is another schema that would be =
useful for GNAP to support.=20
>=20
> I disagree that GNAP should be limited to identifier claims.=20
>=20
> =E1=90=A7
>=20
> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer > wrote:
> One thing I think we should learn from OIDC is that returning claims =
from an API, and not just an assertion or direct response, is a powerful =
and useful pattern. We have an opportunity to separate these cleanly, =
where OIDC didn=E2=80=99t have the opportunity in defining the =
=E2=80=9Cclaims=E2=80=9D request parameter.
>=20
> As an alternative to the current XYZ and XAuth syntaxes, over the =
weekend I=E2=80=99ve been playing with something that would look like =
this strawman in the request:
>=20
>=20
> {
>    subject: {
>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =
=E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
>    }
> }
>=20
> This request says that I=E2=80=99d like some subset of these =
identifiers (as plain text in the response) and some subset of signed =
assertions in the given formats. Each one would have an associated space =
in the return. I=E2=80=99m not picturing that the =E2=80=9Cid=E2=80=9D =
field values would affect the contents of the assertions: so I could ask =
for an email address identifier but get back an ID token that had only =
the subject identifier. Maybe that=E2=80=99s not the right model? But =
it=E2=80=99s at least simple and deterministic this way, and it=E2=80=99s =
something to play with.
>=20
> Note: The =E2=80=9Cid=E2=80=9D names are taken from =
https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.html =
, the =E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=99t =
see a source that collected them. If you wanted specific bundles of =
claims about the user from a UserInfoEndpoint, for example, you=E2=80=99d =
have something like:
>=20
> {
>    subject: {
>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =
=E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
>    },
>    resources: [{
>        type: =E2=80=9Cuserinfo=E2=80=9D,
>        datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D,=
 =E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
>   }]
> }
>=20
> This is an example for a specific kind of resource, and I don=E2=80=99t =
think that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema =
here, or the datatype values therein. That should be work outside of =
GNAP, probably for the OIDF.
>=20
> This approach is extensible in several ways, each of them for a =
specific reason that I think is clear:
>=20
>  - new values in the =E2=80=9Cid=E2=80=9D field to give new =
identifiers
>  - new values in the =E2=80=9Cassertion=E2=80=9D field to give new =
assertion formats
>  - new fields under the =E2=80=9Csubject=E2=80=9D heading=20
>  - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =
=E2=80=9Cscim-v1=E2=80=9D or =E2=80=9Cfacebook-profile=E2=80=9D for =
instance)
>  - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource type
>  - new top-level request parameters
>=20
> As per the other thread, if you wanted to use the OIDC query language, =
you=E2=80=99d package it separately as a top-level request parameter =
since it can include both the ID token response and the access token =
response and we shouldn=E2=80=99t be encouraging mixing these things =
together.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 10, 2020, at 5:00 PM, Dick Hardt > wrote:
>>=20
>> It looks to me that our different views of what is in scope for GNAP =
are the differences below.
>>=20
>> Per the subject line, I'm looking at how the client acquires claims =
about the user. You don't think that is in scope, and that a different =
layer will solve that.
>>=20
>> I think we should learn from OIDC being on top of OAuth, and GNAP =
should be able return ANY claim, not just identifier claims. There are =
use cases that may be difficult to support if we do not have that =
functionality in scope, such as some of the ones I list below, and it =
seems pretty straightforward to support ANY claim if we are supporting =
identifiers.
>>=20
>> /Dick
>>=20
>>=20
>> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer > wrote:
>>=20
>>=20
>>> On Jul 10, 2020, at 2:15 PM, Dick Hardt > wrote:
>>>=20
>>>=20
>>> inline ...=20
>>>=20
>>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer > wrote:
>>> Yes, the core idea is to not have to parse an assertion to get back =
the core authentication information, which consists of an identifier =
(iss/sub pair in OIDC, but could be a number of things). Sometimes the =
client is going to want the rest of the identity information, but If the =
user=E2=80=99s logged into the client before, the client has likely =
cached that info and probably won=E2=80=99t need it, and sending it =
would be a violation of privacy principles.. The client would want the =
info pretty much just in these cases:
>>>=20
>>>  1. The client has never seen the user before.=20
>>>  2. The user=E2=80=99s information has been updated since the last =
time the client saw it.
>>>=20
>>> Agreed
>>> =20
>>>=20
>>> Now for case (1), how would the client know if it wants to request =
the user=E2=80=99s profile info or not, since it doesn=E2=80=99t know =
who the user is?
>>>=20
>>> But the client could know who the user is. The client may have used =
a different AS to authenticate the user.
>>=20
>> In these cases, the client is not going to be requesting identity =
information from the AS to log the user in, so it=E2=80=99s not relevant =
to the use case. The client will have an opportunity to push that =
information to the AS.
>>=20
>>> The User may have self identified to the client. The client may have =
a cookie saying who the user was and the user said that was them. While =
the latter cases are really a strong hint, they are likely right most of =
the time and can lead to a user experience basde on that hint
>>=20
>> In these cases, the AS might be able to guess if the client has info =
about the user already, but probably not. And the assumptions fall apart =
if it=E2=80=99s in fact a different user that ends up logging in, which =
is of course possible (the hint you gave doesn=E2=80=99t match the =
identity of the current user after the AS validates them). This =
possibility leads to clients always asking for everything every time and =
the server providing everything every time. That=E2=80=99s a pattern I =
think we should avoid in an ultimate solution =E2=80=94 but ultimately, =
I don=E2=80=99t think that this kind of protocol decision is inside of =
GNAP.
>>=20
>>> =20
>>> And the AS won=E2=80=99t know if client is going to want the profile =
info, since the AS won=E2=80=99t know if the client has the user=E2=80=99s=
 info or not. Sure, the AS might have seen that client and that user =
combo previously, but it doesn=E2=80=99t know if the client needs an =
update.
>>>=20
>>> The client can share with the AS the user it knows or thinks it is =
dealing with, which could let the AS respond if the information was new. =
This could be the case for an AS that is providing claims, but not =
authentication, and could happen silently. The user would only interact =
if the user information had changed, and the client wanted the updated =
information.
>>> =20
>>=20
>> See above.
>>=20
>>>=20
>>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s =
info has been updated or not because it doesn=E2=80=99t know who the =
user is yet. If the AS can provide some time of updated stamp to the =
client, the client can pull the new info when it needs it.
>>>=20
>>> See above.
>>=20
>> See above.
>>=20
>>> =20
>>>=20
>>> If you ignore both of these cases and put all the user information =
inline with the main request/response, you end up in a situation where =
the client always requests everything and the server always provides =
everything, since you can=E2=80=99t be sure you=E2=80=99re not in =
situation (1) or (2) ahead of time.
>>>=20
>>> See above. There are a number of other states the client could be =
in.
>>>=20
>>> For example, the client could be stateless about user information, =
so it knows it is ALWAYS in state 1.
>>=20
>> A stateless client would need to fetch appropriate user information =
every time, then. But that=E2=80=99s an optimization for a very specific =
case.
>>=20
>>> =20
>>>=20
>>> This is really what I mean about the two-stage identity protocol.
>>>=20
>>> I know what it is. Per above, GNAP lets us support a wider set of =
use cases. Why limit ourselves to what OIDC supported?
>>=20
>> We aren=E2=80=99t limiting the protocol, but instead limiting the =
scope of what we define internal to the GNAP protocol. There=E2=80=99s a =
lot of room for innovation on top of it.
>>=20
>>> =20
>>> In the first stage, you push the bare minimum of what you need to =
get the user known to the client. In the second stage, the client uses =
its access token to call an API to get whatever else it needs to know =
about the user.
>>>=20
>>> =46rom a privacy perspective in non-enterprise use cases, I think =
the user should give consent to any updated personal information to a =
client. In general, the client should not be able to get the latest =
information about a user whenever it wants.
>>=20
>> This is about the rights associated with the access token, then. And =
an access token doesn=E2=80=99t have to keep working if the AS has a =
policy that says it won=E2=80=99t. The AS/RS could easily decide that a =
particular access token will only return data that hasn=E2=80=99t been =
changed. Maybe it stops working after the data changes, or it just =
returns old data, or any number of things. This is for the AS/RS to =
decide and this is pretty standard interpretation of the token, nothing =
special here because we=E2=80=99re dealing with identity.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> =20
>>> /Dick
>>> =E1=90=A7
>>=20
>=20


--Apple-Mail=_0A159823-E591-453E-A38E-9D0C5B4F34F7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
am saying that GNAP, it its definition within this working group, should =
be limited to identifier claims. Other claims can come from other =
protocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop =
them from being built, but in my opinion we shouldn=E2=80=99t be =
defining those here. See the discussion below on the extensibility =
avenues of this approach.

 =E2=80=94 Justin

On Jul =
13, 2020, at 2:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree that an API to return =
claims is useful. I think we have agreed on that. 
Using the SubjectIdentifiers schema is =
another schema that would be useful for GNAP to support. 

I disagree that =
GNAP should be limited to identifier claims. 

3D""=E1=90=A7

On Mon, Jul =
13, 2020 at 7:16 AM Justin Richer <jricher@mit.edu> wrote:
One thing I think we should learn from OIDC is =
that returning claims from an API, and not just an assertion or direct =
response, is a powerful and useful pattern. We have an opportunity to =
separate these cleanly, where OIDC didn=E2=80=99t have the opportunity =
in defining the =E2=80=9Cclaims=E2=80=9D request parameter.

As an alternative to the =
current XYZ and XAuth syntaxes, over the weekend I=E2=80=99ve been =
playing with something that would look like this strawman in the =
request:


{
   subject: {
    =
  id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
      =
assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =
=E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
   }
}

This request says that =
I=E2=80=99d like some subset of these identifiers (as plain text in the =
response) and some subset of signed assertions in the given formats. =
Each one would have an associated space in the return. I=E2=80=99m not =
picturing that the =E2=80=9Cid=E2=80=9D field values would affect the =
contents of the assertions: so I could ask for an email address =
identifier but get back an ID token that had only the subject =
identifier. Maybe that=E2=80=99s not the right model? But it=E2=80=99s =
at least simple and deterministic this way, and it=E2=80=99s something =
to play with.

Note: The =E2=80=9Cid=E2=80=9D names are taken from https://tools.ietf.org/id/draft-ietf-secevent-subject-identifie=
rs-05.html, the =E2=80=9Cassertion=E2=80=9D names are made up as I =
didn=E2=80=99t see a source that collected them. If you wanted specific =
bundles of claims about the user from a UserInfoEndpoint, for example, =
you=E2=80=99d have something like:

{
  =
 subject: {
  =
    id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
      assertion: [ =E2=80=9Codic_id_token=E2=80=9D=
, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" =
]
  =
 },
  =
 resources: [{
  =
     type: =E2=80=9Cuserinfo=E2=80=9D,
       datatypes: [ =
=E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =E2=80=9Cphone=E2=80=9D=
, =E2=80=9Cemail=E2=80=9D ]
  }]
}

This is an example for a specific kind =
of resource, and I don=E2=80=99t think that GNAP should define the =
=E2=80=9Cuserinfo=E2=80=9D schema here, or the datatype values therein. =
That should be work outside of GNAP, probably for the OIDF.

This approach is =
extensible in several ways, each of them for a specific reason that I =
think is clear:

 - new values in the =E2=80=9Cid=E2=80=9D field to give =
new identifiers
 - new values in the =
=E2=80=9Cassertion=E2=80=9D field to give new assertion =
formats
 - new fields under the =E2=80=9Csubject=
=E2=80=9D heading 
 - new resource types =
besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or =
=E2=80=9Cfacebook-profile=E2=80=9D for instance)
 - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D =
resource type
 - new top-level request =
parameters

As =
per the other thread, if you wanted to use the OIDC query language, =
you=E2=80=99d package it separately as a top-level request parameter =
since it can include both the ID token response and the access token =
response and we shouldn=E2=80=99t be encouraging mixing these things =
together.

 =E2=80=94 Justin

On Jul =
10, 2020, at 5:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It looks to me that our different =
views of what is in scope for GNAP are the differences below.

Per the subject line, =
I'm looking at how the client acquires claims about the user. You don't =
think that is in scope, and that a different layer will solve =
that.

I think =
we should learn from OIDC being on top of OAuth, and GNAP should be able =
return ANY claim, not just identifier claims. There are use cases that =
may be difficult to support if we do not have that functionality in =
scope, such as some of the ones I list below, and it seems pretty =
straightforward to support ANY claim if we are supporting =
identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09 PM Justin Richer =
<jricher@mit.edu> wrote:


On Jul 10, 2020, at 2:15 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:


inline ... 

On Thu, Jul =
9, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea is =
to not have to parse an assertion to get back the core authentication =
information, which consists of an identifier (iss/sub pair in OIDC, but =
could be a number of things). Sometimes the client is going to want the =
rest of the identity information, but If the user=E2=80=99s logged =
into the client before, the client has likely cached that info and =
probably won=E2=80=99t need it, and sending it would be a violation of =
privacy principles.. The client would want the info pretty much just in =
these cases:

 1. =
The client has never seen the user before. 
 2. The user=E2=80=99s information has been updated =
since the last time the client saw it.

Agreed
 

Now for case (1), how would the client =
know if it wants to request the user=E2=80=99s profile info or not, =
since it doesn=E2=80=99t know who the user is? =


But the client could know who the user is. The client may =
have used a different AS to authenticate the user. =


In these cases, the client is not going =
to be requesting identity information from the AS to log the user in, so =
it=E2=80=99s not relevant to the use case. The client will have an =
opportunity to push that information to the AS.

The User may have self identified to the client. The client =
may have a cookie saying who the user was and the user said that was =
them. While the latter cases are really a strong hint, they are likely =
right most of the time and can lead to a user experience basde on that =
hint

In these cases, the AS might be able to =
guess if the client has info about the user already, but probably not. =
And the assumptions fall apart if it=E2=80=99s in fact a different user =
that ends up logging in, which is of course possible (the hint you gave =
doesn=E2=80=99t match the identity of the current user after the AS =
validates them). This possibility leads to clients always asking for =
everything every time and the server providing everything every time. =
That=E2=80=99s a pattern I think we should avoid in an ultimate solution =
=E2=80=94 but ultimately, I don=E2=80=99t think that this kind of =
protocol decision is inside of GNAP.

 
And =
the AS won=E2=80=99t know if client is going to want the profile info, =
since the AS won=E2=80=99t know if the client has the user=E2=80=99s =
info or not. Sure, the AS might have seen that client and that user =
combo previously, but it doesn=E2=80=99t know if the client needs an =
update.

The client can share with the AS the user it knows or thinks =
it is dealing with, which could let the AS respond if the information =
was new. This could be the case for an AS that is providing claims, but =
not authentication, and could happen silently. The user would only =
interact if the user information had changed, and the client wanted the =
updated information.
 

See above.


And for (2), the client won=E2=80=99t =
know if the user=E2=80=99s info has been updated or not because it =
doesn=E2=80=99t know who the user is yet. If the AS can provide some =
time of updated stamp to the client, the client can pull the new info =
when it needs it.

See =
above.

See above.

 

If you ignore both of these cases and =
put all the user information inline with the main request/response, you =
end up in a situation where the client always requests everything and =
the server always provides everything, since you can=E2=80=99t be sure =
you=E2=80=99re not in situation (1) or (2) ahead of =
time.

See above. There are a number of other states the client =
could be in.

For=
 example, the client could be stateless about user information, so it =
knows it is ALWAYS in state =
1.

A stateless client would need to fetch =
appropriate user information every time, then. But that=E2=80=99s an =
optimization for a very specific case.

 

This is really what I mean about the =
two-stage identity protocol. 

I know what it is. Per above, GNAP lets =
us support a wider set of use cases. Why limit ourselves to what OIDC =
supported?

We aren=E2=80=99t limiting the =
protocol, but instead limiting the scope of what we define internal to =
the GNAP protocol. There=E2=80=99s a lot of room for innovation on top =
of it.

 
In the first stage, you push the bare minimum of what you =
need to get the user known to the client. In the second stage, the =
client uses its access token to call an API to get whatever else it =
needs to know about the user. 
=46rom a privacy perspective in =
non-enterprise use cases, I think the user should give consent to any =
updated personal information to a client. In general, the client =
should not be able to get the latest information about a user whenever =
it wants.

This is about the rights associated =
with the access token, then. And an access token doesn=E2=80=99t have to =
keep working if the AS has a policy that says it won=E2=80=99t. The =
AS/RS could easily decide that a particular access token will only =
return data that hasn=E2=80=99t been changed. Maybe it stops working =
after the data changes, or it just returns old data, or any number of =
things. This is for the AS/RS to decide and this is pretty standard =
interpretation of the token, nothing special here because we=E2=80=99re =
dealing with identity.

 =E2=80=94 Justin

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









=

--Apple-Mail=_0A159823-E591-453E-A38E-9D0C5B4F34F7--


From nobody Mon Jul 13 11:57: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 4E72C3A1745 for ; Mon, 13 Jul 2020 11:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 XjfZUAotvpPP for ; Mon, 13 Jul 2020 11:57:50 -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 7CB5C3A1882 for ; Mon, 13 Jul 2020 11:57:38 -0700 (PDT)
Received: from [192.168.1.7] (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 06DIvWTR003641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jul 2020 14:57:33 -0400
From: Justin Richer 
Message-Id: <83DB69E6-F0ED-41A0-A4DA-B7AE4AB89579@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_656925EB-5343-4206-B93A-691E8320D368"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 13 Jul 2020 14:57:32 -0400
In-Reply-To: 
Cc: Denis , "txauth@ietf.org" 
To: Dick Hardt 
References:    <325bc015-1547-c56c-c1fe-67a97165785d@free.fr>  <83480ab0-03bc-7cc9-d166-ece4c6b63861@free.fr> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 13 Jul 2020 18:57:54 -0000

--Apple-Mail=_656925EB-5343-4206-B93A-691E8320D368
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

If I=E2=80=99m understanding Denis=E2=80=99s proposal, he=E2=80=99s =
saying that that =E2=80=9Cprior step=E2=80=9D is the lynchpin of the =
whole model, since interaction between the client and the RS (and the =
user and the RS) is key to Denis=E2=80=99s privacy model. Additionally, =
what happens *at* each step is different. Consent is gathered at the =
client, not the GS in this diagram, for example. The GS simply mints a =
token as specified by the client and the RS.

It=E2=80=99s for these reasons that, as long as I=E2=80=99ve been =
understanding correctly, I=E2=80=99ve been saying that Denis=E2=80=99s =
model as proposed is pretty different. But what I think isn=E2=80=99t =
that different is the different steps if you=E2=80=99re willing to look =
at the boundaries around the boxes differently. For example, what OAuth =
would call =E2=80=9Cthe AS=E2=80=9D might end up being a few different =
boxes in GNAP that do different things. I had started down that route =
with XYZ=E2=80=99s design allowing the interaction to be managed =
separately.=20

I think that the disconnect we=E2=80=99re seeing here might be caused by =
vocabulary mismatches. If we aren=E2=80=99t meaning the same thing when =
we say the same terms, it=E2=80=99s easy to get things mixed up with =
each other. Since GNAP is just barely forming its vocabulary out of the =
legacy of OAuth and kin, we have a chance to maybe draw the lines better =
and see if that=E2=80=99s how we can get things to fit.

 =E2=80=94 Justin

> On Jul 13, 2020, at 2:02 PM, Dick Hardt  wrote:
>=20
>=20
> I'm going to just address the first part of your response so that we =
can get clarity on that before diving into your later comments.
>=20
> The calls between your proposal and XAuth are not inverted, your =
proposal has a prior step. Step 1 in XAuth maps to Step 2 in your =
proposal, and Step 2 in XAuth is Step 3 in your proposal..
>=20
> Below are 2 diagrams showing the same steps, the first keeping the =
existing step labels for XAuth, the latter renaming the steps to =
correspond to your proposal. This looks pretty similar to your diagram. =
What am I missing?
>=20
> /Dick
>=20
> DIAGRAM 1 (steps start at 0)
>        +--------+                           +------------+
>        |  User  |                           |  Resource  |
>        |        |                           | Owner (RO) |
>        +--------+                           +------------+
>            |      \                       /      |
>            |       \                     /       |
>            |        \                   /        |
>            |         \                 /         |
>        +--------+     +---------------+     +------------+
>        | Client |---->|     Grant     |     |  Resource  |
>        |        | (1) |  Server (GS)  | _ _ |   Server   |
>        |        |<----|               |     |    (RS)    |
>        |        |     +---------------+     |            |
>        |        |-------------------------->|            |
>        |        |           (2)             |            |
>        |        |<--------------------------|            |
>        |        |-------------------------->|            |
>        |        |           (0)             |            |
>        |        |<--------------------------|            |
>        +--------+                           +------------+
>=20
>=20
> DIAGRAM 2 (steps start at 1)
>        +--------+                           +------------+
>        |  User  |                           |  Resource  |
>        |        |                           | Owner (RO) |
>        +--------+                           +------------+
>            |      \                       /      |
>            |       \                     /       |
>            |        \                   /        |
>            |         \                 /         |
>        +--------+     +---------------+     +------------+
>        | Client |---->|     Grant     |     |  Resource  |
>        |        | (2) |  Server (GS)  | _ _ |   Server   |
>        |        |<----|               |     |    (RS)    |
>        |        |     +---------------+     |            |
>        |        |-------------------------->|            |
>        |        |           (3)             |            |
>        |        |<--------------------------|            |
>        |        |-------------------------->|            |
>        |        |           (1)             |            |
>        |        |<--------------------------|            |
>        +--------+                           +------------+
> =E1=90=A7
>=20
> On Mon, Jul 13, 2020 at 7:08 AM Denis > wrote:
> Hello Dick,
>=20
> You wrote: "This looks pretty similar to your protocol drawing".
>=20
> No. There is a fundamental difference with the sequencing of the flow =
of the exchanges where the (1) and (2) flows are inverted.=20
>=20
> In your figure:
> The Client makes calls to the GS (1)
> The Client makes calls to the RS (2)
> while in my figure:
> The Client makes calls to the RS (1)
> The Client makes calls to the AS (2)
> In your figure, the first flow is with the GS, whereas in my figure =
the first flow is with the RS and there is a good reason for that:=20
> the client first contacts the RS to know what the RS expects. The =
client indicates in its first exchange to the RS whether it wants to =
authenticate=20
> or to perform another operation.  In the case of an authentication =
operation, the RS may respond to the client that is supports FIDO U2F=20
> or that it is willing the client to present some attribute(s) from one =
or more AS.
>=20
> Then after the client has to figure out whether the user is using FIDO =
and if not whether the user has an account with one of the AS.
> In the later case, if there is a match then the client, *after having =
received the user consent*, may contact the appropriate AS to ask=20
> for some attribute(s).=20
>=20
> The same fundamental difference applies with =
draft-richer-transactional-authz-06 (XYZ) where the first exchange is =
done with the AS:
> "The RC creates a transaction request and sends it to the AS".
>=20
> This answers also in details to one of your comments:
> What looks to be missing from your proposal is:
> A) The Client making a call to the RS to discover what it needs from a =
GS, and which GS to ask, prior to (1).
> This is not missing since this is the foundation of the architecture. =
The discovery mechanism at the RS has been described=20
> in details in an earlier email with the following title: "Support of =
FIDO and data minimization by RSs".
>=20
> The main figures are copied below (using ASCII):
>   =
+-----------------------------------+---------------------------------+
>   +           Operation               +      Mathematical expression   =
 +
>   =
+-----------------------------------+---------------------------------+
>   + Authentication                    + Condition 1 OR Condition 2     =
 +
>   =
+-----------------------------------+---------------------------------+
>   + Operation A OR Operation Z        + Condition 3 AND Condition 4    =
 +
>   =
+-----------------------------------+---------------------------------+
>=20
> Conditions table:=20
>=20
>   =
+-------------+--------------+-----------------------------+----------+
>   + Condition 1 + FIDO U2F 1.2 +                             +         =
 +
>   =
+-------------+--------------+-----------------------------+----------+
>   + Condition 2 + AS 1         + set 1 of a attributes types +         =
 +
>   =
+-------------+--------------+-----------------------------+----------+
>   + Condition 3 + AS 2         + set 2 of a attributes types + Scope =
21 +
>   =
+-------------+--------------+-----------------------------+----------+
>   + Condition 4 + AS 9         + set 3 of a attributes types-+         =
 +
>   =
+-------------+--------------+-----------------------------+----------+
>=20
> According to the operation announced by the Client, the RS returns to =
the Client both the mathematical expression=20
> associated with that operation and the conditions included in that =
mathematical expression. The Client may then=20
> present that information to the user in order to obtain the user =
consent in a standardized manner.
>=20
> Another comment you made is:
> What looks to be missing from your proposal is:
> B) A mechanism for the Client to prove to the GS that it has gathered =
consent from the User.
> The user consent should not be captured *by the GS*, since the GS =
would be in a position to apply a different consent decision=20
> without letting it know to the user (or to the client).
>=20
> The user consent must be captured *by the Client* and the Client must =
be able to verify that this consent has indeed been followed by the AS.=20=

>=20
> The authorization data managed at the RS by the RO is used by the =
Client to query the consent of the user in a standardized manner.
> When, later on, the access token is returned to the Client by the AS, =
the Client (not the user) using that authorization data as well as=20
> the decision of the user is able to verify that the requested =
attributes (and no more) are indeed present into the access token.=20
>=20
> This is why access tokens may *not* be considered to be opaque to the =
Clients.
>=20
> In my earlier email copied below, six major differences with XAuth =
from 1) to 6) are listed.
>=20
> Denis
>=20
>> =46rom =
https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1 =

>>=20
>> 1.1 =
. =
 Parties
>>=20
>>    The parties and their relationships to each other:
>>        +--------+                           +------------+
>>        |  User  |                           |  Resource  |
>>        |        |                           | Owner (RO) |
>>        +--------+                           +------------+
>>            |      \                       /      |
>>            |       \                     /       |
>>            |        \                   /        |
>>            |         \                 /         |
>>        +--------+     +---------------+     +------------+
>>        | Client |---->|     Grant     |     |  Resource  |
>>        |        | (1) |  Server (GS)  | _ _ |   Server   |
>>        |        |<----|               |     |    (RS)    |
>>        |        |     +---------------+     |            |
>>        |        |-------------------------->|            |
>>        |        |           (2)             |            |
>>        |        |<--------------------------|            |
>>        +--------+                           +------------+
>>=20
>>=20
>> The lines without arrows represent relationships.=20
>> The User trusts the Client
>> The User trusts the GS
>> The RO trusts the GS to issue access tokens for the RS
>> The RS trusts the tokens issued by the RS
>> The RO controls the RS
>>=20
>> The Client makes calls to the GS (1)
>> The Client makes calls to the RS (2)
>>=20
>> This looks pretty similar to your protocol drawing.
>>=20
>> What looks to be missing from your proposal is:
>>=20
>> A) The Client making a call to the RS to discover what it needs from =
a GS, and which GS to ask, prior to (1).
>> B) A mechanism for the Client to prove to the GS that it has gathered =
consent from the User.
>>=20
>> The current protocol does not require the GS to interact with either =
the User, the RO, or the RS -- which looks to me to meet your privacy =
goals.
>>=20
>> =E1=90=A7
>>=20
>> On Fri, Jul 10, 2020 at 6:06 AM Denis > wrote:
>> Hi Dick,
>>=20
>>> Hi Denis, thanks for sharing the model. I don't fully understand =
what is going on, questions inserted:
>> Responses are inserted.
>>>=20
>>> FWIW: having paragraphs start with the step number (1), (2) etc. =
would make it easier to map between the description and the diagram.
>>>=20
>>> On Thu, Jul 9, 2020 at 3:26 AM Denis > wrote:
>>> This is a new thread.
>>>=20
>>> Preamble: This model is quite different from the XAuth model.=20
>>> In particular, a RO has no relationship with any AS and a Client =
does not need to be associated with any AS prior to any access to a RS.
>>>=20
>>> A key point of this model is that the user's consent is handled =
locally by the Client and hence no AS nor RS is handling a man machine =
interface=20
>>> for the user consent. This allows to support locally the user =
consent for multiple ASs while keeping all ASs ignorant about the =
choices of the user=20
>>> made for accessing a particular RS.
>>>=20
>>>=20
>>>        +--------+                           +------------+
>>>        |  User  |                           |  Resource  |
>>>        |        |                           | Owner (RO) |
>>>        +--------+                           +------------+
>>>            |      \                              |
>>>            |       \                             |
>>>            |        \                            |
>>>            |         \                           |
>>>     +-----------+     +---------------+     +------------+
>>>     |           |---->| Authorization |     |            |
>>>     |           | (2) |  Server (AS)  |     |            |
>>>     |           |<----|               |     |            |
>>>     |  Client   |     +---------------+     |            |
>>>     |           |-------------------------->|  Resource  |
>>>     |   User    |           (1)             |   Server   |
>>>     |  Consent  |<--------------------------|    (RS)    |
>>>     |  element  |                           |            |
>>>     |           |-------------------------->|            |------>
>>>     |           |           (3)             |            |  (4)
>>>     |           |<--------------------------|            |<------
>>>     +-----------+                           +------------+
>>>=20
>>> The flow of operations is as follows:
>>>=20
>>> The Client (which may have been previously authenticated using FIDO)
>>>=20
>>> Which party has the client authenticated to? The client =
authenticating with FIDO is confusing to me. FIDO is usually how a user =
authenticates.
>> If the user has previously opened a user account with the RS using =
FIDO, then the client may be authenticated by the RS using FIDO.
>> In such a case, the user is already known to the RS under a pseudonym =
specific to the RS. It may (or may not) have previously presented access =
tokens=20
>> to that RS.
>>=20
>>>  contacts the RS and after some dialogue with the RS selects an =
operation=20
>>> How does the client know which RS to contact?
>> For a private usage, the user may use DuckDuckGo, while for business =
he may use an application from his company which lists various services=20=

>> available in the context of his job or his position. Some services =
may be freely available to all the employees of the company with any =
authentication,
>> e.g. the phone book of the employees may be freely available on the =
intranet of the company, while some other services may require the user=20=

>> to authenticate to the AS from the company.
>>=20
>>>  that it wants to perform on the RS (1a). Note that it may also =
indicate directly the operation that it wants to perform on the RS =
without any prior dialogue.=20
>>> In return (1b), the RS informs the Client about which attributes are =
needed by the RS for performing the requested operation and from which =
Attributes Servers=20
>>> they may be obtained.=20
>>>=20
>>> (1a) and (1b) are not labeled. There is only (1)=20
>> (1a) is the first exchange for (1) with the arrow from left to right, =
while (1b) is the response with the arrow from right to left.=20
>> The same applies to the other exchanges i.e. (2) , (3) and (4).
>>=20
>>>=20
>>> This information is specifically marked to indicate that it shall be =
handled by the "User Consent element" from the Client.=20
>>>=20
>>> Why? What is the significance of this? Which information is marked?
>> In the response, a specific identifier or a magic number is used to =
indicate the start and the length of the information block =20
>> to be sent to the "User Consent element" supported by the Client.
>>=20
>>> The presentation of that information is up to the man machine =
interface supported by the "User Consent element" from the Client.=20
>>>=20
>>>=20
>>> Which information?=20
>> The attributes that are needed by the RS for performing a requested =
operation and from which Attributes Servers they may be obtained.
>>=20
>>>=20
>>> The user can see which attributes are requested by the RS for =
performing the requested operation and, if it consents, the Client =
contacts one or more=20
>>> appropriate Authorization Servers (2a).
>>>=20
>>> How does the client know which AS(s) to contact?
>> For each AS trusted by the RS to perfom a given operation, the RS =
should indicate a user-friendly name and a URL of the AS.=20
>>=20
>>> The user consent is hence captured locally by the Client (i.e. there =
is no dialogue with any AS nor any RS).
>>>=20
>>>=20
>>> No dialogue with who? The client is calling the AS is it not?=20
>> For the user consent, there is no external call since it is handled =
locally. Afterwards, there is a call to the AS(s) selected by the user.
>>=20
>>>=20
>>> When the Client got the access tokens from these authorization =
servers (2b), it sends all of them in a single request to the RS (3a).
>>>=20
>>>=20
>>> So the RS must trust the AS that issued the tokens. And the AS must =
trust the Client to have gathered consent.
>> Theses two assertions are correct.
>>> And the AS must have a relationship with the user.
>> Only when the user chooses one AS while giving its consent, then the =
user must have a relationship with the selected AS.
>>=20
>>> It is unclear what role the RO is playing in this though. The RO and =
RS look to be the same entity from all the other parties.
>> A RO, as indicated on the figure, has only a relationship with one =
RS: it has no relationship with any AS.=20
>> The RS trusts the AS but the AS does not know which RSs are trusting =
it.
>>=20
>>>=20
>>> =46rom my current understanding, at a high level, this looks like it =
is supported by GNAP with the addition of the discovery step (1).
>> Well, it is fairly different :=20
>>=20
>> 1) The first major difference is that there is no arrow between the =
RO and the AS. No protocol or "out-of-bands" means are necessary.=20
>>=20
>> 2) The second major difference is that there is no arrow between the =
AS and the RS. No protocol is necessary.
>>=20
>> 3) The third major difference is that the AS does not know any RS. =
Note: for backward compatibility reasons, an exception might exist for =
"old" Auth 2.0 ASs.
>>=20
>> 4) The fourth major difference is that the XAuth spec. is rather =
vague to describe when and by who the user consent is captured:=20
>>     XAuth states on page 4: "User consent is often required at the =
GS". In that case, the GS is able to act as Big Brother. No other case =
is described.
>>=20
>> 5) The fifth major difference is that the data that is transferred to =
a "User Consent Element" to capture the user consent. That data can be =
standardized.=20
>>     Moreover, it will also be possible to standardize the dialogue =
between the RO and the RS. The RO will then be able to manage remotely =
the authorization tables.
>>     See my email sent on June 6, with the following subject: "Support =
of FIDO and data minimization by RSs".
>>=20
>> 6) Another difference is the following: since there is no interaction =
between the RO and the AS, "authorizations from the RO" as described in =
XAuth do not exist. =20
>>> There have been a number of proposals for doing this discovery, and =
perhaps now there are enough use cases to look at standardizing =
something. =20
>>> No interaction is needed between the AS and the User as the Client =
is providing enough "information" in the user object of the Grant =
Request=20
>>> to satisfy the AS releasing the access tokens.=20
>> Not sure I understand correctly this last sentence.
>>>=20
>>> Perhaps as I understand the model in more detail I will understand =
what is missing from GNAP (besides the discovery step).
>> It would be hard to say "what is missing" from XAuth since the =
foundations are not the same.
>>=20
>> In order to compare different architectures, there is the need to =
start with the trust relationships.=20
>> Unfortunately, the word "trust" is absent in the main body of =
draft-hardt-xauth-protocol-12. Hence,=20
>> the description of the trust relationships is missing.
>>=20
>> Denis
>>=20
>>>=20
>>> /Dick
>>>=20
>>> (I've skipped reviewing the delegation use case below until I =
understand the simple use case)
>>>=20
>>>=20
>>> End of the story for a simple access
>>>=20
>>>=20
>>> Start of a subsequent story for a delegation case
>>>=20
>>> Let us now suppose that the RS is unable to fulfil the request by =
its own and that it needs to contact another RS. RS1 contacts RS2 (4a) =
and indicates the operation=20
>>> that it wants to perform on RS2 (that operation may not be the same =
as the original operation). In return (4b), RS2 informs RS1 about which =
attributes are needed=20
>>> by RS2 for performing the requested operation and from which =
Attributes Servers they may be obtained. RS1 forwards that information =
to the Client.=20
>>>=20
>>> This information is marked to indicate that it shall be handled by =
the "User Consent element" from the Client. The presentation of that =
information is up to the man machine                            =20
>>> interface from the Client. The user can see which attributes are =
requested by RS2 for performing the new requested operation and, if it =
consents, the Client contacts one or more=20
>>> appropriate Authorization Servers. The user consent is hence =
captured locally by the "User Consent element" from the Client. (i.e. =
there is no dialogue with any AS, nor RS1, nor RS2).=20
>>>=20
>>> When the Client got the access token(s) from the authorization =
server(s), it sends all of them in a single request to RS1. RS1 then =
forwards the additional access token(s) to RS2.
>>>=20
>>>=20
>>> Some observations:=20
>>>=20
>>> The user nor the Client are linked with any particular AS. A user =
may use today an AS of the Bank of America and may change tomorrow to =
the Bank of Missouri.=20
>>> As soon as he will be registered with the Bank of Missouri, he will =
be able to get access tokens from the AS of the Bank of Missouri. The AS =
of Bank of America=20
>>> has not been able to know where its access tokens have been used. =
This will be the same for AS of the Bank of Missouri. There is no need =
for any direct dialogue=20
>>> between any AS and any RS at the time a client is making an access. =
There is no need                             for any RO to contact any =
AS.
>>>=20
>>> This model has been constructed following a "Privacy by Design" =
approach.
>>>=20
>>> Denis
>>>=20
>>> --=20
>>> Txauth mailing list
>>> Txauth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/txauth =

>>> =E1=90=A7
>>=20
>=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=_656925EB-5343-4206-B93A-691E8320D368
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

If =
I=E2=80=99m understanding Denis=E2=80=99s proposal, he=E2=80=99s saying =
that that =E2=80=9Cprior step=E2=80=9D is the lynchpin of the whole =
model, since interaction between the client and the RS (and the user and =
the RS) is key to Denis=E2=80=99s privacy model. Additionally, what =
happens *at* each step is different. Consent is gathered at the client, =
not the GS in this diagram, for example. The GS simply mints a token as =
specified by the client and the RS.

It=E2=80=99s for these reasons that, as =
long as I=E2=80=99ve been understanding correctly, I=E2=80=99ve been =
saying that Denis=E2=80=99s model as proposed is pretty different. But =
what I think isn=E2=80=99t that different is the different steps if =
you=E2=80=99re willing to look at the boundaries around the boxes =
differently. For example, what OAuth would call =E2=80=9Cthe AS=E2=80=9D =
might end up being a few different boxes in GNAP that do different =
things. I had started down that route with XYZ=E2=80=99s design allowing =
the interaction to be managed separately. 

I think that the disconnect we=E2=80=99re=
 seeing here might be caused by vocabulary mismatches. If we aren=E2=80=99=
t meaning the same thing when we say the same terms, it=E2=80=99s easy =
to get things mixed up with each other. Since GNAP is just barely =
forming its vocabulary out of the legacy of OAuth and kin, we have a =
chance to maybe draw the lines better and see if that=E2=80=99s how we =
can get things to fit.

 =E2=80=94 Justin

On Jul 13, 2020, at 2:02 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


I'm =
going to just address the first part of your response so that we can get =
clarity on that before diving into your later comments.

The calls between your =
proposal and XAuth are not inverted, your proposal has a prior step. =
Step 1 in XAuth maps to Step 2 in your proposal, and Step 2 in XAuth is =
Step 3 in your proposal..

Below are 2 diagrams showing the same steps, the first =
keeping the existing step labels for XAuth, the latter renaming the =
steps to correspond to your proposal. This looks pretty similar to your =
diagram. What am I missing?

/Dick

DIAGRAM 1 (steps start at 0)
       +--------+                        =
   +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (0)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+


DIAGRAM 2 (steps start at 1)
       +--------+                 =
          +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (2) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (3)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (1)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+
3D""=E1=90=A7

On Mon, Jul =
13, 2020 at 7:08 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hello Dick,

    


    

    
You wrote: "This looks pretty similar
      to your protocol drawing".

      

    

    
No. There is a fundamental difference
      with the sequencing of the flow of the exchanges where the (1) and
      (2) flows are inverted. 

    

    


    

    
In your figure:

    

    

      

        
The Client makes calls to the GS (1)

        
The Client makes calls to the RS (2)

      

      
while in my figure:

      

        

          
The Client makes calls to the RS (1)

          
The Client makes calls to the AS (2)

        

      

    

    
In your figure, the first flow is with
      the GS, whereas in my figure the first flow is with the RS and
      there is a good reason for that: 

      the client first contacts the RS to know what the RS expects. The
      client indicates in its first exchange to the RS whether it wants
      to authenticate 

      or to perform another operation.  In the case of an =
authentication
      operation, the RS may respond to the client that is supports FIDO
      U2F 

      or that it is willing the client to present some attribute(s) from
      one or more AS.

    


    

    
Then after the client has to figure out
      whether the user is using FIDO and if not whether the user has an
      account with one of the AS.

    
In the later case, if there is a match
      then the client, *after having received the user =
consent*,
      may contact the appropriate AS to ask 

      for some attribute(s). 

    

    


    

    
The same fundamental difference applies
      with draft-richer-transactional-authz-06 (XYZ) where the first
      exchange is done with the AS:

    
"The RC creates a transaction request
      and sends it to the AS".

    


    

    
This answers also in details to one of
      your comments:

    

      

        
What looks to be missing from your proposal =
is:

        
A) The Client making a call to the RS to =
discover what it
          needs from a GS, and which GS to ask, prior to (1).

      

    

    
This is not missing since this is the
      foundation of the architecture. The discovery mechanism at the RS
      has been described 

      in details in an earlier email with the following title: "Support
      of FIDO and data minimization by RSs".

    


    

    

    
The main figures are copied below
      (using ASCII):
 
              =
+-----------------------------------+------------------------------=
---+

                +           =
Operation          &nb=
sp;    +      Mathematical
              expression    +

                =
+-----------------------------------+------------------------------=
---+

                + Authentication          &nb=
sp;         +
              Condition 1 OR Condition 2     
              +

                =
+-----------------------------------+------------------------------=
---+

                + Operation A OR
              Operation Z        +
              Condition 3 AND Condition 4    
              +

                =
+-----------------------------------+------------------------------=
---+

              

            Conditions
              table: 

              

                =
+-------------+--------------+-----------------------------+-------=
---+

                + Condition 1 +
              FIDO U2F 1.2 +          &nb=
sp;            =
;     
              +          =
+

                =
+-------------+--------------+-----------------------------+-------=
---+

                + Condition 2 +
              AS 1         + set
              1 of a attributes types +          +

                =
+-------------+--------------+-----------------------------+-------=
---+

                + Condition 3 +
              AS 2         + set
              2 of a attributes types + Scope 21 +

                =
+-------------+--------------+-----------------------------+-------=
---+

                + Condition 4 +
              AS 9         + set
              3 of a attributes types-+          +

                =
+-------------+--------------+-----------------------------+-------=
---+

          

        According to the operation announced by the Client, the RS
        returns to the Client both the mathematical expression 

        associated with that operation and the conditions included in
        that mathematical expression. The Client may then 

        present that information to the user in order to obtain the user
        consent in a standardized manner.

      

    

    
Another comment you made is:

    

      
What looks to be missing from your proposal =
is:

      
B) A mechanism for the Client to prove to the GS =
that it has
        gathered consent from the User.

    

    
The user consent should not be captured *by the GS*, =
since the
      GS would be in a position to apply a different consent decision =


      without letting it know to the user (or to the client).

    


      The user consent must be captured *by the Client* and the Client
      must be able to verify that this consent has indeed been followed
      by the AS. 

    

    


    

    
The authorization data managed at the RS by the RO =
is used by
      the Client to query the consent of the user in a standardized
      manner.

    
When, later on, the access token is returned to the =
Client by
      the AS, the Client (not the user) using that authorization data as
      well as 

      the decision of the user is able to verify that the requested
      attributes (and no more) are indeed present into the access token.
      

      

      This is why access tokens may *not* be considered to be opaque to
      the Clients.

    


    

    
In my earlier email copied below, six major =
differences with
      XAuth from 1) to 6) are listed.

    


    

    
Denis

      

    

    

     =20
      
From https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti=
on-1.1
        


          

            
1.1.  Parties


   The parties and their relationships to each other:


            
       +--------+                           =
+------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+



          

          

            


            

            
The lines without arrows represent =
relationships. 

          

        

        
The User trusts the Client

        
The User trusts the GS

        
The RO trusts the GS to issue access tokens for =
the RS

        
The RS trusts the tokens issued by the RS

        
The RO controls the RS

        


        

        
The Client makes calls to the GS (1)

        
The Client makes calls to the RS (2)

        


        

        
This looks pretty similar to your protocol =
drawing.

        


        

        
What looks to be missing from your proposal =
is:

        


        

        
A) The Client making a call to the RS to =
discover what it
          needs from a GS, and which GS to ask, prior to (1).

        
B) A mechanism for the Client to prove to the GS =
that it
          has gathered consent from the User.

        


        

        
The current protocol does not require the GS to =
interact
          with either the User, the RO, or the RS -- which looks to me
          to meet your privacy goals.

        


        

      

      
3D""=E1=90=A7

      

      

        
On Fri, Jul 10, 2020 at =
6:06
          AM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hi Dick,

            


            

            

              

                
Hi Denis, thanks for sharing =
the model. I
                  don't fully understand what is going on, questions
                  inserted:

              

            

            Responses are inserted.

            

              

                

                  


                  

                  
FWIW: having paragraphs start with the =
step
                    number (1), (2) etc. would make it easier to map
                    between the description and the diagram.

                

                

                

                  
On Thu, Jul 9, =
2020
                    at 3:26 AM Denis <denis.ietf@free.fr>
                    wrote:

                  

                  

                    

                      
This is a new thread.

                            

                            Preamble: This model is quite different from
                            the XAuth model. 

                            In particular, a RO has no relationship with
                            any AS and a Client does not need to be
                            associated with any AS prior to any access
                            to a RS.

                            

                            A key point of this model is that the user's
                            consent is handled locally by the Client and
                            hence no AS nor RS is handling a man machine
                            interface 

                            for the user consent. This allows to support
                            locally the user consent for multiple ASs
                            while keeping all ASs ignorant about the
                            choices of the user 

                            made for accessing a particular RS.

                            

                              

                                    
                                +--------+          &nb=
sp;            =
;   
                                +------------+

                                       |  User 
                                |          &nb=
sp;            =
;   
                                |  =
Resource 
                                |

                                       |        |          &nb=
sp;            =
;   
                                | Owner (RO) |

                                       +--------+        
                                          &nb=
sp;       +------------+

                                           =
|      \          &nb=
sp;            =
;      
                                |

                                           =
|       =
\          &nb=
sp;            =
;     
                                |

                                           =
|       
                                \          &nb=
sp;            =
;    
                                |

                                           =
|        
                                \          &nb=
sp;            =
;   
                                |

                                    =
+-----------+     +---------------+    
                                +------------+

                                    =
|           =
|---->|
                                Authorization |     |          &nb=
sp;
                                |

                                    =
|           =
|
                                (2) |  =
Server (AS) 
                                |     |          &nb=
sp;
                                |

                                    =
|           =
|<----|          &nb=
sp;   
                                |     |          &nb=
sp;
                                |

                                    =
|  Client  =

                                |     +---------------+    
                                |          &nb=
sp; |

                                    =
|           =
|-------------------------->| 
                                Resource  =
|

                                    =
|   User   
                                |           =
(1)          &nb=
sp; 
                                |   =
Server  
                                |

                                    =
|  Consent 
                                =
|<--------------------------|   =

                                (RS)    |

                                    =
|  element 
                                |          &nb=
sp;            =
;   
                                |          &nb=
sp; |

                                    =
|           =
|-------------------------->|          &nb=
sp;
                                |------>

                                    =
|           =
|          
                                (3)          &nb=
sp;  |          &nb=
sp;
                                |  =
(4)

                                    =
|           =
|<--------------------------|          &nb=
sp;
                                |<------

                                    =
+-----------+          &nb=
sp;            =
;   
                                +------------+

                            
                            The flow of operations is as follows:

                            

                            The Client (which may have been previously
                            authenticated using FIDO) 

                      

                    

                  

                  
Which party has the client =
authenticated to? The
                    client authenticating with FIDO is confusing to me.
                    FIDO is usually how a user authenticates.

                

              

            
If the user has previously opened =
a user account with the
              RS using FIDO, then the client may be authenticated by the
              RS using FIDO.

              In such a case, the user is already known to the RS under
              a pseudonym specific to the RS. It may (or may not) have
              previously presented access tokens 

              to that RS.

            

            

              

                

                  
 contacts the RS and after
                      some dialogue with the RS selects an operation 

                    

                  
How does the client know which RS to =
contact?

                

              

            
For a private usage, the user may =
use DuckDuckGo, while
              for business he may use an application from his company
              which lists various services 

              available in the context of his job or his position. Some
              services may be freely available to all the employees of
              the company with any authentication,

              e.g. the phone book of the employees may be freely
              available on the intranet of the company, while some other
              services may require the user 

              to authenticate to the AS from the company.

            

              

                

                  
 that it wants to perform on
                      the RS (1a). Note that it may also indicate
                      directly the operation that it wants to perform on
                      the RS without any prior dialogue. 

                    

                  

                    

                      
 In return (1b), the RS
                            informs the Client about which attributes
                            are needed by the RS for performing the
                            requested operation and from which
                            Attributes Servers 

                            they may be obtained. 

                          

                      

                    

                  

                  
(1a) and (1b) are not labeled. There =
is only (1)
                    

                  

                

              

            
(1a) is the first exchange for =
(1) with the arrow from
              left to right, while (1b) is the response with the arrow
              from right to left. 

              The same applies to the other exchanges i.e. (2) , (3) and
              (4).

            

            

              

                

                  

                    

                      
 

                            This information is specifically marked to
                            indicate that it shall be handled by the
                            "User Consent element" from the Client. 

                          

                      

                    

                  

                  
Why? What is the significance of this? =
Which
                    information is marked?

                

              

            
In the response, a specific =
identifier or a magic number
              is used to indicate the start and the length of the
              information block  

              to be sent to the "User =
Consent
                element" supported by the Client.

            

            

              

                

                  
The presentation of that
                        information is up to the man machine interface
                        supported by the "User Consent element" from the
                        Client. 

                      

                  

                  


                  

                  
Which information? 

                  

                

              

            
The=
 attributes that are needed by the
                RS for performing a requested operation and from which
                Attributes Servers they may be obtained.

            

              

                

                  

                    

                      
 

                            The user can see which attributes are
                            requested by the RS for performing the
                            requested operation and, if it consents, the
                            Client contacts one or more 

                            appropriate Authorization Servers (2a). =


                      

                    

                  

                  
How does the client know which AS(s) =
to contact?

                

              

            
For each AS trusted by the RS to =
perfom a given
              operation, the RS should indicate a user-friendly name and
              a URL of the AS. 

            

            

              

                

                  

                    

                      
The user consent is hence
                            captured locally by the Client (i.e. there
                            is no dialogue with any AS nor any RS).

                          

                      

                    

                  

                  


                  

                  
No dialogue with who? The client is =
calling the
                    AS is it not? 

                  

                

              

            
For the user consent, there is no =
external call since it
              is handled locally. Afterwards, there is a call to the
              AS(s) selected by the user.

            

              

                

                  

                    

                      
 

                            When the Client got the access tokens from
                            these authorization servers (2b), it sends
                            all of them in a single request to the RS
                            (3a).

                          

                      

                    

                  

                  


                  

                  
So the RS must trust the AS that =
issued the
                    tokens. And the AS must trust the Client to have
                    gathered consent.

                

              

            

            Theses two assertions are correct.

            

              

                

                  
 And the AS must have a relationship =
with the
                    user. 

                

              

            
Only when the user chooses one AS =
while giving its
              consent, then the user must have a relationship with the
              selected AS.

            

              

                

                  
It is unclear what role the RO is =
playing in this
                    though. The RO and RS look to be the same entity
                    from all the other parties.

                

              

            
A RO, as indicated on the figure, =
has only a relationship
              with one RS: it has no relationship with any AS. 

              The RS trusts the AS but the AS does not know which RSs
              are trusting it.

            

              

                

                  


                  

                  
=46rom my current understanding, at a =
high level,
                    this looks like it is supported by GNAP with the
                    addition of the discovery step (1). 

                

              

            
Well, it is fairly different : =


            

            
1) The first major =
difference is that there is no arrow
                between the RO and the AS. No protocol or "out-of-bands"
                means are necessary. 

              
2) The second major difference is that =
there is no
                arrow between the AS and the RS. No protocol is
                necessary. 
3) The third major =
difference is that the AS does not
                know any RS. Note: for backward compatibility reasons,
                an exception might exist for "old" Auth 2.0 ASs.

              
4) The fourth major difference is that =
the XAuth spec.
                is rather vague to describe when and by who the user
                consent is captured: 

                    XAuth states on page 4: "User consent =
is often required
                at the GS". In that case, the GS is able to act as Big
                Brother. No other case is described.

              

              5) The fifth major difference is that the data that is
              transferred to a "User Consent Element" to capture the
              user consent. That data can be standardized. 
=

                  Moreover, it will also be possible to =
standardize the
              dialogue between the RO and the RS. The RO will then be
              able to manage remotely the authorization tables.

                  See my email sent on June 6, with the =
following
              subject: "Support of FIDO and data minimization by =
RSs".

              

              6) Another difference is the following: since there is no
              interaction between the RO and the AS, "authorizations
              from the RO" as described in XAuth do not exist.   =


            

              

                

                  
There have been a number of proposals =
for doing
                    this discovery, and perhaps now there are enough use
                    cases to look at standardizing something.  

                    No interaction is needed between the AS and the =
User
                    as the Client is providing enough "information" in
                    the user object of the Grant Request 

                    to satisfy the AS releasing the access tokens. 

                  

                

              

            

            Not sure I understand correctly this last sentence.

            

              

                

                  


                  

                  
Perhaps as I understand the model in =
more detail
                    I will understand what is missing from GNAP (besides
                    the discovery step).

                

              

            
It would be hard to say "what is =
missing" from XAuth
              since the foundations are not the same.
In =
order to compare different architectures, there is the
              need to start with the trust relationships. 

              Unfortunately, the word "trust" is absent in the main body
              of draft-hardt-xauth-protocol-12. Hence, 

              the description of the trust relationships is missing.

            
Denis

            

              

                

                  


                  

                  
/Dick

                  


                  

                  
(I've skipped reviewing the delegation =
use case
                    below until I understand the simple use case)

                  


                  

                  

                    

                      
 

                            End of the story for a simple =
access
 

                            Start of a subsequent story for a delegation
                            case

                            

                            Let us now suppose that the RS is unable to
                            fulfil the request by its own and that it
                            needs to contact another RS. RS1 contacts
                            RS2 (4a) and indicates
                            the operation 

                            that it wants to perform on RS2 (that
                            operation may not be the same as the
                            original operation). In return (4b), RS2
                            informs RS1 about which attributes are
                            needed 

                            by RS2 for performing the requested
                            operation and from which Attributes Servers
                            they may be obtained. RS1 forwards that
                            information to the Client. 

                            

                            This information is marked to indicate that
                            it shall be handled by the "User Consent
                            element" from the Client. The presentation
                            of that information is up to the man machine
                            

                            interface from the Client. The user can see
                            which attributes are requested by RS2 for
                            performing the new requested operation and,
                            if it consents, the Client contacts one or
                            more 

                            appropriate Authorization Servers. The user
                            consent is hence captured locally by the
                            "User Consent element" from the Client.
                            (i.e. there is no dialogue with any AS, nor
                            RS1, nor RS2). 

                            

                            When the Client got the access token(s) from
                            the authorization server(s), it sends all of
                            them in a single request to RS1. RS1 then
                            forwards the additional access token(s) to
                            RS2.

                            

                            

                            Some observations: 

                            

                            The user nor the Client are linked with any
                            particular AS. A user may use today an AS of
                            the Bank of America and may change tomorrow
                            to the Bank of Missouri. 

                            As soon as he will be registered with the
                            Bank of Missouri, he will be able to get
                            access tokens from the AS of the Bank of
                            Missouri. The AS of Bank of America 

                            has not been able to know where its access
                            tokens have been used. This will be the same
                            for AS of the Bank of Missouri. There is no
                            need for any direct dialogue 

                            between any AS and any RS at the time a
                            client is making an access. There is no need
                            for any RO to contact any AS.
This model has been
                            constructed following a "Privacy by Design"
                            approach.

                        Denis
=

                      

                    

                    -- 

                    Txauth mailing list

                    Txauth@ietf.org

                    https://www.ietf.org/mailman/listinfo/txauth
=

                  

                

              

              
3D""=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

=

--Apple-Mail=_656925EB-5343-4206-B93A-691E8320D368--


From nobody Mon Jul 13 12:22: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 982F13A17D0 for ; Mon, 13 Jul 2020 12:22:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.628
X-Spam-Level: 
X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_FACE_BAD=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, 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 T4ZYShdMKdqL for ; Mon, 13 Jul 2020 12:22:20 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932333A17C2 for ; Mon, 13 Jul 2020 12:22:19 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d74 with ME id 2jNF2300J4FMSmm03jNGtF; Mon, 13 Jul 2020 21:22:17 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 13 Jul 2020 21:22:17 +0200
X-ME-IP: 86.238.65.197
To: Justin Richer , Dick Hardt 
Cc: "txauth@ietf.org" 
References:    <325bc015-1547-c56c-c1fe-67a97165785d@free.fr>  <83480ab0-03bc-7cc9-d166-ece4c6b63861@free.fr>  <83DB69E6-F0ED-41A0-A4DA-B7AE4AB89579@mit.edu>
From: Denis 
Message-ID: <34dfca59-47f7-63e4-b25f-01648b0bd14b@free.fr>
Date: Mon, 13 Jul 2020 21:22:11 +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: <83DB69E6-F0ED-41A0-A4DA-B7AE4AB89579@mit.edu>
Content-Type: multipart/alternative; boundary="------------651143750B8A37CDCFB98DC4"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 13 Jul 2020 19:22:25 -0000

This is a multi-part message in MIME format.
--------------651143750B8A37CDCFB98DC4
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Justin,

You have perfectly understood the differences. The location where the 
user consent is gathered /i//n a uniform way/ using to the information 
released by the RS
is a fundamental element of the design.

> If I’m understanding Denis’s proposal, he’s saying that that “prior 
> step” is the lynchpin of the whole model, since interaction between 
> the client and the RS (and the user and the RS) is key to Denis’s 
> privacy model. Additionally, what happens *at* each step is different. 
> Consent is gathered at the client, not the GS in this diagram, for 
> example. The GS simply mints a token as specified by the client and 
> the RS.
>
> It’s for these reasons that, as long as I’ve been understanding 
> correctly, I’ve been saying that Denis’s model as proposed is pretty 
> different.

Indeed.

Denis

> But what I think isn’t that different is the different steps if you’re 
> willing to look at the boundaries around the boxes differently. For 
> example, what OAuth would call “the AS” might end up being a few 
> different boxes in GNAP that do different things. I had started down 
> that route with XYZ’s design allowing the interaction to be managed 
> separately.
>
> I think that the disconnect we’re seeing here might be caused by 
> vocabulary mismatches. If we aren’t meaning the same thing when we say 
> the same terms, it’s easy to get things mixed up with each other. 
> Since GNAP is just barely forming its vocabulary out of the legacy of 
> OAuth and kin, we have a chance to maybe draw the lines better and see 
> if that’s how we can get things to fit.
>
>  — Justin
>
>> On Jul 13, 2020, at 2:02 PM, Dick Hardt > > wrote:
>>
>>
>> I'm going to just address the first part of your response so that we 
>> can get clarity on that before diving into your later comments.
>>
>> The calls between your proposal and XAuth are not inverted, your 
>> proposal has a prior step. Step 1 in XAuth maps to Step 2 in your 
>> proposal, and Step 2 in XAuth is Step 3 in your proposal..
>>
>> Below are 2 diagrams showing the same steps, the first keeping the 
>> existing step labels for XAuth, the latter renaming the steps to 
>> correspond to your proposal. This looks pretty similar to your 
>> diagram. What am I missing?
>>
>> /Dick
>>
>> DIAGRAM 1 (steps start at 0)
>>         +--------+                           +------------+
>>         |  User  |                           |  Resource  |
>>         |        |                           | Owner (RO) |
>>         +--------+                           +------------+
>>             |      \                       /      |
>>             |       \                     /       |
>>             |        \                   /        |
>>             |         \                 /         |
>>         +--------+     +---------------+     +------------+
>>         | Client |---->|     Grant     |     |  Resource  |
>>         |        | (1) |  Server (GS)  | _ _ |   Server   |
>>         |        |<----|               |     |    (RS)    |
>>         |        |     +---------------+     |            |
>>         |        |-------------------------->|            |
>>         |        |           (2)             |            |
>>         |        |<--------------------------|            |
>>         |        |-------------------------->|            |
>>         |        |           (0)             |            |
>>         |        |<--------------------------|            |
>>         +--------+                           +------------+
>> DIAGRAM 2 (steps start at 1)
>>         +--------+                           +------------+
>>         |  User  |                           |  Resource  |
>>         |        |                           | Owner (RO) |
>>         +--------+                           +------------+
>>             |      \                       /      |
>>             |       \                     /       |
>>             |        \                   /        |
>>             |         \                 /         |
>>         +--------+     +---------------+     +------------+
>>         | Client |---->|     Grant     |     |  Resource  |
>>         |        | (2) |  Server (GS)  | _ _ |   Server   |
>>         |        |<----|               |     |    (RS)    |
>>         |        |     +---------------+     |            |
>>         |        |-------------------------->|            |
>>         |        |           (3)             |            |
>>         |        |<--------------------------|            |
>>         |        |-------------------------->|            |
>>         |        |           (1)             |            |
>>         |        |<--------------------------|            |
>>         +--------+                           +------------+
>> ᐧ
>>
>> On Mon, Jul 13, 2020 at 7:08 AM Denis > > wrote:
>>
>>     Hello Dick,
>>
>>     You wrote: "This looks pretty similar to your protocol drawing".
>>
>>     No. There is a fundamental difference with the sequencing of the
>>     flow of the exchanges where the (1) and (2) flows are inverted.
>>
>>     In your figure:
>>
>>         The Client makes calls to the GS (1)
>>         The Client makes calls to the RS (2)
>>
>>     while in my figure:
>>
>>         The Client makes calls to the RS (1)
>>         The Client makes calls to the AS (2)
>>
>>     In your figure, the first flow is with the GS, whereas in my
>>     figure the first flow is with the RS and there is a good reason
>>     for that:
>>     the client first contacts the RS to know what the RS expects. The
>>     client indicates in its first exchange to the RS whether it wants
>>     to authenticate
>>     or to perform another operation.  In the case of an
>>     authentication operation, the RS may respond to the client that
>>     is supports FIDO U2F
>>     or that it is willing the client to present some attribute(s)
>>     from one or more AS.
>>
>>     Then after the client has to figure out whether the user is using
>>     FIDO and if not whether the user has an account with one of the AS.
>>     In the later case, if there is a match then the client,/*after
>>     having received the user consent*/, may contact the appropriate
>>     AS to ask
>>     for some attribute(s).
>>
>>     The same fundamental difference applies with
>>     draft-richer-transactional-authz-06 (XYZ) where the first
>>     exchange is done with the AS:
>>     "The RC creates a transaction request and sends it to the AS".
>>
>>     This answers also in details to one of your comments:
>>
>>         What looks to be missing from your proposal is:
>>         A) The Client making a call to the RS to discover what it
>>         needs from a GS, and which GS to ask, prior to (1).
>>
>>     This is not missing since this is the foundation of the
>>     architecture. The discovery mechanism at the RS has been described
>>     in details in an earlier email with the following title: "Support
>>     of FIDO and data minimization by RSs".
>>
>>     The main figures are copied below (using ASCII):**
>>
>>     *+-----------------------------------+---------------------------------+
>>     +Operation+Mathematical expression+
>>     +-----------------------------------+---------------------------------+
>>     + Authentication+ Condition 1 OR Condition 2+
>>     +-----------------------------------+---------------------------------+
>>     + Operation A OR Operation Z+ Condition 3 AND Condition 4+
>>     +-----------------------------------+---------------------------------+
>>
>>     **Conditions table: **
>>
>>     +-------------+--------------+-----------------------------+----------+
>>     + Condition 1 + FIDO U2F 1.2 +++
>>     +-------------+--------------+-----------------------------+----------+
>>     + Condition 2 + AS 1+ set 1 of a attributes types + +
>>     +-------------+--------------+-----------------------------+----------+
>>     + Condition 3 + AS 2+ set 2 of a attributes types + Scope 21 +
>>      
>>     +-------------+--------------+-----------------------------+----------+
>>     + Condition 4 + AS 9+ set 3 of a attributes types-+ +
>>     +-------------+--------------+-----------------------------+----------+
>>     *
>>     According to the operation announced by the Client, the RS
>>     returns to the Client both the mathematical expression
>>     associated with that operation and the conditions included in
>>     that mathematical expression. The Client may then
>>     present that information to the user in order to obtain the user
>>     consent in a standardized manner.
>>
>>     Another comment you made is:
>>
>>         What looks to be missing from your proposal is:
>>         B) A mechanism for the Client to prove to the GS that it has
>>         gathered consent from the User.
>>
>>     The user consent should not be captured *by the GS*, since the GS
>>     would be in a position to apply a different consent decision
>>     without letting it know to the user (or to the client).
>>
>>     The user consent must be captured *by the Client* and the Client
>>     must be able to verify that this consent has indeed been followed
>>     by the AS.
>>
>>     The authorization data managed at the RS by the RO is used by the
>>     Client to query the consent of the user in a standardized manner.
>>     When, later on, the access token is returned to the Client by the
>>     AS, the Client (not the user) using that authorization data as
>>     well as
>>     the decision of the user is able to verify that the requested
>>     attributes (and no more) are indeed present into the access token.
>>
>>     This is why access tokens may *not* be considered to be opaque to
>>     the Clients.
>>
>>     In my earlier email copied below, six major differences with
>>     XAuth from 1) to 6) are listed.
>>
>>     Denis
>>
>>>     From
>>>     https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1
>>>
>>>
>>>
>>>           1.1
>>>           .
>>>           Parties
>>>
>>>
>>>
>>>         The parties and their relationships to each other:
>>>             +--------+                           +------------+
>>>             |  User  |                           |  Resource  |
>>>             |        |                           | Owner (RO) |
>>>             +--------+                           +------------+
>>>                 |      \                       /      |
>>>                 |       \                     /       |
>>>                 |        \                   /        |
>>>                 |         \                 /         |
>>>             +--------+     +---------------+     +------------+
>>>             | Client |---->|     Grant     |     |  Resource  |
>>>             |        | (1) |  Server (GS)  | _ _ |   Server   |
>>>             |        |<----|               |     |    (RS)    |
>>>             |        |     +---------------+     |            |
>>>             |        |-------------------------->|            |
>>>             |        |           (2)             |            |
>>>             |        |<--------------------------|            |
>>>             +--------+                           +------------+
>>>
>>>
>>>     The lines without arrows represent relationships.
>>>     The User trusts the Client
>>>     The User trusts the GS
>>>     The RO trusts the GS to issue access tokens for the RS
>>>     The RS trusts the tokens issued by the RS
>>>     The RO controls the RS
>>>
>>>     The Client makes calls to the GS (1)
>>>     The Client makes calls to the RS (2)
>>>
>>>     This looks pretty similar to your protocol drawing.
>>>
>>>     What looks to be missing from your proposal is:
>>>
>>>     A) The Client making a call to the RS to discover what it needs
>>>     from a GS, and which GS to ask, prior to (1).
>>>     B) A mechanism for the Client to prove to the GS that it has
>>>     gathered consent from the User.
>>>
>>>     The current protocol does not require the GS to interact with
>>>     either the User, the RO, or the RS -- which looks to me to meet
>>>     your privacy goals.
>>>
>>>     ᐧ
>>>
>>>     On Fri, Jul 10, 2020 at 6:06 AM Denis >>     > wrote:
>>>
>>>         Hi Dick,
>>>
>>>>         Hi Denis, thanks for sharing the model. I don't fully
>>>>         understand what is going on, questions inserted:
>>>         Responses are inserted.
>>>>
>>>>         FWIW: having paragraphs start with the step number (1), (2)
>>>>         etc. would make it easier to map between the description
>>>>         and the diagram.
>>>>
>>>>         On Thu, Jul 9, 2020 at 3:26 AM Denis >>>         > wrote:
>>>>
>>>>             This is a new thread.
>>>>
>>>>             Preamble: This model is quite different from the XAuth
>>>>             model.
>>>>             In particular, a RO has no relationship with any AS and
>>>>             a Client does not need to be associated with any AS
>>>>             prior to any access to a RS.
>>>>
>>>>             A key point of this model is that the user's consent is
>>>>             handled locally by the Client and hence no AS nor RS is
>>>>             handling a man machine interface
>>>>             for the user consent. This allows to support locally
>>>>             the user consent for multiple ASs while keeping all ASs
>>>>             ignorant about the choices of the user
>>>>             made for accessing a particular RS.
>>>>             *
>>>>
>>>>             **+--------++------------+
>>>>             |User||Resource|
>>>>             ||| Owner (RO) |
>>>>             +--------++------------+
>>>>             |\|
>>>>             |\|
>>>>             |\|
>>>>             |\|
>>>>             +-----------++---------------++------------+
>>>>             ||---->| Authorization |||
>>>>             || (2) |Server (AS)|||
>>>>             ||<----||||
>>>>             |Client|+---------------+||
>>>>             ||-------------------------->|Resource|
>>>>             |User|(1)|Server|
>>>>             |Consent|<--------------------------|(RS)|
>>>>             |element|||
>>>>             ||-------------------------->||------>
>>>>             ||(3)||(4)
>>>>             ||<--------------------------||<------
>>>>             +-----------++------------+
>>>>             *
>>>>             The flow of operations is as follows:
>>>>
>>>>             The Client (which may have been previously
>>>>             authenticated using FIDO)
>>>>
>>>>         Which party has the client authenticated to? The client
>>>>         authenticating with FIDO is confusing to me. FIDO is
>>>>         usually how a user authenticates.
>>>
>>>         If the user has previously opened a user account with the RS
>>>         using FIDO, then the client may be authenticated by the RS
>>>         using FIDO.
>>>         In such a case, the user is already known to the RS under a
>>>         pseudonym specific to the RS. It may (or may not) have
>>>         previously presented access tokens
>>>         to that RS.
>>>
>>>>         contacts the RS and after some dialogue with the RS selects
>>>>         an operation
>>>>         How does the client know which RS to contact?
>>>
>>>         For a private usage, the user may use DuckDuckGo, while for
>>>         business he may use an application from his company which
>>>         lists various services
>>>         available in the context of his job or his position. Some
>>>         services may be freely available to all the employees of the
>>>         company with any authentication,
>>>         e.g. the phone book of the employees may be freely available
>>>         on the intranet of the company, while some other services
>>>         may require the user
>>>         to authenticate to the AS from the company.
>>>
>>>>         that it wants to perform on the RS (1a). Note that it may
>>>>         also indicate directly the operation that it wants to
>>>>         perform on the RS without any prior dialogue.
>>>>
>>>>             In return (1b), the RS informs the Client about which
>>>>             attributes are needed by the RS for performing the
>>>>             requested operation and from which Attributes Servers
>>>>             they may be obtained.
>>>>
>>>>         (1a) and (1b) are not labeled. There is only (1)
>>>
>>>         (1a) is the first exchange for (1) with the arrow from left
>>>         to right, while (1b) is the response with the arrow from
>>>         right to left.
>>>         The same applies to the other exchanges i.e. (2) , (3) and (4).
>>>
>>>>
>>>>             This information is specifically marked to indicate
>>>>             that it shall be handled by the "User Consent element"
>>>>             from the Client.
>>>>
>>>>         Why? What is the significance of this? Which information is
>>>>         marked?
>>>
>>>         In the response, a specific identifier or a magic number is
>>>         used to indicate the start and the length of the information
>>>         block
>>>         to be sent to the "User Consent element" supported by the
>>>         Client.
>>>
>>>>         The presentation of that information is up to the man
>>>>         machine interface supported by the "User Consent element"
>>>>         from the Client.
>>>>
>>>>
>>>>         Which information?
>>>
>>>         The attributes that are needed by the RS for performing a
>>>         requested operation and from which Attributes Servers they
>>>         may be obtained.
>>>
>>>>
>>>>             The user can see which attributes are requested by the
>>>>             RS for performing the requested operation and, if it
>>>>             consents, the Client contacts one or more
>>>>             appropriate Authorization Servers (2a).
>>>>
>>>>         How does the client know which AS(s) to contact?
>>>
>>>         For each AS trusted by the RS to perfom a given operation,
>>>         the RS should indicate a user-friendly name and a URL of the
>>>         AS.
>>>
>>>>             The user consent is hence captured locally by the
>>>>             Client (i.e. there is no dialogue with any AS nor any RS).
>>>>
>>>>
>>>>         No dialogue with who? The client is calling the AS is it not?
>>>
>>>         For the user consent, there is no external call since it is
>>>         handled locally. Afterwards, there is a call to the AS(s)
>>>         selected by the user.
>>>
>>>>
>>>>             When the Client got the access tokens from these
>>>>             authorization servers (2b), it sends all of them in a
>>>>             single request to the RS (3a).
>>>>
>>>>
>>>>         So the RS must trust the AS that issued the tokens. And the
>>>>         AS must trust the Client to have gathered consent.
>>>         Theses two assertions are correct.
>>>>         And the AS must have a relationship with the user.
>>>
>>>         Only when the user chooses one AS while giving its consent,
>>>         then the user must have a relationship with the selected AS.
>>>
>>>>         It is unclear what role the RO is playing in this though.
>>>>         The RO and RS look to be the same entity from all the other
>>>>         parties.
>>>
>>>         A RO, as indicated on the figure, has only a relationship
>>>         with one RS: it has no relationship with any AS.
>>>         The RS trusts the AS but the AS does not know which RSs are
>>>         trusting it.
>>>
>>>>
>>>>         From my current understanding, at a high level, this looks
>>>>         like it is supported by GNAP with the addition of the
>>>>         discovery step (1).
>>>
>>>         Well, it is fairly different :
>>>
>>>             1) The first major difference is that there is no arrow
>>>             between the RO and the AS. No protocol or "out-of-bands"
>>>             means are necessary.
>>>
>>>             2) The second major difference is that there is no arrow
>>>             between the AS and the RS. No protocol is necessary.
>>>
>>>             3) The third major difference is that the AS does not
>>>             know any RS. Note: for backward compatibility reasons,
>>>             an exception might exist for "old" Auth 2.0 ASs.
>>>
>>>             4) The fourth major difference is that the XAuth spec.
>>>             is rather vague to describe when and by who the user
>>>             consent is captured:
>>>                 XAuth states on page 4: "User consent is /often
>>>             /required at the GS". In that case, the GS is able to
>>>             act as Big Brother. No other case is described.
>>>
>>>             5) The fifth major difference is that the data that is
>>>             transferred to a "User Consent Element" to capture the
>>>             user consent. That data can be standardized.
>>>                 Moreover, it will also be possible to standardize
>>>             the dialogue between the RO and the RS. The RO will then
>>>             be able to manage remotely the authorization tables.
>>>                 See my email sent on June 6, with the following
>>>             subject: "Support of FIDO and data minimization by RSs".
>>>
>>>             6) Another difference is the following: since there is
>>>             no interaction between the RO and the AS,
>>>             "authorizations from the RO" as described in XAuth do
>>>             not exist. 
>>>
>>>>         There have been a number of proposals for doing this
>>>>         discovery, and perhaps now there are enough use cases to
>>>>         look at standardizing something.
>>>>         No interaction is needed between the AS and the User as the
>>>>         Client is providing enough "information" in the user object
>>>>         of the Grant Request
>>>>         to satisfy the AS releasing the access tokens.
>>>         Not sure I understand correctly this last sentence.
>>>>
>>>>         Perhaps as I understand the model in more detail I will
>>>>         understand what is missing from GNAP (besides the discovery
>>>>         step).
>>>
>>>         It would be hard to say "what is missing" from XAuth since
>>>         the foundations are not the same.
>>>
>>>         In order to compare different architectures, there is the
>>>         need to start with the trust relationships.
>>>         Unfortunately, the word "trust" is absent in the main body
>>>         of draft-hardt-xauth-protocol-12. Hence,
>>>         the description of the trust relationships is missing.
>>>
>>>         Denis
>>>
>>>>
>>>>         /Dick
>>>>
>>>>         (I've skipped reviewing the delegation use case below until
>>>>         I understand the simple use case)
>>>>
>>>>
>>>>             End of the story for a simple access
>>>>
>>>>
>>>>             Start of a subsequent story for a delegation case
>>>>
>>>>             Let us now suppose that the RS is unable to fulfil the
>>>>             request by its own and that it needs to contact another
>>>>             RS. RS1 contacts RS2 (4a) and indicates the operation
>>>>             that it wants to perform on RS2 (that operation may not
>>>>             be the same as the original operation). In return (4b),
>>>>             RS2 informs RS1 about which attributes are needed
>>>>             by RS2 for performing the requested operation and from
>>>>             which Attributes Servers they may be obtained. RS1
>>>>             forwards that information to the Client.
>>>>
>>>>             This information is marked to indicate that it shall be
>>>>             handled by the "User Consent element" from the Client.
>>>>             The presentation of that information is up to the man
>>>>             machine
>>>>             interface from the Client. The user can see which
>>>>             attributes are requested by RS2 for performing the new
>>>>             requested operation and, if it consents, the Client
>>>>             contacts one or more
>>>>             appropriate Authorization Servers. The user consent is
>>>>             hence captured locally by the "User Consent element"
>>>>             from the Client. (i.e. there is no dialogue with any
>>>>             AS, nor RS1, nor RS2).
>>>>
>>>>             When the Client got the access token(s) from the
>>>>             authorization server(s), it sends all of them in a
>>>>             single request to RS1. RS1 then forwards the additional
>>>>             access token(s) to RS2.
>>>>
>>>>
>>>>             Some observations:
>>>>
>>>>             The user nor the Client are linked with any particular
>>>>             AS. A user may use today an AS of the Bank of America
>>>>             and may change tomorrow to the Bank of Missouri.
>>>>             As soon as he will be registered with the Bank of
>>>>             Missouri, he will be able to get access tokens from the
>>>>             AS of the Bank of Missouri. The AS of Bank of America
>>>>             has not been able to know where its access tokens have
>>>>             been used. This will be the same for AS of the Bank of
>>>>             Missouri. There is no need for any direct dialogue
>>>>             between any AS and any RS at the time a client is
>>>>             making an access. There is no need for any RO to
>>>>             contact any AS.
>>>>
>>>>             This model has been constructed following a "Privacy by
>>>>             Design" approach.
>>>>
>>>>             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
>


--------------651143750B8A37CDCFB98DC4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Justin,

    


    

    
You have perfectly understood the
      differences. The location where the user consent is gathered in
        a uniform way using to the information released by the RS 

      is a fundamental element of the design.  

    

    

    

      
      If I’m understanding Denis’s proposal, he’s saying that that
      “prior step” is the lynchpin of the whole model, since interaction
      between the client and the RS (and the user and the RS) is key to
      Denis’s privacy model. Additionally, what happens *at* each step
      is different. Consent is gathered at the client, not the GS in
      this diagram, for example. The GS simply mints a token as
      specified by the client and the RS.
      


      

      
It’s for these reasons that, as long as I’ve been
        understanding correctly, I’ve been saying that Denis’s model as
        proposed is pretty different. 

    

    
Indeed.

    
Denis

    

    

      
But what I think isn’t that different is the
        different steps if you’re willing to look at the boundaries
        around the boxes differently. For example, what OAuth would call
        “the AS” might end up being a few different boxes in GNAP that
        do different things. I had started down that route with XYZ’s
        design allowing the interaction to be managed separately. 

      


      

      
I think that the disconnect we’re seeing here might
        be caused by vocabulary mismatches. If we aren’t meaning the
        same thing when we say the same terms, it’s easy to get things
        mixed up with each other. Since GNAP is just barely forming its
        vocabulary out of the legacy of OAuth and kin, we have a chance
        to maybe draw the lines better and see if that’s how we can get
        things to fit.

        


        

        
 — Justin

          


            

              
On Jul 13, 2020, at 2:02 PM, Dick Hardt <dick.hardt@gmail.com>
                wrote:

              

              

                
                


                  
I'm going to just address the first part
                    of your response so that we can get clarity on that
                    before diving into your later comments.

                  


                  

                  
The calls between your proposal and
                    XAuth are not inverted, your proposal has a prior
                    step. Step 1 in XAuth maps to Step 2 in your
                    proposal, and Step 2 in XAuth is Step 3 in your
                    proposal..

                  


                  

                  
Below are 2 diagrams showing the same
                    steps, the first keeping the existing step labels
                    for XAuth, the latter renaming the steps to
                    correspond to your proposal. This looks pretty
                    similar to your diagram. What am I missing?

                  


                  

                  
/Dick

                  


                  

                  

                    
DIAGRAM 1 (steps start at 0)

                    
       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (0)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+

                    

                    

                    
DIAGRAM 2 (steps start at 1)

                    
       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (2) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (3)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (1)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+

                  

                

                
ᐧ

                

                

                  
On Mon, Jul 13, 2020
                    at 7:08 AM Denis <denis.ietf@free.fr>
                    wrote:

                  

                  

                    

                      
Hello Dick,

                      


                      

                      
You wrote: "This looks pretty
                        similar to your protocol drawing".

                        

                      

                      
No. There is a fundamental
                        difference with the sequencing of the flow of
                        the exchanges where the (1) and (2) flows are
                        inverted. 

                      

                      


                      

                      
In your figure:

                      

                      

                        

                          
The Client makes calls to the GS
                            (1)

                          
The Client makes calls to the RS
                            (2)

                        

                        
while in my figure:

                        

                          

                            
The Client makes calls to the
                              RS (1)

                            
The Client makes calls to the
                              AS (2)

                          

                        

                      

                      
In your figure, the first flow is
                        with the GS, whereas in my figure the first flow
                        is with the RS and there is a good reason for
                        that: 

                        the client first contacts the RS to know what
                        the RS expects. The client indicates in its
                        first exchange to the RS whether it wants to
                        authenticate 

                        or to perform another operation.  In the case of
                        an authentication operation, the RS may respond
                        to the client that is supports FIDO U2F 

                        or that it is willing the client to present some
                        attribute(s) from one or more AS.

                      


                      

                      
Then after the client has to figure
                        out whether the user is using FIDO and if not
                        whether the user has an account with one of the
                        AS.

                      
In the later case, if there is a
                        match then the client, *after having
                          received the user consent*, may contact
                        the appropriate AS to ask 

                        for some attribute(s). 

                      

                      


                      

                      
The same fundamental difference
                        applies with draft-richer-transactional-authz-06
                        (XYZ) where the first exchange is done with the
                        AS:

                      
"The RC creates a transaction
                        request and sends it to the AS".

                      


                      

                      
This answers also in details to one
                        of your comments:

                      

                        

                          
What looks to be missing from
                            your proposal is:

                          
A) The Client making a call to
                            the RS to discover what it needs from a GS,
                            and which GS to ask, prior to (1).

                        

                      

                      
This is not missing since this is
                        the foundation of the architecture. The
                        discovery mechanism at the RS has been described
                        

                        in details in an earlier email with the
                        following title: "Support of FIDO and data
                        minimization by RSs".

                      


                      

                      
The main figures are copied below
                        (using ASCII):
                        
  +-----------------------------------+---------------------------------+

                                  +          
                                Operation              
                                +      Mathematical
                                expression    +

                                  +-----------------------------------+---------------------------------+

                                  +
                                Authentication                   
                                + Condition 1 OR Condition 2      +

                                  +-----------------------------------+---------------------------------+

                                  + Operation A
                                OR Operation Z        +
                                Condition 3 AND Condition 4     +

                                  +-----------------------------------+---------------------------------+

                                

                              Conditions table: 

                                

                                  +-------------+--------------+-----------------------------+----------+

                                  + Condition 1 +
                                FIDO U2F 1.2 +                            
                                +          +

                                  +-------------+--------------+-----------------------------+----------+

                                  + Condition 2 +
                                AS 1         +
                                set 1 of a attributes types +          +

                                  +-------------+--------------+-----------------------------+----------+

                                  + Condition 3 +
                                AS 2         +
                                set 2 of a attributes types + Scope 21 +

                                  +-------------+--------------+-----------------------------+----------+

                                  + Condition 4 +
                                AS 9         +
                                set 3 of a attributes types-+          +

                                  +-------------+--------------+-----------------------------+----------+

                            

                          According to the operation announced by the
                          Client, the RS returns to the Client both the
                          mathematical expression 

                          associated with that operation and the
                          conditions included in that mathematical
                          expression. The Client may then 

                          present that information to the user in order
                          to obtain the user consent in a standardized
                          manner.

                        

                      

                      
Another comment you made is:

                      

                        
What looks to be missing from your
                          proposal is:

                        
B) A mechanism for the Client to
                          prove to the GS that it has gathered consent
                          from the User.

                      

                      
The user consent should not be
                        captured *by the GS*, since the GS would be in a
                        position to apply a different consent decision 

                        without letting it know to the user (or to the
                        client).

                      


                        The user consent must be captured *by the
                        Client* and the Client must be able to verify
                        that this consent has indeed been followed by
                        the AS. 

                      

                      


                      

                      
The authorization data managed at
                        the RS by the RO is used by the Client to query
                        the consent of the user in a standardized
                        manner.

                      
When, later on, the access token is
                        returned to the Client by the AS, the Client
                        (not the user) using that authorization data as
                        well as 

                        the decision of the user is able to verify that
                        the requested attributes (and no more) are
                        indeed present into the access token. 

                        

                        This is why access tokens may *not* be
                        considered to be opaque to the Clients.

                      


                      

                      
In my earlier email copied below,
                        six major differences with XAuth from 1) to 6)
                        are listed.

                      


                      

                      
Denis

                        

                      

                      

                        
From https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1
                          


                            

                              
1.1.  Parties


   The parties and their relationships to each other:


                              
       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+



                            

                            

                              


                              

                              
The lines without arrows
                                represent relationships. 

                            

                          

                          
The User trusts the Client

                          
The User trusts the GS

                          
The RO trusts the GS to issue
                            access tokens for the RS

                          
The RS trusts the tokens issued
                            by the RS

                          
The RO controls the RS

                          


                          

                          
The Client makes calls to the GS
                            (1)

                          
The Client makes calls to the RS
                            (2)

                          


                          

                          
This looks pretty similar to
                            your protocol drawing.

                          


                          

                          
What looks to be missing from
                            your proposal is:

                          


                          

                          
A) The Client making a call to
                            the RS to discover what it needs from a GS,
                            and which GS to ask, prior to (1).

                          
B) A mechanism for the Client to
                            prove to the GS that it has gathered consent
                            from the User.

                          


                          

                          
The current protocol does not
                            require the GS to interact with either the
                            User, the RO, or the RS -- which looks to me
                            to meet your privacy goals.

                          


                          

                        

                        
ᐧ

                        

                        

                          
On Fri, Jul
                            10, 2020 at 6:06 AM Denis <denis.ietf@free.fr>
                            wrote:

                          

                          

                            

                              
Hi Dick,

                              


                              

                              

                                

                                  
Hi Denis,
                                    thanks for sharing the model. I
                                    don't fully understand what is going
                                    on, questions inserted:

                                

                              

                              Responses are inserted.

                              

                                

                                  

                                    


                                    

                                    
FWIW: having
                                      paragraphs start with the step
                                      number (1), (2) etc. would make it
                                      easier to map between the
                                      description and the diagram.

                                  

                                  

                                  

                                    
On
                                      Thu, Jul 9, 2020 at 3:26 AM Denis
                                      <denis.ietf@free.fr>
                                      wrote:

                                    

                                    

                                      

                                        

                                          
This is a new
                                              thread.

                                              

                                              Preamble: This model is
                                              quite different from the
                                              XAuth model. 

                                              In particular, a RO has no
                                              relationship with any AS
                                              and a Client does not need
                                              to be associated with any
                                              AS prior to any access to
                                              a RS.

                                              

                                              A key point of this model
                                              is that the user's consent
                                              is handled locally by the
                                              Client and hence no AS nor
                                              RS is handling a man
                                              machine interface 

                                              for the user consent. This
                                              allows to support locally
                                              the user consent for
                                              multiple ASs while keeping
                                              all ASs ignorant about the
                                              choices of the user 

                                              made for accessing a
                                              particular RS.

                                              

                                                

                                                       +--------+                          
                                                  +------------+

                                                        
                                                  | 
                                                  User  |                          
                                                  | 
                                                  Resource  |

                                                        
                                                  |       
                                                  |                          
                                                  | Owner (RO) |

                                                        
                                                  +--------+                           +------------+

                                                            
                                                  |     
                                                  \                             
                                                  |

                                                            
                                                  |      
                                                  \                            
                                                  |

                                                            
                                                  |       
                                                  \                           
                                                  |

                                                            
                                                  |        
                                                  \                          
                                                  |

                                                      +-----------+     +---------------+     +------------+

                                                      |          
                                                  |---->|
                                                  Authorization |     |           
                                                  |

                                                      |          
                                                  | (2) |  Server
                                                  (AS)  |     |           
                                                  |

                                                      |          
                                                  |<----|              
                                                  |    
                                                  |           
                                                  |

                                                      |  Client   |     +---------------+     |           
                                                  |

                                                      |          
                                                  |-------------------------->|  Resource  |

                                                      |   User    |          
                                                  (1)            
                                                  |  
                                                  Server   |

                                                      |  Consent  |<--------------------------|    (RS)    |

                                                      |  element  |                          
                                                  |           
                                                  |

                                                      |          
                                                  |-------------------------->|           
                                                  |------>

                                                      |          
                                                  |          
                                                  (3)            
                                                  |           
                                                  | 
                                                  (4)

                                                      |          
                                                  |<--------------------------|           
                                                  |<------

                                                      +-----------+                          
                                                  +------------+

                                              

                                              The flow of operations is
                                              as follows:

                                              

                                              The Client (which may have
                                              been previously
                                              authenticated using FIDO)
                                            

                                        

                                      

                                    

                                    
Which party has the
                                      client authenticated to? The
                                      client authenticating with FIDO is
                                      confusing to me. FIDO is usually
                                      how a user authenticates.

                                  

                                

                              

                              
If the user has previously
                                opened a user account with the RS using
                                FIDO, then the client may be
                                authenticated by the RS using FIDO.

                                In such a case, the user is already
                                known to the RS under a pseudonym
                                specific to the RS. It may (or may not)
                                have previously presented access tokens
                                

                                to that RS.

                              

                              

                                

                                  

                                    
 contacts the RS and
                                        after some dialogue with the RS
                                        selects an operation 

                                      

                                    
How does the client
                                      know which RS to contact?

                                  

                                

                              

                              
For a private usage, the user
                                may use DuckDuckGo, while for business
                                he may use an application from his
                                company which lists various services 

                                available in the context of his job or
                                his position. Some services may be
                                freely available to all the employees of
                                the company with any authentication,

                                e.g. the phone book of the employees may
                                be freely available on the intranet of
                                the company, while some other services
                                may require the user 

                                to authenticate to the AS from the
                                company.

                              

                                

                                  

                                    
 that it wants to
                                        perform on the RS (1a). Note
                                        that it may also indicate
                                        directly the operation that it
                                        wants to perform on the RS
                                        without any prior dialogue. 

                                      

                                    

                                      

                                        

                                          
 In return
                                              (1b), the RS informs the
                                              Client about which
                                              attributes are needed by
                                              the RS for performing the
                                              requested operation and
                                              from which Attributes
                                              Servers 

                                              they may be obtained. 

                                            

                                        

                                      

                                    

                                    
(1a) and (1b) are not
                                      labeled. There is only (1) 

                                    

                                  

                                

                              

                              
(1a) is the first exchange for
                                (1) with the arrow from left to right,
                                while (1b) is the response with the
                                arrow from right to left. 

                                The same applies to the other exchanges
                                i.e. (2) , (3) and (4).

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
 

                                              This information is
                                              specifically marked to
                                              indicate that it shall be
                                              handled by the "User
                                              Consent element" from the
                                              Client. 

                                            

                                        

                                      

                                    

                                    
Why? What is the
                                      significance of this? Which
                                      information is marked?

                                  

                                

                              

                              
In the response, a specific
                                identifier or a magic number is used to
                                indicate the start and the length of the
                                information block  

                                to be sent to the "User Consent element"
                                  supported by the Client.

                              

                              

                                

                                  

                                    

                                      
The presentation
                                          of that information is up to
                                          the man machine interface
                                          supported by the "User Consent
                                          element" from the Client. 

                                        

                                    

                                    


                                    

                                    
Which information? 

                                    

                                  

                                

                              

                              
The
                                  attributes that are needed by the RS
                                  for performing a requested operation
                                  and from which Attributes Servers they
                                  may be obtained.

                              

                                

                                  

                                    

                                      

                                        

                                          
 

                                              The user can see which
                                              attributes are requested
                                              by the RS for performing
                                              the requested operation
                                              and, if it consents, the
                                              Client contacts one or
                                              more 

                                              appropriate Authorization
                                              Servers (2a). 

                                        

                                      

                                    

                                    
How does the client
                                      know which AS(s) to contact?

                                  

                                

                              

                              
For each AS trusted by the RS
                                to perfom a given operation, the RS
                                should indicate a user-friendly name and
                                a URL of the AS. 

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
The user
                                              consent is hence captured
                                              locally by the Client
                                              (i.e. there is no dialogue
                                              with any AS nor any RS).

                                            

                                        

                                      

                                    

                                    


                                    

                                    
No dialogue with who?
                                      The client is calling the AS is it
                                      not? 

                                    

                                  

                                

                              

                              
For the user consent, there is
                                no external call since it is handled
                                locally. Afterwards, there is a call to
                                the AS(s) selected by the user.

                              

                                

                                  

                                    

                                      

                                        

                                          
 

                                              When the Client got the
                                              access tokens from these
                                              authorization servers
                                              (2b), it sends all of them
                                              in a single request to the
                                              RS (3a).

                                            

                                        

                                      

                                    

                                    


                                    

                                    
So the RS must trust
                                      the AS that issued the tokens. And
                                      the AS must trust the Client to
                                      have gathered consent.

                                  

                                

                              

                              Theses two assertions are correct.

                              

                                

                                  

                                    
 And the AS must have
                                      a relationship with the user. 

                                  

                                

                              

                              
Only when the user chooses one
                                AS while giving its consent, then the
                                user must have a relationship with the
                                selected AS.

                              

                                

                                  

                                    
It is unclear what
                                      role the RO is playing in this
                                      though. The RO and RS look to be
                                      the same entity from all the other
                                      parties.

                                  

                                

                              

                              
A RO, as indicated on the
                                figure, has only a relationship with one
                                RS: it has no relationship with any AS.
                                

                                The RS trusts the AS but the AS does not
                                know which RSs are trusting it.

                              

                                

                                  

                                    


                                    

                                    
From my current
                                      understanding, at a high level,
                                      this looks like it is supported by
                                      GNAP with the addition of the
                                      discovery step (1). 

                                  

                                

                              

                              
Well, it is fairly different :
                                

                              

                              

                                
1) The first major
                                  difference is that there is no arrow
                                  between the RO and the AS. No protocol
                                  or "out-of-bands" means are necessary.
                                  

                                

                                
2) The second major
                                  difference is that there is no arrow
                                  between the AS and the RS. No protocol
                                  is necessary. 

                                
3) The third major
                                  difference is that the AS does not
                                  know any RS. Note: for backward
                                  compatibility reasons, an exception
                                  might exist for "old" Auth 2.0 ASs.

                                

                                
4) The fourth major
                                  difference is that the XAuth spec. is
                                  rather vague to describe when and by
                                  who the user consent is captured: 

                                      XAuth states on page 4: "User
                                  consent is often required
                                  at the GS". In that case, the GS is
                                  able to act as Big Brother. No other
                                  case is described.

                                

                                5) The fifth major difference is that
                                the data that is transferred to a "User
                                Consent Element" to capture the user
                                consent. That data can be standardized.
                                

                                    Moreover, it will also be possible
                                to standardize the dialogue between the
                                RO and the RS. The RO will then be able
                                to manage remotely the authorization
                                tables.

                                    See my email sent on June 6, with
                                the following subject: "Support of FIDO
                                and data minimization by RSs".

                                

                                6) Another difference is the following:
                                since there is no interaction between
                                the RO and the AS, "authorizations from
                                the RO" as described in XAuth do not
                                exist.   

                              

                                

                                  

                                    
There have been a
                                      number of proposals for doing this
                                      discovery, and perhaps now there
                                      are enough use cases to look at
                                      standardizing something.  

                                      No interaction is needed between
                                      the AS and the User as the Client
                                      is providing enough "information"
                                      in the user object of the Grant
                                      Request 

                                      to satisfy the AS releasing the
                                      access tokens. 

                                    

                                  

                                

                              

                              Not sure I understand correctly this last
                              sentence.

                              

                                

                                  

                                    


                                    

                                    
Perhaps as I
                                      understand the model in more
                                      detail I will understand what is
                                      missing from GNAP (besides the
                                      discovery step).

                                  

                                

                              

                              
It would be hard to say "what
                                is missing" from XAuth since the
                                foundations are not the same.

                              
In order to compare different
                                architectures, there is the need to
                                start with the trust relationships. 

                                Unfortunately, the word "trust" is
                                absent in the main body of
                                draft-hardt-xauth-protocol-12. Hence, 

                                the description of the trust
                                relationships is missing.

                              

                              
Denis

                              

                                

                                  

                                    


                                    

                                    
/Dick

                                    


                                    

                                    
(I've skipped
                                      reviewing the delegation use case
                                      below until I understand the
                                      simple use case)

                                    


                                    

                                    

                                      

                                        

                                          
 

                                              End of the story for a
                                              simple access

                                          
 

                                              Start of a subsequent
                                              story for a delegation
                                              case

                                              

                                              Let us now suppose that
                                              the RS is unable to fulfil
                                              the request by its own and
                                              that it needs to contact
                                              another RS. RS1 contacts
                                              RS2 (4a)
                                              and indicates the
                                              operation 

                                              that it wants to perform
                                              on RS2 (that operation may
                                              not be the same as the
                                              original operation). In
                                              return (4b), RS2 informs
                                              RS1 about which attributes
                                              are needed 

                                              by RS2 for performing the
                                              requested operation and
                                              from which Attributes
                                              Servers they may be
                                              obtained. RS1 forwards
                                              that information to the
                                              Client. 

                                              

                                              This information is marked
                                              to indicate that it shall
                                              be handled by the "User
                                              Consent element" from the
                                              Client. The presentation
                                              of that information is up
                                              to the man machine 

                                              interface from the Client.
                                              The user can see which
                                              attributes are requested
                                              by RS2 for performing the
                                              new requested operation
                                              and, if it consents, the
                                              Client contacts one or
                                              more 

                                              appropriate Authorization
                                              Servers. The user consent
                                              is hence captured locally
                                              by the "User Consent
                                              element" from the Client.
                                              (i.e. there is no dialogue
                                              with any AS, nor RS1, nor
                                              RS2). 

                                              

                                              When the Client got the
                                              access token(s) from the
                                              authorization server(s),
                                              it sends all of them in a
                                              single request to RS1. RS1
                                              then forwards the
                                              additional access token(s)
                                              to RS2.

                                              

                                              

                                              Some observations: 

                                              

                                              The user nor the Client
                                              are linked with any
                                              particular AS. A user may
                                              use today an AS of the
                                              Bank of America and may
                                              change tomorrow to the
                                              Bank of Missouri. 

                                              As soon as he will be
                                              registered with the Bank
                                              of Missouri, he will be
                                              able to get access tokens
                                              from the AS of the Bank of
                                              Missouri. The AS of Bank
                                              of America 

                                              has not been able to know
                                              where its access tokens
                                              have been used. This will
                                              be the same for AS of the
                                              Bank of Missouri. There is
                                              no need for any direct
                                              dialogue 

                                              between any AS and any RS
                                              at the time a client is
                                              making an access. There is
                                              no need for any RO to
                                              contact any AS.

                                          
This model
                                              has been constructed
                                              following a "Privacy by
                                              Design" approach.

                                          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

              

            

          

          

        

      

    

    


    

  


--------------651143750B8A37CDCFB98DC4--


From nobody Mon Jul 13 12:31: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 5B2583A0828 for ; Mon, 13 Jul 2020 12:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4DvP_KiCpWZZ for ; Mon, 13 Jul 2020 12:31:22 -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 5F78D3A0827 for ; Mon, 13 Jul 2020 12:31:19 -0700 (PDT)
Received: from [192.168.1.7] (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 06DJVGj4017038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Jul 2020 15:31:17 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_AD4750CD-8CD5-4B3C-A12D-D895BBBD73F0"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 13 Jul 2020 15:31:16 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu>  <174F2061-3F0F-49B2-A18F-58DF658E4473@mit.edu>  
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 13 Jul 2020 19:31:30 -0000

--Apple-Mail=_AD4750CD-8CD5-4B3C-A12D-D895BBBD73F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

A quick note, as my choice of language below seems to have been =
confusing. First there is a typo, where the word =E2=80=9Cit=E2=80=9D =
should have been =E2=80=9Cin=E2=80=9D to read:

> I am saying that GNAP, in its definition within this working group, =
should be limited to identifier claims.

And second, there seems to be confusion around whether I=E2=80=99m =
trying to argue about the scope =E2=80=9Callowed=E2=80=9D by the charter =
by saying =E2=80=9Cits definition within this working group=E2=80=9D =
here.=20

To be clear, we as the working group are defining GNAP the protocol. It =
has not yet been defined, and that=E2=80=99s why were all here. The =
charter doesn=E2=80=99t define it. The input specs don=E2=80=99t define =
it. The working group defines it, and my stance as a contributor to this =
WG is that we should focus on a delegation protocol with some basic =
identifier query support and leave the full fledged identity protocol to =
different work.=20

We=E2=80=99ve already got our hands full here without taking all of that =
on, especially since I do believe we need to build GNAP in such a way as =
to facilitate its extension in several known directions, including a =
full identity protocol. If we do things right here, we can see GNAP as =
the basis of a large number of things out there in the world.=20

So my stance in what we should do, as we define GNAP as a protocol, is =
focus on this one, limited slice of the identity space and not spiral =
into others.

 =E2=80=94 Justin

> On Jul 13, 2020, at 2:51 PM, Justin Richer  wrote:
>=20
> I am saying that GNAP, it its definition within this working group, =
should be limited to identifier claims. Other claims can come from other =
protocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop =
them from being built, but in my opinion we shouldn=E2=80=99t be =
defining those here. See the discussion below on the extensibility =
avenues of this approach.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 13, 2020, at 2:12 PM, Dick Hardt > wrote:
>>=20
>> I agree that an API to return claims is useful. I think we have =
agreed on that.=20
>>=20
>> Using the SubjectIdentifiers schema is another schema that would be =
useful for GNAP to support.=20
>>=20
>> I disagree that GNAP should be limited to identifier claims.=20
>>=20
>> =E1=90=A7
>>=20
>> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer > wrote:
>> One thing I think we should learn from OIDC is that returning claims =
from an API, and not just an assertion or direct response, is a powerful =
and useful pattern. We have an opportunity to separate these cleanly, =
where OIDC didn=E2=80=99t have the opportunity in defining the =
=E2=80=9Cclaims=E2=80=9D request parameter.
>>=20
>> As an alternative to the current XYZ and XAuth syntaxes, over the =
weekend I=E2=80=99ve been playing with something that would look like =
this strawman in the request:
>>=20
>>=20
>> {
>>    subject: {
>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =
=E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
>>    }
>> }
>>=20
>> This request says that I=E2=80=99d like some subset of these =
identifiers (as plain text in the response) and some subset of signed =
assertions in the given formats. Each one would have an associated space =
in the return. I=E2=80=99m not picturing that the =E2=80=9Cid=E2=80=9D =
field values would affect the contents of the assertions: so I could ask =
for an email address identifier but get back an ID token that had only =
the subject identifier. Maybe that=E2=80=99s not the right model? But =
it=E2=80=99s at least simple and deterministic this way, and it=E2=80=99s =
something to play with.
>>=20
>> Note: The =E2=80=9Cid=E2=80=9D names are taken from =
https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.html =
, the =E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=99t =
see a source that collected them. If you wanted specific bundles of =
claims about the user from a UserInfoEndpoint, for example, you=E2=80=99d =
have something like:
>>=20
>> {
>>    subject: {
>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =
=E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
>>    },
>>    resources: [{
>>        type: =E2=80=9Cuserinfo=E2=80=9D,
>>        datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D=
, =E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
>>   }]
>> }
>>=20
>> This is an example for a specific kind of resource, and I don=E2=80=99t=
 think that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema =
here, or the datatype values therein. That should be work outside of =
GNAP, probably for the OIDF.
>>=20
>> This approach is extensible in several ways, each of them for a =
specific reason that I think is clear:
>>=20
>>  - new values in the =E2=80=9Cid=E2=80=9D field to give new =
identifiers
>>  - new values in the =E2=80=9Cassertion=E2=80=9D field to give new =
assertion formats
>>  - new fields under the =E2=80=9Csubject=E2=80=9D heading=20
>>  - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =
=E2=80=9Cscim-v1=E2=80=9D or =E2=80=9Cfacebook-profile=E2=80=9D for =
instance)
>>  - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource type
>>  - new top-level request parameters
>>=20
>> As per the other thread, if you wanted to use the OIDC query =
language, you=E2=80=99d package it separately as a top-level request =
parameter since it can include both the ID token response and the access =
token response and we shouldn=E2=80=99t be encouraging mixing these =
things together.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 10, 2020, at 5:00 PM, Dick Hardt > wrote:
>>>=20
>>> It looks to me that our different views of what is in scope for GNAP =
are the differences below.
>>>=20
>>> Per the subject line, I'm looking at how the client acquires claims =
about the user. You don't think that is in scope, and that a different =
layer will solve that.
>>>=20
>>> I think we should learn from OIDC being on top of OAuth, and GNAP =
should be able return ANY claim, not just identifier claims. There are =
use cases that may be difficult to support if we do not have that =
functionality in scope, such as some of the ones I list below, and it =
seems pretty straightforward to support ANY claim if we are supporting =
identifiers.
>>>=20
>>> /Dick
>>>=20
>>>=20
>>> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer > wrote:
>>>=20
>>>=20
>>>> On Jul 10, 2020, at 2:15 PM, Dick Hardt > wrote:
>>>>=20
>>>>=20
>>>> inline ...=20
>>>>=20
>>>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer > wrote:
>>>> Yes, the core idea is to not have to parse an assertion to get back =
the core authentication information, which consists of an identifier =
(iss/sub pair in OIDC, but could be a number of things). Sometimes the =
client is going to want the rest of the identity information, but If the =
user=E2=80=99s logged into the client before, the client has likely =
cached that info and probably won=E2=80=99t need it, and sending it =
would be a violation of privacy principles.. The client would want the =
info pretty much just in these cases:
>>>>=20
>>>>  1. The client has never seen the user before.=20
>>>>  2. The user=E2=80=99s information has been updated since the last =
time the client saw it.
>>>>=20
>>>> Agreed
>>>> =20
>>>>=20
>>>> Now for case (1), how would the client know if it wants to request =
the user=E2=80=99s profile info or not, since it doesn=E2=80=99t know =
who the user is?
>>>>=20
>>>> But the client could know who the user is. The client may have used =
a different AS to authenticate the user.
>>>=20
>>> In these cases, the client is not going to be requesting identity =
information from the AS to log the user in, so it=E2=80=99s not relevant =
to the use case. The client will have an opportunity to push that =
information to the AS.
>>>=20
>>>> The User may have self identified to the client. The client may =
have a cookie saying who the user was and the user said that was them. =
While the latter cases are really a strong hint, they are likely right =
most of the time and can lead to a user experience basde on that hint
>>>=20
>>> In these cases, the AS might be able to guess if the client has info =
about the user already, but probably not. And the assumptions fall apart =
if it=E2=80=99s in fact a different user that ends up logging in, which =
is of course possible (the hint you gave doesn=E2=80=99t match the =
identity of the current user after the AS validates them). This =
possibility leads to clients always asking for everything every time and =
the server providing everything every time. That=E2=80=99s a pattern I =
think we should avoid in an ultimate solution =E2=80=94 but ultimately, =
I don=E2=80=99t think that this kind of protocol decision is inside of =
GNAP.
>>>=20
>>>> =20
>>>> And the AS won=E2=80=99t know if client is going to want the =
profile info, since the AS won=E2=80=99t know if the client has the =
user=E2=80=99s info or not. Sure, the AS might have seen that client and =
that user combo previously, but it doesn=E2=80=99t know if the client =
needs an update.
>>>>=20
>>>> The client can share with the AS the user it knows or thinks it is =
dealing with, which could let the AS respond if the information was new. =
This could be the case for an AS that is providing claims, but not =
authentication, and could happen silently. The user would only interact =
if the user information had changed, and the client wanted the updated =
information.
>>>> =20
>>>=20
>>> See above.
>>>=20
>>>>=20
>>>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s =
info has been updated or not because it doesn=E2=80=99t know who the =
user is yet. If the AS can provide some time of updated stamp to the =
client, the client can pull the new info when it needs it.
>>>>=20
>>>> See above.
>>>=20
>>> See above.
>>>=20
>>>> =20
>>>>=20
>>>> If you ignore both of these cases and put all the user information =
inline with the main request/response, you end up in a situation where =
the client always requests everything and the server always provides =
everything, since you can=E2=80=99t be sure you=E2=80=99re not in =
situation (1) or (2) ahead of time.
>>>>=20
>>>> See above. There are a number of other states the client could be =
in.
>>>>=20
>>>> For example, the client could be stateless about user information, =
so it knows it is ALWAYS in state 1.
>>>=20
>>> A stateless client would need to fetch appropriate user information =
every time, then. But that=E2=80=99s an optimization for a very specific =
case.
>>>=20
>>>> =20
>>>>=20
>>>> This is really what I mean about the two-stage identity protocol.
>>>>=20
>>>> I know what it is. Per above, GNAP lets us support a wider set of =
use cases. Why limit ourselves to what OIDC supported?
>>>=20
>>> We aren=E2=80=99t limiting the protocol, but instead limiting the =
scope of what we define internal to the GNAP protocol. There=E2=80=99s a =
lot of room for innovation on top of it.
>>>=20
>>>> =20
>>>> In the first stage, you push the bare minimum of what you need to =
get the user known to the client. In the second stage, the client uses =
its access token to call an API to get whatever else it needs to know =
about the user.
>>>>=20
>>>> =46rom a privacy perspective in non-enterprise use cases, I think =
the user should give consent to any updated personal information to a =
client. In general, the client should not be able to get the latest =
information about a user whenever it wants.
>>>=20
>>> This is about the rights associated with the access token, then. And =
an access token doesn=E2=80=99t have to keep working if the AS has a =
policy that says it won=E2=80=99t. The AS/RS could easily decide that a =
particular access token will only return data that hasn=E2=80=99t been =
changed. Maybe it stops working after the data changes, or it just =
returns old data, or any number of things. This is for the AS/RS to =
decide and this is pretty standard interpretation of the token, nothing =
special here because we=E2=80=99re dealing with identity.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>> =20
>>>> /Dick
>>>> =E1=90=A7
>>>=20
>>=20
>=20
> --=20
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth


--Apple-Mail=_AD4750CD-8CD5-4B3C-A12D-D895BBBD73F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

A =
quick note, as my choice of language below seems to have been confusing. =
First there is a typo, where the word =E2=80=9Cit=E2=80=9D should have =
been =E2=80=9Cin=E2=80=9D to read:

I am saying that GNAP, in its definition within this working group, should be =
limited to identifier claims.

And second, there seems to be confusion =
around whether I=E2=80=99m trying to argue about the scope =E2=80=9Callowe=
d=E2=80=9D by the charter by saying =E2=80=9Cits definition within this =
working group=E2=80=9D here. 

To be clear, we as the working group =
are defining GNAP the protocol. It has not yet been =
defined, and that=E2=80=99s why were all here. The charter doesn=E2=80=99t=
 define it. The input specs don=E2=80=99t define it. The working group =
defines it, and my stance as a contributor to this WG is that we should =
focus on a delegation protocol with some basic identifier query support =
and leave the full fledged identity protocol to different =
work. 

We=E2=80=99ve already got our hands full here without taking =
all of that on, especially since I do believe we need to build GNAP in =
such a way as to facilitate its extension in several known directions, =
including a full identity protocol. If we do things right here, we can =
see GNAP as the basis of a large number of things out there in the =
world. 

So =
my stance in what we should do, as we define GNAP as a protocol, is =
focus on this one, limited slice of the identity space and not spiral =
into others.

 =E2=80=94 Justin

On Jul =
13, 2020, at 2:51 PM, Justin Richer <jricher@mit.edu> wrote:



I am saying that GNAP, =
it its definition within this working group, should be limited to =
identifier claims. Other claims can come from other protocols properly =
layered on top of GNAP. GNAP shouldn=E2=80=99t stop them from being =
built, but in my opinion we shouldn=E2=80=99t be defining those here. =
See the discussion below on the extensibility avenues of this =
approach.

 =E2=80=
=94 Justin

On Jul 13, 2020, at 2:12 PM, =
Dick Hardt <dick.hardt@gmail.com> wrote:

I agree that an API to return claims is useful. I think we =
have agreed on that. 

Using the SubjectIdentifiers schema is another schema that =
would be useful for GNAP to support. 

I disagree that GNAP should be =
limited to identifier claims. 

3D""=E1=90=A7

On Mon, Jul =
13, 2020 at 7:16 AM Justin Richer <jricher@mit.edu> wrote:
One thing I think we should learn from OIDC is =
that returning claims from an API, and not just an assertion or direct =
response, is a powerful and useful pattern. We have an opportunity to =
separate these cleanly, where OIDC didn=E2=80=99t have the opportunity =
in defining the =E2=80=9Cclaims=E2=80=9D request parameter.

As an alternative to the =
current XYZ and XAuth syntaxes, over the weekend I=E2=80=99ve been =
playing with something that would look like this strawman in the =
request:


{
   subject: {
    =
  id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
      =
assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =
=E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
   }
}

This request says that =
I=E2=80=99d like some subset of these identifiers (as plain text in the =
response) and some subset of signed assertions in the given formats. =
Each one would have an associated space in the return. I=E2=80=99m not =
picturing that the =E2=80=9Cid=E2=80=9D field values would affect the =
contents of the assertions: so I could ask for an email address =
identifier but get back an ID token that had only the subject =
identifier. Maybe that=E2=80=99s not the right model? But it=E2=80=99s =
at least simple and deterministic this way, and it=E2=80=99s something =
to play with.

Note: The =E2=80=9Cid=E2=80=9D names are taken from https://tools.ietf.org/id/draft-ietf-secevent-subject-identifie=
rs-05.html, the =E2=80=9Cassertion=E2=80=9D names are made up as I =
didn=E2=80=99t see a source that collected them. If you wanted specific =
bundles of claims about the user from a UserInfoEndpoint, for example, =
you=E2=80=99d have something like:

{
  =
 subject: {
  =
    id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
      assertion: [ =E2=80=9Codic_id_token=E2=80=9D=
, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" =
]
  =
 },
  =
 resources: [{
  =
     type: =E2=80=9Cuserinfo=E2=80=9D,
       datatypes: [ =
=E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =E2=80=9Cphone=E2=80=9D=
, =E2=80=9Cemail=E2=80=9D ]
  }]
}

This is an example for a specific kind =
of resource, and I don=E2=80=99t think that GNAP should define the =
=E2=80=9Cuserinfo=E2=80=9D schema here, or the datatype values therein. =
That should be work outside of GNAP, probably for the OIDF.

This approach is =
extensible in several ways, each of them for a specific reason that I =
think is clear:

 - new values in the =E2=80=9Cid=E2=80=9D field to give =
new identifiers
 - new values in the =
=E2=80=9Cassertion=E2=80=9D field to give new assertion =
formats
 - new fields under the =E2=80=9Csubject=
=E2=80=9D heading 
 - new resource types =
besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or =
=E2=80=9Cfacebook-profile=E2=80=9D for instance)
 - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D =
resource type
 - new top-level request =
parameters

As =
per the other thread, if you wanted to use the OIDC query language, =
you=E2=80=99d package it separately as a top-level request parameter =
since it can include both the ID token response and the access token =
response and we shouldn=E2=80=99t be encouraging mixing these things =
together.

 =E2=80=94 Justin

On Jul =
10, 2020, at 5:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It looks to me that our different =
views of what is in scope for GNAP are the differences below.

Per the subject line, =
I'm looking at how the client acquires claims about the user. You don't =
think that is in scope, and that a different layer will solve =
that.

I think =
we should learn from OIDC being on top of OAuth, and GNAP should be able =
return ANY claim, not just identifier claims. There are use cases that =
may be difficult to support if we do not have that functionality in =
scope, such as some of the ones I list below, and it seems pretty =
straightforward to support ANY claim if we are supporting =
identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09 PM Justin Richer =
<jricher@mit.edu> wrote:


On Jul 10, 2020, at 2:15 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:


inline ... 

On Thu, Jul =
9, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea is =
to not have to parse an assertion to get back the core authentication =
information, which consists of an identifier (iss/sub pair in OIDC, but =
could be a number of things). Sometimes the client is going to want the =
rest of the identity information, but If the user=E2=80=99s logged =
into the client before, the client has likely cached that info and =
probably won=E2=80=99t need it, and sending it would be a violation of =
privacy principles.. The client would want the info pretty much just in =
these cases:

 1. =
The client has never seen the user before. 
 2. The user=E2=80=99s information has been updated =
since the last time the client saw it.

Agreed
 

Now for case (1), how would the client =
know if it wants to request the user=E2=80=99s profile info or not, =
since it doesn=E2=80=99t know who the user is? =


But the client could know who the user is. The client may =
have used a different AS to authenticate the user. =


In these cases, the client is not going =
to be requesting identity information from the AS to log the user in, so =
it=E2=80=99s not relevant to the use case. The client will have an =
opportunity to push that information to the AS.

The User may have self identified to the client. The client =
may have a cookie saying who the user was and the user said that was =
them. While the latter cases are really a strong hint, they are likely =
right most of the time and can lead to a user experience basde on that =
hint

In these cases, the AS might be able to =
guess if the client has info about the user already, but probably not. =
And the assumptions fall apart if it=E2=80=99s in fact a different user =
that ends up logging in, which is of course possible (the hint you gave =
doesn=E2=80=99t match the identity of the current user after the AS =
validates them). This possibility leads to clients always asking for =
everything every time and the server providing everything every time. =
That=E2=80=99s a pattern I think we should avoid in an ultimate solution =
=E2=80=94 but ultimately, I don=E2=80=99t think that this kind of =
protocol decision is inside of GNAP.

 
And =
the AS won=E2=80=99t know if client is going to want the profile info, =
since the AS won=E2=80=99t know if the client has the user=E2=80=99s =
info or not. Sure, the AS might have seen that client and that user =
combo previously, but it doesn=E2=80=99t know if the client needs an =
update.

The client can share with the AS the user it knows or thinks =
it is dealing with, which could let the AS respond if the information =
was new. This could be the case for an AS that is providing claims, but =
not authentication, and could happen silently. The user would only =
interact if the user information had changed, and the client wanted the =
updated information.
 

See above.


And for (2), the client won=E2=80=99t =
know if the user=E2=80=99s info has been updated or not because it =
doesn=E2=80=99t know who the user is yet. If the AS can provide some =
time of updated stamp to the client, the client can pull the new info =
when it needs it.

See =
above.

See above.

 

If you ignore both of these cases and =
put all the user information inline with the main request/response, you =
end up in a situation where the client always requests everything and =
the server always provides everything, since you can=E2=80=99t be sure =
you=E2=80=99re not in situation (1) or (2) ahead of =
time.

See above. There are a number of other states the client =
could be in.

For=
 example, the client could be stateless about user information, so it =
knows it is ALWAYS in state =
1.

A stateless client would need to fetch =
appropriate user information every time, then. But that=E2=80=99s an =
optimization for a very specific case.

 

This is really what I mean about the =
two-stage identity protocol. 

I know what it is. Per above, GNAP lets =
us support a wider set of use cases. Why limit ourselves to what OIDC =
supported?

We aren=E2=80=99t limiting the =
protocol, but instead limiting the scope of what we define internal to =
the GNAP protocol. There=E2=80=99s a lot of room for innovation on top =
of it.

 
In the first stage, you push the bare minimum of what you =
need to get the user known to the client. In the second stage, the =
client uses its access token to call an API to get whatever else it =
needs to know about the user. 
=46rom a privacy perspective in =
non-enterprise use cases, I think the user should give consent to any =
updated personal information to a client. In general, the client =
should not be able to get the latest information about a user whenever =
it wants.

This is about the rights associated =
with the access token, then. And an access token doesn=E2=80=99t have to =
keep working if the AS has a policy that says it won=E2=80=99t. The =
AS/RS could easily decide that a particular access token will only =
return data that hasn=E2=80=99t been changed. Maybe it stops working =
after the data changes, or it just returns old data, or any number of =
things. This is for the AS/RS to decide and this is pretty standard =
interpretation of the token, nothing special here because we=E2=80=99re =
dealing with identity.

 =E2=80=94 Justin

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









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

=

--Apple-Mail=_AD4750CD-8CD5-4B3C-A12D-D895BBBD73F0--


From nobody Mon Jul 13 12:34: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 8A53E3A0101 for ; Mon, 13 Jul 2020 12:34:48 -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=[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_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 Ox_9icZMLItJ for ; Mon, 13 Jul 2020 12:34:44 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 C212B3A090B for ; Mon, 13 Jul 2020 12:34:16 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id t74so9827595lff.2 for ; Mon, 13 Jul 2020 12:34:16 -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=rj8Jc8xsGMvEKc/iusxm5DQH1LAOhjzhF7T/UNU+YWg=; b=Zj2JubSidACIai1d5uWeFoDvevDtKoN07wVT6yFYhgAdg+ys3ADgQ/yBXAsYTCt6zm 1uiJu6h7QCfRHi7A9405TV134erex9qT0UA3LlEyfGLdKW87fDYC+gYY2CMyd51RDwLB e8e5vV7Zt9l1l0WJ9zTUKDR0ByQsXQOfNdPE01xnwgDybagZLWB0N95D8gWjUCq3WW4x K8u/9hjzIOUoIA1yJYe15JBVJZwKwNx4dQAzU+GvIMVsfF2cIxELd35mL+0Gzn6vLQWW vXchAwk7jsUUV/k4LlUhKIZLEO3hz0/hj8XlSd/AmkHs3/Fdhrvdi0oAEoeL4al2HkMM zung==
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=rj8Jc8xsGMvEKc/iusxm5DQH1LAOhjzhF7T/UNU+YWg=; b=UXpJIwlE/tKNKVGZKq8vpO0mCu1nDDYN4BN9nK9AUcfOHVUy1fyV7A3iuZZd9lJ5vx jYyUEn8yzKcsihOft1Tpzc5qI5tHSzYYZVkhko8qSJgJMaJ6Hfc/xvnLQ2RTK05O9G/+ pgrm9oJTPjV69rbYkeKK/vi40X/Ea3XEOSzX2kkMtgFOESAyKhRie4fefaJqr2lXaG50 I5cDHtpi17qfvgBztii2xdPIbJiSG2/OXWJ5wZTdX5GhX0NUAAB0aqmhP0Awv8odZpWv CtS1oZkHcXyfotZmGNln5Lw+p67IwLtJ5JYxcbHBB2hQHkHz8YrRpInvj34Y3j1y9ahl Uebw==
X-Gm-Message-State: AOAM533/5mUoydINP534K8BKIoo/T0ZHlivxUW+efl6vF3/Lvj6CGQKf kNos8wlGDP+vpV9NfjzbqrAPf5LB81uPmRp8Y8Y=
X-Google-Smtp-Source: ABdhPJxyCB55JzrWVSO6fl4DnLu/BbqwganbiCNFqTC21pSgL2iIHX9RoraEEBJ+fgPRW6uY4yLuAv3nxFiz1c5zRB4=
X-Received: by 2002:a19:64c:: with SMTP id 73mr368957lfg.0.1594668854803; Mon, 13 Jul 2020 12:34:14 -0700 (PDT)
MIME-Version: 1.0
References:    <325bc015-1547-c56c-c1fe-67a97165785d@free.fr>  <83480ab0-03bc-7cc9-d166-ece4c6b63861@free.fr>  <83DB69E6-F0ED-41A0-A4DA-B7AE4AB89579@mit.edu> <34dfca59-47f7-63e4-b25f-01648b0bd14b@free.fr>
In-Reply-To: <34dfca59-47f7-63e4-b25f-01648b0bd14b@free.fr>
From: Dick Hardt 
Date: Mon, 13 Jul 2020 12:33:36 -0700
Message-ID: 
To: Denis 
Cc: Justin Richer , "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000a000ee05aa57c60f"
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 13 Jul 2020 19:34:49 -0000

--000000000000a000ee05aa57c60f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I get that the Client<->RS step is critical to the use case, as is the User
not interacting with the GS, but there are other use cases where the User
does not interact with the GS, for example
https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-2.3., but
Denis's use case should not be the only use case.

So it seems that GNAP can support Denis's use case by defining the
initial Client<->RS interaction, and the information in the user object of
the Grant Request to be what the GS needs to issue access tokens, which was
what I suggested earlier.

I don't understand what is missing, besides the details of the Client<->RS
interaction, and what is in the Grant Request.


On Mon, Jul 13, 2020 at 12:22 PM Denis  wrote:

> Hi Justin,
>
> You have perfectly understood the differences. The location where the use=
r
> consent is gathered *i**n a uniform way* using to the information
> released by the RS
> is a fundamental element of the design.
>
> If I=E2=80=99m understanding Denis=E2=80=99s proposal, he=E2=80=99s sayin=
g that that =E2=80=9Cprior step=E2=80=9D
> is the lynchpin of the whole model, since interaction between the client
> and the RS (and the user and the RS) is key to Denis=E2=80=99s privacy mo=
del.
> Additionally, what happens *at* each step is different. Consent is gather=
ed
> at the client, not the GS in this diagram, for example. The GS simply min=
ts
> a token as specified by the client and the RS.
>
> It=E2=80=99s for these reasons that, as long as I=E2=80=99ve been underst=
anding correctly,
> I=E2=80=99ve been saying that Denis=E2=80=99s model as proposed is pretty=
 different.
>
> Indeed.
>
> Denis
>
> But what I think isn=E2=80=99t that different is the different steps if y=
ou=E2=80=99re
> willing to look at the boundaries around the boxes differently. For
> example, what OAuth would call =E2=80=9Cthe AS=E2=80=9D might end up bein=
g a few different
> boxes in GNAP that do different things. I had started down that route wit=
h
> XYZ=E2=80=99s design allowing the interaction to be managed separately.
>
> I think that the disconnect we=E2=80=99re seeing here might be caused by
> vocabulary mismatches. If we aren=E2=80=99t meaning the same thing when w=
e say the
> same terms, it=E2=80=99s easy to get things mixed up with each other. Sin=
ce GNAP is
> just barely forming its vocabulary out of the legacy of OAuth and kin, we
> have a chance to maybe draw the lines better and see if that=E2=80=99s ho=
w we can
> get things to fit.
>
>  =E2=80=94 Justin
>
> On Jul 13, 2020, at 2:02 PM, Dick Hardt  wrote:
>
>
> I'm going to just address the first part of your response so that we can
> get clarity on that before diving into your later comments.
>
> The calls between your proposal and XAuth are not inverted, your proposal
> has a prior step. Step 1 in XAuth maps to Step 2 in your proposal, and St=
ep
> 2 in XAuth is Step 3 in your proposal..
>
> Below are 2 diagrams showing the same steps, the first keeping the
> existing step labels for XAuth, the latter renaming the steps to correspo=
nd
> to your proposal. This looks pretty similar to your diagram. What am I
> missing?
>
> /Dick
>
> DIAGRAM 1 (steps start at 0)
>
>        +--------+                           +------------+
>        |  User  |                           |  Resource  |
>        |        |                           | Owner (RO) |
>        +--------+                           +------------+
>            |      \                       /      |
>            |       \                     /       |
>            |        \                   /        |
>            |         \                 /         |
>        +--------+     +---------------+     +------------+
>        | Client |---->|     Grant     |     |  Resource  |
>        |        | (1) |  Server (GS)  | _ _ |   Server   |
>        |        |<----|               |     |    (RS)    |
>        |        |     +---------------+     |            |
>        |        |-------------------------->|            |
>        |        |           (2)             |            |
>        |        |<--------------------------|            |
>        |        |-------------------------->|            |
>        |        |           (0)             |            |
>        |        |<--------------------------|            |
>        +--------+                           +------------+
>
> DIAGRAM 2 (steps start at 1)
>
>        +--------+                           +------------+
>        |  User  |                           |  Resource  |
>        |        |                           | Owner (RO) |
>        +--------+                           +------------+
>            |      \                       /      |
>            |       \                     /       |
>            |        \                   /        |
>            |         \                 /         |
>        +--------+     +---------------+     +------------+
>        | Client |---->|     Grant     |     |  Resource  |
>        |        | (2) |  Server (GS)  | _ _ |   Server   |
>        |        |<----|               |     |    (RS)    |
>        |        |     +---------------+     |            |
>        |        |-------------------------->|            |
>        |        |           (3)             |            |
>        |        |<--------------------------|            |
>        |        |-------------------------->|            |
>        |        |           (1)             |            |
>        |        |<--------------------------|            |
>        +--------+                           +------------+
>
> =E1=90=A7
>
> On Mon, Jul 13, 2020 at 7:08 AM Denis  wrote:
>
>> Hello Dick,
>>
>> You wrote: "This looks pretty similar to your protocol drawing".
>>
>> No. There is a fundamental difference with the sequencing of the flow of
>> the exchanges where the (1) and (2) flows are inverted.
>>
>> In your figure:
>>
>> The Client makes calls to the GS (1)
>> The Client makes calls to the RS (2)
>>
>> while in my figure:
>>
>> The Client makes calls to the RS (1)
>> The Client makes calls to the AS (2)
>>
>> In your figure, the first flow is with the GS, whereas in my figure the
>> first flow is with the RS and there is a good reason for that:
>> the client first contacts the RS to know what the RS expects. The client
>> indicates in its first exchange to the RS whether it wants to authentica=
te
>> or to perform another operation.  In the case of an authentication
>> operation, the RS may respond to the client that is supports FIDO U2F
>> or that it is willing the client to present some attribute(s) from one o=
r
>> more AS.
>>
>> Then after the client has to figure out whether the user is using FIDO
>> and if not whether the user has an account with one of the AS.
>> In the later case, if there is a match then the client,* *after having
>> received the user consent**, may contact the appropriate AS to ask
>> for some attribute(s).
>>
>> The same fundamental difference applies with
>> draft-richer-transactional-authz-06 (XYZ) where the first exchange is do=
ne
>> with the AS:
>> "The RC creates a transaction request and sends it to the AS".
>>
>> This answers also in details to one of your comments:
>>
>> What looks to be missing from your proposal is:
>> A) The Client making a call to the RS to discover what it needs from a
>> GS, and which GS to ask, prior to (1).
>>
>> This is not missing since this is the foundation of the architecture. Th=
e
>> discovery mechanism at the RS has been described
>> in details in an earlier email with the following title: "Support of FID=
O
>> and data minimization by RSs".
>>
>> The main figures are copied below (using ASCII):
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *
>> +-----------------------------------+---------------------------------+
>> +           Operation               +      Mathematical expression    +
>> +-----------------------------------+---------------------------------+ =
  +
>> Authentication                    + Condition 1 OR Condition 2      +
>> +-----------------------------------+---------------------------------+ =
  +
>> Operation A OR Operation Z        + Condition 3 AND Condition 4     +
>> +-----------------------------------+---------------------------------+ =
**Conditions
>> table: *
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *
>> +-------------+--------------+-----------------------------+----------+ =
  +
>> Condition 1 + FIDO U2F 1.2 +                             +          +
>> +-------------+--------------+-----------------------------+----------+ =
  +
>> Condition 2 + AS 1         + set 1 of a attributes types +          +
>> +-------------+--------------+-----------------------------+----------+ =
  +
>> Condition 3 + AS 2         + set 2 of a attributes types + Scope 21 +
>> +-------------+--------------+-----------------------------+----------+ =
  +
>> Condition 4 + AS 9         + set 3 of a attributes types-+          +
>> +-------------+--------------+-----------------------------+----------+ =
*
>> According to the operation announced by the Client, the RS returns to th=
e
>> Client both the mathematical expression
>> associated with that operation and the conditions included in that
>> mathematical expression. The Client may then
>> present that information to the user in order to obtain the user consent
>> in a standardized manner.
>> Another comment you made is:
>>
>> What looks to be missing from your proposal is:
>> B) A mechanism for the Client to prove to the GS that it has gathered
>> consent from the User.
>>
>> The user consent should not be captured *by the GS*, since the GS would
>> be in a position to apply a different consent decision
>> without letting it know to the user (or to the client).
>>
>> The user consent must be captured *by the Client* and the Client must be
>> able to verify that this consent has indeed been followed by the AS.
>>
>> The authorization data managed at the RS by the RO is used by the Client
>> to query the consent of the user in a standardized manner.
>> When, later on, the access token is returned to the Client by the AS, th=
e
>> Client (not the user) using that authorization data as well as
>> the decision of the user is able to verify that the requested attributes
>> (and no more) are indeed present into the access token.
>>
>> This is why access tokens may *not* be considered to be opaque to the
>> Clients.
>>
>> In my earlier email copied below, six major differences with XAuth from
>> 1) to 6) are listed.
>>
>> Denis
>>
>> From
>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1
>>
>> 1.1 .  Parties
>>
>>    The parties and their relationships to each other:
>>
>>        +--------+                           +------------+
>>        |  User  |                           |  Resource  |
>>        |        |                           | Owner (RO) |
>>        +--------+                           +------------+
>>            |      \                       /      |
>>            |       \                     /       |
>>            |        \                   /        |
>>            |         \                 /         |
>>        +--------+     +---------------+     +------------+
>>        | Client |---->|     Grant     |     |  Resource  |
>>        |        | (1) |  Server (GS)  | _ _ |   Server   |
>>        |        |<----|               |     |    (RS)    |
>>        |        |     +---------------+     |            |
>>        |        |-------------------------->|            |
>>        |        |           (2)             |            |
>>        |        |<--------------------------|            |
>>        +--------+                           +------------+
>>
>>
>> The lines without arrows represent relationships.
>> The User trusts the Client
>> The User trusts the GS
>> The RO trusts the GS to issue access tokens for the RS
>> The RS trusts the tokens issued by the RS
>> The RO controls the RS
>>
>> The Client makes calls to the GS (1)
>> The Client makes calls to the RS (2)
>>
>> This looks pretty similar to your protocol drawing.
>>
>> What looks to be missing from your proposal is:
>>
>> A) The Client making a call to the RS to discover what it needs from a
>> GS, and which GS to ask, prior to (1).
>> B) A mechanism for the Client to prove to the GS that it has gathered
>> consent from the User.
>>
>> The current protocol does not require the GS to interact with either the
>> User, the RO, or the RS -- which looks to me to meet your privacy goals.
>>
>> =E1=90=A7
>>
>> On Fri, Jul 10, 2020 at 6:06 AM Denis  wrote:
>>
>>> Hi Dick,
>>>
>>> Hi Denis, thanks for sharing the model. I don't fully understand what i=
s
>>> going on, questions inserted:
>>>
>>> Responses are inserted.
>>>
>>>
>>> FWIW: having paragraphs start with the step number (1), (2) etc. would
>>> make it easier to map between the description and the diagram.
>>>
>>> On Thu, Jul 9, 2020 at 3:26 AM Denis  wrote:
>>>
>>>> This is a new thread.
>>>>
>>>> Preamble: This model is quite different from the XAuth model.
>>>> In particular, a RO has no relationship with any AS and a Client does
>>>> not need to be associated with any AS prior to any access to a RS.
>>>>
>>>> A key point of this model is that the user's consent is handled locall=
y
>>>> by the Client and hence no AS nor RS is handling a man machine interfa=
ce
>>>> for the user consent. This allows to support locally the user consent
>>>> for multiple ASs while keeping all ASs ignorant about the choices of t=
he
>>>> user
>>>> made for accessing a particular RS.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *       +--------+                           +------------+        |
>>>> User  |                           |  Resource  |        |
>>>> |                           | Owner (RO) |        +--------+
>>>>                   +------------+            |
>>>> \                              |            |
>>>> \                             |            |
>>>> \                            |            |
>>>> \                           |     +-----------+     +---------------+
>>>> +------------+     |           |---->| Authorization |     |          =
  |
>>>>     |           | (2) |  Server (AS)  |     |            |     |
>>>> |<----|               |     |            |     |  Client   |
>>>> +---------------+     |            |     |
>>>> |-------------------------->|  Resource  |     |   User    |
>>>> (1)             |   Server   |     |  Consent
>>>> |<--------------------------|    (RS)    |     |  element
>>>> |                           |            |     |
>>>> |-------------------------->|            |------>     |
>>>> |           (3)             |            |  (4)     |
>>>> |<--------------------------|            |<------
>>>> +-----------+                           +------------+ *
>>>> The flow of operations is as follows:
>>>>
>>>> The Client (which may have been previously authenticated using FIDO)
>>>>
>>> Which party has the client authenticated to? The client authenticating
>>> with FIDO is confusing to me. FIDO is usually how a user authenticates.
>>>
>>> If the user has previously opened a user account with the RS using FIDO=
,
>>> then the client may be authenticated by the RS using FIDO.
>>> In such a case, the user is already known to the RS under a pseudonym
>>> specific to the RS. It may (or may not) have previously presented acces=
s
>>> tokens
>>> to that RS.
>>>
>>>  contacts the RS and after some dialogue with the RS selects an
>>> operation
>>> How does the client know which RS to contact?
>>>
>>> For a private usage, the user may use DuckDuckGo, while for business he
>>> may use an application from his company which lists various services
>>> available in the context of his job or his position. Some services may
>>> be freely available to all the employees of the company with any
>>> authentication,
>>> e.g. the phone book of the employees may be freely available on the
>>> intranet of the company, while some other services may require the user
>>> to authenticate to the AS from the company.
>>>
>>>  that it wants to perform on the RS (1a). Note that it may also
>>> indicate directly the operation that it wants to perform on the RS with=
out
>>> any prior dialogue.
>>>
>>>> In return (1b), the RS informs the Client about which attributes are
>>>> needed by the RS for performing the requested operation and from which
>>>> Attributes Servers
>>>> they may be obtained.
>>>>
>>> (1a) and (1b) are not labeled. There is only (1)
>>>
>>> (1a) is the first exchange for (1) with the arrow from left to right,
>>> while (1b) is the response with the arrow from right to left.
>>> The same applies to the other exchanges i.e. (2) , (3) and (4).
>>>
>>>
>>>> This information is specifically marked to indicate that it shall be
>>>> handled by the "User Consent element" from the Client.
>>>>
>>> Why? What is the significance of this? Which information is marked?
>>>
>>> In the response, a specific identifier or a magic number is used to
>>> indicate the start and the length of the information block
>>> to be sent to the "User Consent element" supported by the Client.
>>>
>>> The presentation of that information is up to the man machine interface
>>> supported by the "User Consent element" from the Client.
>>>
>>> Which information?
>>>
>>> The attributes that are needed by the RS for performing a requested
>>> operation and from which Attributes Servers they may be obtained.
>>>
>>>
>>>> The user can see which attributes are requested by the RS for
>>>> performing the requested operation and, if it consents, the Client con=
tacts
>>>> one or more
>>>> appropriate Authorization Servers (2a).
>>>>
>>> How does the client know which AS(s) to contact?
>>>
>>> For each AS trusted by the RS to perfom a given operation, the RS shoul=
d
>>> indicate a user-friendly name and a URL of the AS.
>>>
>>> The user consent is hence captured locally by the Client (i.e. there is
>>>> no dialogue with any AS nor any RS).
>>>>
>>>
>>> No dialogue with who? The client is calling the AS is it not?
>>>
>>> For the user consent, there is no external call since it is handled
>>> locally. Afterwards, there is a call to the AS(s) selected by the user.
>>>
>>>
>>>> When the Client got the access tokens from these authorization servers
>>>> (2b), it sends all of them in a single request to the RS (3a).
>>>>
>>>
>>> So the RS must trust the AS that issued the tokens. And the AS must
>>> trust the Client to have gathered consent.
>>>
>>> Theses two assertions are correct.
>>>
>>> And the AS must have a relationship with the user.
>>>
>>> Only when the user chooses one AS while giving its consent, then the
>>> user must have a relationship with the selected AS.
>>>
>>> It is unclear what role the RO is playing in this though. The RO and RS
>>> look to be the same entity from all the other parties.
>>>
>>> A RO, as indicated on the figure, has only a relationship with one RS:
>>> it has no relationship with any AS.
>>> The RS trusts the AS but the AS does not know which RSs are trusting it=
.
>>>
>>>
>>> From my current understanding, at a high level, this looks like it is
>>> supported by GNAP with the addition of the discovery step (1).
>>>
>>> Well, it is fairly different :
>>>
>>> 1) The first major difference is that there is no arrow between the RO
>>> and the AS. No protocol or "out-of-bands" means are necessary.
>>>
>>> 2) The second major difference is that there is no arrow between the AS
>>> and the RS. No protocol is necessary.
>>>
>>> 3) The third major difference is that the AS does not know any RS. Note=
:
>>> for backward compatibility reasons, an exception might exist for "old" =
Auth
>>> 2.0 ASs.
>>>
>>> 4) The fourth major difference is that the XAuth spec. is rather vague
>>> to describe when and by who the user consent is captured:
>>>     XAuth states on page 4: "User consent is *often *required at the
>>> GS". In that case, the GS is able to act as Big Brother. No other case =
is
>>> described.
>>> 5) The fifth major difference is that the data that is transferred to a
>>> "User Consent Element" to capture the user consent. That data can be
>>> standardized.
>>>     Moreover, it will also be possible to standardize the dialogue
>>> between the RO and the RS. The RO will then be able to manage remotely =
the
>>> authorization tables.
>>>     See my email sent on June 6, with the following subject: "Support o=
f
>>> FIDO and data minimization by RSs".
>>>
>>> 6) Another difference is the following: since there is no interaction
>>> between the RO and the AS, "authorizations from the RO" as described in
>>> XAuth do not exist.
>>>
>>> There have been a number of proposals for doing this discovery, and
>>> perhaps now there are enough use cases to look at standardizing somethi=
ng.
>>> No interaction is needed between the AS and the User as the Client is
>>> providing enough "information" in the user object of the Grant Request
>>> to satisfy the AS releasing the access tokens.
>>>
>>> Not sure I understand correctly this last sentence.
>>>
>>>
>>> Perhaps as I understand the model in more detail I will understand what
>>> is missing from GNAP (besides the discovery step).
>>>
>>> It would be hard to say "what is missing" from XAuth since the
>>> foundations are not the same.
>>>
>>> In order to compare different architectures, there is the need to start
>>> with the trust relationships.
>>> Unfortunately, the word "trust" is absent in the main body of
>>> draft-hardt-xauth-protocol-12. Hence,
>>> the description of the trust relationships is missing.
>>>
>>> Denis
>>>
>>>
>>> /Dick
>>>
>>> (I've skipped reviewing the delegation use case below until I understan=
d
>>> the simple use case)
>>>
>>>
>>>> End of the story for a simple access
>>>>
>>>>
>>>> Start of a subsequent story for a delegation case
>>>>
>>>> Let us now suppose that the RS is unable to fulfil the request by its
>>>> own and that it needs to contact another RS. RS1 contacts RS2 (4a) and
>>>> indicates the operation
>>>> that it wants to perform on RS2 (that operation may not be the same as
>>>> the original operation). In return (4b), RS2 informs RS1 about which
>>>> attributes are needed
>>>> by RS2 for performing the requested operation and from which Attribute=
s
>>>> Servers they may be obtained. RS1 forwards that information to the Cli=
ent.
>>>>
>>>> This information is marked to indicate that it shall be handled by the
>>>> "User Consent element" from the Client. The presentation of that
>>>> information is up to the man machine
>>>> interface from the Client. The user can see which attributes are
>>>> requested by RS2 for performing the new requested operation and, if it
>>>> consents, the Client contacts one or more
>>>> appropriate Authorization Servers. The user consent is hence captured
>>>> locally by the "User Consent element" from the Client. (i.e. there is =
no
>>>> dialogue with any AS, nor RS1, nor RS2).
>>>>
>>>> When the Client got the access token(s) from the authorization
>>>> server(s), it sends all of them in a single request to RS1. RS1 then
>>>> forwards the additional access token(s) to RS2.
>>>>
>>>>
>>>> Some observations:
>>>>
>>>> The user nor the Client are linked with any particular AS. A user may
>>>> use today an AS of the Bank of America and may change tomorrow to the =
Bank
>>>> of Missouri.
>>>> As soon as he will be registered with the Bank of Missouri, he will be
>>>> able to get access tokens from the AS of the Bank of Missouri. The AS =
of
>>>> Bank of America
>>>> has not been able to know where its access tokens have been used. This
>>>> will be the same for AS of the Bank of Missouri. There is no need for =
any
>>>> direct dialogue
>>>> between any AS and any RS at the time a client is making an access.
>>>> There is no need for any RO to contact any AS.
>>>>
>>>> This model has been constructed following a "Privacy by Design"
>>>> approach.
>>>> Denis
>>>>
>>>> --
>>>> Txauth mailing list
>>>> Txauth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>> =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
>
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000a000ee05aa57c60f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I get that the Client<=
;->RS step is critical to the use case, as is the User not interacting w=
ith the GS, but there are other use cases where the User does not interact =
with the GS, for example=C2=A0https://tools.ietf.org/html/draft-hard=
t-xauth-protocol-11#section-2.3., but Denis's use case should not b=
e the only use case.=C2=A0

So it seems that GNAP can sup=
port Denis's use case by=C2=A0defining the initial=C2=A0Client<->=
RS interaction, and the=C2=A0information in the user object of the Grant Re=
quest to be what the GS needs to issue access tokens, which was what I sugg=
ested earlier.

I don't understand what is miss=
ing, besides the details of the Client<->RS interaction, and what is =
in the Grant Request.


=

On Mon, Ju=
l 13, 2020 at 12:22 PM Denis <deni=
s.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hi Justin,

    


    

    
You have perfectly understood the
      differences. The location where the user consent is gathered i=
n
        a uniform way using to the information released by the RS 

      is a fundamental element of the design.=C2=A0 

    

    

    

     =20
      If I=E2=80=99m understanding Denis=E2=80=99s proposal, he=E2=80=99s s=
aying that that
      =E2=80=9Cprior step=E2=80=9D is the lynchpin of the whole model, sinc=
e interaction
      between the client and the RS (and the user and the RS) is key to
      Denis=E2=80=99s privacy model. Additionally, what happens *at* each s=
tep
      is different. Consent is gathered at the client, not the GS in
      this diagram, for example. The GS simply mints a token as
      specified by the client and the RS.
      


      

      
It=E2=80=99s for these reasons that, as long as I=E2=80=99ve bee=
n
        understanding correctly, I=E2=80=99ve been saying that Denis=E2=80=
=99s model as
        proposed is pretty different. 

    

    
Indeed.

    
Denis

    

    

      
But what I think isn=E2=80=99t that different is the
        different steps if you=E2=80=99re willing to look at the boundaries
        around the boxes differently. For example, what OAuth would call
        =E2=80=9Cthe AS=E2=80=9D might end up being a few different boxes i=
n GNAP that
        do different things. I had started down that route with XYZ=E2=80=
=99s
        design allowing the interaction to be managed separately.=C2=A0
      


      

      
I think that the disconnect we=E2=80=99re seeing here might
        be caused by vocabulary mismatches. If we aren=E2=80=99t meaning th=
e
        same thing when we say the same terms, it=E2=80=99s easy to get thi=
ngs
        mixed up with each other. Since GNAP is just barely forming its
        vocabulary out of the legacy of OAuth and kin, we have a chance
        to maybe draw the lines better and see if that=E2=80=99s how we can=
 get
        things to fit.

        


        

        
=C2=A0=E2=80=94 Justin

          


            

              
On Jul 13, 2020, at 2:02 PM, Dick Hardt <dick.hardt@gmail.com>
                wrote:

              

              

               =20
                


                  
I'm going to just address the first part
                    of your response so that we can get clarity on that
                    before diving into your later comments.

                  


                  

                  
The calls between your proposal and
                    XAuth are not inverted, your proposal has a prior
                    step. Step 1 in XAuth maps to Step 2 in your
                    proposal, and Step 2 in XAuth is Step 3 in your
                    proposal..

                  


                  

                  
Below are 2 diagrams showing the same
                    steps, the first keeping the existing step labels
                    for XAuth, the latter renaming the steps to
                    correspond to your proposal. This looks pretty
                    similar to your diagram. What am I missing?

                  


                  

                  
/Dick

                  


                  

                  

                    
DIAGRAM 1 (steps start =
at 0)

                    
       +--------+      =
                     +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (0)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+

                    

                    

                    
DIAGRAM 2 (steps start =
at 1)

                    
       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (2) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (3)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (1)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+

                  

                

                
=E1=90=A7

                

                

                  
On Mon, Jul 13, 202=
0
                    at 7:08 AM Denis <denis.ietf@free.fr>
                    wrote:

                  

                  

                    

                      
Hello Dick,

                      


                      

                      
You wrote: "This looks pretty
                        similar to your protocol drawing".

                        

                      

                      
No. There is a fundamental
                        difference with the sequencing of the flow of
                        the exchanges where the (1) and (2) flows are
                        inverted. 

                      

                      


                      

                      
In your figure:

                      

                      

                        

                          
The Client makes calls to the GS
                            (1)

                          
The Client makes calls to the RS
                            (2)

                        

                        
while in my figure:

                        

                          

                            
The Client makes calls to the
                              RS (1)

                            
The Client makes calls to the
                              AS (2)

                          

                        

                      

                      
In your figure, the first flow is
                        with the GS, whereas in my figure the first flow
                        is with the RS and there is a good reason for
                        that: 

                        the client first contacts the RS to know what
                        the RS expects. The client indicates in its
                        first exchange to the RS whether it wants to
                        authenticate 

                        or to perform another operation.=C2=A0 In the case =
of
                        an authentication operation, the RS may respond
                        to the client that is supports FIDO U2F 

                        or that it is willing the client to present some
                        attribute(s) from one or more AS.

                      


                      

                      
Then after the client has to figure
                        out whether the user is using FIDO and if not
                        whether the user has an account with one of the
                        AS.

                      
In the later case, if there is a
                        match then the client, *after having
                          received the user consent*, may contact
                        the appropriate AS to ask 

                        for some attribute(s). 

                      

                      


                      

                      
The same fundamental difference
                        applies with draft-richer-transactional-authz-06
                        (XYZ) where the first exchange is done with the
                        AS:

                      
"The RC creates a transaction
                        request and sends it to the AS".

                      


                      

                      
This answers also in details to one
                        of your comments:

                      

                        

                          
What looks to be missing from
                            your proposal is:

                          
A) The Client making a call to
                            the RS to discover what it needs from a GS,
                            and which GS to ask, prior to (1).

                        

                      

                      
This is not missing since this is
                        the foundation of the architecture. The
                        discovery mechanism at the RS has been described
                        

                        in details in an earlier email with the
                        following title: "Support of FIDO and data
                        minimization by RSs".

                      


                      

                      
The main figures are copied below
                        (using ASCII):
                        
<=
b>=C2=A0 +---------------------=
--------------+---------------------------------+

                                =C2=A0 +=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                Operation=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                +=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 Mathematical
                                expression=C2=A0=C2=A0=C2=A0 +=


                                =C2=A0 +----------------------=
-------------+---------------------------------+

                                =C2=A0 +
                                Authentication=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
                                + Condition 1 OR Condition 2=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +

                                =C2=A0 +----------------------=
-------------+---------------------------------+

                                =C2=A0 + Operation A
                                OR Operation Z=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 +
                                Condition 3 AND Condition 4=C2=A0=C2=
=A0=C2=A0=C2=A0 +

                                =C2=A0 +----------------------=
-------------+---------------------------------+

                                

                              Conditions table: 

                                

                                =C2=A0 +-------------+--------=
------+-----------------------------+----------+

                                =C2=A0 + Condition 1 +
                                FIDO U2F 1.2 +=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                +=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 +

                                =C2=A0 +-------------+--------=
------+-----------------------------+----------+

                                =C2=A0 + Condition 2 +
                                AS 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 +
                                set 1 of a attributes types + =C2=A0<=
/span>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=
=A0+

                                =C2=A0 +-------------+--------=
------+-----------------------------+----------+

                                =C2=A0 + Condition 3 +
                                AS 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 +
                                set 2 of a attributes types + Scope 21 +
                                =C2=A0 +-------------+--------=
------+-----------------------------+----------+

                                =C2=A0 + Condition 4 +
                                AS 9=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 +
                                set 3 of a attributes types-+ =C2=A0<=
/span>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=
=A0+

                                =C2=A0 +-------------+--------=
------+-----------------------------+----------+

                            

                          According to the operation announced by the
                          Client, the RS returns to the Client both the
                          mathematical expression 

                          associated with that operation and the
                          conditions included in that mathematical
                          expression. The Client may then 

                          present that information to the user in order
                          to obtain the user consent in a standardized
                          manner.

                        

                      

                      
Another comment you made is:

                      

                        
What looks to be missing from your
                          proposal is:

                        
B) A mechanism for the Client to
                          prove to the GS that it has gathered consent
                          from the User.

                      

                      
The user consent should not be
                        captured *by the GS*, since the GS would be in a
                        position to apply a different consent decision 

                        without letting it know to the user (or to the
                        client).

                      


                        The user consent must be captured *by the
                        Client* and the Client must be able to verify
                        that this consent has indeed been followed by
                        the AS. 

                      

                      


                      

                      
The authorization data managed at
                        the RS by the RO is used by the Client to query
                        the consent of the user in a standardized
                        manner.

                      
When, later on, the access token is
                        returned to the Client by the AS, the Client
                        (not the user) using that authorization data as
                        well as 

                        the decision of the user is able to verify that
                        the requested attributes (and no more) are
                        indeed present into the access token. 

                        

                        This is why access tokens may *not* be
                        considered to be opaque to the Clients.

                      


                      

                      
In my earlier email copied below,
                        six major differences with XAuth from 1) to 6)
                        are listed.

                      


                      

                      
Denis

                        

                      

                      

                        
From=C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1
                          


                            

                              
1.1.  Parties


   The parties and their relationships to each other:


                              
       +--------+      =
                     +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+



                            

                            

                              


                              

                              
The lines without arrows
                                represent relationships.=C2=A0

                            

                          

                          
The User trusts the Client

                          
The User trusts the GS

                          
The RO trusts the GS to issue
                            access tokens for the RS

                          
The RS trusts the tokens issued
                            by the RS

                          
The RO controls the RS

                          


                          

                          
The Client makes calls to the GS
                            (1)

                          
The Client makes calls to the RS
                            (2)

                          


                          

                          
This looks pretty similar to
                            your protocol drawing.

                          


                          

                          
What looks to be missing from
                            your proposal is:

                          


                          

                          
A) The Client making a call to
                            the RS to discover what it needs from a GS,
                            and which GS to ask, prior to (1).

                          
B) A mechanism for the Client to
                            prove to the GS that it has gathered consent
                            from the User.

                          


                          

                          
The current protocol does not
                            require the GS to interact with either the
                            User, the RO, or the RS -- which looks to me
                            to meet your privacy=C2=A0goals.

                          


                          

                        

                        
3D""=E1=90=A7

                        

                        

                          
On Fri, Jul
                            10, 2020 at 6:06 AM Denis <denis.ietf@free.fr>
                            wrote:

                          

                          

                            

                              
Hi Dick,

                              


                              

                              

                                

                                  
Hi Denis,
                                    thanks for sharing the model. I
                                    don't fully understand what is goin=
g
                                    on, questions inserted:

                                

                              

                              Responses are inserted.

                              

                                

                                  

                                    


                                    

                                    
FWIW: having
                                      paragraphs start with the step
                                      number (1), (2) etc. would make it
                                      easier to map between the
                                      description and the diagram.

                                  

                                  

                                  

                                    
O=
n
                                      Thu, Jul 9, 2020 at 3:26 AM Denis
                                      <denis.ietf@free.fr>
                                      wrote:

                                    

                                    

                                      

                                        

                                          
This is a=
 new
                                              thread.

                                              

                                              Preamble: This model is
                                              quite different from the
                                              XAuth model. 

                                              In particular, a RO has no
                                              relationship with any AS
                                              and a Client does not need
                                              to be associated with any
                                              AS prior to any access to
                                              a RS.

                                              

                                              A key point of this model
                                              is that the user's consen=
t
                                              is handled locally by the
                                              Client and hence no AS nor
                                              RS is handling a man
                                              machine interface 

                                              for the user consent. This
                                              allows to support locally
                                              the user consent for
                                              multiple ASs while keeping
                                              all ASs ignorant about the
                                              choices of the user 

                                              made for accessing a
                                              particular 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=C2=A0
                                                  +------------+

                                                  =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
                                                  |=C2=A0
                                                  User=C2=A0 <=
/span>|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=
=A0 |

                                                  =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
                                                  |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  | Owner (RO) |

                                                  =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
                                                  +--------+=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0+------------+

                                                  =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0
                                                  \=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
                                                  |

                                                  =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  \=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                                                  |

                                                  =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  \=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
                                                  |

                                                  =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  \=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |

                                                  =C2=A0=C2=A0=C2=A0 =
+-----------+=C2=A0 =C2=A0=C2=A0=C2=A0+---=
------------+=C2=A0=C2=A0=C2=A0=C2=A0 +------------+

                                                  =C2=A0=C2=A0=C2=A0 =
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |---->|
                                                  Authorization |=C2=
=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |

                                                  =C2=A0=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) |=C2=
=A0 Server
                                                  (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=C2=A0=C2=A0=C2=A0=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 <=
/span>|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0
                                                  |

                                                  =C2=A0=C2=A0=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  (1)=C2=A0=C2=
=A0=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=C2=A0 =
|=C2=A0 Consent=C2=A0 |<---------------=
-----------|=C2=A0=C2=A0=C2=A0 (RS)=C2=A0=C2=A0=C2=A0 |

                                                  =C2=A0=C2=A0=C2=A0 =
|=C2=A0 element=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |

                                                  =C2=A0=C2=A0=C2=A0 =
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |-----------------=
--------->|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
                                                  |------>

                                                  =C2=A0=C2=A0=C2=A0 =
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |=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 =
|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                  |<-------------=
-------------|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
                                                  |<------

                                                  =C2=A0=C2=A0=C2=A0 =
+-----------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 flow of operations is
                                              as follows:

                                              

                                              The Client (which may have
                                              been previously
                                              authenticated using FIDO)
                                            

                                        

                                      

                                    

                                    
Which party has the
                                      client authenticated to? The
                                      client authenticating with FIDO is
                                      confusing to me. FIDO is usually
                                      how a user authenticates.

                                  

                                

                              

                              
If the user has previously
                                opened a user account with the RS using
                                FIDO, then the client may be
                                authenticated by the RS using FIDO.

                                In such a case, the user is already
                                known to the RS under a pseudonym
                                specific to the RS. It may (or may not)
                                have previously presented access tokens
                                

                                to that RS.

                              

                              

                                

                                  

                                    
=C2=A0contact=
s the RS and
                                        after some dialogue with the RS
                                        selects an operation 

                                      

                                    
How does the client
                                      know which RS to contact?

                                  

                                

                              

                              
For a private usage, the user
                                may use DuckDuckGo, while for business
                                he may use an application from his
                                company which lists various services 

                                available in the context of his job or
                                his position. Some services may be
                                freely available to all the employees of
                                the company with any authentication,

                                e.g. the phone book of the employees may
                                be freely available on the intranet of
                                the company, while some other services
                                may require the user 

                                to authenticate to the AS from the
                                company.

                              

                                

                                  

                                    
=C2=A0that it=
 wants to
                                        perform on the RS (1a). Note
                                        that it may also indicate
                                        directly the operation that it
                                        wants to perform on the RS
                                        without any prior dialogue. =


                                      

                                    

                                      

                                        

                                          
 In retur=
n
                                              (1b), the RS informs the
                                              Client about which
                                              attributes are needed by
                                              the RS for performing the
                                              requested operation and
                                              from which Attributes
                                              Servers 

                                              they may be obtained. 

                                            

                                        

                                      

                                    

                                    
(1a) and (1b) are not
                                      labeled. There is only (1) 

                                    

                                  

                                

                              

                              
(1a) is the first exchange for
                                (1) with the arrow from left to right,
                                while (1b) is the response with the
                                arrow from right to left. 

                                The same applies to the other exchanges
                                i.e. (2) , (3) and (4).

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
 

                                              This information is
                                              specifically marked to
                                              indicate that it shall be
                                              handled by the "User
                                              Consent element" from th=
e
                                              Client. 

                                            

                                        

                                      

                                    

                                    
Why? What is the
                                      significance of this? Which
                                      information is marked?

                                  

                                

                              

                              
In the response, a specific
                                identifier or a magic number is used to
                                indicate the start and the length of the
                                information block=C2=A0 

                                to be sent to the &quo=
t;User Consent element"
                                  supported by the Client.

                              

                              

                                

                                  

                                    

                                      
The presentat=
ion
                                          of that information is up to
                                          the man machine interface
                                          supported by the "User Conse=
nt
                                          element" from the Client. 
                                        

                                    

                                    


                                    

                                    
Which information? 

                                    

                                  

                                

                              

                              
The
                                  attributes that are needed by the RS
                                  for performing a requested operation
                                  and from which Attributes Servers they
                                  may be obtained.

                              

                                

                                  

                                    

                                      

                                        

                                          
 

                                              The user can see which
                                              attributes are requested
                                              by the RS for performing
                                              the requested operation
                                              and, if it consents, the
                                              Client contacts one or
                                              more 

                                              appropriate Authorization
                                              Servers (2a). 

                                        

                                      

                                    

                                    
How does the client
                                      know which AS(s) to contact?

                                  

                                

                              

                              
For each AS trusted by the RS
                                to perfom a given operation, the RS
                                should indicate a user-friendly name and
                                a URL of the AS. 

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
The user
                                              consent is hence captured
                                              locally by the Client
                                              (i.e. there is no dialogue
                                              with any AS nor any RS).

                                            

                                        

                                      

                                    

                                    


                                    

                                    
No dialogue with who?
                                      The client is calling the AS is it
                                      not? 

                                    

                                  

                                

                              

                              
For the user consent, there is
                                no external call since it is handled
                                locally. Afterwards, there is a call to
                                the AS(s) selected by the user.

                              

                                

                                  

                                    

                                      

                                        

                                          
 

                                              When the Client got the
                                              access tokens from these
                                              authorization servers
                                              (2b), it sends all of them
                                              in a single request to the
                                              RS (3a).

                                            

                                        

                                      

                                    

                                    


                                    

                                    
So the RS must trust
                                      the AS that issued the tokens. And
                                      the AS must trust the Client to
                                      have gathered consent.

                                  

                                

                              

                              Theses two assertions are correct.

                              

                                

                                  

                                    
 And the AS must have
                                      a relationship with the user. 

                                  

                                

                              

                              
Only when the user chooses one
                                AS while giving its consent, then the
                                user must have a relationship with the
                                selected AS.

                              

                                

                                  

                                    
It is unclear what
                                      role the RO is playing in this
                                      though. The RO and RS look to be
                                      the same entity from all the other
                                      parties.

                                  

                                

                              

                              
A RO, as indicated on the
                                figure, has only a relationship with one
                                RS: it has no relationship with any AS.
                                

                                The RS trusts the AS but the AS does not
                                know which RSs are trusting it.

                              

                                

                                  

                                    


                                    

                                    
From my current
                                      understanding, at a high level,
                                      this looks like it is supported by
                                      GNAP with the addition of the
                                      discovery step (1). 

                                  

                                

                              

                              
Well, it is fairly different :
                                

                              

                              

                                
1) The first major
                                  difference is that there is no arrow
                                  between the RO and the AS. No protocol
                                  or "out-of-bands" means are nec=
essary.
                                  

                                

                                
2) The second major
                                  difference is that there is no arrow
                                  between the AS and the RS. No protocol
                                  is necessary. 

                                
3) The third major
                                  difference is that the AS does not
                                  know any RS. Note: for backward
                                  compatibility reasons, an exception
                                  might exist for "old" Auth 2.0 =
ASs.

                                

                                
4) The fourth major
                                  difference is that the XAuth spec. is
                                  rather vague to describe when and by
                                  who the user consent is captured: 

                                  =C2=A0=C2=A0=C2=A0 XAuth states on page 4=
: "User
                                  consent is often required
                                  at the GS". In that case, the GS is
                                  able to act as Big Brother. No other
                                  case is described.

                                

                                5) The fifth major difference is that
                                the data that is transferred to a "Use=
r
                                Consent Element" to capture the user
                                consent. That data can be standardized.
                                

                                =C2=A0=C2=A0=C2=A0 Moreover, it will also b=
e possible
                                to standardize the dialogue between the
                                RO and the RS. The RO will then be able
                                to manage remotely the authorization
                                tables.

                                =C2=A0=C2=A0=C2=A0 See my email sent on Jun=
e 6, with
                                the following subject: "Support of FID=
O
                                and data minimization by RSs".

                                

                                6) Another difference is the following:
                                since there is no interaction between
                                the RO and the AS, "authorizations fro=
m
                                the RO" as described in XAuth do not
                                exist. =C2=A0 

                              

                                

                                  

                                    
There have been a
                                      number of proposals for doing this
                                      discovery, and perhaps now there
                                      are enough use cases to look at
                                      standardizing something.=C2=A0 

                                      No interaction=C2=A0is needed between
                                      the AS and the User as the Client
                                      is providing enough "information=
"
                                      in the user object of the Grant
                                      Request 

                                      to satisfy the AS releasing the
                                      access tokens. 

                                    

                                  

                                

                              

                              Not sure I understand correctly this last
                              sentence.

                              

                                

                                  

                                    


                                    

                                    
Perhaps as I
                                      understand the model in more
                                      detail I will understand what is
                                      missing from GNAP (besides the
                                      discovery step).

                                  

                                

                              

                              
It would be hard to say "what
                                is missing" from XAuth since the
                                foundations are not the same.

                              
In order to compare different
                                architectures, there is the need to
                                start with the trust relationships. 

                                Unfortunately, the word "trust" i=
s
                                absent in the main body of
                                draft-hardt-xauth-protocol-12. Hence, 

                                the description of the trust
                                relationships is missing.

                              

                              
Denis

                              

                                

                                  

                                    


                                    

                                    
/Dick

                                    


                                    

                                    
(I've skipped
                                      reviewing the delegation use case
                                      below until I understand the
                                      simple use case)

                                    


                                    

                                    

                                      

                                        

                                          
 

                                              End of the story for a
                                              simple access

                                          
 

                                              Start of a subsequent
                                              story for a delegation
                                              case

                                              

                                              Let us now suppose that
                                              the RS is unable to fulfil
                                              the request by its own and
                                              that it needs to contact
                                              another RS. RS1 contacts
                                              RS2 (4a)
                                              and indicates the
                                              operation 

                                              that it wants to perform
                                              on RS2 (that operation may
                                              not be the same as the
                                              original operation). In
                                              return (4b), RS2 informs
                                              RS1 about which attributes
                                              are needed 

                                              by RS2 for performing the
                                              requested operation and
                                              from which Attributes
                                              Servers they may be
                                              obtained. RS1 forwards
                                              that information to the
                                              Client. 

                                              

                                              This information is marked
                                              to indicate that it shall
                                              be handled by the "User
                                              Consent element" from th=
e
                                              Client. The presentation
                                              of that information is up
                                              to the man machine 

                                              interface from the Client.
                                              The user can see which
                                              attributes are requested
                                              by RS2 for performing the
                                              new requested operation
                                              and, if it consents, the
                                              Client contacts one or
                                              more 

                                              appropriate Authorization
                                              Servers. The user consent
                                              is hence captured locally
                                              by the "User Consent
                                              element" from the Client=
.
                                              (i.e. there is no dialogue
                                              with any AS, nor RS1, nor
                                              RS2). 

                                              

                                              When the Client got the
                                              access token(s) from the
                                              authorization server(s),
                                              it sends all of them in a
                                              single request to RS1. RS1
                                              then forwards the
                                              additional access token(s)
                                              to RS2.

                                              

                                              

                                              Some observations: 

                                              

                                              The user nor the Client
                                              are linked with any
                                              particular AS. A user may
                                              use today an AS of the
                                              Bank of America and may
                                              change tomorrow to the
                                              Bank of Missouri. 

                                              As soon as he will be
                                              registered with the Bank
                                              of Missouri, he will be
                                              able to get access tokens
                                              from the AS of the Bank of
                                              Missouri. The AS of Bank
                                              of America 

                                              has not been able to know
                                              where its access tokens
                                              have been used. This will
                                              be the same for AS of the
                                              Bank of Missouri. There is
                                              no need for any direct
                                              dialogue 

                                              between any AS and any RS
                                              at the time a client is
                                              making an access. There is
                                              no need for any RO to
                                              contact any AS.

                                          
This mode=
l
                                              has been constructed
                                              following a "Privacy by
                                              Design" approach.=


                                          Denis=


                                        

                                      

                                      -- 

                                      Txauth mailing list

                                      Txauth@ietf.org

                                      https://www.ietf.o=
rg/mailman/listinfo/txauth

                                    

                                  

                                

                                
3D""=E1=90=A7

                              

                              


                              

                            

                          

                        

                      

                      


                      

                    

                    -- 

                    Txauth mailing list

                    Tx=
auth@ietf.org

                    https://www.ietf.org/mailman/listinf=
o/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




--000000000000a000ee05aa57c60f--


From nobody Mon Jul 13 12:36:32 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 D25533A0842 for ; Mon, 13 Jul 2020 12:36:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.629
X-Spam-Level: 
X-Spam-Status: No, score=-0.629 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.267, NICE_REPLY_A=-0.001, 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 0HMBCHns5RfF for ; Mon, 13 Jul 2020 12:36:22 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC953A059F for ; Mon, 13 Jul 2020 12:36:20 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d74 with ME id 2jcH2300D4FMSmm03jcJeM; Mon, 13 Jul 2020 21:36:19 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 13 Jul 2020 21:36:19 +0200
X-ME-IP: 86.238.65.197
To: Justin Richer , Dick Hardt 
Cc: txauth@ietf.org
References:  <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu>  <174F2061-3F0F-49B2-A18F-58DF658E4473@mit.edu>  
From: Denis 
Message-ID: <8228eb96-eefe-e391-232e-35daccd0c2fa@free.fr>
Date: Mon, 13 Jul 2020 21:36: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="------------1058B1C07B3B780341D94618"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 13 Jul 2020 19:36:30 -0000

This is a multi-part message in MIME format.
--------------1058B1C07B3B780341D94618
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Justin,

Since the "sub" claim has been "diverted" from it original semantics, we 
will need to define four types of identifiers for a user,whether it is:

    (1) temporarily unique,
    (2) unique to the resource server,
    (3) unique to the authorization server (this was the original
    semantics of the "sub" claim) or
    (4) globally unique (e.g. a distinguished name or an email address).

In terms of privacy, for each of them, the consequences are quite different.

Denis

> I am saying that GNAP, it its definition within this working group, 
> should be limited to identifier claims. Other claims can come from 
> other protocols properly layered on top of GNAP. GNAP shouldn’t stop 
> them from being built, but in my opinion we shouldn’t be defining 
> those here. See the discussion below on the extensibility avenues of 
> this approach.
>
>  — Justin
>
>> On Jul 13, 2020, at 2:12 PM, Dick Hardt > > wrote:
>>
>> I agree that an API to return claims is useful. I think we have 
>> agreed on that.
>>
>> Using the SubjectIdentifiers schema is another schema that would be 
>> useful for GNAP to support.
>>
>> I disagree that GNAP should be limited to identifier claims.
>>
>> ᐧ
>>
>> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer > > wrote:
>>
>>     One thing I think we should learn from OIDC is that returning
>>     claims from an API, and not just an assertion or direct response,
>>     is a powerful and useful pattern. We have an opportunity to
>>     separate these cleanly, where OIDC didn’t have the opportunity in
>>     defining the “claims” request parameter.
>>
>>     As an alternative to the current XYZ and XAuth syntaxes, over the
>>     weekend I’ve been playing with something that would look like
>>     this strawman in the request:
>>
>>
>>         {
>>            subject: {
>>               id: [ “account”, “email”, “iss-sub”],
>>               assertion: [ “odic_id_token”, “verifiable_credential”,
>>         “saml" ]
>>            }
>>         }
>>
>>
>>     This request says that I’d like some subset of these identifiers
>>     (as plain text in the response) and some subset of signed
>>     assertions in the given formats. Each one would have an
>>     associated space in the return. I’m not picturing that the “id”
>>     field values would affect the contents of the assertions: so I
>>     could ask for an email address identifier but get back an ID
>>     token that had only the subject identifier. Maybe that’s not the
>>     right model? But it’s at least simple and deterministic this way,
>>     and it’s something to play with.
>>
>>     Note: The “id” names are taken from
>>     https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.html,
>>     the “assertion” names are made up as I didn’t see a source that
>>     collected them. If you wanted specific bundles of claims about
>>     the user from a UserInfoEndpoint, for example, you’d have
>>     something like:
>>
>>         {
>>            subject: {
>>               id: [ “account”, “email”, “iss-sub”],
>>               assertion: [ “odic_id_token”, “verifiable_credential”,
>>         “saml" ]
>>            },
>>            resources: [{
>>                type: “userinfo”,
>>                datatypes: [ “openid”, “profile”, “phone”, “email” ]
>>           }]
>>         }
>>
>>
>>     This is an example for a specific kind of resource, and I don’t
>>     think that GNAP should define the “userinfo” schema here, or the
>>     datatype values therein. That should be work outside of GNAP,
>>     probably for the OIDF.
>>
>>     This approach is extensible in several ways, each of them for a
>>     specific reason that I think is clear:
>>
>>      - new values in the “id” field to give new identifiers
>>      - new values in the “assertion” field to give new assertion formats
>>      - new fields under the “subject” heading
>>      - new resource types besides “userinfo” (like “scim-v1” or
>>     “facebook-profile” for instance)
>>      - new datatypes within the “userinfo” resource type
>>      - new top-level request parameters
>>
>>     As per the other thread, if you wanted to use the OIDC query
>>     language, you’d package it separately as a top-level request
>>     parameter since it can include both the ID token response and the
>>     access token response and we shouldn’t be encouraging mixing
>>     these things together.
>>
>>      — Justin
>>
>>>     On Jul 10, 2020, at 5:00 PM, Dick Hardt >>     > wrote:
>>>
>>>     It looks to me that our different views of what is in scope for
>>>     GNAP are the differences below.
>>>
>>>     Per the subject line, I'm looking at how the client acquires
>>>     claims about the user. You don't think that is in scope, and
>>>     that a different layer will solve that.
>>>
>>>     I think we should learn from OIDC being on top of OAuth, and
>>>     GNAP should be able return ANY claim, not just identifier
>>>     claims. There are use cases that may be difficult to support if
>>>     we do not have that functionality in scope, such as some of the
>>>     ones I list below, and it seems pretty straightforward to
>>>     support ANY claim if we are supporting identifiers.
>>>
>>>     /Dick
>>>
>>>
>>>     On Fri, Jul 10, 2020 at 1:09 PM Justin Richer >>     > wrote:
>>>
>>>
>>>
>>>>         On Jul 10, 2020, at 2:15 PM, Dick Hardt
>>>>         > wrote:
>>>>
>>>>
>>>>         inline ...
>>>>
>>>>         On Thu, Jul 9, 2020 at 5:44 PM Justin Richer
>>>>         > wrote:
>>>>
>>>>             Yes, the core idea is to not have to parse an assertion
>>>>             to get back the core authentication information, which
>>>>             consists of an identifier (iss/sub pair in OIDC, but
>>>>             could be a number of things). Sometimes the client is
>>>>             going to want the rest of the identity information,
>>>>             but If the user’s logged into the client before, the
>>>>             client has likely cached that info and probably won’t
>>>>             need it, and sending it would be a violation of privacy
>>>>             principles.. The client would want the info pretty much
>>>>             just in these cases:
>>>>
>>>>              1. The client has never seen the user before.
>>>>              2. The user’s information has been updated since the
>>>>             last time the client saw it.
>>>>
>>>>
>>>>         Agreed
>>>>
>>>>
>>>>             Now for case (1), how would the client know if it wants
>>>>             to request the user’s profile info or not, since it
>>>>             doesn’t know who the user is?
>>>>
>>>>
>>>>         But the client could know who the user is. The client may
>>>>         have used a different AS to authenticate the user.
>>>
>>>         In these cases, the client is not going to be requesting
>>>         identity information from the AS to log the user in, so it’s
>>>         not relevant to the use case. The client will have an
>>>         opportunity to push that information to the AS.
>>>
>>>>         The User may have self identified to the client. The client
>>>>         may have a cookie saying who the user was and the user said
>>>>         that was them. While the latter cases are really a strong
>>>>         hint, they are likely right most of the time and can lead
>>>>         to a user experience basde on that hint
>>>
>>>         In these cases, the AS might be able to guess if the client
>>>         has info about the user already, but probably not. And the
>>>         assumptions fall apart if it’s in fact a different user that
>>>         ends up logging in, which is of course possible (the hint
>>>         you gave doesn’t match the identity of the current user
>>>         after the AS validates them). This possibility leads to
>>>         clients always asking for everything every time and the
>>>         server providing everything every time. That’s a pattern I
>>>         think we should avoid in an ultimate solution — but
>>>         ultimately, I don’t think that this kind of protocol
>>>         decision is inside of GNAP.
>>>
>>>>             And the AS won’t know if client is going to want the
>>>>             profile info, since the AS won’t know if the client has
>>>>             the user’s info or not. Sure, the AS might have seen
>>>>             that client and that user combo previously, but it
>>>>             doesn’t know if the client needs an update.
>>>>
>>>>
>>>>         The client can share with the AS the user it knows or
>>>>         thinks it is dealing with, which could let the AS respond
>>>>         if the information was new. This could be the case for an
>>>>         AS that is providing claims, but not authentication, and
>>>>         could happen silently. The user would only interact if the
>>>>         user information had changed, and the client wanted the
>>>>         updated information.
>>>
>>>         See above.
>>>
>>>>
>>>>             And for (2), the client won’t know if the user’s info
>>>>             has been updated or not because it doesn’t know who the
>>>>             user is yet. If the AS can provide some time of updated
>>>>             stamp to the client, the client can pull the new info
>>>>             when it needs it.
>>>>
>>>>
>>>>         See above.
>>>
>>>         See above.
>>>
>>>>
>>>>             If you ignore both of these cases and put all the user
>>>>             information inline with the main request/response, you
>>>>             end up in a situation where the client always requests
>>>>             everything and the server always provides everything,
>>>>             since you can’t be sure you’re not in situation (1) or
>>>>             (2) ahead of time.
>>>>
>>>>
>>>>         See above. There are a number of other states the client
>>>>         could be in.
>>>>
>>>>         For example, the client could be stateless about user
>>>>         information, so it knows it is ALWAYS in state 1.
>>>
>>>         A stateless client would need to fetch appropriate user
>>>         information every time, then. But that’s an optimization for
>>>         a very specific case.
>>>
>>>>
>>>>             This is really what I mean about the two-stage identity
>>>>             protocol.
>>>>
>>>>
>>>>         I know what it is. Per above, GNAP lets us support a wider
>>>>         set of use cases. Why limit ourselves to what OIDC supported?
>>>
>>>         We aren’t limiting the protocol, but instead limiting the
>>>         scope of what we define internal to the GNAP protocol.
>>>         There’s a lot of room for innovation on top of it.
>>>
>>>>             In the first stage, you push the bare minimum of what
>>>>             you need to get the user known to the client. In the
>>>>             second stage, the client uses its access token to call
>>>>             an API to get whatever else it needs to know about the
>>>>             user.
>>>>
>>>>
>>>>         From a privacy perspective in non-enterprise use cases, I
>>>>         think the user should give consent to any updated personal
>>>>         information to a client. In general, the client should not
>>>>         be able to get the latest information about a user whenever
>>>>         it wants.
>>>
>>>         This is about the rights associated with the access token,
>>>         then. And an access token doesn’t have to keep working if
>>>         the AS has a policy that says it won’t. The AS/RS could
>>>         easily decide that a particular access token will only
>>>         return data that hasn’t been changed. Maybe it stops working
>>>         after the data changes, or it just returns old data, or any
>>>         number of things. This is for the AS/RS to decide and this
>>>         is pretty standard interpretation of the token, nothing
>>>         special here because we’re dealing with identity.
>>>
>>>          — Justin
>>>
>>>>         /Dick
>>>>         ᐧ
>>>
>>
>
>


--------------1058B1C07B3B780341D94618
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Justin, 

      

    


      

    
Since the "sub"
        claim has been "diverted" from it original semantics, we will
        need to define four types of identifiers for a user, whether it is:

    

      
 (1)
            temporarily unique, 

          

      
(2) unique to the
            resource server, 

          

      
(3) unique to the
            authorization
            server (this was the original semantics of the "sub" claim)
            or 

            (4) globally unique (e.g. a distinguished name or an email
            address).

          

    

    
In
        terms of privacy, for each of them, the consequences are quite
        different.

      

    


      

    
Denis

      

    

    


    

    

      
      I am saying that GNAP, it its definition within this working
      group, should be limited to identifier claims. Other claims can
      come from other protocols properly layered on top of GNAP. GNAP
      shouldn’t stop them from being built, but in my opinion we
      shouldn’t be defining those here. See the discussion below on the
      extensibility avenues of this approach.
      


      

      
 — Justin

        


          

            
On Jul 13, 2020, at 2:12 PM, Dick Hardt <dick.hardt@gmail.com>
              wrote:

            

            

              
              
I agree that an API to return
                claims is useful. I think we have agreed on that. 
                


                

                
Using the SubjectIdentifiers schema is
                  another schema that would be useful for GNAP to
                  support. 

                


                

                
I disagree that GNAP should be limited to
                  identifier claims. 

                


                

              

              
ᐧ

              

              

                
On Mon, Jul 13, 2020
                  at 7:16 AM Justin Richer <jricher@mit.edu>
                  wrote:

                

                

                  
One
                    thing I think we should learn from OIDC is that
                    returning claims from an API, and not just an
                    assertion or direct response, is a powerful and
                    useful pattern. We have an opportunity to separate
                    these cleanly, where OIDC didn’t have the
                    opportunity in defining the “claims” request
                    parameter.
                    


                    

                    
As an alternative to the current XYZ
                      and XAuth syntaxes, over the weekend I’ve been
                      playing with something that would look like this
                      strawman in the request:

                    


                    

                    


                    

                    

                      
{

                      
   subject: {

                      
      id: [ “account”, “email”,
                        “iss-sub”],

                      
      assertion: [ “odic_id_token”,
                        “verifiable_credential”, “saml" ]

                      
   }

                      
}

                    

                    


                    

                    
This request says that I’d like some
                      subset of these identifiers (as plain text in the
                      response) and some subset of signed assertions in
                      the given formats. Each one would have an
                      associated space in the return. I’m not picturing
                      that the “id” field values would affect the
                      contents of the assertions: so I could ask for an
                      email address identifier but get back an ID token
                      that had only the subject identifier. Maybe that’s
                      not the right model? But it’s at least simple and
                      deterministic this way, and it’s something to play
                      with.

                    


                    

                    
Note: The “id” names are taken from https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.html,
                      the “assertion” names are made up as I didn’t see
                      a source that collected them. If you wanted
                      specific bundles of claims about the user from a
                      UserInfoEndpoint, for example, you’d have
                      something like:

                    


                    

                    

                      

                        
{

                      

                      

                        
   subject: {

                      

                      

                        
      id: [ “account”, “email”,
                          “iss-sub”],

                      

                      

                        
      assertion: [
                          “odic_id_token”, “verifiable_credential”,
                          “saml" ]

                      

                      

                        
   },

                      

                      

                        
   resources: [{

                      

                      

                        
       type: “userinfo”,

                      

                      

                        
       datatypes: [ “openid”,
                          “profile”, “phone”, “email” ]

                      

                      

                        
  }]

                      

                      

                        
}

                      

                    

                    


                    

                    
This is an example for a specific kind
                      of resource, and I don’t think that GNAP should
                      define the “userinfo” schema here, or the datatype
                      values therein. That should be work outside of
                      GNAP, probably for the OIDF.

                    


                    

                    
This approach is extensible in several
                      ways, each of them for a specific reason that I
                      think is clear:

                    


                    

                    
 - new values in the “id” field to
                      give new identifiers

                    
 - new values in the “assertion” field
                      to give new assertion formats

                    
 - new fields under the “subject”
                      heading 

                    
 - new resource types besides
                      “userinfo” (like “scim-v1” or “facebook-profile”
                      for instance)

                    
 - new datatypes within the “userinfo”
                      resource type

                    
 - new top-level request parameters

                    


                    

                    
As per the other thread, if you wanted
                      to use the OIDC query language, you’d package it
                      separately as a top-level request parameter since
                      it can include both the ID token response and the
                      access token response and we shouldn’t be
                      encouraging mixing these things together.

                    


                    

                    
 — Justin

                      


                        

                          
On Jul 10, 2020, at 5:00 PM,
                            Dick Hardt <dick.hardt@gmail.com>
                            wrote:

                          

                          

                            
It looks to me that
                              our different views of what is in scope
                              for GNAP are the differences below.
                              


                              

                              
Per the subject line, I'm
                                looking at how the client acquires
                                claims about the user. You don't think
                                that is in scope, and that a different
                                layer will solve that.

                              


                              

                              
I think we should learn from
                                OIDC being on top of OAuth, and GNAP
                                should be able return ANY claim, not
                                just identifier claims. There are use
                                cases that may be difficult to support
                                if we do not have that functionality in
                                scope, such as some of the ones I list
                                below, and it seems pretty
                                straightforward to support ANY claim if
                                we are supporting identifiers.

                              


                              

                              
/Dick

                              


                              

                            

                            

                            

                              
On Fri,
                                Jul 10, 2020 at 1:09 PM Justin Richer
                                <jricher@mit.edu>
                                wrote:

                              

                              

                                


                                  


                                    

                                      
On Jul 10, 2020, at
                                        2:15 PM, Dick Hardt <dick.hardt@gmail.com>
                                        wrote:

                                      

                                      

                                        

                                          


                                          

                                          inline ... 
                                          


                                            

                                              
On
                                                Thu, Jul 9, 2020 at 5:44
                                                PM Justin Richer <jricher@mit.edu>
                                                wrote:

                                              

                                              

                                                
Yes, the
                                                  core idea is to not
                                                  have to parse an
                                                  assertion to get back
                                                  the core
                                                  authentication
                                                  information, which
                                                  consists of an
                                                  identifier (iss/sub
                                                  pair in OIDC, but
                                                  could be a number of
                                                  things). Sometimes the
                                                  client is going to
                                                  want the rest of the
                                                  identity information,
                                                  but If the user’s
                                                  logged into the client
                                                  before, the client has
                                                  likely cached that
                                                  info and probably
                                                  won’t need it, and
                                                  sending it would be a
                                                  violation of privacy
                                                  principles.. The
                                                  client would want the
                                                  info pretty much just
                                                  in these cases:
                                                  


                                                  

                                                  
 1. The
                                                    client has never
                                                    seen the user
                                                    before. 

                                                  
 2. The
                                                    user’s information
                                                    has been updated
                                                    since the last time
                                                    the client saw it.

                                                

                                              

                                              


                                              

                                              
Agreed

                                              
 

                                              

                                                

                                                  


                                                  

                                                  
Now for
                                                    case (1), how would
                                                    the client know if
                                                    it wants to request
                                                    the user’s profile
                                                    info or not, since
                                                    it doesn’t know who
                                                    the user is? 

                                                

                                              

                                              


                                              

                                              
But the
                                                client could know who
                                                the user is. The client
                                                may have used a
                                                different AS to
                                                authenticate the user. 

                                            

                                          

                                        

                                      

                                    

                                    


                                    

                                    
In these cases, the
                                      client is not going to be
                                      requesting identity information
                                      from the AS to log the user in, so
                                      it’s not relevant to the use case.
                                      The client will have an
                                      opportunity to push that
                                      information to the AS.

                                    

                                    

                                      

                                        

                                          

                                            

                                              
The User may
                                                have self identified to
                                                the client. The client
                                                may have a cookie saying
                                                who the user was and the
                                                user said that was them.
                                                While the latter cases
                                                are really a strong
                                                hint, they are likely
                                                right most of the time
                                                and can lead to a user
                                                experience basde on that
                                                hint

                                            

                                          

                                        

                                      

                                    

                                    


                                    

                                    
In these cases, the AS
                                      might be able to guess if the
                                      client has info about the user
                                      already, but probably not. And the
                                      assumptions fall apart if it’s in
                                      fact a different user that ends up
                                      logging in, which is of course
                                      possible (the hint you gave
                                      doesn’t match the identity of the
                                      current user after the AS
                                      validates them). This possibility
                                      leads to clients always asking for
                                      everything every time and the
                                      server providing everything every
                                      time. That’s a pattern I think we
                                      should avoid in an ultimate
                                      solution — but ultimately, I don’t
                                      think that this kind of protocol
                                      decision is inside of GNAP.

                                    

                                    

                                      

                                        

                                          

                                            

                                              
 

                                              

                                                

                                                  
And the
                                                    AS won’t know if
                                                    client is going to
                                                    want the profile
                                                    info, since the AS
                                                    won’t know if the
                                                    client has the
                                                    user’s info or not.
                                                    Sure, the AS might
                                                    have seen that
                                                    client and that user
                                                    combo previously,
                                                    but it doesn’t know
                                                    if the client needs
                                                    an update.

                                                

                                              

                                              


                                              

                                              
The client
                                                can share with the AS
                                                the user it knows or
                                                thinks it is dealing
                                                with, which could let
                                                the AS respond if the
                                                information was new.
                                                This could be the case
                                                for an AS that is
                                                providing claims, but
                                                not authentication, and
                                                could happen silently.
                                                The user would only
                                                interact if the user
                                                information had changed,
                                                and the client wanted
                                                the updated information.

                                              
 

                                            

                                          

                                        

                                      

                                    

                                    


                                    

                                    
See above.

                                    

                                    

                                      

                                        

                                          

                                            

                                              

                                                

                                                  


                                                  

                                                  
And for
                                                    (2), the client
                                                    won’t know if the
                                                    user’s info has been
                                                    updated or not
                                                    because it doesn’t
                                                    know who the user is
                                                    yet. If the AS can
                                                    provide some time of
                                                    updated stamp to the
                                                    client, the client
                                                    can pull the new
                                                    info when it needs
                                                    it.

                                                

                                              

                                              


                                              

                                              
See above.

                                            

                                          

                                        

                                      

                                    

                                    


                                    

                                    See above.

                                  


                                    

                                      

                                        

                                          

                                            

                                              
 

                                              

                                                

                                                  


                                                  

                                                  
If you
                                                    ignore both of these
                                                    cases and put all
                                                    the user information
                                                    inline with the main
                                                    request/response,
                                                    you end up in a
                                                    situation where the
                                                    client always
                                                    requests everything
                                                    and the server
                                                    always provides
                                                    everything, since
                                                    you can’t be sure
                                                    you’re not in
                                                    situation (1) or (2)
                                                    ahead of time.

                                                

                                              

                                              


                                              

                                              
See above.
                                                There are a number of
                                                other states the client
                                                could be in.

                                              


                                              

                                              
For example,
                                                the client could be
                                                stateless about user
                                                information, so it knows
                                                it is ALWAYS in state 1.

                                            

                                          

                                        

                                      

                                    

                                    


                                    

                                    
A stateless client
                                      would need to fetch appropriate
                                      user information every time, then.
                                      But that’s an optimization for a
                                      very specific case.

                                    

                                    

                                      

                                        

                                          

                                            

                                              
 

                                              

                                                

                                                  


                                                  

                                                  
This is
                                                    really what I mean
                                                    about the two-stage
                                                    identity protocol. 

                                                

                                              

                                              


                                              

                                              
I know what
                                                it is. Per above, GNAP
                                                lets us support a wider
                                                set of use cases. Why
                                                limit ourselves to what
                                                OIDC supported?

                                            

                                          

                                        

                                      

                                    

                                    


                                    

                                    
We aren’t limiting the
                                      protocol, but instead limiting the
                                      scope of what we define internal
                                      to the GNAP protocol. There’s a
                                      lot of room for innovation on top
                                      of it.

                                    

                                    

                                      

                                        

                                          

                                            

                                              
 

                                              

                                                

                                                  
In the
                                                    first stage, you
                                                    push the bare
                                                    minimum of what you
                                                    need to get the user
                                                    known to the client.
                                                    In the second stage,
                                                    the client uses its
                                                    access token to call
                                                    an API to get
                                                    whatever else it
                                                    needs to know about
                                                    the user. 

                                                

                                              

                                              


                                              

                                              
From a
                                                privacy perspective in
                                                non-enterprise use
                                                cases, I think the user
                                                should give consent to
                                                any updated personal
                                                information to a client.
                                                In general, the client
                                                should not be able to
                                                get the latest
                                                information about a user
                                                whenever it wants.

                                            

                                          

                                        

                                      

                                    

                                    


                                    

                                    
This is about the
                                      rights associated with the access
                                      token, then. And an access token
                                      doesn’t have to keep working if
                                      the AS has a policy that says it
                                      won’t. The AS/RS could easily
                                      decide that a particular access
                                      token will only return data that
                                      hasn’t been changed. Maybe it
                                      stops working after the data
                                      changes, or it just returns old
                                      data, or any number of things.
                                      This is for the AS/RS to decide
                                      and this is pretty standard
                                      interpretation of the token,
                                      nothing special here because we’re
                                      dealing with identity.

                                    


                                    

                                    
 — Justin

                                    

                                    

                                      

                                        

                                          

                                            

                                              
 

                                              
/Dick

                                            

                                          

                                        

                                        
ᐧ

                                      

                                    

                                  

                                  

                                

                              

                            

                          

                        

                      

                      

                    

                  

                

              

            

          

        

        

      

      

      

    

    


    

  


--------------1058B1C07B3B780341D94618--


From nobody Mon Jul 13 13:06: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 D35AC3A07E0 for ; Mon, 13 Jul 2020 13:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.628
X-Spam-Level: 
X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_FACE_BAD=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, 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 6ieVSY-3l39I for ; Mon, 13 Jul 2020 13:06:40 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380913A00B3 for ; Mon, 13 Jul 2020 13:06:39 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d74 with ME id 2k6d230014FMSmm03k6dCa; Mon, 13 Jul 2020 22:06:37 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 13 Jul 2020 22:06:37 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt 
Cc: Justin Richer , "txauth@ietf.org" 
References:    <325bc015-1547-c56c-c1fe-67a97165785d@free.fr>  <83480ab0-03bc-7cc9-d166-ece4c6b63861@free.fr>  <83DB69E6-F0ED-41A0-A4DA-B7AE4AB89579@mit.edu> <34dfca59-47f7-63e4-b25f-01648b0bd14b@free.fr> 
From: Denis 
Message-ID: <329996ce-ffa0-9713-b2ff-2a9722a24cf1@free.fr>
Date: Mon, 13 Jul 2020 22:06: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="------------A7002511349A222A2531E6CE"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 13 Jul 2020 20:06:45 -0000

This is a multi-part message in MIME format.
--------------A7002511349A222A2531E6CE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Dick,

You wrote: "I don't understand what is missing". The response is in my 
previous email.
The *user consent* is always requested by the Client and hence it is 
never requested by the GS/AS.

Two other important points:

1° At the first exchange, the RS discloses the elements of an 
authorization table
      that are directly dependent upon the operation that the client is 
willing to perform.

2° I propose a way to integrate FIDO, since FIDO allows to support the 
user's authentication phase
      by disclosing only a pseudonym unique to the RS.

Denis


> I get that the Client<->RS step is critical to the use case, as is the 
> User not interacting with the GS, but there are other use cases where 
> the User does not interact with the GS, for example 
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-2.3., 
> but Denis's use case should not be the only use case.
>
> So it seems that GNAP can support Denis's use case by defining the 
> initial Client<->RS interaction, and the information in the user 
> object of the Grant Request to be what the GS needs to issue access 
> tokens, which was what I suggested earlier.
>
> I don't understand what is missing, besides the details of the 
> Client<->RS interaction, and what is in the Grant Request.
>
>
> On Mon, Jul 13, 2020 at 12:22 PM Denis  > wrote:
>
>     Hi Justin,
>
>     You have perfectly understood the differences. The location where
>     the user consent is gathered /i//n a uniform way/ using to the
>     information released by the RS
>     is a fundamental element of the design.
>
>>     If I’m understanding Denis’s proposal, he’s saying that that
>>     “prior step” is the lynchpin of the whole model, since
>>     interaction between the client and the RS (and the user and the
>>     RS) is key to Denis’s privacy model. Additionally, what happens
>>     *at* each step is different. Consent is gathered at the client,
>>     not the GS in this diagram, for example. The GS simply mints a
>>     token as specified by the client and the RS.
>>
>>     It’s for these reasons that, as long as I’ve been understanding
>>     correctly, I’ve been saying that Denis’s model as proposed is
>>     pretty different.
>
>     Indeed.
>
>     Denis
>
>>     But what I think isn’t that different is the different steps if
>>     you’re willing to look at the boundaries around the boxes
>>     differently. For example, what OAuth would call “the AS” might
>>     end up being a few different boxes in GNAP that do different
>>     things. I had started down that route with XYZ’s design allowing
>>     the interaction to be managed separately.
>>
>>     I think that the disconnect we’re seeing here might be caused by
>>     vocabulary mismatches. If we aren’t meaning the same thing when
>>     we say the same terms, it’s easy to get things mixed up with each
>>     other. Since GNAP is just barely forming its vocabulary out of
>>     the legacy of OAuth and kin, we have a chance to maybe draw the
>>     lines better and see if that’s how we can get things to fit.
>>
>>      — Justin
>>
>>>     On Jul 13, 2020, at 2:02 PM, Dick Hardt >>     > wrote:
>>>
>>>
>>>     I'm going to just address the first part of your response so
>>>     that we can get clarity on that before diving into your later
>>>     comments.
>>>
>>>     The calls between your proposal and XAuth are not inverted, your
>>>     proposal has a prior step. Step 1 in XAuth maps to Step 2 in
>>>     your proposal, and Step 2 in XAuth is Step 3 in your proposal..
>>>
>>>     Below are 2 diagrams showing the same steps, the first keeping
>>>     the existing step labels for XAuth, the latter renaming the
>>>     steps to correspond to your proposal. This looks pretty similar
>>>     to your diagram. What am I missing?
>>>
>>>     /Dick
>>>
>>>     DIAGRAM 1 (steps start at 0)
>>>             +--------+                           +------------+
>>>             |  User  |                           |  Resource  |
>>>             |        |                           | Owner (RO) |
>>>             +--------+                           +------------+
>>>                 |      \                       /      |
>>>                 |       \                     /       |
>>>                 |        \                   /        |
>>>                 |         \                 /         |
>>>             +--------+     +---------------+     +------------+
>>>             | Client |---->|     Grant     |     |  Resource  |
>>>             |        | (1) |  Server (GS)  | _ _ |   Server   |
>>>             |        |<----|               |     |    (RS)    |
>>>             |        |     +---------------+     |            |
>>>             |        |-------------------------->|            |
>>>             |        |           (2)             |            |
>>>             |        |<--------------------------|            |
>>>             |        |-------------------------->|            |
>>>             |        |           (0)             |            |
>>>             |        |<--------------------------|            |
>>>             +--------+                           +------------+
>>>     DIAGRAM 2 (steps start at 1)
>>>             +--------+                           +------------+
>>>             |  User  |                           |  Resource  |
>>>             |        |                           | Owner (RO) |
>>>             +--------+                           +------------+
>>>                 |      \                       /      |
>>>                 |       \                     /       |
>>>                 |        \                   /        |
>>>                 |         \                 /         |
>>>             +--------+     +---------------+     +------------+
>>>             | Client |---->|     Grant     |     |  Resource  |
>>>             |        | (2) |  Server (GS)  | _ _ |   Server   |
>>>             |        |<----|               |     |    (RS)    |
>>>             |        |     +---------------+     |            |
>>>             |        |-------------------------->|            |
>>>             |        |           (3)             |            |
>>>             |        |<--------------------------|            |
>>>             |        |-------------------------->|            |
>>>             |        |           (1)             |            |
>>>             |        |<--------------------------|            |
>>>             +--------+                           +------------+
>>>     ᐧ
>>>
>>>     On Mon, Jul 13, 2020 at 7:08 AM Denis >>     > wrote:
>>>
>>>         Hello Dick,
>>>
>>>         You wrote: "This looks pretty similar to your protocol drawing".
>>>
>>>         No. There is a fundamental difference with the sequencing of
>>>         the flow of the exchanges where the (1) and (2) flows are
>>>         inverted.
>>>
>>>         In your figure:
>>>
>>>             The Client makes calls to the GS (1)
>>>             The Client makes calls to the RS (2)
>>>
>>>         while in my figure:
>>>
>>>             The Client makes calls to the RS (1)
>>>             The Client makes calls to the AS (2)
>>>
>>>         In your figure, the first flow is with the GS, whereas in my
>>>         figure the first flow is with the RS and there is a good
>>>         reason for that:
>>>         the client first contacts the RS to know what the RS
>>>         expects. The client indicates in its first exchange to the
>>>         RS whether it wants to authenticate
>>>         or to perform another operation.  In the case of an
>>>         authentication operation, the RS may respond to the client
>>>         that is supports FIDO U2F
>>>         or that it is willing the client to present some
>>>         attribute(s) from one or more AS.
>>>
>>>         Then after the client has to figure out whether the user is
>>>         using FIDO and if not whether the user has an account with
>>>         one of the AS.
>>>         In the later case, if there is a match then the
>>>         client,/*after having received the user consent*/, may
>>>         contact the appropriate AS to ask
>>>         for some attribute(s).
>>>
>>>         The same fundamental difference applies with
>>>         draft-richer-transactional-authz-06 (XYZ) where the first
>>>         exchange is done with the AS:
>>>         "The RC creates a transaction request and sends it to the AS".
>>>
>>>         This answers also in details to one of your comments:
>>>
>>>             What looks to be missing from your proposal is:
>>>             A) The Client making a call to the RS to discover what
>>>             it needs from a GS, and which GS to ask, prior to (1).
>>>
>>>         This is not missing since this is the foundation of the
>>>         architecture. The discovery mechanism at the RS has been
>>>         described
>>>         in details in an earlier email with the following title:
>>>         "Support of FIDO and data minimization by RSs".
>>>
>>>         The main figures are copied below (using ASCII):**
>>>
>>>         *+-----------------------------------+---------------------------------+
>>>         +Operation+Mathematical expression+
>>>         +-----------------------------------+---------------------------------+
>>>         + Authentication+ Condition 1 OR Condition 2+
>>>         +-----------------------------------+---------------------------------+
>>>         + Operation A OR Operation Z+ Condition 3 AND Condition 4+
>>>         +-----------------------------------+---------------------------------+
>>>
>>>         **Conditions table: **
>>>
>>>         +-------------+--------------+-----------------------------+----------+
>>>         + Condition 1 + FIDO U2F 1.2 +++
>>>         +-------------+--------------+-----------------------------+----------+
>>>         + Condition 2 + AS 1+ set 1 of a attributes types + +
>>>         +-------------+--------------+-----------------------------+----------+
>>>         + Condition 3 + AS 2+ set 2 of a attributes types + Scope 21 +
>>>          
>>>         +-------------+--------------+-----------------------------+----------+
>>>         + Condition 4 + AS 9+ set 3 of a attributes types-+ +
>>>         +-------------+--------------+-----------------------------+----------+
>>>         *
>>>         According to the operation announced by the Client, the RS
>>>         returns to the Client both the mathematical expression
>>>         associated with that operation and the conditions included
>>>         in that mathematical expression. The Client may then
>>>         present that information to the user in order to obtain the
>>>         user consent in a standardized manner.
>>>
>>>         Another comment you made is:
>>>
>>>             What looks to be missing from your proposal is:
>>>             B) A mechanism for the Client to prove to the GS that it
>>>             has gathered consent from the User.
>>>
>>>         The user consent should not be captured *by the GS*, since
>>>         the GS would be in a position to apply a different consent
>>>         decision
>>>         without letting it know to the user (or to the client).
>>>
>>>         The user consent must be captured *by the Client* and the
>>>         Client must be able to verify that this consent has indeed
>>>         been followed by the AS.
>>>
>>>         The authorization data managed at the RS by the RO is used
>>>         by the Client to query the consent of the user in a
>>>         standardized manner.
>>>         When, later on, the access token is returned to the Client
>>>         by the AS, the Client (not the user) using that
>>>         authorization data as well as
>>>         the decision of the user is able to verify that the
>>>         requested attributes (and no more) are indeed present into
>>>         the access token.
>>>
>>>         This is why access tokens may *not* be considered to be
>>>         opaque to the Clients.
>>>
>>>         In my earlier email copied below, six major differences with
>>>         XAuth from 1) to 6) are listed.
>>>
>>>         Denis
>>>
>>>>         From
>>>>         https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1
>>>>
>>>>
>>>>
>>>>               1.1
>>>>               .
>>>>               Parties
>>>>
>>>>
>>>>
>>>>             The parties and their relationships to each other:
>>>>                 +--------+                           +------------+
>>>>                 |  User  |                           |  Resource  |
>>>>                 |        |                           | Owner (RO) |
>>>>                 +--------+                           +------------+
>>>>                     |      \                       /      |
>>>>                     |       \                     /       |
>>>>                     |        \                   /        |
>>>>                     |         \                 /         |
>>>>                 +--------+     +---------------+     +------------+
>>>>                 | Client |---->|     Grant     |     |  Resource  |
>>>>                 |        | (1) |  Server (GS)  | _ _ |   Server   |
>>>>                 |        |<----|               |     |    (RS)    |
>>>>                 |        |     +---------------+     |            |
>>>>                 |        |-------------------------->|            |
>>>>                 |        |           (2)             |            |
>>>>                 |        |<--------------------------|            |
>>>>                 +--------+                           +------------+
>>>>
>>>>
>>>>         The lines without arrows represent relationships.
>>>>         The User trusts the Client
>>>>         The User trusts the GS
>>>>         The RO trusts the GS to issue access tokens for the RS
>>>>         The RS trusts the tokens issued by the RS
>>>>         The RO controls the RS
>>>>
>>>>         The Client makes calls to the GS (1)
>>>>         The Client makes calls to the RS (2)
>>>>
>>>>         This looks pretty similar to your protocol drawing.
>>>>
>>>>         What looks to be missing from your proposal is:
>>>>
>>>>         A) The Client making a call to the RS to discover what it
>>>>         needs from a GS, and which GS to ask, prior to (1).
>>>>         B) A mechanism for the Client to prove to the GS that it
>>>>         has gathered consent from the User.
>>>>
>>>>         The current protocol does not require the GS to interact
>>>>         with either the User, the RO, or the RS -- which looks to
>>>>         me to meet your privacy goals.
>>>>
>>>>         ᐧ
>>>>
>>>>         On Fri, Jul 10, 2020 at 6:06 AM Denis >>>         > wrote:
>>>>
>>>>             Hi Dick,
>>>>
>>>>>             Hi Denis, thanks for sharing the model. I don't fully
>>>>>             understand what is going on, questions inserted:
>>>>             Responses are inserted.
>>>>>
>>>>>             FWIW: having paragraphs start with the step number
>>>>>             (1), (2) etc. would make it easier to map between the
>>>>>             description and the diagram.
>>>>>
>>>>>             On Thu, Jul 9, 2020 at 3:26 AM Denis
>>>>>             > wrote:
>>>>>
>>>>>                 This is a new thread.
>>>>>
>>>>>                 Preamble: This model is quite different from the
>>>>>                 XAuth model.
>>>>>                 In particular, a RO has no relationship with any
>>>>>                 AS and a Client does not need to be associated
>>>>>                 with any AS prior to any access to a RS.
>>>>>
>>>>>                 A key point of this model is that the user's
>>>>>                 consent is handled locally by the Client and hence
>>>>>                 no AS nor RS is handling a man machine interface
>>>>>                 for the user consent. This allows to support
>>>>>                 locally the user consent for multiple ASs while
>>>>>                 keeping all ASs ignorant about the choices of the
>>>>>                 user
>>>>>                 made for accessing a particular RS.
>>>>>                 *
>>>>>
>>>>>                 **+--------++------------+
>>>>>                 |User||Resource|
>>>>>                 ||| Owner (RO) |
>>>>>                 +--------++------------+
>>>>>                 |\|
>>>>>                 |\|
>>>>>                 |\|
>>>>>                 |\|
>>>>>                 +-----------++---------------++------------+
>>>>>                 ||---->| Authorization |||
>>>>>                 || (2) |Server (AS)|||
>>>>>                 ||<----||||
>>>>>                 |Client|+---------------+||
>>>>>                 ||-------------------------->|Resource|
>>>>>                 |User|(1)|Server|
>>>>>                 |Consent|<--------------------------|(RS)|
>>>>>                 |element|||
>>>>>                 ||-------------------------->||------>
>>>>>                 ||(3)||(4)
>>>>>                 ||<--------------------------||<------
>>>>>                 +-----------++------------+
>>>>>                 *
>>>>>                 The flow of operations is as follows:
>>>>>
>>>>>                 The Client (which may have been previously
>>>>>                 authenticated using FIDO)
>>>>>
>>>>>             Which party has the client authenticated to? The
>>>>>             client authenticating with FIDO is confusing to me.
>>>>>             FIDO is usually how a user authenticates.
>>>>
>>>>             If the user has previously opened a user account with
>>>>             the RS using FIDO, then the client may be authenticated
>>>>             by the RS using FIDO.
>>>>             In such a case, the user is already known to the RS
>>>>             under a pseudonym specific to the RS. It may (or may
>>>>             not) have previously presented access tokens
>>>>             to that RS.
>>>>
>>>>>             contacts the RS and after some dialogue with the RS
>>>>>             selects an operation
>>>>>             How does the client know which RS to contact?
>>>>
>>>>             For a private usage, the user may use DuckDuckGo, while
>>>>             for business he may use an application from his company
>>>>             which lists various services
>>>>             available in the context of his job or his position.
>>>>             Some services may be freely available to all the
>>>>             employees of the company with any authentication,
>>>>             e.g. the phone book of the employees may be freely
>>>>             available on the intranet of the company, while some
>>>>             other services may require the user
>>>>             to authenticate to the AS from the company.
>>>>
>>>>>             that it wants to perform on the RS (1a). Note that it
>>>>>             may also indicate directly the operation that it wants
>>>>>             to perform on the RS without any prior dialogue.
>>>>>
>>>>>                 In return (1b), the RS informs the Client about
>>>>>                 which attributes are needed by the RS for
>>>>>                 performing the requested operation and from which
>>>>>                 Attributes Servers
>>>>>                 they may be obtained.
>>>>>
>>>>>             (1a) and (1b) are not labeled. There is only (1)
>>>>
>>>>             (1a) is the first exchange for (1) with the arrow from
>>>>             left to right, while (1b) is the response with the
>>>>             arrow from right to left.
>>>>             The same applies to the other exchanges i.e. (2) , (3)
>>>>             and (4).
>>>>
>>>>>
>>>>>                 This information is specifically marked to
>>>>>                 indicate that it shall be handled by the "User
>>>>>                 Consent element" from the Client.
>>>>>
>>>>>             Why? What is the significance of this? Which
>>>>>             information is marked?
>>>>
>>>>             In the response, a specific identifier or a magic
>>>>             number is used to indicate the start and the length of
>>>>             the information block
>>>>             to be sent to the "User Consent element" supported by
>>>>             the Client.
>>>>
>>>>>             The presentation of that information is up to the man
>>>>>             machine interface supported by the "User Consent
>>>>>             element" from the Client.
>>>>>
>>>>>
>>>>>             Which information?
>>>>
>>>>             The attributes that are needed by the RS for performing
>>>>             a requested operation and from which Attributes Servers
>>>>             they may be obtained.
>>>>
>>>>>
>>>>>                 The user can see which attributes are requested by
>>>>>                 the RS for performing the requested operation and,
>>>>>                 if it consents, the Client contacts one or more
>>>>>                 appropriate Authorization Servers (2a).
>>>>>
>>>>>             How does the client know which AS(s) to contact?
>>>>
>>>>             For each AS trusted by the RS to perfom a given
>>>>             operation, the RS should indicate a user-friendly name
>>>>             and a URL of the AS.
>>>>
>>>>>                 The user consent is hence captured locally by the
>>>>>                 Client (i.e. there is no dialogue with any AS nor
>>>>>                 any RS).
>>>>>
>>>>>
>>>>>             No dialogue with who? The client is calling the AS is
>>>>>             it not?
>>>>
>>>>             For the user consent, there is no external call since
>>>>             it is handled locally. Afterwards, there is a call to
>>>>             the AS(s) selected by the user.
>>>>
>>>>>
>>>>>                 When the Client got the access tokens from these
>>>>>                 authorization servers (2b), it sends all of them
>>>>>                 in a single request to the RS (3a).
>>>>>
>>>>>
>>>>>             So the RS must trust the AS that issued the tokens.
>>>>>             And the AS must trust the Client to have gathered consent.
>>>>             Theses two assertions are correct.
>>>>>             And the AS must have a relationship with the user.
>>>>
>>>>             Only when the user chooses one AS while giving its
>>>>             consent, then the user must have a relationship with
>>>>             the selected AS.
>>>>
>>>>>             It is unclear what role the RO is playing in this
>>>>>             though. The RO and RS look to be the same entity from
>>>>>             all the other parties.
>>>>
>>>>             A RO, as indicated on the figure, has only a
>>>>             relationship with one RS: it has no relationship with
>>>>             any AS.
>>>>             The RS trusts the AS but the AS does not know which RSs
>>>>             are trusting it.
>>>>
>>>>>
>>>>>             From my current understanding, at a high level, this
>>>>>             looks like it is supported by GNAP with the addition
>>>>>             of the discovery step (1).
>>>>
>>>>             Well, it is fairly different :
>>>>
>>>>                 1) The first major difference is that there is no
>>>>                 arrow between the RO and the AS. No protocol or
>>>>                 "out-of-bands" means are necessary.
>>>>
>>>>                 2) The second major difference is that there is no
>>>>                 arrow between the AS and the RS. No protocol is
>>>>                 necessary.
>>>>
>>>>                 3) The third major difference is that the AS does
>>>>                 not know any RS. Note: for backward compatibility
>>>>                 reasons, an exception might exist for "old" Auth
>>>>                 2.0 ASs.
>>>>
>>>>                 4) The fourth major difference is that the XAuth
>>>>                 spec. is rather vague to describe when and by who
>>>>                 the user consent is captured:
>>>>                     XAuth states on page 4: "User consent is /often
>>>>                 /required at the GS". In that case, the GS is able
>>>>                 to act as Big Brother. No other case is described.
>>>>
>>>>                 5) The fifth major difference is that the data that
>>>>                 is transferred to a "User Consent Element" to
>>>>                 capture the user consent. That data can be
>>>>                 standardized.
>>>>                     Moreover, it will also be possible to
>>>>                 standardize the dialogue between the RO and the RS.
>>>>                 The RO will then be able to manage remotely the
>>>>                 authorization tables.
>>>>                     See my email sent on June 6, with the following
>>>>                 subject: "Support of FIDO and data minimization by
>>>>                 RSs".
>>>>
>>>>                 6) Another difference is the following: since there
>>>>                 is no interaction between the RO and the AS,
>>>>                 "authorizations from the RO" as described in XAuth
>>>>                 do not exist. 
>>>>
>>>>>             There have been a number of proposals for doing this
>>>>>             discovery, and perhaps now there are enough use cases
>>>>>             to look at standardizing something.
>>>>>             No interaction is needed between the AS and the User
>>>>>             as the Client is providing enough "information" in the
>>>>>             user object of the Grant Request
>>>>>             to satisfy the AS releasing the access tokens.
>>>>             Not sure I understand correctly this last sentence.
>>>>>
>>>>>             Perhaps as I understand the model in more detail I
>>>>>             will understand what is missing from GNAP (besides the
>>>>>             discovery step).
>>>>
>>>>             It would be hard to say "what is missing" from XAuth
>>>>             since the foundations are not the same.
>>>>
>>>>             In order to compare different architectures, there is
>>>>             the need to start with the trust relationships.
>>>>             Unfortunately, the word "trust" is absent in the main
>>>>             body of draft-hardt-xauth-protocol-12. Hence,
>>>>             the description of the trust relationships is missing.
>>>>
>>>>             Denis
>>>>
>>>>>
>>>>>             /Dick
>>>>>
>>>>>             (I've skipped reviewing the delegation use case below
>>>>>             until I understand the simple use case)
>>>>>
>>>>>
>>>>>                 End of the story for a simple access
>>>>>
>>>>>
>>>>>                 Start of a subsequent story for a delegation case
>>>>>
>>>>>                 Let us now suppose that the RS is unable to fulfil
>>>>>                 the request by its own and that it needs to
>>>>>                 contact another RS. RS1 contacts RS2 (4a) and
>>>>>                 indicates the operation
>>>>>                 that it wants to perform on RS2 (that operation
>>>>>                 may not be the same as the original operation). In
>>>>>                 return (4b), RS2 informs RS1 about which
>>>>>                 attributes are needed
>>>>>                 by RS2 for performing the requested operation and
>>>>>                 from which Attributes Servers they may be
>>>>>                 obtained. RS1 forwards that information to the
>>>>>                 Client.
>>>>>
>>>>>                 This information is marked to indicate that it
>>>>>                 shall be handled by the "User Consent element"
>>>>>                 from the Client. The presentation of that
>>>>>                 information is up to the man machine
>>>>>                 interface from the Client. The user can see which
>>>>>                 attributes are requested by RS2 for performing the
>>>>>                 new requested operation and, if it consents, the
>>>>>                 Client contacts one or more
>>>>>                 appropriate Authorization Servers. The user
>>>>>                 consent is hence captured locally by the "User
>>>>>                 Consent element" from the Client. (i.e. there is
>>>>>                 no dialogue with any AS, nor RS1, nor RS2).
>>>>>
>>>>>                 When the Client got the access token(s) from the
>>>>>                 authorization server(s), it sends all of them in a
>>>>>                 single request to RS1. RS1 then forwards the
>>>>>                 additional access token(s) to RS2.
>>>>>
>>>>>
>>>>>                 Some observations:
>>>>>
>>>>>                 The user nor the Client are linked with any
>>>>>                 particular AS. A user may use today an AS of the
>>>>>                 Bank of America and may change tomorrow to the
>>>>>                 Bank of Missouri.
>>>>>                 As soon as he will be registered with the Bank of
>>>>>                 Missouri, he will be able to get access tokens
>>>>>                 from the AS of the Bank of Missouri. The AS of
>>>>>                 Bank of America
>>>>>                 has not been able to know where its access tokens
>>>>>                 have been used. This will be the same for AS of
>>>>>                 the Bank of Missouri. There is no need for any
>>>>>                 direct dialogue
>>>>>                 between any AS and any RS at the time a client is
>>>>>                 making an access. There is no need for any RO to
>>>>>                 contact any AS.
>>>>>
>>>>>                 This model has been constructed following a
>>>>>                 "Privacy by Design" approach.
>>>>>
>>>>>                 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
>>
>
>     -- 
>     Txauth mailing list
>     Txauth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/txauth
>


--------------A7002511349A222A2531E6CE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Dick,

    


    

    
You wrote: "I don't understand what is
      missing". The response is in my previous email.

      The user consent is always requested by the Client and
      hence it is never requested by the GS/AS.

    


    

    
Two other important points:

    


    

    
1° At the first exchange, the RS
      discloses the elements of an authorization table 

           that are directly dependent upon the operation that the
      client is willing to perform.

    
 

    

    
2° I propose a way to integrate FIDO,
      since FIDO allows to support the user's authentication phase 

           by disclosing only a pseudonym unique to the RS.

    


    

    
Denis

    


    

    

    

      
      

        

          
I get that the Client<->RS step is
            critical to the use case, as is the User not interacting
            with the GS, but there are other use cases where the User
            does not interact with the GS, for example https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-2.3.,
            but Denis's use case should not be the only use case. 
            


            

            
So it seems that GNAP can support Denis's use case
              by defining the initial Client<->RS interaction, and
              the information in the user object of the Grant Request to
              be what the GS needs to issue access tokens, which was
              what I suggested earlier.

            


            

            
I don't understand what is missing, besides the details
              of the Client<->RS interaction, and what is in the
              Grant Request.

            


            

          

        

      

      

      

        
On Mon, Jul 13, 2020 at 12:22
          PM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hi Justin,

            


            

            
You have perfectly understood the differences. The
              location where the user consent is gathered in
                a uniform way using to the information released by
              the RS 

              is a fundamental element of the design.  

            

            

            
 If I’m understanding Denis’s
              proposal, he’s saying that that “prior step” is the
              lynchpin of the whole model, since interaction between the
              client and the RS (and the user and the RS) is key to
              Denis’s privacy model. Additionally, what happens *at*
              each step is different. Consent is gathered at the client,
              not the GS in this diagram, for example. The GS simply
              mints a token as specified by the client and the RS.
              


              

              
It’s for these reasons that, as long as I’ve been
                understanding correctly, I’ve been saying that Denis’s
                model as proposed is pretty different. 

            

            
Indeed.

            
Denis

            

            

              
But what I think isn’t that different is the
                different steps if you’re willing to look at the
                boundaries around the boxes differently. For example,
                what OAuth would call “the AS” might end up being a few
                different boxes in GNAP that do different things. I had
                started down that route with XYZ’s design allowing the
                interaction to be managed separately. 

              


              

              
I think that the disconnect we’re seeing here might
                be caused by vocabulary mismatches. If we aren’t meaning
                the same thing when we say the same terms, it’s easy to
                get things mixed up with each other. Since GNAP is just
                barely forming its vocabulary out of the legacy of OAuth
                and kin, we have a chance to maybe draw the lines better
                and see if that’s how we can get things to fit.

                


                

                
 — Justin

                  


                    

                      
On Jul 13, 2020, at 2:02 PM, Dick Hardt <dick.hardt@gmail.com>
                        wrote:

                      

                      

                        


                          
I'm going to just address the first part
                            of your response so that we can get clarity
                            on that before diving into your later
                            comments.

                          


                          

                          
The calls between your proposal and XAuth
                            are not inverted, your proposal has a prior
                            step. Step 1 in XAuth maps to Step 2 in your
                            proposal, and Step 2 in XAuth is Step 3 in
                            your proposal..

                          


                          

                          
Below are 2 diagrams showing the same
                            steps, the first keeping the existing step
                            labels for XAuth, the latter renaming the
                            steps to correspond to your proposal. This
                            looks pretty similar to your diagram. What
                            am I missing?

                          


                          

                          
/Dick

                          


                          

                          

                            
DIAGRAM 1 (steps start at 0)

                            
       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (0)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+

                            
DIAGRAM 2 (steps start at 1)

                            
       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (2) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (3)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (1)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+

                          

                        

                        
ᐧ

                        

                        

                          
On Mon, Jul
                            13, 2020 at 7:08 AM Denis <denis.ietf@free.fr>
                            wrote:

                          

                          

                            

                              
Hello Dick,

                              


                              

                              
You wrote: "This looks pretty similar
                                to your protocol drawing".

                                

                              

                              
No. There is a fundamental difference
                                with the sequencing of the flow of the
                                exchanges where the (1) and (2) flows
                                are inverted. 

                              

                              


                              

                              
In your figure:

                              

                              

                                

                                  
The Client makes calls to the GS
                                    (1)

                                  
The Client makes calls to the RS
                                    (2)

                                

                                
while in my figure:

                                

                                  

                                    
The Client makes calls to the
                                      RS (1)

                                    
The Client makes calls to the
                                      AS (2)

                                  

                                

                              

                              
In your figure, the first flow is
                                with the GS, whereas in my figure the
                                first flow is with the RS and there is a
                                good reason for that: 

                                the client first contacts the RS to know
                                what the RS expects. The client
                                indicates in its first exchange to the
                                RS whether it wants to authenticate 

                                or to perform another operation.  In the
                                case of an authentication operation, the
                                RS may respond to the client that is
                                supports FIDO U2F 

                                or that it is willing the client to
                                present some attribute(s) from one or
                                more AS.

                              


                              

                              
Then after the client has to figure
                                out whether the user is using FIDO and
                                if not whether the user has an account
                                with one of the AS.

                              
In the later case, if there is a
                                match then the client, *after having
                                  received the user consent*, may
                                contact the appropriate AS to ask 

                                for some attribute(s). 

                              

                              


                              

                              
The same fundamental difference
                                applies with
                                draft-richer-transactional-authz-06
                                (XYZ) where the first exchange is done
                                with the AS:

                              
"The RC creates a transaction request
                                and sends it to the AS".

                              


                              

                              
This answers also in details to one
                                of your comments:

                              

                                

                                  
What looks to be missing from
                                    your proposal is:

                                  
A) The Client making a call to
                                    the RS to discover what it needs
                                    from a GS, and which GS to ask,
                                    prior to (1).

                                

                              

                              
This is not missing since this is the
                                foundation of the architecture. The
                                discovery mechanism at the RS has been
                                described 

                                in details in an earlier email with the
                                following title: "Support of FIDO and
                                data minimization by RSs".

                              


                              

                              
The main figures are copied below
                                (using ASCII):
                                
 
                                        +-----------------------------------+---------------------------------+

                                          +          
                                        Operation              
                                        +      Mathematical
                                        expression    +

                                          +-----------------------------------+---------------------------------+

                                          + Authentication                   
                                        + Condition 1 OR
                                        Condition 2      +

                                          +-----------------------------------+---------------------------------+

                                          + Operation A OR
                                        Operation Z        +
                                        Condition 3 AND Condition 4    
                                        +

                                          +-----------------------------------+---------------------------------+

                                        

                                      Conditions table: 

                                        

                                          +-------------+--------------+-----------------------------+----------+

                                          + Condition 1 +
                                        FIDO U2F 1.2 +                            
                                        +          +

                                          +-------------+--------------+-----------------------------+----------+

                                          + Condition 2 +
                                        AS 1         + set
                                        1 of a attributes types +          +

                                          +-------------+--------------+-----------------------------+----------+

                                          + Condition 3 +
                                        AS 2         + set
                                        2 of a attributes types + Scope
                                        21 +

                                          +-------------+--------------+-----------------------------+----------+

                                          + Condition 4 +
                                        AS 9         + set
                                        3 of a attributes types-+          +

                                          +-------------+--------------+-----------------------------+----------+

                                    

                                  According to the operation announced
                                  by the Client, the RS returns to the
                                  Client both the mathematical
                                  expression 

                                  associated with that operation and the
                                  conditions included in that
                                  mathematical expression. The Client
                                  may then 

                                  present that information to the user
                                  in order to obtain the user consent in
                                  a standardized manner.

                                

                              

                              
Another comment you made is:

                              

                                
What looks to be missing from your
                                  proposal is:

                                
B) A mechanism for the Client to
                                  prove to the GS that it has gathered
                                  consent from the User.

                              

                              
The user consent should not be
                                captured *by the GS*, since the GS would
                                be in a position to apply a different
                                consent decision 

                                without letting it know to the user (or
                                to the client).

                              


                                The user consent must be captured *by
                                the Client* and the Client must be able
                                to verify that this consent has indeed
                                been followed by the AS. 

                              

                              


                              

                              
The authorization data managed at the
                                RS by the RO is used by the Client to
                                query the consent of the user in a
                                standardized manner.

                              
When, later on, the access token is
                                returned to the Client by the AS, the
                                Client (not the user) using that
                                authorization data as well as 

                                the decision of the user is able to
                                verify that the requested attributes
                                (and no more) are indeed present into
                                the access token. 

                                

                                This is why access tokens may *not* be
                                considered to be opaque to the Clients.

                              


                              

                              
In my earlier email copied below, six
                                major differences with XAuth from 1) to
                                6) are listed.

                              


                              

                              
Denis

                                

                              

                              

                                
From https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1
                                  


                                    

                                      
1.1.  Parties


   The parties and their relationships to each other:


                                      
       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+



                                    

                                    

                                      


                                      

                                      
The lines without arrows
                                        represent relationships. 

                                    

                                  

                                  
The User trusts the Client

                                  
The User trusts the GS

                                  
The RO trusts the GS to issue
                                    access tokens for the RS

                                  
The RS trusts the tokens issued
                                    by the RS

                                  
The RO controls the RS

                                  


                                  

                                  
The Client makes calls to the GS
                                    (1)

                                  
The Client makes calls to the RS
                                    (2)

                                  


                                  

                                  
This looks pretty similar to your
                                    protocol drawing.

                                  


                                  

                                  
What looks to be missing from
                                    your proposal is:

                                  


                                  

                                  
A) The Client making a call to
                                    the RS to discover what it needs
                                    from a GS, and which GS to ask,
                                    prior to (1).

                                  
B) A mechanism for the Client to
                                    prove to the GS that it has gathered
                                    consent from the User.

                                  


                                  

                                  
The current protocol does not
                                    require the GS to interact with
                                    either the User, the RO, or the RS
                                    -- which looks to me to meet your
                                    privacy goals.

                                  


                                  

                                

                                
ᐧ

                                

                                

                                  
On
                                    Fri, Jul 10, 2020 at 6:06 AM Denis
                                    <denis.ietf@free.fr>
                                    wrote:

                                  

                                  

                                    

                                      
Hi Dick,

                                      


                                      

                                      

                                        

                                          
Hi Denis,
                                            thanks for sharing the
                                            model. I don't fully
                                            understand what is going on,
                                            questions inserted:

                                        

                                      

                                      Responses are inserted.

                                      

                                        

                                          

                                            


                                            

                                            
FWIW: having paragraphs
                                              start with the step number
                                              (1), (2) etc. would make
                                              it easier to map between
                                              the description and the
                                              diagram.

                                          

                                          

                                          

                                            
On Thu,
                                              Jul 9, 2020 at 3:26 AM
                                              Denis <denis.ietf@free.fr>
                                              wrote:

                                            

                                            

                                              

                                                

                                                  
This
                                                      is a new thread.

                                                      

                                                      Preamble: This
                                                      model is quite
                                                      different from the
                                                      XAuth model. 

                                                      In particular, a
                                                      RO has no
                                                      relationship with
                                                      any AS and a
                                                      Client does not
                                                      need to be
                                                      associated with
                                                      any AS prior to
                                                      any access to a
                                                      RS.

                                                      

                                                      A key point of
                                                      this model is that
                                                      the user's consent
                                                      is handled locally
                                                      by the Client and
                                                      hence no AS nor RS
                                                      is handling a man
                                                      machine interface
                                                      

                                                      for the user
                                                      consent. This
                                                      allows to support
                                                      locally the user
                                                      consent for
                                                      multiple ASs while
                                                      keeping all ASs
                                                      ignorant about the
                                                      choices of the
                                                      user 

                                                      made for accessing
                                                      a particular RS.

                                                      

                                                        

                                                              
                                                          +--------+                          
                                                          +------------+

                                                                 | 
                                                          User 
                                                          |                          
                                                          | 
                                                          Resource 
                                                          |

                                                                 |       
                                                          |                          
                                                          | Owner
                                                          (RO) |

                                                                 +--------+        
                                                                            +------------+

                                                                    
                                                          |     
                                                          \                             
                                                          |

                                                                    
                                                          |      
                                                          \                            
                                                          |

                                                                    
                                                          |       
                                                          \                           
                                                          |

                                                                    
                                                          |        
                                                          \                          
                                                          |

                                                              +-----------+ 
                                                             +---------------+    
                                                          +------------+

                                                              |          
                                                          |---->|
                                                          Authorization
                                                          |     |           
                                                          |

                                                              |          
                                                          | (2) | 
                                                          Server
                                                          (AS)  |    
                                                          |           
                                                          |

                                                              |          
                                                          |<----|              
                                                          |    
                                                          |           
                                                          |

                                                              | 
                                                          Client  
                                                          |    
                                                          +---------------+    
                                                          |           
                                                          |

                                                              |          
                                                          |-------------------------->| 
                                                          Resource 
                                                          |

                                                              |  
                                                          User   
                                                          |          
                                                          (1)            
                                                          |  
                                                          Server  
                                                          |

                                                              | 
                                                          Consent 
                                                          |<--------------------------|   
                                                          (RS)   
                                                          |

                                                              | 
                                                          element 
                                                          |                          
                                                          |           
                                                          |

                                                              |          
                                                          |-------------------------->|           
                                                          |------>

                                                              |          
                                                          |          
                                                          (3)            
                                                          |           
                                                          | 
                                                          (4)

                                                              |          
                                                          |<--------------------------|           
                                                          |<------

                                                              +-----------+                          
                                                          +------------+

                                                      

                                                      The flow of
                                                      operations is as
                                                      follows:

                                                      

                                                      The Client (which
                                                      may have been
                                                      previously
                                                      authenticated
                                                      using FIDO) 

                                                

                                              

                                            

                                            
Which party has the
                                              client authenticated to?
                                              The client authenticating
                                              with FIDO is confusing to
                                              me. FIDO is usually how a
                                              user authenticates.

                                          

                                        

                                      

                                      
If the user has previously
                                        opened a user account with the
                                        RS using FIDO, then the client
                                        may be authenticated by the RS
                                        using FIDO.

                                        In such a case, the user is
                                        already known to the RS under a
                                        pseudonym specific to the RS. It
                                        may (or may not) have previously
                                        presented access tokens 

                                        to that RS.

                                      

                                      

                                        

                                          

                                            
 contacts
                                                the RS and after some
                                                dialogue with the RS
                                                selects an operation 

                                              

                                            
How does the client
                                              know which RS to contact?

                                          

                                        

                                      

                                      
For a private usage, the user
                                        may use DuckDuckGo, while for
                                        business he may use an
                                        application from his company
                                        which lists various services 

                                        available in the context of his
                                        job or his position. Some
                                        services may be freely available
                                        to all the employees of the
                                        company with any authentication,

                                        e.g. the phone book of the
                                        employees may be freely
                                        available on the intranet of the
                                        company, while some other
                                        services may require the user 

                                        to authenticate to the AS from
                                        the company.

                                      

                                        

                                          

                                            
 that
                                                it wants to perform on
                                                the RS (1a). Note that
                                                it may also indicate
                                                directly the operation
                                                that it wants to perform
                                                on the RS without any
                                                prior dialogue. 

                                              

                                            

                                              

                                                

                                                  

                                                      In return (1b),
                                                      the RS informs the
                                                      Client about which
                                                      attributes are
                                                      needed by the RS
                                                      for performing the
                                                      requested
                                                      operation and from
                                                      which Attributes
                                                      Servers 

                                                      they may be
                                                      obtained. 

                                                    

                                                

                                              

                                            

                                            
(1a) and (1b) are not
                                              labeled. There is only (1)
                                              

                                            

                                          

                                        

                                      

                                      
(1a) is the first exchange for
                                        (1) with the arrow from left to
                                        right, while (1b) is the
                                        response with the arrow from
                                        right to left. 

                                        The same applies to the other
                                        exchanges i.e. (2) , (3) and
                                        (4).

                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                      

                                                      This information
                                                      is specifically
                                                      marked to indicate
                                                      that it shall be
                                                      handled by the
                                                      "User Consent
                                                      element" from the
                                                      Client. 

                                                    

                                                

                                              

                                            

                                            
Why? What is the
                                              significance of this?
                                              Which information is
                                              marked?

                                          

                                        

                                      

                                      
In the response, a specific
                                        identifier or a magic number is
                                        used to indicate the start and
                                        the length of the information
                                        block  

                                        to be sent to the "User Consent
                                          element" supported by the
                                          Client.

                                      

                                      

                                        

                                          

                                            

                                              
The
                                                  presentation of that
                                                  information is up to
                                                  the man machine
                                                  interface supported by
                                                  the "User Consent
                                                  element" from the
                                                  Client. 

                                                

                                            

                                            


                                            

                                            
Which information? 

                                            

                                          

                                        

                                      

                                      
The
                                          attributes that are needed by
                                          the RS for performing a
                                          requested operation and from
                                          which Attributes Servers they
                                          may be obtained.

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                      

                                                      The user can see
                                                      which attributes
                                                      are requested by
                                                      the RS for
                                                      performing the
                                                      requested
                                                      operation and, if
                                                      it consents, the
                                                      Client contacts
                                                      one or more 

                                                      appropriate
                                                      Authorization
                                                      Servers (2a). 

                                                

                                              

                                            

                                            
How does the client
                                              know which AS(s) to
                                              contact?

                                          

                                        

                                      

                                      
For each AS trusted by the RS
                                        to perfom a given operation, the
                                        RS should indicate a
                                        user-friendly name and a URL of
                                        the AS. 

                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
The
                                                      user consent is
                                                      hence captured
                                                      locally by the
                                                      Client (i.e. there
                                                      is no dialogue
                                                      with any AS nor
                                                      any RS).

                                                    

                                                

                                              

                                            

                                            


                                            

                                            
No dialogue with who?
                                              The client is calling the
                                              AS is it not? 

                                            

                                          

                                        

                                      

                                      
For the user consent, there is
                                        no external call since it is
                                        handled locally. Afterwards,
                                        there is a call to the AS(s)
                                        selected by the user.

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                      

                                                      When the Client
                                                      got the access
                                                      tokens from these
                                                      authorization
                                                      servers (2b), it
                                                      sends all of them
                                                      in a single
                                                      request to the RS
                                                      (3a).

                                                    

                                                

                                              

                                            

                                            


                                            

                                            
So the RS must trust
                                              the AS that issued the
                                              tokens. And the AS must
                                              trust the Client to have
                                              gathered consent.

                                          

                                        

                                      

                                      Theses two assertions are correct.

                                      

                                        

                                          

                                            
 And the AS must have a
                                              relationship with the
                                              user. 

                                          

                                        

                                      

                                      
Only when the user chooses one
                                        AS while giving its consent,
                                        then the user must have a
                                        relationship with the selected
                                        AS.

                                      

                                        

                                          

                                            
It is unclear what role
                                              the RO is playing in this
                                              though. The RO and RS look
                                              to be the same entity from
                                              all the other parties.

                                          

                                        

                                      

                                      
A RO, as indicated on the
                                        figure, has only a relationship
                                        with one RS: it has no
                                        relationship with any AS. 

                                        The RS trusts the AS but the AS
                                        does not know which RSs are
                                        trusting it.

                                      

                                        

                                          

                                            


                                            

                                            
From my current
                                              understanding, at a high
                                              level, this looks like it
                                              is supported by GNAP with
                                              the addition of the
                                              discovery step (1). 

                                          

                                        

                                      

                                      
Well, it is fairly different :
                                        

                                      

                                      

                                        
1) The first major difference
                                          is that there is no arrow
                                          between the RO and the AS. No
                                          protocol or "out-of-bands"
                                          means are necessary. 

                                        

                                        
2) The second major
                                          difference is that there is no
                                          arrow between the AS and the
                                          RS. No protocol is necessary.
                                        

                                        
3) The third major difference
                                          is that the AS does not know
                                          any RS. Note: for backward
                                          compatibility reasons, an
                                          exception might exist for
                                          "old" Auth 2.0 ASs.

                                        

                                        
4) The fourth major
                                          difference is that the XAuth
                                          spec. is rather vague to
                                          describe when and by who the
                                          user consent is captured: 

                                              XAuth states on page 4:
                                          "User consent is often required
                                          at the GS". In that case, the
                                          GS is able to act as Big
                                          Brother. No other case is
                                          described.

                                        

                                        5) The fifth major difference is
                                        that the data that is
                                        transferred to a "User Consent
                                        Element" to capture the user
                                        consent. That data can be
                                        standardized. 

                                            Moreover, it will also be
                                        possible to standardize the
                                        dialogue between the RO and the
                                        RS. The RO will then be able to
                                        manage remotely the
                                        authorization tables.

                                            See my email sent on June 6,
                                        with the following subject:
                                        "Support of FIDO and data
                                        minimization by RSs".

                                        

                                        6) Another difference is the
                                        following: since there is no
                                        interaction between the RO and
                                        the AS, "authorizations from the
                                        RO" as described in XAuth do not
                                        exist.   

                                      

                                        

                                          

                                            
There have been a
                                              number of proposals for
                                              doing this discovery, and
                                              perhaps now there are
                                              enough use cases to look
                                              at standardizing
                                              something.  

                                              No interaction is needed
                                              between the AS and the
                                              User as the Client is
                                              providing enough
                                              "information" in the user
                                              object of the Grant
                                              Request 

                                              to satisfy the AS
                                              releasing the access
                                              tokens. 

                                            

                                          

                                        

                                      

                                      Not sure I understand correctly
                                      this last sentence.

                                      

                                        

                                          

                                            


                                            

                                            
Perhaps as I understand
                                              the model in more detail I
                                              will understand what is
                                              missing from GNAP (besides
                                              the discovery step).

                                          

                                        

                                      

                                      
It would be hard to say "what
                                        is missing" from XAuth since the
                                        foundations are not the same.

                                      
In order to compare different
                                        architectures, there is the need
                                        to start with the trust
                                        relationships. 

                                        Unfortunately, the word "trust"
                                        is absent in the main body of
                                        draft-hardt-xauth-protocol-12.
                                        Hence, 

                                        the description of the trust
                                        relationships is missing.

                                      

                                      
Denis

                                      

                                        

                                          

                                            


                                            

                                            
/Dick

                                            


                                            

                                            
(I've skipped reviewing
                                              the delegation use case
                                              below until I understand
                                              the simple use case)

                                            


                                            

                                            

                                              

                                                

                                                  

                                                      

                                                      End of the story
                                                      for a simple
                                                      access

                                                  

                                                      

                                                      Start of a
                                                      subsequent story
                                                      for a delegation
                                                      case

                                                      

                                                      Let us now suppose
                                                      that the RS is
                                                      unable to fulfil
                                                      the request by its
                                                      own and that it
                                                      needs to contact
                                                      another RS. RS1
                                                      contacts RS2 (4a)
                                                      and
                                                      indicates the
                                                      operation 

                                                      that it wants to
                                                      perform on RS2
                                                      (that operation
                                                      may not be the
                                                      same as the
                                                      original
                                                      operation). In
                                                      return (4b), RS2
                                                      informs RS1 about
                                                      which attributes
                                                      are needed 

                                                      by RS2 for
                                                      performing the
                                                      requested
                                                      operation and from
                                                      which Attributes
                                                      Servers they may
                                                      be obtained. RS1
                                                      forwards that
                                                      information to the
                                                      Client. 

                                                      

                                                      This information
                                                      is marked to
                                                      indicate that it
                                                      shall be handled
                                                      by the "User
                                                      Consent element"
                                                      from the Client.
                                                      The presentation
                                                      of that
                                                      information is up
                                                      to the man machine
                                                      

                                                      interface from the
                                                      Client. The user
                                                      can see which
                                                      attributes are
                                                      requested by RS2
                                                      for performing the
                                                      new requested
                                                      operation and, if
                                                      it consents, the
                                                      Client contacts
                                                      one or more 

                                                      appropriate
                                                      Authorization
                                                      Servers. The user
                                                      consent is hence
                                                      captured locally
                                                      by the "User
                                                      Consent element"
                                                      from the Client.
                                                      (i.e. there is no
                                                      dialogue with any
                                                      AS, nor RS1, nor
                                                      RS2). 

                                                      

                                                      When the Client
                                                      got the access
                                                      token(s) from the
                                                      authorization
                                                      server(s), it
                                                      sends all of them
                                                      in a single
                                                      request to RS1.
                                                      RS1 then forwards
                                                      the additional
                                                      access token(s) to
                                                      RS2.

                                                      

                                                      

                                                      Some observations:
                                                      

                                                      

                                                      The user nor the
                                                      Client are linked
                                                      with any
                                                      particular AS. A
                                                      user may use today
                                                      an AS of the Bank
                                                      of America and may
                                                      change tomorrow to
                                                      the Bank of
                                                      Missouri. 

                                                      As soon as he will
                                                      be registered with
                                                      the Bank of
                                                      Missouri, he will
                                                      be able to get
                                                      access tokens from
                                                      the AS of the Bank
                                                      of Missouri. The
                                                      AS of Bank of
                                                      America 

                                                      has not been able
                                                      to know where its
                                                      access tokens have
                                                      been used. This
                                                      will be the same
                                                      for AS of the Bank
                                                      of Missouri. There
                                                      is no need for any
                                                      direct dialogue 

                                                      between any AS and
                                                      any RS at the time
                                                      a client is making
                                                      an access. There
                                                      is no need for any
                                                      RO to contact any
                                                      AS.

                                                  
This
                                                      model has been
                                                      constructed
                                                      following a
                                                      "Privacy by
                                                      Design" approach.

                                                  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

                      

                    

                  

                  

                

              

            

            


            

          

          -- 

          Txauth mailing list

          Txauth@ietf.org

          https://www.ietf.org/mailman/listinfo/txauth

        

      

    

    


    

  


--------------A7002511349A222A2531E6CE--


From nobody Mon Jul 13 13:17: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 B86553A0845 for ; Mon, 13 Jul 2020 13:17: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 6T5473MvJVDI for ; Mon, 13 Jul 2020 13:17:16 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450: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 BA1283A082A for ; Mon, 13 Jul 2020 13:17:15 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id d21so9896836lfb.6 for ; Mon, 13 Jul 2020 13:17: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;  bh=P3mPDRJJxJSADqcfFkZ9XspZlD05gfrvR66CJf/Rw9U=; b=a8eKWRV0DgIYWbNWYKvnOLJLDpVC8GTiQ5jmbgl5NjUXvtccj7+cCdWdl74J144G9e KFrQBvKU3jWrdALJZ8814o/jj4cKivd4KR47vO5Wt5VUXE0wjLcXS/2zzN5R9y/nFGS/ WEXcIJqFfWzCpI9RvbuY3GcA+926hh12TyGEpfCoKhhUtwzRu3wKgKnWrRjJnounTw+x w2tXR94by66ma3zirpORjmKde3p/vno5G6y31WJ7cpPyLDPWoy2M3P8GjVsYaQL/vWUl /1Kz/K36cgBDCWKyGi+ttRXy0ILhXJ1f7txzYlj59XZXlA0SIVAnwjMgey6zvXSPoi4c iq/A==
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; bh=P3mPDRJJxJSADqcfFkZ9XspZlD05gfrvR66CJf/Rw9U=; b=FPar7e/9Cpq632HFM5awyhwXIoYqot+IkVEQ1pp4mWiUKK/J7k22x/rFjCcV9quvl1 54jycTd8wDHHXmiUQWcv2M9eRCwgoAPkH2uwkvCNY6R91CAhxS9bSpB6Z9XDJL8XlxeN 3op0DvcjFyct6265JdD9qvIQvC9OjgtBboJzpGRJ5msrpFeyYkoZk4EurDQueQsueyGB PJAVvHoOh0Dzep8lnwawdR71oRCqarq+klaY7pdJQAPRpUGwOavFiAkUuuiqw91EwkrR hlaroCADu0hi8vuMpvJ2oOzBPuZ41zqApXschoj8hi8ZR+amYyrl5jppPNyhQsb++/Op fkiQ==
X-Gm-Message-State: AOAM533seIc3TFvdkEE7jLd7+2NFgPrAdR2EG1CGRs3bo9KXY1cwkod4 qXLF6BIlTeCZmLoAMj0fyfLuOajpnTg4jPw75H/JOLf7
X-Google-Smtp-Source: ABdhPJyFy37qTGVIT1dNQYU9JvobaLYggw0Z+Pt4Kh0SbInalRrOMnZZ9DtDAbPvfArWPSW691c0CNrG4n3eri4/WpY=
X-Received: by 2002:a19:ac03:: with SMTP id g3mr416067lfc.164.1594671433315; Mon, 13 Jul 2020 13:17:13 -0700 (PDT)
MIME-Version: 1.0
References: <159467045136.14799.4677302347817656998@ietfa.amsl.com>
In-Reply-To: <159467045136.14799.4677302347817656998@ietfa.amsl.com>
From: Dick Hardt 
Date: Mon, 13 Jul 2020 13:16:36 -0700
Message-ID: 
To: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000050fa6805aa586074"
Archived-At: 
Subject: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-13.txt
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, 13 Jul 2020 20:17:18 -0000

--00000000000050fa6805aa586074
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Clarified when a User is also an RO, per Francis suggestion.

The major normative change is making all authorization requests a RAR
request, presuming that there is a RAR type for OAuth scopes,( or there is
a decision that the default type is a JSON string of type OAuth scope)

This version still restricts an authorization request to one type

{
    "authorizations": {
        "writer": {
            "type": "oauth_scope",
            "scope": ["create","update","delete"]
        },
        "reader": {
                "type": "oauth_scope",
                "scope": ["read","list"]
        }
    }
}


Versus the slightly more verbose syntax in XYZ using an array, or object of
arrays per below. I'm leaning towards the slightly more verbose version,
which also aligns with RAR, and will make that change once I have updated
my implementation.

Multiple tokens

{
    "authorizations": {
        "writer": [
            {
                "type": "oauth_scope",
                "scope": ["create","update","delete"]
            }
        ],
        "reader": [
            {
                "type": "oauth_scope",
                "scope": ["read","list"]
            }
        ]
    }
}


Single token

{
    "authorizations": [
        {
            "type": "oauth_scope",
            "scope": ["create","update","delete"]
        },
        {
            "type": "oauth_scope",
            "scope": ["read","list"]
        }
    ]
}



---------- Forwarded message ---------
From: 
Date: Mon, Jul 13, 2020 at 1:01 PM
Subject: New Version Notification for draft-hardt-xauth-protocol-13.txt
To: Dick Hardt 



A new version of I-D, draft-hardt-xauth-protocol-13.txt
has been successfully submitted by Dick Hardt and posted to the
IETF repository.

Name:           draft-hardt-xauth-protocol
Revision:       13
Title:          The Grant Negotiation and Authorization Protocol
Document date:  2020-07-13
Group:          Individual Submission
Pages:          39
URL:
https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-13.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol=
/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-13
Htmlized:
https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:
https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-13

Abstract:
   Client software often desires resources or identity claims that are
   independent of the client.  This protocol allows a user and/or
   resource owner to delegate resource authorization and/or release of
   identity claims to a server.  Client software can then request access
   to resources and/or identity claims by calling the server.  The
   server acquires consent and authorization from the user and/or
   resource owner if required, and then returns to the client software
   the authorization and identity claims that were approved.  This
   protocol may be extended to support alternative authorizations,
   claims, interactions, and client authentication mechanisms.




Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


=E1=90=A7

--00000000000050fa6805aa586074
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Clarified when a User is also an RO, per Francis suggestio=
n.

The major normative change is making all authorizatio=
n requests a RAR request, presuming that there is a RAR type for OAuth scop=
es,( or there is a decision that the default type is a JSON string of type =
OAuth scope)

This version still restricts an authorizati=
on request to one type

{
=C2=A0 =C2=A0 "author=
izations": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "writer":=
 { 
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type": &=
quot;oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 "scope": ["create","update","delete&quo=
t;]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 "reader": { 
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 "type": "oauth_scope",
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": =
["read","list"]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }=

=C2=A0 =C2=A0 }
}

Versus the slightly more verbose syntax in XYZ using an array, or object =
of arrays per=C2=A0below. I'm leaning towards the slightly more verbose=
 version, which also aligns with RAR, and will make that change once I have=
 updated my implementation.

Multiple tokens
<=
blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">
{
=

=C2=A0 =C2=A0 "authorizations": {
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 "writer": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 { 
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 "type": "oauth_scope",
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": ["create&=
quot;,"update","delete"]
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "reader": [
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { 
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 "type": "oauth_scope",
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "scope": =
["read","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 }
}

Single token
{
=C2=A0 =C2=A0 "authorizations": [
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 { 
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "type&q=
uot;: "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 "scope": ["create","update","del=
ete"]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 { 
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "=
;type": "oauth_scope",
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 "scope": ["read","list"]
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 ]
}


---------- Forwarded message ---------
From: &=
lt;internet-d=
rafts@ietf.org>
Date: Mon, Jul 13, 2020 at 1:01 PM
Subj=
ect: New Version Notification for draft-hardt-xauth-protocol-13.txt
To: =
Dick Hardt <di=
ck.hardt@gmail.com>




A new version of I-D, draft-hardt-xauth-protocol-13.txt

has been successfully submitted by Dick Hardt and posted to the

IETF repository.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardt-xauth-protocol
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A013

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The Grant Negotiation and Authoriz=
ation Protocol

Document date:=C2=A0 2020-07-13

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 39

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hardt-xauth-prot=
ocol-13.txt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/=
/tools.ietf.org/html/draft-hardt-xauth-protocol-13

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0=
https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol

Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-hardt-xauth-protocol-=
13



Abstract:

=C2=A0 =C2=A0Client software often desires resources or identity claims tha=
t are

=C2=A0 =C2=A0independent of the client.=C2=A0 This protocol allows a user a=
nd/or

=C2=A0 =C2=A0resource owner to delegate resource authorization and/or relea=
se of

=C2=A0 =C2=A0identity claims to a server.=C2=A0 Client software can then re=
quest access

=C2=A0 =C2=A0to resources and/or identity claims by calling the server.=C2=
=A0 The

=C2=A0 =C2=A0server acquires consent and authorization from the user and/or=


=C2=A0 =C2=A0resource owner if required, and then returns to the client sof=
tware

=C2=A0 =C2=A0the authorization and identity claims that were approved.=C2=
=A0 This

=C2=A0 =C2=A0protocol may be extended to support alternative authorizations=
,

=C2=A0 =C2=A0claims, interactions, and client authentication mechanisms.








Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat






3D""=
=E1=90=A7


--00000000000050fa6805aa586074--


From nobody Mon Jul 13 13:21: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 DC80E3A084A for ; Mon, 13 Jul 2020 13:21:12 -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=[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_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 mC_JxHp5cq9I for ; Mon, 13 Jul 2020 13:21:09 -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 69E7F3A099C for ; Mon, 13 Jul 2020 13:20:15 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id h22so19574593lji.9 for ; Mon, 13 Jul 2020 13:20: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=7nNEiDFfliR1U6KaX58uAwmkzEmh+uXC0PINGGbHoKg=; b=KgeL/IPUN0IDl689SUSua5r4Q49k/W6XZKwB29utPJIrv9AEOu0vXJLPUz5ZORMaSB f9pFW23fG2B3r+nPoGU+2+habdeJW2KA1EUCXFGuVVXXc9zt+6sNcs2sg3y+0DUltQw+ yf5k4C4lfLSJEozrCf7jHjTinJtJKDF5qrO8mVWBh3B/hXykbSrVLqKm0drDT1EAuWPz dzt7+MMM81Ds96MvRHVwtx8BT8hDzAyjjnXjCyuiQmRacFtWf4M0hHPu20TOJugXFUjt C6ZdhZf0zshlnIcNl133wUDky5X3YAkkwU5rluY9kiqMlTGMLBHe7eEi6B6kQ15U1SLG jgcQ==
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=7nNEiDFfliR1U6KaX58uAwmkzEmh+uXC0PINGGbHoKg=; b=PEUdmAJbborPMga8qIyfurwehRH7+gJVEM7uhg+zHlVgUSyKTEPKixVmZ1wVbA+7jI quw0KeuQW5wYNBC0I2xQwxhxPWnRZX1AJcHH3pHifDXV3x2N/J/weapk7til0HAVi16Z WOIGlkf8HzkD5tYoIonq+R7EnS0xBYJ+fvOlATWfZerhDKbXIDQ7LFJeEMDnfzBhc9qD +JknvJf7h7ouZXIr1YmXe7moxs+Q0LTH0rurB/kXZGesiK7hsm0pPd/J/mT9Kndd3mJw mGQSb7BoFbM5Q26Kw2JnODaJMvbZBBBRm1QRRem4H9rmxJQONOc5pU5PDYeyw63geYUP XR4g==
X-Gm-Message-State: AOAM533i43MVO3B8asBN0XD+WMN0pV7OX8UX9zVGJ9SJ9a97C/DLhTuW lpRW7UC2EmKSjFzTFFcmo3YhduOM1IvNvxqTHHg=
X-Google-Smtp-Source: ABdhPJzDfBxWv2dPicnsqvoOfLWoeDU5vbesxjcC8jHv3vhl7vAanWqajOTtDI040pzqJC1bg4V90rZeBO8Da2e0pnc=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr667107ljn.5.1594671613044; Mon, 13 Jul 2020 13:20:13 -0700 (PDT)
MIME-Version: 1.0
References:    <325bc015-1547-c56c-c1fe-67a97165785d@free.fr>  <83480ab0-03bc-7cc9-d166-ece4c6b63861@free.fr>  <83DB69E6-F0ED-41A0-A4DA-B7AE4AB89579@mit.edu> <34dfca59-47f7-63e4-b25f-01648b0bd14b@free.fr>  <329996ce-ffa0-9713-b2ff-2a9722a24cf1@free.fr>
In-Reply-To: <329996ce-ffa0-9713-b2ff-2a9722a24cf1@free.fr>
From: Dick Hardt 
Date: Mon, 13 Jul 2020 13:19:36 -0700
Message-ID: 
To: Denis 
Cc: "txauth@ietf.org" , Justin Richer 
Content-Type: multipart/alternative; boundary="00000000000007706505aa586b86"
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 13 Jul 2020 20:21:13 -0000

--00000000000007706505aa586b86
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Denis: it looks like we are talking past each other.

Are you suggesting that GNAP *ONLY *as you have proposed?

Otherwise, it looks to me like your requirements can be added to GNAP.

=E1=90=A7

On Mon, Jul 13, 2020 at 1:06 PM Denis  wrote:

> Dick,
>
> You wrote: "I don't understand what is missing". The response is in my
> previous email.
> The *user consent* is always requested by the Client and hence it is
> never requested by the GS/AS.
>
> Two other important points:
>
> 1=C2=B0 At the first exchange, the RS discloses the elements of an
> authorization table
>      that are directly dependent upon the operation that the client is
> willing to perform.
>
> 2=C2=B0 I propose a way to integrate FIDO, since FIDO allows to support t=
he
> user's authentication phase
>      by disclosing only a pseudonym unique to the RS.
>
> Denis
>
>
> I get that the Client<->RS step is critical to the use case, as is the
> User not interacting with the GS, but there are other use cases where the
> User does not interact with the GS, for example
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-2.3.,
> but Denis's use case should not be the only use case.
>
> So it seems that GNAP can support Denis's use case by defining the
> initial Client<->RS interaction, and the information in the user object o=
f
> the Grant Request to be what the GS needs to issue access tokens, which w=
as
> what I suggested earlier.
>
> I don't understand what is missing, besides the details of the Client<->R=
S
> interaction, and what is in the Grant Request.
>
>
> On Mon, Jul 13, 2020 at 12:22 PM Denis  wrote:
>
>> Hi Justin,
>>
>> You have perfectly understood the differences. The location where the
>> user consent is gathered *i**n a uniform way* using to the information
>> released by the RS
>> is a fundamental element of the design.
>>
>> If I=E2=80=99m understanding Denis=E2=80=99s proposal, he=E2=80=99s sayi=
ng that that =E2=80=9Cprior step=E2=80=9D
>> is the lynchpin of the whole model, since interaction between the client
>> and the RS (and the user and the RS) is key to Denis=E2=80=99s privacy m=
odel.
>> Additionally, what happens *at* each step is different. Consent is gathe=
red
>> at the client, not the GS in this diagram, for example. The GS simply mi=
nts
>> a token as specified by the client and the RS.
>>
>> It=E2=80=99s for these reasons that, as long as I=E2=80=99ve been unders=
tanding
>> correctly, I=E2=80=99ve been saying that Denis=E2=80=99s model as propos=
ed is pretty
>> different.
>>
>> Indeed.
>>
>> Denis
>>
>> But what I think isn=E2=80=99t that different is the different steps if =
you=E2=80=99re
>> willing to look at the boundaries around the boxes differently. For
>> example, what OAuth would call =E2=80=9Cthe AS=E2=80=9D might end up bei=
ng a few different
>> boxes in GNAP that do different things. I had started down that route wi=
th
>> XYZ=E2=80=99s design allowing the interaction to be managed separately.
>>
>> I think that the disconnect we=E2=80=99re seeing here might be caused by
>> vocabulary mismatches. If we aren=E2=80=99t meaning the same thing when =
we say the
>> same terms, it=E2=80=99s easy to get things mixed up with each other. Si=
nce GNAP is
>> just barely forming its vocabulary out of the legacy of OAuth and kin, w=
e
>> have a chance to maybe draw the lines better and see if that=E2=80=99s h=
ow we can
>> get things to fit.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 13, 2020, at 2:02 PM, Dick Hardt  wrote:
>>
>>
>> I'm going to just address the first part of your response so that we can
>> get clarity on that before diving into your later comments.
>>
>> The calls between your proposal and XAuth are not inverted, your proposa=
l
>> has a prior step. Step 1 in XAuth maps to Step 2 in your proposal, and S=
tep
>> 2 in XAuth is Step 3 in your proposal..
>>
>> Below are 2 diagrams showing the same steps, the first keeping the
>> existing step labels for XAuth, the latter renaming the steps to corresp=
ond
>> to your proposal. This looks pretty similar to your diagram. What am I
>> missing?
>>
>> /Dick
>>
>> DIAGRAM 1 (steps start at 0)
>>
>>        +--------+                           +------------+
>>        |  User  |                           |  Resource  |
>>        |        |                           | Owner (RO) |
>>        +--------+                           +------------+
>>            |      \                       /      |
>>            |       \                     /       |
>>            |        \                   /        |
>>            |         \                 /         |
>>        +--------+     +---------------+     +------------+
>>        | Client |---->|     Grant     |     |  Resource  |
>>        |        | (1) |  Server (GS)  | _ _ |   Server   |
>>        |        |<----|               |     |    (RS)    |
>>        |        |     +---------------+     |            |
>>        |        |-------------------------->|            |
>>        |        |           (2)             |            |
>>        |        |<--------------------------|            |
>>        |        |-------------------------->|            |
>>        |        |           (0)             |            |
>>        |        |<--------------------------|            |
>>        +--------+                           +------------+
>>
>> DIAGRAM 2 (steps start at 1)
>>
>>        +--------+                           +------------+
>>        |  User  |                           |  Resource  |
>>        |        |                           | Owner (RO) |
>>        +--------+                           +------------+
>>            |      \                       /      |
>>            |       \                     /       |
>>            |        \                   /        |
>>            |         \                 /         |
>>        +--------+     +---------------+     +------------+
>>        | Client |---->|     Grant     |     |  Resource  |
>>        |        | (2) |  Server (GS)  | _ _ |   Server   |
>>        |        |<----|               |     |    (RS)    |
>>        |        |     +---------------+     |            |
>>        |        |-------------------------->|            |
>>        |        |           (3)             |            |
>>        |        |<--------------------------|            |
>>        |        |-------------------------->|            |
>>        |        |           (1)             |            |
>>        |        |<--------------------------|            |
>>        +--------+                           +------------+
>>
>> =E1=90=A7
>>
>> On Mon, Jul 13, 2020 at 7:08 AM Denis  wrote:
>>
>>> Hello Dick,
>>>
>>> You wrote: "This looks pretty similar to your protocol drawing".
>>>
>>> No. There is a fundamental difference with the sequencing of the flow o=
f
>>> the exchanges where the (1) and (2) flows are inverted.
>>>
>>> In your figure:
>>>
>>> The Client makes calls to the GS (1)
>>> The Client makes calls to the RS (2)
>>>
>>> while in my figure:
>>>
>>> The Client makes calls to the RS (1)
>>> The Client makes calls to the AS (2)
>>>
>>> In your figure, the first flow is with the GS, whereas in my figure the
>>> first flow is with the RS and there is a good reason for that:
>>> the client first contacts the RS to know what the RS expects. The clien=
t
>>> indicates in its first exchange to the RS whether it wants to authentic=
ate
>>> or to perform another operation.  In the case of an authentication
>>> operation, the RS may respond to the client that is supports FIDO U2F
>>> or that it is willing the client to present some attribute(s) from one
>>> or more AS.
>>>
>>> Then after the client has to figure out whether the user is using FIDO
>>> and if not whether the user has an account with one of the AS.
>>> In the later case, if there is a match then the client,* *after having
>>> received the user consent**, may contact the appropriate AS to ask
>>> for some attribute(s).
>>>
>>> The same fundamental difference applies with
>>> draft-richer-transactional-authz-06 (XYZ) where the first exchange is d=
one
>>> with the AS:
>>> "The RC creates a transaction request and sends it to the AS".
>>>
>>> This answers also in details to one of your comments:
>>>
>>> What looks to be missing from your proposal is:
>>> A) The Client making a call to the RS to discover what it needs from a
>>> GS, and which GS to ask, prior to (1).
>>>
>>> This is not missing since this is the foundation of the architecture.
>>> The discovery mechanism at the RS has been described
>>> in details in an earlier email with the following title: "Support of
>>> FIDO and data minimization by RSs".
>>>
>>> The main figures are copied below (using ASCII):
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *
>>> +-----------------------------------+---------------------------------+
>>> +           Operation               +      Mathematical expression    +
>>> +-----------------------------------+---------------------------------+=
   +
>>> Authentication                    + Condition 1 OR Condition 2      +
>>> +-----------------------------------+---------------------------------+=
   +
>>> Operation A OR Operation Z        + Condition 3 AND Condition 4     +
>>> +-----------------------------------+---------------------------------+=
 **Conditions
>>> table: *
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *
>>> +-------------+--------------+-----------------------------+----------+=
   +
>>> Condition 1 + FIDO U2F 1.2 +                             +          +
>>> +-------------+--------------+-----------------------------+----------+=
   +
>>> Condition 2 + AS 1         + set 1 of a attributes types +          +
>>> +-------------+--------------+-----------------------------+----------+=
   +
>>> Condition 3 + AS 2         + set 2 of a attributes types + Scope 21 +
>>> +-------------+--------------+-----------------------------+----------+=
   +
>>> Condition 4 + AS 9         + set 3 of a attributes types-+          +
>>> +-------------+--------------+-----------------------------+----------+=
 *
>>> According to the operation announced by the Client, the RS returns to
>>> the Client both the mathematical expression
>>> associated with that operation and the conditions included in that
>>> mathematical expression. The Client may then
>>> present that information to the user in order to obtain the user consen=
t
>>> in a standardized manner.
>>> Another comment you made is:
>>>
>>> What looks to be missing from your proposal is:
>>> B) A mechanism for the Client to prove to the GS that it has gathered
>>> consent from the User.
>>>
>>> The user consent should not be captured *by the GS*, since the GS would
>>> be in a position to apply a different consent decision
>>> without letting it know to the user (or to the client).
>>>
>>> The user consent must be captured *by the Client* and the Client must b=
e
>>> able to verify that this consent has indeed been followed by the AS.
>>>
>>> The authorization data managed at the RS by the RO is used by the Clien=
t
>>> to query the consent of the user in a standardized manner.
>>> When, later on, the access token is returned to the Client by the AS,
>>> the Client (not the user) using that authorization data as well as
>>> the decision of the user is able to verify that the requested attribute=
s
>>> (and no more) are indeed present into the access token.
>>>
>>> This is why access tokens may *not* be considered to be opaque to the
>>> Clients.
>>>
>>> In my earlier email copied below, six major differences with XAuth from
>>> 1) to 6) are listed.
>>>
>>> Denis
>>>
>>> From
>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-1.1
>>>
>>> 1.1 .  Parties
>>>
>>>    The parties and their relationships to each other:
>>>
>>>        +--------+                           +------------+
>>>        |  User  |                           |  Resource  |
>>>        |        |                           | Owner (RO) |
>>>        +--------+                           +------------+
>>>            |      \                       /      |
>>>            |       \                     /       |
>>>            |        \                   /        |
>>>            |         \                 /         |
>>>        +--------+     +---------------+     +------------+
>>>        | Client |---->|     Grant     |     |  Resource  |
>>>        |        | (1) |  Server (GS)  | _ _ |   Server   |
>>>        |        |<----|               |     |    (RS)    |
>>>        |        |     +---------------+     |            |
>>>        |        |-------------------------->|            |
>>>        |        |           (2)             |            |
>>>        |        |<--------------------------|            |
>>>        +--------+                           +------------+
>>>
>>>
>>> The lines without arrows represent relationships.
>>> The User trusts the Client
>>> The User trusts the GS
>>> The RO trusts the GS to issue access tokens for the RS
>>> The RS trusts the tokens issued by the RS
>>> The RO controls the RS
>>>
>>> The Client makes calls to the GS (1)
>>> The Client makes calls to the RS (2)
>>>
>>> This looks pretty similar to your protocol drawing.
>>>
>>> What looks to be missing from your proposal is:
>>>
>>> A) The Client making a call to the RS to discover what it needs from a
>>> GS, and which GS to ask, prior to (1).
>>> B) A mechanism for the Client to prove to the GS that it has gathered
>>> consent from the User.
>>>
>>> The current protocol does not require the GS to interact with either th=
e
>>> User, the RO, or the RS -- which looks to me to meet your privacy goals=
.
>>>
>>> =E1=90=A7
>>>
>>> On Fri, Jul 10, 2020 at 6:06 AM Denis  wrote:
>>>
>>>> Hi Dick,
>>>>
>>>> Hi Denis, thanks for sharing the model. I don't fully understand what
>>>> is going on, questions inserted:
>>>>
>>>> Responses are inserted.
>>>>
>>>>
>>>> FWIW: having paragraphs start with the step number (1), (2) etc. would
>>>> make it easier to map between the description and the diagram.
>>>>
>>>> On Thu, Jul 9, 2020 at 3:26 AM Denis  wrote:
>>>>
>>>>> This is a new thread.
>>>>>
>>>>> Preamble: This model is quite different from the XAuth model.
>>>>> In particular, a RO has no relationship with any AS and a Client does
>>>>> not need to be associated with any AS prior to any access to a RS.
>>>>>
>>>>> A key point of this model is that the user's consent is handled
>>>>> locally by the Client and hence no AS nor RS is handling a man machin=
e
>>>>> interface
>>>>> for the user consent. This allows to support locally the user consent
>>>>> for multiple ASs while keeping all ASs ignorant about the choices of =
the
>>>>> user
>>>>> made for accessing a particular RS.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *       +--------+                           +------------+        |
>>>>> User  |                           |  Resource  |        |
>>>>> |                           | Owner (RO) |        +--------+
>>>>>                   +------------+            |
>>>>> \                              |            |
>>>>> \                             |            |
>>>>> \                            |            |
>>>>> \                           |     +-----------+     +---------------+
>>>>> +------------+     |           |---->| Authorization |     |         =
   |
>>>>>     |           | (2) |  Server (AS)  |     |            |     |
>>>>> |<----|               |     |            |     |  Client   |
>>>>> +---------------+     |            |     |
>>>>> |-------------------------->|  Resource  |     |   User    |
>>>>> (1)             |   Server   |     |  Consent
>>>>> |<--------------------------|    (RS)    |     |  element
>>>>> |                           |            |     |
>>>>> |-------------------------->|            |------>     |
>>>>> |           (3)             |            |  (4)     |
>>>>> |<--------------------------|            |<------
>>>>> +-----------+                           +------------+ *
>>>>> The flow of operations is as follows:
>>>>>
>>>>> The Client (which may have been previously authenticated using FIDO)
>>>>>
>>>> Which party has the client authenticated to? The client authenticating
>>>> with FIDO is confusing to me. FIDO is usually how a user authenticates=
.
>>>>
>>>> If the user has previously opened a user account with the RS using
>>>> FIDO, then the client may be authenticated by the RS using FIDO.
>>>> In such a case, the user is already known to the RS under a pseudonym
>>>> specific to the RS. It may (or may not) have previously presented acce=
ss
>>>> tokens
>>>> to that RS.
>>>>
>>>>  contacts the RS and after some dialogue with the RS selects an
>>>> operation
>>>> How does the client know which RS to contact?
>>>>
>>>> For a private usage, the user may use DuckDuckGo, while for business h=
e
>>>> may use an application from his company which lists various services
>>>> available in the context of his job or his position. Some services may
>>>> be freely available to all the employees of the company with any
>>>> authentication,
>>>> e.g. the phone book of the employees may be freely available on the
>>>> intranet of the company, while some other services may require the use=
r
>>>> to authenticate to the AS from the company.
>>>>
>>>>  that it wants to perform on the RS (1a). Note that it may also
>>>> indicate directly the operation that it wants to perform on the RS wit=
hout
>>>> any prior dialogue.
>>>>
>>>>> In return (1b), the RS informs the Client about which attributes are
>>>>> needed by the RS for performing the requested operation and from whic=
h
>>>>> Attributes Servers
>>>>> they may be obtained.
>>>>>
>>>> (1a) and (1b) are not labeled. There is only (1)
>>>>
>>>> (1a) is the first exchange for (1) with the arrow from left to right,
>>>> while (1b) is the response with the arrow from right to left.
>>>> The same applies to the other exchanges i.e. (2) , (3) and (4).
>>>>
>>>>
>>>>> This information is specifically marked to indicate that it shall be
>>>>> handled by the "User Consent element" from the Client.
>>>>>
>>>> Why? What is the significance of this? Which information is marked?
>>>>
>>>> In the response, a specific identifier or a magic number is used to
>>>> indicate the start and the length of the information block
>>>> to be sent to the "User Consent element" supported by the Client.
>>>>
>>>> The presentation of that information is up to the man machine interfac=
e
>>>> supported by the "User Consent element" from the Client.
>>>>
>>>> Which information?
>>>>
>>>> The attributes that are needed by the RS for performing a requested
>>>> operation and from which Attributes Servers they may be obtained.
>>>>
>>>>
>>>>> The user can see which attributes are requested by the RS for
>>>>> performing the requested operation and, if it consents, the Client co=
ntacts
>>>>> one or more
>>>>> appropriate Authorization Servers (2a).
>>>>>
>>>> How does the client know which AS(s) to contact?
>>>>
>>>> For each AS trusted by the RS to perfom a given operation, the RS
>>>> should indicate a user-friendly name and a URL of the AS.
>>>>
>>>> The user consent is hence captured locally by the Client (i.e. there i=
s
>>>>> no dialogue with any AS nor any RS).
>>>>>
>>>>
>>>> No dialogue with who? The client is calling the AS is it not?
>>>>
>>>> For the user consent, there is no external call since it is handled
>>>> locally. Afterwards, there is a call to the AS(s) selected by the user=
.
>>>>
>>>>
>>>>> When the Client got the access tokens from these authorization server=
s
>>>>> (2b), it sends all of them in a single request to the RS (3a).
>>>>>
>>>>
>>>> So the RS must trust the AS that issued the tokens. And the AS must
>>>> trust the Client to have gathered consent.
>>>>
>>>> Theses two assertions are correct.
>>>>
>>>> And the AS must have a relationship with the user.
>>>>
>>>> Only when the user chooses one AS while giving its consent, then the
>>>> user must have a relationship with the selected AS.
>>>>
>>>> It is unclear what role the RO is playing in this though. The RO and R=
S
>>>> look to be the same entity from all the other parties.
>>>>
>>>> A RO, as indicated on the figure, has only a relationship with one RS:
>>>> it has no relationship with any AS.
>>>> The RS trusts the AS but the AS does not know which RSs are trusting i=
t.
>>>>
>>>>
>>>> From my current understanding, at a high level, this looks like it is
>>>> supported by GNAP with the addition of the discovery step (1).
>>>>
>>>> Well, it is fairly different :
>>>>
>>>> 1) The first major difference is that there is no arrow between the RO
>>>> and the AS. No protocol or "out-of-bands" means are necessary.
>>>>
>>>> 2) The second major difference is that there is no arrow between the A=
S
>>>> and the RS. No protocol is necessary.
>>>>
>>>> 3) The third major difference is that the AS does not know any RS.
>>>> Note: for backward compatibility reasons, an exception might exist for
>>>> "old" Auth 2.0 ASs.
>>>>
>>>> 4) The fourth major difference is that the XAuth spec. is rather vague
>>>> to describe when and by who the user consent is captured:
>>>>     XAuth states on page 4: "User consent is *often *required at the
>>>> GS". In that case, the GS is able to act as Big Brother. No other case=
 is
>>>> described.
>>>> 5) The fifth major difference is that the data that is transferred to =
a
>>>> "User Consent Element" to capture the user consent. That data can be
>>>> standardized.
>>>>     Moreover, it will also be possible to standardize the dialogue
>>>> between the RO and the RS. The RO will then be able to manage remotely=
 the
>>>> authorization tables.
>>>>     See my email sent on June 6, with the following subject: "Support
>>>> of FIDO and data minimization by RSs".
>>>>
>>>> 6) Another difference is the following: since there is no interaction
>>>> between the RO and the AS, "authorizations from the RO" as described i=
n
>>>> XAuth do not exist.
>>>>
>>>> There have been a number of proposals for doing this discovery, and
>>>> perhaps now there are enough use cases to look at standardizing someth=
ing.
>>>> No interaction is needed between the AS and the User as the Client is
>>>> providing enough "information" in the user object of the Grant Request
>>>> to satisfy the AS releasing the access tokens.
>>>>
>>>> Not sure I understand correctly this last sentence.
>>>>
>>>>
>>>> Perhaps as I understand the model in more detail I will understand wha=
t
>>>> is missing from GNAP (besides the discovery step).
>>>>
>>>> It would be hard to say "what is missing" from XAuth since the
>>>> foundations are not the same.
>>>>
>>>> In order to compare different architectures, there is the need to star=
t
>>>> with the trust relationships.
>>>> Unfortunately, the word "trust" is absent in the main body of
>>>> draft-hardt-xauth-protocol-12. Hence,
>>>> the description of the trust relationships is missing.
>>>>
>>>> Denis
>>>>
>>>>
>>>> /Dick
>>>>
>>>> (I've skipped reviewing the delegation use case below until I
>>>> understand the simple use case)
>>>>
>>>>
>>>>> End of the story for a simple access
>>>>>
>>>>>
>>>>> Start of a subsequent story for a delegation case
>>>>>
>>>>> Let us now suppose that the RS is unable to fulfil the request by its
>>>>> own and that it needs to contact another RS. RS1 contacts RS2 (4a) an=
d
>>>>> indicates the operation
>>>>> that it wants to perform on RS2 (that operation may not be the same a=
s
>>>>> the original operation). In return (4b), RS2 informs RS1 about which
>>>>> attributes are needed
>>>>> by RS2 for performing the requested operation and from which
>>>>> Attributes Servers they may be obtained. RS1 forwards that informatio=
n to
>>>>> the Client.
>>>>>
>>>>> This information is marked to indicate that it shall be handled by th=
e
>>>>> "User Consent element" from the Client. The presentation of that
>>>>> information is up to the man machine
>>>>> interface from the Client. The user can see which attributes are
>>>>> requested by RS2 for performing the new requested operation and, if i=
t
>>>>> consents, the Client contacts one or more
>>>>> appropriate Authorization Servers. The user consent is hence captured
>>>>> locally by the "User Consent element" from the Client. (i.e. there is=
 no
>>>>> dialogue with any AS, nor RS1, nor RS2).
>>>>>
>>>>> When the Client got the access token(s) from the authorization
>>>>> server(s), it sends all of them in a single request to RS1. RS1 then
>>>>> forwards the additional access token(s) to RS2.
>>>>>
>>>>>
>>>>> Some observations:
>>>>>
>>>>> The user nor the Client are linked with any particular AS. A user may
>>>>> use today an AS of the Bank of America and may change tomorrow to the=
 Bank
>>>>> of Missouri.
>>>>> As soon as he will be registered with the Bank of Missouri, he will b=
e
>>>>> able to get access tokens from the AS of the Bank of Missouri. The AS=
 of
>>>>> Bank of America
>>>>> has not been able to know where its access tokens have been used. Thi=
s
>>>>> will be the same for AS of the Bank of Missouri. There is no need for=
 any
>>>>> direct dialogue
>>>>> between any AS and any RS at the time a client is making an access.
>>>>> There is no need for any RO to contact any AS.
>>>>>
>>>>> This model has been constructed following a "Privacy by Design"
>>>>> approach.
>>>>> Denis
>>>>>
>>>>> --
>>>>> Txauth mailing list
>>>>> Txauth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>
>>>> =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
>>
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--00000000000007706505aa586b86
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Denis: it looks like we are talking past each other.
<=
br>
Are you suggesting that GNAP ONLY as you have proposed=
?

Otherwise, it looks to me like your requirements=
 can be added to GNAP.

3D""=E1=90=A7<=
/div>
O=
n Mon, Jul 13, 2020 at 1:06 PM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Dick,

    


    

    
You wrote: "I don't understand what is
      missing". The response is in my previous email.

      The user consent is always requested by the Client and
      hence it is never requested by the GS/AS.

    


    

    
Two other important points:

    


    

    
1=C2=B0 At the first exchange, the RS
      discloses the elements of an authorization table 

      =C2=A0=C2=A0=C2=A0=C2=A0 that are directly dependent upon the operati=
on that the
      client is willing to perform.

    
 

    

    
2=C2=B0 I propose a way to integrate FIDO,
      since FIDO allows to support the user's authentication phase 

      =C2=A0=C2=A0=C2=A0=C2=A0 by disclosing only a pseudonym unique to the=
 RS.

    


    

    
Denis

    


    

    

    

     =20
      

        

          
I get that the Client<->RS step is
            critical to the use case, as is the User not interacting
            with the GS, but there are other use cases where the User
            does not interact with the GS, for example=C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#secti=
on-2.3.,
            but Denis's use case should not be the only use case.=C2=A0
            


            

            
So it seems that GNAP can support Denis's use case
              by=C2=A0defining the initial=C2=A0Client<->RS interacti=
on, and
              the=C2=A0information in the user object of the Grant Request =
to
              be what the GS needs to issue access tokens, which was
              what I suggested earlier.

            


            

            
I don't understand what is missing, besides the detail=
s
              of the Client<->RS interaction, and what is in the
              Grant Request.

            


            

          

        

      

      

      

        
On Mon, Jul 13, 2020 at 12:22
          PM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hi Justin,

            


            

            
You have perfectly understood the differences. The
              location where the user consent is gathered in
                a uniform way using to the information released by
              the RS 

              is a fundamental element of the design.=C2=A0 

            

            

            
 If I=E2=80=99m understanding Denis=
=E2=80=99s
              proposal, he=E2=80=99s saying that that =E2=80=9Cprior step=
=E2=80=9D is the
              lynchpin of the whole model, since interaction between the
              client and the RS (and the user and the RS) is key to
              Denis=E2=80=99s privacy model. Additionally, what happens *at=
*
              each step is different. Consent is gathered at the client,
              not the GS in this diagram, for example. The GS simply
              mints a token as specified by the client and the RS.
              


              

              
It=E2=80=99s for these reasons that, as long as I=E2=80=
=99ve been
                understanding correctly, I=E2=80=99ve been saying that Deni=
s=E2=80=99s
                model as proposed is pretty different. 

            

            
Indeed.

            
Denis

            

            

              
But what I think isn=E2=80=99t that different is the
                different steps if you=E2=80=99re willing to look at the
                boundaries around the boxes differently. For example,
                what OAuth would call =E2=80=9Cthe AS=E2=80=9D might end up=
 being a few
                different boxes in GNAP that do different things. I had
                started down that route with XYZ=E2=80=99s design allowing =
the
                interaction to be managed separately.=C2=A0

              


              

              
I think that the disconnect we=E2=80=99re seeing here mi=
ght
                be caused by vocabulary mismatches. If we aren=E2=80=99t me=
aning
                the same thing when we say the same terms, it=E2=80=99s eas=
y to
                get things mixed up with each other. Since GNAP is just
                barely forming its vocabulary out of the legacy of OAuth
                and kin, we have a chance to maybe draw the lines better
                and see if that=E2=80=99s how we can get things to fit.

                


                

                
=C2=A0=E2=80=94 Justin

                  


                    

                      
On Jul 13, 2020, at 2:02 PM, Dick Hardt <dick.hardt@gmail.com<=
/a>>
                        wrote:

                      

                      

                        


                          
I'm going to just address the first part
                            of your response so that we can get clarity
                            on that before diving into your later
                            comments.

                          


                          

                          
The calls between your proposal and XAuth
                            are not inverted, your proposal has a prior
                            step. Step 1 in XAuth maps to Step 2 in your
                            proposal, and Step 2 in XAuth is Step 3 in
                            your proposal..

                          


                          

                          
Below are 2 diagrams showing the same
                            steps, the first keeping the existing step
                            labels for XAuth, the latter renaming the
                            steps to correspond to your proposal. This
                            looks pretty similar to your diagram. What
                            am I missing?

                          


                          

                          
/Dick

                          


                          

                          

                            
DIAGRAM 1 (step=
s start at 0)

                            
       +-------=
-+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (0)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+

                            
DIAGRAM 2 (step=
s start at 1)

                            
       +--------+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (2) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (3)             |            |
       |        |<--------------------------|            |
       |        |-------------------------->|            |
       |        |           (1)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+

                          

                        

                        
3D""=E1=90=A7

                        

                        

                          
On Mon, Jul
                            13, 2020 at 7:08 AM Denis <denis.ietf@free.fr>
                            wrote:

                          

                          

                            

                              
Hello Dick,

                              


                              

                              
You wrote: "This looks pretty simil=
ar
                                to your protocol drawing".

                                

                              

                              
No. There is a fundamental difference
                                with the sequencing of the flow of the
                                exchanges where the (1) and (2) flows
                                are inverted. 

                              

                              


                              

                              
In your figure:

                              

                              

                                

                                  
The Client makes calls to the GS
                                    (1)

                                  
The Client makes calls to the RS
                                    (2)

                                

                                
while in my figure:

                                

                                  

                                    
The Client makes calls to the
                                      RS (1)

                                    
The Client makes calls to the
                                      AS (2)

                                  

                                

                              

                              
In your figure, the first flow is
                                with the GS, whereas in my figure the
                                first flow is with the RS and there is a
                                good reason for that: 

                                the client first contacts the RS to know
                                what the RS expects. The client
                                indicates in its first exchange to the
                                RS whether it wants to authenticate 

                                or to perform another operation.=C2=A0 In t=
he
                                case of an authentication operation, the
                                RS may respond to the client that is
                                supports FIDO U2F 

                                or that it is willing the client to
                                present some attribute(s) from one or
                                more AS.

                              


                              

                              
Then after the client has to figure
                                out whether the user is using FIDO and
                                if not whether the user has an account
                                with one of the AS.

                              
In the later case, if there is a
                                match then the client, *after having
                                  received the user consent*, may
                                contact the appropriate AS to ask 

                                for some attribute(s). 

                              

                              


                              

                              
The same fundamental difference
                                applies with
                                draft-richer-transactional-authz-06
                                (XYZ) where the first exchange is done
                                with the AS:

                              
"The RC creates a transaction reque=
st
                                and sends it to the AS".

                              


                              

                              
This answers also in details to one
                                of your comments:

                              

                                

                                  
What looks to be missing from
                                    your proposal is:

                                  
A) The Client making a call to
                                    the RS to discover what it needs
                                    from a GS, and which GS to ask,
                                    prior to (1).

                                

                              

                              
This is not missing since this is the
                                foundation of the architecture. The
                                discovery mechanism at the RS has been
                                described 

                                in details in an earlier email with the
                                following title: "Support of FIDO and
                                data minimization by RSs".

                              


                              

                              
The main figures are copied below
                                (using ASCII):
                                
=
=C2=A0
                                        +---------------------------=
--------+---------------------------------+

                                        =C2=A0 +=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                        Operation=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                        +=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 Mathematical
                                        expression=C2=A0=C2=A0=C2=A0 =
+

                                        =C2=A0 +--------------=
---------------------+---------------------------------+

                                        =C2=A0 + Authenticatio=
n=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                        + Condition 1 OR
                                        Condition 2=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 +

                                        =C2=A0 +--------------=
---------------------+---------------------------------+

                                        =C2=A0 + Operation A O=
R
                                        Operation Z=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 +
                                        Condition 3 AND Condition 4=
=C2=A0=C2=A0=C2=A0=C2=A0
                                        +

                                        =C2=A0 +--------------=
---------------------+---------------------------------+

                                        

                                      Conditions table: 

                                        

                                        =C2=A0 +-------------+=
--------------+-----------------------------+----------+

                                        =C2=A0 + Condition 1 +
                                        FIDO U2F 1.2 +=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
                                        +=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +

                                        =C2=A0 +-------------+=
--------------+-----------------------------+----------+

                                        =C2=A0 + Condition 2 +
                                        AS 1=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 + set
                                        1 of a attributes types + =C2=
=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+

                                        =C2=A0 +-------------+=
--------------+-----------------------------+----------+

                                        =C2=A0 + Condition 3 +
                                        AS 2=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 + set
                                        2 of a attributes types + Scope
                                        21 +

                                        =C2=A0 +-------------+=
--------------+-----------------------------+----------+

                                        =C2=A0 + Condition 4 +
                                        AS 9=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 + set
                                        3 of a attributes types-+ =C2=
=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+

                                        =C2=A0 +-------------+=
--------------+-----------------------------+----------+

                                    

                                  According to the operation announced
                                  by the Client, the RS returns to the
                                  Client both the mathematical
                                  expression 

                                  associated with that operation and the
                                  conditions included in that
                                  mathematical expression. The Client
                                  may then 

                                  present that information to the user
                                  in order to obtain the user consent in
                                  a standardized manner.

                                

                              

                              
Another comment you made is:

                              

                                
What looks to be missing from your
                                  proposal is:

                                
B) A mechanism for the Client to
                                  prove to the GS that it has gathered
                                  consent from the User.

                              

                              
The user consent should not be
                                captured *by the GS*, since the GS would
                                be in a position to apply a different
                                consent decision 

                                without letting it know to the user (or
                                to the client).

                              


                                The user consent must be captured *by
                                the Client* and the Client must be able
                                to verify that this consent has indeed
                                been followed by the AS. 

                              

                              


                              

                              
The authorization data managed at the
                                RS by the RO is used by the Client to
                                query the consent of the user in a
                                standardized manner.

                              
When, later on, the access token is
                                returned to the Client by the AS, the
                                Client (not the user) using that
                                authorization data as well as 

                                the decision of the user is able to
                                verify that the requested attributes
                                (and no more) are indeed present into
                                the access token. 

                                

                                This is why access tokens may *not* be
                                considered to be opaque to the Clients.
                              


                              

                              
In my earlier email copied below, six
                                major differences with XAuth from 1) to
                                6) are listed.

                              


                              

                              
Denis

                                

                              

                              

                                
From=C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-=
1.1
                                  


                                    

                                      
1.1.  Parties


   The parties and their relationships to each other:


                                      
       +-------=
-+                           +------------+
       |  User  |                           |  Resource  |
       |        |                           | Owner (RO) |
       +--------+                           +------------+
           |      \                       /      |
           |       \                     /       |
           |        \                   /        |
           |         \                 /         |
       +--------+     +---------------+     +------------+
       | Client |---->|     Grant     |     |  Resource  |
       |        | (1) |  Server (GS)  | _ _ |   Server   |
       |        |<----|               |     |    (RS)    |
       |        |     +---------------+     |            |
       |        |-------------------------->|            |
       |        |           (2)             |            |
       |        |<--------------------------|            |
       +--------+                           +------------+



                                    

                                    

                                      


                                      

                                      
The lines without arrows
                                        represent relationships.=C2=A0
                                    

                                  

                                  
The User trusts the Client

                                  
The User trusts the GS

                                  
The RO trusts the GS to issue
                                    access tokens for the RS

                                  
The RS trusts the tokens issued
                                    by the RS

                                  
The RO controls the RS

                                  


                                  

                                  
The Client makes calls to the GS
                                    (1)

                                  
The Client makes calls to the RS
                                    (2)

                                  


                                  

                                  
This looks pretty similar to your
                                    protocol drawing.

                                  


                                  

                                  
What looks to be missing from
                                    your proposal is:

                                  


                                  

                                  
A) The Client making a call to
                                    the RS to discover what it needs
                                    from a GS, and which GS to ask,
                                    prior to (1).

                                  
B) A mechanism for the Client to
                                    prove to the GS that it has gathered
                                    consent from the User.

                                  


                                  

                                  
The current protocol does not
                                    require the GS to interact with
                                    either the User, the RO, or the RS
                                    -- which looks to me to meet your
                                    privacy=C2=A0goals.

                                  


                                  

                                

                                
3D""=E1=90=A7

                                

                                

                                  
On
                                    Fri, Jul 10, 2020 at 6:06 AM Denis
                                    <denis.ietf@free.fr>
                                    wrote:

                                  

                                  

                                    

                                      
Hi Dick,

                                      


                                      

                                      

                                        

                                          
Hi Denis,
                                            thanks for sharing the
                                            model. I don't fully
                                            understand what is going on,
                                            questions inserted:

                                        

                                      

                                      Responses are inserted.

                                      

                                        

                                          

                                            


                                            

                                            
FWIW: having paragraphs
                                              start with the step number
                                              (1), (2) etc. would make
                                              it easier to map between
                                              the description and the
                                              diagram.

                                          

                                          

                                          

                                            
On Thu,
                                              Jul 9, 2020 at 3:26 AM
                                              Denis <denis.ietf@free.fr>
                                              wrote:

                                            

                                            

                                              

                                                

                                                  
T=
his
                                                      is a new thread.

                                                      

                                                      Preamble: This
                                                      model is quite
                                                      different from the
                                                      XAuth model. 

                                                      In particular, a
                                                      RO has no
                                                      relationship with
                                                      any AS and a
                                                      Client does not
                                                      need to be
                                                      associated with
                                                      any AS prior to
                                                      any access to a
                                                      RS.

                                                      

                                                      A key point of
                                                      this model is that
                                                      the user's consen=
t
                                                      is handled locally
                                                      by the Client and
                                                      hence no AS nor RS
                                                      is handling a man
                                                      machine interface
                                                      

                                                      for the user
                                                      consent. This
                                                      allows to support
                                                      locally the user
                                                      consent for
                                                      multiple ASs while
                                                      keeping all ASs
                                                      ignorant about the
                                                      choices of the
                                                      user 

                                                      made for accessing
                                                      a particular RS.

                                                      

                                                        

                                                        <=
b>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          +--------+=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
                                                          +---------=
---+

                                                          =C2=A0=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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=C2=A0
                                                          |

                                                          =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                                                          |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
                                                          | Owner
                                                          (RO) |

                                                          =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0
                                                          =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+------------+

                                                          =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          \=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0
                                                          |

                                                          =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          \=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
                                                          |

                                                          =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          \=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                                                          |

                                                          =C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          \=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
                                                          |

                                                          =C2=A0=C2=
=A0=C2=A0 +-----------+=C2=A0
                                                          =C2=
=A0=C2=A0=C2=A0+---------------+=C2=A0=C2=A0=C2=A0=C2=A0
                                                          +---------=
---+

                                                          =C2=A0=C2=
=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                                                          |---->|
                                                          Authorization
                                                          |=C2=A0=C2=
=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0
                                                          |

                                                          =C2=A0=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) |=C2=A0
                                                          Server
                                                          (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=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0
                                                          |

                                                          =C2=A0=C2=
=A0=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          (1)=
=C2=A0=C2=A0=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=C2=A0 |=C2=A0
                                                          Consent=C2=A0
                                                          |<-----=
---------------------|=C2=A0=C2=A0=C2=A0
                                                          (RS)=
=C2=A0=C2=A0=C2=A0
                                                          |

                                                          =C2=A0=C2=
=A0=C2=A0 |=C2=A0
                                                          element=C2=A0
                                                          |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
                                                          |=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          |

                                                          =C2=A0=C2=
=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                                                          |---------=
----------------->|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0
                                                          |------>=
;

                                                          =C2=A0=C2=
=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          |=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 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                                                          |<-----=
---------------------|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0
                                                          |<-----=
-

                                                          =C2=A0=C2=
=A0=C2=A0 +-----------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 flow of
                                                      operations is as
                                                      follows:

                                                      

                                                      The Client (which
                                                      may have been
                                                      previously
                                                      authenticated
                                                      using FIDO) 
                                                

                                              

                                            

                                            
Which party has the
                                              client authenticated to?
                                              The client authenticating
                                              with FIDO is confusing to
                                              me. FIDO is usually how a
                                              user authenticates.

                                          

                                        

                                      

                                      
If the user has previously
                                        opened a user account with the
                                        RS using FIDO, then the client
                                        may be authenticated by the RS
                                        using FIDO.

                                        In such a case, the user is
                                        already known to the RS under a
                                        pseudonym specific to the RS. It
                                        may (or may not) have previously
                                        presented access tokens 

                                        to that RS.

                                      

                                      

                                        

                                          

                                            
=C2=A0contacts
                                                the RS and after some
                                                dialogue with the RS
                                                selects an operation 

                                              

                                            
How does the client
                                              know which RS to contact?
                                          

                                        

                                      

                                      
For a private usage, the user
                                        may use DuckDuckGo, while for
                                        business he may use an
                                        application from his company
                                        which lists various services 

                                        available in the context of his
                                        job or his position. Some
                                        services may be freely available
                                        to all the employees of the
                                        company with any authentication,
                                        e.g. the phone book of the
                                        employees may be freely
                                        available on the intranet of the
                                        company, while some other
                                        services may require the user 

                                        to authenticate to the AS from
                                        the company.

                                      

                                        

                                          

                                            
=C2=A0that
                                                it wants to perform on
                                                the RS (1a). Note that
                                                it may also indicate
                                                directly the operation
                                                that it wants to perform
                                                on the RS without any
                                                prior dialogue. 

                                              <=
/div>
                                            

                                              

                                                

                                                  

                                                      In return (1b),
                                                      the RS informs the
                                                      Client about which
                                                      attributes are
                                                      needed by the RS
                                                      for performing the
                                                      requested
                                                      operation and from
                                                      which Attributes
                                                      Servers 

                                                      they may be
                                                      obtained. 

                                                    

                                                

                                              

                                            

                                            
(1a) and (1b) are not
                                              labeled. There is only (1)
                                              

                                            

                                          

                                        

                                      

                                      
(1a) is the first exchange for
                                        (1) with the arrow from left to
                                        right, while (1b) is the
                                        response with the arrow from
                                        right to left. 

                                        The same applies to the other
                                        exchanges i.e. (2) , (3) and
                                        (4).

                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                      

                                                      This information
                                                      is specifically
                                                      marked to indicate
                                                      that it shall be
                                                      handled by the
                                                      "User Consent
                                                      element" from th=
e
                                                      Client. 

                                                    

                                                

                                              

                                            

                                            
Why? What is the
                                              significance of this?
                                              Which information is
                                              marked?

                                          

                                        

                                      

                                      
In the response, a specific
                                        identifier or a magic number is
                                        used to indicate the start and
                                        the length of the information
                                        block=C2=A0 

                                        to be sent to the "User Consent
                                          element" supported by the
                                          Client.

                                      

                                      

                                        

                                          

                                            

                                              
The
                                                  presentation of that
                                                  information is up to
                                                  the man machine
                                                  interface supported by
                                                  the "User Consent
                                                  element" from the
                                                  Client. 

                                                

                                            

                                            


                                            

                                            
Which information? 

                                            

                                          

                                        

                                      

                                      
The
                                          attributes that are needed by
                                          the RS for performing a
                                          requested operation and from
                                          which Attributes Servers they
                                          may be obtained.

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                      

                                                      The user can see
                                                      which attributes
                                                      are requested by
                                                      the RS for
                                                      performing the
                                                      requested
                                                      operation and, if
                                                      it consents, the
                                                      Client contacts
                                                      one or more 

                                                      appropriate
                                                      Authorization
                                                      Servers (2a). =


                                                

                                              

                                            

                                            
How does the client
                                              know which AS(s) to
                                              contact?

                                          

                                        

                                      

                                      
For each AS trusted by the RS
                                        to perfom a given operation, the
                                        RS should indicate a
                                        user-friendly name and a URL of
                                        the AS. 

                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
T=
he
                                                      user consent is
                                                      hence captured
                                                      locally by the
                                                      Client (i.e. there
                                                      is no dialogue
                                                      with any AS nor
                                                      any RS).

                                                    

                                                

                                              

                                            

                                            


                                            

                                            
No dialogue with who?
                                              The client is calling the
                                              AS is it not? 

                                            

                                          

                                        

                                      

                                      
For the user consent, there is
                                        no external call since it is
                                        handled locally. Afterwards,
                                        there is a call to the AS(s)
                                        selected by the user.

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                      

                                                      When the Client
                                                      got the access
                                                      tokens from these
                                                      authorization
                                                      servers (2b), it
                                                      sends all of them
                                                      in a single
                                                      request to the RS
                                                      (3a).

                                                    

                                                

                                              

                                            

                                            


                                            

                                            
So the RS must trust
                                              the AS that issued the
                                              tokens. And the AS must
                                              trust the Client to have
                                              gathered consent.

                                          

                                        

                                      

                                      Theses two assertions are correct.
                                      

                                        

                                          

                                            
 And the AS must have a
                                              relationship with the
                                              user. 

                                          

                                        

                                      

                                      
Only when the user chooses one
                                        AS while giving its consent,
                                        then the user must have a
                                        relationship with the selected
                                        AS.

                                      

                                        

                                          

                                            
It is unclear what role
                                              the RO is playing in this
                                              though. The RO and RS look
                                              to be the same entity from
                                              all the other parties.

                                          

                                        

                                      

                                      
A RO, as indicated on the
                                        figure, has only a relationship
                                        with one RS: it has no
                                        relationship with any AS. 

                                        The RS trusts the AS but the AS
                                        does not know which RSs are
                                        trusting it.

                                      

                                        

                                          

                                            


                                            

                                            
From my current
                                              understanding, at a high
                                              level, this looks like it
                                              is supported by GNAP with
                                              the addition of the
                                              discovery step (1). 

                                          

                                        

                                      

                                      
Well, it is fairly different :
                                        

                                      

                                      

                                        
1) The first major difference
                                          is that there is no arrow
                                          between the RO and the AS. No
                                          protocol or "out-of-bands&qu=
ot;
                                          means are necessary. 

                                        

                                        
2) The second major
                                          difference is that there is no
                                          arrow between the AS and the
                                          RS. No protocol is necessary.
                                        

                                        
3) The third major difference
                                          is that the AS does not know
                                          any RS. Note: for backward
                                          compatibility reasons, an
                                          exception might exist for
                                          "old" Auth 2.0 ASs.

                                        

                                        
4) The fourth major
                                          difference is that the XAuth
                                          spec. is rather vague to
                                          describe when and by who the
                                          user consent is captured: 

                                          =C2=A0=C2=A0=C2=A0 XAuth states o=
n page 4:
                                          "User consent is often required
                                          at the GS". In that case, th=
e
                                          GS is able to act as Big
                                          Brother. No other case is
                                          described.

                                        

                                        5) The fifth major difference is
                                        that the data that is
                                        transferred to a "User Consent
                                        Element" to capture the user
                                        consent. That data can be
                                        standardized. 

                                        =C2=A0=C2=A0=C2=A0 Moreover, it wil=
l also be
                                        possible to standardize the
                                        dialogue between the RO and the
                                        RS. The RO will then be able to
                                        manage remotely the
                                        authorization tables.

                                        =C2=A0=C2=A0=C2=A0 See my email sen=
t on June 6,
                                        with the following subject:
                                        "Support of FIDO and data
                                        minimization by RSs".

                                        

                                        6) Another difference is the
                                        following: since there is no
                                        interaction between the RO and
                                        the AS, "authorizations from t=
he
                                        RO" as described in XAuth do n=
ot
                                        exist. =C2=A0 

                                      

                                        

                                          

                                            
There have been a
                                              number of proposals for
                                              doing this discovery, and
                                              perhaps now there are
                                              enough use cases to look
                                              at standardizing
                                              something.=C2=A0 

                                              No interaction=C2=A0is needed
                                              between the AS and the
                                              User as the Client is
                                              providing enough
                                              "information" in th=
e user
                                              object of the Grant
                                              Request 

                                              to satisfy the AS
                                              releasing the access
                                              tokens. 

                                            

                                          

                                        

                                      

                                      Not sure I understand correctly
                                      this last sentence.

                                      

                                        

                                          

                                            


                                            

                                            
Perhaps as I understand
                                              the model in more detail I
                                              will understand what is
                                              missing from GNAP (besides
                                              the discovery step).

                                          

                                        

                                      

                                      
It would be hard to say "what
                                        is missing" from XAuth since t=
he
                                        foundations are not the same.

                                      
In order to compare different
                                        architectures, there is the need
                                        to start with the trust
                                        relationships. 

                                        Unfortunately, the word "trust=
"
                                        is absent in the main body of
                                        draft-hardt-xauth-protocol-12.
                                        Hence, 

                                        the description of the trust
                                        relationships is missing.

                                      

                                      
Denis

                                      

                                        

                                          

                                            


                                            

                                            
/Dick

                                            


                                            

                                            
(I've skipped reviewin=
g
                                              the delegation use case
                                              below until I understand
                                              the simple use case)

                                            


                                            

                                            

                                              

                                                

                                                  

                                                      

                                                      End of the story
                                                      for a simple
                                                      access

                                                  

                                                      

                                                      Start of a
                                                      subsequent story
                                                      for a delegation
                                                      case

                                                      

                                                      Let us now suppose
                                                      that the RS is
                                                      unable to fulfil
                                                      the request by its
                                                      own and that it
                                                      needs to contact
                                                      another RS. RS1
                                                      contacts RS2 <=
span lang=3D"EN-US">(4a)
                                                      and
                                                      indicates the
                                                      operation 

                                                      that it wants to
                                                      perform on RS2
                                                      (that operation
                                                      may not be the
                                                      same as the
                                                      original
                                                      operation). In
                                                      return (4b), RS2
                                                      informs RS1 about
                                                      which attributes
                                                      are needed 

                                                      by RS2 for
                                                      performing the
                                                      requested
                                                      operation and from
                                                      which Attributes
                                                      Servers they may
                                                      be obtained. RS1
                                                      forwards that
                                                      information to the
                                                      Client. 

                                                      

                                                      This information
                                                      is marked to
                                                      indicate that it
                                                      shall be handled
                                                      by the "User
                                                      Consent element"
                                                      from the Client.
                                                      The presentation
                                                      of that
                                                      information is up
                                                      to the man machine
                                                      

                                                      interface from the
                                                      Client. The user
                                                      can see which
                                                      attributes are
                                                      requested by RS2
                                                      for performing the
                                                      new requested
                                                      operation and, if
                                                      it consents, the
                                                      Client contacts
                                                      one or more 

                                                      appropriate
                                                      Authorization
                                                      Servers. The user
                                                      consent is hence
                                                      captured locally
                                                      by the "User
                                                      Consent element"
                                                      from the Client.
                                                      (i.e. there is no
                                                      dialogue with any
                                                      AS, nor RS1, nor
                                                      RS2). 

                                                      

                                                      When the Client
                                                      got the access
                                                      token(s) from the
                                                      authorization
                                                      server(s), it
                                                      sends all of them
                                                      in a single
                                                      request to RS1.
                                                      RS1 then forwards
                                                      the additional
                                                      access token(s) to
                                                      RS2.

                                                      

                                                      

                                                      Some observations:
                                                      

                                                      

                                                      The user nor the
                                                      Client are linked
                                                      with any
                                                      particular AS. A
                                                      user may use today
                                                      an AS of the Bank
                                                      of America and may
                                                      change tomorrow to
                                                      the Bank of
                                                      Missouri. 

                                                      As soon as he will
                                                      be registered with
                                                      the Bank of
                                                      Missouri, he will
                                                      be able to get
                                                      access tokens from
                                                      the AS of the Bank
                                                      of Missouri. The
                                                      AS of Bank of
                                                      America 

                                                      has not been able
                                                      to know where its
                                                      access tokens have
                                                      been used. This
                                                      will be the same
                                                      for AS of the Bank
                                                      of Missouri. There
                                                      is no need for any
                                                      direct dialogue 

                                                      between any AS and
                                                      any RS at the time
                                                      a client is making
                                                      an access. There
                                                      is no need for any
                                                      RO to contact any
                                                      AS.

                                                  
T=
his
                                                      model has been
                                                      constructed
                                                      following a
                                                      "Privacy by
                                                      Design" approach=
.

                                                  Deni=
s

                                                

                                              

                                              -- 

                                              Txauth mailing list

                                              Txauth@ietf.org

                                              https://ww=
w.ietf.org/mailman/listinfo/txauth

                                            

                                          

                                        

                                        
3D""=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
                      

                    

                  

                  

                

              

            

            


            

          

          -- 

          Txauth mailing list

          Txauth@ietf.=
org

          https://www.ietf.org/mailman/listinfo/txauth

        

      

    

    


    

  


-- 

Txauth mailing list

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




--00000000000007706505aa586b86--


From nobody Mon Jul 13 16:47: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 C39643A079B for ; Mon, 13 Jul 2020 16:47:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-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=sunet.se
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 K34U7mV6Y0fS for ; Mon, 13 Jul 2020 16:47:22 -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 82E0E3A0803 for ; Mon, 13 Jul 2020 16:46:56 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id z24so20230369ljn.8 for ; Mon, 13 Jul 2020 16:46:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=to:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=26cfhxblor4gUzx3Qs0bJLOXW8edzmEnBegZ7pXNGLM=; b=NCvYSdAx07ALcuX+sju8Z8ZZ9jK51rGzieKX4EUiVl/SmZ2nlUmc6OkR8GfSB5cV6F HuG5pXwaw3FaK16pwqcfTAD+sL45UrG8Su3qj5jjkFrnVnUF1xk86oLe/g/2eImsm5qd ek/2oFCqGgB2dch5E5KHoAcSrpiTHzAI6fBhtYqK9uNspUBKKOgBQhrARrSEiM5b7b7p P/etv+0edDsbVMxbE4vYgXpOAQHBPNjGMalOK+AOVRY6JcASADQFCo54+NPFB6VQ7kin zcGdEFc2SVWfZ6FMaGJWcmoOfxpXDSuriF8psSQay9rMWOHjMjjk5HczRWHmOxZko/NL uLBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:autocrypt:subject:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=26cfhxblor4gUzx3Qs0bJLOXW8edzmEnBegZ7pXNGLM=; b=YXr8Rswb+NVJ2WYQiSlO2qjLOF9fLMNd4uiBbaDi5PGMpDgddhuc2dqPjmuEdjEhoc B1wWGwco7dwrszA0mK6CpE8j3x30R5HpHpGgm2/wVZE+2eri9MOL3TgfcXO6wiF0eDcR FHNCsmKdJGmiiYI4TWKBtSs3BeEpR2a+gDftRnA7c6fgNQ7pg3heH7jKoHBSNoFicxlT nsRrVgP1p67SxdmtV0EFMp7MpqNWX1ujiY+brJN7IzT/TpzA5gc39cJwf08YOSHjiTg1 ILW9pjIKm8dp/BkVp8WLVqbKVzo0i6KO0x8fCnmY7+k4kLbSNIJ89mEh8tx/kIlibTLF WRdA==
X-Gm-Message-State: AOAM530T56xdZbbNswiSQQk7TUKk8QhbLDEUDnUSvS0ZjS6isVgq5tql QMKvdc7YEbXtZkMqAwrdeseEJ4OHM+dlCHex
X-Google-Smtp-Source: ABdhPJwu7aDTQwDZoKeKrFCpxXUk8JHMFtmj5AwWe/efbDkk9rQU5RsoQSKT+48kcvJFgx3uZtubLA==
X-Received: by 2002:a2e:1514:: with SMTP id s20mr864681ljd.455.1594684013579;  Mon, 13 Jul 2020 16:46:53 -0700 (PDT)
Received: from [10.0.0.129] (h-98-128-228-179.NA.cust.bahnhof.se. [98.128.228.179]) by smtp.gmail.com with ESMTPSA id q3sm3999013ljm.22.2020.07.13.16.46.51 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2020 16:46:52 -0700 (PDT)
To: txauth@ietf.org
References:      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <89945398-E404-4FAE-91D0-5C5E8F202CDE@mit.edu>
From: Leif Johansson 
Autocrypt: addr=leifj@sunet.se; prefer-encrypt=mutual; keydata= xsBNBFJK9qIBCACypED81H1N4YmhMJrb4uOtTDzo+lFZDVVOcK11+NhTFl+AZZFnWH/7UPn+ q5ZZBd/IhONfb5QGw5FzTyBWHsbAteXgCvHAIyumwhQzhZnow6myyC6/MwDhomT5rb3MkCKC yQMNfj/yMgL6ZRsXVhlGOLMmOekRfKe2wiC5BhRaQQwPZPwgFS5D0Tro8Xfxjk98u8rNpQXi 9walRAffRY+byhkPiBj0sVA2RXK9Dx2DL3EY0xx07r6Qhs2XkbXNDDCHRuChhHSHwWC16VS9 x7Nhfg2EwKqmMGRNREikjwzDl/aHKz+FXTLONdmc83sRyklqgH90f3na6s/RT5XTb08xABEB AAHNHUxlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U+wsB+BBMBCAAoAhsDBgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCW7Yg8gUJDw7ExQAKCRDXOtZDCtR41io7CACOVmQcjoS7cfuF 43NhvpfFjSn91qShubrWx/p0+v/1MRyGajeMKcBd9HPDsN/lhMuY6k2zI1Qsrsycv51QQ+d0 +lPFxO3LKcrzaKqfKV3UZP3eVsMQgyP21iFIFAw424aAeBjWRhhnzlvsiP3RzF4NNb7goMWR PLWlld4M+MGqlM+T8M2Jbxl2OejedK5HCGm00IzXS7NojDGdIiXHbx0S0RloNb7ssQdFdHAH M6hO30lCwTM5jnNbejXhFUlMqYdRjWPUAbFwX3Pw9Wpkr5xz5xYbx8xPZBIG6ROp8ExxP31V NTm+DTnwJS5LLMbV1aDLYIzYlEossP2NFhLtwVDEzsBNBFJK9qIBCAC+k1tFOeDS4gMxEgRk fiVLHFemwJWQiGZHYhtDgjh6w6mB8G3WZ+/gD2CMp5DgHFRC1sW2iMj3gOzrfyxzd9AmWbhX YceR6EFkTc6OVsaIb+eHH/Zo3DKyB1Dq9CA5fjjnEQzti+KKSZYWzB0Fkt7qrfOS6YM1zMjE UxUUwsl1qirx5DuByWLDX7ULU7H/xmPVhHUVZO8XEaFV2m+ICx8Y6B98KMeJ0Qz8b8wp2g7v WEkwS2R6IjF0kMrRxnxUvwA6EUiZuFphhuY/lWCJusLl1olgOE+BKMEUStJWEi0s+pd8FL1v OLeNKbIUFro0+oZr9byABpkPNjMxKV36uj1dABEBAAHCwGUEGAEIAA8CGwwFAlu2H5wFCQ8O w3cACgkQ1zrWQwrUeNbSVAgAmRS6XxztiU9pczUwElOnolmnAIUocSXdfllZABxLX1MkZ4Yn 0jEbJKMpPOAMu7cQs4gni/AprnMae23taqJprwWCE6lTcOEhdPNKSFhdL4eE+UCd9Z9S/8PC M0GkjDF9FAWcrIBmySiHmZfAwKbHk3+AhDmY2PzN+mOzgU7t855+OtcoI02PDEXJGTCU9Mcl YtMNAlrmMmbMUApLSIoFluY35nlBVDFD3bDuCb59Nbs9aBJ9bu956G04XUcYt9sTsnkPppzX 82jyCc6Oeg9He8F1ep7AEoscflUKuwn9YF/sblqq27GO4d/BQPtaNw0iGz1H1C1QWKES4tk4 bZRWFA==
Message-ID: <7f57ec9c-6112-c15f-caa0-7b1dcda1d0ea@sunet.se>
Date: Tue, 14 Jul 2020 01:46:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <89945398-E404-4FAE-91D0-5C5E8F202CDE@mit.edu>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Txauth] WG scope wrt. identity (Was: Polymorphism (Was: JSON Schema?))
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, 13 Jul 2020 23:47:25 -0000

On 2020-07-10 22:09, Justin Richer wrote:
> It seems to be pretty clear that you and I are interpreting the charter text differently, so I’d like to hear what the chairs think the best approach will be when we finally get to defining what’s
> included in GNAP. This should perhaps be a discussion point for the group in the upcoming meeting. Until then, I can hopefully expand on what I interpret.

Mostly thats a question of WG consensus and not what the chairs think.

I suspect the WG is currently (like me) trying to catch up and isn't really in a position to
form consensus around anything.

We clearly need that to change. Forming consensus is what the IETF does and that can't
happen in the current environment.

Following the various threads that typically involve Justin and Dick I am scratching my
head trying to fathom how it is that two of the most experienced, intelligent and deeply
technical persons in the IETF are able to consistently and repeatedly missunderstand each
other so often.

Whatever the reason I am sure (again as chair) this *has to change* for the WG to get back
on target.

	Cheers Leif


From nobody Tue Jul 14 09:18: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 E9BA73A09A9 for ; Tue, 14 Jul 2020 09:18:31 -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 yQ5TSu4KC-_7 for ; Tue, 14 Jul 2020 09:18:30 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640115.outbound.protection.outlook.com [40.107.64.115]) (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 3919A3A09A3 for ; Tue, 14 Jul 2020 09:18:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VgRir2QpXlNc40X05m/KIH9iWTo4hJ/A62AQl9Uu2BsoWfxbsO62koTeaOzrGORLsS3KE/Q1iT3LEYA7dFnxtMnq7rJh/qZU886KQBe1G2mC72JqW6YAbmSDvF4JXKlj0nuoKYGK+Bbpp7Ngg2nAtEgMxSuUNim2PvO9X+oJIV45nHZxbcWqYW4EgX04kB8oyc9sXZy0U35xMaiQ8jhNd21JIFOwO11E6mVfnhhbNu3lF0sxHp/NVTNmmvigKGIPS2l0vQguGZhEcsnNUHs/by3Nx1y7Pb8Kh6b+uyPzOB/G+wcc8FilOD+xYFqhvFmDAFJ7N6VmFtRTDjHD2q4JcQ==
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=kDSanUCfgukQ3oCRb8a4kBu6GqwAV/WZHHCNKQFxgew=; b=nH/78jGK0ALXjLYPNXXB4RQ19ei765WLz14jV1DSFIE/g+akN1Fd5rsHf3XbeKVMa/56FGo8qdAJVzgu7pinxTbDHn56Yg54IzjPmzYyfXxnJmq+1vAI98TMz2yVrY0r+oIJCikTUx2yqcF+mghk+udoVDBUpcO7mYpPFwWU74mfXE8eEy3w2X9sQOPb1H00Ko3D/vCSV2TRsdu/f7uLnDkwK50WhpHKOVjtgctdWpuglO4MBiHizijpMjNYNULqUWVcAbXpnnypq2KvlhY940j/n6tpgsbzy0YaN6v/xYZfBdZLaJcHtv0WnFmp1BQJxPsAgQFhR/49A2+palAUFA==
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=kDSanUCfgukQ3oCRb8a4kBu6GqwAV/WZHHCNKQFxgew=; b=HyOkIVYZBZmhFuXrT0XJv6diBgTP9HxakPkXDOyWay8RzdH0XI1Ci2fXAX+qCOe9uLXy5gcl2IFRpaDY1+UJqmTe+F27JhJx9k+X699UAnnsFC1ka3feD6hcmWxbd9NHXUfnw8Beme4oesiynrKtmHlRlKxeBplM3g1GTBpIqxQ=
Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0794.namprd00.prod.outlook.com (2603:10b6:610:6f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3229.0; Tue, 14 Jul 2020 16:18:28 +0000
Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::29f8:dc4a:8aac:e889]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::29f8:dc4a:8aac:e889%8]) with mapi id 15.20.3234.000; Tue, 14 Jul 2020 16:18:28 +0000
From: Mike Jones 
To: Dick Hardt , "txauth@ietf.org" , Justin Richer 
Thread-Topic: Key handle vs client id & handle
Thread-Index: AdZZ+mZgxtkBmq+UR+efg3xrZERnOA==
Date: Tue, 14 Jul 2020 16:18:28 +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-07-14T16:13:33Z;  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=c9535e6e-8b68-4306-a8cf-534cae1e35ea; 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.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: a8dd16e0-20f1-4c9a-d226-08d828118b17
x-ms-traffictypediagnostic: CH2PR00MB0794:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0r4bbwneQxtUdTO1cC4cbtb/IZKKF9IbCgejLXL9mMA/tkrbdHAKdyQbs5YXsHYgTvidv1UeVKNKPC0uAqu9qrgmIiyGe4Qk3PNT5e4gSgGK3b3liDUNuMXD/pPi7uBwSstNTu38riWvMzfpAWhl9A6vTpAbAUC6gS8rgua/jGrJHNOLNv8KwimCRuGGDnI3L3zbwBbUF4HCK78TcrRRKkN8EMEL+lUHyYZZqsvQcgfaypLoWMwofrxoU0v2bKDQ7muDAcNdGF+78kgjyG7C9oHDN24Xiq20YhYlLsAXBPdHPzxm3lssxbU+8dUHwIuy8xGci/Yn2H3iRmFyeHSA8dRsYwp8wxwqt5WMgJOGwzynBsoruZ6xU1Ur3m2aMRX3787iDOPDYREwsaJiqZ+JhA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(376002)(136003)(346002)(396003)(39860400002)(366004)(86362001)(316002)(186003)(66556008)(10290500003)(26005)(110136005)(66946007)(76116006)(66476007)(66446008)(83380400001)(64756008)(478600001)(966005)(166002)(33656002)(55016002)(8936002)(71200400001)(21615005)(2906002)(8676002)(52536014)(53546011)(5660300002)(6506007)(82950400001)(7696005)(82960400001)(9686003)(8990500004); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: 3IrhejWTmbTfOdX2IKKRxR+bDXcoOhmX20yYdbDvThuyWle+ruJJow9dvuJOz3OcKXuRVlWCmJ7K+Esrxf0kJ56uZ+R+KsENLROlvXGFSVB8rqsAZ3OFx2+4fxuEebhY4krccI3+ZvwnEk4Ki0/21KSgyS15rBcRwc664LwhBNeiCS3h/XP8dcuifq/2bKaEn+vBXJc5tJDwq/VghjzR9FZsc2ePMUcOzM1ebF6fhJa+0b9UKbP0i1pgCtOTlaKBQDWaNsxy164a6LyjKQSKHB46QbG3aL2C+FLAi8zNgCUid73pwtTyJQqLLpOF55s0krKtH2LDzQdRIL1MIGqgQWLIZfHZiuATVL+DkHPGzt3CeEgXrF3bAjV+BRmCdiZ7dJMOGdoa6NBDVh7MyDABETJhAhJVlHMaOhhi4cjulN0vlf+5tFrQl7AhfKi4brGmUUqzHdF2xKx+DE8oZRp83T+ns21iGIAzPTkXmeiSRzs=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB067803B92F8CF0A34DE0F2EFF5610CH2PR00MB0678namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a8dd16e0-20f1-4c9a-d226-08d828118b17
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 16:18:28.4441 (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: iw39oWKLLFY3AENb3yjGrzEKLLR7ejRRpCZocErjoAfvfgiwMRr/hULlUhxU3JC4siTncf4N5C5paIGitHswDg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0794
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 14 Jul 2020 16:18:32 -0000

--_000_CH2PR00MB067803B92F8CF0A34DE0F2EFF5610CH2PR00MB0678namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBzaWduaWZpY2FudCBkaWZmZXJlbmNlcyBiZXR3ZWVuIHN0
YXRpY2FsbHkgYW5kIGR5bmFtaWNhbGx5IHJlZ2lzdGVyZWQgY2xpZW50cyBhbmQgdGhhdOKAmXMg
YXBwcm9wcmlhdGUgdG8gYmUgYWJsZSB0byBzeW50YWN0aWNhbGx5IGRpZmZlcmVudGlhdGUgYmV0
d2VlbiB0aGVtIGF0IHJ1bnRpbWUuICBGb3Igb25lIHRoaW5nLCB0aGUgcmVzb3VyY2UgcmVxdWly
ZW1lbnRzIGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBjYW4gYmUgdmVyeSBkaWZmZXJlbnQu
DQoNCldlIHNob3VsZCBhbHNvIGJlIHRoaW5raW5nIGFib3V0IGhvdyB0byBpbmNsdWRlIHdoYXQg
dGhlIE9wZW5JRCBDb25uZWN0IEZlZGVyYXRpb24gc3BlYyBodHRwczovL29wZW5pZC5uZXQvc3Bl
Y3Mvb3BlbmlkLWNvbm5lY3QtZmVkZXJhdGlvbi0xXzAuaHRtbCBjYWxscyDigJxBdXRvbWF0aWMg
UmVnaXN0cmF0aW9u4oCdLiAgVGhpcyBsZXRzIHRoZSBjbGllbnQgZW5jb2RlIGEgcmVnaXN0cmF0
aW9uIHJlcXVlc3QgcmVmZXJlbmNlIGluIHRoZSBjbGllbnQgSUQsIHNvIG5vIHN0YXRpYyBvciBk
eW5hbWljIHJlZ2lzdHJhdGlvbiBldmVuIG9jY3Vycy4gIFNlZSBodHRwczovL29wZW5pZC5uZXQv
c3BlY3Mvb3BlbmlkLWNvbm5lY3QtZmVkZXJhdGlvbi0xXzAtMTIuaHRtbCNyZmMuc2VjdGlvbi45
LjEuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAtLSBNaWtlDQoNCkZyb206IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPg0K
U2VudDogRnJpZGF5LCBKdWx5IDEwLCAyMDIwIDE6MTcgUE0NClRvOiB0eGF1dGhAaWV0Zi5vcmc7
IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT47IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbT4NClN1YmplY3Q6IEtleSBoYW5kbGUgdnMgY2xpZW50IGlkICYgaGFu
ZGxlDQoNCisgTWlrZSBhcyBoZSBoYWQgaW50ZXJlc3QgaW4gdGhpcyB0b3BpYw0KDQpNeSB1bmRl
cnN0YW5kaW5nIGlzIHRoYXQgYW4gZXhpc3RpbmcgT0F1dGggMiBjbGllbnQgd291bGQgdXNlIHRo
ZWlyIGN1cnJlbnQgY2xpZW50IGlkIGFzIHRoZWlyIGtleSBoYW5kbGUsIGFuZCBhIGR5bmFtaWMg
Y2xpZW50IChvbmUgdGhhdCB3YXMgbm90IHByZS1yZWdpc3RlcmVkKSB3b3VsZCBiZSBnaXZlbiBh
IGtleSBoYW5kbGUgYnkgdGhlIEFTLg0KDQpUaGVyZSBhcmUgcG90ZW50aWFsbHkgc29tZSBzaWdu
aWZpY2FudCBkaWZmZXJlbmNlcyBiZXR3ZWVuIGEgcmVnaXN0ZXJlZCBjbGllbnQsIGFuZCBhIGR5
bmFtaWMgY2xpZW50IHRvIGFuIEFTLg0KDQpUaGUgQVMgaXMgbGlrZWx5IHRvIGtub3cgdGhlIGlk
ZW50aXR5IG9mIGEgcmVnaXN0ZXJlZCBjbGllbnQsIGFuZCBoYXZlIGRpZmZlcmVudCBwb2xpY2ll
cyBiZXR3ZWVuIHRoZSB0d28gdHlwZXMgb2YgY2xpZW50cy4gRm9yIGV4YW1wbGUsIGEgcmVnaXN0
ZXJlZCBjbGllbnQgbWF5IGhhdmUgYWNjZXNzIHRvIGEgJ3dyaXRlIiBzY29wZSwgd2hpbGUgYSBk
eW5hbWljIGNsaWVudCBkb2VzIG5vdC4NCg0KVGhlIEFTIG1heSBoYXZlIDEwMHMgb3IgMTAwMHMg
b2YgcmVnaXN0ZXJlZCBjbGllbnRzLCBidXQgYSBkeW5hbWljIGNsaWVudCBtYXkgaGF2ZSAxME1z
IG9yIDEwME1zIG9mIGluc3RhbmNlcywgd2hpY2ggbWF5IGRpY3RhdGUgc2VwYXJhdGUgc3RvcmFn
ZSBzZXJ2aWNlcy4gQWRkaXRpb25hbGx5LCBpbnRlcm5hbCB0byB0aGUgQVMsIHdoaWNoIHN5c3Rl
bXMgY2FuIHdyaXRlIHRvIHRoZSByZWdpc3RlcmVkIGNsaWVudCBzdG9yZSBpcyBnb2luZyB0byBi
ZSBkaWZmZXJlbnQgdGhhbiB0aGUgZHluYW1pYyBjbGllbnQgc3RvcmUuDQoNCkluIFhZWiwgc3Vi
c2VxdWVudCBjYWxscyB0byB0aGUgQVMsIGJvdGggcmVnaXN0ZXJlZCBjbGllbnRzIGFuZCBkeW5h
bWljIGNsaWVudHMgcGFzcyBhIGtleSBoYW5kbGUsIHNvIHRoZXJlIGlzIG5vIGVhc3kgd2F5IHRv
IGRpZmZlcmVudGlhdGUgYmV0d2VlbiB0aGUgdHdvLg0KDQpXaGlsZSB0aGUgQVMgY291bGQgZW1i
ZWQgc2VtYW50aWNzIGluIHRoZSBrZXkgaGFuZGxlIGlkZW50aWZpZXIgdG8gaW5kaWNhdGUgd2hp
Y2ggaWRlbnRpZmllcnMgYXJlIHByZS1yZWdpc3RlcmVkIHZzIGR5bmFtaWMsIHRoZXJlIGFyZSBt
YW55IGNhc2VzIHdoZXJlIHRoZSBBUyBkb2VzIG5lZWQgdG8ga25vdyB0aGUgZGlmZmVyZW5jZSwg
c28gbWFraW5nIHRoZSBkaWZmZXJlbmNlIGEgZmVhdHVyZSBvZiBHTkFQIHNlZW1zIGxpa2UgYSBi
ZXR0ZXIgcGF0aC4NCg0KDQo=

--_000_CH2PR00MB067803B92F8CF0A34DE0F2EFF5610CH2PR00MB0678namp_
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
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj
MDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K
CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjojMDAyMDYwIj5JIGFncmVlIHRoYXQgdGhlcmUgYXJlIHNpZ25pZmljYW50IGRpZmZlcmVuY2Vz
IGJldHdlZW4gc3RhdGljYWxseSBhbmQgZHluYW1pY2FsbHkgcmVnaXN0ZXJlZCBjbGllbnRzIGFu
ZCB0aGF04oCZcyBhcHByb3ByaWF0ZSB0byBiZSBhYmxlIHRvIHN5bnRhY3RpY2FsbHkgZGlmZmVy
ZW50aWF0ZSBiZXR3ZWVuIHRoZW0gYXQgcnVudGltZS4mbmJzcDsgRm9yIG9uZSB0aGluZywgdGhl
DQogcmVzb3VyY2UgcmVxdWlyZW1lbnRzIGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBjYW4g
YmUgdmVyeSBkaWZmZXJlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5X
ZSBzaG91bGQgYWxzbyBiZSB0aGlua2luZyBhYm91dCBob3cgdG8gaW5jbHVkZSB3aGF0IHRoZSBP
cGVuSUQgQ29ubmVjdCBGZWRlcmF0aW9uIHNwZWMNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL29w
ZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZmVkZXJhdGlvbi0xXzAuaHRtbCI+aHR0cHM6
Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWZlZGVyYXRpb24tMV8wLmh0bWw8L2E+
IGNhbGxzIOKAnEF1dG9tYXRpYyBSZWdpc3RyYXRpb27igJ0uJm5ic3A7IFRoaXMgbGV0cyB0aGUg
Y2xpZW50IGVuY29kZSBhIHJlZ2lzdHJhdGlvbiByZXF1ZXN0IHJlZmVyZW5jZSBpbiB0aGUgY2xp
ZW50IElELCBzbyBubw0KIHN0YXRpYyBvciBkeW5hbWljIHJlZ2lzdHJhdGlvbiBldmVuIG9jY3Vy
cy4mbmJzcDsgU2VlIDxhIGhyZWY9Imh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29u
bmVjdC1mZWRlcmF0aW9uLTFfMC0xMi5odG1sI3JmYy5zZWN0aW9uLjkuMSI+DQpodHRwczovL29w
ZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZmVkZXJhdGlvbi0xXzAtMTIuaHRtbCNyZmMu
c2VjdGlvbi45LjE8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IERpY2sg
SGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gRnJp
ZGF5LCBKdWx5IDEwLCAyMDIwIDE6MTcgUE08YnI+DQo8Yj5Ubzo8L2I+IHR4YXV0aEBpZXRmLm9y
ZzsgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0OzsgTWlrZSBKb25lcyAmbHQ7
TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBLZXkg
aGFuZGxlIHZzIGNsaWVudCBpZCAmYW1wOyBoYW5kbGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+KyBNaWtlIGFzIGhlIGhhZCBpbnRlcmVzdCBpbiB0aGlzIHRvcGljPG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgdW5kZXJzdGFuZGluZyBpcyB0
aGF0IGFuIGV4aXN0aW5nIE9BdXRoIDIgY2xpZW50IHdvdWxkIHVzZSB0aGVpciBjdXJyZW50IGNs
aWVudCBpZCBhcyB0aGVpciBrZXkgaGFuZGxlLCBhbmQgYSBkeW5hbWljIGNsaWVudCAob25lIHRo
YXQgd2FzIG5vdCBwcmUtcmVnaXN0ZXJlZCkgd291bGQgYmUgZ2l2ZW4gYSBrZXkgaGFuZGxlIGJ5
IHRoZSBBUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGhlcmUgYXJlIHBvdGVudGlhbGx5IHNvbWUgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZXMg
YmV0d2VlbiBhIHJlZ2lzdGVyZWQgY2xpZW50LCBhbmQgYSBkeW5hbWljIGNsaWVudCB0byBhbiBB
Uy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VGhlIEFTIGlzIGxpa2VseSB0byBrbm93IHRoZSBpZGVudGl0eSBvZiBhIHJlZ2lzdGVyZWQgY2xp
ZW50LCBhbmQgaGF2ZSBkaWZmZXJlbnQgcG9saWNpZXMgYmV0d2VlbiB0aGUgdHdvIHR5cGVzIG9m
IGNsaWVudHMuIEZvciBleGFtcGxlLCBhIHJlZ2lzdGVyZWQgY2xpZW50IG1heSBoYXZlIGFjY2Vz
cyB0byBhICd3cml0ZSZxdW90OyBzY29wZSwgd2hpbGUgYSBkeW5hbWljIGNsaWVudCBkb2VzIG5v
dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
VGhlIEFTIG1heSBoYXZlIDEwMHMgb3IgMTAwMHMgb2YgcmVnaXN0ZXJlZCBjbGllbnRzLCBidXQg
YSBkeW5hbWljIGNsaWVudCBtYXkgaGF2ZSAxME1zIG9yIDEwME1zIG9mIGluc3RhbmNlcywgd2hp
Y2ggbWF5IGRpY3RhdGUgc2VwYXJhdGUmbmJzcDtzdG9yYWdlIHNlcnZpY2VzLiBBZGRpdGlvbmFs
bHksIGludGVybmFsIHRvIHRoZSBBUywgd2hpY2ggc3lzdGVtcyBjYW4gd3JpdGUgdG8gdGhlIHJl
Z2lzdGVyZWQmbmJzcDtjbGllbnQNCiBzdG9yZSBpcyBnb2luZyB0byBiZSBkaWZmZXJlbnQgdGhh
biB0aGUgZHluYW1pYyBjbGllbnQmbmJzcDtzdG9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gWFlaLCBzdWJzZXF1ZW50IGNhbGxzIHRv
IHRoZSBBUywgYm90aCByZWdpc3RlcmVkIGNsaWVudHMgYW5kIGR5bmFtaWMgY2xpZW50cyBwYXNz
IGEga2V5IGhhbmRsZSwgc28gdGhlcmUgaXMgbm8gZWFzeSB3YXkgdG8gZGlmZmVyZW50aWF0ZSBi
ZXR3ZWVuIHRoZSB0d28uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPldoaWxlIHRoZSBBUyBjb3VsZCBlbWJlZCBzZW1hbnRpY3MgaW4gdGhlIGtl
eSBoYW5kbGUgaWRlbnRpZmllciB0byBpbmRpY2F0ZSB3aGljaCBpZGVudGlmaWVycyBhcmUgcHJl
LXJlZ2lzdGVyZWQgdnMgZHluYW1pYywgdGhlcmUgYXJlIG1hbnkgY2FzZXMgd2hlcmUgdGhlIEFT
IGRvZXMgbmVlZCB0byBrbm93IHRoZSBkaWZmZXJlbmNlLCBzbyBtYWtpbmcmbmJzcDt0aGUgZGlm
ZmVyZW5jZSBhIGZlYXR1cmUgb2YgR05BUA0KIHNlZW1zIGxpa2UgYSBiZXR0ZXIgcGF0aC48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N
CjwvaHRtbD4NCg==

--_000_CH2PR00MB067803B92F8CF0A34DE0F2EFF5610CH2PR00MB0678namp_--


From nobody Tue Jul 14 10:54:32 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 D8C5C3A097D for ; Tue, 14 Jul 2020 10:54:30 -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 (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 lGvkXTqkJjst for ; Tue, 14 Jul 2020 10:54:28 -0700 (PDT)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670117.outbound.protection.outlook.com [40.107.67.117]) (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 93E223A095A for ; Tue, 14 Jul 2020 10:54:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZWM0Um4GbkNn8Y6HDbl5VM/txiubUi9ETUrIetk/md4WCMbvnGFRStFR9jUCknIoxVOcetuS6v63WgtkdIkCAsGbDh+43GipvqpRB27MBn+Y4pgOplyky67dKJJouZTk0GNRmHTrnYjrggu141XNw0Jz8rUO78V8x8LYt49SGR/Ar10EGu8snDJhjm+bj7xNUyWG9wkP/wd2Ai3yWpgLwYp3iru316jayxK2Nvn7ZCJEyq71KmB1wAFrMrp9t/8Td+a9srArMG9VCJbKP407UxUpPdkmWE74JsW0adMTljP5kbVZdaUoCzidbz5ScIzobtWv+RGRetEEgrVql5Zs2Q==
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=wYOXMn8ZgpSe7qOnz+/jUUWcDuYfz+B3B2kvB91qNRI=; b=S58CDcde/ZW+o0xkizkv4h7R4PvN4wF+Ynm3j3sTY/lAXgNxMghqi+cVhTSc/bNBFI5q9t++kIXwUv3/i9OUxMKf2NtlDek33J79P4WVdb0hMyA5czVwsLCRjuV5BZLVcqtIlA9I56tkLB/ra95QaoLZ4zJhKLrOyY/QYF473bHf7wlL+DaWWKQqwK4cx5ZOF12aDRNN2k+x81qSpD6sddf/62PCoLvenoKHCXi9iznyb2aeIY+duvse1TbFA4ugL7jHn8dd3HPm59oTgmKbQj/lpvc3kMQm9wenvy/F026R1Iu7t9WRD9slzOFvvsZ6PO5zGQG/M4FkXk1OKHcgzA==
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=wYOXMn8ZgpSe7qOnz+/jUUWcDuYfz+B3B2kvB91qNRI=; b=uWuGzDxaOV6pNwKl8BAT8jPHzPTkZfRq07zYilQ0YbBUXXydhl19DCs2IuPr6UP3M1CTQf37FFftoGvyhY8WGZoI44cwAeCZshlPAM0OngejGjoQ9KZqJoFkrJTuuoYlM9RyBMs0m1xJtZ3vWM9li+TifHK0ej4pfHBXKnGivcU=
Received: from YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:20::25) by YTBPR01MB3647.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:23::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.22; Tue, 14 Jul 2020 17:54:26 +0000
Received: from YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM ([fe80::c57f:32dc:ba85:19a3]) by YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM ([fe80::c57f:32dc:ba85:19a3%5]) with mapi id 15.20.3174.025; Tue, 14 Jul 2020 17:54:26 +0000
From: Mike Varley 
To: Mike Jones , Dick Hardt , "txauth@ietf.org" , Justin Richer 
Thread-Topic: [Txauth] Key handle vs client id & handle
Thread-Index: AQHWWgfQI3P9P86/Z0OmlGTftB7qcQ==
Date: Tue, 14 Jul 2020 17:54:26 +0000
Message-ID: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.38.20061401
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=securekey.com;
x-originating-ip: [50.101.239.135]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 06e032f3-a714-4926-e5c0-08d8281ef325
x-ms-traffictypediagnostic: YTBPR01MB3647:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5OBqrn/l6afz4uwHMWhpjyPrfKdKZtGMUidXJGZjbneeLG4d4BYBKIrJoSfcs3PdFb2cUES7Fogg8cQYhCduTZgCRdT5BFK2g1A3p8nO3vfJqbhvt6HAJS7jQP1viyF0JCBymdNqYBPrcFmI3k2i4fiSORe7ILn7Y9Jl9/B4e2fqEUPTBAIJbv8Iz10oxg77vLozLqnPXCHqpfbFG5nw6VKnSDJUfq39tOHM2v69/o6WkezMxuVrWL8qWFJDP0EkStjVn/TuATaGw9YK8pOzN68QDeivTFZcC0F8ZkeItM2wIxaO9zN/6lUm36eyuKKiG/Sl+3G+EJ6MXWnX9+lgB5C/dNYJcARuTBIDrXRi/Ksf26D92qD2TI12gV9xhu93pL5UM4c//vtuixGQH7WEeg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(396003)(136003)(376002)(39830400003)(346002)(366004)(36756003)(478600001)(44832011)(6512007)(2906002)(66946007)(71200400001)(8936002)(966005)(186003)(83380400001)(21615005)(66476007)(64756008)(26005)(2616005)(66556008)(66446008)(166002)(91956017)(76116006)(6506007)(53546011)(33656002)(6486002)(110136005)(8676002)(5660300002)(86362001)(45080400002)(316002); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: OHuOcXBUbKRrSExeIcusCTT36lnqo8wAKUS+YXwfkkoF6piekDL434f4kExHPyRlkVrVMqdQXlAihV15rrYiBABaCdYfIYw8aL1jozTX4pOl6PAmQ8IUaE+il6QRztK/0PSt52lPKL2N1LZGcD5isTsDOhTAga6lXDGsEBHdUtDm9EuV68SMcVRcv/KuzFi5TgsBjpqQ8P5Zt/YDZsX1D5EC6rne0McRB1HLwnux7yUECdgh3jISCorhD3cQ15xOFcDd2fQ7WWKg3eSCkXm9k5dnmXmbREQFfXvHlcSgV5zb6YIMknqnFXzumeXjh/groCrqUNuXaMYed82fMKD1b9KKh7PDTyL34MyFhImubOLkMdvaothsbVQLx866HjCS7Do9blOM/wZjkTtGiE/lKOa6cLZAgL95hLL13dfQaQQp+i1a7SiCw8IPXqJ5qNbc8zP0tRrE04QvDrR+/euPlFh6yGSFC2qhkOBDt/ufdhbybzN2vIwzjKr0rCHfjbos
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_29AAF03B12B64E619BF4EF951506931Bsecurekeycom_"
MIME-Version: 1.0
X-OriginatorOrg: securekey.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 06e032f3-a714-4926-e5c0-08d8281ef325
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 17:54:26.5404 (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: 71brR+J3wvFoUIxpqXCuVw+1UWrxfp4guwLfN2O9IjtSQvfE4ZrZoQx3RJQONyQNDFp4EIQ4hIvGCx+BfK7B+ehqkQIdRhm93atI5F7jcU4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3647
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 14 Jul 2020 17:54:31 -0000

--_000_29AAF03B12B64E619BF4EF951506931Bsecurekeycom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXMgY2xpZW50IHJlZ2lzdHJhdGlvbiBpbiBzY29wZSBmb3IgdGhlIHByb3RvY29sPw0KDQpBIGdl
bmVyaWMgd2F5IG9mIGhhbmRsaW5nIGNsaWVudHMgKHZpYSBJRCBvciBIYW5kbGUgb3IgS2V5IG9y
IHdoYXRldmVyKSBpcyB0byBoYXZlIHByb2Nlc3NpbmcgcnVsZSBvbiB0aGUgQVMgc3VjaCBhcyDi
gJxpZiB0aGUgQVMgcmVjb2duaXplcyB0aGUgY2xpZW50IElEIChhbmQgYXV0aGVudGljYXRpb24g
b2YgdGhhdCBjbGllbnQgSUQpIHRoZW4gaXQgbWF5IHByb2Nlc3MgdGhlIHJlcXVlc3Qgb24gYmVo
YWxmIG9mIHRoYXQgY2xpZW50LiBJZiB0aGUgQVMgZG9lcyBub3QgcmVjb2duaXplIHRoZSBjbGll
bnQgSUQsIGl0IG11c3QgdHJlYXQgdGhpcyBhcyBhIG5ldyBjbGllbnQgcmVnaXN0cmF0aW9uIGFu
ZCBldmFsdWF0ZSBhbnkgYXV0aG9yaXphdGlvbiBldmlkZW5jZSB0aGUgY2xpZW50IHByb3ZpZGVz
IGJlZm9yZSBlbmFibGluZyB0aGUgY2xpZW50IGFuZCBtYXBwaW5nIHBvbGljaWVzIHRvIHRoYXQg
Y2xpZW504oCdICh0aGlzIG1lYW5zIGR5bmFtaWMgb3IgYXV0b21hdGljIGNsaWVudHMgbmVlZCB0
byBwcm92aWRlIGFkZGl0aW9uYWwgYXNzZXJ0aW9ucyAvIHNvZnR3YXJlIHN0YXRlbWVudHMgd2hh
dGV2ZXIgdG8gcmVnaXN0ZXIgdGhlaXIgSUQuDQoNClNvbWV0aGluZyBsaWtlIHRoaXMgYWxsb3dz
IGZvciB2ZXJ5IGZsZXhpYmxlIHN5c3RlbXM6DQpTeXN0ZW0gQSBjYW4gYmUgdW5rbm93biB0byB0
aGUgQVMgYnV0IGNhbiBkeW5hbWljYWxseSByZWdpc3RlcmVkIGVhY2ggdGltZSB3aXRoIGFuIGFw
cHJvcHJpYXRlIHNvZnR3YXJlIHN0YXRlbWVudA0KU3lzdGVtIEIgY2FuIGhhdmUgYSBmYWlybHkg
c3RhYmxlIGNsaWVudCBJRCBhdCB0aGUgQVMsIGJ1dCByb3RhdGUgdGhhdCBJRCBldmVyeSBtb250
aCB0aHJvdWdoIGF1dG9tYXRpYyByZWdpc3RyYXRpb24gKHdpdGggYW4gYXNzZXJ0aW9uIGl0IGdv
dCBmcm9tIHRoZSBBUyBkdXJpbmcgYSBwcmUtcmVnaXN0cmF0aW9uIGZvciBleGFtcGxlKQ0KU3lz
dGVtIEMgY2FuIHByZS1yZWdpc3RlciB3aXRoIHRoZSBBUyBmb3IgYSBjbGllbnQgSUQgYmVjYXVz
ZSBpdCBkb2VzbuKAmXQgZGVhbCB3aXRoIHNvZnR3YXJlIHN0YXRlbWVudHMgZXRj4oCmDQrigKYN
CkFuZCBldmVuIOKAmFN0YXRlbGVzc0FT4oCZIGNhbiBvcGVyYXRlIGJ5IG5ldmVyIHN0b3Jpbmcg
Y2xpZW50IElEcyBiZWNhdXNlIGl0IHdpbGwgYWx3YXlzIGp1c3QgcmVseSBvbiB0aGUgc29mdHdh
cmUgc3RhdGVtZW50cy4NCg0KSSB0aGluayBhIGNsaWVudCByZWdpc3RyYXRpb24gcHJvdG9jb2wg
dGhhdCBhbGxvd3MgdGhlc2Ugc2NlbmFyaW9zIHdvdWxkIGJlIHZlcnkgdXNlZnVsIGluIEdOQVAs
IGJ1dCBob3BlZnVsbHkgYXZvaWRpbmcgaGF2aW5nIHRvIGRlZmluZSB3aGF0IOKAmGV2aWRlbmNl
4oCZIHRoZSBBUyBuZWVkcyB0byBhY2NlcHQgZm9yIGVhY2ggc2NlbmFyaW8uDQoNClRoYW5rcywN
Cg0KTVYNCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxm
IG9mIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu
b3JnPg0KRGF0ZTogVHVlc2RheSwgSnVseSAxNCwgMjAyMCBhdCAxMjoxOCBQTQ0KVG86IERpY2sg
SGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPiwgInR4YXV0aEBpZXRmLm9yZyIgPHR4YXV0aEBp
ZXRmLm9yZz4sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4NClN1YmplY3Q6IFJlOiBb
VHhhdXRoXSBLZXkgaGFuZGxlIHZzIGNsaWVudCBpZCAmIGhhbmRsZQ0KDQpJIGFncmVlIHRoYXQg
dGhlcmUgYXJlIHNpZ25pZmljYW50IGRpZmZlcmVuY2VzIGJldHdlZW4gc3RhdGljYWxseSBhbmQg
ZHluYW1pY2FsbHkgcmVnaXN0ZXJlZCBjbGllbnRzIGFuZCB0aGF04oCZcyBhcHByb3ByaWF0ZSB0
byBiZSBhYmxlIHRvIHN5bnRhY3RpY2FsbHkgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHRoZW0gYXQg
cnVudGltZS4gIEZvciBvbmUgdGhpbmcsIHRoZSByZXNvdXJjZSByZXF1aXJlbWVudHMgYXQgdGhl
IGF1dGhvcml6YXRpb24gc2VydmVyIGNhbiBiZSB2ZXJ5IGRpZmZlcmVudC4NCg0KV2Ugc2hvdWxk
IGFsc28gYmUgdGhpbmtpbmcgYWJvdXQgaG93IHRvIGluY2x1ZGUgd2hhdCB0aGUgT3BlbklEIENv
bm5lY3QgRmVkZXJhdGlvbiBzcGVjIGh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29u
bmVjdC1mZWRlcmF0aW9uLTFfMC5odG1sIGNhbGxzIOKAnEF1dG9tYXRpYyBSZWdpc3RyYXRpb27i
gJ0uICBUaGlzIGxldHMgdGhlIGNsaWVudCBlbmNvZGUgYSByZWdpc3RyYXRpb24gcmVxdWVzdCBy
ZWZlcmVuY2UgaW4gdGhlIGNsaWVudCBJRCwgc28gbm8gc3RhdGljIG9yIGR5bmFtaWMgcmVnaXN0
cmF0aW9uIGV2ZW4gb2NjdXJzLiAgU2VlIGh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQt
Y29ubmVjdC1mZWRlcmF0aW9uLTFfMC0xMi5odG1sI3JmYy5zZWN0aW9uLjkuMS4NCg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UN
Cg0KRnJvbTogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+DQpTZW50OiBGcmlkYXks
IEp1bHkgMTAsIDIwMjAgMToxNyBQTQ0KVG86IHR4YXV0aEBpZXRmLm9yZzsgSnVzdGluIFJpY2hl
ciA8anJpY2hlckBtaXQuZWR1PjsgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu
Y29tPg0KU3ViamVjdDogS2V5IGhhbmRsZSB2cyBjbGllbnQgaWQgJiBoYW5kbGUNCg0KKyBNaWtl
IGFzIGhlIGhhZCBpbnRlcmVzdCBpbiB0aGlzIHRvcGljDQoNCk15IHVuZGVyc3RhbmRpbmcgaXMg
dGhhdCBhbiBleGlzdGluZyBPQXV0aCAyIGNsaWVudCB3b3VsZCB1c2UgdGhlaXIgY3VycmVudCBj
bGllbnQgaWQgYXMgdGhlaXIga2V5IGhhbmRsZSwgYW5kIGEgZHluYW1pYyBjbGllbnQgKG9uZSB0
aGF0IHdhcyBub3QgcHJlLXJlZ2lzdGVyZWQpIHdvdWxkIGJlIGdpdmVuIGEga2V5IGhhbmRsZSBi
eSB0aGUgQVMuDQoNClRoZXJlIGFyZSBwb3RlbnRpYWxseSBzb21lIHNpZ25pZmljYW50IGRpZmZl
cmVuY2VzIGJldHdlZW4gYSByZWdpc3RlcmVkIGNsaWVudCwgYW5kIGEgZHluYW1pYyBjbGllbnQg
dG8gYW4gQVMuDQoNClRoZSBBUyBpcyBsaWtlbHkgdG8ga25vdyB0aGUgaWRlbnRpdHkgb2YgYSBy
ZWdpc3RlcmVkIGNsaWVudCwgYW5kIGhhdmUgZGlmZmVyZW50IHBvbGljaWVzIGJldHdlZW4gdGhl
IHR3byB0eXBlcyBvZiBjbGllbnRzLiBGb3IgZXhhbXBsZSwgYSByZWdpc3RlcmVkIGNsaWVudCBt
YXkgaGF2ZSBhY2Nlc3MgdG8gYSAnd3JpdGUiIHNjb3BlLCB3aGlsZSBhIGR5bmFtaWMgY2xpZW50
IGRvZXMgbm90Lg0KDQpUaGUgQVMgbWF5IGhhdmUgMTAwcyBvciAxMDAwcyBvZiByZWdpc3RlcmVk
IGNsaWVudHMsIGJ1dCBhIGR5bmFtaWMgY2xpZW50IG1heSBoYXZlIDEwTXMgb3IgMTAwTXMgb2Yg
aW5zdGFuY2VzLCB3aGljaCBtYXkgZGljdGF0ZSBzZXBhcmF0ZSBzdG9yYWdlIHNlcnZpY2VzLiBB
ZGRpdGlvbmFsbHksIGludGVybmFsIHRvIHRoZSBBUywgd2hpY2ggc3lzdGVtcyBjYW4gd3JpdGUg
dG8gdGhlIHJlZ2lzdGVyZWQgY2xpZW50IHN0b3JlIGlzIGdvaW5nIHRvIGJlIGRpZmZlcmVudCB0
aGFuIHRoZSBkeW5hbWljIGNsaWVudCBzdG9yZS4NCg0KSW4gWFlaLCBzdWJzZXF1ZW50IGNhbGxz
IHRvIHRoZSBBUywgYm90aCByZWdpc3RlcmVkIGNsaWVudHMgYW5kIGR5bmFtaWMgY2xpZW50cyBw
YXNzIGEga2V5IGhhbmRsZSwgc28gdGhlcmUgaXMgbm8gZWFzeSB3YXkgdG8gZGlmZmVyZW50aWF0
ZSBiZXR3ZWVuIHRoZSB0d28uDQoNCldoaWxlIHRoZSBBUyBjb3VsZCBlbWJlZCBzZW1hbnRpY3Mg
aW4gdGhlIGtleSBoYW5kbGUgaWRlbnRpZmllciB0byBpbmRpY2F0ZSB3aGljaCBpZGVudGlmaWVy
cyBhcmUgcHJlLXJlZ2lzdGVyZWQgdnMgZHluYW1pYywgdGhlcmUgYXJlIG1hbnkgY2FzZXMgd2hl
cmUgdGhlIEFTIGRvZXMgbmVlZCB0byBrbm93IHRoZSBkaWZmZXJlbmNlLCBzbyBtYWtpbmcgdGhl
IGRpZmZlcmVuY2UgYSBmZWF0dXJlIG9mIEdOQVAgc2VlbXMgbGlrZSBhIGJldHRlciBwYXRoLg0K
DQoNCg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBmb3IgdGhlIHNvbGUgdXNl
IG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnRzIGFuZCBtYXkgYmUgcHJpdmlsZWdlZCwgY29uZmlk
ZW50aWFsIG9yIG90aGVyd2lzZSBleGVtcHQgZnJvbSBkaXNjbG9zdXJlIHVuZGVyIGxhdy4gQW55
IGRpc3RyaWJ1dGlvbiwgcHJpbnRpbmcgb3Igb3RoZXIgdXNlIGJ5IGFueW9uZSBvdGhlciB0aGFu
IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgYW4g
aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5
LCBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoaXMgZW1haWwgYW5kIGl0cyBhdHRhY2htZW50cy4N
Cg==

--_000_29AAF03B12B64E619BF4EF951506931Bsecurekeycom_
Content-Type: text/html; charset="utf-8"
Content-ID: <765A1E182A2F0C4295E4AEBC5CA9A541@CANPRD01.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N
c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox
MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h
cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t
Q0EiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIGNsaWVudCByZWdpc3RyYXRpb24gaW4gc2Nv
cGUgZm9yIHRoZSBwcm90b2NvbD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBnZW5lcmljIHdh
eSBvZiBoYW5kbGluZyBjbGllbnRzICh2aWEgSUQgb3IgSGFuZGxlIG9yIEtleSBvciB3aGF0ZXZl
cikgaXMgdG8gaGF2ZSBwcm9jZXNzaW5nIHJ1bGUgb24gdGhlIEFTIHN1Y2ggYXMg4oCcaWYgdGhl
IEFTIHJlY29nbml6ZXMgdGhlIGNsaWVudCBJRCAoYW5kIGF1dGhlbnRpY2F0aW9uIG9mIHRoYXQg
Y2xpZW50IElEKSB0aGVuIGl0IG1heSBwcm9jZXNzIHRoZSByZXF1ZXN0IG9uIGJlaGFsZiBvZg0K
IHRoYXQgY2xpZW50LiBJZiB0aGUgQVMgZG9lcyBub3QgcmVjb2duaXplIHRoZSBjbGllbnQgSUQs
IGl0IG11c3QgdHJlYXQgdGhpcyBhcyBhIG5ldyBjbGllbnQgcmVnaXN0cmF0aW9uIGFuZCBldmFs
dWF0ZSBhbnkgYXV0aG9yaXphdGlvbiBldmlkZW5jZSB0aGUgY2xpZW50IHByb3ZpZGVzIGJlZm9y
ZSBlbmFibGluZyB0aGUgY2xpZW50IGFuZCBtYXBwaW5nIHBvbGljaWVzIHRvIHRoYXQgY2xpZW50
4oCdICh0aGlzIG1lYW5zIGR5bmFtaWMgb3IgYXV0b21hdGljDQogY2xpZW50cyBuZWVkIHRvIHBy
b3ZpZGUgYWRkaXRpb25hbCBhc3NlcnRpb25zIC8gc29mdHdhcmUgc3RhdGVtZW50cyB3aGF0ZXZl
ciB0byByZWdpc3RlciB0aGVpciBJRC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21ldGhp
bmcgbGlrZSB0aGlzIGFsbG93cyBmb3IgdmVyeSBmbGV4aWJsZSBzeXN0ZW1zOjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3lzdGVtIEEgY2FuIGJlIHVua25vd24gdG8gdGhl
IEFTIGJ1dCBjYW4gZHluYW1pY2FsbHkgcmVnaXN0ZXJlZCBlYWNoIHRpbWUgd2l0aCBhbiBhcHBy
b3ByaWF0ZSBzb2Z0d2FyZSBzdGF0ZW1lbnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlN5c3RlbSBCIGNhbiBoYXZlIGEgZmFpcmx5IHN0YWJsZSBjbGllbnQgSUQgYXQgdGhl
IEFTLCBidXQgcm90YXRlIHRoYXQgSUQgZXZlcnkgbW9udGggdGhyb3VnaCBhdXRvbWF0aWMgcmVn
aXN0cmF0aW9uICh3aXRoIGFuIGFzc2VydGlvbiBpdCBnb3QgZnJvbSB0aGUgQVMgZHVyaW5nIGEg
cHJlLXJlZ2lzdHJhdGlvbiBmb3IgZXhhbXBsZSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlN5c3RlbSBDIGNhbiBwcmUtcmVnaXN0ZXIgd2l0aCB0aGUgQVMgZm9yIGEgY2xp
ZW50IElEIGJlY2F1c2UgaXQgZG9lc27igJl0IGRlYWwgd2l0aCBzb2Z0d2FyZSBzdGF0ZW1lbnRz
IGV0Y+KApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCmPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgZXZlbiDigJhTdGF0ZWxlc3NBU+KAmSBj
YW4gb3BlcmF0ZSBieSBuZXZlciBzdG9yaW5nIGNsaWVudCBJRHMgYmVjYXVzZSBpdCB3aWxsIGFs
d2F5cyBqdXN0IHJlbHkgb24gdGhlIHNvZnR3YXJlIHN0YXRlbWVudHMuDQo8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SSB0aGluayBhIGNsaWVudCByZWdpc3RyYXRpb24gcHJvdG9jb2wgdGhhdCBh
bGxvd3MgdGhlc2Ugc2NlbmFyaW9zIHdvdWxkIGJlIHZlcnkgdXNlZnVsIGluIEdOQVAsIGJ1dCBo
b3BlZnVsbHkgYXZvaWRpbmcgaGF2aW5nIHRvIGRlZmluZSB3aGF0IOKAmGV2aWRlbmNl4oCZIHRo
ZSBBUyBuZWVkcyB0byBhY2NlcHQgZm9yIGVhY2ggc2NlbmFyaW8uPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TVY8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg
MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2
LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206
DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5U
eGF1dGggJmx0O3R4YXV0aC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgTWlrZSBK
b25lcyAmbHQ7TWljaGFlbC5Kb25lcz00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7
PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEp1bHkgMTQsIDIwMjAgYXQgMTI6MTggUE08YnI+
DQo8Yj5UbzogPC9iPkRpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0OywgJnF1
b3Q7dHhhdXRoQGlldGYub3JnJnF1b3Q7ICZsdDt0eGF1dGhAaWV0Zi5vcmcmZ3Q7LCBKdXN0aW4g
UmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBb
VHhhdXRoXSBLZXkgaGFuZGxlIHZzIGNsaWVudCBpZCAmYW1wOyBoYW5kbGU8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMwMDIwNjAiPkkgYWdyZWUgdGhhdCB0aGVyZSBhcmUgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZXMg
YmV0d2VlbiBzdGF0aWNhbGx5IGFuZCBkeW5hbWljYWxseSByZWdpc3RlcmVkIGNsaWVudHMgYW5k
IHRoYXTigJlzIGFwcHJvcHJpYXRlIHRvIGJlIGFibGUgdG8gc3ludGFjdGljYWxseSBkaWZmZXJl
bnRpYXRlIGJldHdlZW4gdGhlbSBhdA0KIHJ1bnRpbWUuJm5ic3A7IEZvciBvbmUgdGhpbmcsIHRo
ZSByZXNvdXJjZSByZXF1aXJlbWVudHMgYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGNhbiBi
ZSB2ZXJ5IGRpZmZlcmVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2
MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPldlIHNo
b3VsZCBhbHNvIGJlIHRoaW5raW5nIGFib3V0IGhvdyB0byBpbmNsdWRlIHdoYXQgdGhlIE9wZW5J
RCBDb25uZWN0IEZlZGVyYXRpb24gc3BlYw0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vb3Blbmlk
Lm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1mZWRlcmF0aW9uLTFfMC5odG1sIj5odHRwczovL29w
ZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZmVkZXJhdGlvbi0xXzAuaHRtbDwvYT4gY2Fs
bHMg4oCcQXV0b21hdGljIFJlZ2lzdHJhdGlvbuKAnS4mbmJzcDsgVGhpcyBsZXRzIHRoZSBjbGll
bnQgZW5jb2RlIGEgcmVnaXN0cmF0aW9uIHJlcXVlc3QgcmVmZXJlbmNlIGluIHRoZSBjbGllbnQg
SUQsIHNvIG5vDQogc3RhdGljIG9yIGR5bmFtaWMgcmVnaXN0cmF0aW9uIGV2ZW4gb2NjdXJzLiZu
YnNwOyBTZWUgPGEgaHJlZj0iaHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0
LWZlZGVyYXRpb24tMV8wLTEyLmh0bWwjcmZjLnNlY3Rpb24uOS4xIj4NCmh0dHBzOi8vb3Blbmlk
Lm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1mZWRlcmF0aW9uLTFfMC0xMi5odG1sI3JmYy5zZWN0
aW9uLjkuMTwvYT4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2
MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+RnJv
bTo8L2I+IERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ow0KPGJyPg0KPGI+
U2VudDo8L2I+IEZyaWRheSwgSnVseSAxMCwgMjAyMCAxOjE3IFBNPGJyPg0KPGI+VG86PC9iPiB0
eGF1dGhAaWV0Zi5vcmc7IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDs7IE1p
a2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5TdWJq
ZWN0OjwvYj4gS2V5IGhhbmRsZSB2cyBjbGllbnQgaWQgJmFtcDsgaGFuZGxlPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w
cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiYjNDM7IE1pa2UgYXMgaGUgaGFkIGludGVyZXN0IGlu
IHRoaXMgdG9waWM8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5NeSB1bmRlcnN0
YW5kaW5nIGlzIHRoYXQgYW4gZXhpc3RpbmcgT0F1dGggMiBjbGllbnQgd291bGQgdXNlIHRoZWly
IGN1cnJlbnQgY2xpZW50IGlkIGFzIHRoZWlyIGtleSBoYW5kbGUsIGFuZCBhIGR5bmFtaWMgY2xp
ZW50IChvbmUgdGhhdCB3YXMgbm90IHByZS1yZWdpc3RlcmVkKSB3b3VsZCBiZSBnaXZlbiBhIGtl
eSBoYW5kbGUgYnkgdGhlIEFTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6MzYuMHB0Ij5UaGVyZSBhcmUgcG90ZW50aWFsbHkgc29tZSBzaWduaWZpY2FudCBkaWZm
ZXJlbmNlcyBiZXR3ZWVuIGEgcmVnaXN0ZXJlZCBjbGllbnQsIGFuZCBhIGR5bmFtaWMgY2xpZW50
IHRvIGFuIEFTLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu
MHB0Ij5UaGUgQVMgaXMgbGlrZWx5IHRvIGtub3cgdGhlIGlkZW50aXR5IG9mIGEgcmVnaXN0ZXJl
ZCBjbGllbnQsIGFuZCBoYXZlIGRpZmZlcmVudCBwb2xpY2llcyBiZXR3ZWVuIHRoZSB0d28gdHlw
ZXMgb2YgY2xpZW50cy4gRm9yIGV4YW1wbGUsIGEgcmVnaXN0ZXJlZCBjbGllbnQgbWF5IGhhdmUg
YWNjZXNzIHRvIGEgJ3dyaXRlJnF1b3Q7IHNjb3BlLCB3aGlsZSBhIGR5bmFtaWMNCiBjbGllbnQg
ZG9lcyBub3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w
cHQiPlRoZSBBUyBtYXkgaGF2ZSAxMDBzIG9yIDEwMDBzIG9mIHJlZ2lzdGVyZWQgY2xpZW50cywg
YnV0IGEgZHluYW1pYyBjbGllbnQgbWF5IGhhdmUgMTBNcyBvciAxMDBNcyBvZiBpbnN0YW5jZXMs
IHdoaWNoIG1heSBkaWN0YXRlIHNlcGFyYXRlJm5ic3A7c3RvcmFnZSBzZXJ2aWNlcy4gQWRkaXRp
b25hbGx5LCBpbnRlcm5hbCB0byB0aGUgQVMsIHdoaWNoIHN5c3RlbXMgY2FuIHdyaXRlDQogdG8g
dGhlIHJlZ2lzdGVyZWQmbmJzcDtjbGllbnQgc3RvcmUgaXMgZ29pbmcgdG8gYmUgZGlmZmVyZW50
IHRoYW4gdGhlIGR5bmFtaWMgY2xpZW50Jm5ic3A7c3RvcmUuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkluIFhZWiwgc3Vic2VxdWVudCBjYWxscyB0
byB0aGUgQVMsIGJvdGggcmVnaXN0ZXJlZCBjbGllbnRzIGFuZCBkeW5hbWljIGNsaWVudHMgcGFz
cyBhIGtleSBoYW5kbGUsIHNvIHRoZXJlIGlzIG5vIGVhc3kgd2F5IHRvIGRpZmZlcmVudGlhdGUg
YmV0d2VlbiB0aGUgdHdvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl
ZnQ6MzYuMHB0Ij5XaGlsZSB0aGUgQVMgY291bGQgZW1iZWQgc2VtYW50aWNzIGluIHRoZSBrZXkg
aGFuZGxlIGlkZW50aWZpZXIgdG8gaW5kaWNhdGUgd2hpY2ggaWRlbnRpZmllcnMgYXJlIHByZS1y
ZWdpc3RlcmVkIHZzIGR5bmFtaWMsIHRoZXJlIGFyZSBtYW55IGNhc2VzIHdoZXJlIHRoZSBBUyBk
b2VzIG5lZWQgdG8ga25vdyB0aGUgZGlmZmVyZW5jZSwgc28gbWFraW5nJm5ic3A7dGhlIGRpZmZl
cmVuY2UNCiBhIGZlYXR1cmUgb2YgR05BUCBzZWVtcyBsaWtlIGEgYmV0dGVyIHBhdGguPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgaWQ9
ImJvZHkiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7IGNvbG9yOmRhcmtncmF5OyBsaW5lLWhlaWdo
dDoxMHB0OyBmb250LWZhbWlseTogJ0FyaWFsJywndGltZXMgcm9tYW4nLHNlcmlmOyI+DQpUaGlz
IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGlu
dGVuZGVkIHJlY2lwaWVudHMgYW5kIG1heSBiZSBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwgb3Ig
b3RoZXJ3aXNlIGV4ZW1wdCBmcm9tIGRpc2Nsb3N1cmUgdW5kZXIgbGF3LiBBbnkgZGlzdHJpYnV0
aW9uLCBwcmludGluZyBvciBvdGhlciB1c2UgYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVu
ZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLg0KIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVk
IHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwgYW5kIHBl
cm1hbmVudGx5IGRlbGV0ZSB0aGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMuPC9wPg0KPC9k
aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_29AAF03B12B64E619BF4EF951506931Bsecurekeycom_--


From nobody Tue Jul 14 12:31: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 BF1B23A09D8 for ; Tue, 14 Jul 2020 12:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Q57-0yFEox3m for ; Tue, 14 Jul 2020 12:31:36 -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 28A253A0ACF for ; Tue, 14 Jul 2020 12:31:34 -0700 (PDT)
Received: from [192.168.1.7] (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 06EJVVtJ029555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Jul 2020 15:31:32 -0400
From: Justin Richer 
Message-Id: <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1964F3F2-BA9C-4366-B9A3-C418A3471219"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 14 Jul 2020 15:31:31 -0400
In-Reply-To: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com>
Cc: Mike Jones , Dick Hardt , "txauth@ietf.org" 
To: Mike Varley 
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 14 Jul 2020 19:31:44 -0000

--Apple-Mail=_1964F3F2-BA9C-4366-B9A3-C418A3471219
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I not only agree with Mike Jones that =E2=80=9Cautomatic registration=E2=80=
=9D should be part of the process, but I would argue that that kind of =
model should be a default mode of operation. If you have an identifier =
that you can send to short-circuit that, great! But we should focus on =
having the capability of inlining a lot of this information wherever =
possible. This is already the direction that the input proposals are =
heading.

So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope for =
the protocol in general, and since both XYZ and Xauth have mechanisms =
that allow the client to present a key and get back an identifier that =
it can use in the future we have something equivalent.=20

But I think there=E2=80=99s a little more to it than that: Ultimately, I =
think we should question thinking in terms of =E2=80=9Cregistration=E2=80=9D=
, a model which has hampered the OAuth 2 model in a lot of use cases. =
For example, the federation draft Mike Jones references below hacks the =
=E2=80=9Cclient_id=E2=80=9D parameter and makes it point to a document =
that the AS has to fetch. This construct is done for two reasons: (1) =
Oauth requires a =E2=80=9Cclient_id=E2=80=9D in the request and (2) =
it=E2=80=99s difficult to pass information by value to the AS due to =
front-channel restrictions. Since we=E2=80=99re defining a new protocol, =
we don=E2=80=99t need to hack that functionality into a =E2=80=9Cclient =
ID=E2=80=9D or equivalent and instead we can pass that information =
directly in the protocol. If we don=E2=80=99t assume that the client =
*has* to have a client ID equivalent, but it *can* have one in a set of =
defined circumstances, then I think we are in a much better spot. This =
is the reasoning for XYZ=E2=80=99s model of having clients identified by =
the key, and that key can potentially be passed by a reference =
identifier.

I think all of the use cases that Mike Varley presents below are all =
valid directions, with the caveat that we shouldn=E2=80=99t assume a =
client should be presenting an ID at all steps. Mechanisms like software =
statements should be presentable apart from a client ID, as should =
on-device keys. We=E2=80=99re probably going to want extensions for =
device posture and other forms of attestation as well.

This is one of the domains that I think we can clearly surpass OAuth =
2=E2=80=99s flexibility and capabilities if we are willing to look past =
OAuth 2=E2=80=99s assumptions of what=E2=80=99s needed inline in the =
protocol.=20

 =E2=80=94 Justin

> On Jul 14, 2020, at 1:54 PM, Mike Varley  =
wrote:
>=20
> Is client registration in scope for the protocol?
> =20
> A generic way of handling clients (via ID or Handle or Key or =
whatever) is to have processing rule on the AS such as =E2=80=9Cif the =
AS recognizes the client ID (and authentication of that client ID) then =
it may process the request on behalf of that client. If the AS does not =
recognize the client ID, it must treat this as a new client registration =
and evaluate any authorization evidence the client provides before =
enabling the client and mapping policies to that client=E2=80=9D (this =
means dynamic or automatic clients need to provide additional assertions =
/ software statements whatever to register their ID.
> =20
> Something like this allows for very flexible systems:
> System A can be unknown to the AS but can dynamically registered each =
time with an appropriate software statement
> System B can have a fairly stable client ID at the AS, but rotate that =
ID every month through automatic registration (with an assertion it got =
from the AS during a pre-registration for example)
> System C can pre-register with the AS for a client ID because it =
doesn=E2=80=99t deal with software statements etc=E2=80=A6
> =E2=80=A6
> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing =
client IDs because it will always just rely on the software statements.
> =20
> I think a client registration protocol that allows these scenarios =
would be very useful in GNAP, but hopefully avoiding having to define =
what =E2=80=98evidence=E2=80=99 the AS needs to accept for each =
scenario.
> =20
> Thanks,
> =20
> MV
> =20
> From: Txauth > on behalf of Mike Jones =
>
> Date: Tuesday, July 14, 2020 at 12:18 PM
> To: Dick Hardt >, =
"txauth@ietf.org " >, Justin Richer >
> Subject: Re: [Txauth] Key handle vs client id & handle
> =20
> I agree that there are significant differences between statically and =
dynamically registered clients and that=E2=80=99s appropriate to be able =
to syntactically differentiate between them at runtime.  For one thing, =
the resource requirements at the authorization server can be very =
different.
> =20
> We should also be thinking about how to include what the OpenID =
Connect Federation spec =
https://openid.net/specs/openid-connect-federation-1_0.html =
 calls =
=E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client encode a =
registration request reference in the client ID, so no static or dynamic =
registration even occurs.  See =
https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section=
.9.1 =
.
> =20
>                                                        -- Mike
> =20
> From: Dick Hardt >=20=

> Sent: Friday, July 10, 2020 1:17 PM
> To: txauth@ietf.org ; Justin Richer =
>; Mike Jones =
>
> Subject: Key handle vs client id & handle
> =20
> + Mike as he had interest in this topic
> =20
> My understanding is that an existing OAuth 2 client would use their =
current client id as their key handle, and a dynamic client (one that =
was not pre-registered) would be given a key handle by the AS.
> =20
> There are potentially some significant differences between a =
registered client, and a dynamic client to an AS.
> =20
> The AS is likely to know the identity of a registered client, and have =
different policies between the two types of clients. For example, a =
registered client may have access to a 'write" scope, while a dynamic =
client does not.
> =20
> The AS may have 100s or 1000s of registered clients, but a dynamic =
client may have 10Ms or 100Ms of instances, which may dictate separate =
storage services. Additionally, internal to the AS, which systems can =
write to the registered client store is going to be different than the =
dynamic client store.
> =20
> In XYZ, subsequent calls to the AS, both registered clients and =
dynamic clients pass a key handle, so there is no easy way to =
differentiate between the two.
> =20
> While the AS could embed semantics in the key handle identifier to =
indicate which identifiers are pre-registered vs dynamic, there are many =
cases where the AS does need to know the difference, so making the =
difference a feature of GNAP seems like a better path.
> =20
> =20
> 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.
>=20


--Apple-Mail=_1964F3F2-BA9C-4366-B9A3-C418A3471219
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
not only agree with Mike Jones that =E2=80=9Cautomatic registration=E2=80=9D=
 should be part of the process, but I would argue that that kind of =
model should be a default mode of operation. If you have an identifier =
that you can send to short-circuit that, great! But we should focus on =
having the capability of inlining a lot of this information wherever =
possible. This is already the direction that the input proposals are =
heading.

So I =
kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope for the =
protocol in general, and since both XYZ and Xauth have mechanisms that =
allow the client to present a key and get back an identifier that it can =
use in the future we have something equivalent. 

But I think there=E2=80=99=
s a little more to it than that: Ultimately, I think we should question =
thinking in terms of =E2=80=9Cregistration=E2=80=9D, a model which has =
hampered the OAuth 2 model in a lot of use cases. For example, the =
federation draft Mike Jones references below hacks the =E2=80=9Cclient_id=E2=
=80=9D parameter and makes it point to a document that the AS has to =
fetch. This construct is done for two reasons: (1) Oauth requires a =
=E2=80=9Cclient_id=E2=80=9D in the request and (2) it=E2=80=99s =
difficult to pass information by value to the AS due to front-channel =
restrictions. Since we=E2=80=99re defining a new protocol, we don=E2=80=99=
t need to hack that functionality into a =E2=80=9Cclient ID=E2=80=9D or =
equivalent and instead we can pass that information directly in the =
protocol. If we don=E2=80=99t assume that the client *has* to have a =
client ID equivalent, but it *can* have one in a set of defined =
circumstances, then I think we are in a much better spot. This is the =
reasoning for XYZ=E2=80=99s model of having clients identified by the =
key, and that key can potentially be passed by a reference =
identifier.

I =
think all of the use cases that Mike Varley presents below are all valid =
directions, with the caveat that we shouldn=E2=80=99t assume a client =
should be presenting an ID at all steps. Mechanisms like software =
statements should be presentable apart from a client ID, as should =
on-device keys. We=E2=80=99re probably going to want extensions for =
device posture and other forms of attestation as well.

This is one of the =
domains that I think we can clearly surpass OAuth 2=E2=80=99s =
flexibility and capabilities if we are willing to look past OAuth 2=E2=80=99=
s assumptions of what=E2=80=99s needed inline in the =
protocol. 

 =E2=80=94 Justin

On Jul =
14, 2020, at 1:54 PM, Mike Varley <mike.varley@securekey.com> wrote:

Is client =
registration in scope for the protocol?
 
A generic way of handling clients (via =
ID or Handle or Key or whatever) is to have processing rule on the AS =
such as =E2=80=9Cif the AS recognizes the client ID (and authentication =
of that client ID) then it may process the request on behalf of that =
client. If the AS does not recognize the client ID, it must treat this =
as a new client registration and evaluate any authorization evidence the =
client provides before enabling the client and mapping policies to that =
client=E2=80=9D (this means dynamic or automatic clients need to provide =
additional assertions / software statements whatever to register their =
ID.
 
Something =
like this allows for very flexible systems:
System A =
can be unknown to the AS but can dynamically registered each time with =
an appropriate software statement
System B can have a fairly stable =
client ID at the AS, but rotate that ID every month through automatic =
registration (with an assertion it got from the AS during a =
pre-registration for example)
System C can pre-register with the AS =
for a client ID because it doesn=E2=80=99t deal with software statements =
etc=E2=80=A6
=E2=80=A6
And even =E2=80=98StatelessAS=E2=80=99 can operate by never =
storing client IDs because it will always just rely on the software =
statements.
 
I think a client registration protocol that allows these =
scenarios would be very useful in GNAP, but hopefully avoiding having to =
define what =E2=80=98evidence=E2=80=99 the AS needs to accept for each =
scenario.
 
Thanks,
 
MV
 
From: Txauth <txauth-bounces@ietf.org> =
on behalf of Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
Date: Tuesday, July 14, 2020 =
at 12:18 PM
To: Dick Hardt <dick.hardt@gmail.com>, =
"txauth@ietf.org" <txauth@ietf.org>, Justin =
Richer <jricher@mit.edu>
Subject: Re: [Txauth] Key handle =
vs client id & handle
 
I agree =
that there are significant differences between statically and =
dynamically registered clients and that=E2=80=99s appropriate to be able =
to syntactically differentiate between them at runtime.  For one =
thing, the resource requirements at the authorization server can be very =
different.
 
We should also be thinking about how to include what the =
OpenID Connect Federation spec https://openid.net/specs/openid-connect-federation-1_0.html=
 calls =E2=80=9CAutomati=
c Registration=E2=80=9D.  This lets the client encode a =
registration request reference in the client ID, so no static or dynamic =
registration even occurs.  See https://openid.net/specs/openid-connect-federation-1_0-12.html#=
rfc.section.9.1.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 
From: Dick Hardt <dick.hardt@gmail.com> 
Sent: Friday, July 10, 2020 1:17 =
PM
To: txauth@ietf.org; Justin =
Richer <jricher@mit.edu>; =
Mike Jones <Michael.Jones@microsoft.com>
Subject: Key handle vs client id =
& handle
 
+ Mike as he had interest in this =
topic
 
My understanding is that =
an existing OAuth 2 client would use their current client id as their =
key handle, and a dynamic client (one that was not pre-registered) would =
be given a key handle by the AS.
 
There are potentially some significant differences between a =
registered client, and a dynamic client to an AS.
 
The AS is likely to know the identity =
of a registered client, and have different policies between the two =
types of clients. For example, a registered client may have access to a =
'write" scope, while a dynamic client does not.
 
The AS may have 100s or 1000s of =
registered clients, but a dynamic client may have 10Ms or 100Ms of =
instances, which may dictate separate storage services. =
Additionally, internal to the AS, which systems can write to the =
registered client store is going to be different than the dynamic =
client store.
 
In XYZ, subsequent calls to the AS, both registered clients =
and dynamic clients pass a key handle, so there is no easy way to =
differentiate between the two.
 
While the AS could embed semantics in the key handle =
identifier to indicate which identifiers are pre-registered vs dynamic, =
there are many cases where the AS does need to know the difference, so =
making the difference a feature of GNAP seems like a better =
path.
 
 
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.

=

--Apple-Mail=_1964F3F2-BA9C-4366-B9A3-C418A3471219--


From nobody Tue Jul 14 13:00: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 E8CDB3A0ACB for ; Tue, 14 Jul 2020 13:00:36 -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 pdT9f63H1Fk9 for ; Tue, 14 Jul 2020 13:00:35 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 BD74A3A0AC3 for ; Tue, 14 Jul 2020 13:00:34 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id q5so24456067wru.6 for ; Tue, 14 Jul 2020 13:00:34 -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=/BbJsO5YBaM3o/G0+7AVcWGY59c67z2FUv5+vOTFdGk=; b=XMUfiWxCKQNt2/RPICVUMUNlfUVLGJwONBgNbZwNqAFp5AJXrQpnjNO6OaXeRIilap KpbA4iViuAQR/IlctqaZINOP1BQCKUUX5nQI3VK1bQhBhls8vo3xMcBIBNTRKVq0lgS9 2GUDkL/V9RGqVkKbGaWR+CWEkI6cpRbVEa0SIKN+8IfOcV3Uj6IV9o3j4NDLp9jcdSjw rqSIj8bxWI0jnytwdT9h4yoiCqMSI45hCb8qxyOVqo8QQZA+7QzoAxim1JlOsd53P6ML QIdGfbG0SMdz4pVd56C3WKFeUEtQ/riqArvmXYEj35BfqRQM+8dc/qLrLLJa2uYZI/99 uN0g==
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=/BbJsO5YBaM3o/G0+7AVcWGY59c67z2FUv5+vOTFdGk=; b=f23BxP97GEjWQCdUONy/atCxXVIrgBTpjMoy2NbbT4Lu6LE6hC6jlOeBEjh+L52qmD 0AJZs+CQ+VNHK+EupZU0lDbuk1fVtP7ZQ6/AjArinoGcoT9sn2Majl+XV3jXfKwRGPUz GT8nMbnSsNGYqcHdM2zO+C07rKBTWUwWAkNugDe7cGkkGDu/O9W/Q9ZI398LjRHrmjvE xn0yn0JnaVcT6jGZD1hniAadJzQMC+jzGbVZcMN62uc0S8XwtgL7RRPyBWEQdayY4RHy +4GJI2f+ezgGPi8DVM5W27EIZT01jwANtD+BnRXtkRQkgUe2IRdUviU+MNBfNG/QvZeD nWMg==
X-Gm-Message-State: AOAM533MloUzrCIc7NIyxW4f31OkWyo1nt3LtgIqQDQYg8wmbc1/xrsi DjRLzyuvlxZzxXJGiR7N/eWQeMRPwjeQd3BfrwGfMEtK
X-Google-Smtp-Source: ABdhPJyGz1SVOwvO83+IuKCuq5jkM4pUlQdz55nhasTVLtEwuGFSN99spVJEcvn1IXu3f/pTZBhJ2pOirIV6tHoY2mo=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr3151091ljh.110.1594752833286;  Tue, 14 Jul 2020 11:53:53 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com>
In-Reply-To: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com>
From: Dick Hardt 
Date: Tue, 14 Jul 2020 11:53:17 -0700
Message-ID: 
To: Mike Varley 
Cc: Mike Jones ,  "txauth@ietf.org" , Justin Richer 
Content-Type: multipart/alternative; boundary="00000000000021f7af05aa6b5483"
Archived-At: 
Subject: [Txauth] Client Registration (Was: Key handle vs client id & handle
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, 14 Jul 2020 20:00:37 -0000

--00000000000021f7af05aa6b5483
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

(changing subject to reflect topic)

In my opinion, client registration is in scope.

In both XYZ and XAuth, the client can provide some information about
itself, and get back an ID it can use in subsequent calls. No one has said
that should NOT be in scope so far.

Myself, I do support adding other mechanisms for a Client to share
information about itself with an AS such as software statements, or a URI
that binds a URI to information retrieved from that URI, and to the Client.

I agree that we don't want to define software statements per se, but we
should refer to some standards so that interop between clients and ASs.

/Dick

On Tue, Jul 14, 2020 at 10:54 AM Mike Varley 
wrote:

> Is client registration in scope for the protocol?
>
>
>
> A generic way of handling clients (via ID or Handle or Key or whatever) i=
s
> to have processing rule on the AS such as =E2=80=9Cif the AS recognizes t=
he client
> ID (and authentication of that client ID) then it may process the request
> on behalf of that client. If the AS does not recognize the client ID, it
> must treat this as a new client registration and evaluate any authorizati=
on
> evidence the client provides before enabling the client and mapping
> policies to that client=E2=80=9D (this means dynamic or automatic clients=
 need to
> provide additional assertions / software statements whatever to register
> their ID.
>
>
>
> Something like this allows for very flexible systems:
>
> System A can be unknown to the AS but can dynamically registered each tim=
e
> with an appropriate software statement
>
> System B can have a fairly stable client ID at the AS, but rotate that ID
> every month through automatic registration (with an assertion it got from
> the AS during a pre-registration for example)
>
> System C can pre-register with the AS for a client ID because it doesn=E2=
=80=99t
> deal with software statements etc=E2=80=A6
>
> =E2=80=A6
>
> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing clien=
t IDs because it
> will always just rely on the software statements.
>
>
>
> I think a client registration protocol that allows these scenarios would
> be very useful in GNAP, but hopefully avoiding having to define what
> =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
>
>
>
> Thanks,
>
>
>
> MV
>
>
>
> *From: *Txauth  on behalf of Mike Jones
> 
> *Date: *Tuesday, July 14, 2020 at 12:18 PM
> *To: *Dick Hardt , "txauth@ietf.org" <
> txauth@ietf.org>, Justin Richer 
> *Subject: *Re: [Txauth] Key handle vs client id & handle
>
>
>
> I agree that there are significant differences between statically and
> dynamically registered clients and that=E2=80=99s appropriate to be able =
to
> syntactically differentiate between them at runtime.  For one thing, the
> resource requirements at the authorization server can be very different.
>
>
>
> We should also be thinking about how to include what the OpenID Connect
> Federation spec
> https://openid.net/specs/openid-connect-federation-1_0.html calls
> =E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client encode a =
registration
> request reference in the client ID, so no static or dynamic registration
> even occurs.  See
> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.sectio=
n.9.1
> .
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Dick Hardt 
> *Sent:* Friday, July 10, 2020 1:17 PM
> *To:* txauth@ietf.org; Justin Richer ; Mike Jones <
> Michael.Jones@microsoft.com>
> *Subject:* Key handle vs client id & handle
>
>
>
> + Mike as he had interest in this topic
>
>
>
> My understanding is that an existing OAuth 2 client would use their
> current client id as their key handle, and a dynamic client (one that was
> not pre-registered) would be given a key handle by the AS.
>
>
>
> There are potentially some significant differences between a registered
> client, and a dynamic client to an AS.
>
>
>
> The AS is likely to know the identity of a registered client, and have
> different policies between the two types of clients. For example, a
> registered client may have access to a 'write" scope, while a dynamic
> client does not.
>
>
>
> The AS may have 100s or 1000s of registered clients, but a dynamic client
> may have 10Ms or 100Ms of instances, which may dictate separate storage
> services. Additionally, internal to the AS, which systems can write to th=
e
> registered client store is going to be different than the dynamic
> client store.
>
>
>
> In XYZ, subsequent calls to the AS, both registered clients and dynamic
> clients pass a key handle, so there is no easy way to differentiate betwe=
en
> the two.
>
>
>
> While the AS could embed semantics in the key handle identifier to
> indicate which identifiers are pre-registered vs dynamic, there are many
> cases where the AS does need to know the difference, so making the
> difference a feature of GNAP seems like a better path.
>
>
>
>
>
> 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 intend=
ed
> recipient, please contact the sender immediately, and permanently delete
> this email and its attachments.
>
=E1=90=A7

--00000000000021f7af05aa6b5483
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


(changing subject to reflect topic)

In my opinion, client registration is in scope.

In both XYZ and XAuth, the client can provide some information about =
itself, and get back an ID it can use in subsequent calls. No one has said =
that should NOT be in scope so far.

Myself, I do s=
upport adding other mechanisms for a Client to share information about itse=
lf with an AS such as software statements, or a URI that binds a URI to inf=
ormation retrieved from that URI, and to the Client.

I agree that we don't want to define software statements per se, but=
 we should refer to some standards so that interop between clients and ASs.=


/Dick

On Tue, Jul 14, 2020 at 10:54 AM Mike Varley=
 <mike.varley@securekey.com=
> wrote:











Is client registration in scope for the protocol?=



=C2=A0


A generic way of handling clients (via ID or Handle =
or Key or whatever) is to have processing rule on the AS such as =E2=80=9Ci=
f the AS recognizes the client ID (and authentication of that client ID) th=
en it may process the request on behalf of
 that client. If the AS does not recognize the client ID, it must treat thi=
s as a new client registration and evaluate any authorization evidence the =
client provides before enabling the client and mapping policies to that cli=
ent=E2=80=9D (this means dynamic or automatic
 clients need to provide additional assertions / software statements whatev=
er to register their ID.



=C2=A0


Something like this allows for very flexible systems=
:


System A can be unknown to the AS but can dynamicall=
y registered each time with an appropriate software statement=



System B can have a fairly stable client ID at the A=
S, but rotate that ID every month through automatic registration (with an a=
ssertion it got from the AS during a pre-registration for example)


System C can pre-register with the AS for a client I=
D because it doesn=E2=80=99t deal with software statements etc=E2=80=A6<=
/u>


=E2=80=A6


And even =E2=80=98StatelessAS=E2=80=99 can operate b=
y never storing client IDs because it will always just rely on the software=
 statements.



=C2=A0


I think a client registration protocol that allows t=
hese scenarios would be very useful in GNAP, but hopefully avoiding having =
to define what =E2=80=98evidence=E2=80=99 the AS needs to accept for each s=
cenario.


=C2=A0


Thanks,


=C2=A0


MV


=C2=A0




From:
Txauth <txauth-bounces@ietf.org<=
/a>> on behalf of Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org=
>

Date: Tuesday, July 14, 2020 at 12:18 PM

To: Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>=


Subject: Re: [Txauth] Key handle vs client id & handle=







=C2=A0




I agree that there are significant differences between statically=
 and dynamically registered clients and that=E2=80=99s appropriate to be ab=
le to syntactically differentiate between them at
 runtime.=C2=A0 For one thing, the resource requirements at the authorizati=
on server can be very different.


=C2=A0


We should also be thinking about how to include what the OpenID C=
onnect Federation spec
https://openid.net/specs/openid-connect-federation-1_=
0.html calls =E2=80=9CAutomatic Registration=E2=80=9D.=C2=A0 This lets =
the client encode a registration request reference in the client ID, so no
 static or dynamic registration even occurs.=C2=A0 See 
https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.=
9.1.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=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: Dick Hardt &=
lt;dick.hardt@gma=
il.com>


Sent: Friday, July 10, 2020 1:17 PM

To: txauth@ietf=
.org; Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>

Subject: Key handle vs client id & handle




=C2=A0




+ Mike as he had interest=
 in this topic




=C2=A0




My understanding is that =
an existing OAuth 2 client would use their current client id as their key h=
andle, and a dynamic client (one that was not pre-registered) would be give=
n a key handle by the AS.






=C2=A0






There are potentially som=
e significant differences between a registered client, and a dynamic client=
 to an AS.






=C2=A0






The AS is likely to know =
the identity of a registered client, and have different policies between th=
e two types of clients. For example, a registered client may have access to=
 a 'write" scope, while a dynamic
 client does not.






=C2=A0






The AS may have 100s or 1=
000s of registered clients, but a dynamic client may have 10Ms or 100Ms of =
instances, which may dictate separate=C2=A0storage services. Additionally, =
internal to the AS, which systems can write
 to the registered=C2=A0client store is going to be different than the dyna=
mic client=C2=A0store.






=C2=A0






In XYZ, subsequent calls =
to the AS, both registered clients and dynamic clients pass a key handle, s=
o there is no easy way to differentiate between the two.






=C2=A0






While the AS could embed =
semantics in the key handle identifier to indicate which identifiers are pr=
e-registered vs dynamic, there are many cases where the AS does need to kno=
w the difference, so making=C2=A0the difference
 a feature of GNAP seems like a better path.








=C2=A0






=C2=A0











This email and any attachments are for the sole use of the intended recipie=
nts and may be privileged, confidential or otherwise exempt from disclosure=
 under law. Any distribution, printing or other use by anyone other than th=
e intended recipient is prohibited.
 If you are not an intended recipient, please contact the sender immediatel=
y, and permanently delete this email and its attachments.







3D""=
=E1=90=A7


--00000000000021f7af05aa6b5483--


From nobody Tue Jul 14 16:26: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 9AB8E3A00B0 for ; Tue, 14 Jul 2020 16:26: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 BsIOPTUdfc9k for ; Tue, 14 Jul 2020 16:26:23 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 3EC043A0975 for ; Tue, 14 Jul 2020 16:25:31 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id h13so78154otr.0 for ; Tue, 14 Jul 2020 16:25:31 -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=uSdaOlaK2Wh6QSTlwwgo1tNo0oVmI0BS+9v2Z4glG+E=; b=qXzXdT5EJXHRoaTcgOHH+jB7X/kKaIz3hWydl6rQurZLOqHDN3TXAIC/Lq3PD6s7yP 07qvO+hLglMYUoRYKXcecQ4KuUGWLFnUS/xmETmsknJmNBY56lAQHYAuKep8ZoEvNb0S v9/+GXIoauqjFIzqhioHB51l1rz/05A8sP3UTQpLTf9o0UpJ3yYzY0roS8kiTzU32tDg dNQE6GTu0dQbe3HFsKDQmaHcezFWqtNhUGBFfvd1mzWaYrjYoAPxUECiVywqFtkfeV7J Jcu2qH9dw2U3PRlO5mAHMmg/9HnHwoJJqQv8TNwJdokPxj2n3D3W6tdkbQHAoWat0xPM tqLA==
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=uSdaOlaK2Wh6QSTlwwgo1tNo0oVmI0BS+9v2Z4glG+E=; b=e2Edmvri+WcYuL9oZ7eVTAjCg5YZT++GmnN6SkpJlt9GabsSJ+jlx7niEd3n15u7Ea KfQtXDCaSxtsz5ePQBkjY5O5puE7xCPpjvNx7Hi8Uv9jseqUAhsBDXX8nkGHCsLcFc3Z sfekxHMhv9bZKUNZ+T+2UzRv9lz93HyMI8VWve74xHcaNTFKUpQxPwhkoN+5QEI2QFDY gzWmYCVyyqgycCC+YxLjCMYjZHZqeTkZKdqCZNVNAH/XrN/cE+WnaUq1A5535wlbEdUs BjrE2omLsj87UpmsxuTh3Xb+PrA30jsb1BtiJhaQ3gEfkRS5jkm7goXoOM9DyR4UGWy5 /orw==
X-Gm-Message-State: AOAM532bxPJho2e6caSRT9iPGRdL/BVNBEoubZQoEEKp6N53+qUUUJQs zhCuJP4cSONG58KMUu++zosqs2fwtI3vC3hb9mE=
X-Google-Smtp-Source: ABdhPJzvczawDioI7s91plasfxG92lWBAWHRWk0ekB1pSq+bObtoZpBsGKKKiTODdRzOKVrIQ48yw+avRY7bZhyUdwI=
X-Received: by 2002:a9d:66ca:: with SMTP id t10mr6056041otm.358.1594769130386;  Tue, 14 Jul 2020 16:25:30 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> 
In-Reply-To: 
From: Tom Jones 
Date: Tue, 14 Jul 2020 16:25:18 -0700
Message-ID: 
To: Dick Hardt 
Cc: Mike Varley ,  Mike Jones ,  Justin Richer , "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000083f92e05aa6f1fbc"
Archived-At: 
Subject: Re: [Txauth] Client Registration (Was: Key handle vs client id & handle
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, 14 Jul 2020 23:26:27 -0000

--00000000000083f92e05aa6f1fbc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I suggested earlier to use the entity statement of the Openid federation
spec, but heard no feedback. Why not?

thx ..Tom (mobile)

On Tue, Jul 14, 2020, 1:00 PM Dick Hardt  wrote:

> (changing subject to reflect topic)
>
> In my opinion, client registration is in scope.
>
> In both XYZ and XAuth, the client can provide some information about
> itself, and get back an ID it can use in subsequent calls. No one has sai=
d
> that should NOT be in scope so far.
>
> Myself, I do support adding other mechanisms for a Client to share
> information about itself with an AS such as software statements, or a URI
> that binds a URI to information retrieved from that URI, and to the Clien=
t.
>
> I agree that we don't want to define software statements per se, but we
> should refer to some standards so that interop between clients and ASs.
>
> /Dick
>
> On Tue, Jul 14, 2020 at 10:54 AM Mike Varley 
> wrote:
>
>> Is client registration in scope for the protocol?
>>
>>
>>
>> A generic way of handling clients (via ID or Handle or Key or whatever)
>> is to have processing rule on the AS such as =E2=80=9Cif the AS recogniz=
es the
>> client ID (and authentication of that client ID) then it may process the
>> request on behalf of that client. If the AS does not recognize the clien=
t
>> ID, it must treat this as a new client registration and evaluate any
>> authorization evidence the client provides before enabling the client an=
d
>> mapping policies to that client=E2=80=9D (this means dynamic or automati=
c clients
>> need to provide additional assertions / software statements whatever to
>> register their ID.
>>
>>
>>
>> Something like this allows for very flexible systems:
>>
>> System A can be unknown to the AS but can dynamically registered each
>> time with an appropriate software statement
>>
>> System B can have a fairly stable client ID at the AS, but rotate that I=
D
>> every month through automatic registration (with an assertion it got fro=
m
>> the AS during a pre-registration for example)
>>
>> System C can pre-register with the AS for a client ID because it doesn=
=E2=80=99t
>> deal with software statements etc=E2=80=A6
>>
>> =E2=80=A6
>>
>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing clie=
nt IDs because it
>> will always just rely on the software statements.
>>
>>
>>
>> I think a client registration protocol that allows these scenarios would
>> be very useful in GNAP, but hopefully avoiding having to define what
>> =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> MV
>>
>>
>>
>> *From: *Txauth  on behalf of Mike Jones
>> 
>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>> *To: *Dick Hardt , "txauth@ietf.org" <
>> txauth@ietf.org>, Justin Richer 
>> *Subject: *Re: [Txauth] Key handle vs client id & handle
>>
>>
>>
>> I agree that there are significant differences between statically and
>> dynamically registered clients and that=E2=80=99s appropriate to be able=
 to
>> syntactically differentiate between them at runtime.  For one thing, the
>> resource requirements at the authorization server can be very different.
>>
>>
>>
>> We should also be thinking about how to include what the OpenID Connect
>> Federation spec
>> https://openid.net/specs/openid-connect-federation-1_0.html calls
>> =E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client encode a=
 registration
>> request reference in the client ID, so no static or dynamic registration
>> even occurs.  See
>> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.secti=
on.9.1
>> .
>>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> *From:* Dick Hardt 
>> *Sent:* Friday, July 10, 2020 1:17 PM
>> *To:* txauth@ietf..org ; Justin Richer ;
>> Mike Jones 
>> *Subject:* Key handle vs client id & handle
>>
>>
>>
>> + Mike as he had interest in this topic
>>
>>
>>
>> My understanding is that an existing OAuth 2 client would use their
>> current client id as their key handle, and a dynamic client (one that wa=
s
>> not pre-registered) would be given a key handle by the AS.
>>
>>
>>
>> There are potentially some significant differences between a registered
>> client, and a dynamic client to an AS.
>>
>>
>>
>> The AS is likely to know the identity of a registered client, and have
>> different policies between the two types of clients. For example, a
>> registered client may have access to a 'write" scope, while a dynamic
>> client does not.
>>
>>
>>
>> The AS may have 100s or 1000s of registered clients, but a dynamic clien=
t
>> may have 10Ms or 100Ms of instances, which may dictate separate storage
>> services. Additionally, internal to the AS, which systems can write to t=
he
>> registered client store is going to be different than the dynamic
>> client store.
>>
>>
>>
>> In XYZ, subsequent calls to the AS, both registered clients and dynamic
>> clients pass a key handle, so there is no easy way to differentiate betw=
een
>> the two.
>>
>>
>>
>> While the AS could embed semantics in the key handle identifier to
>> indicate which identifiers are pre-registered vs dynamic, there are many
>> cases where the AS does need to know the difference, so making the
>> difference a feature of GNAP seems like a better path.
>>
>>
>>
>>
>>
>> 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 inten=
ded
>> recipient, please contact the sender immediately, and permanently delete
>> this email and its attachments.
>>
> =E1=90=A7
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--00000000000083f92e05aa6f1fbc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I suggested earlier to use the entity statement of the Op=
enid federation spec, but heard no feedback. Why not?

thx ..Tom (mobile)

On Tue, Jul 14, 2020, 1:0=
0 PM Dick Hardt <dick.hardt@gmai=
l.com> wrote:
(changing subject to reflect topic)

In my =
opinion, client registration is in scope.

In both =
XYZ and XAuth, the client can provide some information about itself, and ge=
t back an ID it can use in subsequent calls. No one has said that should NO=
T be in scope so far.

Myself, I do support adding =
other mechanisms for a Client to share information about itself with an AS =
such as software statements, or a URI that binds a URI to information retri=
eved from that URI, and to the Client.

I agree tha=
t we don't want to define software statements per se, but we should ref=
er to some standards so that interop between clients and ASs.
/Dick

On Tue, Jul 14, 2020 at 10:54 AM Mike Varley <=
mike.varley@securekey.com> wrote:











Is client registration in scope for the protocol?=



=C2=A0


A generic way of handling clients (via ID or Handle =
or Key or whatever) is to have processing rule on the AS such as =E2=80=9Ci=
f the AS recognizes the client ID (and authentication of that client ID) th=
en it may process the request on behalf of
 that client. If the AS does not recognize the client ID, it must treat thi=
s as a new client registration and evaluate any authorization evidence the =
client provides before enabling the client and mapping policies to that cli=
ent=E2=80=9D (this means dynamic or automatic
 clients need to provide additional assertions / software statements whatev=
er to register their ID.



=C2=A0


Something like this allows for very flexible systems=
:


System A can be unknown to the AS but can dynamicall=
y registered each time with an appropriate software statement=



System B can have a fairly stable client ID at the A=
S, but rotate that ID every month through automatic registration (with an a=
ssertion it got from the AS during a pre-registration for example)


System C can pre-register with the AS for a client I=
D because it doesn=E2=80=99t deal with software statements etc=E2=80=A6<=
/u>


=E2=80=A6


And even =E2=80=98StatelessAS=E2=80=99 can operate b=
y never storing client IDs because it will always just rely on the software=
 statements.



=C2=A0


I think a client registration protocol that allows t=
hese scenarios would be very useful in GNAP, but hopefully avoiding having =
to define what =E2=80=98evidence=E2=80=99 the AS needs to accept for each s=
cenario.


=C2=A0


Thanks,


=C2=A0


MV


=C2=A0




From:
Txauth <txaut=
h-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>

Date: Tuesday, July 14, 2020 at 12:18 PM

To: Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.or=
g" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>=
;

Subject: Re: [Txauth] Key handle vs client id & handle=







=C2=A0




I agree that there are significant differences between statically=
 and dynamically registered clients and that=E2=80=99s appropriate to be ab=
le to syntactically differentiate between them at
 runtime.=C2=A0 For one thing, the resource requirements at the authorizati=
on server can be very different.


=C2=A0


We should also be thinking about how to include what the OpenID C=
onnect Federation spec
https://openid.net/specs/openid-co=
nnect-federation-1_0.html calls =E2=80=9CAutomatic Registration=E2=80=
=9D.=C2=A0 This lets the client encode a registration request reference in =
the client ID, so no
 static or dynamic registration even occurs.=C2=A0 See 
https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.=
9.1.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=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: Dick Hardt &=
lt;dick.hardt@gmail.com>


Sent: Friday, July 10, 2020 1:17 PM

To: txauth@ietf..org; Justin Richer <jricher@mit.edu>; Mike =
Jones <Michael.Jones@microsoft.com>

Subject: Key handle vs client id & handle




=C2=A0




+ Mike as he had interest=
 in this topic




=C2=A0




My understanding is that =
an existing OAuth 2 client would use their current client id as their key h=
andle, and a dynamic client (one that was not pre-registered) would be give=
n a key handle by the AS.






=C2=A0






There are potentially som=
e significant differences between a registered client, and a dynamic client=
 to an AS.






=C2=A0






The AS is likely to know =
the identity of a registered client, and have different policies between th=
e two types of clients. For example, a registered client may have access to=
 a 'write" scope, while a dynamic
 client does not.






=C2=A0






The AS may have 100s or 1=
000s of registered clients, but a dynamic client may have 10Ms or 100Ms of =
instances, which may dictate separate=C2=A0storage services. Additionally, =
internal to the AS, which systems can write
 to the registered=C2=A0client store is going to be different than the dyna=
mic client=C2=A0store.






=C2=A0






In XYZ, subsequent calls =
to the AS, both registered clients and dynamic clients pass a key handle, s=
o there is no easy way to differentiate between the two.






=C2=A0






While the AS could embed =
semantics in the key handle identifier to indicate which identifiers are pr=
e-registered vs dynamic, there are many cases where the AS does need to kno=
w the difference, so making=C2=A0the difference
 a feature of GNAP seems like a better path.








=C2=A0






=C2=A0











This email and any attachments are for the sole use of the intended recipie=
nts and may be privileged, confidential or otherwise exempt from disclosure=
 under law. Any distribution, printing or other use by anyone other than th=
e intended recipient is prohibited.
 If you are not an intended recipient, please contact the sender immediatel=
y, and permanently delete this email and its attachments.







3D""=
=E1=90=A7

-- 

Txauth mailing list

Txa=
uth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth<=
/a>




--00000000000083f92e05aa6f1fbc--


From nobody Wed Jul 15 07: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 D00A43A0C13 for ; Wed, 15 Jul 2020 07:35:44 -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 0LmheoB3HxUU for ; Wed, 15 Jul 2020 07:35:42 -0700 (PDT)
Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670125.outbound.protection.outlook.com [40.107.67.125]) (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 A1BD33A0DCA for ; Wed, 15 Jul 2020 07:35:16 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=awCtqbAesEEtQ17blNi9mYAR0dRUvN2YfaPkqHrHGzDSTtmTfreCvs7ChCqz8Io4IBlwKf6padpiGB2/j+gMnBRf1EblZxPrEcDBUgAohG5XgPmtFAaIVStpjbbz9aemILmeIsXTwuPeuCkUwPa//yD92hbo8MnUKeMHM0OoaDMJnSrIeNt9TVPjrmUjul7aIvmZDRtKJDVrIev9/gz6jouk6gDltlam9PxDLXgENcAAwppZ+E+qCd+PedAsbtMcq/1ZK8BLpG4WWbGtz772XDa56ouSCG0K1dGCU6PIXDU4FysVDrpgHUQUGnyyS/O7hZG/MH/K5/bYEzVVCGyExQ==
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=hzxGUxqKWe9KOmXTaQv5J6jzYhPeLxmmmDsjRCLdY8s=; b=NtgleHTNzDu1x6Xe+/BmC/Y+0EPuHF9wKGs3oMKDolq4py6GeHL1QORYG1QBabP/dQgc5suT/TNSEOsqbILTgH+Ky0q1OeMD5twwy/2/q1inzKbShN8k85EHT7kivApsU34595XZi8Px0ryLe+hj23c92AsDORVABd/JVEqY40fXmpwpZRQdh8OOViWm+/AkCRCu0IZCTn9BHX0jtddC2xDw4ImquJHJgyD9+AVsTzYqxz5t8JBMYewvmdDrM7+JK9maQgCHzHUZBuFYoAxgMB7W3eZMMFhHETCi66PyLe0AmMVdVGjJEhyRp3HJJ2jkd6LIxqg6NqnhinBWW+E+Hw==
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=hzxGUxqKWe9KOmXTaQv5J6jzYhPeLxmmmDsjRCLdY8s=; b=nouAGZQvBonFloGfUdb3BGEHZqlkqWTlm2G+l7YF0LeZ4uYv2+cKuvtdJdVFwJa82WxYgx9g8CghLaKJMnoTOqkyHHmFIdWbSrH9aRIQw8pHFsQCDicebQS6X04GzYV85UJmLY/BESAtkYTlRaOUFjrGDIQclbR9a+f7UN3iORg=
Received: from YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:20::25) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Wed, 15 Jul 2020 14:35:14 +0000
Received: from YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM ([fe80::c57f:32dc:ba85:19a3]) by YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM ([fe80::c57f:32dc:ba85:19a3%5]) with mapi id 15.20.3174.025; Wed, 15 Jul 2020 14:35:14 +0000
From: Mike Varley 
To: Tom Jones , Dick Hardt 
CC: Mike Jones , Justin Richer , "txauth@ietf.org" 
Thread-Topic: [Txauth] Client Registration (Was: Key handle vs client id & handle
Thread-Index: AQHWWhDWyJ/zdl74zk6R5leJfCQDpqkHt/AAgAC7LQA=
Date: Wed, 15 Jul 2020 14:35:14 +0000
Message-ID: 
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/16.39.20071300
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=securekey.com;
x-originating-ip: [50.101.239.135]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bf09c711-55cf-475b-a612-08d828cc49b4
x-ms-traffictypediagnostic: YTBPR01MB3966:
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: CVgc9xO3S6AAbAbeIb46L/jJ11rErCpoPBUI9OsFUQuXwT1KqFhb66gugeb8BAUIFSK6q7ZHnidQjVgLan9D6TRK4UPI6tCutkAkTuOVssDcayDgth7P6S8SZd9dhwZlwOqWJ618eQbHvQnYLg3GyvMPgHmhUKbASlSy+DxOCd2vgrXziGIepebHmnrZ3bckJPzC+DqM9bXWMakWQJc5NI0Hv3WYdQLC4Fu4ESbReiGncpows0sq/Xq6jtjL/NSDH/T2lfJyiSPlsPI6OW0M5u5DQr3xi5e3arx6uz9RsBTHNdA6GTLulaub1qgCHVz84maRItyNl15l0rNCXiJ0bcv3qeQbdiQ88dNGjuV/w47T8ZnbfuCoxPLyXsv+V3Wgin3tQFdy9fKp2xo3VsqO2g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(39850400004)(396003)(366004)(376002)(136003)(346002)(33656002)(45080400002)(2616005)(966005)(316002)(6506007)(9326002)(8676002)(5660300002)(53546011)(8936002)(66446008)(6512007)(66556008)(66946007)(83380400001)(36756003)(64756008)(66476007)(6486002)(76116006)(4326008)(71200400001)(86362001)(21615005)(26005)(44832011)(478600001)(54906003)(2906002)(166002)(110136005)(186003); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: wIClrvrIubU82oNoWnnD79+PkIQQWBwWzaN6kYosA7xOl3eEnSLqJm7ojPSBEmOaUl+PtapCiWToYvW6YelYtd6w24tBqGPBNrCH6EjZY1Z7se4Q62GuLFa/eFiPI7Q8HS0KfHnrvRuY9UVJLfzFkvLIYKJt81diigxDsK/+0rUxcMKaovRCwi7pSvhvcJIotrBxuSUII/GOeiDBKWK0rjKnWN1IZXTRLoLXBsVdnF3TO6t0vl1utGmOhRUN/TTXGmYI4AxyJBmH2uGv1VMkYWkrwLa1wuIIy6pPe51tBroYQTzA0M0B5Vw+/tLehMNfcrstSsIjtea0YXzCMUregoQex/QgvyyZzehiLvFWTi5dJAT1Fuw5TKO4vI7tic1nWJqUkHQ1PWEFCwtGpV4B9BhbgIXxPmtPpbehn+kw0xzNKC2N5BfOPETmkZbBDrhhBwsLT69l8jCLhiXNzuImfQrEREijPhVwcNO8c5AsOeqiCM1rPiILEqtBE/yKPX55
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_A519897D8BDA420BA8DF0EB77E23E248securekeycom_"
MIME-Version: 1.0
X-OriginatorOrg: securekey.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: bf09c711-55cf-475b-a612-08d828cc49b4
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2020 14:35:14.6752 (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: JZhQlf/Zk1c0Z4IyZrGiedY9TubFQd/J2sLb0RridT3pXawi4ybsSnY8z4ohPbKHbAW9nhMkeTZd43OlrSic2uVEAr07t5RdOdyM0xJHBN4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3966
Archived-At: 
Subject: Re: [Txauth] Client Registration (Was: Key handle vs client id & handle
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, 15 Jul 2020 14:35:45 -0000

--_000_A519897D8BDA420BA8DF0EB77E23E248securekeycom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgVG9tLA0KSSB0aGluayB0aGUgZ3JvdXAgaXMgc3RpbGwgYWxpZ25pbmcgb24gdGhlIGNvbmNl
cHQsIGFuZCB0aGUgZW50aXR5IHN0YXRlbWVudCBpcyBhIG1lY2hhbmlzbSAoYW5kIGxpa2VseSBh
biBhcHByb3ByaWF0ZSBvbmUpIGJ1dCB3ZSBqdXN0IGhhdmVu4oCZdCBnb3R0ZW4gdGhlcmUgeWV0
Lg0KDQpJIHRoaW5rIHRoZSBuZXh0IHF1ZXN0aW9uIChvbmNlIHdlIGFncmVlIHRoZXJlIGlzIGEg
cmVxdWlyZW1lbnQgZm9yIHRoaXMgdHlwZSBvZiBhc3NlcnRpb24gZm9yIGNsaWVudHMpIGlzIHdo
YXQgdHlwZSBvZiBhc3NlcnRpb25zIG1heSBuZWVkIHRvIGJlIHN1cHBvcnRlZOKApg0KDQpNVg0K
DQpGcm9tOiBUb20gSm9uZXMgPHRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb20+DQpEYXRlOiBU
dWVzZGF5LCBKdWx5IDE0LCAyMDIwIGF0IDc6MjUgUE0NClRvOiBEaWNrIEhhcmR0IDxkaWNrLmhh
cmR0QGdtYWlsLmNvbT4NCkNjOiBNaWtlIFZhcmxleSA8bWlrZS52YXJsZXlAc2VjdXJla2V5LmNv
bT4sIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu
b3JnPiwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiwgInR4YXV0aEBpZXRmLm9yZyIg
PHR4YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBDbGllbnQgUmVnaXN0cmF0
aW9uIChXYXM6IEtleSBoYW5kbGUgdnMgY2xpZW50IGlkICYgaGFuZGxlDQoNCkkgc3VnZ2VzdGVk
IGVhcmxpZXIgdG8gdXNlIHRoZSBlbnRpdHkgc3RhdGVtZW50IG9mIHRoZSBPcGVuaWQgZmVkZXJh
dGlvbiBzcGVjLCBidXQgaGVhcmQgbm8gZmVlZGJhY2suIFdoeSBub3Q/DQp0aHggLi5Ub20gKG1v
YmlsZSkNCg0KT24gVHVlLCBKdWwgMTQsIDIwMjAsIDE6MDAgUE0gRGljayBIYXJkdCA8ZGljay5o
YXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQooY2hh
bmdpbmcgc3ViamVjdCB0byByZWZsZWN0IHRvcGljKQ0KDQpJbiBteSBvcGluaW9uLCBjbGllbnQg
cmVnaXN0cmF0aW9uIGlzIGluIHNjb3BlLg0KDQpJbiBib3RoIFhZWiBhbmQgWEF1dGgsIHRoZSBj
bGllbnQgY2FuIHByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCBpdHNlbGYsIGFuZCBnZXQg
YmFjayBhbiBJRCBpdCBjYW4gdXNlIGluIHN1YnNlcXVlbnQgY2FsbHMuIE5vIG9uZSBoYXMgc2Fp
ZCB0aGF0IHNob3VsZCBOT1QgYmUgaW4gc2NvcGUgc28gZmFyLg0KDQpNeXNlbGYsIEkgZG8gc3Vw
cG9ydCBhZGRpbmcgb3RoZXIgbWVjaGFuaXNtcyBmb3IgYSBDbGllbnQgdG8gc2hhcmUgaW5mb3Jt
YXRpb24gYWJvdXQgaXRzZWxmIHdpdGggYW4gQVMgc3VjaCBhcyBzb2Z0d2FyZSBzdGF0ZW1lbnRz
LCBvciBhIFVSSSB0aGF0IGJpbmRzIGEgVVJJIHRvIGluZm9ybWF0aW9uIHJldHJpZXZlZCBmcm9t
IHRoYXQgVVJJLCBhbmQgdG8gdGhlIENsaWVudC4NCg0KSSBhZ3JlZSB0aGF0IHdlIGRvbid0IHdh
bnQgdG8gZGVmaW5lIHNvZnR3YXJlIHN0YXRlbWVudHMgcGVyIHNlLCBidXQgd2Ugc2hvdWxkIHJl
ZmVyIHRvIHNvbWUgc3RhbmRhcmRzIHNvIHRoYXQgaW50ZXJvcCBiZXR3ZWVuIGNsaWVudHMgYW5k
IEFTcy4NCg0KL0RpY2sNCg0KT24gVHVlLCBKdWwgMTQsIDIwMjAgYXQgMTA6NTQgQU0gTWlrZSBW
YXJsZXkgPG1pa2UudmFybGV5QHNlY3VyZWtleS5jb208bWFpbHRvOm1pa2UudmFybGV5QHNlY3Vy
ZWtleS5jb20+PiB3cm90ZToNCklzIGNsaWVudCByZWdpc3RyYXRpb24gaW4gc2NvcGUgZm9yIHRo
ZSBwcm90b2NvbD8NCg0KQSBnZW5lcmljIHdheSBvZiBoYW5kbGluZyBjbGllbnRzICh2aWEgSUQg
b3IgSGFuZGxlIG9yIEtleSBvciB3aGF0ZXZlcikgaXMgdG8gaGF2ZSBwcm9jZXNzaW5nIHJ1bGUg
b24gdGhlIEFTIHN1Y2ggYXMg4oCcaWYgdGhlIEFTIHJlY29nbml6ZXMgdGhlIGNsaWVudCBJRCAo
YW5kIGF1dGhlbnRpY2F0aW9uIG9mIHRoYXQgY2xpZW50IElEKSB0aGVuIGl0IG1heSBwcm9jZXNz
IHRoZSByZXF1ZXN0IG9uIGJlaGFsZiBvZiB0aGF0IGNsaWVudC4gSWYgdGhlIEFTIGRvZXMgbm90
IHJlY29nbml6ZSB0aGUgY2xpZW50IElELCBpdCBtdXN0IHRyZWF0IHRoaXMgYXMgYSBuZXcgY2xp
ZW50IHJlZ2lzdHJhdGlvbiBhbmQgZXZhbHVhdGUgYW55IGF1dGhvcml6YXRpb24gZXZpZGVuY2Ug
dGhlIGNsaWVudCBwcm92aWRlcyBiZWZvcmUgZW5hYmxpbmcgdGhlIGNsaWVudCBhbmQgbWFwcGlu
ZyBwb2xpY2llcyB0byB0aGF0IGNsaWVudOKAnSAodGhpcyBtZWFucyBkeW5hbWljIG9yIGF1dG9t
YXRpYyBjbGllbnRzIG5lZWQgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGFzc2VydGlvbnMgLyBzb2Z0
d2FyZSBzdGF0ZW1lbnRzIHdoYXRldmVyIHRvIHJlZ2lzdGVyIHRoZWlyIElELg0KDQpTb21ldGhp
bmcgbGlrZSB0aGlzIGFsbG93cyBmb3IgdmVyeSBmbGV4aWJsZSBzeXN0ZW1zOg0KU3lzdGVtIEEg
Y2FuIGJlIHVua25vd24gdG8gdGhlIEFTIGJ1dCBjYW4gZHluYW1pY2FsbHkgcmVnaXN0ZXJlZCBl
YWNoIHRpbWUgd2l0aCBhbiBhcHByb3ByaWF0ZSBzb2Z0d2FyZSBzdGF0ZW1lbnQNClN5c3RlbSBC
IGNhbiBoYXZlIGEgZmFpcmx5IHN0YWJsZSBjbGllbnQgSUQgYXQgdGhlIEFTLCBidXQgcm90YXRl
IHRoYXQgSUQgZXZlcnkgbW9udGggdGhyb3VnaCBhdXRvbWF0aWMgcmVnaXN0cmF0aW9uICh3aXRo
IGFuIGFzc2VydGlvbiBpdCBnb3QgZnJvbSB0aGUgQVMgZHVyaW5nIGEgcHJlLXJlZ2lzdHJhdGlv
biBmb3IgZXhhbXBsZSkNClN5c3RlbSBDIGNhbiBwcmUtcmVnaXN0ZXIgd2l0aCB0aGUgQVMgZm9y
IGEgY2xpZW50IElEIGJlY2F1c2UgaXQgZG9lc27igJl0IGRlYWwgd2l0aCBzb2Z0d2FyZSBzdGF0
ZW1lbnRzIGV0Y+KApg0K4oCmDQpBbmQgZXZlbiDigJhTdGF0ZWxlc3NBU+KAmSBjYW4gb3BlcmF0
ZSBieSBuZXZlciBzdG9yaW5nIGNsaWVudCBJRHMgYmVjYXVzZSBpdCB3aWxsIGFsd2F5cyBqdXN0
IHJlbHkgb24gdGhlIHNvZnR3YXJlIHN0YXRlbWVudHMuDQoNCkkgdGhpbmsgYSBjbGllbnQgcmVn
aXN0cmF0aW9uIHByb3RvY29sIHRoYXQgYWxsb3dzIHRoZXNlIHNjZW5hcmlvcyB3b3VsZCBiZSB2
ZXJ5IHVzZWZ1bCBpbiBHTkFQLCBidXQgaG9wZWZ1bGx5IGF2b2lkaW5nIGhhdmluZyB0byBkZWZp
bmUgd2hhdCDigJhldmlkZW5jZeKAmSB0aGUgQVMgbmVlZHMgdG8gYWNjZXB0IGZvciBlYWNoIHNj
ZW5hcmlvLg0KDQpUaGFua3MsDQoNCk1WDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNA
aWV0Zi5vcmc8bWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIE1p
a2UgSm9uZXMgPE1pY2hhZWwuSm9uZXM9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1h
aWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogVHVlc2RheSwgSnVs
eSAxNCwgMjAyMCBhdCAxMjoxOCBQTQ0KVG86IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwu
Y29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+LCAidHhhdXRoQGlldGYub3JnPG1haWx0
bzp0eGF1dGhAaWV0Zi5vcmc+IiA8dHhhdXRoQGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5v
cmc+PiwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5l
ZHU+Pg0KU3ViamVjdDogUmU6IFtUeGF1dGhdIEtleSBoYW5kbGUgdnMgY2xpZW50IGlkICYgaGFu
ZGxlDQoNCkkgYWdyZWUgdGhhdCB0aGVyZSBhcmUgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZXMgYmV0
d2VlbiBzdGF0aWNhbGx5IGFuZCBkeW5hbWljYWxseSByZWdpc3RlcmVkIGNsaWVudHMgYW5kIHRo
YXTigJlzIGFwcHJvcHJpYXRlIHRvIGJlIGFibGUgdG8gc3ludGFjdGljYWxseSBkaWZmZXJlbnRp
YXRlIGJldHdlZW4gdGhlbSBhdCBydW50aW1lLiAgRm9yIG9uZSB0aGluZywgdGhlIHJlc291cmNl
IHJlcXVpcmVtZW50cyBhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgY2FuIGJlIHZlcnkgZGlm
ZmVyZW50Lg0KDQpXZSBzaG91bGQgYWxzbyBiZSB0aGlua2luZyBhYm91dCBob3cgdG8gaW5jbHVk
ZSB3aGF0IHRoZSBPcGVuSUQgQ29ubmVjdCBGZWRlcmF0aW9uIHNwZWMgaHR0cHM6Ly9vcGVuaWQu
bmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWZlZGVyYXRpb24tMV8wLmh0bWwgY2FsbHMg4oCcQXV0
b21hdGljIFJlZ2lzdHJhdGlvbuKAnS4gIFRoaXMgbGV0cyB0aGUgY2xpZW50IGVuY29kZSBhIHJl
Z2lzdHJhdGlvbiByZXF1ZXN0IHJlZmVyZW5jZSBpbiB0aGUgY2xpZW50IElELCBzbyBubyBzdGF0
aWMgb3IgZHluYW1pYyByZWdpc3RyYXRpb24gZXZlbiBvY2N1cnMuICBTZWUgaHR0cHM6Ly9vcGVu
aWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWZlZGVyYXRpb24tMV8wLTEyLmh0bWwjcmZjLnNl
Y3Rpb24uOS4xLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWls
LmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pg0KU2VudDogRnJpZGF5LCBKdWx5IDEw
LCAyMDIwIDE6MTcgUE0NClRvOiB0eGF1dGhAaWV0Zi4ub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5v
cmc+OyBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVk
dT4+OyBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hh
ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpTdWJqZWN0OiBLZXkgaGFuZGxlIHZzIGNsaWVudCBp
ZCAmIGhhbmRsZQ0KDQorIE1pa2UgYXMgaGUgaGFkIGludGVyZXN0IGluIHRoaXMgdG9waWMNCg0K
TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGFuIGV4aXN0aW5nIE9BdXRoIDIgY2xpZW50IHdvdWxk
IHVzZSB0aGVpciBjdXJyZW50IGNsaWVudCBpZCBhcyB0aGVpciBrZXkgaGFuZGxlLCBhbmQgYSBk
eW5hbWljIGNsaWVudCAob25lIHRoYXQgd2FzIG5vdCBwcmUtcmVnaXN0ZXJlZCkgd291bGQgYmUg
Z2l2ZW4gYSBrZXkgaGFuZGxlIGJ5IHRoZSBBUy4NCg0KVGhlcmUgYXJlIHBvdGVudGlhbGx5IHNv
bWUgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZXMgYmV0d2VlbiBhIHJlZ2lzdGVyZWQgY2xpZW50LCBh
bmQgYSBkeW5hbWljIGNsaWVudCB0byBhbiBBUy4NCg0KVGhlIEFTIGlzIGxpa2VseSB0byBrbm93
IHRoZSBpZGVudGl0eSBvZiBhIHJlZ2lzdGVyZWQgY2xpZW50LCBhbmQgaGF2ZSBkaWZmZXJlbnQg
cG9saWNpZXMgYmV0d2VlbiB0aGUgdHdvIHR5cGVzIG9mIGNsaWVudHMuIEZvciBleGFtcGxlLCBh
IHJlZ2lzdGVyZWQgY2xpZW50IG1heSBoYXZlIGFjY2VzcyB0byBhICd3cml0ZSIgc2NvcGUsIHdo
aWxlIGEgZHluYW1pYyBjbGllbnQgZG9lcyBub3QuDQoNClRoZSBBUyBtYXkgaGF2ZSAxMDBzIG9y
IDEwMDBzIG9mIHJlZ2lzdGVyZWQgY2xpZW50cywgYnV0IGEgZHluYW1pYyBjbGllbnQgbWF5IGhh
dmUgMTBNcyBvciAxMDBNcyBvZiBpbnN0YW5jZXMsIHdoaWNoIG1heSBkaWN0YXRlIHNlcGFyYXRl
IHN0b3JhZ2Ugc2VydmljZXMuIEFkZGl0aW9uYWxseSwgaW50ZXJuYWwgdG8gdGhlIEFTLCB3aGlj
aCBzeXN0ZW1zIGNhbiB3cml0ZSB0byB0aGUgcmVnaXN0ZXJlZCBjbGllbnQgc3RvcmUgaXMgZ29p
bmcgdG8gYmUgZGlmZmVyZW50IHRoYW4gdGhlIGR5bmFtaWMgY2xpZW50IHN0b3JlLg0KDQpJbiBY
WVosIHN1YnNlcXVlbnQgY2FsbHMgdG8gdGhlIEFTLCBib3RoIHJlZ2lzdGVyZWQgY2xpZW50cyBh
bmQgZHluYW1pYyBjbGllbnRzIHBhc3MgYSBrZXkgaGFuZGxlLCBzbyB0aGVyZSBpcyBubyBlYXN5
IHdheSB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gdGhlIHR3by4NCg0KV2hpbGUgdGhlIEFTIGNv
dWxkIGVtYmVkIHNlbWFudGljcyBpbiB0aGUga2V5IGhhbmRsZSBpZGVudGlmaWVyIHRvIGluZGlj
YXRlIHdoaWNoIGlkZW50aWZpZXJzIGFyZSBwcmUtcmVnaXN0ZXJlZCB2cyBkeW5hbWljLCB0aGVy
ZSBhcmUgbWFueSBjYXNlcyB3aGVyZSB0aGUgQVMgZG9lcyBuZWVkIHRvIGtub3cgdGhlIGRpZmZl
cmVuY2UsIHNvIG1ha2luZyB0aGUgZGlmZmVyZW5jZSBhIGZlYXR1cmUgb2YgR05BUCBzZWVtcyBs
aWtlIGEgYmV0dGVyIHBhdGguDQoNCg0KDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg
YXJlIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudHMgYW5kIG1heSBi
ZSBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwgb3Igb3RoZXJ3aXNlIGV4ZW1wdCBmcm9tIGRpc2Ns
b3N1cmUgdW5kZXIgbGF3LiBBbnkgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBvdGhlciB1c2Ug
YnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVk
LiBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRo
ZSBzZW5kZXIgaW1tZWRpYXRlbHksIGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhpcyBlbWFpbCBh
bmQgaXRzIGF0dGFjaG1lbnRzLg0KW0ltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLl3hkKcNCi0tDQpU
eGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRmLm9y
Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQo=

--_000_A519897D8BDA420BA8DF0EB77E23E248securekeycom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
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
bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp
IFRvbSwgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSBn
cm91cCBpcyBzdGlsbCBhbGlnbmluZyBvbiB0aGUgY29uY2VwdCwgYW5kIHRoZSBlbnRpdHkgc3Rh
dGVtZW50IGlzIGEgbWVjaGFuaXNtIChhbmQgbGlrZWx5IGFuIGFwcHJvcHJpYXRlIG9uZSkgYnV0
IHdlIGp1c3QgaGF2ZW7igJl0IGdvdHRlbiB0aGVyZSB5ZXQuPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgdGhpbmsgdGhlIG5leHQgcXVlc3Rpb24gKG9uY2Ugd2UgYWdyZWUgdGhlcmUgaXMgYSBy
ZXF1aXJlbWVudCBmb3IgdGhpcyB0eXBlIG9mIGFzc2VydGlvbiBmb3IgY2xpZW50cykgaXMgd2hh
dCB0eXBlIG9mIGFzc2VydGlvbnMgbWF5IG5lZWQgdG8gYmUgc3VwcG9ydGVk4oCmDQo8bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+TVY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv
cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Ub20gSm9uZXMgJmx0O3Rob21hc2Ns
aW5nYW5qb25lc0BnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEp1bHkg
MTQsIDIwMjAgYXQgNzoyNSBQTTxicj4NCjxiPlRvOiA8L2I+RGljayBIYXJkdCAmbHQ7ZGljay5o
YXJkdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5NaWtlIFZhcmxleSAmbHQ7bWlrZS52
YXJsZXlAc2VjdXJla2V5LmNvbSZndDssIE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXM9NDBt
aWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnJmd0OywgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hl
ckBtaXQuZWR1Jmd0OywgJnF1b3Q7dHhhdXRoQGlldGYub3JnJnF1b3Q7ICZsdDt0eGF1dGhAaWV0
Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVHhhdXRoXSBDbGllbnQgUmVnaXN0
cmF0aW9uIChXYXM6IEtleSBoYW5kbGUgdnMgY2xpZW50IGlkICZhbXA7IGhhbmRsZTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFy
Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNi4wcHQiPg0K
SSBzdWdnZXN0ZWQgZWFybGllciB0byB1c2UgdGhlIGVudGl0eSBzdGF0ZW1lbnQgb2YgdGhlIE9w
ZW5pZCBmZWRlcmF0aW9uIHNwZWMsIGJ1dCBoZWFyZCBubyBmZWVkYmFjay4gV2h5IG5vdD88bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl
ZnQ6MzYuMHB0Ij50aHggLi5Ub20gKG1vYmlsZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gVHVlLCBKdWwgMTQsIDIwMjAsIDE6MDAgUE0gRGlj
ayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIj5kaWNrLmhh
cmR0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw
dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo
dDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6MzYuMHB0Ij4oY2hhbmdpbmcgc3ViamVjdCB0byByZWZsZWN0IHRvcGljKTxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JbiBteSBvcGluaW9u
LCBjbGllbnQgcmVnaXN0cmF0aW9uIGlzIGluIHNjb3BlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JbiBib3RoIFhZWiBhbmQgWEF1dGgsIHRoZSBj
bGllbnQgY2FuIHByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCBpdHNlbGYsIGFuZCBnZXQg
YmFjayBhbiBJRCBpdCBjYW4gdXNlIGluIHN1YnNlcXVlbnQgY2FsbHMuIE5vIG9uZSBoYXMgc2Fp
ZCB0aGF0IHNob3VsZCBOT1QgYmUgaW4gc2NvcGUgc28gZmFyLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw
dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5NeXNlbGYsIEkgZG8gc3VwcG9ydCBhZGRp
bmcgb3RoZXIgbWVjaGFuaXNtcyBmb3IgYSBDbGllbnQgdG8gc2hhcmUgaW5mb3JtYXRpb24gYWJv
dXQgaXRzZWxmIHdpdGggYW4gQVMgc3VjaCBhcyBzb2Z0d2FyZSBzdGF0ZW1lbnRzLCBvciBhIFVS
SSB0aGF0IGJpbmRzIGEgVVJJIHRvIGluZm9ybWF0aW9uIHJldHJpZXZlZCBmcm9tIHRoYXQgVVJJ
LCBhbmQgdG8gdGhlDQogQ2xpZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6MzYuMHB0Ij5JIGFncmVlIHRoYXQgd2UgZG9uJ3Qgd2FudCB0byBkZWZpbmUgc29m
dHdhcmUgc3RhdGVtZW50cyBwZXIgc2UsIGJ1dCB3ZSBzaG91bGQgcmVmZXIgdG8gc29tZSBzdGFu
ZGFyZHMgc28gdGhhdCBpbnRlcm9wIGJldHdlZW4gY2xpZW50cyBhbmQgQVNzLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4vRGljazxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu
MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gVHVlLCBKdWwgMTQsIDIwMjAgYXQg
MTA6NTQgQU0gTWlrZSBWYXJsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzptaWtlLnZhcmxleUBzZWN1
cmVrZXkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlrZS52YXJsZXlAc2VjdXJla2V5LmNvbTwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g
MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCklzIGNsaWVu
dCByZWdpc3RyYXRpb24gaW4gc2NvcGUgZm9yIHRoZSBwcm90b2NvbD88bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCkEg
Z2VuZXJpYyB3YXkgb2YgaGFuZGxpbmcgY2xpZW50cyAodmlhIElEIG9yIEhhbmRsZSBvciBLZXkg
b3Igd2hhdGV2ZXIpIGlzIHRvIGhhdmUgcHJvY2Vzc2luZyBydWxlIG9uIHRoZSBBUyBzdWNoIGFz
IOKAnGlmIHRoZSBBUyByZWNvZ25pemVzIHRoZSBjbGllbnQgSUQgKGFuZCBhdXRoZW50aWNhdGlv
biBvZiB0aGF0IGNsaWVudCBJRCkgdGhlbiBpdCBtYXkgcHJvY2VzcyB0aGUgcmVxdWVzdCBvbiBi
ZWhhbGYgb2YgdGhhdCBjbGllbnQuIElmIHRoZQ0KIEFTIGRvZXMgbm90IHJlY29nbml6ZSB0aGUg
Y2xpZW50IElELCBpdCBtdXN0IHRyZWF0IHRoaXMgYXMgYSBuZXcgY2xpZW50IHJlZ2lzdHJhdGlv
biBhbmQgZXZhbHVhdGUgYW55IGF1dGhvcml6YXRpb24gZXZpZGVuY2UgdGhlIGNsaWVudCBwcm92
aWRlcyBiZWZvcmUgZW5hYmxpbmcgdGhlIGNsaWVudCBhbmQgbWFwcGluZyBwb2xpY2llcyB0byB0
aGF0IGNsaWVudOKAnSAodGhpcyBtZWFucyBkeW5hbWljIG9yIGF1dG9tYXRpYyBjbGllbnRzIG5l
ZWQgdG8NCiBwcm92aWRlIGFkZGl0aW9uYWwgYXNzZXJ0aW9ucyAvIHNvZnR3YXJlIHN0YXRlbWVu
dHMgd2hhdGV2ZXIgdG8gcmVnaXN0ZXIgdGhlaXIgSUQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NClNvbWV0aGlu
ZyBsaWtlIHRoaXMgYWxsb3dzIGZvciB2ZXJ5IGZsZXhpYmxlIHN5c3RlbXM6PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NClN5c3RlbSBB
IGNhbiBiZSB1bmtub3duIHRvIHRoZSBBUyBidXQgY2FuIGR5bmFtaWNhbGx5IHJlZ2lzdGVyZWQg
ZWFjaCB0aW1lIHdpdGggYW4gYXBwcm9wcmlhdGUgc29mdHdhcmUgc3RhdGVtZW50PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NClN5c3Rl
bSBCIGNhbiBoYXZlIGEgZmFpcmx5IHN0YWJsZSBjbGllbnQgSUQgYXQgdGhlIEFTLCBidXQgcm90
YXRlIHRoYXQgSUQgZXZlcnkgbW9udGggdGhyb3VnaCBhdXRvbWF0aWMgcmVnaXN0cmF0aW9uICh3
aXRoIGFuIGFzc2VydGlvbiBpdCBnb3QgZnJvbSB0aGUgQVMgZHVyaW5nIGEgcHJlLXJlZ2lzdHJh
dGlvbiBmb3IgZXhhbXBsZSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt
YXJnaW4tbGVmdDozNi4wcHQiPg0KU3lzdGVtIEMgY2FuIHByZS1yZWdpc3RlciB3aXRoIHRoZSBB
UyBmb3IgYSBjbGllbnQgSUQgYmVjYXVzZSBpdCBkb2VzbuKAmXQgZGVhbCB3aXRoIHNvZnR3YXJl
IHN0YXRlbWVudHMgZXRj4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCuKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpBbmQgZXZlbiDigJhTdGF0ZWxlc3NBU+KAmSBj
YW4gb3BlcmF0ZSBieSBuZXZlciBzdG9yaW5nIGNsaWVudCBJRHMgYmVjYXVzZSBpdCB3aWxsIGFs
d2F5cyBqdXN0IHJlbHkgb24gdGhlIHNvZnR3YXJlIHN0YXRlbWVudHMuDQo8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4N
CkkgdGhpbmsgYSBjbGllbnQgcmVnaXN0cmF0aW9uIHByb3RvY29sIHRoYXQgYWxsb3dzIHRoZXNl
IHNjZW5hcmlvcyB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bCBpbiBHTkFQLCBidXQgaG9wZWZ1bGx5IGF2
b2lkaW5nIGhhdmluZyB0byBkZWZpbmUgd2hhdCDigJhldmlkZW5jZeKAmSB0aGUgQVMgbmVlZHMg
dG8gYWNjZXB0IGZvciBlYWNoIHNjZW5hcmlvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KVGhhbmtzLDxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4w
cHQiPg0KTVY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm
dDozNi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj
bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UeGF1dGggJmx0OzxhIGhy
ZWY9Im1haWx0bzp0eGF1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0
aC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIE1pa2UgSm9uZXMgJmx0O01p
Y2hhZWwuSm9uZXM9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7
PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEp1bHkgMTQsIDIwMjAgYXQgMTI6MTggUE08YnI+
DQo8Yj5UbzogPC9iPkRpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdt
YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDssICZx
dW90OzxhIGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1
dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dHhhdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoQGlldGYub3JnPC9hPiZndDssIEp1c3RpbiBSaWNoZXIN
CiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpy
aWNoZXJAbWl0LmVkdTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVHhhdXRoXSBL
ZXkgaGFuZGxlIHZzIGNsaWVudCBpZCAmYW1wOyBoYW5kbGU8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0
Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGFncmVl
IHRoYXQgdGhlcmUgYXJlIHNpZ25pZmljYW50IGRpZmZlcmVuY2VzIGJldHdlZW4gc3RhdGljYWxs
eSBhbmQgZHluYW1pY2FsbHkgcmVnaXN0ZXJlZCBjbGllbnRzIGFuZCB0aGF04oCZcyBhcHByb3By
aWF0ZSB0byBiZSBhYmxlIHRvIHN5bnRhY3RpY2FsbHkgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHRo
ZW0gYXQgcnVudGltZS4mbmJzcDsgRm9yIG9uZSB0aGluZywgdGhlIHJlc291cmNlIHJlcXVpcmVt
ZW50cw0KIGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBjYW4gYmUgdmVyeSBkaWZmZXJlbnQu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0
OjcyLjBwdCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8
c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+V2Ugc2hvdWxkIGFsc28gYmUgdGhpbmtpbmcgYWJv
dXQgaG93IHRvIGluY2x1ZGUgd2hhdCB0aGUgT3BlbklEIENvbm5lY3QgRmVkZXJhdGlvbiBzcGVj
DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0
LWZlZGVyYXRpb24tMV8wLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL29wZW5pZC5uZXQv
c3BlY3Mvb3BlbmlkLWNvbm5lY3QtZmVkZXJhdGlvbi0xXzAuaHRtbDwvYT4gY2FsbHMg4oCcQXV0
b21hdGljIFJlZ2lzdHJhdGlvbuKAnS4mbmJzcDsgVGhpcyBsZXRzIHRoZSBjbGllbnQgZW5jb2Rl
IGEgcmVnaXN0cmF0aW9uIHJlcXVlc3QgcmVmZXJlbmNlIGluIHRoZQ0KIGNsaWVudCBJRCwgc28g
bm8gc3RhdGljIG9yIGR5bmFtaWMgcmVnaXN0cmF0aW9uIGV2ZW4gb2NjdXJzLiZuYnNwOyBTZWUg
PGEgaHJlZj0iaHR0cHM6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LWZlZGVyYXRp
b24tMV8wLTEyLmh0bWwjcmZjLnNlY3Rpb24uOS4xIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov
L29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtZmVkZXJhdGlvbi0xXzAtMTIuaHRtbCNy
ZmMuc2VjdGlvbi45LjE8L2E+LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
O21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPGI+RnJvbTo8L2I+IERp
Y2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9i
PiBGcmlkYXksIEp1bHkgMTAsIDIwMjAgMToxNyBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0i
bWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0aEBpZXRmLi5vcmc8
L2E+OyBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0
YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs7IE1pa2UgSm9uZXMgJmx0Ozxh
IGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5r
Ij5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i
PiBLZXkgaGFuZGxlIHZzIGNsaWVudCBpZCAmYW1wOyBoYW5kbGU8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6
NzIuMHB0Ij4NCiYjNDM7IE1pa2UgYXMgaGUgaGFkIGludGVyZXN0IGluIHRoaXMgdG9waWM8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIu
MHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGFuIGV4aXN0
aW5nIE9BdXRoIDIgY2xpZW50IHdvdWxkIHVzZSB0aGVpciBjdXJyZW50IGNsaWVudCBpZCBhcyB0
aGVpciBrZXkgaGFuZGxlLCBhbmQgYSBkeW5hbWljIGNsaWVudCAob25lIHRoYXQgd2FzIG5vdCBw
cmUtcmVnaXN0ZXJlZCkgd291bGQgYmUgZ2l2ZW4gYSBrZXkgaGFuZGxlIGJ5IHRoZSBBUy48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t
bGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NClRoZXJlIGFyZSBwb3RlbnRp
YWxseSBzb21lIHNpZ25pZmljYW50IGRpZmZlcmVuY2VzIGJldHdlZW4gYSByZWdpc3RlcmVkIGNs
aWVudCwgYW5kIGEgZHluYW1pYyBjbGllbnQgdG8gYW4gQVMuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
O21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpUaGUgQVMgaXMgbGlrZWx5IHRvIGtub3cgdGhlIGlkZW50
aXR5IG9mIGEgcmVnaXN0ZXJlZCBjbGllbnQsIGFuZCBoYXZlIGRpZmZlcmVudCBwb2xpY2llcyBi
ZXR3ZWVuIHRoZSB0d28gdHlwZXMgb2YgY2xpZW50cy4gRm9yIGV4YW1wbGUsIGEgcmVnaXN0ZXJl
ZCBjbGllbnQgbWF5IGhhdmUgYWNjZXNzIHRvIGEgJ3dyaXRlJnF1b3Q7IHNjb3BlLCB3aGlsZSBh
IGR5bmFtaWMgY2xpZW50IGRvZXMgbm90LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm
dDo3Mi4wcHQiPg0KVGhlIEFTIG1heSBoYXZlIDEwMHMgb3IgMTAwMHMgb2YgcmVnaXN0ZXJlZCBj
bGllbnRzLCBidXQgYSBkeW5hbWljIGNsaWVudCBtYXkgaGF2ZSAxME1zIG9yIDEwME1zIG9mIGlu
c3RhbmNlcywgd2hpY2ggbWF5IGRpY3RhdGUgc2VwYXJhdGUmbmJzcDtzdG9yYWdlIHNlcnZpY2Vz
LiBBZGRpdGlvbmFsbHksIGludGVybmFsIHRvIHRoZSBBUywgd2hpY2ggc3lzdGVtcyBjYW4gd3Jp
dGUgdG8gdGhlIHJlZ2lzdGVyZWQmbmJzcDtjbGllbnQgc3RvcmUgaXMgZ29pbmcgdG8NCiBiZSBk
aWZmZXJlbnQgdGhhbiB0aGUgZHluYW1pYyBjbGllbnQmbmJzcDtzdG9yZS48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4w
cHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCkluIFhZWiwgc3Vic2VxdWVudCBjYWxscyB0
byB0aGUgQVMsIGJvdGggcmVnaXN0ZXJlZCBjbGllbnRzIGFuZCBkeW5hbWljIGNsaWVudHMgcGFz
cyBhIGtleSBoYW5kbGUsIHNvIHRoZXJlIGlzIG5vIGVhc3kgd2F5IHRvIGRpZmZlcmVudGlhdGUg
YmV0d2VlbiB0aGUgdHdvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQi
Pg0KV2hpbGUgdGhlIEFTIGNvdWxkIGVtYmVkIHNlbWFudGljcyBpbiB0aGUga2V5IGhhbmRsZSBp
ZGVudGlmaWVyIHRvIGluZGljYXRlIHdoaWNoIGlkZW50aWZpZXJzIGFyZSBwcmUtcmVnaXN0ZXJl
ZCB2cyBkeW5hbWljLCB0aGVyZSBhcmUgbWFueSBjYXNlcyB3aGVyZSB0aGUgQVMgZG9lcyBuZWVk
IHRvIGtub3cgdGhlIGRpZmZlcmVuY2UsIHNvIG1ha2luZyZuYnNwO3RoZSBkaWZmZXJlbmNlIGEg
ZmVhdHVyZSBvZiBHTkFQIHNlZW1zIGxpa2UgYSBiZXR0ZXIgcGF0aC48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0
OjcyLjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2
LjBwdDtsaW5lLWhlaWdodDoxMC4wcHQiIGlkPSJtXy0zMjA0NDU5NDA3MTE3NDQ2MTI1Z21haWwt
bV8tODgzNTkwNDAwODE1Njg5MjM3OWJvZHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVw
dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmRhcmtncmF5
Ij5UaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGZvciB0aGUgc29sZSB1c2Ugb2Yg
dGhlIGludGVuZGVkIHJlY2lwaWVudHMgYW5kIG1heSBiZSBwcml2aWxlZ2VkLCBjb25maWRlbnRp
YWwgb3Igb3RoZXJ3aXNlIGV4ZW1wdCBmcm9tIGRpc2Nsb3N1cmUgdW5kZXIgbGF3LiBBbnkgZGlz
dHJpYnV0aW9uLCBwcmludGluZw0KIG9yIG90aGVyIHVzZSBieSBhbnlvbmUgb3RoZXIgdGhhbiB0
aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IGFuIGlu
dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBpbW1lZGlhdGVseSwg
YW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGlzIGVtYWlsIGFuZCBpdHMgYXR0YWNobWVudHMuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRp
bmc6MGNtIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjMyIiBoZWlnaHQ9IjMyIiBzdHlsZT0id2lk
dGg6LjMzMzNpbjtoZWlnaHQ6LjMzMzNpbiIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6fldS
RDAwMDAuanBnIiBhbHQ9IkltYWdlIHJlbW92ZWQgYnkgc2VuZGVyLiI+PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6d2hpdGUiPuGQpzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LS0gPGJyPg0KVHhh
dXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj5UeGF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48bzpwPjwvbzpwPjwv
cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_A519897D8BDA420BA8DF0EB77E23E248securekeycom_--


From nobody Wed Jul 15 09:16: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 2BC693A0DF7 for ; Wed, 15 Jul 2020 09:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.171
X-Spam-Level: 
X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.459] 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 mmIzeZegnizy for ; Wed, 15 Jul 2020 09:16:24 -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 B73B53A0DD8 for ; Wed, 15 Jul 2020 09:16:16 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d53 with ME id 3UGD2300L4FMSmm03UGENv; Wed, 15 Jul 2020 18:16:14 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 15 Jul 2020 18:16:14 +0200
X-ME-IP: 86.238.65.197
To: "txauth@ietf.org" 
From: Denis 
Message-ID: <7572576d-b5b4-dea5-3383-fbbf6cc10450@free.fr>
Date: Wed, 15 Jul 2020 18:16:11 +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="------------59AA34BF6021139BCF28E8A1"
Content-Language: en-GB
Archived-At: 
Subject: [Txauth] Support of delegation
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, 15 Jul 2020 16:16:26 -0000

This is a multi-part message in MIME format.
--------------59AA34BF6021139BCF28E8A1
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

*Support of delegation*

The charter is mentioning a "delegation process", but at this time it is 
unclear how the delegation of an operation
originating from one Client towards two or more resource servers (RSs) 
will be supported.

Here after is a proposal to support a delegation scheme constructed 
along "Privacy by Design" principles.
A key element of this scheme is the use of a "User Consent element" 
supported by the Client.

In order to support this proposed delegation scheme, (only) a sequence 
of delegation tokens is needed.


*+--------++------------+
|User||Resource|
||\| Owner (RO) |
+--------+ \+------------+
|\|
|\|
|\|
|\|
|\|
+-----------+ (2a) +---------------++----------+
||----->| Authorization |||
|| (2b) |Server (AS)|||
|Client|<-----||||
|| (1a) +---------------+||
||------------------------>| Resource |
|User|(1b)| Server 1 |
|Consent|<------------------------|(RS1)|
|element|(3a)|| (4a)+----------+
||------------------------>||------>||
|||| (4b)||
|User|(3b)||<------||
|Consent|<------------------------||| Resource |
|element|+----------+| Server 2 |
||(5a)|(RS2)|
||------------------------------------------->||
||(5b)||
||<-------------------------------------------||
+-----------++----------+

**
*

*DELEGATION CASES*

Two cases are being considered, whether RS1 and RS2 do not belong to the 
same service (Case A)
or whether they both belong to the same service (Case B).

The sequence of flows up to (3a) are the same as those described in an 
earlier email called :
"A model with a User Consent Element (with a clean figure)"


*Case A*

Let us suppose that RS1 is unable to fulfil the operation by its own and 
that it needs to contact another RS, i.e. RS2.
RS1 contacts RS2 (4a) and indicates the operation that it is willing to 
perform on RS2 (that operation may not be
exactly the same as the original operation indicated by the client).

In return (4b), RS2 informs RS1 about which kind of attributes are 
needed by RS2 for performing the requested operation
and from which Attributes Servers they may be obtained. RS2 also 
provides a temporary API address and an handle so that
the Client can subsequently make a call directly to an API from RS2. RS1 
forwards that information to the Client.

This information is marked to indicate that it shall be handled by the 
"User Consent element" from the Client.
The presentation of that information is up to the man machine interface 
from the Client. The user can see the new requested
operation by RS1 on RS2 and which kind of attributes are requested by 
RS2, as well as from which ASs. If the user consents
to release these attributes to RS2, the Client then contacts one or more 
appropriate Authorization Servers.

Once the Client has obtained the appropriate access tokens targeted to 
RS2, it presents all of them to RS2 (5a) in a single request.
Then RS2 is able to provide a response to the Client (5b).

_Some observations_:

The user consent is captured locally by the "User Consent element" from 
the Client. There are two /user consent/ phases:
one for RS1 and another one for RS2.

RS1 will know which kind of attributes types are requested by RS2, but 
will be unable to know which attribute values from which AS(s)
will be presented by the Client to RS2.

RS1 does see the flow (5b) since this flow is going directly from RS2 to 
the Client.

The "User Consent element" from the Client may use a cache of previous 
user consents and may present earlier choices
to the user for speeding the user consent process.

The relationships between RS1 and RS2 can change at any time but no AS 
needs to be informed on these relationships.

There is no protocol between any AS and any RO, including using 
"out-of-bands" means.


*Case B*

Let us now suppose that RS1 is unable to fulfil the operation by its own 
but that it knows that the requested operation can be fulfilled
thanks to the help of another RS /from the same service/.

In such a case, when returning the "authorization table" (see an earlier 
email called "Support of FIDO and data minimization by RSs")
in the exchange (1b) for the given requested operation, RS1 will include 
both its name and the name of the service.

If the user consents to request the inclusion of the name of this 
service into the access token(s) delivered to RS1, then this allows
to save the exchanges (5a) and (5b): in such a case, all the exchanges 
with the Client will be carried out through RS1.

If the user do not consent to request the inclusion of the name of this 
service into the access token(s) delivered to RS1, then the previous
case A will apply.

Denis


--------------59AA34BF6021139BCF28E8A1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    

    

    

    

    
Support of delegation

        

        The charter is mentioning a "delegation process", but at this
        time it
        is unclear how the delegation of an
        operation 

        originating from one Client towards two or more resource servers
        (RSs) will be supported.

        

        Here after is a proposal to support a delegation scheme
        constructed
        along "Privacy by Design" principles.

        A key element of this scheme is the use of a "User
          Consent element"
          supported by the Client.

    
In order to support this proposed delegation
        scheme, (only) a sequence of delegation tokens is needed.

    

        

            +--------+                        +------------+

                | 
            User  |                        | 
            Resource  |

                |        |\                      
            | Owner (RO) |

                +--------+ \                      +------------+

                    |       \                          
            |

                    |        \                         
            |

                    |         \                        
            |

                    |          \                       
            |

                    |           \                      
            |

              +-----------+ (2a) +---------------+  +----------+

              |           |----->| Authorization |  |         
            |

              |           | (2b) |  Server
            (AS)  | 
            |          |

              | 
            Client   |<-----|               |  |         
            |

              |           | (1a) +---------------+  |          |

              |           |------------------------>|
            Resource |

              |  
            User    |            (1b)         | Server 1 |

              | 
            Consent 
            |<------------------------| 
            (RS1)   |

              | 
            element  |            (3a)         |         
            |
            (4a)  +----------+

              |           |------------------------>|          |------>|         
            |

              |           |                         |         
            | (4b)  |          |

              |  
            User    |            (3b)         |         
            |<------|         
            |

              | 
            Consent 
            |<------------------------|         
            |       | Resource |

              | 
            element  |                         +----------+       | Server 2 |

              |           |           
            (5a)                           
            |  (RS2)   |

              |           |------------------------------------------->|          |

              |           |         
              (5b)                            |          |

              |           |<-------------------------------------------|          |

              +-----------+                                           
            +----------+

          

        

        

    
DELEGATION
          CASES

        

        Two cases are being considered, whether RS1 and RS2 do not
        belong to the same
        service (Case A) 

        or whether they both belong to the same service (Case B).

    
The
        sequence of flows up to (3a) are the same as those described in
        an earlier email called :

        "A model with a User Consent Element (with a clean figure)"

      

    

        

        Case A

        

        Let us suppose that RS1 is unable to fulfil the operation by its
        own and that
        it needs to contact another RS, i.e. RS2. 

        RS1 contacts RS2 (4a) and indicates
        the operation that it is willing to perform on RS2 (that
        operation may
        not be 

        exactly the same as the original operation indicated by the
        client). 

        

        In return (4b), RS2 informs RS1 about which kind of attributes
        are needed by
        RS2 for performing the requested operation 

        and from which Attributes Servers
        they may be obtained. RS2 also provides a temporary API address
        and an handle so that

        the
        Client can subsequently make a call directly to an API from RS2.
        RS1 forwards that
        information to the Client.

        

        This information is marked to indicate that it shall be handled
        by the
        "User Consent element" from the Client. 

        The presentation of that
        information is up to the man machine interface from the Client.
        The user can
        see the new requested 

        operation by RS1 on RS2 and which kind of attributes are
        requested by RS2, as well as from which ASs. If the user
        consents 

        to release
        these attributes to RS2, the Client then contacts one or more
        appropriate
        Authorization Servers. 

        

        Once the Client has obtained the appropriate access tokens
        targeted to RS2, it
        presents all of them to RS2 (5a) in a single request. 

        Then RS2 is able to
        provide a response to the Client (5b).

    

    
    
Some
          observations:

        

        The user consent is captured locally by the "User Consent
        element"
        from the Client. There are two user consent phases: 

        one for RS1 and another one
        for RS2.

        

        RS1 will know which kind of attributes types are requested by
        RS2, but will be
        unable to know which attribute values from which AS(s) 

        will be presented by the
        Client to RS2.

        

        RS1 does see the flow (5b) since this flow is going directly
        from RS2 to
        the Client.

    
The
      "User
          Consent element"
          from the Client may use a cache of previous user
        consents and may present earlier choices 

        to the user for speeding the user consent process.

    
The
        relationships between RS1 and RS2 can change at any time but no
        AS needs to be informed on these relationships.

      

    
There
        is no protocol between any AS and any RO, including using
        "out-of-bands" means. 

      

    

        

        Case B

      

      Let
        us now suppose that RS1 is unable to fulfil the operation by its
        own but that
        it knows that the requested operation can be fulfilled 

        thanks to the help of another RS from
          the same service.

    
In
        such a case, when returning the "authorization table"
      (see
          an earlier email called "Support of FIDO and data minimization
          by RSs") 

          in the exchange (1b) for the given requested
        operation, RS1 will include both its name and the name
        of the service. 

      

    
If
        the user consents to request the inclusion of the name of
        this service into the access token(s) delivered to RS1, then
        this allows 

        to save
        the exchanges (5a) and (5b): in such a case, all the exchanges
        with the Client
        will be carried out through RS1.

    
If
        the user do not consent to
          request the inclusion of the name of
          this service into the access token(s) delivered to RS1, then
          the previous 

          case A will apply.

    
Denis

      

    

      

    

  


--------------59AA34BF6021139BCF28E8A1--


From nobody Wed Jul 15 10:04: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 CF2F73A0880 for ; Wed, 15 Jul 2020 10:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.171
X-Spam-Level: 
X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.459] 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 Uz33jcP21o1J for ; Wed, 15 Jul 2020 10:04:44 -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 C2B873A085F for ; Wed, 15 Jul 2020 10:04:43 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d53 with ME id 3V4h2300G4FMSmm03V4hz4; Wed, 15 Jul 2020 19:04:42 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 15 Jul 2020 19:04:42 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt 
Cc: "txauth@ietf.org" 
From: Denis 
Message-ID: <7c1f0439-42e4-9f7d-4dd2-e741f7cb57f2@free.fr>
Date: Wed, 15 Jul 2020 19:04:39 +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="------------CBA27F4A16CCBAD5F37FFCF0"
Content-Language: en-GB
Archived-At: 
Subject: [Txauth] Registered Clients and Dynamic Clients
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, 15 Jul 2020 17:04:46 -0000

This is a multi-part message in MIME format.
--------------CBA27F4A16CCBAD5F37FFCF0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Dick,

I am puzzled with the two following definitions in 
draft-hardt-xauth-protocol-13 :

*Registered Client* - a Client 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.

[Denis]  I interpret the last sentence in the following way: A 
Registered Client may be either an Application or a User.
              Is it correct ?

*Dynamic Client* - a Client that has not been previously registered with 
the GS, and each instance will generate
        it’s own asymmetric key pair so it can prove it is the same 
instance of the Client on subsequent requests. The GS
        MAY return a Dynamic Client a Client Handle for the Client to 
identify itself in subsequent requests. A single-page
        application with no active server component is an example of a 
Dynamic Client. A Dynamic Client MUST be interacting
        with a User.

[Denis] The draft does not include any other explanation for the reason 
to support the so-called "Dynamic Clients".
While I can understand the value to use a temporary key pair for a given 
RS, I can't understand the value for a GS
             to support unknown clients. If a GS knows nothing about a 
so-called "Dynamic Client", then it will not be able to deliver
             any user attribute into an access token to such client.

Denis


--------------CBA27F4A16CCBAD5F37FFCF0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
Hello
        Dick,

        

        I am puzzled with the two following definitions in
        draft-hardt-xauth-protocol-13 :

      

           
        *Registered Client* - a Client 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.

      
        

        [Denis]  I interpret the last sentence in the following way: A
        Registered Client may be either an Application or a User. 

                     Is it correct ?

        

             
        *Dynamic Client* - a Client that has not been previously
        registered with the
        GS, and each instance will generate 

               it’s own asymmetric key pair so it can
        prove it is the same instance of the Client on subsequent
        requests. The GS 

               MAY
        return a Dynamic Client a Client Handle for the Client to
        identify itself in
        subsequent requests. A single-page 

               application with no active server component
        is an example of a Dynamic Client. A Dynamic Client MUST be
        interacting 

               with a
        User.

        

        [Denis] The
          draft does not include any other explanation for the reason to
          support the so-called "Dynamic Clients". 

                        While I can understand the value
        to use a temporary key pair for a given
        RS, I can't understand the value for a GS 

                    to support unknown clients. If a GS knows nothing
        about a so-called "Dynamic Client", then it will not
        be able to deliver 

                    any user attribute into an access token to such
        client. 
      

    
Denis

      

    

  


--------------CBA27F4A16CCBAD5F37FFCF0--


From nobody Wed Jul 15 10:16: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 1014D3A0FC3 for ; Wed, 15 Jul 2020 10:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 p65OwZ8lW7Oc for ; Wed, 15 Jul 2020 10:16:47 -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 8BCDB3A0F07 for ; Wed, 15 Jul 2020 10:16:37 -0700 (PDT)
Received: from [192.168.1.7] (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 06FHGUEE030854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jul 2020 13:16:31 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C67C8FB1-4952-4100-B30C-EEEF87585778"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 15 Jul 2020 13:16:24 -0400
In-Reply-To: <7572576d-b5b4-dea5-3383-fbbf6cc10450@free.fr>
Cc: "txauth@ietf.org" 
To: Denis 
References: <7572576d-b5b4-dea5-3383-fbbf6cc10450@free.fr>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Support of delegation
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, 15 Jul 2020 17:16:50 -0000

--Apple-Mail=_C67C8FB1-4952-4100-B30C-EEEF87585778
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The primary delegation in mind is the delegation of rights from the =
resource owner to the client (in control of the user). Redelegation of =
rights from one RS down to another is a design consideration, but in my =
opinion that=E2=80=99s another layer of the protocol and process beyond =
the primary concern.

 =E2=80=94 Justin

> On Jul 15, 2020, at 12:16 PM, Denis  wrote:
>=20
>=20
>=20
> Support of delegation
>=20
> The charter is mentioning a "delegation process", but at this time it =
is unclear how the delegation of an operation=20
> originating from one Client towards two or more resource servers (RSs) =
will be supported.
>=20
> Here after is a proposal to support a delegation scheme constructed =
along "Privacy by Design" principles.
> A key element of this scheme is the use of a "User Consent element" =
supported by the Client.
>=20
> In order to support this proposed delegation scheme, (only) a sequence =
of delegation tokens is needed.
>=20
>=20
>     +--------+                        +------------+
>     |  User  |                        |  Resource  |
>     |        |\                       | Owner (RO) |
>     +--------+ \                      +------------+
>         |       \                           |
>         |        \                          |
>         |         \                         |
>         |          \                        |
>         |           \                       |
>   +-----------+ (2a) +---------------+  +----------+
>   |           |----->| Authorization |  |          |
>   |           | (2b) |  Server (AS)  |  |          |
>   |  Client   |<-----|               |  |          |
>   |           | (1a) +---------------+  |          |
>   |           |------------------------>| Resource |
>   |   User    |            (1b)         | Server 1 |
>   |  Consent  |<------------------------|  (RS1)   |
>   |  element  |            (3a)         |          | (4a)  =
+----------+
>   |           |------------------------>|          |------>|           =
           |
>   |           |                         |          | (4b)  |          =
|
>   |   User    |            (3b)         |          |<------|           =
           |
>   |  Consent  |<------------------------|          |       | Resource =
|
>   |  element  |                         +----------+       | Server 2 =
|
>   |           |            (5a)                            |  (RS2)   =
|
>   |           |------------------------------------------->|          =
|
>   |           |            (5b)                            |          =
|
>   |           |<-------------------------------------------|          =
|
>   +-----------+                                            =
+----------+
>=20
>=20
>=20
> DELEGATION CASES
>=20
> Two cases are being considered, whether RS1 and RS2 do not belong to =
the same service (Case A)=20
> or whether they both belong to the same service (Case B).
>=20
> The sequence of flows up to (3a) are the same as those described in an =
earlier email called :
> "A model with a User Consent Element (with a clean figure)"
>=20
>=20
> Case A
>=20
> Let us suppose that RS1 is unable to fulfil the operation by its own =
and that it needs to contact another RS, i.e. RS2.=20
> RS1 contacts RS2 (4a) and indicates the operation that it is willing =
to perform on RS2 (that operation may not be=20
> exactly the same as the original operation indicated by the client).=20=

>=20
> In return (4b), RS2 informs RS1 about which kind of attributes are =
needed by RS2 for performing the requested operation=20
> and from which Attributes Servers they may be obtained. RS2 also =
provides a temporary API address and an handle so that
> the Client can subsequently make a call directly to an API from RS2. =
RS1 forwards that information to the Client.
>=20
> This information is marked to indicate that it shall be handled by the =
"User Consent element" from the Client.=20
> The presentation of that information is up to the man machine =
interface from the Client. The user can see the new requested=20
> operation by RS1 on RS2 and which kind of attributes are requested by =
RS2, as well as from which ASs. If the user consents=20
> to release these attributes to RS2, the Client then contacts one or =
more appropriate Authorization Servers.=20
>=20
> Once the Client has obtained the appropriate access tokens targeted to =
RS2, it presents all of them to RS2 (5a) in a single request.=20
> Then RS2 is able to provide a response to the Client (5b).
>=20
> Some observations:
>=20
> The user consent is captured locally by the "User Consent element" =
from the Client. There are two user consent phases:=20
> one for RS1 and another one for RS2.
>=20
> RS1 will know which kind of attributes types are requested by RS2, but =
will be unable to know which attribute values from which AS(s)=20
> will be presented by the Client to RS2.
>=20
> RS1 does see the flow (5b) since this flow is going directly from RS2 =
to the Client.
>=20
> The "User Consent element" from the Client may use a cache of previous =
user consents and may present earlier choices=20
> to the user for speeding the user consent process.
>=20
> The relationships between RS1 and RS2 can change at any time but no AS =
needs to be informed on these relationships.
>=20
> There is no protocol between any AS and any RO, including using =
"out-of-bands" means.=20
>=20
>=20
> Case B
>=20
> Let us now suppose that RS1 is unable to fulfil the operation by its =
own but that it knows that the requested operation can be fulfilled=20
> thanks to the help of another RS from the same service.
>=20
> In such a case, when returning the "authorization table" (see an =
earlier email called "Support of FIDO and data minimization by RSs")=20
> in the exchange (1b) for the given requested operation, RS1 will =
include both its name and the name of the service.=20
>=20
> If the user consents to request the inclusion of the name of this =
service into the access token(s) delivered to RS1, then this allows=20
> to save the exchanges (5a) and (5b): in such a case, all the exchanges =
with the Client will be carried out through RS1.
>=20
> If the user do not consent to request the inclusion of the name of =
this service into the access token(s) delivered to RS1, then the =
previous=20
> case A will apply.
>=20
> Denis
>=20
> --=20
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth


--Apple-Mail=_C67C8FB1-4952-4100-B30C-EEEF87585778
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The =
primary delegation in mind is the delegation of rights from the resource =
owner to the client (in control of the user). Redelegation of rights =
from one RS down to another is a design consideration, but in my opinion =
that=E2=80=99s another layer of the protocol and process beyond the =
primary concern.

 =E2=80=94 Justin

On Jul =
15, 2020, at 12:16 PM, Denis <denis.ietf@free.fr> wrote:



 =20
  

    

    
Support of =
delegation

        

        The charter is mentioning a "delegation process", but at this
        time it
        is unclear how the delegation of an
        operation 

        originating from one Client towards two or more resource servers
        (RSs) will be supported.

        

        Here after is a proposal to support a delegation scheme
        constructed
        along "Privacy by Design" principles.

        A key element of this scheme is the use of a "User
          Consent element"
          supported by the Client.
In order to support this =
proposed delegation
        scheme, (only) a sequence of delegation tokens is =
needed.

        

            +--------+          &nb=
sp;            =
; +------------+

                | 
            User =
 |          &nb=
sp;            =
; | 
            Resource  |

                |        =
|\          &nb=
sp;           
            | Owner (RO) |

                +--------+ \          &nb=
sp;           +------------+

                    |       =
\          &nb=
sp;            =
;   
            |

                    |        =
\          &nb=
sp;            =
;  
            |

                    |         =
\          &nb=
sp;            =
; 
            |

                    |          =
\          &nb=
sp;            =
;
            |

                    |           =
\          &nb=
sp;           
            |

              +-----------+ (2a) =
+---------------+  +----------+

              =
|           =
|----->| Authorization |  |         
            |

              =
|           =
| (2b) |  Server
            (AS)  =
| 
            |          =
|

              =
| 
            Client   |<-----|          &nb=
sp;    |  |         
            |

              =
|           =
| (1a) +---------------+  |          |

              =
|           =
|------------------------>|
            Resource |

              =
|  
            User    |          &nb=
sp; (1b)         | =
Server 1 |

              =
| 
            Consent 
            |<------------------------| 
            (RS1)   |

              =
| 
            element  |          &nb=
sp; (3a)         =
|         
            |
            (4a)  =
+----------+

              =
|           =
|------------------------>|          =
|------>|         
            |

              =
|           =
|          &nb=
sp;            =
;  |         
            | (4b)  |          =
|

              =
|  
            User    |          &nb=
sp; (3b)         =
|         
            |<------|         
            |

              =
| 
            Consent 
            |<------------------------|         
            |       | Resource |

              =
| 
            element  |          &nb=
sp;            =
;  +----------+       | Server 2 |

              =
|           =
|          &nb=
sp;
            (5a)          &nb=
sp;            =
;    
            |  =
(RS2)   =
|

              =
|           =
|------------------------------------------->|          =
|

              =
|           =
|         
              (5b)          &nb=
sp;            =
;     |          =
|

              =
|           =
|<-------------------------------------------|          =
|

              =
+-----------+          &nb=
sp;            =
;            &=
nbsp;       
            +----------+

          

        

        
DELEGATION
          CASES

        

        Two cases are being considered, whether RS1 and RS2 do not
        belong to the same
        service (Case A) 

        or whether they both belong to the same service (Case =
B).
The
        sequence of flows up to (3a) are the same as those described in
        an earlier email called :

        "A model with a User Consent Element (with a clean figure)"

      

        

        Case A

        

        Let us suppose that RS1 is unable to fulfil the operation by its
        own and that
        it needs to contact another RS, i.e. RS2. 

        RS1 contacts RS2 (4a) and indicates
        the operation that it is willing to perform on RS2 (that
        operation may
        not be 

        exactly the same as the original operation indicated by the
        client). 

        

        In return (4b), RS2 informs RS1 about which kind of attributes
        are needed by
        RS2 for performing the requested operation 

        and from which Attributes Servers
        they may be obtained. RS2 also provides a temporary API address
        and an handle so that

        the
        Client can subsequently make a call directly to an API from RS2.
        RS1 forwards that
        information to the Client.

        

        This information is marked to indicate that it shall be handled
        by the
        "User Consent element" from the Client. 

        The presentation of that
        information is up to the man machine interface from the Client.
        The user can
        see the new requested 

        operation by RS1 on RS2 and which kind of attributes are
        requested by RS2, as well as from which ASs. If the user
        consents 

        to release
        these attributes to RS2, the Client then contacts one or more
        appropriate
        Authorization Servers. 

        

        Once the Client has obtained the appropriate access tokens
        targeted to RS2, it
        presents all of them to RS2 (5a) in a single request. 

        Then RS2 is able to
        provide a response to the Client (5b).

    

    
Some
          observations:

        

        The user consent is captured locally by the "User Consent
        element"
        from the Client. There are two user consent =
phases: 

        one for RS1 and another one
        for RS2.

        

        RS1 will know which kind of attributes types are requested by
        RS2, but will be
        unable to know which attribute values from which AS(s) 

        will be presented by the
        Client to RS2.

        

        RS1 does see the flow (5b) since this flow is going directly
        from RS2 to
        the Client.
The
      "User
          Consent element"
          from the Client may use a cache of previous user
        consents and may present earlier choices 

        to the user for speeding the user consent process.
The
        relationships between RS1 and RS2 can change at any time but no
        AS needs to be informed on these relationships.

      
There
        is no protocol between any AS and any RO, including using
        "out-of-bands" means. 

      

        

        Case B

      

      Let
        us now suppose that RS1 is unable to fulfil the operation by its
        own but that
        it knows that the requested operation can be fulfilled 

        thanks to the help of another RS from
          the same service.
In
        such a case, when returning the "authorization table"
      (see
          an earlier email called "Support of FIDO and data minimization
          by RSs") 

          in the exchange (1b) for the given requested
        operation, RS1 will include both its name and the name
        of the service. 

      
If
        the user consents to request the inclusion of the name of
        this service into the access token(s) delivered to RS1, then
        this allows 

        to save
        the exchanges (5a) and (5b): in such a case, all the exchanges
        with the Client
        will be carried out through RS1.
If
        the user do not consent to
          request the inclusion of the name of
          this service into the access token(s) delivered to RS1, then
          the previous 

          case A will apply.
Denis

      

      

  


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

=

--Apple-Mail=_C67C8FB1-4952-4100-B30C-EEEF87585778--


From nobody Wed Jul 15 10:18: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 572993A0B24 for ; Wed, 15 Jul 2020 10:18: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, 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 nuhgEIuIzT6g for ; Wed, 15 Jul 2020 10:18: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 BCD3D3A0FB2 for ; Wed, 15 Jul 2020 10:17:52 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id h22so3431626lji.9 for ; Wed, 15 Jul 2020 10:17: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=GsERo1vBCm1Ofoh4/nLQoJa4ydniNH4OiX7pKHpbnOo=; b=rJyzVeMQKY6+IRPtzxj54Sq7KkaF9OgHPrDXUNLr/50+vHwZAmw62VeOsFN/NFBqkL qARnc7R6njl/sAK6k4kfQC5D5xS4ztzgELmvaozk5uot0ELxVsgE47TZ3BtX9TeV3i1l 4LKJeh+udUAXVroGVgwQdd2N6pW9E2Bs+4evkt436SY8eg+fGE0Sx3qwFYXSHrDNSmR4 R3Hx8Aq6sd/5z4oxlGr4QPnwoCuDI2Je1Vk7gPHIVNRkmXXwJp9Vb9HWSlVu3VxcpBWh WYhSmb/t01bENm+GLe6PeRuYCVaCtK4FhsWmPOKXXo7WYG8d282Rcsn/MoJnTDAN8mMC GmSg==
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=GsERo1vBCm1Ofoh4/nLQoJa4ydniNH4OiX7pKHpbnOo=; b=hNe1T9d9/Rm2xBuUFxaMNrfOguQ3z3rm5y+ePrckEi8mijLpuMVjLT209xJZqjwf5l dbbOaqvxt6dHTMlUnJgnb7YCzj6SlDt3Q5KlLikC2lVH/FFSpQGriVdDsFDQ3Hiy66AR yb5eyUsTKmeBoKzHTFFbV+UrpNcowvvK2nXWO7apO2IQxOq55c5K8ymA6nrUSCfy3+rw WLiKtboMjIa7L4CzOuXE0kKdeAG85oiw4w6UwDZeMe8BcAMLxIyNApJjbuuzBhcpqkGt lkvzV1i5o5b3Wc7cak3VJM9CA9FSP0G6k/R9LPb6xJdji97E/EZoV8lJIpSQguKHT/be Zapw==
X-Gm-Message-State: AOAM533VrmNQP1jaD8jaJEsLsAPMQzztEF8Nhk/e8HxRrOsgmoyB8yZ1 26Iqlgl0/liFU8HnPCaobkHGyOB+xnXsQzX5R1QIQ/MR
X-Google-Smtp-Source: ABdhPJyQyahOhVbt3anAuQX/ZyArGLSjY+PEi7AQExL3X/1TxFZIlE78+I/R2p1OSIAR6PaXvXDARhfXgdMKR3epTgc=
X-Received: by 2002:a2e:b70b:: with SMTP id j11mr93269ljo.142.1594833470556; Wed, 15 Jul 2020 10:17:50 -0700 (PDT)
MIME-Version: 1.0
References: <7c1f0439-42e4-9f7d-4dd2-e741f7cb57f2@free.fr>
In-Reply-To: <7c1f0439-42e4-9f7d-4dd2-e741f7cb57f2@free.fr>
From: Dick Hardt 
Date: Wed, 15 Jul 2020 10:17:14 -0700
Message-ID: 
To: Denis 
Cc: "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000007d0fac05aa7e1ab0"
Archived-At: 
Subject: Re: [Txauth] Registered Clients and Dynamic Clients
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, 15 Jul 2020 17:18:15 -0000

--0000000000007d0fac05aa7e1ab0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 15, 2020 at 10:04 AM Denis  wrote:

> Hello Dick,
>
> I am puzzled with the two following definitions in
> draft-hardt-xauth-protocol-13 :
>
>       *Registered Client* - a Client 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.
>
> [Denis]  I interpret the last sentence in the following way: A Registered
> Client may be either an Application or a User.
>              Is it correct ?
>

No. A Registered Client MAY be interacting with a User, or it MAY not. IE,
a Registered Client may be a service.


>
>       *Dynamic Client* - a Client that has not been previously registered
> with the GS, and each instance will generate
>        it=E2=80=99s own asymmetric key pair so it can prove it is the sam=
e
> instance of the Client on subsequent requests. The GS
>        MAY return a Dynamic Client a Client Handle for the Client to
> identify itself in subsequent requests. A single-page
>        application with no active server component is an example of a
> Dynamic Client. A Dynamic Client MUST be interacting
>        with a User.
>
> [Denis] The draft does not include any other explanation for the reason
> to support the so-called "Dynamic Clients".
>             While I can understand the value to use a temporary key pair
> for a given RS, I can't understand the value for a GS
>             to support unknown clients. If a GS knows nothing about a
> so-called "Dynamic Client", then it will not be able to deliver
>             any user attribute into an access token to such client.
>

More of an explanation of Dynamic Clients is a good call out, thanks!

A Dynamic Client MUST be interacting with a User, as "trust" of the Client
is done by the User. A Single Page Application (SPA) or a mobile app are
examples of clients that cannot have a shared secret, but can generate and
keep secure their own key pair..

As suggested in another thread, GNAP could support Clients that are between
these two extremes. Mike called out automatic registration per OpenID
Connect Federation as one example. Other options include a "software
statement" passed from the Client to the GS.

We may want to revisit the terms "Registered Client" and "Dynamic Client"
as we broaden the mechanisms for Clients to "register" with a GS, but these
are the common cases today, so I picked them.

/Dick



> Denis
>
>

--0000000000007d0fac05aa7e1ab0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Wed, Jul 15, 2020 at 10:04 AM Deni=
s <denis.ietf@free.fr> wrot=
e:

 =20

   =20
 =20
  

    
Hello
        Dick,

        

        I am puzzled with the two following definitions in
        draft-hardt-xauth-protocol-13 :

      

      =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
        *Registered Client* - a Client that has registered with the GS
        and has a Client
        ID to identify itself, and 

        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 can prove it possesses a key t=
hat is linked to the
        Client ID.=C2=A0 The GS may
        have different
        policies for what 

        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 different Registered Clients c=
an request.=C2=A0 A Registered Client MAY be
        interacting with
        a User.

      
        

        [Denis]=C2=A0 I interpret the last sentence in the following way: A
        Registered Client may be either an Application or a 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 Is it correct ?

No. A Registered Client MAY be interacting with a User, or it MAY not. IE,=
 a Registered Client may be a service.
=C2=A0

        

        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
        *Dynamic Client* - a Client that has not been previously
        registered with the
        GS, and each instance will generate 

        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it=E2=80=99s own asymmetric ke=
y pair so it can
        prove it is the same instance of the Client on subsequent
        requests. The GS 

        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MAY
        return a Dynamic Client a Client Handle for the Client to
        identify itself in
        subsequent requests. A single-page 

        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 application with no active ser=
ver component
        is an example of a Dynamic Client. A Dynamic Client MUST be
        interacting 

        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with a
        User.

        

        [Denis] The
          draft does not include any other explanation for the reason to
          support the so-called "Dynamic=
 Clients". 

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 While I can understand the value
        to use a temporary key pair for a given
        RS, I can't understand the value for a GS 

        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
to support unknown clients. If a GS knows nothing
        about a so-called "Dynamic Client", then it will not
        be able to deliver 

        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 any u=
ser attribute into an access token to such
        client.

More of an=
 explanation of Dynamic Clients is a good call out, thanks!

<=
/div>
A Dynamic Client MUST be interacting with a User, as "trust&=
quot; of the Client is done by the User. A Single Page Application (SPA) or=
 a mobile app are examples of clients that cannot have a shared secret,=C2=
=A0but can generate and keep secure their=C2=A0own key pair..=C2=A0

As suggested in another thread, GNAP could support Client=
s that are between these two extremes. Mike called out automatic registrati=
on per OpenID Connect Federation as one example. Other options include a &q=
uot;software statement" passed from the Client to the GS.
We may want to revisit the terms "Registered Client"=
 and "Dynamic Client" as we broaden the mechanisms=C2=A0for Clien=
ts to "register" with a GS, but these are the common cases today,=
 so I picked them.

/Dick

=
=C2=A0
 
      

    
Denis

      

    

  





--0000000000007d0fac05aa7e1ab0--


From nobody Wed Jul 15 10:20: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 E4B703A0CFF for ; Wed, 15 Jul 2020 10:19:57 -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 ZtDlsmz0Dl1n for ; Wed, 15 Jul 2020 10:19:55 -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 C127E3A08A5 for ; Wed, 15 Jul 2020 10:19:54 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id f5so3428989ljj.10 for ; Wed, 15 Jul 2020 10:19: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=Ma/sRjxAtiXe2t2qt5hlrNEzjsx09eAAnfFQIfXPFso=; b=NkpFPjFiimpSykGaRDvXfIHXnuJ5rDd8BVD1Rvvpy4VwuW4k0u1FaQDy+bmNQkBFpI +IKXBXakm1wqY6cIYHPa143wQc4kqkloGIgm0J7hKoARk2h95hybkT5yC0OyhZa0Kn9A Mc6uKIRaGi90PjM7Ls+1++DEAALjzkGkHZxpdI6v1bmmsnIEtybMzo+c6b4gPQFTAeAg VQl+FfuUf8BKMijD/o9fDMobyhkZ84FAN3KLUNKlXBbfa929cf0tefAmLbqslyT0bzKu RGZK+r2/Pl2LnC+58qYZQClGOuDUMXTFJQv+yn+s9Wt+dFiXwAAn/xKgBpPWP3aBf8RY 9IXQ==
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=Ma/sRjxAtiXe2t2qt5hlrNEzjsx09eAAnfFQIfXPFso=; b=RSgTPs9+gDyXN01SgBGrpKfK/Sp0f7FqgLxEQsaJYlWimh9lVVsPkpVyT2JJMzD5GF Z+uiVm4yaLRQjvzaScAvW2TKpuk/RzM02w0wTCLE6sjgXzM9QB0VBep4LA00r2PuDmTv S/vWkkQhZ3Oj30T+noecjtIlJq9RfYKcFVqpUtDGVgltVZ7ZlgsUrmTzzHFaGd/6DQ0Y j5Q7RRb8HtNzBBMhAh4ler1HD+Qd6ay+ZITqDUcQPAZgbom4qMBho/8bQZ4h8hLdp2uj cFD1re2HbShFmfPK/WHCDCEbDJVYTsR1PNXslE7j61I9onqM8uqWEvX6EBkZhBRlUWlm Bj3A==
X-Gm-Message-State: AOAM533aFTKZQnrqR4mg81+VGHzL2a9sp2qtjToN42A7WrTbNz6JpK1z I4UdhvBkg5Bsj82g94+8tXAbSvBDOA+lOSv+JDO7hwkN
X-Google-Smtp-Source: ABdhPJyBal/kouIkoqYPBnAFFlC6/gYKdkbP4Pnqxq7DukIcDkDWLSi3nc3txpy7iEdUYk2icLr3FQtIISwm8dhjLqg=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr87075ljn.5.1594833592585; Wed, 15 Jul 2020 10:19:52 -0700 (PDT)
MIME-Version: 1.0
References: <7572576d-b5b4-dea5-3383-fbbf6cc10450@free.fr> 
In-Reply-To: 
From: Dick Hardt 
Date: Wed, 15 Jul 2020 10:19:16 -0700
Message-ID: 
To: Justin Richer 
Cc: Denis , "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000c3126e05aa7e2188"
Archived-At: 
Subject: Re: [Txauth] Support of delegation
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, 15 Jul 2020 17:19:58 -0000

--000000000000c3126e05aa7e2188
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1

On Wed, Jul 15, 2020 at 10:17 AM Justin Richer  wrote:

> The primary delegation in mind is the delegation of rights from the
> resource owner to the client (in control of the user). Redelegation of
> rights from one RS down to another is a design consideration, but in my
> opinion that=E2=80=99s another layer of the protocol and process beyond t=
he primary
> concern.
>
>  =E2=80=94 Justin
>
> On Jul 15, 2020, at 12:16 PM, Denis  wrote:
>
>
>
> *Support of delegation*
>
> The charter is mentioning a "delegation process", but at this time it is
> unclear how the delegation of an operation
> originating from one Client towards two or more resource servers (RSs)
> will be supported.
>
> Here after is a proposal to support a delegation scheme constructed along
> "Privacy by Design" principles.
> A key element of this scheme is the use of a "User Consent element"
> supported by the Client.
>
> In order to support this proposed delegation scheme, (only) a sequence of
> delegation tokens is needed.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *    +--------+                        +------------+     |  User
> |                        |  Resource  |     |
> |\                       | Owner (RO) |     +--------+ \
>           +------------+         |       \                           |
>         |        \                          |         |
> \                         |         |          \                        |
>         |           \                       |   +-----------+ (2a)
> +---------------+  +----------+   |           |----->| Authorization |
> |          |   |           | (2b) |  Server (AS)  |  |          |   |
> Client   |<-----|               |  |          |   |           | (1a)
> +---------------+  |          |   |           |------------------------>|
> Resource |   |   User    |            (1b)         | Server 1 |   |
> Consent  |<------------------------|  (RS1)   |   |  element  |
> (3a)         |          | (4a)  +----------+   |
> |------------------------>|          |------>|          |   |
> |                         |          | (4b)  |          |   |   User
> |            (3b)         |          |<------|          |   |  Consent
> |<------------------------|          |       | Resource |   |  element
> |                         +----------+       | Server 2 |   |
> |            (5a)                            |  (RS2)   |   |
> |------------------------------------------->|          |   |
> |            (5b)                            |          |   |
> |<-------------------------------------------|          |
> +-----------+                                            +----------+ *
>
> *DELEGATION CASES*
>
> Two cases are being considered, whether RS1 and RS2 do not belong to the
> same service (Case A)
> or whether they both belong to the same service (Case B).
>
> The sequence of flows up to (3a) are the same as those described in an
> earlier email called :
> "A model with a User Consent Element (with a clean figure)"
>
>
> *Case A*
>
> Let us suppose that RS1 is unable to fulfil the operation by its own and
> that it needs to contact another RS, i.e. RS2.
> RS1 contacts RS2 (4a) and indicates the operation that it is willing to
> perform on RS2 (that operation may not be
> exactly the same as the original operation indicated by the client).
>
> In return (4b), RS2 informs RS1 about which kind of attributes are needed
> by RS2 for performing the requested operation
> and from which Attributes Servers they may be obtained. RS2 also provides
> a temporary API address and an handle so that
> the Client can subsequently make a call directly to an API from RS2. RS1
> forwards that information to the Client.
>
> This information is marked to indicate that it shall be handled by the
> "User Consent element" from the Client.
> The presentation of that information is up to the man machine interface
> from the Client. The user can see the new requested
> operation by RS1 on RS2 and which kind of attributes are requested by RS2=
,
> as well as from which ASs. If the user consents
> to release these attributes to RS2, the Client then contacts one or more
> appropriate Authorization Servers.
>
> Once the Client has obtained the appropriate access tokens targeted to
> RS2, it presents all of them to RS2 (5a) in a single request.
> Then RS2 is able to provide a response to the Client (5b).
>
> *Some observations*:
>
> The user consent is captured locally by the "User Consent element" from
> the Client. There are two *user consent* phases:
> one for RS1 and another one for RS2.
>
> RS1 will know which kind of attributes types are requested by RS2, but
> will be unable to know which attribute values from which AS(s)
> will be presented by the Client to RS2.
>
> RS1 does see the flow (5b) since this flow is going directly from RS2 to
> the Client.
>
> The "User Consent element" from the Client may use a cache of previous
> user consents and may present earlier choices
> to the user for speeding the user consent process.
>
> The relationships between RS1 and RS2 can change at any time but no AS
> needs to be informed on these relationships.
>
> There is no protocol between any AS and any RO, including using
> "out-of-bands" means.
>
>
> *Case B*
>
> Let us now suppose that RS1 is unable to fulfil the operation by its own
> but that it knows that the requested operation can be fulfilled
> thanks to the help of another RS *from the same service*.
>
> In such a case, when returning the "authorization table" (see an earlier
> email called "Support of FIDO and data minimization by RSs")
> in the exchange (1b) for the given requested operation, RS1 will include
> both its name and the name of the service.
>
> If the user consents to request the inclusion of the name of this service
> into the access token(s) delivered to RS1, then this allows
> to save the exchanges (5a) and (5b): in such a case, all the exchanges
> with the Client will be carried out through RS1.
>
> If the user do not consent to request the inclusion of the name of this
> service into the access token(s) delivered to RS1, then the previous
> case A will apply.
>
> 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
>

--000000000000c3126e05aa7e2188
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


+1

On Wed, Jul 15, 2020 at 10:17 AM 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">
The primary delegation in mind is the delegation of rights =
from the resource owner to the client (in control of the user). Redelegatio=
n of rights from one RS down to another is a design consideration, but in m=
y opinion that=E2=80=99s another layer of the protocol and process beyond t=
he primary concern.

=C2=A0=E2=80=94 Justin

<=
blockquote type=3D"cite">
On Jul 15, 2020, at 12:16 PM, Denis <denis.ietf@free.fr&g=
t; wrote:



 =20
  

    

    
Support of delegation

        

        The charter is mentioning a "delegation process", but at =
this
        time it
        is unclear how the delegation of an
        operation 

        originating from one Client towards two or more resource servers
        (RSs) will be supported.

        

        Here after is a proposal to support a delegation scheme
        constructed
        along "Privacy by Design" principles.

        A key element of this scheme is the use of a "User
          Consent element"
          supported by the Client.
=
In order to support this p=
roposed delegation
        scheme, (only) a sequence of delegation tokens is needed.

        

        =C2=A0=C2=A0=C2=A0 +--------+=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0 |

            =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |\=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
            | Owner (RO) |

            =C2=A0=C2=A0=C2=A0 +--------+ \=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+------------+=


            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
            |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
            |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
            |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
            |

            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
            |

            =C2=A0=C2=A0+-----------+ (2a) +-----=
----------+=C2=A0 +----------+

            =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |----->| Authorization |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
            |

            =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 | (2b) |=C2=A0 Server
            (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
            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 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
            |

            =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 | (1a) +---------------+=C2=A0 |=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 |

            =C2=A0 |=C2=A0=C2=A0
            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 (1b)=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Server 1 |

            =C2=A0 |=C2=A0
            Consent=C2=A0
            |<------------------------|=C2=A0
            (RS1)=C2=A0=C2=A0 |

            =C2=A0 |=C2=A0
            element=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)=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
            |
            (4a)=C2=A0 +----------+

            =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |------------------------>|=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |------>|=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
            |

            =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
            | (4b)=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (3b)=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
            |<------|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
            |

            =C2=A0 |=C2=A0
            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| Resource |

            =C2=A0 |=C2=A0
            element=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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 2 |

            =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
            (5a)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
            |=C2=A0 (RS2)=C2=A0=C2=A0 |
            =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |------------------------------------------=
->|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=


            =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
            =C2=A0=C2=A0(5b)=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

            =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 |<--------------------------------------=
-----|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=


            =C2=A0 +-----------+=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
            +----------+

          

        

        
DELEGATION
          CASES

        

        Two cases are being considered, whether RS1 and RS2 do not
        belong to the same
        service (Case A) 

        or whether they both belong to the same service (Case B).
Th=
e
        sequence of flows up to (3a) are the same as those described in
        an earlier email called :

        "A model with a User Consent Element (with a clean figure)&quo=
t;

      

        

        Case A

        

        Let us suppose that RS1 is unable to fulfil the operation by its
        own and that
        it needs to contact another RS, i.e. RS2. 

        RS1 contacts RS2 (4a) and indicates
        the operation that it is willing to perform on RS2 (that
        operation may
        not be 

        exactly the same as the original operation indicated by the
        client). 

        

        In return (4b), RS2 informs RS1 about which kind of attributes
        are needed by
        RS2 for performing the requested operation 

        and from which Attributes Servers
        they may be obtained. RS2 also provides a temporary API address
        and an handle so that

        the
        Client can subsequently make a call directly to an API from RS2.
        RS1 forwards that
        information to the Client.

        

        This information is marked to indicate that it shall be handled
        by the
        "User Consent element" from the Client. 

        The presentation of that
        information is up to the man machine interface from the Client.
        The user can
        see the new requested 

        operation by RS1 on RS2 and which kind of attributes are
        requested by RS2, as well as from which ASs. If the user
        consents 

        to release
        these attributes to RS2, the Client then contacts one or more
        appropriate
        Authorization Servers. 

        

        Once the Client has obtained the appropriate access tokens
        targeted to RS2, it
        presents all of them to RS2 (5a) in a single request. 

        Then RS2 is able to
        provide a response to the Client (5b).

    

    
Some
          observations:

        

        The user consent is captured locally by the "User Consent
        element"
        from the Client. There are two user consent phases: 

        one for RS1 and another one
        for RS2.

        

        RS1 will know which kind of attributes types are requested by
        RS2, but will be
        unable to know which attribute values from which AS(s) 

        will be presented by the
        Client to RS2.

        

        RS1 does see the flow (5b) since this flow is going directly
        from RS2 to
        the Client.
The
      "User
          Consent element"
          from the Client may use a cache of previous user
        consents and may present earlier choices 

        to the user for speeding the user consent process.
The
        relationships between RS1 and RS2 can change at any time but no
        AS needs to be informed on these relationships.

      
There
        is no protocol between any AS and any RO, including using
        "out-of-bands" means. 

      

        

        Case B

      

      Let
        us now suppose that RS1 is unable to fulfil the operation by its
        own but that
        it knows that the requested operation can be fulfilled 

        thanks to the help of another RS from
          the same service.
In
        such a case, when returning the "authorization table"
      (see
          an earlier email called "Support of FIDO and data minimizati=
on
          by RSs") 

          in the exchange (1b) for the given requested
        operation, RS1 will include both its name and the name
        of the service. 

      
If
        the user consents to request the inclusion of the name of
        this service into the access token(s) delivered to RS1, then
        this allows 

        to save
        the exchanges (5a) and (5b): in such a case, all the exchanges
        with the Client
        will be carried out through RS1.
<=
span style=3D"font-family:Arial" lang=3D"EN-US">If
        the user do not consent to
          request the inclusion of the name of
          this service into the access token(s) delivered to RS1, then
          the previous 

          case A will apply.
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




--000000000000c3126e05aa7e2188--


From nobody Wed Jul 15 20:28: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 4185E3A0B39 for ; Wed, 15 Jul 2020 20:28:24 -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=unavailable 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 CdpDL7WSr_CQ for ; Wed, 15 Jul 2020 20:28:21 -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 2360B3A0B33 for ; Wed, 15 Jul 2020 20:28:20 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id r12so5291926wrj.13 for ; Wed, 15 Jul 2020 20:28:20 -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=2Bm9meF3dnM+lH5YVM74RKs0uOCUGea19ooSIkKaTvM=; b=QZRn/RtGEhZ9NE2+RCH8Q3nzDMaQ8+XLTNPIx3AQ8A7NONCLoGSQnidzUUI4TcMyVF 4bm8xeZ10lA7WaIVUEdTPgDnv3rcIC+Bkq1qQ1hRILb2zKzzR5sw7XKtPKZ2ndv9oxdT ZEeZlYeN39N5akLjCNCEqoshKwszNGOs+Z+GY=
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=2Bm9meF3dnM+lH5YVM74RKs0uOCUGea19ooSIkKaTvM=; b=jz8TljWV8Y41dFPc7vwnI6tM1ho5+2DuQvP1BfZI7l8g9sdzb2ejxn9gVWBBTnskM3 TGmqShBegcU3dFCtDDhNaEtHlruYie21xCI2G1PXdQA1khDsGnj5kcqoFbaTcnBs9K6J Wmcjx7d7Zrd6yAZ/G2Yp/qbcQDY0lwLD56mLoRKUjMlQEetaRP79+nqOc9f/XpbueXfl c3vWdXvUcEpZIAtQ1nN0YM1rIUIdQbAeBrBgYh5AyyaDTSSiw4jNx28nej+X9hDOKa8F gdzx7ddQVNJyNz1fbM5eDMASEyIIBzEhB9pkD6HsGE++FUqL4fhNfAW+nQ8l5P9R5QaN szWg==
X-Gm-Message-State: AOAM531+N+FxcRg9MJBBS9Nd/lGbbYby+z9bPUTWQ06LlRTeDQbRq9+D s1Y/yk8/LtIG1IJoY8l/dkhmyRLz7gS31xaGytS7Pw==
X-Google-Smtp-Source: ABdhPJzCiq4tYw6+8PVs0GFSHnEjcODEoSX9/BOwxpqK26aaIoYV93d+x2wAtHWo1Xgy2wKcD/Bm7Ze0acB74C41Ix4=
X-Received: by 2002:adf:91e1:: with SMTP id 88mr2742120wri.89.1594870099470; Wed, 15 Jul 2020 20:28:19 -0700 (PDT)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Francis Pouatcha 
Date: Wed, 15 Jul 2020 23:28:08 -0400
Message-ID: 
To: Dick Hardt 
Cc: Francis Pouatcha , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000be006f05aa86a11c"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 16 Jul 2020 03:28:24 -0000

--000000000000be006f05aa86a11c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Dick,


>>>
>>>>
>>>> 2. Abstract Protocol Flow
>>>>
>>>> I am missing an abstract protocol flow like the one defined in
>>>> https://tools.ietf.org/html/rfc6749#section-1.2.
>>>>
>>>
>>> That's an interesting point. GNAP also has identity claims, so the
>>> abstract flow is somewhat different (there is no Authorization Grant fr=
om
>>> the RO), and not all steps always happen. (there may not be steps (E) a=
nd
>>> (F) with a Resource Server)
>>>
>>> Would you elaborate on what you think would be useful here, that is not
>>> in the specific flows?
>>>
>> A diagram that generalizes the steps, independently of interaction mode
>> is essential for the reader's navigation of the rest of the document. Th=
is
>> is what #section-1.2 of RFC6749 does. I hope we can produce a similar
>> diagram.
>>
>> A subsection of
>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>> could be defined for this.
>>
>
> Interaction modes are one dimension where the steps could be generalized,
> but some steps are optional. For example, the User may not interact with
> the GS, and the GS may interact with the RO. The Client may only want
> claims, and there would be no step of the Client calling the RS.
>
> A generalized diagram would need to include all optional steps so that it
> did not mislead a reader into thinking the diagram included all general
> steps, but it does not seem that is what you are asking for as you wrote:
>
> A subsection of
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
> could be defined for this."
>
> Perhaps you can share how you think the diagram would look?
>
find below my proposal of an abstract sequence diagram.

+----+  +------+  +---+  +---+  +---+
|User|  |Client|  |RS |  |GS |  |RO |
+----+  +------+  +---+  +-+-+  +-+-+
  |(1) Service Request     |      |
  |-------->|       |      |      |
  |         |(2) Service Intent   |
  |         |------>|      |      |
  |         |(3) AuthZ Challenge  |
  |         |<------|      |      |
  |         |(4) AuthZ Request    |
  |         |------------->|      |
  |         |       |      |(5) Consent Request
  |         |       |      |----->|
  |         |       |      |(6) Grant Consent
  |         |       |      |<-----|
  |         |(7) Grant Access (Token)
  |         |<-------------|      |
  |         |(8) Service Request (Token)
  |         +------>+      |      |
  |         |(9) Service Response |
  |         |<------|      |      |
  |(10) Service Response   |      |
  +<--------|       |      |      |
  +         +       +      +      +

(1) Service Request: This is the service request sent by a User to the
Client. This can be a simple file read request or even a complex payment
initiation request.

(2) Service Intent: In order to discover authorization requirements, the
Client sends a service intent to the RS.

(3) AuthZ Challenge: The response to a service intent request is generally
an AuthZ Challenge. The content of this AuthZ Challenge, can be an
identification challenge, an AuthZ exemption, or details on requested
AuthZ. The content AuthZ Challenge can be similar to the oAuth2 RAR.

(4) AuthZ Request : the Client sends an AuthZ Request to the GS including
the AuthZ Challenge. This request can be similar to the oAuth PAR request.

(5) Requests Consent : GS sends consent request to RO.
Remark: The abstract protocol flow does not display a response of the
request (4) to the Client. This is IMO a general misunderstanding. This
protocol wants the GS to collect a consent from the RO.
- In the case of a "redirect interaction", GS will use transport
infrastructure provided by the Client to instruct the User to send the RO
to the GS (in most cases, user and RO are identical).
- In the case of a "decoupled interaction", GS will directly contact RO and
collect consent in a direct interaction with the RO (see CIBA).
- In the case of an "embedded interaction", GS will allow the Client to
directly collect the Consent of the RO in a direct interaction with the
User.

(6) Grant Consent : RO return a Consent Grant to GS.

(7) Grant Access : GS produces the corresponding access token and returns
it to Client.

(8) Service Request : Client uses the access token to send the service
request to RS.

(9) and (10) are self explaining.

One of our upcoming exercises will be to challenge this abstract protocol
flow with existing interactions (and if possible associated use cases) to
see if we are missing something. After an agreement on the abstract
protocol flow we can make sure each interaction provides a mapping to step
1 to 10.

I will strip the rest of the post here. And bring further responses in
separate mails.

Best regards.
/Francis

> =E1=90=A7
>
--=20
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--000000000000be006f05aa86a11c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Dick,

<=
div class=3D"gmail_quote">
=C2=A0

2. Abstra=
ct Protocol Flow







I am missing an abstract protocol flow like the one de=
fined in https://tools.ietf.org/html/rfc6749#section-1.2.

That's an interesting point. G=
NAP also has identity claims, so the abstract flow is somewhat different (t=
here is no Authorization Grant from the RO), and not all steps always happe=
n. (there may not be steps (E) and (F) with a Resource Server)
=


Would you elaborate on what you think would be useful here, that is not i=
n the specific flows?
A diagram that generalizes the steps, independently of inter=
action mode is essential for the reader's navigation of the rest of the=
 document.=C2=A0This is what=C2=A0#section-1.2 of RFC6749 does. I hope we c=
an produce a similar diagram.
A subsection of=C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#se=
ction-1.1 could be defined for this.

Interaction modes are one dimension where the steps could be generaliz=
ed, but some steps are optional. For example, the User may not interact wit=
h the GS, and the GS may interact with the RO. The Client may only want cla=
ims, and there would be no step of the Client calling the RS.
<=
div>
A generalized diagram would need to include all optional steps so that it =
did not mislead a reader into thinking the diagram included all general ste=
ps, but it does not seem that is what you are asking for as you wrote:

A subsection of=C2=A0https://tools.ietf.=
org/html/draft-hardt-xauth-protocol-12#section-1.1 could be defined for=
 this."

Perhaps you can share how you think the diag=
ram would look?
find below my proposal of an abstract sequence diagram.

+----+ =C2=A0+------+ =C2=A0+---+ =C2=A0+---+ =C2=A0+---+
|User| =C2=
=A0|Client| =C2=A0|RS | =C2=A0|GS | =C2=A0|RO |
+----+ =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 |(2) Service Intent =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=
=A0 =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) AuthZ Challenge =C2=A0|
=C2=A0 | =
=C2=A0 =C2=A0 =C2=A0 =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) AuthZ 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|(5) Consent 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|(6) Grant 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 |(7) Grant Access (Token)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 |<-------------| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 |(8) Service Request (Token)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 +------>+ =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(9) Service Response |
=C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 |<------| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=
=A0|
=C2=A0 |(10) Service Response =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=
=A0 +<--------| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=
=A0 =C2=A0|
=C2=A0 + =C2=A0 =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) Service=
 Request: This is the service request sent by a User to the Client. This ca=
n be a simple file read request or even a complex payment initiation reques=
t.

(2) Service Intent: In order to discover authorization req=
uirements, the Client sends a service intent to the RS.

(3) A=
uthZ Challenge: The response to a service intent request is generally an Au=
thZ Challenge. The content of this AuthZ Challenge, can be an identificatio=
n challenge, an AuthZ exemption, or details on requested AuthZ. The content=
 AuthZ Challenge can be similar to the oAuth2 RAR.

(4) AuthZ =
Request : the Client sends an AuthZ Request to the GS including the AuthZ C=
hallenge. This request can be similar to the oAuth PAR request.

(5) Requests Consent : GS sends consent request to RO.=C2=A0
Remark: The abstract protocol flow does not =
display a response of the request (4) to the Client. This is IMO a general =
misunderstanding. This protocol wants the GS to collect a consent from the =
RO.=C2=A0
- In the case of a &quo=
t;redirect interaction", GS will use transport infrastructure provided=
 by the Client to instruct the User to send the RO to the GS (in most cases=
, user and RO are identical).
- I=
n the case of a "decoupled interaction", GS will directly contact=
 RO and collect consent in a direct interaction with the RO (see CIBA).
- In the case of an "embedded i=
nteraction", GS will allow the Client to directly collect the Consent =
of the RO in a direct interaction with the User.

(=
6) Grant Consent : RO return a Consent Grant to GS.

(7) Grant=
 Access : GS produces the corresponding access token and returns it to Clie=
nt.

(8) Service Request : Client uses the access token to sen=
d the service request to RS.

=

(9) and (10) are self explaining=
.

One of our upcoming=C2=A0exercises will be to challenge thi=
s abstract protocol flow with existing interactions=C2=A0(and if possible a=
ssociated use cases) to see if we are missing something. After an agreement=
 on the abstract protocol flow we can make sure each interaction provides a=
 mapping to step 1 to 10.

I will strip the rest =
of the post here. And bring further responses in separate mails.

Best regards.
/Francis=C2=A0=C2=A0


3D""=E1=90=
=A7
-- 
<=
/font>
Francis Pouatcha
Co-Founder and Technical Lead
ad=
orsys GmbH & Co. KG


--000000000000be006f05aa86a11c--


From nobody Thu Jul 16 00:49: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 0D1DB3A0BE9 for ; Thu, 16 Jul 2020 00:49: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=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 hl7Kr90IO0gG for ; Thu, 16 Jul 2020 00:49:43 -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 B8B373A08B3 for ; Thu, 16 Jul 2020 00:49:43 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id a11so4283544ilk.0 for ; Thu, 16 Jul 2020 00:49: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=2KOC+LUiZS9yANP7OehDMtL9E04r5STlgFFoAzhN3dk=; b=mwqOcylwsiTI5Jlreo/wN1IFm8fmjl1A/DlKKcGyg7OZzM8vcJLcHFr8q7TDoT32ih 8E8GNTCujYNFmzpHuUAXdTteSljS00XXT7Xl/HJFB7nJURmZE2SGn75429Q9Yni/ioAC 6759w7yr3yMmTiVotCAtFcnCMv/2qsXUUV3nGqqvyi5dE3ZcGTrzPw75uF4KuqD6LjXe vQEDmWs90CBR2lIPiTxi+2/IWU3DhG/apiZWaUblRji1+jUpYPcqNDd+VXnKaoWQxPlc A0FP9WfMRN09e8X5li9bNJwSoZ3a8eQCG2yiAYPGFXh1gN7/wXLMMsNHt77WJ/zyrikV gTRQ==
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=2KOC+LUiZS9yANP7OehDMtL9E04r5STlgFFoAzhN3dk=; b=II9ZaWiC6jzh67TPxB1gNFA09dQnPDTDqZMaZTdgIXhNt9pi7M+pd6tuzdO8nDcEDb nXVsUMPUTRXtv/3mg6LVJKY+ct6sVH/lZgj1Lzy+U09xy8oPbkGUZZsq1UQbLh8n0cAI ZTBDSbF4b2KXNwPoh6+tznEl88oAztNqwIa9C5bR6JXeeSbr8cVLlJwlQd7qh2E9026M /ZljdwQ083bBCqta9kKBOZME7bvA6AAk/SGuUwJyIuiU0cBjvJXAKVjHoT7mWq+FwKLa LHBIgux2UsJ07JQw1n4mBCVbOJQYKyoV/Xh/iZUkNhyXIKDF62vrUmNbziAXob5ZvmCK yDGg==
X-Gm-Message-State: AOAM533tx82c4tTYVMo1pWgUvG6dQq4bd7hQ5X6anL0nEVPZwVmE6QYp fkZUcJjeiPXxEQSfJrtaosBRksMNAXsmJLR3T08=
X-Google-Smtp-Source: ABdhPJxzrPJ81rFvKzsZYBwjk74rl+ebQLuMgzCgHPR6+n7p6MsRnxqIQuTR/u62Rd41szf6gbGKkXmpn3/AqsW6BSg=
X-Received: by 2002:a05:6e02:1313:: with SMTP id g19mr3152175ilr.123.1594885782948;  Thu, 16 Jul 2020 00:49:42 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>
In-Reply-To: <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>
From: Fabien Imbault 
Date: Thu, 16 Jul 2020 09:49:31 +0200
Message-ID: 
To: Justin Richer 
Cc: Mike Varley , "txauth@ietf.org" ,  Mike Jones ,  Dick Hardt 
Content-Type: multipart/alternative; boundary="0000000000008cd10905aa8a4884"
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 16 Jul 2020 07:49:46 -0000

--0000000000008cd10905aa8a4884
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1 on that.

We can then see it more as life cycle management of the client than
registration per say, and this comes with many benefits compared to the
current client_id.

Fabien

On Tue, Jul 14, 2020 at 9:32 PM Justin Richer  wrote:

> I not only agree with Mike Jones that =E2=80=9Cautomatic registration=E2=
=80=9D should be
> part of the process, but I would argue that that kind of model should be =
a
> default mode of operation. If you have an identifier that you can send to
> short-circuit that, great! But we should focus on having the capability o=
f
> inlining a lot of this information wherever possible. This is already the
> direction that the input proposals are heading.
>
> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope for th=
e protocol in
> general, and since both XYZ and Xauth have mechanisms that allow the clie=
nt
> to present a key and get back an identifier that it can use in the future
> we have something equivalent.
>
> But I think there=E2=80=99s a little more to it than that: Ultimately, I =
think we
> should question thinking in terms of =E2=80=9Cregistration=E2=80=9D, a mo=
del which has
> hampered the OAuth 2 model in a lot of use cases. For example, the
> federation draft Mike Jones references below hacks the =E2=80=9Cclient_id=
=E2=80=9D
> parameter and makes it point to a document that the AS has to fetch. This
> construct is done for two reasons: (1) Oauth requires a =E2=80=9Cclient_i=
d=E2=80=9D in the
> request and (2) it=E2=80=99s difficult to pass information by value to th=
e AS due
> to front-channel restrictions. Since we=E2=80=99re defining a new protoco=
l, we
> don=E2=80=99t need to hack that functionality into a =E2=80=9Cclient ID=
=E2=80=9D or equivalent and
> instead we can pass that information directly in the protocol. If we don=
=E2=80=99t
> assume that the client *has* to have a client ID equivalent, but it *can*
> have one in a set of defined circumstances, then I think we are in a much
> better spot. This is the reasoning for XYZ=E2=80=99s model of having clie=
nts
> identified by the key, and that key can potentially be passed by a
> reference identifier.
>
> I think all of the use cases that Mike Varley presents below are all vali=
d
> directions, with the caveat that we shouldn=E2=80=99t assume a client sho=
uld be
> presenting an ID at all steps. Mechanisms like software statements should
> be presentable apart from a client ID, as should on-device keys. We=E2=80=
=99re
> probably going to want extensions for device posture and other forms of
> attestation as well.
>
> This is one of the domains that I think we can clearly surpass OAuth 2=E2=
=80=99s
> flexibility and capabilities if we are willing to look past OAuth 2=E2=80=
=99s
> assumptions of what=E2=80=99s needed inline in the protocol.
>
>  =E2=80=94 Justin
>
> On Jul 14, 2020, at 1:54 PM, Mike Varley 
> wrote:
>
> Is client registration in scope for the protocol?
>
> A generic way of handling clients (via ID or Handle or Key or whatever) i=
s
> to have processing rule on the AS such as =E2=80=9Cif the AS recognizes t=
he client
> ID (and authentication of that client ID) then it may process the request
> on behalf of that client. If the AS does not recognize the client ID, it
> must treat this as a new client registration and evaluate any authorizati=
on
> evidence the client provides before enabling the client and mapping
> policies to that client=E2=80=9D (this means dynamic or automatic clients=
 need to
> provide additional assertions / software statements whatever to register
> their ID.
>
> Something like this allows for very flexible systems:
> System A can be unknown to the AS but can dynamically registered each tim=
e
> with an appropriate software statement
> System B can have a fairly stable client ID at the AS, but rotate that ID
> every month through automatic registration (with an assertion it got from
> the AS during a pre-registration for example)
> System C can pre-register with the AS for a client ID because it doesn=E2=
=80=99t
> deal with software statements etc=E2=80=A6
> =E2=80=A6
> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing clien=
t IDs because it
> will always just rely on the software statements.
>
> I think a client registration protocol that allows these scenarios would
> be very useful in GNAP, but hopefully avoiding having to define what
> =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
>
> Thanks,
>
> MV
>
> *From: *Txauth  on behalf of Mike Jones <
> Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
> *Date: *Tuesday, July 14, 2020 at 12:18 PM
> *To: *Dick Hardt , "txauth@ietf.org" <
> txauth@ietf.org>, Justin Richer 
> *Subject: *Re: [Txauth] Key handle vs client id & handle
>
> I agree that there are significant differences between statically and
> dynamically registered clients and that=E2=80=99s appropriate to be able =
to
> syntactically differentiate between them at runtime.  For one thing, the
> resource requirements at the authorization server can be very different.
>
> We should also be thinking about how to include what the OpenID Connect
> Federation spec
> https://openid.net/specs/openid-connect-federation-1_0.html calls
> =E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client encode a =
registration
> request reference in the client ID, so no static or dynamic registration
> even occurs.  See
> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.sectio=
n.9.1
> 
> .
>
>                                                        -- Mike
>
> *From:* Dick Hardt 
> *Sent:* Friday, July 10, 2020 1:17 PM
> *To:* txauth@ietf.org; Justin Richer ; Mike Jones <
> Michael.Jones@microsoft.com>
> *Subject:* Key handle vs client id & handle
>
> + Mike as he had interest in this topic
>
> My understanding is that an existing OAuth 2 client would use their
> current client id as their key handle, and a dynamic client (one that was
> not pre-registered) would be given a key handle by the AS.
>
> There are potentially some significant differences between a registered
> client, and a dynamic client to an AS.
>
> The AS is likely to know the identity of a registered client, and have
> different policies between the two types of clients. For example, a
> registered client may have access to a 'write" scope, while a dynamic
> client does not.
>
> The AS may have 100s or 1000s of registered clients, but a dynamic client
> may have 10Ms or 100Ms of instances, which may dictate separate storage
> services. Additionally, internal to the AS, which systems can write to th=
e
> registered client store is going to be different than the dynamic
> client store.
>
> In XYZ, subsequent calls to the AS, both registered clients and dynamic
> clients pass a key handle, so there is no easy way to differentiate betwe=
en
> the two.
>
> While the AS could embed semantics in the key handle identifier to
> indicate which identifiers are pre-registered vs dynamic, there are many
> cases where the AS does need to know the difference, so making the
> difference a feature of GNAP seems like a better path.
>
>
>
> 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 intend=
ed
> recipient, please contact the sender immediately, and permanently delete
> this email and its attachments.
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--0000000000008cd10905aa8a4884
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



--0000000000007bdfd805aa8decb5--


From nobody Thu Jul 16 05:37: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 8E4303A09E4 for ; Thu, 16 Jul 2020 05:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.631
X-Spam-Level: 
X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, 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 4ZJxdmr05_v2 for ; Thu, 16 Jul 2020 05:37:17 -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 02B503A0A7E for ; Thu, 16 Jul 2020 05:37:16 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d81 with ME id 3odE230054FMSmm03odE9o; Thu, 16 Jul 2020 14:37:15 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 16 Jul 2020 14:37:15 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt 
Cc: "txauth@ietf.org" 
References: <7c1f0439-42e4-9f7d-4dd2-e741f7cb57f2@free.fr> 
From: Denis 
Message-ID: <2201d382-c2f3-1496-b368-5b2caeb5eab5@free.fr>
Date: Thu, 16 Jul 2020 14:37: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
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------A0BEB5181878082A37BDACEF"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Registered Clients and Dynamic Clients
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, 16 Jul 2020 12:37:20 -0000

This is a multi-part message in MIME format.
--------------A0BEB5181878082A37BDACEF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Dick,

> On Wed, Jul 15, 2020 at 10:04 AM Denis  > wrote:
>
>     Hello Dick,
>
>     I am puzzled with the two following definitions in
>     draft-hardt-xauth-protocol-13 :
>
>     *Registered Client* - a Client 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.
>
>     [Denis]  I interpret the last sentence in the following way: A
>     Registered Client may be either an Application or a User.
>                  Is it correct ?
>
>
> No. A Registered Client MAY be interacting with a User, or it MAY not. 
> IE, a Registered Client may be a service.

It seems that what I call an Application is what you call a service. 
Usually a service may be supported by multiple servers,
so I get the impression that my terminology is better suited. If not, 
would you be able to explain ?

>           *Dynamic Client* - a Client that has not been previously
>     registered with the GS, and each instance will generate
>            it’s own asymmetric key pair so it can prove it is the same
>     instance of the Client on subsequent requests. The GS
>            MAY return a Dynamic Client a Client Handle for the Client
>     to identify itself in subsequent requests. A single-page
>            application with no active server component is an example
>     of a Dynamic Client. A Dynamic Client MUST be interacting
>            with a User.
>
>     [Denis] The draft does not include any other explanation for the
>     reason to support the so-called "Dynamic Clients".
>     While I can understand the value to use a temporary key pair for a
>     given RS, I can't understand the value for a GS
>                 to support unknown clients. If a GS knows nothing
>     about a so-called "Dynamic Client", then it will not be able to
>     deliver
>                 any user attribute into an access token to such client.
>
>
> More of an explanation of Dynamic Clients is a good call out, thanks!
>
> A Dynamic Client MUST be interacting with a User, as "trust" of the 
> Client is done by the User.
> A Single Page Application (SPA) or a mobile app are examples of 
> clients that cannot have a shared secret, but can generate and keep 
> secure their own key pair..
>
> As suggested in another thread, GNAP could support Clients that are 
> between these two extremes.
> Mike called out automatic registration per OpenID Connect Federation 
> as one example. Other options include a "software statement" passed 
> from the Client to the GS.
>
> We may want to revisit the terms "Registered Client" and "Dynamic 
> Client" as we broaden the mechanisms for Clients to "register" with a 
> GS, but these are the common cases today, so I picked them.

It seems that the intent is to support both a client registration 
protocol and a client operational protocol with the GS/AS.

Client registration may be done in many ways until the user is able to 
get a /both an identifier/ and private key
usable for an AS, and the AS is able to use /t//he same identifier/ and 
the corresponding public key to authenticate the user.

For example, draft-hardt-xauth-protocol-13 states: "The Client always 
uses a private asymmetric key to authenticate to the GS".

This should be the start of the story with an important observation: the 
client always uses /an identifier/, in particular to allow to gracefully 
change that private key.

One way to register and then to authenticate to a GS may simply be to 
use FIDO.FIDO is currently supported by many web browsers.

If/once we will be finished with the main topic, then why not address 
client registration but there is no strong adherence with our main topic.
Hence, client registration should not be on the list of our top priorities.

If we define one /or more/ client registration schemes, then this should 
better be in a separate and independent RFC.

Denis

>
> /Dick
>
>     Denis
>


--------------A0BEB5181878082A37BDACEF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Dick,

    


    

    

      
      
On Wed, Jul 15, 2020 at 10:04 AM Denis <denis.ietf@free.fr>
        wrote:

        

          

            

              
Hello Dick,

                  

                  I am puzzled with the two following definitions in
                  draft-hardt-xauth-protocol-13 :

                

                     
                  *Registered Client* - a Client 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.

                 

                  [Denis]  I interpret the last sentence in the
                  following way: A Registered Client may be either an
                  Application or a User. 

                               Is it correct ?

                

            

          

          


          

          
No. A Registered Client MAY be interacting with a User,
            or it MAY not. IE, a Registered Client may be a service.

        

      

    

    
It seems that what I call an Application is
        what you call a service. Usually a service may be supported by
        multiple servers, 

        so I get the impression that my terminology is better suited. If
        not, would you be able to explain ?

    

      

        

          
 

          

            

              
      *Dynamic Client* - a Client that
                  has not been previously registered with the GS, and
                  each instance will generate 

                         it’s own asymmetric key pair so it can prove it
                  is the same instance of the Client on subsequent
                  requests. The GS 

                         MAY return a Dynamic Client a Client Handle for
                  the Client to identify itself in subsequent requests.
                  A single-page 

                         application with no active server component is
                  an example of a Dynamic Client. A Dynamic Client MUST
                  be interacting 

                         with a User.

                  

                  [Denis] The draft does not include any other
                    explanation for the reason to support the so-called
                      "Dynamic Clients". 

                                  While I can understand
                  the value to use a temporary key pair for a given RS,
                  I can't understand the value for a GS 

                              to support unknown clients. If a GS knows
                  nothing about a so-called "Dynamic Client", then it
                  will not be able to deliver 

                              any user attribute into an access token to
                  such client.

            

          

          


          

          
More of an explanation of Dynamic Clients is a good call
            out, thanks!

          


          

          
A Dynamic Client MUST be interacting with a User, as
            "trust" of the Client is done by the User. 

            A Single Page Application (SPA) or a mobile app are examples
            of clients that cannot have a shared secret, but can
            generate and keep secure their own key pair.. 

          


          

          
As suggested in another thread, GNAP could support
            Clients that are between these two extremes. 

            Mike called out automatic registration per OpenID Connect
            Federation as one example. Other options include a "software
            statement" passed from the Client to the GS.

          


          

          
We may want to revisit the terms "Registered Client" and
            "Dynamic Client" as we broaden the mechanisms for Clients to
            "register" with a GS, but these are the common cases today,
            so I picked them.

        

      

    

    

      It seems that the intent is to support both a client registration
      protocol and a client operational protocol with the GS/AS. 

    
    
Client registration may be done in many ways
        until the user is able to get a both an identifier and
        private key 

        usable for an AS, and the AS is able to use the same
          identifier and the corresponding public key to
        authenticate the user.

    For example, draft-hardt-xauth-protocol-13
      states: "The Client always uses a private asymmetric key to
      authenticate to the GS".

    
    
This should be the start of the story with an
        important observation: the client always uses an identifier,
        in particular to allow to gracefully change that private key.

    
One way to register and then to authenticate
        to a GS may simply be to use FIDO.
        FIDO is currently supported by many web browsers.

        

        If/once we will be finished with the main topic, then why not
        address client registration but there is no strong adherence
        with our main topic.

        Hence, client registration should not be on the list of our top
        priorities.

    

    
If we define one or more client
        registration schemes, then this should better be in a separate
        and independent RFC.

      

    
Denis

        

      

    

      

        

          


          

          
/Dick

          


          

          
 

          

            

              
  

              
Denis

                

            

          

        

      

    

    


    

  


--------------A0BEB5181878082A37BDACEF--


From nobody Thu Jul 16 05:45: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 62BF03A08F4 for ; Thu, 16 Jul 2020 05:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.629
X-Spam-Level: 
X-Spam-Status: No, score=-0.629 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.267, NICE_REPLY_A=-0.001, 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 xRj5GaJ0516u for ; Thu, 16 Jul 2020 05:45:18 -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 4A12B3A0872 for ; Thu, 16 Jul 2020 05:45:17 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d81 with ME id 3olE2300e4FMSmm03olE12; Thu, 16 Jul 2020 14:45:15 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 16 Jul 2020 14:45:15 +0200
X-ME-IP: 86.238.65.197
To: Francis Pouatcha 
Cc: txauth@ietf.org, Dick Hardt 
References:       
From: Denis 
Message-ID: 
Date: Thu, 16 Jul 2020 14:45: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
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------6CE010C1B3F16B17732CD37E"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 16 Jul 2020 12:45:20 -0000

This is a multi-part message in MIME format.
--------------6CE010C1B3F16B17732CD37E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello  Francis,

The first two steps of your scenario are nice, in particular the second one:

    (2) Service Intent: In order to discover *authorization
    requirements*, the Client sends a service intent to the RS.

This means that the client first contacts the RS, instead of the GS.

However, the third step is missing to disclose to the client these 
"*authorization requirements*", in particular which AS(s),
it may contact, which attributes are requested and how/when/where the 
user consent is gathered.

Unless the scenario is mandating all the RSs to trust one and only one 
GS and the client to have a relationship with that GS,
the remaining steps of this scenario do not work.

Step (5) mandates the GS to know who the owner of a given RS is, and 
thus mandates the client to disclose to the GS the identity of the RS.
The consequence is the following : this scenario, /as well as the 
scenario described in draft-hardt-xauth-protocol-13/, allows the GS to 
act as Big Brother.

Denis

> Hello Fabian,
>
> On Thu, Jul 16, 2020 at 4:47 AM Fabien Imbault 
> > wrote:
>
>     Hi,
>
>     That's interesting, however the important logic is actually
>     implemented within (5). And so for the reader, it might be quite
>     difficult to understand what we're after (compared to oauth2 for
>     instance). So in my view, this kind of schema has its place, but
>     not at the start of the document where we should primarily be
>     concerned about explaining why someone should read the document..
>
>     It's also not easy to understand :
>     - why we sometimes use different labels between requests and
>     responses (for instance, 5 and 6)
>
> Will need support in drafting the correct terms. The main purpose of 
> this diagram is to help sharpen the definition of terms and verbs used 
> in the draft.
>
>     - sometimes we use "grant" and sometimes "authZ", and it doesn't
>     seem very clear what is the difference in use
>
> IMO: the granting is the process of given permission.
> - RO can grant his Consent to the User or Client
> - GS can turn the RO Grant into an AuthZ.
> - Client can use AuthZ to access a Resource.
>
>     A terminology section would be great to clarify.
>
> Yes. There is a terminology section in there. We need to bring the 
> wissing words into the list and sharpen those already there.
>
>
>     If I understand correctly your remark in 5, you think the
>     request/response scheme (as in XYZ) may be misleading.
>
> No. XYZ does IMO exactly  that. Just try to be more abstract for a 
> better description of the models.
>
>     On the contrary, I think it allows support rich interaction
>     scenarios (and especially the ones you describe) with greater
>     flexibility.
>
> Flexibility shall not be put ahead of formal correctness.
>
>     For instance, some would disagree with the assertion that the goal
>     is for the GS to gather consent (see discussion on putting that on
>     client side). A fixed interaction schema has the downside of not
>     permitting other setups.
>
> This discussion is the result of the lack of sharp terminology. Most 
> of the time mixing up gathering consent (the act) and the way consent 
> is gathered and transported from RO to GS (the interaction).
> /Francis
>
>
>     Fabien
>
>     On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha
>          > wrote:
>
>         Hello Dick,
>
>
>                         2. Abstract Protocol Flow
>                         I am missing an abstract protocol flow like
>                         the one defined in
>                         https://tools.ietf.org/html/rfc6749#section-1.2.
>
>
>                     That's an interesting point. GNAP also has
>                     identity claims, so the abstract flow is somewhat
>                     different (there is no Authorization Grant from
>                     the RO), and not all steps always happen. (there
>                     may not be steps (E) and (F) with a Resource Server)
>
>                     Would you elaborate on what you think would be
>                     useful here, that is not in the specific flows?
>
>                 A diagram that generalizes the steps, independently of
>                 interaction mode is essential for the reader's
>                 navigation of the rest of the document. This is
>                 what #section-1.2 of RFC6749 does. I hope we can
>                 produce a similar diagram.
>
>                 A subsection of
>                 https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>                 could be defined for this.
>
>
>             Interaction modes are one dimension where the steps could
>             be generalized, but some steps are optional. For example,
>             the User may not interact with the GS, and the GS may
>             interact with the RO. The Client may only want claims, and
>             there would be no step of the Client calling the RS.
>
>             A generalized diagram would need to include all optional
>             steps so that it did not mislead a reader into thinking
>             the diagram included all general steps, but it does not
>             seem that is what you are asking for as you wrote:
>
>             A subsection of
>             https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>             could be defined for this."
>
>             Perhaps you can share how you think the diagram would look?
>
>         find below my proposal of an abstract sequence diagram.
>
>         +----+  +------+  +---+  +---+  +---+
>         |User|  |Client|  |RS |  |GS |  |RO |
>         +----+  +------+  +---+  +-+-+  +-+-+
>           |(1) Service Request     |      |
>           |-------->|       |      |      |
>           |         |(2) Service Intent   |
>           |         |------>|      |      |
>           |         |(3) AuthZ Challenge  |
>           |         |<------|      |      |
>           |         |(4) AuthZ Request    |
>           |         |------------->|      |
>           |         |       |      |(5) Consent Request
>           |         |       |      |----->|
>           |         |       |      |(6) Grant Consent
>           |         |       |      |<-----|
>           |         |(7) Grant Access (Token)
>           |         |<-------------|      |
>           |         |(8) Service Request (Token)
>           |         +------>+      |      |
>           |         |(9) Service Response |
>           |         |<------|      |      |
>           |(10) Service Response   |      |
>           +<--------|       |      |      |
>           +         +       +      +      +
>
>         (1) Service Request: This is the service request sent by a
>         User to the Client. This can be a simple file read request or
>         even a complex payment initiation request.
>
>         (2) Service Intent: In order to discover authorization
>         requirements, the Client sends a service intent to the RS.
>
>         (3) AuthZ Challenge: The response to a service intent request
>         is generally an AuthZ Challenge. The content of this AuthZ
>         Challenge, can be an identification challenge, an AuthZ
>         exemption, or details on requested AuthZ. The content AuthZ
>         Challenge can be similar to the oAuth2 RAR.
>
>         (4) AuthZ Request : the Client sends an AuthZ Request to the
>         GS including the AuthZ Challenge. This request can be similar
>         to the oAuth PAR request.
>
>         (5) Requests Consent : GS sends consent request to RO.
>         Remark: The abstract protocol flow does not display a response
>         of the request (4) to the Client. This is IMO a general
>         misunderstanding. This protocol wants the GS to collect a
>         consent from the RO.
>         - In the case of a "redirect interaction", GS will use
>         transport infrastructure provided by the Client to instruct
>         the User to send the RO to the GS (in most cases, user and RO
>         are identical).
>         - In the case of a "decoupled interaction", GS will directly
>         contact RO and collect consent in a direct interaction with
>         the RO (see CIBA).
>         - In the case of an "embedded interaction", GS will allow the
>         Client to directly collect the Consent of the RO in a direct
>         interaction with the User.
>
>         (6) Grant Consent : RO return a Consent Grant to GS.
>
>         (7) Grant Access : GS produces the corresponding access token
>         and returns it to Client.
>
>         (8) Service Request : Client uses the access token to send the
>         service request to RS.
>
>         (9) and (10) are self explaining....
>
>         One of our upcoming exercises will be to challenge this
>         abstract protocol flow with existing interactions (and if
>         possible associated use cases) to see if we are missing
>         something. After an agreement on the abstract protocol flow we
>         can make sure each interaction provides a mapping to step 1 to 10.
>
>         I will strip the rest of the post here. And bring further
>         responses in separate mails.
>
>         Best regards.
>         /Francis
>
>             ᐧ
>
>         -- 
>         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/
>


--------------6CE010C1B3F16B17732CD37E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello  Francis,

      

    

    
The first two steps of your scenario
      are nice, in particular the second one:

    

      
(2) Service Intent: In order to
        discover authorization requirements, the Client sends a
        service intent to the RS.

    

    
This means that the client first
      contacts the RS, instead of the GS.

    


    

    
However, the third step is missing to
      disclose to the client these "authorization requirements",
      in particular which AS(s), 

      it may contact, which attributes are requested and how/when/where
      the user consent is gathered.

      

      Unless the scenario is mandating all the RSs to trust one and only
      one GS and the client to have a relationship with that GS, 

      the remaining steps of this scenario do not work.

    

    


    

    
Step (5) mandates the GS to know who
      the owner of a given RS is, and thus mandates the client to
      disclose to the GS the identity of the RS.

    
The consequence is the following : this
      scenario, as well as the scenario described in
        draft-hardt-xauth-protocol-13, allows the GS to act as Big
      Brother. 

    

    


    

    
Denis

    

    

    

      
      

        
Hello Fabian,

        

        

          
On Thu, Jul 16, 2020 at 4:47
            AM Fabien Imbault <fabien.imbault@gmail.com>
            wrote:

          

          

            
Hi, 
              


              

              
That's interesting, however the important logic is
                actually implemented within (5). And so for the reader,
                it might be quite difficult to understand what we're
                after (compared to oauth2 for instance). So in my view,
                this kind of schema has its place, but not at the start
                of the document where we should primarily be concerned
                about explaining why someone should read the document..

              


              

              
It's also not easy to understand : 

              
- why we sometimes use different labels between
                requests and responses (for instance, 5 and 6)

            

          

          
Will need support in drafting the correct terms. The main
            purpose of this diagram is to help sharpen the definition of
            terms and verbs used in the draft.

          


          

          

            

              
- sometimes we use "grant" and sometimes "authZ", and
                it doesn't seem very clear what is the difference in use

            

          

          
IMO: the granting is the process of given permission.

          
- RO can grant his Consent to the User or Client

          
- GS can turn the RO Grant into an AuthZ.

          
- Client can use AuthZ to access a Resource.

          


          

          

            

              
A terminology section would be great to clarify.

            

          

          
Yes. There is a terminology section in there. We need to
            bring the wissing words into the list and sharpen those
            already there. 

          

            

              


              

              
If I understand correctly your remark in 5, you think
                the request/response scheme (as in XYZ) may be
                misleading. 

            

          

          
No. XYZ does IMO exactly  that. Just try to be more
            abstract for a better description of the models.

          
 

          

            

              
On the contrary, I think it allows support rich
                interaction scenarios (and especially the ones you
                describe) with greater flexibility. 

            

          

          
Flexibility shall not be put ahead of formal correctness.

          
 

          

            

              
For instance, some would disagree with the assertion
                that the goal is for the GS to gather consent (see
                discussion on putting that on client side). A fixed
                interaction schema has the downside of not permitting
                other setups.

            

          

          
This discussion is the result of the lack of sharp
            terminology. Most of the time mixing up gathering consent
            (the act) and the way consent is gathered and transported
            from RO to GS (the interaction).

          
/Francis

          


          

          

            

              


              

              
Fabien

            

            

            

              
On Thu, Jul 16, 2020 at
                5:28 AM Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>
                wrote:

              

              

                

                  
Hello Dick,
                    


                      

                  

                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      
 

                                      

                                        

                                          

                                            

                                              


                                                

                                              
2.
                                                  Abstract Protocol Flow

                                              

                                                
I
                                                    am missing an
                                                    abstract protocol
                                                    flow like the one
                                                    defined in https://tools.ietf.org/html/rfc6749#section-1.2.

                                              

                                            

                                          

                                        

                                      

                                      


                                        

                                      
That's
                                          an interesting point. GNAP
                                          also has identity claims, so
                                          the abstract flow is somewhat
                                          different (there is no
                                          Authorization Grant from the
                                          RO), and not all steps always
                                          happen. (there may not be
                                          steps (E) and (F) with a
                                          Resource Server)

                                      


                                        

                                      
Would
                                          you elaborate on what you
                                          think would be useful here,
                                          that is not in the specific
                                          flows?

                                    

                                  

                                

                                
A diagram
                                    that generalizes the steps,
                                    independently of interaction mode is
                                    essential for the reader's
                                    navigation of the rest of the
                                    document. This is what #section-1.2
                                    of RFC6749 does. I hope we can
                                    produce a similar diagram.

                                


                                  

                                
                              

                            

                          

                          


                            

                          
Interaction modes
                              are one dimension where the steps could be
                              generalized, but some steps are optional.
                              For example, the User may not interact
                              with the GS, and the GS may interact with
                              the RO. The Client may only want claims,
                              and there would be no step of the Client
                              calling the RS.

                          


                            

                          
A generalized
                              diagram would need to include all optional
                              steps so that it did not mislead a reader
                              into thinking the diagram included all
                              general steps, but it does not seem that
                              is what you are asking for as you wrote:

                          


                            

                          
A subsection of https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
                              could be defined for this."

                            

                          


                            

                          
Perhaps you can
                              share how you think the diagram would
                              look?

                        

                      

                    

                    
find below my proposal
                        of an abstract sequence diagram.

                    


                      

                    
+----+  +------+  +---+
                         +---+  +---+

                        |User|  |Client|  |RS |  |GS |  |RO |

                        +----+  +------+  +---+  +-+-+  +-+-+

                          |(1) Service Request     |      |

                          |-------->|       |      |      |

                          |         |(2) Service Intent   |

                          |         |------>|      |      |

                          |         |(3) AuthZ Challenge  |

                          |         |<------|      |      |

                          |         |(4) AuthZ Request    |

                          |         |------------->|      |

                          |         |       |      |(5) Consent Request

                          |         |       |      |----->|

                          |         |       |      |(6) Grant Consent

                          |         |       |      |<-----|

                          |         |(7) Grant Access (Token)

                          |         |<-------------|      |

                          |         |(8) Service Request (Token)

                          |         +------>+      |      |

                          |         |(9) Service Response |

                          |         |<------|      |      |

                          |(10) Service Response   |      |

                          +<--------|       |      |      |

                          +         +       +      +      +

                      

                    


                      

                    
(1) Service Request:
                        This is the service request sent by a User to
                        the Client. This can be a simple file read
                        request or even a complex payment initiation
                        request.

                    


                      

                    
(2) Service Intent: In
                        order to discover authorization requirements,
                        the Client sends a service intent to the RS.

                    


                      

                    
(3) AuthZ Challenge: The
                        response to a service intent request is
                        generally an AuthZ Challenge. The content of
                        this AuthZ Challenge, can be an identification
                        challenge, an AuthZ exemption, or details on
                        requested AuthZ. The content AuthZ Challenge can
                        be similar to the oAuth2 RAR.

                    


                      

                    
(4) AuthZ Request : the
                        Client sends an AuthZ Request to the GS
                        including the AuthZ Challenge. This request can
                        be similar to the oAuth PAR request.

                    


                      

                    
(5) Requests Consent :
                        GS sends consent request to RO. 

                    
Remark: The abstract
                        protocol flow does not display a response of the
                        request (4) to the Client. This is IMO a general
                        misunderstanding. This protocol wants the GS to
                        collect a consent from the RO. 

                    
- In the case of a
                        "redirect interaction", GS will use transport
                        infrastructure provided by the Client to
                        instruct the User to send the RO to the GS (in
                        most cases, user and RO are identical).

                    
- In the case of a
                        "decoupled interaction", GS will directly
                        contact RO and collect consent in a direct
                        interaction with the RO (see CIBA).

                    
- In the case of an
                        "embedded interaction", GS will allow the Client
                        to directly collect the Consent of the RO in a
                        direct interaction with the User.

                    


                      

                    
(6) Grant Consent : RO
                        return a Consent Grant to GS.

                    


                      

                    
(7) Grant Access : GS
                        produces the corresponding access token and
                        returns it to Client.

                    


                      

                    
(8) Service Request :
                        Client uses the access token to send the service
                        request to RS.

                    


                      

                    
(9) and (10) are self
                        explaining....

                    


                      

                    
One of our
                        upcoming exercises will be to challenge this
                        abstract protocol flow with existing
                        interactions (and if possible associated use
                        cases) to see if we are missing something. After
                        an agreement on the abstract protocol flow we
                        can make sure each interaction provides a
                        mapping to step 1 to 10.

                    


                      

                    
I will
                        strip the rest of the post here. And bring
                        further responses in separate mails.

                    


                      

                    
Best
                        regards.

                    
/Francis  

                    

                      

                        

                          

                          

                        

                      

                      
ᐧ

                    

                  

                  -- 

                  
                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    
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

                          
                        

                      

                    

                  

                

              

            

          

        

      

      

      

    

    


    

  


--------------6CE010C1B3F16B17732CD37E--


From nobody Thu Jul 16 06:59: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 CD67D3A085A for ; Thu, 16 Jul 2020 06:59:39 -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 14OPz6v1IwXy for ; Thu, 16 Jul 2020 06:59:37 -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 B17EE3A086B for ; Thu, 16 Jul 2020 06:59:36 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id z13so7179463wrw.5 for ; Thu, 16 Jul 2020 06:59:36 -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=lu6Gc9PNJ4C7uY1LkBCMf4AiNmGBtE+4zieZlzNPUGM=; b=aKVfd25JuC2BpzSFPc4QHGso76JbfUAk9C4Iyrylg1TCPQgX9TmFQQ8iIFUx6VcDGK Gfp31aKBUUn4P/5zfdAQ3BQrL+tEpyJ92YIp7sK5UgdHjHwbBo58sWgcdeyhTftgAigl BPIVFty6QMP5ts4UaNH2B/oTrN17dtoRhwueM=
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=lu6Gc9PNJ4C7uY1LkBCMf4AiNmGBtE+4zieZlzNPUGM=; b=lTHwUBMpyCzZwfFbathYCJrCpc32bRpO2lJwTmi189IaW8B4y4XNvzvp1hDLyinI6k W/b1aB1tj4yF9zy8OQ5U21Kkrqmu4TRKE7koATo0rr9xbOicn2Ss1zh/ucw3VetogLVw ZysU86m0kN24VZoQUmp7055t5qHEcu7ZCPF+ELQJM8n0hRIKXSJKtmnkbDMn29prE1+r ZjSAqQrwAWjmlgzRQ9j2sc6cPtx3jSpmXRWSJ3v69Zs7B8z4eNomBUq1/RykmAxwm7o+ 7AWM3H4Bv3n8hZ9T/f2vN9Ebp5+AvQrZsI+I7z08MBNW+VxRZwm1tnSIunOFSqOKbWSm kZOQ==
X-Gm-Message-State: AOAM532m80xK7zufimYytJFkLQaH+EfdiebDtti7i5HbNTKB4CNCXOZN qocw/E8DWjQh2XKovAK658iDy5x3mnR15cuQ8tBTtw==
X-Google-Smtp-Source: ABdhPJze5X2lJcrx2HniV56Ht4BLqcrcjIM1//LSx2++ieo5l4O+LCIx9+YjfPvCjvsduBpCuiuvgmqVSGCMishkeDU=
X-Received: by 2002:a5d:4a84:: with SMTP id o4mr5350745wrq.104.1594907974910;  Thu, 16 Jul 2020 06:59:34 -0700 (PDT)
MIME-Version: 1.0
References:        
In-Reply-To: 
From: Francis Pouatcha 
Date: Thu, 16 Jul 2020 09:59:23 -0400
Message-ID: 
To: Denis 
Cc: txauth@ietf.org, Dick Hardt 
Content-Type: multipart/alternative; boundary="0000000000004b5c0605aa8f7318"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 16 Jul 2020 13:59:40 -0000

--0000000000004b5c0605aa8f7318
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Denis,

On Thu, Jul 16, 2020 at 8:45 AM Denis  wrote:

> Hello  Francis,
>
> The first two steps of your scenario are nice, in particular the second
> one:
>
> (2) Service Intent: In order to discover *authorization requirements*,
> the Client sends a service intent to the RS.
>
> This means that the client first contacts the RS, instead of the GS.
>

> However, the third step is missing to disclose to the client these "*auth=
orization
> requirements*", in particular which AS(s),
> it may contact, which attributes are requested and how/when/where the use=
r
> consent is gathered.
>
The response (2) AuthZ Challenge carries the reference to the GS. Mean the
resource server instructs the Client on which GS to approach for
authorization.


> Unless the scenario is mandating all the RSs to trust one and only one GS
> and the client to have a relationship with that GS,
> the remaining steps of this scenario do not work.
>
Can you elaborate why it shall not work for many GSs?


>

> Step (5) mandates the GS to know who the owner of a given RS is
>
Step (5) mandates the GS to know the RO, as owner of the target Resource,
but not the RS (Resource Server). Resource not-equals RS.

, and thus mandates the client to disclose to the GS the identity of the
> RS.
>
No. Here there is no requirement from GS to know the RS.


> The consequence is the following : this scenario, *as well as the
> scenario described in draft-hardt-xauth-protocol-13*, allows the GS to
> act as Big Brother.
>
No.

RS will find a way to validate AuthZ produced by any GS. Means RS must
trust that very GS or trust somebody that trusts that very GS (e.g. CA).
GS must not know the RS but must understand the Resource and trust the
Resource Owner, so that GS can validate the RO Grant.

/Francis

>
> Denis
>
> Hello Fabian,
>
> On Thu, Jul 16, 2020 at 4:47 AM Fabien Imbault 
> wrote:
>
>> Hi,
>>
>> That's interesting, however the important logic is actually implemented
>> within (5). And so for the reader, it might be quite difficult to
>> understand what we're after (compared to oauth2 for instance). So in my
>> view, this kind of schema has its place, but not at the start of the
>> document where we should primarily be concerned about explaining why
>> someone should read the document..
>>
>> It's also not easy to understand :
>> - why we sometimes use different labels between requests and responses
>> (for instance, 5 and 6)
>>
> Will need support in drafting the correct terms. The main purpose of this
> diagram is to help sharpen the definition of terms and verbs used in the
> draft.
>
> - sometimes we use "grant" and sometimes "authZ", and it doesn't seem ver=
y
>> clear what is the difference in use
>>
> IMO: the granting is the process of given permission.
> - RO can grant his Consent to the User or Client
> - GS can turn the RO Grant into an AuthZ.
> - Client can use AuthZ to access a Resource.
>
> A terminology section would be great to clarify.
>>
> Yes. There is a terminology section in there. We need to bring the wissin=
g
> words into the list and sharpen those already there.
>
>>
>> If I understand correctly your remark in 5, you think the
>> request/response scheme (as in XYZ) may be misleading.
>>
> No. XYZ does IMO exactly  that. Just try to be more abstract for a better
> description of the models.
>
>
>> On the contrary, I think it allows support rich interaction scenarios
>> (and especially the ones you describe) with greater flexibility.
>>
> Flexibility shall not be put ahead of formal correctness.
>
>
>> For instance, some would disagree with the assertion that the goal is fo=
r
>> the GS to gather consent (see discussion on putting that on client side)=
. A
>> fixed interaction schema has the downside of not permitting other setups=
.
>>
> This discussion is the result of the lack of sharp terminology. Most of
> the time mixing up gathering consent (the act) and the way consent is
> gathered and transported from RO to GS (the interaction).
> /Francis
>
>
>> Fabien
>>
>> On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha > 40adorsys.de@dmarc.ietf.org> wrote:
>>
>>> Hello Dick,
>>>
>>>
>>>>>>
>>>>>>>
>>>>>>> 2. Abstract Protocol Flow
>>>>>>> I am missing an abstract protocol flow like the one defined in
>>>>>>> https://tools.ietf.org/html/rfc6749#section-1.2.
>>>>>>>
>>>>>>
>>>>>> That's an interesting point. GNAP also has identity claims, so the
>>>>>> abstract flow is somewhat different (there is no Authorization Grant=
 from
>>>>>> the RO), and not all steps always happen. (there may not be steps (E=
) and
>>>>>> (F) with a Resource Server)
>>>>>>
>>>>>> Would you elaborate on what you think would be useful here, that is
>>>>>> not in the specific flows?
>>>>>>
>>>>> A diagram that generalizes the steps, independently of interaction
>>>>> mode is essential for the reader's navigation of the rest of the
>>>>> document. This is what #section-1.2 of RFC6749 does. I hope we can pr=
oduce
>>>>> a similar diagram.
>>>>>
>>>>> A subsection of
>>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>>>> could be defined for this.
>>>>>
>>>>
>>>> Interaction modes are one dimension where the steps could be
>>>> generalized, but some steps are optional. For example, the User may no=
t
>>>> interact with the GS, and the GS may interact with the RO. The Client =
may
>>>> only want claims, and there would be no step of the Client calling the=
 RS.
>>>>
>>>> A generalized diagram would need to include all optional steps so that
>>>> it did not mislead a reader into thinking the diagram included all gen=
eral
>>>> steps, but it does not seem that is what you are asking for as you wro=
te:
>>>>
>>>> A subsection of
>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>>> could be defined for this."
>>>>
>>>> Perhaps you can share how you think the diagram would look?
>>>>
>>> find below my proposal of an abstract sequence diagram.
>>>
>>> +----+  +------+  +---+  +---+  +---+
>>> |User|  |Client|  |RS |  |GS |  |RO |
>>> +----+  +------+  +---+  +-+-+  +-+-+
>>>   |(1) Service Request     |      |
>>>   |-------->|       |      |      |
>>>   |         |(2) Service Intent   |
>>>   |         |------>|      |      |
>>>   |         |(3) AuthZ Challenge  |
>>>   |         |<------|      |      |
>>>   |         |(4) AuthZ Request    |
>>>   |         |------------->|      |
>>>   |         |       |      |(5) Consent Request
>>>   |         |       |      |----->|
>>>   |         |       |      |(6) Grant Consent
>>>   |         |       |      |<-----|
>>>   |         |(7) Grant Access (Token)
>>>   |         |<-------------|      |
>>>   |         |(8) Service Request (Token)
>>>   |         +------>+      |      |
>>>   |         |(9) Service Response |
>>>   |         |<------|      |      |
>>>   |(10) Service Response   |      |
>>>   +<--------|       |      |      |
>>>   +         +       +      +      +
>>>
>>> (1) Service Request: This is the service request sent by a User to the
>>> Client. This can be a simple file read request or even a complex paymen=
t
>>> initiation request.
>>>
>>> (2) Service Intent: In order to discover authorization requirements, th=
e
>>> Client sends a service intent to the RS.
>>>
>>> (3) AuthZ Challenge: The response to a service intent request is
>>> generally an AuthZ Challenge. The content of this AuthZ Challenge, can =
be
>>> an identification challenge, an AuthZ exemption, or details on requeste=
d
>>> AuthZ. The content AuthZ Challenge can be similar to the oAuth2 RAR.
>>>
>>> (4) AuthZ Request : the Client sends an AuthZ Request to the GS
>>> including the AuthZ Challenge. This request can be similar to the oAuth=
 PAR
>>> request.
>>>
>>> (5) Requests Consent : GS sends consent request to RO.
>>> Remark: The abstract protocol flow does not display a response of the
>>> request (4) to the Client. This is IMO a general misunderstanding. This
>>> protocol wants the GS to collect a consent from the RO.
>>> - In the case of a "redirect interaction", GS will use transport
>>> infrastructure provided by the Client to instruct the User to send the =
RO
>>> to the GS (in most cases, user and RO are identical).
>>> - In the case of a "decoupled interaction", GS will directly contact RO
>>> and collect consent in a direct interaction with the RO (see CIBA).
>>> - In the case of an "embedded interaction", GS will allow the Client to
>>> directly collect the Consent of the RO in a direct interaction with the
>>> User.
>>>
>>> (6) Grant Consent : RO return a Consent Grant to GS.
>>>
>>> (7) Grant Access : GS produces the corresponding access token and
>>> returns it to Client.
>>>
>>> (8) Service Request : Client uses the access token to send the service
>>> request to RS.
>>>
>>> (9) and (10) are self explaining....
>>>
>>> One of our upcoming exercises will be to challenge this abstract
>>> protocol flow with existing interactions (and if possible associated us=
e
>>> cases) to see if we are missing something. After an agreement on the
>>> abstract protocol flow we can make sure each interaction provides a map=
ping
>>> to step 1 to 10.
>>>
>>> I will strip the rest of the post here. And bring further responses in
>>> separate mails.
>>>
>>> Best regards.
>>> /Francis
>>>
>>>> =E1=90=A7
>>>>
>>> --
>>> 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/

--0000000000004b5c0605aa8f7318
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Denis,

On Thu, Jul 16, 2020 at 8:45 =
AM Denis <denis.ietf@free.fr&g=
t; wrote:

 =20
   =20
 =20
  

    
Hello=C2=A0 Francis,

      

    

    
The first two steps of your scenario
      are nice, in particular the second one:

    

      
(2) Service Intent: In order to
        discover authorization requirements, the Client sends a
        service intent to the RS.

    

    
This means that the client first
      contacts the RS, instead of the GS.=C2=A0

    


    

    
However, the third step is missing to
      disclose to the client these "authorization requirements&=
quot;,
      in particular which AS(s), 

      it may contact, which attributes are requested and how/when/where
      the user consent is gathered.
The re=
sponse (2) AuthZ Challenge carries the reference to the GS. Mean the resour=
ce server instructs the Client on which GS to approach for authorization.=
=C2=A0

=
=C2=A0

    

    


    

    
Step (5) mandates the GS to know who
      the owner of a given RS is
Step (5) mand=
ates the GS to know the RO, as owner of the target Resource, but not the RS=
 (Resource Server). Resource not-equals=C2=A0RS.

, and thus mandates t=
he client to
      disclose to the GS the identity of the RS.=C2=A0
No. Here there is no requirement from GS to know the RS.
=C2=A0

    
The consequence is the following : this
      scenario, as well as the scenario described in
        draft-hardt-xauth-protocol-13, allows the GS to act as Big
      Brother. 
No.=C2=A0

RS will find a way to validate AuthZ produced by any GS. Means RS =
must trust that very GS or trust somebody=C2=A0that trusts that very GS (e.=
g. CA).
GS must not know the RS but must understand the Resource =
and trust the Resource Owner, so that GS can validate the RO Grant.

/Francis

    

    


    

    
Denis

    

    

    

     =20
      

        
Hello Fabian,

        

        

          
On Thu, Jul 16, 2020 at 4:4=
7
            AM Fabien Imbault <fabien.imbault@gmail.com>
            wrote:

          

          

            
Hi,=C2=A0
              


              

              
That's interesting, however the important logic is
                actually implemented within (5). And so for the reader,
                it might be quite difficult to understand what we're
                after (compared to oauth2 for instance). So in my view,
                this kind of schema has its place, but not at the start
                of the document where we should primarily be concerned
                about explaining why someone should read the document..
              


              

              
It's also not easy to understand :=C2=A0

              
- why we sometimes use different labels between
                requests and responses (for instance, 5 and 6)

            

          

          
Will need support in drafting the correct terms. The main
            purpose of this diagram=C2=A0is to help sharpen the definition =
of
            terms and verbs used in the draft.

          


          

          

            

              
- sometimes we use "grant" and sometimes "=
;authZ", and
                it doesn't seem very clear what is the difference in us=
e

            

          

          
IMO: the granting is the process of given permission.

          
- RO can grant his Consent to the User or Client

          
- GS can turn the RO Grant into an AuthZ.

          
- Client can use AuthZ to access a Resource.

          


          

          

            

              
A terminology section would be great to clarify.

            

          

          
Yes. There is a terminology section in there. We need to
            bring the wissing words into the list and sharpen those
            already there.=C2=A0

          

            

              


              

              
If I understand correctly your remark in 5, you think
                the request/response scheme (as in XYZ) may be
                misleading.=C2=A0

            

          

          
No. XYZ does IMO exactly=C2=A0 that. Just try to be more
            abstract for a better description of the models.

          
=C2=A0

          

            

              
On the contrary, I think it allows support rich
                interaction scenarios (and especially the ones you
                describe) with greater flexibility. 

            

          

          
Flexibility shall not be put ahead of formal correctness.
          
=C2=A0

          

            

              
For instance, some would disagree with the assertion
                that the goal is for the GS to gather consent (see
                discussion on putting that on client side). A fixed
                interaction schema has the downside of not permitting
                other setups.

            

          

          
This discussion is the result of the lack of sharp
            terminology. Most of the time mixing up gathering consent
            (the act) and the way consent is gathered and transported
            from RO to GS (the interaction).

          
/Francis

          


          

          

            

              


              

              
Fabien

            

            

            

              
On Thu, Jul 16, 2020 at
                5:28 AM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org>=
;
                wrote:

              

              

                

                  
Hello Dick,
                    


                      

                  

                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      
=C2=A0<=
/font>

                                      

                                        

                                          

                                            

                                              


                                                

                                              
2.
                                                  Abstract Protocol Flow

                                              

                                                
I
                                                    am missing an
                                                    abstract protocol
                                                    flow like the one
                                                    defined in https://t=
ools.ietf.org/html/rfc6749#section-1.2.

                                              

                                            

                                          

                                        

                                      

                                      


                                        

                                      
That=
9;s
                                          an interesting point. GNAP
                                          also has identity claims, so
                                          the abstract flow is somewhat
                                          different (there is no
                                          Authorization Grant from the
                                          RO), and not all steps always
                                          happen. (there may not be
                                          steps (E) and (F) with a
                                          Resource Server)

                                      


                                        

                                      
Would
                                          you elaborate on what you
                                          think would be useful here,
                                          that is not in the specific
                                          flows?

                                    

                                  

                                

                                
A diagram
                                    that generalizes the steps,
                                    independently of interaction mode is
                                    essential for the reader's
                                    navigation of the rest of the
                                    document.=C2=A0This is what=C2=A0#secti=
on-1.2
                                    of RFC6749 does. I hope we can
                                    produce a similar diagram.

                                


                                  

                                
A subsection
                                    of=C2=A0https:=
//tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
                                    could be defined for this.

                              

                            

                          

                          


                            

                          
Interaction modes
                              are one dimension where the steps could be
                              generalized, but some steps are optional.
                              For example, the User may not interact
                              with the GS, and the GS may interact with
                              the RO. The Client may only want claims,
                              and there would be no step of the Client
                              calling the RS.

                          


                            

                          
A generalized
                              diagram would need to include all optional
                              steps so that it did not mislead a reader
                              into thinking the diagram included all
                              general steps, but it does not seem that
                              is what you are asking for as you wrote:

                          


                            

                          
A subsection of=C2=
=A0https://tools.ietf.org/html/draft-hardt-xauth-p=
rotocol-12#section-1.1
                              could be defined for this."

                            

                          


                            

                          
Perhaps you can
                              share how you think the diagram would
                              look?

                        

                      

                    

                    
find below my proposal
                        of an abstract sequence diagram.

                    


                      

                    
+----+ =C2=A0+------+ =C2=
=A0+---+
                        =C2=A0+---+ =C2=A0+---+

                        |User| =C2=A0|Client| =C2=A0|RS | =C2=A0|GS | =C2=
=A0|RO |

                        +----+ =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 |(2) Service I=
ntent =C2=A0 |

                        =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =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) AuthZ Cha=
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 |(4) AuthZ Req=
uest =C2=A0 =C2=A0|

                        =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |-------------=
>| =C2=A0 =C2=A0 =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) Consent 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|(6) Grant 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 |(7) Grant Acc=
ess (Token)

                        =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<---------=
----| =C2=A0 =C2=A0 =C2=A0|

                        =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(8) Service R=
equest (Token)

                        =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 +------>+ =
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|

                        =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(9) Service R=
esponse |

                        =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<------| =
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|

                        =C2=A0 |(10) Service Response =C2=A0 | =C2=A0 =C2=
=A0 =C2=A0|

                        =C2=A0 +<--------| =C2=A0 =C2=A0 =C2=A0 | =C2=A0=
 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|

                        =C2=A0 + =C2=A0 =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) Service Request:
                        This is the service request sent by a User to
                        the Client. This can be a simple file read
                        request or even a complex payment initiation
                        request.

                    


                      

                    
(2) Service Intent: In
                        order to discover authorization requirements,
                        the Client sends a service intent to the RS.=


                    


                      

                    
(3) AuthZ Challenge: The
                        response to a service intent request is
                        generally an AuthZ Challenge. The content of
                        this AuthZ Challenge, can be an identification
                        challenge, an AuthZ exemption, or details on
                        requested AuthZ. The content AuthZ Challenge can
                        be similar to the oAuth2 RAR.

                    


                      

                    
(4) AuthZ Request : the
                        Client sends an AuthZ Request to the GS
                        including the AuthZ Challenge. This request can
                        be similar to the oAuth PAR request.

                    


                      

                    
(5) Requests Consent :
                        GS sends consent request to RO.=C2=A0

                    
Remark: The abstract
                        protocol flow does not display a response of the
                        request (4) to the Client. This is IMO a general
                        misunderstanding. This protocol wants the GS to
                        collect a consent from the RO.=C2=A0

                    
- In the case of a
                        "redirect interaction", GS will use trans=
port
                        infrastructure provided by the Client to
                        instruct the User to send the RO to the GS (in
                        most cases, user and RO are identical).
                    
- In the case of a
                        "decoupled interaction", GS will directly
                        contact RO and collect consent in a direct
                        interaction with the RO (see CIBA).

                    
- In the case of an
                        "embedded interaction", GS will allow the=
 Client
                        to directly collect the Consent of the RO in a
                        direct interaction with the User.

                    


                      

                    
(6) Grant Consent : RO
                        return a Consent Grant to GS.

                    


                      

                    
(7) Grant Access : GS
                        produces the corresponding access token and
                        returns it to Client.

                    


                      

                    
(8) Service Request :
                        Client uses the access token to send the service
                        request to RS.

                    


                      

                    
(9) and (10) are self
                        explaining....

                    


                      

                    
One of our
                        upcoming=C2=A0exercises will be to challenge this
                        abstract protocol flow with existing
                        interactions=C2=A0(and if possible associated use
                        cases) to see if we are missing something. After
                        an agreement on the abstract protocol flow we
                        can make sure each interaction provides a
                        mapping to step 1 to 10.

                    


                      

                    
I will
                        strip the rest of the post here. And bring
                        further responses in separate mails.

                    


                      

                    
Best
                        regards.

                    
/Francis=C2=
=A0=C2=A0

                    

                      

                        

                          

                          

                        

                      

                      
3D""=E1=90=A7

                    

                  

                  -- 

                  
                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    
Francis
                                        Pouatcha

                                    
Co-Founde=
r
                                        and Technical Lead

                                    
adorsys
                                        GmbH & Co. KG

                                    
                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

                -- 

                Txauth mailing list

                Txauth=
@ietf.org

                https://www.ietf.org/mailman/listinfo/tx=
auth

              

            

          

        

        

        


        

        -- 

        

          

            

              

                

                  

                    

                      

                        

                          
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/
+1 on that.

We can then see it more as =
life cycle management of the client than registration per say, and this com=
es with many benefits compared to the current client_id.

Fabien

On Tue, Jul 14, 2020 at 9:32 PM Justin Richer <jricher@mit.edu> wrote:
I not only agree with Mike Jones that =E2=80=9Cautomatic registr=
ation=E2=80=9D should be part of the process, but I would argue that that k=
ind of model should be a default mode of operation. If you have an identifi=
er that you can send to short-circuit that, great! But we should focus on h=
aving the capability of inlining a lot of this information wherever possibl=
e. This is already the direction that the input proposals are heading.
=

So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in=
 scope for the protocol in general, and since both XYZ and Xauth have mecha=
nisms that allow the client to present a key and get back an identifier tha=
t it can use in the future we have something equivalent.=C2=A0
But I think there=E2=80=99s a little more to it than that: Ult=
imately, I think we should question thinking in terms of =E2=80=9Cregistrat=
ion=E2=80=9D, a model which has hampered the OAuth 2 model in a lot of use =
cases. For example, the federation draft Mike Jones references below hacks =
the =E2=80=9Cclient_id=E2=80=9D parameter and makes it point to a document =
that the AS has to fetch. This construct is done for two reasons: (1) Oauth=
 requires a =E2=80=9Cclient_id=E2=80=9D in the request and (2) it=E2=80=99s=
 difficult to pass information by value to the AS due to front-channel rest=
rictions. Since we=E2=80=99re defining a new protocol, we don=E2=80=99t nee=
d to hack that functionality into a =E2=80=9Cclient ID=E2=80=9D or equivale=
nt and instead we can pass that information directly in the protocol. If we=
 don=E2=80=99t assume that the client *has* to have a client ID equivalent,=
 but it *can* have one in a set of defined circumstances, then I think we a=
re in a much better spot. This is the reasoning for XYZ=E2=80=99s model of =
having clients identified by the key, and that key can potentially be passe=
d by a reference identifier.

I think all of the us=
e cases that Mike Varley presents below are all valid directions, with the =
caveat that we shouldn=E2=80=99t assume a client should be presenting an ID=
 at all steps. Mechanisms like software statements should be presentable ap=
art from a client ID, as should on-device keys. We=E2=80=99re probably goin=
g to want extensions for device posture and other forms of attestation as w=
ell.

This is one of the domains that I think we ca=
n clearly surpass OAuth 2=E2=80=99s flexibility and capabilities if we are =
willing to look past OAuth 2=E2=80=99s assumptions of what=E2=80=99s needed=
 inline in the protocol.=C2=A0

=C2=A0=E2=80=94 Jus=
tin

On Jul 14, 2020, at 1=
:54 PM, Mike Varley <mike.varley@securekey.com> wrote:

Is client registration in scope for the protocol?=

=C2=A0
A generic wa=
y of handling clients (via ID or Handle or Key or whatever) is to have proc=
essing rule on the AS such as =E2=80=9Cif the AS recognizes the client ID (=
and authentication of that client ID) then it may process the request on be=
half of that client. If the AS does not recognize the client ID, it must tr=
eat this as a new client registration and evaluate any authorization eviden=
ce the client provides before enabling the client and mapping policies to t=
hat client=E2=80=9D (this means dynamic or automatic clients need to provid=
e additional assertions / software statements whatever to register their ID=
.
=C2=A0
Somethin=
g like this allows for very flexible systems:
=
System A can be unknown to the AS but can dynamically registered each time =
with an appropriate software statement
System =
B can have a fairly stable client ID at the AS, but rotate that ID every mo=
nth through automatic registration (with an assertion it got from the AS du=
ring a pre-registration for example)
System C =
can pre-register with the AS for a client ID because it doesn=E2=80=99t dea=
l with software statements etc=E2=80=A6
=E2=80=
=A6
And even =E2=80=98StatelessAS=E2=80=99 can=
 operate by never storing client IDs because it will always just rely on th=
e software statements.
=C2=A0
I think a client registration protocol that allows these scena=
rios would be very useful in GNAP, but hopefully avoiding having to define =
what =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
=C2=A0
Thanks,<=
/u>
=C2=A0
MV<=
/u>
=C2=A0
From:=
=C2=A0Txauth <txauth-bounces@ietf.org> on behal=
f of Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
Da=
te:=C2=A0Tuesday, July 14, 2020 at 12:18 PM
To:=C2=A0Dick Hardt <dic=
k.hardt@gmail.com>, "txauth=
@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu=
>
Subject:=C2=A0Re: [Txauth] Key handle vs cl=
ient id & handle
=C2=A0
I agree that there are significant differences between statically and =
dynamically registered clients and that=E2=80=99s appropriate to be able to=
 syntactically differentiate between them at runtime.=C2=A0 For one thing, =
the resource requirements at the authorization server can be very different=
.
=C2=A0
We should also be thinking about how to include what the OpenID =
Connect Federation spec=C2=A0https://openid.net/specs/openi=
d-connect-federation-1_0.html=C2=A0calls =E2=80=9CAutomati=
c Registration=E2=80=9D.=C2=A0 This lets the client encode a registration r=
equest reference in the client ID, so no static or dynamic registration eve=
n occurs.=C2=A0 See=C2=A0https://openid.net/sp=
ecs/openid-connect-federation-1_0-12.html#rfc.section.9.1.
=C2=A0
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=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:=C2=A0Dick Hardt &=
lt;dick.hardt@gmail.com>=C2=A0
Sent:=C2=A0Friday, July 10, 2020 1:17=
 PM
To:=C2=A0txaut=
h@ietf.org; Justin Richer <jriche=
r@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Subject:=C2=A0Key handle vs client id & handle
=C2=A0
+ Mike as he had interes=
t in this topic
=C2=A0=

My understanding is that an existing OAuth 2 clie=
nt would use their current client id as their key handle, and a dynamic cli=
ent (one that was not pre-registered) would be given a key handle by the AS=
.
=C2=A0
There are potentially some significant differences =
between a registered client, and a dynamic client to an AS.
=C2=A0
The AS is likely to know the identity of a registered client, and ha=
ve different policies between the two types of clients. For example, a regi=
stered client may have access to a 'write" scope, while a dynamic =
client does not.
=C2=A0=

The AS may have 100s or 1000s of reg=
istered clients, but a dynamic client may have 10Ms or 100Ms of instances, =
which may dictate separate=C2=A0storage services. Additionally, internal to=
 the AS, which systems can write to the registered=C2=A0client store is goi=
ng to be different than the dynamic client=C2=A0store.
<=
/div>
=C2=A0
=C2=A0<=
/div>
While the AS could embed semantics in the ke=
y handle identifier to indicate which identifiers are pre-registered vs dyn=
amic, there are many cases where the AS does need to know the difference, s=
o making=C2=A0the difference a feature of GNAP seems like a better path.=

=C2=A0
=

=C2=A0
This email and any attachments are for the sole use of the i=
ntended recipients and may be privileged, confidential or otherwise exempt =
from disclosure under law. Any distribution, printing or other use by anyon=
e other than the intended recipient is prohibited. If you are not an intend=
ed recipient, please contact the sender immediately, and permanently delete=
 this email and its attachments.

-- 

Txauth mailing list

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




--0000000000008cd10905aa8a4884--


From nobody Thu Jul 16 01:20: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 61F0D3A1146 for ; Thu, 16 Jul 2020 01:20:53 -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 aqxlHeljyq-J for ; Thu, 16 Jul 2020 01:20:47 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0: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 BC43C3A1148 for ; Thu, 16 Jul 2020 01:20:46 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id t27so4300445ill.9 for ; Thu, 16 Jul 2020 01:20: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=Y4a9U6pEEFj1ohxvjPWwpTkRSVFq0XPDYW35xRggI1Q=; b=ZCI3Yf9I5/NT2TNgA+XhDnBClJRNp+h7AuumICQOSbM9iqzKJp4g+xmYTWl86Tdjti HV9C0RCEITvSp2LUnNndntgGaD9rmQ85NdhRZxdCU1HgdoMHjv33F9ouCOBEJAzTZIpc /SnOd+h17LUoYEzTTyfj7mISD8/bldUKQraTTm4i0FG14boXb7deUst7irysMcbyNgsc p9b/UVtrJvYEJdPL4TpwOAZrZAXvTmRtUWOAeryiOpjtoLO2IypdI3D1p5CeObnNAgxq 3IH6IN/1bILOnxqUrCfB1dOuhEynzDbbp2w0AZMHIKHE/jPNzkY5XaLN5kJg+ptGOrzz 9teQ==
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=Y4a9U6pEEFj1ohxvjPWwpTkRSVFq0XPDYW35xRggI1Q=; b=juVzP7S7Q9iMZVnSWfPWewcsYyxwZqxLSkGMG0zZM9oWwyMHEVGhQQCOSciK7B7+2A MM+XwerfZWb8Cc6JquG7Z5lTR38vXR28eP1YQ7HQL5eyn6Oqd9N/lBA4PobohmARYnfZ mzb5NezLotSKbqH6CUnPf904CTmFmgRxGkS3kJy+5eSEwbjrJLknReEON0tYs8SZ+0Rs VRjH6QdbDwEM9JYsf8LAkv6DSATqudi/TDbO9oR+ZxwdbWNfmTyKbiuFCOXsRxE+hvJJ iWf86e1vnUi7E6s34LFfa+x4sSiw90LVzuCd38QDjli9nDNqa9O58W/YzJPtWvyftJv1 cN7A==
X-Gm-Message-State: AOAM531NjIj1EacOlbI2Uc/a+5SvyYZWIs9zXdDu+IcAt7PtaVDrvThW IgGgvQmrlm8DQRPHog+uPdDsspmFNt+mdx6w0TA=
X-Google-Smtp-Source: ABdhPJy15Lpbva8bnvXcAD4olBaImIW3Q/ohvYew65IEUX+SHuwQi3Dw/KL915qup4xyyVs3f8OxhJaYHvbVL2QELh4=
X-Received: by 2002:a05:6e02:1313:: with SMTP id g19mr3240496ilr.123.1594887645899;  Thu, 16 Jul 2020 01:20:45 -0700 (PDT)
MIME-Version: 1.0
References:  <382b5f57-6825-3537-c66b-fb2c38e5140c@free.fr>  
In-Reply-To: 
From: Fabien Imbault 
Date: Thu, 16 Jul 2020 10:20:34 +0200
Message-ID: 
To: Denis 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000097306805aa8ab79d"
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 16 Jul 2020 08:20:54 -0000

--00000000000097306805aa8ab79d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Denis for your answers.

I think what you call delegation is a slightly different requirement than
how the term is generally used in our context.
Instead of delegation, I would rather suggest to call it a "resource chain"
(and as in any supply chain, those could come from different parties).

I think the privacy concern is important, and it would be interesting to
get back to prior art on the issue.
for instance, https://github.com/samuelgoto/WebID provides an interesting
analysis on RP or IdP collusion (here more focused on the ID part), a
similar vein of work may enable richer discussions whether/when the GS is
the right place for user consent, or not.

Then on user consent : implementations of XYZ do handle user consent. In
our case, we've also decoupled the consent part (as a separate project).
Initially we did that to simplify the implementation of the AS core flow
(between client and AS), while covering the UX requirements in a
separate project.
But the nice thing about that is that it doesn't change the core flow, and
depending on the use case, one may either place it on the AS part (as we've
implemented so far, and as most people would do today) or on the client
part (as you think it should be). This demonstrates that depending how we
assemble parts, we may end up with a solution that may fit various
requirements.

Fabien

On Mon, Jul 13, 2020 at 10:40 AM Denis  wrote:

> Hi Fabien,
>
> Thank you for your responses. Rather than responding in the text, I will
> pick up two of your comments:
>
> FI : as far as I'm concerned, there are many more interactions than
> Oauth/XYZ/Xauth.
> Your view seems to be that it is simpler because AS are way less central,
> but it seems to me
> that RS are much more complex to implement correctly.
>
> In XYZ/Xauth there is a protocol needed between the GS and many ROs. This
> protocol is "out of the scope" of these drafts and this is where the
> complexity is hidden.
> So it looks simpler for the client but it is much more complicated for th=
e
> management of the delegation at the GS. This also makes the assumption th=
at
> a single GS
> will be able to handle the delegation case because all the RSs are
> supposed to be in the same domain which is a very restrictive case. My
> proposal is able to handle
> the multi-domain case.
>
> Every RS is best placed to know where to forward an operation when it
> can't respond to it of its own. A RO should not need to inform a GS to te=
ll
> what its relationships
> with other RSs are. A GS should not be in a position to know everything
> about the relationships between RSs and to be informed in real time of an=
y
> change about these
> relationships.
>
> In term of trust, I mentioned:
>
>    - If a user has an account opened with an AS, then he trusts that AS
>    to deliver the requested and genuine attributes into an access token.
>
> This is it. There is no other trust relationship. The user does not trust
> or rely on any collaboration between a RO and a GS.
>
>
> A second of your comments:
>
> FI: if we can't do it with maximum privacy, then we won't do it; which is
> a design choice,
>
> I would rather say: If we can do it with maximum privacy, let us do it. A=
t
> this time :
>
>    - in draft-hardt-xauth-protocol-12, the word "privacy" does not even
>    exist.
>    - in draft-richer-transactional-authz-06, there is a single sentence
>    in the privacy considerations section:
>
>          Handles are passed between parties and therefore should be
> stateful and not contain any internal structure or information,
>          which could leak private data.
>
> About the user consent. At this time :
>
>    - in draft-richer-transactional-authz-06, the user consent is never
>    addressed.
>    - in draft-hardt-xauth-protocol-12, the user consent is captured by
>    the GS whereas it should be captured by the Client.
>
>          The client has no way to verify that the user consent has indeed
> been followed by the GS because the client
>          cannot verify that what happens "behind the scenery" at the GS i=
s
> conformant with what the user has consented.
>
> Denis
>
> Hi Denis,
>
> Thanks for your answer.
>
> My comments are embedded in the text, marked with FI.
>
> Fabien
>
>
> Le ven. 10 juil. 2020 =C3=A0 17:53, Denis  a =C3=A9cr=
it :
>
>> Hi Fabien,
>>
>> It would have been appreciated that you kept the original message in you=
r
>> response. I have copied it again at the end of this email.
>>
>
> FI : sorry, not always easy on a mobile. Will make sure that's the case
> next time.
>
>>
>> Comments are between the lines.
>>
>> Hi Denis,
>>
>> I think it's interesting, but also very different to XYZ/XAuth so it
>> raises many questions ;-)
>> The figure is impossible to read.
>>
>> Use a PC. Copy and paste and then use the Courier font. On my PC (with
>> the clear figure) it was perfect.
>>
>> So let me try to summarize the suggested approach, with a concrete
>> example, to make sure we understand well:
>>
>> *0. The client authN to the AS (in whatever way is supported)*
>> Ex : client is a corporate financing called "finapp". finapp contacts AS=
0
>> for authentication (say an openbanking service).
>> User is John Doe, CFO at NeedMoney Inc. (+ other identity claims if
>> needed, maybe some verified credential from NeedMoney Holding that John =
is
>> indeed CFO).
>>
>> *Dear John, *
>> *to access to your finapp, please identify yourself through your prefere=
d
>> openbanking account.*
>> *Thanks*
>>
>> If I understand you correctly,  finapp is a local application e.g. on
>> your smartphone.
>>
> FI : not necessarily, the client could be a mobile app, a web app, etc.,
> making api calls to backend protected services.
>
>> *1. The client contacts a RS in a discovery phase, which includes the
>> selection of (at least) an operation, for which the RS returns the requi=
red
>> authZ attributes *
>> Ex : finapp needs to use NeedMoney's data to evaluate how much credit it
>> can offer.
>>
>> Op1 : compute the credit rating, from RS1 (this is outsourced to an
>> external credit analyst), through the external service's own AS1.
>> But to do that, RS needs your historic bank statements.
>> Op2 : get your list of banks, RS2 (as registered within finapp),
>> through openbanking AS0 and retrieve the bank statements :
>> Op3a : get historic data from his main bank, RS2a (say an international
>> bank), through openbanking AS0
>> Op3b : same from a second bank account, RS2b (say a local bank), through
>> openbanking AS0
>>
>> Why don't you make your very first example a little bit more complicated
>> ? with RS1, RS2a, RS2b, ... AS0, AS1, ...
>>
>> :-)
>>
> FI : fair point. But i believe it's important to grasp what it means on a
> realistic example, especially as the proposed protocol would be very much
> dependant on the way RS calls are made.
>
>>
>> The intent of the *first *email was to discuss a *basic *model and to
>> place the highlights on the way to capture the *user's consent*
>> in an interoperable manner without letting know to any RS or AS the
>> choices of the user. This is a fundamental feature of the model.
>> In XAuth, the user's consent is not formalized in the protocol : "User
>> consent is *often *required at the GS".
>>
> FI : in the context of xauth, this seems pretty clear I think.
>
>> *2. User consent *
>> RS1 aggregates the list of attributes required (from all RS) and sends i=
t
>> to finapp.
>>
>> *Dear John, *
>> *To evaluate your credit request, we need the following information: *
>> *- your list of bank accounts (retrieved from your finapp account)*
>> *- the associated banking statements over the past 12 months (from each
>> bank)*
>> *- we'll pass that data to the credit agency, which will return your
>> credit score *
>> *Do you agree ?*
>>
>> John approves (or not..., maybe he'll agree only for one specific bank),
>> via finapp directly
>> (I like that, albeit in a more traditional flow, I'm also separating the
>> UI from the rest of the protocol of XYZ, and it works too).
>>
>> As described, the user could simply push to the RS the banking statement=
s
>> over the past 12 months (from each bank).
>> The user consent is not about : "*Do you agree that*
>> * we pass the data to the credit agency, which will return your credit
>> score" *since no attributes nor ASs are involved in the question.
>>
> FI : this is possible of course, but pretty surprising. Today most
> implementations are using oauth to delegate the implementation to some
> specialized component, while here each RS would be responsible for
> authentication. That is not an innocent choice from an implementation and
> deployment perspective.
>
>>
>> I guess you want the user to get access tokens targeted for RS2x so that
>> each bank will accept to disclose his banking statements over the past 1=
2
>> months.
>>
>> The consent is whether the user accepts to get access tokens from some o=
f
>> his banks targeted for RS2x for the following operation:
>> "Retrieval of the past 12 months banking statements" which corresponds t=
o
>> an API for each bank and then to send these access tokens to RS1.
>>
>> In practice, the client (e.g. using FIDO) will connect transparently to
>> each of the appropriate AS from the banks and will get the requested acc=
ess
>> tokens
>> with a requested validity period of about 5 minutes.
>>
> FI : yes.
>
>> *3. Requests to the protected resources *
>> The client gets the access tokens and uses the services for which access
>> was granted.
>>
>> *Analysis: (maybe I didn't get everything right, if so let me know) *
>> The trust model is focused around the relationship between the enduser
>> (John) and his application (finapp), which seems fine.
>>
>> No. The trust model is not making a focus on that specific relationship.
>> BTW, no access token is necessarily needed by the user to be able to use
>> finapp.
>>
> FI : maybe, maybe not. As soon as I want to fetch api calls, I need acces=
s
> tokens.
>
>> =3D> I see some potential issues :
>>
>> a. it will be really difficult for an end user to understand what AS0 an=
d
>> AS1 are, why they're different, and why he needs to authenticate to each=
 of
>> them.
>> How do you enable a federated experience? (especially as there could be
>> many)
>>
>> I fear that you have not fully captured what the user consent is about.
>> See the above explanations. In addition, there is no concept of federati=
on.
>>
> FI : your notion of consent is very specific to what you have in mind. It
> would require a kind of automated system to work.
> As for the concept of federation, this is required in practice in you
> don't hypothesize a dependancy on FIDO. The Uma2 standard is probably the
> closest to some of your ideas and focuses a lot on federation.
>
>> b. deciding what is the main RS (here RS1) to be called by the client
>> seems very critical, as it is the one that needs to orchestrate everythi=
ng.
>> This seems a very hierarchical and imperative model which seems somewhat
>> counter intuitive in terms of developer experience (as least
>> as it is made today, we clearly don't go into so much details). The call
>> hierarchy may quickly become very complex, which may also become
>> a problem when separate services evolve.
>>
>> The client calls the main RS (here RS1). What may happen next is fully
>> dependant upon the operation that the user is willing to perform and
>> this is unpredictable (since the back end service may change at any poin=
t
>> of time).
>>
> FI : OK, but is it good engineering practice to have to deal with the
> internals of service calls? The reason why people delegate APIs is
> precisely to avoid that complexity. Today with OAuth, and tomorrow with
> XYZ/Xauth, the programming model is way simpler. Privacy may be a good
> reason to change that, but we need to be very thoughtful about that.
>
>> c. RS1 gets all the information required to access all sub-resources, an=
d
>> therefore gets also a lot of responsibility (and power). But from finapp=
's
>> point of view, it is the one that has the relationship with the user and
>> is providing the core value proposition, while RS1 is just an external
>> service.
>>
>>  So is it really a problem ?
>>
> FI : I think so. If I'm finapp, I don't want to be this dependant on RS1
> for a lot of good and bad reasons. What I hope the example conveys is tha=
t
> there's no reason why RS1 would suddenly become the center of orchestrati=
on
> for all queries, while all the underlying data is actually elsewhere.
> The fact that the proposed protocol mandates this behaviour is surprising
> and I don't see why that is.
>
>> d. multi-user (common B2B scenario): John wants to authorize a read
>> access to his finapp account to his external auditor, Ann (who is not a
>> direct user
>> of finapp herself, but might already be registered by openbanking AS0).
>> How do you do that? Does it require the access token itself to be able t=
o
>> delegate rights?
>>
>> The intent of the short description I sent was to describe two simple
>> scenarios, so that we could start discussing about them.
>> At this point, the intent is not to cover all the scenarios you may drea=
m
>> of.
>>
> FI : fair point. However, as previously discussed, this is a big concern
> as we don't know whether you think this is a valid use case or whether th=
is
> is out of scope (so far, I understood it was more, if we can't do it with
> maximum privacy, then we won't do it; which is a design choice, but
> standards are usually about consensus with people that need to deal with
> real life problems).
>
>> e. more generally, a threat model would be required, as there are many
>> more interactions now.
>>
>> There are less interactions than in XAuth: there is no protocol between
>> ASs and RSs, nor between ROs and ASs.
>>
> FI : as far as I'm concerned, there are many more interactions than
> Oauth/XYZ/Xauth. Your view seems to be that it is simpler because AS are
> way less central, but it seems to me that RS are much more complex to
> implement correctly.
>
>>
>> Before a threat model, a trust model is needed. Do we have a trust model
>> for XAuth ?
>> Unfortunately not, since the word "trust" is absent in the main body of
>> draft-hardt-xauth-protocol-12.
>>
> FI : sorry but I don't need the word trust to do threat modeling...
>
>> In this model, the trust relationships are as follows:
>>
>>    - The user trusts its client.
>>    - If a user has an account opened with an AS, then he trusts that AS
>>    to deliver the requested and genuine attributes into an access token.
>>    - A RS may trust one or more ASs for one or more types of attributes
>>    *and* for performing a given operation.
>>    - A RS may be administered remotely by one or more RO.
>>
>> *Note*: for authentication, a RS may accept either FIDO or one or more
>> types of attributes from one or more ASs.
>>
> Denis
>>
>> Cheers,
>> Fabien
>>
>>
>> This is a new thread.
>>
>>
>> Preamble: This model is quite different from the XAuth model.
>> In particular, a RO has no relationship with any AS and a Client does no=
t
>> need to be associated with any AS prior to any access to a RS.
>>
>> A key point of this model is that the user's consent is handled locally
>> by the Client and hence no AS nor RS is handling a man machine interface
>> for the user consent. This allows to support locally the user consent fo=
r
>> multiple ASs while keeping all ASs ignorant about the choices of the use=
r
>> made for accessing a particular RS.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *       +--------+                           +------------+        |
>> User  |                           |  Resource  |        |
>> |                           | Owner (RO) |        +--------+
>>                   +------------+            |
>> \                              |            |
>> \                             |            |
>> \                            |            |
>> \                           |     +-----------+     +---------------+
>> +------------+     |           |---->| Authorization |     |            =
|
>>     |           | (2) |  Server (AS)  |     |            |     |
>> |<----|               |     |            |     |  Client   |
>> +---------------+     |            |     |
>> |-------------------------->|  Resource  |     |   User    |
>> (1)             |   Server   |     |  Consent
>> |<--------------------------|    (RS)    |     |  element
>> |                           |            |     |
>> |-------------------------->|            |------>     |
>> |           (3)             |            |  (4)     |
>> |<--------------------------|            |<------
>> +-----------+                           +------------+ *
>> The flow of operations is as follows:
>>
>> The Client (which may have been previously authenticated using FIDO)
>> contacts the RS and after some dialogue with the RS selects an operation
>> that it wants to perform on the RS (1a). Note that it may also indicate
>> directly the operation that it wants to perform on the RS without any pr=
ior
>> dialogue.
>> In return (1b), the RS informs the Client about which attributes are
>> needed by the RS for performing the requested operation and from which
>> Attributes Servers
>> they may be obtained.
>>
>> This information is specifically marked to indicate that it shall be
>> handled by the "User Consent element" from the Client.
>> The presentation of that information is up to the man machine interface
>> supported by the "User Consent element" from the Client.
>>
>> The user can see which attributes are requested by the RS for performing
>> the requested operation and, if it consents, the Client contacts one or
>> more
>> appropriate Authorization Servers (2a). The user consent is hence
>> captured locally by the Client (i.e. there is no dialogue with any AS no=
r
>> any RS).
>>
>> When the Client got the access tokens from these authorization servers
>> (2b), it sends all of them in a single request to the RS (3a).
>>
>> End of the story for a simple access
>>
>>
>> Start of a subsequent story for a delegation case
>>
>> Let us now suppose that the RS is unable to fulfil the request by its ow=
n
>> and that it needs to contact another RS. RS1 contacts RS2 (4a) and
>> indicates the operation
>> that it wants to perform on RS2 (that operation may not be the same as
>> the original operation). In return (4b), RS2 informs RS1 about which
>> attributes are needed
>> by RS2 for performing the requested operation and from which Attributes
>> Servers they may be obtained. RS1 forwards that information to the Clien=
t.
>>
>> This information is marked to indicate that it shall be handled by the
>> "User Consent element" from the Client. The presentation of that
>> information is up to the man machine
>> interface from the Client. The user can see which attributes are
>> requested by RS2 for performing the new requested operation and, if it
>> consents, the Client contacts one or more
>> appropriate Authorization Servers. The user consent is hence captured
>> locally by the "User Consent element" from the Client. (i.e. there is no
>> dialogue with any AS, nor RS1, nor RS2).
>>
>> When the Client got the access token(s) from the authorization server(s)=
,
>> it sends all of them in a single request to RS1. RS1 then forwards the
>> additional access token(s) to RS2.
>>
>>
>> Some observations:
>>
>> The user nor the Client are linked with any particular AS. A user may us=
e
>> today an AS of the Bank of America and may change tomorrow to the Bank o=
f
>> Missouri.
>> As soon as he will be registered with the Bank of Missouri, he will be
>> able to get access tokens from the AS of the Bank of Missouri. The AS of
>> Bank of America
>> has not been able to know where its access tokens have been used. This
>> will be the same for AS of the Bank of Missouri. There is no need for an=
y
>> direct dialogue
>> between any AS and any RS at the time a client is making an access. Ther=
e
>> is no need for any RO to contact any AS.
>>
>> This model has been constructed following a "Privacy by Design" approach=
.
>> Denis
>>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--00000000000097306805aa8ab79d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Denis for your answers.

I think what you call delegation is a slightly different requireme=
nt than how the term is generally used in our context.
Instea=
d of delegation, I would rather suggest to call it a "resource chain&q=
uot; (and as in any supply chain, those could come from different parties).=


I think the privacy concern is important, and it =
would be interesting to get back to prior art on the issue.
for i=
nstance,=C2=A0https://githu=
b.com/samuelgoto/WebID=C2=A0provides an interesting analysis on RP or I=
dP collusion (here more focused on the ID part), a similar vein of work may=
 enable richer discussions whether/when the GS is the right place for user =
consent, or not.=C2=A0

Then on user consent : impl=
ementations of XYZ do handle user consent. In our case, we've also deco=
upled the consent part (as a separate project). Initially we did that to si=
mplify the implementation of the AS core flow (between client and AS), whil=
e covering the UX requirements in a separate=C2=A0project.=C2=A0
=
But the nice thing about that is that it doesn't change the core flow, =
and depending on the use case, one may either place it on the AS part (as w=
e've implemented so far, and as most people would do today) or on the c=
lient part (as you think it should be). This demonstrates that depending ho=
w we assemble parts, we may end up with a solution that may fit various req=
uirements.

Fabien

On Mon, Jul 13, 2020 at 10:=
40 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hi Fabien,

    


    

    
Thank you for your responses. Rather
      than responding in the text, I will pick up two of your comments:
    

      
FI : as far as I'm concerned, there
        are many more interactions than Oauth/XYZ/Xauth. 

        Your view seems to be that it is simpler because AS are way less
        central, but it seems to me 

        that RS are much more complex to implement correctly. 

      

    

    
In XYZ/Xauth there is a protocol needed
      between the GS and many ROs. This protocol is "out of the scope&=
quot;
      of these drafts and this is where the complexity is hidden. 

      So it looks simpler for the client but it is much more complicated
      for the management of the delegation at the GS. This also makes
      the assumption that a single GS 

      will be able to handle the delegation case because all the RSs are
      supposed to be in the same domain which is a very restrictive
      case. My proposal is able to handle 

      the multi-domain case.

    

    


    

    
Every RS is best placed to know where
      to forward an operation when it can't respond to it of its own. A
      RO should not need to inform a GS to tell what its relationships 

      with other RSs are. A GS should not be in a position to know
      everything about the relationships between RSs and to be informed
      in real time of any change about these

      relationships.

    


    

    
In term of trust, I mentioned:

    

      
    
        
  • If a user has an account opened with an AS, then he trusts
          that AS to deliver the requested and genuine attributes into
          an access token.
    • 
      

    

    
This is it. There is no other trust
      relationship. The user does not trust or rely on any collaboration
      between a RO and a GS.

    
 

    

    


    

    
A second of your comments:

    

      
FI: if we can't do it with maximum privacy, then we won't =
do
        it; which is a design choice,

    

    
I would rather say: If we can do it with maximum privacy, let us
      do it. At this time :

    
    
      
  • in draft-hardt-xauth-protocol-12, the word "privacy" do=
es not
        even exist.
    • 
      
  • in draft-richer-transactional-authz-06, there is a single
        sentence in the privacy considerations section:
    • 
    

    
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Handles are passed between parties=
 and therefore should
      be stateful and not contain any internal structure or information,
      

      =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 which could leak private data.

    
About the user consent. At this time :

    
    
      
  • in draft-richer-transactional-authz-06, the user consent is
        never addressed.
    • 
      
  • in draft-hardt-xauth-protocol-12, the user consent is captured
        by the GS whereas it should be captured by the Client.
    
      
    • 
    

    
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The client has no w=
ay to verify that the user consent
      has indeed been followed by the GS because the client 

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cannot verify that w=
hat happens "behind the scenery" at
      the GS is conformant with what the user has consented.

    
 Denis

    

    

     =20
      

        
Hi Denis,
          


          

          
Thanks for your answer.=C2=A0

          


          

          
My comments are embedded in the text, marked
            with FI.=C2=A0

          


          

          
Fabien=C2=A0

          

          

          

            
Le ven. 10 juil. 2020 =C3=
=A0
              17:53, Denis <denis.ietf@free.fr> a
              =C3=A9crit=C2=A0:

            

            

              

                
Hi Fabien,

                


                

                
It would have been appreciated that you kept the
                  original message in your response. I have copied it
                  again at the end of this email.

                

              

            

          

        

        


        

        
FI : sorry, not always easy on a mobile. Will
          make sure that's the case next time.=C2=A0

        

          

            

              

                
 

                


                

                
Comments are between the lines.

                


                

                

                  
Hi Denis,=C2=A0
                    


                    

                    
I think it's interesting, but also very
                      different to XYZ/XAuth so it raises many questions
                      ;-)

                    
The figure is impossible to read.

                  

                

                
Use a PC. Copy and paste and then use the Courier
                  font. On my PC (with the clear figure) it was perfect.
                

                  

                    
So let me try to summarize the suggested
                      approach, with a concrete example, to make sure we
                      understand well:

                    


                    

                    
0. The client authN to the AS (in whatever
                        way is supported)

                    
Ex : client is a corporate=C2=A0financing called
                      "finapp". finapp contacts AS0 for authentic=
ation
                      (say an openbanking service).=C2=A0=C2=A0

                    
User is John Doe, CFO at NeedMoney Inc. (+
                      other identity claims if needed, maybe some
                      verified credential from NeedMoney Holding that
                      John is indeed CFO).

                    


                    

                    
Dear John,=C2=A0

                    
to access to your finapp, please identify
                        yourself through your prefered openbanking
                        account.

                    
Thanks

                  

                

                
If I understand you correctly,=C2=A0 finapp is a local
                  application e.g. on your smartphone.

                

              

            

          

        

        
FI : not necessarily, the client could be a
          mobile app, a web app, etc., making api calls to backend
          protected services.=C2=A0

        

          

            

              

                
 

                

                  
1. The client contacts a RS in a
                      discovery phase, which includes the selection of
                      (at least) an operation, for which the RS returns
                      the required authZ attributes=C2=A0
                    
Ex : finapp needs to use NeedMoney's data to
                      evaluate how much credit it can offer.

                    


                    

                    
Op1 : compute the credit rating, from RS1 (this
                      is outsourced to an external credit analyst),
                      through the external service's own AS1.

                    

                    
But to do that, RS needs your historic bank
                      statements.

                    
Op2 : get your list of banks, RS2 (as
                      registered within finapp), through=C2=A0openbanking A=
S0
                      and retrieve the bank statements :=C2=A0

                    
Op3a : get historic data from his main bank,
                      RS2a (say an international bank), through
                      openbanking AS0

                    
Op3b : same from a second bank account, RS2b
                      (say a local bank), through openbanking AS0

                  

                

                
Why don't you make your very first example a little
                  bit more complicated ? with RS1, RS2a, RS2b, ... AS0,
                  AS1, ... 

                

                
:-)

                

              

            

          

        

        
FI : fair point. But i believe it's important=
 to
          grasp what it means on a realistic example, especially as the
          proposed protocol would be very much dependant on the way RS
          calls are made.=C2=A0

        

          

            

              

                


                  The intent of the first email was to discuss
                  a basic model and to place the highlights on
                  the way to capture the user's consent 

                  in an interoperable manner without letting know to any
                  RS or AS the choices of the user. This is a
                  fundamental feature of the model.

                  In XAuth, the user's consent is not formalized in the
                  protocol : "User consent is often required at
                  the GS".

                

              

            

          

        

        
FI : in the context of xauth, this seems pretty
          clear I think.=C2=A0

        

          

            

              

                
 

                

                  

                    
2. User consent=C2=A0

                    
RS1 aggregates the list of attributes required
                      (from all RS) and sends it to finapp.

                  

                

                

                  

                    
Dear John,=C2=A0

                    
To evaluate your credit request, we need the
                        following information:=C2=A0

                    
- your list of bank accounts (retrieved from
                        your finapp account)

                    
- the associated banking statements over the
                        past 12 months (from each bank)

                    
- we'll pass that data to the credit agency=
,
                        which will return your credit score=C2=A0

                    
Do you agree ?

                    


                    

                    
John approves (or not..., maybe he'll agree
                      only for one specific bank), via finapp directly 

                      (I like that, albeit in a more traditional flow,
                      I'm also separating the UI from the rest of the
                      protocol of XYZ, and it works too).

                  

                

                
As described, the user could simply push to the RS
                  the banking statements over the past 12 months (from
                  each bank).

                  The user consent is not about : "Do you agree tha=
t
                   we pass the data to the credit agency, which will
                    return your credit score"

                  since no attributes nor ASs are involved in the
                  question.

              

            

          

        

        
FI : this is possible of course, but pretty
          surprising. Today most implementations are using oauth to
          delegate the implementation to some specialized component,
          while here each RS would be responsible for authentication.
          That is not an innocent choice from an implementation and
          deployment perspective.=C2=A0

        

          

            

              

                


                  

                
I guess you want the user to get access tokens
                  targeted for RS2x so that each bank will accept to
                  disclose his banking statements over the past 12
                  months.

                
The consent is whether the user accepts to get access
                  tokens from some of his banks targeted for RS2x for
                  the following operation: 

                  "Retrieval of the past 12 months banking statements&=
quot;
                  which corresponds to an API for each bank and then to
                  send these access tokens to RS1.

                
In practice, the client (e.g. using FIDO) will
                  connect transparently to each of the appropriate AS
                  from the banks and will get the requested access
                  tokens 

                  with a requested validity period of about 5 minutes.

              

            

          

        

        
FI : yes.=C2=A0

        

          

            

              

                

                  

                    
3. Requests to the protected resources=C2=A0

                    
The client gets the access tokens and uses the
                      services for which access was granted.

                    


                    

                    
Analysis: (maybe I didn't get everything
                        right, if so let me know)=C2=A0

                    
The trust model is focused around the
                      relationship between the enduser (John) and his
                      application (finapp), which seems fine.

                  

                

                
No. The trust model is not making a focus on that
                  specific relationship. BTW, no access token is
                  necessarily needed by the user to be able to use
                  finapp.

                

              

            

          

        

        
FI : maybe, maybe not. As soon as I want to
          fetch api calls, I need access tokens.=C2=A0

        

          

            

              

                
 

                

                  
=3D> I see some potential issues :=C2=
=A0
                    


                    

                    
a. it will be really difficult for an end user
                      to understand what AS0 and AS1 are, why they're
                      different, and why he needs to authenticate to
                      each of them. 

                      How do you enable a federated experience?
                      (especially as there could be many)

                  

                

                
I fear that you have not fully captured what the user
                  consent is about. See the above explanations. In
                  addition, there is no concept of federation. 

                

              

            

          

        

        
FI : your notion of consent is very specific to
          what you have in mind. It would require a kind of automated
          system to work.=C2=A0

        
As for the concept of federation, this is
          required in practice in you don't hypothesize a dependancy on
          FIDO. The Uma2 standard is probably the closest to some of
          your ideas and focuses a lot on federation.=C2=A0

        

          

            

              

                
 

                

                  

                    
b. deciding what is the main RS (here RS1) to
                      be called by the client seems very critical, as it
                      is the one that needs to orchestrate everything. 

                      This seems a very hierarchical and imperative
                      model which seems somewhat counter intuitive in
                      terms of developer experience (as least 

                      as it is made today, we clearly don't go into so
                      much details). The call hierarchy may quickly
                      become very complex, which may also become 

                      a problem when separate services evolve.

                  

                

                
The client calls the main RS (here RS1). What may
                  happen next is fully dependant upon the operation that
                  the user is willing to perform and 

                  this is unpredictable (since the back end service may
                  change at any point of time).

              

            

          

        

        
FI : OK, but is it good engineering practice to
          have to deal with the internals of service calls? The reason
          why people delegate APIs is precisely to avoid that
          complexity. Today with OAuth, and tomorrow with XYZ/Xauth, the
          programming model is way simpler. Privacy may be a good reason
          to change that, but we need to be very thoughtful about that.=C2=
=A0

        

          

            

              

                

                  

                    
c. RS1 gets all the information required to
                      access all sub-resources, and therefore gets also
                      a lot of responsibility (and power). But from
                      finapp's 

                      point of view, it is the one that has the
                      relationship with the user and is providing the
                      core value proposition, while RS1 is just an
                      external service.

                  

                

                
=C2=A0So is it really a problem ? 

                

              

            

          

        

        
FI : I think so. If I'm finapp, I don't w=
ant to
          be this dependant on RS1 for a lot of good and bad reasons.
          What I hope the example conveys is that there's no reason why
          RS1 would suddenly become the center of orchestration for all
          queries, while all the underlying data is actually elsewhere.=C2=
=A0

        
The fact that the proposed protocol mandates
          this behaviour is surprising and I don't see why that is.=C2=
=A0

        

          

            

              

                
 

                

                  

                    
d. multi-user (common B2B scenario): John wants
                      to authorize a read access to his finapp account
                      to his external auditor, Ann (who is not a direct
                      user 

                      of finapp herself, but might already be registered
                      by openbanking AS0). How do you do that? Does it
                      require the access token itself to be able to
                      delegate rights?

                  

                

                
The intent of the short description I sent was to
                  describe two simple scenarios, so that we could start
                  discussing about them.

                  At this point, the intent is not to cover all the
                  scenarios you may dream of.

              

            

          

        

        
FI : fair point. However, as previously
          discussed, this is a big concern as we don't know whether you
          think this is a valid use case or whether this is out of scope
          (so far, I understood it was more, if we can't do it with
          maximum privacy, then we won't do it; which is a design
          choice, but standards are usually about consensus with people
          that need to deal with real life problems).=C2=A0

        

          

            

              

                

                  

                    
e. more generally, a threat model would be
                      required, as there are many more interactions now.
                  

                

                
There are less interactions than in XAuth: there is
                  no protocol between ASs and RSs, nor between ROs and
                  ASs.

                

              

            

          

        

        
FI : as far as I'm concerned, there are many
          more interactions than Oauth/XYZ/Xauth. Your view seems to be
          that it is simpler because AS are way less central, but it
          seems to me that RS are much more complex to implement
          correctly.=C2=A0

        

          

            

              

                
 

                  Before a threat model, a trust model is needed. Do we
                  have a trust model for XAuth ? 

                  Unfortunately not, since the word "trust" is ab=
sent in
                  the main body of draft-hardt-xauth-protocol-12.

              

            

          

        

        
FI : sorry but I don't need the word trust to=
 do
          threat modeling...=C2=A0

        

          

            

              

                
In this model, the trust relationships are as
                  follows:

                
    
                  
  • The user trusts its client.
    • 
                  
  • If a user has an account opened with an AS, then
                    he trusts that AS to deliver the requested and
                    genuine attributes into an access token.
    • 
                  
  • A RS may trust one or more ASs for one or more
                    types of attributes and for performing a
                    given operation.
    • 
                  
  • A RS may be administered remotely by one or more
                    RO.
    
                  
    • 
                

                
Note: for authentication, a RS may accept
                  either FIDO or one or more types of attributes from
                  one or more ASs.=C2=A0

              

            

          

        

        

          

            

              

                
 

                
Denis

                

                  

                    
Cheers,=C2=A0

                    
Fabien

                    

                  

                  

                

                

                  This is a new thread.

                
                

                  
 

                      Preamble: This model is quite different from the
                      XAuth model. 

                      In particular, a RO has no relationship with any
                      AS and a Client does not need to be associated
                      with any AS prior to any access to a RS.

                      

                      A key point of this model is that the user's
                      consent is handled locally by the Client and hence
                      no AS nor RS is handling a man machine interface 

                      for the user consent. This allows to support
                      locally the user consent for multiple ASs while
                      keeping all ASs ignorant about the choices of the
                      user 

                      made for accessing a particular 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=C2=A0
                          +------------+

                          =C2=A0=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0 |

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                          | Owner (RO) |

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+------------+

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
                          |

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
                          |

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
                          |

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 \=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
                          |

                          =C2=A0=C2=A0=C2=A0 +-----------+=C2=A0 =C2=A0=C2=A0=C2=A0+---------------+=C2=
=A0=C2=A0=C2=A0=C2=A0
                          +------------+

                          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---->|
                          Authorization |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
                          |

                          =C2=A0=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) |=C2=A0 Server (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=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0 |

                          =C2=A0=C2=A0=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=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=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 (1)=C2=A0=C2=A0=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=C2=A0 |=C2=A0 Consent=C2=A0
                          |<--------------------------|=C2=
=A0=C2=A0=C2=A0
                          (RS)=C2=A0=C2=A0=C2=A0 |

                          =C2=A0=C2=A0=C2=A0 |=C2=A0 element=C2=A0
                          |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                          |

                          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |---------------=
----------->|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
                          |------>

                          =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=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 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<-----------=
---------------|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
                          |<------

                          =C2=A0=C2=A0=C2=A0 +-----------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=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 flow of operations is as follows:

                      

                      The Client (which may have been previously
                      authenticated using FIDO) contacts the RS and
                      after some dialogue with the RS selects an
                      operation 

                      that it wants to perform on the RS (1a). Note that
                      it may also indicate directly the operation that
                      it wants to perform on the RS without any prior
                      dialogue. 

                      In return (1b), the RS informs the Client about
                      which attributes are needed by the RS for
                      performing the requested operation and from which
                      Attributes Servers 

                      they may be obtained. 

                      

                      This information is specifically marked to
                      indicate that it shall be handled by the "User
                      Consent element" from the Client. 

                      The presentation of that information is up to the
                      man machine interface supported by the "User
                      Consent element" from the Client. 

                      

                      The user can see which attributes are requested by
                      the RS for performing the requested operation and,
                      if it consents, the Client contacts one or more 

                      appropriate Authorization Servers (2a). The user
                      consent is hence captured locally by the Client
                      (i.e. there is no dialogue with any AS nor any
                      RS).

                      

                      When the Client got the access tokens from these
                      authorization servers (2b), it sends all of them
                      in a single request to the RS (3a).

                      

                      End of the story for a simple access

                  
 

                      Start of a subsequent story for a delegation case

                      

                      Let us now suppose that the RS is unable to fulfil
                      the request by its own and that it needs to
                      contact another RS. RS1 contacts RS2 (4a) and
                      indicates the operation 

                      that it wants to perform on RS2 (that operation
                      may not be the same as the original operation). In
                      return (4b), RS2 informs RS1 about which
                      attributes are needed 

                      by RS2 for performing the requested operation and
                      from which Attributes Servers they may be
                      obtained. RS1 forwards that information to the
                      Client. 

                      

                      This information is marked to indicate that it
                      shall be handled by the "User Consent element&qu=
ot;
                      from the Client. The presentation of that
                      information is up to the man machine 

                      interface from the Client. The user can see which
                      attributes are requested by RS2 for performing the
                      new requested operation and, if it consents, the
                      Client contacts one or more 

                      appropriate Authorization Servers. The user
                      consent is hence captured locally by the "User
                      Consent element" from the Client. (i.e. there is
                      no dialogue with any AS, nor RS1, nor RS2). 

                      

                      When the Client got the access token(s) from the
                      authorization server(s), it sends all of them in a
                      single request to RS1. RS1 then forwards the
                      additional access token(s) to RS2.

                      

                      

                      Some observations: 

                      

                      The user nor the Client are linked with any
                      particular AS. A user may use today an AS of the
                      Bank of America and may change tomorrow to the
                      Bank of Missouri. 

                      As soon as he will be registered with the Bank of
                      Missouri, he will be able to get access tokens
                      from the AS of the Bank of Missouri. The AS of
                      Bank of America 

                      has not been able to know where its access tokens
                      have been used. This will be the same for AS of
                      the Bank of Missouri. There is no need for any
                      direct dialogue 

                      between any AS and any RS at the time a client is
                      making an access. There is no need for any RO to
                      contact any AS.

                  
This model has been constructed
                      following a "Privacy by Design" approach.

                  Denis

                  

              

            

          

        

      

    

    


    

  


-- 

Txauth mailing list

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




--00000000000097306805aa8ab79d--


From nobody Thu Jul 16 01:46: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 A93E63A1206 for ; Thu, 16 Jul 2020 01:46:58 -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 eTDDLF9341De for ; Thu, 16 Jul 2020 01:46:56 -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 547033A1204 for ; Thu, 16 Jul 2020 01:46:56 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id d18so5211232ion.0 for ; Thu, 16 Jul 2020 01:46: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=GCLd+rU+cb1ibw7VQLDOwMfW+sv5OGhFGIRGyNnJsu4=; b=b9SfiBXPHzCD6lVwnTZSrbqOwHMi3oUQDyKLZK35FH8kyi4RfzqwACTvVgrUsWsFnW kIurOjgJHc5UuOPh4yykPxqHGB/GVxzrV2zrYUNrYZtgBKNRYQAa5/FPGpK5QiXYYuJC qt/DXuj51u6LmGaFtCfrXQY/67vcXe06LzguIX4M0Pi8Q0Jyx53WYO42k38yDhOuuen+ OsmrFVMk/0xQFjzFxamSS+D/Udu4FT2UoEmEnVdgInHh8X3ox0nUrHqUKPmdVkvdtfvQ qkuYrfTxHGXlEYSTZ/PX32U7m67TR1uNqkxPZCbwfxuVfBQwLMIRb0KID2MQx92o5lLB xY3A==
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=GCLd+rU+cb1ibw7VQLDOwMfW+sv5OGhFGIRGyNnJsu4=; b=QNkws7M6UvPY+/yWDgjQj9wXFkEKSb5OqWUZQ1AOrvc0J9Xu+ZijfH9axiD67ynwff N/2gmR4pnSn3zUT27+plsymtcqYBb8ne1O3PALEdgV2n8ALMne/ycFdmCG8MujQhbVgn B0XgHNwlspii/Ek6l8zYZM629vaF4D0o92jBgJ+1EFx9BIuQBIuo2NTAbOis2+pUFbDz xE9srVrrZqxiQPfno1G9QnzJKMxPrVqk5Xz+uJE6JqK41od8IBnIvE/9fo/FBPAOreQC gtVcysmbUlH+hspClGfqF05rHLc4M4Fx4tV9MJiDlWFziH0sE5eScv9X1/nFJ63BIrNm itzQ==
X-Gm-Message-State: AOAM530L8Bg+D9gVpR57gJKD2e8wD6+rcmVNmqQZpS4/SRUNt5f0uJHj ikT/T8ykffTapx+NxT31LgM0MjwvtDita3//Ess=
X-Google-Smtp-Source: ABdhPJyQStjxJStGaMNerDL0G4JJCHuw3xoqdf1qo4Ks/RPdQ/7qMRDSzo/+NyesmHNo46TEBn6nmFLHammiRYocELY=
X-Received: by 2002:a5d:9699:: with SMTP id m25mr3493249ion.74.1594889215430;  Thu, 16 Jul 2020 01:46:55 -0700 (PDT)
MIME-Version: 1.0
References:     
In-Reply-To: 
From: Fabien Imbault 
Date: Thu, 16 Jul 2020 10:46:44 +0200
Message-ID: 
To: Francis Pouatcha 
Cc: Dick Hardt , txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000024544905aa8b1561"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 16 Jul 2020 08:46:59 -0000

--00000000000024544905aa8b1561
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

That's interesting, however the important logic is actually implemented
within (5). And so for the reader, it might be quite difficult to
understand what we're after (compared to oauth2 for instance). So in my
view, this kind of schema has its place, but not at the start of the
document where we should primarily be concerned about explaining why
someone should read the document.

It's also not easy to understand :
- why we sometimes use different labels between requests and responses (for
instance, 5 and 6)
- sometimes we use "grant" and sometimes "authZ", and it doesn't seem very
clear what is the difference in use
A terminology section would be great to clarify.

If I understand correctly your remark in 5, you think the request/response
scheme (as in XYZ) may be misleading.
On the contrary, I think it allows support rich interaction scenarios (and
especially the ones you describe) with greater flexibility. For instance,
some would disagree with the assertion that the goal is for the GS to
gather consent (see discussion on putting that on client side). A fixed
interaction schema has the downside of not permitting other setups.

Fabien

On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha  wrote:

> Hello Dick,
>
>
>>>>
>>>>>
>>>>> 2. Abstract Protocol Flow
>>>>>
>>>>> I am missing an abstract protocol flow like the one defined in
>>>>> https://tools.ietf.org/html/rfc6749#section-1.2.
>>>>>
>>>>
>>>> That's an interesting point. GNAP also has identity claims, so the
>>>> abstract flow is somewhat different (there is no Authorization Grant f=
rom
>>>> the RO), and not all steps always happen. (there may not be steps (E) =
and
>>>> (F) with a Resource Server)
>>>>
>>>> Would you elaborate on what you think would be useful here, that is no=
t
>>>> in the specific flows?
>>>>
>>> A diagram that generalizes the steps, independently of interaction mode
>>> is essential for the reader's navigation of the rest of the document. T=
his
>>> is what #section-1.2 of RFC6749 does. I hope we can produce a similar
>>> diagram.
>>>
>>> A subsection of
>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>> could be defined for this.
>>>
>>
>> Interaction modes are one dimension where the steps could be generalized=
,
>> but some steps are optional. For example, the User may not interact with
>> the GS, and the GS may interact with the RO. The Client may only want
>> claims, and there would be no step of the Client calling the RS.
>>
>> A generalized diagram would need to include all optional steps so that i=
t
>> did not mislead a reader into thinking the diagram included all general
>> steps, but it does not seem that is what you are asking for as you wrote=
:
>>
>> A subsection of
>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>> could be defined for this."
>>
>> Perhaps you can share how you think the diagram would look?
>>
> find below my proposal of an abstract sequence diagram.
>
> +----+  +------+  +---+  +---+  +---+
> |User|  |Client|  |RS |  |GS |  |RO |
> +----+  +------+  +---+  +-+-+  +-+-+
>   |(1) Service Request     |      |
>   |-------->|       |      |      |
>   |         |(2) Service Intent   |
>   |         |------>|      |      |
>   |         |(3) AuthZ Challenge  |
>   |         |<------|      |      |
>   |         |(4) AuthZ Request    |
>   |         |------------->|      |
>   |         |       |      |(5) Consent Request
>   |         |       |      |----->|
>   |         |       |      |(6) Grant Consent
>   |         |       |      |<-----|
>   |         |(7) Grant Access (Token)
>   |         |<-------------|      |
>   |         |(8) Service Request (Token)
>   |         +------>+      |      |
>   |         |(9) Service Response |
>   |         |<------|      |      |
>   |(10) Service Response   |      |
>   +<--------|       |      |      |
>   +         +       +      +      +
>
> (1) Service Request: This is the service request sent by a User to the
> Client. This can be a simple file read request or even a complex payment
> initiation request.
>
> (2) Service Intent: In order to discover authorization requirements, the
> Client sends a service intent to the RS.
>
> (3) AuthZ Challenge: The response to a service intent request is generall=
y
> an AuthZ Challenge. The content of this AuthZ Challenge, can be an
> identification challenge, an AuthZ exemption, or details on requested
> AuthZ. The content AuthZ Challenge can be similar to the oAuth2 RAR.
>
> (4) AuthZ Request : the Client sends an AuthZ Request to the GS including
> the AuthZ Challenge. This request can be similar to the oAuth PAR request=
.
>
> (5) Requests Consent : GS sends consent request to RO.
> Remark: The abstract protocol flow does not display a response of the
> request (4) to the Client. This is IMO a general misunderstanding. This
> protocol wants the GS to collect a consent from the RO.
> - In the case of a "redirect interaction", GS will use transport
> infrastructure provided by the Client to instruct the User to send the RO
> to the GS (in most cases, user and RO are identical).
> - In the case of a "decoupled interaction", GS will directly contact RO
> and collect consent in a direct interaction with the RO (see CIBA).
> - In the case of an "embedded interaction", GS will allow the Client to
> directly collect the Consent of the RO in a direct interaction with the
> User.
>
> (6) Grant Consent : RO return a Consent Grant to GS.
>
> (7) Grant Access : GS produces the corresponding access token and returns
> it to Client.
>
> (8) Service Request : Client uses the access token to send the service
> request to RS.
>
> (9) and (10) are self explaining..
>
> One of our upcoming exercises will be to challenge this abstract protocol
> flow with existing interactions (and if possible associated use cases) to
> see if we are missing something. After an agreement on the abstract
> protocol flow we can make sure each interaction provides a mapping to ste=
p
> 1 to 10.
>
> I will strip the rest of the post here. And bring further responses in
> separate mails.
>
> Best regards.
> /Francis
>
>> =E1=90=A7
>>
> --
> 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
>

--00000000000024544905aa8b1561
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,=C2=A0

That's interesting, howev=
er the important logic is actually implemented within (5). And so for the r=
eader, it might be quite difficult to understand what we're after (comp=
ared to oauth2 for instance). So in my view, this kind of schema has its pl=
ace, but not at the start of the document where we should primarily be conc=
erned about explaining why someone should read the document.

=

It's also not easy to understand :=C2=A0
- why we =
sometimes use different labels between requests and responses (for instance=
, 5 and 6)
- sometimes we use "grant" and sometimes &qu=
ot;authZ", and it doesn't seem very clear what is the difference i=
n use
A terminology section would be great to clarify.
=

If I understand correctly your remark in 5, you think the re=
quest/response scheme (as in XYZ) may be misleading.=C2=A0
On the=
 contrary, I think it allows support rich interaction scenarios (and especi=
ally the ones you describe) with greater flexibility. For instance, some wo=
uld disagree with the assertion that the goal is for the GS to gather conse=
nt (see discussion on putting that on client side). A fixed interaction sch=
ema has the downside of not permitting other setups.

Fabien

On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha <fpo=3D=
40adorsys.de@dmarc.ietf.org<=
/a>> wrote:
<=
div dir=3D"ltr">
Hello Dick,

=


Interaction modes are one dimension where the steps could be generaliz=
ed, but some steps are optional. For example, the User may not interact wit=
h the GS, and the GS may interact with the RO. The Client may only want cla=
ims, and there would be no step of the Client calling the RS.
<=
div>
A generalized diagram would need to include all optional steps so that it =
did not mislead a reader into thinking the diagram included all general ste=
ps, but it does not seem that is what you are asking for as you wrote:

A subsection of=C2=A0https://tools.ietf.=
org/html/draft-hardt-xauth-protocol-12#section-1.1 could be defined for=
 this."

Perhaps you can share how you think the diag=
ram would look?
find below my proposal of an abstract sequence diagram.

+----+ =C2=A0+------+ =C2=A0+---+ =C2=A0+---+ =C2=A0+---+
|User| =C2=
=A0|Client| =C2=A0|RS | =C2=A0|GS | =C2=A0|RO |
+----+ =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 |(2) Service Intent =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=
=A0 =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) AuthZ Challenge =C2=A0|
=C2=A0 | =
=C2=A0 =C2=A0 =C2=A0 =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) AuthZ 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|(5) Consent 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|(6) Grant 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 |(7) Grant Access (Token)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 |<-------------| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 |(8) Service Request (Token)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 +------>+ =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(9) Service Response |
=C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 |<------| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=
=A0|
=C2=A0 |(10) Service Response =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=
=A0 +<--------| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=
=A0 =C2=A0|
=C2=A0 + =C2=A0 =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) Service=
 Request: This is the service request sent by a User to the Client. This ca=
n be a simple file read request or even a complex payment initiation reques=
t.

(2) Service Intent: In order to discover authorization req=
uirements, the Client sends a service intent to the RS.

(3) A=
uthZ Challenge: The response to a service intent request is generally an Au=
thZ Challenge. The content of this AuthZ Challenge, can be an identificatio=
n challenge, an AuthZ exemption, or details on requested AuthZ. The content=
 AuthZ Challenge can be similar to the oAuth2 RAR.

(4) AuthZ =
Request : the Client sends an AuthZ Request to the GS including the AuthZ C=
hallenge. This request can be similar to the oAuth PAR request.

(5) Requests Consent : GS sends consent request to RO.=C2=A0
Remark: The abstract protocol flow does not =
display a response of the request (4) to the Client. This is IMO a general =
misunderstanding. This protocol wants the GS to collect a consent from the =
RO.=C2=A0
- In the case of a &quo=
t;redirect interaction", GS will use transport infrastructure provided=
 by the Client to instruct the User to send the RO to the GS (in most cases=
, user and RO are identical).
- I=
n the case of a "decoupled interaction", GS will directly contact=
 RO and collect consent in a direct interaction with the RO (see CIBA).
- In the case of an "embedded i=
nteraction", GS will allow the Client to directly collect the Consent =
of the RO in a direct interaction with the User.

(=
6) Grant Consent : RO return a Consent Grant to GS.

(7) Grant=
 Access : GS produces the corresponding access token and returns it to Clie=
nt.

(8) Service Request : Client uses the access token to sen=
d the service request to RS.

=

(9) and (10) are self explaining=
..

One of our upcoming=C2=A0exercises will be to challenge th=
is abstract protocol flow with existing interactions=C2=A0(and if possible =
associated use cases) to see if we are missing something. After an agreemen=
t on the abstract protocol flow we can make sure each interaction provides =
a mapping to step 1 to 10.

I will strip the rest=
 of the post here. And bring further responses in separate mails.

Best regards.
/Francis=C2=A0=C2=A0
<=
div>
<=
/div>


3D""=E1=90=
=A7
-- 
<=
/font>
Francis P=
ouatcha
Co-Founder and Technical =
Lead
adorsys GmbH & Co. KG

-- 

Txauth mailing list

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




--00000000000024544905aa8b1561--


From nobody Thu Jul 16 05:10: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 6D8033A0477 for ; Thu, 16 Jul 2020 05:10:22 -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 Czn9Pwvx36sw for ; Thu, 16 Jul 2020 05:10:20 -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 D70013A0403 for ; Thu, 16 Jul 2020 05:10:19 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id j18so10075264wmi.3 for ; Thu, 16 Jul 2020 05:10: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=FXiuf3rVkdLXyPA3Y/sU9mUVGWHhqfSgjB8SkhJI4O8=; b=CXnlbX6F8NAb37zS7LdJ5rg059Eybi4xIZhkxVmIi/K8qPFYyv8guKYFYYasAzimh/ iuDyLqkkWFTw7tUhllZ/V3dOe6yoXh/kdNUXnDu8Pl1pa3ktkSW+6N+KEv8Jf4jRknXa oKSwxqb+LhQ+mxy9lNTu142wsNGm2QfHWR43w=
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=FXiuf3rVkdLXyPA3Y/sU9mUVGWHhqfSgjB8SkhJI4O8=; b=rpF/PEPZ4Ur59pywZpDRdUpWocj+p10lLqnd5iRulHbikIiHMrotb1OlFVCWIRkqz7 +4KOsVsaHVxkNWDPp5bdE+XCxYM5Gk2KsQNtOFb0Oz+BPrHIyWOgWVoan+ktnamjRUFW igshOaWfkdCi+QC3ZqA06KcDq1CrWvFdrCG4UtI5cI19Bj1hwoG8/sldnVbatL+9cYAs l4PiX7QTN7PhQ3GsqT4pwsewbSKiP0HgaALutLckG4BkvaIdNVT491abGcLUhisKafNd RijqtwhJtRF6Zk2jJu3XQHj522nyv3cY6aYS0GxE6/xxWa66PdHwD5du4EiEG2KJm9U7 KTeA==
X-Gm-Message-State: AOAM531Cmx7MviCD6fd3L0F2Dxy1aEGS/iUCPYkVgvH7UQ7pb3raQEII vmvN40D3xPDwZz4lA9KoyP4bqaq/AV7FwhJ0OPj1jw==
X-Google-Smtp-Source: ABdhPJyXBmsaLmLxCqS5pY9mWIDiLqqFuvJFJiVvo0UchET3vawNSejQXcggprhSju5Gpx2olldULk8cT0zRFzcrMuY=
X-Received: by 2002:a05:600c:294a:: with SMTP id n10mr3952744wmd.38.1594901418198;  Thu, 16 Jul 2020 05:10:18 -0700 (PDT)
MIME-Version: 1.0
References:      
In-Reply-To: 
From: Francis Pouatcha 
Date: Thu, 16 Jul 2020 08:10:07 -0400
Message-ID: 
To: Fabien Imbault 
Cc: Dick Hardt , txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007bdfd805aa8decb5"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 16 Jul 2020 12:10:22 -0000

--0000000000007bdfd805aa8decb5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Fabian,

On Thu, Jul 16, 2020 at 4:47 AM Fabien Imbault 
wrote:

> Hi,
>
> That's interesting, however the important logic is actually implemented
> within (5). And so for the reader, it might be quite difficult to
> understand what we're after (compared to oauth2 for instance). So in my
> view, this kind of schema has its place, but not at the start of the
> document where we should primarily be concerned about explaining why
> someone should read the document.
>
> It's also not easy to understand :
> - why we sometimes use different labels between requests and responses
> (for instance, 5 and 6)
>
Will need support in drafting the correct terms. The main purpose of this
diagram is to help sharpen the definition of terms and verbs used in the
draft.

- sometimes we use "grant" and sometimes "authZ", and it doesn't seem very
> clear what is the difference in use
>
IMO: the granting is the process of given permission.
- RO can grant his Consent to the User or Client
- GS can turn the RO Grant into an AuthZ.
- Client can use AuthZ to access a Resource.

A terminology section would be great to clarify.
>
Yes. There is a terminology section in there. We need to bring the wissing
words into the list and sharpen those already there.

>
> If I understand correctly your remark in 5, you think the request/respons=
e
> scheme (as in XYZ) may be misleading.
>
No. XYZ does IMO exactly  that. Just try to be more abstract for a better
description of the models.


> On the contrary, I think it allows support rich interaction scenarios (an=
d
> especially the ones you describe) with greater flexibility.
>
Flexibility shall not be put ahead of formal correctness.


> For instance, some would disagree with the assertion that the goal is for
> the GS to gather consent (see discussion on putting that on client side).=
 A
> fixed interaction schema has the downside of not permitting other setups.
>
This discussion is the result of the lack of sharp terminology. Most of the
time mixing up gathering consent (the act) and the way consent is gathered
and transported from RO to GS (the interaction).
/Francis


> Fabien
>
> On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha  40adorsys.de@dmarc.ietf.org> wrote:
>
>> Hello Dick,
>>
>>
>>>>>
>>>>>>
>>>>>> 2. Abstract Protocol Flow
>>>>>>
>>>>>> I am missing an abstract protocol flow like the one defined in
>>>>>> https://tools.ietf.org/html/rfc6749#section-1.2.
>>>>>>
>>>>>
>>>>> That's an interesting point. GNAP also has identity claims, so the
>>>>> abstract flow is somewhat different (there is no Authorization Grant =
from
>>>>> the RO), and not all steps always happen. (there may not be steps (E)=
 and
>>>>> (F) with a Resource Server)
>>>>>
>>>>> Would you elaborate on what you think would be useful here, that is
>>>>> not in the specific flows?
>>>>>
>>>> A diagram that generalizes the steps, independently of interaction mod=
e
>>>> is essential for the reader's navigation of the rest of the document. =
This
>>>> is what #section-1.2 of RFC6749 does. I hope we can produce a similar
>>>> diagram.
>>>>
>>>> A subsection of
>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>>> could be defined for this.
>>>>
>>>
>>> Interaction modes are one dimension where the steps could be
>>> generalized, but some steps are optional. For example, the User may not
>>> interact with the GS, and the GS may interact with the RO. The Client m=
ay
>>> only want claims, and there would be no step of the Client calling the =
RS.
>>>
>>> A generalized diagram would need to include all optional steps so that
>>> it did not mislead a reader into thinking the diagram included all gene=
ral
>>> steps, but it does not seem that is what you are asking for as you wrot=
e:
>>>
>>> A subsection of
>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>> could be defined for this."
>>>
>>> Perhaps you can share how you think the diagram would look?
>>>
>> find below my proposal of an abstract sequence diagram.
>>
>> +----+  +------+  +---+  +---+  +---+
>> |User|  |Client|  |RS |  |GS |  |RO |
>> +----+  +------+  +---+  +-+-+  +-+-+
>>   |(1) Service Request     |      |
>>   |-------->|       |      |      |
>>   |         |(2) Service Intent   |
>>   |         |------>|      |      |
>>   |         |(3) AuthZ Challenge  |
>>   |         |<------|      |      |
>>   |         |(4) AuthZ Request    |
>>   |         |------------->|      |
>>   |         |       |      |(5) Consent Request
>>   |         |       |      |----->|
>>   |         |       |      |(6) Grant Consent
>>   |         |       |      |<-----|
>>   |         |(7) Grant Access (Token)
>>   |         |<-------------|      |
>>   |         |(8) Service Request (Token)
>>   |         +------>+      |      |
>>   |         |(9) Service Response |
>>   |         |<------|      |      |
>>   |(10) Service Response   |      |
>>   +<--------|       |      |      |
>>   +         +       +      +      +
>>
>> (1) Service Request: This is the service request sent by a User to the
>> Client. This can be a simple file read request or even a complex payment
>> initiation request.
>>
>> (2) Service Intent: In order to discover authorization requirements, the
>> Client sends a service intent to the RS.
>>
>> (3) AuthZ Challenge: The response to a service intent request is
>> generally an AuthZ Challenge. The content of this AuthZ Challenge, can b=
e
>> an identification challenge, an AuthZ exemption, or details on requested
>> AuthZ. The content AuthZ Challenge can be similar to the oAuth2 RAR.
>>
>> (4) AuthZ Request : the Client sends an AuthZ Request to the GS includin=
g
>> the AuthZ Challenge. This request can be similar to the oAuth PAR reques=
t.
>>
>> (5) Requests Consent : GS sends consent request to RO.
>> Remark: The abstract protocol flow does not display a response of the
>> request (4) to the Client. This is IMO a general misunderstanding. This
>> protocol wants the GS to collect a consent from the RO.
>> - In the case of a "redirect interaction", GS will use transport
>> infrastructure provided by the Client to instruct the User to send the R=
O
>> to the GS (in most cases, user and RO are identical).
>> - In the case of a "decoupled interaction", GS will directly contact RO
>> and collect consent in a direct interaction with the RO (see CIBA).
>> - In the case of an "embedded interaction", GS will allow the Client to
>> directly collect the Consent of the RO in a direct interaction with the
>> User.
>>
>> (6) Grant Consent : RO return a Consent Grant to GS.
>>
>> (7) Grant Access : GS produces the corresponding access token and return=
s
>> it to Client.
>>
>> (8) Service Request : Client uses the access token to send the service
>> request to RS.
>>
>> (9) and (10) are self explaining...
>>
>> One of our upcoming exercises will be to challenge this abstract protoco=
l
>> flow with existing interactions (and if possible associated use cases) t=
o
>> see if we are missing something. After an agreement on the abstract
>> protocol flow we can make sure each interaction provides a mapping to st=
ep
>> 1 to 10.
>>
>> I will strip the rest of the post here. And bring further responses in
>> separate mails.
>>
>> Best regards.
>> /Francis
>>
>>> =E1=90=A7
>>>
>> --
>> 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/

--0000000000007bdfd805aa8decb5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Fabian,

On Thu, Jul 16, 2020 at 4:47=
 AM Fabien Imbault <fabien.i=
mbault@gmail.com> wrote:
Hi,=C2=A0

That's in=
teresting, however the important logic is actually implemented within (5). =
And so for the reader, it might be quite difficult to understand what we=
9;re after (compared to oauth2 for instance). So in my view, this kind of s=
chema has its place, but not at the start of the document where we should p=
rimarily be concerned about explaining why someone should read the document=
.

It's also not easy to understand :=C2=A0
- why we sometimes use different labels between requests and respons=
es (for instance, 5 and 6)
Will need support i=
n drafting the correct terms. The main purpose of this diagram=C2=A0is to h=
elp sharpen the definition of terms and verbs used in the draft.
=

- sometimes we use "grant" and sometimes "authZ"=
, and it doesn't seem very clear what is the difference in use
IMO: the granting is the process of given permission.<=
/div>
- RO can grant his Consent to the User or Client
- GS c=
an turn the RO Grant into an AuthZ.
- Client can use AuthZ to acc=
ess a Resource.

A terminology section would be great to cl=
arify.
Yes. There is a terminology section in =
there. We need to bring the wissing words into the list and sharpen those a=
lready there.=C2=A0
=


If I understand correctly your remark =
in 5, you think the request/response scheme (as in XYZ) may be misleading.=
=C2=A0
No. XYZ does IMO exactly=C2=A0 that. Ju=
st try to be more abstract for a better description of the models.
=C2=A0
On the contrary, I think it allows support rich interaction scen=
arios (and especially the ones you describe) with greater flexibility. 
Flexibility shall not be put ahead of formal corr=
ectness.
=C2=A0
For instance, some would disagree with the asse=
rtion that the goal is for the GS to gather consent (see discussion on putt=
ing that on client side). A fixed interaction schema has the downside of no=
t permitting other setups.
This discussion is =
the result of the lack of sharp terminology. Most of the time mixing up gat=
hering consent (the act) and the way consent is gathered and transported fr=
om RO to GS (the interaction).
/Francis


Fabien

On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha <fpo=
=3D40adors=
ys.de@dmarc.ietf.org> wrote:
Hello Dick,

=

=C2=A0

2. Abstract Protocol Flow







I am missing an abstract protocol flow like the one de=
fined in https://tools.ietf.org/html/rfc6749#section-1.2.

That's an interesting point. G=
NAP also has identity claims, so the abstract flow is somewhat different (t=
here is no Authorization Grant from the RO), and not all steps always happe=
n. (there may not be steps (E) and (F) with a Resource Server)
=


Would you elaborate on what you think would be useful here, that is not i=
n the specific flows?
A diagram that generalizes the steps, independently of inter=
action mode is essential for the reader's navigation of the rest of the=
 document.=C2=A0This is what=C2=A0#section-1.2 of RFC6749 does. I hope we c=
an produce a similar diagram.
A subsection of=C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#se=
ction-1.1 could be defined for this.

Interaction modes are one dimension where the steps could be generaliz=
ed, but some steps are optional. For example, the User may not interact wit=
h the GS, and the GS may interact with the RO. The Client may only want cla=
ims, and there would be no step of the Client calling the RS.
<=
div>
A generalized diagram would need to include all optional steps so that it =
did not mislead a reader into thinking the diagram included all general ste=
ps, but it does not seem that is what you are asking for as you wrote:

A subsection of=C2=A0https://tools.ietf.=
org/html/draft-hardt-xauth-protocol-12#section-1.1 could be defined for=
 this."

Perhaps you can share how you think the diag=
ram would look?
find below my proposal of an abstract sequence diagram.

+----+ =C2=A0+------+ =C2=A0+---+ =C2=A0+---+ =C2=A0+---+
|User| =C2=
=A0|Client| =C2=A0|RS | =C2=A0|GS | =C2=A0|RO |
+----+ =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 |(2) Service Intent =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=
=A0 =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) AuthZ Challenge =C2=A0|
=C2=A0 | =
=C2=A0 =C2=A0 =C2=A0 =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) AuthZ 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|(5) Consent 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|(6) Grant 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 |(7) Grant Access (Token)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 |<-------------| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 |(8) Service Request (Token)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 +------>+ =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(9) Service Response |
=C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 |<------| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=
=A0|
=C2=A0 |(10) Service Response =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=
=A0 +<--------| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=
=A0 =C2=A0|
=C2=A0 + =C2=A0 =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) Service=
 Request: This is the service request sent by a User to the Client. This ca=
n be a simple file read request or even a complex payment initiation reques=
t.

(2) Service Intent: In order to discover authorization req=
uirements, the Client sends a service intent to the RS.

(3) A=
uthZ Challenge: The response to a service intent request is generally an Au=
thZ Challenge. The content of this AuthZ Challenge, can be an identificatio=
n challenge, an AuthZ exemption, or details on requested AuthZ. The content=
 AuthZ Challenge can be similar to the oAuth2 RAR.

(4) AuthZ =
Request : the Client sends an AuthZ Request to the GS including the AuthZ C=
hallenge. This request can be similar to the oAuth PAR request.

(5) Requests Consent : GS sends consent request to RO.=C2=A0
Remark: The abstract protocol flow does not =
display a response of the request (4) to the Client. This is IMO a general =
misunderstanding. This protocol wants the GS to collect a consent from the =
RO.=C2=A0
- In the case of a &quo=
t;redirect interaction", GS will use transport infrastructure provided=
 by the Client to instruct the User to send the RO to the GS (in most cases=
, user and RO are identical).
- I=
n the case of a "decoupled interaction", GS will directly contact=
 RO and collect consent in a direct interaction with the RO (see CIBA).
- In the case of an "embedded i=
nteraction", GS will allow the Client to directly collect the Consent =
of the RO in a direct interaction with the User.

(=
6) Grant Consent : RO return a Consent Grant to GS.

(7) Grant=
 Access : GS produces the corresponding access token and returns it to Clie=
nt.

(8) Service Request : Client uses the access token to sen=
d the service request to RS.

=

(9) and (10) are self explaining=
...

One of our upcoming=C2=A0exercises will be to challenge t=
his abstract protocol flow with existing interactions=C2=A0(and if possible=
 associated use cases) to see if we are missing something. After an agreeme=
nt on the abstract protocol flow we can make sure each interaction provides=
 a mapping to step 1 to 10.

<=
/font>
I will strip the res=
t of the post here. And bring further responses in separate mails.

Best regards.
/Francis=C2=A0=C2=A0
<=
div>
<=
/div>


3D""=E1=90=
=A7
-- 
<=
/font>
Francis P=
ouatcha
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/


--0000000000004b5c0605aa8f7318--


From nobody Thu Jul 16 08:24: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 40DFC3A0AC3 for ; Thu, 16 Jul 2020 08:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 lk6ttenJro5b for ; Thu, 16 Jul 2020 08:24: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 6AEA53A0AC4 for ; Thu, 16 Jul 2020 08:24:45 -0700 (PDT)
Received: from [192.168.1.7] (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 06GFOe9Q001008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jul 2020 11:24:41 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_2B47E552-290A-4954-8C0C-7EAA73E006DF"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 16 Jul 2020 11:24:40 -0400
In-Reply-To: 
Cc: Mike Varley , "txauth@ietf.org" , Mike Jones , Dick Hardt 
To: Fabien Imbault 
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 16 Jul 2020 15:24:48 -0000

--Apple-Mail=_2B47E552-290A-4954-8C0C-7EAA73E006DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Exactly =E2=80=94 when we start to look at it as managing the lifecycle =
of a piece of software, instead of a registration at the AS, we can =
start thinking in different terms what =E2=80=9Ctrusting=E2=80=9D the =
client means in the context of what the client is doing. That trust =
could come from some kind of signed attestation about the software (like =
the OAuth 2 DynReg software statement), or it could come from some =
externally fetchable item (like a Solid WebID, a DID, or the OIDC =
Federation extension), or it could come from someone sitting at a =
console and typing in information and getting back an identifier. And =
none of these need to pretend to be a global =E2=80=9Cclient id=E2=80=9D =
for it to work. The world of clients is much more diverse than OAuth 2 =
likes to admit, and we see that with trying to nail down a =
=E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =
=E2=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =
=E2=80=9Cautomatic=E2=80=9D vs. =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 =
any number of other things.=20

OAuth 2 only needs client IDs because the front channel needs a way to =
pass client identifiers when the client can=E2=80=99t authenticate =
itself directly. We tried to get rid of this restriction with PAR and =
JAR together, but there turned out to be corner cases in OAuth 2=E2=80=99s=
 world that still needed client_id, and implementations assumed it would =
be there anyway.=20

In GNAP, we can avoid that problem from the beginning by looking at the =
model differently and understanding where we=E2=80=99re coming from, and =
why.

 =E2=80=94 Justin

> On Jul 16, 2020, at 3:49 AM, Fabien Imbault  =
wrote:
>=20
> +1 on that.
>=20
> We can then see it more as life cycle management of the client than =
registration per say, and this comes with many benefits compared to the =
current client_id.
>=20
> Fabien
>=20
> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer > wrote:
> I not only agree with Mike Jones that =E2=80=9Cautomatic =
registration=E2=80=9D should be part of the process, but I would argue =
that that kind of model should be a default mode of operation. If you =
have an identifier that you can send to short-circuit that, great! But =
we should focus on having the capability of inlining a lot of this =
information wherever possible. This is already the direction that the =
input proposals are heading.
>=20
> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope for =
the protocol in general, and since both XYZ and Xauth have mechanisms =
that allow the client to present a key and get back an identifier that =
it can use in the future we have something equivalent.=20
>=20
> But I think there=E2=80=99s a little more to it than that: Ultimately, =
I think we should question thinking in terms of =E2=80=9Cregistration=E2=80=
=9D, a model which has hampered the OAuth 2 model in a lot of use cases. =
For example, the federation draft Mike Jones references below hacks the =
=E2=80=9Cclient_id=E2=80=9D parameter and makes it point to a document =
that the AS has to fetch. This construct is done for two reasons: (1) =
Oauth requires a =E2=80=9Cclient_id=E2=80=9D in the request and (2) =
it=E2=80=99s difficult to pass information by value to the AS due to =
front-channel restrictions. Since we=E2=80=99re defining a new protocol, =
we don=E2=80=99t need to hack that functionality into a =E2=80=9Cclient =
ID=E2=80=9D or equivalent and instead we can pass that information =
directly in the protocol. If we don=E2=80=99t assume that the client =
*has* to have a client ID equivalent, but it *can* have one in a set of =
defined circumstances, then I think we are in a much better spot. This =
is the reasoning for XYZ=E2=80=99s model of having clients identified by =
the key, and that key can potentially be passed by a reference =
identifier.
>=20
> I think all of the use cases that Mike Varley presents below are all =
valid directions, with the caveat that we shouldn=E2=80=99t assume a =
client should be presenting an ID at all steps. Mechanisms like software =
statements should be presentable apart from a client ID, as should =
on-device keys. We=E2=80=99re probably going to want extensions for =
device posture and other forms of attestation as well.
>=20
> This is one of the domains that I think we can clearly surpass OAuth =
2=E2=80=99s flexibility and capabilities if we are willing to look past =
OAuth 2=E2=80=99s assumptions of what=E2=80=99s needed inline in the =
protocol.=20
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 14, 2020, at 1:54 PM, Mike Varley > wrote:
>>=20
>> Is client registration in scope for the protocol?
>> =20
>> A generic way of handling clients (via ID or Handle or Key or =
whatever) is to have processing rule on the AS such as =E2=80=9Cif the =
AS recognizes the client ID (and authentication of that client ID) then =
it may process the request on behalf of that client. If the AS does not =
recognize the client ID, it must treat this as a new client registration =
and evaluate any authorization evidence the client provides before =
enabling the client and mapping policies to that client=E2=80=9D (this =
means dynamic or automatic clients need to provide additional assertions =
/ software statements whatever to register their ID.
>> =20
>> Something like this allows for very flexible systems:
>> System A can be unknown to the AS but can dynamically registered each =
time with an appropriate software statement
>> System B can have a fairly stable client ID at the AS, but rotate =
that ID every month through automatic registration (with an assertion it =
got from the AS during a pre-registration for example)
>> System C can pre-register with the AS for a client ID because it =
doesn=E2=80=99t deal with software statements etc=E2=80=A6
>> =E2=80=A6
>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing =
client IDs because it will always just rely on the software statements.
>> =20
>> I think a client registration protocol that allows these scenarios =
would be very useful in GNAP, but hopefully avoiding having to define =
what =E2=80=98evidence=E2=80=99 the AS needs to accept for each =
scenario.
>> =20
>> Thanks,
>> =20
>> MV
>> =20
>> From: Txauth > on behalf of Mike Jones =
>
>> Date: Tuesday, July 14, 2020 at 12:18 PM
>> To: Dick Hardt >, =
"txauth@ietf.org " >, Justin Richer >
>> Subject: Re: [Txauth] Key handle vs client id & handle
>> =20
>> I agree that there are significant differences between statically and =
dynamically registered clients and that=E2=80=99s appropriate to be able =
to syntactically differentiate between them at runtime.  For one thing, =
the resource requirements at the authorization server can be very =
different.
>> =20
>> We should also be thinking about how to include what the OpenID =
Connect Federation spec =
https://openid.net/specs/openid-connect-federation-1_0.html =
 calls =
=E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client encode a =
registration request reference in the client ID, so no static or dynamic =
registration even occurs.  See =
https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section=
.9.1 =
.
>> =20
>>                                                        -- Mike
>> =20
>> From: Dick Hardt >=20=

>> Sent: Friday, July 10, 2020 1:17 PM
>> To: txauth@ietf.org ; Justin Richer =
>; Mike Jones =
>
>> Subject: Key handle vs client id & handle
>> =20
>> + Mike as he had interest in this topic
>> =20
>> My understanding is that an existing OAuth 2 client would use their =
current client id as their key handle, and a dynamic client (one that =
was not pre-registered) would be given a key handle by the AS.
>> =20
>> There are potentially some significant differences between a =
registered client, and a dynamic client to an AS.
>> =20
>> The AS is likely to know the identity of a registered client, and =
have different policies between the two types of clients. For example, a =
registered client may have access to a 'write" scope, while a dynamic =
client does not.
>> =20
>> The AS may have 100s or 1000s of registered clients, but a dynamic =
client may have 10Ms or 100Ms of instances, which may dictate separate =
storage services. Additionally, internal to the AS, which systems can =
write to the registered client store is going to be different than the =
dynamic client store.
>> =20
>> In XYZ, subsequent calls to the AS, both registered clients and =
dynamic clients pass a key handle, so there is no easy way to =
differentiate between the two.
>> =20
>> While the AS could embed semantics in the key handle identifier to =
indicate which identifiers are pre-registered vs dynamic, there are many =
cases where the AS does need to know the difference, so making the =
difference a feature of GNAP seems like a better path.
>> =20
>> =20
>> 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.
>>=20
>=20
> --=20
> Txauth mailing list
> Txauth@ietf.org 
> https://www.ietf.org/mailman/listinfo/txauth =



--Apple-Mail=_2B47E552-290A-4954-8C0C-7EAA73E006DF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Exactly =E2=80=94 when we start to look at it as managing the =
lifecycle of a piece of software, instead of a registration at the AS, =
we can start thinking in different terms what =E2=80=9Ctrusting=E2=80=9D =
the client means in the context of what the client is doing. That trust =
could come from some kind of signed attestation about the software (like =
the OAuth 2 DynReg software statement), or it could come from some =
externally fetchable item (like a Solid WebID, a DID, or the OIDC =
Federation extension), or it could come from someone sitting at a =
console and typing in information and getting back an identifier. And =
none of these need to pretend to be a global =E2=80=9Cclient id=E2=80=9D =
for it to work. The world of clients is much more diverse than OAuth 2 =
likes to admit, and we see that with trying to nail down a =
=E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =
=E2=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =
=E2=80=9Cautomatic=E2=80=9D vs. =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 =
any number of other things. 

OAuth 2 only needs client IDs because =
the front channel needs a way to pass client identifiers when the client =
can=E2=80=99t authenticate itself directly. We tried to get rid of this =
restriction with PAR and JAR together, but there turned out to be corner =
cases in OAuth 2=E2=80=99s world that still needed client_id, and =
implementations assumed it would be there anyway. 

In GNAP, we can avoid =
that problem from the beginning by looking at the model differently and =
understanding where we=E2=80=99re coming from, and why.

 =E2=80=94 =
Justin

On Jul 16, 2020, at 3:49 AM, Fabien Imbault =
<fabien.imbault@gmail.com> wrote:

+1 on that.

We can then see it more as life cycle =
management of the client than registration per say, and this comes with =
many benefits compared to the current client_id.

Fabien

On Tue, Jul =
14, 2020 at 9:32 PM Justin Richer <jricher@mit.edu> wrote:
I not only agree with Mike Jones that =
=E2=80=9Cautomatic registration=E2=80=9D should be part of the process, =
but I would argue that that kind of model should be a default mode of =
operation. If you have an identifier that you can send to short-circuit =
that, great! But we should focus on having the capability of inlining a =
lot of this information wherever possible. This is already the direction =
that the input proposals are heading.

So I kind-of agree that =
=E2=80=9Cregistration=E2=80=9D is in scope for the protocol in general, =
and since both XYZ and Xauth have mechanisms that allow the client to =
present a key and get back an identifier that it can use in the future =
we have something equivalent. 

But I think there=E2=80=99s a little =
more to it than that: Ultimately, I think we should question thinking in =
terms of =E2=80=9Cregistration=E2=80=9D, a model which has hampered the =
OAuth 2 model in a lot of use cases. For example, the federation draft =
Mike Jones references below hacks the =E2=80=9Cclient_id=E2=80=9D =
parameter and makes it point to a document that the AS has to fetch. =
This construct is done for two reasons: (1) Oauth requires a =
=E2=80=9Cclient_id=E2=80=9D in the request and (2) it=E2=80=99s =
difficult to pass information by value to the AS due to front-channel =
restrictions. Since we=E2=80=99re defining a new protocol, we don=E2=80=99=
t need to hack that functionality into a =E2=80=9Cclient ID=E2=80=9D or =
equivalent and instead we can pass that information directly in the =
protocol. If we don=E2=80=99t assume that the client *has* to have a =
client ID equivalent, but it *can* have one in a set of defined =
circumstances, then I think we are in a much better spot. This is the =
reasoning for XYZ=E2=80=99s model of having clients identified by the =
key, and that key can potentially be passed by a reference =
identifier.

I =
think all of the use cases that Mike Varley presents below are all valid =
directions, with the caveat that we shouldn=E2=80=99t assume a client =
should be presenting an ID at all steps. Mechanisms like software =
statements should be presentable apart from a client ID, as should =
on-device keys. We=E2=80=99re probably going to want extensions for =
device posture and other forms of attestation as well.

This is one of the =
domains that I think we can clearly surpass OAuth 2=E2=80=99s =
flexibility and capabilities if we are willing to look past OAuth 2=E2=80=99=
s assumptions of what=E2=80=99s needed inline in the =
protocol. 

 =E2=80=94 Justin
On Jul =
14, 2020, at 1:54 PM, Mike Varley <mike.varley@securekey.com> wrote:

Is =
client registration in scope for the protocol?
 
A =
generic way of handling clients (via ID or Handle or Key or whatever) is =
to have processing rule on the AS such as =E2=80=9Cif the AS recognizes =
the client ID (and authentication of that client ID) then it may process =
the request on behalf of that client. If the AS does not recognize the =
client ID, it must treat this as a new client registration and evaluate =
any authorization evidence the client provides before enabling the =
client and mapping policies to that client=E2=80=9D (this means dynamic =
or automatic clients need to provide additional assertions / software =
statements whatever to register their ID.
 
Something like this allows for very flexible systems:
System =
A can be unknown to the AS but can dynamically registered each time with =
an appropriate software statement
System =
B can have a fairly stable client ID at the AS, but rotate that ID every =
month through automatic registration (with an assertion it got from the =
AS during a pre-registration for example)
System =
C can pre-register with the AS for a client ID because it doesn=E2=80=99t =
deal with software statements etc=E2=80=A6
=E2=80=A6=

And =
even =E2=80=98StatelessAS=E2=80=99 can operate by never storing client =
IDs because it will always just rely on the software statements.
 
I =
think a client registration protocol that allows these scenarios would =
be very useful in GNAP, but hopefully avoiding having to define what =
=E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
 
Thanks,
 
MV
 
From: Txauth <txauth-bounces@ietf.org> on behalf of Mike Jones =
<Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
Date: Tuesday, =
July 14, 2020 at 12:18 PM
To: Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
Subject: Re: [Txauth] Key =
handle vs client id & handle
 
I agree that there are =
significant differences between statically and dynamically registered =
clients and that=E2=80=99s appropriate to be able to syntactically =
differentiate between them at runtime.  For one thing, the resource =
requirements at the authorization server can be very different.
 
We should also =
be thinking about how to include what the OpenID Connect Federation =
spec https://openid.net/specs/openid-connect-federation-1_0.html=
 calls =E2=80=9CAutomatic =
Registration=E2=80=9D.  This lets the client encode a registration =
request reference in the client ID, so no static or dynamic registration =
even occurs.  See https://openid.net/specs/openid-connect-federation-1_0-12.html#=
rfc.section.9.1.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 
From: Dick Hardt <dick.hardt@gmail.com> 
Sent: Friday, =
July 10, 2020 1:17 PM
To: txauth@ietf.org; Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Subject: Key handle vs =
client id & handle
 
+ Mike as =
he had interest in this topic
 
My =
understanding is that an existing OAuth 2 client would use their current =
client id as their key handle, and a dynamic client (one that was not =
pre-registered) would be given a key handle by the AS.
 
There are =
potentially some significant differences between a registered client, =
and a dynamic client to an AS.
 
The AS is =
likely to know the identity of a registered client, and have different =
policies between the two types of clients. For example, a registered =
client may have access to a 'write" scope, while a dynamic client does =
not.
 
The AS =
may have 100s or 1000s of registered clients, but a dynamic client may =
have 10Ms or 100Ms of instances, which may dictate separate storage =
services. Additionally, internal to the AS, which systems can write to =
the registered client store is going to be different than the =
dynamic client store.
 
In XYZ, =
subsequent calls to the AS, both registered clients and dynamic clients =
pass a key handle, so there is no easy way to differentiate between the =
two.
 
While the =
AS could embed semantics in the key handle identifier to indicate which =
identifiers are pre-registered vs dynamic, there are many cases where =
the AS does need to know the difference, so making the difference a =
feature of GNAP seems like a better path.
 
 
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.

-- 

Txauth mailing list

Txauth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth
=





=

--Apple-Mail=_2B47E552-290A-4954-8C0C-7EAA73E006DF--


From nobody Thu Jul 16 09:57: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 5CB6A3A0C80 for ; Thu, 16 Jul 2020 09:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.629
X-Spam-Level: 
X-Spam-Status: No, score=-0.629 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.267, NICE_REPLY_A=-0.001, 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 zY7b6KpyEezk for ; Thu, 16 Jul 2020 09:57:29 -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 B51053A0C7F for ; Thu, 16 Jul 2020 09:57:28 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d11 with ME id 3sxR2300U4FMSmm03sxSz3; Thu, 16 Jul 2020 18:57:26 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 16 Jul 2020 18:57:26 +0200
X-ME-IP: 86.238.65.197
To: Francis Pouatcha 
Cc: txauth@ietf.org, Dick Hardt 
References:         
From: Denis 
Message-ID: 
Date: Thu, 16 Jul 2020 18:57:23 +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="------------BD9FDD90F2EB8A97F86F4964"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 16 Jul 2020 16:57:32 -0000

This is a multi-part message in MIME format.
--------------BD9FDD90F2EB8A97F86F4964
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Francis,

> Hello Denis,
>
> On Thu, Jul 16, 2020 at 8:45 AM Denis  > wrote:
>
>     Hello  Francis,
>
>     The first two steps of your scenario are nice, in particular the
>     second one:
>
>         (2) Service Intent: In order to discover *authorization
>         requirements*, the Client sends a service intent to the RS.
>
>     This means that the client first contacts the RS, instead of the GS.
>
>
>     However, the third step is missing to disclose to the client these
>     "*authorization requirements*", in particular which AS(s),
>     it may contact, which attributes are requested and how/when/where
>     the user consent is gathered.
>
> The response (2) AuthZ Challenge carries the reference to the GS. Mean 
> the resource server instructs the Client on which GS to approach for 
> authorization.

This information was not mentioned in your description.

>
>     Unless the scenario is mandating all the RSs to trust one and only
>     one GS and the client to have a relationship with that GS,
>     the remaining steps of this scenario do not work.
>
> Can you elaborate why it shall not work for many GSs?

Your answer above mentions : "which GS to approach for authorization". 
It uses the singular whereas it should use the plural.

In addition, indicating only which GS*s* (plural) is insufficient, since 
the RS also needs to indicate to the Client which attributes
are requested for each of these GSs.

Your description is also silent to explain how/when/where the user 
consent is gathered.

>     Step (5) mandates the GS to know who the owner of a given RS is
>
> Step (5) mandates the GS to know the RO, as owner of the target 
> Resource, but not the RS (Resource Server). Resource not-equals RS.
>
>     , and thus mandates the client to disclose to the GS the identity
>     of the RS.
>

> No. Here there is no requirement from GS to know the RS.

In your are using the terminology of RFC 6749, then page 5 states:

    In OAuth, the client requests access to resources controlled by the
    resource owner and hosted by the resource server.

In order to make sure that the right RO is in charge of the appropriate 
RS, the GS needs to maintain a mapping between the RS and the RO.
The client does not know who the ROs are.

>     The consequence is the following : this scenario, /as well as the
>     scenario described in draft-hardt-xauth-protocol-13/, allows the
>     GS to act as Big Brother.
>
> No.

If the GS is in a position to know when a client is attempting to make 
an access to a given RS, then it can maintain logs of these events.

> RS will find a way to validate AuthZ produced by any GS.

No. A RS trusts some GSs for some kinds of attributes. It does not trust 
all the GSs that might exist in the world.

> Means RS must trust that very GS or trust somebody that trusts that 
> very GS (e.g. CA).

Trust relationships are not necessarily transitive (nor bilateral).

> GS must not know the RS but must understand the Resource and trust the 
> Resource Owner, so that GS can validate the RO Grant.

It would be interesting if you could elaborate on the last part of this 
sentence :
"[GS] must understand the Resource and trust the Resource Owner, so that 
GS can validate the RO Grant".

Denis

>
> /Francis
>
>
>     Denis
>
>>     Hello Fabian,
>>
>>     On Thu, Jul 16, 2020 at 4:47 AM Fabien Imbault
>>     > wrote:
>>
>>         Hi,
>>
>>         That's interesting, however the important logic is actually
>>         implemented within (5). And so for the reader, it might be
>>         quite difficult to understand what we're after (compared to
>>         oauth2 for instance). So in my view, this kind of schema has
>>         its place, but not at the start of the document where we
>>         should primarily be concerned about explaining why someone
>>         should read the document..
>>
>>         It's also not easy to understand :
>>         - why we sometimes use different labels between requests and
>>         responses (for instance, 5 and 6)
>>
>>     Will need support in drafting the correct terms. The main purpose
>>     of this diagram is to help sharpen the definition of terms and
>>     verbs used in the draft.
>>
>>         - sometimes we use "grant" and sometimes "authZ", and it
>>         doesn't seem very clear what is the difference in use
>>
>>     IMO: the granting is the process of given permission.
>>     - RO can grant his Consent to the User or Client
>>     - GS can turn the RO Grant into an AuthZ.
>>     - Client can use AuthZ to access a Resource.
>>
>>         A terminology section would be great to clarify.
>>
>>     Yes. There is a terminology section in there. We need to bring
>>     the wissing words into the list and sharpen those already there.
>>
>>
>>         If I understand correctly your remark in 5, you think the
>>         request/response scheme (as in XYZ) may be misleading.
>>
>>     No. XYZ does IMO exactly  that. Just try to be more abstract for
>>     a better description of the models.
>>
>>         On the contrary, I think it allows support rich interaction
>>         scenarios (and especially the ones you describe) with greater
>>         flexibility.
>>
>>     Flexibility shall not be put ahead of formal correctness.
>>
>>         For instance, some would disagree with the assertion that the
>>         goal is for the GS to gather consent (see discussion on
>>         putting that on client side). A fixed interaction schema has
>>         the downside of not permitting other setups.
>>
>>     This discussion is the result of the lack of sharp terminology.
>>     Most of the time mixing up gathering consent (the act) and the
>>     way consent is gathered and transported from RO to GS (the
>>     interaction).
>>     /Francis
>>
>>
>>         Fabien
>>
>>         On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha
>>         >         > wrote:
>>
>>             Hello Dick,
>>
>>
>>                             2. Abstract Protocol Flow
>>                             I am missing an abstract protocol flow
>>                             like the one defined in
>>                             https://tools.ietf.org/html/rfc6749#section-1.2.
>>
>>
>>                         That's an interesting point. GNAP also has
>>                         identity claims, so the abstract flow is
>>                         somewhat different (there is no Authorization
>>                         Grant from the RO), and not all steps always
>>                         happen. (there may not be steps (E) and (F)
>>                         with a Resource Server)
>>
>>                         Would you elaborate on what you think would
>>                         be useful here, that is not in the specific
>>                         flows?
>>
>>                     A diagram that generalizes the steps,
>>                     independently of interaction mode is essential
>>                     for the reader's navigation of the rest of the
>>                     document. This is what #section-1.2 of RFC6749
>>                     does. I hope we can produce a similar diagram.
>>
>>                     A subsection of
>>                     https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>                     could be defined for this.
>>
>>
>>                 Interaction modes are one dimension where the steps
>>                 could be generalized, but some steps are optional.
>>                 For example, the User may not interact with the GS,
>>                 and the GS may interact with the RO. The Client may
>>                 only want claims, and there would be no step of the
>>                 Client calling the RS.
>>
>>                 A generalized diagram would need to include all
>>                 optional steps so that it did not mislead a reader
>>                 into thinking the diagram included all general steps,
>>                 but it does not seem that is what you are asking for
>>                 as you wrote:
>>
>>                 A subsection of
>>                 https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>                 could be defined for this."
>>
>>                 Perhaps you can share how you think the diagram would
>>                 look?
>>
>>             find below my proposal of an abstract sequence diagram.
>>
>>             +----+  +------+  +---+  +---+  +---+
>>             |User|  |Client|  |RS |  |GS |  |RO |
>>             +----+  +------+  +---+  +-+-+  +-+-+
>>               |(1) Service Request     |      |
>>               |-------->|       |      |      |
>>               |         |(2) Service Intent   |
>>               |         |------>|      |      |
>>               |         |(3) AuthZ Challenge  |
>>               |         |<------|      |      |
>>               |         |(4) AuthZ Request    |
>>               |         |------------->|      |
>>               |         |       |      |(5) Consent Request
>>               |         |       |      |----->|
>>               |         |       |      |(6) Grant Consent
>>               |         |       |      |<-----|
>>               |         |(7) Grant Access (Token)
>>               |         |<-------------|      |
>>               |         |(8) Service Request (Token)
>>               |         +------>+      |      |
>>               |         |(9) Service Response |
>>               |         |<------|      |      |
>>               |(10) Service Response   |      |
>>               +<--------|       |      |      |
>>               +         +       +      +      +
>>
>>             (1) Service Request: This is the service request sent by
>>             a User to the Client. This can be a simple file read
>>             request or even a complex payment initiation request.
>>
>>             (2) Service Intent: In order to discover authorization
>>             requirements, the Client sends a service intent to the RS.
>>
>>             (3) AuthZ Challenge: The response to a service intent
>>             request is generally an AuthZ Challenge. The content of
>>             this AuthZ Challenge, can be an identification challenge,
>>             an AuthZ exemption, or details on requested AuthZ. The
>>             content AuthZ Challenge can be similar to the oAuth2 RAR.
>>
>>             (4) AuthZ Request : the Client sends an AuthZ Request to
>>             the GS including the AuthZ Challenge. This request can be
>>             similar to the oAuth PAR request.
>>
>>             (5) Requests Consent : GS sends consent request to RO.
>>             Remark: The abstract protocol flow does not display a
>>             response of the request (4) to the Client. This is IMO a
>>             general misunderstanding. This protocol wants the GS to
>>             collect a consent from the RO.
>>             - In the case of a "redirect interaction", GS will use
>>             transport infrastructure provided by the Client to
>>             instruct the User to send the RO to the GS (in most
>>             cases, user and RO are identical).
>>             - In the case of a "decoupled interaction", GS will
>>             directly contact RO and collect consent in a direct
>>             interaction with the RO (see CIBA).
>>             - In the case of an "embedded interaction", GS will allow
>>             the Client to directly collect the Consent of the RO in a
>>             direct interaction with the User.
>>
>>             (6) Grant Consent : RO return a Consent Grant to GS.
>>
>>             (7) Grant Access : GS produces the corresponding access
>>             token and returns it to Client.
>>
>>             (8) Service Request : Client uses the access token to
>>             send the service request to RS.
>>
>>             (9) and (10) are self explaining....
>>
>>             One of our upcoming exercises will be to challenge this
>>             abstract protocol flow with existing interactions (and if
>>             possible associated use cases) to see if we are missing
>>             something. After an agreement on the abstract protocol
>>             flow we can make sure each interaction provides a mapping
>>             to step 1 to 10.
>>
>>             I will strip the rest of the post here. And bring further
>>             responses in separate mails.
>>
>>             Best regards.
>>             /Francis
>>
>>                 ᐧ
>>
>>             -- 
>>             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/



--------------BD9FDD90F2EB8A97F86F4964
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Francis,

    


    

    

      
      

        
Hello Denis,

        

        

          
On Thu, Jul 16, 2020 at 8:45
            AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              
Hello  Francis,

                

              

              
The first two steps of your scenario are nice, in
                particular the second one:

              

                
(2) Service Intent: In order to discover authorization
                    requirements, the Client sends a service intent
                  to the RS.

              

              
This means that the client first contacts the RS,
                instead of the GS. 

            

          

          

            

              


              

              
However, the third step is missing to disclose to the
                client these "authorization requirements", in
                particular which AS(s), 

                it may contact, which attributes are requested and
                how/when/where the user consent is gathered.

                

              

            

          

          
The response (2) AuthZ Challenge carries the reference to
            the GS. Mean the resource server instructs the Client on
            which GS to approach for authorization. 

          

        

      

    

    
This information was not mentioned in your description.

    

      

        

          

            

              
 

                Unless the scenario is mandating all the RSs to trust
                one and only one GS and the client to have a
                relationship with that GS, 

                the remaining steps of this scenario do not work.

                

              

            

          

          
Can you elaborate why it shall not work for many GSs?

        

      

    

    
Your answer above mentions : "which GS to approach for
      authorization". It uses the singular whereas it should use the
      plural.

    
In addition, indicating only which GSs (plural) is
      insufficient, since the RS also needs to indicate to the Client
      which attributes 

      are requested for each of these GSs.

    
Your description is also silent to explain how/when/where the
      user consent is gathered.

    

      

        

          

            

              
 

            

          

          

            

              
Step (5) mandates the GS to know who the owner of a
                given RS is

            

          

          
Step (5) mandates the GS to know the RO, as owner of the
            target Resource, but not the RS (Resource Server). Resource
            not-equals RS.

          


          

          

            

              
, and thus mandates the client to disclose to the GS
                the identity of the RS. 

              

            

          

        

      

    

    

    

      

        

          
No. Here there is no requirement from GS to know the RS.

        

      

    

    
In your are using the terminology of RFC 6749, then page 5
      states:

    

      
In OAuth, the client requests access to resources controlled by
        the resource owner and hosted by the resource server.

      

    

    
In order to make sure that the right RO is in charge of the
      appropriate RS, the GS needs to maintain a mapping between the RS
      and the RO.

      The client does not know who the ROs are.

    

      

        

          
 

          

            

              
The consequence is the following : this scenario, as
                  well as the scenario described in
                  draft-hardt-xauth-protocol-13, allows the GS to
                act as Big Brother. 

              

            

          

          
No. 

          

        

      

    

    
If the GS is in a position to know when a client is attempting to
      make an access to a given RS, then it can maintain logs of these
      events.

    

    

      

        

          
RS will find a way to validate AuthZ produced by any GS.
          

        

      

    

    
No. A RS trusts some GSs for some kinds of attributes. It does
      not trust all the GSs that might exist in the world.

    

      

        

          
Means RS must trust that very GS or trust somebody that
            trusts that very GS (e.g. CA).

        

      

    

    
Trust relationships are not necessarily transitive (nor
      bilateral).

    

      

        

          
GS must not know the RS but must understand the Resource
            and trust the Resource Owner, so that GS can validate the RO
            Grant.

        

      

    

    
It would be interesting if you could elaborate on the last part
      of this sentence :

      "[GS] must understand the Resource and trust the Resource Owner,
      so that GS can validate the RO Grant".

    
Denis

    

    

      

        

          


          

          
/Francis

          

            

              
 

              


              

              
Denis

              

              

              

                

                  
Hello Fabian,

                  

                  

                    
On Thu, Jul 16,
                      2020 at 4:47 AM Fabien Imbault <fabien.imbault@gmail.com>
                      wrote:

                    

                    

                      
Hi, 
                        


                        

                        
That's interesting, however the important
                          logic is actually implemented within (5). And
                          so for the reader, it might be quite difficult
                          to understand what we're after (compared to
                          oauth2 for instance). So in my view, this kind
                          of schema has its place, but not at the start
                          of the document where we should primarily be
                          concerned about explaining why someone should
                          read the document..

                        


                        

                        
It's also not easy to understand : 

                        
- why we sometimes use different labels
                          between requests and responses (for instance,
                          5 and 6)

                      

                    

                    
Will need support in drafting the correct
                      terms. The main purpose of this diagram is to help
                      sharpen the definition of terms and verbs used in
                      the draft.

                    


                    

                    

                      

                        
- sometimes we use "grant" and sometimes
                          "authZ", and it doesn't seem very clear what
                          is the difference in use

                      

                    

                    
IMO: the granting is the process of given
                      permission.

                    
- RO can grant his Consent to the User or
                      Client

                    
- GS can turn the RO Grant into an AuthZ.

                    
- Client can use AuthZ to access a Resource.

                    


                    

                    

                      

                        
A terminology section would be great to
                          clarify.

                      

                    

                    
Yes. There is a terminology section in there.
                      We need to bring the wissing words into the list
                      and sharpen those already there. 

                    

                      

                        


                        

                        
If I understand correctly your remark in 5,
                          you think the request/response scheme (as in
                          XYZ) may be misleading. 

                      

                    

                    
No. XYZ does IMO exactly  that. Just try to be
                      more abstract for a better description of the
                      models.

                    
 

                    

                      

                        
On the contrary, I think it allows support
                          rich interaction scenarios (and especially the
                          ones you describe) with greater flexibility. 

                      

                    

                    
Flexibility shall not be put ahead of formal
                      correctness.

                    
 

                    

                      

                        
For instance, some would disagree with the
                          assertion that the goal is for the GS to
                          gather consent (see discussion on putting that
                          on client side). A fixed interaction schema
                          has the downside of not permitting other
                          setups.

                      

                    

                    
This discussion is the result of the lack of
                      sharp terminology. Most of the time mixing up
                      gathering consent (the act) and the way consent is
                      gathered and transported from RO to GS (the
                      interaction).

                    
/Francis

                    


                    

                    

                      

                        


                        

                        
Fabien

                      

                      

                      

                        
On Thu, Jul
                          16, 2020 at 5:28 AM Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>
                          wrote:

                        

                        

                          

                            
Hello
                                Dick,
                              


                                

                            

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                
 

                                                

                                                  

                                                    

                                                      

                                                        


                                                          

                                                        
2.
                                                          Abstract
                                                          Protocol Flow

                                                        

                                                          
I
                                                          am missing an
                                                          abstract
                                                          protocol flow
                                                          like the one
                                                          defined in https://tools.ietf.org/html/rfc6749#section-1.2.

                                                        

                                                      

                                                    

                                                  

                                                

                                                


                                                  

                                                
That's
                                                    an interesting
                                                    point. GNAP also has
                                                    identity claims, so
                                                    the abstract flow is
                                                    somewhat different
                                                    (there is no
                                                    Authorization Grant
                                                    from the RO), and
                                                    not all steps always
                                                    happen. (there may
                                                    not be steps (E) and
                                                    (F) with a Resource
                                                    Server)

                                                


                                                  

                                                
Would
                                                    you elaborate on
                                                    what you think would
                                                    be useful here, that
                                                    is not in the
                                                    specific flows?

                                              

                                            

                                          

                                          
A
                                              diagram that generalizes
                                              the steps, independently
                                              of interaction mode is
                                              essential for the reader's
                                              navigation of the rest of
                                              the document. This is
                                              what #section-1.2 of
                                              RFC6749 does. I hope we
                                              can produce a similar
                                              diagram.

                                          


                                            

                                          
                                        

                                      

                                    

                                    


                                      

                                    
Interaction
                                        modes are one dimension where
                                        the steps could be generalized,
                                        but some steps are optional. For
                                        example, the User may not
                                        interact with the GS, and the GS
                                        may interact with the RO. The
                                        Client may only want claims, and
                                        there would be no step of the
                                        Client calling the RS.

                                    


                                      

                                    
A
                                        generalized diagram would need
                                        to include all optional steps so
                                        that it did not mislead a reader
                                        into thinking the diagram
                                        included all general steps, but
                                        it does not seem that is what
                                        you are asking for as you wrote:

                                    


                                      

                                    
A
                                        subsection of https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
                                        could be defined for this."

                                      

                                    


                                      

                                    
Perhaps
                                        you can share how you think the
                                        diagram would look?

                                  

                                

                              

                              
find below my
                                  proposal of an abstract sequence
                                  diagram.

                              


                                

                              
+----+
                                   +------+  +---+  +---+  +---+

                                  |User|  |Client|  |RS |  |GS |  |RO |

                                  +----+  +------+  +---+  +-+-+  +-+-+

                                    |(1) Service Request     |      |

                                    |-------->|       |      |      |

                                    |         |(2) Service Intent   |

                                    |         |------>|      |      |

                                    |         |(3) AuthZ Challenge  |

                                    |         |<------|      |      |

                                    |         |(4) AuthZ Request    |

                                    |         |------------->|      |

                                    |         |       |      |(5)
                                  Consent Request

                                    |         |       |      |----->|

                                    |         |       |      |(6) Grant
                                  Consent

                                    |         |       |      |<-----|

                                    |         |(7) Grant Access (Token)

                                    |         |<-------------|      |

                                    |         |(8) Service Request
                                  (Token)

                                    |         +------>+      |      |

                                    |         |(9) Service Response |

                                    |         |<------|      |      |

                                    |(10) Service Response   |      |

                                    +<--------|       |      |      |

                                    +         +       +      +      +

                                

                              


                                

                              
(1) Service
                                  Request: This is the service request
                                  sent by a User to the Client. This can
                                  be a simple file read request or even
                                  a complex payment initiation request.

                              


                                

                              
(2) Service
                                  Intent: In order to discover
                                  authorization requirements, the Client
                                  sends a service intent to the RS.

                              


                                

                              
(3) AuthZ
                                  Challenge: The response to a service
                                  intent request is generally an AuthZ
                                  Challenge. The content of this AuthZ
                                  Challenge, can be an identification
                                  challenge, an AuthZ exemption, or
                                  details on requested AuthZ. The
                                  content AuthZ Challenge can be similar
                                  to the oAuth2 RAR.

                              


                                

                              
(4) AuthZ
                                  Request : the Client sends an AuthZ
                                  Request to the GS including the AuthZ
                                  Challenge. This request can be similar
                                  to the oAuth PAR request.

                              


                                

                              
(5) Requests
                                  Consent : GS sends consent request to
                                  RO. 

                              
Remark: The
                                  abstract protocol flow does not
                                  display a response of the request (4)
                                  to the Client. This is IMO a general
                                  misunderstanding. This protocol wants
                                  the GS to collect a consent from the
                                  RO. 

                              
- In the case
                                  of a "redirect interaction", GS will
                                  use transport infrastructure provided
                                  by the Client to instruct the User to
                                  send the RO to the GS (in most cases,
                                  user and RO are identical).

                              
- In the case
                                  of a "decoupled interaction", GS will
                                  directly contact RO and collect
                                  consent in a direct interaction with
                                  the RO (see CIBA).

                              
- In the case
                                  of an "embedded interaction", GS will
                                  allow the Client to directly collect
                                  the Consent of the RO in a direct
                                  interaction with the User.

                              


                                

                              
(6) Grant
                                  Consent : RO return a Consent Grant to
                                  GS.

                              


                                

                              
(7) Grant
                                  Access : GS produces the corresponding
                                  access token and returns it to Client.

                              


                                

                              
(8) Service
                                  Request : Client uses the access token
                                  to send the service request to RS.

                              


                                

                              
(9) and (10)
                                  are self explaining....

                              


                                

                              
One of our
                                  upcoming exercises will be to
                                  challenge this abstract protocol flow
                                  with existing interactions (and if
                                  possible associated use cases) to see
                                  if we are missing something. After an
                                  agreement on the abstract protocol
                                  flow we can make sure each interaction
                                  provides a mapping to step 1 to 10.

                              


                                

                              
I
                                  will strip the rest of the post here.
                                  And bring further responses in
                                  separate mails.

                              


                                

                              
Best
                                  regards.

                              
/Francis  

                              

                                

                                  

                                    

                                    

                                  

                                

                                
ᐧ

                              

                            

                            -- 

                            
                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              
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

                          
                        

                      

                    

                  

                

              

            

          

        

      

    

    


    

  


--------------BD9FDD90F2EB8A97F86F4964--


From nobody Thu Jul 16 10:43: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 276183A0896 for ; Thu, 16 Jul 2020 10:43:10 -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 1FsHppQ4BaiN for ; Thu, 16 Jul 2020 10:43:08 -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 1C10A3A0891 for ; Thu, 16 Jul 2020 10:43:07 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id q7so9057442ljm.1 for ; Thu, 16 Jul 2020 10:43: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=PFZY4tKPrrvBd8XI/MFW/oeoSloIEh9LBrqVKjgTT1w=; b=n46DRITPmQt6YrX/olwjGv54m+Llv+mi+OAxgQEhFW9xMH2mw++Thvv4Js+Kq/msEi 9NKBQUziqPSuOBB562oa/YfIwS+beih1lDWFMq1wTGh5WJdAXCO8iCHlVQZeYiMv7HZs 6BfVeo65ocfeRgEJm2hHKdzkFFEvcVLwda7B4np7W85xmXc32Yg9iVxMg/Xf41/xZCwI QCorkgeFQheZ2oHZMlopN7FGyF4kzoHspk3icKG3xyh9aJYWYJkoa+j8/PCHDKIlazEN DBINGcd8jcOljKmR5FcpKT1sI0/ZH/EA7KWFcyVlsRnWN4m7UBcWRc0ES847w4YRMPGd VFPA==
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=PFZY4tKPrrvBd8XI/MFW/oeoSloIEh9LBrqVKjgTT1w=; b=c4oC5x2SQT8kupktm31TQU2YO8jAd6RPcsawBXRdGamLo27V9gN1LMMjLGignUE99m yioC2j0U29mdw3xKqR7LrHMwTUZSUx81OSpvvjrFWQwrkXtGAsrx8W9XOBb+MKHRpYKK FYqpCWcyVh671puJ4I226MzQorxj1PNvTtAGyr6y0W3EAOe5n+FymnwsWfrQJ46alQzc KBE75TLxA6k+1aTHnGJB6y3W0cBT5XdvhyILjLIahJbcIp5pEivt52FaxPOg/6GpYCAo FWZfOmRPTTZsSnScRl2XzKA19QMVczZP8v1W9eZQnbFXcZiixbrauRo5Z5xglAJJPdqP c18A==
X-Gm-Message-State: AOAM533z4e22/SAC/xMFB9g7knJW7/ulZqjye5VLU2g6LctF5J/7SJLK BhNo1UKVD5PPr1aQ/1FgvshULhBsetX/3/8fz8SOtvcs
X-Google-Smtp-Source: ABdhPJxSxzptSQTyB7jm/6HbJDxoh7PUf3eCVjtKCX9ibq1KtPFJ9rrufWRYcjGiDwgJstuQHRb3AB333Q6ZXnwrwrc=
X-Received: by 2002:a05:651c:547:: with SMTP id q7mr2452561ljp.437.1594921385944;  Thu, 16 Jul 2020 10:43:05 -0700 (PDT)
MIME-Version: 1.0
References: <7c1f0439-42e4-9f7d-4dd2-e741f7cb57f2@free.fr>  <2201d382-c2f3-1496-b368-5b2caeb5eab5@free.fr>
In-Reply-To: <2201d382-c2f3-1496-b368-5b2caeb5eab5@free.fr>
From: Dick Hardt 
Date: Thu, 16 Jul 2020 10:42:29 -0700
Message-ID: 
To: Denis 
Cc: "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000a76a9705aa92925f"
Archived-At: 
Subject: Re: [Txauth] Registered Clients and Dynamic Clients
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, 16 Jul 2020 17:43:10 -0000

--000000000000a76a9705aa92925f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

inline ...

On Thu, Jul 16, 2020 at 5:37 AM Denis  wrote:

> Hi Dick,
>
> On Wed, Jul 15, 2020 at 10:04 AM Denis  wrote:
>
>> Hello Dick,
>>
>> I am puzzled with the two following definitions in
>> draft-hardt-xauth-protocol-13 :
>>
>>       *Registered Client* - a Client 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.  Th=
e
>> GS may have different policies for what
>>        different Registered Clients can request.  A Registered Client
>> MAY be interacting with a User.
>>
>> [Denis]  I interpret the last sentence in the following way: A Registere=
d
>> Client may be either an Application or a User.
>>              Is it correct ?
>>
>
> No. A Registered Client MAY be interacting with a User, or it MAY not. IE=
,
> a Registered Client may be a service.
>
> It seems that what I call an Application is what you call a service.
> Usually a service may be supported by multiple servers,
> so I get the impression that my terminology is better suited. If not,
> would you be able to explain ?
>

A Client could be an application the User is using, or it could be a
service with no specific User.


>
>
>>       *Dynamic Client* - a Client that has not been previously registere=
d
>> with the GS, and each instance will generate
>>        it=E2=80=99s own asymmetric key pair so it can prove it is the sa=
me
>> instance of the Client on subsequent requests. The GS
>>        MAY return a Dynamic Client a Client Handle for the Client to
>> identify itself in subsequent requests. A single-page
>>        application with no active server component is an example of a
>> Dynamic Client. A Dynamic Client MUST be interacting
>>        with a User.
>>
>> [Denis] The draft does not include any other explanation for the reason
>> to support the so-called "Dynamic Clients".
>>             While I can understand the value to use a temporary key pair
>> for a given RS, I can't understand the value for a GS
>>             to support unknown clients. If a GS knows nothing about a
>> so-called "Dynamic Client", then it will not be able to deliver
>>             any user attribute into an access token to such client.
>>
>
> More of an explanation of Dynamic Clients is a good call out, thanks!
>
> A Dynamic Client MUST be interacting with a User, as "trust" of the Clien=
t
> is done by the User.
> A Single Page Application (SPA) or a mobile app are examples of clients
> that cannot have a shared secret, but can generate and keep secure
> their own key pair..
>
> As suggested in another thread, GNAP could support Clients that are
> between these two extremes.
> Mike called out automatic registration per OpenID Connect Federation as
> one example. Other options include a "software statement" passed from the
> Client to the GS.
>
> We may want to revisit the terms "Registered Client" and "Dynamic Client"
> as we broaden the mechanisms for Clients to "register" with a GS, but the=
se
> are the common cases today, so I picked them.
>
>
> It seems that the intent is to support both a client registration protoco=
l
> and a client operational protocol with the GS/AS.
>
> Client registration may be done in many ways until the user is able to ge=
t
> a *both an identifier* and private key
> usable for an AS, and the AS is able to use *t**he same identifier* and
> the corresponding public key to authenticate the user.
>
It appears you are mixing client identifiers and user identifiers, as well
as user authentication at a AS, and client authentication at an AS. User
authentication at the AS is out of scope of GNAP as I understand it (there
are lots of existing mechanisms that work fine). Client authentication to
the AS is in scope.



> For example, draft-hardt-xauth-protocol-13 states: "The Client always use=
s
> a private asymmetric key to authenticate to the GS".
>
> This should be the start of the story with an important observation: the
> client always uses *an identifier*, in particular to allow to gracefully
> change that private key.
>
The challenge is that the client needs a unique identifier for the GS,
which is why in both XYZ, and XAuth, the GS generates the identifier for
dynamic clients, and the generally also generates the identifier for
registered clients.


> One way to register and then to authenticate to a GS may simply be to use
> FIDO. FIDO is currently supported by many web browsers.
>

Technically, the web browsers support WebAuthN. While FIDO is great
technology, I would see it as an authentication choice between the GS and
the User, and out of scope of GNAP. A challenge with FIDO is portability
across devices, as a binding is usually tied to a specific device.


>
> If/once we will be finished with the main topic, then why not address
> client registration but there is no strong adherence with our main topic.
> Hence, client registration should not be on the list of our top prioritie=
s.
>
> If we define one *or more* client registration schemes, then this should
> better be in a separate and independent RFC.
>
Maybe, maybe not.

My preference is to have a larger document that covers inter-related topics
than a bunch of smaller documents that an implementer has to bounce around
between.

/Dick

--000000000000a76a9705aa92925f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


inline ...

On Thu, Jul 16, 2020 at 5:37 AM=
 Denis <denis.ietf@free.fr>=
 wrote:

 =20
   =20
 =20
  

    
Hi Dick,

    


    

    

     =20
      
On Wed, Jul 15, 2020 at 10:04 AM Denis <denis.ietf@free.fr>
        wrote:

        

          

            

              
Hello Dick,

                  

                  I am puzzled with the two following definitions in
                  draft-hardt-xauth-protocol-13 :

                
                =C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
                  *Registered Client* - a Client that has registered
                  with the GS and has a Client ID to identify itself,
                  and 

                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 can prove it possess=
es a key that is linked to
                  the Client ID.=C2=A0 The GS may have
                  different policies for what 

                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 different Registered=
 Clients can request.=C2=A0
                  A Registered Client MAY be interacting with a
                  User.

                 

                  [Denis]=C2=A0 I interpret the last sentence in the
                  following way: A Registered Client may be either an
                  Application or a 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 Is it correct ?

                

            

          

          


          

          
No. A Registered Client MAY be interacting with a User,
            or it MAY not. IE, a Registered Client may be a service.

        

      

    

    
It seems that what I call an Application is
        what you call a service. Usually a service may be supported by
        multiple servers, 

        so I get the impression that my terminology is better suited. If
        not, would you be able to explain ?

A Client could be an application the User is using, or it=
 could be a service with no specific User.
=C2=A0

    

      

        

          
=C2=A0

          

            

              
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *Dynamic Client* - a Client that
                  has not been previously registered with the GS, and
                  each instance will generate 

                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it=E2=80=99s own asy=
mmetric key pair so it can prove it
                  is the same instance of the Client on subsequent
                  requests. The GS 

                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MAY return a Dynamic=
 Client a Client Handle for
                  the Client to identify itself in subsequent requests.
                  A single-page 

                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 application with no =
active server component is
                  an example of a Dynamic Client. A Dynamic Client MUST
                  be interacting 

                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with a User.

                  

                  [Denis] The draft does not =
include any other
                    explanation for the reason to support the so-called
                      "Dynamic Clients". 

                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 While I can understand
                  the value to use a temporary key pair for a given RS,
                  I can't understand the value for a GS 

                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 to support unknown clients. If a GS knows
                  nothing about a so-called "Dynamic Client", the=
n it
                  will not be able to deliver 

                  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0 any user attribute into an access token to
                  such client.

            

          

          


          

          
More of an explanation of Dynamic Clients is a good call
            out, thanks!

          


          

          
A Dynamic Client MUST be interacting with a User, as
            "trust" of the Client is done by the User. 

            A Single Page Application (SPA) or a mobile app are examples
            of clients that cannot have a shared secret,=C2=A0but can
            generate and keep secure their=C2=A0own key pair..=C2=A0

          


          

          
As suggested in another thread, GNAP could support
            Clients that are between these two extremes. 

            Mike called out automatic registration per OpenID Connect
            Federation as one example. Other options include a "softwa=
re
            statement" passed from the Client to the GS.

          


          

          
We may want to revisit the terms "Registered Client&quo=
t; and
            "Dynamic Client" as we broaden the mechanisms=C2=A0fo=
r Clients to
            "register" with a GS, but these are the common cases =
today,
            so I picked them.

        

      

    

    

      It seems that the intent is to support both a client registration
      protocol and a client operational protocol with the GS/AS. 

    
    
Client registration may be done in many ways
        until the user is able to get a both an identifier and
        private key 

        usable for an AS, and the AS is able to use the same
          identifier and the corresponding public key to
        authenticate the user.
It appears=
 you are mixing client identifiers and user identifiers, as well as user au=
thentication at a AS, and client authentication at an AS. User authenticati=
on at the AS is out of scope of GNAP as I understand it (there are lots of =
existing mechanisms that work fine). Client authentication to the AS is in =
scope.

=C2=A0

    For example, draft-hardt-xauth-protocol-13
      states: "The Client always uses a private asymmetric key to
      authenticate to the GS".

    
    
This should be the start of the story with an
        important observation: the client always uses an identifier,
        in particular to allow to gracefully change that private key.
The challenge is that the client needs a uniqu=
e identifier for the GS, which is why in both XYZ, and XAuth, the GS genera=
tes the identifier for dynamic clients, and the generally also generates th=
e identifier for registered clients.
=C2=A0

    
One way to register and then to authenticate
        to a GS may simply be to use FIDO.
        FIDO is currently supported by many web browsers.

Technically, the web browsers support W=
ebAuthN. While FIDO is great technology, I would see it as an authenticatio=
n choice between the GS and the User, and out of scope of GNAP. A challenge=
 with FIDO is portability across devices, as a binding is usually tied to a=
 specific device.
=C2=A0

        

        If/once we will be finished with the main topic, then why not
        address client registration but there is no strong adherence
        with our main topic.

        Hence, client registration should not be on the list of our top
        priorities.

    

    
If we define one or more client
        registration schemes, then this should better be in a separate
        and independent RFC.
Maybe, maybe=
 not.

My preference is to have a larger document t=
hat covers inter-related topics than a bunch of smaller documents that an i=
mplementer has to bounce around between.=C2=A0

/Di=
ck
=C2=A0


--000000000000a76a9705aa92925f--


From nobody Thu Jul 16 11:01: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 96D343A09C6 for ; Thu, 16 Jul 2020 11:00:58 -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 lAIUADg6GSqh for ; Thu, 16 Jul 2020 11:00:56 -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 5F6693A09CE for ; Thu, 16 Jul 2020 11:00:55 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id e8so9225404ljb.0 for ; Thu, 16 Jul 2020 11:00: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=jCZKVkoMVcJYzFIOTFoOlAEFhJMObgkZ8DGI9+xo3EA=; b=RCZ90qSbOt1y/EwOmRpMOGO0Bb2Y9AWlw8hTsZ7KjTTBTWG/2zvIL6loe14EUhHecU 8DtibIRAZ3ct+bLjZJVtUgJGh6Wr54gjX68Cqu+Bf/RA891bUSCzCB694TE6jU4rbxCt haNM1ma68/ioEeBcP17l5iy0JpkwfSLy8K1FCb2fkDNpVfOG/B6vGOReftaEP5bZhs4s ppKPRU0OpiMmW1V2lug1aZuoIq/vwT8pY/M5CRV+iFPR51RTrlBNIjqb/NYQks1a1/oa Im2onRbQyWM0rfdLMsxmeZARKGBjrm9uh23JmD2F4AVtWjif5RV/be1sL9IEO5efVSQg qr/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=jCZKVkoMVcJYzFIOTFoOlAEFhJMObgkZ8DGI9+xo3EA=; b=pxL4mx+AUSLeeupPBML0/XKk4ISPYfxGCBbgG95jsr198fQfcTX+D94UFKSV4g6rEc X0gPvHp7cZqXicDT4PiV35QrTX0u0w1lYUdBo9N0we5W1zIC139U3DrRsn59mp++WG4E HhMzuQypmN7hKNXSegSXw/9MKoY8qLpKR1oF5Mwx9+p1zNH24tlRR6XJ0h58XK+dunBK HH2PWj6oDQhAeYjkgq9SwwGwJiv8deOSL+atXu9x/77M3Rts5wwocNcJB8LG6Ugh7eEp ooIHJOZ6eUvZVEdlPIJAuZ/jUOaWtffDlvOJvcEsTiZEp+K1T5aZZRs7tY2tSbsgvQd5 K86w==
X-Gm-Message-State: AOAM533BEGfIkmacrcTVsyC61oZByfkxDI1NOA8O9KONJIJpPSdVPZjN ET3iZbD5MNajo7uSk+/YN6qZ3JGtiF8ZCCQtgws=
X-Google-Smtp-Source: ABdhPJwEXPK76MYQn0LnwNTWF8OCzzDiEnsdXux4dX+LTMi2C0GQRnoSwu9sHGrpHmP3i/QCnjk9SrNxOP7Ij99H6Q0=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr2762367ljn.5.1594922453237; Thu, 16 Jul 2020 11:00:53 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>  
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 16 Jul 2020 11:00:17 -0700
Message-ID: 
To: Justin Richer 
Cc: Fabien Imbault , Mike Varley ,  "txauth@ietf.org" , Mike Jones 
Content-Type: multipart/alternative; boundary="00000000000045043b05aa92d247"
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 16 Jul 2020 18:00:59 -0000

--00000000000045043b05aa92d247
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Justin,

While I agree that the assumption in OAuth 2 that all Clients have a
client_id is problematic, the requirement for a client_id in many use cases
is still there, and it does not represent a piece of software, but a
relationship between parties.

Organization A writes client software that calls resources managed by the
AS in Organization B. The client_id represents Organization A to
Organization B. Organization B does not care what software Organization A
is running, and there may be numerous pieces of software at Organization A
that use the same client_id. The access granted by Organization B to
Organization A needs to be able to be different than the rights granted to
Organization C.

I agree that we don't want to force all clients to have a client_id, and as
discussed, there are a variety of inputs for an AS to accept calls from a
piece of software, and often, that will be a particular *instance* of the
software, but we also don't want to force clients to all be treated the
same, because they are not.






On Thu, Jul 16, 2020 at 8:24 AM Justin Richer  wrote:

> Exactly =E2=80=94 when we start to look at it as managing the lifecycle o=
f a piece
> of software, instead of a registration at the AS, we can start thinking i=
n
> different terms what =E2=80=9Ctrusting=E2=80=9D the client means in the c=
ontext of what the
> client is doing. That trust could come from some kind of signed attestati=
on
> about the software (like the OAuth 2 DynReg software statement), or it
> could come from some externally fetchable item (like a Solid WebID, a DID=
,
> or the OIDC Federation extension), or it could come from someone sitting =
at
> a console and typing in information and getting back an identifier. And
> none of these need to pretend to be a global =E2=80=9Cclient id=E2=80=9D =
for it to work.
> The world of clients is much more diverse than OAuth 2 likes to admit, an=
d
> we see that with trying to nail down a =E2=80=9Cconfidential=E2=80=9D vs.=
 =E2=80=9Cpublic=E2=80=9D vs.
> =E2=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautom=
atic=E2=80=9D vs. =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of
> other things.
>
> OAuth 2 only needs client IDs because the front channel needs a way to
> pass client identifiers when the client can=E2=80=99t authenticate itself=
 directly.
> We tried to get rid of this restriction with PAR and JAR together, but
> there turned out to be corner cases in OAuth 2=E2=80=99s world that still=
 needed
> client_id, and implementations assumed it would be there anyway.
>
> In GNAP, we can avoid that problem from the beginning by looking at the
> model differently and understanding where we=E2=80=99re coming from, and =
why.
>
>  =E2=80=94 Justin
>
> On Jul 16, 2020, at 3:49 AM, Fabien Imbault 
> wrote:
>
> +1 on that.
>
> We can then see it more as life cycle management of the client than
> registration per say, and this comes with many benefits compared to the
> current client_id.
>
> Fabien
>
> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer  wrote:
>
>> I not only agree with Mike Jones that =E2=80=9Cautomatic registration=E2=
=80=9D should be
>> part of the process, but I would argue that that kind of model should be=
 a
>> default mode of operation. If you have an identifier that you can send t=
o
>> short-circuit that, great! But we should focus on having the capability =
of
>> inlining a lot of this information wherever possible. This is already th=
e
>> direction that the input proposals are heading.
>>
>> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope for t=
he protocol in
>> general, and since both XYZ and Xauth have mechanisms that allow the cli=
ent
>> to present a key and get back an identifier that it can use in the futur=
e
>> we have something equivalent.
>>
>> But I think there=E2=80=99s a little more to it than that: Ultimately, I=
 think we
>> should question thinking in terms of =E2=80=9Cregistration=E2=80=9D, a m=
odel which has
>> hampered the OAuth 2 model in a lot of use cases. For example, the
>> federation draft Mike Jones references below hacks the =E2=80=9Cclient_i=
d=E2=80=9D
>> parameter and makes it point to a document that the AS has to fetch. Thi=
s
>> construct is done for two reasons: (1) Oauth requires a =E2=80=9Cclient_=
id=E2=80=9D in the
>> request and (2) it=E2=80=99s difficult to pass information by value to t=
he AS due
>> to front-channel restrictions. Since we=E2=80=99re defining a new protoc=
ol, we
>> don=E2=80=99t need to hack that functionality into a =E2=80=9Cclient ID=
=E2=80=9D or equivalent and
>> instead we can pass that information directly in the protocol. If we don=
=E2=80=99t
>> assume that the client *has* to have a client ID equivalent, but it *can=
*
>> have one in a set of defined circumstances, then I think we are in a muc=
h
>> better spot. This is the reasoning for XYZ=E2=80=99s model of having cli=
ents
>> identified by the key, and that key can potentially be passed by a
>> reference identifier.
>>
>> I think all of the use cases that Mike Varley presents below are all
>> valid directions, with the caveat that we shouldn=E2=80=99t assume a cli=
ent should
>> be presenting an ID at all steps. Mechanisms like software statements
>> should be presentable apart from a client ID, as should on-device keys.
>> We=E2=80=99re probably going to want extensions for device posture and o=
ther forms
>> of attestation as well.
>>
>> This is one of the domains that I think we can clearly surpass OAuth 2=
=E2=80=99s
>> flexibility and capabilities if we are willing to look past OAuth 2=E2=
=80=99s
>> assumptions of what=E2=80=99s needed inline in the protocol.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 14, 2020, at 1:54 PM, Mike Varley 
>> wrote:
>>
>> Is client registration in scope for the protocol?
>>
>> A generic way of handling clients (via ID or Handle or Key or whatever)
>> is to have processing rule on the AS such as =E2=80=9Cif the AS recogniz=
es the
>> client ID (and authentication of that client ID) then it may process the
>> request on behalf of that client. If the AS does not recognize the clien=
t
>> ID, it must treat this as a new client registration and evaluate any
>> authorization evidence the client provides before enabling the client an=
d
>> mapping policies to that client=E2=80=9D (this means dynamic or automati=
c clients
>> need to provide additional assertions / software statements whatever to
>> register their ID.
>>
>> Something like this allows for very flexible systems:
>> System A can be unknown to the AS but can dynamically registered each
>> time with an appropriate software statement
>> System B can have a fairly stable client ID at the AS, but rotate that I=
D
>> every month through automatic registration (with an assertion it got fro=
m
>> the AS during a pre-registration for example)
>> System C can pre-register with the AS for a client ID because it doesn=
=E2=80=99t
>> deal with software statements etc=E2=80=A6
>> =E2=80=A6
>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing clie=
nt IDs because it
>> will always just rely on the software statements.
>>
>> I think a client registration protocol that allows these scenarios would
>> be very useful in GNAP, but hopefully avoiding having to define what
>> =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
>>
>> Thanks,
>>
>> MV
>>
>> *From: *Txauth  on behalf of Mike Jones <
>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>> *To: *Dick Hardt , "txauth@ietf.org" <
>> txauth@ietf.org>, Justin Richer 
>> *Subject: *Re: [Txauth] Key handle vs client id & handle
>>
>> I agree that there are significant differences between statically and
>> dynamically registered clients and that=E2=80=99s appropriate to be able=
 to
>> syntactically differentiate between them at runtime.  For one thing, the
>> resource requirements at the authorization server can be very different.
>>
>> We should also be thinking about how to include what the OpenID Connect
>> Federation spec
>> https://openid.net/specs/openid-connect-federation-1_0.html calls
>> =E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client encode a=
 registration
>> request reference in the client ID, so no static or dynamic registration
>> even occurs.  See
>> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.secti=
on.9.1
>> 
>> .
>>
>>                                                        -- Mike
>>
>> *From:* Dick Hardt 
>> *Sent:* Friday, July 10, 2020 1:17 PM
>> *To:* txauth@ietf.org; Justin Richer ; Mike Jones <
>> Michael.Jones@microsoft.com>
>> *Subject:* Key handle vs client id & handle
>>
>> + Mike as he had interest in this topic
>>
>> My understanding is that an existing OAuth 2 client would use their
>> current client id as their key handle, and a dynamic client (one that wa=
s
>> not pre-registered) would be given a key handle by the AS.
>>
>> There are potentially some significant differences between a registered
>> client, and a dynamic client to an AS.
>>
>> The AS is likely to know the identity of a registered client, and have
>> different policies between the two types of clients. For example, a
>> registered client may have access to a 'write" scope, while a dynamic
>> client does not.
>>
>> The AS may have 100s or 1000s of registered clients, but a dynamic clien=
t
>> may have 10Ms or 100Ms of instances, which may dictate separate storage
>> services. Additionally, internal to the AS, which systems can write to t=
he
>> registered client store is going to be different than the dynamic
>> client store.
>>
>> In XYZ, subsequent calls to the AS, both registered clients and dynamic
>> clients pass a key handle, so there is no easy way to differentiate betw=
een
>> the two.
>>
>> While the AS could embed semantics in the key handle identifier to
>> indicate which identifiers are pre-registered vs dynamic, there are many
>> cases where the AS does need to know the difference, so making the
>> difference a feature of GNAP seems like a better path.
>>
>>
>>
>> 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 inten=
ded
>> recipient, please contact the sender immediately, and permanently delete
>> this email and its attachments.
>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
>

--00000000000045043b05aa92d247
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Justin,=C2=A0

While I agree that the as=
sumption in OAuth 2 that all Clients have a client_id is problematic, the r=
equirement for a client_id in many use cases is still there, and it does no=
t represent a piece of software, but a relationship between parties.
<=
div>

Organization A writes client software that calls re=
sources managed by the AS in Organization B. The client_id represents Organ=
ization A to Organization B. Organization B does not care what software Org=
anization A is running, and there may be numerous=C2=A0pieces of software a=
t Organization A that use the same client_id. The access granted by Organiz=
ation B to Organization A needs to be able to be different than the rights =
granted to Organization C.=C2=A0

I agree tha=
t we don't want to force all clients to have a client_id, and as discus=
sed, there are a variety of inputs for an AS to accept calls from a piece o=
f software, and often, that will be a particular instance of the sof=
tware, but we also don't want to force clients to all be treated the sa=
me, because they are not.=C2=A0





<=
div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 16, 2020 at 8:24 AM Justin=
 Richer <jricher@mit.edu> wrot=
e:
Exactly =E2=80=94 when we start to look at it =
as managing the lifecycle of a piece of software, instead of a registration=
 at the AS, we can start thinking in different terms what =E2=80=9Ctrusting=
=E2=80=9D the client means in the context of what the client is doing. That=
 trust could come from some kind of signed attestation about the software (=
like the OAuth 2 DynReg software statement), or it could come from some ext=
ernally fetchable item (like a Solid WebID, a DID, or the OIDC Federation e=
xtension), or it could come from someone sitting at a console and typing in=
 information and getting back an identifier. And none of these need to pret=
end to be a global =E2=80=9Cclient id=E2=80=9D for it to work. The world of=
 clients is much more diverse than OAuth 2 likes to admit, and we see that =
with trying to nail down a =E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpubl=
ic=E2=80=9D vs. =E2=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =
=E2=80=9Cautomatic=E2=80=9D vs. =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 a=
ny number of other things.=C2=A0

OAuth 2 only needs=
 client IDs because the front channel needs a way to pass client identifier=
s when the client can=E2=80=99t authenticate itself directly. We tried to g=
et rid of this restriction with PAR and JAR together, but there turned out =
to be corner cases in OAuth 2=E2=80=99s world that still needed client_id, =
and implementations assumed it would be there anyway.=C2=A0

<=
/div>
In GNAP, we can avoid that problem from the beginning by looking =
at the model differently and understanding where we=E2=80=99re coming from,=
 and why.

=C2=A0=E2=80=94 Justin

On Jul 16, 2020, at 3:49 AM, Fabien Imbault <<=
a href=3D"mailto:fabien.imbault@gmail.com" target=3D"_blank">fabien.imbault=
@gmail.com> wrote:

+1 on that.
We can then see it more as life cycle management of the client=
 than registration per say, and this comes with many benefits compared to t=
he current client_id.

Fabien

On Tue, Jul 14, =
2020 at 9:32 PM Justin Richer <jricher@mit.edu> wrote:
I not only agree with Mike Jones that =E2=
=80=9Cautomatic registration=E2=80=9D should be part of the process, but I =
would argue that that kind of model should be a default mode of operation. =
If you have an identifier that you can send to short-circuit that, great! B=
ut we should focus on having the capability of inlining a lot of this infor=
mation wherever possible. This is already the direction that the input prop=
osals are heading.

So I kind-of agree that =E2=80=9Cregi=
stration=E2=80=9D is in scope for the protocol in general, and since both X=
YZ and Xauth have mechanisms that allow the client to present a key and get=
 back an identifier that it can use in the future we have something equival=
ent.=C2=A0

But I think there=E2=80=99s a little mo=
re to it than that: Ultimately, I think we should question thinking in term=
s of =E2=80=9Cregistration=E2=80=9D, a model which has hampered the OAuth 2=
 model in a lot of use cases. For example, the federation draft Mike Jones =
references below hacks the =E2=80=9Cclient_id=E2=80=9D parameter and makes =
it point to a document that the AS has to fetch. This construct is done for=
 two reasons: (1) Oauth requires a =E2=80=9Cclient_id=E2=80=9D in the reque=
st and (2) it=E2=80=99s difficult to pass information by value to the AS du=
e to front-channel restrictions. Since we=E2=80=99re defining a new protoco=
l, we don=E2=80=99t need to hack that functionality into a =E2=80=9Cclient =
ID=E2=80=9D or equivalent and instead we can pass that information directly=
 in the protocol. If we don=E2=80=99t assume that the client *has* to have =
a client ID equivalent, but it *can* have one in a set of defined circumsta=
nces, then I think we are in a much better spot. This is the reasoning for =
XYZ=E2=80=99s model of having clients identified by the key, and that key c=
an potentially be passed by a reference identifier.

I think all of the use cases that Mike Varley presents below are all vali=
d directions, with the caveat that we shouldn=E2=80=99t assume a client sho=
uld be presenting an ID at all steps. Mechanisms like software statements s=
hould be presentable apart from a client ID, as should on-device keys. We=
=E2=80=99re probably going to want extensions for device posture and other =
forms of attestation as well.

This is one of the d=
omains that I think we can clearly surpass OAuth 2=E2=80=99s flexibility an=
d capabilities if we are willing to look past OAuth 2=E2=80=99s assumptions=
 of what=E2=80=99s needed inline in the protocol.=C2=A0

=C2=A0=E2=80=94 Justin

<=
div>On Jul 14, 2020, at 1:54 PM, Mike Varley <mike.varley@securekey.com> wrot=
e:

Is client registration in s=
cope for the protocol?
=C2=A0
A generic way of handling clients (via ID or Handle or Key or =
whatever) is to have processing rule on the AS such as =E2=80=9Cif the AS r=
ecognizes the client ID (and authentication of that client ID) then it may =
process the request on behalf of that client. If the AS does not recognize =
the client ID, it must treat this as a new client registration and evaluate=
 any authorization evidence the client provides before enabling the client =
and mapping policies to that client=E2=80=9D (this means dynamic or automat=
ic clients need to provide additional assertions / software statements what=
ever to register their ID.
=C2=A0
Something like this allows for very flexible systems:
System A can be unknown to the AS but can dynamica=
lly registered each time with an appropriate software statement
System B can have a fairly stable client ID at the AS, bu=
t rotate that ID every month through automatic registration (with an assert=
ion it got from the AS during a pre-registration for example)=

System C can pre-register with the AS for a client ID becau=
se it doesn=E2=80=99t deal with software statements etc=E2=80=A6<=
/u>
=E2=80=A6
And even =E2=80=
=98StatelessAS=E2=80=99 can operate by never storing client IDs because it =
will always just rely on the software statements.
=C2=A0
I think a client registration proto=
col that allows these scenarios would be very useful in GNAP, but hopefully=
 avoiding having to define what =E2=80=98evidence=E2=80=99 the AS needs to =
accept for each scenario.
=C2=A0=

Thanks,
=C2=A0
MV
=C2=A0
From:=C2=A0Txauth <txauth-bounces@i=
etf.org> on behalf of Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.iet=
f.org>
Date:=C2=A0Tuesday, July 14, 2020 at 1=
2:18 PM
To:=C2=A0Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
Subject:=C2=A0Re: [Txau=
th] Key handle vs client id & handle
=C2=A0
I agree that there are significant differences bet=
ween statically and dynamically registered clients and that=E2=80=99s appro=
priate to be able to syntactically differentiate between them at runtime.=
=C2=A0 For one thing, the resource requirements at the authorization server=
 can be very different.
=C2=A0
We should also be thinking about how to in=
clude what the OpenID Connect Federation spec=C2=A0https:=
//openid.net/specs/openid-connect-federation-1_0.html=C2=A0calls =E2=80=9CAutomatic Registration=E2=80=9D.=C2=A0 This lets the client=
 encode a registration request reference in the client ID, so no static or =
dynamic registration even occurs.=C2=A0 See=C2=A0https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.secti=
on.9.1.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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:=
=C2=A0Dick Hardt <dick.h=
ardt@gmail.com>=C2=A0
Sent:=C2=A0Friday, July 10, 2020 1:17 PM
To:=C2=A0txauth@ietf.org; Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Su=
bject:=C2=A0Key handle vs client id & handle=

=C2=A0
=C2=A0
My understanding is tha=
t an existing OAuth 2 client would use their current client id as their key=
 handle, and a dynamic client (one that was not pre-registered) would be gi=
ven a key handle by the AS.
=
=C2=A0
There are potentially s=
ome significant differences between a registered client, and a dynamic clie=
nt to an AS.
=C2=A0<=
/u>
The AS is likely to know the identity of=
 a registered client, and have different policies between the two types of =
clients. For example, a registered client may have access to a 'write&q=
uot; scope, while a dynamic client does not.
=

=C2=A0
The AS m=
ay have 100s or 1000s of registered clients, but a dynamic client may have =
10Ms or 100Ms of instances, which may dictate separate=C2=A0storage service=
s. Additionally, internal to the AS, which systems can write to the registe=
red=C2=A0client store is going to be different than the dynamic client=C2=
=A0store.
=C2=A0=

In XYZ, subsequent calls to the AS, both re=
gistered clients and dynamic clients pass a key handle, so there is no easy=
 way to differentiate between the two.
=C2=A0
While the AS c=
ould embed semantics in the key handle identifier to indicate which identif=
iers are pre-registered vs dynamic, there are many cases where the AS does =
need to know the difference, so making=C2=A0the difference a feature of GNA=
P seems like a better path.
=C2=A0
=C2=A0
Th=
is email and any attachments are for the sole use of the intended recipient=
s and may be privileged, confidential or otherwise exempt from disclosure u=
nder law. Any distribution, printing or other use by anyone other than the =
intended recipient is prohibited. If you are not an intended recipient, ple=
ase contact the sender immediately, and permanently delete this email and i=
ts attachments.

-- 

Txauth mailing list

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





--00000000000045043b05aa92d247--


From nobody Thu Jul 16 11: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 799CF3A00C4 for ; Thu, 16 Jul 2020 11:16:03 -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 2hG7R9xN9daW for ; Thu, 16 Jul 2020 11:16:00 -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 D1EC83A00C3 for ; Thu, 16 Jul 2020 11:15:59 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id j11so9258709ljo.7 for ; Thu, 16 Jul 2020 11:15: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=HUSy/p2zaikhjyfThZLkwUbe7+66gAAvbhMS5gtNUyA=; b=EOragD6FqkL4nMk9A+w+HjCdPQs0ZPuDdO7wZZbT7Zlb4+UEJbXdEkDnFuQZEXfLBe Uxt5Jl7WNJCN780fEzhmaEF/J9+sBO9u9kjJ2DrXKR5eFXtuXkZ1HPr9ooaTh+8CO9E3 NaaRoI5GUEw5Sx85PUe3xqVi88IE3wgztxep24FwmtyEoFZhcFpTnW38n5sYrKaXYtsk Pf843pTldH1ywjfQALGVBosDJQrYa3P3HTez0TiwPs/OhL66O9qh2Ck8UpjVoFLfv7Uw j6kpsloTOvAeUf0W7/JrhBEqz5+jHdPlnmFP/RKSMu86yIx/dnDgx9lSthiWns5RY3AK Rj3Q==
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=HUSy/p2zaikhjyfThZLkwUbe7+66gAAvbhMS5gtNUyA=; b=qTG6pZJ4gD/H/yYqJbjseHBC7RmD+Kgh/OjfUyjZYIHmsqXVM+4wn1bfc7ICc/96qC qCiw3JJsCz9EX8cGyNG4Qa3EQ8awo3qlziy/6sfInxICJkab6VmfAsBuL0eM+6jWhmgs 9aF7yP/6goF4Hy89pau0jgxEoDXN1BmWVS6Hsambjs19e4YYC005ZReTbm9Sba9OqHpI j1+XtqyuYj4eKjel0w37L0NHWjKr0cwzNJCRyeDe1Rp4zWUKPhgt1W+SIA6XeJD7g1IJ rZUKhzWnKdyL8Or13c1V9qTyQeA4x0n4+cwtbNUbD2YWSO9yMSdivcIyizjcxUNzPupj Zu2Q==
X-Gm-Message-State: AOAM532DTI+1D89vtJnAuLJjJ4cwqQHQ3SciCA+/6ycQMNAumE1K3hnJ fC1djIAZGtsykUb1dWlNm0+YsK0ZK7tD6c11p5x/4+Nw
X-Google-Smtp-Source: ABdhPJz8yRMIcMhnwBORLC5Tj0iwRWsy6g5/GKJdxf6uw9ELmcHxZxmzjULLZoQqdQY0gytHsayO9CQQNgt/pNrJdzI=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr2798986ljg.69.1594923357835; Thu, 16 Jul 2020 11:15:57 -0700 (PDT)
MIME-Version: 1.0
References:          
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 16 Jul 2020 11:15:21 -0700
Message-ID: 
To: Denis 
Cc: Francis Pouatcha , txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000030181705aa93080c"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 16 Jul 2020 18:16:04 -0000

--00000000000030181705aa93080c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Francis

Thanks for drafting the sequence diagram and descriptions! I really like
where. you are going with it.

As our objective is to provide an abstraction,  what do you think of
collapsing steps 2&3, 5&6, and 8&9 in the diagram?

Per the discussion to your post, there is also some tuning of the
descriptions of each step. I would also add in which steps are optional.

Referencing other parts of the document would be useful, as this
abstraction is intended to be a high level guide to the protocol, so adding
other top level sections to the document, even if they are thin, would help
the reader in grasping the possible flows.

/Dick

On Thu, Jul 16, 2020 at 9:57 AM Denis  wrote:

> Hello Francis,
>
> Hello Denis,
>
> On Thu, Jul 16, 2020 at 8:45 AM Denis  wrote:
>
>> Hello  Francis,
>>
>> The first two steps of your scenario are nice, in particular the second
>> one:
>>
>> (2) Service Intent: In order to discover *authorization requirements*,
>> the Client sends a service intent to the RS.
>>
>> This means that the client first contacts the RS, instead of the GS.
>>
>
>> However, the third step is missing to disclose to the client these "*aut=
horization
>> requirements*", in particular which AS(s),
>> it may contact, which attributes are requested and how/when/where the
>> user consent is gathered.
>>
>> The response (2) AuthZ Challenge carries the reference to the GS. Mean
> the resource server instructs the Client on which GS to approach for
> authorization.
>
> This information was not mentioned in your description.
>
>
>> Unless the scenario is mandating all the RSs to trust one and only one G=
S
>> and the client to have a relationship with that GS,
>> the remaining steps of this scenario do not work.
>>
>> Can you elaborate why it shall not work for many GSs?
>
> Your answer above mentions : "which GS to approach for authorization". It
> uses the singular whereas it should use the plural.
>
> In addition, indicating only which GS*s* (plural) is insufficient, since
> the RS also needs to indicate to the Client which attributes
> are requested for each of these GSs.
>
> Your description is also silent to explain how/when/where the user consen=
t
> is gathered.
>
>
>>
> Step (5) mandates the GS to know who the owner of a given RS is
>>
> Step (5) mandates the GS to know the RO, as owner of the target Resource,
> but not the RS (Resource Server). Resource not-equals RS.
>
> , and thus mandates the client to disclose to the GS the identity of the
>> RS.
>>
>
> No. Here there is no requirement from GS to know the RS.
>
> In your are using the terminology of RFC 6749, then page 5 states:
>
> In OAuth, the client requests access to resources controlled by the
> resource owner and hosted by the resource server.
>
> In order to make sure that the right RO is in charge of the appropriate
> RS, the GS needs to maintain a mapping between the RS and the RO.
> The client does not know who the ROs are.
>
>
>
>> The consequence is the following : this scenario, *as well as the
>> scenario described in draft-hardt-xauth-protocol-13*, allows the GS to
>> act as Big Brother.
>>
> No.
>
> If the GS is in a position to know when a client is attempting to make an
> access to a given RS, then it can maintain logs of these events.
>
> RS will find a way to validate AuthZ produced by any GS.
>
> No. A RS trusts some GSs for some kinds of attributes. It does not trust
> all the GSs that might exist in the world.
>
> Means RS must trust that very GS or trust somebody that trusts that very
> GS (e.g. CA).
>
> Trust relationships are not necessarily transitive (nor bilateral).
>
> GS must not know the RS but must understand the Resource and trust the
> Resource Owner, so that GS can validate the RO Grant.
>
> It would be interesting if you could elaborate on the last part of this
> sentence :
> "[GS] must understand the Resource and trust the Resource Owner, so that
> GS can validate the RO Grant".
>
> Denis
>
>
> /Francis
>
>>
>> Denis
>>
>> Hello Fabian,
>>
>> On Thu, Jul 16, 2020 at 4:47 AM Fabien Imbault 
>> wrote:
>>
>>> Hi,
>>>
>>> That's interesting, however the important logic is actually implemented
>>> within (5). And so for the reader, it might be quite difficult to
>>> understand what we're after (compared to oauth2 for instance). So in my
>>> view, this kind of schema has its place, but not at the start of the
>>> document where we should primarily be concerned about explaining why
>>> someone should read the document..
>>>
>>> It's also not easy to understand :
>>> - why we sometimes use different labels between requests and responses
>>> (for instance, 5 and 6)
>>>
>> Will need support in drafting the correct terms. The main purpose of thi=
s
>> diagram is to help sharpen the definition of terms and verbs used in the
>> draft.
>>
>> - sometimes we use "grant" and sometimes "authZ", and it doesn't seem
>>> very clear what is the difference in use
>>>
>> IMO: the granting is the process of given permission.
>> - RO can grant his Consent to the User or Client
>> - GS can turn the RO Grant into an AuthZ.
>> - Client can use AuthZ to access a Resource.
>>
>> A terminology section would be great to clarify.
>>>
>> Yes. There is a terminology section in there. We need to bring the
>> wissing words into the list and sharpen those already there.
>>
>>>
>>> If I understand correctly your remark in 5, you think the
>>> request/response scheme (as in XYZ) may be misleading.
>>>
>> No. XYZ does IMO exactly  that. Just try to be more abstract for a bette=
r
>> description of the models.
>>
>>
>>> On the contrary, I think it allows support rich interaction scenarios
>>> (and especially the ones you describe) with greater flexibility.
>>>
>> Flexibility shall not be put ahead of formal correctness.
>>
>>
>>> For instance, some would disagree with the assertion that the goal is
>>> for the GS to gather consent (see discussion on putting that on client
>>> side). A fixed interaction schema has the downside of not permitting ot=
her
>>> setups.
>>>
>> This discussion is the result of the lack of sharp terminology. Most of
>> the time mixing up gathering consent (the act) and the way consent is
>> gathered and transported from RO to GS (the interaction).
>> /Francis
>>
>>
>>> Fabien
>>>
>>> On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha >> 40adorsys.de@dmarc.ietf.org> wrote:
>>>
>>>> Hello Dick,
>>>>
>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 2. Abstract Protocol Flow
>>>>>>>> I am missing an abstract protocol flow like the one defined in
>>>>>>>> https://tools.ietf.org/html/rfc6749#section-1.2.
>>>>>>>>
>>>>>>>
>>>>>>> That's an interesting point. GNAP also has identity claims, so the
>>>>>>> abstract flow is somewhat different (there is no Authorization Gran=
t from
>>>>>>> the RO), and not all steps always happen. (there may not be steps (=
E) and
>>>>>>> (F) with a Resource Server)
>>>>>>>
>>>>>>> Would you elaborate on what you think would be useful here, that is
>>>>>>> not in the specific flows?
>>>>>>>
>>>>>> A diagram that generalizes the steps, independently of interaction
>>>>>> mode is essential for the reader's navigation of the rest of the
>>>>>> document. This is what #section-1.2 of RFC6749 does. I hope we can p=
roduce
>>>>>> a similar diagram.
>>>>>>
>>>>>> A subsection of
>>>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.=
1
>>>>>> could be defined for this.
>>>>>>
>>>>>
>>>>> Interaction modes are one dimension where the steps could be
>>>>> generalized, but some steps are optional. For example, the User may n=
ot
>>>>> interact with the GS, and the GS may interact with the RO. The Client=
 may
>>>>> only want claims, and there would be no step of the Client calling th=
e RS.
>>>>>
>>>>> A generalized diagram would need to include all optional steps so tha=
t
>>>>> it did not mislead a reader into thinking the diagram included all ge=
neral
>>>>> steps, but it does not seem that is what you are asking for as you wr=
ote:
>>>>>
>>>>> A subsection of
>>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>>>> could be defined for this."
>>>>>
>>>>> Perhaps you can share how you think the diagram would look?
>>>>>
>>>> find below my proposal of an abstract sequence diagram.
>>>>
>>>> +----+  +------+  +---+  +---+  +---+
>>>> |User|  |Client|  |RS |  |GS |  |RO |
>>>> +----+  +------+  +---+  +-+-+  +-+-+
>>>>   |(1) Service Request     |      |
>>>>   |-------->|       |      |      |
>>>>   |         |(2) Service Intent   |
>>>>   |         |------>|      |      |
>>>>   |         |(3) AuthZ Challenge  |
>>>>   |         |<------|      |      |
>>>>   |         |(4) AuthZ Request    |
>>>>   |         |------------->|      |
>>>>   |         |       |      |(5) Consent Request
>>>>   |         |       |      |----->|
>>>>   |         |       |      |(6) Grant Consent
>>>>   |         |       |      |<-----|
>>>>   |         |(7) Grant Access (Token)
>>>>   |         |<-------------|      |
>>>>   |         |(8) Service Request (Token)
>>>>   |         +------>+      |      |
>>>>   |         |(9) Service Response |
>>>>   |         |<------|      |      |
>>>>   |(10) Service Response   |      |
>>>>   +<--------|       |      |      |
>>>>   +         +       +      +      +
>>>>
>>>> (1) Service Request: This is the service request sent by a User to the
>>>> Client. This can be a simple file read request or even a complex payme=
nt
>>>> initiation request.
>>>>
>>>> (2) Service Intent: In order to discover authorization requirements,
>>>> the Client sends a service intent to the RS.
>>>>
>>>> (3) AuthZ Challenge: The response to a service intent request is
>>>> generally an AuthZ Challenge. The content of this AuthZ Challenge, can=
 be
>>>> an identification challenge, an AuthZ exemption, or details on request=
ed
>>>> AuthZ. The content AuthZ Challenge can be similar to the oAuth2 RAR.
>>>>
>>>> (4) AuthZ Request : the Client sends an AuthZ Request to the GS
>>>> including the AuthZ Challenge. This request can be similar to the oAut=
h PAR
>>>> request.
>>>>
>>>> (5) Requests Consent : GS sends consent request to RO.
>>>> Remark: The abstract protocol flow does not display a response of the
>>>> request (4) to the Client. This is IMO a general misunderstanding. Thi=
s
>>>> protocol wants the GS to collect a consent from the RO.
>>>> - In the case of a "redirect interaction", GS will use transport
>>>> infrastructure provided by the Client to instruct the User to send the=
 RO
>>>> to the GS (in most cases, user and RO are identical).
>>>> - In the case of a "decoupled interaction", GS will directly contact R=
O
>>>> and collect consent in a direct interaction with the RO (see CIBA).
>>>> - In the case of an "embedded interaction", GS will allow the Client t=
o
>>>> directly collect the Consent of the RO in a direct interaction with th=
e
>>>> User.
>>>>
>>>> (6) Grant Consent : RO return a Consent Grant to GS.
>>>>
>>>> (7) Grant Access : GS produces the corresponding access token and
>>>> returns it to Client.
>>>>
>>>> (8) Service Request : Client uses the access token to send the service
>>>> request to RS.
>>>>
>>>> (9) and (10) are self explaining....
>>>>
>>>> One of our upcoming exercises will be to challenge this abstract
>>>> protocol flow with existing interactions (and if possible associated u=
se
>>>> cases) to see if we are missing something. After an agreement on the
>>>> abstract protocol flow we can make sure each interaction provides a ma=
pping
>>>> to step 1 to 10.
>>>>
>>>> I will strip the rest of the post here. And bring further responses in
>>>> separate mails.
>>>>
>>>> Best regards.
>>>> /Francis
>>>>
>>>>> =E1=90=A7
>>>>>
>>>> --
>>>> 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/
>
>
>

--00000000000030181705aa93080c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Francis

Thanks for drafting the sequ=
ence diagram and descriptions! I really like where. you are going with it.<=
/div>

As our objective is to provide an abstraction,=C2=
=A0 what do you think of collapsing steps 2&3, 5&6, and 8&9 in =
the diagram?

Per the discussion to your post, ther=
e is also some tuning of the descriptions of each step. I would also add in=
 which steps are optional.

Referencing other parts=
 of the document would be useful, as this abstraction is intended to be a h=
igh level guide to the protocol, so adding other top level sections to the =
document, even if they are thin, would help the reader in grasping the poss=
ible flows.

/Dick

On Thu, Jul 16, 2020 at 9:5=
7 AM Denis <denis.ietf@free.fr=
> wrote:

 =20
   =20
 =20
  

    
Hello Francis,

    


    

    

     =20
      

        
Hello Denis,

        

        

          
On Thu, Jul 16, 2020 at 8:4=
5
            AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              
Hello=C2=A0 Francis,

                

              

              
The first two steps of your scenario are nice, in
                particular the second one:

              

                
(2) Service Intent: In order to discover authorizat=
ion
                    requirements, the Client sends a service intent
                  to the RS.

              

              
This means that the client first contacts the RS,
                instead of the GS.=C2=A0

            

          

          

            

              


              

              
However, the third step is missing to disclose to the
                client these "authorization requirements",=
 in
                particular which AS(s), 

                it may contact, which attributes are requested and
                how/when/where the user consent is gathered.

                

              

            

          

          
The response (2) AuthZ Challenge carries the reference to
            the GS. Mean the resource server instructs the Client on
            which GS to approach for authorization. 

          

        

      

    

    
This information was not mentioned in your description.

    

      

        

          

            

              
 

                Unless the scenario is mandating all the RSs to trust
                one and only one GS and the client to have a
                relationship with that GS, 

                the remaining steps of this scenario do not work.

                

              

            

          

          
Can you elaborate why it shall not work for=C2=A0many GSs?
        

      

    

    
Your answer above mentions : "which GS to approach for
      authorization". It uses the singular whereas it should use the
      plural.

    
In addition, indicating only which GSs (plural) is
      insufficient, since the RS also needs to indicate to the Client
      which attributes 

      are requested for each of these GSs.

    
Your description is also silent to explain how/when/where the
      user consent is gathered.

    

      

        

          

            

              
=C2=A0

            

          

          

            

              
Step (5) mandates the GS to know who the owner of a
                given RS is

            

          

          
Step (5) mandates the GS to know the RO, as owner of the
            target Resource, but not the RS (Resource Server). Resource
            not-equals=C2=A0RS.

          


          

          

            

              
, and thus mandates the client to disclose to the GS
                the identity of the RS. 

              

            

          

        

      

    

    

    

      

        

          
No. Here there is no requirement from GS to know the RS.
        

      

    

    
In your are using the terminology of RFC 6749, then page 5
      states:

    

      
In OAuth, the client requests access to resources controlled by
        the resource owner and hosted by the resource server.

      

    

    
In order to make sure that the right RO is in charge of the
      appropriate RS, the GS needs to maintain a mapping between the RS
      and the RO.

      The client does not know who the ROs are.

    

      

        

          
=C2=A0

          

            

              
The consequence is the following : this scenario, as
                  well as the scenario described in
                  draft-hardt-xauth-protocol-13, allows the GS to
                act as Big Brother. 

              

            

          

          
No. 

          

        

      

    

    
If the GS is in a position to know when a client is attempting to
      make an access to a given RS, then it can maintain logs of these
      events.

    

    

      

        

          
RS will find a way to validate AuthZ produced by any GS.
          

        

      

    

    
No. A RS trusts some GSs for some kinds of attributes. It does
      not trust all the GSs that might exist in the world.

    

      

        

          
Means RS must trust that very GS or trust somebody=C2=A0that
            trusts that very GS (e.g. CA).

        

      

    

    
Trust relationships are not necessarily transitive (nor
      bilateral).

    

      

        

          
GS must not know the RS but must understand the Resource
            and trust the Resource Owner, so that GS can validate the RO
            Grant.

        

      

    

    
It would be interesting if you could elaborate on the last part
      of this sentence :

      "[GS] must understand the Resource and trust the Resource Owner,
      so that GS can validate the RO Grant".

    
Denis

    

    

      

        

          


          

          
/Francis

          

            

              
 

              


              

              
Denis

              

              

              

                

                  
Hello Fabian,

                  

                  

                    
On Thu, Jul 16,
                      2020 at 4:47 AM Fabien Imbault <fabien.imbault@gmail.com>=
;
                      wrote:

                    

                    

                      
Hi,=C2=A0
                        


                        

                        
That's interesting, however the important
                          logic is actually implemented within (5). And
                          so for the reader, it might be quite difficult
                          to understand what we're after (compared to
                          oauth2 for instance). So in my view, this kind
                          of schema has its place, but not at the start
                          of the document where we should primarily be
                          concerned about explaining why someone should
                          read the document..

                        


                        

                        
It's also not easy to understand :=C2=A0
                        
- why we sometimes use different labels
                          between requests and responses (for instance,
                          5 and 6)

                      

                    

                    
Will need support in drafting the correct
                      terms. The main purpose of this diagram=C2=A0is to he=
lp
                      sharpen the definition of terms and verbs used in
                      the draft.

                    


                    

                    

                      

                        
- sometimes we use "grant" and somet=
imes
                          "authZ", and it doesn't seem very c=
lear what
                          is the difference in use

                      

                    

                    
IMO: the granting is the process of given
                      permission.

                    
- RO can grant his Consent to the User or
                      Client

                    
- GS can turn the RO Grant into an AuthZ.

                    
- Client can use AuthZ to access a Resource.

                    


                    

                    

                      

                        
A terminology section would be great to
                          clarify.

                      

                    

                    
Yes. There is a terminology section in there.
                      We need to bring the wissing words into the list
                      and sharpen those already there.=C2=A0

                    

                      

                        


                        

                        
If I understand correctly your remark in 5,
                          you think the request/response scheme (as in
                          XYZ) may be misleading.=C2=A0

                      

                    

                    
No. XYZ does IMO exactly=C2=A0 that. Just try to b=
e
                      more abstract for a better description of the
                      models.

                    
=C2=A0

                    

                      

                        
On the contrary, I think it allows support
                          rich interaction scenarios (and especially the
                          ones you describe) with greater flexibility. 
                      

                    

                    
Flexibility shall not be put ahead of formal
                      correctness.

                    
=C2=A0

                    

                      

                        
For instance, some would disagree with the
                          assertion that the goal is for the GS to
                          gather consent (see discussion on putting that
                          on client side). A fixed interaction schema
                          has the downside of not permitting other
                          setups.

                      

                    

                    
This discussion is the result of the lack of
                      sharp terminology. Most of the time mixing up
                      gathering consent (the act) and the way consent is
                      gathered and transported from RO to GS (the
                      interaction).

                    
/Francis

                    


                    

                    

                      

                        


                        

                        
Fabien

                      

                      

                      

                        
On Thu, Jul
                          16, 2020 at 5:28 AM Francis Pouatcha <fpo=3D40adorsys.de=
@dmarc.ietf.org>
                          wrote:

                        

                        

                          

                            
Hello
                                Dick,
                              


                                

                            

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                
=C2=A0

                                                

                                                  

                                                    

                                                      

                                                        


                                                          

                                                        
2.
                                                          Abstract
                                                          Protocol Flow

                                                        

                                                          
I
                                                          am missing an
                                                          abstract
                                                          protocol flow
                                                          like the one
                                                          defined in htt=
ps://tools.ietf.org/html/rfc6749#section-1.2.

                                                        

                                                      

                                                    

                                                  

                                                

                                                


                                                  

                                                
That's
                                                    an interesting
                                                    point. GNAP also has
                                                    identity claims, so
                                                    the abstract flow is
                                                    somewhat different
                                                    (there is no
                                                    Authorization Grant
                                                    from the RO), and
                                                    not all steps always
                                                    happen. (there may
                                                    not be steps (E) and
                                                    (F) with a Resource
                                                    Server)

                                                


                                                  

                                                
Would
                                                    you elaborate on
                                                    what you think would
                                                    be useful here, that
                                                    is not in the
                                                    specific flows?<=
/div>
                                              

                                            

                                          

                                          
A
                                              diagram that generalizes
                                              the steps, independently
                                              of interaction mode is
                                              essential for the reader'=
s
                                              navigation of the rest of
                                              the document.=C2=A0This is
                                              what=C2=A0#section-1.2 of
                                              RFC6749 does. I hope we
                                              can produce a similar
                                              diagram.

                                          

                                            

                                          
A
                                              subsection of=C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#se=
ction-1.1
                                              could be defined for this.

                                        

                                      

                                    

                                    


                                      

                                    
Interacti=
on
                                        modes are one dimension where
                                        the steps could be generalized,
                                        but some steps are optional. For
                                        example, the User may not
                                        interact with the GS, and the GS
                                        may interact with the RO. The
                                        Client may only want claims, and
                                        there would be no step of the
                                        Client calling the RS.

                                    


                                      

                                    
A
                                        generalized diagram would need
                                        to include all optional steps so
                                        that it did not mislead a reader
                                        into thinking the diagram
                                        included all general steps, but
                                        it does not seem that is what
                                        you are asking for as you wrote:

                                    


                                      

                                    
A
                                        subsection of=C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-=
1.1
                                        could be defined for this."
                                      

                                    


                                      

                                    
Perhaps
                                        you can share how you think the
                                        diagram would look?

                                  

                                

                              

                              
find below my
                                  proposal of an abstract sequence
                                  diagram.

                              


                                

                              
+----+
                                  =C2=A0+------+ =C2=A0+---+ =C2=A0+---+ =
=C2=A0+---+

                                  |User| =C2=A0|Client| =C2=A0|RS | =C2=A0|=
GS | =C2=A0|RO |

                                  +----+ =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 |(2)=
 Service Intent =C2=A0 |

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =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)=
 AuthZ Challenge =C2=A0|

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =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)=
 AuthZ 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|(5)
                                  Consent 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|(6) Grant
                                  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 |(7)=
 Grant Access (Token)

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<=
;-------------| =C2=A0 =C2=A0 =C2=A0|

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(8)=
 Service Request
                                  (Token)

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---=
--->+ =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(9)=
 Service Response |

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<=
;------| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|

                                  =C2=A0 |(10) Service Response =C2=A0 | =
=C2=A0 =C2=A0 =C2=A0|

                                  =C2=A0 +<--------| =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|

                                  =C2=A0 + =C2=A0 =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) Service
                                  Request: This is the service request
                                  sent by a User to the Client. This can
                                  be a simple file read request or even
                                  a complex payment initiation request.

                              


                                

                              
(2) Service
                                  Intent: In order to discover
                                  authorization requirements, the Client
                                  sends a service intent to the RS.<=
/div>
                              


                                

                              
(3) AuthZ
                                  Challenge: The response to a service
                                  intent request is generally an AuthZ
                                  Challenge. The content of this AuthZ
                                  Challenge, can be an identification
                                  challenge, an AuthZ exemption, or
                                  details on requested AuthZ. The
                                  content AuthZ Challenge can be similar
                                  to the oAuth2 RAR.

                              


                                

                              
(4) AuthZ
                                  Request : the Client sends an AuthZ
                                  Request to the GS including the AuthZ
                                  Challenge. This request can be similar
                                  to the oAuth PAR request.

                              


                                

                              
(5) Requests
                                  Consent : GS sends consent request to
                                  RO.=C2=A0

                              
Remark: The
                                  abstract protocol flow does not
                                  display a response of the request (4)
                                  to the Client. This is IMO a general
                                  misunderstanding. This protocol wants
                                  the GS to collect a consent from the
                                  RO.=C2=A0

                              
- In the case
                                  of a "redirect interaction", GS=
 will
                                  use transport infrastructure provided
                                  by the Client to instruct the User to
                                  send the RO to the GS (in most cases,
                                  user and RO are identical).

                              
- In the case
                                  of a "decoupled interaction", G=
S will
                                  directly contact RO and collect
                                  consent in a direct interaction with
                                  the RO (see CIBA).

                              
- In the case
                                  of an "embedded interaction", G=
S will
                                  allow the Client to directly collect
                                  the Consent of the RO in a direct
                                  interaction with the User.

                              


                                

                              
(6) Grant
                                  Consent : RO return a Consent Grant to
                                  GS.

                              


                                

                              
(7) Grant
                                  Access : GS produces the corresponding
                                  access token and returns it to Client.

                              


                                

                              
(8) Service
                                  Request : Client uses the access token
                                  to send the service request to RS.=


                              


                                

                              
(9) and (10)
                                  are self explaining....

                              


                                

                              
One of our
                                  upcoming=C2=A0exercises will be to
                                  challenge this abstract protocol flow
                                  with existing interactions=C2=A0(and if
                                  possible associated use cases) to see
                                  if we are missing something. After an
                                  agreement on the abstract protocol
                                  flow we can make sure each interaction
                                  provides a mapping to step 1 to 10.

                              


                                

                              
I
                                  will strip the rest of the post here.
                                  And bring further responses in
                                  separate mails.

                              

                                

                              
Be=
st
                                  regards.

                              
/F=
rancis=C2=A0=C2=A0

                              

                                

                                  

                                    

                                    

                                  

                                

                                
3D""=E1=
=90=A7

                              

                            

                            -- 

                            
                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              
Francis
                                                  Pouatcha

                                              
Co-Founder
                                                  and Technical Lead=


                                              
adorsys
                                                  GmbH & Co. KG<=
/div>
                                              
                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                          -- 

                          Txauth mailing list

                          Txauth@ietf.org

                          https://www.ietf.org/mailman/l=
istinfo/txauth

                        

                      

                    

                  

                  

                  


                  

                  -- 

                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    
Francis Pouatcha

                                    
Co-Founder and Technical Lead
                                    
adorsys GmbH & Co. KG

                                    
                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

                

                

              

              


              

            

          

        

        

        


        

        -- 

        
      

    

    


    

  





--00000000000030181705aa93080c--


From nobody Thu Jul 16 12:26:41 2020
Return-Path: 
X-Original-To: txauth@ietf.org
Delivered-To: txauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 318D83A0B44; Thu, 16 Jul 2020 12:26:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: rdd@cert.org, txauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.8.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159492757819.14301.12018762959870734961@ietfa.amsl.com>
Date: Thu, 16 Jul 2020 12:26:18 -0700
Archived-At: 
Subject: [Txauth] gnap - Requested session has been scheduled for IETF 108
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jul 2020 19:26:18 -0000

Dear Amy Vezza,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


    gnap Session 1 (1:40 requested)
    Monday, 27 July 2020, Session III 1410-1550
    Room Name: Room 7 size: 7
    ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/108/sessions/gnap.ics

Request Information:


---------------------------------------------------------
Working Group Name: Grant Negotiation and Authorization Protocol
Area Name: Security Area
Session Requester: Amy Vezza


Number of Sessions: 1
Length of Session(s):  100 Minutes
Number of Attendees: 100
Conflicts to Avoid: 
 Chair Conflict: ace acme cose curdle dots emu i2nsf ipsecme kitten lake lamps mile mls oauth rats sacm secdispatch secevent suit teep tls tokbind trans httpbis quic saag







People who must be present:
  Yaron Sheffer
  Roman Danyliw

Resources Requested:

Special Requests:
  
---------------------------------------------------------



From nobody Thu Jul 16 13:05: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 11DA13A0C0A for ; Thu, 16 Jul 2020 13:05: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, 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 ahZCOmKvT04w for ; Thu, 16 Jul 2020 13:05:41 -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 112ED3A0C0C for ; Thu, 16 Jul 2020 13:05:40 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id z15so8349299wrl.8 for ; Thu, 16 Jul 2020 13:05: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=Bq37XJE9iinHP6K1pNJWIijP0OuVDHUKxj67zTygdKU=; b=L0Gvamh/OwPdjgxA2Ly/hTgZjgbKYJPAzM0tsULRZ4S4750tVj7HkywCcMIzfsHMKS iLQGvAiQvCWKy9eef5koY+oJyX2bkE+X1c5JtadQYKZln40aVEPa2rv3BS5q0p+vhATG SIwXm51K9WEYb4Wa3sH8FDwbejioVTk0aAS/0=
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=Bq37XJE9iinHP6K1pNJWIijP0OuVDHUKxj67zTygdKU=; b=RJ50XLw82A9hexZBBKl8J6xprZ9elsNWc0lhF6kPzr2SNkES/v8gJPRypZ+b8SAl2x eYHV4NWpStjAg/6aPxK/LbvvGKNwFB/ZzoF+nPpjZuHve5tuJdm6P9whraVD2XBeHX45 995YEhaimjRtPKVHKfjruSmXHK6QhwtGfbLmaqzahRENZit2z0fjFjyxncQmPry2qLre 2NUTh0Jt5Ys2/NKYhx8PFc5YWhFRIQ64Y+AY1wWgzrz7T69CFbkg5i4mjMirmMnXUc5y T0JDRxsupmqFip6Y0ltlwTFPe+IH4w82X0VYpTQYlJnpP2zhJ9PfkTeLHUSvrIFwikrv 2+Bg==
X-Gm-Message-State: AOAM530Uf2aEol1CeGNx3ItAAn8nW792VDSh6k4TVfOIywgbuiW3hN9F Tp4AkoFXVpScxcWIAf7d7y7DneCGgR2Ro3HvHyM4mNLPEo4=
X-Google-Smtp-Source: ABdhPJxZM0rM0WV1uxRXAat9+y84iSBvaLNkEVN1XPWmLtiV/OfSzFPuJ9Ga35YFUWbZjyQXjpYMcm+bMv+RfzUtkMA=
X-Received: by 2002:adf:c382:: with SMTP id p2mr6423226wrf.283.1594929938738;  Thu, 16 Jul 2020 13:05:38 -0700 (PDT)
MIME-Version: 1.0
References:           
In-Reply-To: 
From: Francis Pouatcha 
Date: Thu, 16 Jul 2020 16:05:27 -0400
Message-ID: 
To: txauth@ietf.org
Cc: Dick Hardt , Denis 
Content-Type: multipart/alternative; boundary="00000000000070c6bf05aa9490cc"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 16 Jul 2020 20:05:45 -0000

--00000000000070c6bf05aa9490cc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Dick, Denis,

here is an updated version of the diagram following Dick's advice to
collapse responses and some clarifications as raised by Denis:

+----+  +------+  +---+  +---+  +---+
|User|  |Client|  |RS |  |GS |  |RO |
+----+  +------+  +---+  +-+-+  +-+-+
  |(1) ServiceRequest      |      |
  |-------->|       |      |      |
  |         |(2) ServiceIntent:AuthZChallenge
  |         |<----->|      |      |
  |         |       |      |      |
  |         |(3) AuthZRequest(AuthZChallenge)
  |         |------------->|      |
  |         |       |      |(4) ConsentRequest:Grant
  |         |       |      |<---->|
  |         |(5) GrantAccess(AuthZ)
  |         |<-------------|      |
  |         |       |      |      |
  |         |(6) ServiceRequest(AuthZ):ServiceResponse
  |         |<----->|      |      |
  |(7) ServiceResponse     |      |
  |<--------|       |      |      |
  +         +       +      +      +

Nomenclature of Arrows:
---> designate a request.
<--- designates a response.
<--> request with immediate response.

Step, Action and Interaction:
This diagram describes actions and not interactions:
- Each step carries a number.
- An action with immediate response is collapsed into a single step (2, 4,
6).
- An action with deferred response is represented by two steps (1&7, 3&5).
- An action might be carried out using many interactions and might for the
purpose of transport involve more parties (see redirect interaction bellow)

(1) ServiceRequest
This is the service request sent by the User to the Client. This can be a
simple file read request or a complex payment initiation request.

(2) ServiceIntent:AuthZChallenge
In order to discover authorization requirements, the Client sends
a ServiceIntent request to the RS. The response to a ServiceIntent request
is an AuthZChallenge.
The content of an AuthZChallenge can be similar to the oAuth2 RAR.
The content of the AuthZChallenge can be:
- An identification challenge. Generally when the RS can not associate the
ServiceRequest with an RO.
- An AuthZ exemption. Generally when the RS needs no further AuthZ to
fulfill the Client request.
- Details on the requested AuthZ, including instructions on which GSs the
Client can approach for AuthZ; instructions on which attributes are
requested for each of these GSs.

(3) AuthZRequest(AuthZChallenge)
The Client sends an AuthZRequest to the GS including the AuthZChallenge.
This request can be similar to the oAuth2 PAR request.

(4) ConsentRequest:Grant
GS sends a consent request to RO. The way a GS connects with the RO to
collect RO's consent (Grant) is dependent on the interaction mode. This is
also valid for the nature of the Grant returned by the RO to the GS.
- In the case of a "redirect interaction", GS will use the transport
infrastructure provided by the Client to instruct the User to send the RO
to the GS authorization endpoint (in most cases, user and RO are
identical). In the case of oAuth2 AuthCode flow, the Grant provided by the
RO is stored by the GS (AS) at the AuthZ endpoint, then mapped to an
authCode that is transported by the User (User Agent) through the Client to
the token endpoint of the GS.
- In the case of a "decoupled interaction", GS will directly contact RO and
collect consent in a direct interaction with the RO (see CIBA). This
diagram assumes GS can evaluate the AuthZChallenge to find out how to
locate the RO. As there is a direct interaction between the GS and the RO,
the form/nature of the Grant is left to the discretion of the concrete
interaction mode.
- In the case of an "embedded interaction", GS will allow the Client to
directly collect the Consent (Grant) of the RO in a direct interaction
between the Client and the User (also assuming in most cases, that user and
RO are identical); and then send it to the GS in exchange of the AuthZ. We
say the interaction between GS and RO is embedded in the communication with
the Client.

(5) GrantAccess(AuthZ)
>From evaluating the Grant provided by the client, the GS produces a
corresponding access token and returns it to the Client.
Note that GS knowledge of the original or target RS is not necessary for
the issuance of the access token, unless GS is required to bind the token
to a target RS.

(6) ServiceRequest(AuthZ):ServiceResponse
Client uses the GS provided AuthZ to send the service request to RS. Recall
that AuthZ (token) can be, but must not be bound to an RS.

(7) is self explaining.

One of our upcoming exercises will be to challenge this abstract protocol
flow with existing interactions (and if possible associated use cases) to
see if we are missing something. After an agreement on the abstract
protocol flow we can make sure each interaction provides a mapping to step
1 to 7.

/Francis

On Thu, Jul 16, 2020 at 2:15 PM Dick Hardt  wrote:

> Hi Francis
>
> Thanks for drafting the sequence diagram and descriptions! I really like
> where. you are going with it.
>
> As our objective is to provide an abstraction,  what do you think of
> collapsing steps 2&3, 5&6, and 8&9 in the diagram?
>
> Per the discussion to your post, there is also some tuning of the
> descriptions of each step. I would also add in which steps are optional.
>
> Referencing other parts of the document would be useful, as this
> abstraction is intended to be a high level guide to the protocol, so addi=
ng
> other top level sections to the document, even if they are thin, would he=
lp
> the reader in grasping the possible flows.
>
> /Dick
>
> On Thu, Jul 16, 2020 at 9:57 AM Denis  wrote:
>
>> Hello Francis,
>>
>> Hello Denis,
>>
>> On Thu, Jul 16, 2020 at 8:45 AM Denis  wrote:
>>
>>> Hello  Francis,
>>>
>>> The first two steps of your scenario are nice, in particular the second
>>> one:
>>>
>>> (2) Service Intent: In order to discover *authorization requirements*,
>>> the Client sends a service intent to the RS.
>>>
>>> This means that the client first contacts the RS, instead of the GS.
>>>
>>
>>> However, the third step is missing to disclose to the client these "*au=
thorization
>>> requirements*", in particular which AS(s),
>>> it may contact, which attributes are requested and how/when/where the
>>> user consent is gathered.
>>>
>>> The response (2) AuthZ Challenge carries the reference to the GS. Mean
>> the resource server instructs the Client on which GS to approach for
>> authorization.
>>
>> This information was not mentioned in your description.
>>
>>
>>> Unless the scenario is mandating all the RSs to trust one and only one
>>> GS and the client to have a relationship with that GS,
>>> the remaining steps of this scenario do not work.
>>>
>>> Can you elaborate why it shall not work for many GSs?
>>
>> Your answer above mentions : "which GS to approach for authorization". I=
t
>> uses the singular whereas it should use the plural.
>>
>> In addition, indicating only which GS*s* (plural) is insufficient, since
>> the RS also needs to indicate to the Client which attributes
>> are requested for each of these GSs.
>>
>> Your description is also silent to explain how/when/where the user
>> consent is gathered.
>>
>>
>>>
>> Step (5) mandates the GS to know who the owner of a given RS is
>>>
>> Step (5) mandates the GS to know the RO, as owner of the target Resource=
,
>> but not the RS (Resource Server). Resource not-equals RS.
>>
>> , and thus mandates the client to disclose to the GS the identity of the
>>> RS.
>>>
>>
>> No. Here there is no requirement from GS to know the RS.
>>
>> In your are using the terminology of RFC 6749, then page 5 states:
>>
>> In OAuth, the client requests access to resources controlled by the
>> resource owner and hosted by the resource server.
>>
>> In order to make sure that the right RO is in charge of the appropriate
>> RS, the GS needs to maintain a mapping between the RS and the RO.
>> The client does not know who the ROs are.
>>
>>
>>
>>> The consequence is the following : this scenario, *as well as the
>>> scenario described in draft-hardt-xauth-protocol-13*, allows the GS to
>>> act as Big Brother.
>>>
>> No.
>>
>> If the GS is in a position to know when a client is attempting to make a=
n
>> access to a given RS, then it can maintain logs of these events.
>>
>> RS will find a way to validate AuthZ produced by any GS.
>>
>> No. A RS trusts some GSs for some kinds of attributes. It does not trust
>> all the GSs that might exist in the world.
>>
>> Means RS must trust that very GS or trust somebody that trusts that very
>> GS (e.g. CA).
>>
>> Trust relationships are not necessarily transitive (nor bilateral).
>>
>> GS must not know the RS but must understand the Resource and trust the
>> Resource Owner, so that GS can validate the RO Grant.
>>
>> It would be interesting if you could elaborate on the last part of this
>> sentence :
>> "[GS] must understand the Resource and trust the Resource Owner, so that
>> GS can validate the RO Grant".
>>
>> Denis
>>
>>
>> /Francis
>>
>>>
>>> Denis
>>>
>>> Hello Fabian,
>>>
>>> On Thu, Jul 16, 2020 at 4:47 AM Fabien Imbault 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> That's interesting, however the important logic is actually implemente=
d
>>>> within (5). And so for the reader, it might be quite difficult to
>>>> understand what we're after (compared to oauth2 for instance). So in m=
y
>>>> view, this kind of schema has its place, but not at the start of the
>>>> document where we should primarily be concerned about explaining why
>>>> someone should read the document..
>>>>
>>>> It's also not easy to understand :
>>>> - why we sometimes use different labels between requests and responses
>>>> (for instance, 5 and 6)
>>>>
>>> Will need support in drafting the correct terms. The main purpose of
>>> this diagram is to help sharpen the definition of terms and verbs used =
in
>>> the draft.
>>>
>>> - sometimes we use "grant" and sometimes "authZ", and it doesn't seem
>>>> very clear what is the difference in use
>>>>
>>> IMO: the granting is the process of given permission.
>>> - RO can grant his Consent to the User or Client
>>> - GS can turn the RO Grant into an AuthZ.
>>> - Client can use AuthZ to access a Resource.
>>>
>>> A terminology section would be great to clarify.
>>>>
>>> Yes. There is a terminology section in there. We need to bring the
>>> wissing words into the list and sharpen those already there.
>>>
>>>>
>>>> If I understand correctly your remark in 5, you think the
>>>> request/response scheme (as in XYZ) may be misleading.
>>>>
>>> No. XYZ does IMO exactly  that. Just try to be more abstract for a
>>> better description of the models.
>>>
>>>
>>>> On the contrary, I think it allows support rich interaction scenarios
>>>> (and especially the ones you describe) with greater flexibility.
>>>>
>>> Flexibility shall not be put ahead of formal correctness.
>>>
>>>
>>>> For instance, some would disagree with the assertion that the goal is
>>>> for the GS to gather consent (see discussion on putting that on client
>>>> side). A fixed interaction schema has the downside of not permitting o=
ther
>>>> setups.
>>>>
>>> This discussion is the result of the lack of sharp terminology. Most of
>>> the time mixing up gathering consent (the act) and the way consent is
>>> gathered and transported from RO to GS (the interaction).
>>> /Francis
>>>
>>>
>>>> Fabien
>>>>
>>>> On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha >>> 40adorsys.de@dmarc.ietf.org> wrote:
>>>>
>>>>> Hello Dick,
>>>>>
>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2. Abstract Protocol Flow
>>>>>>>>> I am missing an abstract protocol flow like the one defined in
>>>>>>>>> https://tools.ietf.org/html/rfc6749#section-1.2.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That's an interesting point. GNAP also has identity claims, so the
>>>>>>>> abstract flow is somewhat different (there is no Authorization Gra=
nt from
>>>>>>>> the RO), and not all steps always happen. (there may not be steps =
(E) and
>>>>>>>> (F) with a Resource Server)
>>>>>>>>
>>>>>>>> Would you elaborate on what you think would be useful here, that i=
s
>>>>>>>> not in the specific flows?
>>>>>>>>
>>>>>>> A diagram that generalizes the steps, independently of interaction
>>>>>>> mode is essential for the reader's navigation of the rest of the
>>>>>>> document. This is what #section-1.2 of RFC6749 does. I hope we can =
produce
>>>>>>> a similar diagram.
>>>>>>>
>>>>>>> A subsection of
>>>>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1=
.1
>>>>>>> could be defined for this.
>>>>>>>
>>>>>>
>>>>>> Interaction modes are one dimension where the steps could be
>>>>>> generalized, but some steps are optional. For example, the User may =
not
>>>>>> interact with the GS, and the GS may interact with the RO. The Clien=
t may
>>>>>> only want claims, and there would be no step of the Client calling t=
he RS.
>>>>>>
>>>>>> A generalized diagram would need to include all optional steps so
>>>>>> that it did not mislead a reader into thinking the diagram included =
all
>>>>>> general steps, but it does not seem that is what you are asking for =
as you
>>>>>> wrote:
>>>>>>
>>>>>> A subsection of
>>>>>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.=
1
>>>>>> could be defined for this."
>>>>>>
>>>>>> Perhaps you can share how you think the diagram would look?
>>>>>>
>>>>> find below my proposal of an abstract sequence diagram.
>>>>>
>>>>> +----+  +------+  +---+  +---+  +---+
>>>>> |User|  |Client|  |RS |  |GS |  |RO |
>>>>> +----+  +------+  +---+  +-+-+  +-+-+
>>>>>   |(1) Service Request     |      |
>>>>>   |-------->|       |      |      |
>>>>>   |         |(2) Service Intent   |
>>>>>   |         |------>|      |      |
>>>>>   |         |(3) AuthZ Challenge  |
>>>>>   |         |<------|      |      |
>>>>>   |         |(4) AuthZ Request    |
>>>>>   |         |------------->|      |
>>>>>   |         |       |      |(5) Consent Request
>>>>>   |         |       |      |----->|
>>>>>   |         |       |      |(6) Grant Consent
>>>>>   |         |       |      |<-----|
>>>>>   |         |(7) Grant Access (Token)
>>>>>   |         |<-------------|      |
>>>>>   |         |(8) Service Request (Token)
>>>>>   |         +------>+      |      |
>>>>>   |         |(9) Service Response |
>>>>>   |         |<------|      |      |
>>>>>   |(10) Service Response   |      |
>>>>>   +<--------|       |      |      |
>>>>>   +         +       +      +      +
>>>>>
>>>>> (1) Service Request: This is the service request sent by a User to th=
e
>>>>> Client. This can be a simple file read request or even a complex paym=
ent
>>>>> initiation request.
>>>>>
>>>>> (2) Service Intent: In order to discover authorization requirements,
>>>>> the Client sends a service intent to the RS.
>>>>>
>>>>> (3) AuthZ Challenge: The response to a service intent request is
>>>>> generally an AuthZ Challenge. The content of this AuthZ Challenge, ca=
n be
>>>>> an identification challenge, an AuthZ exemption, or details on reques=
ted
>>>>> AuthZ. The content AuthZ Challenge can be similar to the oAuth2 RAR.
>>>>>
>>>>> (4) AuthZ Request : the Client sends an AuthZ Request to the GS
>>>>> including the AuthZ Challenge. This request can be similar to the oAu=
th PAR
>>>>> request.
>>>>>
>>>>> (5) Requests Consent : GS sends consent request to RO.
>>>>> Remark: The abstract protocol flow does not display a response of the
>>>>> request (4) to the Client. This is IMO a general misunderstanding. Th=
is
>>>>> protocol wants the GS to collect a consent from the RO.
>>>>> - In the case of a "redirect interaction", GS will use transport
>>>>> infrastructure provided by the Client to instruct the User to send th=
e RO
>>>>> to the GS (in most cases, user and RO are identical).
>>>>> - In the case of a "decoupled interaction", GS will directly contact
>>>>> RO and collect consent in a direct interaction with the RO (see CIBA)=
.
>>>>> - In the case of an "embedded interaction", GS will allow the Client
>>>>> to directly collect the Consent of the RO in a direct interaction wit=
h the
>>>>> User.
>>>>>
>>>>> (6) Grant Consent : RO return a Consent Grant to GS.
>>>>>
>>>>> (7) Grant Access : GS produces the corresponding access token and
>>>>> returns it to Client.
>>>>>
>>>>> (8) Service Request : Client uses the access token to send the servic=
e
>>>>> request to RS.
>>>>>
>>>>> (9) and (10) are self explaining....
>>>>>
>>>>> One of our upcoming exercises will be to challenge this abstract
>>>>> protocol flow with existing interactions (and if possible associated =
use
>>>>> cases) to see if we are missing something. After an agreement on the
>>>>> abstract protocol flow we can make sure each interaction provides a m=
apping
>>>>> to step 1 to 10.
>>>>>
>>>>> I will strip the rest of the post here. And bring further responses i=
n
>>>>> separate mails.
>>>>>
>>>>> Best regards.
>>>>> /Francis
>>>>>
>>>>>> =E1=90=A7
>>>>>>
>>>>> --
>>>>> 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/
>>
>>
>>

--=20
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--00000000000070c6bf05aa9490cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Dick, Denis,

here is an updated version of the diagram following Dick's advice =
to collapse responses and some clarifications as raised by Denis:

+----+ =C2=A0+------+ =C2=A0+---+ =C2=A0+---+ =C2=A0+---+
|User| =
=C2=A0|Client| =C2=A0|RS | =C2=A0|GS | =C2=A0|RO |
+----+ =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 |(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 |(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|(4) Cons=
entRequest: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 |(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 |(6) ServiceRequest(AuthZ):Service=
Response
=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+

Nomenclature of Arrows:=C2=A0
--->=C2=A0designate a request.
<---=C2=A0designates a response.
<--> request with immediate=C2=A0response.

Step, Action and Interaction:
This diagram describes actions and not interactions:=C2=A0<=
/div>
- Each step carries a number.
- An action with immediate=C2=A0response is=
 collapsed=C2=A0into a single step (2, 4, 6).
- An action with deferred response is represented by two ste=
ps (1&7, 3&5).
- An actio=
n might be carried out using many interactions and might for the purpose of=
 transport involve more parties (see redirect interaction bellow)

(1) ServiceRequest
This=
 is the service request sent by the User to the Client. This can be a simpl=
e file read request or a complex payment initiation request.

=
(2)=C2=A0ServiceIntent:AuthZChallenge
In order to discover authorization requirements, the Client sends a=C2=
=A0ServiceIntent request=C2=A0to the RS. The response to a=C2=A0ServiceInte=
nt request is an AuthZChallenge.=C2=A0
The content of an AuthZChallenge can be similar to the oAuth2 RAR.
The content of the AuthZChallen=
ge can be:
- An identificatio=
n challenge. Generally when the RS can not associate the ServiceRequest wit=
h an RO.
- An AuthZ exemption. Ge=
nerally when the RS needs no further AuthZ to fulfill the Client request.
- Details on the requested AuthZ, =
including=C2=A0instructions  on which GSs the Client can approach for AuthZ=
; instructions on which attributes are requested for each of these GSs.

(3)=C2=A0AuthZRequest(AuthZChallenge)
The Client sends an AuthZRequest to t=
he GS including the AuthZChallenge. This request can be similar to the oAut=
h2 PAR request.

=

(4)=C2=A0ConsentRequest:Grant
GS sends a consent request to RO. The way a GS c=
onnects with the RO to collect RO's consent (Grant) is dependent on the=
 interaction mode. This is also valid for the nature of the Grant returned =
by the RO to the GS.
-=C2=A0In th=
e case of a=C2=A0"redirect interaction", GS will use the transpor=
t infrastructure provided by the Client to instruct the User to send the RO=
 to the GS authorization endpoint (in most cases, user and RO are identical=
). In the case of oAuth2 AuthCode flow, the Grant provided by the RO is sto=
red by the GS (AS) at the AuthZ endpoint, then mapped to an authCode that i=
s transported by the User (User Agent) through the Client to the token endp=
oint of the GS.=C2=A0
- In the ca=
se of a "decoupled interaction", GS will directly contact RO and =
collect consent in a direct interaction with the RO (see CIBA). This diagra=
m=C2=A0assumes GS can evaluate the AuthZChallenge to find out how to locate=
 the RO. As there is a direct interaction between the GS and the RO, the fo=
rm/nature of the Grant is left to the discretion of the concrete interactio=
n mode.
- In the case of an "=
;embedded interaction", GS will allow the Client to directly collect t=
he Consent (Grant) of the RO in a direct interaction between the Client and=
 the User=C2=A0(also assuming in most cases, that user and RO are identical=
); and then send it to the GS in exchange of the AuthZ. We say the interact=
ion between GS and RO is embedded in the communication with the Client.

(5)=C2=A0GrantAccess(AuthZ)
From evaluating the Grant provided by the client, the GS produces a c=
orresponding access token and returns it to the Client.
Note that GS knowledge of the original or target RS =
is not necessary for the issuance of the access token, unless GS is require=
d to bind the token to a target RS.=C2=A0

(6)=C2=A0ServiceReq=
uest(AuthZ):ServiceResponse
Clien=
t uses the GS provided=C2=A0AuthZ=C2=A0to send the service request to RS. R=
ecall that AuthZ (token)=C2=A0can be, but must not be bound to an RS.

(7) is self explaining.
=

One of our upcoming=C2=A0exe=
rcises will be to challenge this abstract protocol flow with existing inter=
actions=C2=A0(and if possible associated use cases) to see if we are missin=
g something. After an agreement on the abstract protocol flow we can make s=
ure each interaction provides a mapping to step 1 to 7.
<=
div>
/Francis

On Thu, Jul 16, 2020 at 2:15 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi F=
rancis

Thanks for drafting the sequence diagram and desc=
riptions! I really like where. you are going with it.

<=
div>As our objective is to provide an abstraction,=C2=A0 what do you think =
of collapsing steps 2&3, 5&6, and 8&9 in the diagram?

Per the discussion to your post, there is also some tuning =
of the descriptions of each step. I would also add in which steps are optio=
nal.

Referencing other parts of the document would=
 be useful, as this abstraction is intended to be a high level guide to the=
 protocol, so adding other top level sections to the document, even if they=
 are thin, would help the reader in grasping the possible flows.
=

/Dick

On Thu, Jul 16, 2020 at 9:57 AM Denis <denis.ietf@free.fr>=
 wrote:

 =20
   =20
 =20
  

    
Hello Francis,

    


    

    

     =20
      

        
Hello Denis,

        

        

          
On Thu, Jul 16, 2020 at 8:4=
5
            AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              
Hello=C2=A0 Francis,

                

              

              
The first two steps of your scenario are nice, in
                particular the second one:

              

                
(2) Service Intent: In order to discover authorizat=
ion
                    requirements, the Client sends a service intent
                  to the RS.

              

              
This means that the client first contacts the RS,
                instead of the GS.=C2=A0

            

          

          

            

              


              

              
However, the third step is missing to disclose to the
                client these "authorization requirements",=
 in
                particular which AS(s), 

                it may contact, which attributes are requested and
                how/when/where the user consent is gathered.

                

              

            

          

          
The response (2) AuthZ Challenge carries the reference to
            the GS. Mean the resource server instructs the Client on
            which GS to approach for authorization. 

          

        

      

    

    
This information was not mentioned in your description.

    

      

        

          

            

              
 

                Unless the scenario is mandating all the RSs to trust
                one and only one GS and the client to have a
                relationship with that GS, 

                the remaining steps of this scenario do not work.

                

              

            

          

          
Can you elaborate why it shall not work for=C2=A0many GSs?
        

      

    

    
Your answer above mentions : "which GS to approach for
      authorization". It uses the singular whereas it should use the
      plural.

    
In addition, indicating only which GSs (plural) is
      insufficient, since the RS also needs to indicate to the Client
      which attributes 

      are requested for each of these GSs.

    
Your description is also silent to explain how/when/where the
      user consent is gathered.

    

      

        

          

            

              
=C2=A0

            

          

          

            

              
Step (5) mandates the GS to know who the owner of a
                given RS is

            

          

          
Step (5) mandates the GS to know the RO, as owner of the
            target Resource, but not the RS (Resource Server). Resource
            not-equals=C2=A0RS.

          


          

          

            

              
, and thus mandates the client to disclose to the GS
                the identity of the RS. 

              

            

          

        

      

    

    

    

      

        

          
No. Here there is no requirement from GS to know the RS.
        

      

    

    
In your are using the terminology of RFC 6749, then page 5
      states:

    

      
In OAuth, the client requests access to resources controlled by
        the resource owner and hosted by the resource server.

      

    

    
In order to make sure that the right RO is in charge of the
      appropriate RS, the GS needs to maintain a mapping between the RS
      and the RO.

      The client does not know who the ROs are.

    

      

        

          
=C2=A0

          

            

              
The consequence is the following : this scenario, as
                  well as the scenario described in
                  draft-hardt-xauth-protocol-13, allows the GS to
                act as Big Brother. 

              

            

          

          
No. 

          

        

      

    

    
If the GS is in a position to know when a client is attempting to
      make an access to a given RS, then it can maintain logs of these
      events.

    

    

      

        

          
RS will find a way to validate AuthZ produced by any GS.
          

        

      

    

    
No. A RS trusts some GSs for some kinds of attributes. It does
      not trust all the GSs that might exist in the world.

    

      

        

          
Means RS must trust that very GS or trust somebody=C2=A0that
            trusts that very GS (e.g. CA).

        

      

    

    
Trust relationships are not necessarily transitive (nor
      bilateral).

    

      

        

          
GS must not know the RS but must understand the Resource
            and trust the Resource Owner, so that GS can validate the RO
            Grant.

        

      

    

    
It would be interesting if you could elaborate on the last part
      of this sentence :

      "[GS] must understand the Resource and trust the Resource Owner,
      so that GS can validate the RO Grant".

    
Denis

    

    

      

        

          


          

          
/Francis

          

            

              
 

              


              

              
Denis

              

              

              

                

                  
Hello Fabian,

                  

                  

                    
On Thu, Jul 16,
                      2020 at 4:47 AM Fabien Imbault <fabien.imbault@gmail.com>=
;
                      wrote:

                    

                    

                      
Hi,=C2=A0
                        


                        

                        
That's interesting, however the important
                          logic is actually implemented within (5). And
                          so for the reader, it might be quite difficult
                          to understand what we're after (compared to
                          oauth2 for instance). So in my view, this kind
                          of schema has its place, but not at the start
                          of the document where we should primarily be
                          concerned about explaining why someone should
                          read the document..

                        


                        

                        
It's also not easy to understand :=C2=A0
                        
- why we sometimes use different labels
                          between requests and responses (for instance,
                          5 and 6)

                      

                    

                    
Will need support in drafting the correct
                      terms. The main purpose of this diagram=C2=A0is to he=
lp
                      sharpen the definition of terms and verbs used in
                      the draft.

                    


                    

                    

                      

                        
- sometimes we use "grant" and somet=
imes
                          "authZ", and it doesn't seem very c=
lear what
                          is the difference in use

                      

                    

                    
IMO: the granting is the process of given
                      permission.

                    
- RO can grant his Consent to the User or
                      Client

                    
- GS can turn the RO Grant into an AuthZ.

                    
- Client can use AuthZ to access a Resource.

                    


                    

                    

                      

                        
A terminology section would be great to
                          clarify.

                      

                    

                    
Yes. There is a terminology section in there.
                      We need to bring the wissing words into the list
                      and sharpen those already there.=C2=A0

                    

                      

                        


                        

                        
If I understand correctly your remark in 5,
                          you think the request/response scheme (as in
                          XYZ) may be misleading.=C2=A0

                      

                    

                    
No. XYZ does IMO exactly=C2=A0 that. Just try to b=
e
                      more abstract for a better description of the
                      models.

                    
=C2=A0

                    

                      

                        
On the contrary, I think it allows support
                          rich interaction scenarios (and especially the
                          ones you describe) with greater flexibility. 
                      

                    

                    
Flexibility shall not be put ahead of formal
                      correctness.

                    
=C2=A0

                    

                      

                        
For instance, some would disagree with the
                          assertion that the goal is for the GS to
                          gather consent (see discussion on putting that
                          on client side). A fixed interaction schema
                          has the downside of not permitting other
                          setups.

                      

                    

                    
This discussion is the result of the lack of
                      sharp terminology. Most of the time mixing up
                      gathering consent (the act) and the way consent is
                      gathered and transported from RO to GS (the
                      interaction).

                    
/Francis

                    


                    

                    

                      

                        


                        

                        
Fabien

                      

                      

                      

                        
On Thu, Jul
                          16, 2020 at 5:28 AM Francis Pouatcha <fpo=3D40adorsys.de=
@dmarc.ietf.org>
                          wrote:

                        

                        

                          

                            
Hello
                                Dick,
                              


                                

                            

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                
=C2=A0

                                                

                                                  

                                                    

                                                      

                                                        


                                                          

                                                        
2.
                                                          Abstract
                                                          Protocol Flow

                                                        

                                                          
I
                                                          am missing an
                                                          abstract
                                                          protocol flow
                                                          like the one
                                                          defined in htt=
ps://tools.ietf.org/html/rfc6749#section-1.2.

                                                        

                                                      

                                                    

                                                  

                                                

                                                


                                                  

                                                
That's
                                                    an interesting
                                                    point. GNAP also has
                                                    identity claims, so
                                                    the abstract flow is
                                                    somewhat different
                                                    (there is no
                                                    Authorization Grant
                                                    from the RO), and
                                                    not all steps always
                                                    happen. (there may
                                                    not be steps (E) and
                                                    (F) with a Resource
                                                    Server)

                                                


                                                  

                                                
Would
                                                    you elaborate on
                                                    what you think would
                                                    be useful here, that
                                                    is not in the
                                                    specific flows?<=
/div>
                                              

                                            

                                          

                                          
A
                                              diagram that generalizes
                                              the steps, independently
                                              of interaction mode is
                                              essential for the reader'=
s
                                              navigation of the rest of
                                              the document.=C2=A0This is
                                              what=C2=A0#section-1.2 of
                                              RFC6749 does. I hope we
                                              can produce a similar
                                              diagram.

                                          

                                            

                                          
A
                                              subsection of=C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#se=
ction-1.1
                                              could be defined for this.

                                        

                                      

                                    

                                    


                                      

                                    
Interacti=
on
                                        modes are one dimension where
                                        the steps could be generalized,
                                        but some steps are optional. For
                                        example, the User may not
                                        interact with the GS, and the GS
                                        may interact with the RO. The
                                        Client may only want claims, and
                                        there would be no step of the
                                        Client calling the RS.

                                    


                                      

                                    
A
                                        generalized diagram would need
                                        to include all optional steps so
                                        that it did not mislead a reader
                                        into thinking the diagram
                                        included all general steps, but
                                        it does not seem that is what
                                        you are asking for as you wrote:

                                    


                                      

                                    
A
                                        subsection of=C2=A0https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-=
1.1
                                        could be defined for this."
                                      

                                    


                                      

                                    
Perhaps
                                        you can share how you think the
                                        diagram would look?

                                  

                                

                              

                              
find below my
                                  proposal of an abstract sequence
                                  diagram.

                              


                                

                              
+----+
                                  =C2=A0+------+ =C2=A0+---+ =C2=A0+---+ =
=C2=A0+---+

                                  |User| =C2=A0|Client| =C2=A0|RS | =C2=A0|=
GS | =C2=A0|RO |

                                  +----+ =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 |(2)=
 Service Intent =C2=A0 |

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =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)=
 AuthZ Challenge =C2=A0|

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =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)=
 AuthZ 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|(5)
                                  Consent 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|(6) Grant
                                  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 |(7)=
 Grant Access (Token)

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<=
;-------------| =C2=A0 =C2=A0 =C2=A0|

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(8)=
 Service Request
                                  (Token)

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---=
--->+ =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(9)=
 Service Response |

                                  =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<=
;------| =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|

                                  =C2=A0 |(10) Service Response =C2=A0 | =
=C2=A0 =C2=A0 =C2=A0|

                                  =C2=A0 +<--------| =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|

                                  =C2=A0 + =C2=A0 =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) Service
                                  Request: This is the service request
                                  sent by a User to the Client. This can
                                  be a simple file read request or even
                                  a complex payment initiation request.

                              


                                

                              
(2) Service
                                  Intent: In order to discover
                                  authorization requirements, the Client
                                  sends a service intent to the RS.<=
/div>
                              


                                

                              
(3) AuthZ
                                  Challenge: The response to a service
                                  intent request is generally an AuthZ
                                  Challenge. The content of this AuthZ
                                  Challenge, can be an identification
                                  challenge, an AuthZ exemption, or
                                  details on requested AuthZ. The
                                  content AuthZ Challenge can be similar
                                  to the oAuth2 RAR.

                              


                                

                              
(4) AuthZ
                                  Request : the Client sends an AuthZ
                                  Request to the GS including the AuthZ
                                  Challenge. This request can be similar
                                  to the oAuth PAR request.

                              


                                

                              
(5) Requests
                                  Consent : GS sends consent request to
                                  RO.=C2=A0

                              
Remark: The
                                  abstract protocol flow does not
                                  display a response of the request (4)
                                  to the Client. This is IMO a general
                                  misunderstanding. This protocol wants
                                  the GS to collect a consent from the
                                  RO.=C2=A0

                              
- In the case
                                  of a "redirect interaction", GS=
 will
                                  use transport infrastructure provided
                                  by the Client to instruct the User to
                                  send the RO to the GS (in most cases,
                                  user and RO are identical).

                              
- In the case
                                  of a "decoupled interaction", G=
S will
                                  directly contact RO and collect
                                  consent in a direct interaction with
                                  the RO (see CIBA).

                              
- In the case
                                  of an "embedded interaction", G=
S will
                                  allow the Client to directly collect
                                  the Consent of the RO in a direct
                                  interaction with the User.

                              


                                

                              
(6) Grant
                                  Consent : RO return a Consent Grant to
                                  GS.

                              


                                

                              
(7) Grant
                                  Access : GS produces the corresponding
                                  access token and returns it to Client.

                              


                                

                              
(8) Service
                                  Request : Client uses the access token
                                  to send the service request to RS.=


                              


                                

                              
(9) and (10)
                                  are self explaining....

                              


                                

                              
One of our
                                  upcoming=C2=A0exercises will be to
                                  challenge this abstract protocol flow
                                  with existing interactions=C2=A0(and if
                                  possible associated use cases) to see
                                  if we are missing something. After an
                                  agreement on the abstract protocol
                                  flow we can make sure each interaction
                                  provides a mapping to step 1 to 10.

                              


                                

                              
I
                                  will strip the rest of the post here.
                                  And bring further responses in
                                  separate mails.

                              

                                

                              
Be=
st
                                  regards.

                              
/F=
rancis=C2=A0=C2=A0

                              

                                

                                  

                                    

                                    

                                  

                                

                                
3D""=E1=
=90=A7

                              

                            

                            -- 

                            
                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              
Francis
                                                  Pouatcha

                                              
Co-Founder
                                                  and Technical Lead=


                                              
adorsys
                                                  GmbH & Co. KG<=
/div>
                                              
                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                          -- 

                          Txauth mailing list

                          Txauth@ietf.org

                          https://www.ietf.org/mailman/l=
istinfo/txauth

                        

                      

                    

                  

                  

                  


                  

                  -- 

                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    
Francis Pouatcha

                                    
Co-Founder and Technical Lead
                                    
adorsys GmbH & Co. KG

                                    
                                  

                                

                              

                            

                          

                        

                      

                    

                  

                

                

                

              

              


              

            

          

        

        

        


        

        -- 

        
      

    

    


    

  







-- 


--00000000000070c6bf05aa9490cc--


From nobody Thu Jul 16 13:08: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 9A99C3A0C0D for ; Thu, 16 Jul 2020 13:08:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 v-Ykq9phq4-h for ; Thu, 16 Jul 2020 13:08: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 8856D3A0C0E for ; Thu, 16 Jul 2020 13:08:09 -0700 (PDT)
Received: from [192.168.1.7] (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 06GK85BG008163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jul 2020 16:08:06 -0400
From: Justin Richer 
Message-Id: <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C0E167B3-6ABE-4799-B8EA-627E991D582E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 16 Jul 2020 16:08:05 -0400
In-Reply-To: 
Cc: Fabien Imbault , Mike Varley , "txauth@ietf.org" , Mike Jones 
To: Dick Hardt 
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 16 Jul 2020 20:08:13 -0000

--Apple-Mail=_C0E167B3-6ABE-4799-B8EA-627E991D582E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think that the cross-organizational trust model is an interesting one, =
and in fact it=E2=80=99s one of the things that=E2=80=99s pushed me away =
from a client_id. In the scenario that you describe, =E2=80=9Cclient_id=E2=
=80=9D is used to represent something that it was never meant to =
represent: the organization running the software, not the software =
itself. It isn=E2=80=99t a client_id, and while in OAuth 2 the client_id =
could be co-opted to carry that information, it=E2=80=99s considered bad =
practice to share client_ids between multiple pieces of software.=20

I would argue that to address this use case properly, there should be =
another level of identifier to bridge that trust that the software can =
present, showing that it is a part of Organization A, and not =
Organization C. This isn=E2=80=99t a client identifier, it=E2=80=99s an =
organization identifier, and it should be separate. You might want to =
identify both the client instance as well as the organization it=E2=80=99s=
 a part of, for example. This is part of the motivation behind putting =
=E2=80=9Corganizational data=E2=80=9D within scope for the client to =
send to the AS, after all.

Therefore, I strongly disagree that this scenario =E2=80=9Crequires=E2=80=9D=
 a client_id to be solved. In fact, I think that solving this scenario =
with a client_id is an anti-pattern that stems from OAuth 2=E2=80=99s =
over-reliance on client_id as a persistent identifier within the =
protocol, and we can and should do better with GNAP. It=E2=80=99s very =
similar to Mike Jones=E2=80=99s referenced federation document, where =
the client_id is co-opted as a means of bootstrapping client =
registration and discovery, or in the Solid Authentication specification =
which stuffs a WebID into the client_id field.

With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools that we =
had to solve our problems, and come up with some very clever solutions. =
What I=E2=80=99m trying to argue to this community is that we are in a =
position to create our own, better tools.=20

 =E2=80=94 Justin

> On Jul 16, 2020, at 2:00 PM, Dick Hardt  wrote:
>=20
> Justin,=20
>=20
> While I agree that the assumption in OAuth 2 that all Clients have a =
client_id is problematic, the requirement for a client_id in many use =
cases is still there, and it does not represent a piece of software, but =
a relationship between parties.
>=20
> Organization A writes client software that calls resources managed by =
the AS in Organization B. The client_id represents Organization A to =
Organization B. Organization B does not care what software Organization =
A is running, and there may be numerous pieces of software at =
Organization A that use the same client_id. The access granted by =
Organization B to Organization A needs to be able to be different than =
the rights granted to Organization C.=20
>=20
> I agree that we don't want to force all clients to have a client_id, =
and as discussed, there are a variety of inputs for an AS to accept =
calls from a piece of software, and often, that will be a particular =
instance of the software, but we also don't want to force clients to all =
be treated the same, because they are not.=20
>=20
>=20
>=20
>=20
>=20
>=20
> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer > wrote:
> Exactly =E2=80=94 when we start to look at it as managing the =
lifecycle of a piece of software, instead of a registration at the AS, =
we can start thinking in different terms what =E2=80=9Ctrusting=E2=80=9D =
the client means in the context of what the client is doing. That trust =
could come from some kind of signed attestation about the software (like =
the OAuth 2 DynReg software statement), or it could come from some =
externally fetchable item (like a Solid WebID, a DID, or the OIDC =
Federation extension), or it could come from someone sitting at a =
console and typing in information and getting back an identifier. And =
none of these need to pretend to be a global =E2=80=9Cclient id=E2=80=9D =
for it to work. The world of clients is much more diverse than OAuth 2 =
likes to admit, and we see that with trying to nail down a =
=E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =
=E2=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =
=E2=80=9Cautomatic=E2=80=9D vs. =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 =
any number of other things.=20
>=20
> OAuth 2 only needs client IDs because the front channel needs a way to =
pass client identifiers when the client can=E2=80=99t authenticate =
itself directly. We tried to get rid of this restriction with PAR and =
JAR together, but there turned out to be corner cases in OAuth 2=E2=80=99s=
 world that still needed client_id, and implementations assumed it would =
be there anyway.=20
>=20
> In GNAP, we can avoid that problem from the beginning by looking at =
the model differently and understanding where we=E2=80=99re coming from, =
and why.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault > wrote:
>>=20
>> +1 on that.
>>=20
>> We can then see it more as life cycle management of the client than =
registration per say, and this comes with many benefits compared to the =
current client_id.
>>=20
>> Fabien
>>=20
>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer > wrote:
>> I not only agree with Mike Jones that =E2=80=9Cautomatic =
registration=E2=80=9D should be part of the process, but I would argue =
that that kind of model should be a default mode of operation. If you =
have an identifier that you can send to short-circuit that, great! But =
we should focus on having the capability of inlining a lot of this =
information wherever possible. This is already the direction that the =
input proposals are heading.
>>=20
>> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope =
for the protocol in general, and since both XYZ and Xauth have =
mechanisms that allow the client to present a key and get back an =
identifier that it can use in the future we have something equivalent.=20=

>>=20
>> But I think there=E2=80=99s a little more to it than that: =
Ultimately, I think we should question thinking in terms of =
=E2=80=9Cregistration=E2=80=9D, a model which has hampered the OAuth 2 =
model in a lot of use cases. For example, the federation draft Mike =
Jones references below hacks the =E2=80=9Cclient_id=E2=80=9D parameter =
and makes it point to a document that the AS has to fetch. This =
construct is done for two reasons: (1) Oauth requires a =E2=80=9Cclient_id=
=E2=80=9D in the request and (2) it=E2=80=99s difficult to pass =
information by value to the AS due to front-channel restrictions. Since =
we=E2=80=99re defining a new protocol, we don=E2=80=99t need to hack =
that functionality into a =E2=80=9Cclient ID=E2=80=9D or equivalent and =
instead we can pass that information directly in the protocol. If we =
don=E2=80=99t assume that the client *has* to have a client ID =
equivalent, but it *can* have one in a set of defined circumstances, =
then I think we are in a much better spot. This is the reasoning for =
XYZ=E2=80=99s model of having clients identified by the key, and that =
key can potentially be passed by a reference identifier.
>>=20
>> I think all of the use cases that Mike Varley presents below are all =
valid directions, with the caveat that we shouldn=E2=80=99t assume a =
client should be presenting an ID at all steps. Mechanisms like software =
statements should be presentable apart from a client ID, as should =
on-device keys. We=E2=80=99re probably going to want extensions for =
device posture and other forms of attestation as well.
>>=20
>> This is one of the domains that I think we can clearly surpass OAuth =
2=E2=80=99s flexibility and capabilities if we are willing to look past =
OAuth 2=E2=80=99s assumptions of what=E2=80=99s needed inline in the =
protocol.=20
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 14, 2020, at 1:54 PM, Mike Varley > wrote:
>>>=20
>>> Is client registration in scope for the protocol?
>>> =20
>>> A generic way of handling clients (via ID or Handle or Key or =
whatever) is to have processing rule on the AS such as =E2=80=9Cif the =
AS recognizes the client ID (and authentication of that client ID) then =
it may process the request on behalf of that client. If the AS does not =
recognize the client ID, it must treat this as a new client registration =
and evaluate any authorization evidence the client provides before =
enabling the client and mapping policies to that client=E2=80=9D (this =
means dynamic or automatic clients need to provide additional assertions =
/ software statements whatever to register their ID.
>>> =20
>>> Something like this allows for very flexible systems:
>>> System A can be unknown to the AS but can dynamically registered =
each time with an appropriate software statement
>>> System B can have a fairly stable client ID at the AS, but rotate =
that ID every month through automatic registration (with an assertion it =
got from the AS during a pre-registration for example)
>>> System C can pre-register with the AS for a client ID because it =
doesn=E2=80=99t deal with software statements etc=E2=80=A6
>>> =E2=80=A6
>>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing =
client IDs because it will always just rely on the software statements.
>>> =20
>>> I think a client registration protocol that allows these scenarios =
would be very useful in GNAP, but hopefully avoiding having to define =
what =E2=80=98evidence=E2=80=99 the AS needs to accept for each =
scenario.
>>> =20
>>> Thanks,
>>> =20
>>> MV
>>> =20
>>> From: Txauth > on behalf of Mike Jones =
>
>>> Date: Tuesday, July 14, 2020 at 12:18 PM
>>> To: Dick Hardt >, =
"txauth@ietf.org " >, Justin Richer >
>>> Subject: Re: [Txauth] Key handle vs client id & handle
>>> =20
>>> I agree that there are significant differences between statically =
and dynamically registered clients and that=E2=80=99s appropriate to be =
able to syntactically differentiate between them at runtime.  For one =
thing, the resource requirements at the authorization server can be very =
different.
>>> =20
>>> We should also be thinking about how to include what the OpenID =
Connect Federation spec =
https://openid.net/specs/openid-connect-federation-1_0.html =
 calls =
=E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client encode a =
registration request reference in the client ID, so no static or dynamic =
registration even occurs.  See =
https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section=
.9.1 =
.
>>> =20
>>>                                                        -- Mike
>>> =20
>>> From: Dick Hardt >=20
>>> Sent: Friday, July 10, 2020 1:17 PM
>>> To: txauth@ietf.org ; Justin Richer =
>; Mike Jones =
>
>>> Subject: Key handle vs client id & handle
>>> =20
>>> + Mike as he had interest in this topic
>>> =20
>>> My understanding is that an existing OAuth 2 client would use their =
current client id as their key handle, and a dynamic client (one that =
was not pre-registered) would be given a key handle by the AS.
>>> =20
>>> There are potentially some significant differences between a =
registered client, and a dynamic client to an AS.
>>> =20
>>> The AS is likely to know the identity of a registered client, and =
have different policies between the two types of clients. For example, a =
registered client may have access to a 'write" scope, while a dynamic =
client does not.
>>> =20
>>> The AS may have 100s or 1000s of registered clients, but a dynamic =
client may have 10Ms or 100Ms of instances, which may dictate separate =
storage services. Additionally, internal to the AS, which systems can =
write to the registered client store is going to be different than the =
dynamic client store.
>>> =20
>>> In XYZ, subsequent calls to the AS, both registered clients and =
dynamic clients pass a key handle, so there is no easy way to =
differentiate between the two.
>>> =20
>>> While the AS could embed semantics in the key handle identifier to =
indicate which identifiers are pre-registered vs dynamic, there are many =
cases where the AS does need to know the difference, so making the =
difference a feature of GNAP seems like a better path.
>>> =20
>>> =20
>>> 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.
>>>=20
>>=20
>> --=20
>> Txauth mailing list
>> Txauth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/txauth =

>=20


--Apple-Mail=_C0E167B3-6ABE-4799-B8EA-627E991D582E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
think that the cross-organizational trust model is an interesting one, =
and in fact it=E2=80=99s one of the things that=E2=80=99s pushed me away =
from a client_id. In the scenario that you describe, =E2=80=9Cclient_id=E2=
=80=9D is used to represent something that it was never meant to =
represent: the organization running the software, not the software =
itself. It isn=E2=80=99t a client_id, and while in OAuth 2 the client_id =
could be co-opted to carry that information, it=E2=80=99s considered bad =
practice to share client_ids between multiple pieces of =
software. 

I =
would argue that to address this use case properly, there should be =
another level of identifier to bridge that trust that the software can =
present, showing that it is a part of Organization A, and not =
Organization C. This isn=E2=80=99t a client identifier, it=E2=80=99s an =
organization identifier, and it should be separate. You might want to =
identify both the client instance as well as the organization it=E2=80=99s=
 a part of, for example. This is part of the motivation behind putting =
=E2=80=9Corganizational data=E2=80=9D within scope for the client to =
send to the AS, after all.

Therefore, I strongly disagree that this scenario =
=E2=80=9Crequires=E2=80=9D a client_id to be solved. In fact, I think =
that solving this scenario with a client_id is an anti-pattern that =
stems from OAuth 2=E2=80=99s over-reliance on client_id as a persistent =
identifier within the protocol, and we can and should do better with =
GNAP. It=E2=80=99s very similar to Mike Jones=E2=80=99s referenced =
federation document, where the client_id is co-opted as a means of =
bootstrapping client registration and discovery, or in the Solid =
Authentication specification which stuffs a WebID into the client_id =
field.

With =
OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools that we had to =
solve our problems, and come up with some very clever solutions. What =
I=E2=80=99m trying to argue to this community is that we are in a =
position to create our own, better tools. 

 =E2=80=94 Justin

On Jul 16, 2020, at 2:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, 

While I agree that the assumption in =
OAuth 2 that all Clients have a client_id is problematic, the =
requirement for a client_id in many use cases is still there, and it =
does not represent a piece of software, but a relationship between =
parties.

Organization A writes client software that calls resources =
managed by the AS in Organization B. The client_id represents =
Organization A to Organization B. Organization B does not care what =
software Organization A is running, and there may be =
numerous pieces of software at Organization A that use the same =
client_id. The access granted by Organization B to Organization A needs =
to be able to be different than the rights granted to Organization =
C. 

I=
 agree that we don't want to force all clients to have a client_id, and =
as discussed, there are a variety of inputs for an AS to accept calls =
from a piece of software, and often, that will be a particular instance of the software, but we also don't want to force =
clients to all be treated the same, because they are =
not. 






On Thu, Jul 16, 2020 at 8:24 AM Justin Richer =
<jricher@mit.edu> =
wrote:
Exactly =E2=80=94 when we start to look at it as =
managing the lifecycle of a piece of software, instead of a registration =
at the AS, we can start thinking in different terms what =E2=80=9Ctrusting=
=E2=80=9D the client means in the context of what the client is doing. =
That trust could come from some kind of signed attestation about the =
software (like the OAuth 2 DynReg software statement), or it could come =
from some externally fetchable item (like a Solid WebID, a DID, or the =
OIDC Federation extension), or it could come from someone sitting at a =
console and typing in information and getting back an identifier. And =
none of these need to pretend to be a global =E2=80=9Cclient id=E2=80=9D =
for it to work. The world of clients is much more diverse than OAuth 2 =
likes to admit, and we see that with trying to nail down a =
=E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =
=E2=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =
=E2=80=9Cautomatic=E2=80=9D vs. =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 =
any number of other things. 

OAuth 2 only needs client IDs because =
the front channel needs a way to pass client identifiers when the client =
can=E2=80=99t authenticate itself directly. We tried to get rid of this =
restriction with PAR and JAR together, but there turned out to be corner =
cases in OAuth 2=E2=80=99s world that still needed client_id, and =
implementations assumed it would be there anyway. 

In GNAP, we can avoid =
that problem from the beginning by looking at the model differently and =
understanding where we=E2=80=99re coming from, and why.

 =E2=80=94 =
Justin

On Jul 16, 2020, at 3:49 AM, =
Fabien Imbault <fabien.imbault@gmail.com> =
wrote:

+1 =
on that.

We can then =
see it more as life cycle management of the client than registration per =
say, and this comes with many benefits compared to the current =
client_id.

Fabien

On Tue, Jul =
14, 2020 at 9:32 PM Justin Richer <jricher@mit.edu> wrote:
I not only agree with =
Mike Jones that =E2=80=9Cautomatic registration=E2=80=9D should be part =
of the process, but I would argue that that kind of model should be a =
default mode of operation. If you have an identifier that you can send =
to short-circuit that, great! But we should focus on having the =
capability of inlining a lot of this information wherever possible. This =
is already the direction that the input proposals are heading.

So I kind-of agree that =
=E2=80=9Cregistration=E2=80=9D is in scope for the protocol in general, =
and since both XYZ and Xauth have mechanisms that allow the client to =
present a key and get back an identifier that it can use in the future =
we have something equivalent. 

But I think there=E2=80=99s a little =
more to it than that: Ultimately, I think we should question thinking in =
terms of =E2=80=9Cregistration=E2=80=9D, a model which has hampered the =
OAuth 2 model in a lot of use cases. For example, the federation draft =
Mike Jones references below hacks the =E2=80=9Cclient_id=E2=80=9D =
parameter and makes it point to a document that the AS has to fetch. =
This construct is done for two reasons: (1) Oauth requires a =
=E2=80=9Cclient_id=E2=80=9D in the request and (2) it=E2=80=99s =
difficult to pass information by value to the AS due to front-channel =
restrictions. Since we=E2=80=99re defining a new protocol, we don=E2=80=99=
t need to hack that functionality into a =E2=80=9Cclient ID=E2=80=9D or =
equivalent and instead we can pass that information directly in the =
protocol. If we don=E2=80=99t assume that the client *has* to have a =
client ID equivalent, but it *can* have one in a set of defined =
circumstances, then I think we are in a much better spot. This is the =
reasoning for XYZ=E2=80=99s model of having clients identified by the =
key, and that key can potentially be passed by a reference =
identifier.

I =
think all of the use cases that Mike Varley presents below are all valid =
directions, with the caveat that we shouldn=E2=80=99t assume a client =
should be presenting an ID at all steps. Mechanisms like software =
statements should be presentable apart from a client ID, as should =
on-device keys. We=E2=80=99re probably going to want extensions for =
device posture and other forms of attestation as well.

This is one of the =
domains that I think we can clearly surpass OAuth 2=E2=80=99s =
flexibility and capabilities if we are willing to look past OAuth 2=E2=80=99=
s assumptions of what=E2=80=99s needed inline in the =
protocol. 

 =E2=80=94 Justin
On Jul =
14, 2020, at 1:54 PM, Mike Varley <mike.varley@securekey.com> wrote:

Is =
client registration in scope for the protocol?
 
A =
generic way of handling clients (via ID or Handle or Key or whatever) is =
to have processing rule on the AS such as =E2=80=9Cif the AS recognizes =
the client ID (and authentication of that client ID) then it may process =
the request on behalf of that client. If the AS does not recognize the =
client ID, it must treat this as a new client registration and evaluate =
any authorization evidence the client provides before enabling the =
client and mapping policies to that client=E2=80=9D (this means dynamic =
or automatic clients need to provide additional assertions / software =
statements whatever to register their ID.
 
Something like this allows for very flexible systems:
System =
A can be unknown to the AS but can dynamically registered each time with =
an appropriate software statement
System =
B can have a fairly stable client ID at the AS, but rotate that ID every =
month through automatic registration (with an assertion it got from the =
AS during a pre-registration for example)
System =
C can pre-register with the AS for a client ID because it doesn=E2=80=99t =
deal with software statements etc=E2=80=A6
=E2=80=A6=

And =
even =E2=80=98StatelessAS=E2=80=99 can operate by never storing client =
IDs because it will always just rely on the software statements.
 
I =
think a client registration protocol that allows these scenarios would =
be very useful in GNAP, but hopefully avoiding having to define what =
=E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
 
Thanks,
 
MV
 
From: Txauth <txauth-bounces@ietf.org> on behalf of Mike Jones =
<Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
Date: Tuesday, =
July 14, 2020 at 12:18 PM
To: Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
Subject: Re: [Txauth] Key =
handle vs client id & handle
 
I agree that there are =
significant differences between statically and dynamically registered =
clients and that=E2=80=99s appropriate to be able to syntactically =
differentiate between them at runtime.  For one thing, the resource =
requirements at the authorization server can be very different.
 
We should also =
be thinking about how to include what the OpenID Connect Federation =
spec https://openid.net/specs/openid-connect-federation-1_0.html=
 calls =E2=80=9CAutomatic =
Registration=E2=80=9D.  This lets the client encode a registration =
request reference in the client ID, so no static or dynamic registration =
even occurs.  See https://openid.net/specs/openid-connect-federation-1_0-12.html#=
rfc.section.9.1.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 
From: Dick Hardt <dick.hardt@gmail.com> 
Sent: Friday, =
July 10, 2020 1:17 PM
To: txauth@ietf.org; Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Subject: Key handle vs =
client id & handle
 
+ Mike as =
he had interest in this topic
 
My =
understanding is that an existing OAuth 2 client would use their current =
client id as their key handle, and a dynamic client (one that was not =
pre-registered) would be given a key handle by the AS.
 
There are =
potentially some significant differences between a registered client, =
and a dynamic client to an AS.
 
The AS is =
likely to know the identity of a registered client, and have different =
policies between the two types of clients. For example, a registered =
client may have access to a 'write" scope, while a dynamic client does =
not.
 
The AS =
may have 100s or 1000s of registered clients, but a dynamic client may =
have 10Ms or 100Ms of instances, which may dictate separate storage =
services. Additionally, internal to the AS, which systems can write to =
the registered client store is going to be different than the =
dynamic client store.
 
In XYZ, =
subsequent calls to the AS, both registered clients and dynamic clients =
pass a key handle, so there is no easy way to differentiate between the =
two.
 
While the =
AS could embed semantics in the key handle identifier to indicate which =
identifiers are pre-registered vs dynamic, there are many cases where =
the AS does need to know the difference, so making the difference a =
feature of GNAP seems like a better path.
 
 
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.

-- 

Txauth mailing list

Txauth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth
=







=

--Apple-Mail=_C0E167B3-6ABE-4799-B8EA-627E991D582E--


From nobody Thu Jul 16 13:35: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 06E1D3A0CB4 for ; Thu, 16 Jul 2020 13:35:06 -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 oU4CcmMdpr78 for ; Thu, 16 Jul 2020 13:35:03 -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 83A9F3A0CB2 for ; Thu, 16 Jul 2020 13:35:02 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id f5so9787960ljj.10 for ; Thu, 16 Jul 2020 13:35: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=0WDKieczsshZytlFQw2kPJ8dUvxyCmS5nLoXQsBzNmw=; b=KCOevJQgybXGKL7Qz+Cd1x0RsdoEn/WHIXDk6ybUJwrAPs8UoN3Xq1Uezi9uHx8t62 MeuhxBn/7RYj9ZEirBAdsGXFlakK5BZ5LSEKzaDF41bjTEcym14KA4P4Mf/U2mgW+NWc TwqNfDkIoBsAzLZBDy2qpjfJEWYzrlZM1ckywKcJL1aIX66KpvULj5PMiINed8avfNR2 vZhfTjyplI5sObBEgLOgSpIs7uKNw3p183zZMahbRHsqqYxcQT6t74vyB4jbGsl6lmRB pwaibKaRc6eDoUx7r8+IZ5WeRVXT8F+gr++gyGvUV/fceuxLKKUGcLnQh6bPTr/n2hiS eUNA==
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=0WDKieczsshZytlFQw2kPJ8dUvxyCmS5nLoXQsBzNmw=; b=oyuUfaG+0mfM8FpQeWCRG/VcWJqxTisQA2Yoa/S/VXcqsaaEH1OfUYduJqvc6kaH/U drvYzOxepEE3YzRHGJH3ltLSMtOM7FSv7MN3f2e7TBXN008fXffALF1LMf0kWFAkqbos Ymy4IAf2sV1SzFI9XUUW5FUdUuhj71ad42Pm6mPCNKaG1G1eOkS2uretXqfJnAmq9mU2 IG6RbUuO9HThtz4IJurgWoNkLwo6FR/7yfsvTevRKKXIHahETubKm22mgaJNJZjqxEpZ yoi6qJSJ2D+L6MtvIoZ2ggucPLZDGT1K90CJiAa7oOoLqNfPpJzHmE5yx8Zqm7x/rCKK +TSw==
X-Gm-Message-State: AOAM5324dMCMENWou63l3Q/hLn5ur/U52DAF5dYU1rM4y7WzbK+QhZ4F VZiLD/S9/TMCwtpSXKnHuK82HEVQnpHbSQBkpM8=
X-Google-Smtp-Source: ABdhPJyGYZSgaY+NaTliX7oLxMRFCjRsbjfkmUc/Y4MPSQ50Qg6IGKAgA3R2yxrgpbMwwtNDR4tVcTxu/xzt44rwb4E=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr3024132ljg.69.1594931700425; Thu, 16 Jul 2020 13:35:00 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>    <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>
In-Reply-To: <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>
From: Dick Hardt 
Date: Thu, 16 Jul 2020 13:34:23 -0700
Message-ID: 
To: Justin Richer 
Cc: Fabien Imbault , Mike Varley ,  "txauth@ietf.org" , Mike Jones 
Content-Type: multipart/alternative; boundary="00000000000071e8cc05aa94f9c2"
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 16 Jul 2020 20:35:06 -0000

--00000000000071e8cc05aa94f9c2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

One client identifier was a simplistic example. Org A may have numerous
clients, perhaps in different teams, perhaps in different services, each
with their own policy at Org B.

When one of the Org A clients makes a call to the Org B AS, it needs to
identify itself with some identifier so that Org B knows which policy to
enforce. Why not the Client ID?

I also agree with your comments that other client identification situations
are different, and forcing the same identification model on them does not
make sense, but I fail to see the value throwing out a concept (client_id)
that has worked well for the use cases it was designed for.


=E1=90=A7

On Thu, Jul 16, 2020 at 1:08 PM Justin Richer  wrote:

> I think that the cross-organizational trust model is an interesting one,
> and in fact it=E2=80=99s one of the things that=E2=80=99s pushed me away =
from a client_id.
> In the scenario that you describe, =E2=80=9Cclient_id=E2=80=9D is used to=
 represent
> something that it was never meant to represent: the organization running
> the software, not the software itself. It isn=E2=80=99t a client_id, and =
while in
> OAuth 2 the client_id could be co-opted to carry that information, it=E2=
=80=99s
> considered bad practice to share client_ids between multiple pieces of
> software.
>
> I would argue that to address this use case properly, there should be
> another level of identifier to bridge that trust that the software can
> present, showing that it is a part of Organization A, and not Organizatio=
n
> C. This isn=E2=80=99t a client identifier, it=E2=80=99s an organization i=
dentifier, and it
> should be separate. You might want to identify both the client instance a=
s
> well as the organization it=E2=80=99s a part of, for example. This is par=
t of the
> motivation behind putting =E2=80=9Corganizational data=E2=80=9D within sc=
ope for the client
> to send to the AS, after all.
>
> Therefore, I strongly disagree that this scenario =E2=80=9Crequires=E2=80=
=9D a client_id
> to be solved. In fact, I think that solving this scenario with a client_i=
d
> is an anti-pattern that stems from OAuth 2=E2=80=99s over-reliance on cli=
ent_id as
> a persistent identifier within the protocol, and we can and should do
> better with GNAP. It=E2=80=99s very similar to Mike Jones=E2=80=99s refer=
enced federation
> document, where the client_id is co-opted as a means of bootstrapping
> client registration and discovery, or in the Solid Authentication
> specification which stuffs a WebID into the client_id field.
>
> With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools that we ha=
d to solve our
> problems, and come up with some very clever solutions. What I=E2=80=99m t=
rying to
> argue to this community is that we are in a position to create our own,
> better tools.
>
>  =E2=80=94 Justin
>
> On Jul 16, 2020, at 2:00 PM, Dick Hardt  wrote:
>
> Justin,
>
> While I agree that the assumption in OAuth 2 that all Clients have a
> client_id is problematic, the requirement for a client_id in many use cas=
es
> is still there, and it does not represent a piece of software, but a
> relationship between parties.
>
> Organization A writes client software that calls resources managed by the
> AS in Organization B. The client_id represents Organization A to
> Organization B. Organization B does not care what software Organization A
> is running, and there may be numerous pieces of software at Organization =
A
> that use the same client_id. The access granted by Organization B to
> Organization A needs to be able to be different than the rights granted t=
o
> Organization C.
>
> I agree that we don't want to force all clients to have a client_id, and
> as discussed, there are a variety of inputs for an AS to accept calls fro=
m
> a piece of software, and often, that will be a particular *instance* of
> the software, but we also don't want to force clients to all be treated t=
he
> same, because they are not.
>
>
>
>
>
>
> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer  wrote:
>
>> Exactly =E2=80=94 when we start to look at it as managing the lifecycle =
of a
>> piece of software, instead of a registration at the AS, we can start
>> thinking in different terms what =E2=80=9Ctrusting=E2=80=9D the client m=
eans in the context
>> of what the client is doing. That trust could come from some kind of sig=
ned
>> attestation about the software (like the OAuth 2 DynReg software
>> statement), or it could come from some externally fetchable item (like a
>> Solid WebID, a DID, or the OIDC Federation extension), or it could come
>> from someone sitting at a console and typing in information and getting
>> back an identifier. And none of these need to pretend to be a global
>> =E2=80=9Cclient id=E2=80=9D for it to work. The world of clients is much=
 more diverse than
>> OAuth 2 likes to admit, and we see that with trying to nail down a
>> =E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=80=
=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautomatic=E2=
=80=9D vs.
>> =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of other things.
>>
>> OAuth 2 only needs client IDs because the front channel needs a way to
>> pass client identifiers when the client can=E2=80=99t authenticate itsel=
f directly.
>> We tried to get rid of this restriction with PAR and JAR together, but
>> there turned out to be corner cases in OAuth 2=E2=80=99s world that stil=
l needed
>> client_id, and implementations assumed it would be there anyway.
>>
>> In GNAP, we can avoid that problem from the beginning by looking at the
>> model differently and understanding where we=E2=80=99re coming from, and=
 why.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault 
>> wrote:
>>
>> +1 on that.
>>
>> We can then see it more as life cycle management of the client than
>> registration per say, and this comes with many benefits compared to the
>> current client_id.
>>
>> Fabien
>>
>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer  wrote:
>>
>>> I not only agree with Mike Jones that =E2=80=9Cautomatic registration=
=E2=80=9D should be
>>> part of the process, but I would argue that that kind of model should b=
e a
>>> default mode of operation. If you have an identifier that you can send =
to
>>> short-circuit that, great! But we should focus on having the capability=
 of
>>> inlining a lot of this information wherever possible. This is already t=
he
>>> direction that the input proposals are heading.
>>>
>>> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope for =
the protocol in
>>> general, and since both XYZ and Xauth have mechanisms that allow the cl=
ient
>>> to present a key and get back an identifier that it can use in the futu=
re
>>> we have something equivalent.
>>>
>>> But I think there=E2=80=99s a little more to it than that: Ultimately, =
I think
>>> we should question thinking in terms of =E2=80=9Cregistration=E2=80=9D,=
 a model which has
>>> hampered the OAuth 2 model in a lot of use cases. For example, the
>>> federation draft Mike Jones references below hacks the =E2=80=9Cclient_=
id=E2=80=9D
>>> parameter and makes it point to a document that the AS has to fetch. Th=
is
>>> construct is done for two reasons: (1) Oauth requires a =E2=80=9Cclient=
_id=E2=80=9D in the
>>> request and (2) it=E2=80=99s difficult to pass information by value to =
the AS due
>>> to front-channel restrictions. Since we=E2=80=99re defining a new proto=
col, we
>>> don=E2=80=99t need to hack that functionality into a =E2=80=9Cclient ID=
=E2=80=9D or equivalent and
>>> instead we can pass that information directly in the protocol. If we do=
n=E2=80=99t
>>> assume that the client *has* to have a client ID equivalent, but it *ca=
n*
>>> have one in a set of defined circumstances, then I think we are in a mu=
ch
>>> better spot. This is the reasoning for XYZ=E2=80=99s model of having cl=
ients
>>> identified by the key, and that key can potentially be passed by a
>>> reference identifier.
>>>
>>> I think all of the use cases that Mike Varley presents below are all
>>> valid directions, with the caveat that we shouldn=E2=80=99t assume a cl=
ient should
>>> be presenting an ID at all steps. Mechanisms like software statements
>>> should be presentable apart from a client ID, as should on-device keys.
>>> We=E2=80=99re probably going to want extensions for device posture and =
other forms
>>> of attestation as well.
>>>
>>> This is one of the domains that I think we can clearly surpass OAuth 2=
=E2=80=99s
>>> flexibility and capabilities if we are willing to look past OAuth 2=E2=
=80=99s
>>> assumptions of what=E2=80=99s needed inline in the protocol.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 14, 2020, at 1:54 PM, Mike Varley 
>>> wrote:
>>>
>>> Is client registration in scope for the protocol?
>>>
>>> A generic way of handling clients (via ID or Handle or Key or whatever)
>>> is to have processing rule on the AS such as =E2=80=9Cif the AS recogni=
zes the
>>> client ID (and authentication of that client ID) then it may process th=
e
>>> request on behalf of that client. If the AS does not recognize the clie=
nt
>>> ID, it must treat this as a new client registration and evaluate any
>>> authorization evidence the client provides before enabling the client a=
nd
>>> mapping policies to that client=E2=80=9D (this means dynamic or automat=
ic clients
>>> need to provide additional assertions / software statements whatever to
>>> register their ID.
>>>
>>> Something like this allows for very flexible systems:
>>> System A can be unknown to the AS but can dynamically registered each
>>> time with an appropriate software statement
>>> System B can have a fairly stable client ID at the AS, but rotate that
>>> ID every month through automatic registration (with an assertion it got
>>> from the AS during a pre-registration for example)
>>> System C can pre-register with the AS for a client ID because it doesn=
=E2=80=99t
>>> deal with software statements etc=E2=80=A6
>>> =E2=80=A6
>>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing cli=
ent IDs because
>>> it will always just rely on the software statements.
>>>
>>> I think a client registration protocol that allows these scenarios woul=
d
>>> be very useful in GNAP, but hopefully avoiding having to define what
>>> =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
>>>
>>> Thanks,
>>>
>>> MV
>>>
>>> *From: *Txauth  on behalf of Mike Jones <
>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
>>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>>> *To: *Dick Hardt , "txauth@ietf.org" <
>>> txauth@ietf.org>, Justin Richer 
>>> *Subject: *Re: [Txauth] Key handle vs client id & handle
>>>
>>> I agree that there are significant differences between statically and
>>> dynamically registered clients and that=E2=80=99s appropriate to be abl=
e to
>>> syntactically differentiate between them at runtime.  For one thing, th=
e
>>> resource requirements at the authorization server can be very different=
.
>>>
>>> We should also be thinking about how to include what the OpenID Connect
>>> Federation spec
>>> https://openid.net/specs/openid-connect-federation-1_0.html calls
>>> =E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client encode =
a registration
>>> request reference in the client ID, so no static or dynamic registratio=
n
>>> even occurs.  See
>>> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.sect=
ion.9.1
>>> 
>>> .
>>>
>>>                                                        -- Mike
>>>
>>> *From:* Dick Hardt 
>>> *Sent:* Friday, July 10, 2020 1:17 PM
>>> *To:* txauth@ietf.org; Justin Richer ; Mike Jones <
>>> Michael.Jones@microsoft.com>
>>> *Subject:* Key handle vs client id & handle
>>>
>>> + Mike as he had interest in this topic
>>>
>>> My understanding is that an existing OAuth 2 client would use their
>>> current client id as their key handle, and a dynamic client (one that w=
as
>>> not pre-registered) would be given a key handle by the AS.
>>>
>>> There are potentially some significant differences between a registered
>>> client, and a dynamic client to an AS.
>>>
>>> The AS is likely to know the identity of a registered client, and have
>>> different policies between the two types of clients. For example, a
>>> registered client may have access to a 'write" scope, while a dynamic
>>> client does not.
>>>
>>> The AS may have 100s or 1000s of registered clients, but a dynamic
>>> client may have 10Ms or 100Ms of instances, which may dictate
>>> separate storage services. Additionally, internal to the AS, which syst=
ems
>>> can write to the registered client store is going to be different than =
the
>>> dynamic client store.
>>>
>>> In XYZ, subsequent calls to the AS, both registered clients and dynamic
>>> clients pass a key handle, so there is no easy way to differentiate bet=
ween
>>> the two.
>>>
>>> While the AS could embed semantics in the key handle identifier to
>>> indicate which identifiers are pre-registered vs dynamic, there are man=
y
>>> cases where the AS does need to know the difference, so making the
>>> difference a feature of GNAP seems like a better path.
>>>
>>>
>>>
>>> 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 inte=
nded
>>> recipient, please contact the sender immediately, and permanently delet=
e
>>> this email and its attachments.
>>>
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>>
>

--00000000000071e8cc05aa94f9c2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


One client identifier was a simplistic example. Org A may =
have numerous clients, perhaps in different teams, perhaps in different ser=
vices, each with their own policy at Org B.

When one=
 of the Org A clients makes a call to the Org B AS, it needs to identify it=
self with some identifier so that Org B knows which policy to enforce. Why =
not the Client ID?

I also agree with your comments=
 that other client identification situations are different, and forcing the=
 same identification model on them does not make sense, but I fail=C2=A0to =
see the value throwing out a concept (client_id) that has worked well for t=
he use cases it was designed for.=C2=A0


=

3D""==E1=90=A7

On Thu, Jul 16, 2020 at 1:08 PM Justin Riche=
r <jricher@mit.edu> wrote:
=

I think that the cross-organizational trust model is=
 an interesting one, and in fact it=E2=80=99s one of the things that=E2=80=
=99s pushed me away from a client_id. In the scenario that you describe, =
=E2=80=9Cclient_id=E2=80=9D is used to represent something that it was neve=
r meant to represent: the organization running the software, not the softwa=
re itself. It isn=E2=80=99t a client_id, and while in OAuth 2 the client_id=
 could be co-opted to carry that information, it=E2=80=99s considered bad p=
ractice to share client_ids between multiple pieces of software.=C2=A0
=

I would argue that to address this use case properly, there =
should be another level of identifier to bridge that trust that the softwar=
e can present, showing that it is a part of Organization A, and not Organiz=
ation C. This isn=E2=80=99t a client identifier, it=E2=80=99s an organizati=
on identifier, and it should be separate. You might want to identify both t=
he client instance as well as the organization it=E2=80=99s a part of, for =
example. This is part of the motivation behind putting =E2=80=9Corganizatio=
nal data=E2=80=9D within scope for the client to send to the AS, after all.=


Therefore, I strongly disagree that this scenario=
 =E2=80=9Crequires=E2=80=9D a client_id to be solved. In fact, I think that=
 solving this scenario with a client_id is an anti-pattern that stems from =
OAuth 2=E2=80=99s over-reliance on client_id as a persistent identifier wit=
hin the protocol, and we can and should do better with GNAP. It=E2=80=99s v=
ery similar to Mike Jones=E2=80=99s referenced federation document, where t=
he client_id is co-opted as a means of bootstrapping client registration an=
d discovery, or in the Solid Authentication specification which stuffs a We=
bID into the client_id field.

With OAuth 2=E2=80=
=99s ecosystem, we=E2=80=99ve used the tools that we had to solve our probl=
ems, and come up with some very clever solutions. What I=E2=80=99m trying t=
o argue to this community is that we are in a position to create our own, b=
etter tools.=C2=A0

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

On Jul 16, 2020, at 2:00 PM, Dick Hardt =
<dick.hardt@gm=
ail.com> wrote:

Justin,=C2=A0
While I agree that the assumption in OAuth 2 that all Clients h=
ave a client_id is problematic, the requirement for a client_id in many use=
 cases is still there, and it does not represent a piece of software, but a=
 relationship between parties.

Organization A=
 writes client software that calls resources managed by the AS in Organizat=
ion B. The client_id represents Organization A to Organization B. Organizat=
ion B does not care what software Organization A is running, and there may =
be numerous=C2=A0pieces of software at Organization A that use the same cli=
ent_id. The access granted by Organization B to Organization A needs to be =
able to be different than the rights granted to Organization C.=C2=A0
=


I agree that we don't want to force all clien=
ts to have a client_id, and as discussed, there are a variety of inputs for=
 an AS to accept calls from a piece of software, and often, that will be a =
particular instance of the software, but we also don't want to f=
orce clients to all be treated the same, because they are not.=C2=A0
<=
div>




<=
/div>
O=
n Thu, Jul 16, 2020 at 8:24 AM Justin Richer <jricher@mit.edu> wrote:
Exactly =E2=80=94 when we st=
art to look at it as managing the lifecycle of a piece of software, instead=
 of a registration at the AS, we can start thinking in different terms what=
 =E2=80=9Ctrusting=E2=80=9D the client means in the context of what the cli=
ent is doing. That trust could come from some kind of signed attestation ab=
out the software (like the OAuth 2 DynReg software statement), or it could =
come from some externally fetchable item (like a Solid WebID, a DID, or the=
 OIDC Federation extension), or it could come from someone sitting at a con=
sole and typing in information and getting back an identifier. And none of =
these need to pretend to be a global =E2=80=9Cclient id=E2=80=9D for it to =
work. The world of clients is much more diverse than OAuth 2 likes to admit=
, and we see that with trying to nail down a =E2=80=9Cconfidential=E2=80=9D=
 vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cst=
atic=E2=80=9D vs. =E2=80=9Cautomatic=E2=80=9D vs. =E2=80=9Cephemeral=E2=80=
=9D vs. =E2=80=A6 any number of other things.=C2=A0

OAuth 2 only needs client IDs because the front channel needs a way to pas=
s client identifiers when the client can=E2=80=99t authenticate itself dire=
ctly. We tried to get rid of this restriction with PAR and JAR together, bu=
t there turned out to be corner cases in OAuth 2=E2=80=99s world that still=
 needed client_id, and implementations assumed it would be there anyway.=C2=
=A0

In GNAP, we can avoid that problem from the be=
ginning by looking at the model differently and understanding where we=E2=
=80=99re coming from, and why.

=C2=A0=E2=80=94 Jus=
tin

On Jul 16, 2020, at 3:49 AM,=
 Fabien Imbault <fabien.imbault@gmail.com> wrote:

+1 on that.

We can then see it more as life cycle man=
agement of the client than registration per say, and this comes with many b=
enefits compared to the current client_id.

Fabien<=
/div>

On Tue, Jul 14, 2020 at 9:32 PM Justin Richer <jricher@mit.edu> wrote:
I not only agree with =
Mike Jones that =E2=80=9Cautomatic registration=E2=80=9D should be part of =
the process, but I would argue that that kind of model should be a default =
mode of operation. If you have an identifier that you can send to short-cir=
cuit that, great! But we should focus on having the capability of inlining =
a lot of this information wherever possible. This is already the direction =
that the input proposals are heading.

So I kind-of agree=
 that =E2=80=9Cregistration=E2=80=9D is in scope for the protocol in genera=
l, and since both XYZ and Xauth have mechanisms that allow the client to pr=
esent a key and get back an identifier that it can use in the future we hav=
e something equivalent.=C2=A0

But I think there=E2=
=80=99s a little more to it than that: Ultimately, I think we should questi=
on thinking in terms of =E2=80=9Cregistration=E2=80=9D, a model which has h=
ampered the OAuth 2 model in a lot of use cases. For example, the federatio=
n draft Mike Jones references below hacks the =E2=80=9Cclient_id=E2=80=9D p=
arameter and makes it point to a document that the AS has to fetch. This co=
nstruct is done for two reasons: (1) Oauth requires a =E2=80=9Cclient_id=E2=
=80=9D in the request and (2) it=E2=80=99s difficult to pass information by=
 value to the AS due to front-channel restrictions. Since we=E2=80=99re def=
ining a new protocol, we don=E2=80=99t need to hack that functionality into=
 a =E2=80=9Cclient ID=E2=80=9D or equivalent and instead we can pass that i=
nformation directly in the protocol. If we don=E2=80=99t assume that the cl=
ient *has* to have a client ID equivalent, but it *can* have one in a set o=
f defined circumstances, then I think we are in a much better spot. This is=
 the reasoning for XYZ=E2=80=99s model of having clients identified by the =
key, and that key can potentially be passed by a reference identifier.

I think all of the use cases that Mike Varley presents=
 below are all valid directions, with the caveat that we shouldn=E2=80=99t =
assume a client should be presenting an ID at all steps. Mechanisms like so=
ftware statements should be presentable apart from a client ID, as should o=
n-device keys. We=E2=80=99re probably going to want extensions for device p=
osture and other forms of attestation as well.

Thi=
s is one of the domains that I think we can clearly surpass OAuth 2=E2=80=
=99s flexibility and capabilities if we are willing to look past OAuth 2=E2=
=80=99s assumptions of what=E2=80=99s needed inline in the protocol.=C2=A0<=
/div>

=C2=A0=E2=80=94 Justin

On Jul 14, 2020, at 1:54 PM, Mike Varley <mike.varley@securek=
ey.com> wrote:

Is clien=
t registration in scope for the protocol?
<=
/u>=C2=A0
A generic way of handling clients (via ID o=
r Handle or Key or whatever) is to have processing rule on the AS such as =
=E2=80=9Cif the AS recognizes the client ID (and authentication of that cli=
ent ID) then it may process the request on behalf of that client. If the AS=
 does not recognize the client ID, it must treat this as a new client regis=
tration and evaluate any authorization evidence the client provides before =
enabling the client and mapping policies to that client=E2=80=9D (this mean=
s dynamic or automatic clients need to provide additional assertions / soft=
ware statements whatever to register their ID.
=C2=A0
Something like this allows for very fl=
exible systems:
System A can be unknown to the=
 AS but can dynamically registered each time with an appropriate software s=
tatement
System B can have a fairly stable cli=
ent ID at the AS, but rotate that ID every month through automatic registra=
tion (with an assertion it got from the AS during a pre-registration for ex=
ample)
System C can pre-register with the AS f=
or a client ID because it doesn=E2=80=99t deal with software statements etc=
=E2=80=A6
=E2=80=A6
And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing clie=
nt IDs because it will always just rely on the software statements.<=
u>
=C2=A0
I think a client =
registration protocol that allows these scenarios would be very useful in G=
NAP, but hopefully avoiding having to define what =E2=80=98evidence=E2=80=
=99 the AS needs to accept for each scenario.
=
=C2=A0
Thanks,
=
=C2=A0
MV
=
=C2=A0
From:=C2=A0<=
span style=3D"font-size:12pt">Txauth <txauth-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones=3D4=
0microsoft.com@dmarc.ietf.org>
Date:=C2=A0Tue=
sday, July 14, 2020 at 12:18 PM
To:=C2=A0Dick Hardt =
<dick.hardt@gmail.com>, &q=
uot;txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
Subject:=
=C2=A0Re: [Txauth] Key handle vs client id & handle
=C2=A0
I agree that there are s=
ignificant differences between statically and dynamically registered client=
s and that=E2=80=99s appropriate to be able to syntactically differentiate =
between them at runtime.=C2=A0 For one thing, the resource requirements at =
the authorization server can be very different.
<=
div style=3D"margin:0cm 0cm 0.0001pt 36pt;font-size:11pt;font-family:Calibr=
i,sans-serif">=C2=A0
We should also be =
thinking about how to include what the OpenID Connect Federation spec=
=C2=A0https://openid.net/specs/openid-connect-federation-1_0.html=
=C2=A0calls =E2=80=9CAutomatic Registration=E2=80=9D.=C2=
=A0 This lets the client encode a registration request reference in the cli=
ent ID, so no static or dynamic registration even occurs.=C2=A0 See=
=C2=A0https://openid.net/specs/openid-connect-federa=
tion-1_0-12.html#rfc.section.9.1.
=C2=
=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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<=
/u>
=C2=A0
From:=C2=A0Dick Hardt <dick.hardt@gmail.com>=C2=A0
Sen=
t:=C2=A0Friday, July 10, 2020 1:17 PM
To:=
=C2=A0txauth@ietf.org; Justin =
Richer <jricher@mit.edu>; Mike =
Jones <Michael.Jones@micro=
soft.com>
Subject:=C2=A0Key handle vs client =
id & handle
=C2=A0
+ Mike as he had interest in this topic
=C2=A0
=C2=A0
=
There are potentially some significant differences between a registered cli=
ent, and a dynamic client to an AS.
=C2=A0
The AS is likely =
to know the identity of a registered client, and have different policies be=
tween the two types of clients. For example, a registered client may have a=
ccess to a 'write" scope, while a dynamic client does not.<=
u>
=C2=A0
=

The AS may have 100s or 1000s of registered clients, but a d=
ynamic client may have 10Ms or 100Ms of instances, which may dictate separa=
te=C2=A0storage services. Additionally, internal to the AS, which systems c=
an write to the registered=C2=A0client store is going to be different than =
the dynamic client=C2=A0store.
=C2=A0
In XYZ, subsequent cal=
ls to the AS, both registered clients and dynamic clients pass a key handle=
, so there is no easy way to differentiate between the two.
=C2=A0
While the AS could embed semantics in the key handle identifier to i=
ndicate which identifiers are pre-registered vs dynamic, there are many cas=
es where the AS does need to know the difference, so making=C2=A0the differ=
ence a feature of GNAP seems like a better path.
<=
/div>
=C2=A0
This email and any attachment=
s are for the sole use of the intended recipients and may be privileged, co=
nfidential or otherwise exempt from disclosure under law. Any distribution,=
 printing or other use by anyone other than the intended recipient is prohi=
bited. If you are not an intended recipient, please contact the sender imme=
diately, and permanently delete this email and its attachments.

-- 

Txauth mailing list

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









--00000000000071e8cc05aa94f9c2--


From nobody Thu Jul 16 14:47: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 561F33A0D40 for ; Thu, 16 Jul 2020 14:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 yyyP7pTUThgv for ; Thu, 16 Jul 2020 14:46:56 -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 746D13A0D45 for ; Thu, 16 Jul 2020 14:46:56 -0700 (PDT)
Received: from [192.168.1.7] (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 06GLkqbX007754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jul 2020 17:46:52 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_BE9DB44B-C917-48A0-B40B-7B0609FFB916"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 16 Jul 2020 17:46:52 -0400
In-Reply-To: 
Cc: Fabien Imbault , Mike Varley , "txauth@ietf.org" , Mike Jones 
To: Dick Hardt 
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>    <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 16 Jul 2020 21:46:59 -0000

--Apple-Mail=_BE9DB44B-C917-48A0-B40B-7B0609FFB916
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

For all of these, I still say we should have different levels of =
identifier. A =E2=80=9Cclient ID=E2=80=9D should identify the client, =
and not be used as a stand-in for other things.=20

Off the top of my head I think we might want to have identifiers, =
assertions, proofs, and other trust-binding items for:

 - Organizations
 - Devices
 - Software applications
 - Software instances
 - Software versions

So if we=E2=80=99re going to talk about identifying these aspects, we =
should tackle each as its own thing and not mush it all into =
=E2=80=9Cclient_id=E2=80=9D. That way, hopefully, GNAP can have a much =
better idea what a =E2=80=9Cclient=E2=80=9D is than OAuth 2 currently =
does.

 =E2=80=94 Justin

> On Jul 16, 2020, at 4:34 PM, Dick Hardt  wrote:
>=20
> One client identifier was a simplistic example. Org A may have =
numerous clients, perhaps in different teams, perhaps in different =
services, each with their own policy at Org B.
>=20
> When one of the Org A clients makes a call to the Org B AS, it needs =
to identify itself with some identifier so that Org B knows which policy =
to enforce. Why not the Client ID?
>=20
> I also agree with your comments that other client identification =
situations are different, and forcing the same identification model on =
them does not make sense, but I fail to see the value throwing out a =
concept (client_id) that has worked well for the use cases it was =
designed for.=20
>=20
>=20
> =E1=90=A7
>=20
> On Thu, Jul 16, 2020 at 1:08 PM Justin Richer > wrote:
> I think that the cross-organizational trust model is an interesting =
one, and in fact it=E2=80=99s one of the things that=E2=80=99s pushed me =
away from a client_id. In the scenario that you describe, =
=E2=80=9Cclient_id=E2=80=9D is used to represent something that it was =
never meant to represent: the organization running the software, not the =
software itself. It isn=E2=80=99t a client_id, and while in OAuth 2 the =
client_id could be co-opted to carry that information, it=E2=80=99s =
considered bad practice to share client_ids between multiple pieces of =
software.=20
>=20
> I would argue that to address this use case properly, there should be =
another level of identifier to bridge that trust that the software can =
present, showing that it is a part of Organization A, and not =
Organization C. This isn=E2=80=99t a client identifier, it=E2=80=99s an =
organization identifier, and it should be separate. You might want to =
identify both the client instance as well as the organization it=E2=80=99s=
 a part of, for example. This is part of the motivation behind putting =
=E2=80=9Corganizational data=E2=80=9D within scope for the client to =
send to the AS, after all.
>=20
> Therefore, I strongly disagree that this scenario =E2=80=9Crequires=E2=80=
=9D a client_id to be solved. In fact, I think that solving this =
scenario with a client_id is an anti-pattern that stems from OAuth 2=E2=80=
=99s over-reliance on client_id as a persistent identifier within the =
protocol, and we can and should do better with GNAP. It=E2=80=99s very =
similar to Mike Jones=E2=80=99s referenced federation document, where =
the client_id is co-opted as a means of bootstrapping client =
registration and discovery, or in the Solid Authentication specification =
which stuffs a WebID into the client_id field.
>=20
> With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools that we =
had to solve our problems, and come up with some very clever solutions. =
What I=E2=80=99m trying to argue to this community is that we are in a =
position to create our own, better tools.=20
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 16, 2020, at 2:00 PM, Dick Hardt > wrote:
>>=20
>> Justin,=20
>>=20
>> While I agree that the assumption in OAuth 2 that all Clients have a =
client_id is problematic, the requirement for a client_id in many use =
cases is still there, and it does not represent a piece of software, but =
a relationship between parties.
>>=20
>> Organization A writes client software that calls resources managed by =
the AS in Organization B. The client_id represents Organization A to =
Organization B. Organization B does not care what software Organization =
A is running, and there may be numerous pieces of software at =
Organization A that use the same client_id. The access granted by =
Organization B to Organization A needs to be able to be different than =
the rights granted to Organization C.=20
>>=20
>> I agree that we don't want to force all clients to have a client_id, =
and as discussed, there are a variety of inputs for an AS to accept =
calls from a piece of software, and often, that will be a particular =
instance of the software, but we also don't want to force clients to all =
be treated the same, because they are not.=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer > wrote:
>> Exactly =E2=80=94 when we start to look at it as managing the =
lifecycle of a piece of software, instead of a registration at the AS, =
we can start thinking in different terms what =E2=80=9Ctrusting=E2=80=9D =
the client means in the context of what the client is doing. That trust =
could come from some kind of signed attestation about the software (like =
the OAuth 2 DynReg software statement), or it could come from some =
externally fetchable item (like a Solid WebID, a DID, or the OIDC =
Federation extension), or it could come from someone sitting at a =
console and typing in information and getting back an identifier. And =
none of these need to pretend to be a global =E2=80=9Cclient id=E2=80=9D =
for it to work. The world of clients is much more diverse than OAuth 2 =
likes to admit, and we see that with trying to nail down a =
=E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =
=E2=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =
=E2=80=9Cautomatic=E2=80=9D vs. =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 =
any number of other things.=20
>>=20
>> OAuth 2 only needs client IDs because the front channel needs a way =
to pass client identifiers when the client can=E2=80=99t authenticate =
itself directly. We tried to get rid of this restriction with PAR and =
JAR together, but there turned out to be corner cases in OAuth 2=E2=80=99s=
 world that still needed client_id, and implementations assumed it would =
be there anyway.=20
>>=20
>> In GNAP, we can avoid that problem from the beginning by looking at =
the model differently and understanding where we=E2=80=99re coming from, =
and why.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault =
> wrote:
>>>=20
>>> +1 on that.
>>>=20
>>> We can then see it more as life cycle management of the client than =
registration per say, and this comes with many benefits compared to the =
current client_id.
>>>=20
>>> Fabien
>>>=20
>>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer > wrote:
>>> I not only agree with Mike Jones that =E2=80=9Cautomatic =
registration=E2=80=9D should be part of the process, but I would argue =
that that kind of model should be a default mode of operation. If you =
have an identifier that you can send to short-circuit that, great! But =
we should focus on having the capability of inlining a lot of this =
information wherever possible. This is already the direction that the =
input proposals are heading.
>>>=20
>>> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope =
for the protocol in general, and since both XYZ and Xauth have =
mechanisms that allow the client to present a key and get back an =
identifier that it can use in the future we have something equivalent.=20=

>>>=20
>>> But I think there=E2=80=99s a little more to it than that: =
Ultimately, I think we should question thinking in terms of =
=E2=80=9Cregistration=E2=80=9D, a model which has hampered the OAuth 2 =
model in a lot of use cases. For example, the federation draft Mike =
Jones references below hacks the =E2=80=9Cclient_id=E2=80=9D parameter =
and makes it point to a document that the AS has to fetch. This =
construct is done for two reasons: (1) Oauth requires a =E2=80=9Cclient_id=
=E2=80=9D in the request and (2) it=E2=80=99s difficult to pass =
information by value to the AS due to front-channel restrictions. Since =
we=E2=80=99re defining a new protocol, we don=E2=80=99t need to hack =
that functionality into a =E2=80=9Cclient ID=E2=80=9D or equivalent and =
instead we can pass that information directly in the protocol. If we =
don=E2=80=99t assume that the client *has* to have a client ID =
equivalent, but it *can* have one in a set of defined circumstances, =
then I think we are in a much better spot. This is the reasoning for =
XYZ=E2=80=99s model of having clients identified by the key, and that =
key can potentially be passed by a reference identifier.
>>>=20
>>> I think all of the use cases that Mike Varley presents below are all =
valid directions, with the caveat that we shouldn=E2=80=99t assume a =
client should be presenting an ID at all steps. Mechanisms like software =
statements should be presentable apart from a client ID, as should =
on-device keys. We=E2=80=99re probably going to want extensions for =
device posture and other forms of attestation as well.
>>>=20
>>> This is one of the domains that I think we can clearly surpass OAuth =
2=E2=80=99s flexibility and capabilities if we are willing to look past =
OAuth 2=E2=80=99s assumptions of what=E2=80=99s needed inline in the =
protocol.=20
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>> On Jul 14, 2020, at 1:54 PM, Mike Varley > wrote:
>>>>=20
>>>> Is client registration in scope for the protocol?
>>>> =20
>>>> A generic way of handling clients (via ID or Handle or Key or =
whatever) is to have processing rule on the AS such as =E2=80=9Cif the =
AS recognizes the client ID (and authentication of that client ID) then =
it may process the request on behalf of that client. If the AS does not =
recognize the client ID, it must treat this as a new client registration =
and evaluate any authorization evidence the client provides before =
enabling the client and mapping policies to that client=E2=80=9D (this =
means dynamic or automatic clients need to provide additional assertions =
/ software statements whatever to register their ID.
>>>> =20
>>>> Something like this allows for very flexible systems:
>>>> System A can be unknown to the AS but can dynamically registered =
each time with an appropriate software statement
>>>> System B can have a fairly stable client ID at the AS, but rotate =
that ID every month through automatic registration (with an assertion it =
got from the AS during a pre-registration for example)
>>>> System C can pre-register with the AS for a client ID because it =
doesn=E2=80=99t deal with software statements etc=E2=80=A6
>>>> =E2=80=A6
>>>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing =
client IDs because it will always just rely on the software statements.
>>>> =20
>>>> I think a client registration protocol that allows these scenarios =
would be very useful in GNAP, but hopefully avoiding having to define =
what =E2=80=98evidence=E2=80=99 the AS needs to accept for each =
scenario.
>>>> =20
>>>> Thanks,
>>>> =20
>>>> MV
>>>> =20
>>>> From: Txauth > on behalf of Mike Jones =
>
>>>> Date: Tuesday, July 14, 2020 at 12:18 PM
>>>> To: Dick Hardt >, "txauth@ietf.org =
" >, =
Justin Richer >
>>>> Subject: Re: [Txauth] Key handle vs client id & handle
>>>> =20
>>>> I agree that there are significant differences between statically =
and dynamically registered clients and that=E2=80=99s appropriate to be =
able to syntactically differentiate between them at runtime.  For one =
thing, the resource requirements at the authorization server can be very =
different.
>>>> =20
>>>> We should also be thinking about how to include what the OpenID =
Connect Federation spec =
https://openid.net/specs/openid-connect-federation-1_0.html =
 calls =
=E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client encode a =
registration request reference in the client ID, so no static or dynamic =
registration even occurs.  See =
https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section=
.9.1 =
.
>>>> =20
>>>>                                                        -- Mike
>>>> =20
>>>> From: Dick Hardt >=20
>>>> Sent: Friday, July 10, 2020 1:17 PM
>>>> To: txauth@ietf.org ; Justin Richer =
>; Mike Jones =
>
>>>> Subject: Key handle vs client id & handle
>>>> =20
>>>> + Mike as he had interest in this topic
>>>> =20
>>>> My understanding is that an existing OAuth 2 client would use their =
current client id as their key handle, and a dynamic client (one that =
was not pre-registered) would be given a key handle by the AS.
>>>> =20
>>>> There are potentially some significant differences between a =
registered client, and a dynamic client to an AS.
>>>> =20
>>>> The AS is likely to know the identity of a registered client, and =
have different policies between the two types of clients. For example, a =
registered client may have access to a 'write" scope, while a dynamic =
client does not.
>>>> =20
>>>> The AS may have 100s or 1000s of registered clients, but a dynamic =
client may have 10Ms or 100Ms of instances, which may dictate separate =
storage services. Additionally, internal to the AS, which systems can =
write to the registered client store is going to be different than the =
dynamic client store.
>>>> =20
>>>> In XYZ, subsequent calls to the AS, both registered clients and =
dynamic clients pass a key handle, so there is no easy way to =
differentiate between the two.
>>>> =20
>>>> While the AS could embed semantics in the key handle identifier to =
indicate which identifiers are pre-registered vs dynamic, there are many =
cases where the AS does need to know the difference, so making the =
difference a feature of GNAP seems like a better path.
>>>> =20
>>>> =20
>>>> 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.
>>>>=20
>>>=20
>>> --=20
>>> Txauth mailing list
>>> Txauth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/txauth =

>>=20
>=20


--Apple-Mail=_BE9DB44B-C917-48A0-B40B-7B0609FFB916
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

For =
all of these, I still say we should have different levels of identifier. =
A =E2=80=9Cclient ID=E2=80=9D should identify the client, and not be =
used as a stand-in for other things. 

Off the top of my head I think we might =
want to have identifiers, assertions, proofs, and other trust-binding =
items for:

 - Organizations
 - =
Devices
 - Software applications
 - Software instances
 - =
Software versions

So if we=E2=80=99re going to talk about identifying these =
aspects, we should tackle each as its own thing and not mush it all into =
=E2=80=9Cclient_id=E2=80=9D. That way, hopefully, GNAP can have a much =
better idea what a =E2=80=9Cclient=E2=80=9D is than OAuth 2 currently =
does.

 =E2=80=
=94 Justin

On Jul 16, 2020, at 4:34 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

One client identifier was a =
simplistic example. Org A may have numerous clients, perhaps in =
different teams, perhaps in different services, each with their own =
policy at Org B.

When one of the Org A clients makes a call to the Org B AS, =
it needs to identify itself with some identifier so that Org B knows =
which policy to enforce. Why not the Client ID?

I also agree with your comments that =
other client identification situations are different, and forcing the =
same identification model on them does not make sense, but I =
fail to see the value throwing out a concept (client_id) that has =
worked well for the use cases it was designed for. 


3D""=E1=90=A7

On Thu, Jul =
16, 2020 at 1:08 PM Justin Richer <jricher@mit.edu> wrote:
I think that the cross-organizational trust =
model is an interesting one, and in fact it=E2=80=99s one of the things =
that=E2=80=99s pushed me away from a client_id. In the scenario that you =
describe, =E2=80=9Cclient_id=E2=80=9D is used to represent something =
that it was never meant to represent: the organization running the =
software, not the software itself. It isn=E2=80=99t a client_id, and =
while in OAuth 2 the client_id could be co-opted to carry that =
information, it=E2=80=99s considered bad practice to share client_ids =
between multiple pieces of software. 

I would argue that to address this use =
case properly, there should be another level of identifier to bridge =
that trust that the software can present, showing that it is a part of =
Organization A, and not Organization C. This isn=E2=80=99t a client =
identifier, it=E2=80=99s an organization identifier, and it should be =
separate. You might want to identify both the client instance as well as =
the organization it=E2=80=99s a part of, for example. This is part of =
the motivation behind putting =E2=80=9Corganizational data=E2=80=9D =
within scope for the client to send to the AS, after all.

Therefore, I strongly =
disagree that this scenario =E2=80=9Crequires=E2=80=9D a client_id to be =
solved. In fact, I think that solving this scenario with a client_id is =
an anti-pattern that stems from OAuth 2=E2=80=99s over-reliance on =
client_id as a persistent identifier within the protocol, and we can and =
should do better with GNAP. It=E2=80=99s very similar to Mike Jones=E2=80=99=
s referenced federation document, where the client_id is co-opted as a =
means of bootstrapping client registration and discovery, or in the =
Solid Authentication specification which stuffs a WebID into the =
client_id field.

With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the =
tools that we had to solve our problems, and come up with some very =
clever solutions. What I=E2=80=99m trying to argue to this community is =
that we are in a position to create our own, better =
tools. 

 =E2=80=94 Justin

On Jul =
16, 2020, at 2:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, 

While I agree that the assumption in =
OAuth 2 that all Clients have a client_id is problematic, the =
requirement for a client_id in many use cases is still there, and it =
does not represent a piece of software, but a relationship between =
parties.

Organization A writes client software that calls resources =
managed by the AS in Organization B. The client_id represents =
Organization A to Organization B. Organization B does not care what =
software Organization A is running, and there may be =
numerous pieces of software at Organization A that use the same =
client_id. The access granted by Organization B to Organization A needs =
to be able to be different than the rights granted to Organization =
C. 

I=
 agree that we don't want to force all clients to have a client_id, and =
as discussed, there are a variety of inputs for an AS to accept calls =
from a piece of software, and often, that will be a particular instance of the software, but we also don't want to force =
clients to all be treated the same, because they are =
not. 






On Thu, Jul 16, 2020 at 8:24 AM Justin Richer =
<jricher@mit.edu> wrote:
Exactly =E2=80=94=
 when we start to look at it as managing the lifecycle of a piece of =
software, instead of a registration at the AS, we can start thinking in =
different terms what =E2=80=9Ctrusting=E2=80=9D the client means in the =
context of what the client is doing. That trust could come from some =
kind of signed attestation about the software (like the OAuth 2 DynReg =
software statement), or it could come from some externally fetchable =
item (like a Solid WebID, a DID, or the OIDC Federation extension), or =
it could come from someone sitting at a console and typing in =
information and getting back an identifier. And none of these need to =
pretend to be a global =E2=80=9Cclient id=E2=80=9D for it to work. The =
world of clients is much more diverse than OAuth 2 likes to admit, and =
we see that with trying to nail down a =E2=80=9Cconfidential=E2=80=9D =
vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=80=9Cdynamic=E2=80=9D vs. =
=E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautomatic=E2=80=9D vs. =
=E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of other =
things. 

OAuth 2 only needs client IDs because the front channel needs =
a way to pass client identifiers when the client can=E2=80=99t =
authenticate itself directly. We tried to get rid of this restriction =
with PAR and JAR together, but there turned out to be corner cases in =
OAuth 2=E2=80=99s world that still needed client_id, and implementations =
assumed it would be there anyway. 

In GNAP, we can avoid that problem from =
the beginning by looking at the model differently and understanding =
where we=E2=80=99re coming from, and why.

 =E2=80=94 Justin

On Jul 16, 2020, at 3:49 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

+1 on that.

We can then see it more =
as life cycle management of the client than registration per say, and =
this comes with many benefits compared to the current =
client_id.

Fabien

On Tue, Jul =
14, 2020 at 9:32 PM Justin Richer <jricher@mit.edu> wrote:
I not only agree with =
Mike Jones that =E2=80=9Cautomatic registration=E2=80=9D should be part =
of the process, but I would argue that that kind of model should be a =
default mode of operation. If you have an identifier that you can send =
to short-circuit that, great! But we should focus on having the =
capability of inlining a lot of this information wherever possible. This =
is already the direction that the input proposals are heading.

So I kind-of agree that =
=E2=80=9Cregistration=E2=80=9D is in scope for the protocol in general, =
and since both XYZ and Xauth have mechanisms that allow the client to =
present a key and get back an identifier that it can use in the future =
we have something equivalent. 

But I think there=E2=80=99s a little =
more to it than that: Ultimately, I think we should question thinking in =
terms of =E2=80=9Cregistration=E2=80=9D, a model which has hampered the =
OAuth 2 model in a lot of use cases. For example, the federation draft =
Mike Jones references below hacks the =E2=80=9Cclient_id=E2=80=9D =
parameter and makes it point to a document that the AS has to fetch. =
This construct is done for two reasons: (1) Oauth requires a =
=E2=80=9Cclient_id=E2=80=9D in the request and (2) it=E2=80=99s =
difficult to pass information by value to the AS due to front-channel =
restrictions. Since we=E2=80=99re defining a new protocol, we don=E2=80=99=
t need to hack that functionality into a =E2=80=9Cclient ID=E2=80=9D or =
equivalent and instead we can pass that information directly in the =
protocol. If we don=E2=80=99t assume that the client *has* to have a =
client ID equivalent, but it *can* have one in a set of defined =
circumstances, then I think we are in a much better spot. This is the =
reasoning for XYZ=E2=80=99s model of having clients identified by the =
key, and that key can potentially be passed by a reference =
identifier.

I =
think all of the use cases that Mike Varley presents below are all valid =
directions, with the caveat that we shouldn=E2=80=99t assume a client =
should be presenting an ID at all steps. Mechanisms like software =
statements should be presentable apart from a client ID, as should =
on-device keys. We=E2=80=99re probably going to want extensions for =
device posture and other forms of attestation as well.

This is one of the =
domains that I think we can clearly surpass OAuth 2=E2=80=99s =
flexibility and capabilities if we are willing to look past OAuth 2=E2=80=99=
s assumptions of what=E2=80=99s needed inline in the =
protocol. 

 =E2=80=94 Justin
On Jul =
14, 2020, at 1:54 PM, Mike Varley <mike.varley@securekey.com> wrote:

Is =
client registration in scope for the protocol?
 
A =
generic way of handling clients (via ID or Handle or Key or whatever) is =
to have processing rule on the AS such as =E2=80=9Cif the AS recognizes =
the client ID (and authentication of that client ID) then it may process =
the request on behalf of that client. If the AS does not recognize the =
client ID, it must treat this as a new client registration and evaluate =
any authorization evidence the client provides before enabling the =
client and mapping policies to that client=E2=80=9D (this means dynamic =
or automatic clients need to provide additional assertions / software =
statements whatever to register their ID.
 
Something like this allows for very flexible systems:
System =
A can be unknown to the AS but can dynamically registered each time with =
an appropriate software statement
System =
B can have a fairly stable client ID at the AS, but rotate that ID every =
month through automatic registration (with an assertion it got from the =
AS during a pre-registration for example)
System =
C can pre-register with the AS for a client ID because it doesn=E2=80=99t =
deal with software statements etc=E2=80=A6
=E2=80=A6=

And =
even =E2=80=98StatelessAS=E2=80=99 can operate by never storing client =
IDs because it will always just rely on the software statements.
 
I =
think a client registration protocol that allows these scenarios would =
be very useful in GNAP, but hopefully avoiding having to define what =
=E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
 
Thanks,
 
MV
 
From: Txauth <txauth-bounces@ietf.org> on behalf of Mike Jones =
<Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
Date: Tuesday, =
July 14, 2020 at 12:18 PM
To: Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
Subject: Re: [Txauth] Key =
handle vs client id & handle
 
I agree that there are =
significant differences between statically and dynamically registered =
clients and that=E2=80=99s appropriate to be able to syntactically =
differentiate between them at runtime.  For one thing, the resource =
requirements at the authorization server can be very different.
 
We should also =
be thinking about how to include what the OpenID Connect Federation =
spec https://openid.net/specs/openid-connect-federation-1_0.html=
 calls =E2=80=9CAutomatic =
Registration=E2=80=9D.  This lets the client encode a registration =
request reference in the client ID, so no static or dynamic registration =
even occurs.  See https://openid.net/specs/openid-connect-federation-1_0-12.html#=
rfc.section.9.1.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 
From: Dick Hardt <dick.hardt@gmail.com> 
Sent: Friday, =
July 10, 2020 1:17 PM
To: txauth@ietf.org; Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Subject: Key handle vs =
client id & handle
 
+ Mike as =
he had interest in this topic
 
My =
understanding is that an existing OAuth 2 client would use their current =
client id as their key handle, and a dynamic client (one that was not =
pre-registered) would be given a key handle by the AS.
 
There are =
potentially some significant differences between a registered client, =
and a dynamic client to an AS.
 
The AS is =
likely to know the identity of a registered client, and have different =
policies between the two types of clients. For example, a registered =
client may have access to a 'write" scope, while a dynamic client does =
not.
 
The AS =
may have 100s or 1000s of registered clients, but a dynamic client may =
have 10Ms or 100Ms of instances, which may dictate separate storage =
services. Additionally, internal to the AS, which systems can write to =
the registered client store is going to be different than the =
dynamic client store.
 
In XYZ, =
subsequent calls to the AS, both registered clients and dynamic clients =
pass a key handle, so there is no easy way to differentiate between the =
two.
 
While the =
AS could embed semantics in the key handle identifier to indicate which =
identifiers are pre-registered vs dynamic, there are many cases where =
the AS does need to know the difference, so making the difference a =
feature of GNAP seems like a better path.
 
 
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.

-- 

Txauth mailing list

Txauth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth
=










=

--Apple-Mail=_BE9DB44B-C917-48A0-B40B-7B0609FFB916--


From nobody Thu Jul 16 14:52: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 691833A0D50 for ; Thu, 16 Jul 2020 14:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.081
X-Spam-Level: 
X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 SLJX56oa9FAq for ; Thu, 16 Jul 2020 14:52: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 0B7263A0D4C for ; Thu, 16 Jul 2020 14:52:47 -0700 (PDT)
Received: from [192.168.1.7] (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 06GLqkEn009442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 16 Jul 2020 17:52:46 -0400
From: Justin Richer 
Content-Type: multipart/alternative; boundary="Apple-Mail=_0D99A97F-CBC9-4EAB-8158-4A9B3B969993"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: 
Date: Thu, 16 Jul 2020 17:52:46 -0400
To: txauth@ietf.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: [Txauth] New version of XYZ Draft
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, 16 Jul 2020 21:52:49 -0000

--Apple-Mail=_0D99A97F-CBC9-4EAB-8158-4A9B3B969993
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,

I=E2=80=99ve updated the XYZ draft specification. Since the publication =
tools are currently locked prior to the upcoming virtual meeting, I have =
published it online here:

https://oauth.xyz/draft-richer-transactional-authz =


This represents a pretty significant refactoring of the specification, =
hopefully to make the concepts and capabilities easier to understand. =
The core protocol is largely the same as before, but there are a number =
of serious updates:

 - Continuation requests happen at a URL returned in the TX response. =
The =E2=80=9Chandle=E2=80=9D is still sent as one of the input values =
here, since the handle can also be used it other contexts.
 - Tokens now can include the resources they are issued for
 - Tokens can have an optional management URI for rotation and =
revocation.
 - =E2=80=9Cclaims=E2=80=9D has been removed in favor of =E2=80=9Csubject=E2=
=80=9D dealing directly with identifiers and assertions
 - the =E2=80=9Cuser=E2=80=9D request and response now align with =
identifiers and assertions
 - Extensions and registries are more clearly enumerated throughout the =
document
 - DID-related items have been excised in deference to a future possible =
extension
 - Added a =E2=80=9Cpushback=E2=80=9D mechanism to complement the =
=E2=80=9Ccallback=E2=80=9D mechanism
 - Simplified dynamic handle returns and access tokens based on =
developer feedback (basically we dropped a bunch of =E2=80=9Cwhat if=E2=80=
=9D stuff that nobody used or liked, like SHA3 hashes for bearer tokens)

I=E2=80=99ve also updated the interactive examples on https://oauth.xyz/ =
 to match this new draft. Hopefully it=E2=80=99s =
consistent with the draft text.

I have not yet, however, updated any of the implementations of XYZ to =
take the elements of new syntax into account, so there might be some =
more changes prior to the IETF meeting as I realize what terrible =
mistakes I=E2=80=99ve made when doing that. :)=20

Feedback, as always, is welcomed, and thanks to everyone who=E2=80=99s =
provided input to the project to date.=20

 =E2=80=94 Justin=

--Apple-Mail=_0D99A97F-CBC9-4EAB-8158-4A9B3B969993
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
all,

I=E2=80=99ve =
updated the XYZ draft specification. Since the publication tools are =
currently locked prior to the upcoming virtual meeting, I have published =
it online here:

https://oauth.xyz/draft-richer-transactional-authz

This represents a =
pretty significant refactoring of the specification, hopefully to make =
the concepts and capabilities easier to understand. The core protocol is =
largely the same as before, but there are a number of serious =
updates:

 -=
 Continuation requests happen at a URL returned in the TX response. The =
=E2=80=9Chandle=E2=80=9D is still sent as one of the input values here, =
since the handle can also be used it other contexts.
 - Tokens now can include the resources they are issued =
for
 - Tokens can have an optional management =
URI for rotation and revocation.
 - =
=E2=80=9Cclaims=E2=80=9D has been removed in favor of =E2=80=9Csubject=E2=80=
=9D dealing directly with identifiers and assertions
 - the =E2=80=9Cuser=E2=80=9D request and response now =
align with identifiers and assertions
 - =
Extensions and registries are more clearly enumerated throughout the =
document
 - DID-related items have been =
excised in deference to a future possible extension
 - Added a =E2=80=9Cpushback=E2=80=9D mechanism to =
complement the =E2=80=9Ccallback=E2=80=9D mechanism
 - Simplified dynamic handle returns and access tokens =
based on developer feedback (basically we dropped a bunch of =E2=80=9Cwhat=
 if=E2=80=9D stuff that nobody used or liked, like SHA3 hashes for =
bearer tokens)

I=E2=80=99ve also updated the interactive examples on https://oauth.xyz/ to =
match this new draft. Hopefully it=E2=80=99s consistent with the draft =
text.

I have =
not yet, however, updated any of the implementations of XYZ to take the =
elements of new syntax into account, so there might be some more changes =
prior to the IETF meeting as I realize what terrible mistakes I=E2=80=99ve=
 made when doing that. :) 

Feedback, as always, is welcomed, and =
thanks to everyone who=E2=80=99s provided input to the project to =
date. 

 =E2=80=94 Justin
=

--Apple-Mail=_0D99A97F-CBC9-4EAB-8158-4A9B3B969993--


From nobody Thu Jul 16 16:57: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 A2A323A0E1A for ; Thu, 16 Jul 2020 16:57: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 Rearv5EhB-WJ for ; Thu, 16 Jul 2020 16:57:53 -0700 (PDT)
Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 A99DF3A0E19 for ; Thu, 16 Jul 2020 16:57:53 -0700 (PDT)
Received: by mail-oo1-xc35.google.com with SMTP id z23so1530669ood.8 for ; Thu, 16 Jul 2020 16:57: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=8M3bdOx08v2X/OxZAp5vRsiCZHXSiuKuXHLIH5dNLr0=; b=qzYexOS8ve5Sb1yeSCQJ29bi9VItec4ra5XFd+8YO3w36HfYqOPRJb1oiSfGXmmElP 3RPNe1tfl+zfO7W7G8OmjOdTVhHYDjC6dXQbYDwVc2AwbtMfl60dq6cwIetNmAj+yjRw aXgAK94+rdiJg/p7OEHGQqRwvri/rBwrPRZQLXg6rIvjWowIoDDzFizmqjUU5PAC/X4A rIoNtX0AjAkq1AreSurEGWi0TNkCAujHtlV5rVrNrrNqsStkIblm8aF41d/v/vZSKCsI X8e3v9DgA6gJVjtX9e7B7NrUE+i6IziRbjZd8BR6D54H62Mh049AwyrXuy6Ud2qtoquy hHDw==
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=8M3bdOx08v2X/OxZAp5vRsiCZHXSiuKuXHLIH5dNLr0=; b=Hu2X3VLlVFy3qSVhr6Lar1Zj4ybElRLV0znHDPc25cK57crsvxHRL8i/bURoTI5WXR bYKK9Tm43IbycybdTD0jAHU7piDN7OrW9UuCRjgmeHC32rp+L56SjEo1NxezbVBWSsUf rs4Oo2oCZ7ULqVG41zu7eGk4gG+2m+i+7KihTIA1jmKSfDUorjYcFkm6S305h4e5gGrq B4H73Ay7oU8U4k4wjzzqalBgWBBMTkIxaSlllrZy0roL0ivvKoDYEW91Gm6OXHtZMsaO xH6PhfCckfxY9SzteWLeeSrak1OLk4n6NOL3sblJKKDJ4EYhKric87BdIlhryKhffbkH BcCg==
X-Gm-Message-State: AOAM5328uT/72HPysew+cE+fg+quWl5ki7He2l4HCzftVbG8t1EaNn77 ChQBu2ExnB/x0DNeBHl1BWw0CGkapFxGU69pLJU=
X-Google-Smtp-Source: ABdhPJzYc2DZ8AZxLg6WQ2h4i4ML3a7H2z2WfTAPi8h/FKuctHI0btt3j/RSREaKT5OXXBxkHtVvlZzeO5oaCjLcUwY=
X-Received: by 2002:a4a:e2ca:: with SMTP id l10mr6501258oot.53.1594943871621;  Thu, 16 Jul 2020 16:57:51 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>    <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>  
In-Reply-To: 
From: Tom Jones 
Date: Thu, 16 Jul 2020 16:57:39 -0700
Message-ID: 
To: Justin Richer 
Cc: Dick Hardt , Fabien Imbault ,  Mike Varley , "txauth@ietf.org" ,  Mike Jones 
Content-Type: multipart/alternative; boundary="000000000000e7a01905aa97ce2b"
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 16 Jul 2020 23:57:57 -0000

--000000000000e7a01905aa97ce2b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I have been working on different level s of identifier, but from the mobile
app perspective. That's the hardest case as you need to boot strap trust. I
suspect that in the web site case you will need these levels. Transport,
application, real world.

If anyone wants to work on these, let me know and I'll get you the links in
Kantara.

thx ..Tom (mobile)

On Thu, Jul 16, 2020, 2:47 PM Justin Richer  wrote:

> For all of these, I still say we should have different levels of
> identifier. A =E2=80=9Cclient ID=E2=80=9D should identify the client, and=
 not be used as a
> stand-in for other things.
>
> Off the top of my head I think we might want to have identifiers,
> assertions, proofs, and other trust-binding items for:
>
>  - Organizations
>  - Devices
>  - Software applications
>  - Software instances
>  - Software versions
>
> So if we=E2=80=99re going to talk about identifying these aspects, we sho=
uld
> tackle each as its own thing and not mush it all into =E2=80=9Cclient_id=
=E2=80=9D. That
> way, hopefully, GNAP can have a much better idea what a =E2=80=9Cclient=
=E2=80=9D is than
> OAuth 2 currently does.
>
>  =E2=80=94 Justin
>
> On Jul 16, 2020, at 4:34 PM, Dick Hardt  wrote:
>
> One client identifier was a simplistic example. Org A may have numerous
> clients, perhaps in different teams, perhaps in different services, each
> with their own policy at Org B.
>
> When one of the Org A clients makes a call to the Org B AS, it needs to
> identify itself with some identifier so that Org B knows which policy to
> enforce. Why not the Client ID?
>
> I also agree with your comments that other client identification
> situations are different, and forcing the same identification model on th=
em
> does not make sense, but I fail to see the value throwing out a concept
> (client_id) that has worked well for the use cases it was designed for.
>
>
> =E1=90=A7
>
> On Thu, Jul 16, 2020 at 1:08 PM Justin Richer  wrote:
>
>> I think that the cross-organizational trust model is an interesting one,
>> and in fact it=E2=80=99s one of the things that=E2=80=99s pushed me away=
 from a client_id.
>> In the scenario that you describe, =E2=80=9Cclient_id=E2=80=9D is used t=
o represent
>> something that it was never meant to represent: the organization running
>> the software, not the software itself. It isn=E2=80=99t a client_id, and=
 while in
>> OAuth 2 the client_id could be co-opted to carry that information, it=E2=
=80=99s
>> considered bad practice to share client_ids between multiple pieces of
>> software.
>>
>> I would argue that to address this use case properly, there should be
>> another level of identifier to bridge that trust that the software can
>> present, showing that it is a part of Organization A, and not Organizati=
on
>> C. This isn=E2=80=99t a client identifier, it=E2=80=99s an organization =
identifier, and it
>> should be separate. You might want to identify both the client instance =
as
>> well as the organization it=E2=80=99s a part of, for example. This is pa=
rt of the
>> motivation behind putting =E2=80=9Corganizational data=E2=80=9D within s=
cope for the client
>> to send to the AS, after all.
>>
>> Therefore, I strongly disagree that this scenario =E2=80=9Crequires=E2=
=80=9D a client_id
>> to be solved. In fact, I think that solving this scenario with a client_=
id
>> is an anti-pattern that stems from OAuth 2=E2=80=99s over-reliance on cl=
ient_id as
>> a persistent identifier within the protocol, and we can and should do
>> better with GNAP. It=E2=80=99s very similar to Mike Jones=E2=80=99s refe=
renced federation
>> document, where the client_id is co-opted as a means of bootstrapping
>> client registration and discovery, or in the Solid Authentication
>> specification which stuffs a WebID into the client_id field.
>>
>> With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools that we h=
ad to solve our
>> problems, and come up with some very clever solutions. What I=E2=80=99m =
trying to
>> argue to this community is that we are in a position to create our own,
>> better tools.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 16, 2020, at 2:00 PM, Dick Hardt  wrote:
>>
>> Justin,
>>
>> While I agree that the assumption in OAuth 2 that all Clients have a
>> client_id is problematic, the requirement for a client_id in many use ca=
ses
>> is still there, and it does not represent a piece of software, but a
>> relationship between parties.
>>
>> Organization A writes client software that calls resources managed by th=
e
>> AS in Organization B. The client_id represents Organization A to
>> Organization B. Organization B does not care what software Organization =
A
>> is running, and there may be numerous pieces of software at Organization=
 A
>> that use the same client_id. The access granted by Organization B to
>> Organization A needs to be able to be different than the rights granted =
to
>> Organization C.
>>
>> I agree that we don't want to force all clients to have a client_id, and
>> as discussed, there are a variety of inputs for an AS to accept calls fr=
om
>> a piece of software, and often, that will be a particular *instance* of
>> the software, but we also don't want to force clients to all be treated =
the
>> same, because they are not.
>>
>>
>>
>>
>>
>>
>> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer  wrote:
>>
>>> Exactly =E2=80=94 when we start to look at it as managing the lifecycle=
 of a
>>> piece of software, instead of a registration at the AS, we can start
>>> thinking in different terms what =E2=80=9Ctrusting=E2=80=9D the client =
means in the context
>>> of what the client is doing. That trust could come from some kind of si=
gned
>>> attestation about the software (like the OAuth 2 DynReg software
>>> statement), or it could come from some externally fetchable item (like =
a
>>> Solid WebID, a DID, or the OIDC Federation extension), or it could come
>>> from someone sitting at a console and typing in information and getting
>>> back an identifier. And none of these need to pretend to be a global
>>> =E2=80=9Cclient id=E2=80=9D for it to work. The world of clients is muc=
h more diverse than
>>> OAuth 2 likes to admit, and we see that with trying to nail down a
>>> =E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=80=
=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautomatic=E2=
=80=9D vs.
>>> =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of other things.
>>>
>>> OAuth 2 only needs client IDs because the front channel needs a way to
>>> pass client identifiers when the client can=E2=80=99t authenticate itse=
lf directly.
>>> We tried to get rid of this restriction with PAR and JAR together, but
>>> there turned out to be corner cases in OAuth 2=E2=80=99s world that sti=
ll needed
>>> client_id, and implementations assumed it would be there anyway.
>>>
>>> In GNAP, we can avoid that problem from the beginning by looking at the
>>> model differently and understanding where we=E2=80=99re coming from, an=
d why.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault 
>>> wrote:
>>>
>>> +1 on that.
>>>
>>> We can then see it more as life cycle management of the client than
>>> registration per say, and this comes with many benefits compared to the
>>> current client_id.
>>>
>>> Fabien
>>>
>>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer  wrote:
>>>
>>>> I not only agree with Mike Jones that =E2=80=9Cautomatic registration=
=E2=80=9D should
>>>> be part of the process, but I would argue that that kind of model shou=
ld be
>>>> a default mode of operation. If you have an identifier that you can se=
nd to
>>>> short-circuit that, great! But we should focus on having the capabilit=
y of
>>>> inlining a lot of this information wherever possible. This is already =
the
>>>> direction that the input proposals are heading.
>>>>
>>>> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope for=
 the protocol in
>>>> general, and since both XYZ and Xauth have mechanisms that allow the c=
lient
>>>> to present a key and get back an identifier that it can use in the fut=
ure
>>>> we have something equivalent.
>>>>
>>>> But I think there=E2=80=99s a little more to it than that: Ultimately,=
 I think
>>>> we should question thinking in terms of =E2=80=9Cregistration=E2=80=9D=
, a model which has
>>>> hampered the OAuth 2 model in a lot of use cases. For example, the
>>>> federation draft Mike Jones references below hacks the =E2=80=9Cclient=
_id=E2=80=9D
>>>> parameter and makes it point to a document that the AS has to fetch. T=
his
>>>> construct is done for two reasons: (1) Oauth requires a =E2=80=9Cclien=
t_id=E2=80=9D in the
>>>> request and (2) it=E2=80=99s difficult to pass information by value to=
 the AS due
>>>> to front-channel restrictions. Since we=E2=80=99re defining a new prot=
ocol, we
>>>> don=E2=80=99t need to hack that functionality into a =E2=80=9Cclient I=
D=E2=80=9D or equivalent and
>>>> instead we can pass that information directly in the protocol. If we d=
on=E2=80=99t
>>>> assume that the client *has* to have a client ID equivalent, but it *c=
an*
>>>> have one in a set of defined circumstances, then I think we are in a m=
uch
>>>> better spot. This is the reasoning for XYZ=E2=80=99s model of having c=
lients
>>>> identified by the key, and that key can potentially be passed by a
>>>> reference identifier.
>>>>
>>>> I think all of the use cases that Mike Varley presents below are all
>>>> valid directions, with the caveat that we shouldn=E2=80=99t assume a c=
lient should
>>>> be presenting an ID at all steps. Mechanisms like software statements
>>>> should be presentable apart from a client ID, as should on-device keys=
.
>>>> We=E2=80=99re probably going to want extensions for device posture and=
 other forms
>>>> of attestation as well.
>>>>
>>>> This is one of the domains that I think we can clearly surpass OAuth
>>>> 2=E2=80=99s flexibility and capabilities if we are willing to look pas=
t OAuth 2=E2=80=99s
>>>> assumptions of what=E2=80=99s needed inline in the protocol.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Jul 14, 2020, at 1:54 PM, Mike Varley 
>>>> wrote:
>>>>
>>>> Is client registration in scope for the protocol?
>>>>
>>>> A generic way of handling clients (via ID or Handle or Key or whatever=
)
>>>> is to have processing rule on the AS such as =E2=80=9Cif the AS recogn=
izes the
>>>> client ID (and authentication of that client ID) then it may process t=
he
>>>> request on behalf of that client. If the AS does not recognize the cli=
ent
>>>> ID, it must treat this as a new client registration and evaluate any
>>>> authorization evidence the client provides before enabling the client =
and
>>>> mapping policies to that client=E2=80=9D (this means dynamic or automa=
tic clients
>>>> need to provide additional assertions / software statements whatever t=
o
>>>> register their ID.
>>>>
>>>> Something like this allows for very flexible systems:
>>>> System A can be unknown to the AS but can dynamically registered each
>>>> time with an appropriate software statement
>>>> System B can have a fairly stable client ID at the AS, but rotate that
>>>> ID every month through automatic registration (with an assertion it go=
t
>>>> from the AS during a pre-registration for example)
>>>> System C can pre-register with the AS for a client ID because it
>>>> doesn=E2=80=99t deal with software statements etc=E2=80=A6
>>>> =E2=80=A6
>>>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing cl=
ient IDs because
>>>> it will always just rely on the software statements.
>>>>
>>>> I think a client registration protocol that allows these scenarios
>>>> would be very useful in GNAP, but hopefully avoiding having to define =
what
>>>> =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
>>>>
>>>> Thanks,
>>>>
>>>> MV
>>>>
>>>> *From: *Txauth  on behalf of Mike Jones <
>>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
>>>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>>>> *To: *Dick Hardt , "txauth@ietf.org" <
>>>> txauth@ietf.org>, Justin Richer 
>>>> *Subject: *Re: [Txauth] Key handle vs client id & handle
>>>>
>>>> I agree that there are significant differences between statically and
>>>> dynamically registered clients and that=E2=80=99s appropriate to be ab=
le to
>>>> syntactically differentiate between them at runtime.  For one thing, t=
he
>>>> resource requirements at the authorization server can be very differen=
t.
>>>>
>>>> We should also be thinking about how to include what the OpenID Connec=
t
>>>> Federation spec
>>>> https://openid.net/specs/openid-connect-federation-1_0.html calls
>>>> =E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client encode=
 a registration
>>>> request reference in the client ID, so no static or dynamic registrati=
on
>>>> even occurs.  See
>>>> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.sec=
tion.9.1
>>>> 
>>>> .
>>>>
>>>>                                                        -- Mike
>>>>
>>>> *From:* Dick Hardt 
>>>> *Sent:* Friday, July 10, 2020 1:17 PM
>>>> *To:* txauth@ietf.org; Justin Richer ; Mike Jones <
>>>> Michael.Jones@microsoft.com>
>>>> *Subject:* Key handle vs client id & handle
>>>>
>>>> + Mike as he had interest in this topic
>>>>
>>>> My understanding is that an existing OAuth 2 client would use their
>>>> current client id as their key handle, and a dynamic client (one that =
was
>>>> not pre-registered) would be given a key handle by the AS.
>>>>
>>>> There are potentially some significant differences between a registere=
d
>>>> client, and a dynamic client to an AS.
>>>>
>>>> The AS is likely to know the identity of a registered client, and have
>>>> different policies between the two types of clients. For example, a
>>>> registered client may have access to a 'write" scope, while a dynamic
>>>> client does not.
>>>>
>>>> The AS may have 100s or 1000s of registered clients, but a dynamic
>>>> client may have 10Ms or 100Ms of instances, which may dictate
>>>> separate storage services. Additionally, internal to the AS, which sys=
tems
>>>> can write to the registered client store is going to be different than=
 the
>>>> dynamic client store.
>>>>
>>>> In XYZ, subsequent calls to the AS, both registered clients and dynami=
c
>>>> clients pass a key handle, so there is no easy way to differentiate be=
tween
>>>> the two.
>>>>
>>>> While the AS could embed semantics in the key handle identifier to
>>>> indicate which identifiers are pre-registered vs dynamic, there are ma=
ny
>>>> cases where the AS does need to know the difference, so making the
>>>> difference a feature of GNAP seems like a better path.
>>>>
>>>>
>>>>
>>>> This email and any attachments are for the sole use of the intended
>>>> recipients and may be privileged, confidential or otherwise exempt fro=
m
>>>> disclosure under law. Any distribution, printing or other use by anyon=
e
>>>> other than the intended recipient is prohibited. If you are not an int=
ended
>>>> recipient, please contact the sender immediately, and permanently dele=
te
>>>> this email and its attachments.
>>>>
>>>>
>>>> --
>>>> Txauth mailing list
>>>> Txauth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>
>>>
>>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000e7a01905aa97ce2b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I have been working on different level s of identifier, b=
ut from the mobile app perspective. That's the hardest case as you need=
 to boot strap trust. I suspect that in the web site case you will need the=
se levels. Transport, application, real world.

<=
div dir=3D"auto">If anyone wants to work on these, let me know and I'll=
 get you the links in Kantara.

thx ..Tom (mobile)

On Thu, Jul 16, 2020, 2:47 PM=
 Justin Richer <jricher@mit.edu&g=
t; wrote:
For all of these, I still say we sh=
ould have different levels of identifier. A =E2=80=9Cclient ID=E2=80=9D sho=
uld identify the client, and not be used as a stand-in for other things.=C2=
=A0

Off the top of my head I think we might want to have=
 identifiers, assertions, proofs, and other trust-binding items for:
<=
div>
=C2=A0- Organizations
=C2=A0- Devices
=C2=A0- Software applications
=C2=A0- Software instances
<=
div>=C2=A0- Software versions

So if we=E2=80=99re =
going to talk about identifying these aspects, we should tackle each as its=
 own thing and not mush it all into =E2=80=9Cclient_id=E2=80=9D. That way, =
hopefully, GNAP can have a much better idea what a =E2=80=9Cclient=E2=80=9D=
 is than OAuth 2 currently does.

=C2=A0=E2=80=94 J=
ustin

On Jul 16, 2020, at 4:34 P=
M, Dick Hardt <dick.hardt@gmail.com> wrote:

One client identifier was a simplistic example. Org A may have =
numerous clients, perhaps in different teams, perhaps in different services=
, each with their own policy at Org B.

When one of t=
he Org A clients makes a call to the Org B AS, it needs to identify itself =
with some identifier so that Org B knows which policy to enforce. Why not t=
he Client ID?

I also agree with your comments that=
 other client identification situations are different, and forcing the same=
 identification model on them does not make sense, but I fail=C2=A0to see t=
he value throwing out a concept (client_id) that has worked well for the us=
e cases it was designed for.=C2=A0


3D""=E1=90=A7

On Thu, Jul 16, 2020 at 1:08 PM Justin Richer <=
;jr=
icher@mit.edu> wrote:
I think that the cross-organizational trust model is an i=
nteresting one, and in fact it=E2=80=99s one of the things that=E2=80=99s p=
ushed me away from a client_id. In the scenario that you describe, =E2=80=
=9Cclient_id=E2=80=9D is used to represent something that it was never mean=
t to represent: the organization running the software, not the software its=
elf. It isn=E2=80=99t a client_id, and while in OAuth 2 the client_id could=
 be co-opted to carry that information, it=E2=80=99s considered bad practic=
e to share client_ids between multiple pieces of software.=C2=A0

I would argue that to address this use case properly, there should=
 be another level of identifier to bridge that trust that the software can =
present, showing that it is a part of Organization A, and not Organization =
C. This isn=E2=80=99t a client identifier, it=E2=80=99s an organization ide=
ntifier, and it should be separate. You might want to identify both the cli=
ent instance as well as the organization it=E2=80=99s a part of, for exampl=
e. This is part of the motivation behind putting =E2=80=9Corganizational da=
ta=E2=80=9D within scope for the client to send to the AS, after all.
=


Therefore, I strongly disagree that this scenario =E2=
=80=9Crequires=E2=80=9D a client_id to be solved. In fact, I think that sol=
ving this scenario with a client_id is an anti-pattern that stems from OAut=
h 2=E2=80=99s over-reliance on client_id as a persistent identifier within =
the protocol, and we can and should do better with GNAP. It=E2=80=99s very =
similar to Mike Jones=E2=80=99s referenced federation document, where the c=
lient_id is co-opted as a means of bootstrapping client registration and di=
scovery, or in the Solid Authentication specification which stuffs a WebID =
into the client_id field.

With OAuth 2=E2=80=99s e=
cosystem, we=E2=80=99ve used the tools that we had to solve our problems, a=
nd come up with some very clever solutions. What I=E2=80=99m trying to argu=
e to this community is that we are in a position to create our own, better =
tools.=C2=A0

=C2=A0=E2=80=94 Justin

On Jul 16, 2020, at 2:00 PM, Dick Hardt <=
dick.hardt@gmail.com> wrote:

Justin,=
=C2=A0

While I agree that the assumption in OAuth 2 that=
 all Clients have a client_id is problematic, the requirement for a client_=
id in many use cases is still there, and it does not represent a piece of s=
oftware, but a relationship between parties.

=
Organization A writes client software that calls resources managed by the A=
S in Organization B. The client_id represents Organization A to Organizatio=
n B. Organization B does not care what software Organization A is running, =
and there may be numerous=C2=A0pieces of software at Organization A that us=
e the same client_id. The access granted by Organization B to Organization =
A needs to be able to be different than the rights granted to Organization =
C.=C2=A0

I agree that we don't want to f=
orce all clients to have a client_id, and as discussed, there are a variety=
 of inputs for an AS to accept calls from a piece of software, and often, t=
hat will be a particular instance of the software, but we also don&#=
39;t want to force clients to all be treated the same, because they are not=
.=C2=A0






On Thu, Jul 16, 2020 at 8:24 AM Justin Richer <jricher@mit.edu=
> wrote:
=

Exactly =E2=80=94 when we start to look at it as managing the lifecycl=
e of a piece of software, instead of a registration at the AS, we can start=
 thinking in different terms what =E2=80=9Ctrusting=E2=80=9D the client mea=
ns in the context of what the client is doing. That trust could come from s=
ome kind of signed attestation about the software (like the OAuth 2 DynReg =
software statement), or it could come from some externally fetchable item (=
like a Solid WebID, a DID, or the OIDC Federation extension), or it could c=
ome from someone sitting at a console and typing in information and getting=
 back an identifier. And none of these need to pretend to be a global =E2=
=80=9Cclient id=E2=80=9D for it to work. The world of clients is much more =
diverse than OAuth 2 likes to admit, and we see that with trying to nail do=
wn a =E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=80=
=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautomatic=E2=
=80=9D vs. =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of other th=
ings.=C2=A0

OAuth 2 only needs client IDs because t=
he front channel needs a way to pass client identifiers when the client can=
=E2=80=99t authenticate itself directly. We tried to get rid of this restri=
ction with PAR and JAR together, but there turned out to be corner cases in=
 OAuth 2=E2=80=99s world that still needed client_id, and implementations a=
ssumed it would be there anyway.=C2=A0

In GNAP, we=
 can avoid that problem from the beginning by looking at the model differen=
tly and understanding where we=E2=80=99re coming from, and why.
<=
br>
=C2=A0=E2=80=94 Justin

=

On Jul 16, 2020, at 3:49 AM, Fabien Imbault <fabien.imbault@g=
mail.com> wrote:

+1 on that.

=

We can then see it more as life cycle management of the client t=
han registration per say, and this comes with many benefits compared to the=
 current client_id.

Fabien

On Tue, Jul 14, 20=
20 at 9:32 PM Justin Richer <jricher@mit.edu> wrote:
I not only agree with Mi=
ke Jones that =E2=80=9Cautomatic registration=E2=80=9D should be part of th=
e process, but I would argue that that kind of model should be a default mo=
de of operation. If you have an identifier that you can send to short-circu=
it that, great! But we should focus on having the capability of inlining a =
lot of this information wherever possible. This is already the direction th=
at the input proposals are heading.

So I kind-of agree t=
hat =E2=80=9Cregistration=E2=80=9D is in scope for the protocol in general,=
 and since both XYZ and Xauth have mechanisms that allow the client to pres=
ent a key and get back an identifier that it can use in the future we have =
something equivalent.=C2=A0

But I think there=E2=
=80=99s a little more to it than that: Ultimately, I think we should questi=
on thinking in terms of =E2=80=9Cregistration=E2=80=9D, a model which has h=
ampered the OAuth 2 model in a lot of use cases. For example, the federatio=
n draft Mike Jones references below hacks the =E2=80=9Cclient_id=E2=80=9D p=
arameter and makes it point to a document that the AS has to fetch. This co=
nstruct is done for two reasons: (1) Oauth requires a =E2=80=9Cclient_id=E2=
=80=9D in the request and (2) it=E2=80=99s difficult to pass information by=
 value to the AS due to front-channel restrictions. Since we=E2=80=99re def=
ining a new protocol, we don=E2=80=99t need to hack that functionality into=
 a =E2=80=9Cclient ID=E2=80=9D or equivalent and instead we can pass that i=
nformation directly in the protocol. If we don=E2=80=99t assume that the cl=
ient *has* to have a client ID equivalent, but it *can* have one in a set o=
f defined circumstances, then I think we are in a much better spot. This is=
 the reasoning for XYZ=E2=80=99s model of having clients identified by the =
key, and that key can potentially be passed by a reference identifier.

I think all of the use cases that Mike Varley presents=
 below are all valid directions, with the caveat that we shouldn=E2=80=99t =
assume a client should be presenting an ID at all steps. Mechanisms like so=
ftware statements should be presentable apart from a client ID, as should o=
n-device keys. We=E2=80=99re probably going to want extensions for device p=
osture and other forms of attestation as well.

Thi=
s is one of the domains that I think we can clearly surpass OAuth 2=E2=80=
=99s flexibility and capabilities if we are willing to look past OAuth 2=E2=
=80=99s assumptions of what=E2=80=99s needed inline in the protocol.=C2=A0<=
/div>

=C2=A0=E2=80=94 Justin

On Jul 14, 2020, at 1:54 PM, Mike Varley <=
mike.varley@securekey.com> wrote:

Is client registration in scope for the protocol?<=
/div>
=C2=A0
A generic way of handlin=
g clients (via ID or Handle or Key or whatever) is to have processing rule =
on the AS such as =E2=80=9Cif the AS recognizes the client ID (and authenti=
cation of that client ID) then it may process the request on behalf of that=
 client. If the AS does not recognize the client ID, it must treat this as =
a new client registration and evaluate any authorization evidence the clien=
t provides before enabling the client and mapping policies to that client=
=E2=80=9D (this means dynamic or automatic clients need to provide addition=
al assertions / software statements whatever to register their ID.
=C2=A0
Something like thi=
s allows for very flexible systems:
System A c=
an be unknown to the AS but can dynamically registered each time with an ap=
propriate software statement
System B can have=
 a fairly stable client ID at the AS, but rotate that ID every month throug=
h automatic registration (with an assertion it got from the AS during a pre=
-registration for example)
System C can pre-re=
gister with the AS for a client ID because it doesn=E2=80=99t deal with sof=
tware statements etc=E2=80=A6
=E2=80=A6=

And even =E2=80=98StatelessAS=E2=80=99 can operate b=
y never storing client IDs because it will always just rely on the software=
 statements.
=C2=A0
I think a client registration protocol that allows these scenarios would=
 be very useful in GNAP, but hopefully avoiding having to define what =E2=
=80=98evidence=E2=80=99 the AS needs to accept for each scenario.=

=C2=A0
Thanks,
=C2=A0
MV
=C2=A0
From:=C2=A0Txauth <txauth-bounces@ietf.org> =
on behalf of Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.=
ietf.org>
Date:=C2=A0Tuesday, July 14, 2020 a=
t 12:18 PM
To:=C2=A0Dick Hardt <dick.hardt@gmail.com>, &quo=
t;txauth@ietf.org&=
quot; <txauth@ietf.=
org>, Justin Richer <jricher@mit.edu>
Subject:=C2=A0Re: [=
Txauth] Key handle vs client id & handle
=C2=A0
I agree that there are significant differences=
 between statically and dynamically registered clients and that=E2=80=99s a=
ppropriate to be able to syntactically differentiate between them at runtim=
e.=C2=A0 For one thing, the resource requirements at the authorization serv=
er can be very different.
=C2=A0
=
We should also be thinking about how to =
include what the OpenID Connect Federation spec=C2=A0https://openid.net/specs/openid-connect-federation-1_0.html=C2=A0calls =E2=80=9CAutomatic Registration=E2=80=9D.=C2=A0 T=
his lets the client encode a registration request reference in the client I=
D, so no static or dynamic registration even occurs.=C2=A0 See=C2=A0<=
/span>https://openid.net/specs/openid-c=
onnect-federation-1_0-12.html#rfc.section.9.1.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=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:=C2=A0Dick Hardt <dick.hardt@gmail.com=
>=C2=A0
Sent:=C2=A0Friday, July 10, =
2020 1:17 PM
To:=C2=A0txauth@ietf.org; Justin Richer <jricher@mit.edu>; Mike Jones=
 <Micha=
el.Jones@microsoft.com>
Subject:=C2=A0Key han=
dle vs client id & handle
=C2=
=A0
+ Mike as he had interest in thi=
s topic
=C2=A0
My understanding is that an existing OAuth 2 client would=
 use their current client id as their key handle, and a dynamic client (one=
 that was not pre-registered) would be given a key handle by the AS.=

=C2=A0
There are potentially some significant differences between =
a registered client, and a dynamic client to an AS.
=C2=A0
T=
he AS is likely to know the identity of a registered client, and have diffe=
rent policies between the two types of clients. For example, a registered c=
lient may have access to a 'write" scope, while a dynamic client d=
oes not.
=C2=A0<=
/div>
The AS may have 100s or 1000s of registered =
clients, but a dynamic client may have 10Ms or 100Ms of instances, which ma=
y dictate separate=C2=A0storage services. Additionally, internal to the AS,=
 which systems can write to the registered=C2=A0client store is going to be=
 different than the dynamic client=C2=A0store.
=C2=A0
In XYZ=
, subsequent calls to the AS, both registered clients and dynamic clients p=
ass a key handle, so there is no easy way to differentiate between the two.=

=C2=A0
While the AS could embed semantics in the key handle=
 identifier to indicate which identifiers are pre-registered vs dynamic, th=
ere are many cases where the AS does need to know the difference, so making=
=C2=A0the difference a feature of GNAP seems like a better path.<=
/u>
=C2=A0
=C2=A0
This email and any attachments are for the sole use of the intende=
d recipients and may be privileged, confidential or otherwise exempt from d=
isclosure under law. Any distribution, printing or other use by anyone othe=
r than the intended recipient is prohibited. If you are not an intended rec=
ipient, please contact the sender immediately, and permanently delete this =
email and its attachments.

-- 

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>



--000000000000e7a01905aa97ce2b--


From nobody Fri Jul 17 09:09: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 807453A0829 for ; Fri, 17 Jul 2020 09:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.631
X-Spam-Level: 
X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, 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 Pkf8zZQVwdGh for ; Fri, 17 Jul 2020 09:09:05 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF3C43A0822 for ; Fri, 17 Jul 2020 09:09:04 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d85 with ME id 4G92230054FMSmm03G92Nn; Fri, 17 Jul 2020 18:09:02 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 17 Jul 2020 18:09:02 +0200
X-ME-IP: 86.238.65.197
To: Dick Hardt 
Cc: "txauth@ietf.org" 
References: <7c1f0439-42e4-9f7d-4dd2-e741f7cb57f2@free.fr>  <2201d382-c2f3-1496-b368-5b2caeb5eab5@free.fr> 
From: Denis 
Message-ID: <87fe40e8-7e00-3684-ce12-3ec28fd69c28@free.fr>
Date: Fri, 17 Jul 2020 18:09:00 +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="------------B4D33F1A130C7C2358C3792B"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Registered Clients and Dynamic Clients
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, 17 Jul 2020 16:09:08 -0000

This is a multi-part message in MIME format.
--------------B4D33F1A130C7C2358C3792B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Dick,

I picked three of your sentences below :

    It appears you are mixing client identifiers and user identifiers,
    as well as user authentication at a AS, and client authentication at
    an AS.
    User authentication at the AS is out of scope of GNAP as I
    understand it (there are lots of existing mechanisms that work fine).
    Client authentication to the AS is in scope.

An AS needs to authenticate users in order to relate them to their 
attributes: there is a user account at the AS for each registered user.
So user authentication is one important step in the protocol. It shall 
be handled using an asymmetric key pair.

A client is a piece of software and/or hardware trusted either by an 
application or by a user that interfaces on their behalf with ASs and RSs.

An AS usually does not handle clients accounts. It may be interesting in 
some cases to make sure, from an AS point of view, that a user is indeed
using a secure element with some specific properties. But at this time 
the wording "secure element" has not been pronounced. If we would like
to go in that direction we would need to describe APDUs (Application 
Protocol Data Units) but at this time I am not aware that the IETF has 
already
addressed such topic.

However, I got the impression that the real need is not "entity 
authentication" for the client.
Would you explain the rational for your need, instead of the solution ?

I picked another sentence:

    A challenge with FIDO is portability across devices, as a binding is
    usually tied to a specific device.

This is currently true with what the FIDO Alliance has currently 
published, but this can be solved.
Denis

> inline ...
>
> On Thu, Jul 16, 2020 at 5:37 AM Denis  > wrote:
>
>     Hi Dick,
>
>>     On Wed, Jul 15, 2020 at 10:04 AM Denis >     > wrote:
>>
>>         Hello Dick,
>>
>>         I am puzzled with the two following definitions in
>>         draft-hardt-xauth-protocol-13 :
>>
>>               *Registered Client* - a Client 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.
>>
>>         [Denis]  I interpret the last sentence in the following way:
>>         A Registered Client may be either an Application or a User.
>>                      Is it correct ?
>>
>>
>>     No. A Registered Client MAY be interacting with a User, or it MAY
>>     not. IE, a Registered Client may be a service.
>
>     It seems that what I call an Application is what you call a
>     service. Usually a service may be supported by multiple servers,
>     so I get the impression that my terminology is better suited. If
>     not, would you be able to explain ?
>
>
> A Client could be an application the User is using, or it could be a 
> service with no specific User.
>
>>         *Dynamic Client* - a Client that has not been previously
>>         registered with the GS, and each instance will generate
>>                it’s own asymmetric key pair so it can prove it is the
>>         same instance of the Client on subsequent requests. The GS
>>                MAY return a Dynamic Client a Client Handle for the
>>         Client to identify itself in subsequent requests. A single-page
>>                application with no active server component is an
>>         example of a Dynamic Client. A Dynamic Client MUST be
>>         interacting
>>                with a User.
>>
>>         [Denis] The draft does not include any other explanation for
>>         the reason to support the so-called "Dynamic Clients".
>>         While I can understand the value to use a temporary key pair
>>         for a given RS, I can't understand the value for a GS
>>                     to support unknown clients. If a GS knows nothing
>>         about a so-called "Dynamic Client", then it will not be able
>>         to deliver
>>                     any user attribute into an access token to such
>>         client.
>>
>>
>>     More of an explanation of Dynamic Clients is a good call out, thanks!
>>
>>     A Dynamic Client MUST be interacting with a User, as "trust" of
>>     the Client is done by the User.
>>     A Single Page Application (SPA) or a mobile app are examples of
>>     clients that cannot have a shared secret, but can generate and
>>     keep secure their own key pair..
>>
>>     As suggested in another thread, GNAP could support Clients that
>>     are between these two extremes.
>>     Mike called out automatic registration per OpenID Connect
>>     Federation as one example. Other options include a "software
>>     statement" passed from the Client to the GS.
>>
>>     We may want to revisit the terms "Registered Client" and "Dynamic
>>     Client" as we broaden the mechanisms for Clients to "register"
>>     with a GS, but these are the common cases today, so I picked them.
>
>     It seems that the intent is to support both a client registration
>     protocol and a client operational protocol with the GS/AS.
>
>     Client registration may be done in many ways until the user is
>     able to get a /both an identifier/ and private key
>     usable for an AS, and the AS is able to use /t//he same
>     identifier/ and the corresponding public key to authenticate the user.
>
> It appears you are mixing client identifiers and user identifiers, as 
> well as user authentication at a AS, and client authentication at an 
> AS. User authentication at the AS is out of scope of GNAP as I 
> understand it (there are lots of existing mechanisms that work fine). 
> Client authentication to the AS is in scope.
>
>     For example, draft-hardt-xauth-protocol-13 states: "The Client
>     always uses a private asymmetric key to authenticate to the GS".
>
>     This should be the start of the story with an important
>     observation: the client always uses /an identifier/, in particular
>     to allow to gracefully change that private key.
>
> The challenge is that the client needs a unique identifier for the GS, 
> which is why in both XYZ, and XAuth, the GS generates the identifier 
> for dynamic clients, and the generally also generates the identifier 
> for registered clients.
>
>     One way to register and then to authenticate to a GS may simply be
>     to use FIDO.FIDO is currently supported by many web browsers.
>
>
> Technically, the web browsers support WebAuthN. While FIDO is great 
> technology, I would see it as an authentication choice between the GS 
> and the User, and out of scope of GNAP. A challenge with FIDO is 
> portability across devices, as a binding is usually tied to a specific 
> device.
>
>
>     If/once we will be finished with the main topic, then why not
>     address client registration but there is no strong adherence with
>     our main topic.
>     Hence, client registration should not be on the list of our top
>     priorities.
>
>     If we define one /or more/ client registration schemes, then this
>     should better be in a separate and independent RFC.
>
> Maybe, maybe not.
>
> My preference is to have a larger document that covers inter-related 
> topics than a bunch of smaller documents that an implementer has to 
> bounce around between.
>
> /Dick



--------------B4D33F1A130C7C2358C3792B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Dick,

    


    

    
I picked three of your sentences below
      :

    

      

        
It appears you are mixing client identifiers and user
          identifiers, as well as user authentication at a AS, and
          client authentication at an AS. 

          User authentication at the AS is out of scope of GNAP as I
          understand it (there are lots of existing mechanisms that work
          fine). 

          Client authentication to the AS is in scope.

      

      
An AS needs to authenticate users in order to relate them to
        their attributes: there is a user account at the AS for each
        registered user.

      
So user authentication is one important step in the protocol.
        It shall be handled using an asymmetric key pair.

      


      

      
A client is a piece of software and/or hardware trusted
        either by an application or by a user that interfaces on their
        behalf with ASs and RSs.

        

        An AS usually does not handle clients accounts. It may be
        interesting in some cases to make sure, from an AS point of
        view, that a user is indeed 

        using a secure element with some specific properties. But at
        this time the wording "secure element" has not been pronounced.
        If we would like 

        to go in that direction we would need to describe APDUs
        (Application Protocol Data Units) but at this time I am not
        aware that the IETF has already 

        addressed such topic.  

      

      


      

      
However, I got the impression that the real need is not
        "entity authentication" for the client. 

        Would you explain the rational for your need, instead of the
        solution ?  

      

      


      

      
I picked another sentence:

      

        
A challenge with FIDO is portability across devices, as a
          binding is usually tied to a specific device.

      

      
This is currently true with what the FIDO Alliance has
        currently published, but this can be solved.

      

      
  

      
Denis 

      

    

    

    

      
      

        
inline ...

        

        

          
On Thu, Jul 16, 2020 at 5:37
            AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              
Hi Dick,

              


              

              

                
On Wed, Jul 15, 2020 at 10:04 AM Denis
                  <denis.ietf@free.fr>
                  wrote:

                  

                    

                      

                        
Hello
                            Dick,

                            

                            I am puzzled with the two following
                            definitions in draft-hardt-xauth-protocol-13
                            :

                          

                                *Registered Client* - a
                            Client 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.

                           

                            [Denis]  I interpret the last sentence in
                            the following way: A Registered Client may
                            be either an Application or a User. 

                                         Is it correct ?

                          

                      

                    

                    


                    

                    
No. A Registered Client MAY be interacting with
                      a User, or it MAY not. IE, a Registered Client may
                      be a service.

                  

                

              

              
It seems that what I call an
                  Application is what you call a service. Usually a
                  service may be supported by multiple servers, 

                  so I get the impression that my terminology is better
                  suited. If not, would you be able to explain ?

            

          

          


          

          
A Client could be an application the User is using, or it
            could be a service with no specific User.

          
 

          

            

              

                

                  

                    
 

                    

                      

                        
     
                            *Dynamic Client* - a Client that has not
                            been previously registered with the GS, and
                            each instance will generate 

                                   it’s own asymmetric key pair so it
                            can prove it is the same instance of the
                            Client on subsequent requests. The GS 

                                   MAY return a Dynamic Client a Client
                            Handle for the Client to identify itself in
                            subsequent requests. A single-page 

                                   application with no active server
                            component is an example of a Dynamic Client.
                            A Dynamic Client MUST be interacting 

                                   with a User.

                            

                            [Denis] The
                              draft does not include any other
                              explanation for the reason to support the
                            so-called
                                "Dynamic Clients". 

                                            While I can
                            understand the value to use a temporary key
                            pair for a given RS, I can't understand the
                            value for a GS 

                                        to support unknown clients. If a
                            GS knows nothing about a so-called "Dynamic
                            Client", then it will not be able to deliver
                            

                                        any user attribute into an
                            access token to such client.

                      

                    

                    


                    

                    
More of an explanation of Dynamic Clients is a
                      good call out, thanks!

                    


                    

                    
A Dynamic Client MUST be interacting with a
                      User, as "trust" of the Client is done by the
                      User. 

                      A Single Page Application (SPA) or a mobile app
                      are examples of clients that cannot have a shared
                      secret, but can generate and keep secure their own
                      key pair.. 

                    


                    

                    
As suggested in another thread, GNAP could
                      support Clients that are between these two
                      extremes. 

                      Mike called out automatic registration per OpenID
                      Connect Federation as one example. Other options
                      include a "software statement" passed from the
                      Client to the GS.

                    


                    

                    
We may want to revisit the terms "Registered
                      Client" and "Dynamic Client" as we broaden the
                      mechanisms for Clients to "register" with a GS,
                      but these are the common cases today, so I picked
                      them.

                  

                

              

              

                It seems that the intent is to support both a client
                registration protocol and a client operational protocol
                with the GS/AS. 

              
              
Client registration may be done in
                  many ways until the user is able to get a both an
                    identifier and private key 

                  usable for an AS, and the AS is able to use the
                    same identifier and the corresponding public key
                  to authenticate the user.

            

          

          
It appears you are mixing client identifiers and user
            identifiers, as well as user authentication at a AS, and
            client authentication at an AS. User authentication at the
            AS is out of scope of GNAP as I understand it (there are
            lots of existing mechanisms that work fine). Client
            authentication to the AS is in scope.

          


          

          
 

          

            
 For example,
                draft-hardt-xauth-protocol-13 states: "The Client always
                uses a private asymmetric key to authenticate to the
                GS".

              
              
This should be the start of the
                  story with an important observation: the client always
                  uses an identifier, in particular to allow to
                  gracefully change that private key.

            

          

          
The challenge is that the client needs a unique
            identifier for the GS, which is why in both XYZ, and XAuth,
            the GS generates the identifier for dynamic clients, and the
            generally also generates the identifier for registered
            clients.

          
 

          

            

              
One way to register and then to
                  authenticate to a GS may simply be to use FIDO. FIDO is currently supported by many web
                  browsers.

                

            

          

          


          

          
Technically, the web browsers support WebAuthN. While
            FIDO is great technology, I would see it as an
            authentication choice between the GS and the User, and out
            of scope of GNAP. A challenge with FIDO is portability
            across devices, as a binding is usually tied to a specific
            device.

          
 

          

            

              
 

                  If/once we will be finished with the main topic, then
                  why not address client registration but there is no
                  strong adherence with our main topic.

                  Hence, client registration should not be on the list
                  of our top priorities.

              

              
If we define one or more
                  client registration schemes, then this should better
                  be in a separate and independent RFC.

            

          

          
Maybe, maybe not.

          


          

          
My preference is to have a larger document that covers
            inter-related topics than a bunch of smaller documents that
            an implementer has to bounce around between. 

          


          

          
/Dick

          
 

        

      

    

    


    

  


--------------B4D33F1A130C7C2358C3792B--


From nobody Fri Jul 17 09: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 9E7513A086C for ; Fri, 17 Jul 2020 09:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.63
X-Spam-Level: 
X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, 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 r-dq61t_tRFQ for ; Fri, 17 Jul 2020 09:16:37 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1453A0863 for ; Fri, 17 Jul 2020 09:16:35 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d85 with ME id 4GGZ2300D4FMSmm03GGZ9c; Fri, 17 Jul 2020 18:16:34 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 17 Jul 2020 18:16:34 +0200
X-ME-IP: 86.238.65.197
To: Fabien Imbault 
Cc: txauth@ietf.org
References:  <382b5f57-6825-3537-c66b-fb2c38e5140c@free.fr>   
From: Denis 
Message-ID: <49ff9f53-6f75-6bd7-f09f-2ac8c2bc5ba2@free.fr>
Date: Fri, 17 Jul 2020 18:16:31 +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="------------CE31A6735C767D6FCA0FFE17"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 17 Jul 2020 16:16:41 -0000

This is a multi-part message in MIME format.
--------------CE31A6735C767D6FCA0FFE17
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Fabien,

> Thanks Denis for your answers.
>
> I think what you call delegation is a slightly different requirement 
> than how the term is generally used in our context.
> Instead of delegation, I would rather suggest to call it a "resource 
> chain" (and as in any supply chain, those could come from different 
> parties).

Whatever you call it, I believe that the model should be able to support 
it.

> I think the privacy concern is important, and it would be interesting 
> to get back to prior art on the issue.
> for instance, https://github.com/samuelgoto/WebID provides an 
> interesting analysis on RP or IdP collusion
> (here more focused on the ID part), a similar vein of work may enable 
> richer discussions whether/when the GS
> is the right place for user consent, or not.

The way and the place the user consent is captured is indeed critical.

> Then on user consent : implementations of XYZ do handle user consent. 
> In our case, we've also decoupled the consent part (as a separate 
> project).

You are using the word "we". Do you mean that you are part of the design 
team or of the implementers team of XYZ ?

> Initially we did that to simplify the implementation of the AS core 
> flow (between client and AS), while covering the UX requirements in a 
> separate project.
> But the nice thing about that is that it doesn't change the core flow, 
> and depending on the use case, one may either place it on the AS part 
> (as we've implemented so far,
> and as most people would do today) or on the client part (as you think 
> it should be). This demonstrates that depending how we assemble parts, 
> we may end up
> with a solution that may fit various requirements.

In addition to the place where the user consent is captured, there is 
the need to consider the assurances that the user can obtain about the 
respect of his choices.

I have explained that such assurance can be obtained when the choice is 
made by the client and when the returned access tokens are not 
considered to be opaque to the client.
It is also obvious that the GS/AS is kept ignorant of the proposed 
choices and is only informed about which user attributes should be 
inserted into the access token.

At this time, no equivalent explanations have been provided when/if the 
user consent interface is handled by the GS/AS.

Denis

>
> Fabien
>
> On Mon, Jul 13, 2020 at 10:40 AM Denis  > wrote:
>
>     Hi Fabien,
>
>     Thank you for your responses. Rather than responding in the text,
>     I will pick up two of your comments:
>
>         FI : as far as I'm concerned, there are many more interactions
>         than Oauth/XYZ/Xauth.
>         Your view seems to be that it is simpler because AS are way
>         less central, but it seems to me
>         that RS are much more complex to implement correctly.
>
>     In XYZ/Xauth there is a protocol needed between the GS and many
>     ROs. This protocol is "out of the scope" of these drafts and this
>     is where the complexity is hidden.
>     So it looks simpler for the client but it is much more complicated
>     for the management of the delegation at the GS. This also makes
>     the assumption that a single GS
>     will be able to handle the delegation case because all the RSs are
>     supposed to be in the same domain which is a very restrictive
>     case. My proposal is able to handle
>     the multi-domain case.
>
>     Every RS is best placed to know where to forward an operation when
>     it can't respond to it of its own. A RO should not need to inform
>     a GS to tell what its relationships
>     with other RSs are. A GS should not be in a position to know
>     everything about the relationships between RSs and to be informed
>     in real time of any change about these
>     relationships.
>
>     In term of trust, I mentioned:
>
>       * If a user has an account opened with an AS, then he trusts
>         that AS to deliver the requested and genuine attributes into
>         an access token.
>
>     This is it. There is no other trust relationship. The user does
>     not trust or rely on any collaboration between a RO and a GS.
>
>
>     A second of your comments:
>
>         FI: if we can't do it with maximum privacy, then we won't do
>         it; which is a design choice,
>
>     I would rather say: If we can do it with maximum privacy, let us
>     do it. At this time :
>
>       * in draft-hardt-xauth-protocol-12, the word "privacy" does not
>         even exist.
>       * in draft-richer-transactional-authz-06, there is a single
>         sentence in the privacy considerations section:
>
>              Handles are passed between parties and therefore should
>     be stateful and not contain any internal structure or information,
>              which could leak private data.
>
>     About the user consent. At this time :
>
>       * in draft-richer-transactional-authz-06, the user consent is
>         never addressed.
>       * in draft-hardt-xauth-protocol-12, the user consent is captured
>         by the GS whereas it should be captured by the Client.
>
>              The client has no way to verify that the user consent has
>     indeed been followed by the GS because the client
>              cannot verify that what happens "behind the scenery" at
>     the GS is conformant with what the user has consented.
>
>     Denis
>
>>     Hi Denis,
>>
>>     Thanks for your answer.
>>
>>     My comments are embedded in the text, marked with FI.
>>
>>     Fabien
>>
>>
>>     Le ven. 10 juil. 2020 à 17:53, Denis >     > a écrit :
>>
>>         Hi Fabien,
>>
>>         It would have been appreciated that you kept the original
>>         message in your response. I have copied it again at the end
>>         of this email.
>>
>>
>>     FI : sorry, not always easy on a mobile. Will make sure that's
>>     the case next time.
>>
>>
>>         Comments are between the lines.
>>
>>>         Hi Denis,
>>>
>>>         I think it's interesting, but also very different to
>>>         XYZ/XAuth so it raises many questions ;-)
>>>         The figure is impossible to read.
>>
>>         Use a PC. Copy and paste and then use the Courier font. On my
>>         PC (with the clear figure) it was perfect.
>>
>>>         So let me try to summarize the suggested approach, with a
>>>         concrete example, to make sure we understand well:
>>>
>>>         *0. The client authN to the AS (in whatever way is supported)*
>>>         Ex : client is a corporate financing called "finapp". finapp
>>>         contacts AS0 for authentication (say an openbanking service).
>>>         User is John Doe, CFO at NeedMoney Inc. (+ other identity
>>>         claims if needed, maybe some verified credential from
>>>         NeedMoney Holding that John is indeed CFO).
>>>
>>>         /Dear John, /
>>>         /to access to your finapp, please identify yourself through
>>>         your prefered openbanking account./
>>>         /Thanks/
>>
>>         If I understand you correctly,  finapp is a local application
>>         e.g. on your smartphone.
>>
>>     FI : not necessarily, the client could be a mobile app, a web
>>     app, etc., making api calls to backend protected services.
>>
>>>         *1. The client contacts a RS in a discovery phase, which
>>>         includes the selection of (at least) an operation, for which
>>>         the RS returns the required authZ attributes *
>>>         Ex : finapp needs to use NeedMoney's data to evaluate how
>>>         much credit it can offer.
>>>
>>>         Op1 : compute the credit rating, from RS1 (this is
>>>         outsourced to an external credit analyst), through the
>>>         external service's own AS1.
>>>         But to do that, RS needs your historic bank statements.
>>>         Op2 : get your list of banks, RS2 (as registered within
>>>         finapp), through openbanking AS0 and retrieve the bank
>>>         statements :
>>>         Op3a : get historic data from his main bank, RS2a (say an
>>>         international bank), through openbanking AS0
>>>         Op3b : same from a second bank account, RS2b (say a local
>>>         bank), through openbanking AS0
>>
>>         Why don't you make your very first example a little bit more
>>         complicated ? with RS1, RS2a, RS2b, ... AS0, AS1, ...
>>
>>         :-)
>>
>>     FI : fair point. But i believe it's important to grasp what it
>>     means on a realistic example, especially as the proposed protocol
>>     would be very much dependant on the way RS calls are made.
>>
>>
>>         The intent of the /first /email was to discuss a /basic
>>         /model and to place the highlights on the way to capture the
>>         *user's consent*
>>         in an interoperable manner without letting know to any RS or
>>         AS the choices of the user. This is a fundamental feature of
>>         the model.
>>         In XAuth, the user's consent is not formalized in the
>>         protocol : "User consent is /often /required at the GS".
>>
>>     FI : in the context of xauth, this seems pretty clear I think.
>>
>>>         *2. User consent *
>>>         RS1 aggregates the list of attributes required (from all RS)
>>>         and sends it to finapp.
>>>         /Dear John, /
>>>         /To evaluate your credit request, we need the following
>>>         information: /
>>>         /- your list of bank accounts (retrieved from your finapp
>>>         account)/
>>>         /- the associated banking statements over the past 12 months
>>>         (from each bank)/
>>>         /- we'll pass that data to the credit agency, which will
>>>         return your credit score /
>>>         /Do you agree ?/
>>>
>>>         John approves (or not..., maybe he'll agree only for one
>>>         specific bank), via finapp directly
>>>         (I like that, albeit in a more traditional flow, I'm also
>>>         separating the UI from the rest of the protocol of XYZ, and
>>>         it works too).
>>
>>         As described, the user could simply push to the RS the
>>         banking statements over the past 12 months (from each bank).
>>         The user consent is not about : "/Do you agree that/ /we pass
>>         the data to the credit agency, which will return your credit
>>         score"
>>         /since no attributes nor ASs are involved in the question.
>>
>>     FI : this is possible of course, but pretty surprising. Today
>>     most implementations are using oauth to delegate the
>>     implementation to some specialized component, while here each RS
>>     would be responsible for authentication. That is not an innocent
>>     choice from an implementation and deployment perspective.
>>
>>         /
>>         /
>>
>>         I guess you want the user to get access tokens targeted for
>>         RS2x so that each bank will accept to disclose his banking
>>         statements over the past 12 months.
>>
>>         The consent is whether the user accepts to get access tokens
>>         from some of his banks targeted for RS2x for the following
>>         operation:
>>         "Retrieval of the past 12 months banking statements" which
>>         corresponds to an API for each bank and then to send these
>>         access tokens to RS1.
>>
>>         In practice, the client (e.g. using FIDO) will connect
>>         transparently to each of the appropriate AS from the banks
>>         and will get the requested access tokens
>>         with a requested validity period of about 5 minutes.
>>
>>     FI : yes.
>>
>>>         *3. Requests to the protected resources *
>>>         The client gets the access tokens and uses the services for
>>>         which access was granted.
>>>
>>>         *Analysis: (maybe I didn't get everything right, if so let
>>>         me know) *
>>>         The trust model is focused around the relationship between
>>>         the enduser (John) and his application (finapp), which seems
>>>         fine.
>>
>>         No. The trust model is not making a focus on that specific
>>         relationship. BTW, no access token is necessarily needed by
>>         the user to be able to use finapp.
>>
>>     FI : maybe, maybe not. As soon as I want to fetch api calls, I
>>     need access tokens.
>>
>>>         => I see some potential issues :
>>>
>>>         a. it will be really difficult for an end user to understand
>>>         what AS0 and AS1 are, why they're different, and why he
>>>         needs to authenticate to each of them.
>>>         How do you enable a federated experience? (especially as
>>>         there could be many)
>>
>>         I fear that you have not fully captured what the user consent
>>         is about. See the above explanations. In addition, there is
>>         no concept of federation.
>>
>>     FI : your notion of consent is very specific to what you have in
>>     mind. It would require a kind of automated system to work.
>>     As for the concept of federation, this is required in practice in
>>     you don't hypothesize a dependancy on FIDO. The Uma2 standard is
>>     probably the closest to some of your ideas and focuses a lot on
>>     federation.
>>
>>>         b. deciding what is the main RS (here RS1) to be called by
>>>         the client seems very critical, as it is the one that needs
>>>         to orchestrate everything.
>>>         This seems a very hierarchical and imperative model which
>>>         seems somewhat counter intuitive in terms of developer
>>>         experience (as least
>>>         as it is made today, we clearly don't go into so much
>>>         details). The call hierarchy may quickly become very
>>>         complex, which may also become
>>>         a problem when separate services evolve.
>>
>>         The client calls the main RS (here RS1). What may happen next
>>         is fully dependant upon the operation that the user is
>>         willing to perform and
>>         this is unpredictable (since the back end service may change
>>         at any point of time).
>>
>>     FI : OK, but is it good engineering practice to have to deal with
>>     the internals of service calls? The reason why people delegate
>>     APIs is precisely to avoid that complexity. Today with OAuth, and
>>     tomorrow with XYZ/Xauth, the programming model is way simpler.
>>     Privacy may be a good reason to change that, but we need to be
>>     very thoughtful about that.
>>
>>>         c. RS1 gets all the information required to access all
>>>         sub-resources, and therefore gets also a lot of
>>>         responsibility (and power). But from finapp's
>>>         point of view, it is the one that has the relationship with
>>>         the user and is providing the core value proposition, while
>>>         RS1 is just an external service.
>>
>>          So is it really a problem ?
>>
>>     FI : I think so. If I'm finapp, I don't want to be this dependant
>>     on RS1 for a lot of good and bad reasons. What I hope the example
>>     conveys is that there's no reason why RS1 would suddenly become
>>     the center of orchestration for all queries, while all the
>>     underlying data is actually elsewhere.
>>     The fact that the proposed protocol mandates this behaviour is
>>     surprising and I don't see why that is.
>>
>>>         d. multi-user (common B2B scenario): John wants to authorize
>>>         a read access to his finapp account to his external auditor,
>>>         Ann (who is not a direct user
>>>         of finapp herself, but might already be registered by
>>>         openbanking AS0). How do you do that? Does it require the
>>>         access token itself to be able to delegate rights?
>>
>>         The intent of the short description I sent was to describe
>>         two simple scenarios, so that we could start discussing about
>>         them.
>>         At this point, the intent is not to cover all the scenarios
>>         you may dream of.
>>
>>     FI : fair point. However, as previously discussed, this is a big
>>     concern as we don't know whether you think this is a valid use
>>     case or whether this is out of scope (so far, I understood it was
>>     more, if we can't do it with maximum privacy, then we won't do
>>     it; which is a design choice, but standards are usually about
>>     consensus with people that need to deal with real life problems).
>>
>>>         e. more generally, a threat model would be required, as
>>>         there are many more interactions now.
>>
>>         There are less interactions than in XAuth: there is no
>>         protocol between ASs and RSs, nor between ROs and ASs.
>>
>>     FI : as far as I'm concerned, there are many more interactions
>>     than Oauth/XYZ/Xauth. Your view seems to be that it is simpler
>>     because AS are way less central, but it seems to me that RS are
>>     much more complex to implement correctly.
>>
>>
>>         Before a threat model, a trust model is needed. Do we have a
>>         trust model for XAuth ?
>>         Unfortunately not, since the word "trust" is absent in the
>>         main body of draft-hardt-xauth-protocol-12.
>>
>>     FI : sorry but I don't need the word trust to do threat modeling...
>>
>>         In this model, the trust relationships are as follows:
>>
>>           * The user trusts its client.
>>           * If a user has an account opened with an AS, then he
>>             trusts that AS to deliver the requested and genuine
>>             attributes into an access token.
>>           * A RS may trust one or more ASs for one or more types of
>>             attributes _and_ for performing a given operation.
>>           * A RS may be administered remotely by one or more RO.
>>
>>         _Note_: for authentication, a RS may accept either FIDO or
>>         one or more types of attributes from one or more ASs.
>>
>>         Denis
>>
>>>         Cheers,
>>>         Fabien
>>>
>>
>>         This is a new thread.
>>
>>
>>         Preamble: This model is quite different from the XAuth model.
>>         In particular, a RO has no relationship with any AS and a
>>         Client does not need to be associated with any AS prior to
>>         any access to a RS.
>>
>>         A key point of this model is that the user's consent is
>>         handled locally by the Client and hence no AS nor RS is
>>         handling a man machine interface
>>         for the user consent. This allows to support locally the user
>>         consent for multiple ASs while keeping all ASs ignorant about
>>         the choices of the user
>>         made for accessing a particular RS.
>>         *
>>
>>         **+--------++------------+
>>         |User||Resource|
>>         ||| Owner (RO) |
>>         +--------++------------+
>>         |\|
>>         |\|
>>         |\|
>>         |\|
>>         +-----------++---------------++------------+
>>         ||---->| Authorization |||
>>         || (2) |Server (AS)|||
>>         ||<----||||
>>         |Client|+---------------+||
>>         ||-------------------------->|Resource|
>>         |User|(1)|Server|
>>         |Consent|<--------------------------|(RS)|
>>         |element|||
>>         ||-------------------------->||------>
>>         ||(3)||(4)
>>         ||<--------------------------||<------
>>         +-----------++------------+
>>         *
>>         The flow of operations is as follows:
>>
>>         The Client (which may have been previously authenticated
>>         using FIDO) contacts the RS and after some dialogue with the
>>         RS selects an operation
>>         that it wants to perform on the RS (1a). Note that it may
>>         also indicate directly the operation that it wants to perform
>>         on the RS without any prior dialogue.
>>         In return (1b), the RS informs the Client about which
>>         attributes are needed by the RS for performing the requested
>>         operation and from which Attributes Servers
>>         they may be obtained.
>>
>>         This information is specifically marked to indicate that it
>>         shall be handled by the "User Consent element" from the Client.
>>         The presentation of that information is up to the man machine
>>         interface supported by the "User Consent element" from the
>>         Client.
>>
>>         The user can see which attributes are requested by the RS for
>>         performing the requested operation and, if it consents, the
>>         Client contacts one or more
>>         appropriate Authorization Servers (2a). The user consent is
>>         hence captured locally by the Client (i.e. there is no
>>         dialogue with any AS nor any RS).
>>
>>         When the Client got the access tokens from these
>>         authorization servers (2b), it sends all of them in a single
>>         request to the RS (3a).
>>
>>         End of the story for a simple access
>>
>>
>>         Start of a subsequent story for a delegation case
>>
>>         Let us now suppose that the RS is unable to fulfil the
>>         request by its own and that it needs to contact another RS.
>>         RS1 contacts RS2 (4a) and indicates the operation
>>         that it wants to perform on RS2 (that operation may not be
>>         the same as the original operation). In return (4b), RS2
>>         informs RS1 about which attributes are needed
>>         by RS2 for performing the requested operation and from which
>>         Attributes Servers they may be obtained. RS1 forwards that
>>         information to the Client.
>>
>>         This information is marked to indicate that it shall be
>>         handled by the "User Consent element" from the Client. The
>>         presentation of that information is up to the man machine
>>         interface from the Client. The user can see which attributes
>>         are requested by RS2 for performing the new requested
>>         operation and, if it consents, the Client contacts one or more
>>         appropriate Authorization Servers. The user consent is hence
>>         captured locally by the "User Consent element" from the
>>         Client. (i.e. there is no dialogue with any AS, nor RS1, nor
>>         RS2).
>>
>>         When the Client got the access token(s) from the
>>         authorization server(s), it sends all of them in a single
>>         request to RS1. RS1 then forwards the additional access
>>         token(s) to RS2.
>>
>>
>>         Some observations:
>>
>>         The user nor the Client are linked with any particular AS. A
>>         user may use today an AS of the Bank of America and may
>>         change tomorrow to the Bank of Missouri.
>>         As soon as he will be registered with the Bank of Missouri,
>>         he will be able to get access tokens from the AS of the Bank
>>         of Missouri. The AS of Bank of America
>>         has not been able to know where its access tokens have been
>>         used. This will be the same for AS of the Bank of Missouri.
>>         There is no need for any direct dialogue
>>         between any AS and any RS at the time a client is making an
>>         access. There is no need for any RO to contact any AS.
>>
>>         This model has been constructed following a "Privacy by
>>         Design" approach.
>>
>>         Denis
>>
>
>     -- 
>     Txauth mailing list
>     Txauth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/txauth
>


--------------CE31A6735C767D6FCA0FFE17
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Fabien,

    


    

    

      
      

        
Thanks Denis for your answers.
          


          

          
I think what you call delegation is a slightly different
            requirement than how the term is generally used in our
            context.

          

          
Instead of delegation, I would rather suggest to call it
            a "resource chain" (and as in any supply chain, those could
            come from different parties).

        

      

    

    
Whatever you call it, I believe that the model should be able to
      support it. 

    

    

      

        

          
I think the privacy concern is important, and it would be
            interesting to get back to prior art on the issue.

          
for instance, https://github.com/samuelgoto/WebID provides
            an interesting analysis on RP or IdP collusion 

            (here more focused on the ID part), a similar vein of work
            may enable richer discussions whether/when the GS 

            is the right place for user consent, or not. 

          

        

      

    

    
The way and the place the user consent is captured is indeed
      critical. 

    

    

      

        

          
Then on user consent : implementations of XYZ do handle
            user consent. In our case, we've also decoupled the consent
            part (as a separate project). 

          

        

      

    

    
You are using the word "we". Do you mean that you are part of the
      design team or of the implementers team of XYZ ?

    

      

        

          
Initially we did that to simplify the implementation of
            the AS core flow (between client and AS), while covering the
            UX requirements in a separate project. 

          
But the nice thing about that is that it doesn't change
            the core flow, and depending on the use case, one may either
            place it on the AS part (as we've implemented so far, 

            and as most people would do today) or on the client part (as
            you think it should be). This demonstrates that depending
            how we assemble parts, we may end up 

            with a solution that may fit various requirements.

        

      

    

    
In addition to the place where the user consent is captured,
      there is the need to consider the assurances that the user can
      obtain about the respect of his choices.

      

      I have explained that such assurance can be obtained when the
      choice is made by the client and when the returned access tokens
      are not considered to be opaque to the client.

      It is also obvious that the GS/AS is kept ignorant of the proposed
      choices and is only informed about which user attributes should be
      inserted into the access token.

      

      At this time, no equivalent explanations have been provided
      when/if the user consent interface is handled by the GS/AS.

    
Denis

    

      

        

          


          

          
Fabien

        

        

        

          
On Mon, Jul 13, 2020 at
            10:40 AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              
Hi Fabien,

              


              

              
Thank you for your responses. Rather than responding
                in the text, I will pick up two of your comments:

              

                
FI : as far as I'm concerned, there are many more
                  interactions than Oauth/XYZ/Xauth. 

                  Your view seems to be that it is simpler because AS
                  are way less central, but it seems to me 

                  that RS are much more complex to implement correctly.
                  

                

              

              
In XYZ/Xauth there is a protocol needed between the
                GS and many ROs. This protocol is "out of the scope" of
                these drafts and this is where the complexity is hidden.
                

                So it looks simpler for the client but it is much more
                complicated for the management of the delegation at the
                GS. This also makes the assumption that a single GS 

                will be able to handle the delegation case because all
                the RSs are supposed to be in the same domain which is a
                very restrictive case. My proposal is able to handle 

                the multi-domain case.

              

              


              

              
Every RS is best placed to know where to forward an
                operation when it can't respond to it of its own. A RO
                should not need to inform a GS to tell what its
                relationships 

                with other RSs are. A GS should not be in a position to
                know everything about the relationships between RSs and
                to be informed in real time of any change about these

                relationships.

              


              

              
In term of trust, I mentioned:

              

                
    
                  
  • If a user has an account opened with an AS, then
                    he trusts that AS to deliver the requested and
                    genuine attributes into an access token.
    • 
                

              

              
This is it. There is no other trust relationship. The
                user does not trust or rely on any collaboration between
                a RO and a GS.

              
 

              

              


              

              
A second of your comments:

              

                
FI: if we can't do it with maximum privacy, then we
                  won't do it; which is a design choice,

              

              
I would rather say: If we can do it with maximum
                privacy, let us do it. At this time :

              
    
                
  • in draft-hardt-xauth-protocol-12, the word "privacy"
                  does not even exist.
    • 
                
  • in draft-richer-transactional-authz-06, there is a
                  single sentence in the privacy considerations section:
    • 
              

              
         Handles are passed between parties and
                therefore should be stateful and not contain any
                internal structure or information, 

                         which could leak private data.

              
About the user consent. At this time :

              
    
                
  • in draft-richer-transactional-authz-06, the user
                  consent is never addressed.
    • 
                
  • in draft-hardt-xauth-protocol-12, the user consent
                  is captured by the GS whereas it should be captured by
                  the Client.
    
                
    • 
              

              
         The client has no way to verify that the user
                consent has indeed been followed by the GS because the
                client 

                         cannot verify that what happens "behind the
                scenery" at the GS is conformant with what the user has
                consented.

              
 Denis

              

              

                

                  
Hi Denis,
                    


                    

                    
Thanks for your answer. 

                    


                    

                    
My comments are embedded in the
                      text, marked with FI. 

                    


                    

                    
Fabien 

                    

                    

                    

                      
Le ven. 10 juil.
                        2020 à 17:53, Denis <denis.ietf@free.fr>
                        a écrit :

                      

                      

                        

                          
Hi Fabien,

                          


                          

                          
It would have been appreciated that you
                            kept the original message in your response.
                            I have copied it again at the end of this
                            email.

                          

                        

                      

                    

                  

                  


                  

                  
FI : sorry, not always easy on a
                    mobile. Will make sure that's the case next time. 

                  

                    

                      

                        

                          
 

                          


                          

                          
Comments are between the lines.

                          


                          

                          

                            
Hi Denis, 
                              


                              

                              
I think it's interesting, but also
                                very different to XYZ/XAuth so it raises
                                many questions ;-)

                              
The figure is impossible to read.

                            

                          

                          
Use a PC. Copy and paste and then use the
                            Courier font. On my PC (with the clear
                            figure) it was perfect.

                          

                            

                              
So let me try to summarize the
                                suggested approach, with a concrete
                                example, to make sure we understand
                                well:

                              


                              

                              
0. The client authN to the AS (in
                                  whatever way is supported)

                              
Ex : client is a corporate financing
                                called "finapp". finapp contacts AS0 for
                                authentication (say an openbanking
                                service).  

                              
User is John Doe, CFO at NeedMoney
                                Inc. (+ other identity claims if needed,
                                maybe some verified credential from
                                NeedMoney Holding that John is indeed
                                CFO).

                              


                              

                              
Dear John, 

                              
to access to your finapp, please
                                  identify yourself through your
                                  prefered openbanking account.

                              
Thanks

                            

                          

                          
If I understand you correctly,  finapp is a
                            local application e.g. on your smartphone.

                          

                        

                      

                    

                  

                  
FI : not necessarily, the client could
                    be a mobile app, a web app, etc., making api calls
                    to backend protected services. 

                  

                    

                      

                        

                          
 

                          

                            
1. The client contacts a
                                RS in a discovery phase, which includes
                                the selection of (at least) an
                                operation, for which the RS returns the
                                required authZ attributes 
                              
Ex : finapp needs to use NeedMoney's
                                data to evaluate how much credit it can
                                offer.

                              


                              

                              
Op1 : compute the credit rating, from
                                RS1 (this is outsourced to an external
                                credit analyst), through the external
                                service's own AS1.

                              

                              
But to do that, RS needs your
                                historic bank statements.

                              
Op2 : get your list of banks, RS2 (as
                                registered within finapp),
                                through openbanking AS0 and retrieve the
                                bank statements : 

                              
Op3a : get historic data from his
                                main bank, RS2a (say an international
                                bank), through openbanking AS0

                              
Op3b : same from a second bank
                                account, RS2b (say a local bank),
                                through openbanking AS0

                            

                          

                          
Why don't you make your very first example
                            a little bit more complicated ? with RS1,
                            RS2a, RS2b, ... AS0, AS1, ... 

                          

                          
:-)

                          

                        

                      

                    

                  

                  
FI : fair point. But i believe it's
                    important to grasp what it means on a realistic
                    example, especially as the proposed protocol would
                    be very much dependant on the way RS calls are
                    made. 

                  

                    

                      

                        

                          


                            The intent of the first email was
                            to discuss a basic model and to
                            place the highlights on the way to capture
                            the user's consent 

                            in an interoperable manner without letting
                            know to any RS or AS the choices of the
                            user. This is a fundamental feature of the
                            model.

                            In XAuth, the user's consent is not
                            formalized in the protocol : "User consent
                            is often required at the GS".

                          

                        

                      

                    

                  

                  
FI : in the context of xauth, this
                    seems pretty clear I think. 

                  

                    

                      

                        

                          
 

                          

                            

                              
2. User consent 

                              
RS1 aggregates the list of attributes
                                required (from all RS) and sends it to
                                finapp.

                            

                          

                          

                            

                              
Dear John, 

                              
To evaluate your credit request,
                                  we need the following information: 

                              
- your list of bank accounts
                                  (retrieved from your finapp account)

                              
- the associated banking
                                  statements over the past 12 months
                                  (from each bank)

                              
- we'll pass that data to the
                                  credit agency, which will return your
                                  credit score 

                              
Do you agree ?

                              


                              

                              
John approves (or not..., maybe he'll
                                agree only for one specific bank), via
                                finapp directly 

                                (I like that, albeit in a more
                                traditional flow, I'm also separating
                                the UI from the rest of the protocol of
                                XYZ, and it works too).

                            

                          

                          
As described, the user could simply push to
                            the RS the banking statements over the past
                            12 months (from each bank).

                            The user consent is not about : "Do you
                              agree that  we pass the data to
                              the credit agency, which will return your
                              credit score"

                            since no attributes nor ASs are involved
                            in the question.

                        

                      

                    

                  

                  
FI : this is possible of course, but
                    pretty surprising. Today most implementations are
                    using oauth to delegate the implementation to some
                    specialized component, while here each RS would be
                    responsible for authentication. That is not an
                    innocent choice from an implementation and
                    deployment perspective. 

                  

                    

                      

                        

                          


                            

                          
I guess you want the user to get access
                            tokens targeted for RS2x so that each bank
                            will accept to disclose his banking
                            statements over the past 12 months.

                          
The consent is whether the user accepts to
                            get access tokens from some of his banks
                            targeted for RS2x for the following
                            operation: 

                            "Retrieval of the past 12 months banking
                            statements" which corresponds to an API for
                            each bank and then to send these access
                            tokens to RS1.

                          
In practice, the client (e.g. using FIDO)
                            will connect transparently to each of the
                            appropriate AS from the banks and will get
                            the requested access tokens 

                            with a requested validity period of about 5
                            minutes.

                        

                      

                    

                  

                  
FI : yes. 

                  

                    

                      

                        

                          

                            

                              
3. Requests to the protected
                                  resources 

                              
The client gets the access tokens and
                                uses the services for which access was
                                granted.

                              


                              

                              
Analysis: (maybe I didn't get
                                  everything right, if so let me know) 

                              
The trust model is focused around the
                                relationship between the enduser (John)
                                and his application (finapp), which
                                seems fine.

                            

                          

                          
No. The trust model is not making a focus
                            on that specific relationship. BTW, no
                            access token is necessarily needed by the
                            user to be able to use finapp.

                          

                        

                      

                    

                  

                  
FI : maybe, maybe not. As soon as I
                    want to fetch api calls, I need access tokens. 

                  

                    

                      

                        

                          
 

                          

                            
=> I see some potential
                              issues : 
                              


                              

                              
a. it will be really difficult for an
                                end user to understand what AS0 and AS1
                                are, why they're different, and why he
                                needs to authenticate to each of them. 

                                How do you enable a federated
                                experience? (especially as there could
                                be many)

                            

                          

                          
I fear that you have not fully captured
                            what the user consent is about. See the
                            above explanations. In addition, there is no
                            concept of federation. 

                          

                        

                      

                    

                  

                  
FI : your notion of consent is very
                    specific to what you have in mind. It would require
                    a kind of automated system to work. 

                  
As for the concept of federation, this
                    is required in practice in you don't hypothesize a
                    dependancy on FIDO. The Uma2 standard is probably
                    the closest to some of your ideas and focuses a lot
                    on federation. 

                  

                    

                      

                        

                          
 

                          

                            

                              
b. deciding what is the main RS (here
                                RS1) to be called by the client seems
                                very critical, as it is the one that
                                needs to orchestrate everything. 

                                This seems a very hierarchical and
                                imperative model which seems somewhat
                                counter intuitive in terms of developer
                                experience (as least 

                                as it is made today, we clearly don't go
                                into so much details). The call
                                hierarchy may quickly become very
                                complex, which may also become 

                                a problem when separate services evolve.

                            

                          

                          
The client calls the main RS (here RS1).
                            What may happen next is fully dependant upon
                            the operation that the user is willing to
                            perform and 

                            this is unpredictable (since the back end
                            service may change at any point of time).

                        

                      

                    

                  

                  
FI : OK, but is it good engineering
                    practice to have to deal with the internals of
                    service calls? The reason why people delegate APIs
                    is precisely to avoid that complexity. Today with
                    OAuth, and tomorrow with XYZ/Xauth, the programming
                    model is way simpler. Privacy may be a good reason
                    to change that, but we need to be very thoughtful
                    about that. 

                  

                    

                      

                        

                          

                            

                              
c. RS1 gets all the information
                                required to access all sub-resources,
                                and therefore gets also a lot of
                                responsibility (and power). But from
                                finapp's 

                                point of view, it is the one that has
                                the relationship with the user and is
                                providing the core value proposition,
                                while RS1 is just an external service.

                            

                          

                          
 So is it really a problem ? 

                          

                        

                      

                    

                  

                  
FI : I think so. If I'm finapp, I
                    don't want to be this dependant on RS1 for a lot of
                    good and bad reasons. What I hope the example
                    conveys is that there's no reason why RS1 would
                    suddenly become the center of orchestration for all
                    queries, while all the underlying data is actually
                    elsewhere. 

                  
The fact that the proposed protocol
                    mandates this behaviour is surprising and I don't
                    see why that is. 

                  

                    

                      

                        

                          
 

                          

                            

                              
d. multi-user (common B2B scenario):
                                John wants to authorize a read access to
                                his finapp account to his external
                                auditor, Ann (who is not a direct user 

                                of finapp herself, but might already be
                                registered by openbanking AS0). How do
                                you do that? Does it require the access
                                token itself to be able to delegate
                                rights?

                            

                          

                          
The intent of the short description I sent
                            was to describe two simple scenarios, so
                            that we could start discussing about them.

                            At this point, the intent is not to cover
                            all the scenarios you may dream of.

                        

                      

                    

                  

                  
FI : fair point. However, as
                    previously discussed, this is a big concern as we
                    don't know whether you think this is a valid use
                    case or whether this is out of scope (so far, I
                    understood it was more, if we can't do it with
                    maximum privacy, then we won't do it; which is a
                    design choice, but standards are usually about
                    consensus with people that need to deal with real
                    life problems). 

                  

                    

                      

                        

                          

                            

                              
e. more generally, a threat model
                                would be required, as there are many
                                more interactions now.

                            

                          

                          
There are less interactions than in XAuth:
                            there is no protocol between ASs and RSs,
                            nor between ROs and ASs.

                          

                        

                      

                    

                  

                  
FI : as far as I'm concerned, there
                    are many more interactions than Oauth/XYZ/Xauth.
                    Your view seems to be that it is simpler because AS
                    are way less central, but it seems to me that RS are
                    much more complex to implement correctly. 

                  

                    

                      

                        

                          
 

                            Before a threat model, a trust model is
                            needed. Do we have a trust model for XAuth ?
                            

                            Unfortunately not, since the word "trust" is
                            absent in the main body of
                            draft-hardt-xauth-protocol-12.

                        

                      

                    

                  

                  
FI : sorry but I don't need the word
                    trust to do threat modeling... 

                  

                    

                      

                        

                          
In this model, the trust relationships are
                            as follows:

                          
    
                            
  • The user trusts its client.
    • 
                            
  • If a user has an account opened with an
                              AS, then he trusts that AS to deliver the
                              requested and genuine attributes into an
                              access token.
    • 
                            
  • A RS may trust one or more ASs for one
                              or more types of attributes and
                              for performing a given operation.
    • 
                            
  • A RS may be administered remotely by one
                              or more RO.
    
                            
    • 
                          

                          
Note: for authentication, a RS may
                            accept either FIDO or one or more types of
                            attributes from one or more ASs. 

                        

                      

                    

                  

                  

                    

                      

                        

                          
 

                          
Denis

                          

                            

                              
Cheers, 

                              
Fabien

                              

                            

                            

                          

                          

                            This is a new thread.

                          
                          

                            
 

                                Preamble: This model is quite different
                                from the XAuth model. 

                                In particular, a RO has no relationship
                                with any AS and a Client does not need
                                to be associated with any AS prior to
                                any access to a RS.

                                

                                A key point of this model is that the
                                user's consent is handled locally by the
                                Client and hence no AS nor RS is
                                handling a man machine interface 

                                for the user consent. This allows to
                                support locally the user consent for
                                multiple ASs while keeping all ASs
                                ignorant about the choices of the user 

                                made for accessing a particular RS.

                                

                                  

                                         +--------+                          
                                    +------------+

                                           |  User 
                                    |                          
                                    |  Resource 
                                    |

                                           |       
                                    |                          
                                    | Owner (RO) |

                                           +--------+        
                                                      +------------+

                                               |     
                                    \                             
                                    |

                                               |      
                                    \                            
                                    |

                                               |       
                                    \                           
                                    |

                                               |        
                                    \                          
                                    |

                                        +-----------+ 
                                       +---------------+    
                                    +------------+

                                        |          
                                    |---->| Authorization |    
                                    |            |

                                        |          
                                    | (2) |  Server
                                    (AS)  |     |           
                                    |

                                        |          
                                    |<----|              
                                    |     |           
                                    |

                                        |  Client  
                                    |     +---------------+    
                                    |            |

                                        |          
                                    |-------------------------->| 
                                    Resource  |

                                        |   User   
                                    |           (1)            
                                    |   Server  
                                    |

                                        |  Consent 
                                    |<--------------------------|   
                                    (RS)    |

                                        |  element 
                                    |                          
                                    |            |

                                        |          
                                    |-------------------------->|           
                                    |------>

                                        |          
                                    |           (3)            
                                    |            | 
                                    (4)

                                        |          
                                    |<--------------------------|           
                                    |<------

                                        +-----------+                          
                                    +------------+

                                

                                The flow of operations is as follows:

                                

                                The Client (which may have been
                                previously authenticated using FIDO)
                                contacts the RS and after some dialogue
                                with the RS selects an operation 

                                that it wants to perform on the RS (1a).
                                Note that it may also indicate directly
                                the operation that it wants to perform
                                on the RS without any prior dialogue. 

                                In return (1b), the RS informs the
                                Client about which attributes are needed
                                by the RS for performing the requested
                                operation and from which Attributes
                                Servers 

                                they may be obtained. 

                                

                                This information is specifically marked
                                to indicate that it shall be handled by
                                the "User Consent element" from the
                                Client. 

                                The presentation of that information is
                                up to the man machine interface
                                supported by the "User Consent element"
                                from the Client. 

                                

                                The user can see which attributes are
                                requested by the RS for performing the
                                requested operation and, if it consents,
                                the Client contacts one or more 

                                appropriate Authorization Servers (2a).
                                The user consent is hence captured
                                locally by the Client (i.e. there is no
                                dialogue with any AS nor any RS).

                                

                                When the Client got the access tokens
                                from these authorization servers (2b),
                                it sends all of them in a single request
                                to the RS (3a).

                                

                                End of the story for a simple access

                            
 

                                Start of a subsequent story for a
                                delegation case

                                

                                Let us now suppose that the RS is unable
                                to fulfil the request by its own and
                                that it needs to contact another RS. RS1
                                contacts RS2 (4a) and
                                indicates the operation 

                                that it wants to perform on RS2 (that
                                operation may not be the same as the
                                original operation). In return (4b), RS2
                                informs RS1 about which attributes are
                                needed 

                                by RS2 for performing the requested
                                operation and from which Attributes
                                Servers they may be obtained. RS1
                                forwards that information to the Client.
                                

                                

                                This information is marked to indicate
                                that it shall be handled by the "User
                                Consent element" from the Client. The
                                presentation of that information is up
                                to the man machine 

                                interface from the Client. The user can
                                see which attributes are requested by
                                RS2 for performing the new requested
                                operation and, if it consents, the
                                Client contacts one or more 

                                appropriate Authorization Servers. The
                                user consent is hence captured locally
                                by the "User Consent element" from the
                                Client. (i.e. there is no dialogue with
                                any AS, nor RS1, nor RS2). 

                                

                                When the Client got the access token(s)
                                from the authorization server(s), it
                                sends all of them in a single request to
                                RS1. RS1 then forwards the additional
                                access token(s) to RS2.

                                

                                

                                Some observations: 

                                

                                The user nor the Client are linked with
                                any particular AS. A user may use today
                                an AS of the Bank of America and may
                                change tomorrow to the Bank of Missouri.
                                

                                As soon as he will be registered with
                                the Bank of Missouri, he will be able to
                                get access tokens from the AS of the
                                Bank of Missouri. The AS of Bank of
                                America 

                                has not been able to know where its
                                access tokens have been used. This will
                                be the same for AS of the Bank of
                                Missouri. There is no need for any
                                direct dialogue 

                                between any AS and any RS at the time a
                                client is making an access. There is no
                                need for any RO to contact any AS.

                            
This model has been
                                constructed following a "Privacy by
                                Design" approach.

                            Denis

                            

                        

                      

                    

                  

                

              

              


              

            

            -- 

            Txauth mailing list

            Txauth@ietf.org

            https://www.ietf.org/mailman/listinfo/txauth

          

        

      

    

    


    

  


--------------CE31A6735C767D6FCA0FFE17--


From nobody Fri Jul 17 09:21: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 A473E3A0890 for ; Fri, 17 Jul 2020 09:21:15 -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, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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
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 b_kPKP6CqPwS for ; Fri, 17 Jul 2020 09:21:12 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30AC3A088C for ; Fri, 17 Jul 2020 09:21:10 -0700 (PDT)
Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d85 with ME id 4GM8230074FMSmm03GM8kt; Fri, 17 Jul 2020 18:21:08 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 17 Jul 2020 18:21:08 +0200
X-ME-IP: 86.238.65.197
To: Francis Pouatcha , txauth@ietf.org, Dick Hardt 
References:            
From: Denis 
Message-ID: 
Date: Fri, 17 Jul 2020 18:21: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: 
Content-Type: multipart/alternative; boundary="------------7B15785DB4717D0F8ED6F6FF"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 17 Jul 2020 16:21:16 -0000

This is a multi-part message in MIME format.
--------------7B15785DB4717D0F8ED6F6FF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Francis and Dick,

The good news first: we are making some progress. We are now close to an 
agreement with steps (1) up to (3),
... except that the place where the user consent is captured is not 
mentioned/indicated.

If a RO needs to be involved and since a RO is directly associated with 
a RS, why can't it be directly queried
by the appropriate RS after step (2) or later on ?

Which information is supposed to be presented to the RO ?
Which information is supposed to be returned by the RO ?

Denis

> Hello Dick, Denis,
>
> here is an updated version of the diagram following Dick's advice to 
> collapse responses and some clarifications as raised by Denis:
>
> +----+  +------+  +---+  +---+  +---+
> |User|  |Client|  |RS |  |GS |  |RO |
> +----+  +------+  +---+  +-+-+  +-+-+
>   |(1) ServiceRequest      |      |
>   |-------->|       |      |      |
>   |         |(2) ServiceIntent:AuthZChallenge
>   |         |<----->|      |      |
>   |         |       |      |      |
>   |         |(3) AuthZRequest(AuthZChallenge)
>   |         |------------->|      |
>   |         |       |      |(4) ConsentRequest:Grant
>   |         |       |      |<---->|
>   |         |(5) GrantAccess(AuthZ)
>   |         |<-------------|      |
>   |         |       |      |      |
>   |         |(6) ServiceRequest(AuthZ):ServiceResponse
>   |         |<----->|      |      |
>   |(7) ServiceResponse     |      |
>   |<--------|       |      |      |
>   +         +       +      +      +
>
> Nomenclature of Arrows:
> ---> designate a request.
> <--- designates a response.
> <--> request with immediate response.
>
> Step, Action and Interaction:
> This diagram describes actions and not interactions:
> - Each step carries a number.
> - An action with immediate response is collapsed into a single step 
> (2, 4, 6).
> - An action with deferred response is represented by two steps (1&7, 3&5).
> - An action might be carried out using many interactions and might for 
> the purpose of transport involve more parties (see redirect 
> interaction bellow)
>
> (1) ServiceRequest
> This is the service request sent by the User to the Client. This can 
> be a simple file read request or a complex payment initiation request.
>
> (2) ServiceIntent:AuthZChallenge
> In order to discover authorization requirements, the Client sends 
> a ServiceIntent request to the RS. The response to a ServiceIntent 
> request is an AuthZChallenge.
> The content of an AuthZChallenge can be similar to the oAuth2 RAR.
> The content of the AuthZChallenge can be:
> - An identification challenge. Generally when the RS can not associate 
> the ServiceRequest with an RO.
> - An AuthZ exemption. Generally when the RS needs no further AuthZ to 
> fulfill the Client request.
> - Details on the requested AuthZ, including instructions on which GSs 
> the Client can approach for AuthZ; instructions on which attributes 
> are requested for each of these GSs.
>
> (3) AuthZRequest(AuthZChallenge)
> The Client sends an AuthZRequest to the GS including the 
> AuthZChallenge. This request can be similar to the oAuth2 PAR request.
>
> (4) ConsentRequest:Grant
> GS sends a consent request to RO. The way a GS connects with the RO to 
> collect RO's consent (Grant) is dependent on the interaction mode. 
> This is also valid for the nature of the Grant returned by the RO to 
> the GS.
> - In the case of a "redirect interaction", GS will use the transport 
> infrastructure provided by the Client to instruct the User to send the 
> RO to the GS authorization endpoint (in most cases, user and RO are 
> identical). In the case of oAuth2 AuthCode flow, the Grant provided by 
> the RO is stored by the GS (AS) at the AuthZ endpoint, then mapped to 
> an authCode that is transported by the User (User Agent) through the 
> Client to the token endpoint of the GS.
> - In the case of a "decoupled interaction", GS will directly contact 
> RO and collect consent in a direct interaction with the RO (see CIBA). 
> This diagram assumes GS can evaluate the AuthZChallenge to find out 
> how to locate the RO. As there is a direct interaction between the GS 
> and the RO, the form/nature of the Grant is left to the discretion of 
> the concrete interaction mode.
> - In the case of an "embedded interaction", GS will allow the Client 
> to directly collect the Consent (Grant) of the RO in a direct 
> interaction between the Client and the User (also assuming in most 
> cases, that user and RO are identical); and then send it to the GS in 
> exchange of the AuthZ. We say the interaction between GS and RO is 
> embedded in the communication with the Client.
>
> (5) GrantAccess(AuthZ)
> From evaluating the Grant provided by the client, the GS produces a 
> corresponding access token and returns it to the Client.
> Note that GS knowledge of the original or target RS is not necessary 
> for the issuance of the access token, unless GS is required to bind 
> the token to a target RS.
>
> (6) ServiceRequest(AuthZ):ServiceResponse
> Client uses the GS provided AuthZ to send the service request to RS. 
> Recall that AuthZ (token) can be, but must not be bound to an RS.
>
> (7) is self explaining.
>
> One of our upcoming exercises will be to challenge this abstract 
> protocol flow with existing interactions (and if possible associated 
> use cases) to see if we are missing something. After an agreement on 
> the abstract protocol flow we can make sure each interaction provides 
> a mapping to step 1 to 7.
>
> /Francis
>
> On Thu, Jul 16, 2020 at 2:15 PM Dick Hardt  > wrote:
>
>     Hi Francis
>
>     Thanks for drafting the sequence diagram and descriptions! I
>     really like where. you are going with it.
>
>     As our objective is to provide an abstraction,  what do you think
>     of collapsing steps 2&3, 5&6, and 8&9 in the diagram?
>
>     Per the discussion to your post, there is also some tuning of the
>     descriptions of each step. I would also add in which steps are
>     optional.
>
>     Referencing other parts of the document would be useful, as this
>     abstraction is intended to be a high level guide to the protocol,
>     so adding other top level sections to the document, even if they
>     are thin, would help the reader in grasping the possible flows.
>
>     /Dick
>
>     On Thu, Jul 16, 2020 at 9:57 AM Denis      > wrote:
>
>         Hello Francis,
>
>>         Hello Denis,
>>
>>         On Thu, Jul 16, 2020 at 8:45 AM Denis >         > wrote:
>>
>>             Hello  Francis,
>>
>>             The first two steps of your scenario are nice, in
>>             particular the second one:
>>
>>                 (2) Service Intent: In order to discover
>>                 *authorization requirements*, the Client sends a
>>                 service intent to the RS.
>>
>>             This means that the client first contacts the RS, instead
>>             of the GS.
>>
>>
>>             However, the third step is missing to disclose to the
>>             client these "*authorization requirements*", in
>>             particular which AS(s),
>>             it may contact, which attributes are requested and
>>             how/when/where the user consent is gathered.
>>
>>         The response (2) AuthZ Challenge carries the reference to the
>>         GS. Mean the resource server instructs the Client on which GS
>>         to approach for authorization.
>
>         This information was not mentioned in your description.
>
>>
>>             Unless the scenario is mandating all the RSs to trust one
>>             and only one GS and the client to have a relationship
>>             with that GS,
>>             the remaining steps of this scenario do not work.
>>
>>         Can you elaborate why it shall not work for many GSs?
>
>         Your answer above mentions : "which GS to approach for
>         authorization". It uses the singular whereas it should use the
>         plural.
>
>         In addition, indicating only which GS*s* (plural) is
>         insufficient, since the RS also needs to indicate to the
>         Client which attributes
>         are requested for each of these GSs.
>
>         Your description is also silent to explain how/when/where the
>         user consent is gathered.
>
>>             Step (5) mandates the GS to know who the owner of a given
>>             RS is
>>
>>         Step (5) mandates the GS to know the RO, as owner of the
>>         target Resource, but not the RS (Resource Server). Resource
>>         not-equals RS.
>>
>>             , and thus mandates the client to disclose to the GS the
>>             identity of the RS.
>>
>
>>         No. Here there is no requirement from GS to know the RS.
>
>         In your are using the terminology of RFC 6749, then page 5 states:
>
>             In OAuth, the client requests access to resources
>             controlled by the resource owner and hosted by the
>             resource server.
>
>         In order to make sure that the right RO is in charge of the
>         appropriate RS, the GS needs to maintain a mapping between the
>         RS and the RO.
>         The client does not know who the ROs are.
>
>>             The consequence is the following : this scenario, /as
>>             well as the scenario described in
>>             draft-hardt-xauth-protocol-13/, allows the GS to act as
>>             Big Brother.
>>
>>         No.
>
>         If the GS is in a position to know when a client is attempting
>         to make an access to a given RS, then it can maintain logs of
>         these events.
>
>>         RS will find a way to validate AuthZ produced by any GS.
>
>         No. A RS trusts some GSs for some kinds of attributes. It does
>         not trust all the GSs that might exist in the world.
>
>>         Means RS must trust that very GS or trust somebody that
>>         trusts that very GS (e.g. CA).
>
>         Trust relationships are not necessarily transitive (nor
>         bilateral).
>
>>         GS must not know the RS but must understand the Resource and
>>         trust the Resource Owner, so that GS can validate the RO Grant.
>
>         It would be interesting if you could elaborate on the last
>         part of this sentence :
>         "[GS] must understand the Resource and trust the Resource
>         Owner, so that GS can validate the RO Grant".
>
>         Denis
>
>>
>>         /Francis
>>
>>
>>             Denis
>>
>>>             Hello Fabian,
>>>
>>>             On Thu, Jul 16, 2020 at 4:47 AM Fabien Imbault
>>>             >>             > wrote:
>>>
>>>                 Hi,
>>>
>>>                 That's interesting, however the important logic is
>>>                 actually implemented within (5). And so for the
>>>                 reader, it might be quite difficult to understand
>>>                 what we're after (compared to oauth2 for instance).
>>>                 So in my view, this kind of schema has its place,
>>>                 but not at the start of the document where we should
>>>                 primarily be concerned about explaining why someone
>>>                 should read the document..
>>>
>>>                 It's also not easy to understand :
>>>                 - why we sometimes use different labels between
>>>                 requests and responses (for instance, 5 and 6)
>>>
>>>             Will need support in drafting the correct terms. The
>>>             main purpose of this diagram is to help sharpen the
>>>             definition of terms and verbs used in the draft.
>>>
>>>                 - sometimes we use "grant" and sometimes "authZ",
>>>                 and it doesn't seem very clear what is the
>>>                 difference in use
>>>
>>>             IMO: the granting is the process of given permission.
>>>             - RO can grant his Consent to the User or Client
>>>             - GS can turn the RO Grant into an AuthZ.
>>>             - Client can use AuthZ to access a Resource.
>>>
>>>                 A terminology section would be great to clarify.
>>>
>>>             Yes. There is a terminology section in there. We need to
>>>             bring the wissing words into the list and sharpen those
>>>             already there.
>>>
>>>
>>>                 If I understand correctly your remark in 5, you
>>>                 think the request/response scheme (as in XYZ) may be
>>>                 misleading.
>>>
>>>             No. XYZ does IMO exactly  that. Just try to be more
>>>             abstract for a better description of the models.
>>>
>>>                 On the contrary, I think it allows support rich
>>>                 interaction scenarios (and especially the ones you
>>>                 describe) with greater flexibility.
>>>
>>>             Flexibility shall not be put ahead of formal correctness.
>>>
>>>                 For instance, some would disagree with the assertion
>>>                 that the goal is for the GS to gather consent (see
>>>                 discussion on putting that on client side). A fixed
>>>                 interaction schema has the downside of not
>>>                 permitting other setups.
>>>
>>>             This discussion is the result of the lack of sharp
>>>             terminology. Most of the time mixing up gathering
>>>             consent (the act) and the way consent is gathered and
>>>             transported from RO to GS (the interaction).
>>>             /Francis
>>>
>>>
>>>                 Fabien
>>>
>>>                 On Thu, Jul 16, 2020 at 5:28 AM Francis Pouatcha
>>>                 >>                 > wrote:
>>>
>>>                     Hello Dick,
>>>
>>>
>>>                                     2. Abstract Protocol Flow
>>>                                     I am missing an abstract
>>>                                     protocol flow like the one
>>>                                     defined in
>>>                                     https://tools.ietf.org/html/rfc6749#section-1.2.
>>>
>>>
>>>                                 That's an interesting point. GNAP
>>>                                 also has identity claims, so the
>>>                                 abstract flow is somewhat different
>>>                                 (there is no Authorization Grant
>>>                                 from the RO), and not all steps
>>>                                 always happen. (there may not be
>>>                                 steps (E) and (F) with a Resource
>>>                                 Server)
>>>
>>>                                 Would you elaborate on what you
>>>                                 think would be useful here, that is
>>>                                 not in the specific flows?
>>>
>>>                             A diagram that generalizes the steps,
>>>                             independently of interaction mode is
>>>                             essential for the reader's navigation of
>>>                             the rest of the document. This is
>>>                             what #section-1.2 of RFC6749 does. I
>>>                             hope we can produce a similar diagram.
>>>
>>>                             A subsection of
>>>                             https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>>                             could be defined for this.
>>>
>>>
>>>                         Interaction modes are one dimension where
>>>                         the steps could be generalized, but some
>>>                         steps are optional. For example, the User
>>>                         may not interact with the GS, and the GS may
>>>                         interact with the RO. The Client may only
>>>                         want claims, and there would be no step of
>>>                         the Client calling the RS.
>>>
>>>                         A generalized diagram would need to include
>>>                         all optional steps so that it did not
>>>                         mislead a reader into thinking the diagram
>>>                         included all general steps, but it does not
>>>                         seem that is what you are asking for as you
>>>                         wrote:
>>>
>>>                         A subsection of
>>>                         https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
>>>                         could be defined for this."
>>>
>>>                         Perhaps you can share how you think the
>>>                         diagram would look?
>>>
>>>                     find below my proposal of an abstract sequence
>>>                     diagram.
>>>
>>>                     +----+  +------+  +---+  +---+  +---+
>>>                     |User|  |Client|  |RS |  |GS |  |RO |
>>>                     +----+  +------+  +---+  +-+-+  +-+-+
>>>                       |(1) Service Request |      |
>>>                       |-------->|       |    |      |
>>>                       |         |(2) Service Intent   |
>>>                       |         |------>|    |      |
>>>                       |         |(3) AuthZ Challenge  |
>>>                       |         |<------|    |      |
>>>                       |         |(4) AuthZ Request    |
>>>                       | |------------->|      |
>>>                       |         |       |  |(5) Consent Request
>>>                       |         |       |  |----->|
>>>                       |         |       |  |(6) Grant Consent
>>>                       |         |       |  |<-----|
>>>                       |         |(7) Grant Access (Token)
>>>                       | |<-------------|      |
>>>                       |         |(8) Service Request (Token)
>>>                       |         +------>+    |      |
>>>                       |         |(9) Service Response |
>>>                       |         |<------|    |      |
>>>                       |(10) Service Response |      |
>>>                       +<--------|       |    |      |
>>>                       +         +       +  +      +
>>>
>>>                     (1) Service Request: This is the service request
>>>                     sent by a User to the Client. This can be a
>>>                     simple file read request or even a complex
>>>                     payment initiation request.
>>>
>>>                     (2) Service Intent: In order to discover
>>>                     authorization requirements, the Client sends a
>>>                     service intent to the RS.
>>>
>>>                     (3) AuthZ Challenge: The response to a service
>>>                     intent request is generally an AuthZ Challenge.
>>>                     The content of this AuthZ Challenge, can be an
>>>                     identification challenge, an AuthZ exemption, or
>>>                     details on requested AuthZ. The content AuthZ
>>>                     Challenge can be similar to the oAuth2 RAR.
>>>
>>>                     (4) AuthZ Request : the Client sends an AuthZ
>>>                     Request to the GS including the AuthZ Challenge.
>>>                     This request can be similar to the oAuth PAR
>>>                     request.
>>>
>>>                     (5) Requests Consent : GS sends consent request
>>>                     to RO.
>>>                     Remark: The abstract protocol flow does not
>>>                     display a response of the request (4) to the
>>>                     Client. This is IMO a general misunderstanding.
>>>                     This protocol wants the GS to collect a consent
>>>                     from the RO.
>>>                     - In the case of a "redirect interaction", GS
>>>                     will use transport infrastructure provided by
>>>                     the Client to instruct the User to send the RO
>>>                     to the GS (in most cases, user and RO are
>>>                     identical).
>>>                     - In the case of a "decoupled interaction", GS
>>>                     will directly contact RO and collect consent in
>>>                     a direct interaction with the RO (see CIBA).
>>>                     - In the case of an "embedded interaction", GS
>>>                     will allow the Client to directly collect the
>>>                     Consent of the RO in a direct interaction with
>>>                     the User.
>>>
>>>                     (6) Grant Consent : RO return a Consent Grant to GS.
>>>
>>>                     (7) Grant Access : GS produces the corresponding
>>>                     access token and returns it to Client.
>>>
>>>                     (8) Service Request : Client uses the access
>>>                     token to send the service request to RS.
>>>
>>>                     (9) and (10) are self explaining....
>>>
>>>                     One of our upcoming exercises will be to
>>>                     challenge this abstract protocol flow with
>>>                     existing interactions (and if possible
>>>                     associated use cases) to see if we are missing
>>>                     something. After an agreement on the abstract
>>>                     protocol flow we can make sure each interaction
>>>                     provides a mapping to step 1 to 10.
>>>
>>>                     I will strip the rest of the post here. And
>>>                     bring further responses in separate mails.
>>>
>>>                     Best regards.
>>>                     /Francis
>>>
>>>                         ᐧ
>>>
>>>                     -- 
>>>                     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/



--------------7B15785DB4717D0F8ED6F6FF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Francis and Dick,

    


    

    
The good news first: we are making some
      progress. We are now close to an agreement with steps (1) up to
      (3), 

      ... except that the place where the user consent is captured is
      not mentioned/indicated.

    


    

    
If a RO needs to be involved and since
      a RO is directly associated with a RS, why can't it be directly
      queried 

      by the appropriate RS after step (2) or later on ?

    


    

    
Which information is supposed to be
      presented to the RO ?

      Which information is supposed to be returned by the RO ?

    


    

    Denis

    

    

      
      

        
Hello Dick, Denis,

        


          

        
here is an updated version of the
            diagram following Dick's advice to collapse responses and
            some clarifications as raised by Denis:

        


          

        
+----+  +------+  +---+  +---+
             +---+

            |User|  |Client|  |RS |  |GS |  |RO |

            +----+  +------+  +---+  +-+-+  +-+-+

              |(1) ServiceRequest      |      |

              |-------->|       |      |      |

              |         |(2) ServiceIntent:AuthZChallenge  

              |         |<----->|      |      |

              |         |       |      |      |

              |         |(3) AuthZRequest(AuthZChallenge)

              |         |------------->|      |

              |         |       |      |(4) ConsentRequest:Grant

              |         |       |      |<---->|

              |         |(5) GrantAccess(AuthZ)

              |         |<-------------|      |

              |         |       |      |      |

              |         |(6) ServiceRequest(AuthZ):ServiceResponse

              |         |<----->|      |      |

              |(7) ServiceResponse     |      |

              |<--------|       |      |      |

              +         +       +      +      +

        


          

        
Nomenclature of Arrows: 

        
---> designate a request.

        
<--- designates a response.

        
<--> request with
            immediate response.

          

        


          

        
Step, Action and Interaction:

        
This diagram describes actions and
            not interactions: 

        
- Each step carries a number.

        
- An action with immediate response
            is collapsed into a single step (2, 4, 6).

        
- An action with deferred response
            is represented by two steps (1&7, 3&5).

        
- An action might be carried out
            using many interactions and might for the purpose of
            transport involve more parties (see redirect interaction
            bellow)

        


          

        

          
(1) ServiceRequest

          
This is the service request sent
              by the User to the Client. This can be a simple file read
              request or a complex payment initiation request.

          


            

          
(2) ServiceIntent:AuthZChallenge

          
In order to discover authorization
              requirements, the Client sends a ServiceIntent request to
              the RS. The response to a ServiceIntent request is an
              AuthZChallenge. 

          
The content of an AuthZChallenge
              can be similar to the oAuth2 RAR.

            

          
The content of the AuthZChallenge
              can be:

            

          
- An identification challenge.
              Generally when the RS can not associate the ServiceRequest
              with an RO.

          
- An AuthZ exemption. Generally
              when the RS needs no further AuthZ to fulfill the Client
              request.

          
- Details on the requested AuthZ,
              including instructions on which GSs the Client can
              approach for AuthZ; instructions on which attributes are
              requested for each of these GSs.

          

            


              

          

          
(3) AuthZRequest(AuthZChallenge)

          
The Client sends an AuthZRequest
              to the GS including the AuthZChallenge. This request can
              be similar to the oAuth2 PAR request.

          


            

          
(4) ConsentRequest:Grant

          
GS sends a consent request to RO.
              The way a GS connects with the RO to collect RO's consent
              (Grant) is dependent on the interaction mode. This is also
              valid for the nature of the Grant returned by the RO to
              the GS.

          
- In the case of a "redirect
              interaction", GS will use the transport infrastructure
              provided by the Client to instruct the User to send the RO
              to the GS authorization endpoint (in most cases, user and
              RO are identical). In the case of oAuth2 AuthCode flow,
              the Grant provided by the RO is stored by the GS (AS) at
              the AuthZ endpoint, then mapped to an authCode that is
              transported by the User (User Agent) through the Client to
              the token endpoint of the GS. 

          
- In the case of a "decoupled
              interaction", GS will directly contact RO and collect
              consent in a direct interaction with the RO (see CIBA).
              This diagram assumes GS can evaluate the AuthZChallenge to
              find out how to locate the RO. As there is a direct
              interaction between the GS and the RO, the form/nature of
              the Grant is left to the discretion of the concrete
              interaction mode.

          
- In the case of an "embedded
              interaction", GS will allow the Client to directly collect
              the Consent (Grant) of the RO in a direct interaction
              between the Client and the User (also assuming in most
              cases, that user and RO are identical); and then send it
              to the GS in exchange of the AuthZ. We say the interaction
              between GS and RO is embedded in the communication with
              the Client.

          


            

          
(5) GrantAccess(AuthZ)

          
From evaluating the Grant provided
              by the client, the GS produces a corresponding access
              token and returns it to the Client.

          
Note that GS knowledge of the
              original or target RS is not necessary for the issuance of
              the access token, unless GS is required to bind the token
              to a target RS. 

          


            

          
(6) ServiceRequest(AuthZ):ServiceResponse

          
Client uses the GS
              provided AuthZ to send the service request to RS. Recall
              that AuthZ (token) can be, but must not be bound to an RS.

          


            

          
(7) is self explaining.

          


            

          
One of our upcoming exercises will
              be to challenge this abstract protocol flow with existing
              interactions (and if possible associated use cases) to see
              if we are missing something. After an agreement on the
              abstract protocol flow we can make sure each interaction
              provides a mapping to step 1 to 7.

        

        


          

        
/Francis

      

      

      

        
On Thu, Jul 16, 2020 at 2:15
          PM Dick Hardt <dick.hardt@gmail.com> wrote:

        

        

          
Hi Francis
            


            

            
Thanks for drafting the sequence diagram and
              descriptions! I really like where. you are going with it.

            


            

            
As our objective is to provide an abstraction,  what do
              you think of collapsing steps 2&3, 5&6, and
              8&9 in the diagram?

            


            

            
Per the discussion to your post, there is also some
              tuning of the descriptions of each step. I would also add
              in which steps are optional.

            


            

            
Referencing other parts of the document would be
              useful, as this abstraction is intended to be a high level
              guide to the protocol, so adding other top level sections
              to the document, even if they are thin, would help the
              reader in grasping the possible flows.

            


            

            
/Dick

          

          

          

            
On Thu, Jul 16, 2020 at
              9:57 AM Denis <denis.ietf@free.fr>
              wrote:

            

            

              

                
Hello Francis,

                


                

                

                  

                    
Hello Denis,

                    

                    

                      
On Thu, Jul 16,
                        2020 at 8:45 AM Denis <denis.ietf@free.fr>
                        wrote:

                      

                      

                        

                          
Hello  Francis,

                            

                          

                          
The first two steps of your scenario are
                            nice, in particular the second one:

                          

                            
(2) Service Intent: In order to
                              discover authorization requirements,
                              the Client sends a service intent to the
                              RS.

                          

                          
This means that the client first contacts
                            the RS, instead of the GS. 

                        

                      

                      

                        

                          


                          

                          
However, the third step is missing to
                            disclose to the client these "authorization
                              requirements", in particular which
                            AS(s), 

                            it may contact, which attributes are
                            requested and how/when/where the user
                            consent is gathered.

                            

                          

                        

                      

                      
The response (2) AuthZ Challenge carries the
                        reference to the GS. Mean the resource server
                        instructs the Client on which GS to approach for
                        authorization. 

                      

                    

                  

                

                
This information was not mentioned in your
                  description.

                

                  

                    

                      

                        

                          
 

                            Unless the scenario is mandating all the RSs
                            to trust one and only one GS and the client
                            to have a relationship with that GS, 

                            the remaining steps of this scenario do not
                            work.

                            

                          

                        

                      

                      
Can you elaborate why it shall not work
                        for many GSs?

                    

                  

                

                
Your answer above mentions : "which GS to approach
                  for authorization". It uses the singular whereas it
                  should use the plural.

                
In addition, indicating only which GSs
                  (plural) is insufficient, since the RS also needs to
                  indicate to the Client which attributes 

                  are requested for each of these GSs.

                
Your description is also silent to explain
                  how/when/where the user consent is gathered.

                

                  

                    

                      

                        

                          
 

                        

                      

                      

                        

                          
Step (5) mandates the GS to know who the
                            owner of a given RS is

                        

                      

                      
Step (5) mandates the GS to know the RO, as
                        owner of the target Resource, but not the RS
                        (Resource Server). Resource not-equals RS.

                      


                      

                      

                        

                          
, and thus mandates the client to
                            disclose to the GS the identity of the RS. 

                          

                        

                      

                    

                  

                

                

                

                  

                    

                      
No. Here there is no requirement from GS to
                        know the RS.

                    

                  

                

                
In your are using the terminology of RFC 6749, then
                  page 5 states:

                

                  
In OAuth, the client requests access to resources
                    controlled by the resource owner and hosted by the
                    resource server.

                  

                

                
In order to make sure that the right RO is in charge
                  of the appropriate RS, the GS needs to maintain a
                  mapping between the RS and the RO.

                  The client does not know who the ROs are.

                

                  

                    

                      
 

                      

                        

                          
The consequence is the following : this
                            scenario, as well as the scenario
                              described in draft-hardt-xauth-protocol-13,
                            allows the GS to act as Big Brother. 

                          

                        

                      

                      
No. 

                      

                    

                  

                

                
If the GS is in a position to know when a client is
                  attempting to make an access to a given RS, then it
                  can maintain logs of these events.

                

                

                  

                    

                      
RS will find a way to validate AuthZ produced
                        by any GS. 

                    

                  

                

                
No. A RS trusts some GSs for some kinds of
                  attributes. It does not trust all the GSs that might
                  exist in the world.

                

                  

                    

                      
Means RS must trust that very GS or trust
                        somebody that trusts that very GS (e.g. CA).

                    

                  

                

                
Trust relationships are not necessarily transitive
                  (nor bilateral).

                

                  

                    

                      
GS must not know the RS but must understand
                        the Resource and trust the Resource Owner, so
                        that GS can validate the RO Grant.

                    

                  

                

                
It would be interesting if you could elaborate on the
                  last part of this sentence :

                  "[GS] must understand the Resource and trust the
                  Resource Owner, so that GS can validate the RO Grant".

                
Denis

                

                

                  

                    

                      


                      

                      
/Francis

                      

                        

                          
 

                          


                          

                          
Denis

                          

                          

                          

                            

                              
Hello Fabian,

                              

                              

                                
On
                                  Thu, Jul 16, 2020 at 4:47 AM Fabien
                                  Imbault <fabien.imbault@gmail.com>
                                  wrote:

                                

                                

                                  
Hi, 
                                    


                                    

                                    
That's interesting, however the
                                      important logic is actually
                                      implemented within (5). And so for
                                      the reader, it might be quite
                                      difficult to understand what we're
                                      after (compared to oauth2 for
                                      instance). So in my view, this
                                      kind of schema has its place, but
                                      not at the start of the document
                                      where we should primarily be
                                      concerned about explaining why
                                      someone should read the document..

                                    


                                    

                                    
It's also not easy to
                                      understand : 

                                    
- why we sometimes use
                                      different labels between requests
                                      and responses (for instance, 5 and
                                      6)

                                  

                                

                                
Will need support in drafting the
                                  correct terms. The main purpose of
                                  this diagram is to help sharpen the
                                  definition of terms and verbs used in
                                  the draft.

                                


                                

                                

                                  

                                    
- sometimes we use "grant" and
                                      sometimes "authZ", and it doesn't
                                      seem very clear what is the
                                      difference in use

                                  

                                

                                
IMO: the granting is the process of
                                  given permission.

                                
- RO can grant his Consent to the
                                  User or Client

                                
- GS can turn the RO Grant into an
                                  AuthZ.

                                
- Client can use AuthZ to access a
                                  Resource.

                                


                                

                                

                                  

                                    
A terminology section would be
                                      great to clarify.

                                  

                                

                                
Yes. There is a terminology section
                                  in there. We need to bring the wissing
                                  words into the list and sharpen those
                                  already there. 

                                

                                  

                                    


                                    

                                    
If I understand correctly your
                                      remark in 5, you think the
                                      request/response scheme (as in
                                      XYZ) may be misleading. 

                                  

                                

                                
No. XYZ does IMO exactly  that.
                                  Just try to be more abstract for a
                                  better description of the models.

                                
 

                                

                                  

                                    
On the contrary, I think it
                                      allows support rich interaction
                                      scenarios (and especially the ones
                                      you describe) with greater
                                      flexibility. 

                                  

                                

                                
Flexibility shall not be put ahead
                                  of formal correctness.

                                
 

                                

                                  

                                    
For instance, some would
                                      disagree with the assertion that
                                      the goal is for the GS to gather
                                      consent (see discussion on putting
                                      that on client side). A fixed
                                      interaction schema has the
                                      downside of not permitting other
                                      setups.

                                  

                                

                                
This discussion is the result of
                                  the lack of sharp terminology. Most of
                                  the time mixing up gathering consent
                                  (the act) and the way consent is
                                  gathered and transported from RO to GS
                                  (the interaction).

                                
/Francis

                                


                                

                                

                                  

                                    


                                    

                                    
Fabien

                                  

                                  

                                  

                                    
On
                                      Thu, Jul 16, 2020 at 5:28 AM
                                      Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>
                                      wrote:

                                    

                                    

                                      

                                        
Hello Dick,
                                          


                                            

                                        

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
2.
                                                          Abstract
                                                          Protocol Flow

                                                          

                                                          
I
                                                          am missing an
                                                          abstract
                                                          protocol flow
                                                          like the one
                                                          defined in https://tools.ietf.org/html/rfc6749#section-1.2.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
That's
                                                          an interesting
                                                          point. GNAP
                                                          also has
                                                          identity
                                                          claims, so the
                                                          abstract flow
                                                          is somewhat
                                                          different
                                                          (there is no
                                                          Authorization
                                                          Grant from the
                                                          RO), and not
                                                          all steps
                                                          always happen.
                                                          (there may not
                                                          be steps (E)
                                                          and (F) with a
                                                          Resource
                                                          Server)

                                                          


                                                          

                                                          
Would
                                                          you elaborate
                                                          on what you
                                                          think would be
                                                          useful here,
                                                          that is not in
                                                          the specific
                                                          flows?

                                                          

                                                        

                                                      

                                                      
A
                                                          diagram that
                                                          generalizes
                                                          the steps,
                                                          independently
                                                          of interaction
                                                          mode is
                                                          essential for
                                                          the reader's
                                                          navigation of
                                                          the rest of
                                                          the
                                                          document. This
                                                          is
                                                          what #section-1.2
                                                          of RFC6749
                                                          does. I hope
                                                          we can produce
                                                          a similar
                                                          diagram.

                                                      


                                                        

                                                      
                                                    

                                                  

                                                

                                                


                                                  

                                                
Interaction
                                                    modes are one
                                                    dimension where the
                                                    steps could be
                                                    generalized, but
                                                    some steps are
                                                    optional. For
                                                    example, the User
                                                    may not interact
                                                    with the GS, and the
                                                    GS may interact with
                                                    the RO. The Client
                                                    may only want
                                                    claims, and there
                                                    would be no step of
                                                    the Client calling
                                                    the RS.

                                                


                                                  

                                                
A
                                                    generalized diagram
                                                    would need to
                                                    include all optional
                                                    steps so that it did
                                                    not mislead a reader
                                                    into thinking the
                                                    diagram included all
                                                    general steps, but
                                                    it does not seem
                                                    that is what you are
                                                    asking for as you
                                                    wrote:

                                                


                                                  

                                                
A
                                                    subsection of https://tools.ietf.org/html/draft-hardt-xauth-protocol-12#section-1.1
                                                    could be defined for
                                                    this."

                                                  

                                                


                                                  

                                                
Perhaps
                                                    you can share how
                                                    you think the
                                                    diagram would look?

                                              

                                            

                                          

                                          
find
                                              below my proposal of an
                                              abstract sequence diagram.

                                          


                                            

                                          
+----+
                                               +------+  +---+  +---+
                                               +---+

                                              |User|  |Client|  |RS |
                                               |GS |  |RO |

                                              +----+  +------+  +---+
                                               +-+-+  +-+-+

                                                |(1) Service Request    
                                              |      |

                                                |-------->|       |  
                                                 |      |

                                                |         |(2) Service
                                              Intent   |

                                                |         |------>|  
                                                 |      |

                                                |         |(3) AuthZ
                                              Challenge  |

                                                |         |<------|  
                                                 |      |

                                                |         |(4) AuthZ
                                              Request    |

                                                |        
                                              |------------->|      |

                                                |         |       |    
                                               |(5) Consent Request

                                                |         |       |    
                                               |----->|

                                                |         |       |    
                                               |(6) Grant Consent

                                                |         |       |    
                                               |<-----|

                                                |         |(7) Grant
                                              Access (Token)

                                                |        
                                              |<-------------|      |

                                                |         |(8) Service
                                              Request (Token)

                                                |         +------>+  
                                                 |      |

                                                |         |(9) Service
                                              Response |

                                                |         |<------|  
                                                 |      |

                                                |(10) Service Response  
                                              |      |

                                                +<--------|       |  
                                                 |      |

                                                +         +       +    
                                               +      +

                                            

                                          


                                            

                                          
(1)
                                              Service Request: This is
                                              the service request sent
                                              by a User to the Client.
                                              This can be a simple file
                                              read request or even a
                                              complex payment initiation
                                              request.

                                          


                                            

                                          
(2)
                                              Service Intent: In order
                                              to discover authorization
                                              requirements, the Client
                                              sends a service intent to
                                              the RS.

                                          


                                            

                                          
(3)
                                              AuthZ Challenge: The
                                              response to a service
                                              intent request is
                                              generally an AuthZ
                                              Challenge. The content of
                                              this AuthZ Challenge, can
                                              be an identification
                                              challenge, an AuthZ
                                              exemption, or details on
                                              requested AuthZ. The
                                              content AuthZ Challenge
                                              can be similar to the
                                              oAuth2 RAR.

                                          


                                            

                                          
(4)
                                              AuthZ Request : the Client
                                              sends an AuthZ Request to
                                              the GS including the AuthZ
                                              Challenge. This request
                                              can be similar to the
                                              oAuth PAR request.

                                          


                                            

                                          
(5)
                                              Requests Consent : GS
                                              sends consent request to
                                              RO. 

                                          
Remark:
                                              The abstract protocol flow
                                              does not display a
                                              response of the request
                                              (4) to the Client. This is
                                              IMO a general
                                              misunderstanding. This
                                              protocol wants the GS to
                                              collect a consent from the
                                              RO. 

                                          
-
                                              In the case of a "redirect
                                              interaction", GS will use
                                              transport infrastructure
                                              provided by the Client to
                                              instruct the User to send
                                              the RO to the GS (in most
                                              cases, user and RO are
                                              identical).

                                          
-
                                              In the case of a
                                              "decoupled interaction",
                                              GS will directly contact
                                              RO and collect consent in
                                              a direct interaction with
                                              the RO (see CIBA).

                                          
-
                                              In the case of an
                                              "embedded interaction", GS
                                              will allow the Client to
                                              directly collect the
                                              Consent of the RO in a
                                              direct interaction with
                                              the User.

                                          


                                            

                                          
(6)
                                              Grant Consent : RO return
                                              a Consent Grant to GS.

                                          


                                            

                                          
(7)
                                              Grant Access : GS produces
                                              the corresponding access
                                              token and returns it to
                                              Client.

                                          


                                            

                                          
(8)
                                              Service Request : Client
                                              uses the access token to
                                              send the service request
                                              to RS.

                                          


                                            

                                          
(9)
                                              and (10) are self
                                              explaining....

                                          


                                            

                                          
One
                                              of our upcoming exercises
                                              will be to challenge this
                                              abstract protocol flow
                                              with existing
                                              interactions (and if
                                              possible associated use
                                              cases) to see if we are
                                              missing something. After
                                              an agreement on the
                                              abstract protocol flow we
                                              can make sure each
                                              interaction provides a
                                              mapping to step 1 to 10.

                                          


                                            

                                          
I
                                              will strip the rest of the
                                              post here. And bring
                                              further responses in
                                              separate mails.

                                          


                                            

                                          
Best
                                              regards.

                                          
/Francis  

                                          

                                            

                                              

                                                

                                                

                                              

                                            

                                            
ᐧ

                                          

                                        

                                        -- 

                                        
                                        

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          
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

                        
                      

                    

                  

                

              

            

          

        

      

    

    


    

  


--------------7B15785DB4717D0F8ED6F6FF--


From nobody Fri Jul 17 10:10: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 1C0CC3A086B for ; Fri, 17 Jul 2020 10:10:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, PDS_OTHER_BAD_TLD=1.999, 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 JCtvX3XJalYz for ; Fri, 17 Jul 2020 10:10:49 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450: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 182093A0867 for ; Fri, 17 Jul 2020 10:10:49 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id i19so1239087lfj.8 for ; Fri, 17 Jul 2020 10:10: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=SC5rabZNngC+b7QaUE4a1Jg59GsfpYSIwvUwC2Y66L4=; b=iCTsPnj0PLqoFEYSbVac4U8r7qioTQb1jzAoedOqSsvM7Fq5iKR1PAxCdmRuF8RA2/ 4Qc37xbzFmicU2cB3++Ncxi0pae6eZhSr2grIXMMnv3E2iwYvjysa5Lv6fJqX1pqp1Qu 5BIB88DfaHLrSnEirajW+0kG0i2Y5vFdQx5iuLtN+sWIDG22SWlyXaoLSREN9Ihww+LP h76bNLwcpRf2TAhx0SK+slRILFRmOal/WLpNdiyXp8fU+v8/L/JmBnj2KdwhkcWjgrp7 cF4GqLvlUCU8h5xanp/OG6R6AVl3ikpR5XR5dFeiP+ONh1tzfycst45CzbeFFUFn/iWK M8NQ==
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=SC5rabZNngC+b7QaUE4a1Jg59GsfpYSIwvUwC2Y66L4=; b=koW/faDvGi/FgYC6CZmNJDR6t/7zMi6EXxDmg7tzdfQKPD9I5fX+sI9jdDAy/aMsKS EAoloSxmkzcLAOwG/wTXuzA0ODduXqo3O3IswIknxqvsnkIl+I4eFnmRXRgesa4n1w30 02VPwu4bhXJTQRQHJuw1R7jD+9RhIJdHAWSJrb10frAqVcKGxk6S1PQzd9OI+AZXxgR6 NhOR606Cm24EpOvbsW365jMCM4nQkOMs54H812rx2ElRnqX0N8MT56Fh8t3x/POWGn7b cJ3vFGv3h0gL/fUfiZLrV9x8bgPe9j8XfhLnYBxWrbqMTiiGD+ogJ/ywXvuyOTC9Gy3H 45CA==
X-Gm-Message-State: AOAM532F6iNQ2eUiPjM1v4/Fa7ayQTVgeR9ErUPjrN6rRs0AmwBM/ITf IK+upyYXJX4Md2l+WDCADnCXXpQ/YvEYD80x1uQ=
X-Google-Smtp-Source: ABdhPJz9NPa/k+dqgWXw+lAlmYn81vAWncd6fxbWaMix1FZP0OCBEehLb7EDbeJf0Rx9XLPnt4t6i+SzEbC5ZdVOgVk=
X-Received: by 2002:a19:64c:: with SMTP id 73mr5190067lfg.0.1595005847015; Fri, 17 Jul 2020 10:10:47 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 17 Jul 2020 10:10:10 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ed19e105aaa63c10"
Archived-At: 
Subject: Re: [Txauth] New version of XYZ Draft
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, 17 Jul 2020 17:10:51 -0000

--000000000000ed19e105aaa63c10
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Justin,

Glad to see that you are aligning on having URIs for the access tokens and
the "grant".

While the token URI is unique to the token, you have not done the same for
a "grant", but have a handle and a non-unique URI.

Why not have a unique grant URI similar to the token URI? (a combination of
the handle and a non-unique URI) -- this is then both the identifier, and
the URL for "management"?

Glad to see you have excised the DID references. I don't think the common
use cases are well established there currently.

I have LOTS of feedback on your interaction changes, that I'll post later
on, and hope that others have feedback on those as well.

/Dick





On Thu, Jul 16, 2020 at 2:52 PM Justin Richer  wrote:

> Hi all,
>
> I=E2=80=99ve updated the XYZ draft specification. Since the publication t=
ools are
> currently locked prior to the upcoming virtual meeting, I have published =
it
> online here:
>
> https://oauth.xyz/draft-richer-transactional-authz
>
> This represents a pretty significant refactoring of the specification,
> hopefully to make the concepts and capabilities easier to understand. The
> core protocol is largely the same as before, but there are a number of
> serious updates:
>
>  - Continuation requests happen at a URL returned in the TX response. The
> =E2=80=9Chandle=E2=80=9D is still sent as one of the input values here, s=
ince the handle
> can also be used it other contexts.
>  - Tokens now can include the resources they are issued for
>  - Tokens can have an optional management URI for rotation and revocation=
.
>  - =E2=80=9Cclaims=E2=80=9D has been removed in favor of =E2=80=9Csubject=
=E2=80=9D dealing directly with
> identifiers and assertions
>  - the =E2=80=9Cuser=E2=80=9D request and response now align with identif=
iers and
> assertions
>  - Extensions and registries are more clearly enumerated throughout the
> document
>  - DID-related items have been excised in deference to a future possible
> extension
>  - Added a =E2=80=9Cpushback=E2=80=9D mechanism to complement the =E2=80=
=9Ccallback=E2=80=9D mechanism
>  - Simplified dynamic handle returns and access tokens based on developer
> feedback (basically we dropped a bunch of =E2=80=9Cwhat if=E2=80=9D stuff=
 that nobody used
> or liked, like SHA3 hashes for bearer tokens)
>
> I=E2=80=99ve also updated the interactive examples on https://oauth.xyz/ =
to match
> this new draft. Hopefully it=E2=80=99s consistent with the draft text.
>
> I have not yet, however, updated any of the implementations of XYZ to tak=
e
> the elements of new syntax into account, so there might be some more
> changes prior to the IETF meeting as I realize what terrible mistakes I=
=E2=80=99ve
> made when doing that. :)
>
> Feedback, as always, is welcomed, and thanks to everyone who=E2=80=99s pr=
ovided
> input to the project to date.
>
>  =E2=80=94 Justin
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000ed19e105aaa63c10
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey Justin,

Glad to see that you ar=
e aligning=C2=A0on having URIs for the access tokens and the "grant&qu=
ot;.

While the token URI is unique=C2=A0to the tok=
en, you have not done the same for a "grant", but have a handle a=
nd a non-unique URI.

Why not have a unique grant U=
RI similar to the token URI? (a combination of the handle and a non-unique =
URI) -- this is then both the identifier, and the URL for "management&=
quot;?

Glad to see you have excised the DID refere=
nces. I don't think the common use cases are well established there cur=
rently.

I have LOTS of feedback=C2=A0on your inter=
action changes, that I'll post later on, and hope that others have feed=
back on those as well.

/Dick

<=
div>



On Thu, Jul 16, 2020 at 2:52 PM=
 Justin Richer <jricher@mit.edu&g=
t; wrote:
Hi all,

I=E2=80=99ve=
 updated the XYZ draft specification. Since the publication tools are curre=
ntly locked prior to the upcoming virtual meeting, I have published it onli=
ne here:


This represents a pretty signi=
ficant refactoring of the specification, hopefully to make the concepts and=
 capabilities easier to understand. The core protocol is largely the same a=
s before, but there are a number of serious updates:

=C2=A0- Continuation requests happen at a URL returned in the TX respons=
e. The =E2=80=9Chandle=E2=80=9D is still sent as one of the input values he=
re, since the handle can also be used it other contexts.
=C2=A0- =
Tokens now can include the resources they are issued for
=C2=A0- =
Tokens can have an optional management URI for rotation and revocation.
=C2=A0- =E2=80=9Cclaims=E2=80=9D has been removed in favor of =E2=80=
=9Csubject=E2=80=9D dealing directly with identifiers and assertions
<=
div>=C2=A0- the =E2=80=9Cuser=E2=80=9D request and response now align with =
identifiers and assertions
=C2=A0- Extensions and registries are =
more clearly enumerated throughout the document
=C2=A0- DID-relat=
ed items have been excised in deference to a future possible extension
=C2=A0- Added a =E2=80=9Cpushback=E2=80=9D mechanism to complement th=
e =E2=80=9Ccallback=E2=80=9D mechanism
=C2=A0- Simplified dynamic=
 handle returns and access tokens based on developer feedback (basically we=
 dropped a bunch of =E2=80=9Cwhat if=E2=80=9D stuff that nobody used or lik=
ed, like SHA3 hashes for bearer tokens)

I=E2=80=99=
ve also updated the interactive examples on=C2=A0https://oauth.xyz/=C2=A0to match this new draft.=
 Hopefully it=E2=80=99s consistent with the draft text.

I have not yet, however, updated any of the implementations of XYZ to=
 take the elements of new syntax into account, so there might be some more =
changes prior to the IETF meeting as I realize what terrible mistakes I=E2=
=80=99ve made when doing that. :)=C2=A0

Feedback, =
as always, is welcomed, and thanks to everyone who=E2=80=99s provided input=
 to the project to date.=C2=A0

=C2=A0=E2=80=94 Jus=
tin
-- 

Txauth mailing list

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




--000000000000ed19e105aaa63c10--


From nobody Fri Jul 17 11:07: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 DBF763A0A11 for ; Fri, 17 Jul 2020 11:07:38 -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 ralyZWxDJtGg for ; Fri, 17 Jul 2020 11:07:37 -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 2D2AC3A0A09 for ; Fri, 17 Jul 2020 11:07:37 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id u12so6549721lff.2 for ; Fri, 17 Jul 2020 11:07: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=uwhG1CJJlBF/AkqajzxOqyTunpEsp5sWpw3kRQ65wdA=; b=tlZK6FTOf6PTugDUDsPwT23vnSRCW0LYg3NPEvMo4iP26bI496dAiafKQIW/LuGqn7 zD32V+Z0lW4ZtWwn2svFRR20WYPwk3ib9czKD9YdE7x6Q9dWj39EUf253tIcGnZrYVgH 5EQkUxKrMrHOU2STH5TSUXQGh+MtpGDFrQ2WbOD5/TTB93vXD8TWafGIi95PT7vK4jsX QLJv6JdLxgxNh81tcBwp7FiTQlshggtAeljIeBTcQ5+Ti7fABQFo7gUrS/hUC+r1MNap +O8GC2aGcg4VQ75oENoBqGs72SBa5E6iUOOY0YHlrRx5Sz/X2ar837TbcfVocP3gSZTH y07g==
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=uwhG1CJJlBF/AkqajzxOqyTunpEsp5sWpw3kRQ65wdA=; b=DntMNb8uuepJtGZvtU8RYiw1qNo4SfU6RFb3xe7EPU/T8yRNRE1FBCczRSBroL/c32 9gWjH62Y98Xh6t4oe4TsFfqPAwROxVMDfgZu8ulShH8kSW+/M8NTYaZEsASGPR44IcEw K6k94ifDQ3RSYNiZmc/IUxiaxvZN4UccS5YB7q+zMycA9q2w1z6JqRXCdwciBB7Uls8r H2o+nwK+M1q5Zn1mi/XjTKaCux3ebDm/YBFiTAvcgvSMqM0ejB4xnoUqIapMp/dEDWeC 1l5CyVZlBYc2casrAqQDy0IdW+m7JZ//Gw2I4wvIQjxQNmKRSNl59f7YnrzMIUzdof1I smxw==
X-Gm-Message-State: AOAM530qUN72raLNXL5GkIIIsF4Ofjik4WDuaCeZs7+ttYmXfkXhXC0C wm5bHKKJsjQPLQA++DAVbILwClrU5gP+eb79eyU=
X-Google-Smtp-Source: ABdhPJxqyvkyyUsdN3dHM5wWX/sQMME53p5sLzyjaGBJJxQavl8dQYdPlANylYxEvvLLFC6bz0r+4X8Op4jl/q6mQqs=
X-Received: by 2002:a19:c8a:: with SMTP id 132mr5218198lfm.23.1595009255044; Fri, 17 Jul 2020 11:07:35 -0700 (PDT)
MIME-Version: 1.0
References: <7c1f0439-42e4-9f7d-4dd2-e741f7cb57f2@free.fr>  <2201d382-c2f3-1496-b368-5b2caeb5eab5@free.fr>  <87fe40e8-7e00-3684-ce12-3ec28fd69c28@free.fr>
In-Reply-To: <87fe40e8-7e00-3684-ce12-3ec28fd69c28@free.fr>
From: Dick Hardt 
Date: Fri, 17 Jul 2020 11:06:58 -0700
Message-ID: 
To: Denis 
Cc: "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000000f7c2e05aaa70812"
Archived-At: 
Subject: Re: [Txauth] Registered Clients and Dynamic Clients
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, 17 Jul 2020 18:07:39 -0000

--0000000000000f7c2e05aaa70812
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Comments inline ...

On Fri, Jul 17, 2020 at 9:09 AM Denis  wrote:

> Hi Dick,
>
> I picked three of your sentences below :
>
> It appears you are mixing client identifiers and user identifiers, as wel=
l
> as user authentication at a AS, and client authentication at an AS.
> User authentication at the AS is out of scope of GNAP as I understand it
> (there are lots of existing mechanisms that work fine).
> Client authentication to the AS is in scope.
>
> An AS needs to authenticate users in order to relate them to their
> attributes: there is a user account at the AS for each registered user.
> So user authentication is one important step in the protocol. It shall be
> handled using an asymmetric key pair.
>

I think user authentication is an important step, but I strongly view it is
out of scope of the protocol. There continues to be innovatio in user
authentication, and there I fail to see the value in GNAP standardizing
what an AS MUST do.


>
> A client is a piece of software and/or hardware trusted either by an
> application or by a user that interfaces on their behalf with ASs and RSs=
.
>

Given that a client is making API calls, I don't see how a client can be
hardware.


>
> An AS usually does not handle clients accounts. It may be interesting in
> some cases to make sure, from an AS point of view, that a user is indeed
> using a secure element with some specific properties. But at this time th=
e
> wording "secure element" has not been pronounced. If we would like
> to go in that direction we would need to describe APDUs (Application
> Protocol Data Units) but at this time I am not aware that the IETF has
> already
> addressed such topic.
>
> However, I got the impression that the real need is not "entity
> authentication" for the client.
> Would you explain the rational for your need, instead of the solution ?
>

A reminder that there are many other use cases for GNAP than your use case,
and that supporting existing OAuth and OpenID Connect use cases is in
scope. Often, what an AS will grant a client is dependent on which client
it is, hence the requirement for "entity authentication".


>
> I picked another sentence:
>
> A challenge with FIDO is portability across devices, as a binding is
> usually tied to a specific device.
>
> This is currently true with what the FIDO Alliance has currently
> published, but this can be solved.
>

Maybe, but it is out of scope of GNAP, and I don't think we should design a
protocol based on what we would like another standards body to do.

/Dick
=E1=90=A7

--0000000000000f7c2e05aaa70812
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Comments inline ...=C2=A0

On Fri, Jul 17, 2020 at 9:09=
 AM Denis <denis.ietf@free.fr&=
gt; wrote:

 =20
   =20
 =20
  

    
Hi Dick,

    


    

    
I picked three of your sentences below
      :

    

      

        
It appears you are mixing client identifiers and user
          identifiers, as well as user authentication at a AS, and
          client authentication at an AS. 

          User authentication at the AS is out of scope of GNAP as I
          understand it (there are lots of existing mechanisms that work
          fine). 

          Client authentication to the AS is in scope.

      

      
An AS needs to authenticate users in order to relate them to
        their attributes: there is a user account at the AS for each
        registered user.

      
So user authentication is one important step in the protocol.
        It shall be handled using an asymmetric key pair.
=


I think user authentication is an importan=
t step, but I strongly view it is out of scope of the protocol. There conti=
nues to be innovatio in user authentication, and there I fail to see the va=
lue in GNAP standardizing what an AS MUST do.
=C2=A0

      


      

      
A client is a piece of software and/or hardware trusted
        either by an application or by a user that interfaces on their
        behalf with ASs and RSs.
Given that a client is making API calls, I don't see how a =
client can be hardware.
=C2=A0

        

        An AS usually does not handle clients accounts. It may be
        interesting in some cases to make sure, from an AS point of
        view, that a user is indeed 

        using a secure element with some specific properties. But at
        this time the wording "secure element" has not been prono=
unced.
        If we would like 

        to go in that direction we would need to describe APDUs
        (Application Protocol Data Units) but at this time I am not
        aware that the IETF has already 

        addressed such topic.=C2=A0 

      

      


      

      
However, I got the impression that the real need is not
        "entity authentication" for the client. 

        Would you explain the rational for your need, instead of the
        solution ?=C2=A0 

=

A reminder that there are many other use cases for GNAP than your use =
case, and that supporting existing OAuth and OpenID Connect use cases is in=
 scope. Often, what an AS will grant a client is dependent on which client =
it is, hence the requirement for "entity authentication".
=C2=A0
=


      

      


      

      
I picked another sentence:

      

        
A challenge with FIDO is portability across devices, as a
          binding is usually tied to a specific device.

      

      
This is currently true with what the FIDO Alliance has
        currently published, but this can be solved.
<=
/blockquote>

Maybe, but it is out of scope of GNAP, and =
I don't think we should design a protocol based on what we would like a=
nother standards body to do.
=C2=A0
/Dick
3D""=E1=90=A7


--0000000000000f7c2e05aaa70812--


From nobody Fri Jul 17 11:12: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 6F50E3A0A19 for ; Fri, 17 Jul 2020 11:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.54
X-Spam-Level: 
X-Spam-Status: No, score=-0.54 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_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 UAvg7BkWVTFE for ; Fri, 17 Jul 2020 11:12:20 -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 D40B03A0A11 for ; Fri, 17 Jul 2020 11:12:19 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id e4so13728458ljn.4 for ; Fri, 17 Jul 2020 11:12: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=8F41mdT6CQ3ykr71nJm4wYy/Lxe4JHvFirVvVtVzgEo=; b=cB5k69xVr3dHqJuZMiWCRoowM3g2hJbQ85wFICHq1aBAw2ddFHxfHw66OG/FVHczEo 9xeRQ9H5VqVLwAR9XZyjUzxi0RBnof2YKKS27m50m+zwRvDBkRqL8kbJCjpKneVZIGnC Lcejpz3jGcLoaGdASiaGBzDtb3Gd3sUOrCEKyrnb3h/CzSwCyWOQ05aOgJ3W8OFjilgf uC1MY2Zap/InSlXjTgDLTsan1sswyhvErxX8DlVnvS/5z61JhZa6Xn72rmFO8UvXof4E OE4rs1xRryeuebylcap6Bpyzdhfu2R4SwK56LOKW3D28RE/gygcFKKc5VcDNovi1p/Rr XdoQ==
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=8F41mdT6CQ3ykr71nJm4wYy/Lxe4JHvFirVvVtVzgEo=; b=ftB8++cTzVXqsGcURkt4BHIc+E6QiQZC35dIIrwtY0dCVocLpHapkT7SEyM4d1rePz h+XFgya4IQoMxVDvAbZIbarTVu2FXWhjmqSDzoegczx8e+OSYCqLWxwzEm1/1vWd92WU hDvDr7ZdXScEEPkt3Owi03tzQ8obuWnMOFVKD4TL9JzToyx9SfLIxBQkULjpN6VBSi3E XpvZB0iZQoKphw2VC5IKcIsWdgqmRQE9jvdautW2mBF4Qs+5btYVODjV9nNiWYn0a31S xyiEch4Zyb7ndv5yh9OSLGuP4Tfj/LN+yKIblfI3cdZ0kMt/i5LI9PHGIxf9hiWgoiSp wPCA==
X-Gm-Message-State: AOAM533X5s6gv5vTepsGjw0cENiDP23SvG/CnW5wSRV+WtMhii0w2rQQ Ft/KSveAnCKfG9Qv57lwgy1xrdHVThqVPhJrylw=
X-Google-Smtp-Source: ABdhPJwsuzXFeCmy9qzCeE2OfKOWzUEOsYPhdKL/DjQDRyZbPHeZMCRGu/4pA9zxAPRF5Ergvta7pdjoVHldCTiKj/s=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr5215843ljg.69.1595009537806; Fri, 17 Jul 2020 11:12:17 -0700 (PDT)
MIME-Version: 1.0
References:             
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 17 Jul 2020 11:11:41 -0700
Message-ID: 
To: Denis 
Cc: Francis Pouatcha , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ea1ab705aaa7182e"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 17 Jul 2020 18:12:21 -0000

--000000000000ea1ab705aaa7182e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:

> Hello Francis and Dick,
>
> The good news first: we are making some progress. We are now close to an
> agreement with steps (1) up to (3),
> ... except that the place where the user consent is captured is not
> mentioned/indicated.
>
> If a RO needs to be involved and since a RO is directly associated with a
> RS, why can't it be directly queried
> by the appropriate RS after step (2) or later on ?
>

Good question. Perhaps you can expand on a use case where that would be
useful?


>
> Which information is supposed to be presented to the RO ?
> Which information is supposed to be returned by the RO ?
>

Just like how the user authenticates to an AS, how the AS and RO
communicate is out of scope. For many use cases, the User is the RO, and
the interaction is through a user interface, not a machine protocol.
=E1=90=A7

--000000000000ea1ab705aaa7182e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Jul 17, 2020 at 9:21 AM Denis=
 <denis.ietf@free.fr> wrote=
:

 =20
   =20
 =20
  

    
Hello Francis and Dick,

    


    

    
The good news first: we are making some
      progress. We are now close to an agreement with steps (1) up to
      (3), 

      ... except that the place where the user consent is captured is
      not mentioned/indicated.

    


    

    
If a RO needs to be involved and since
      a RO is directly associated with a RS, why can't it be directly
      queried 

      by the appropriate RS after step (2) or later on ?

Good question. Perhaps you can expand on a use ca=
se where that would be useful?
=C2=A0

    


    

    
Which information is supposed to be
      presented to the RO ?

      Which information is supposed to be returned by the RO ?
<=
/blockquote>

Just like how the user authenticates to an =
AS, how the AS and RO communicate is out of scope. For many use cases, the =
User is the RO, and the interaction is through a user interface, not a mach=
ine protocol.=C2=A0
3D""=E1=90=A7


--000000000000ea1ab705aaa7182e--


From nobody Fri Jul 17 14:36: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 5EC0B3A07EE for ; Fri, 17 Jul 2020 14:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.081
X-Spam-Level: 
X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 6SResr45nXCH for ; Fri, 17 Jul 2020 14:36: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 539F93A07E3 for ; Fri, 17 Jul 2020 14:36:48 -0700 (PDT)
Received: from [192.168.1.3] (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 06HLaF5C020730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jul 2020 17:36:46 -0400
From: Justin Richer 
Message-Id: <5B2BF4E7-77CD-4DC6-A0C9-E7894CE38A5E@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EDA524C4-98FB-4D7E-AB06-0BE02C32822D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 17 Jul 2020 17:34:10 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:  
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] New version of XYZ Draft
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, 17 Jul 2020 21:36:50 -0000

--Apple-Mail=_EDA524C4-98FB-4D7E-AB06-0BE02C32822D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Most of these are changes I=E2=80=99ve wanted to do for quite some time =
and finally had opportunity to make the edits. As I said below, the core =
protocol really hasn=E2=80=99t changed in nature, but hopefully it=E2=80=99=
s easier to understand with it laid out in this way.=20

All of these are points that I=E2=80=99ve made previously on the list in =
discussions, but to answer your questions directly:

- Mapping items to separate URLs has been on XYZ=E2=80=99s radar since =
well before it was proposed in Xauth, so this is bringing some of that =
into the concrete system. I still need to implement it to see how well =
it works in practice.

- The need to rotate the reference handle as well as use it externally =
(the =E2=80=9Cextend a request=E2=80=9D method) both call for having an =
identifier separate from the access URL. It also allows an AS more =
freedom in how it manages its endpoints, and aligns with the desire to =
push more information into the ongoing request after the initial phase. =
I=E2=80=99d actually rather the access token management move in that =
direction, using the token itself as the artifact, but I couldn=E2=80=99t =
do that and still use the DELETE method for revocation. So that=E2=80=99s =
an engineering challenge that I think the group should discuss, and =
decide whether it=E2=80=99s worth having the =E2=80=9CDELETE=E2=80=9D =
verb semantics and having that restriction placed on the AS as a =
consequence.

- The DID work is likely better suited for an extension, and always has =
been. But it was worth having in previous revisions for discussion =
purposes, especially as a point around how a non-HTTP interaction method =
would work. I expect to see DIDCOMM, CHAPI, WebAuthN, and other =
interaction methods in the extensions landscape of GNAP, usable =
alongside the others.=20

And a final point, the interaction setup hasn=E2=80=99t really changed, =
so I=E2=80=99m curious to hear what you think has changed there. Even =
with a couple new capabilities on the way there (short_uri and app) and =
back (pushback), It=E2=80=99s structurally and conceptually identical to =
previous revisions.

 =E2=80=94 Justin

> On Jul 17, 2020, at 1:10 PM, Dick Hardt  wrote:
>=20
> Hey Justin,
>=20
> Glad to see that you are aligning on having URIs for the access tokens =
and the "grant".
>=20
> While the token URI is unique to the token, you have not done the same =
for a "grant", but have a handle and a non-unique URI.
>=20
> Why not have a unique grant URI similar to the token URI? (a =
combination of the handle and a non-unique URI) -- this is then both the =
identifier, and the URL for "management"?
>=20
> Glad to see you have excised the DID references. I don't think the =
common use cases are well established there currently.
>=20
> I have LOTS of feedback on your interaction changes, that I'll post =
later on, and hope that others have feedback on those as well.
>=20
> /Dick
>=20
>=20
>=20
>=20
>=20
> On Thu, Jul 16, 2020 at 2:52 PM Justin Richer > wrote:
> Hi all,
>=20
> I=E2=80=99ve updated the XYZ draft specification. Since the =
publication tools are currently locked prior to the upcoming virtual =
meeting, I have published it online here:
>=20
> https://oauth.xyz/draft-richer-transactional-authz =

>=20
> This represents a pretty significant refactoring of the specification, =
hopefully to make the concepts and capabilities easier to understand. =
The core protocol is largely the same as before, but there are a number =
of serious updates:
>=20
>  - Continuation requests happen at a URL returned in the TX response. =
The =E2=80=9Chandle=E2=80=9D is still sent as one of the input values =
here, since the handle can also be used it other contexts.
>  - Tokens now can include the resources they are issued for
>  - Tokens can have an optional management URI for rotation and =
revocation.
>  - =E2=80=9Cclaims=E2=80=9D has been removed in favor of =E2=80=9Csubjec=
t=E2=80=9D dealing directly with identifiers and assertions
>  - the =E2=80=9Cuser=E2=80=9D request and response now align with =
identifiers and assertions
>  - Extensions and registries are more clearly enumerated throughout =
the document
>  - DID-related items have been excised in deference to a future =
possible extension
>  - Added a =E2=80=9Cpushback=E2=80=9D mechanism to complement the =
=E2=80=9Ccallback=E2=80=9D mechanism
>  - Simplified dynamic handle returns and access tokens based on =
developer feedback (basically we dropped a bunch of =E2=80=9Cwhat if=E2=80=
=9D stuff that nobody used or liked, like SHA3 hashes for bearer tokens)
>=20
> I=E2=80=99ve also updated the interactive examples on =
https://oauth.xyz/  to match this new draft. =
Hopefully it=E2=80=99s consistent with the draft text.
>=20
> I have not yet, however, updated any of the implementations of XYZ to =
take the elements of new syntax into account, so there might be some =
more changes prior to the IETF meeting as I realize what terrible =
mistakes I=E2=80=99ve made when doing that. :)=20
>=20
> Feedback, as always, is welcomed, and thanks to everyone who=E2=80=99s =
provided input to the project to date.=20
>=20
>  =E2=80=94 Justin
> --=20
> Txauth mailing list
> Txauth@ietf.org 
> https://www.ietf.org/mailman/listinfo/txauth =



--Apple-Mail=_EDA524C4-98FB-4D7E-AB06-0BE02C32822D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Most of these are changes I=E2=80=99ve wanted to do for quite =
some time and finally had opportunity to make the edits. As I said =
below, the core protocol really hasn=E2=80=99t changed in nature, but =
hopefully it=E2=80=99s easier to understand with it laid out in this =
way. 

All =
of these are points that I=E2=80=99ve made previously on the list in =
discussions, but to answer your questions directly:

- Mapping items to =
separate URLs has been on XYZ=E2=80=99s radar since well before it was =
proposed in Xauth, so this is bringing some of that into the concrete =
system. I still need to implement it to see how well it works in =
practice.

- =
The need to rotate the reference handle as well as use it externally =
(the =E2=80=9Cextend a request=E2=80=9D method) both call for having an =
identifier separate from the access URL. It also allows an AS more =
freedom in how it manages its endpoints, and aligns with the desire to =
push more information into the ongoing request after the initial phase. =
I=E2=80=99d actually rather the access token management move in that =
direction, using the token itself as the artifact, but I couldn=E2=80=99t =
do that and still use the DELETE method for revocation. So that=E2=80=99s =
an engineering challenge that I think the group should discuss, and =
decide whether it=E2=80=99s worth having the =E2=80=9CDELETE=E2=80=9D =
verb semantics and having that restriction placed on the AS as a =
consequence.

- =
The DID work is likely better suited for an extension, and always has =
been. But it was worth having in previous revisions for discussion =
purposes, especially as a point around how a non-HTTP interaction method =
would work. I expect to see DIDCOMM, CHAPI, WebAuthN, and other =
interaction methods in the extensions landscape of GNAP, usable =
alongside the others. 

And a final point, the interaction setup hasn=E2=80=99t =
really changed, so I=E2=80=99m curious to hear what you think has changed there. Even with a couple new capabilities on =
the way there (short_uri and app) and back (pushback), It=E2=80=99s =
structurally and conceptually identical to previous revisions.

 =E2=80=94 =
Justin

On Jul 17, 2020, at 1:10 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

Hey Justin,

Glad to see that you are =
aligning on having URIs for the access tokens and the =
"grant".

While =
the token URI is unique to the token, you have not done the same =
for a "grant", but have a handle and a non-unique URI.

Why not have a unique =
grant URI similar to the token URI? (a combination of the handle and a =
non-unique URI) -- this is then both the identifier, and the URL for =
"management"?

Glad to see you have excised the DID references. I don't =
think the common use cases are well established there =
currently.

I =
have LOTS of feedback on your interaction changes, that I'll post =
later on, and hope that others have feedback on those as well.

/Dick





On Thu, Jul 16, 2020 at 2:52 PM Justin =
Richer <jricher@mit.edu> wrote:
Hi all,

I=E2=80=99ve updated the XYZ draft specification. Since the =
publication tools are currently locked prior to the upcoming virtual =
meeting, I have published it online here:

https://oauth.xyz/draft-richer-transactional-authz

This represents a =
pretty significant refactoring of the specification, hopefully to make =
the concepts and capabilities easier to understand. The core protocol is =
largely the same as before, but there are a number of serious =
updates:

 -=
 Continuation requests happen at a URL returned in the TX response. The =
=E2=80=9Chandle=E2=80=9D is still sent as one of the input values here, =
since the handle can also be used it other contexts.
 - Tokens now can include the resources they are issued =
for
 - Tokens can have an optional management =
URI for rotation and revocation.
 - =
=E2=80=9Cclaims=E2=80=9D has been removed in favor of =E2=80=9Csubject=E2=80=
=9D dealing directly with identifiers and assertions
 - the =E2=80=9Cuser=E2=80=9D request and response now =
align with identifiers and assertions
 - =
Extensions and registries are more clearly enumerated throughout the =
document
 - DID-related items have been =
excised in deference to a future possible extension
 - Added a =E2=80=9Cpushback=E2=80=9D mechanism to =
complement the =E2=80=9Ccallback=E2=80=9D mechanism
 - Simplified dynamic handle returns and access tokens =
based on developer feedback (basically we dropped a bunch of =E2=80=9Cwhat=
 if=E2=80=9D stuff that nobody used or liked, like SHA3 hashes for =
bearer tokens)

I=E2=80=99ve also updated the interactive examples on https://oauth.xyz/ to match this new draft. =
Hopefully it=E2=80=99s consistent with the draft text.

I have not yet, however, =
updated any of the implementations of XYZ to take the elements of new =
syntax into account, so there might be some more changes prior to the =
IETF meeting as I realize what terrible mistakes I=E2=80=99ve made when =
doing that. :) 

Feedback, as always, is welcomed, and thanks to everyone =
who=E2=80=99s provided input to the project to date. 

 =E2=80=94 =
Justin
-- 

Txauth mailing list

Txauth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth
=





=

--Apple-Mail=_EDA524C4-98FB-4D7E-AB06-0BE02C32822D--


From nobody Fri Jul 17 15:47: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 7B7FE3A0AA1 for ; Fri, 17 Jul 2020 15:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.097
X-Spam-Level: 
X-Spam-Status: No, score=-0.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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, 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 uhINNK34dYCK for ; Fri, 17 Jul 2020 15:47:27 -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 3AA373A0AA2 for ; Fri, 17 Jul 2020 15:47:27 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id e4so14448156ljn.4 for ; Fri, 17 Jul 2020 15:47: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=fX+Uilvt+n3f6R5UmxF/5D6unCczKgXcFM+gAXBDoLg=; b=nmNLt8JN3+4OQMIDq+49pGhcohKNaIGIFfa+XTxl/kva6iuSJ7XmULaelozcgIIg/U j8cbdkqb5Mggy840BevAIWOb8py486HDyxc1008WqZwXxnL6ku57g5+kHNOG1UeQYgmV aLbzE/nCeXPkAFHNCap0AaconoWHPCT9RSdwrRUg87Gxmt38N42iJdGLnYp1szyeIA09 PfQQjab732l3p954TKalR8fUz22S6tgFCcmTYBb4LSUWh+bmFeo+eErHd44vUgWr0W/Z nCbJ2M6MlTVw2clqDySZhr53IPmPXo9OPyUdh8qGu/5XTzlZVVcwfvHjzdSL7meNfzRT tNKA==
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=fX+Uilvt+n3f6R5UmxF/5D6unCczKgXcFM+gAXBDoLg=; b=ECnsKf1VS41ARxGJIXu8zlSdEyxchi97cDMdIXlERwEYnPc/EkpMbLShaT3nxcmUsy 6YNJXIsgCEJ7Mr3F9knaChgLMpPkNPrIKEbrvn2p0hi72CIG87MnMUgAHmyKNPdP3/yM ThB75zDW2E0LDxWpkouHKAcUb4HP/eCUDiYt6NaOgX4wZdxeVsHUvzRKDsC1KOV010IA 1zXGEq6iLV7eweG7F5IZkEisLGlzs5xSBuBiujA3OyMFJ9nTxIaBs459e0NU/ipbf6kR jm/liFSgF0xdf1QQHQC9GlSMSRd4dGoeAZ3G65btxTvJAys7cxn9bYHG6EaHJh1uOprj yf2A==
X-Gm-Message-State: AOAM530V8+m8BaTksVtrX5rspcHoFbLripoY+v7W1KWzwcJU9xaCdX1L Jl+O5bAvUQoQC8H3bqfbVJ3leUATMZ/5+9KOvBM=
X-Google-Smtp-Source: ABdhPJwrkbE17IhxEVzygo2kXi4ML1gJItjQh0OTziY1gakpY9x/eKPrbTsXR22Z355Y0jFMaV5ZPB3lTrXJbE+7XFw=
X-Received: by 2002:a2e:b70b:: with SMTP id j11mr5435478ljo.142.1595026045143;  Fri, 17 Jul 2020 15:47:25 -0700 (PDT)
MIME-Version: 1.0
References:   <5B2BF4E7-77CD-4DC6-A0C9-E7894CE38A5E@mit.edu>
In-Reply-To: <5B2BF4E7-77CD-4DC6-A0C9-E7894CE38A5E@mit.edu>
From: Dick Hardt 
Date: Fri, 17 Jul 2020 15:46:48 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d40f3905aaaaf08a"
Archived-At: 
Subject: Re: [Txauth] New version of XYZ Draft
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, 17 Jul 2020 22:47:29 -0000

--000000000000d40f3905aaaaf08a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

XYZ is looking a lot more like XAuth, similar to how XAuth has shifted
towards XYZ.

I have implemented separate URIs for grants and authorizations, and it
worked really well.

All 3 of the new capabilities are problematic. Perhaps you did not notice
that there no longer is a short_uri in XAuth? As I recall, you were opposed
to the short URI that was in the earlier drafts of XAuth. In my XAuth
implementation, I show QR codes in the CLI app. Have you checked out my
implementation? Have you implemented a QR code? I found that the string did
not need to be nearly as short as it has in the past.

I still don't understand the requirement to rotate the reference handle. I
read over the pointer you provided last time we discussed it, and
responded, but I have not heard back from you on that.


=E1=90=A7

On Fri, Jul 17, 2020 at 2:36 PM Justin Richer  wrote:

> Most of these are changes I=E2=80=99ve wanted to do for quite some time a=
nd
> finally had opportunity to make the edits. As I said below, the core
> protocol really hasn=E2=80=99t changed in nature, but hopefully it=E2=80=
=99s easier to
> understand with it laid out in this way.
>
> All of these are points that I=E2=80=99ve made previously on the list in
> discussions, but to answer your questions directly:
>
> - Mapping items to separate URLs has been on XYZ=E2=80=99s radar since we=
ll before
> it was proposed in Xauth, so this is bringing some of that into the
> concrete system. I still need to implement it to see how well it works in
> practice.
>
> - The need to rotate the reference handle as well as use it externally
> (the =E2=80=9Cextend a request=E2=80=9D method) both call for having an i=
dentifier separate
> from the access URL. It also allows an AS more freedom in how it manages
> its endpoints, and aligns with the desire to push more information into t=
he
> ongoing request after the initial phase. I=E2=80=99d actually rather the =
access
> token management move in that direction, using the token itself as the
> artifact, but I couldn=E2=80=99t do that and still use the DELETE method =
for
> revocation. So that=E2=80=99s an engineering challenge that I think the g=
roup
> should discuss, and decide whether it=E2=80=99s worth having the =E2=80=
=9CDELETE=E2=80=9D verb
> semantics and having that restriction placed on the AS as a consequence.
>
> - The DID work is likely better suited for an extension, and always has
> been. But it was worth having in previous revisions for discussion
> purposes, especially as a point around how a non-HTTP interaction method
> would work. I expect to see DIDCOMM, CHAPI, WebAuthN, and other interacti=
on
> methods in the extensions landscape of GNAP, usable alongside the others.
>
> And a final point, the interaction setup hasn=E2=80=99t really changed, s=
o I=E2=80=99m
> curious to hear what you think *has* changed there. Even with a couple
> new capabilities on the way there (short_uri and app) and back (pushback)=
,
> It=E2=80=99s structurally and conceptually identical to previous revision=
s.
>
>  =E2=80=94 Justin
>
> On Jul 17, 2020, at 1:10 PM, Dick Hardt  wrote:
>
> Hey Justin,
>
> Glad to see that you are aligning on having URIs for the access tokens an=
d
> the "grant".
>
> While the token URI is unique to the token, you have not done the same fo=
r
> a "grant", but have a handle and a non-unique URI.
>
> Why not have a unique grant URI similar to the token URI? (a combination
> of the handle and a non-unique URI) -- this is then both the identifier,
> and the URL for "management"?
>
> Glad to see you have excised the DID references. I don't think the common
> use cases are well established there currently.
>
> I have LOTS of feedback on your interaction changes, that I'll post later
> on, and hope that others have feedback on those as well.
>
> /Dick
>
>
>
>
>
> On Thu, Jul 16, 2020 at 2:52 PM Justin Richer  wrote:
>
>> Hi all,
>>
>> I=E2=80=99ve updated the XYZ draft specification. Since the publication =
tools are
>> currently locked prior to the upcoming virtual meeting, I have published=
 it
>> online here:
>>
>> https://oauth.xyz/draft-richer-transactional-authz
>>
>> This represents a pretty significant refactoring of the specification,
>> hopefully to make the concepts and capabilities easier to understand. Th=
e
>> core protocol is largely the same as before, but there are a number of
>> serious updates:
>>
>>  - Continuation requests happen at a URL returned in the TX response. Th=
e
>> =E2=80=9Chandle=E2=80=9D is still sent as one of the input values here, =
since the handle
>> can also be used it other contexts.
>>  - Tokens now can include the resources they are issued for
>>  - Tokens can have an optional management URI for rotation and revocatio=
n.
>>  - =E2=80=9Cclaims=E2=80=9D has been removed in favor of =E2=80=9Csubjec=
t=E2=80=9D dealing directly with
>> identifiers and assertions
>>  - the =E2=80=9Cuser=E2=80=9D request and response now align with identi=
fiers and
>> assertions
>>  - Extensions and registries are more clearly enumerated throughout the
>> document
>>  - DID-related items have been excised in deference to a future possible
>> extension
>>  - Added a =E2=80=9Cpushback=E2=80=9D mechanism to complement the =E2=80=
=9Ccallback=E2=80=9D mechanism
>>  - Simplified dynamic handle returns and access tokens based on develope=
r
>> feedback (basically we dropped a bunch of =E2=80=9Cwhat if=E2=80=9D stuf=
f that nobody used
>> or liked, like SHA3 hashes for bearer tokens)
>>
>> I=E2=80=99ve also updated the interactive examples on https://oauth.xyz/=
 to
>> match this new draft. Hopefully it=E2=80=99s consistent with the draft t=
ext.
>>
>> I have not yet, however, updated any of the implementations of XYZ to
>> take the elements of new syntax into account, so there might be some mor=
e
>> changes prior to the IETF meeting as I realize what terrible mistakes I=
=E2=80=99ve
>> made when doing that. :)
>>
>> Feedback, as always, is welcomed, and thanks to everyone who=E2=80=99s p=
rovided
>> input to the project to date.
>>
>>  =E2=80=94 Justin
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
>

--000000000000d40f3905aaaaf08a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


XYZ is looking a lot more like XAuth, similar to how XAuth=
 has shifted towards XYZ.=C2=A0

I have implemented separ=
ate URIs for grants and authorizations, and it worked really well.

All 3 of the new capabilities are problematic. Perhaps you=
 did not notice that there no longer is a short_uri in XAuth? As I recall, =
you were opposed to the short URI that was in the earlier drafts of XAuth. =
In my XAuth implementation, I show QR codes in the CLI app. Have you checke=
d out my implementation? Have you implemented a QR code? I found that the s=
tring did not need to be nearly as short as it has in the past.=C2=A0
=


I still don't understand the requirement to rotate =
the reference handle. I read over the pointer you provided last time we dis=
cussed it, and responded, but I have not heard back from you on that.
=



3D""=E1=90=A7

On Fri, Jul 17=
, 2020 at 2:36 PM Justin Richer <jric=
her@mit.edu> wrote:


--000000000000d40f3905aaaaf08a--


From nobody Fri Jul 17 23:15: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 7D50F3A0C2E for ; Fri, 17 Jul 2020 23:15: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 4IHPy5bPhazQ for ; Fri, 17 Jul 2020 23:15:11 -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 3C14C3A0C2A for ; Fri, 17 Jul 2020 23:15:11 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id e64so12593344iof.12 for ; Fri, 17 Jul 2020 23:15: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=U5I/8gfLLOmAx3oQEhjnvSKwNXveu3IbHuL9S0YqOr8=; b=cXm/chl3WA+tLLHnA6drOTWrjhbmIDFrCZChVsmOmk3fzfulzdbUaAEWysPHREmjfi 0BodJXxNtGsRo2qMdPkv6lJBnJ5P0StcUnZMZwb5RHZFnT3JtJJuIZda3t76t4oKT09+ GaX8ug0nrsC3RZG+rCOC19LdUYgCcS/BdxvdjbQciddva6SAVflVRNZHoovqVUnjRte/ qjAc4ckl32/YHzvrXptLwqQnLSfgijY5Ff9yUuws2a/OOSp8ZIL5trk/Rpp75kaJjhU/ IHWooOmmogaXifgRxifihIk1Gdq9YYcaFFaagKvrSaL9uy23gegti4mD5/dFPkl0yN91 rcQw==
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=U5I/8gfLLOmAx3oQEhjnvSKwNXveu3IbHuL9S0YqOr8=; b=cSWv6hqsiM4wRPtX7tkVtsGaICeInzGAeoK8lXIWnIe0Xwcjt9ayAK0MQatmjz2v9k hV12kTG+V5zfI/+mR0YXVOD+O9sDhOphVc1qOYU2e2IZrip50vYapsCtidWHVOZgP48j O8NQ2+QttFbmwnn543Sgo3gNd0ekidonqnPC12k0JRL7sJneMOFE7NZIJVbHOAcOU4a1 OFfVUwepJr12ZeYP5yj+jNte32DMQlM/TyutHzy32iLg6SMiexOFLmAWdb9XE6Hi8wwv X43MA6pjm1YRV2qQ6usSJjYyOXEzV0NLSxHqffQ7XYt2ZEKz0VTa3axs1q2tIrZqBhyF dwCg==
X-Gm-Message-State: AOAM531Q2OAsvIOMHx0GsJhzYd4FwoGEtewS0aqIfPu7gc1x4+2X3IMo 2B78fs/WuloZUiRVcKTW3l0vwoqCwvqF6uM0yuI=
X-Google-Smtp-Source: ABdhPJwvuLvWDPUSvZzm6HQpDbqu3cZahRfes2AFQbQHPi9izgAv0/SUcZGstqnV8WQPYmGTPunWjy7zsUSiOH70gSc=
X-Received: by 2002:a02:1a06:: with SMTP id 6mr14992385jai.8.1595052910277; Fri, 17 Jul 2020 23:15:10 -0700 (PDT)
MIME-Version: 1.0
References:  <382b5f57-6825-3537-c66b-fb2c38e5140c@free.fr>    <49ff9f53-6f75-6bd7-f09f-2ac8c2bc5ba2@free.fr>
In-Reply-To: <49ff9f53-6f75-6bd7-f09f-2ac8c2bc5ba2@free.fr>
From: Fabien Imbault 
Date: Sat, 18 Jul 2020 08:14:57 +0200
Message-ID: 
To: Denis 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001d761205aab1329d"
Archived-At: 
Subject: Re: [Txauth] A model with a User Consent Element (with a clean figure)
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, 18 Jul 2020 06:15:15 -0000

--0000000000001d761205aab1329d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Denis. I think that's clear.

By "we", I meant myself and a few colleagues. So far it's just a bunch of
quick MVPs and it's expected to grow overtime as an independant opensource
implementation. I think it's important we take the specs and try to
implement them to make sure it's easily understandable by external devs.

Fabien

Le ven. 17 juil. 2020 =C3=A0 18:16, Denis  a =C3=A9crit=
 :

> Hi Fabien,
>
> Thanks Denis for your answers.
>
> I think what you call delegation is a slightly different requirement than
> how the term is generally used in our context.
> Instead of delegation, I would rather suggest to call it a "resource
> chain" (and as in any supply chain, those could come from different
> parties).
>
> Whatever you call it, I believe that the model should be able to support
> it.
>
> I think the privacy concern is important, and it would be interesting to
> get back to prior art on the issue.
> for instance, https://github.com/samuelgoto/WebID provides an interesting
> analysis on RP or IdP collusion
> (here more focused on the ID part), a similar vein of work may enable
> richer discussions whether/when the GS
> is the right place for user consent, or not.
>
> The way and the place the user consent is captured is indeed critical.
>
> Then on user consent : implementations of XYZ do handle user consent. In
> our case, we've also decoupled the consent part (as a separate project).
>
> You are using the word "we". Do you mean that you are part of the design
> team or of the implementers team of XYZ ?
>
> Initially we did that to simplify the implementation of the AS core flow
> (between client and AS), while covering the UX requirements in a
> separate project.
> But the nice thing about that is that it doesn't change the core flow, an=
d
> depending on the use case, one may either place it on the AS part (as we'=
ve
> implemented so far,
> and as most people would do today) or on the client part (as you think it
> should be). This demonstrates that depending how we assemble parts, we ma=
y
> end up
> with a solution that may fit various requirements.
>
> In addition to the place where the user consent is captured, there is the
> need to consider the assurances that the user can obtain about the respec=
t
> of his choices.
>
> I have explained that such assurance can be obtained when the choice is
> made by the client and when the returned access tokens are not considered
> to be opaque to the client.
> It is also obvious that the GS/AS is kept ignorant of the proposed choice=
s
> and is only informed about which user attributes should be inserted into
> the access token.
>
> At this time, no equivalent explanations have been provided when/if the
> user consent interface is handled by the GS/AS.
>
> Denis
>
>
> Fabien
>
> On Mon, Jul 13, 2020 at 10:40 AM Denis  wrote:
>
>> Hi Fabien,
>>
>> Thank you for your responses. Rather than responding in the text, I will
>> pick up two of your comments:
>>
>> FI : as far as I'm concerned, there are many more interactions than
>> Oauth/XYZ/Xauth.
>> Your view seems to be that it is simpler because AS are way less central=
,
>> but it seems to me
>> that RS are much more complex to implement correctly.
>>
>> In XYZ/Xauth there is a protocol needed between the GS and many ROs. Thi=
s
>> protocol is "out of the scope" of these drafts and this is where the
>> complexity is hidden.
>> So it looks simpler for the client but it is much more complicated for
>> the management of the delegation at the GS. This also makes the assumpti=
on
>> that a single GS
>> will be able to handle the delegation case because all the RSs are
>> supposed to be in the same domain which is a very restrictive case. My
>> proposal is able to handle
>> the multi-domain case.
>>
>> Every RS is best placed to know where to forward an operation when it
>> can't respond to it of its own. A RO should not need to inform a GS to t=
ell
>> what its relationships
>> with other RSs are. A GS should not be in a position to know everything
>> about the relationships between RSs and to be informed in real time of a=
ny
>> change about these
>> relationships.
>>
>> In term of trust, I mentioned:
>>
>>    - If a user has an account opened with an AS, then he trusts that AS
>>    to deliver the requested and genuine attributes into an access token.
>>
>> This is it. There is no other trust relationship. The user does not trus=
t
>> or rely on any collaboration between a RO and a GS.
>>
>>
>> A second of your comments:
>>
>> FI: if we can't do it with maximum privacy, then we won't do it; which i=
s
>> a design choice,
>>
>> I would rather say: If we can do it with maximum privacy, let us do it.
>> At this time :
>>
>>    - in draft-hardt-xauth-protocol-12, the word "privacy" does not even
>>    exist.
>>    - in draft-richer-transactional-authz-06, there is a single sentence
>>    in the privacy considerations section:
>>
>>          Handles are passed between parties and therefore should be
>> stateful and not contain any internal structure or information,
>>          which could leak private data.
>>
>> About the user consent. At this time :
>>
>>    - in draft-richer-transactional-authz-06, the user consent is never
>>    addressed.
>>    - in draft-hardt-xauth-protocol-12, the user consent is captured by
>>    the GS whereas it should be captured by the Client.
>>
>>          The client has no way to verify that the user consent has indee=
d
>> been followed by the GS because the client
>>          cannot verify that what happens "behind the scenery" at the GS
>> is conformant with what the user has consented.
>>
>> Denis
>>
>> Hi Denis,
>>
>> Thanks for your answer.
>>
>> My comments are embedded in the text, marked with FI.
>>
>> Fabien
>>
>>
>> Le ven. 10 juil. 2020 =C3=A0 17:53, Denis  a =C3=A9c=
rit :
>>
>>> Hi Fabien,
>>>
>>> It would have been appreciated that you kept the original message in
>>> your response. I have copied it again at the end of this email.
>>>
>>
>> FI : sorry, not always easy on a mobile. Will make sure that's the case
>> next time.
>>
>>>
>>> Comments are between the lines.
>>>
>>> Hi Denis,
>>>
>>> I think it's interesting, but also very different to XYZ/XAuth so it
>>> raises many questions ;-)
>>> The figure is impossible to read.
>>>
>>> Use a PC. Copy and paste and then use the Courier font. On my PC (with
>>> the clear figure) it was perfect.
>>>
>>> So let me try to summarize the suggested approach, with a concrete
>>> example, to make sure we understand well:
>>>
>>> *0. The client authN to the AS (in whatever way is supported)*
>>> Ex : client is a corporate financing called "finapp". finapp contacts
>>> AS0 for authentication (say an openbanking service).
>>> User is John Doe, CFO at NeedMoney Inc. (+ other identity claims if
>>> needed, maybe some verified credential from NeedMoney Holding that John=
 is
>>> indeed CFO).
>>>
>>> *Dear John, *
>>> *to access to your finapp, please identify yourself through your
>>> prefered openbanking account.*
>>> *Thanks*
>>>
>>> If I understand you correctly,  finapp is a local application e.g. on
>>> your smartphone.
>>>
>> FI : not necessarily, the client could be a mobile app, a web app, etc.,
>> making api calls to backend protected services.
>>
>>> *1. The client contacts a RS in a discovery phase, which includes the
>>> selection of (at least) an operation, for which the RS returns the requ=
ired
>>> authZ attributes *
>>> Ex : finapp needs to use NeedMoney's data to evaluate how much credit i=
t
>>> can offer.
>>>
>>> Op1 : compute the credit rating, from RS1 (this is outsourced to an
>>> external credit analyst), through the external service's own AS1.
>>> But to do that, RS needs your historic bank statements.
>>> Op2 : get your list of banks, RS2 (as registered within finapp),
>>> through openbanking AS0 and retrieve the bank statements :
>>> Op3a : get historic data from his main bank, RS2a (say an international
>>> bank), through openbanking AS0
>>> Op3b : same from a second bank account, RS2b (say a local bank), throug=
h
>>> openbanking AS0
>>>
>>> Why don't you make your very first example a little bit more complicate=
d
>>> ? with RS1, RS2a, RS2b, ... AS0, AS1, ...
>>>
>>> :-)
>>>
>> FI : fair point. But i believe it's important to grasp what it means on =
a
>> realistic example, especially as the proposed protocol would be very muc=
h
>> dependant on the way RS calls are made.
>>
>>>
>>> The intent of the *first *email was to discuss a *basic *model and to
>>> place the highlights on the way to capture the *user's consent*
>>> in an interoperable manner without letting know to any RS or AS the
>>> choices of the user. This is a fundamental feature of the model.
>>> In XAuth, the user's consent is not formalized in the protocol : "User
>>> consent is *often *required at the GS".
>>>
>> FI : in the context of xauth, this seems pretty clear I think.
>>
>>> *2. User consent *
>>> RS1 aggregates the list of attributes required (from all RS) and sends
>>> it to finapp.
>>>
>>> *Dear John, *
>>> *To evaluate your credit request, we need the following information: *
>>> *- your list of bank accounts (retrieved from your finapp account)*
>>> *- the associated banking statements over the past 12 months (from each
>>> bank)*
>>> *- we'll pass that data to the credit agency, which will return your
>>> credit score *
>>> *Do you agree ?*
>>>
>>> John approves (or not..., maybe he'll agree only for one specific bank)=
,
>>> via finapp directly
>>> (I like that, albeit in a more traditional flow, I'm also separating th=
e
>>> UI from the rest of the protocol of XYZ, and it works too).
>>>
>>> As described, the user could simply push to the RS the banking
>>> statements over the past 12 months (from each bank).
>>> The user consent is not about : "*Do you agree that*
>>> * we pass the data to the credit agency, which will return your credit
>>> score" *since no attributes nor ASs are involved in the question.
>>>
>> FI : this is possible of course, but pretty surprising. Today most
>> implementations are using oauth to delegate the implementation to some
>> specialized component, while here each RS would be responsible for
>> authentication. That is not an innocent choice from an implementation an=
d
>> deployment perspective.
>>
>>>
>>> I guess you want the user to get access tokens targeted for RS2x so tha=
t
>>> each bank will accept to disclose his banking statements over the past =
12
>>> months.
>>>
>>> The consent is whether the user accepts to get access tokens from some
>>> of his banks targeted for RS2x for the following operation:
>>> "Retrieval of the past 12 months banking statements" which corresponds
>>> to an API for each bank and then to send these access tokens to RS1.
>>>
>>> In practice, the client (e.g. using FIDO) will connect transparently to
>>> each of the appropriate AS from the banks and will get the requested ac=
cess
>>> tokens
>>> with a requested validity period of about 5 minutes.
>>>
>> FI : yes.
>>
>>> *3. Requests to the protected resources *
>>> The client gets the access tokens and uses the services for which acces=
s
>>> was granted.
>>>
>>> *Analysis: (maybe I didn't get everything right, if so let me know) *
>>> The trust model is focused around the relationship between the enduser
>>> (John) and his application (finapp), which seems fine.
>>>
>>> No. The trust model is not making a focus on that specific relationship=
.
>>> BTW, no access token is necessarily needed by the user to be able to us=
e
>>> finapp.
>>>
>> FI : maybe, maybe not. As soon as I want to fetch api calls, I need
>> access tokens.
>>
>>> =3D> I see some potential issues :
>>>
>>> a. it will be really difficult for an end user to understand what AS0
>>> and AS1 are, why they're different, and why he needs to authenticate to
>>> each of them.
>>> How do you enable a federated experience? (especially as there could be
>>> many)
>>>
>>> I fear that you have not fully captured what the user consent is about.
>>> See the above explanations. In addition, there is no concept of federat=
ion.
>>>
>> FI : your notion of consent is very specific to what you have in mind. I=
t
>> would require a kind of automated system to work.
>> As for the concept of federation, this is required in practice in you
>> don't hypothesize a dependancy on FIDO. The Uma2 standard is probably th=
e
>> closest to some of your ideas and focuses a lot on federation.
>>
>>> b. deciding what is the main RS (here RS1) to be called by the client
>>> seems very critical, as it is the one that needs to orchestrate everyth=
ing.
>>> This seems a very hierarchical and imperative model which seems somewha=
t
>>> counter intuitive in terms of developer experience (as least
>>> as it is made today, we clearly don't go into so much details). The cal=
l
>>> hierarchy may quickly become very complex, which may also become
>>> a problem when separate services evolve.
>>>
>>> The client calls the main RS (here RS1). What may happen next is fully
>>> dependant upon the operation that the user is willing to perform and
>>> this is unpredictable (since the back end service may change at any
>>> point of time).
>>>
>> FI : OK, but is it good engineering practice to have to deal with the
>> internals of service calls? The reason why people delegate APIs is
>> precisely to avoid that complexity. Today with OAuth, and tomorrow with
>> XYZ/Xauth, the programming model is way simpler. Privacy may be a good
>> reason to change that, but we need to be very thoughtful about that.
>>
>>> c. RS1 gets all the information required to access all sub-resources,
>>> and therefore gets also a lot of responsibility (and power). But from
>>> finapp's
>>> point of view, it is the one that has the relationship with the user an=
d
>>> is providing the core value proposition, while RS1 is just an external
>>> service.
>>>
>>>  So is it really a problem ?
>>>
>> FI : I think so. If I'm finapp, I don't want to be this dependant on RS1
>> for a lot of good and bad reasons. What I hope the example conveys is th=
at
>> there's no reason why RS1 would suddenly become the center of orchestrat=
ion
>> for all queries, while all the underlying data is actually elsewhere.
>> The fact that the proposed protocol mandates this behaviour is surprisin=
g
>> and I don't see why that is.
>>
>>> d. multi-user (common B2B scenario): John wants to authorize a read
>>> access to his finapp account to his external auditor, Ann (who is not a
>>> direct user
>>> of finapp herself, but might already be registered by openbanking AS0).
>>> How do you do that? Does it require the access token itself to be able =
to
>>> delegate rights?
>>>
>>> The intent of the short description I sent was to describe two simple
>>> scenarios, so that we could start discussing about them.
>>> At this point, the intent is not to cover all the scenarios you may
>>> dream of.
>>>
>> FI : fair point. However, as previously discussed, this is a big concern
>> as we don't know whether you think this is a valid use case or whether t=
his
>> is out of scope (so far, I understood it was more, if we can't do it wit=
h
>> maximum privacy, then we won't do it; which is a design choice, but
>> standards are usually about consensus with people that need to deal with
>> real life problems).
>>
>>> e. more generally, a threat model would be required, as there are many
>>> more interactions now.
>>>
>>> There are less interactions than in XAuth: there is no protocol between
>>> ASs and RSs, nor between ROs and ASs.
>>>
>> FI : as far as I'm concerned, there are many more interactions than
>> Oauth/XYZ/Xauth. Your view seems to be that it is simpler because AS are
>> way less central, but it seems to me that RS are much more complex to
>> implement correctly.
>>
>>>
>>> Before a threat model, a trust model is needed. Do we have a trust mode=
l
>>> for XAuth ?
>>> Unfortunately not, since the word "trust" is absent in the main body of
>>> draft-hardt-xauth-protocol-12.
>>>
>> FI : sorry but I don't need the word trust to do threat modeling...
>>
>>> In this model, the trust relationships are as follows:
>>>
>>>    - The user trusts its client.
>>>    - If a user has an account opened with an AS, then he trusts that AS
>>>    to deliver the requested and genuine attributes into an access token=
.
>>>    - A RS may trust one or more ASs for one or more types of attributes
>>>    *and* for performing a given operation.
>>>    - A RS may be administered remotely by one or more RO.
>>>
>>> *Note*: for authentication, a RS may accept either FIDO or one or more
>>> types of attributes from one or more ASs.
>>>
>> Denis
>>>
>>> Cheers,
>>> Fabien
>>>
>>>
>>> This is a new thread.
>>>
>>>
>>> Preamble: This model is quite different from the XAuth model.
>>> In particular, a RO has no relationship with any AS and a Client does
>>> not need to be associated with any AS prior to any access to a RS.
>>>
>>> A key point of this model is that the user's consent is handled locally
>>> by the Client and hence no AS nor RS is handling a man machine interfac=
e
>>> for the user consent. This allows to support locally the user consent
>>> for multiple ASs while keeping all ASs ignorant about the choices of th=
e
>>> user
>>> made for accessing a particular RS.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *       +--------+                           +------------+        |
>>> User  |                           |  Resource  |        |
>>> |                           | Owner (RO) |        +--------+
>>>                   +------------+            |
>>> \                              |            |
>>> \                             |            |
>>> \                            |            |
>>> \                           |     +-----------+     +---------------+
>>> +------------+     |           |---->| Authorization |     |           =
 |
>>>     |           | (2) |  Server (AS)  |     |            |     |
>>> |<----|               |     |            |     |  Client   |
>>> +---------------+     |            |     |
>>> |-------------------------->|  Resource  |     |   User    |
>>> (1)             |   Server   |     |  Consent
>>> |<--------------------------|    (RS)    |     |  element
>>> |                           |            |     |
>>> |-------------------------->|            |------>     |
>>> |           (3)             |            |  (4)     |
>>> |<--------------------------|            |<------
>>> +-----------+                           +------------+ *
>>> The flow of operations is as follows:
>>>
>>> The Client (which may have been previously authenticated using FIDO)
>>> contacts the RS and after some dialogue with the RS selects an operatio=
n
>>> that it wants to perform on the RS (1a). Note that it may also indicate
>>> directly the operation that it wants to perform on the RS without any p=
rior
>>> dialogue.
>>> In return (1b), the RS informs the Client about which attributes are
>>> needed by the RS for performing the requested operation and from which
>>> Attributes Servers
>>> they may be obtained.
>>>
>>> This information is specifically marked to indicate that it shall be
>>> handled by the "User Consent element" from the Client.
>>> The presentation of that information is up to the man machine interface
>>> supported by the "User Consent element" from the Client.
>>>
>>> The user can see which attributes are requested by the RS for performin=
g
>>> the requested operation and, if it consents, the Client contacts one or
>>> more
>>> appropriate Authorization Servers (2a). The user consent is hence
>>> captured locally by the Client (i.e. there is no dialogue with any AS n=
or
>>> any RS).
>>>
>>> When the Client got the access tokens from these authorization servers
>>> (2b), it sends all of them in a single request to the RS (3a).
>>>
>>> End of the story for a simple access
>>>
>>>
>>> Start of a subsequent story for a delegation case
>>>
>>> Let us now suppose that the RS is unable to fulfil the request by its
>>> own and that it needs to contact another RS. RS1 contacts RS2 (4a) and
>>> indicates the operation
>>> that it wants to perform on RS2 (that operation may not be the same as
>>> the original operation). In return (4b), RS2 informs RS1 about which
>>> attributes are needed
>>> by RS2 for performing the requested operation and from which Attributes
>>> Servers they may be obtained. RS1 forwards that information to the Clie=
nt.
>>>
>>> This information is marked to indicate that it shall be handled by the
>>> "User Consent element" from the Client. The presentation of that
>>> information is up to the man machine
>>> interface from the Client. The user can see which attributes are
>>> requested by RS2 for performing the new requested operation and, if it
>>> consents, the Client contacts one or more
>>> appropriate Authorization Servers. The user consent is hence captured
>>> locally by the "User Consent element" from the Client. (i.e. there is n=
o
>>> dialogue with any AS, nor RS1, nor RS2).
>>>
>>> When the Client got the access token(s) from the authorization
>>> server(s), it sends all of them in a single request to RS1. RS1 then
>>> forwards the additional access token(s) to RS2.
>>>
>>>
>>> Some observations:
>>>
>>> The user nor the Client are linked with any particular AS. A user may
>>> use today an AS of the Bank of America and may change tomorrow to the B=
ank
>>> of Missouri.
>>> As soon as he will be registered with the Bank of Missouri, he will be
>>> able to get access tokens from the AS of the Bank of Missouri. The AS o=
f
>>> Bank of America
>>> has not been able to know where its access tokens have been used. This
>>> will be the same for AS of the Bank of Missouri. There is no need for a=
ny
>>> direct dialogue
>>> between any AS and any RS at the time a client is making an access.
>>> There is no need for any RO to contact any AS.
>>>
>>> This model has been constructed following a "Privacy by Design" approac=
h.
>>> Denis
>>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
>

--0000000000001d761205aab1329d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Denis. I think that's clear.=C2=A0

By "we", I meant myself and a f=
ew colleagues. So far it's just a bunch of quick MVPs and it's expe=
cted to grow overtime as an independant opensource implementation. I think =
it's important we take the specs and try to implement them to make sure=
 it's easily understandable by external devs.
Fabien=C2=A0

Le ven. 17 juil. 2020 =C3=A0 18=
:16, Denis <denis.ietf@free.fr=
> a =C3=A9crit=C2=A0:

 =20
   =20
 =20
  

    
Hi Fabien,

    


    

    

     =20
      

        
Thanks Denis for your answers.
          


          

          
I think what you call delegation is a slightly different
            requirement than how the term is generally used in our
            context.

          

          
Instead of delegation, I would rather suggest to call it
            a "resource chain" (and as in any supply chain, those=
 could
            come from different parties).

        

      

    

    
Whatever you call it, I believe that the model should be able to
      support it. 

    

    

      

        

          
I think the privacy concern is important, and it would be
            interesting to get back to prior art on the issue.

          
for instance,=C2=A0https://github.com/samuelgoto/W=
ebID=C2=A0provides
            an interesting analysis on RP or IdP collusion 

            (here more focused on the ID part), a similar vein of work
            may enable richer discussions whether/when the GS 

            is the right place for user consent, or not. 

          

        

      

    

    
The way and the place the user consent is captured is indeed
      critical. 

    

    

      

        

          
Then on user consent : implementations of XYZ do handle
            user consent. In our case, we've also decoupled the consent
            part (as a separate project). 

          

        

      

    

    
You are using the word "we". Do you mean that you are part=
 of the
      design team or of the implementers team of XYZ ?

    

      

        

          
Initially we did that to simplify the implementation of
            the AS core flow (between client and AS), while covering the
            UX requirements in a separate=C2=A0project.=C2=A0

          
But the nice thing about that is that it doesn't change
            the core flow, and depending on the use case, one may either
            place it on the AS part (as we've implemented so far, 

            and as most people would do today) or on the client part (as
            you think it should be). This demonstrates that depending
            how we assemble parts, we may end up 

            with a solution that may fit various requirements.

        

      

    

    
In addition to the place where the user consent is captured,
      there is the need to consider the assurances that the user can
      obtain about the respect of his choices.

      

      I have explained that such assurance can be obtained when the
      choice is made by the client and when the returned access tokens
      are not considered to be opaque to the client.

      It is also obvious that the GS/AS is kept ignorant of the proposed
      choices and is only informed about which user attributes should be
      inserted into the access token.

      

      At this time, no equivalent explanations have been provided
      when/if the user consent interface is handled by the GS/AS.

    
Denis

    

      

        

          


          

          
Fabien

        

        

        

          
On Mon, Jul 13, 2020 at
            10:40 AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              
Hi Fabien,

              


              

              
Thank you for your responses. Rather than responding
                in the text, I will pick up two of your comments:

              

                
FI : as far as I'm concerned, there are many more
                  interactions than Oauth/XYZ/Xauth. 

                  Your view seems to be that it is simpler because AS
                  are way less central, but it seems to me 

                  that RS are much more complex to implement correctly.
                  

                

              

              
In XYZ/Xauth there is a protocol needed between the
                GS and many ROs. This protocol is "out of the scope&qu=
ot; of
                these drafts and this is where the complexity is hidden.
                

                So it looks simpler for the client but it is much more
                complicated for the management of the delegation at the
                GS. This also makes the assumption that a single GS 

                will be able to handle the delegation case because all
                the RSs are supposed to be in the same domain which is a
                very restrictive case. My proposal is able to handle 

                the multi-domain case.

              

              


              

              
Every RS is best placed to know where to forward an
                operation when it can't respond to it of its own. A RO
                should not need to inform a GS to tell what its
                relationships 

                with other RSs are. A GS should not be in a position to
                know everything about the relationships between RSs and
                to be informed in real time of any change about these

                relationships.

              


              

              
In term of trust, I mentioned:

              

                
    
                  
  • If a user has an account opened with an AS, then
                    he trusts that AS to deliver the requested and
                    genuine attributes into an access token.
    • 
                

              

              
This is it. There is no other trust relationship. The
                user does not trust or rely on any collaboration between
                a RO and a GS.

              
 

              

              


              

              
A second of your comments:

              

                
FI: if we can't do it with maximum privacy, then we
                  won't do it; which is a design choice,

              

              
I would rather say: If we can do it with maximum
                privacy, let us do it. At this time :

              
    
                
  • in draft-hardt-xauth-protocol-12, the word "privac=
y"
                  does not even exist.
    • 
                
  • in draft-richer-transactional-authz-06, there is a
                  single sentence in the privacy considerations section:
              

              
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Handles are passed betwe=
en parties and
                therefore should be stateful and not contain any
                internal structure or information, 

                =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 which could leak private =
data.

              
About the user consent. At this time :

              
    
                
  • in draft-richer-transactional-authz-06, the user
                  consent is never addressed.
    • 
                
  • in draft-hardt-xauth-protocol-12, the user consent
                  is captured by the GS whereas it should be captured by
                  the Client.
    
                
    • 
              

              
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The clien=
t has no way to verify that the user
                consent has indeed been followed by the GS because the
                client 

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cannot ver=
ify that what happens "behind the
                scenery" at the GS is conformant with what the user ha=
s
                consented.

              
 Denis

              

              

                

                  
Hi Denis,
                    


                    

                    
Thanks for your answer.=C2=A0

                    


                    

                    
My comments are embedded in the
                      text, marked with FI.=C2=A0

                    


                    

                    
Fabien=C2=A0

                    

                    

                    

                      
Le ven. 10 juil=
.
                        2020 =C3=A0 17:53, Denis <denis.ietf@free.fr=
>
                        a =C3=A9crit=C2=A0:

                      

                      

                        

                          
Hi Fabien,

                          


                          

                          
It would have been appreciated that you
                            kept the original message in your response.
                            I have copied it again at the end of this
                            email.

                          

                        

                      

                    

                  

                  


                  

                  
FI : sorry, not always easy on a
                    mobile. Will make sure that's the case next time.=
=C2=A0

                  

                    

                      

                        

                          
 

                          


                          

                          
Comments are between the lines.

                          


                          

                          

                            
Hi Denis,=C2=A0
                              


                              

                              
I think it's interesting, but also
                                very different to XYZ/XAuth so it raises
                                many questions ;-)

                              
The figure is impossible to read.

                            

                          

                          
Use a PC. Copy and paste and then use the
                            Courier font. On my PC (with the clear
                            figure) it was perfect.

                          

                            

                              
So let me try to summarize the
                                suggested approach, with a concrete
                                example, to make sure we understand
                                well:

                              


                              

                              
0. The client authN to the AS (in
                                  whatever way is supported)

                              
Ex : client is a corporate=C2=A0financin=
g
                                called "finapp". finapp contacts =
AS0 for
                                authentication (say an openbanking
                                service).=C2=A0=C2=A0

                              
User is John Doe, CFO at NeedMoney
                                Inc. (+ other identity claims if needed,
                                maybe some verified credential from
                                NeedMoney Holding that John is indeed
                                CFO).

                              


                              

                              
Dear John,=C2=A0

                              
to access to your finapp, please
                                  identify yourself through your
                                  prefered openbanking account.

                              
Thanks

                            

                          

                          
If I understand you correctly,=C2=A0 finapp is=
 a
                            local application e.g. on your smartphone.

                          

                        

                      

                    

                  

                  
FI : not necessarily, the client could
                    be a mobile app, a web app, etc., making api calls
                    to backend protected services.=C2=A0

                  

                    

                      

                        

                          
 

                          

                            
1. The client contacts a
                                RS in a discovery phase, which includes
                                the selection of (at least) an
                                operation, for which the RS returns the
                                required authZ attributes=C2=A0
                              
Ex : finapp needs to use NeedMoney's
                                data to evaluate how much credit it can
                                offer.

                              


                              

                              
Op1 : compute the credit rating, from
                                RS1 (this is outsourced to an external
                                credit analyst), through the external
                                service's own AS1.

                              

                              
But to do that, RS needs your
                                historic bank statements.

                              
Op2 : get your list of banks, RS2 (as
                                registered within finapp),
                                through=C2=A0openbanking AS0 and retrieve t=
he
                                bank statements :=C2=A0

                              
Op3a : get historic data from his
                                main bank, RS2a (say an international
                                bank), through openbanking AS0

                              
Op3b : same from a second bank
                                account, RS2b (say a local bank),
                                through openbanking AS0

                            

                          

                          
Why don't you make your very first example
                            a little bit more complicated ? with RS1,
                            RS2a, RS2b, ... AS0, AS1, ... 

                          

                          
:-)

                          

                        

                      

                    

                  

                  
FI : fair point. But i believe it's
                    important to grasp what it means on a realistic
                    example, especially as the proposed protocol would
                    be very much dependant on the way RS calls are
                    made.=C2=A0

                  

                    

                      

                        

                          


                            The intent of the first email was
                            to discuss a basic model and to
                            place the highlights on the way to capture
                            the user's consent 

                            in an interoperable manner without letting
                            know to any RS or AS the choices of the
                            user. This is a fundamental feature of the
                            model.

                            In XAuth, the user's consent is not
                            formalized in the protocol : "User consent
                            is often required at the GS".

                          

                        

                      

                    

                  

                  
FI : in the context of xauth, this
                    seems pretty clear I think.=C2=A0

                  

                    

                      

                        

                          
 

                          

                            

                              
2. User consent=C2=A0

                              
RS1 aggregates the list of attributes
                                required (from all RS) and sends it to
                                finapp.

                            

                          

                          

                            

                              
Dear John,=C2=A0

                              
To evaluate your credit request,
                                  we need the following information:=C2=A0<=
/i>

                              
- your list of bank accounts
                                  (retrieved from your finapp account)<=
/div>
                              
- the associated banking
                                  statements over the past 12 months
                                  (from each bank)

                              
- we'll pass that data to the
                                  credit agency, which will return your
                                  credit score=C2=A0

                              
Do you agree ?

                              


                              

                              
John approves (or not..., maybe he'l=
l
                                agree only for one specific bank), via
                                finapp directly 

                                (I like that, albeit in a more
                                traditional flow, I'm also separating
                                the UI from the rest of the protocol of
                                XYZ, and it works too).

                            

                          

                          
As described, the user could simply push to
                            the RS the banking statements over the past
                            12 months (from each bank).

                            The user consent is not about : "Do you
                              agree that  we pass the data to
                              the credit agency, which will return your
                              credit score"

                            since no attributes nor ASs are involved
                            in the question.

                        

                      

                    

                  

                  
FI : this is possible of course, but
                    pretty surprising. Today most implementations are
                    using oauth to delegate the implementation to some
                    specialized component, while here each RS would be
                    responsible for authentication. That is not an
                    innocent choice from an implementation and
                    deployment perspective.=C2=A0

                  

                    

                      

                        

                          


                            

                          
I guess you want the user to get access
                            tokens targeted for RS2x so that each bank
                            will accept to disclose his banking
                            statements over the past 12 months.

                          
The consent is whether the user accepts to
                            get access tokens from some of his banks
                            targeted for RS2x for the following
                            operation: 

                            "Retrieval of the past 12 months banking
                            statements" which corresponds to an API fo=
r
                            each bank and then to send these access
                            tokens to RS1.

                          
In practice, the client (e.g. using FIDO)
                            will connect transparently to each of the
                            appropriate AS from the banks and will get
                            the requested access tokens 

                            with a requested validity period of about 5
                            minutes.

                        

                      

                    

                  

                  
FI : yes.=C2=A0

                  

                    

                      

                        

                          

                            

                              
3. Requests to the protected
                                  resources=C2=A0

                              
The client gets the access tokens and
                                uses the services for which access was
                                granted.

                              


                              

                              
Analysis: (maybe I didn't get
                                  everything right, if so let me know)=C2=
=A0

                              
The trust model is focused around the
                                relationship between the enduser (John)
                                and his application (finapp), which
                                seems fine.

                            

                          

                          
No. The trust model is not making a focus
                            on that specific relationship. BTW, no
                            access token is necessarily needed by the
                            user to be able to use finapp.

                          

                        

                      

                    

                  

                  
FI : maybe, maybe not. As soon as I
                    want to fetch api calls, I need access tokens.=C2=A0
                  

                    

                      

                        

                          
 

                          

                            
=3D> I see some potential
                              issues :=C2=A0
                              


                              

                              
a. it will be really difficult for an
                                end user to understand what AS0 and AS1
                                are, why they're different, and why he
                                needs to authenticate to each of them. 

                                How do you enable a federated
                                experience? (especially as there could
                                be many)

                            

                          

                          
I fear that you have not fully captured
                            what the user consent is about. See the
                            above explanations. In addition, there is no
                            concept of federation. 

                          

                        

                      

                    

                  

                  
FI : your notion of consent is very
                    specific to what you have in mind. It would require
                    a kind of automated system to work.=C2=A0

                  
As for the concept of federation, this
                    is required in practice in you don't hypothesize a
                    dependancy on FIDO. The Uma2 standard is probably
                    the closest to some of your ideas and focuses a lot
                    on federation.=C2=A0

                  

                    

                      

                        

                          
 

                          

                            

                              
b. deciding what is the main RS (here
                                RS1) to be called by the client seems
                                very critical, as it is the one that
                                needs to orchestrate everything. 

                                This seems a very hierarchical and
                                imperative model which seems somewhat
                                counter intuitive in terms of developer
                                experience (as least 

                                as it is made today, we clearly don't g=
o
                                into so much details). The call
                                hierarchy may quickly become very
                                complex, which may also become 

                                a problem when separate services evolve.
                            

                          

                          
The client calls the main RS (here RS1).
                            What may happen next is fully dependant upon
                            the operation that the user is willing to
                            perform and 

                            this is unpredictable (since the back end
                            service may change at any point of time).

                        

                      

                    

                  

                  
FI : OK, but is it good engineering
                    practice to have to deal with the internals of
                    service calls? The reason why people delegate APIs
                    is precisely to avoid that complexity. Today with
                    OAuth, and tomorrow with XYZ/Xauth, the programming
                    model is way simpler. Privacy may be a good reason
                    to change that, but we need to be very thoughtful
                    about that.=C2=A0

                  

                    

                      

                        

                          

                            

                              
c. RS1 gets all the information
                                required to access all sub-resources,
                                and therefore gets also a lot of
                                responsibility (and power). But from
                                finapp's 

                                point of view, it is the one that has
                                the relationship with the user and is
                                providing the core value proposition,
                                while RS1 is just an external service.
                            

                          

                          
=C2=A0So is it really a problem ? 

                          

                        

                      

                    

                  

                  
FI : I think so. If I'm finapp, I
                    don't want to be this dependant on RS1 for a lot of
                    good and bad reasons. What I hope the example
                    conveys is that there's no reason why RS1 would
                    suddenly become the center of orchestration for all
                    queries, while all the underlying data is actually
                    elsewhere.=C2=A0

                  
The fact that the proposed protocol
                    mandates this behaviour is surprising and I don't
                    see why that is.=C2=A0

                  

                    

                      

                        

                          
 

                          

                            

                              
d. multi-user (common B2B scenario):
                                John wants to authorize a read access to
                                his finapp account to his external
                                auditor, Ann (who is not a direct user 

                                of finapp herself, but might already be
                                registered by openbanking AS0). How do
                                you do that? Does it require the access
                                token itself to be able to delegate
                                rights?

                            

                          

                          
The intent of the short description I sent
                            was to describe two simple scenarios, so
                            that we could start discussing about them.

                            At this point, the intent is not to cover
                            all the scenarios you may dream of.

                        

                      

                    

                  

                  
FI : fair point. However, as
                    previously discussed, this is a big concern as we
                    don't know whether you think this is a valid use
                    case or whether this is out of scope (so far, I
                    understood it was more, if we can't do it with
                    maximum privacy, then we won't do it; which is a
                    design choice, but standards are usually about
                    consensus with people that need to deal with real
                    life problems).=C2=A0

                  

                    

                      

                        

                          

                            

                              
e. more generally, a threat model
                                would be required, as there are many
                                more interactions now.

                            

                          

                          
There are less interactions than in XAuth:
                            there is no protocol between ASs and RSs,
                            nor between ROs and ASs.

                          

                        

                      

                    

                  

                  
FI : as far as I'm concerned, there
                    are many more interactions than Oauth/XYZ/Xauth.
                    Your view seems to be that it is simpler because AS
                    are way less central, but it seems to me that RS are
                    much more complex to implement correctly.=C2=A0

                  

                    

                      

                        

                          
 

                            Before a threat model, a trust model is
                            needed. Do we have a trust model for XAuth ?
                            

                            Unfortunately not, since the word "trust&q=
uot; is
                            absent in the main body of
                            draft-hardt-xauth-protocol-12.

                        

                      

                    

                  

                  
FI : sorry but I don't need the wor=
d
                    trust to do threat modeling...=C2=A0

                  

                    

                      

                        

                          
In this model, the trust relationships are
                            as follows:

                          
    
                            
  • The user trusts its client.
    • 
                            
  • If a user has an account opened with an
                              AS, then he trusts that AS to deliver the
                              requested and genuine attributes into an
                              access token.
    • 
                            
  • A RS may trust one or more ASs for one
                              or more types of attributes and
                              for performing a given operation.
    • 
                            
  • A RS may be administered remotely by one
                              or more RO.
    
                            
    • 
                          

                          
Note: for authentication, a RS may
                            accept either FIDO or one or more types of
                            attributes from one or more ASs.=C2=A0

                        

                      

                    

                  

                  

                    

                      

                        

                          
 

                          
Denis

                          

                            

                              
Cheers,=C2=A0

                              
Fabien

                              

                            

                            

                          

                          

                            This is a new thread.

                          
                          

                            
 

                                Preamble: This model is quite different
                                from the XAuth model. 

                                In particular, a RO has no relationship
                                with any AS and a Client does not need
                                to be associated with any AS prior to
                                any access to a RS.

                                

                                A key point of this model is that the
                                user's consent is handled locally by th=
e
                                Client and hence no AS nor RS is
                                handling a man machine interface 

                                for the user consent. This allows to
                                support locally the user consent for
                                multiple ASs while keeping all ASs
                                ignorant about the choices of the user 

                                made for accessing a particular 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=C2=A0
                                    +------------+

                                    =C2=A0=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0
                                    |

                                    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    | Owner (RO) |

                                    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 +--------+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    =C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0+------------+

                                    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    \=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |

                                    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
                                    \=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |

                                    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
                                    \=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |

                                    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0
                                    \=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |

                                    =C2=A0=C2=A0=C2=A0 +------=
-----+=C2=A0
                                    =C2=A0=C2=A0=C2=A0+=
---------------+=C2=A0=C2=A0=C2=A0=C2=A0
                                    +------------+

                                    =C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |---->| Authorization |=
=C2=A0=C2=A0=C2=A0=C2=A0
                                    |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

                                    =C2=A0=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) |=C2=A0 Serve=
r
                                    (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=C2=A0=C2=A0=C2=A0=
=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=C2=A0=C2=A0=C2=A0=C2=A0 |

                                    =C2=A0=C2=A0=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=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=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (1)=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |=C2=A0=C2=A0 Serve=
r=C2=A0=C2=A0
                                    |

                                    =C2=A0=C2=A0=C2=A0 |=
=C2=A0 Consent=C2=A0
                                    |<--------------------------|=
=C2=A0=C2=A0=C2=A0
                                    (RS)=C2=A0=C2=A0=C2=A0 |

                                    =C2=A0=C2=A0=C2=A0 |=
=C2=A0 element=C2=A0
                                    |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

                                    =C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |-------------------------->|=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |------>

                                    =C2=A0=C2=A0=C2=A0 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |=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 |=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |<--------------------------|=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                    |<------

                                    =C2=A0=C2=A0=C2=A0 +------=
-----+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=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 flow of operations is as follows:

                                

                                The Client (which may have been
                                previously authenticated using FIDO)
                                contacts the RS and after some dialogue
                                with the RS selects an operation 

                                that it wants to perform on the RS (1a).
                                Note that it may also indicate directly
                                the operation that it wants to perform
                                on the RS without any prior dialogue. 

                                In return (1b), the RS informs the
                                Client about which attributes are needed
                                by the RS for performing the requested
                                operation and from which Attributes
                                Servers 

                                they may be obtained. 

                                

                                This information is specifically marked
                                to indicate that it shall be handled by
                                the "User Consent element" from t=
he
                                Client. 

                                The presentation of that information is
                                up to the man machine interface
                                supported by the "User Consent element=
"
                                from the Client. 

                                

                                The user can see which attributes are
                                requested by the RS for performing the
                                requested operation and, if it consents,
                                the Client contacts one or more 

                                appropriate Authorization Servers (2a).
                                The user consent is hence captured
                                locally by the Client (i.e. there is no
                                dialogue with any AS nor any RS).

                                

                                When the Client got the access tokens
                                from these authorization servers (2b),
                                it sends all of them in a single request
                                to the RS (3a).

                                

                                End of the story for a simple access=


                            
 

                                Start of a subsequent story for a
                                delegation case

                                

                                Let us now suppose that the RS is unable
                                to fulfil the request by its own and
                                that it needs to contact another RS. RS1
                                contacts RS2 (4a) and
                                indicates the operation 

                                that it wants to perform on RS2 (that
                                operation may not be the same as the
                                original operation). In return (4b), RS2
                                informs RS1 about which attributes are
                                needed 

                                by RS2 for performing the requested
                                operation and from which Attributes
                                Servers they may be obtained. RS1
                                forwards that information to the Client.
                                

                                

                                This information is marked to indicate
                                that it shall be handled by the "User
                                Consent element" from the Client. The
                                presentation of that information is up
                                to the man machine 

                                interface from the Client. The user can
                                see which attributes are requested by
                                RS2 for performing the new requested
                                operation and, if it consents, the
                                Client contacts one or more 

                                appropriate Authorization Servers. The
                                user consent is hence captured locally
                                by the "User Consent element" fro=
m the
                                Client. (i.e. there is no dialogue with
                                any AS, nor RS1, nor RS2). 

                                

                                When the Client got the access token(s)
                                from the authorization server(s), it
                                sends all of them in a single request to
                                RS1. RS1 then forwards the additional
                                access token(s) to RS2.

                                

                                

                                Some observations: 

                                

                                The user nor the Client are linked with
                                any particular AS. A user may use today
                                an AS of the Bank of America and may
                                change tomorrow to the Bank of Missouri.
                                

                                As soon as he will be registered with
                                the Bank of Missouri, he will be able to
                                get access tokens from the AS of the
                                Bank of Missouri. The AS of Bank of
                                America 

                                has not been able to know where its
                                access tokens have been used. This will
                                be the same for AS of the Bank of
                                Missouri. There is no need for any
                                direct dialogue 

                                between any AS and any RS at the time a
                                client is making an access. There is no
                                need for any RO to contact any AS.
                            
This model has been
                                constructed following a "Privacy by
                                Design" approach.

                            Denis

                            

                        

                      

                    

                  

                

              

              


              

            

            -- 

            Txauth mailing list

            Txauth@ietf.org

            https://www.ietf.org/mailman/list=
info/txauth

          

        

      

    

    


    

  





--0000000000001d761205aab1329d--


From nobody Sat Jul 18 07:55: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 8FF813A08CA for ; Sat, 18 Jul 2020 07:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.082
X-Spam-Level: 
X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 wJhmEYIutKnS for ; Sat, 18 Jul 2020 07:55: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 379463A08C0 for ; Sat, 18 Jul 2020 07:55:13 -0700 (PDT)
Received: from [192.168.1.3] (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 06IEtBeZ007399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Jul 2020 10:55:12 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_B37A944A-8E0F-4185-8A0C-F223D41C5666"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sat, 18 Jul 2020 10:55:11 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:   <5B2BF4E7-77CD-4DC6-A0C9-E7894CE38A5E@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] New version of XYZ Draft
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, 18 Jul 2020 14:55:17 -0000

--Apple-Mail=_B37A944A-8E0F-4185-8A0C-F223D41C5666
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I really don=E2=80=99t see them as shifting towards each other so much =
as it is them adapting and changing based on ongoing efforts. As such =
I=E2=80=99ve modified XYZ not to make it =E2=80=9Clook more like =
XAuth=E2=80=9D, but rather to hopefully improve it in some measurable =
dimensions. So if you wonder why it doesn=E2=80=99t =E2=80=9Clook even =
more like XAuth=E2=80=9D it=E2=80=99s because I don=E2=80=99t think that =
such changes would be improvements =E2=80=94 in fact, even with recent =
improvements, I think there are a still a lot of issues with XAuth=E2=80=99=
s design and assumptions. XYZ can, I=E2=80=99m sure, also be improved.

The goal here isn=E2=80=99t to take two projects and make them look the =
same. The goal here is to make one protocol, GNAP, with the best ideas =
and elements engineered into it that we, as a working group, can. It=E2=80=
=99s not about one input proposal winning over another, it=E2=80=99s =
about improving our understanding of all the use cases and possible =
solutions and coming up with the best specification possible. Making =
things better should always be the goal. Progress should always be the =
goal.=20

But we aren=E2=80=99t here to build XYZ or XAuth. We=E2=80=99re here to =
build GNAP and decide what GNAP looks like. XYZ=E2=80=99s structure and =
design is the best I=E2=80=99ve been able to make it so far, and it =
should be our goal as a WG to move past either XYZ or XAuth and build =
GNAP even better than any of that.

 =E2=80=94 Justin

> On Jul 17, 2020, at 6:46 PM, Dick Hardt  wrote:
>=20
> XYZ is looking a lot more like XAuth, similar to how XAuth has shifted =
towards XYZ.=20
>=20
> I have implemented separate URIs for grants and authorizations, and it =
worked really well.
>=20
> All 3 of the new capabilities are problematic. Perhaps you did not =
notice that there no longer is a short_uri in XAuth? As I recall, you =
were opposed to the short URI that was in the earlier drafts of XAuth. =
In my XAuth implementation, I show QR codes in the CLI app. Have you =
checked out my implementation? Have you implemented a QR code? I found =
that the string did not need to be nearly as short as it has in the =
past.=20
>=20
> I still don't understand the requirement to rotate the reference =
handle. I read over the pointer you provided last time we discussed it, =
and responded, but I have not heard back from you on that.
>=20
>=20
> =E1=90=A7
>=20
> On Fri, Jul 17, 2020 at 2:36 PM Justin Richer > wrote:
> Most of these are changes I=E2=80=99ve wanted to do for quite some =
time and finally had opportunity to make the edits. As I said below, the =
core protocol really hasn=E2=80=99t changed in nature, but hopefully =
it=E2=80=99s easier to understand with it laid out in this way.=20
>=20
> All of these are points that I=E2=80=99ve made previously on the list =
in discussions, but to answer your questions directly:
>=20
> - Mapping items to separate URLs has been on XYZ=E2=80=99s radar since =
well before it was proposed in Xauth, so this is bringing some of that =
into the concrete system. I still need to implement it to see how well =
it works in practice.
>=20
> - The need to rotate the reference handle as well as use it externally =
(the =E2=80=9Cextend a request=E2=80=9D method) both call for having an =
identifier separate from the access URL. It also allows an AS more =
freedom in how it manages its endpoints, and aligns with the desire to =
push more information into the ongoing request after the initial phase. =
I=E2=80=99d actually rather the access token management move in that =
direction, using the token itself as the artifact, but I couldn=E2=80=99t =
do that and still use the DELETE method for revocation. So that=E2=80=99s =
an engineering challenge that I think the group should discuss, and =
decide whether it=E2=80=99s worth having the =E2=80=9CDELETE=E2=80=9D =
verb semantics and having that restriction placed on the AS as a =
consequence.
>=20
> - The DID work is likely better suited for an extension, and always =
has been. But it was worth having in previous revisions for discussion =
purposes, especially as a point around how a non-HTTP interaction method =
would work. I expect to see DIDCOMM, CHAPI, WebAuthN, and other =
interaction methods in the extensions landscape of GNAP, usable =
alongside the others.=20
>=20
> And a final point, the interaction setup hasn=E2=80=99t really =
changed, so I=E2=80=99m curious to hear what you think has changed =
there. Even with a couple new capabilities on the way there (short_uri =
and app) and back (pushback), It=E2=80=99s structurally and conceptually =
identical to previous revisions.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 17, 2020, at 1:10 PM, Dick Hardt > wrote:
>>=20
>> Hey Justin,
>>=20
>> Glad to see that you are aligning on having URIs for the access =
tokens and the "grant".
>>=20
>> While the token URI is unique to the token, you have not done the =
same for a "grant", but have a handle and a non-unique URI.
>>=20
>> Why not have a unique grant URI similar to the token URI? (a =
combination of the handle and a non-unique URI) -- this is then both the =
identifier, and the URL for "management"?
>>=20
>> Glad to see you have excised the DID references. I don't think the =
common use cases are well established there currently.
>>=20
>> I have LOTS of feedback on your interaction changes, that I'll post =
later on, and hope that others have feedback on those as well.
>>=20
>> /Dick
>>=20
>>=20
>>=20
>>=20
>>=20
>> On Thu, Jul 16, 2020 at 2:52 PM Justin Richer > wrote:
>> Hi all,
>>=20
>> I=E2=80=99ve updated the XYZ draft specification. Since the =
publication tools are currently locked prior to the upcoming virtual =
meeting, I have published it online here:
>>=20
>> https://oauth.xyz/draft-richer-transactional-authz =

>>=20
>> This represents a pretty significant refactoring of the =
specification, hopefully to make the concepts and capabilities easier to =
understand. The core protocol is largely the same as before, but there =
are a number of serious updates:
>>=20
>>  - Continuation requests happen at a URL returned in the TX response. =
The =E2=80=9Chandle=E2=80=9D is still sent as one of the input values =
here, since the handle can also be used it other contexts.
>>  - Tokens now can include the resources they are issued for
>>  - Tokens can have an optional management URI for rotation and =
revocation.
>>  - =E2=80=9Cclaims=E2=80=9D has been removed in favor of =
=E2=80=9Csubject=E2=80=9D dealing directly with identifiers and =
assertions
>>  - the =E2=80=9Cuser=E2=80=9D request and response now align with =
identifiers and assertions
>>  - Extensions and registries are more clearly enumerated throughout =
the document
>>  - DID-related items have been excised in deference to a future =
possible extension
>>  - Added a =E2=80=9Cpushback=E2=80=9D mechanism to complement the =
=E2=80=9Ccallback=E2=80=9D mechanism
>>  - Simplified dynamic handle returns and access tokens based on =
developer feedback (basically we dropped a bunch of =E2=80=9Cwhat if=E2=80=
=9D stuff that nobody used or liked, like SHA3 hashes for bearer tokens)
>>=20
>> I=E2=80=99ve also updated the interactive examples on =
https://oauth.xyz/  to match this new draft. =
Hopefully it=E2=80=99s consistent with the draft text.
>>=20
>> I have not yet, however, updated any of the implementations of XYZ to =
take the elements of new syntax into account, so there might be some =
more changes prior to the IETF meeting as I realize what terrible =
mistakes I=E2=80=99ve made when doing that. :)=20
>>=20
>> Feedback, as always, is welcomed, and thanks to everyone who=E2=80=99s =
provided input to the project to date.=20
>>=20
>>  =E2=80=94 Justin
>> --=20
>> Txauth mailing list
>> Txauth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/txauth =

>=20


--Apple-Mail=_B37A944A-8E0F-4185-8A0C-F223D41C5666
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
really don=E2=80=99t see them as shifting towards each other so much as =
it is them adapting and changing based on ongoing efforts. As such =
I=E2=80=99ve modified XYZ not to make it =E2=80=9Clook more like =
XAuth=E2=80=9D, but rather to hopefully improve it in some measurable =
dimensions. So if you wonder why it doesn=E2=80=99t =E2=80=9Clook even =
more like XAuth=E2=80=9D it=E2=80=99s because I don=E2=80=99t think that =
such changes would be improvements =E2=80=94 in fact, even with recent =
improvements, I think there are a still a lot of issues with XAuth=E2=80=99=
s design and assumptions. XYZ can, I=E2=80=99m sure, also be =
improved.

The goal =
here isn=E2=80=99t to take two projects and make them look the same. The =
goal here is to make one protocol, GNAP, with the best ideas and =
elements engineered into it that we, as a working group, =
can. It=E2=80=99s not about one input proposal winning over =
another, it=E2=80=99s about improving our understanding of all the use =
cases and possible solutions and coming up with the best specification =
possible. Making things better should always be the goal. Progress =
should always be the goal. 

But we =
aren=E2=80=99t here to build XYZ or XAuth. We=E2=80=99re here to build =
GNAP and decide what GNAP looks like. XYZ=E2=80=99s structure and design =
is the best I=E2=80=99ve been able to make it so far, and it should be =
our goal as a WG to move past either XYZ or XAuth and build GNAP even =
better than any of that.

 =E2=80=94=
 Justin

On Jul 17, 2020, at 6:46 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

XYZ is looking a lot more like =
XAuth, similar to how XAuth has shifted towards XYZ. 

I have implemented =
separate URIs for grants and authorizations, and it worked really =
well.

All 3 of =
the new capabilities are problematic. Perhaps you did not notice that =
there no longer is a short_uri in XAuth? As I recall, you were opposed =
to the short URI that was in the earlier drafts of XAuth. In my XAuth =
implementation, I show QR codes in the CLI app. Have you checked out my =
implementation? Have you implemented a QR code? I found that the string =
did not need to be nearly as short as it has in the =
past. 

I =
still don't understand the requirement to rotate the reference handle. I =
read over the pointer you provided last time we discussed it, and =
responded, but I have not heard back from you on that.


3D""=E1=90=A7

On Fri, Jul =
17, 2020 at 2:36 PM Justin Richer <jricher@mit.edu> wrote:
Most of these are changes I=E2=80=99=
ve wanted to do for quite some time and finally had opportunity to make =
the edits. As I said below, the core protocol really hasn=E2=80=99t =
changed in nature, but hopefully it=E2=80=99s easier to understand with =
it laid out in this way. 

All of these are points that I=E2=80=99ve=
 made previously on the list in discussions, but to answer your =
questions directly:

- Mapping items to separate URLs has been on XYZ=E2=80=99s =
radar since well before it was proposed in Xauth, so this is bringing =
some of that into the concrete system. I still need to implement it to =
see how well it works in practice.

- The need to rotate the reference =
handle as well as use it externally (the =E2=80=9Cextend a request=E2=80=9D=
 method) both call for having an identifier separate from the access =
URL. It also allows an AS more freedom in how it manages its endpoints, =
and aligns with the desire to push more information into the ongoing =
request after the initial phase. I=E2=80=99d actually rather the access =
token management move in that direction, using the token itself as the =
artifact, but I couldn=E2=80=99t do that and still use the DELETE method =
for revocation. So that=E2=80=99s an engineering challenge that I think =
the group should discuss, and decide whether it=E2=80=99s worth having =
the =E2=80=9CDELETE=E2=80=9D verb semantics and having that restriction =
placed on the AS as a consequence.

- The DID work is likely better suited =
for an extension, and always has been. But it was worth having in =
previous revisions for discussion purposes, especially as a point around =
how a non-HTTP interaction method would work. I expect to see DIDCOMM, =
CHAPI, WebAuthN, and other interaction methods in the extensions =
landscape of GNAP, usable alongside the others. 

And a final point, the =
interaction setup hasn=E2=80=99t really changed, so I=E2=80=99m curious =
to hear what you think has changed there. Even with a =
couple new capabilities on the way there (short_uri and app) and back =
(pushback), It=E2=80=99s structurally and conceptually identical to =
previous revisions.

 =E2=80=94 Justin
On Jul =
17, 2020, at 1:10 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey Justin,

Glad to see that you are =
aligning on having URIs for the access tokens and the =
"grant".

While =
the token URI is unique to the token, you have not done the same =
for a "grant", but have a handle and a non-unique URI.

Why not have a unique =
grant URI similar to the token URI? (a combination of the handle and a =
non-unique URI) -- this is then both the identifier, and the URL for =
"management"?

Glad to see you have excised the DID references. I don't =
think the common use cases are well established there =
currently.

I =
have LOTS of feedback on your interaction changes, that I'll post =
later on, and hope that others have feedback on those as well.

/Dick





On Thu, Jul 16, 2020 at 2:52 PM Justin =
Richer <jricher@mit.edu> wrote:
Hi all,

I=E2=80=99ve updated the =
XYZ draft specification. Since the publication tools are currently =
locked prior to the upcoming virtual meeting, I have published it online =
here:

https://oauth.xyz/draft-richer-transactional-authz

This represents a =
pretty significant refactoring of the specification, hopefully to make =
the concepts and capabilities easier to understand. The core protocol is =
largely the same as before, but there are a number of serious =
updates:

 -=
 Continuation requests happen at a URL returned in the TX response. The =
=E2=80=9Chandle=E2=80=9D is still sent as one of the input values here, =
since the handle can also be used it other contexts.
 - Tokens now can include the resources they are issued =
for
 - Tokens can have an optional management =
URI for rotation and revocation.
 - =
=E2=80=9Cclaims=E2=80=9D has been removed in favor of =E2=80=9Csubject=E2=80=
=9D dealing directly with identifiers and assertions
 - the =E2=80=9Cuser=E2=80=9D request and response now =
align with identifiers and assertions
 - =
Extensions and registries are more clearly enumerated throughout the =
document
 - DID-related items have been =
excised in deference to a future possible extension
 - Added a =E2=80=9Cpushback=E2=80=9D mechanism to =
complement the =E2=80=9Ccallback=E2=80=9D mechanism
 - Simplified dynamic handle returns and access tokens =
based on developer feedback (basically we dropped a bunch of =E2=80=9Cwhat=
 if=E2=80=9D stuff that nobody used or liked, like SHA3 hashes for =
bearer tokens)

I=E2=80=99ve also updated the interactive examples on https://oauth.xyz/ to match this new draft. =
Hopefully it=E2=80=99s consistent with the draft text.

I have not yet, however, =
updated any of the implementations of XYZ to take the elements of new =
syntax into account, so there might be some more changes prior to the =
IETF meeting as I realize what terrible mistakes I=E2=80=99ve made when =
doing that. :) 

Feedback, as always, is welcomed, and thanks to everyone =
who=E2=80=99s provided input to the project to date. 

 =E2=80=94 =
Justin
-- 

Txauth mailing list

Txauth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth
=







=

--Apple-Mail=_B37A944A-8E0F-4185-8A0C-F223D41C5666--


From nobody Sat Jul 18 09:56: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 9EB0A3A0A85 for ; Sat, 18 Jul 2020 09:56:44 -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 vRmnpwAgGqPh for ; Sat, 18 Jul 2020 09:56:41 -0700 (PDT)
Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 B44503A0A7E for ; Sat, 18 Jul 2020 09:56:41 -0700 (PDT)
Received: by mail-ot1-x342.google.com with SMTP id 5so9105254oty.11 for ; Sat, 18 Jul 2020 09:56: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=YuOsFVqsvqlOROWlKzKkVw5Oh7ypd8bJfI0bZTYV5TA=; b=YG/krm+/NVURoN9x2vNeT7wiGzMJ2wAlKY7X4e/PSI/VWgMUCz2nDiui537Mrftjj+ 5TryHXLt6qvNkrZUQLSj5v7776DvvW8ksu/XFYt0Fn8dsIZ7xpOc9rV8GQ+2sp8rSL6a cjZhgrdwXX6LojCXxbNWKqSeDXqiAXMxAD1pIwQtXW4wHIemcbre7C1V3i8s3UuR7UN6 Wh0/KSHDJ/Z+XTahB42aWX+r5MaHKZWq1cPsnzLDijARxiGJY6d2aY+08ajCcBwealMU u2pVoHBNwrZT3N0JWQ4ag6bYMmFhgeHAU0YR+ojN/J3SSRJZD3crbHCd9S0cBpcQ3DQX gLGg==
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=YuOsFVqsvqlOROWlKzKkVw5Oh7ypd8bJfI0bZTYV5TA=; b=p+/qgh7mWI2yaP8cGQ/7RgT6tIEHsdDgnPw6agwppmwlEmC51tkDUWhdRjFPn+t9SB GiYGuC2gpb1gVbRs9JV3qB+tCFcqEvpRvLymcK67q470VPq8rGi6Z80lcDSLjN8h6VNp 1tOIpbjXrURdi0HBkzWq0UX8wpQgF8WLfX559dWDtlbWin2OTjhJVDlN9icrTXW3I1dB IKE1mgRFdJCUphxfneUHnnyOlp8fq/rmIheWi7s+/GOWK7qfz6AzPjUaAzUDlKqh/uJ6 6Ui4I1bEtOi2XiW8ENjKeKaIXa63GNyOd7SMFnszVG2oIMJxThZKAV0Jo5txWsZF9aGo kzLw==
X-Gm-Message-State: AOAM533znTpgXyjgPvFv6N1DyiiNLsZxv3y39qS27qZ0V7QE5W3DybcZ ZacMEUWHTqhV9IoPpj+Q23xX/YBSiT8WqyVKcessG0i0
X-Google-Smtp-Source: ABdhPJxX+OyCZVb3szVYC3y4cFEp2gq32RSdVBDLylVsvP9mLClnqtFGbLAnlg1ljQfMG/ic6oGaREF7uNFdZhWzPP0=
X-Received: by 2002:a9d:66ca:: with SMTP id t10mr12878845otm.358.1595091400800;  Sat, 18 Jul 2020 09:56:40 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu>  <174F2061-3F0F-49B2-A18F-58DF658E4473@mit.edu>   
In-Reply-To: 
From: Tom Jones 
Date: Sat, 18 Jul 2020 09:56:28 -0700
Message-ID: 
To: Justin Richer 
Cc: Dick Hardt , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000543cf705aaba289b"
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 18 Jul 2020 16:56:45 -0000

--000000000000543cf705aaba289b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree with Justin's comment " what we should do, as we define GNAP as a
protocol, is focus on this one, limited slice of the identity space and not
spiral into others."
The title "Authorization" should rule the purposes of this group above all
else.

The earlier statement that the client should know who the user is - is just
plain WRONG. The client should only know the information the user is
willing to share with the client.
It is now the law in California that the client cannot demand identity
information that is not required for a legitimate business purpose.
There are some clients that act as fiduciaries for the user (financial and
healthcare come to mind), but as a general rule the "client" is not to be
trusted by the user.
I understand most of the people on this list are paid by the client's of
the world, but you are still bound by the laws that apply to those clients.

Peace ..tom


On Mon, Jul 13, 2020 at 12:31 PM Justin Richer  wrote:

> A quick note, as my choice of language below seems to have been confusing=
.
> First there is a typo, where the word =E2=80=9Cit=E2=80=9D should have be=
en =E2=80=9Cin=E2=80=9D to read:
>
> I am saying that GNAP, *in* its definition within this working group,
> should be limited to identifier claims.
>
>
> And second, there seems to be confusion around whether I=E2=80=99m trying=
 to argue
> about the scope =E2=80=9Callowed=E2=80=9D by the charter by saying =E2=80=
=9Cits definition within
> this working group=E2=80=9D here.
>
> To be clear, we as the working group are *defining* GNAP the protocol. It
> has not yet been defined, and that=E2=80=99s why were all here. The chart=
er doesn=E2=80=99t
> define it. The input specs don=E2=80=99t define it. The working group def=
ines it,
> and my stance as a contributor to this WG is that we should focus on a
> delegation protocol with some basic identifier query support and leave th=
e
> full fledged identity protocol to different work.
>
> We=E2=80=99ve already got our hands full here without taking all of that =
on,
> especially since I do believe we need to build GNAP in such a way as to
> facilitate its extension in several known directions, including a full
> identity protocol. If we do things right here, we can see GNAP as the bas=
is
> of a large number of things out there in the world.
>
> So my stance in what we should do, as we define GNAP as a protocol, is
> focus on this one, limited slice of the identity space and not spiral int=
o
> others.
>
>  =E2=80=94 Justin
>
> On Jul 13, 2020, at 2:51 PM, Justin Richer  wrote:
>
> I am saying that GNAP, it its definition within this working group, shoul=
d
> be limited to identifier claims. Other claims can come from other protoco=
ls
> properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop them from be=
ing built,
> but in my opinion we shouldn=E2=80=99t be defining those here. See the di=
scussion
> below on the extensibility avenues of this approach.
>
>  =E2=80=94 Justin
>
> On Jul 13, 2020, at 2:12 PM, Dick Hardt  wrote:
>
> I agree that an API to return claims is useful. I think we have agreed on
> that.
>
> Using the SubjectIdentifiers schema is another schema that would be usefu=
l
> for GNAP to support.
>
> I disagree that GNAP should be limited to identifier claims.
>
> =E1=90=A7
>
> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer  wrote:
>
>> One thing I think we should learn from OIDC is that returning claims fro=
m
>> an API, and not just an assertion or direct response, is a powerful and
>> useful pattern. We have an opportunity to separate these cleanly, where
>> OIDC didn=E2=80=99t have the opportunity in defining the =E2=80=9Cclaims=
=E2=80=9D request parameter.
>>
>> As an alternative to the current XYZ and XAuth syntaxes, over the weeken=
d
>> I=E2=80=99ve been playing with something that would look like this straw=
man in the
>> request:
>>
>>
>> {
>>    subject: {
>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=
=9Ciss-sub=E2=80=9D],
>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifiable_=
credential=E2=80=9D, =E2=80=9Csaml" ]
>>    }
>> }
>>
>>
>> This request says that I=E2=80=99d like some subset of these identifiers=
 (as
>> plain text in the response) and some subset of signed assertions in the
>> given formats. Each one would have an associated space in the return. I=
=E2=80=99m
>> not picturing that the =E2=80=9Cid=E2=80=9D field values would affect th=
e contents of the
>> assertions: so I could ask for an email address identifier but get back =
an
>> ID token that had only the subject identifier. Maybe that=E2=80=99s not =
the right
>> model? But it=E2=80=99s at least simple and deterministic this way, and =
it=E2=80=99s
>> something to play with.
>>
>> Note: The =E2=80=9Cid=E2=80=9D names are taken from
>> https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.htm=
l,
>> the =E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=99t se=
e a source that collected
>> them. If you wanted specific bundles of claims about the user from a
>> UserInfoEndpoint, for example, you=E2=80=99d have something like:
>>
>> {
>>    subject: {
>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=
=9Ciss-sub=E2=80=9D],
>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifiable_=
credential=E2=80=9D, =E2=80=9Csaml" ]
>>    },
>>    resources: [{
>>        type: =E2=80=9Cuserinfo=E2=80=9D,
>>        datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D,=
 =E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
>>   }]
>> }
>>
>>
>> This is an example for a specific kind of resource, and I don=E2=80=99t =
think
>> that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, or t=
he datatype values
>> therein. That should be work outside of GNAP, probably for the OIDF.
>>
>> This approach is extensible in several ways, each of them for a specific
>> reason that I think is clear:
>>
>>  - new values in the =E2=80=9Cid=E2=80=9D field to give new identifiers
>>  - new values in the =E2=80=9Cassertion=E2=80=9D field to give new asser=
tion formats
>>  - new fields under the =E2=80=9Csubject=E2=80=9D heading
>>  - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9C=
scim-v1=E2=80=9D or
>> =E2=80=9Cfacebook-profile=E2=80=9D for instance)
>>  - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource type
>>  - new top-level request parameters
>>
>> As per the other thread, if you wanted to use the OIDC query language,
>> you=E2=80=99d package it separately as a top-level request parameter sin=
ce it can
>> include both the ID token response and the access token response and we
>> shouldn=E2=80=99t be encouraging mixing these things together.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 10, 2020, at 5:00 PM, Dick Hardt  wrote:
>>
>> It looks to me that our different views of what is in scope for GNAP are
>> the differences below.
>>
>> Per the subject line, I'm looking at how the client acquires claims abou=
t
>> the user. You don't think that is in scope, and that a different layer w=
ill
>> solve that.
>>
>> I think we should learn from OIDC being on top of OAuth, and GNAP should
>> be able return ANY claim, not just identifier claims. There are use case=
s
>> that may be difficult to support if we do not have that functionality in
>> scope, such as some of the ones I list below, and it seems pretty
>> straightforward to support ANY claim if we are supporting identifiers.
>>
>> /Dick
>>
>>
>> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer  wrote:
>>
>>>
>>>
>>> On Jul 10, 2020, at 2:15 PM, Dick Hardt  wrote:
>>>
>>>
>>> inline ...
>>>
>>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer  wrote:
>>>
>>>> Yes, the core idea is to not have to parse an assertion to get back th=
e
>>>> core authentication information, which consists of an identifier (iss/=
sub
>>>> pair in OIDC, but could be a number of things). Sometimes the client i=
s
>>>> going to want the rest of the identity information, but If the user=E2=
=80=99s
>>>> logged into the client before, the client has likely cached that info =
and
>>>> probably won=E2=80=99t need it, and sending it would be a violation of=
 privacy
>>>> principles.. The client would want the info pretty much just in these =
cases:
>>>>
>>>>  1. The client has never seen the user before.
>>>>  2. The user=E2=80=99s information has been updated since the last tim=
e the
>>>> client saw it.
>>>>
>>>
>>> Agreed
>>>
>>>
>>>>
>>>> Now for case (1), how would the client know if it wants to request the
>>>> user=E2=80=99s profile info or not, since it doesn=E2=80=99t know who =
the user is?
>>>>
>>>
>>> But the client could know who the user is. The client may have used a
>>> different AS to authenticate the user.
>>>
>>>
>>> In these cases, the client is not going to be requesting identity
>>> information from the AS to log the user in, so it=E2=80=99s not relevan=
t to the use
>>> case. The client will have an opportunity to push that information to t=
he
>>> AS.
>>>
>>> The User may have self identified to the client. The client may have a
>>> cookie saying who the user was and the user said that was them. While t=
he
>>> latter cases are really a strong hint, they are likely right most of th=
e
>>> time and can lead to a user experience basde on that hint
>>>
>>>
>>> In these cases, the AS might be able to guess if the client has info
>>> about the user already, but probably not. And the assumptions fall apar=
t if
>>> it=E2=80=99s in fact a different user that ends up logging in, which is=
 of course
>>> possible (the hint you gave doesn=E2=80=99t match the identity of the c=
urrent user
>>> after the AS validates them). This possibility leads to clients always
>>> asking for everything every time and the server providing everything ev=
ery
>>> time. That=E2=80=99s a pattern I think we should avoid in an ultimate s=
olution =E2=80=94
>>> but ultimately, I don=E2=80=99t think that this kind of protocol decisi=
on is inside
>>> of GNAP.
>>>
>>>
>>>
>>>> And the AS won=E2=80=99t know if client is going to want the profile i=
nfo,
>>>> since the AS won=E2=80=99t know if the client has the user=E2=80=99s i=
nfo or not. Sure, the
>>>> AS might have seen that client and that user combo previously, but it
>>>> doesn=E2=80=99t know if the client needs an update.
>>>>
>>>
>>> The client can share with the AS the user it knows or thinks it is
>>> dealing with, which could let the AS respond if the information was new=
.
>>> This could be the case for an AS that is providing claims, but not
>>> authentication, and could happen silently. The user would only interact=
 if
>>> the user information had changed, and the client wanted the updated
>>> information.
>>>
>>>
>>>
>>> See above.
>>>
>>>
>>>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s info =
has been updated
>>>> or not because it doesn=E2=80=99t know who the user is yet. If the AS =
can provide
>>>> some time of updated stamp to the client, the client can pull the new =
info
>>>> when it needs it.
>>>>
>>>
>>> See above.
>>>
>>>
>>> See above.
>>>
>>>
>>>
>>>>
>>>> If you ignore both of these cases and put all the user information
>>>> inline with the main request/response, you end up in a situation where=
 the
>>>> client always requests everything and the server always provides
>>>> everything, since you can=E2=80=99t be sure you=E2=80=99re not in situ=
ation (1) or (2)
>>>> ahead of time.
>>>>
>>>
>>> See above. There are a number of other states the client could be in.
>>>
>>> For example, the client could be stateless about user information, so i=
t
>>> knows it is ALWAYS in state 1.
>>>
>>>
>>> A stateless client would need to fetch appropriate user information
>>> every time, then. But that=E2=80=99s an optimization for a very specifi=
c case.
>>>
>>>
>>>
>>>>
>>>> This is really what I mean about the two-stage identity protocol.
>>>>
>>>
>>> I know what it is. Per above, GNAP lets us support a wider set of use
>>> cases. Why limit ourselves to what OIDC supported?
>>>
>>>
>>> We aren=E2=80=99t limiting the protocol, but instead limiting the scope=
 of what
>>> we define internal to the GNAP protocol. There=E2=80=99s a lot of room =
for
>>> innovation on top of it.
>>>
>>>
>>>
>>>> In the first stage, you push the bare minimum of what you need to get
>>>> the user known to the client. In the second stage, the client uses its
>>>> access token to call an API to get whatever else it needs to know abou=
t the
>>>> user.
>>>>
>>>
>>> From a privacy perspective in non-enterprise use cases, I think the use=
r
>>> should give consent to any updated personal information to a client. In
>>> general, the client should not be able to get the latest information ab=
out
>>> a user whenever it wants.
>>>
>>>
>>> This is about the rights associated with the access token, then. And an
>>> access token doesn=E2=80=99t have to keep working if the AS has a polic=
y that says
>>> it won=E2=80=99t. The AS/RS could easily decide that a particular acces=
s token will
>>> only return data that hasn=E2=80=99t been changed. Maybe it stops worki=
ng after the
>>> data changes, or it just returns old data, or any number of things. Thi=
s is
>>> for the AS/RS to decide and this is pretty standard interpretation of t=
he
>>> token, nothing special here because we=E2=80=99re dealing with identity=
.
>>>
>>>  =E2=80=94 Justin
>>>
>>>
>>> /Dick
>>> =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
>

--000000000000543cf705aaba289b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I agree with Justin's comment "=C2=A0what we shou=
ld do, as we define GNAP as a protocol, is focus on this one, limited slice=
 of the identity space and not spiral into others."
The title &quo=
t;Authorization" should rule the purposes of this group above all else=
.

The earlier statement=C2=A0that the client should =
know who the user is - is just plain WRONG. The client should only know the=
 information the user is willing to share with the client.
It is =
now the law in California that the client cannot demand=C2=A0identity infor=
mation that is not required for a legitimate business purpose.
Th=
ere are some clients that act as fiduciaries for the user (financial=C2=A0a=
nd healthcare come to mind), but as a general rule the "client" i=
s not to be trusted by the user.
I understand most of the people=
=C2=A0on this list are paid by the client's of the world, but you are s=
till bound by the laws that apply to those clients.

Peace ..tom

<=
/div>

On Mon, Jul 13, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
A quick note, as my choice of language below seems to have been confusi=
ng. First there is a typo, where the word =E2=80=9Cit=E2=80=9D should have =
been =E2=80=9Cin=E2=80=9D to read:

I am saying that GNAP, in=
 its definition within this working group, should be limited to identif=
ier claims.

And second, there seems t=
o be confusion around whether I=E2=80=99m trying to argue about the scope =
=E2=80=9Callowed=E2=80=9D by the charter by saying =E2=80=9Cits definition =
within this working group=E2=80=9D here.=C2=A0

To =
be clear, we as the working group are defining GNAP the protocol. It=
 has not yet been defined, and that=E2=80=99s why were all here. The charte=
r doesn=E2=80=99t define it. The input specs don=E2=80=99t define it. The w=
orking group defines it, and my stance as a contributor to this WG is that =
we should focus on a delegation protocol with some basic identifier query s=
upport and leave the full fledged identity protocol to different work.=C2=
=A0

We=E2=80=99ve already got our hands full here =
without taking all of that on, especially since I do believe we need to bui=
ld GNAP in such a way as to facilitate its extension in several known direc=
tions, including a full identity protocol. If we do things right here, we c=
an see GNAP as the basis of a large number of things out there in the world=
.=C2=A0

So my stance in what we should do, as we d=
efine GNAP as a protocol, is focus on this one, limited slice of the identi=
ty space and not spiral into others.

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

On Jul 13, 2020, at 2=
:51 PM, Justin Richer <jricher@mit.edu> wrote:



I am saying that GNAP, it its def=
inition within this working group, should be limited to identifier claims. =
Other claims can come from other protocols properly layered on top of GNAP.=
 GNAP shouldn=E2=80=99t stop them from being built, but in my opinion we sh=
ouldn=E2=80=99t be defining those here. See the discussion below on the ext=
ensibility avenues of this approach.

=C2=A0=E2=80=94 Jus=
tin

On Jul 13, 2020, at 2:12 PM,=
 Dick Hardt <d=
ick.hardt@gmail.com> wrote:

I agree t=
hat an API to return claims is useful. I think we have agreed on that.=C2=
=A0

Using the SubjectIdentifiers schema is another schem=
a that would be useful for GNAP to support.=C2=A0

=
I disagree=C2=A0that GNAP should be limited to identifier claims.=C2=A0

3D""=E1=90=A7

On Mon, Jul 13, 2020=
 at 7:16 AM Justin Richer <jricher@mit.edu> wrote:
One thing I think we should learn from OIDC is =
that returning claims from an API, and not just an assertion or direct resp=
onse, is a powerful and useful pattern. We have an opportunity to separate =
these cleanly, where OIDC didn=E2=80=99t have the opportunity in defining t=
he =E2=80=9Cclaims=E2=80=9D request parameter.

As an alt=
ernative to the current XYZ and XAuth syntaxes, over the weekend I=E2=80=99=
ve been playing with something that would look like this strawman in the re=
quest:


{
=C2=A0 =C2=A0subject:=
 {
=C2=A0 =C2=A0 =C2=A0 id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=
=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=80=9D],
=C2=A0 =C2=A0 =C2=
=A0 assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifiable_crede=
ntial=E2=80=9D, =E2=80=9Csaml" ]
=C2=A0 =C2=A0}
}<=
/div>

This request says that I=E2=80=99d li=
ke some subset of these identifiers (as plain text in the response) and som=
e subset of signed assertions in the given formats. Each one would have an =
associated space in the return. I=E2=80=99m not picturing that the =E2=80=
=9Cid=E2=80=9D field values would affect the contents of the assertions: so=
 I could ask for an email address identifier but get back an ID token that =
had only the subject identifier. Maybe that=E2=80=99s not the right model? =
But it=E2=80=99s at least simple and deterministic this way, and it=E2=80=
=99s something to play with.

Note: The =E2=80=9Cid=
=E2=80=9D names are taken from=C2=A0https://to=
ols.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.html, the =
=E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=99t see a sou=
rce that collected them. If you wanted specific bundles of claims about the=
 user from a UserInfoEndpoint, for example, you=E2=80=99d have something li=
ke:

{
=C2=A0 =C2=A0subject: {=

=C2=A0 =C2=A0 =C2=A0 id: [ =E2=80=9Caccount=E2=80=9D,=
 =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=80=9D],
=
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=
=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
=C2=A0 =C2=A0},
=C2=A0 =C2=A0resources: [{
=C2=A0 =C2=A0 =C2=A0 =C2=A0type: =E2=80=9Cuserinfo=E2=80=9D,
=C2=A0 =C2=A0 =C2=A0 =C2=A0datatypes: [ =E2=80=9Copenid=
=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =E2=80=9Cphone=E2=80=9D, =E2=80=9Cema=
il=E2=80=9D ]
=C2=A0 }]
}

This is an example for a specific kind=
 of resource, and I don=E2=80=99t think that GNAP should define the =E2=80=
=9Cuserinfo=E2=80=9D schema here, or the datatype values therein. That shou=
ld be work outside of GNAP, probably for the OIDF.

This approach is extensible in several ways, each of them for a specific r=
eason that I think is clear:

=C2=A0- new values in=
 the =E2=80=9Cid=E2=80=9D field to give new identifiers
=C2=A0- n=
ew values in the =E2=80=9Cassertion=E2=80=9D field to give new assertion fo=
rmats
=C2=A0- new fields under the =E2=80=9Csubject=E2=80=9D head=
ing=C2=A0
=C2=A0- new resource types besides =E2=80=9Cuserinfo=E2=
=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or =E2=80=9Cfacebook-profile=E2=80=
=9D for instance)
=C2=A0- new datatypes within the =E2=80=9Cuseri=
nfo=E2=80=9D resource type
=C2=A0- new top-level request paramete=
rs

As per the other thread, if you wanted to use t=
he OIDC query language, you=E2=80=99d package it separately as a top-level =
request parameter since it can include both the ID token response and the a=
ccess token response and we shouldn=E2=80=99t be encouraging mixing these t=
hings together.

=C2=A0=E2=80=94 Justin
On Jul 10, 2020, at 5:00 PM, Dick Hardt <=
;dick.hardt@gmail=
.com> wrote:

It looks to me that our =
different views of what is in scope for GNAP are the differences below.
Per the subject line, I'm looking at how the client acq=
uires claims about the user. You don't think that is in scope, and that=
 a different layer will solve that.

I think we sho=
uld learn from OIDC being on top of OAuth, and GNAP should be able return A=
NY claim, not just identifier claims. There are use cases that may be diffi=
cult to support if we do not have that functionality in scope, such as some=
 of the ones I list below, and it seems pretty straightforward to support A=
NY claim if we are supporting identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09 PM Justin Richer <jricher@mit.edu> wrot=
e:


On Jul 10, 2020, at 2:15 PM, Dick Hardt=
 <dick.hardt@g=
mail.com> wrote:

inline ...=C2=A0

On Thu, Jul 9, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wr=
ote:
Yes, t=
he core idea is to not have to parse an assertion to get back the core auth=
entication information, which consists of an identifier (iss/sub pair in OI=
DC, but could be a number of things). Sometimes the client is going to want=
 the rest of the identity information, but=C2=A0If the user=E2=80=99s logge=
d into the client before, the client has likely cached that info and probab=
ly won=E2=80=99t need it, and sending it would be a violation of privacy pr=
inciples.. The client would want the info pretty much just in these cases:<=
div>
=C2=A01. The client has never seen the user before.=C2=
=A0
=C2=A02. The user=E2=80=99s information has been updated sinc=
e the last time the client saw it.

<=
div>Agreed
=C2=A0

Now for case (1), how would the client kno=
w if it wants to request the user=E2=80=99s profile info or not, since it d=
oesn=E2=80=99t know who the user is? 

But the client could know who the user is. The client may have used =
a different AS to authenticate the user. 

In these cases, the client is not going to be =
requesting identity information from the AS to log the user in, so it=E2=80=
=99s not relevant to the use case. The client will have an opportunity to p=
ush that information to the AS.

The User may have self i=
dentified to the client. The client may have a cookie saying who the user w=
as and the user said that was them. While the latter cases are really a str=
ong hint, they are likely right most of the time and can lead to a user exp=
erience basde on that hint
<=
br>
In these cases, the AS might be able to guess if the client h=
as info about the user already, but probably not. And the assumptions fall =
apart if it=E2=80=99s in fact a different user that ends up logging in, whi=
ch is of course possible (the hint you gave doesn=E2=80=99t match the ident=
ity of the current user after the AS validates them). This possibility lead=
s to clients always asking for everything every time and the server providi=
ng everything every time. That=E2=80=99s a pattern I think we should avoid =
in an ultimate solution =E2=80=94 but ultimately, I don=E2=80=99t think tha=
t this kind of protocol decision is inside of GNAP.

=C2=
=A0
And th=
e AS won=E2=80=99t know if client is going to want the profile info, since =
the AS won=E2=80=99t know if the client has the user=E2=80=99s info or not.=
 Sure, the AS might have seen that client and that user combo previously, b=
ut it doesn=E2=80=99t know if the client needs an update.

The client can share with the AS the user it kno=
ws or thinks it is dealing with, which could let the AS respond if the info=
rmation was new. This could be the case for an AS that is providing claims,=
 but not authentication, and could happen silently. The user would only int=
eract if the user information had changed, and the client wanted the update=
d information.
=C2=A0
<=
div>
See above.


And for (2), the client won=E2=
=80=99t know if the user=E2=80=99s info has been updated or not because it =
doesn=E2=80=99t know who the user is yet. If the AS can provide some time o=
f updated stamp to the client, the client can pull the new info when it nee=
ds it.

See above.

See above.

<=
div>=C2=A0

If you ignore both of these cases and put all the user info=
rmation inline with the main request/response, you end up in a situation wh=
ere the client always requests everything and the server always provides ev=
erything, since you can=E2=80=99t be sure you=E2=80=99re not in situation (=
1) or (2) ahead of time.

See ab=
ove. There are a number of other states the client could be in.
<=
br>
For example, the client could be stateless about user informa=
tion, so it knows it is ALWAYS in state 1.

A stateless client would need to fetch approp=
riate user information every time, then. But that=E2=80=99s an optimization=
 for a very specific case.

=C2=A0

This is really wh=
at I mean about the two-stage identity protocol. 
<=
div>
I know what it is. Per above, GNAP lets us support a wid=
er set of use cases. Why limit ourselves to what OIDC supported?

We aren=E2=80=99t limit=
ing the protocol, but instead limiting the scope of what we define internal=
 to the GNAP protocol. There=E2=80=99s a lot of room for innovation on top =
of it.

=C2=A0
In the first stage, you push the bare minimum of wha=
t you need to get the user known to the client. In the second stage, the cl=
ient uses its access token to call an API to get whatever else it needs to =
know about the user. 

From a pr=
ivacy perspective in non-enterprise use cases, I think the user should give=
 consent to any updated personal information to a client. In general, the=
=C2=A0client should not be able to get the latest information about a user =
whenever it wants.

This is about the rights associated with the access token, then. And =
an access token doesn=E2=80=99t have to keep working if the AS has a policy=
 that says it won=E2=80=99t. The AS/RS could easily decide that a particula=
r access token will only return data that hasn=E2=80=99t been changed. Mayb=
e it stops working after the data changes, or it just returns old data, or =
any number of things. This is for the AS/RS to decide and this is pretty st=
andard interpretation of the token, nothing special here because we=E2=80=
=99re dealing with identity.

=C2=A0=E2=80=94 Justi=
n

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







-- 
Txauth mailing list
Txauth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/txauth
<=
br>-- 

Txauth mailing list

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



--000000000000543cf705aaba289b--


From nobody Sat Jul 18 17:59: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 706273A0EE4 for ; Sat, 18 Jul 2020 17:58:58 -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_FILL_THIS_FORM_SHORT=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 mCT240AWCysI for ; Sat, 18 Jul 2020 17:58: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 185D83A0EE2 for ; Sat, 18 Jul 2020 17:58:55 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id h22so16613071lji.9 for ; Sat, 18 Jul 2020 17:58: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=DguDxTBcE33lDUDnEPYob8oBISaDBANm9GrDepketQI=; b=SunFkGR+Cdem5YORBKvW8PJJi3FwB5VvFGLJerpJVe/Lj9uHpJXc0z09SbvTiq0QQn CwvGjgv39Lsjasi51UNX98dp9wwmBVS/pK0Uc+hporoKcjpPYXNJ3QxFab63BXgo81pT xuJB3inU0Da4fnPovxjb61EoH0OCYhlwBSCDd3Cd/If1iPyqtNvqI+iMf1awhXH7e2mR c20WfaBSecSm3l3aN7wA85OjufPJiFaLsAad+VjFLC1UNkcygSojLU7niTZto5Zj385W 0X5VdpdWMGs6yAd8FkRiSxlFVQ+ONkFj962fwm4PHWLh0lahE/OOKpKixXOsp855wro0 WJGw==
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=DguDxTBcE33lDUDnEPYob8oBISaDBANm9GrDepketQI=; b=NHEvTsNXpeMMDleSF8wDlqShIOFAgTg1rBKcp595FgAhJ560XwmzVHrfYcyauy6CTo ahGlLtGpInUuyv1bEYYW+hjNQnf5IYFy/tbuf0uZ5Buc+HZFMwEZGuwH9+rVyAvaPUBa K5aC+hb6aID52cpyra+7QPwfSODyejNj/mOCXDOK2aF0vNgRK9qN2wYSnAqgktBlvpA1 cjcGv2I4SBY4kwomWESMFUqKUaZ9AG9cC36UNAaJV7qQqGf0UQ9VxHISCXadlWyFf4UM oEVoDYKEhy3xanM39oQu1F4jepmurtydH8Xbl1Wl9HuzhfGe9Lon2BOwCEE+AZwsft9V UTgw==
X-Gm-Message-State: AOAM531TeIpU4N9fMEGWyRw15hmlWW8z2enkECAo2VsP7T0pdvH/fnZo ba7AlPs3NDYfrVrkC/lzToydJK8mD77usBG2Yyw=
X-Google-Smtp-Source: ABdhPJzo1l6FdCR1O58N59rTurRpR7PkcpOqw0PhZExEjI32SgkvUtg4Myhrz/3CpYV9i7t9lt3yThojhb0tDQLEbUM=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr7683924ljn.5.1595120332896; Sat, 18 Jul 2020 17:58:52 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu>  <174F2061-3F0F-49B2-A18F-58DF658E4473@mit.edu>    
In-Reply-To: 
From: Dick Hardt 
Date: Sat, 18 Jul 2020 17:58:16 -0700
Message-ID: 
To: Tom Jones 
Cc: Justin Richer , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d0fe1105aac0e46b"
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 19 Jul 2020 00:58:58 -0000

--000000000000d0fe1105aac0e46b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Tom

While I think defining claims is out of scope of the WG, I think enabling a
client to obtain claims about a user is in scope.
Would you consider authorization for the release of claims to be part of
the purpose of this WG?

I'm concerned about the XYZ shift to subject identifiers from claims, and
pushing claims to a higher layer, as it may indicate to developers that
they can ONLY ask for a user identifier.

When I think of a claim, I include any and all identifiers, but I also
include user attributes such as under-13, over-21,
student-at-an-accredited-school, resident of city/state/province/country.

GNAP can enable a client to ask for only the claims it needs, preserving
user privacy, and compliance with many privacy regulations.

Would you agree?

/Dick




On Sat, Jul 18, 2020 at 9:56 AM Tom Jones 
wrote:

> I agree with Justin's comment " what we should do, as we define GNAP as a
> protocol, is focus on this one, limited slice of the identity space and n=
ot
> spiral into others."
> The title "Authorization" should rule the purposes of this group above al=
l
> else.
>
> The earlier statement that the client should know who the user is - is
> just plain WRONG. The client should only know the information the user is
> willing to share with the client.
> It is now the law in California that the client cannot demand identity
> information that is not required for a legitimate business purpose.
> There are some clients that act as fiduciaries for the user (financial an=
d
> healthcare come to mind), but as a general rule the "client" is not to be
> trusted by the user.
> I understand most of the people on this list are paid by the client's of
> the world, but you are still bound by the laws that apply to those client=
s.
>
> Peace ..tom
>
>
> On Mon, Jul 13, 2020 at 12:31 PM Justin Richer  wrote:
>
>> A quick note, as my choice of language below seems to have been
>> confusing. First there is a typo, where the word =E2=80=9Cit=E2=80=9D sh=
ould have been =E2=80=9Cin=E2=80=9D
>> to read:
>>
>> I am saying that GNAP, *in* its definition within this working group,
>> should be limited to identifier claims.
>>
>>
>> And second, there seems to be confusion around whether I=E2=80=99m tryin=
g to
>> argue about the scope =E2=80=9Callowed=E2=80=9D by the charter by saying=
 =E2=80=9Cits definition
>> within this working group=E2=80=9D here.
>>
>> To be clear, we as the working group are *defining* GNAP the protocol.
>> It has not yet been defined, and that=E2=80=99s why were all here. The c=
harter
>> doesn=E2=80=99t define it. The input specs don=E2=80=99t define it. The =
working group
>> defines it, and my stance as a contributor to this WG is that we should
>> focus on a delegation protocol with some basic identifier query support =
and
>> leave the full fledged identity protocol to different work.
>>
>> We=E2=80=99ve already got our hands full here without taking all of that=
 on,
>> especially since I do believe we need to build GNAP in such a way as to
>> facilitate its extension in several known directions, including a full
>> identity protocol. If we do things right here, we can see GNAP as the ba=
sis
>> of a large number of things out there in the world.
>>
>> So my stance in what we should do, as we define GNAP as a protocol, is
>> focus on this one, limited slice of the identity space and not spiral in=
to
>> others.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 13, 2020, at 2:51 PM, Justin Richer  wrote:
>>
>> I am saying that GNAP, it its definition within this working group,
>> should be limited to identifier claims. Other claims can come from other
>> protocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop t=
hem from
>> being built, but in my opinion we shouldn=E2=80=99t be defining those he=
re. See the
>> discussion below on the extensibility avenues of this approach.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 13, 2020, at 2:12 PM, Dick Hardt  wrote:
>>
>> I agree that an API to return claims is useful. I think we have agreed o=
n
>> that.
>>
>> Using the SubjectIdentifiers schema is another schema that would be
>> useful for GNAP to support.
>>
>> I disagree that GNAP should be limited to identifier claims.
>>
>> =E1=90=A7
>>
>> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer  wrote:
>>
>>> One thing I think we should learn from OIDC is that returning claims
>>> from an API, and not just an assertion or direct response, is a powerfu=
l
>>> and useful pattern. We have an opportunity to separate these cleanly, w=
here
>>> OIDC didn=E2=80=99t have the opportunity in defining the =E2=80=9Cclaim=
s=E2=80=9D request parameter.
>>>
>>> As an alternative to the current XYZ and XAuth syntaxes, over the
>>> weekend I=E2=80=99ve been playing with something that would look like t=
his strawman
>>> in the request:
>>>
>>>
>>> {
>>>    subject: {
>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=
=9Ciss-sub=E2=80=9D],
>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifiable=
_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>    }
>>> }
>>>
>>>
>>> This request says that I=E2=80=99d like some subset of these identifier=
s (as
>>> plain text in the response) and some subset of signed assertions in the
>>> given formats. Each one would have an associated space in the return. I=
=E2=80=99m
>>> not picturing that the =E2=80=9Cid=E2=80=9D field values would affect t=
he contents of the
>>> assertions: so I could ask for an email address identifier but get back=
 an
>>> ID token that had only the subject identifier. Maybe that=E2=80=99s not=
 the right
>>> model? But it=E2=80=99s at least simple and deterministic this way, and=
 it=E2=80=99s
>>> something to play with.
>>>
>>> Note: The =E2=80=9Cid=E2=80=9D names are taken from
>>> https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.ht=
ml,
>>> the =E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=99t s=
ee a source that collected
>>> them. If you wanted specific bundles of claims about the user from a
>>> UserInfoEndpoint, for example, you=E2=80=99d have something like:
>>>
>>> {
>>>    subject: {
>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=
=9Ciss-sub=E2=80=9D],
>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifiable=
_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>    },
>>>    resources: [{
>>>        type: =E2=80=9Cuserinfo=E2=80=9D,
>>>        datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D=
, =E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
>>>   }]
>>> }
>>>
>>>
>>> This is an example for a specific kind of resource, and I don=E2=80=99t=
 think
>>> that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, or =
the datatype values
>>> therein. That should be work outside of GNAP, probably for the OIDF.
>>>
>>> This approach is extensible in several ways, each of them for a specifi=
c
>>> reason that I think is clear:
>>>
>>>  - new values in the =E2=80=9Cid=E2=80=9D field to give new identifiers
>>>  - new values in the =E2=80=9Cassertion=E2=80=9D field to give new asse=
rtion formats
>>>  - new fields under the =E2=80=9Csubject=E2=80=9D heading
>>>  - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=
=9Cscim-v1=E2=80=9D or
>>> =E2=80=9Cfacebook-profile=E2=80=9D for instance)
>>>  - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource type
>>>  - new top-level request parameters
>>>
>>> As per the other thread, if you wanted to use the OIDC query language,
>>> you=E2=80=99d package it separately as a top-level request parameter si=
nce it can
>>> include both the ID token response and the access token response and we
>>> shouldn=E2=80=99t be encouraging mixing these things together.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 10, 2020, at 5:00 PM, Dick Hardt  wrote:
>>>
>>> It looks to me that our different views of what is in scope for GNAP ar=
e
>>> the differences below.
>>>
>>> Per the subject line, I'm looking at how the client acquires claims
>>> about the user. You don't think that is in scope, and that a different
>>> layer will solve that.
>>>
>>> I think we should learn from OIDC being on top of OAuth, and GNAP shoul=
d
>>> be able return ANY claim, not just identifier claims. There are use cas=
es
>>> that may be difficult to support if we do not have that functionality i=
n
>>> scope, such as some of the ones I list below, and it seems pretty
>>> straightforward to support ANY claim if we are supporting identifiers.
>>>
>>> /Dick
>>>
>>>
>>> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer  wrote:
>>>
>>>>
>>>>
>>>> On Jul 10, 2020, at 2:15 PM, Dick Hardt  wrote:
>>>>
>>>>
>>>> inline ...
>>>>
>>>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer  wrote:
>>>>
>>>>> Yes, the core idea is to not have to parse an assertion to get back
>>>>> the core authentication information, which consists of an identifier
>>>>> (iss/sub pair in OIDC, but could be a number of things). Sometimes th=
e
>>>>> client is going to want the rest of the identity information, but If =
the
>>>>> user=E2=80=99s logged into the client before, the client has likely c=
ached that
>>>>> info and probably won=E2=80=99t need it, and sending it would be a vi=
olation of
>>>>> privacy principles.. The client would want the info pretty much just =
in
>>>>> these cases:
>>>>>
>>>>>  1. The client has never seen the user before.
>>>>>  2. The user=E2=80=99s information has been updated since the last ti=
me the
>>>>> client saw it.
>>>>>
>>>>
>>>> Agreed
>>>>
>>>>
>>>>>
>>>>> Now for case (1), how would the client know if it wants to request th=
e
>>>>> user=E2=80=99s profile info or not, since it doesn=E2=80=99t know who=
 the user is?
>>>>>
>>>>
>>>> But the client could know who the user is. The client may have used a
>>>> different AS to authenticate the user.
>>>>
>>>>
>>>> In these cases, the client is not going to be requesting identity
>>>> information from the AS to log the user in, so it=E2=80=99s not releva=
nt to the use
>>>> case. The client will have an opportunity to push that information to =
the
>>>> AS.
>>>>
>>>> The User may have self identified to the client. The client may have a
>>>> cookie saying who the user was and the user said that was them. While =
the
>>>> latter cases are really a strong hint, they are likely right most of t=
he
>>>> time and can lead to a user experience basde on that hint
>>>>
>>>>
>>>> In these cases, the AS might be able to guess if the client has info
>>>> about the user already, but probably not. And the assumptions fall apa=
rt if
>>>> it=E2=80=99s in fact a different user that ends up logging in, which i=
s of course
>>>> possible (the hint you gave doesn=E2=80=99t match the identity of the =
current user
>>>> after the AS validates them). This possibility leads to clients always
>>>> asking for everything every time and the server providing everything e=
very
>>>> time. That=E2=80=99s a pattern I think we should avoid in an ultimate =
solution =E2=80=94
>>>> but ultimately, I don=E2=80=99t think that this kind of protocol decis=
ion is inside
>>>> of GNAP.
>>>>
>>>>
>>>>
>>>>> And the AS won=E2=80=99t know if client is going to want the profile =
info,
>>>>> since the AS won=E2=80=99t know if the client has the user=E2=80=99s =
info or not. Sure, the
>>>>> AS might have seen that client and that user combo previously, but it
>>>>> doesn=E2=80=99t know if the client needs an update.
>>>>>
>>>>
>>>> The client can share with the AS the user it knows or thinks it is
>>>> dealing with, which could let the AS respond if the information was ne=
w.
>>>> This could be the case for an AS that is providing claims, but not
>>>> authentication, and could happen silently. The user would only interac=
t if
>>>> the user information had changed, and the client wanted the updated
>>>> information.
>>>>
>>>>
>>>>
>>>> See above.
>>>>
>>>>
>>>>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s info=
 has been updated
>>>>> or not because it doesn=E2=80=99t know who the user is yet. If the AS=
 can provide
>>>>> some time of updated stamp to the client, the client can pull the new=
 info
>>>>> when it needs it.
>>>>>
>>>>
>>>> See above.
>>>>
>>>>
>>>> See above.
>>>>
>>>>
>>>>
>>>>>
>>>>> If you ignore both of these cases and put all the user information
>>>>> inline with the main request/response, you end up in a situation wher=
e the
>>>>> client always requests everything and the server always provides
>>>>> everything, since you can=E2=80=99t be sure you=E2=80=99re not in sit=
uation (1) or (2)
>>>>> ahead of time.
>>>>>
>>>>
>>>> See above. There are a number of other states the client could be in.
>>>>
>>>> For example, the client could be stateless about user information, so
>>>> it knows it is ALWAYS in state 1.
>>>>
>>>>
>>>> A stateless client would need to fetch appropriate user information
>>>> every time, then. But that=E2=80=99s an optimization for a very specif=
ic case.
>>>>
>>>>
>>>>
>>>>>
>>>>> This is really what I mean about the two-stage identity protocol.
>>>>>
>>>>
>>>> I know what it is. Per above, GNAP lets us support a wider set of use
>>>> cases. Why limit ourselves to what OIDC supported?
>>>>
>>>>
>>>> We aren=E2=80=99t limiting the protocol, but instead limiting the scop=
e of what
>>>> we define internal to the GNAP protocol. There=E2=80=99s a lot of room=
 for
>>>> innovation on top of it.
>>>>
>>>>
>>>>
>>>>> In the first stage, you push the bare minimum of what you need to get
>>>>> the user known to the client. In the second stage, the client uses it=
s
>>>>> access token to call an API to get whatever else it needs to know abo=
ut the
>>>>> user.
>>>>>
>>>>
>>>> From a privacy perspective in non-enterprise use cases, I think the
>>>> user should give consent to any updated personal information to a clie=
nt.
>>>> In general, the client should not be able to get the latest informatio=
n
>>>> about a user whenever it wants.
>>>>
>>>>
>>>> This is about the rights associated with the access token, then. And a=
n
>>>> access token doesn=E2=80=99t have to keep working if the AS has a poli=
cy that says
>>>> it won=E2=80=99t. The AS/RS could easily decide that a particular acce=
ss token will
>>>> only return data that hasn=E2=80=99t been changed. Maybe it stops work=
ing after the
>>>> data changes, or it just returns old data, or any number of things. Th=
is is
>>>> for the AS/RS to decide and this is pretty standard interpretation of =
the
>>>> token, nothing special here because we=E2=80=99re dealing with identit=
y.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>>
>>>> /Dick
>>>> =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
>>
>

--000000000000d0fe1105aac0e46b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey Tom

While I think =
defining claims=C2=A0is out of scope of the WG, I think enabling a client t=
o obtain claims about a user is in scope.
Would you consider=
 authorization for the release of claims to be part of the purpose of this =
WG?

I'm concerned about the X=
YZ shift to subject identifiers from claims, and pushing claims to a higher=
 layer, as it may indicate to developers that they can ONLY ask for a user =
identifier.=C2=A0

When I think of a claim, I inclu=
de any and all identifiers, but I also include user attributes such as unde=
r-13, over-21, student-at-an-accredited-school, resident of city/state/prov=
ince/country.

GNAP can enable a client to ask for =
only the claims it needs, preserving user privacy, and compliance with many=
 privacy regulations.

Would you agree?
<=
br>
/Dick



=


On Sat, Jul 18, 2020 at 9:56 AM Tom Jones <thomasclinganjones@gmail.c=
om> wrote:
I agree with Justin's comment "=C2=A0what we sh=
ould do, as we define GNAP as a protocol, is focus on this one, limited sli=
ce of the identity space and not spiral into others."
The title &q=
uot;Authorization" should rule the purposes of this group above all el=
se.

The earlier statement=C2=A0that the client shoul=
d know who the user is - is just plain WRONG. The client should only know t=
he information the user is willing to share with the client.
It i=
s now the law in California that the client cannot demand=C2=A0identity inf=
ormation that is not required for a legitimate business purpose.
=
There are some clients that act as fiduciaries for the user (financial=C2=
=A0and healthcare come to mind), but as a general rule the "client&quo=
t; is not to be trusted by the user.
I understand most of the peo=
ple=C2=A0on this list are paid by the client's of the world, but you ar=
e still bound by the laws that apply to those clients.

Peace ..tom


On Mon, Jul 13, 2020 at 12:31 PM Justin Riche=
r <jricher@mit.edu<=
/a>> wrote:
<=
div>A quick note, as my choice of language below seems to have been confusi=
ng. First there is a typo, where the word =E2=80=9Cit=E2=80=9D should have =
been =E2=80=9Cin=E2=80=9D to read:

I am saying that GNAP, in its definition within this worki=
ng group, should be limited to identifier claims.
And second, there seems to be confusion around whether I=E2=80=
=99m trying to argue about the scope =E2=80=9Callowed=E2=80=9D by the chart=
er by saying =E2=80=9Cits definition within this working group=E2=80=9D her=
e.=C2=A0

To be clear, we as the working group are =
defining GNAP the protocol. It has not yet been defined, and that=E2=
=80=99s why were all here. The charter doesn=E2=80=99t define it. The input=
 specs don=E2=80=99t define it. The working group defines it, and my stance=
 as a contributor to this WG is that we should focus on a delegation protoc=
ol with some basic identifier query support and leave the full fledged iden=
tity protocol to different work.=C2=A0

We=E2=80=99=
ve already got our hands full here without taking all of that on, especiall=
y since I do believe we need to build GNAP in such a way as to facilitate i=
ts extension in several known directions, including a full identity protoco=
l. If we do things right here, we can see GNAP as the basis of a large numb=
er of things out there in the world.=C2=A0

So my s=
tance in what we should do, as we define GNAP as a protocol, is focus on th=
is one, limited slice of the identity space and not spiral into others.

=C2=A0=E2=80=94 Justin

On Jul 13, 2020, at 2:51 PM, Justin Richer <jricher@mit.edu> wrote:


I am saying that GNAP, it its definition within this working group, sh=
ould be limited to identifier claims. Other claims can come from other prot=
ocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop them fro=
m being built, but in my opinion we shouldn=E2=80=99t be defining those her=
e. See the discussion below on the extensibility avenues of this approach.<=
div>
=C2=A0=E2=80=94 Justin

On Jul 13, 2020, at 2:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I agree that an API to return claims is useful=
. I think we have agreed on that.=C2=A0

Using the Subjec=
tIdentifiers schema is another schema that would be useful for GNAP to supp=
ort.=C2=A0

I disagree=C2=A0that GNAP should be lim=
ited to identifier claims.=C2=A0

3D""=E1=90=A7

On Mon, Jul 13, 2020 at 7:16 AM Justin Richer <jricher@mit.edu> wrote=
:
One thing=
 I think we should learn from OIDC is that returning claims from an API, an=
d not just an assertion or direct response, is a powerful and useful patter=
n. We have an opportunity to separate these cleanly, where OIDC didn=E2=80=
=99t have the opportunity in defining the =E2=80=9Cclaims=E2=80=9D request =
parameter.

As an alternative to the current XYZ and XAut=
h syntaxes, over the weekend I=E2=80=99ve been playing with something that =
would look like this strawman in the request:


=

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Codic_id_token=
=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
=C2=A0 =C2=A0}
}

T=
his request says that I=E2=80=99d like some subset of these identifiers (as=
 plain text in the response) and some subset of signed assertions in the gi=
ven formats. Each one would have an associated space in the return. I=E2=80=
=99m not picturing that the =E2=80=9Cid=E2=80=9D field values would affect =
the contents of the assertions: so I could ask for an email address identif=
ier but get back an ID token that had only the subject identifier. Maybe th=
at=E2=80=99s not the right model? But it=E2=80=99s at least simple and dete=
rministic this way, and it=E2=80=99s something to play with.

=

Note: The =E2=80=9Cid=E2=80=9D names are taken from=C2=A0https://tools.ietf.org/id/draft-ietf-secevent-subject=
-identifiers-05.html, the =E2=80=9Cassertion=E2=80=9D names are made up=
 as I didn=E2=80=99t see a source that collected them. If you wanted specif=
ic bundles of claims about the user from a UserInfoEndpoint, for example, y=
ou=E2=80=99d have something like:

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Cod=
ic_id_token=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csam=
l" ]
=C2=A0 =C2=A0},
=C2=A0 =
=C2=A0resources: [{
=C2=A0 =C2=A0 =C2=A0 =C2=A0type: =
=E2=80=9Cuserinfo=E2=80=9D,
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =E2=80=
=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
=C2=A0 }]=

}

This is=
 an example for a specific kind of resource, and I don=E2=80=99t think that=
 GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, or the data=
type values therein. That should be work outside of GNAP, probably for the =
OIDF.

This approach is extensible in several ways,=
 each of them for a specific reason that I think is clear:

=C2=A0- new values in the =E2=80=9Cid=E2=80=9D field to give new i=
dentifiers
=C2=A0- new values in the =E2=80=9Cassertion=E2=80=9D =
field to give new assertion formats
=C2=A0- new fields under the =
=E2=80=9Csubject=E2=80=9D heading=C2=A0
=C2=A0- new resource type=
s besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or =E2=
=80=9Cfacebook-profile=E2=80=9D for instance)
=C2=A0- new datatyp=
es within the =E2=80=9Cuserinfo=E2=80=9D resource type
=C2=A0- ne=
w top-level request parameters

As per the other th=
read, if you wanted to use the OIDC query language, you=E2=80=99d package i=
t separately as a top-level request parameter since it can include both the=
 ID token response and the access token response and we shouldn=E2=80=99t b=
e encouraging mixing these things together.

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

On Jul 10, 2020=
, at 5:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It looks to me that our different views of what is in scope for GNAP ar=
e the differences below.

Per the subject line, I'm l=
ooking at how the client acquires claims about the user. You don't thin=
k that is in scope, and that a different layer will solve that.
<=
br>
I think we should learn from OIDC being on top of OAuth, and =
GNAP should be able return ANY claim, not just identifier claims. There are=
 use cases that may be difficult to support if we do not have that function=
ality in scope, such as some of the ones I list below, and it seems pretty =
straightforward to support ANY claim if we are supporting identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09=
 PM Justin Richer <=
jricher@mit.edu> wrote:


On Jul 10, =
2020, at 2:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


inline ...=C2=A0

On Thu, Jul 9, 2020 at 5=
:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea is to not have to parse an assert=
ion to get back the core authentication information, which consists of an i=
dentifier (iss/sub pair in OIDC, but could be a number of things). Sometime=
s the client is going to want the rest of the identity information, but=C2=
=A0If the user=E2=80=99s logged into the client before, the client has like=
ly cached that info and probably won=E2=80=99t need it, and sending it woul=
d be a violation of privacy principles.. The client would want the info pre=
tty much just in these cases:

=C2=A01. The client has ne=
ver seen the user before.=C2=A0
=C2=A02. The user=E2=80=99s infor=
mation has been updated since the last time the client saw it.
<=
/blockquote>

Agreed
=C2=A0

Now for case (=
1), how would the client know if it wants to request the user=E2=80=99s pro=
file info or not, since it doesn=E2=80=99t know who the user is? 

But the client could know who the user i=
s. The client may have used a different AS to authenticate the user. 
=


In these cases, th=
e client is not going to be requesting identity information from the AS to =
log the user in, so it=E2=80=99s not relevant to the use case. The client w=
ill have an opportunity to push that information to the AS.

<=
div>The User may have self identified to the client. The client may have a =
cookie saying who the user was and the user said that was them. While the l=
atter cases are really a strong hint, they are likely right most of the tim=
e and can lead to a user experience basde on that hint

In these cases, the AS might be a=
ble to guess if the client has info about the user already, but probably no=
t. And the assumptions fall apart if it=E2=80=99s in fact a different user =
that ends up logging in, which is of course possible (the hint you gave doe=
sn=E2=80=99t match the identity of the current user after the AS validates =
them). This possibility leads to clients always asking for everything every=
 time and the server providing everything every time. That=E2=80=99s a patt=
ern I think we should avoid in an ultimate solution =E2=80=94 but ultimatel=
y, I don=E2=80=99t think that this kind of protocol decision is inside of G=
NAP.

=C2=A0
And the AS won=E2=80=99t know if client is going to wa=
nt the profile info, since the AS won=E2=80=99t know if the client has the =
user=E2=80=99s info or not. Sure, the AS might have seen that client and th=
at user combo previously, but it doesn=E2=80=99t know if the client needs a=
n update.

The client can share =
with the AS the user it knows or thinks it is dealing with, which could let=
 the AS respond if the information was new. This could be the case for an A=
S that is providing claims, but not authentication, and could happen silent=
ly. The user would only interact if the user information had changed, and t=
he client wanted the updated information.
=C2=A0

See above.


And =
for (2), the client won=E2=80=99t know if the user=E2=80=99s info has been =
updated or not because it doesn=E2=80=99t know who the user is yet. If the =
AS can provide some time of updated stamp to the client, the client can pul=
l the new info when it needs it.

See above.

See a=
bove.

=C2=A0

If you ignore both of these cases=
 and put all the user information inline with the main request/response, yo=
u end up in a situation where the client always requests everything and the=
 server always provides everything, since you can=E2=80=99t be sure you=E2=
=80=99re not in situation (1) or (2) ahead of time.

See above. There are a number of other states the clie=
nt could be in.

For example, the client could be s=
tateless about user information, so it knows it is ALWAYS in state 1.
=


A stateless client=
 would need to fetch appropriate user information every time, then. But tha=
t=E2=80=99s an optimization for a very specific case.

=
=C2=A0
This is really what I mean about the two-stage identity protoco=
l. 

I know what it is. Per abov=
e, GNAP lets us support a wider set of use cases. Why limit ourselves to wh=
at OIDC supported?

We aren=E2=80=99t limiting the protocol, but instead limiting the sco=
pe of what we define internal to the GNAP protocol. There=E2=80=99s a lot o=
f room for innovation on top of it.

=C2=A0
In the first stage, you=
 push the bare minimum of what you need to get the user known to the client=
. In the second stage, the client uses its access token to call an API to g=
et whatever else it needs to know about the user. 
=


From a privacy perspective in non-enterprise use cases,=
 I think the user should give consent to any updated personal information t=
o a client. In general, the=C2=A0client should not be able to get the lates=
t information about a user whenever it wants.
=


This is about the rights associated with t=
he access token, then. And an access token doesn=E2=80=99t have to keep wor=
king if the AS has a policy that says it won=E2=80=99t. The AS/RS could eas=
ily decide that a particular access token will only return data that hasn=
=E2=80=99t been changed. Maybe it stops working after the data changes, or =
it just returns old data, or any number of things. This is for the AS/RS to=
 decide and this is pretty standard interpretation of the token, nothing sp=
ecial here because we=E2=80=99re dealing with identity.

=C2=A0=E2=80=94 Justin

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







-- 
Txauth mailing list
Txauth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/txauth
<=
br>-- 

Txauth mailing list

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




--000000000000d0fe1105aac0e46b--


From nobody Sat Jul 18 17:59: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 70F433A0F41 for ; Sat, 18 Jul 2020 17:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.097
X-Spam-Level: 
X-Spam-Status: No, score=-0.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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, 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 33b5o5txTeOP for ; Sat, 18 Jul 2020 17:59:18 -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 C90D33A0F0F for ; Sat, 18 Jul 2020 17:59:15 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id j11so16598893ljo.7 for ; Sat, 18 Jul 2020 17:59: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=G/h2MHkgq1sPb2jicuXpnYLhu4QVIVwOwcHMjjmDJU0=; b=eIRuniEB+gf14DSiprRalZag3pihxJiTCH2sDyMwX9I2EV5nlr5WK9p9oR/ZHrtuHh KZXyOsSR6NfWPmgdRsrAe8hn3VhTN7LMW01PO9jYCfDPfxQOlVHipzMOpQ5InMwxITFG p+8xtw6KcAJ6+AeuitOjZzPSkg+735App4Q/1ldjHeCteG5YZjyloflVoqHquNP8zVSY J8WgHWV6aPZBY6ZQlaC0lhMaYC+hFAmgXrHbCnhOuvPGzxtV5+GvDSS8zpSnrfPHGS/R i0CFyzunDqLFgi/eUjzA+aMpstFazx9YeECYYouZcFZ+f90jtYMiBCXSmXgsJ4d9gcVf 6p1g==
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=G/h2MHkgq1sPb2jicuXpnYLhu4QVIVwOwcHMjjmDJU0=; b=tbV2Hhmu08Sb6IYFigagEUjurpbS90tgddd3Af5Cc2LIe+jVjYaXH2qNk/tURXPjun qetRfd4kBr4L43CQab2LN72mVdV+ZIK6qbRQ7xaTBk4JSyXaDJyrZQbk20930ifG/dxA 7xPtHNftJARwr1XgNoem9ZQdsKz52LzS1xU98QDz46eW/AJySWxZ8c0AJOXy1ThV716H FFBiPQG2o/FWj1ziuLDAT5nVlQZEHIBYyW/H8nDx0Aq0S+5c3X0tcKI6z6nEdPO5IjBx OtYBjXsuGAjsZkjJAjGIsCWAjW2SFkDKtAHQLjdfLciolSKENA5iB8RonHQN0ymeE8f5 iX/g==
X-Gm-Message-State: AOAM530429EwW/BF6qdQyEykxng+yj/M7kIv900lTIQAQ9ch411PMyZP 29kVRojLFixmrbLNIZPBZsQ8JAuVuqvsrShxhhxURVKw
X-Google-Smtp-Source: ABdhPJyk5myKe16P+0ePMlQNofpS3aTNTP5MPf/F29A+0rd5PilnmjfHcS20sb83LgqKRGMj6qhGxUcKGhJWYxlGOjg=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr7688262ljh.110.1595120353939;  Sat, 18 Jul 2020 17:59:13 -0700 (PDT)
MIME-Version: 1.0
References:   <5B2BF4E7-77CD-4DC6-A0C9-E7894CE38A5E@mit.edu>  
In-Reply-To: 
From: Dick Hardt 
Date: Sat, 18 Jul 2020 17:58:38 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001216fa05aac0e6b7"
Archived-At: 
Subject: Re: [Txauth] New version of XYZ Draft
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, 19 Jul 2020 00:59:28 -0000

--0000000000001216fa05aac0e6b7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Justin: how about we let the chairs drive WG conversations on the
goals, and we focus on the technical discussion?

In addition to my questions and observations earlier, here is my feedback
on the new capabilities in XYZ:

2.5.2. Redirect to an Arbitrary Short URL

This looks the same as 2.5.1 except it is short. My concern with both of
these is the AS has no signal on the mode chosen by the client/user. It
could be a redirect on the same device, or decoupled, where the user is now
on a different device. In 2.5.3 you justify a new URL because the AS may
want a different URL for an app. I think that is even more significant
between an on device redirect, and a decoupled experience. By having
different URLs for the different modes in XAuth, the AS can ensure the one
in a decoupled mode is short enough to be scanned if decoupled is
supported. In other words, the mode dictates if it should be short enough
to be scanned.

2.5.3 Open an Application-specific URL

What are you intending "app" to mean? I can think of a device where the
client can open a URL, and a URL could not be associated with an
application on the device. Are you thinking the client will do some
detection if a specific app is available on the device? What if the app is
not on the device? Most platforms don't provide any probing on what other
apps are on a device, so there is no mechanism to detect if the app is
present prior to launching. Is that what you are expecting?

2.5.5. Receive an HTTP Direct Callback

What use cases require this functionality? Contrary to SecEvent, where both
push and poll are specified because a receiver may not be able to have a
public endpoint, the AS has a public endpoint for the client to call. In
GNAP, the client can poll the AS. Why have both?

/Dick



On Sat, Jul 18, 2020 at 7:55 AM Justin Richer  wrote:

> I really don=E2=80=99t see them as shifting towards each other so much as=
 it is
> them adapting and changing based on ongoing efforts. As such I=E2=80=99ve=
 modified
> XYZ not to make it =E2=80=9Clook more like XAuth=E2=80=9D, but rather to =
hopefully improve
> it in some measurable dimensions. So if you wonder why it doesn=E2=80=99t=
 =E2=80=9Clook
> even more like XAuth=E2=80=9D it=E2=80=99s because I don=E2=80=99t think =
that such changes would be
> improvements =E2=80=94 in fact, even with recent improvements, I think th=
ere are a
> still a lot of issues with XAuth=E2=80=99s design and assumptions. XYZ ca=
n, I=E2=80=99m
> sure, also be improved.
>
> The goal here isn=E2=80=99t to take two projects and make them look the s=
ame. The
> goal here is to make one protocol, GNAP, with the best ideas and elements
> engineered into it that we, as a working group, can. It=E2=80=99s not abo=
ut one
> input proposal winning over another, it=E2=80=99s about improving our und=
erstanding
> of all the use cases and possible solutions and coming up with the best
> specification possible. Making things better should always be the goal.
> Progress should always be the goal.
>
> But we aren=E2=80=99t here to build XYZ or XAuth. We=E2=80=99re here to b=
uild GNAP and
> decide what GNAP looks like. XYZ=E2=80=99s structure and design is the be=
st I=E2=80=99ve
> been able to make it so far, and it should be our goal as a WG to move pa=
st
> either XYZ or XAuth and build GNAP even better than any of that.
>
>  =E2=80=94 Justin
>
> On Jul 17, 2020, at 6:46 PM, Dick Hardt  wrote:
>
> XYZ is looking a lot more like XAuth, similar to how XAuth has shifted
> towards XYZ.
>
> I have implemented separate URIs for grants and authorizations, and it
> worked really well.
>
> All 3 of the new capabilities are problematic. Perhaps you did not notice
> that there no longer is a short_uri in XAuth? As I recall, you were oppos=
ed
> to the short URI that was in the earlier drafts of XAuth. In my XAuth
> implementation, I show QR codes in the CLI app. Have you checked out my
> implementation? Have you implemented a QR code? I found that the string d=
id
> not need to be nearly as short as it has in the past.
>
> I still don't understand the requirement to rotate the reference handle. =
I
> read over the pointer you provided last time we discussed it, and
> responded, but I have not heard back from you on that.
>
>
> =E1=90=A7
>
> On Fri, Jul 17, 2020 at 2:36 PM Justin Richer  wrote:
>
>> Most of these are changes I=E2=80=99ve wanted to do for quite some time =
and
>> finally had opportunity to make the edits. As I said below, the core
>> protocol really hasn=E2=80=99t changed in nature, but hopefully it=E2=80=
=99s easier to
>> understand with it laid out in this way.
>>
>> All of these are points that I=E2=80=99ve made previously on the list in
>> discussions, but to answer your questions directly:
>>
>> - Mapping items to separate URLs has been on XYZ=E2=80=99s radar since w=
ell
>> before it was proposed in Xauth, so this is bringing some of that into t=
he
>> concrete system. I still need to implement it to see how well it works i=
n
>> practice.
>>
>> - The need to rotate the reference handle as well as use it externally
>> (the =E2=80=9Cextend a request=E2=80=9D method) both call for having an =
identifier separate
>> from the access URL. It also allows an AS more freedom in how it manages
>> its endpoints, and aligns with the desire to push more information into =
the
>> ongoing request after the initial phase. I=E2=80=99d actually rather the=
 access
>> token management move in that direction, using the token itself as the
>> artifact, but I couldn=E2=80=99t do that and still use the DELETE method=
 for
>> revocation. So that=E2=80=99s an engineering challenge that I think the =
group
>> should discuss, and decide whether it=E2=80=99s worth having the =E2=80=
=9CDELETE=E2=80=9D verb
>> semantics and having that restriction placed on the AS as a consequence.
>>
>> - The DID work is likely better suited for an extension, and always has
>> been. But it was worth having in previous revisions for discussion
>> purposes, especially as a point around how a non-HTTP interaction method
>> would work. I expect to see DIDCOMM, CHAPI, WebAuthN, and other interact=
ion
>> methods in the extensions landscape of GNAP, usable alongside the others=
.
>>
>> And a final point, the interaction setup hasn=E2=80=99t really changed, =
so I=E2=80=99m
>> curious to hear what you think *has* changed there. Even with a couple
>> new capabilities on the way there (short_uri and app) and back (pushback=
),
>> It=E2=80=99s structurally and conceptually identical to previous revisio=
ns.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 17, 2020, at 1:10 PM, Dick Hardt  wrote:
>>
>> Hey Justin,
>>
>> Glad to see that you are aligning on having URIs for the access tokens
>> and the "grant".
>>
>> While the token URI is unique to the token, you have not done the same
>> for a "grant", but have a handle and a non-unique URI.
>>
>> Why not have a unique grant URI similar to the token URI? (a combination
>> of the handle and a non-unique URI) -- this is then both the identifier,
>> and the URL for "management"?
>>
>> Glad to see you have excised the DID references. I don't think the commo=
n
>> use cases are well established there currently.
>>
>> I have LOTS of feedback on your interaction changes, that I'll post late=
r
>> on, and hope that others have feedback on those as well.
>>
>> /Dick
>>
>>
>>
>>
>>
>> On Thu, Jul 16, 2020 at 2:52 PM Justin Richer  wrote:
>>
>>> Hi all,
>>>
>>> I=E2=80=99ve updated the XYZ draft specification. Since the publication=
 tools
>>> are currently locked prior to the upcoming virtual meeting, I have
>>> published it online here:
>>>
>>> https://oauth.xyz/draft-richer-transactional-authz
>>>
>>> This represents a pretty significant refactoring of the specification,
>>> hopefully to make the concepts and capabilities easier to understand. T=
he
>>> core protocol is largely the same as before, but there are a number of
>>> serious updates:
>>>
>>>  - Continuation requests happen at a URL returned in the TX response.
>>> The =E2=80=9Chandle=E2=80=9D is still sent as one of the input values h=
ere, since the
>>> handle can also be used it other contexts.
>>>  - Tokens now can include the resources they are issued for
>>>  - Tokens can have an optional management URI for rotation and
>>> revocation.
>>>  - =E2=80=9Cclaims=E2=80=9D has been removed in favor of =E2=80=9Csubje=
ct=E2=80=9D dealing directly with
>>> identifiers and assertions
>>>  - the =E2=80=9Cuser=E2=80=9D request and response now align with ident=
ifiers and
>>> assertions
>>>  - Extensions and registries are more clearly enumerated throughout the
>>> document
>>>  - DID-related items have been excised in deference to a future possibl=
e
>>> extension
>>>  - Added a =E2=80=9Cpushback=E2=80=9D mechanism to complement the =E2=
=80=9Ccallback=E2=80=9D mechanism
>>>  - Simplified dynamic handle returns and access tokens based on
>>> developer feedback (basically we dropped a bunch of =E2=80=9Cwhat if=E2=
=80=9D stuff that
>>> nobody used or liked, like SHA3 hashes for bearer tokens)
>>>
>>> I=E2=80=99ve also updated the interactive examples on https://oauth.xyz=
/ to
>>> match this new draft. Hopefully it=E2=80=99s consistent with the draft =
text.
>>>
>>> I have not yet, however, updated any of the implementations of XYZ to
>>> take the elements of new syntax into account, so there might be some mo=
re
>>> changes prior to the IETF meeting as I realize what terrible mistakes I=
=E2=80=99ve
>>> made when doing that. :)
>>>
>>> Feedback, as always, is welcomed, and thanks to everyone who=E2=80=99s =
provided
>>> input to the project to date.
>>>
>>>  =E2=80=94 Justin
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>>
>

--0000000000001216fa05aac0e6b7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Ju=
stin: how about we let the chairs drive WG conversations on the goals,=C2=
=A0and we focus on the=C2=A0technical discussion?

=
In addition to my questions and observations earlier, here is my feedback o=
n the new capabilities in XYZ:

2.5.2. Redirect=
 to an Arbitrary Short URL

This looks the same=
 as 2.5.1 except it is short. My concern with both of these is the AS has n=
o signal on the mode chosen by the client/user. It could be a redirect on t=
he same device, or decoupled, where the user is now on a different device. =
In 2.5.3 you justify a new URL because the AS may want a different=C2=A0URL=
 for an app. I think that is even more significant between an on device red=
irect, and a decoupled experience. By having different URLs for the differe=
nt modes in XAuth, the AS can ensure the one in a decoupled mode is short e=
nough to be scanned if decoupled is supported. In other words, the mode dic=
tates if it should be short enough to be scanned.

=
2.5.3 Open an Application-specific URL

What are yo=
u intending "app" to mean? I can think of a device where the clie=
nt can open a URL, and a URL could not be associated with an application on=
 the device. Are you thinking the client will do some detection if a specif=
ic app is available on the device? What if the app is not on the device? Mo=
st platforms don't provide any probing on what other apps are on a devi=
ce, so there is no mechanism to detect if the app is present prior to launc=
hing. Is that what you are expecting?

2.5.5. Recei=
ve an HTTP Direct Callback

What use cases requ=
ire this functionality? Contrary to SecEvent, where both push and poll are =
specified because a receiver=C2=A0may not be able to have a public endpoint=
, the AS has a public endpoint for the=C2=A0client to call. In GNAP, the cl=
ient can poll the AS. Why have both?

/Dick



On Sat, Jul 18, 2020 at 7:55 =
AM Justin Richer <j=
richer@mit.edu> wrote:
I really don=E2=80=99t see them as shifting towards each=
 other so much as it is them adapting and changing based on ongoing efforts=
. As such I=E2=80=99ve modified XYZ not to make it =E2=80=9Clook more like =
XAuth=E2=80=9D, but rather to hopefully improve it in some measurable dimen=
sions. So if you wonder why it doesn=E2=80=99t =E2=80=9Clook even more like=
 XAuth=E2=80=9D it=E2=80=99s because I don=E2=80=99t think that such change=
s would be improvements =E2=80=94 in fact, even with recent improvements, I=
 think there are a still a lot of issues with XAuth=E2=80=99s design and as=
sumptions. XYZ can, I=E2=80=99m sure, also be improved.

=
The goal here isn=E2=80=99t to take two projects and make them look the sam=
e. The goal here is to make one protocol, GNAP, with the best ideas and ele=
ments engineered into it that we, as a working group, can.=C2=A0It=E2=80=99=
s not about one input proposal winning over another, it=E2=80=99s about imp=
roving our understanding of all the use cases and possible solutions and co=
ming up with the best specification possible. Making things better should a=
lways be the goal. Progress should always be the goal.=C2=A0

=

But we aren=E2=80=99t here to build XYZ or XAuth. We=E2=80=99re here t=
o build GNAP and decide what GNAP looks like. XYZ=E2=80=99s structure and d=
esign is the best I=E2=80=99ve been able to make it so far, and it should b=
e our goal as a WG to move past either XYZ or XAuth and build GNAP even bet=
ter than any of that.

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


On Jul 17, 2020, at 6:46 PM, Dick H=
ardt <dick.har=
dt@gmail.com> wrote:

XYZ is looking a=
 lot more like XAuth, similar to how XAuth has shifted towards XYZ.=C2=A0
I have implemented separate URIs for grants and authoriza=
tions, and it worked really well.

All 3 of the new=
 capabilities are problematic. Perhaps you did not notice that there no lon=
ger is a short_uri in XAuth? As I recall, you were opposed to the short URI=
 that was in the earlier drafts of XAuth. In my XAuth implementation, I sho=
w QR codes in the CLI app. Have you checked out my implementation? Have you=
 implemented a QR code? I found that the string did not need to be nearly a=
s short as it has in the past.=C2=A0

I still don&#=
39;t understand the requirement to rotate the reference handle. I read over=
 the pointer you provided last time we discussed it, and responded, but I h=
ave not heard back from you on that.


3D""=E1=90=A7

On Fri, Jul 17, 2020 at 2:36 PM Justin Ri=
cher <jricher@mit.e=
du> wrote:
On Jul 17, 2020, at 1:10 PM, Dick Hardt <dick.hardt@gmail.com> =
wrote:

Hey Justin,

Gl=
ad to see that you are aligning=C2=A0on having URIs for the access tokens a=
nd the "grant".

While the token URI is u=
nique=C2=A0to the token, you have not done the same for a "grant"=
, but have a handle and a non-unique URI.

Why not =
have a unique grant URI similar to the token URI? (a combination of the han=
dle and a non-unique URI) -- this is then both the identifier, and the URL =
for "management"?

Glad to see you have e=
xcised the DID references. I don't think the common use cases are well =
established there currently.

I have LOTS of feedba=
ck=C2=A0on your interaction changes, that I'll post later on, and hope =
that others have feedback on those as well.

/Dick<=
/div>





=

On Thu, Ju=
l 16, 2020 at 2:52 PM Justin Richer <jricher@mit.edu> wrote:
Hi all,

I=E2=80=99=
ve updated the XYZ draft specification. Since the publication tools are cur=
rently locked prior to the upcoming virtual meeting, I have published it on=
line here:


This represents a pretty sig=
nificant refactoring of the specification, hopefully to make the concepts a=
nd capabilities easier to understand. The core protocol is largely the same=
 as before, but there are a number of serious updates:

=

=C2=A0- Continuation requests happen at a URL returned in the TX respo=
nse. The =E2=80=9Chandle=E2=80=9D is still sent as one of the input values =
here, since the handle can also be used it other contexts.
=C2=A0=
- Tokens now can include the resources they are issued for
=C2=A0=
- Tokens can have an optional management URI for rotation and revocation.
=C2=A0- =E2=80=9Cclaims=E2=80=9D has been removed in favor of =E2=
=80=9Csubject=E2=80=9D dealing directly with identifiers and assertions
=C2=A0- the =E2=80=9Cuser=E2=80=9D request and response now align wi=
th identifiers and assertions
=C2=A0- Extensions and registries a=
re more clearly enumerated throughout the document
=C2=A0- DID-re=
lated items have been excised in deference to a future possible extension
=C2=A0- Added a =E2=80=9Cpushback=E2=80=9D mechanism to complement=
 the =E2=80=9Ccallback=E2=80=9D mechanism
=C2=A0- Simplified dyna=
mic handle returns and access tokens based on developer feedback (basically=
 we dropped a bunch of =E2=80=9Cwhat if=E2=80=9D stuff that nobody used or =
liked, like SHA3 hashes for bearer tokens)

I=E2=80=
=99ve also updated the interactive examples on=C2=A0https://oauth.xyz/=C2=A0to match this new dra=
ft. Hopefully it=E2=80=99s consistent with the draft text.

I have not yet, however, updated any of the implementations of XYZ=
 to take the elements of new syntax into account, so there might be some mo=
re changes prior to the IETF meeting as I realize what terrible mistakes I=
=E2=80=99ve made when doing that. :)=C2=A0

Feedbac=
k, as always, is welcomed, and thanks to everyone who=E2=80=99s provided in=
put to the project to date.=C2=A0

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

Txauth mailing list

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









--0000000000001216fa05aac0e6b7--


From nobody Sat Jul 18 19:34: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 45E4F3A07C3 for ; Sat, 18 Jul 2020 19:34:46 -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_FILL_THIS_FORM_SHORT=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 T8e49bJHoaD2 for ; Sat, 18 Jul 2020 19:34:43 -0700 (PDT)
Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 1D9E53A07C2 for ; Sat, 18 Jul 2020 19:34:43 -0700 (PDT)
Received: by mail-ot1-x342.google.com with SMTP id w17so9694202otl.4 for ; Sat, 18 Jul 2020 19:34: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=xe1vBnunaWeu3mThWzISgi5HUbVbRT3cC1NrANLhgh0=; b=ZZRE9WzfPVD+ma9hG5oMCgG2xZf2545hODCgPL81Fhy2D4D4W3T/bwTpC0cu/H9Upx dLanrWxGKUh0cppEuPqcKna2TrSBv9/suqkmXIXTaj9a30oqVPRU45n4ChHWgA/RW/4h InmMNt6ly0az40+TfMPIGOOdrZueQ0WGlOEKJmt/zpjCvslrj+/+t2u1mkMRPeWZy7PP HmHj/kiM1hSIYvN8LjudJDx0Bca2DazFhJpUpPawzpEqGy59ytzm+JCuC05GT0wqJcle QrrGWRwwAcmHAVuOpGGqqNrfyQHyu4kGIkQ4PUlAwtgguptTm/5IbtYH6ys/wUEn2S07 Ejgw==
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=xe1vBnunaWeu3mThWzISgi5HUbVbRT3cC1NrANLhgh0=; b=ZADTxl7UHNrgsv9/7OMnZ1J+mbJV30DKMgSY7y/jiRcpDYhoRxIXkMIXjz7OTZwccq ILle00ySx6wXowbyJ78dvwzG1abFWPe5+MurYICT2coYrmk6Z+CAOWsPWfSFNeyTeFZa YVR67wUCCKphY9Z6IB7RwmGusHd/jd8jDrGVvuApmxZiHD3eF7xtPErv1l8crr2sbKeV CDQXaCnFxnZFGeTkhJQ1nJM5rAwiXKdm3Z3RaJUO/RGhXZf6RGk4NtLEprYnbdmCWY83 3ADOHneXCkRzP7XgB22FjlnBXHtVAZDwSMaZWWFxda8I2moQugGA5bNX9Q33y8nA0qvt Q0lw==
X-Gm-Message-State: AOAM531BCxShue+fjXH5jd1j6XtiRf+z7dz4pHlnLuS0mEcHRpC41+uX g6QOme8kzc1sFy4g9pc2dsoElj/ZZvZgxLPU2gU=
X-Google-Smtp-Source: ABdhPJw5gjhjPfwL/KWB979gEVqiOhiyZznQrWyzwJF/cmAc8J1OroyAJUnq4O+HdtL4vfdQK6qGBOJxRdrfR/I5ZIM=
X-Received: by 2002:a05:6830:3151:: with SMTP id c17mr15364744ots.143.1595126082260;  Sat, 18 Jul 2020 19:34:42 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu>  <174F2061-3F0F-49B2-A18F-58DF658E4473@mit.edu>     
In-Reply-To: 
From: Tom Jones 
Date: Sat, 18 Jul 2020 19:34:30 -0700
Message-ID: 
To: Dick Hardt 
Cc: Justin Richer , txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008151ec05aac23b14"
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 19 Jul 2020 02:34:46 -0000

--0000000000008151ec05aac23b14
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

absolutely, yes, tha az token can authorize any resource held by the
resource server.
The ONLY thing special about PII is the protection granted by the various
privacy laws.

As an aside, I don't find much in the current discussion that gives me a
warm feeling about privacy.
The stuff in the torsten tokens is about as anti-privacy an effort as
exists today.
Identity assurance does NOT need to be enabled by sending more and yet
again more PII.
Peace ..tom


On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt  wrote:

> Hey Tom
>
> While I think defining claims is out of scope of the WG, I think enabling
> a client to obtain claims about a user is in scope.
> Would you consider authorization for the release of claims to be part of
> the purpose of this WG?
>
> I'm concerned about the XYZ shift to subject identifiers from claims, and
> pushing claims to a higher layer, as it may indicate to developers that
> they can ONLY ask for a user identifier.
>
> When I think of a claim, I include any and all identifiers, but I also
> include user attributes such as under-13, over-21,
> student-at-an-accredited-school, resident of city/state/province/country.
>
> GNAP can enable a client to ask for only the claims it needs, preserving
> user privacy, and compliance with many privacy regulations.
>
> Would you agree?
>
> /Dick
>
>
>
>
> On Sat, Jul 18, 2020 at 9:56 AM Tom Jones 
> wrote:
>
>> I agree with Justin's comment " what we should do, as we define GNAP as =
a
>> protocol, is focus on this one, limited slice of the identity space and =
not
>> spiral into others."
>> The title "Authorization" should rule the purposes of this group above
>> all else.
>>
>> The earlier statement that the client should know who the user is - is
>> just plain WRONG. The client should only know the information the user i=
s
>> willing to share with the client.
>> It is now the law in California that the client cannot demand identity
>> information that is not required for a legitimate business purpose.
>> There are some clients that act as fiduciaries for the user
>> (financial and healthcare come to mind), but as a general rule the "clie=
nt"
>> is not to be trusted by the user.
>> I understand most of the people on this list are paid by the client's of
>> the world, but you are still bound by the laws that apply to those clien=
ts.
>>
>> Peace ..tom
>>
>>
>> On Mon, Jul 13, 2020 at 12:31 PM Justin Richer  wrote:
>>
>>> A quick note, as my choice of language below seems to have been
>>> confusing. First there is a typo, where the word =E2=80=9Cit=E2=80=9D s=
hould have been =E2=80=9Cin=E2=80=9D
>>> to read:
>>>
>>> I am saying that GNAP, *in* its definition within this working group,
>>> should be limited to identifier claims.
>>>
>>>
>>> And second, there seems to be confusion around whether I=E2=80=99m tryi=
ng to
>>> argue about the scope =E2=80=9Callowed=E2=80=9D by the charter by sayin=
g =E2=80=9Cits definition
>>> within this working group=E2=80=9D here.
>>>
>>> To be clear, we as the working group are *defining* GNAP the protocol.
>>> It has not yet been defined, and that=E2=80=99s why were all here. The =
charter
>>> doesn=E2=80=99t define it. The input specs don=E2=80=99t define it. The=
 working group
>>> defines it, and my stance as a contributor to this WG is that we should
>>> focus on a delegation protocol with some basic identifier query support=
 and
>>> leave the full fledged identity protocol to different work.
>>>
>>> We=E2=80=99ve already got our hands full here without taking all of tha=
t on,
>>> especially since I do believe we need to build GNAP in such a way as to
>>> facilitate its extension in several known directions, including a full
>>> identity protocol. If we do things right here, we can see GNAP as the b=
asis
>>> of a large number of things out there in the world.
>>>
>>> So my stance in what we should do, as we define GNAP as a protocol, is
>>> focus on this one, limited slice of the identity space and not spiral i=
nto
>>> others.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 13, 2020, at 2:51 PM, Justin Richer  wrote:
>>>
>>> I am saying that GNAP, it its definition within this working group,
>>> should be limited to identifier claims. Other claims can come from othe=
r
>>> protocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop =
them from
>>> being built, but in my opinion we shouldn=E2=80=99t be defining those h=
ere. See the
>>> discussion below on the extensibility avenues of this approach.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 13, 2020, at 2:12 PM, Dick Hardt  wrote:
>>>
>>> I agree that an API to return claims is useful. I think we have agreed
>>> on that.
>>>
>>> Using the SubjectIdentifiers schema is another schema that would be
>>> useful for GNAP to support.
>>>
>>> I disagree that GNAP should be limited to identifier claims.
>>>
>>> =E1=90=A7
>>>
>>> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer  wrote:
>>>
>>>> One thing I think we should learn from OIDC is that returning claims
>>>> from an API, and not just an assertion or direct response, is a powerf=
ul
>>>> and useful pattern. We have an opportunity to separate these cleanly, =
where
>>>> OIDC didn=E2=80=99t have the opportunity in defining the =E2=80=9Cclai=
ms=E2=80=9D request parameter.
>>>>
>>>> As an alternative to the current XYZ and XAuth syntaxes, over the
>>>> weekend I=E2=80=99ve been playing with something that would look like =
this strawman
>>>> in the request:
>>>>
>>>>
>>>> {
>>>>    subject: {
>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=
=9Ciss-sub=E2=80=9D],
>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifiabl=
e_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>>    }
>>>> }
>>>>
>>>>
>>>> This request says that I=E2=80=99d like some subset of these identifie=
rs (as
>>>> plain text in the response) and some subset of signed assertions in th=
e
>>>> given formats. Each one would have an associated space in the return. =
I=E2=80=99m
>>>> not picturing that the =E2=80=9Cid=E2=80=9D field values would affect =
the contents of the
>>>> assertions: so I could ask for an email address identifier but get bac=
k an
>>>> ID token that had only the subject identifier. Maybe that=E2=80=99s no=
t the right
>>>> model? But it=E2=80=99s at least simple and deterministic this way, an=
d it=E2=80=99s
>>>> something to play with.
>>>>
>>>> Note: The =E2=80=9Cid=E2=80=9D names are taken from
>>>> https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.h=
tml,
>>>> the =E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=99t =
see a source that collected
>>>> them. If you wanted specific bundles of claims about the user from a
>>>> UserInfoEndpoint, for example, you=E2=80=99d have something like:
>>>>
>>>> {
>>>>    subject: {
>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=
=9Ciss-sub=E2=80=9D],
>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifiabl=
e_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>>    },
>>>>    resources: [{
>>>>        type: =E2=80=9Cuserinfo=E2=80=9D,
>>>>        datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=
=9D, =E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
>>>>   }]
>>>> }
>>>>
>>>>
>>>> This is an example for a specific kind of resource, and I don=E2=80=99=
t think
>>>> that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, or=
 the datatype values
>>>> therein. That should be work outside of GNAP, probably for the OIDF.
>>>>
>>>> This approach is extensible in several ways, each of them for a
>>>> specific reason that I think is clear:
>>>>
>>>>  - new values in the =E2=80=9Cid=E2=80=9D field to give new identifier=
s
>>>>  - new values in the =E2=80=9Cassertion=E2=80=9D field to give new ass=
ertion formats
>>>>  - new fields under the =E2=80=9Csubject=E2=80=9D heading
>>>>  - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=
=9Cscim-v1=E2=80=9D or
>>>> =E2=80=9Cfacebook-profile=E2=80=9D for instance)
>>>>  - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource type
>>>>  - new top-level request parameters
>>>>
>>>> As per the other thread, if you wanted to use the OIDC query language,
>>>> you=E2=80=99d package it separately as a top-level request parameter s=
ince it can
>>>> include both the ID token response and the access token response and w=
e
>>>> shouldn=E2=80=99t be encouraging mixing these things together.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Jul 10, 2020, at 5:00 PM, Dick Hardt  wrote:
>>>>
>>>> It looks to me that our different views of what is in scope for GNAP
>>>> are the differences below.
>>>>
>>>> Per the subject line, I'm looking at how the client acquires claims
>>>> about the user. You don't think that is in scope, and that a different
>>>> layer will solve that.
>>>>
>>>> I think we should learn from OIDC being on top of OAuth, and GNAP
>>>> should be able return ANY claim, not just identifier claims. There are=
 use
>>>> cases that may be difficult to support if we do not have that function=
ality
>>>> in scope, such as some of the ones I list below, and it seems pretty
>>>> straightforward to support ANY claim if we are supporting identifiers.
>>>>
>>>> /Dick
>>>>
>>>>
>>>> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Jul 10, 2020, at 2:15 PM, Dick Hardt  wrote:
>>>>>
>>>>>
>>>>> inline ...
>>>>>
>>>>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer  wrote:
>>>>>
>>>>>> Yes, the core idea is to not have to parse an assertion to get back
>>>>>> the core authentication information, which consists of an identifier
>>>>>> (iss/sub pair in OIDC, but could be a number of things). Sometimes t=
he
>>>>>> client is going to want the rest of the identity information, but If=
 the
>>>>>> user=E2=80=99s logged into the client before, the client has likely =
cached that
>>>>>> info and probably won=E2=80=99t need it, and sending it would be a v=
iolation of
>>>>>> privacy principles.. The client would want the info pretty much just=
 in
>>>>>> these cases:
>>>>>>
>>>>>>  1. The client has never seen the user before.
>>>>>>  2. The user=E2=80=99s information has been updated since the last t=
ime the
>>>>>> client saw it.
>>>>>>
>>>>>
>>>>> Agreed
>>>>>
>>>>>
>>>>>>
>>>>>> Now for case (1), how would the client know if it wants to request
>>>>>> the user=E2=80=99s profile info or not, since it doesn=E2=80=99t kno=
w who the user is?
>>>>>>
>>>>>
>>>>> But the client could know who the user is. The client may have used a
>>>>> different AS to authenticate the user.
>>>>>
>>>>>
>>>>> In these cases, the client is not going to be requesting identity
>>>>> information from the AS to log the user in, so it=E2=80=99s not relev=
ant to the use
>>>>> case. The client will have an opportunity to push that information to=
 the
>>>>> AS.
>>>>>
>>>>> The User may have self identified to the client. The client may have =
a
>>>>> cookie saying who the user was and the user said that was them. While=
 the
>>>>> latter cases are really a strong hint, they are likely right most of =
the
>>>>> time and can lead to a user experience basde on that hint
>>>>>
>>>>>
>>>>> In these cases, the AS might be able to guess if the client has info
>>>>> about the user already, but probably not. And the assumptions fall ap=
art if
>>>>> it=E2=80=99s in fact a different user that ends up logging in, which =
is of course
>>>>> possible (the hint you gave doesn=E2=80=99t match the identity of the=
 current user
>>>>> after the AS validates them). This possibility leads to clients alway=
s
>>>>> asking for everything every time and the server providing everything =
every
>>>>> time. That=E2=80=99s a pattern I think we should avoid in an ultimate=
 solution =E2=80=94
>>>>> but ultimately, I don=E2=80=99t think that this kind of protocol deci=
sion is inside
>>>>> of GNAP.
>>>>>
>>>>>
>>>>>
>>>>>> And the AS won=E2=80=99t know if client is going to want the profile=
 info,
>>>>>> since the AS won=E2=80=99t know if the client has the user=E2=80=99s=
 info or not. Sure, the
>>>>>> AS might have seen that client and that user combo previously, but i=
t
>>>>>> doesn=E2=80=99t know if the client needs an update.
>>>>>>
>>>>>
>>>>> The client can share with the AS the user it knows or thinks it is
>>>>> dealing with, which could let the AS respond if the information was n=
ew.
>>>>> This could be the case for an AS that is providing claims, but not
>>>>> authentication, and could happen silently. The user would only intera=
ct if
>>>>> the user information had changed, and the client wanted the updated
>>>>> information.
>>>>>
>>>>>
>>>>>
>>>>> See above.
>>>>>
>>>>>
>>>>>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s inf=
o has been
>>>>>> updated or not because it doesn=E2=80=99t know who the user is yet. =
If the AS can
>>>>>> provide some time of updated stamp to the client, the client can pul=
l the
>>>>>> new info when it needs it.
>>>>>>
>>>>>
>>>>> See above.
>>>>>
>>>>>
>>>>> See above.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> If you ignore both of these cases and put all the user information
>>>>>> inline with the main request/response, you end up in a situation whe=
re the
>>>>>> client always requests everything and the server always provides
>>>>>> everything, since you can=E2=80=99t be sure you=E2=80=99re not in si=
tuation (1) or (2)
>>>>>> ahead of time.
>>>>>>
>>>>>
>>>>> See above. There are a number of other states the client could be in.
>>>>>
>>>>> For example, the client could be stateless about user information, so
>>>>> it knows it is ALWAYS in state 1.
>>>>>
>>>>>
>>>>> A stateless client would need to fetch appropriate user information
>>>>> every time, then. But that=E2=80=99s an optimization for a very speci=
fic case.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> This is really what I mean about the two-stage identity protocol.
>>>>>>
>>>>>
>>>>> I know what it is. Per above, GNAP lets us support a wider set of use
>>>>> cases. Why limit ourselves to what OIDC supported?
>>>>>
>>>>>
>>>>> We aren=E2=80=99t limiting the protocol, but instead limiting the sco=
pe of
>>>>> what we define internal to the GNAP protocol. There=E2=80=99s a lot o=
f room for
>>>>> innovation on top of it.
>>>>>
>>>>>
>>>>>
>>>>>> In the first stage, you push the bare minimum of what you need to ge=
t
>>>>>> the user known to the client. In the second stage, the client uses i=
ts
>>>>>> access token to call an API to get whatever else it needs to know ab=
out the
>>>>>> user.
>>>>>>
>>>>>
>>>>> From a privacy perspective in non-enterprise use cases, I think the
>>>>> user should give consent to any updated personal information to a cli=
ent.
>>>>> In general, the client should not be able to get the latest informati=
on
>>>>> about a user whenever it wants.
>>>>>
>>>>>
>>>>> This is about the rights associated with the access token, then. And
>>>>> an access token doesn=E2=80=99t have to keep working if the AS has a =
policy that
>>>>> says it won=E2=80=99t. The AS/RS could easily decide that a particula=
r access token
>>>>> will only return data that hasn=E2=80=99t been changed. Maybe it stop=
s working
>>>>> after the data changes, or it just returns old data, or any number of
>>>>> things. This is for the AS/RS to decide and this is pretty standard
>>>>> interpretation of the token, nothing special here because we=E2=80=99=
re dealing
>>>>> with identity.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>>
>>>>> /Dick
>>>>> =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
>>>
>>

--0000000000008151ec05aac23b14
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


absolutely, yes, tha az token can authorize=C2=A0any resou=
rce held by the resource server.
The ONLY thing special about PII is th=
e protection granted by the various privacy laws.

=
As an aside, I don't find much in the current discussion that gives me =
a warm feeling about privacy.
The stuff in the torsten tokens is =
about as anti-privacy an effort as exists today.
Identity assuran=
ce does NOT need to be enabled by sending more and yet again more PII.
Peace ..tom


On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Tom

While I think defining claims=C2=A0is out of=
 scope of the WG, I think enabling a client to obtain claims about a user i=
s in scope.
Would you consider authorization for the release=
 of claims to be part of the purpose of this WG?

I'm concerned about the XYZ shift to subject identifier=
s from claims, and pushing claims to a higher layer, as it may indicate to =
developers that they can ONLY ask for a user identifier.=C2=A0
When I think of a claim, I include any and all identifiers, bu=
t I also include user attributes such as under-13, over-21, student-at-an-a=
ccredited-school, resident of city/state/province/country.

GNAP can enable a client to ask for only the claims it needs, pres=
erving user privacy, and compliance with many privacy regulations.

Would you agree?

/Dick
=




On Sat, Jul 18, 20=
20 at 9:56 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
I agree wit=
h Justin's comment "=C2=A0what we should do, as we define GNAP as =
a protocol, is focus on this one, limited slice of the identity space and n=
ot spiral into others."
The title "Authorization" should=
 rule the purposes of this group above all else.

The=
 earlier statement=C2=A0that the client should know who the user is - is ju=
st plain WRONG. The client should only know the information the user is wil=
ling to share with the client.
It is now the law in California th=
at the client cannot demand=C2=A0identity information that is not required =
for a legitimate business purpose.
There are some clients that ac=
t as fiduciaries for the user (financial=C2=A0and healthcare come to mind),=
 but as a general rule the "client" is not to be trusted by the u=
ser.
I understand most of the people=C2=A0on this list are paid b=
y the client's of the world, but you are still bound by the laws that a=
pply to those clients.

Peace ..tom


On M=
on, Jul 13, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
A quick note, as my choice of =
language below seems to have been confusing. First there is a typo, where t=
he word =E2=80=9Cit=E2=80=9D should have been =E2=80=9Cin=E2=80=9D to read:=


I am saying that GNAP, <=
b>in its definition within this working group, should be limited to ide=
ntifier claims.

And second, there see=
ms to be confusion around whether I=E2=80=99m trying to argue about the sco=
pe =E2=80=9Callowed=E2=80=9D by the charter by saying =E2=80=9Cits definiti=
on within this working group=E2=80=9D here.=C2=A0

=
To be clear, we as the working group are defining GNAP the protocol.=
 It has not yet been defined, and that=E2=80=99s why were all here. The cha=
rter doesn=E2=80=99t define it. The input specs don=E2=80=99t define it. Th=
e working group defines it, and my stance as a contributor to this WG is th=
at we should focus on a delegation protocol with some basic identifier quer=
y support and leave the full fledged identity protocol to different work.=
=C2=A0

We=E2=80=99ve already got our hands full he=
re without taking all of that on, especially since I do believe we need to =
build GNAP in such a way as to facilitate its extension in several known di=
rections, including a full identity protocol. If we do things right here, w=
e can see GNAP as the basis of a large number of things out there in the wo=
rld.=C2=A0

So my stance in what we should do, as w=
e define GNAP as a protocol, is focus on this one, limited slice of the ide=
ntity space and not spiral into others.

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

On Jul 13, 2020, a=
t 2:51 PM, Justin Richer <jricher@mit.edu> wrote:



I am saying that GNAP, it its definition within this working group, sh=
ould be limited to identifier claims. Other claims can come from other prot=
ocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop them fro=
m being built, but in my opinion we shouldn=E2=80=99t be defining those her=
e. See the discussion below on the extensibility avenues of this approach.<=
div>
=C2=A0=E2=80=94 Justin

On Jul 13, 2020, at 2:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I agree that an API to return claims is useful=
. I think we have agreed on that.=C2=A0

Using the Subjec=
tIdentifiers schema is another schema that would be useful for GNAP to supp=
ort.=C2=A0

I disagree=C2=A0that GNAP should be lim=
ited to identifier claims.=C2=A0

3D""=E1=90=A7

On Mon, Jul 13, 2020 at 7:16 AM Justin Richer <jricher@mit.edu> wrote=
:
One thing=
 I think we should learn from OIDC is that returning claims from an API, an=
d not just an assertion or direct response, is a powerful and useful patter=
n. We have an opportunity to separate these cleanly, where OIDC didn=E2=80=
=99t have the opportunity in defining the =E2=80=9Cclaims=E2=80=9D request =
parameter.

As an alternative to the current XYZ and XAut=
h syntaxes, over the weekend I=E2=80=99ve been playing with something that =
would look like this strawman in the request:


=

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Codic_id_token=
=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
=C2=A0 =C2=A0}
}

T=
his request says that I=E2=80=99d like some subset of these identifiers (as=
 plain text in the response) and some subset of signed assertions in the gi=
ven formats. Each one would have an associated space in the return. I=E2=80=
=99m not picturing that the =E2=80=9Cid=E2=80=9D field values would affect =
the contents of the assertions: so I could ask for an email address identif=
ier but get back an ID token that had only the subject identifier. Maybe th=
at=E2=80=99s not the right model? But it=E2=80=99s at least simple and dete=
rministic this way, and it=E2=80=99s something to play with.

=

Note: The =E2=80=9Cid=E2=80=9D names are taken from=C2=A0https://tools.ietf.org/id/draft-ietf-secevent-subject=
-identifiers-05.html, the =E2=80=9Cassertion=E2=80=9D names are made up=
 as I didn=E2=80=99t see a source that collected them. If you wanted specif=
ic bundles of claims about the user from a UserInfoEndpoint, for example, y=
ou=E2=80=99d have something like:

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Cod=
ic_id_token=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csam=
l" ]
=C2=A0 =C2=A0},
=C2=A0 =
=C2=A0resources: [{
=C2=A0 =C2=A0 =C2=A0 =C2=A0type: =
=E2=80=9Cuserinfo=E2=80=9D,
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =E2=80=
=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
=C2=A0 }]=

}

This is=
 an example for a specific kind of resource, and I don=E2=80=99t think that=
 GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, or the data=
type values therein. That should be work outside of GNAP, probably for the =
OIDF.

This approach is extensible in several ways,=
 each of them for a specific reason that I think is clear:

=C2=A0- new values in the =E2=80=9Cid=E2=80=9D field to give new i=
dentifiers
=C2=A0- new values in the =E2=80=9Cassertion=E2=80=9D =
field to give new assertion formats
=C2=A0- new fields under the =
=E2=80=9Csubject=E2=80=9D heading=C2=A0
=C2=A0- new resource type=
s besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or =E2=
=80=9Cfacebook-profile=E2=80=9D for instance)
=C2=A0- new datatyp=
es within the =E2=80=9Cuserinfo=E2=80=9D resource type
=C2=A0- ne=
w top-level request parameters

As per the other th=
read, if you wanted to use the OIDC query language, you=E2=80=99d package i=
t separately as a top-level request parameter since it can include both the=
 ID token response and the access token response and we shouldn=E2=80=99t b=
e encouraging mixing these things together.

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

On Jul 10, 2020=
, at 5:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It looks to me that our different views of what is in scope for GNAP ar=
e the differences below.

Per the subject line, I'm l=
ooking at how the client acquires claims about the user. You don't thin=
k that is in scope, and that a different layer will solve that.
<=
br>
I think we should learn from OIDC being on top of OAuth, and =
GNAP should be able return ANY claim, not just identifier claims. There are=
 use cases that may be difficult to support if we do not have that function=
ality in scope, such as some of the ones I list below, and it seems pretty =
straightforward to support ANY claim if we are supporting identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09=
 PM Justin Richer <=
jricher@mit.edu> wrote:


On Jul 10, =
2020, at 2:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


inline ...=C2=A0

On Thu, Jul 9, 2020 at 5=
:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea is to not have to parse an assert=
ion to get back the core authentication information, which consists of an i=
dentifier (iss/sub pair in OIDC, but could be a number of things). Sometime=
s the client is going to want the rest of the identity information, but=C2=
=A0If the user=E2=80=99s logged into the client before, the client has like=
ly cached that info and probably won=E2=80=99t need it, and sending it woul=
d be a violation of privacy principles.. The client would want the info pre=
tty much just in these cases:

=C2=A01. The client has ne=
ver seen the user before.=C2=A0
=C2=A02. The user=E2=80=99s infor=
mation has been updated since the last time the client saw it.
<=
/blockquote>

Agreed
=C2=A0

Now for case (=
1), how would the client know if it wants to request the user=E2=80=99s pro=
file info or not, since it doesn=E2=80=99t know who the user is? 

But the client could know who the user i=
s. The client may have used a different AS to authenticate the user. 
=


In these cases, th=
e client is not going to be requesting identity information from the AS to =
log the user in, so it=E2=80=99s not relevant to the use case. The client w=
ill have an opportunity to push that information to the AS.

<=
div>The User may have self identified to the client. The client may have a =
cookie saying who the user was and the user said that was them. While the l=
atter cases are really a strong hint, they are likely right most of the tim=
e and can lead to a user experience basde on that hint

In these cases, the AS might be a=
ble to guess if the client has info about the user already, but probably no=
t. And the assumptions fall apart if it=E2=80=99s in fact a different user =
that ends up logging in, which is of course possible (the hint you gave doe=
sn=E2=80=99t match the identity of the current user after the AS validates =
them). This possibility leads to clients always asking for everything every=
 time and the server providing everything every time. That=E2=80=99s a patt=
ern I think we should avoid in an ultimate solution =E2=80=94 but ultimatel=
y, I don=E2=80=99t think that this kind of protocol decision is inside of G=
NAP.

=C2=A0
And the AS won=E2=80=99t know if client is going to wa=
nt the profile info, since the AS won=E2=80=99t know if the client has the =
user=E2=80=99s info or not. Sure, the AS might have seen that client and th=
at user combo previously, but it doesn=E2=80=99t know if the client needs a=
n update.

The client can share =
with the AS the user it knows or thinks it is dealing with, which could let=
 the AS respond if the information was new. This could be the case for an A=
S that is providing claims, but not authentication, and could happen silent=
ly. The user would only interact if the user information had changed, and t=
he client wanted the updated information.
=C2=A0

See above.


And =
for (2), the client won=E2=80=99t know if the user=E2=80=99s info has been =
updated or not because it doesn=E2=80=99t know who the user is yet. If the =
AS can provide some time of updated stamp to the client, the client can pul=
l the new info when it needs it.

See above.

See a=
bove.

=C2=A0

If you ignore both of these cases=
 and put all the user information inline with the main request/response, yo=
u end up in a situation where the client always requests everything and the=
 server always provides everything, since you can=E2=80=99t be sure you=E2=
=80=99re not in situation (1) or (2) ahead of time.

See above. There are a number of other states the clie=
nt could be in.

For example, the client could be s=
tateless about user information, so it knows it is ALWAYS in state 1.
=


A stateless client=
 would need to fetch appropriate user information every time, then. But tha=
t=E2=80=99s an optimization for a very specific case.

=
=C2=A0
This is really what I mean about the two-stage identity protoco=
l. 

I know what it is. Per abov=
e, GNAP lets us support a wider set of use cases. Why limit ourselves to wh=
at OIDC supported?

We aren=E2=80=99t limiting the protocol, but instead limiting the sco=
pe of what we define internal to the GNAP protocol. There=E2=80=99s a lot o=
f room for innovation on top of it.

=C2=A0
In the first stage, you=
 push the bare minimum of what you need to get the user known to the client=
. In the second stage, the client uses its access token to call an API to g=
et whatever else it needs to know about the user. 
=


From a privacy perspective in non-enterprise use cases,=
 I think the user should give consent to any updated personal information t=
o a client. In general, the=C2=A0client should not be able to get the lates=
t information about a user whenever it wants.
=


This is about the rights associated with t=
he access token, then. And an access token doesn=E2=80=99t have to keep wor=
king if the AS has a policy that says it won=E2=80=99t. The AS/RS could eas=
ily decide that a particular access token will only return data that hasn=
=E2=80=99t been changed. Maybe it stops working after the data changes, or =
it just returns old data, or any number of things. This is for the AS/RS to=
 decide and this is pretty standard interpretation of the token, nothing sp=
ecial here because we=E2=80=99re dealing with identity.

=C2=A0=E2=80=94 Justin

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








-- 
Txauth mailing list
Txauth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/txauth
<=
br>-- 

Txauth mailing list

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





--0000000000008151ec05aac23b14--


From nobody Sun Jul 19 13:45: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 B71CD3A091A for ; Sun, 19 Jul 2020 13:45: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_FILL_THIS_FORM_SHORT=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 N5TVC7PK0gFq for ; Sun, 19 Jul 2020 13:45:53 -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 1B0963A0918 for ; Sun, 19 Jul 2020 13:45:53 -0700 (PDT)
Received: by mail-lj1-x244.google.com with SMTP id f5so18059295ljj.10 for ; Sun, 19 Jul 2020 13:45: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=HdqJkrg1A8vfjq45sDVBpt2j7szBlkM8YUuoNrrpzVI=; b=DQ1e87S3BeRmIY+EoREhCuEc/XOILgBqDew659EfVsFMwCEezJ0nSa9VjCv3d1ud9t WyRBRKyXDi6PTBHLbVNQhVGbSUrcRl7W0hs0325zrMgjkFo2mwO1lU6d3rIHD0U1MR8F vpXMCzZTcILY0odC7+GK4j8T3gfIanC1BBZ99oqNKwprzGXYHbv9PUdx78tlA0nKDZU3 6ZJ/SIE3wBhxSvJ3dHuEH70wa2bUp7NA5SStxs0spaEjykZ2WmyZFFRo52YruXLVlJJ4 1RyRvq6HYVKoEvDqmOqCicaS/s828GWINsPMfEEh4vl+x7NQ/0JohAJm0NjNEIx0ICCK uZNQ==
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=HdqJkrg1A8vfjq45sDVBpt2j7szBlkM8YUuoNrrpzVI=; b=eLP2XZnjAjl0QKHSZFfsEJdOH2d6NApih30RmNnwldz3KVnIXH0cTwX2Fz8jYDav9N qqhWm+UpYO782AOpff73lWldReLcc7z8CiONu7L2puPCpZVA5nx5eVRUndip/Aj3zSI9 UVUV3bh3Ft2j65QXqAWK+DPdbSMKs0xzddZpfgqXzxKBXETt7sYXz6YXXjxyB9/u3JYk UmkENIzNSEk8PyE7lCCRH6XR5TCINx0XPgVVCialC0mFs5oKgwWXL/dsxQeWTb2XuYPb 0cctD/AEJSJFadHPDwC7aSpr0nV1MAXtTwj5ICM9HyYtfpafu/5o5wW4uhAh62qTSi4E V18A==
X-Gm-Message-State: AOAM530SO8nhVgXD8/XG5zLleiyKzX9GX9t8+kVD/NKl9x0/AjcW1P8r rcvWBXz10oaTF2jbDSEsxf0vsmPNFGS+20WzN1s=
X-Google-Smtp-Source: ABdhPJxSxYSBsSMAt6UmKOyf7l7UVDuzLzrUdCkGcl7n3g2iyZCq3UwOc51OZSY99WuWNzDceIQuVA6YLv44nAtmBI0=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr9324527ljn.5.1595191550865; Sun, 19 Jul 2020 13:45:50 -0700 (PDT)
MIME-Version: 1.0
References:    <8CC8B466-FD6F-4C23-8DAA-99B8A9BDF548@mit.edu>  <097FB93E-96DA-4DF6-8511-0B32FD321211@mit.edu>      <820525FD-4556-4617-8D89-C600D8C90C33@mit.edu>    <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu>  <174F2061-3F0F-49B2-A18F-58DF658E4473@mit.edu>      
In-Reply-To: 
From: Dick Hardt 
Date: Sun, 19 Jul 2020 13:45:14 -0700
Message-ID: 
To: Tom Jones 
Cc: Justin Richer , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bcf5a805aad179ae"
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 19 Jul 2020 20:45:57 -0000

--000000000000bcf5a805aad179ae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tom

The proposal is that Client asks for a claim from the AS, the user consents
at the AS, and the AS directly releases the claim directly to the Client.
No access token. No resource server.

Simpler for Client and Grant Server (AS)






On Sat, Jul 18, 2020 at 7:34 PM Tom Jones 
wrote:

> absolutely, yes, tha az token can authorize any resource held by the
> resource server.
> The ONLY thing special about PII is the protection granted by the various
> privacy laws.
>
> As an aside, I don't find much in the current discussion that gives me a
> warm feeling about privacy.
> The stuff in the torsten tokens is about as anti-privacy an effort as
> exists today.
> Identity assurance does NOT need to be enabled by sending more and yet
> again more PII.
> Peace ..tom
>
>
> On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt  wrote:
>
>> Hey Tom
>>
>> While I think defining claims is out of scope of the WG, I think enablin=
g
>> a client to obtain claims about a user is in scope.
>> Would you consider authorization for the release of claims to be part of
>> the purpose of this WG?
>>
>> I'm concerned about the XYZ shift to subject identifiers from claims, an=
d
>> pushing claims to a higher layer, as it may indicate to developers that
>> they can ONLY ask for a user identifier.
>>
>> When I think of a claim, I include any and all identifiers, but I also
>> include user attributes such as under-13, over-21,
>> student-at-an-accredited-school, resident of city/state/province/country=
.
>>
>> GNAP can enable a client to ask for only the claims it needs, preserving
>> user privacy, and compliance with many privacy regulations.
>>
>> Would you agree?
>>
>> /Dick
>>
>>
>>
>>
>> On Sat, Jul 18, 2020 at 9:56 AM Tom Jones 
>> wrote:
>>
>>> I agree with Justin's comment " what we should do, as we define GNAP as
>>> a protocol, is focus on this one, limited slice of the identity space a=
nd
>>> not spiral into others."
>>> The title "Authorization" should rule the purposes of this group above
>>> all else.
>>>
>>> The earlier statement that the client should know who the user is - is
>>> just plain WRONG. The client should only know the information the user =
is
>>> willing to share with the client.
>>> It is now the law in California that the client cannot demand identity
>>> information that is not required for a legitimate business purpose.
>>> There are some clients that act as fiduciaries for the user
>>> (financial and healthcare come to mind), but as a general rule the "cli=
ent"
>>> is not to be trusted by the user.
>>> I understand most of the people on this list are paid by the client's o=
f
>>> the world, but you are still bound by the laws that apply to those clie=
nts.
>>>
>>> Peace ..tom
>>>
>>>
>>> On Mon, Jul 13, 2020 at 12:31 PM Justin Richer  wrote:
>>>
>>>> A quick note, as my choice of language below seems to have been
>>>> confusing. First there is a typo, where the word =E2=80=9Cit=E2=80=9D =
should have been =E2=80=9Cin=E2=80=9D
>>>> to read:
>>>>
>>>> I am saying that GNAP, *in* its definition within this working group,
>>>> should be limited to identifier claims.
>>>>
>>>>
>>>> And second, there seems to be confusion around whether I=E2=80=99m try=
ing to
>>>> argue about the scope =E2=80=9Callowed=E2=80=9D by the charter by sayi=
ng =E2=80=9Cits definition
>>>> within this working group=E2=80=9D here.
>>>>
>>>> To be clear, we as the working group are *defining* GNAP the protocol.
>>>> It has not yet been defined, and that=E2=80=99s why were all here. The=
 charter
>>>> doesn=E2=80=99t define it. The input specs don=E2=80=99t define it. Th=
e working group
>>>> defines it, and my stance as a contributor to this WG is that we shoul=
d
>>>> focus on a delegation protocol with some basic identifier query suppor=
t and
>>>> leave the full fledged identity protocol to different work.
>>>>
>>>> We=E2=80=99ve already got our hands full here without taking all of th=
at on,
>>>> especially since I do believe we need to build GNAP in such a way as t=
o
>>>> facilitate its extension in several known directions, including a full
>>>> identity protocol. If we do things right here, we can see GNAP as the =
basis
>>>> of a large number of things out there in the world.
>>>>
>>>> So my stance in what we should do, as we define GNAP as a protocol, is
>>>> focus on this one, limited slice of the identity space and not spiral =
into
>>>> others.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Jul 13, 2020, at 2:51 PM, Justin Richer  wrote:
>>>>
>>>> I am saying that GNAP, it its definition within this working group,
>>>> should be limited to identifier claims. Other claims can come from oth=
er
>>>> protocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop=
 them from
>>>> being built, but in my opinion we shouldn=E2=80=99t be defining those =
here. See the
>>>> discussion below on the extensibility avenues of this approach.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Jul 13, 2020, at 2:12 PM, Dick Hardt  wrote:
>>>>
>>>> I agree that an API to return claims is useful. I think we have agreed
>>>> on that.
>>>>
>>>> Using the SubjectIdentifiers schema is another schema that would be
>>>> useful for GNAP to support.
>>>>
>>>> I disagree that GNAP should be limited to identifier claims.
>>>>
>>>> =E1=90=A7
>>>>
>>>> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer  wrote:
>>>>
>>>>> One thing I think we should learn from OIDC is that returning claims
>>>>> from an API, and not just an assertion or direct response, is a power=
ful
>>>>> and useful pattern. We have an opportunity to separate these cleanly,=
 where
>>>>> OIDC didn=E2=80=99t have the opportunity in defining the =E2=80=9Ccla=
ims=E2=80=9D request parameter.
>>>>>
>>>>> As an alternative to the current XYZ and XAuth syntaxes, over the
>>>>> weekend I=E2=80=99ve been playing with something that would look like=
 this strawman
>>>>> in the request:
>>>>>
>>>>>
>>>>> {
>>>>>    subject: {
>>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=
=80=9Ciss-sub=E2=80=9D],
>>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifiab=
le_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>>>    }
>>>>> }
>>>>>
>>>>>
>>>>> This request says that I=E2=80=99d like some subset of these identifi=
ers (as
>>>>> plain text in the response) and some subset of signed assertions in t=
he
>>>>> given formats. Each one would have an associated space in the return.=
 I=E2=80=99m
>>>>> not picturing that the =E2=80=9Cid=E2=80=9D field values would affect=
 the contents of the
>>>>> assertions: so I could ask for an email address identifier but get ba=
ck an
>>>>> ID token that had only the subject identifier. Maybe that=E2=80=99s n=
ot the right
>>>>> model? But it=E2=80=99s at least simple and deterministic this way, a=
nd it=E2=80=99s
>>>>> something to play with.
>>>>>
>>>>> Note: The =E2=80=9Cid=E2=80=9D names are taken from
>>>>> https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.=
html,
>>>>> the =E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=99t=
 see a source that collected
>>>>> them. If you wanted specific bundles of claims about the user from a
>>>>> UserInfoEndpoint, for example, you=E2=80=99d have something like:
>>>>>
>>>>> {
>>>>>    subject: {
>>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=
=80=9Ciss-sub=E2=80=9D],
>>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifiab=
le_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>>>    },
>>>>>    resources: [{
>>>>>        type: =E2=80=9Cuserinfo=E2=80=9D,
>>>>>        datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=
=9D, =E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
>>>>>   }]
>>>>> }
>>>>>
>>>>>
>>>>> This is an example for a specific kind of resource, and I don=E2=80=
=99t think
>>>>> that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, o=
r the datatype values
>>>>> therein. That should be work outside of GNAP, probably for the OIDF.
>>>>>
>>>>> This approach is extensible in several ways, each of them for a
>>>>> specific reason that I think is clear:
>>>>>
>>>>>  - new values in the =E2=80=9Cid=E2=80=9D field to give new identifie=
rs
>>>>>  - new values in the =E2=80=9Cassertion=E2=80=9D field to give new as=
sertion formats
>>>>>  - new fields under the =E2=80=9Csubject=E2=80=9D heading
>>>>>  - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=
=9Cscim-v1=E2=80=9D or
>>>>> =E2=80=9Cfacebook-profile=E2=80=9D for instance)
>>>>>  - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource type
>>>>>  - new top-level request parameters
>>>>>
>>>>> As per the other thread, if you wanted to use the OIDC query language=
,
>>>>> you=E2=80=99d package it separately as a top-level request parameter =
since it can
>>>>> include both the ID token response and the access token response and =
we
>>>>> shouldn=E2=80=99t be encouraging mixing these things together.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> On Jul 10, 2020, at 5:00 PM, Dick Hardt  wrote:
>>>>>
>>>>> It looks to me that our different views of what is in scope for GNAP
>>>>> are the differences below.
>>>>>
>>>>> Per the subject line, I'm looking at how the client acquires claims
>>>>> about the user. You don't think that is in scope, and that a differen=
t
>>>>> layer will solve that.
>>>>>
>>>>> I think we should learn from OIDC being on top of OAuth, and GNAP
>>>>> should be able return ANY claim, not just identifier claims. There ar=
e use
>>>>> cases that may be difficult to support if we do not have that functio=
nality
>>>>> in scope, such as some of the ones I list below, and it seems pretty
>>>>> straightforward to support ANY claim if we are supporting identifiers=
.
>>>>>
>>>>> /Dick
>>>>>
>>>>>
>>>>> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer  wrote=
:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Jul 10, 2020, at 2:15 PM, Dick Hardt  wrote=
:
>>>>>>
>>>>>>
>>>>>> inline ...
>>>>>>
>>>>>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer  wrote=
:
>>>>>>
>>>>>>> Yes, the core idea is to not have to parse an assertion to get back
>>>>>>> the core authentication information, which consists of an identifie=
r
>>>>>>> (iss/sub pair in OIDC, but could be a number of things). Sometimes =
the
>>>>>>> client is going to want the rest of the identity information, but I=
f the
>>>>>>> user=E2=80=99s logged into the client before, the client has likely=
 cached that
>>>>>>> info and probably won=E2=80=99t need it, and sending it would be a =
violation of
>>>>>>> privacy principles.. The client would want the info pretty much jus=
t in
>>>>>>> these cases:
>>>>>>>
>>>>>>>  1. The client has never seen the user before.
>>>>>>>  2. The user=E2=80=99s information has been updated since the last =
time the
>>>>>>> client saw it.
>>>>>>>
>>>>>>
>>>>>> Agreed
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Now for case (1), how would the client know if it wants to request
>>>>>>> the user=E2=80=99s profile info or not, since it doesn=E2=80=99t kn=
ow who the user is?
>>>>>>>
>>>>>>
>>>>>> But the client could know who the user is. The client may have used =
a
>>>>>> different AS to authenticate the user.
>>>>>>
>>>>>>
>>>>>> In these cases, the client is not going to be requesting identity
>>>>>> information from the AS to log the user in, so it=E2=80=99s not rele=
vant to the use
>>>>>> case. The client will have an opportunity to push that information t=
o the
>>>>>> AS.
>>>>>>
>>>>>> The User may have self identified to the client. The client may have
>>>>>> a cookie saying who the user was and the user said that was them. Wh=
ile the
>>>>>> latter cases are really a strong hint, they are likely right most of=
 the
>>>>>> time and can lead to a user experience basde on that hint
>>>>>>
>>>>>>
>>>>>> In these cases, the AS might be able to guess if the client has info
>>>>>> about the user already, but probably not. And the assumptions fall a=
part if
>>>>>> it=E2=80=99s in fact a different user that ends up logging in, which=
 is of course
>>>>>> possible (the hint you gave doesn=E2=80=99t match the identity of th=
e current user
>>>>>> after the AS validates them). This possibility leads to clients alwa=
ys
>>>>>> asking for everything every time and the server providing everything=
 every
>>>>>> time. That=E2=80=99s a pattern I think we should avoid in an ultimat=
e solution =E2=80=94
>>>>>> but ultimately, I don=E2=80=99t think that this kind of protocol dec=
ision is inside
>>>>>> of GNAP.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> And the AS won=E2=80=99t know if client is going to want the profil=
e info,
>>>>>>> since the AS won=E2=80=99t know if the client has the user=E2=80=99=
s info or not. Sure, the
>>>>>>> AS might have seen that client and that user combo previously, but =
it
>>>>>>> doesn=E2=80=99t know if the client needs an update.
>>>>>>>
>>>>>>
>>>>>> The client can share with the AS the user it knows or thinks it is
>>>>>> dealing with, which could let the AS respond if the information was =
new.
>>>>>> This could be the case for an AS that is providing claims, but not
>>>>>> authentication, and could happen silently. The user would only inter=
act if
>>>>>> the user information had changed, and the client wanted the updated
>>>>>> information.
>>>>>>
>>>>>>
>>>>>>
>>>>>> See above.
>>>>>>
>>>>>>
>>>>>>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s in=
fo has been
>>>>>>> updated or not because it doesn=E2=80=99t know who the user is yet.=
 If the AS can
>>>>>>> provide some time of updated stamp to the client, the client can pu=
ll the
>>>>>>> new info when it needs it.
>>>>>>>
>>>>>>
>>>>>> See above.
>>>>>>
>>>>>>
>>>>>> See above.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> If you ignore both of these cases and put all the user information
>>>>>>> inline with the main request/response, you end up in a situation wh=
ere the
>>>>>>> client always requests everything and the server always provides
>>>>>>> everything, since you can=E2=80=99t be sure you=E2=80=99re not in s=
ituation (1) or (2)
>>>>>>> ahead of time.
>>>>>>>
>>>>>>
>>>>>> See above. There are a number of other states the client could be in=
.
>>>>>>
>>>>>> For example, the client could be stateless about user information, s=
o
>>>>>> it knows it is ALWAYS in state 1.
>>>>>>
>>>>>>
>>>>>> A stateless client would need to fetch appropriate user information
>>>>>> every time, then. But that=E2=80=99s an optimization for a very spec=
ific case.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> This is really what I mean about the two-stage identity protocol.
>>>>>>>
>>>>>>
>>>>>> I know what it is. Per above, GNAP lets us support a wider set of us=
e
>>>>>> cases. Why limit ourselves to what OIDC supported?
>>>>>>
>>>>>>
>>>>>> We aren=E2=80=99t limiting the protocol, but instead limiting the sc=
ope of
>>>>>> what we define internal to the GNAP protocol. There=E2=80=99s a lot =
of room for
>>>>>> innovation on top of it.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> In the first stage, you push the bare minimum of what you need to
>>>>>>> get the user known to the client. In the second stage, the client u=
ses its
>>>>>>> access token to call an API to get whatever else it needs to know a=
bout the
>>>>>>> user.
>>>>>>>
>>>>>>
>>>>>> From a privacy perspective in non-enterprise use cases, I think the
>>>>>> user should give consent to any updated personal information to a cl=
ient.
>>>>>> In general, the client should not be able to get the latest informat=
ion
>>>>>> about a user whenever it wants.
>>>>>>
>>>>>>
>>>>>> This is about the rights associated with the access token, then. And
>>>>>> an access token doesn=E2=80=99t have to keep working if the AS has a=
 policy that
>>>>>> says it won=E2=80=99t. The AS/RS could easily decide that a particul=
ar access token
>>>>>> will only return data that hasn=E2=80=99t been changed. Maybe it sto=
ps working
>>>>>> after the data changes, or it just returns old data, or any number o=
f
>>>>>> things. This is for the AS/RS to decide and this is pretty standard
>>>>>> interpretation of the token, nothing special here because we=E2=80=
=99re dealing
>>>>>> with identity.
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>>
>>>>>> /Dick
>>>>>> =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
>>>>
>>>

--000000000000bcf5a805aad179ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Tom

The proposal is that Client asks=
 for a claim from the AS, the user consents at the AS, and the AS directly =
releases the claim directly to the Client. No access token. No resource ser=
ver.=C2=A0

Simpler for Client and Grant Server (AS=
)





On Sat, Jul 18, 2020 at 7:34 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
abso=
lutely, yes, tha az token can authorize=C2=A0any resource held by the resou=
rce server.
The ONLY thing special about PII is the protection granted =
by the various privacy laws.

As an aside, I don=
9;t find much in the current discussion that gives me a warm feeling about =
privacy.
The stuff in the torsten tokens is about as anti-privacy=
 an effort as exists today.
Identity assurance does NOT need to b=
e enabled by sending more and yet again more PII.
Peace ..tom

=


On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt <dick.hardt@gmail.com> wrote:
=

Hey Tom

While I think defining claims=C2=
=A0is out of scope of the WG, I think enabling a client to obtain claims ab=
out a user is in scope.
Would you consider authorization for=
 the release of claims to be part of the purpose of this WG?

I'm concerned about the XYZ shift to subjec=
t identifiers from claims, and pushing claims to a higher layer, as it may =
indicate to developers that they can ONLY ask for a user identifier.=C2=A0<=
/div>

When I think of a claim, I include any and all ide=
ntifiers, but I also include user attributes such as under-13, over-21, stu=
dent-at-an-accredited-school, resident of city/state/province/country.

GNAP can enable a client to ask for only the claims it=
 needs, preserving user privacy, and compliance with many privacy regulatio=
ns.

Would you agree?

/Dic=
k



=

On Sat=
, Jul 18, 2020 at 9:56 AM Tom Jones <thomasclinganjones@gmail.com> wrote:<=
br>
I agree with Justin's comment "=C2=A0what we should do, as we def=
ine GNAP as a protocol, is focus on this one, limited slice of the identity=
 space and not spiral into others."
The title "Authorization&=
quot; should rule the purposes of this group above all else.

The earlier statement=C2=A0that the client should know who the use=
r is - is just plain WRONG. The client should only know the information the=
 user is willing to share with the client.
It is now the law in C=
alifornia that the client cannot demand=C2=A0identity information that is n=
ot required for a legitimate business purpose.
There are some cli=
ents that act as fiduciaries for the user (financial=C2=A0and healthcare co=
me to mind), but as a general rule the "client" is not to be trus=
ted by the user.
I understand most of the people=C2=A0on this lis=
t are paid by the client's of the world, but you are still bound by the=
 laws that apply to those clients.

Peace ..tom


On Mon, Jul 13, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
A quick note, as m=
y choice of language below seems to have been confusing. First there is a t=
ypo, where the word =E2=80=9Cit=E2=80=9D should have been =E2=80=9Cin=E2=80=
=9D to read:

I am saying =
that GNAP, in its definition within this working group, should be li=
mited to identifier claims.

And secon=
d, there seems to be confusion around whether I=E2=80=99m trying to argue a=
bout the scope =E2=80=9Callowed=E2=80=9D by the charter by saying =E2=80=9C=
its definition within this working group=E2=80=9D here.=C2=A0
To be clear, we as the working group are defining GNAP t=
he protocol. It has not yet been defined, and that=E2=80=99s why were all h=
ere. The charter doesn=E2=80=99t define it. The input specs don=E2=80=99t d=
efine it. The working group defines it, and my stance as a contributor to t=
his WG is that we should focus on a delegation protocol with some basic ide=
ntifier query support and leave the full fledged identity protocol to diffe=
rent work.=C2=A0

We=E2=80=99ve already got our han=
ds full here without taking all of that on, especially since I do believe w=
e need to build GNAP in such a way as to facilitate its extension in severa=
l known directions, including a full identity protocol. If we do things rig=
ht here, we can see GNAP as the basis of a large number of things out there=
 in the world.=C2=A0

So my stance in what we shoul=
d do, as we define GNAP as a protocol, is focus on this one, limited slice =
of the identity space and not spiral into others.

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

On Jul 13=
, 2020, at 2:51 PM, Justin Richer <jricher@mit.edu> wrote:



I am saying that GNAP, it its definition within this working group, sh=
ould be limited to identifier claims. Other claims can come from other prot=
ocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop them fro=
m being built, but in my opinion we shouldn=E2=80=99t be defining those her=
e. See the discussion below on the extensibility avenues of this approach.<=
div>
=C2=A0=E2=80=94 Justin

On Jul 13, 2020, at 2:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I agree that an API to return claims is useful=
. I think we have agreed on that.=C2=A0

Using the Subjec=
tIdentifiers schema is another schema that would be useful for GNAP to supp=
ort.=C2=A0

I disagree=C2=A0that GNAP should be lim=
ited to identifier claims.=C2=A0

3D""=E1=90=A7

On Mon, Jul 13, 2020 at 7:16 AM Justin Richer <jricher@mit.edu> wrote=
:
One thing=
 I think we should learn from OIDC is that returning claims from an API, an=
d not just an assertion or direct response, is a powerful and useful patter=
n. We have an opportunity to separate these cleanly, where OIDC didn=E2=80=
=99t have the opportunity in defining the =E2=80=9Cclaims=E2=80=9D request =
parameter.

As an alternative to the current XYZ and XAut=
h syntaxes, over the weekend I=E2=80=99ve been playing with something that =
would look like this strawman in the request:


=

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Codic_id_token=
=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
=C2=A0 =C2=A0}
}

T=
his request says that I=E2=80=99d like some subset of these identifiers (as=
 plain text in the response) and some subset of signed assertions in the gi=
ven formats. Each one would have an associated space in the return. I=E2=80=
=99m not picturing that the =E2=80=9Cid=E2=80=9D field values would affect =
the contents of the assertions: so I could ask for an email address identif=
ier but get back an ID token that had only the subject identifier. Maybe th=
at=E2=80=99s not the right model? But it=E2=80=99s at least simple and dete=
rministic this way, and it=E2=80=99s something to play with.

=

Note: The =E2=80=9Cid=E2=80=9D names are taken from=C2=A0https://tools.ietf.org/id/draft-ietf-secevent-subject=
-identifiers-05.html, the =E2=80=9Cassertion=E2=80=9D names are made up=
 as I didn=E2=80=99t see a source that collected them. If you wanted specif=
ic bundles of claims about the user from a UserInfoEndpoint, for example, y=
ou=E2=80=99d have something like:

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Cod=
ic_id_token=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csam=
l" ]
=C2=A0 =C2=A0},
=C2=A0 =
=C2=A0resources: [{
=C2=A0 =C2=A0 =C2=A0 =C2=A0type: =
=E2=80=9Cuserinfo=E2=80=9D,
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =E2=80=
=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
=C2=A0 }]=

}

This is=
 an example for a specific kind of resource, and I don=E2=80=99t think that=
 GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, or the data=
type values therein. That should be work outside of GNAP, probably for the =
OIDF.

This approach is extensible in several ways,=
 each of them for a specific reason that I think is clear:

=C2=A0- new values in the =E2=80=9Cid=E2=80=9D field to give new i=
dentifiers
=C2=A0- new values in the =E2=80=9Cassertion=E2=80=9D =
field to give new assertion formats
=C2=A0- new fields under the =
=E2=80=9Csubject=E2=80=9D heading=C2=A0
=C2=A0- new resource type=
s besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or =E2=
=80=9Cfacebook-profile=E2=80=9D for instance)
=C2=A0- new datatyp=
es within the =E2=80=9Cuserinfo=E2=80=9D resource type
=C2=A0- ne=
w top-level request parameters

As per the other th=
read, if you wanted to use the OIDC query language, you=E2=80=99d package i=
t separately as a top-level request parameter since it can include both the=
 ID token response and the access token response and we shouldn=E2=80=99t b=
e encouraging mixing these things together.

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

On Jul 10, 2020=
, at 5:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It looks to me that our different views of what is in scope for GNAP ar=
e the differences below.

Per the subject line, I'm l=
ooking at how the client acquires claims about the user. You don't thin=
k that is in scope, and that a different layer will solve that.
<=
br>
I think we should learn from OIDC being on top of OAuth, and =
GNAP should be able return ANY claim, not just identifier claims. There are=
 use cases that may be difficult to support if we do not have that function=
ality in scope, such as some of the ones I list below, and it seems pretty =
straightforward to support ANY claim if we are supporting identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09=
 PM Justin Richer <=
jricher@mit.edu> wrote:


On Jul 10, =
2020, at 2:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


inline ...=C2=A0

On Thu, Jul 9, 2020 at 5=
:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea is to not have to parse an assert=
ion to get back the core authentication information, which consists of an i=
dentifier (iss/sub pair in OIDC, but could be a number of things). Sometime=
s the client is going to want the rest of the identity information, but=C2=
=A0If the user=E2=80=99s logged into the client before, the client has like=
ly cached that info and probably won=E2=80=99t need it, and sending it woul=
d be a violation of privacy principles.. The client would want the info pre=
tty much just in these cases:

=C2=A01. The client has ne=
ver seen the user before.=C2=A0
=C2=A02. The user=E2=80=99s infor=
mation has been updated since the last time the client saw it.
<=
/blockquote>

Agreed
=C2=A0

Now for case (=
1), how would the client know if it wants to request the user=E2=80=99s pro=
file info or not, since it doesn=E2=80=99t know who the user is? 

But the client could know who the user i=
s. The client may have used a different AS to authenticate the user. 
=


In these cases, th=
e client is not going to be requesting identity information from the AS to =
log the user in, so it=E2=80=99s not relevant to the use case. The client w=
ill have an opportunity to push that information to the AS.

<=
div>The User may have self identified to the client. The client may have a =
cookie saying who the user was and the user said that was them. While the l=
atter cases are really a strong hint, they are likely right most of the tim=
e and can lead to a user experience basde on that hint

In these cases, the AS might be a=
ble to guess if the client has info about the user already, but probably no=
t. And the assumptions fall apart if it=E2=80=99s in fact a different user =
that ends up logging in, which is of course possible (the hint you gave doe=
sn=E2=80=99t match the identity of the current user after the AS validates =
them). This possibility leads to clients always asking for everything every=
 time and the server providing everything every time. That=E2=80=99s a patt=
ern I think we should avoid in an ultimate solution =E2=80=94 but ultimatel=
y, I don=E2=80=99t think that this kind of protocol decision is inside of G=
NAP.

=C2=A0
And the AS won=E2=80=99t know if client is going to wa=
nt the profile info, since the AS won=E2=80=99t know if the client has the =
user=E2=80=99s info or not. Sure, the AS might have seen that client and th=
at user combo previously, but it doesn=E2=80=99t know if the client needs a=
n update.

The client can share =
with the AS the user it knows or thinks it is dealing with, which could let=
 the AS respond if the information was new. This could be the case for an A=
S that is providing claims, but not authentication, and could happen silent=
ly. The user would only interact if the user information had changed, and t=
he client wanted the updated information.
=C2=A0

See above.


And =
for (2), the client won=E2=80=99t know if the user=E2=80=99s info has been =
updated or not because it doesn=E2=80=99t know who the user is yet. If the =
AS can provide some time of updated stamp to the client, the client can pul=
l the new info when it needs it.

See above.

See a=
bove.

=C2=A0

If you ignore both of these cases=
 and put all the user information inline with the main request/response, yo=
u end up in a situation where the client always requests everything and the=
 server always provides everything, since you can=E2=80=99t be sure you=E2=
=80=99re not in situation (1) or (2) ahead of time.

See above. There are a number of other states the clie=
nt could be in.

For example, the client could be s=
tateless about user information, so it knows it is ALWAYS in state 1.
=


A stateless client=
 would need to fetch appropriate user information every time, then. But tha=
t=E2=80=99s an optimization for a very specific case.

=
=C2=A0
This is really what I mean about the two-stage identity protoco=
l. 

I know what it is. Per abov=
e, GNAP lets us support a wider set of use cases. Why limit ourselves to wh=
at OIDC supported?

We aren=E2=80=99t limiting the protocol, but instead limiting the sco=
pe of what we define internal to the GNAP protocol. There=E2=80=99s a lot o=
f room for innovation on top of it.

=C2=A0
In the first stage, you=
 push the bare minimum of what you need to get the user known to the client=
. In the second stage, the client uses its access token to call an API to g=
et whatever else it needs to know about the user. 
=


From a privacy perspective in non-enterprise use cases,=
 I think the user should give consent to any updated personal information t=
o a client. In general, the=C2=A0client should not be able to get the lates=
t information about a user whenever it wants.
=


This is about the rights associated with t=
he access token, then. And an access token doesn=E2=80=99t have to keep wor=
king if the AS has a policy that says it won=E2=80=99t. The AS/RS could eas=
ily decide that a particular access token will only return data that hasn=
=E2=80=99t been changed. Maybe it stops working after the data changes, or =
it just returns old data, or any number of things. This is for the AS/RS to=
 decide and this is pretty standard interpretation of the token, nothing sp=
ecial here because we=E2=80=99re dealing with identity.

=C2=A0=E2=80=94 Justin

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








-- 
Txauth mailing list
Txauth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/txauth
<=
br>-- 

Txauth mailing list

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






--000000000000bcf5a805aad179ae--


From nobody Sun Jul 19 21: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 C894F3A09B4 for ; Sun, 19 Jul 2020 21:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level: 
X-Spam-Status: No, score=-2.085 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 TI-AzlAjwqtD for ; Sun, 19 Jul 2020 21:13:34 -0700 (PDT)
Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 DBD573A09AD for ; Sun, 19 Jul 2020 21:13:34 -0700 (PDT)
Received: by mail-pg1-x544.google.com with SMTP id g67so9687639pgc.8 for ; Sun, 19 Jul 2020 21:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=og4Hg2IcGsAsBASgNFTFoafc5KUqDn8T01G4SZC4V+Y=; b=EfZOoSYS5Ommm8+2QKJW6Cu+uol0WcXffuXfpWfub7oVElr+FzP95qtMWL9yte8cMJ q6ukn8IkHsrYWvIZ9Vhq/Bx9UZbQ3Gd7JiXMJXOF17q20Qh2y2Z5tU6SYAUWti/Zxttu /YCa+Ew+DhKi7O0QKlYArLeg1EVLLnV2OiNrFisst1SObJpvhKIMBhJ4fOcNjOHi8bpt u2w2yV2UWyDA97gNXfeCFEjx9EbZROESvfxH5D5048UlpIi1n//f3Ldm0Oas+bcCyt6Y O1cGEknPYwWO68w/DWgxB7qQF3aILOlE6WELEep7AWga0qaOfwBmb9vRSCmedSLAv0wC RJ5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=og4Hg2IcGsAsBASgNFTFoafc5KUqDn8T01G4SZC4V+Y=; b=fOxdj1PV3mGYppWt9662puzcagH4DoWx5pia1C//tHS2dzItitWhgcwKZvwOSHo/Fk yCu9j3+54PWlqKJXH4IGcxKHbFujwPt2udxM/zPChB37Q5VvGp5FpOiNYfSIfkI6XTAN 19x28v1yLRI/2/foPL4kepuMkqJfdJ+BBqeyAo6AqPNkfCuF5MMY9Rg/EPvdBTybXObt QAq6i+f3i/5TfNJwwnQrUkuaDV5334E/W9Oj0zNWCHPpNqUgyKXRa3ILaKIzvlOrk24f 2AS0wIGP02fwkEagzypAdzo+L2ZtyjnlGBjCFVq/VAJns0MWiyIdXbHF0vGXBdJCQhv5 qECg==
X-Gm-Message-State: AOAM5309pPDFT/oqpXeU75njYAmhl+An1qHrBfdguWtVodfvrJJ6RNcc 8ZHdzt1aiAibnMJaQqMqVbNqpz1Y
X-Google-Smtp-Source: ABdhPJwK/1f5pCrMCtrVgK1b28uyK6NNGzB20QiQcrEvDoA/5T4AOwxZBRoOQJgTS6jjhapfY4DR0Q==
X-Received: by 2002:a62:ce46:: with SMTP id y67mr16772888pfg.118.1595218414226;  Sun, 19 Jul 2020 21:13:34 -0700 (PDT)
Received: from [192.168.254.37] ([50.34.183.218]) by smtp.gmail.com with ESMTPSA id bf11sm10188931pjb.48.2020.07.19.21.13.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Jul 2020 21:13:33 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-84693874-CE05-42DB-8CA1-53B8E3EE0F50
Content-Transfer-Encoding: 7bit
From: Tom Jones 
Mime-Version: 1.0 (1.0)
Date: Sun, 19 Jul 2020 21:13:32 -0700
Message-Id: 
References: 
Cc: Justin Richer , txauth@ietf.org
In-Reply-To: 
To: Dick Hardt 
X-Mailer: iPhone Mail (17F80)
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 20 Jul 2020 04:13:38 -0000

--Apple-Mail-84693874-CE05-42DB-8CA1-53B8E3EE0F50
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Well, that might work for you. It won=E2=80=99t work for me. I put the as on=
 the user=E2=80=99s phone. The source and sink of the data can switch roles o=
n a millisecond basis. I will track your progress and adopt what I can.

..Tom's phone

> On Jul 19, 2020, at 1:45 PM, Dick Hardt  wrote:
>=20
> =EF=BB=BF
> Hi Tom
>=20
> The proposal is that Client asks for a claim from the AS, the user consent=
s at the AS, and the AS directly releases the claim directly to the Client. N=
o access token. No resource server.=20
>=20
> Simpler for Client and Grant Server (AS)
>=20
>=20
>=20
>=20
>=20
>=20
>> On Sat, Jul 18, 2020 at 7:34 PM Tom Jones  w=
rote:
>> absolutely, yes, tha az token can authorize any resource held by the reso=
urce server.
>> The ONLY thing special about PII is the protection granted by the various=
 privacy laws.
>>=20
>> As an aside, I don't find much in the current discussion that gives me a w=
arm feeling about privacy.
>> The stuff in the torsten tokens is about as anti-privacy an effort as exi=
sts today.
>> Identity assurance does NOT need to be enabled by sending more and yet ag=
ain more PII.
>> Peace ..tom
>>=20
>>=20
>>> On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt  wrote:=

>>> Hey Tom
>>>=20
>>> While I think defining claims is out of scope of the WG, I think enablin=
g a client to obtain claims about a user is in scope.
>>> Would you consider authorization for the release of claims to be part of=
 the purpose of this WG?
>>>=20
>>> I'm concerned about the XYZ shift to subject identifiers from claims, an=
d pushing claims to a higher layer, as it may indicate to developers that th=
ey can ONLY ask for a user identifier.=20
>>>=20
>>> When I think of a claim, I include any and all identifiers, but I also i=
nclude user attributes such as under-13, over-21, student-at-an-accredited-s=
chool, resident of city/state/province/country.
>>>=20
>>> GNAP can enable a client to ask for only the claims it needs, preserving=
 user privacy, and compliance with many privacy regulations.
>>>=20
>>> Would you agree?
>>>=20
>>> /Dick
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On Sat, Jul 18, 2020 at 9:56 AM Tom Jones  wrote:
>>>> I agree with Justin's comment " what we should do, as we define GNAP as=
 a protocol, is focus on this one, limited slice of the identity space and n=
ot spiral into others."
>>>> The title "Authorization" should rule the purposes of this group above a=
ll else.
>>>>=20
>>>> The earlier statement that the client should know who the user is - is j=
ust plain WRONG. The client should only know the information the user is wil=
ling to share with the client.
>>>> It is now the law in California that the client cannot demand identity i=
nformation that is not required for a legitimate business purpose.
>>>> There are some clients that act as fiduciaries for the user (financial a=
nd healthcare come to mind), but as a general rule the "client" is not to be=
 trusted by the user.
>>>> I understand most of the people on this list are paid by the client's o=
f the world, but you are still bound by the laws that apply to those clients=
.
>>>>=20
>>>> Peace ..tom
>>>>=20
>>>>=20
>>>>> On Mon, Jul 13, 2020 at 12:31 PM Justin Richer  wrote=
:
>>>>> A quick note, as my choice of language below seems to have been confus=
ing. First there is a typo, where the word =E2=80=9Cit=E2=80=9D should have b=
een =E2=80=9Cin=E2=80=9D to read:
>>>>>=20
>>>>>> I am saying that GNAP, in its definition within this working group, s=
hould be limited to identifier claims.
>>>>>=20
>>>>> And second, there seems to be confusion around whether I=E2=80=99m try=
ing to argue about the scope =E2=80=9Callowed=E2=80=9D by the charter by say=
ing =E2=80=9Cits definition within this working group=E2=80=9D here.=20
>>>>>=20
>>>>> To be clear, we as the working group are defining GNAP the protocol. I=
t has not yet been defined, and that=E2=80=99s why were all here. The charte=
r doesn=E2=80=99t define it. The input specs don=E2=80=99t define it. The wo=
rking group defines it, and my stance as a contributor to this WG is that we=
 should focus on a delegation protocol with some basic identifier query supp=
ort and leave the full fledged identity protocol to different work.=20
>>>>>=20
>>>>> We=E2=80=99ve already got our hands full here without taking all of th=
at on, especially since I do believe we need to build GNAP in such a way as t=
o facilitate its extension in several known directions, including a full ide=
ntity protocol. If we do things right here, we can see GNAP as the basis of a=
 large number of things out there in the world.=20
>>>>>=20
>>>>> So my stance in what we should do, as we define GNAP as a protocol, is=
 focus on this one, limited slice of the identity space and not spiral into o=
thers.
>>>>>=20
>>>>>  =E2=80=94 Justin
>>>>>=20
>>>>>> On Jul 13, 2020, at 2:51 PM, Justin Richer  wrote:
>>>>>>=20
>>>>>> I am saying that GNAP, it its definition within this working group, s=
hould be limited to identifier claims. Other claims can come from other prot=
ocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop them from=
 being built, but in my opinion we shouldn=E2=80=99t be defining those here.=
 See the discussion below on the extensibility avenues of this approach.
>>>>>>=20
>>>>>>  =E2=80=94 Justin
>>>>>>=20
>>>>>>> On Jul 13, 2020, at 2:12 PM, Dick Hardt  wrote=
:
>>>>>>>=20
>>>>>>> I agree that an API to return claims is useful. I think we have agre=
ed on that.=20
>>>>>>>=20
>>>>>>> Using the SubjectIdentifiers schema is another schema that would be u=
seful for GNAP to support.=20
>>>>>>>=20
>>>>>>> I disagree that GNAP should be limited to identifier claims.=20
>>>>>>>=20
>>>>>>> =E1=90=A7
>>>>>>>=20
>>>>>>>> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer  wro=
te:
>>>>>>>> One thing I think we should learn from OIDC is that returning claim=
s from an API, and not just an assertion or direct response, is a powerful a=
nd useful pattern. We have an opportunity to separate these cleanly, where O=
IDC didn=E2=80=99t have the opportunity in defining the =E2=80=9Cclaims=E2=80=
=9D request parameter.
>>>>>>>>=20
>>>>>>>> As an alternative to the current XYZ and XAuth syntaxes, over the w=
eekend I=E2=80=99ve been playing with something that would look like this st=
rawman in the request:
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> {
>>>>>>>>    subject: {
>>>>>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=
=80=9Ciss-sub=E2=80=9D],
>>>>>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifi=
able_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>>>>>>    }
>>>>>>>> }
>>>>>>>>=20
>>>>>>>> This request says that I=E2=80=99d like some subset of these identi=
fiers (as plain text in the response) and some subset of signed assertions i=
n the given formats. Each one would have an associated space in the return. I=
=E2=80=99m not picturing that the =E2=80=9Cid=E2=80=9D field values would af=
fect the contents of the assertions: so I could ask for an email address ide=
ntifier but get back an ID token that had only the subject identifier. Maybe=
 that=E2=80=99s not the right model? But it=E2=80=99s at least simple and de=
terministic this way, and it=E2=80=99s something to play with.
>>>>>>>>=20
>>>>>>>> Note: The =E2=80=9Cid=E2=80=9D names are taken from https://tools.i=
etf.org/id/draft-ietf-secevent-subject-identifiers-05.html, the =E2=80=9Cass=
ertion=E2=80=9D names are made up as I didn=E2=80=99t see a source that coll=
ected them. If you wanted specific bundles of claims about the user from a U=
serInfoEndpoint, for example, you=E2=80=99d have something like:
>>>>>>>>=20
>>>>>>>> {
>>>>>>>>    subject: {
>>>>>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=
=80=9Ciss-sub=E2=80=9D],
>>>>>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifi=
able_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>>>>>>    },
>>>>>>>>    resources: [{
>>>>>>>>        type: =E2=80=9Cuserinfo=E2=80=9D,
>>>>>>>>        datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=
=9D, =E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
>>>>>>>>   }]
>>>>>>>> }
>>>>>>>>=20
>>>>>>>> This is an example for a specific kind of resource, and I don=E2=80=
=99t think that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema her=
e, or the datatype values therein. That should be work outside of GNAP, prob=
ably for the OIDF.
>>>>>>>>=20
>>>>>>>> This approach is extensible in several ways, each of them for a spe=
cific reason that I think is clear:
>>>>>>>>=20
>>>>>>>>  - new values in the =E2=80=9Cid=E2=80=9D field to give new identif=
iers
>>>>>>>>  - new values in the =E2=80=9Cassertion=E2=80=9D field to give new a=
ssertion formats
>>>>>>>>  - new fields under the =E2=80=9Csubject=E2=80=9D heading=20
>>>>>>>>  - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=
=9Cscim-v1=E2=80=9D or =E2=80=9Cfacebook-profile=E2=80=9D for instance)
>>>>>>>>  - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource typ=
e
>>>>>>>>  - new top-level request parameters
>>>>>>>>=20
>>>>>>>> As per the other thread, if you wanted to use the OIDC query langua=
ge, you=E2=80=99d package it separately as a top-level request parameter sin=
ce it can include both the ID token response and the access token response a=
nd we shouldn=E2=80=99t be encouraging mixing these things together.
>>>>>>>>=20
>>>>>>>>  =E2=80=94 Justin
>>>>>>>>=20
>>>>>>>>> On Jul 10, 2020, at 5:00 PM, Dick Hardt  wro=
te:
>>>>>>>>>=20
>>>>>>>>> It looks to me that our different views of what is in scope for GN=
AP are the differences below.
>>>>>>>>>=20
>>>>>>>>> Per the subject line, I'm looking at how the client acquires claim=
s about the user. You don't think that is in scope, and that a different lay=
er will solve that.
>>>>>>>>>=20
>>>>>>>>> I think we should learn from OIDC being on top of OAuth, and GNAP s=
hould be able return ANY claim, not just identifier claims. There are use ca=
ses that may be difficult to support if we do not have that functionality in=
 scope, such as some of the ones I list below, and it seems pretty straightf=
orward to support ANY claim if we are supporting identifiers.
>>>>>>>>>=20
>>>>>>>>> /Dick
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer  w=
rote:
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>>> On Jul 10, 2020, at 2:15 PM, Dick Hardt  w=
rote:
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> inline ...=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer =
 wrote:
>>>>>>>>>>>>> Yes, the core idea is to not have to parse an assertion to get=
 back the core authentication information, which consists of an identifier (=
iss/sub pair in OIDC, but could be a number of things). Sometimes the client=
 is going to want the rest of the identity information, but If the user=E2=80=
=99s logged into the client before, the client has likely cached that info a=
nd probably won=E2=80=99t need it, and sending it would be a violation of pr=
ivacy principles.. The client would want the info pretty much just in these c=
ases:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>  1. The client has never seen the user before.=20
>>>>>>>>>>>>>  2. The user=E2=80=99s information has been updated since the l=
ast time the client saw it.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Agreed
>>>>>>>>>>>> =20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Now for case (1), how would the client know if it wants to req=
uest the user=E2=80=99s profile info or not, since it doesn=E2=80=99t know w=
ho the user is?
>>>>>>>>>>>>=20
>>>>>>>>>>>> But the client could know who the user is. The client may have u=
sed a different AS to authenticate the user.
>>>>>>>>>>>=20
>>>>>>>>>>> In these cases, the client is not going to be requesting identit=
y information from the AS to log the user in, so it=E2=80=99s not relevant t=
o the use case. The client will have an opportunity to push that information=
 to the AS.
>>>>>>>>>>>=20
>>>>>>>>>>> The User may have self identified to the client. The client may h=
ave a cookie saying who the user was and the user said that was them. While t=
he latter cases are really a strong hint, they are likely right most of the t=
ime and can lead to a user experience basde on that hint
>>>>>>>>>>=20
>>>>>>>>>> In these cases, the AS might be able to guess if the client has i=
nfo about the user already, but probably not. And the assumptions fall apart=
 if it=E2=80=99s in fact a different user that ends up logging in, which is o=
f course possible (the hint you gave doesn=E2=80=99t match the identity of t=
he current user after the AS validates them). This possibility leads to clie=
nts always asking for everything every time and the server providing everyth=
ing every time. That=E2=80=99s a pattern I think we should avoid in an ultim=
ate solution =E2=80=94 but ultimately, I don=E2=80=99t think that this kind o=
f protocol decision is inside of GNAP.
>>>>>>>>>>=20
>>>>>>>>>>> =20
>>>>>>>>>>>> And the AS won=E2=80=99t know if client is going to want the pr=
ofile info, since the AS won=E2=80=99t know if the client has the user=E2=80=
=99s info or not. Sure, the AS might have seen that client and that user com=
bo previously, but it doesn=E2=80=99t know if the client needs an update.
>>>>>>>>>>>=20
>>>>>>>>>>> The client can share with the AS the user it knows or thinks it i=
s dealing with, which could let the AS respond if the information was new. T=
his could be the case for an AS that is providing claims, but not authentica=
tion, and could happen silently. The user would only interact if the user in=
formation had changed, and the client wanted the updated information.
>>>>>>>>>>> =20
>>>>>>>>>>=20
>>>>>>>>>> See above.
>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> And for (2), the client won=E2=80=99t know if the user=E2=80=99=
s info has been updated or not because it doesn=E2=80=99t know who the user i=
s yet. If the AS can provide some time of updated stamp to the client, the c=
lient can pull the new info when it needs it.
>>>>>>>>>>>=20
>>>>>>>>>>> See above.
>>>>>>>>>>=20
>>>>>>>>>> See above.
>>>>>>>>>>=20
>>>>>>>>>>> =20
>>>>>>>>>>>>=20
>>>>>>>>>>>> If you ignore both of these cases and put all the user informat=
ion inline with the main request/response, you end up in a situation where t=
he client always requests everything and the server always provides everythi=
ng, since you can=E2=80=99t be sure you=E2=80=99re not in situation (1) or (=
2) ahead of time.
>>>>>>>>>>>=20
>>>>>>>>>>> See above. There are a number of other states the client could b=
e in.
>>>>>>>>>>>=20
>>>>>>>>>>> For example, the client could be stateless about user informatio=
n, so it knows it is ALWAYS in state 1.
>>>>>>>>>>=20
>>>>>>>>>> A stateless client would need to fetch appropriate user informati=
on every time, then. But that=E2=80=99s an optimization for a very specific c=
ase.
>>>>>>>>>>=20
>>>>>>>>>>> =20
>>>>>>>>>>>>=20
>>>>>>>>>>>> This is really what I mean about the two-stage identity protoco=
l.
>>>>>>>>>>>=20
>>>>>>>>>>> I know what it is. Per above, GNAP lets us support a wider set o=
f use cases. Why limit ourselves to what OIDC supported?
>>>>>>>>>>=20
>>>>>>>>>> We aren=E2=80=99t limiting the protocol, but instead limiting the=
 scope of what we define internal to the GNAP protocol. There=E2=80=99s a lo=
t of room for innovation on top of it.
>>>>>>>>>>=20
>>>>>>>>>>> =20
>>>>>>>>>>>> In the first stage, you push the bare minimum of what you need t=
o get the user known to the client. In the second stage, the client uses its=
 access token to call an API to get whatever else it needs to know about the=
 user.
>>>>>>>>>>>=20
>>>>>>>>>>> =46rom a privacy perspective in non-enterprise use cases, I thin=
k the user should give consent to any updated personal information to a clie=
nt. In general, the client should not be able to get the latest information a=
bout a user whenever it wants.
>>>>>>>>>>=20
>>>>>>>>>> This is about the rights associated with the access token, then. A=
nd an access token doesn=E2=80=99t have to keep working if the AS has a poli=
cy that says it won=E2=80=99t. The AS/RS could easily decide that a particul=
ar access token will only return data that hasn=E2=80=99t been changed. Mayb=
e it stops working after the data changes, or it just returns old data, or a=
ny number of things. This is for the AS/RS to decide and this is pretty stan=
dard interpretation of the token, nothing special here because we=E2=80=99re=
 dealing with identity.
>>>>>>>>>>=20
>>>>>>>>>>  =E2=80=94 Justin
>>>>>>>>>>=20
>>>>>>>>>>> =20
>>>>>>>>>>> /Dick
>>>>>>>>>>> =E1=90=A7
>>>>>>>>>>=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-84693874-CE05-42DB-8CA1-53B8E3EE0F50
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Well, that might work for you. It won=E2=80=
=99t work for me. I put the as on the user=E2=80=99s phone. The source and s=
ink of the data can switch roles on a millisecond basis. I will track your p=
rogress and adopt what I can.

..Tom's phone

On Jul 19, 2020, at 1:45 PM, Dic=
k Hardt <dick.hardt@gmail.com> wrote:

=EF=BB=BF
Hi Tom
The proposal is that Client asks for a claim from the AS, the u=
ser consents at the AS, and the AS directly releases the claim directly to t=
he Client. No access token. No resource server. 

Simpler for Client and Grant Server (AS)






On Sat, Jul 18, 2020 at 7:34 P=
M Tom Jones <thomasclinga=
njones@gmail.com> wrote:
absolutely, yes, tha az token can authorize&n=
bsp;any resource held by the resource server.
The ONLY thing special abo=
ut PII is the protection granted by the various privacy laws.

=

As an aside, I don't find much in the current discussion that giv=
es me a warm feeling about privacy.
The stuff in the torsten token=
s is about as anti-privacy an effort as exists today.
Identity ass=
urance does NOT need to be enabled by sending more and yet again more PII.
Peace ..tom


On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt <dick.hardt@gmail.com=
> wrote:
Hey Tom

While I think def=
ining claims is out of scope of the WG, I think enabling a client to ob=
tain claims about a user is in scope.
Would you consider auth=
orization for the release of claims to be part of the purpose of this WG?

I'm concerned about the XYZ shift to=
 subject identifiers from claims, and pushing claims to a higher layer, as i=
t may indicate to developers that they can ONLY ask for a user identifier.&n=
bsp;

When I think of a claim, I include any and all=
 identifiers, but I also include user attributes such as under-13, over-21, s=
tudent-at-an-accredited-school, resident of city/state/province/country.

GNAP can enable a client to ask for only the claims it=
 needs, preserving user privacy, and compliance with many privacy regulation=
s.

Would you agree?

/Dick<=
/div>



On Sat, Ju=
l 18, 2020 at 9:56 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
I agree=
 with Justin's comment " what we should do, as we define GNAP as a prot=
ocol, is focus on this one, limited slice of the identity space and not spir=
al into others."
The title "Authorization" should rule the purposes of t=
his group above all else.

The earlier statement =
that the client should know who the user is - is just plain WRONG. The clien=
t should only know the information the user is willing to share with the cli=
ent.
It is now the law in California that the client cannot demand=
 identity information that is not required for a legitimate business pu=
rpose.
There are some clients that act as fiduciaries for the user=
 (financial and healthcare come to mind), but as a general rule the "cl=
ient" is not to be trusted by the user.
I understand most of the p=
eople on this list are paid by the client's of the world, but you are s=
till bound by the laws that apply to those clients.

Peace ..tom


On Mon, Jul 13, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wro=
te:
A quick n=
ote, as my choice of language below seems to have been confusing. First ther=
e is a typo, where the word =E2=80=9Cit=E2=80=9D should have been =E2=80=9Ci=
n=E2=80=9D to read:

I am s=
aying that GNAP, in its definition within this working group, should b=
e limited to identifier claims.

And se=
cond, there seems to be confusion around whether I=E2=80=99m trying to argue=
 about the scope =E2=80=9Callowed=E2=80=9D by the charter by saying =E2=80=9C=
its definition within this working group=E2=80=9D here. 

=

To be clear, we as the working group are defining GNAP the=
 protocol. It has not yet been defined, and that=E2=80=99s why were all here=
. The charter doesn=E2=80=99t define it. The input specs don=E2=80=99t defin=
e it. The working group defines it, and my stance as a contributor to this W=
G is that we should focus on a delegation protocol with some basic identifie=
r query support and leave the full fledged identity protocol to different wo=
rk. 

We=E2=80=99ve already got our hands full h=
ere without taking all of that on, especially since I do believe we need to b=
uild GNAP in such a way as to facilitate its extension in several known dire=
ctions, including a full identity protocol. If we do things right here, we c=
an see GNAP as the basis of a large number of things out there in the world.=
 

So my stance in what we should do, as we def=
ine GNAP as a protocol, is focus on this one, limited slice of the identity s=
pace and not spiral into others.

 =E2=80=94 Ju=
stin

On Jul 13, 2020, at 2:51 PM,=
 Justin Richer <jric=
her@mit.edu> wrote:



I am saying that GNAP, it its definition within this working group, sho=
uld be limited to identifier claims. Other claims can come from other protoc=
ols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop them from b=
eing built, but in my opinion we shouldn=E2=80=99t be defining those here. S=
ee the discussion below on the extensibility avenues of this approach.
<=
br>
 =E2=80=94 Justin

<=
div>On Jul 13, 2020, at 2:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

<=
div>
I agree that an API to return claims is useful. I think=
 we have agreed on that. 

Using the SubjectIdentifie=
rs schema is another schema that would be useful for GNAP to support. <=
/div>

I disagree that GNAP should be limited to iden=
tifier claims. 

3D""=E1=90=A7

On Mon, Jul 13, 2020 at 7:16 AM Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu> w=
rote:
One thi=
ng I think we should learn from OIDC is that returning claims from an API, a=
nd not just an assertion or direct response, is a powerful and useful patter=
n. We have an opportunity to separate these cleanly, where OIDC didn=E2=80=99=
t have the opportunity in defining the =E2=80=9Cclaims=E2=80=9D request para=
meter.

As an alternative to the current XYZ and XAuth syn=
taxes, over the weekend I=E2=80=99ve been playing with something that would l=
ook like this strawman in the request:


{
   subject: {
      id: [ =E2=80=
=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=80=9D],
      assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=
=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
  &nbs=
p;}
}

This request says that=
 I=E2=80=99d like some subset of these identifiers (as plain text in the res=
ponse) and some subset of signed assertions in the given formats. Each one w=
ould have an associated space in the return. I=E2=80=99m not picturing that t=
he =E2=80=9Cid=E2=80=9D field values would affect the contents of the assert=
ions: so I could ask for an email address identifier but get back an ID toke=
n that had only the subject identifier. Maybe that=E2=80=99s not the right m=
odel? But it=E2=80=99s at least simple and deterministic this way, and it=E2=
=80=99s something to play with.

Note: The =E2=80=9C=
id=E2=80=9D names are taken from https://to=
ols.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.html, the =E2=
=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=99t see a source t=
hat collected them. If you wanted specific bundles of claims about the user f=
rom a UserInfoEndpoint, for example, you=E2=80=99d have something like:

{
   subject: {
      id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Ce=
mail=E2=80=9D, =E2=80=9Ciss-sub=E2=80=9D],
   =
;   assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifiable_c=
redential=E2=80=9D, =E2=80=9Csaml" ]
   },
   resources: [{
  &n=
bsp;    type: =E2=80=9Cuserinfo=E2=80=9D,
&nb=
sp;      datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprof=
ile=E2=80=9D, =E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
=

  }]
}

=

This is an example for a specific kind of resource, and I don=E2=80=
=99t think that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema her=
e, or the datatype values therein. That should be work outside of GNAP, prob=
ably for the OIDF.

This approach is extensible in s=
everal ways, each of them for a specific reason that I think is clear:
=


 - new values in the =E2=80=9Cid=E2=80=9D field to g=
ive new identifiers
 - new values in the =E2=80=9Cassertion=E2=
=80=9D field to give new assertion formats
 - new fields unde=
r the =E2=80=9Csubject=E2=80=9D heading 
 - new resource=
 types besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or=
 =E2=80=9Cfacebook-profile=E2=80=9D for instance)
 - new data=
types within the =E2=80=9Cuserinfo=E2=80=9D resource type
 - n=
ew top-level request parameters

As per the other th=
read, if you wanted to use the OIDC query language, you=E2=80=99d package it=
 separately as a top-level request parameter since it can include both the I=
D token response and the access token response and we shouldn=E2=80=99t be e=
ncouraging mixing these things together.

 =E2=80=
=94 Justin

On Jul 10, 2020, at 5:=
00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It lo=
oks to me that our different views of what is in scope for GNAP are the diff=
erences below.

Per the subject line, I'm looking at how t=
he client acquires claims about the user. You don't think that is in scope, a=
nd that a different layer will solve that.

I think w=
e should learn from OIDC being on top of OAuth, and GNAP should be able retu=
rn ANY claim, not just identifier claims. There are use cases that may be di=
fficult to support if we do not have that functionality in scope, such as so=
me of the ones I list below, and it seems pretty straightforward to support A=
NY claim if we are supporting identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09 PM Justin Richer <jricher@mit.edu> wrote:


On Jul 10, 2020, at 2:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


inli=
ne ... 

On Thu, Jul 9, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:
=

Yes, the core idea is t=
o not have to parse an assertion to get back the core authentication informa=
tion, which consists of an identifier (iss/sub pair in OIDC, but could be a n=
umber of things). Sometimes the client is going to want the rest of the iden=
tity information, but If the user=E2=80=99s logged into the client befo=
re, the client has likely cached that info and probably won=E2=80=99t need i=
t, and sending it would be a violation of privacy principles.. The client wo=
uld want the info pretty much just in these cases:

 =
1. The client has never seen the user before. 
 2. The u=
ser=E2=80=99s information has been updated since the last time the client sa=
w it.

Agreed
 

Now for case (1), how would the client know if it wants to request the user=
=E2=80=99s profile info or not, since it doesn=E2=80=99t know who the user i=
s? 

But the client could know wh=
o the user is. The client may have used a different AS to authenticate the u=
ser. 

In these=
 cases, the client is not going to be requesting identity information from t=
he AS to log the user in, so it=E2=80=99s not relevant to the use case. The c=
lient will have an opportunity to push that information to the AS.

=

The User may have self identified to the client. The client may hav=
e a cookie saying who the user was and the user said that was them. While th=
e latter cases are really a strong hint, they are likely right most of the t=
ime and can lead to a user experience basde on that hint

In these cases, the AS might be a=
ble to guess if the client has info about the user already, but probably not=
. And the assumptions fall apart if it=E2=80=99s in fact a different user th=
at ends up logging in, which is of course possible (the hint you gave doesn=E2=
=80=99t match the identity of the current user after the AS validates them).=
 This possibility leads to clients always asking for everything every time a=
nd the server providing everything every time. That=E2=80=99s a pattern I th=
ink we should avoid in an ultimate solution =E2=80=94 but ultimately, I don=E2=
=80=99t think that this kind of protocol decision is inside of GNAP.
 
And the AS won=E2=80=99t know if client is going to want the profile i=
nfo, since the AS won=E2=80=99t know if the client has the user=E2=80=99s in=
fo or not. Sure, the AS might have seen that client and that user combo prev=
iously, but it doesn=E2=80=99t know if the client needs an update.

The client can share with the AS the user=
 it knows or thinks it is dealing with, which could let the AS respond if th=
e information was new. This could be the case for an AS that is providing cl=
aims, but not authentication, and could happen silently. The user would only=
 interact if the user information had changed, and the client wanted the upd=
ated information.
 

See above.


And for (2), the client won=E2=80=
=99t know if the user=E2=80=99s info has been updated or not because it does=
n=E2=80=99t know who the user is yet. If the AS can provide some time of upd=
ated stamp to the client, the client can pull the new info when it needs it.=


See above.

See above.

 =
;

=

If you ignore both of these cases and put all the user information inli=
ne with the main request/response, you end up in a situation where the clien=
t always requests everything and the server always provides everything, sinc=
e you can=E2=80=99t be sure you=E2=80=99re not in situation (1) or (2) ahead=
 of time.

See above. There are a=
 number of other states the client could be in.

For=
 example, the client could be stateless about user information, so it knows i=
t is ALWAYS in state 1.

<=
/div>
A stateless client would need to fetch appropriate user informatio=
n every time, then. But that=E2=80=99s an optimization for a very specific c=
ase.

 

This is really what I mean about the two-sta=
ge identity protocol. 

I know wh=
at it is. Per above, GNAP lets us support a wider set of use cases. Why limi=
t ourselves to what OIDC supported?

We aren=E2=80=99t limiting the protocol, but instead l=
imiting the scope of what we define internal to the GNAP protocol. There=E2=80=
=99s a lot of room for innovation on top of it.

 
In the first st=
age, you push the bare minimum of what you need to get the user known to the=
 client. In the second stage, the client uses its access token to call an AP=
I to get whatever else it needs to know about the user. 

=46rom a privacy perspective in non-enterprise use c=
ases, I think the user should give consent to any updated personal informati=
on to a client. In general, the client should not be able to get the la=
test information about a user whenever it wants.

This is about the rights associated with t=
he access token, then. And an access token doesn=E2=80=99t have to keep work=
ing if the AS has a policy that says it won=E2=80=99t. The AS/RS could easil=
y decide that a particular access token will only return data that hasn=E2=80=
=99t been changed. Maybe it stops working after the data changes, or it just=
 returns old data, or any number of things. This is for the AS/RS to decide a=
nd this is pretty standard interpretation of the token, nothing special here=
 because we=E2=80=99re dealing with identity.

 =
;=E2=80=94 Justin

<=
div>
 
/Dick
=

3D""=E1=90=A7








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

<=
/div>-- 

Txauth mailing list

Txauth@ietf.org
=

https://www.ietf.org/mailman/listinfo/txauth





=

--Apple-Mail-84693874-CE05-42DB-8CA1-53B8E3EE0F50--


From nobody Mon Jul 20 02:00: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 7825F3A08E5 for ; Mon, 20 Jul 2020 02:00:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-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=sunet.se
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 OoZrO5GJK1pF for ; Mon, 20 Jul 2020 02:00: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 AE3633A08DE for ; Mon, 20 Jul 2020 02:00:11 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id f5so19363935ljj.10 for ; Mon, 20 Jul 2020 02:00:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=x7TdwJH/FXpJ+hEq2C08BQp7mDKy8mZL4AkUEcUEEeM=; b=Ig+/W4Gj3d/sdVgTbptoEa2MUpysZR+cVkOpKBC4a07FTHq0hXEke1ecamNKVH/ruQ Pt5I4S+bhC8sJmudOoEsVoeWNRjwP+De1TnvdbaQ1hwa8caMuX3zIrvzJn+OBiksI/Yt WqwKlKk4ZTxQTl77No7OeWSO5iveGls/ObfjT+ljTpjHugaXVFIWnvTCsrKcuLIHTcuq sdHW4SdK0bPkIYByz5mMLMVH214nMJMhxMDzEZXbFHRAZjqGtMBCfwLaKXq6I3bG8Q8m pKSVFtYdyKqZDaHdh6c8BxzT/mfdGF259yEKlN0VhJIAxKSlmb/1KkXKph2tJGGHw4U8 +eyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=x7TdwJH/FXpJ+hEq2C08BQp7mDKy8mZL4AkUEcUEEeM=; b=ov8Z/lTdKUosSB4XOLPMCEWMZdY2tiRkgn4FyEyXTgnCkp4r/W50PbcvDm6DDYxZiM Qjcv8ShE5hcaSb3W3p5iF2UO+ppHAPXrAvWM3TjwDI5e7s/gL5YN6KnKIKrJz1ekOwf3 teytvFGcpCCAj+sefJL+LeAzyafaU0asDl6gsFX8J6HxJQBO97GC5uO1lLcIR2kwLBkt Ecx8K7dGg+adpbIiHgzjflPKfxnawJs0PB6tGdzspE3Txu28wH16TlCfSim85xEe7L8A qxZkJ8RUi8ehA5X8ZHaELgrkrAIYOJM1Vjioe8dVYX5iC/g5/+oraA/jeFv9/2RSAPEy YTRw==
X-Gm-Message-State: AOAM533cs3AKPgCpdAGHbNNPUMYZ6NSdZAd0e4jVR0uLLDKh4zhCYD18 KyR/sf2Xs4EZGWyUfQJQ/rC3bgcTUk+oBQ==
X-Google-Smtp-Source: ABdhPJysEXvtndIrnpSekpAhNgFx7GaxVosvippj5sTFKpRZRIeYMx2Y5rJ5bHh3ox7tCvNNcRpQEw==
X-Received: by 2002:a2e:9749:: with SMTP id f9mr9005675ljj.276.1595235608966;  Mon, 20 Jul 2020 02:00:08 -0700 (PDT)
Received: from [192.168.10.50] ([192.36.125.12]) by smtp.gmail.com with ESMTPSA id g142sm3650006lfd.41.2020.07.20.02.00.07 for  (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jul 2020 02:00:07 -0700 (PDT)
To: txauth@ietf.org
References:  <6D58464F-3EFA-4367-9033-91FCB9CF40AC@mit.edu>  <0905DCA3-1B30-429A-AB02-8ED27D37F6C3@mit.edu>  <974147F1-A9CE-4093-A170-9F4F9DFB3638@mit.edu>  <1D7A02B1-E58D-44D0-9E33-5313A7367949@mit.edu>  <174F2061-3F0F-49B2-A18F-58DF658E4473@mit.edu>      
From: Leif Johansson 
Autocrypt: addr=leifj@sunet.se; prefer-encrypt=mutual; keydata= xsBNBFJK9qIBCACypED81H1N4YmhMJrb4uOtTDzo+lFZDVVOcK11+NhTFl+AZZFnWH/7UPn+ q5ZZBd/IhONfb5QGw5FzTyBWHsbAteXgCvHAIyumwhQzhZnow6myyC6/MwDhomT5rb3MkCKC yQMNfj/yMgL6ZRsXVhlGOLMmOekRfKe2wiC5BhRaQQwPZPwgFS5D0Tro8Xfxjk98u8rNpQXi 9walRAffRY+byhkPiBj0sVA2RXK9Dx2DL3EY0xx07r6Qhs2XkbXNDDCHRuChhHSHwWC16VS9 x7Nhfg2EwKqmMGRNREikjwzDl/aHKz+FXTLONdmc83sRyklqgH90f3na6s/RT5XTb08xABEB AAHNHUxlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U+wsB+BBMBCAAoAhsDBgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCW7Yg8gUJDw7ExQAKCRDXOtZDCtR41io7CACOVmQcjoS7cfuF 43NhvpfFjSn91qShubrWx/p0+v/1MRyGajeMKcBd9HPDsN/lhMuY6k2zI1Qsrsycv51QQ+d0 +lPFxO3LKcrzaKqfKV3UZP3eVsMQgyP21iFIFAw424aAeBjWRhhnzlvsiP3RzF4NNb7goMWR PLWlld4M+MGqlM+T8M2Jbxl2OejedK5HCGm00IzXS7NojDGdIiXHbx0S0RloNb7ssQdFdHAH M6hO30lCwTM5jnNbejXhFUlMqYdRjWPUAbFwX3Pw9Wpkr5xz5xYbx8xPZBIG6ROp8ExxP31V NTm+DTnwJS5LLMbV1aDLYIzYlEossP2NFhLtwVDEzsBNBFJK9qIBCAC+k1tFOeDS4gMxEgRk fiVLHFemwJWQiGZHYhtDgjh6w6mB8G3WZ+/gD2CMp5DgHFRC1sW2iMj3gOzrfyxzd9AmWbhX YceR6EFkTc6OVsaIb+eHH/Zo3DKyB1Dq9CA5fjjnEQzti+KKSZYWzB0Fkt7qrfOS6YM1zMjE UxUUwsl1qirx5DuByWLDX7ULU7H/xmPVhHUVZO8XEaFV2m+ICx8Y6B98KMeJ0Qz8b8wp2g7v WEkwS2R6IjF0kMrRxnxUvwA6EUiZuFphhuY/lWCJusLl1olgOE+BKMEUStJWEi0s+pd8FL1v OLeNKbIUFro0+oZr9byABpkPNjMxKV36uj1dABEBAAHCwGUEGAEIAA8CGwwFAlu2H5wFCQ8O w3cACgkQ1zrWQwrUeNbSVAgAmRS6XxztiU9pczUwElOnolmnAIUocSXdfllZABxLX1MkZ4Yn 0jEbJKMpPOAMu7cQs4gni/AprnMae23taqJprwWCE6lTcOEhdPNKSFhdL4eE+UCd9Z9S/8PC M0GkjDF9FAWcrIBmySiHmZfAwKbHk3+AhDmY2PzN+mOzgU7t855+OtcoI02PDEXJGTCU9Mcl YtMNAlrmMmbMUApLSIoFluY35nlBVDFD3bDuCb59Nbs9aBJ9bu956G04XUcYt9sTsnkPppzX 82jyCc6Oeg9He8F1ep7AEoscflUKuwn9YF/sblqq27GO4d/BQPtaNw0iGz1H1C1QWKES4tk4 bZRWFA==
Message-ID: <5561941e-54f9-8c7b-681a-8b9295ebc462@sunet.se>
Date: Mon, 20 Jul 2020 11:00:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 20 Jul 2020 09:00:43 -0000

On 2020-07-19 04:34, Tom Jones wrote:
> absolutely, yes, tha az token can authorize any resource held by the resource server.
> The ONLY thing special about PII is the protection granted by the various privacy laws.
> 
> As an aside, I don't find much in the current discussion that gives me a warm feeling about privacy.
> The stuff in the torsten tokens is about as anti-privacy an effort as exists today.
> Identity assurance does NOT need to be enabled by sending more and yet again more PII.
> Peace ..tom

Taking off my chairs hat for a bit.

This thread has some very common missunderstanding about PII esp as it pertains
to legislation (eg in the EU).

Identifiers are just as much PII as claims containing things that are recognizably
personal (eg names etc).

The term PII stands for personal /identifiable/ information. Identifiers that
uniquely identify a data subject, regardless of what systems & resources may be
needed to de-reference those identifiers are PII - at least in the eyes of GDPR.

	Cheers Leif


From nobody Mon Jul 20 02:05: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 964C13A08DC for ; Mon, 20 Jul 2020 02:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.631
X-Spam-Level: 
X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, 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 ceC0PGs7zS_K for ; Mon, 20 Jul 2020 02:04:57 -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 7D7B03A08DB for ; Mon, 20 Jul 2020 02:04:56 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d52 with ME id 5M4t2301L2bcEcA03M4uyj; Mon, 20 Jul 2020 11:04:54 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 20 Jul 2020 11:04:54 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt 
Cc: Francis Pouatcha , txauth@ietf.org
References:              
From: Denis 
Message-ID: 
Date: Mon, 20 Jul 2020 11:04: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="------------C76989735FCE20FBC699F4C8"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 20 Jul 2020 09:04:59 -0000

This is a multi-part message in MIME format.
--------------C76989735FCE20FBC699F4C8
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dick,

> On Fri, Jul 17, 2020 at 9:21 AM Denis  > wrote:
>
>     Hello Francis and Dick,
>
>     The good news first: we are making some progress. We are now close
>     to an agreement with steps (1) up to (3),
>     ... except that the place where the user consent is captured is
>     not mentioned/indicated.
>

This major question which is currently left unanswered is where, when 
and how the user consent is captured.

Another important point to consider and to explain is related to the 
assurances that the user can obtain about
the respect of his choices. This point is currently left unanswered in 
draft-hardt-xauth-protocol-13.

>
>     If a RO needs to be involved and since a RO is directly associated
>     with a RS, why can't it be directly queried
>     by the appropriate RS after step (2) or later on ?
>
>
> Good question. Perhaps you can expand on a use case where that would 
> be useful?

Before I expand, would you be able to explain first under which 
circumstances a RO needs to be queried by a GS ?
How can the GS identify which RO to query ?

>     Which information is supposed to be presented to the RO ?
>     Which information is supposed to be returned by the RO ?
>
>
> Just like how the user authenticates to an AS, how the AS and RO 
> communicate is out of scope.

At the moment, the usefulness of a dialogue between a GS and a RO has 
not been explained, nor demonstrated.
The question is about the functionality of that dialogue in terms of 
input and output information (and not about
the design of a protocol or of a user interface). Anyway, AFAIU a 
dialogue between a GS and a RO is optional.

> For many use cases, the User is the RO, and the interaction is through 
> a user interface, not a machine protocol.

Wait a second. You wrote "the User is the RO". The User is attempting to 
make an access to a RS by using a Client.
_That_ User is not the RO of the RS.

Denis



--------------C76989735FCE20FBC699F4C8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Dick,

    


    

    

      
      
On Fri, Jul 17, 2020 at 9:21 AM Denis <denis.ietf@free.fr>
        wrote:

        

          

            

              
Hello Francis and Dick,

              


              

              
The good news first: we are making some progress. We
                are now close to an agreement with steps (1) up to (3),
                

                ... except that the place where the user consent is
                captured is not mentioned/indicated.

            

          

        

      

    

    

    This major question which is currently left unanswered is where,
    when and how the user consent is captured.

    

    Another important point to consider and to explain is related to the
    assurances that the user can obtain about 

    the respect of his choices. This point is currently left unanswered
    in draft-hardt-xauth-protocol-13.

    

    

      

        

          

            

              


              

              
If a RO needs to be involved and since a RO is
                directly associated with a RS, why can't it be directly
                queried 

                by the appropriate RS after step (2) or later on ?

            

          

          


          

          
Good question. Perhaps you can expand on a use case where
            that would be useful?

        

      

    

    
Before I expand, would you be able to explain first under which
      circumstances a RO needs to be queried by a GS ?

      How can the GS identify which RO to query ?

    

    

      

        

          
 

          

            

              
Which information is supposed to be presented to the
                RO ?

                Which information is supposed to be returned by the RO ?

            

          

          


          

          
Just like how the user authenticates to an AS, how the AS
            and RO communicate is out of scope.

          

        

      

    

    
At the moment, the usefulness of a dialogue between a GS and a RO
      has not been explained, nor demonstrated.

      The question is about the functionality of that dialogue in terms
      of input and output information (and not about 

      the design of a protocol or of a user interface). Anyway, AFAIU a
      dialogue between a GS and a RO is optional.

    

    

      

        

          
For many use cases, the User is the RO, and the
            interaction is through a user interface, not a machine
            protocol. 

          

        

      

    

    
Wait a second. You wrote "the User is the RO". The User is
      attempting to make an access to a RS by using a Client. 

      That User is not the RO of the RS.   

      

      Denis

    


    

  


--------------C76989735FCE20FBC699F4C8--


From nobody Mon Jul 20 02:33: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 A9B053A077A for ; Mon, 20 Jul 2020 02:33:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.37
X-Spam-Level: 
X-Spam-Status: No, score=0.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, PDS_OTHER_BAD_TLD=1.999, 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 iqSFjGBS-CXn for ; Mon, 20 Jul 2020 02:33: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 696C43A0772 for ; Mon, 20 Jul 2020 02:33:31 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d52 with ME id 5MZV2300A2bcEcA03MZVRr; Mon, 20 Jul 2020 11:33:29 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 20 Jul 2020 11:33:29 +0200
X-ME-IP: 90.79.51.120
To: Justin Richer 
Cc: txauth@ietf.org
References:  
From: Denis 
Message-ID: <8e09c6e9-5396-dba8-850f-cdf1d602431d@free.fr>
Date: Mon, 20 Jul 2020 11:33:29 +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="------------A924BC1E9065F524BA19731C"
Content-Language: en-GB
Archived-At: 
Subject: [Txauth] Comments on new version of XYZ Draft (draft-richer-transactional-authz-09)
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, 20 Jul 2020 09:33:35 -0000

This is a multi-part message in MIME format.
--------------A924BC1E9065F524BA19731C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Justin,

Since you mentioned "Feedback, as always, is welcomed", hereafter are a 
few comments:

1) The trust relationships are not described: Example : A trusts B for 
some behaviour C.

2) There is no figure to illustrate the various exchanges and to 
indicate whether they are mandatory or optional.

3) The user consent is not addressed.

4) The draft states:

9 Discovery

            By design, the protocol minimizes the need for any 
pre-flight discovery. To begin a transaction, the RC only needs to know
            the transaction endpoint of the AS, and everything else can 
be negotiated dynamically.

If the RC wants to optimize its calls to the AS, it MAY send an HTTP 
OPTIONS request to the transaction endpoint to retrieve
            the server's discovery information.

At the beginning, the client has to clue about what will be requested by 
the RS. Furthermore what will be requested by the RS
will be dependent upon the operation that will be attempted at the RS 
and /the requested information may change at any point of time/.

As long as the client does not know which attributes from which AS(*s*) 
will be needed to perform a given operation on a RS,
the client may not know which AS(*s*) to contact. So the client shall, 
at least once, contact the RS.

Another point is about the RS discovery information. Some RSs, may only 
be willing to disclose some parts of their discovery information
to authenticated users/client applications and some other parts of their 
discovery information to users or client applications that have
already successfully performed some operation(s). The disclosed 
discovery information usually depends both upon the operation that is 
requested
and upon which operation(s) has/have already been successfully 
performed. The case where the discovery information is static and publicly
disclosed should be considered as a specific case of the general case.


5) A Client is not requesting one or more access tokens for itself, but 
on behalf of a user or a client application. Users and client applications
may have an account on the AS, but not Clients. A Client is trusted by 
its user or by its client application to interface with ASs and RSs.

At this time, there is no trust relationship between a Client and an AS 
... unless there is a desire to consider the use of secure elements
by users.


6) The model seems to be limited to the case where RSs have a 
relationship with one and only one AS (i.e. it is a mono-domain 
environment)
and seems to be not applicable nor scalable over the Internet with 
millions of RSs trusting thousands of ASs.

Section 2.1.2 called "Requesting Multiple Access Tokens" provides an 
example for two access tokens. However, it is not explained how
such mechanism would be able to obtain multiple access tokens from more 
than a single AS.


7) "By design", the protocol mandates to tell to the AS which RS will be 
accessed and which operations will be attempted.

This places the AS in an perfect position to act as Big Brother: the AS 
will be able to trace which operations are likely to be performed by
either a user or a client application, on which RS and at which instant 
of time. In addition, if artificial intelligence (AI) is used by the AS or
by a third party to which this information is communicated, this leaves 
the gate wide opened to a lot of undisclosed usages "behind the scenery".

Since it is not possible to be confident that ASs will never perform 
some additional tasks "behind the scenery", there is the need to prevent 
ASs
to behave in an inappropriate manner. Unfortunately, the proposed 
architecture is unable to provide this property.

8) Section 14 (Privacy considerations) mentions:

TBD: There are a lot of privacy considerations to add.

Indeed, in particular, readers should be warned that this protocol 
allows the AS to trace/log which operations are likely to be performed
by every user or client application, on which RS, and at which instant 
of time.

Denis

> Hi all,
>
> I’ve updated the XYZ draft specification. Since the publication tools 
> are currently locked prior to the upcoming virtual meeting, I have 
> published it online here:
>
> https://oauth.xyz/draft-richer-transactional-authz
>
> This represents a pretty significant refactoring of the specification, 
> hopefully to make the concepts and capabilities easier to understand. 
> The core protocol is largely the same as before, but there are a 
> number of serious updates:
>
>  - Continuation requests happen at a URL returned in the TX response. 
> The “handle” is still sent as one of the input values here, since the 
> handle can also be used it other contexts.
>  - Tokens now can include the resources they are issued for
>  - Tokens can have an optional management URI for rotation and revocation.
>  - “claims” has been removed in favor of “subject” dealing directly 
> with identifiers and assertions
>  - the “user” request and response now align with identifiers and 
> assertions
>  - Extensions and registries are more clearly enumerated throughout 
> the document
>  - DID-related items have been excised in deference to a future 
> possible extension
>  - Added a “pushback” mechanism to complement the “callback” mechanism
>  - Simplified dynamic handle returns and access tokens based on 
> developer feedback (basically we dropped a bunch of “what if” stuff 
> that nobody used or liked, like SHA3 hashes for bearer tokens)
>
> I’ve also updated the interactive examples on https://oauth.xyz/ to 
> match this new draft. Hopefully it’s consistent with the draft text.
>
> I have not yet, however, updated any of the implementations of XYZ to 
> take the elements of new syntax into account, so there might be some 
> more changes prior to the IETF meeting as I realize what terrible 
> mistakes I’ve made when doing that. :)
>
> Feedback, as always, is welcomed, and thanks to everyone who’s 
> provided input to the project to date.
>
>  — Justin



--------------A924BC1E9065F524BA19731C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Justin,

    


      

    
Since you mentioned
        "Feedback, as always, is welcomed", hereafter are a few
        comments:

    

    

      

          1) The trust relationships are not described: Example : A
          trusts B for some behaviour C.

        
        

          2) There is no figure to illustrate the various exchanges and
          to indicate whether they are
          mandatory or optional.

      
3) The user consent is not addressed.

        

      

          4) The draft states:

          

                
          9 Discovery 

        
        

                   By design, the protocol
          minimizes the need for any pre-flight discovery. To
          begin a transaction, the RC only needs to know 

                   the transaction endpoint of the
          AS, and everything else can be negotiated dynamically.

        
        

                  
          If the RC wants to optimize its calls to the AS, it MAY send
          an HTTP OPTIONS
          request to the transaction endpoint to retrieve 

                     the server's discovery
          information.

        
          

          At the beginning, the client has to clue about what will be
          requested by the
          RS. Furthermore what will be requested by the RS 

          will be dependent upon the
          operation that will be attempted at the RS and the
            requested information may change at any point
            of time. 

        

      

          As long as the client does not know which attributes from
          which AS(s) will be needed to perform a given operation
          on a RS, 

          the client may not know which
          AS(s) to contact. So the client shall, at least once,
          contact the RS.

      
Another point is about the RS discovery
            information. Some RSs, may only be willing to disclose some
            parts of their discovery information

            to authenticated users/client applications and some other parts of their discovery information
            to users or client applications that
                have 

                already successfully performed some operation(s). The
                disclosed discovery information usually depends both
                upon the operation that is requested 

                and upon which operation(s) has/have already been successfully performed. The
                        case where the discovery
                                information is static and publicly 

                                disclosed should be considered as a
                                specific case of the general case. 

                              

      


          5) A Client is not requesting one or more access tokens for
          itself, but on behalf of a user or a client application. Users
          and client applications 

          may have an
          account on the AS, but not Clients. A Client is trusted by its
          user or by its
          client application to interface with ASs and RSs.

          

          At this time, there is no trust relationship between a Client
          and an AS ... unless there is a desire to consider the use of
          secure elements 

          by users.

          

          

          6) The model seems to be limited to the
            case where RSs have a relationship with one and only one AS
            (i.e. it is a mono-domain environment) 

            and seems to be not applicable nor scalable over the
            Internet with millions of RSs trusting thousands of ASs. 

          

          Section 2.1.2 called "Requesting Multiple Access Tokens"
          provides an example for two
          access tokens. However, it is not explained how 

          such mechanism would be able to
          obtain multiple access tokens from more than a single AS. 

          

          

          7) "By design", the protocol mandates to tell to the AS which
          RS will
          be accessed and which operations will be attempted.

          

          This places the AS in an
          perfect position to act as Big Brother: the AS will be able to
          trace which
          operations are likely to be performed by 

          either a user or a client application, on
          which RS and at which instant of time. In addition, if
          artificial intelligence
          (AI) is used by the AS or 

          by a third party to which this information is
          communicated, this leaves the gate wide opened to a lot of
          undisclosed usages "behind
          the scenery".

          

          Since it is not possible to be confident that ASs will never
          perform some additional tasks "behind
            the scenery", there is the need to prevent ASs 

          to behave in an inappropriate manner. Unfortunately, the
          proposed architecture is unable to provide this property.

          

        

      
8) Section 14 (Privacy considerations)
          mentions:

          

                  
          TBD: There are a lot of privacy considerations to add.

          

          Indeed, in particular, readers should be warned that this
          protocol allows the
          AS to trace/log which
            operations are likely to be performed 

            by every user or client application, on
            which RS, and at which instant of time.

      

    
Denis

    


    

    
Hi
      all,
      


      

      
I’ve updated the XYZ draft specification. Since the
        publication tools are currently locked prior to the upcoming
        virtual meeting, I have published it online here:

      


      

      
      


      

      
This represents a pretty significant refactoring of the
        specification, hopefully to make the concepts and capabilities
        easier to understand. The core protocol is largely the same as
        before, but there are a number of serious updates:

      


      

      
 - Continuation requests happen at a URL returned in the TX
        response. The “handle” is still sent as one of the input values
        here, since the handle can also be used it other contexts.

      
 - Tokens now can include the resources they are issued for

      
 - Tokens can have an optional management URI for rotation
        and revocation.

      
 - “claims” has been removed in favor of “subject” dealing
        directly with identifiers and assertions

      
 - the “user” request and response now align with identifiers
        and assertions

      
 - Extensions and registries are more clearly enumerated
        throughout the document

      
 - DID-related items have been excised in deference to a
        future possible extension

      
 - Added a “pushback” mechanism to complement the “callback”
        mechanism

      
 - Simplified dynamic handle returns and access tokens based
        on developer feedback (basically we dropped a bunch of “what if”
        stuff that nobody used or liked, like SHA3 hashes for bearer
        tokens)

      


      

      
I’ve also updated the interactive examples on https://oauth.xyz/ to match this
        new draft. Hopefully it’s consistent with the draft text.

      


      

      
I have not yet, however, updated any of the implementations
        of XYZ to take the elements of new syntax into account, so there
        might be some more changes prior to the IETF meeting as I
        realize what terrible mistakes I’ve made when doing that. :) 

      


      

      
Feedback, as always, is welcomed, and thanks to everyone
        who’s provided input to the project to date. 

      


      

      
 — Justin

    

    


    

  


--------------A924BC1E9065F524BA19731C--


From nobody Mon Jul 20 04:26: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 7E57D3A0A27 for ; Mon, 20 Jul 2020 04:26:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.082
X-Spam-Level: 
X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 nEsqC-jRf0yW for ; Mon, 20 Jul 2020 04:26:35 -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 C248C3A0A21 for ; Mon, 20 Jul 2020 04:26:34 -0700 (PDT)
Received: from [192.168.1.3] (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 06KBQVXW032428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 Jul 2020 07:26:32 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_6D68D8BE-6912-4F52-A866-F3B062BF8CE4"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 20 Jul 2020 07:26:31 -0400
In-Reply-To: 
Cc: txauth@ietf.org
To: Dick Hardt 
References:   <5B2BF4E7-77CD-4DC6-A0C9-E7894CE38A5E@mit.edu>   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] New version of XYZ Draft
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, 20 Jul 2020 11:26:38 -0000

--Apple-Mail=_6D68D8BE-6912-4F52-A866-F3B062BF8CE4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Dick,

I think it should be pretty uncontroversial that the goal of the GNAP =
working group is to produce the GNAP protocol. But I=E2=80=99m still =
glad to see you=E2=80=99re interested in focusing on technical =
discussions.=20

Answers to the individual points inline.

> On Jul 18, 2020, at 8:58 PM, Dick Hardt  wrote:
>=20
> Justin: how about we let the chairs drive WG conversations on the =
goals, and we focus on the technical discussion?
>=20
> In addition to my questions and observations earlier, here is my =
feedback on the new capabilities in XYZ:
>=20
> 2.5.2. Redirect to an Arbitrary Short URL
>=20
> This looks the same as 2.5.1 except it is short. My concern with both =
of these is the AS has no signal on the mode chosen by the client/user. =
It could be a redirect on the same device, or decoupled, where the user =
is now on a different device. In 2.5.3 you justify a new URL because the =
AS may want a different URL for an app. I think that is even more =
significant between an on device redirect, and a decoupled experience. =
By having different URLs for the different modes in XAuth, the AS can =
ensure the one in a decoupled mode is short enough to be scanned if =
decoupled is supported. In other words, the mode dictates if it should =
be short enough to be scanned.

The differences between a =E2=80=9Ccoupled/decoupled=E2=80=9D experience =
are not controlled by the =E2=80=9Credirect/short_redirect/app=E2=80=9D =
parameters, but by the =E2=80=9Ccallback/pushback=E2=80=9D parameters. =
The first three are parameters that determine some of the ways that the =
client can get :to: the AS, while the others are ways the client can get =
:back: from the AS. They are not tied together like they are in Xauth.=20=


Which combinations are available is up to the client=E2=80=99s request, =
since, after all, the client is the piece of software that knows what it =
can do, not the AS. The AS isn=E2=80=99t in a position to guess what the =
client is going to do with the information it gets back, it can only =
respond to the request for information that the client sends. If a =
client displays a URL to the user as a QR code, it=E2=80=99s probably =
not going to send a =E2=80=9Ccallback=E2=80=9D, for example. If an AS =
determines that it doesn=E2=80=99t want to support that =E2=80=9Cdecoupled=
=E2=80=9D mode for a given request, it can reject it for lack of a =
=E2=80=9Ccallback=E2=80=9D parameter. The reason for this decoupling=20

And as I=E2=80=99m sure you saw in my editor=E2=80=99s note, I=E2=80=99m =
not convinced that the short_redirect is worth it as a separate option, =
even though the semantics are pretty clear here. As I said in the last =
discussion we had on this topic, I=E2=80=99ve implemented a QR code =
based on a full redirect URI and did not find it problematic. You made a =
compelling argument that the AS would potentially have different =
generation rules for short and long, and wouldn=E2=80=99t want to use a =
short one unless it needed to. It seemed to be a simple enough addition =
to put in this revision.

>=20
> 2.5.3 Open an Application-specific URL
>=20
> What are you intending "app" to mean? I can think of a device where =
the client can open a URL, and a URL could not be associated with an =
application on the device. Are you thinking the client will do some =
detection if a specific app is available on the device? What if the app =
is not on the device? Most platforms don't provide any probing on what =
other apps are on a device, so there is no mechanism to detect if the =
app is present prior to launching. Is that what you are expecting?

You can detect if an app (any app) is going to handle a URL on some =
platforms. This mechanism not only lets an AS have different URLs for =
app launching and web-based interaction, and it lets the client optimize =
the experience instead of the awkward fall-through that we have with =
OAuth2=E2=80=99s app2app communication today. Furthermore, as I=E2=80=99m =
sure you saw in my editor=E2=80=99s note, there=E2=80=99s probably going =
to be additional pieces of information passed in this case. I=E2=80=99ve =
talked with a couple different groups who are using distributed storage =
mechanisms to communicate between components. In that case, this will =
probably have more information in it than a single URL, but I didn=E2=80=99=
t want to conjecture what that would look like, thus the note.

>=20
> 2.5.5. Receive an HTTP Direct Callback
>=20
> What use cases require this functionality? Contrary to SecEvent, where =
both push and poll are specified because a receiver may not be able to =
have a public endpoint, the AS has a public endpoint for the client to =
call. In GNAP, the client can poll the AS. Why have both?
>=20

Why limit the client to only callbacks? The callback means =E2=80=9Cthere=E2=
=80=99s an HTTP endpoint that the user=E2=80=99s browser gets to=E2=80=9D =
whereas pushback means =E2=80=9Cthere=E2=80=99s an HTTP endpoint that =
the user=E2=80=99s browser can=E2=80=99t get to=E2=80=9D. Both are =
reasonable, and should be combinable with any of the options for getting =
a user to the AS, above. There are likely to be other options as well, =
since we already see them in the wild (CIBA=E2=80=99s push mode, for =
instance).=20

 =E2=80=94 Justin

> /Dick
>=20
>=20
>=20
> On Sat, Jul 18, 2020 at 7:55 AM Justin Richer > wrote:
> I really don=E2=80=99t see them as shifting towards each other so much =
as it is them adapting and changing based on ongoing efforts. As such =
I=E2=80=99ve modified XYZ not to make it =E2=80=9Clook more like =
XAuth=E2=80=9D, but rather to hopefully improve it in some measurable =
dimensions. So if you wonder why it doesn=E2=80=99t =E2=80=9Clook even =
more like XAuth=E2=80=9D it=E2=80=99s because I don=E2=80=99t think that =
such changes would be improvements =E2=80=94 in fact, even with recent =
improvements, I think there are a still a lot of issues with XAuth=E2=80=99=
s design and assumptions. XYZ can, I=E2=80=99m sure, also be improved.
>=20
> The goal here isn=E2=80=99t to take two projects and make them look =
the same. The goal here is to make one protocol, GNAP, with the best =
ideas and elements engineered into it that we, as a working group, can. =
It=E2=80=99s not about one input proposal winning over another, it=E2=80=99=
s about improving our understanding of all the use cases and possible =
solutions and coming up with the best specification possible. Making =
things better should always be the goal. Progress should always be the =
goal.=20
>=20
> But we aren=E2=80=99t here to build XYZ or XAuth. We=E2=80=99re here =
to build GNAP and decide what GNAP looks like. XYZ=E2=80=99s structure =
and design is the best I=E2=80=99ve been able to make it so far, and it =
should be our goal as a WG to move past either XYZ or XAuth and build =
GNAP even better than any of that.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 17, 2020, at 6:46 PM, Dick Hardt > wrote:
>>=20
>> XYZ is looking a lot more like XAuth, similar to how XAuth has =
shifted towards XYZ.=20
>>=20
>> I have implemented separate URIs for grants and authorizations, and =
it worked really well.
>>=20
>> All 3 of the new capabilities are problematic. Perhaps you did not =
notice that there no longer is a short_uri in XAuth? As I recall, you =
were opposed to the short URI that was in the earlier drafts of XAuth. =
In my XAuth implementation, I show QR codes in the CLI app. Have you =
checked out my implementation? Have you implemented a QR code? I found =
that the string did not need to be nearly as short as it has in the =
past.=20
>>=20
>> I still don't understand the requirement to rotate the reference =
handle. I read over the pointer you provided last time we discussed it, =
and responded, but I have not heard back from you on that.
>>=20
>>=20
>> =E1=90=A7
>>=20
>> On Fri, Jul 17, 2020 at 2:36 PM Justin Richer > wrote:
>> Most of these are changes I=E2=80=99ve wanted to do for quite some =
time and finally had opportunity to make the edits. As I said below, the =
core protocol really hasn=E2=80=99t changed in nature, but hopefully =
it=E2=80=99s easier to understand with it laid out in this way.=20
>>=20
>> All of these are points that I=E2=80=99ve made previously on the list =
in discussions, but to answer your questions directly:
>>=20
>> - Mapping items to separate URLs has been on XYZ=E2=80=99s radar =
since well before it was proposed in Xauth, so this is bringing some of =
that into the concrete system. I still need to implement it to see how =
well it works in practice.
>>=20
>> - The need to rotate the reference handle as well as use it =
externally (the =E2=80=9Cextend a request=E2=80=9D method) both call for =
having an identifier separate from the access URL. It also allows an AS =
more freedom in how it manages its endpoints, and aligns with the desire =
to push more information into the ongoing request after the initial =
phase. I=E2=80=99d actually rather the access token management move in =
that direction, using the token itself as the artifact, but I couldn=E2=80=
=99t do that and still use the DELETE method for revocation. So that=E2=80=
=99s an engineering challenge that I think the group should discuss, and =
decide whether it=E2=80=99s worth having the =E2=80=9CDELETE=E2=80=9D =
verb semantics and having that restriction placed on the AS as a =
consequence.
>>=20
>> - The DID work is likely better suited for an extension, and always =
has been. But it was worth having in previous revisions for discussion =
purposes, especially as a point around how a non-HTTP interaction method =
would work. I expect to see DIDCOMM, CHAPI, WebAuthN, and other =
interaction methods in the extensions landscape of GNAP, usable =
alongside the others.=20
>>=20
>> And a final point, the interaction setup hasn=E2=80=99t really =
changed, so I=E2=80=99m curious to hear what you think has changed =
there. Even with a couple new capabilities on the way there (short_uri =
and app) and back (pushback), It=E2=80=99s structurally and conceptually =
identical to previous revisions.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 17, 2020, at 1:10 PM, Dick Hardt > wrote:
>>>=20
>>> Hey Justin,
>>>=20
>>> Glad to see that you are aligning on having URIs for the access =
tokens and the "grant".
>>>=20
>>> While the token URI is unique to the token, you have not done the =
same for a "grant", but have a handle and a non-unique URI.
>>>=20
>>> Why not have a unique grant URI similar to the token URI? (a =
combination of the handle and a non-unique URI) -- this is then both the =
identifier, and the URL for "management"?
>>>=20
>>> Glad to see you have excised the DID references. I don't think the =
common use cases are well established there currently.
>>>=20
>>> I have LOTS of feedback on your interaction changes, that I'll post =
later on, and hope that others have feedback on those as well.
>>>=20
>>> /Dick
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> On Thu, Jul 16, 2020 at 2:52 PM Justin Richer > wrote:
>>> Hi all,
>>>=20
>>> I=E2=80=99ve updated the XYZ draft specification. Since the =
publication tools are currently locked prior to the upcoming virtual =
meeting, I have published it online here:
>>>=20
>>> https://oauth.xyz/draft-richer-transactional-authz =

>>>=20
>>> This represents a pretty significant refactoring of the =
specification, hopefully to make the concepts and capabilities easier to =
understand. The core protocol is largely the same as before, but there =
are a number of serious updates:
>>>=20
>>>  - Continuation requests happen at a URL returned in the TX =
response. The =E2=80=9Chandle=E2=80=9D is still sent as one of the input =
values here, since the handle can also be used it other contexts.
>>>  - Tokens now can include the resources they are issued for
>>>  - Tokens can have an optional management URI for rotation and =
revocation.
>>>  - =E2=80=9Cclaims=E2=80=9D has been removed in favor of =
=E2=80=9Csubject=E2=80=9D dealing directly with identifiers and =
assertions
>>>  - the =E2=80=9Cuser=E2=80=9D request and response now align with =
identifiers and assertions
>>>  - Extensions and registries are more clearly enumerated throughout =
the document
>>>  - DID-related items have been excised in deference to a future =
possible extension
>>>  - Added a =E2=80=9Cpushback=E2=80=9D mechanism to complement the =
=E2=80=9Ccallback=E2=80=9D mechanism
>>>  - Simplified dynamic handle returns and access tokens based on =
developer feedback (basically we dropped a bunch of =E2=80=9Cwhat if=E2=80=
=9D stuff that nobody used or liked, like SHA3 hashes for bearer tokens)
>>>=20
>>> I=E2=80=99ve also updated the interactive examples on =
https://oauth.xyz/  to match this new draft. =
Hopefully it=E2=80=99s consistent with the draft text.
>>>=20
>>> I have not yet, however, updated any of the implementations of XYZ =
to take the elements of new syntax into account, so there might be some =
more changes prior to the IETF meeting as I realize what terrible =
mistakes I=E2=80=99ve made when doing that. :)=20
>>>=20
>>> Feedback, as always, is welcomed, and thanks to everyone who=E2=80=99s=
 provided input to the project to date.=20
>>>=20
>>>  =E2=80=94 Justin
>>> --=20
>>> Txauth mailing list
>>> Txauth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/txauth =

>>=20
>=20


--Apple-Mail=_6D68D8BE-6912-4F52-A866-F3B062BF8CE4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Dick,

I think it =
should be pretty uncontroversial that the goal of the GNAP working group =
is to produce the GNAP protocol. But I=E2=80=99m still glad to see =
you=E2=80=99re interested in focusing on technical =
discussions. 

Answers to the individual points inline.

On Jul 18, 2020, at 8:58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin:=
 how about we let the chairs drive WG conversations on the =
goals, and we focus on the technical discussion?

In addition to my =
questions and observations earlier, here is my feedback on the new =
capabilities in XYZ:

2.5.2. Redirect to an Arbitrary Short =
URL

This looks the same as 2.5.1 except it is short. My concern =
with both of these is the AS has no signal on the mode chosen by the =
client/user. It could be a redirect on the same device, or decoupled, =
where the user is now on a different device. In 2.5.3 you justify a new =
URL because the AS may want a different URL for an app. I think =
that is even more significant between an on device redirect, and a =
decoupled experience. By having different URLs for the different modes =
in XAuth, the AS can ensure the one in a decoupled mode is short enough =
to be scanned if decoupled is supported. In other words, the mode =
dictates if it should be short enough to be =
scanned.

The differences between a =E2=80=9Ccoupled/decoupled=
=E2=80=9D experience are not controlled by the =
=E2=80=9Credirect/short_redirect/app=E2=80=9D parameters, but by the =
=E2=80=9Ccallback/pushback=E2=80=9D parameters. The first three are =
parameters that determine some of the ways that the client can get :to: =
the AS, while the others are ways the client can get :back: from the AS. =
They are not tied together like they are in Xauth. 

Which combinations are available is up to the =
client=E2=80=99s request, since, after all, the client is the piece of =
software that knows what it can do, not the AS. The AS isn=E2=80=99t in =
a position to guess what the client is going to do with the information =
it gets back, it can only respond to the request for information that =
the client sends. If a client displays a URL to the user as a QR code, =
it=E2=80=99s probably not going to send a =E2=80=9Ccallback=E2=80=9D, =
for example. If an AS determines that it doesn=E2=80=99t want to support =
that =E2=80=9Cdecoupled=E2=80=9D mode for a given request, it can reject =
it for lack of a =E2=80=9Ccallback=E2=80=9D parameter. The reason for =
this decoupling 

And as I=E2=80=99=
m sure you saw in my editor=E2=80=99s note, I=E2=80=99m not convinced =
that the short_redirect is worth it as a separate option, even though =
the semantics are pretty clear here. As I said in the last discussion we =
had on this topic, I=E2=80=99ve implemented a QR code based on a full =
redirect URI and did not find it problematic. You made a compelling =
argument that the AS would potentially have different generation rules =
for short and long, and wouldn=E2=80=99t want to use a short one unless =
it needed to. It seemed to be a simple enough addition to put in this =
revision.


2.5.3 Open an Application-specific =
URL

What are =
you intending "app" to mean? I can think of a device where the client =
can open a URL, and a URL could not be associated with an application on =
the device. Are you thinking the client will do some detection if a =
specific app is available on the device? What if the app is not on the =
device? Most platforms don't provide any probing on what other apps are =
on a device, so there is no mechanism to detect if the app is present =
prior to launching. Is that what you are =
expecting?

You can detect if an app (any app) is going to =
handle a URL on some platforms. This mechanism not only lets an AS have =
different URLs for app launching and web-based interaction, and it lets =
the client optimize the experience instead of the awkward fall-through =
that we have with OAuth2=E2=80=99s app2app communication today. =
Furthermore, as I=E2=80=99m sure you saw in my editor=E2=80=99s note, =
there=E2=80=99s probably going to be additional pieces of information =
passed in this case. I=E2=80=99ve talked with a couple different groups =
who are using distributed storage mechanisms to communicate between =
components. In that case, this will probably have more information in it =
than a single URL, but I didn=E2=80=99t want to conjecture what that =
would look like, thus the note.


2.5.5. =
Receive an HTTP Direct Callback

What use cases require this =
functionality? Contrary to SecEvent, where both push and poll are =
specified because a receiver may not be able to have a public =
endpoint, the AS has a public endpoint for the client to call. In =
GNAP, the client can poll the AS. Why have both?


Why limit the client to only callbacks? The =
callback means =E2=80=9Cthere=E2=80=99s an HTTP endpoint that the =
user=E2=80=99s browser gets to=E2=80=9D whereas pushback means =
=E2=80=9Cthere=E2=80=99s an HTTP endpoint that the user=E2=80=99s =
browser can=E2=80=99t get to=E2=80=9D. Both are reasonable, and should =
be combinable with any of the options for getting a user to the AS, =
above. There are likely to be other options as well, since we already =
see them in the wild (CIBA=E2=80=99s push mode, for =
instance). 

 =E2=80=94 =
Justin

/Dick



On Sat, Jul 18, 2020 at 7:55 AM Justin Richer =
<jricher@mit.edu> wrote:
I really =
don=E2=80=99t see them as shifting towards each other so much as it is =
them adapting and changing based on ongoing efforts. As such I=E2=80=99ve =
modified XYZ not to make it =E2=80=9Clook more like XAuth=E2=80=9D, but =
rather to hopefully improve it in some measurable dimensions. So if you =
wonder why it doesn=E2=80=99t =E2=80=9Clook even more like XAuth=E2=80=9D =
it=E2=80=99s because I don=E2=80=99t think that such changes would be =
improvements =E2=80=94 in fact, even with recent improvements, I think =
there are a still a lot of issues with XAuth=E2=80=99s design and =
assumptions. XYZ can, I=E2=80=99m sure, also be improved.

The goal here isn=E2=80=99=
t to take two projects and make them look the same. The goal here is to =
make one protocol, GNAP, with the best ideas and elements engineered =
into it that we, as a working group, can. It=E2=80=99s not about =
one input proposal winning over another, it=E2=80=99s about improving =
our understanding of all the use cases and possible solutions and coming =
up with the best specification possible. Making things better should =
always be the goal. Progress should always be the goal. 

But we aren=E2=80=99t =
here to build XYZ or XAuth. We=E2=80=99re here to build GNAP and decide =
what GNAP looks like. XYZ=E2=80=99s structure and design is the best =
I=E2=80=99ve been able to make it so far, and it should be our goal as a =
WG to move past either XYZ or XAuth and build GNAP even better than any =
of that.

 =E2=80=94 Justin

On Jul =
17, 2020, at 6:46 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

XYZ is looking a lot more like =
XAuth, similar to how XAuth has shifted towards XYZ. 

I have implemented =
separate URIs for grants and authorizations, and it worked really =
well.

All 3 of =
the new capabilities are problematic. Perhaps you did not notice that =
there no longer is a short_uri in XAuth? As I recall, you were opposed =
to the short URI that was in the earlier drafts of XAuth. In my XAuth =
implementation, I show QR codes in the CLI app. Have you checked out my =
implementation? Have you implemented a QR code? I found that the string =
did not need to be nearly as short as it has in the =
past. 

I =
still don't understand the requirement to rotate the reference handle. I =
read over the pointer you provided last time we discussed it, and =
responded, but I have not heard back from you on that.


3D""=E1=90=A7

On Fri, Jul =
17, 2020 at 2:36 PM Justin Richer <jricher@mit.edu> wrote:
Most =
of these are changes I=E2=80=99ve wanted to do for quite some time and =
finally had opportunity to make the edits. As I said below, the core =
protocol really hasn=E2=80=99t changed in nature, but hopefully it=E2=80=99=
s easier to understand with it laid out in this way. 

All of these are points =
that I=E2=80=99ve made previously on the list in discussions, but to =
answer your questions directly:

- Mapping items to separate URLs has =
been on XYZ=E2=80=99s radar since well before it was proposed in Xauth, =
so this is bringing some of that into the concrete system. I still need =
to implement it to see how well it works in practice.

- The need to rotate the =
reference handle as well as use it externally (the =E2=80=9Cextend a =
request=E2=80=9D method) both call for having an identifier separate =
from the access URL. It also allows an AS more freedom in how it manages =
its endpoints, and aligns with the desire to push more information into =
the ongoing request after the initial phase. I=E2=80=99d actually rather =
the access token management move in that direction, using the token =
itself as the artifact, but I couldn=E2=80=99t do that and still use the =
DELETE method for revocation. So that=E2=80=99s an engineering challenge =
that I think the group should discuss, and decide whether it=E2=80=99s =
worth having the =E2=80=9CDELETE=E2=80=9D verb semantics and having that =
restriction placed on the AS as a consequence.

- The DID work is likely better suited =
for an extension, and always has been. But it was worth having in =
previous revisions for discussion purposes, especially as a point around =
how a non-HTTP interaction method would work. I expect to see DIDCOMM, =
CHAPI, WebAuthN, and other interaction methods in the extensions =
landscape of GNAP, usable alongside the others. 

And a final point, the =
interaction setup hasn=E2=80=99t really changed, so I=E2=80=99m curious =
to hear what you think has changed there. Even with a =
couple new capabilities on the way there (short_uri and app) and back =
(pushback), It=E2=80=99s structurally and conceptually identical to =
previous revisions.

 =E2=80=94 Justin
On Jul =
17, 2020, at 1:10 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey Justin,

Glad to see that you are =
aligning on having URIs for the access tokens and the =
"grant".

While =
the token URI is unique to the token, you have not done the same =
for a "grant", but have a handle and a non-unique URI.

Why not have a unique =
grant URI similar to the token URI? (a combination of the handle and a =
non-unique URI) -- this is then both the identifier, and the URL for =
"management"?

Glad to see you have excised the DID references. I don't =
think the common use cases are well established there =
currently.

I =
have LOTS of feedback on your interaction changes, that I'll post =
later on, and hope that others have feedback on those as well.

/Dick





On Thu, Jul 16, 2020 at 2:52 PM Justin =
Richer <jricher@mit.edu> wrote:
Hi all,

I=E2=80=99ve updated the =
XYZ draft specification. Since the publication tools are currently =
locked prior to the upcoming virtual meeting, I have published it online =
here:

https://oauth.xyz/draft-richer-transactional-authz

This represents a =
pretty significant refactoring of the specification, hopefully to make =
the concepts and capabilities easier to understand. The core protocol is =
largely the same as before, but there are a number of serious =
updates:

 -=
 Continuation requests happen at a URL returned in the TX response. The =
=E2=80=9Chandle=E2=80=9D is still sent as one of the input values here, =
since the handle can also be used it other contexts.
 - Tokens now can include the resources they are issued =
for
 - Tokens can have an optional management =
URI for rotation and revocation.
 - =
=E2=80=9Cclaims=E2=80=9D has been removed in favor of =E2=80=9Csubject=E2=80=
=9D dealing directly with identifiers and assertions
 - the =E2=80=9Cuser=E2=80=9D request and response now =
align with identifiers and assertions
 - =
Extensions and registries are more clearly enumerated throughout the =
document
 - DID-related items have been =
excised in deference to a future possible extension
 - Added a =E2=80=9Cpushback=E2=80=9D mechanism to =
complement the =E2=80=9Ccallback=E2=80=9D mechanism
 - Simplified dynamic handle returns and access tokens =
based on developer feedback (basically we dropped a bunch of =E2=80=9Cwhat=
 if=E2=80=9D stuff that nobody used or liked, like SHA3 hashes for =
bearer tokens)

I=E2=80=99ve also updated the interactive examples on https://oauth.xyz/ to match this new draft. =
Hopefully it=E2=80=99s consistent with the draft text.

I have not yet, however, =
updated any of the implementations of XYZ to take the elements of new =
syntax into account, so there might be some more changes prior to the =
IETF meeting as I realize what terrible mistakes I=E2=80=99ve made when =
doing that. :) 

Feedback, as always, is welcomed, and thanks to everyone =
who=E2=80=99s provided input to the project to date. 

 =E2=80=94 =
Justin
-- 

Txauth mailing list

Txauth@ietf.org

https://www.ietf.org/mailman/listinfo/txauth
=










=

--Apple-Mail=_6D68D8BE-6912-4F52-A866-F3B062BF8CE4--


From nobody Mon Jul 20 08:27: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 C0BCA3A0C4A for ; Mon, 20 Jul 2020 08:27:26 -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_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 MX1i5I3OE4fi for ; Mon, 20 Jul 2020 08:27:25 -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 DE5703A0C60 for ; Mon, 20 Jul 2020 08:27:24 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id a6so249687wmm.0 for ; Mon, 20 Jul 2020 08:27:24 -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=JWD3ECpeNGFrz69bGmpucA0TBqlm9CLHjl7lPe34Kwg=; b=PSATJM5Gq8ttW+98xUpQtGtOR8DrBFmx18VexUwC2Ho41M74YD2NHdRhQEP38IlkJY UcDS8YCTLNJO4dXx/gX1J6PA6qzeaVSxHJlG9BwlEg1jpf0vGwj+1a5HOupCVcVSAkKx pnu5CQLbR0qd4Fpz9Uy9R9umjK9jx8Y238uoU=
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=JWD3ECpeNGFrz69bGmpucA0TBqlm9CLHjl7lPe34Kwg=; b=YuvzNPV6Knb2KbLPd57hE86FFGfqBiy9ZKlEtDAlKjjAkXS8jZR5z310pBh1Wf2NqT XRhqYtUxBcPCuk2rA/Ih3xs/G3TbcSkwQN6F68E8v1IYthXMNJsNqmC2VX94DOFJN+6P e6mVlmmBMYGWFiOt3p1Vh9RDJv8upsyQ/N2Sb4RE2KBWK7G/h8q+O+ZurlGYC2guFcdu IsNrt0cLsG5svHtuiKhGFFd7ZNXUKh73Ay2MX5Q2z2fDwK5msihato0wVYulQ0v4p3zP j2BuA58O2Op/I5Z3X02oPfMEMfJc1OilGiLCX2Uj2GUWMUzUS3Q0s4+WToYPNmMKj4oo zNDg==
X-Gm-Message-State: AOAM532nVkjTjQVkYzgEysJMOCarB0rZO3KtFeNS/laSsRSacaMof3Gf 2dFuvGNfGOvPgZobNYWiI24PiVgAYwjY7Es5Fh6WZIfeCZc=
X-Google-Smtp-Source: ABdhPJy0DXZnbHBBPvHIv4uTLFJ1sAe1bSXguevqUJm8tBxvDDiyLpGFeUhWO5bbu7oQFYJSZs5csE9ELrPY7nxEe/U=
X-Received: by 2002:a1c:6289:: with SMTP id w131mr20934186wmb.64.1595258843207;  Mon, 20 Jul 2020 08:27:23 -0700 (PDT)
MIME-Version: 1.0
References:               
In-Reply-To: 
From: Francis Pouatcha 
Date: Mon, 20 Jul 2020 11:27:12 -0400
Message-ID: 
To: Denis 
Cc: Dick Hardt , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000acaf1205aae124bc"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 20 Jul 2020 15:27:31 -0000

--000000000000acaf1205aae124bc
Content-Type: text/plain; charset="UTF-8"

Hello Denis,

On Mon, Jul 20, 2020 at 5:04 AM Denis  wrote:

> Hi Dick,
>
> On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:
>
>> Hello Francis and Dick,
>>
>> The good news first: we are making some progress. We are now close to an
>> agreement with steps (1) up to (3),
>> ... except that the place where the user consent is captured is not
>> mentioned/indicated.
>>
>
> This major question which is currently left unanswered is where, when and
> how the user consent is captured.
>
> Another important point to consider and to explain is related to the
> assurances that the user can obtain about
> the respect of his choices. This point is currently left unanswered in
> draft-hardt-xauth-protocol-13.
>
>
>> If a RO needs to be involved and since a RO is directly associated with a
>> RS, why can't it be directly queried
>> by the appropriate RS after step (2) or later on ?
>>
>
> Good question. Perhaps you can expand on a use case where that would be
> useful?
>
> Before I expand, would you be able to explain first under which
> circumstances a RO needs to be queried by a GS ?
>
In all circumstances. Can you name a situation where this is not the case?

> How can the GS identify which RO to query ?
>
There is supposed to be a preexisting relationship between GS and RO, If
not RO will have to register with GS in the first interaction (onboarding).

How can the GS identify how to connect with RO?
GS must evaluate the RS provided info in step (3)
AuthZRequest(AuthZChallenge) to decide how to contact the RO. This is where
selection of interaction mode takes place.

>
>
>> Which information is supposed to be presented to the RO ?
>> Which information is supposed to be returned by the RO ?
>>
>
> Just like how the user authenticates to an AS, how the AS and RO
> communicate is out of scope.
>
> At the moment, the usefulness of a dialogue between a GS and a RO has not
> been explained, nor demonstrated.
> The question is about the functionality of that dialogue in terms of input
> and output information (and not about
> the design of a protocol or of a user interface). Anyway, AFAIU a dialogue
> between a GS and a RO is optional.
>
> For many use cases, the User is the RO, and the interaction is through a
> user interface, not a machine protocol.
>
> Wait a second. You wrote "the User is the RO". The User is attempting to
> make an access to a RS by using a Client.
> *That* User is not the RO of the RS.
>
> The User interacts with the Client.
The RO interacts with the GS.

In some use cases (where we use redirect interaction) we assume the person
controlling the "User-Agent" is also the person controlling the "RO-Agent"
and they reside on the same device. These are cases where we say User
equals RO.
-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--000000000000acaf1205aae124bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Denis,

On Mon, Jul 20, 2020 at 5:04 =
AM Denis <denis.ietf@free.fr&g=
t; wrote:

 =20
   =20
 =20
  

    
Hi Dick,

    


    

    

     =20
      
On Fri, Jul 17, 2020 at 9:21 AM Denis <denis.ietf@free.fr>
        wrote:

        

          

            

              
Hello Francis and Dick,

              


              

              
The good news first: we are making some progress. We
                are now close to an agreement with steps (1) up to (3),
                

                ... except that the place where the user consent is
                captured is not mentioned/indicated.

            

          

        

      

    

    

    This major question which is currently left unanswered is where,
    when and how the user consent is captured.

    

    Another important point to consider and to explain is related to the
    assurances that the user can obtain about 

    the respect of his choices. This point is currently left unanswered
    in draft-hardt-xauth-protocol-13.

    

    

      

        

          

            

              


              

              
If a RO needs to be involved and since a RO is
                directly associated with a RS, why can't it be directly
                queried 

                by the appropriate RS after step (2) or later on ?

            

          

          


          

          
Good question. Perhaps you can expand on a use case where
            that would be useful?

        

      

    

    
Before I expand, would you be able to explain first under which
      circumstances a RO needs to be queried by a GS ?
In all circumstances. Can you name a situation where this is not=
 the case?

      How can the GS identify which RO to query ?
There is supposed to be a preexisting relationship between=
 GS and RO, If not RO will have to register with GS in the first interactio=
n (onboarding).

How can the GS identify how to con=
nect with RO?
GS must evaluate the RS provided info in=C2=A0step =
(3) AuthZRequest(AuthZChallenge) to decide how to contact the RO. This is w=
here selection of interaction mode=C2=A0takes place.

    

    

      

        

          
=C2=A0

          

            

              
Which information is supposed to be presented to the
                RO ?

                Which information is supposed to be returned by the RO ?
            

          

          


          

          
Just like how the user authenticates to an AS, how the AS
            and RO communicate is out of scope.

          

        

      

    

    
At the moment, the usefulness of a dialogue between a GS and a RO
      has not been explained, nor demonstrated.

      The question is about the functionality of that dialogue in terms
      of input and output information (and not about 

      the design of a protocol or of a user interface). Anyway, AFAIU a
      dialogue between a GS and a RO is optional.

    

    

      

        

          
For many use cases, the User is the RO, and the
            interaction is through a user interface, not a machine
            protocol. 

          

        

      

    

    
Wait a second. You wrote "the User is the RO". The User is
      attempting to make an access to a RS by using a Client. 

      That User is not the RO of the RS.=C2=A0=C2=A0 

      
The User interacts with the Client.
The RO interacts with the GS.

In some use=
 cases (where we use redirect interaction) we assume the person controlling=
 the "User-Agent" is also the person controlling the "RO-Age=
nt" and they reside on the same device. These are cases where we say U=
ser equals RO.
-- 
Francis Pouatcha
Co-Founder and Technical Lead=

adorsys GmbH & Co. KG


--000000000000acaf1205aae124bc--


From nobody Mon Jul 20 10:13: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 D3AEF3A0DD4 for ; Mon, 20 Jul 2020 10:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.63
X-Spam-Level: 
X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, 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 LZaOOaOI1Pq2 for ; Mon, 20 Jul 2020 10:12:54 -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 9EC5F3A0D86 for ; Mon, 20 Jul 2020 10:12:53 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d34 with ME id 5VCo2300V2bcEcA03VCpsl; Mon, 20 Jul 2020 19:12:51 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 20 Jul 2020 19:12:51 +0200
X-ME-IP: 90.79.51.120
To: Francis Pouatcha 
Cc: Dick Hardt , txauth@ietf.org
References:               
From: Denis 
Message-ID: <8b08ff35-f1d5-ee65-c89a-c1f3191ae5b6@free.fr>
Date: Mon, 20 Jul 2020 19:12:47 +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="------------32A6C22C8E31A7C4E58A1C6D"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 20 Jul 2020 17:13:03 -0000

This is a multi-part message in MIME format.
--------------32A6C22C8E31A7C4E58A1C6D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello  Francis,

> Hello Denis,
>
> On Mon, Jul 20, 2020 at 5:04 AM Denis  > wrote:
>
>     Hi Dick,
>
>>     On Fri, Jul 17, 2020 at 9:21 AM Denis >     > wrote:
>>
>>         Hello Francis and Dick,
>>
>>         The good news first: we are making some progress. We are now
>>         close to an agreement with steps (1) up to (3),
>>         ... except that the place where the user consent is captured
>>         is not mentioned/indicated.
>>
>
>     This major question which is currently left unanswered is where,
>     when and how the user consent is captured.
>
>     Another important point to consider and to explain is related to
>     the assurances that the user can obtain about
>     the respect of his choices. This point is currently left
>     unanswered in draft-hardt-xauth-protocol-13.
>
[Denis] These two major points are still left unanswered at this time.

>
>>
>>         If a RO needs to be involved and since a RO is directly
>>         associated with a RS, why can't it be directly queried
>>         by the appropriate RS after step (2) or later on ?
>>
>>
>>     Good question. Perhaps you can expand on a use case where that
>>     would be useful?
>
>     Before I expand, would you be able to explain first under which
>     circumstances a RO needs to be queried by a GS ?
>
> In all circumstances. Can you name a situation where this is not the case?

[Denis] This is quite easy. The final decision is always taken by the 
RS. If a Client presents access tokens issued by ASs trusted by the RS
that contain appropriate attributes to perform the requested operation, 
then the operation is allowed.

If really a human RO needs to be involved for whatever reason, it is 
possible to get its involvement when the Client connects to the RS.
However such involvement does not need to be formalized by a protocol. 
It can be application specific.

>     How can the GS identify which RO to query ?
>
> There is supposed to be a preexisting relationship between GS and RO, 
> If not RO will have to register with GS in the first interaction 
> (onboarding).
>
> How can the GS identify how to connect with RO?
> GS must evaluate the RS provided info in step (3) 
> AuthZRequest(AuthZChallenge) to decide how to contact the RO. This is 
> where selection of interaction mode takes place.

[Denis] This means that a GS must have prior relationships with the RSs 
and ROs. While this should not be prevented for backward compatibility 
with OAuth 2.0,
this should not be the single case. Prior relationships between ROs and 
GSs is a door half-opened for Big Brother. If in addition the GS is able 
to know which operation
is attempted by the client on which RSs, then it is a door wide-opened 
for Big Brother.

>>         Which information is supposed to be presented to the RO ?
>>         Which information is supposed to be returned by the RO ?
>>
>>
>>     Just like how the user authenticates to an AS, how the AS and RO
>>     communicate is out of scope.
>
>     At the moment, the usefulness of a dialogue between a GS and a RO
>     has not been explained, nor demonstrated.
>     The question is about the functionality of that dialogue in terms
>     of input and output information (and not about
>     the design of a protocol or of a user interface). Anyway, AFAIU a
>     dialogue between a GS and a RO is optional.
>
>>     For many use cases, the User is the RO, and the interaction is
>>     through a user interface, not a machine protocol.
>
>     Wait a second. You wrote "the User is the RO". The User is
>     attempting to make an access to a RS by using a Client.
>     _That_ User is not the RO of the RS.
>
> The User interacts with the Client.
> The RO interacts with the GS.
>
> In some use cases (where we use redirect interaction) we assume the 
> person controlling the "User-Agent" is also the person
> controlling the "RO-Agent" and they reside on the same device. These 
> are cases where we say User equals RO.

[Denis] Sorry, I have difficulties to understand such a case. A person 
giving his consent to himself ?

Denis

> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/



--------------32A6C22C8E31A7C4E58A1C6D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello  Francis,

    


    

    

      
      

        
Hello Denis,

        

        

          
On Mon, Jul 20, 2020 at 5:04
            AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              
Hi Dick,

              


              

              

                
On Fri, Jul 17, 2020 at 9:21 AM Denis
                  <denis.ietf@free.fr>
                  wrote:

                  

                    

                      

                        
Hello Francis and Dick,

                        


                        

                        
The good news first: we are making some
                          progress. We are now close to an agreement
                          with steps (1) up to (3), 

                          ... except that the place where the user
                          consent is captured is not
                          mentioned/indicated.

                      

                    

                  

                

              

              

              This major question which is currently left unanswered is
              where, when and how the user consent is captured.

              

              Another important point to consider and to explain is
              related to the assurances that the user can obtain about 

              the respect of his choices. This point is currently left
              unanswered in draft-hardt-xauth-protocol-13.

            

          

        

      

    

    
[Denis] These two major points are still left unanswered at this
      time.

    

      

        

          

            
 

              

                

                  

                    

                      

                        


                        

                        
If a RO needs to be involved and since a RO
                          is directly associated with a RS, why can't it
                          be directly queried 

                          by the appropriate RS after step (2) or later
                          on ?

                      

                    

                    


                    

                    
Good question. Perhaps you can expand on a use
                      case where that would be useful?

                  

                

              

              
Before I expand, would you be able to explain first
                under which circumstances a RO needs to be queried by a
                GS ?

              

            

          

          
In all circumstances. Can you name a situation where this
            is not the case?

        

      

    

    
[Denis] This is quite easy. The final decision is always taken by
      the RS. If a Client presents access tokens issued by ASs trusted
      by the RS 

      that contain appropriate attributes to perform the requested
      operation, then the operation is allowed.  

    

    
If really a human RO needs to be involved for whatever reason, it
      is possible to get its involvement when the Client connects to the
      RS. 

      However such involvement does not need to be formalized by a
      protocol. It can be application specific.

    

    

      

        

          

            

              
 How can the GS identify which RO to query ?

              

            

          

          
There is supposed to be a preexisting relationship
            between GS and RO, If not RO will have to register with GS
            in the first interaction (onboarding).

          


          

          
How can the GS identify how to connect with RO?

          
GS must evaluate the RS provided info in step (3)
            AuthZRequest(AuthZChallenge) to decide how to contact the
            RO. This is where selection of interaction mode takes place.

          

        

      

    

    
[Denis] This means that a GS must have prior relationships with
      the RSs and ROs. While this should not be prevented for backward
      compatibility with OAuth 2.0, 

      this should not be the single case. Prior relationships between
      ROs and GSs is a door half-opened for Big Brother. If in addition
      the GS is able to know which operation 

      is attempted by the client on which RSs, then it is a door
      wide-opened for Big Brother.

    

      

        

          

            

              

                

                  

                    
 

                    

                      

                        
Which information is supposed to be
                          presented to the RO ?

                          Which information is supposed to be returned
                          by the RO ?

                      

                    

                    


                    

                    
Just like how the user authenticates to an AS,
                      how the AS and RO communicate is out of scope.

                    

                  

                

              

              
At the moment, the usefulness of a dialogue between a
                GS and a RO has not been explained, nor demonstrated.

                The question is about the functionality of that dialogue
                in terms of input and output information (and not about
                

                the design of a protocol or of a user interface).
                Anyway, AFAIU a dialogue between a GS and a RO is
                optional.

              

              

                

                  

                    
For many use cases, the User is the RO, and the
                      interaction is through a user interface, not a
                      machine protocol. 

                    

                  

                

              

              
Wait a second. You wrote "the User is the RO". The User
                is attempting to make an access to a RS by using a
                Client. 

                That User is not the RO of the RS.   

                

              

            

          

          
The User interacts with the Client.

          
The RO interacts with the GS.

          


          

          
In some use cases (where we use redirect interaction) we
            assume the person controlling the "User-Agent" is also the
            person 

            controlling the "RO-Agent" and they reside on the same
            device. These are cases where we say User equals RO.

        

      

    

    
[Denis] Sorry, I have difficulties to understand such a case. A
      person giving his consent to himself ?

    
Denis

    

      
-- 

        

          

            

              

                

                  

                    

                      

                        

                          
Francis Pouatcha

                          
Co-Founder and Technical Lead

                          
adorsys GmbH & Co. KG

                          
                        

                      

                    

                  

                

              

            

          

        

      

    

    


    

  


--------------32A6C22C8E31A7C4E58A1C6D--


From nobody Mon Jul 20 10:27: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 677903A0D77 for ; Mon, 20 Jul 2020 10:27:30 -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 HbovL4qg0iKc for ; Mon, 20 Jul 2020 10:27:28 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 6FFFA3A0D76 for ; Mon, 20 Jul 2020 10:27:28 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id 5so12783778oty.11 for ; Mon, 20 Jul 2020 10:27: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=p1woeKbBI8SNoM3Uj51JJrkv9Z+rJ7LTvQ+LL/9jNvY=; b=dYkA9ml2umN0nm64wQe/6w5iyqUl9yDJvjvCZpPw+CmosAZ3lC/cG9ExL7uUn5FdOw 1p560o2Nw7gcIhdC65xscLAkX+ldt2w9BRK6mbU4/lrwL5Vc3HZyMpA/RQSC3T+89Y4O L3b7uTgR3WPGVDz/vfj2rkM3QcVCCuZ1ym3ArIpPk/0Gv5OwzfiOFs6sxo03KjzaIdMI xQpeZ8RunbxRBEdDRZtsm/M11rrjGl8eAVgZAhORtgGmOtLv4lypA6m365Ry5GqEmtaR Pe0VmtnSWKkjK2DnC5GPUfrTMuA3WU0swB1P5YkhRxCOa9pc6S+ipLUCxTtSOXCQndlL 1Hqw==
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=p1woeKbBI8SNoM3Uj51JJrkv9Z+rJ7LTvQ+LL/9jNvY=; b=RvZ66R4IziutYaeevD1HfGMv9ScAQRDqg8hEKL2SfDRMpBDpBAoE84F1WwCVOMgJoq 8Y5Q6UbAtwmagKhJfguHl5uTW6QGRZWT1WJlU/MkgJ5YXU4DDJtg2F+lT8MrxAN6wB8I 0tFUoRJcZbrXTPI50B/NHIuouTf/9/K/u0PQQWffQdPJeBsj1MjdpZaKKpX/GlDQAyna 0iDejzfv9/1DEvKIL332SXKGsVlWw7DngLrYsyO2P26tUdjSbtbU64OOOK+ogT14Oq5U vwLoI2YmQb2ikWHNe/Sa/KYW7v069ByyIcw+bPtf8kKd4GegCUOIyqFDzWlZuVhMRU9w NBTA==
X-Gm-Message-State: AOAM5314PCyQxZQWiscP5bP/W26KrZAxbFTT9p5NxIncl2vTOPT21EKr Qpwxfo6TyXBXvQdpCi8FrkRvIB4ihynhmT5eTzs=
X-Google-Smtp-Source: ABdhPJy87m7v9HoXWk+owbISCkCNdwipxgcVNGsnLI/S8iIwYcntO/hlTja4hTupLbE2LzKJg7uOqzLDVHBYSA4E66M=
X-Received: by 2002:a9d:a03:: with SMTP id 3mr5588322otg.87.1595266047585; Mon, 20 Jul 2020 10:27:27 -0700 (PDT)
MIME-Version: 1.0
References:                <8b08ff35-f1d5-ee65-c89a-c1f3191ae5b6@free.fr>
In-Reply-To: <8b08ff35-f1d5-ee65-c89a-c1f3191ae5b6@free.fr>
From: Tom Jones 
Date: Mon, 20 Jul 2020 10:27:16 -0700
Message-ID: 
To: Denis 
Cc: Francis Pouatcha , txauth@ietf.org, Dick Hardt 
Content-Type: multipart/alternative; boundary="00000000000016b2e005aae2d216"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 20 Jul 2020 17:27:30 -0000

--00000000000016b2e005aae2d216
Content-Type: text/plain; charset="UTF-8"

This interchange exhibits an essential problem of most of this work. The
idea that humans populate the web. I have yet to see a human with an
ethernet connection. So i must assume that the user agent is the essence of
the human on the web.

Second there are two terms which need to be distinct in the general case -
at least where the RO is a human and the resource contains PII.
The RO aka subject is the identifier that is used by a real world human
that has data on the web that is (inter alia) PII about them.
The user aka guardian (and often also the subject) is the identifier that
is used by a real world human that has acquired control of access to the
PII about the subject.

Peace ..tom


On Mon, Jul 20, 2020 at 10:13 AM Denis  wrote:

> Hello  Francis,
>
> Hello Denis,
>
> On Mon, Jul 20, 2020 at 5:04 AM Denis  wrote:
>
>> Hi Dick,
>>
>> On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:
>>
>>> Hello Francis and Dick,
>>>
>>> The good news first: we are making some progress. We are now close to an
>>> agreement with steps (1) up to (3),
>>> ... except that the place where the user consent is captured is not
>>> mentioned/indicated.
>>>
>>
>> This major question which is currently left unanswered is where, when and
>> how the user consent is captured.
>>
>> Another important point to consider and to explain is related to the
>> assurances that the user can obtain about
>> the respect of his choices. This point is currently left unanswered in
>> draft-hardt-xauth-protocol-13.
>>
> [Denis] These two major points are still left unanswered at this time.
>
>
>>
>>> If a RO needs to be involved and since a RO is directly associated with
>>> a RS, why can't it be directly queried
>>> by the appropriate RS after step (2) or later on ?
>>>
>>
>> Good question. Perhaps you can expand on a use case where that would be
>> useful?
>>
>> Before I expand, would you be able to explain first under which
>> circumstances a RO needs to be queried by a GS ?
>>
> In all circumstances. Can you name a situation where this is not the case?
>
> [Denis] This is quite easy. The final decision is always taken by the RS.
> If a Client presents access tokens issued by ASs trusted by the RS
> that contain appropriate attributes to perform the requested operation,
> then the operation is allowed.
>
> If really a human RO needs to be involved for whatever reason, it is
> possible to get its involvement when the Client connects to the RS.
> However such involvement does not need to be formalized by a protocol. It
> can be application specific.
>
> How can the GS identify which RO to query ?
>>
> There is supposed to be a preexisting relationship between GS and RO, If
> not RO will have to register with GS in the first interaction (onboarding).
>
> How can the GS identify how to connect with RO?
> GS must evaluate the RS provided info in step (3)
> AuthZRequest(AuthZChallenge) to decide how to contact the RO. This is where
> selection of interaction mode takes place.
>
> [Denis] This means that a GS must have prior relationships with the RSs
> and ROs. While this should not be prevented for backward compatibility with
> OAuth 2.0,
> this should not be the single case. Prior relationships between ROs and
> GSs is a door half-opened for Big Brother. If in addition the GS is able to
> know which operation
> is attempted by the client on which RSs, then it is a door wide-opened for
> Big Brother.
>
>
>>
>>> Which information is supposed to be presented to the RO ?
>>> Which information is supposed to be returned by the RO ?
>>>
>>
>> Just like how the user authenticates to an AS, how the AS and RO
>> communicate is out of scope.
>>
>> At the moment, the usefulness of a dialogue between a GS and a RO has not
>> been explained, nor demonstrated.
>> The question is about the functionality of that dialogue in terms of
>> input and output information (and not about
>> the design of a protocol or of a user interface). Anyway, AFAIU a
>> dialogue between a GS and a RO is optional.
>>
>> For many use cases, the User is the RO, and the interaction is through a
>> user interface, not a machine protocol.
>>
>> Wait a second. You wrote "the User is the RO". The User is attempting to
>> make an access to a RS by using a Client.
>> *That* User is not the RO of the RS.
>>
>> The User interacts with the Client.
> The RO interacts with the GS.
>
> In some use cases (where we use redirect interaction) we assume the person
> controlling the "User-Agent" is also the person
> controlling the "RO-Agent" and they reside on the same device. These are
> cases where we say User equals RO.
>
> [Denis] Sorry, I have difficulties to understand such a case. A person
> giving his consent to himself ?
>
> 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
>

--00000000000016b2e005aae2d216
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


This interchange exhibits an essential problem=C2=A0of mos=
t of this work. The idea that humans populate the web. I have yet to see a =
human with an ethernet connection. So i must assume that the user agent is =
the essence of the human on the web.

Second there are tw=
o terms which need to be distinct in the general case - at least where the =
RO is a human and the resource contains PII.
The RO aka subject i=
s the identifier that is used by a real world human that has data on the we=
b that is (inter alia) PII about them.
The user aka guardian (and=
 often also the subject) is the identifier that is used by a real world hum=
an that has acquired control of access to the PII about the subject.
<=
div>
Peace ..tom
=



On Mon, Jul 20, 2020 at 10:13 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hello=C2=A0 Francis,

    


    

    

     =20
      

        
Hello Denis,

        

        

          
On Mon, Jul 20, 2020 at 5:0=
4
            AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              
Hi Dick,

              


              

              

                
On Fri, Jul 17, 2020 at 9:21 AM Denis
                  <denis.ietf@free.fr>
                  wrote:

                  

                    

                      

                        
Hello Francis and Dick,

                        


                        

                        
The good news first: we are making some
                          progress. We are now close to an agreement
                          with steps (1) up to (3), 

                          ... except that the place where the user
                          consent is captured is not
                          mentioned/indicated.

                      

                    

                  

                

              

              

              This major question which is currently left unanswered is
              where, when and how the user consent is captured.

              

              Another important point to consider and to explain is
              related to the assurances that the user can obtain about 

              the respect of his choices. This point is currently left
              unanswered in draft-hardt-xauth-protocol-13.

            

          

        

      

    

    
[Denis] These two major points are still left unanswered at this
      time.

    

      

        

          

            
 

              

                

                  

                    

                      

                        


                        

                        
If a RO needs to be involved and since a RO
                          is directly associated with a RS, why can't i=
t
                          be directly queried 

                          by the appropriate RS after step (2) or later
                          on ?

                      

                    

                    


                    

                    
Good question. Perhaps you can expand on a use
                      case where that would be useful?

                  

                

              

              
Before I expand, would you be able to explain first
                under which circumstances a RO needs to be queried by a
                GS ?

              

            

          

          
In all circumstances. Can you name a situation where this
            is not the case?

        

      

    

    
[Denis] This is quite easy. The final decision is always taken by
      the RS. If a Client presents access tokens issued by ASs trusted
      by the RS 

      that contain appropriate attributes to perform the requested
      operation, then the operation is allowed.=C2=A0 

    

    
If really a human RO needs to be involved for whatever reason, it
      is possible to get its involvement when the Client connects to the
      RS. 

      However such involvement does not need to be formalized by a
      protocol. It can be application specific.

    

    

      

        

          

            

              
 How can the GS identify which RO to query ?

              

            

          

          
There is supposed to be a preexisting relationship
            between GS and RO, If not RO will have to register with GS
            in the first interaction (onboarding).

          


          

          
How can the GS identify how to connect with RO?

          
GS must evaluate the RS provided info in=C2=A0step (3)
            AuthZRequest(AuthZChallenge) to decide how to contact the
            RO. This is where selection of interaction mode=C2=A0takes plac=
e.

          

        

      

    

    
[Denis] This means that a GS must have prior relationships with
      the RSs and ROs. While this should not be prevented for backward
      compatibility with OAuth 2.0, 

      this should not be the single case. Prior relationships between
      ROs and GSs is a door half-opened for Big Brother. If in addition
      the GS is able to know which operation 

      is attempted by the client on which RSs, then it is a door
      wide-opened for Big Brother.

    

      

        

          

            

              

                

                  

                    
=C2=A0

                    

                      

                        
Which information is supposed to be
                          presented to the RO ?

                          Which information is supposed to be returned
                          by the RO ?

                      

                    

                    


                    

                    
Just like how the user authenticates to an AS,
                      how the AS and RO communicate is out of scope.

                    

                  

                

              

              
At the moment, the usefulness of a dialogue between a
                GS and a RO has not been explained, nor demonstrated.

                The question is about the functionality of that dialogue
                in terms of input and output information (and not about
                

                the design of a protocol or of a user interface).
                Anyway, AFAIU a dialogue between a GS and a RO is
                optional.

              

              

                

                  

                    
For many use cases, the User is the RO, and the
                      interaction is through a user interface, not a
                      machine protocol. 

                    

                  

                

              

              
Wait a second. You wrote "the User is the RO". T=
he User
                is attempting to make an access to a RS by using a
                Client. 

                That User is not the RO of the RS.=C2=A0=C2=A0 

                

              

            

          

          
The User interacts with the Client.

          
The RO interacts with the GS.

          


          

          
In some use cases (where we use redirect interaction) we
            assume the person controlling the "User-Agent" is als=
o the
            person 

            controlling the "RO-Agent" and they reside on the sam=
e
            device. These are cases where we say User equals RO.

        

      

    

    
[Denis] Sorry, I have difficulties to understand such a case. A
      person giving his consent to himself ?

    
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




--00000000000016b2e005aae2d216--


From nobody Mon Jul 20 11:47: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 468B23A0DD3 for ; Mon, 20 Jul 2020 11:47:03 -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 EAEDciMzdDkV for ; Mon, 20 Jul 2020 11:47: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 BF9363A0DD2 for ; Mon, 20 Jul 2020 11:47:00 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id g10so581647wmc.1 for ; Mon, 20 Jul 2020 11:47: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=5jfFoyLhcDmXKeZP3fxdEJA3HJPW0xewBNLBF7b8lNY=; b=gBC1Kc+0hs5hA17NV/Yk6gZBNn6Lyx4DV5OaTaCwNHGOfhW2eZ5039SnqCbBLpfVkt gVy8UeaP7E2IylqbVAm8w/Mk49iZ/LJOcIX0v/v7/cpo4Sgb7uelgp+/9tQNgcE/5K0k Ejtdo1WdEusT1Lcajz6C4G9v9I7TLZFDXNrDg=
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=5jfFoyLhcDmXKeZP3fxdEJA3HJPW0xewBNLBF7b8lNY=; b=aeg7561fmQrL8QIBSpQ2FjiLEWWM/dF6FBic+/XIX08uS/pgrfVSLEWzQe4wwP5cVT lINDrIWzCPKr93XJERdflWRhrfhY1JPR44sp2424bvbdPWks5KlWVqgTuRdUOZ3KXviO Rvpg7oHu3y92w4k7IcQCKm5q6XTo84+At8MV6cYFQ8T2Uc/BEmMBefg8hkQsjzyd9WzU 0DtsfbP0dYj/JoDDWJlnByOQXpj+5TucMELqRnaPRJONYo1tEjRDrO+16IR1pyC/9RKK cpAzpeaY4k2LRH5nIXOKs38mwg39Ywu1sESR51/P5cThhocb97hy4PLEsgtlLfkg0TOy sk/Q==
X-Gm-Message-State: AOAM532TRNceXKKuUyXpHDR63U/xk/TxKrZnFhGPAlXZp5x6IlYG3Yza uCX/oloOfQEJGBrb0ytUlZCEigcqHHUqu4eS+7oa9w==
X-Google-Smtp-Source: ABdhPJzXqTHw1+0Jq6AG/wbTyMAlt/JH0fp7sIgD/cPtgJAxSNKP79LFZovVlef0I3p98AOJL7osESimm91Lo/58ueY=
X-Received: by 2002:a05:600c:294a:: with SMTP id n10mr597573wmd.38.1595270819126;  Mon, 20 Jul 2020 11:46:59 -0700 (PDT)
MIME-Version: 1.0
References:                <8b08ff35-f1d5-ee65-c89a-c1f3191ae5b6@free.fr>
In-Reply-To: <8b08ff35-f1d5-ee65-c89a-c1f3191ae5b6@free.fr>
From: Francis Pouatcha 
Date: Mon, 20 Jul 2020 14:46:48 -0400
Message-ID: 
To: Denis 
Cc: Dick Hardt , txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000007eb6c705aae3ee98"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 20 Jul 2020 18:47:03 -0000

--0000000000007eb6c705aae3ee98
Content-Type: text/plain; charset="UTF-8"

Hello Denis,


>>> The good news first: we are making some progress. We are now close to an
>>> agreement with steps (1) up to (3),
>>> ... except that the place where the user consent is captured is not
>>> mentioned/indicated.
>>>
>>
>> This major question which is currently left unanswered is where, when and
>> how the user consent is captured.
>>
> There is nothing like a User consent. It is essential for further
discussions to use the correct keywords.

Clarification 1: User vs. RO
1. User interacts with Client
2. RO interacts with GS

Clarification 2: Consent vs. AuthZ (Authorization)
1. Consent is given by RO to GS and used to produce an Authz.
2. AuthZ is given by GS to Client and used by Client to access Resource at
RS interface on behalf of User.

Modified Question: where, when and how the "RO" Consent is captured?

Answer:
how: Consent is given by the RO to the GS.
where: Depend of interaction mode.
when: before step (5).

>
>> Another important point to consider and to explain is related to the
>> assurances that the user can obtain about
>> the respect of his choices. This point is currently left unanswered in
>> draft-hardt-xauth-protocol-13.
>>
> [Denis] These two major points are still left unanswered at this time.
>
I do not understand the question.

>
>>
>>> If a RO needs to be involved and since a RO is directly associated with
>>> a RS, why can't it be directly queried
>>> by the appropriate RS after step (2) or later on ?
>>>
>>
>> Good question. Perhaps you can expand on a use case where that would be
>> useful?
>>
>> Before I expand, would you be able to explain first under which
>> circumstances a RO needs to be queried by a GS ?
>>
> In all circumstances. Can you name a situation where this is not the case?
>
> [Denis] This is quite easy. The final decision is always taken by the RS.
> If a Client presents access tokens issued by ASs trusted by the RS
> that contain appropriate attributes to perform the requested operation,
> then the operation is allowed.
>
We should be using GS instead of AS to avoid confusion.

> If really a human RO needs to be involved for whatever reason, it is
> possible to get its involvement when the Client connects to the RS.
> However such involvement does not need to be formalized by a protocol. It
> can be application specific.
>
Client has no Relationship with the RO.

There is no reference to a human here. User, Client, RS, GS, RO are all
roles. Nothing states the type of participants they are.

> How can the GS identify which RO to query ?
>>
> There is supposed to be a preexisting relationship between GS and RO, If
> not RO will have to register with GS in the first interaction (onboarding).
>
> How can the GS identify how to connect with RO?
> GS must evaluate the RS provided info in step (3)
> AuthZRequest(AuthZChallenge) to decide how to contact the RO. This is where
> selection of interaction mode takes place.
>
> [Denis] This means that a GS must have prior relationships with the RSs
> and ROs.
>
No. Evaluating an AuthZChallenge to discover the RO:
- does not assume GS knows RS.
- does not presume RS knows GS.

But:
- GS will generally have to know RO, as RO delegates the work to produce
authorizations on his behalf to GS.
- RS will generally have to know RO, as RO custodies his Resources with RS
and trusts RS to only release it to authorized parties.

How do you establish a contract without contracting parties knowing each
other?

> While this should not be prevented for backward compatibility with OAuth
> 2.0,
> this should not be the single case. Prior relationships between ROs and
> GSs is a door half-opened for Big Brother. If in addition the GS is able to
> know which operation
> is attempted by the client on which RSs, then it is a door wide-opened for
> Big Brother.
>
I do not understand this. GS is working for RO.

>
>>
>>> Which information is supposed to be presented to the RO ?
>>> Which information is supposed to be returned by the RO ?
>>>
>>
>> Just like how the user authenticates to an AS, how the AS and RO
>> communicate is out of scope.
>>
>> At the moment, the usefulness of a dialogue between a GS and a RO has not
>> been explained, nor demonstrated.
>> The question is about the functionality of that dialogue in terms of
>> input and output information (and not about
>> the design of a protocol or of a user interface). Anyway, AFAIU a
>> dialogue between a GS and a RO is optional.
>>
>> For many use cases, the User is the RO, and the interaction is through a
>> user interface, not a machine protocol.
>>
>> Wait a second. You wrote "the User is the RO". The User is attempting to
>> make an access to a RS by using a Client.
>> *That* User is not the RO of the RS.
>>
>> The User interacts with the Client.
> The RO interacts with the GS.
>
> In some use cases (where we use redirect interaction) we assume the person
> controlling the "User-Agent" is also the person
> controlling the "RO-Agent" and they reside on the same device. These are
> cases where we say User equals RO.
>
> [Denis] Sorry, I have difficulties to understand such a case. A person
> giving his consent to himself ?
>
We do not have people here, but roles.
RO is consenting
  - that the Client can access his Resource
  - on behalf of the User [optional].

So RO and User are different roles, even if they are sometimes assumed by
the same human/device/machine/...

>
>
-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--0000000000007eb6c705aae3ee98
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello=C2=A0Denis,



                        
The good news first: we are making some
                          progress. We are now close to an agreement
                          with steps (1) up to (3), 

                          ... except that the place where the user
                          consent is captured is not
                          mentioned/indicated.

                      

                    

                  

                

              

              

              This major question which is currently left unanswered is
              where, when and how the user consent is captured.
There is nothin=
g like a User consent. It is essential for further discussions to use the c=
orrect keywords.

Clarification 1: User vs. RO
1. User interacts with Client=C2=A0
2. RO interacts wi=
th GS

Clarification 2: Consent vs. AuthZ (Aut=
horization)
1.=C2=A0Consent is given by RO to GS and used to prod=
uce an Authz.
2. AuthZ is given by GS to Client and used by Clien=
t to access Resource at RS interface on behalf of User.

Modified Question: where, when and =
how the "RO" Consent is captured?

Answer=
:=C2=A0
how: Consent is given by the RO to the GS.=C2=A0
where: Depend of interaction mode.
when: before step (5).
=


              

              Another important point to consider and to explain is
              related to the assurances that the user can obtain about 

              the respect of his choices. This point is currently left
              unanswered in draft-hardt-xauth-protocol-13.

            

          

        

      

    

    
[Denis] These two major points are still left unanswered at this
      time.
I do not understand the question.=C2=
=A0

    

      

        

          

            
 

              

                

                  

                    

                      

                        


                        

                        
If a RO needs to be involved and since a RO
                          is directly associated with a RS, why can't i=
t
                          be directly queried 

                          by the appropriate RS after step (2) or later
                          on ?

                      

                    

                    


                    

                    
Good question. Perhaps you can expand on a use
                      case where that would be useful?

                  

                

              

              
Before I expand, would you be able to explain first
                under which circumstances a RO needs to be queried by a
                GS ?

              

            

          

          
In all circumstances. Can you name a situation where this
            is not the case?

        

      

    

    
[Denis] This is quite easy. The final decision is always taken by
      the RS. If a Client presents access tokens issued by ASs trusted
      by the RS 

      that contain appropriate attributes to perform the requested
      operation, then the operation is allowed.=C2=A0
We should be using GS instead of AS to avoid confusion.=C2=A0

    

    
If really a human RO needs to be involved for whatever reason, it
      is possible to get its involvement when the Client connects to the
      RS. 

      However such involvement does not need to be formalized by a
      protocol. It can be application specific.
<=
div>Client has no Relationship with the RO. 

There=
 is no reference to a human here. User, Client, RS, GS, RO are all roles. N=
othing states the type of participants they are.

    

    

      

        

          

            

              
 How can the GS identify which RO to query ?

              

            

          

          
There is supposed to be a preexisting relationship
            between GS and RO, If not RO will have to register with GS
            in the first interaction (onboarding).

          


          

          
How can the GS identify how to connect with RO?

          
GS must evaluate the RS provided info in=C2=A0step (3)
            AuthZRequest(AuthZChallenge) to decide how to contact the
            RO. This is where selection of interaction mode=C2=A0takes plac=
e.

          

        

      

    

    
[Denis] This means that a GS must have prior relationships with
      the RSs and ROs. 
No. Evaluating an=C2=A0A=
uthZChallenge to discover the RO:
- does not assume GS knows RS.=
=C2=A0
- does not presume RS knows GS.

B=
ut:
- GS will generally=C2=A0have to know RO, as RO delegates the=
 work to produce authorizations on his behalf to GS.
- RS will ge=
nerally have to know RO, as RO custodies his Resources with RS and trusts R=
S to only release it to authorized parties.

How do=
 you establish a contract without contracting parties knowing each other?
While this sh=
ould not be prevented for backward
      compatibility with OAuth 2.0, 

      this should not be the single case. Prior relationships between
      ROs and GSs is a door half-opened for Big Brother. If in addition
      the GS is able to know which operation 

      is attempted by the client on which RSs, then it is a door
      wide-opened for Big Brother.
I do not unde=
rstand this. GS is working for RO.

    

      

        

          

            

              

                

                  

                    
=C2=A0

                    

                      

                        
Which information is supposed to be
                          presented to the RO ?

                          Which information is supposed to be returned
                          by the RO ?

                      

                    

                    


                    

                    
Just like how the user authenticates to an AS,
                      how the AS and RO communicate is out of scope.

                    

                  

                

              

              
At the moment, the usefulness of a dialogue between a
                GS and a RO has not been explained, nor demonstrated.

                The question is about the functionality of that dialogue
                in terms of input and output information (and not about
                

                the design of a protocol or of a user interface).
                Anyway, AFAIU a dialogue between a GS and a RO is
                optional.

              

              

                

                  

                    
For many use cases, the User is the RO, and the
                      interaction is through a user interface, not a
                      machine protocol. 

                    

                  

                

              

              
Wait a second. You wrote "the User is the RO". T=
he User
                is attempting to make an access to a RS by using a
                Client. 

                That User is not the RO of the RS.=C2=A0=C2=A0 

                

              

            

          

          
The User interacts with the Client.

          
The RO interacts with the GS.

          


          

          
In some use cases (where we use redirect interaction) we
            assume the person controlling the "User-Agent" is als=
o the
            person 

            controlling the "RO-Agent" and they reside on the sam=
e
            device. These are cases where we say User equals RO.

        

      

    

    
[Denis] Sorry, I have difficulties to understand such a case. A
      person giving his consent to himself ?
We =
do not have people here, but roles.=C2=A0
RO is consenting
<=
div>=C2=A0 - that the Client can access his Resource=C2=A0
=C2=A0=
 - on behalf of the User [optional].=C2=A0

So RO a=
nd User are different roles, even=C2=A0if they are sometimes assumed by the=
 same human/device/machine/...

    


-- 
<=
div dir=3D"ltr">
Francis Pouatcha
=
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https=
://adorsys-platform.de/solutions/


--0000000000007eb6c705aae3ee98--


From nobody Mon Jul 20 11:54: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 0AC7E3A0DDF for ; Mon, 20 Jul 2020 11:54: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=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 I-3iKvqrphaD for ; Mon, 20 Jul 2020 11:54:07 -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 65FDA3A0DE0 for ; Mon, 20 Jul 2020 11:54:07 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id q15so517942wmj.2 for ; Mon, 20 Jul 2020 11:54:07 -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=pq6BtKPInvvONL5Qj9cYPprcRKTBJ2eB46APU/bfsQc=; b=BysTHqc0gxasuRlHyKTMq5zZBz5tcTVfNIhIqfD8ovNAe8B/wjZLNhKynPQZjY1Jg/ uTf07hFvqZJA6ve+yqZQlHMvj1wT+r7w+xZ9avmD5dg6DP8HPi1clNpsYp5+++BBFFxh S4x7z/YYEkYIFYIqcqX6IJaz4m+a0UlW2z440=
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=pq6BtKPInvvONL5Qj9cYPprcRKTBJ2eB46APU/bfsQc=; b=NmarcBjKXeMQvVTze4lo9/rQanXrhVFfJqO3vz8Tkm84fXllOAn3KacV2wnhh6naLL Ok+0R8hTKaw6f4LTj2M+rWAgunGaVi+ZkygXcCWtFIW6+o8/ppu4ACL/N+SdZ8/C68Cf tnmDb8jW/7NK1r6UTwWqZ1QdT1Q3ooCXcT7ywfU3VJuL926N6nxJ/lRFgJQqmzQNOgqf 36ulQP0heK0eRoJAYyK0FKtVh3eXKlONXu51alB83mWGh60kgKqzSfzKQyteOeEQIqoB YW6PFYKHFWswUgJ8BO34HE95oZ+zTzjgDDigfuZWMM/B4nBDYdM+Ln2SQgHrUtdO3jcg J6VQ==
X-Gm-Message-State: AOAM530vMkxLXp3BwGJwBX6q6vm+D4vgMfRg7TxU52nHn3J/XIJE0WPu 7YB5/Bgx3k1AbRVIa8YycCF6CkgcOP9e+OZAH38wXg==
X-Google-Smtp-Source: ABdhPJy2ILQFqI9bfDt4GtIy5R1uyK9wGZ7tnhxioK4fowbrV0rakGVRYf0m1AY+FAbGlO9lYYI8wqoEaA0QsIsdJbE=
X-Received: by 2002:a7b:c952:: with SMTP id i18mr658875wml.65.1595271245782; Mon, 20 Jul 2020 11:54:05 -0700 (PDT)
MIME-Version: 1.0
References:                <8b08ff35-f1d5-ee65-c89a-c1f3191ae5b6@free.fr> 
In-Reply-To: 
From: Francis Pouatcha 
Date: Mon, 20 Jul 2020 14:53:54 -0400
Message-ID: 
To: Tom Jones 
Cc: Denis , txauth@ietf.org, Dick Hardt 
Content-Type: multipart/alternative; boundary="000000000000ecfe3505aae4070e"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 20 Jul 2020 18:54:09 -0000

--000000000000ecfe3505aae4070e
Content-Type: text/plain; charset="UTF-8"

Hello Tom,


> This interchange exhibits an essential problem of most of this work. The
> idea that humans populate the web. I have yet to see a human with an
> ethernet connection. So i must assume that the user agent is the essence of
> the human on the web.
>
No. The User agent is the agent of the User. The RO agent is the agent of
the RO. Off course the word "agent" only appears when the party (RO, User)
assuming a role needs some means of interacting with other parties.

Referring to a User agent does not conclude to the User being a human.

>
> Second there are two terms which need to be distinct in the general case -
> at least where the RO is a human and the resource contains PII.
>
What is PII?

> The RO aka subject is the identifier that is used by a real world human
> that has data on the web that is (inter alia) PII about them.
>
Next confusion: RO vs. Subject.

> The user aka guardian (and often also the subject) is the identifier that
> is used by a real world human that has acquired control of access to the
> PII about the subject.
>
Next confusion: User vs. Subject

This last sentence looks like the content of a new thread....


-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--000000000000ecfe3505aae4070e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello=C2=A0Tom,


This interchange exhibits an essential problem=C2=A0of most of this =
work. The idea that humans populate the web. I have yet to see a human with=
 an ethernet connection. So i must assume that the user agent is the essenc=
e of the human on the web.
No. The User agent is the=
 agent of the User. The RO agent is the agent of the RO. Off course the wor=
d=C2=A0"agent" only appears when the party (RO, User) assuming a =
role needs some means of interacting with other parties.

Referring=C2=A0to a User agent does not conclude to the User being a=
 human.

Second there are two terms which need to be distin=
ct in the general case - at least where the RO is a human and the resource =
contains PII.
What is PII?=C2=A0
The RO aka =
subject is the identifier that is used by a real world human that has data =
on the web that is (inter alia) PII about them.
Next confusion: RO vs. Subject.=C2=A0
The user aka guardian (and often =
also the subject) is the identifier that is used by a real world human that=
 has acquired control of access to the PII about the subject.
Next confusion: User vs. Subject

T=
his last sentence looks like the content of a new thread....

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


--000000000000ecfe3505aae4070e--


From nobody Mon Jul 20 11:55: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 66CA23A0DDB for ; Mon, 20 Jul 2020 11:55:23 -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=[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, 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 pjXkcQiz5-at for ; Mon, 20 Jul 2020 11:55:20 -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 67DBC3A0DDA for ; Mon, 20 Jul 2020 11:55:20 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id h19so21358585ljg.13 for ; Mon, 20 Jul 2020 11:55:20 -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=T4Gp6zQ05LjgBAorM/fdoQQkW0s457WntuofDq7/efc=; b=mjV7yFjDNC0cOCcl2aFKKKfhB7eTi0FdQZrhmd71vff52kwzfkAhnc76u851WGeHs/ wCp+SmR/7DjovaVsRiF/DYFlxGAooThJSF+Gpm7a0/GFLDF9Q00WDUGmQ7QhZINOlz+S eIcDaK1HmfduNm/dKiqIMjwMj0Ak5UCLc+pI/zP4rz9hYoo+xIxeRNzm5D6Yan0azNOk dxiAgWGi8skbu0+DL74Jbk7K2p3kq+LUuw7l3s5S+57QeHOmSSiuj9mwkYX6c1wpRSzk c1S+54DjFWDJqtGViNnk+91g26Bcc2l4hNlJa6KcEF9r8FLZ63S12RYl718DJLWQk+rh Kbww==
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=T4Gp6zQ05LjgBAorM/fdoQQkW0s457WntuofDq7/efc=; b=EsCw7lg3DRAGYDUVE+inF9jinn3/ohCjOl5FeDoMHKatNDkxram6VLL1V7j47SQEnK MNhzaPMDcSVuqAGgSogyb1CW0koV9suWp+YsCQq7A/9YSfiT6Hqg+r261S+oSZDWo7// /8oFsiDoF41stO9Hk+layN8kcvgM7GuUdrOGIwjaUYT0NE0PACOAuEc9GDts4CcFy4Wl DWoa+CBzawR+/LKDalNU64IJ2bbl3BjhMtPmOHO9K+giXXtwHbm09Tr4Qrm1VCiruOgP 4k57MV557ANKbashdxuWJN3meEzqo6KM4ANsKXzKluSKd+SdByf5tMS5E4AVH50vt46t OvOw==
X-Gm-Message-State: AOAM5313Yazcpn4pFjodewecZxhSTSaMEgmC97BsmDq69rweNThQcDqN fXFAKUDyxlWBkCeSdrV0Zs8JdDfdK1SOcUmGvodOCaT2gQ4=
X-Google-Smtp-Source: ABdhPJxFGAnpxMCKkvKufxqDKV9OyAAYeXx0TM3WK6x7xexE7xoBuiRAljS5R1ATp7o5DqNxXtv2Fiv0F9ETxzCsFt8=
X-Received: by 2002:a2e:8316:: with SMTP id a22mr10465272ljh.246.1595271318259;  Mon, 20 Jul 2020 11:55:18 -0700 (PDT)
MIME-Version: 1.0
References:   <5B2BF4E7-77CD-4DC6-A0C9-E7894CE38A5E@mit.edu>    
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 20 Jul 2020 11:54:42 -0700
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003ecf9005aae40c68"
Archived-At: 
Subject: Re: [Txauth] New version of XYZ Draft
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, 20 Jul 2020 18:55:23 -0000

--0000000000003ecf9005aae40c68
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 20, 2020 at 4:26 AM Justin Richer  wrote:

> Hi Dick,
>
> I think it should be pretty uncontroversial that the goal of the GNAP
> working group is to produce the GNAP protocol. But I=E2=80=99m still glad=
 to see
> you=E2=80=99re interested in focusing on technical discussions.
>
> Answers to the individual points inline.
>
> On Jul 18, 2020, at 8:58 PM, Dick Hardt  wrote:
>
> Justin: how about we let the chairs drive WG conversations on the
> goals, and we focus on the technical discussion?
>
> In addition to my questions and observations earlier, here is my feedback
> on the new capabilities in XYZ:
>
> 2.5.2. Redirect to an Arbitrary Short URL
>
> This looks the same as 2.5.1 except it is short. My concern with both of
> these is the AS has no signal on the mode chosen by the client/user. It
> could be a redirect on the same device, or decoupled, where the user is n=
ow
> on a different device. In 2.5.3 you justify a new URL because the AS may
> want a different URL for an app. I think that is even more significant
> between an on device redirect, and a decoupled experience. By having
> different URLs for the different modes in XAuth, the AS can ensure the on=
e
> in a decoupled mode is short enough to be scanned if decoupled is
> supported. In other words, the mode dictates if it should be short enough
> to be scanned.
>
>
> The differences between a =E2=80=9Ccoupled/decoupled=E2=80=9D experience =
are not
> controlled by the =E2=80=9Credirect/short_redirect/app=E2=80=9D parameter=
s, but by the
> =E2=80=9Ccallback/pushback=E2=80=9D parameters. The first three are param=
eters that
> determine some of the ways that the client can get :to: the AS, while the
> others are ways the client can get :back: from the AS. They are not tied
> together like they are in Xauth.
>
> Which combinations are available is up to the client=E2=80=99s request, s=
ince,
> after all, the client is the piece of software that knows what it can do,
> not the AS. The AS isn=E2=80=99t in a position to guess what the client i=
s going to
> do with the information it gets back, it can only respond to the request
> for information that the client sends. If a client displays a URL to the
> user as a QR code, it=E2=80=99s probably not going to send a =E2=80=9Ccal=
lback=E2=80=9D, for
> example. If an AS determines that it doesn=E2=80=99t want to support that
> =E2=80=9Cdecoupled=E2=80=9D mode for a given request, it can reject it fo=
r lack of a
> =E2=80=9Ccallback=E2=80=9D parameter. The reason for this decoupling
>

Looks like you might have not finished this sentence ... but you are
missing my point.

As noted below, the client may not know what it can do until it tries.

The user will often be the one that decides the actual flow that is
started. If the AS has an app, the user will want to use the device with
the AS, which may not be the device the client is on. The client can show a
QR code for the user to scan with their phone, or it can do a redirect to
the browser and get redirected back. The AS does not know which flow is
happening if the URL provided can do either of those.

I described this in:

https://mailarchive.ietf.org/arch/msg/txauth/qOF5Wl3uYQ9rdzEz7ORftYAAHc4/



>
> And as I=E2=80=99m sure you saw in my editor=E2=80=99s note, I=E2=80=99m =
not convinced that the
> short_redirect is worth it as a separate option, even though the semantic=
s
> are pretty clear here. As I said in the last discussion we had on this
> topic, I=E2=80=99ve implemented a QR code based on a full redirect URI an=
d did not
> find it problematic. You made a compelling argument that the AS would
> potentially have different generation rules for short and long, and
> wouldn=E2=80=99t want to use a short one unless it needed to. It seemed t=
o be a
> simple enough addition to put in this revision.
>
>
> 2.5.3 Open an Application-specific URL
>
> What are you intending "app" to mean? I can think of a device where the
> client can open a URL, and a URL could not be associated with an
> application on the device. Are you thinking the client will do some
> detection if a specific app is available on the device? What if the app i=
s
> not on the device? Most platforms don't provide any probing on what other
> apps are on a device, so there is no mechanism to detect if the app is
> present prior to launching. Is that what you are expecting?
>
>
> You can detect if an app (any app) is going to handle a URL on some
> platforms. This mechanism not only lets an AS have different URLs for app
> launching and web-based interaction, and it lets the client optimize the
> experience instead of the awkward fall-through that we have with OAuth2=
=E2=80=99s
> app2app communication today. Furthermore, as I=E2=80=99m sure you saw in =
my
> editor=E2=80=99s note, there=E2=80=99s probably going to be additional pi=
eces of
> information passed in this case. I=E2=80=99ve talked with a couple differ=
ent groups
> who are using distributed storage mechanisms to communicate between
> components. In that case, this will probably have more information in it
> than a single URL, but I didn=E2=80=99t want to conjecture what that woul=
d look
> like, thus the note.
>

I'm still not sure what you mean by app. Are you thinking only
mobile/tablet? PC? Media streaming device?

On iOS, the ability for an app to detect if a URL will be handled is
significantly limited. Last I checked, you could have 5 URLs in your app to
check. Apple locked it down to improve privacy.

FYI: On iOS, an app can attempt to open a deep link for an app and set a
flag so that the browser will NOT open the URL in the browser if the the
app is not installed. So the client can try opening another app, and if it
is not there, take another course of action, but it would know that until
it tries to open the other app.


>
>
> 2.5.5. Receive an HTTP Direct Callback
>
> What use cases require this functionality? Contrary to SecEvent, where
> both push and poll are specified because a receiver may not be able to ha=
ve
> a public endpoint, the AS has a public endpoint for the client to call. I=
n
> GNAP, the client can poll the AS. Why have both?
>
>
> Why limit the client to only callbacks? The callback means =E2=80=9Cthere=
=E2=80=99s an
> HTTP endpoint that the user=E2=80=99s browser gets to=E2=80=9D whereas pu=
shback means
> =E2=80=9Cthere=E2=80=99s an HTTP endpoint that the user=E2=80=99s browser=
 can=E2=80=99t get to=E2=80=9D. Both are
> reasonable, and should be combinable with any of the options for getting =
a
> user to the AS, above. There are likely to be other options as well, sinc=
e
> we already see them in the wild (CIBA=E2=80=99s push mode, for instance).
>

"Why limit the client?"

This is a security protocol. More ways to do the same thing increases the
attack surface. It also increases  complexity / or lowers
interoperability.  The AS either needs to support ALL the mechanisms, or
there may not be interop if the client and AS don't support a common
mechanism.

=E1=90=A7

--0000000000003ecf9005aae40c68
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Jul 20, 2020 at 4:26 AM Justi=
n Richer <jricher@mit.edu> wro=
te:
Hi Dick,

I think it shou=
ld be pretty uncontroversial that the goal of the GNAP working group is to =
produce the GNAP protocol. But I=E2=80=99m still glad to see you=E2=80=99re=
 interested in focusing on technical discussions.=C2=A0

Answers to the individual points inline.

On Jul 18, 2020, at 8:58 PM, Dick Hardt <dick.hardt@gmail.com=
> wrote:

Justin: how about we let the chairs drive WG conver=
sations on the goals,=C2=A0and we focus on the=C2=A0technical discussion?

In addition to my questions and observations earlie=
r, here is my feedback on the new capabilities in XYZ:

2.5.2. Redirect to an Arbitrary Short URL

=

This looks the same as 2.5.1 except it is short. My concern with both =
of these is the AS has no signal on the mode chosen by the client/user. It =
could be a redirect on the same device, or decoupled, where the user is now=
 on a different device. In 2.5.3 you justify a new URL because the AS may w=
ant a different=C2=A0URL for an app. I think that is even more significant =
between an on device redirect, and a decoupled experience. By having differ=
ent URLs for the different modes in XAuth, the AS can ensure the one in a d=
ecoupled mode is short enough to be scanned if decoupled is supported. In o=
ther words, the mode dictates if it should be short enough to be scanned.

The diff=
erences between a =E2=80=9Ccoupled/decoupled=E2=80=9D experience are not co=
ntrolled by the =E2=80=9Credirect/short_redirect/app=E2=80=9D parameters, b=
ut by the =E2=80=9Ccallback/pushback=E2=80=9D parameters. The first three a=
re parameters that determine some of the ways that the client can get :to: =
the AS, while the others are ways the client can get :back: from the AS. Th=
ey are not tied together like they are in Xauth.=C2=A0

=

Which combinations are available is up to the client=E2=80=99s request=
, since, after all, the client is the piece of software that knows what it =
can do, not the AS. The AS isn=E2=80=99t in a position to guess what the cl=
ient is going to do with the information it gets back, it can only respond =
to the request for information that the client sends. If a client displays =
a URL to the user as a QR code, it=E2=80=99s probably not going to send a =
=E2=80=9Ccallback=E2=80=9D, for example. If an AS determines that it doesn=
=E2=80=99t want to support that =E2=80=9Cdecoupled=E2=80=9D mode for a give=
n request, it can reject it for lack of a =E2=80=9Ccallback=E2=80=9D parame=
ter. The reason for this decoupling=C2=A0
Most of these are=
 changes I=E2=80=99ve wanted to do for quite some time and finally had oppo=
rtunity to make the edits. As I said below, the core protocol really hasn=
=E2=80=99t changed in nature, but hopefully it=E2=80=99s easier to understa=
nd with it laid out in this way.=C2=A0

All of thes=
e are points that I=E2=80=99ve made previously on the list in discussions, =
but to answer your questions directly:

- Mapping i=
tems to separate URLs has been on XYZ=E2=80=99s radar since well before it =
was proposed in Xauth, so this is bringing some of that into the concrete s=
ystem. I still need to implement it to see how well it works in practice.

- The need to rotate the reference handle as well a=
s use it externally (the =E2=80=9Cextend a request=E2=80=9D method) both ca=
ll for having an identifier separate from the access URL. It also allows an=
 AS more freedom in how it manages its endpoints, and aligns with the desir=
e to push more information into the ongoing request after the initial phase=
. I=E2=80=99d actually rather the access token management move in that dire=
ction, using the token itself as the artifact, but I couldn=E2=80=99t do th=
at and still use the DELETE method for revocation. So that=E2=80=99s an eng=
ineering challenge that I think the group should discuss, and decide whethe=
r it=E2=80=99s worth having the =E2=80=9CDELETE=E2=80=9D verb semantics and=
 having that restriction placed on the AS as a consequence.

<=
/div>
- The DID work is likely better suited for an extension, and alwa=
ys has been. But it was worth having in previous revisions for discussion p=
urposes, especially as a point around how a non-HTTP interaction method wou=
ld work. I expect to see DIDCOMM, CHAPI, WebAuthN, and other interaction me=
thods in the extensions landscape of GNAP, usable alongside the others.=C2=
=A0

And a final point, the interaction setup hasn=
=E2=80=99t really changed, so I=E2=80=99m curious to hear what you think has changed there. Even with a couple new capabilities on the way ther=
e (short_uri and app) and back (pushback), It=E2=80=99s structurally and co=
nceptually identical to previous revisions.

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

On Jul 1=
7, 2020, at 1:10 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey Justin,

Glad to see that you are alig=
ning=C2=A0on having URIs for the access tokens and the "grant".

While the token URI is unique=C2=A0to the token, yo=
u have not done the same for a "grant", but have a handle and a n=
on-unique URI.

Why not have a unique grant URI sim=
ilar to the token URI? (a combination of the handle and a non-unique URI) -=
- this is then both the identifier, and the URL for "management"?=


Glad to see you have excised the DID references. =
I don't think the common use cases are well established there currently=
.

I have LOTS of feedback=C2=A0on your interaction=
 changes, that I'll post later on, and hope that others have feedback o=
n those as well.

/Dick




=

On Thu, Jul 16, 2020 at 2:52 PM Justi=
n Richer <jricher@m=
it.edu> wrote:
Hi all,

I=E2=80=99ve updated the XYZ draft sp=
ecification. Since the publication tools are currently locked prior to the =
upcoming virtual meeting, I have published it online here:

=


This represents a pretty significant refactoring of the=
 specification, hopefully to make the concepts and capabilities easier to u=
nderstand. The core protocol is largely the same as before, but there are a=
 number of serious updates:

=C2=A0- Continuation r=
equests happen at a URL returned in the TX response. The =E2=80=9Chandle=E2=
=80=9D is still sent as one of the input values here, since the handle can =
also be used it other contexts.
=C2=A0- Tokens now can include th=
e resources they are issued for
=C2=A0- Tokens can have an option=
al management URI for rotation and revocation.
=C2=A0- =E2=80=9Cc=
laims=E2=80=9D has been removed in favor of =E2=80=9Csubject=E2=80=9D deali=
ng directly with identifiers and assertions
=C2=A0- the =E2=80=9C=
user=E2=80=9D request and response now align with identifiers and assertion=
s
=C2=A0- Extensions and registries are more clearly enumerated t=
hroughout the document
=C2=A0- DID-related items have been excise=
d in deference to a future possible extension
=C2=A0- Added a =E2=
=80=9Cpushback=E2=80=9D mechanism to complement the =E2=80=9Ccallback=E2=80=
=9D mechanism
=C2=A0- Simplified dynamic handle returns and acces=
s tokens based on developer feedback (basically we dropped a bunch of =E2=
=80=9Cwhat if=E2=80=9D stuff that nobody used or liked, like SHA3 hashes fo=
r bearer tokens)

I=E2=80=99ve also updated the int=
eractive examples on=C2=A0=
https://oauth.xyz/=C2=A0to match this new draft. Hopefully it=E2=80=99s=
 consistent with the draft text.

I have not yet, h=
owever, updated any of the implementations of XYZ to take the elements of n=
ew syntax into account, so there might be some more changes prior to the IE=
TF meeting as I realize what terrible mistakes I=E2=80=99ve made when doing=
 that. :)=C2=A0

Feedback, as always, is welcomed, =
and thanks to everyone who=E2=80=99s provided input to the project to date.=
=C2=A0

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

Txauth mailing list

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






Looks like you might have not finished this sentence=
 ... but you are missing my point.

As noted below,=
 the client may not know what it can do until it tries.=C2=A0
The user will often be the one that decides the actual flow tha=
t is started. If the AS has an app, the user will want to use the device wi=
th the AS, which may not be the device the client is on. The client can sho=
w a QR code for the user to scan with their phone, or it can do a redirect =
to the browser and get redirected=C2=A0back. The AS does not know which flo=
w is happening if the URL provided can do either of those.=C2=A0
=

I described this in:


=C2=A0
And as I=E2=80=99m sure you saw in my editor=E2=80=99s note, I=
=E2=80=99m not convinced that the short_redirect is worth it as a separate =
option, even though the semantics are pretty clear here. As I said in the l=
ast discussion we had on this topic, I=E2=80=99ve implemented a QR code bas=
ed on a full redirect URI and did not find it problematic. You made a compe=
lling argument that the AS would potentially have different generation rule=
s for short and long, and wouldn=E2=80=99t want to use a short one unless i=
t needed to. It seemed to be a simple enough addition to put in this revisi=
on.


2.5.3 Open an Appl=
ication-specific URL

What are you intending "=
app" to mean? I can think of a device where the client can open a URL,=
 and a URL could not be associated with an application on the device. Are y=
ou thinking the client will do some detection if a specific app is availabl=
e on the device? What if the app is not on the device? Most platforms don&#=
39;t provide any probing on what other apps are on a device, so there is no=
 mechanism to detect if the app is present prior to launching. Is that what=
 you are expecting?
You can detect if an app (any app) is going to handle a URL on=
 some platforms. This mechanism not only lets an AS have different URLs for=
 app launching and web-based interaction, and it lets the client optimize t=
he experience instead of the awkward fall-through that we have with OAuth2=
=E2=80=99s app2app communication today. Furthermore, as I=E2=80=99m sure yo=
u saw in my editor=E2=80=99s note, there=E2=80=99s probably going to be add=
itional pieces of information passed in this case. I=E2=80=99ve talked with=
 a couple different groups who are using distributed storage mechanisms to =
communicate between components. In that case, this will probably have more =
information in it than a single URL, but I didn=E2=80=99t want to conjectur=
e what that would look like, thus the note.

I'm still not sure what you mean by app.  Are =
you thinking only mobile/tablet? PC? Media streaming device?

=

On iOS, the ability for an app to detect if a URL will be handle=
d is significantly limited. Last I checked, you could have 5 URLs in your a=
pp to check. Apple locked it down to improve privacy.=C2=A0

<=
/div>
FYI: On iOS, an app can attempt to open a deep link for an app an=
d set a flag so that the browser will NOT open the URL in the browser=C2=A0=
if the the app is not installed. So the client can try opening another app,=
 and if it is not there, take another course of action, but it would know t=
hat until it tries to open the other app.
=C2=A0


2.5.5. Rece=
ive an HTTP Direct Callback

What use cases req=
uire this functionality? Contrary to SecEvent, where both push and poll are=
 specified because a receiver=C2=A0may not be able to have a public endpoin=
t, the AS has a public endpoint for the=C2=A0client to call. In GNAP, the c=
lient can poll the AS. Why have both?


Why limit the client to only =
callbacks? The callback means =E2=80=9Cthere=E2=80=99s an HTTP endpoint tha=
t the user=E2=80=99s browser gets to=E2=80=9D whereas pushback means =E2=80=
=9Cthere=E2=80=99s an HTTP endpoint that the user=E2=80=99s browser can=E2=
=80=99t get to=E2=80=9D. Both are reasonable, and should be combinable with=
 any of the options for getting a user to the AS, above. There are likely t=
o be other options as well, since we already see them in the wild (CIBA=E2=
=80=99s push mode, for instance).=C2=A0

"Why limit the client?"

=

This is a security protocol. More ways to do the same thing increases =
the attack surface. It also increases=C2=A0 complexity / or lowers interope=
rability.=C2=A0 The AS either needs to support ALL the mechanisms, or there=
 may not be interop if the client and AS don't support a common mechani=
sm.

3D""=E1=90=A7


--0000000000003ecf9005aae40c68--


From nobody Mon Jul 20 12:11: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 319A13A0E0C for ; Mon, 20 Jul 2020 12:11:27 -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 lXnSS1AjXpAx for ; Mon, 20 Jul 2020 12:11:25 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 1CC493A0E0B for ; Mon, 20 Jul 2020 12:11:25 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id t9so10327195lfl.5 for ; Mon, 20 Jul 2020 12:11:25 -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=PCL1dC4fHhx+iqk5oBVtCoBpoRERkQBIx/JTSwgztII=; b=VcCrFLTl9Jwp8RN3cbx8kMGm06ZNPc8y8ShxsGDMhw4CO7sQMyjfdXbNg9gVtOzXpX N4QvQQzkRAczQodBTo0VyItJWzr5l3E1oqChsxZDV9lR+3Sl70DmgsfxDiGiyNC1Lrad AKyz0TLN7iCgNMR4aIniuJd3qinJ+IQCc7QC0wOTm+A4Yk6w9isCXWM6sd9fkw0MfPQm eJxtw+Gp5SMG491ov/sH92L1zoMteLK+k5dRS5k97ZuNYlVAmTRhgrkRB8L8F9ao0W6Q On2lorcqxho0wGq7KrRe5/IVDj2DWFNkGzN+EUQbVoNKfgEbyIRUQl400wmhWse8Dgg8 yxTg==
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=PCL1dC4fHhx+iqk5oBVtCoBpoRERkQBIx/JTSwgztII=; b=P8dWCNEIIWnQPdi7XFWY27S/+u+2dTZR0IGEvVQT7jLFkamzAdsdRGreGKBnPSYipk 8eDjNviU1DDAYxm8m8MY66dw0helF6hCSdQ+E575fXDTE5tAuLwVF3xNalwZgR8/rFg7 saPG0ZJXTX13xZhtstOeVDruOt1sOYLWiaDW0kG8G4hokAvhf2y1Ns0Y1BX99vlEO63n 5Gd3NiCpmf8zxp4nzga9yZjyGUv8jpJPyafaJIzAAk4Ha+TXK+A6em0CKHU40Y8IgGbC jlkksOsiW/+7xLtbIPp8SLru9hUp6Kw0jXdcfz338qpTjwvA1y4PEZShLfPKU4qdquks ySVA==
X-Gm-Message-State: AOAM53092NpDjCHRl5FxTT4KcgIvF3kPeuPmI3+Z2C01Jo9Mh0EePK3i ryys9Y71uC2yXf/eJmrLroJ/GnIbCLwVk80ie9k=
X-Google-Smtp-Source: ABdhPJxgcgsCqOPc+WRo/fvtZ9GsBGi+BNQAted5NYlUt0L6HZxRGjmQtMrAayjU53pDUHdrDjb6npAzPtmc9XKi1rM=
X-Received: by 2002:a19:8044:: with SMTP id b65mr8318323lfd.91.1595272283020;  Mon, 20 Jul 2020 12:11:23 -0700 (PDT)
MIME-Version: 1.0
References:               
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 20 Jul 2020 12:10:44 -0700
Message-ID: 
To: Denis 
Cc: Francis Pouatcha , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bfe2c605aae44576"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 20 Jul 2020 19:11:27 -0000

--000000000000bfe2c605aae44576
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 20, 2020 at 2:05 AM Denis  wrote:

> Hi Dick,
>
> On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:
>
>> Hello Francis and Dick,
>>
>> The good news first: we are making some progress. We are now close to an
>> agreement with steps (1) up to (3),
>> ... except that the place where the user consent is captured is not
>> mentioned/indicated.
>>
>
> This major question which is currently left unanswered is where, when and
> how the user consent is captured.
>

When is covered, per the sequence. How and where are out of scope of what I
drafted.


>
> Another important point to consider and to explain is related to the
> assurances that the user can obtain about
> the respect of his choices. This point is currently left unanswered in
> draft-hardt-xauth-protocol-13.
>
>
>> If a RO needs to be involved and since a RO is directly associated with =
a
>> RS, why can't it be directly queried
>> by the appropriate RS after step (2) or later on ?
>>
>
> Good question. Perhaps you can expand on a use case where that would be
> useful?
>
> Before I expand, would you be able to explain first under which
> circumstances a RO needs to be queried by a GS ?
> How can the GS identify which RO to query ?
>

If the User is the RO, then the GS knows who to query.

If the RO is a separate entity, then the GS knows the RO from the RS being
queried. An example is a user would like access to an enterprise asset
where a workflow is started to gain approval, and an administrator or
manager provides consent.



>
>
>> Which information is supposed to be presented to the RO ?
>> Which information is supposed to be returned by the RO ?
>>
>
> Just like how the user authenticates to an AS, how the AS and RO
> communicate is out of scope.
>
> At the moment, the usefulness of a dialogue between a GS and a RO has not
> been explained, nor demonstrated.
> The question is about the functionality of that dialogue in terms of inpu=
t
> and output information (and not about
> the design of a protocol or of a user interface). Anyway, AFAIU a dialogu=
e
> between a GS and a RO is optional.
>

See enterprise example above.


> For many use cases, the User is the RO, and the interaction is through a
> user interface, not a machine protocol.
>
> Wait a second. You wrote "the User is the RO". The User is attempting to
> make an access to a RS by using a Client.
> *That* User is not the RO of the RS.
>
The user being the RO is the initial use case for OAuth. A client
application would like access to the user's photos at a photo sharing site.
The resource is the user's photos. The user is the owner of that resource.



>
> Denis
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
=E1=90=A7

--000000000000bfe2c605aae44576
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Jul 20, 2020 at 2:05 AM Denis=
 <denis.ietf@free.fr> wrote=
:

 =20
   =20
 =20
  

    
Hi Dick,

    


    

    

     =20
      
On Fri, Jul 17, 2020 at 9:21 AM Denis <denis.ietf@free.fr>
        wrote:

        

          

            

              
Hello Francis and Dick,

              


              

              
The good news first: we are making some progress. We
                are now close to an agreement with steps (1) up to (3),
                

                ... except that the place where the user consent is
                captured is not mentioned/indicated.

            

          

        

      

    

    

    This major question which is currently left unanswered is where,
    when and how the user consent is captured.
<=
br>
When is covered, per the sequence. How and where are out of s=
cope of what I drafted.=C2=A0
=C2=A0

    

    Another important point to consider and to explain is related to the
    assurances that the user can obtain about 

    the respect of his choices. This point is currently left unanswered
    in draft-hardt-xauth-protocol-13.

    

    

      

        

          

            

              


              

              
If a RO needs to be involved and since a RO is
                directly associated with a RS, why can't it be directly
                queried 

                by the appropriate RS after step (2) or later on ?

            

          

          


          

          
Good question. Perhaps you can expand on a use case where
            that would be useful?

        

      

    

    
Before I expand, would you be able to explain first under which
      circumstances a RO needs to be queried by a GS ?

      How can the GS identify which RO to query ?

If the User is the RO, then the GS knows who to query.=
=C2=A0

If the RO is a separate entity, then the GS=
 knows the RO from the RS being queried. An example=C2=A0is a user would li=
ke access to an enterprise asset where a workflow is started to gain approv=
al, and an administrator or manager provides consent.=C2=A0

<=
/div>
=C2=A0

    

    

      

        

          
=C2=A0

          

            

              
Which information is supposed to be presented to the
                RO ?

                Which information is supposed to be returned by the RO ?
            

          

          


          

          
Just like how the user authenticates to an AS, how the AS
            and RO communicate is out of scope.

          

        

      

    

    
At the moment, the usefulness of a dialogue between a GS and a RO
      has not been explained, nor demonstrated.

      The question is about the functionality of that dialogue in terms
      of input and output information (and not about 

      the design of a protocol or of a user interface). Anyway, AFAIU a
      dialogue between a GS and a RO is optional.

See enterprise example above.
=C2=A0

    

    

      

        

          
For many use cases, the User is the RO, and the
            interaction is through a user interface, not a machine
            protocol. 

          

        

      

    

    
Wait a second. You wrote "the User is the RO". The User is
      attempting to make an access to a RS by using a Client. 

      That User is not the RO of the RS.=C2=A0=C2=A0 
<=
/blockquote>
The user being the RO is the initial use case for OAuth. A=
 client application would like access to the user's photos at a photo s=
haring site. The resource is the user's photos. The user is the owner o=
f that resource.
=C2=A0
=C2=A0

      

      Denis

    


    

  


-- 

Txauth mailing list

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


3D""=
=E1=90=A7


--000000000000bfe2c605aae44576--


From nobody Mon Jul 20 12:16: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 88E053A0E11 for ; Mon, 20 Jul 2020 12:16: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, 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 UEZjjFRy0bao for ; Mon, 20 Jul 2020 12:16:33 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0: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 D06343A0E14 for ; Mon, 20 Jul 2020 12:16:32 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id t4so15237183oij.9 for ; Mon, 20 Jul 2020 12:16: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=CLAphmclu4AcbSSmBRVf1fHDAUieceAWt9CH96f6CRg=; b=LkYg64xPYTH5EDLEwVjFR5oi0Q+cKFUkQVba7DNlmWx2sVjEOaW53AP0A9vB2gXIW9 huv2MOkZTDfu+ymMr+va38Y52ILxrYHrNYa+ATyapSb/yt5zfBNdlOsprHh8O1I4gUBY ysWjPDYjfH3szv7tzyAlgk3iBLaEYhmVOvk/OovFG4MX1/5jImE3qAIazSQbzvYHqWI8 K8+IHtvKH+YrALNlCxnSLtARfc6qhQeSmDYLBnfY87rsPFnEJJ7/1vMNpCL8CvAfQXuc 2BxYWQu28sxHud0F98atkBHBhe813E80DMXBVFnknMp9Et/Lusdac3HqgjPAU+l1tvCg 4fNQ==
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=CLAphmclu4AcbSSmBRVf1fHDAUieceAWt9CH96f6CRg=; b=TwL29Q7jZIv+xF2Eho1Cjo/MdLMpp+c7EmNZM47AVNvExLXXqkK0geS+jzJ0nlzfki 2Sf1RO/hd6PO2uSJZ2WRQa6+uE91wZVoIM2L7fZyBoXx9mmaiee9R4lOQ7lc+Ts1X4l3 y5HVn6zRAXtZ5sIK8JWL9mv/GN2HpCcnzx4W7tefnmwqhEko2ehws87K9pY57dZ2Kz2K TExZtzus0aeKu22zpTNMGKsQZhAp715UWryjW+JHvlBD3QcFaOJFMVnCE9OuynNZvDPL RZy6++WLHh+MYnskevrkySwfurEnJqHG+c/Gng/V2xc83eUmAA3mpzVPzJFaHdclY6Fh owIA==
X-Gm-Message-State: AOAM530KkVQmQii8Pax7CKWSZMXnpQrsECGBx8DL5DoNxdwp7PXA/VqP Oo7jQg5h94EUc6jykvu4F/MR9zBKn6ubvhWH2To=
X-Google-Smtp-Source: ABdhPJw1NUtqlKoZp23KQkFqrS99SaFbVyNtik/pbDAqO6VRLOVlX3LKrnAQaa8+a2GKAEum/ZyhsDt4oeEYjuB9ITg=
X-Received: by 2002:aca:4905:: with SMTP id w5mr650503oia.172.1595272592041; Mon, 20 Jul 2020 12:16:32 -0700 (PDT)
MIME-Version: 1.0
References:                <8b08ff35-f1d5-ee65-c89a-c1f3191ae5b6@free.fr>  
In-Reply-To: 
From: Tom Jones 
Date: Mon, 20 Jul 2020 12:16:20 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: Denis , txauth@ietf.org, Dick Hardt 
Content-Type: multipart/alternative; boundary="0000000000002b291b05aae458d5"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 20 Jul 2020 19:16:35 -0000

--0000000000002b291b05aae458d5
Content-Type: text/plain; charset="UTF-8"

pii = personally identifiable information - it is from the GDPR - i am
not so fond of it myself but it has been used on this list before.
human on internet ==> there exists a user agent.  I never mentioned the
other direction.
RO seems to be used as a real world term.  subject is a digital identifier
which has been used and misused for decades.
i use the word "user" in a different meaning than you - i guess we should
remove the term if there is no common meaning. I detest arguing about the
meaning of words.

Peace ..tom


On Mon, Jul 20, 2020 at 11:54 AM Francis Pouatcha  wrote:

> Hello Tom,
>
>
>> This interchange exhibits an essential problem of most of this work. The
>> idea that humans populate the web. I have yet to see a human with an
>> ethernet connection. So i must assume that the user agent is the essence of
>> the human on the web.
>>
> No. The User agent is the agent of the User. The RO agent is the agent of
> the RO. Off course the word "agent" only appears when the party (RO, User)
> assuming a role needs some means of interacting with other parties.
>
> Referring to a User agent does not conclude to the User being a human.
>
>>
>> Second there are two terms which need to be distinct in the general case
>> - at least where the RO is a human and the resource contains PII.
>>
> What is PII?
>
>> The RO aka subject is the identifier that is used by a real world human
>> that has data on the web that is (inter alia) PII about them.
>>
> Next confusion: RO vs. Subject.
>
>> The user aka guardian (and often also the subject) is the identifier that
>> is used by a real world human that has acquired control of access to the
>> PII about the subject.
>>
> Next confusion: User vs. Subject
>
> This last sentence looks like the content of a new thread....
>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>

--0000000000002b291b05aae458d5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


pii =3D personally identifiable information - it is from t=
he GDPR - i am not=C2=A0so fond of it myself but it has been used on this l=
ist before.
human on internet =3D=3D> there exists a user agent.=C2=
=A0 I never mentioned the other direction.
RO seems to be used as=
 a real world term.=C2=A0 subject=C2=A0is a digital identifier which has be=
en used and misused for decades.
i use the word "user" =
in a different meaning than you - i guess we should remove the term if ther=
e is no common meaning. I detest arguing about the meaning of words.
<=
div>
Peace ..tom
=



On Mon, Jul 20, 2020 at 11:54 AM 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=C2=A0Tom,


This interchange e=
xhibits an essential problem=C2=A0of most of this work. The idea that human=
s populate the web. I have yet to see a human with an ethernet connection. =
So i must assume that the user agent is the essence of the human on the web=
.
No. The User agent is the agent of the User. The R=
O agent is the agent of the RO. Off course the word=C2=A0"agent" =
only appears when the party (RO, User) assuming a role needs some means of =
interacting with other parties.

Referring=C2=A0to =
a User agent does not conclude to the User being a human.

=
Second there are two terms which need to be distinct in the general case - =
at least where the RO is a human and the resource contains PII.
=

What is PII?=C2=A0
The RO aka subject is the identifier=
 that is used by a real world human that has data on the web that is (inter=
 alia) PII about them.
Next confusion: RO vs. =
Subject.=C2=A0
The user aka guardian (and often also the subject) is the =
identifier that is used by a real world human that has acquired control of =
access to the PII about the subject.
Next conf=
usion: User vs. Subject

This last sentence looks l=
ike the content of a new thread....


<=
/div>-- 
Francis Pouatcha
C=
o-Founder and Technical Lead
adorsys GmbH & Co. KG




--0000000000002b291b05aae458d5--


From nobody Mon Jul 20 12:30: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 080A23A0E3B for ; Mon, 20 Jul 2020 12:30:57 -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_FILL_THIS_FORM_SHORT=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 Irnns1lvFylX for ; Mon, 20 Jul 2020 12:30:53 -0700 (PDT)
Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 E2F883A0E63 for ; Mon, 20 Jul 2020 12:30:52 -0700 (PDT)
Received: by mail-lj1-x242.google.com with SMTP id q7so21546485ljm.1 for ; Mon, 20 Jul 2020 12:30: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=4nfAgj8T5DTq+57A9yqfpI7yI9exU67A1531z//MqFo=; b=jM6dZPkWWg8VI+7qt8F6rcaWOpvCzY5ZK93TvTQTcrBbqNvN91K6X29FHOqgNiVEJk +szIpywpwPTDujwdDdeFX3Swz5pBAm4ywb8lrwYjjAggPdhqF6AzR3kMkYtS15NJF9xt htVh7GHluaDJKEdSw+WxFF1jZXD3jJVkM/lozuB/IvulLvYayuFTH4nZDRTntalZTgzh fW2FCLd8kr4JN9P02SH5JnbX8UVJGlwUzDhiJpMYRx3tl3yLZtMG5jTFGbz+FWYsImPq 54Ofzifq2j8P6QADJpwa8d171L5I5mthPoloholhgI87U9BW5NbytD1nYszG82IWHYeg pgEQ==
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=4nfAgj8T5DTq+57A9yqfpI7yI9exU67A1531z//MqFo=; b=tiIgPD92XZwlEQRQ3XGSkgFNnJzfCUguHN7+VQzS15c8f77Bx5a+Lz4a+KyGXVWNg2 cldQx/6EtGZGMd5kkWbDJL6SLaOZmLNJRz37VtTu00vswnYw7ZItvWNVlD1/2puRXJM0 YZir+hxzAKOdbt1TWXIC2ZSr6g4MaCssTwcqeMGrprrgzKwgVWJfs5EPuWebtE9hBTxb z3ORVzcXdvS5OGNGpnMdqSNixS1cqs06FTxAqsR1hnfUzKWtlZRae/EBhtOih+zGOWP6 TzsScv/xWQjysl1+JP6BIwCdJBapUxuJXZJMhHxWRgpmcIt4iJhYwTrw12TS9b0i3XnJ 8/CQ==
X-Gm-Message-State: AOAM530UDIMZUvdKF9Cm063pyyT9t7oUU62189z69zRzDy/gyeHdp7BM YQrR9EfRuJD5Qm/uoL2M+RC7D45vmN9mpu9Yx+0=
X-Google-Smtp-Source: ABdhPJwtbYYNYwkTBV77el1J939VjD4pnCe864KPlMUye+gp0n4vRx2r8jYRpwGpInlGRXuwiuicz7JQvJZijYxxLtQ=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr11638836ljn.5.1595273450722; Mon, 20 Jul 2020 12:30:50 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 20 Jul 2020 12:30:14 -0700
Message-ID: 
To: Tom Jones 
Cc: Justin Richer , txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005999d905aae48ba9"
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 20 Jul 2020 19:30:57 -0000

--0000000000005999d905aae48ba9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Curious: How are you envisioning the client communicates to the AS if it is
on the User's phone?
=E1=90=A7

On Sun, Jul 19, 2020 at 9:13 PM Tom Jones 
wrote:

> Well, that might work for you. It won=E2=80=99t work for me. I put the as=
 on the
> user=E2=80=99s phone. The source and sink of the data can switch roles on=
 a
> millisecond basis. I will track your progress and adopt what I can.
>
> ..Tom's phone
>
> On Jul 19, 2020, at 1:45 PM, Dick Hardt  wrote:
>
> =EF=BB=BF
> Hi Tom
>
> The proposal is that Client asks for a claim from the AS, the user
> consents at the AS, and the AS directly releases the claim directly to th=
e
> Client. No access token. No resource server.
>
> Simpler for Client and Grant Server (AS)
>
>
>
>
>
>
> On Sat, Jul 18, 2020 at 7:34 PM Tom Jones 
> wrote:
>
>> absolutely, yes, tha az token can authorize any resource held by the
>> resource server.
>> The ONLY thing special about PII is the protection granted by the variou=
s
>> privacy laws.
>>
>> As an aside, I don't find much in the current discussion that gives me a
>> warm feeling about privacy.
>> The stuff in the torsten tokens is about as anti-privacy an effort as
>> exists today.
>> Identity assurance does NOT need to be enabled by sending more and yet
>> again more PII.
>> Peace ..tom
>>
>>
>> On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt  wrote:
>>
>>> Hey Tom
>>>
>>> While I think defining claims is out of scope of the WG, I think
>>> enabling a client to obtain claims about a user is in scope.
>>> Would you consider authorization for the release of claims to be part o=
f
>>> the purpose of this WG?
>>>
>>> I'm concerned about the XYZ shift to subject identifiers from claims,
>>> and pushing claims to a higher layer, as it may indicate to developers =
that
>>> they can ONLY ask for a user identifier.
>>>
>>> When I think of a claim, I include any and all identifiers, but I also
>>> include user attributes such as under-13, over-21,
>>> student-at-an-accredited-school, resident of city/state/province/countr=
y.
>>>
>>> GNAP can enable a client to ask for only the claims it needs, preservin=
g
>>> user privacy, and compliance with many privacy regulations.
>>>
>>> Would you agree?
>>>
>>> /Dick
>>>
>>>
>>>
>>>
>>> On Sat, Jul 18, 2020 at 9:56 AM Tom Jones 
>>> wrote:
>>>
>>>> I agree with Justin's comment " what we should do, as we define GNAP a=
s
>>>> a protocol, is focus on this one, limited slice of the identity space =
and
>>>> not spiral into others."
>>>> The title "Authorization" should rule the purposes of this group above
>>>> all else.
>>>>
>>>> The earlier statement that the client should know who the user is - is
>>>> just plain WRONG. The client should only know the information the user=
 is
>>>> willing to share with the client.
>>>> It is now the law in California that the client cannot demand identity
>>>> information that is not required for a legitimate business purpose.
>>>> There are some clients that act as fiduciaries for the user
>>>> (financial and healthcare come to mind), but as a general rule the "cl=
ient"
>>>> is not to be trusted by the user.
>>>> I understand most of the people on this list are paid by the client's
>>>> of the world, but you are still bound by the laws that apply to those
>>>> clients.
>>>>
>>>> Peace ..tom
>>>>
>>>>
>>>> On Mon, Jul 13, 2020 at 12:31 PM Justin Richer  wrote=
:
>>>>
>>>>> A quick note, as my choice of language below seems to have been
>>>>> confusing. First there is a typo, where the word =E2=80=9Cit=E2=80=9D=
 should have been =E2=80=9Cin=E2=80=9D
>>>>> to read:
>>>>>
>>>>> I am saying that GNAP, *in* its definition within this working group,
>>>>> should be limited to identifier claims.
>>>>>
>>>>>
>>>>> And second, there seems to be confusion around whether I=E2=80=99m tr=
ying to
>>>>> argue about the scope =E2=80=9Callowed=E2=80=9D by the charter by say=
ing =E2=80=9Cits definition
>>>>> within this working group=E2=80=9D here.
>>>>>
>>>>> To be clear, we as the working group are *defining* GNAP the
>>>>> protocol. It has not yet been defined, and that=E2=80=99s why were al=
l here. The
>>>>> charter doesn=E2=80=99t define it. The input specs don=E2=80=99t defi=
ne it. The working
>>>>> group defines it, and my stance as a contributor to this WG is that w=
e
>>>>> should focus on a delegation protocol with some basic identifier quer=
y
>>>>> support and leave the full fledged identity protocol to different wor=
k.
>>>>>
>>>>> We=E2=80=99ve already got our hands full here without taking all of t=
hat on,
>>>>> especially since I do believe we need to build GNAP in such a way as =
to
>>>>> facilitate its extension in several known directions, including a ful=
l
>>>>> identity protocol. If we do things right here, we can see GNAP as the=
 basis
>>>>> of a large number of things out there in the world.
>>>>>
>>>>> So my stance in what we should do, as we define GNAP as a protocol, i=
s
>>>>> focus on this one, limited slice of the identity space and not spiral=
 into
>>>>> others.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> On Jul 13, 2020, at 2:51 PM, Justin Richer  wrote:
>>>>>
>>>>> I am saying that GNAP, it its definition within this working group,
>>>>> should be limited to identifier claims. Other claims can come from ot=
her
>>>>> protocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t sto=
p them from
>>>>> being built, but in my opinion we shouldn=E2=80=99t be defining those=
 here. See the
>>>>> discussion below on the extensibility avenues of this approach.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> On Jul 13, 2020, at 2:12 PM, Dick Hardt  wrote:
>>>>>
>>>>> I agree that an API to return claims is useful. I think we have agree=
d
>>>>> on that.
>>>>>
>>>>> Using the SubjectIdentifiers schema is another schema that would be
>>>>> useful for GNAP to support.
>>>>>
>>>>> I disagree that GNAP should be limited to identifier claims.
>>>>>
>>>>> =E1=90=A7
>>>>>
>>>>> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer  wrote=
:
>>>>>
>>>>>> One thing I think we should learn from OIDC is that returning claims
>>>>>> from an API, and not just an assertion or direct response, is a powe=
rful
>>>>>> and useful pattern. We have an opportunity to separate these cleanly=
, where
>>>>>> OIDC didn=E2=80=99t have the opportunity in defining the =E2=80=9Ccl=
aims=E2=80=9D request parameter.
>>>>>>
>>>>>> As an alternative to the current XYZ and XAuth syntaxes, over the
>>>>>> weekend I=E2=80=99ve been playing with something that would look lik=
e this strawman
>>>>>> in the request:
>>>>>>
>>>>>>
>>>>>> {
>>>>>>    subject: {
>>>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=
=80=9Ciss-sub=E2=80=9D],
>>>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifia=
ble_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>>>>    }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> This request says that I=E2=80=99d like some subset of these identif=
iers (as
>>>>>> plain text in the response) and some subset of signed assertions in =
the
>>>>>> given formats. Each one would have an associated space in the return=
. I=E2=80=99m
>>>>>> not picturing that the =E2=80=9Cid=E2=80=9D field values would affec=
t the contents of the
>>>>>> assertions: so I could ask for an email address identifier but get b=
ack an
>>>>>> ID token that had only the subject identifier. Maybe that=E2=80=99s =
not the right
>>>>>> model? But it=E2=80=99s at least simple and deterministic this way, =
and it=E2=80=99s
>>>>>> something to play with.
>>>>>>
>>>>>> Note: The =E2=80=9Cid=E2=80=9D names are taken from
>>>>>> https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05=
.html,
>>>>>> the =E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=99=
t see a source that collected
>>>>>> them. If you wanted specific bundles of claims about the user from a
>>>>>> UserInfoEndpoint, for example, you=E2=80=99d have something like:
>>>>>>
>>>>>> {
>>>>>>    subject: {
>>>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=
=80=9Ciss-sub=E2=80=9D],
>>>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifia=
ble_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>>>>    },
>>>>>>    resources: [{
>>>>>>        type: =E2=80=9Cuserinfo=E2=80=9D,
>>>>>>        datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=
=9D, =E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
>>>>>>   }]
>>>>>> }
>>>>>>
>>>>>>
>>>>>> This is an example for a specific kind of resource, and I don=E2=80=
=99t think
>>>>>> that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, =
or the datatype values
>>>>>> therein. That should be work outside of GNAP, probably for the OIDF.
>>>>>>
>>>>>> This approach is extensible in several ways, each of them for a
>>>>>> specific reason that I think is clear:
>>>>>>
>>>>>>  - new values in the =E2=80=9Cid=E2=80=9D field to give new identifi=
ers
>>>>>>  - new values in the =E2=80=9Cassertion=E2=80=9D field to give new a=
ssertion formats
>>>>>>  - new fields under the =E2=80=9Csubject=E2=80=9D heading
>>>>>>  - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=
=80=9Cscim-v1=E2=80=9D or
>>>>>> =E2=80=9Cfacebook-profile=E2=80=9D for instance)
>>>>>>  - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource type
>>>>>>  - new top-level request parameters
>>>>>>
>>>>>> As per the other thread, if you wanted to use the OIDC query
>>>>>> language, you=E2=80=99d package it separately as a top-level request=
 parameter
>>>>>> since it can include both the ID token response and the access token
>>>>>> response and we shouldn=E2=80=99t be encouraging mixing these things=
 together.
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>> On Jul 10, 2020, at 5:00 PM, Dick Hardt  wrote=
:
>>>>>>
>>>>>> It looks to me that our different views of what is in scope for GNAP
>>>>>> are the differences below.
>>>>>>
>>>>>> Per the subject line, I'm looking at how the client acquires claims
>>>>>> about the user. You don't think that is in scope, and that a differe=
nt
>>>>>> layer will solve that.
>>>>>>
>>>>>> I think we should learn from OIDC being on top of OAuth, and GNAP
>>>>>> should be able return ANY claim, not just identifier claims. There a=
re use
>>>>>> cases that may be difficult to support if we do not have that functi=
onality
>>>>>> in scope, such as some of the ones I list below, and it seems pretty
>>>>>> straightforward to support ANY claim if we are supporting identifier=
s.
>>>>>>
>>>>>> /Dick
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Jul 10, 2020, at 2:15 PM, Dick Hardt 
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> inline ...
>>>>>>>
>>>>>>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yes, the core idea is to not have to parse an assertion to get bac=
k
>>>>>>>> the core authentication information, which consists of an identifi=
er
>>>>>>>> (iss/sub pair in OIDC, but could be a number of things). Sometimes=
 the
>>>>>>>> client is going to want the rest of the identity information, but =
If the
>>>>>>>> user=E2=80=99s logged into the client before, the client has likel=
y cached that
>>>>>>>> info and probably won=E2=80=99t need it, and sending it would be a=
 violation of
>>>>>>>> privacy principles.. The client would want the info pretty much ju=
st in
>>>>>>>> these cases:
>>>>>>>>
>>>>>>>>  1. The client has never seen the user before.
>>>>>>>>  2. The user=E2=80=99s information has been updated since the last=
 time the
>>>>>>>> client saw it.
>>>>>>>>
>>>>>>>
>>>>>>> Agreed
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Now for case (1), how would the client know if it wants to request
>>>>>>>> the user=E2=80=99s profile info or not, since it doesn=E2=80=99t k=
now who the user is?
>>>>>>>>
>>>>>>>
>>>>>>> But the client could know who the user is. The client may have used
>>>>>>> a different AS to authenticate the user.
>>>>>>>
>>>>>>>
>>>>>>> In these cases, the client is not going to be requesting identity
>>>>>>> information from the AS to log the user in, so it=E2=80=99s not rel=
evant to the use
>>>>>>> case. The client will have an opportunity to push that information =
to the
>>>>>>> AS.
>>>>>>>
>>>>>>> The User may have self identified to the client. The client may hav=
e
>>>>>>> a cookie saying who the user was and the user said that was them. W=
hile the
>>>>>>> latter cases are really a strong hint, they are likely right most o=
f the
>>>>>>> time and can lead to a user experience basde on that hint
>>>>>>>
>>>>>>>
>>>>>>> In these cases, the AS might be able to guess if the client has inf=
o
>>>>>>> about the user already, but probably not. And the assumptions fall =
apart if
>>>>>>> it=E2=80=99s in fact a different user that ends up logging in, whic=
h is of course
>>>>>>> possible (the hint you gave doesn=E2=80=99t match the identity of t=
he current user
>>>>>>> after the AS validates them). This possibility leads to clients alw=
ays
>>>>>>> asking for everything every time and the server providing everythin=
g every
>>>>>>> time. That=E2=80=99s a pattern I think we should avoid in an ultima=
te solution =E2=80=94
>>>>>>> but ultimately, I don=E2=80=99t think that this kind of protocol de=
cision is inside
>>>>>>> of GNAP.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> And the AS won=E2=80=99t know if client is going to want the profi=
le info,
>>>>>>>> since the AS won=E2=80=99t know if the client has the user=E2=80=
=99s info or not. Sure, the
>>>>>>>> AS might have seen that client and that user combo previously, but=
 it
>>>>>>>> doesn=E2=80=99t know if the client needs an update.
>>>>>>>>
>>>>>>>
>>>>>>> The client can share with the AS the user it knows or thinks it is
>>>>>>> dealing with, which could let the AS respond if the information was=
 new.
>>>>>>> This could be the case for an AS that is providing claims, but not
>>>>>>> authentication, and could happen silently. The user would only inte=
ract if
>>>>>>> the user information had changed, and the client wanted the updated
>>>>>>> information.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> See above.
>>>>>>>
>>>>>>>
>>>>>>>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s i=
nfo has been
>>>>>>>> updated or not because it doesn=E2=80=99t know who the user is yet=
. If the AS can
>>>>>>>> provide some time of updated stamp to the client, the client can p=
ull the
>>>>>>>> new info when it needs it.
>>>>>>>>
>>>>>>>
>>>>>>> See above.
>>>>>>>
>>>>>>>
>>>>>>> See above.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> If you ignore both of these cases and put all the user information
>>>>>>>> inline with the main request/response, you end up in a situation w=
here the
>>>>>>>> client always requests everything and the server always provides
>>>>>>>> everything, since you can=E2=80=99t be sure you=E2=80=99re not in =
situation (1) or (2)
>>>>>>>> ahead of time.
>>>>>>>>
>>>>>>>
>>>>>>> See above. There are a number of other states the client could be i=
n.
>>>>>>>
>>>>>>> For example, the client could be stateless about user information,
>>>>>>> so it knows it is ALWAYS in state 1.
>>>>>>>
>>>>>>>
>>>>>>> A stateless client would need to fetch appropriate user information
>>>>>>> every time, then. But that=E2=80=99s an optimization for a very spe=
cific case.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> This is really what I mean about the two-stage identity protocol.
>>>>>>>>
>>>>>>>
>>>>>>> I know what it is. Per above, GNAP lets us support a wider set of
>>>>>>> use cases. Why limit ourselves to what OIDC supported?
>>>>>>>
>>>>>>>
>>>>>>> We aren=E2=80=99t limiting the protocol, but instead limiting the s=
cope of
>>>>>>> what we define internal to the GNAP protocol. There=E2=80=99s a lot=
 of room for
>>>>>>> innovation on top of it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> In the first stage, you push the bare minimum of what you need to
>>>>>>>> get the user known to the client. In the second stage, the client =
uses its
>>>>>>>> access token to call an API to get whatever else it needs to know =
about the
>>>>>>>> user.
>>>>>>>>
>>>>>>>
>>>>>>> From a privacy perspective in non-enterprise use cases, I think the
>>>>>>> user should give consent to any updated personal information to a c=
lient.
>>>>>>> In general, the client should not be able to get the latest informa=
tion
>>>>>>> about a user whenever it wants.
>>>>>>>
>>>>>>>
>>>>>>> This is about the rights associated with the access token, then. An=
d
>>>>>>> an access token doesn=E2=80=99t have to keep working if the AS has =
a policy that
>>>>>>> says it won=E2=80=99t. The AS/RS could easily decide that a particu=
lar access token
>>>>>>> will only return data that hasn=E2=80=99t been changed. Maybe it st=
ops working
>>>>>>> after the data changes, or it just returns old data, or any number =
of
>>>>>>> things. This is for the AS/RS to decide and this is pretty standard
>>>>>>> interpretation of the token, nothing special here because we=E2=80=
=99re dealing
>>>>>>> with identity.
>>>>>>>
>>>>>>>  =E2=80=94 Justin
>>>>>>>
>>>>>>>
>>>>>>> /Dick
>>>>>>> =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
>>>>>
>>>>

--0000000000005999d905aae48ba9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Curious: How are you envisioning the client communicates t=
o the AS if it is on the User's phone?
3D""=E1=90=A7
On=
 Sun, Jul 19, 2020 at 9:13 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, that m=
ight work for you. It won=E2=80=99t work for me. I put the as on the user=
=E2=80=99s phone. The source and sink of the data can switch roles on a mil=
lisecond basis. I will track your progress and adopt what I can.

..Tom's phone

On Jul 19, 2020, at 1:45 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
=EF=BB=
=BF
Hi Tom

The proposal is that Client a=
sks for a claim from the AS, the user consents at the AS, and the AS direct=
ly releases the claim directly to the Client. No access token. No resource =
server.=C2=A0

Simpler for Client and Grant Server =
(AS)




=


On Sat, Jul 18, 2020 at 7:34 PM Tom Jones <thomasclinganjones@gmail.com=
> wrote:
=

absolutely, yes, tha az token can authorize=C2=A0any resou=
rce held by the resource server.
The ONLY thing special about PII is th=
e protection granted by the various privacy laws.

=
As an aside, I don't find much in the current discussion that gives me =
a warm feeling about privacy.
The stuff in the torsten tokens is =
about as anti-privacy an effort as exists today.
Identity assuran=
ce does NOT need to be enabled by sending more and yet again more PII.
Peace ..tom
<=
/div>


On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt <<=
a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c=
om> wrote:
Hey Tom

While I thin=
k defining claims=C2=A0is out of scope of the WG, I think enabling a client=
 to obtain claims about a user is in scope.
Would you consid=
er authorization for the release of claims to be part of the purpose of thi=
s WG?

I'm concerned about the=
 XYZ shift to subject identifiers from claims, and pushing claims to a high=
er layer, as it may indicate to developers that they can ONLY ask for a use=
r identifier.=C2=A0

When I think of a claim, I inc=
lude any and all identifiers, but I also include user attributes such as un=
der-13, over-21, student-at-an-accredited-school, resident of city/state/pr=
ovince/country.

GNAP can enable a client to ask fo=
r only the claims it needs, preserving user privacy, and compliance with ma=
ny privacy regulations.

Would you agree?

/Dick




On Sat, Jul 18, 2020 at 9:56 AM Tom Jones <thomasclinganjones@gma=
il.com> wrote:
I agree with Justin's comment "=C2=A0what w=
e should do, as we define GNAP as a protocol, is focus on this one, limited=
 slice of the identity space and not spiral into others."
The titl=
e "Authorization" should rule the purposes of this group above al=
l else.

The earlier statement=C2=A0that the client s=
hould know who the user is - is just plain WRONG. The client should only kn=
ow the information the user is willing to share with the client.
=
It is now the law in California that the client cannot demand=C2=A0identity=
 information that is not required for a legitimate business purpose.
<=
div>There are some clients that act as fiduciaries for the user (financial=
=C2=A0and healthcare come to mind), but as a general rule the "client&=
quot; is not to be trusted by the user.
I understand most of the =
people=C2=A0on this list are paid by the client's of the world, but you=
 are still bound by the laws that apply to those clients.

Peace ..tom


On Mon, Jul 13, 2020 at 12:31 PM Justin Rich=
er <jricher@mit.edu=
> wrote:
=

A quick note, as my choice of language below seems to have been confus=
ing. First there is a typo, where the word =E2=80=9Cit=E2=80=9D should have=
 been =E2=80=9Cin=E2=80=9D to read:

I am saying that GNAP, in its definition within this work=
ing group, should be limited to identifier claims.
<=
br>
And second, there seems to be confusion around whether I=E2=
=80=99m trying to argue about the scope =E2=80=9Callowed=E2=80=9D by the ch=
arter by saying =E2=80=9Cits definition within this working group=E2=80=9D =
here.=C2=A0

To be clear, we as the working group a=
re defining GNAP the protocol. It has not yet been defined, and that=
=E2=80=99s why were all here. The charter doesn=E2=80=99t define it. The in=
put specs don=E2=80=99t define it. The working group defines it, and my sta=
nce as a contributor to this WG is that we should focus on a delegation pro=
tocol with some basic identifier query support and leave the full fledged i=
dentity protocol to different work.=C2=A0

We=E2=80=
=99ve already got our hands full here without taking all of that on, especi=
ally since I do believe we need to build GNAP in such a way as to facilitat=
e its extension in several known directions, including a full identity prot=
ocol. If we do things right here, we can see GNAP as the basis of a large n=
umber of things out there in the world.=C2=A0

So m=
y stance in what we should do, as we define GNAP as a protocol, is focus on=
 this one, limited slice of the identity space and not spiral into others.<=
/div>

=C2=A0=E2=80=94 Justin

On Jul 13, 2020, at 2:51 PM, Justin Richer <jricher@mit.edu> wrote:


I am saying that GNAP, it its definition within this working group, sh=
ould be limited to identifier claims. Other claims can come from other prot=
ocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop them fro=
m being built, but in my opinion we shouldn=E2=80=99t be defining those her=
e. See the discussion below on the extensibility avenues of this approach.<=
div>
=C2=A0=E2=80=94 Justin

On Jul 13, 2020, at 2:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I agree that an API to return claims is useful=
. I think we have agreed on that.=C2=A0

Using the Subjec=
tIdentifiers schema is another schema that would be useful for GNAP to supp=
ort.=C2=A0

I disagree=C2=A0that GNAP should be lim=
ited to identifier claims.=C2=A0

3D""=E1=90=A7

On Mon, Jul 13, 2020 at 7:16 AM Justin Richer <jricher@mit.edu> wrote=
:
One thing=
 I think we should learn from OIDC is that returning claims from an API, an=
d not just an assertion or direct response, is a powerful and useful patter=
n. We have an opportunity to separate these cleanly, where OIDC didn=E2=80=
=99t have the opportunity in defining the =E2=80=9Cclaims=E2=80=9D request =
parameter.

As an alternative to the current XYZ and XAut=
h syntaxes, over the weekend I=E2=80=99ve been playing with something that =
would look like this strawman in the request:


=

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Codic_id_token=
=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
=C2=A0 =C2=A0}
}

T=
his request says that I=E2=80=99d like some subset of these identifiers (as=
 plain text in the response) and some subset of signed assertions in the gi=
ven formats. Each one would have an associated space in the return. I=E2=80=
=99m not picturing that the =E2=80=9Cid=E2=80=9D field values would affect =
the contents of the assertions: so I could ask for an email address identif=
ier but get back an ID token that had only the subject identifier. Maybe th=
at=E2=80=99s not the right model? But it=E2=80=99s at least simple and dete=
rministic this way, and it=E2=80=99s something to play with.

=

Note: The =E2=80=9Cid=E2=80=9D names are taken from=C2=A0https://tools.ietf.org/id/draft-ietf-secevent-subject=
-identifiers-05.html, the =E2=80=9Cassertion=E2=80=9D names are made up=
 as I didn=E2=80=99t see a source that collected them. If you wanted specif=
ic bundles of claims about the user from a UserInfoEndpoint, for example, y=
ou=E2=80=99d have something like:

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Cod=
ic_id_token=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csam=
l" ]
=C2=A0 =C2=A0},
=C2=A0 =
=C2=A0resources: [{
=C2=A0 =C2=A0 =C2=A0 =C2=A0type: =
=E2=80=9Cuserinfo=E2=80=9D,
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =E2=80=
=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
=C2=A0 }]=

}

This is=
 an example for a specific kind of resource, and I don=E2=80=99t think that=
 GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, or the data=
type values therein. That should be work outside of GNAP, probably for the =
OIDF.

This approach is extensible in several ways,=
 each of them for a specific reason that I think is clear:

=C2=A0- new values in the =E2=80=9Cid=E2=80=9D field to give new i=
dentifiers
=C2=A0- new values in the =E2=80=9Cassertion=E2=80=9D =
field to give new assertion formats
=C2=A0- new fields under the =
=E2=80=9Csubject=E2=80=9D heading=C2=A0
=C2=A0- new resource type=
s besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or =E2=
=80=9Cfacebook-profile=E2=80=9D for instance)
=C2=A0- new datatyp=
es within the =E2=80=9Cuserinfo=E2=80=9D resource type
=C2=A0- ne=
w top-level request parameters

As per the other th=
read, if you wanted to use the OIDC query language, you=E2=80=99d package i=
t separately as a top-level request parameter since it can include both the=
 ID token response and the access token response and we shouldn=E2=80=99t b=
e encouraging mixing these things together.

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

On Jul 10, 2020=
, at 5:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It looks to me that our different views of what is in scope for GNAP ar=
e the differences below.

Per the subject line, I'm l=
ooking at how the client acquires claims about the user. You don't thin=
k that is in scope, and that a different layer will solve that.
<=
br>
I think we should learn from OIDC being on top of OAuth, and =
GNAP should be able return ANY claim, not just identifier claims. There are=
 use cases that may be difficult to support if we do not have that function=
ality in scope, such as some of the ones I list below, and it seems pretty =
straightforward to support ANY claim if we are supporting identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09=
 PM Justin Richer <=
jricher@mit.edu> wrote:


On Jul 10, =
2020, at 2:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


inline ...=C2=A0

On Thu, Jul 9, 2020 at 5=
:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea is to not have to parse an assert=
ion to get back the core authentication information, which consists of an i=
dentifier (iss/sub pair in OIDC, but could be a number of things). Sometime=
s the client is going to want the rest of the identity information, but=C2=
=A0If the user=E2=80=99s logged into the client before, the client has like=
ly cached that info and probably won=E2=80=99t need it, and sending it woul=
d be a violation of privacy principles.. The client would want the info pre=
tty much just in these cases:

=C2=A01. The client has ne=
ver seen the user before.=C2=A0
=C2=A02. The user=E2=80=99s infor=
mation has been updated since the last time the client saw it.
<=
/blockquote>

Agreed
=C2=A0

Now for case (=
1), how would the client know if it wants to request the user=E2=80=99s pro=
file info or not, since it doesn=E2=80=99t know who the user is? 

But the client could know who the user i=
s. The client may have used a different AS to authenticate the user. 
=


In these cases, th=
e client is not going to be requesting identity information from the AS to =
log the user in, so it=E2=80=99s not relevant to the use case. The client w=
ill have an opportunity to push that information to the AS.

<=
div>The User may have self identified to the client. The client may have a =
cookie saying who the user was and the user said that was them. While the l=
atter cases are really a strong hint, they are likely right most of the tim=
e and can lead to a user experience basde on that hint

In these cases, the AS might be a=
ble to guess if the client has info about the user already, but probably no=
t. And the assumptions fall apart if it=E2=80=99s in fact a different user =
that ends up logging in, which is of course possible (the hint you gave doe=
sn=E2=80=99t match the identity of the current user after the AS validates =
them). This possibility leads to clients always asking for everything every=
 time and the server providing everything every time. That=E2=80=99s a patt=
ern I think we should avoid in an ultimate solution =E2=80=94 but ultimatel=
y, I don=E2=80=99t think that this kind of protocol decision is inside of G=
NAP.

=C2=A0
And the AS won=E2=80=99t know if client is going to wa=
nt the profile info, since the AS won=E2=80=99t know if the client has the =
user=E2=80=99s info or not. Sure, the AS might have seen that client and th=
at user combo previously, but it doesn=E2=80=99t know if the client needs a=
n update.

The client can share =
with the AS the user it knows or thinks it is dealing with, which could let=
 the AS respond if the information was new. This could be the case for an A=
S that is providing claims, but not authentication, and could happen silent=
ly. The user would only interact if the user information had changed, and t=
he client wanted the updated information.
=C2=A0

See above.


And =
for (2), the client won=E2=80=99t know if the user=E2=80=99s info has been =
updated or not because it doesn=E2=80=99t know who the user is yet. If the =
AS can provide some time of updated stamp to the client, the client can pul=
l the new info when it needs it.

See above.

See a=
bove.

=C2=A0

If you ignore both of these cases=
 and put all the user information inline with the main request/response, yo=
u end up in a situation where the client always requests everything and the=
 server always provides everything, since you can=E2=80=99t be sure you=E2=
=80=99re not in situation (1) or (2) ahead of time.

See above. There are a number of other states the clie=
nt could be in.

For example, the client could be s=
tateless about user information, so it knows it is ALWAYS in state 1.
=


A stateless client=
 would need to fetch appropriate user information every time, then. But tha=
t=E2=80=99s an optimization for a very specific case.

=
=C2=A0
This is really what I mean about the two-stage identity protoco=
l. 

I know what it is. Per abov=
e, GNAP lets us support a wider set of use cases. Why limit ourselves to wh=
at OIDC supported?

We aren=E2=80=99t limiting the protocol, but instead limiting the sco=
pe of what we define internal to the GNAP protocol. There=E2=80=99s a lot o=
f room for innovation on top of it.

=C2=A0
In the first stage, you=
 push the bare minimum of what you need to get the user known to the client=
. In the second stage, the client uses its access token to call an API to g=
et whatever else it needs to know about the user. 
=


From a privacy perspective in non-enterprise use cases,=
 I think the user should give consent to any updated personal information t=
o a client. In general, the=C2=A0client should not be able to get the lates=
t information about a user whenever it wants.
=


This is about the rights associated with t=
he access token, then. And an access token doesn=E2=80=99t have to keep wor=
king if the AS has a policy that says it won=E2=80=99t. The AS/RS could eas=
ily decide that a particular access token will only return data that hasn=
=E2=80=99t been changed. Maybe it stops working after the data changes, or =
it just returns old data, or any number of things. This is for the AS/RS to=
 decide and this is pretty standard interpretation of the token, nothing sp=
ecial here because we=E2=80=99re dealing with identity.

=C2=A0=E2=80=94 Justin

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








-- 
Txauth mailing list
Txauth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/txauth
<=
br>-- 

Txauth mailing list

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







--0000000000005999d905aae48ba9--


From nobody Mon Jul 20 12:46: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 CEEBD3A0E57 for ; Mon, 20 Jul 2020 12:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level: 
X-Spam-Status: No, score=-1.98 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, MALFORMED_FREEMAIL=0.116, MIME_QP_LONG_LINE=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 zY4I2Nsk_-oV for ; Mon, 20 Jul 2020 12:46:49 -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 1C17E3A0E55 for ; Mon, 20 Jul 2020 12:46:49 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id s10so18941939wrw.12 for ; Mon, 20 Jul 2020 12:46:49 -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; bh=RLn64YdY1hXzsjvzCIdHlYKG4fMK5DX4xqrSjtoMnHU=; b=nG8rtaJKtOFyCSryNPMjknbkr6GKQ1/vRtOUfD3ZhzttQss71a3Wxbsv7DTBxwBSWV YR/zZCycAoROoFjzZZCIPNwUO/2ycMUsEGrrbdCAQiK5fdlRU7xuOFdI2JWb1N6mqDd2 sgNlfKDH+tTUlbiRPRJfkCqu79wZl2Peq31QqDLx3cL6ZTyb4nLQdDj/qfA2WTOa7UlI 7Jb9ehMXa3lPaoaugIaEgcl9Q8H7zcJmHuVyjAbmQFKvajGKFzX4J4I/e86TYOv/UkY/ 5xaJ2c6bdn3+Y7mdJ1gKAkhSsOgD0CFVoeIMKDyjHBBJlO3tqZTqTvN9K550s/YwhKz/ hvgA==
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; bh=RLn64YdY1hXzsjvzCIdHlYKG4fMK5DX4xqrSjtoMnHU=; b=igizgSXtCCC+zOPcrVlM0pBS4p0hM87nhVtirLso2Cbh+YbOy2vTJup6rCA84TGMwA wbtFtOgxWHhfypM6QBhqXBsPjlhCtECk8Oa+1Ly0N+x1Vm188e5y3aCwQdwPVoYOWKwh yvEtJ/JvA+oTSrTFuMQWnrx584s0MGUjozYKnCwvZPSlIGI6rZJTj9E87abNUsKgRsjR YgOtBCSG1ZvZK9zF1hkOzRt99d8PyxHkmshYDGh2YSXYMyU4MvW8DTsxAbmfgDY2AgQV E14zfcz1ezLtT5WOfVyYE9MVEncAipgmM5qJIp0NdINv7HuzfbWugNaR4EtpDHb7ikMK ZBjw==
X-Gm-Message-State: AOAM531povUq2hAPJZyLqNuZRUQOUaU7SIwOxbsOKa1J4PUARjv0xi3B n7J0IdeLZ1MkAQtdJRJVHIl6+3Jp
X-Google-Smtp-Source: ABdhPJylBBlyNrhY5j0cz2MiSkWGgJo2XIpidSX1EpEV7LwewGWFjlb1KhA4xcCN65fazWIgG1xLJw==
X-Received: by 2002:a5d:6a8b:: with SMTP id s11mr1639325wru.222.1595274407075;  Mon, 20 Jul 2020 12:46:47 -0700 (PDT)
Received: from [10.0.0.140] (bzq-79-176-11-75.red.bezeqint.net. [79.176.11.75]) by smtp.gmail.com with ESMTPSA id j14sm35049789wrs.75.2020.07.20.12.46.46 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2020 12:46:46 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.39.20071300
Date: Mon, 20 Jul 2020 22:46:45 +0300
From: Yaron Sheffer 
To: "txauth@ietf.org" 
Message-ID: <6CC714D8-2FB2-4BE6-B70B-659C4A8198AB@gmail.com>
Thread-Topic: GNAP agenda uploaded
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3678130006_1959781941"
Archived-At: 
Subject: [Txauth] GNAP agenda uploaded
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, 20 Jul 2020 19:46:51 -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_3678130006_1959781941
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Leif and I uploaded the agenda for next week: https://www.ietf.org/proceedi=
ngs/108/agenda/agenda-108-gnap-00.html

=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


--B_3678130006_1959781941
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Leif and I =
uploaded the agenda for next week: https://www.ietf.org/proceedings/108/ag=
enda/agenda-108-gnap-00.html
 
<=
span style=3D'font-size:11.0pt'>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


--B_3678130006_1959781941--



From nobody Mon Jul 20 15:14:37 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 BB3E53A102C for ; Mon, 20 Jul 2020 15:14:35 -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_FILL_THIS_FORM_SHORT=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 FeeBVJqzRKxx for ; Mon, 20 Jul 2020 15:14:32 -0700 (PDT)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0: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 5A7333A1028 for ; Mon, 20 Jul 2020 15:14:32 -0700 (PDT)
Received: by mail-oi1-x230.google.com with SMTP id 12so15630597oir.4 for ; Mon, 20 Jul 2020 15:14: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=FWv8rczu826K5jBZmEO8e2EphrLkbrc3ZWQeUcMJZoQ=; b=V0HELoZNQWzHWb+q3d+scb+2WAtPcrqFbGUkT5PzXVXXRqbO2jG4aa/UpOqO310KTE huQlWJWB3goF2nGmPU3eC2j7XgIY+bSfBJEcGli80CSRAz/5HvcQqo4cMDLOBmWyh6xR UCv0BJ1/0TUYVwDd5rbFJ85rYxNhbT444FF3gVaGV+OTEAScnAH3K6pSH2HuuJ1xvz9H t8yViPcvmZwp4zXoxuU2QZrQnhIb9jJZpeGtCFTiEdUa3TvkCYu674tAjR0YE5dWyZSf 7EQicc4zjUpOcxQXGqH0rVGsw6jedwNHxr08THgfVkqshzWhF+asHTXgGpsw1SRda0NV rhTg==
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=FWv8rczu826K5jBZmEO8e2EphrLkbrc3ZWQeUcMJZoQ=; b=rPb7H8x0CC/z4RiYGh23JfHT2fg8nJXCLrdPHk9nt3uKCt3peaybn25mtXu45GDCet PbXPq34NriOYmynbvQ6v6ayiTXiymd+H7B66gbW+UQh7i1qzlhc2+GenS3QuiMyk1uvJ v28xZ2mJWS1wdXg7dZxd3muL3RLVfFjpsTxRcd6wV4B8s1y8SIDoVoVy0AmjtQVnhqjB +9/PQE7yY4829+x3HdQEdSOoi0wh4IVL4MHyXhztDMorKcLQQTJtrFp0NxDORnqIrde7 HMf+FpFljy0dSHDWkVoMLrSponTtXI4opA7EwVQZan26hSDDYwv61xR+Ui1NjT6heUF5 /Stg==
X-Gm-Message-State: AOAM532YvJpB6W7s42clJZnhl0cw3fyzWPZQwTE2g/eZD+Mi/Egppge9 vUVb9qlaYD8g++OilDpKxSSTITztYuRgog7sH+8=
X-Google-Smtp-Source: ABdhPJyF8DJyAVIORVO6zyOUWGKiNiUxyemdOtTAFOC4s2rkEEVstUYDFSthsh3gpMCpyq5DBijmxz8LI2jzIZsxBas=
X-Received: by 2002:aca:4b50:: with SMTP id y77mr1033710oia.63.1595283271404;  Mon, 20 Jul 2020 15:14:31 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Tom Jones 
Date: Mon, 20 Jul 2020 15:14:19 -0700
Message-ID: 
To: Dick Hardt 
Cc: Justin Richer , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b5505205aae6d47c"
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 20 Jul 2020 22:14:36 -0000

--000000000000b5505205aae6d47c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

if the user must authorize access to the resource, then what better place
for it than their phone. I don't much worry about inconveniencing some
gigantic corporation.
I should be clear tho, *user agents* do not need to be on user phones, i
was addressing my particular need.
If the user has delegated authority to some cloud based service, then
that *user
agent *could could also host an as.
It is interesting to speculate on whether an IdP (openId provider e.g.)
could ever be a trusted *user agen*t. Given what I understand of the market
today, I guess that is not possible. Markets do, however, change.
Some on the list speculate that the client (sink of user resources) could
be a *user agent*.  That is, at least, problematic, but conceivable.
I, personally, would not conflate a client with a *user agent.* After all,
the user agent has access to (at least some) user accessible resources.
maybe you should just rename the as to be a *user agent.* Or at least state
that the as is an endpoint of a user agent.

BTW, for me a user is an identifier claiming to represent a human at a
device. Whether they are the RO or a guardian is not of importance here. I
know others have other definitions, sorry about that.
Peace ..tom


On Mon, Jul 20, 2020 at 12:30 PM Dick Hardt  wrote:

> Curious: How are you envisioning the client communicates to the AS if it
> is on the User's phone?
> =E1=90=A7
>
> On Sun, Jul 19, 2020 at 9:13 PM Tom Jones 
> wrote:
>
>> Well, that might work for you. It won=E2=80=99t work for me. I put the a=
s on the
>> user=E2=80=99s phone. The source and sink of the data can switch roles o=
n a
>> millisecond basis. I will track your progress and adopt what I can.
>>
>> ..Tom's phone
>>
>> On Jul 19, 2020, at 1:45 PM, Dick Hardt  wrote:
>>
>> =EF=BB=BF
>> Hi Tom
>>
>> The proposal is that Client asks for a claim from the AS, the user
>> consents at the AS, and the AS directly releases the claim directly to t=
he
>> Client. No access token. No resource server.
>>
>> Simpler for Client and Grant Server (AS)
>>
>>
>>
>>
>>
>>
>> On Sat, Jul 18, 2020 at 7:34 PM Tom Jones 
>> wrote:
>>
>>> absolutely, yes, tha az token can authorize any resource held by the
>>> resource server.
>>> The ONLY thing special about PII is the protection granted by the
>>> various privacy laws.
>>>
>>> As an aside, I don't find much in the current discussion that gives me =
a
>>> warm feeling about privacy.
>>> The stuff in the torsten tokens is about as anti-privacy an effort as
>>> exists today.
>>> Identity assurance does NOT need to be enabled by sending more and yet
>>> again more PII.
>>> Peace ..tom
>>>
>>>
>>> On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt  wrote=
:
>>>
>>>> Hey Tom
>>>>
>>>> While I think defining claims is out of scope of the WG, I think
>>>> enabling a client to obtain claims about a user is in scope.
>>>> Would you consider authorization for the release of claims to be part
>>>> of the purpose of this WG?
>>>>
>>>> I'm concerned about the XYZ shift to subject identifiers from claims,
>>>> and pushing claims to a higher layer, as it may indicate to developers=
 that
>>>> they can ONLY ask for a user identifier.
>>>>
>>>> When I think of a claim, I include any and all identifiers, but I also
>>>> include user attributes such as under-13, over-21,
>>>> student-at-an-accredited-school, resident of city/state/province/count=
ry.
>>>>
>>>> GNAP can enable a client to ask for only the claims it needs,
>>>> preserving user privacy, and compliance with many privacy regulations.
>>>>
>>>> Would you agree?
>>>>
>>>> /Dick
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Jul 18, 2020 at 9:56 AM Tom Jones 
>>>> wrote:
>>>>
>>>>> I agree with Justin's comment " what we should do, as we define GNAP
>>>>> as a protocol, is focus on this one, limited slice of the identity sp=
ace
>>>>> and not spiral into others."
>>>>> The title "Authorization" should rule the purposes of this group abov=
e
>>>>> all else.
>>>>>
>>>>> The earlier statement that the client should know who the user is - i=
s
>>>>> just plain WRONG. The client should only know the information the use=
r is
>>>>> willing to share with the client.
>>>>> It is now the law in California that the client cannot demand identit=
y
>>>>> information that is not required for a legitimate business purpose.
>>>>> There are some clients that act as fiduciaries for the user
>>>>> (financial and healthcare come to mind), but as a general rule the "c=
lient"
>>>>> is not to be trusted by the user.
>>>>> I understand most of the people on this list are paid by the client's
>>>>> of the world, but you are still bound by the laws that apply to those
>>>>> clients.
>>>>>
>>>>> Peace ..tom
>>>>>
>>>>>
>>>>> On Mon, Jul 13, 2020 at 12:31 PM Justin Richer 
>>>>> wrote:
>>>>>
>>>>>> A quick note, as my choice of language below seems to have been
>>>>>> confusing. First there is a typo, where the word =E2=80=9Cit=E2=80=
=9D should have been =E2=80=9Cin=E2=80=9D
>>>>>> to read:
>>>>>>
>>>>>> I am saying that GNAP, *in* its definition within this working
>>>>>> group, should be limited to identifier claims.
>>>>>>
>>>>>>
>>>>>> And second, there seems to be confusion around whether I=E2=80=99m t=
rying to
>>>>>> argue about the scope =E2=80=9Callowed=E2=80=9D by the charter by sa=
ying =E2=80=9Cits definition
>>>>>> within this working group=E2=80=9D here.
>>>>>>
>>>>>> To be clear, we as the working group are *defining* GNAP the
>>>>>> protocol. It has not yet been defined, and that=E2=80=99s why were a=
ll here. The
>>>>>> charter doesn=E2=80=99t define it. The input specs don=E2=80=99t def=
ine it. The working
>>>>>> group defines it, and my stance as a contributor to this WG is that =
we
>>>>>> should focus on a delegation protocol with some basic identifier que=
ry
>>>>>> support and leave the full fledged identity protocol to different wo=
rk.
>>>>>>
>>>>>> We=E2=80=99ve already got our hands full here without taking all of =
that on,
>>>>>> especially since I do believe we need to build GNAP in such a way as=
 to
>>>>>> facilitate its extension in several known directions, including a fu=
ll
>>>>>> identity protocol. If we do things right here, we can see GNAP as th=
e basis
>>>>>> of a large number of things out there in the world.
>>>>>>
>>>>>> So my stance in what we should do, as we define GNAP as a protocol,
>>>>>> is focus on this one, limited slice of the identity space and not sp=
iral
>>>>>> into others.
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>> On Jul 13, 2020, at 2:51 PM, Justin Richer  wrote:
>>>>>>
>>>>>> I am saying that GNAP, it its definition within this working group,
>>>>>> should be limited to identifier claims. Other claims can come from o=
ther
>>>>>> protocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t st=
op them from
>>>>>> being built, but in my opinion we shouldn=E2=80=99t be defining thos=
e here. See the
>>>>>> discussion below on the extensibility avenues of this approach.
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>> On Jul 13, 2020, at 2:12 PM, Dick Hardt  wrote=
:
>>>>>>
>>>>>> I agree that an API to return claims is useful. I think we have
>>>>>> agreed on that.
>>>>>>
>>>>>> Using the SubjectIdentifiers schema is another schema that would be
>>>>>> useful for GNAP to support.
>>>>>>
>>>>>> I disagree that GNAP should be limited to identifier claims.
>>>>>>
>>>>>> =E1=90=A7
>>>>>>
>>>>>> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer 
>>>>>> wrote:
>>>>>>
>>>>>>> One thing I think we should learn from OIDC is that returning claim=
s
>>>>>>> from an API, and not just an assertion or direct response, is a pow=
erful
>>>>>>> and useful pattern. We have an opportunity to separate these cleanl=
y, where
>>>>>>> OIDC didn=E2=80=99t have the opportunity in defining the =E2=80=9Cc=
laims=E2=80=9D request parameter.
>>>>>>>
>>>>>>> As an alternative to the current XYZ and XAuth syntaxes, over the
>>>>>>> weekend I=E2=80=99ve been playing with something that would look li=
ke this strawman
>>>>>>> in the request:
>>>>>>>
>>>>>>>
>>>>>>> {
>>>>>>>    subject: {
>>>>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=
=80=9Ciss-sub=E2=80=9D],
>>>>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifi=
able_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>>>>>    }
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> This request says that I=E2=80=99d like some subset of these identi=
fiers (as
>>>>>>> plain text in the response) and some subset of signed assertions in=
 the
>>>>>>> given formats. Each one would have an associated space in the retur=
n. I=E2=80=99m
>>>>>>> not picturing that the =E2=80=9Cid=E2=80=9D field values would affe=
ct the contents of the
>>>>>>> assertions: so I could ask for an email address identifier but get =
back an
>>>>>>> ID token that had only the subject identifier. Maybe that=E2=80=99s=
 not the right
>>>>>>> model? But it=E2=80=99s at least simple and deterministic this way,=
 and it=E2=80=99s
>>>>>>> something to play with.
>>>>>>>
>>>>>>> Note: The =E2=80=9Cid=E2=80=9D names are taken from
>>>>>>> https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-0=
5.html,
>>>>>>> the =E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=
=99t see a source that collected
>>>>>>> them. If you wanted specific bundles of claims about the user from =
a
>>>>>>> UserInfoEndpoint, for example, you=E2=80=99d have something like:
>>>>>>>
>>>>>>> {
>>>>>>>    subject: {
>>>>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=
=80=9Ciss-sub=E2=80=9D],
>>>>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverifi=
able_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>>>>>    },
>>>>>>>    resources: [{
>>>>>>>        type: =E2=80=9Cuserinfo=E2=80=9D,
>>>>>>>        datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=
=80=9D, =E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
>>>>>>>   }]
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> This is an example for a specific kind of resource, and I don=E2=80=
=99t
>>>>>>> think that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema=
 here, or the datatype
>>>>>>> values therein. That should be work outside of GNAP, probably for t=
he OIDF.
>>>>>>>
>>>>>>> This approach is extensible in several ways, each of them for a
>>>>>>> specific reason that I think is clear:
>>>>>>>
>>>>>>>  - new values in the =E2=80=9Cid=E2=80=9D field to give new identif=
iers
>>>>>>>  - new values in the =E2=80=9Cassertion=E2=80=9D field to give new =
assertion formats
>>>>>>>  - new fields under the =E2=80=9Csubject=E2=80=9D heading
>>>>>>>  - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=
=80=9Cscim-v1=E2=80=9D or
>>>>>>> =E2=80=9Cfacebook-profile=E2=80=9D for instance)
>>>>>>>  - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource typ=
e
>>>>>>>  - new top-level request parameters
>>>>>>>
>>>>>>> As per the other thread, if you wanted to use the OIDC query
>>>>>>> language, you=E2=80=99d package it separately as a top-level reques=
t parameter
>>>>>>> since it can include both the ID token response and the access toke=
n
>>>>>>> response and we shouldn=E2=80=99t be encouraging mixing these thing=
s together.
>>>>>>>
>>>>>>>  =E2=80=94 Justin
>>>>>>>
>>>>>>> On Jul 10, 2020, at 5:00 PM, Dick Hardt 
>>>>>>> wrote:
>>>>>>>
>>>>>>> It looks to me that our different views of what is in scope for GNA=
P
>>>>>>> are the differences below.
>>>>>>>
>>>>>>> Per the subject line, I'm looking at how the client acquires claims
>>>>>>> about the user. You don't think that is in scope, and that a differ=
ent
>>>>>>> layer will solve that.
>>>>>>>
>>>>>>> I think we should learn from OIDC being on top of OAuth, and GNAP
>>>>>>> should be able return ANY claim, not just identifier claims. There =
are use
>>>>>>> cases that may be difficult to support if we do not have that funct=
ionality
>>>>>>> in scope, such as some of the ones I list below, and it seems prett=
y
>>>>>>> straightforward to support ANY claim if we are supporting identifie=
rs.
>>>>>>>
>>>>>>> /Dick
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 10, 2020, at 2:15 PM, Dick Hardt 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> inline ...
>>>>>>>>
>>>>>>>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Yes, the core idea is to not have to parse an assertion to get
>>>>>>>>> back the core authentication information, which consists of an id=
entifier
>>>>>>>>> (iss/sub pair in OIDC, but could be a number of things). Sometime=
s the
>>>>>>>>> client is going to want the rest of the identity information, but=
 If the
>>>>>>>>> user=E2=80=99s logged into the client before, the client has like=
ly cached that
>>>>>>>>> info and probably won=E2=80=99t need it, and sending it would be =
a violation of
>>>>>>>>> privacy principles.. The client would want the info pretty much j=
ust in
>>>>>>>>> these cases:
>>>>>>>>>
>>>>>>>>>  1. The client has never seen the user before.
>>>>>>>>>  2. The user=E2=80=99s information has been updated since the las=
t time
>>>>>>>>> the client saw it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Agreed
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Now for case (1), how would the client know if it wants to reques=
t
>>>>>>>>> the user=E2=80=99s profile info or not, since it doesn=E2=80=99t =
know who the user is?
>>>>>>>>>
>>>>>>>>
>>>>>>>> But the client could know who the user is. The client may have use=
d
>>>>>>>> a different AS to authenticate the user.
>>>>>>>>
>>>>>>>>
>>>>>>>> In these cases, the client is not going to be requesting identity
>>>>>>>> information from the AS to log the user in, so it=E2=80=99s not re=
levant to the use
>>>>>>>> case. The client will have an opportunity to push that information=
 to the
>>>>>>>> AS.
>>>>>>>>
>>>>>>>> The User may have self identified to the client. The client may
>>>>>>>> have a cookie saying who the user was and the user said that was t=
hem.
>>>>>>>> While the latter cases are really a strong hint, they are likely r=
ight most
>>>>>>>> of the time and can lead to a user experience basde on that hint
>>>>>>>>
>>>>>>>>
>>>>>>>> In these cases, the AS might be able to guess if the client has
>>>>>>>> info about the user already, but probably not. And the assumptions=
 fall
>>>>>>>> apart if it=E2=80=99s in fact a different user that ends up loggin=
g in, which is of
>>>>>>>> course possible (the hint you gave doesn=E2=80=99t match the ident=
ity of the
>>>>>>>> current user after the AS validates them). This possibility leads =
to
>>>>>>>> clients always asking for everything every time and the server pro=
viding
>>>>>>>> everything every time. That=E2=80=99s a pattern I think we should =
avoid in an
>>>>>>>> ultimate solution =E2=80=94 but ultimately, I don=E2=80=99t think =
that this kind of
>>>>>>>> protocol decision is inside of GNAP.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> And the AS won=E2=80=99t know if client is going to want the prof=
ile info,
>>>>>>>>> since the AS won=E2=80=99t know if the client has the user=E2=80=
=99s info or not. Sure, the
>>>>>>>>> AS might have seen that client and that user combo previously, bu=
t it
>>>>>>>>> doesn=E2=80=99t know if the client needs an update.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The client can share with the AS the user it knows or thinks it is
>>>>>>>> dealing with, which could let the AS respond if the information wa=
s new.
>>>>>>>> This could be the case for an AS that is providing claims, but not
>>>>>>>> authentication, and could happen silently. The user would only int=
eract if
>>>>>>>> the user information had changed, and the client wanted the update=
d
>>>>>>>> information.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> See above.
>>>>>>>>
>>>>>>>>
>>>>>>>>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s =
info has been
>>>>>>>>> updated or not because it doesn=E2=80=99t know who the user is ye=
t. If the AS can
>>>>>>>>> provide some time of updated stamp to the client, the client can =
pull the
>>>>>>>>> new info when it needs it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> See above.
>>>>>>>>
>>>>>>>>
>>>>>>>> See above.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you ignore both of these cases and put all the user informatio=
n
>>>>>>>>> inline with the main request/response, you end up in a situation =
where the
>>>>>>>>> client always requests everything and the server always provides
>>>>>>>>> everything, since you can=E2=80=99t be sure you=E2=80=99re not in=
 situation (1) or (2)
>>>>>>>>> ahead of time.
>>>>>>>>>
>>>>>>>>
>>>>>>>> See above. There are a number of other states the client could be
>>>>>>>> in.
>>>>>>>>
>>>>>>>> For example, the client could be stateless about user information,
>>>>>>>> so it knows it is ALWAYS in state 1.
>>>>>>>>
>>>>>>>>
>>>>>>>> A stateless client would need to fetch appropriate user informatio=
n
>>>>>>>> every time, then. But that=E2=80=99s an optimization for a very sp=
ecific case.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is really what I mean about the two-stage identity protocol.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I know what it is. Per above, GNAP lets us support a wider set of
>>>>>>>> use cases. Why limit ourselves to what OIDC supported?
>>>>>>>>
>>>>>>>>
>>>>>>>> We aren=E2=80=99t limiting the protocol, but instead limiting the =
scope of
>>>>>>>> what we define internal to the GNAP protocol. There=E2=80=99s a lo=
t of room for
>>>>>>>> innovation on top of it.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> In the first stage, you push the bare minimum of what you need to
>>>>>>>>> get the user known to the client. In the second stage, the client=
 uses its
>>>>>>>>> access token to call an API to get whatever else it needs to know=
 about the
>>>>>>>>> user.
>>>>>>>>>
>>>>>>>>
>>>>>>>> From a privacy perspective in non-enterprise use cases, I think th=
e
>>>>>>>> user should give consent to any updated personal information to a =
client.
>>>>>>>> In general, the client should not be able to get the latest inform=
ation
>>>>>>>> about a user whenever it wants.
>>>>>>>>
>>>>>>>>
>>>>>>>> This is about the rights associated with the access token, then.
>>>>>>>> And an access token doesn=E2=80=99t have to keep working if the AS=
 has a policy
>>>>>>>> that says it won=E2=80=99t. The AS/RS could easily decide that a p=
articular access
>>>>>>>> token will only return data that hasn=E2=80=99t been changed. Mayb=
e it stops
>>>>>>>> working after the data changes, or it just returns old data, or an=
y number
>>>>>>>> of things. This is for the AS/RS to decide and this is pretty stan=
dard
>>>>>>>> interpretation of the token, nothing special here because we=E2=80=
=99re dealing
>>>>>>>> with identity.
>>>>>>>>
>>>>>>>>  =E2=80=94 Justin
>>>>>>>>
>>>>>>>>
>>>>>>>> /Dick
>>>>>>>> =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
>>>>>>
>>>>>

--000000000000b5505205aae6d47c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


if the user must authorize access to the resource, then wh=
at better place for it than their phone. I don't much worry about incon=
veniencing some gigantic corporation.
I should be clear tho, user ag=
ents do not need to be on user phones, i was addressing my particular n=
eed.
If the user has delegated authority to some cloud=C2=A0based=
 service, then that user agent could could also host an as.
It is interesting=C2=A0to speculate on whether an IdP (openId provider e.=
g.) could ever be a trusted user agent. Given what I understand of t=
he market today, I guess=C2=A0that is not possible. Markets do, however, ch=
ange.
Some on the list speculate that the client (sink of user re=
sources) could be a user agent.=C2=A0 That is, at least, problematic=
, but conceivable. I,=C2=A0personally, would not conflate a client with a <=
u>user agent. After all, the user agent has access to (at least some) u=
ser accessible resources.
maybe you should just rename the as to =
be a user agent. Or at least state that the as is an endpoint of a u=
ser agent.

BTW, for me a user is an identifier cla=
iming to represent a human at a device. Whether they are the RO or a guardi=
an is not of importance here. I know others have other definitions, sorry a=
bout that.
Peace ..tom
=



On Mon, Jul 20, 2020 at 12:30 PM Dick Hardt &=
lt;dick.hardt@gmail.com> wro=
te:
Curious: How are you envisioning the client communicates to the AS if =
it is on the User's phone?
3D""=E1=90=A7
On Sun, =
Jul 19, 2020 at 9:13 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
=
Well, that might work for you. It won=E2=80=99t work for me. I put the as o=
n the user=E2=80=99s phone. The source and sink of the data can switch role=
s on a millisecond basis. I will track your progress and adopt what I can.<=
br>
..Tom's phone

On Jul 19, 2020, at 1:45 PM, Dick Hardt <dick.hardt@gmail.com> =
wrote:

=EF=BB=BF
Hi Tom

The proposal is that C=
lient asks for a claim from the AS, the user consents at the AS, and the AS=
 directly releases the claim directly to the Client. No access token. No re=
source server.=C2=A0

Simpler for Client and Grant =
Server (AS)






On Sat, Jul 18, 2020 at 7:34 PM Tom Jones <thomasclinganjones@gm=
ail.com> wrote:
absolutely, yes, tha az token can authorize=C2=A0an=
y resource held by the resource server.
The ONLY thing special about PI=
I is the protection granted by the various privacy laws.

As an aside, I don't find much in the current discussion that gi=
ves me a warm feeling about privacy.
The stuff in the torsten tok=
ens is about as anti-privacy an effort as exists today.
Identity =
assurance does NOT need to be enabled by sending more and yet again more PI=
I.
Peace ..tom=



On Sat, Jul 18, 2020 at 5:58 PM Dick Hard=
t <dick.hardt@=
gmail.com> wrote:
Hey Tom

Whi=
le I think defining claims=C2=A0is out of scope of the WG, I think enabling=
 a client to obtain claims about a user is in scope.
Would y=
ou consider authorization for the release of claims to be part of the purpo=
se of this WG?

I'm concerned =
about the XYZ shift to subject identifiers from claims, and pushing claims =
to a higher layer, as it may indicate to developers that they can ONLY ask =
for a user identifier.=C2=A0

When I think of a cla=
im, I include any and all identifiers, but I also include user attributes s=
uch as under-13, over-21, student-at-an-accredited-school, resident of city=
/state/province/country.

GNAP can enable a client =
to ask for only the claims it needs, preserving user privacy, and complianc=
e with many privacy regulations.

Would you agree?<=
/div>

/Dick




On Sat, Jul 18, 2020 at 9:56 AM Tom Jones <thomasclinganjo=
nes@gmail.com> wrote:
I agree with Justin's comment "=C2=
=A0what we should do, as we define GNAP as a protocol, is focus on this one=
, limited slice of the identity space and not spiral into others."The title "Authorization" should rule the purposes of this group=
 above all else.

The earlier statement=C2=A0that the=
 client should know who the user is - is just plain WRONG. The client shoul=
d only know the information the user is willing to share with the client.
It is now the law in California that the client cannot demand=C2=
=A0identity information that is not required for a legitimate business purp=
ose.
There are some clients that act as fiduciaries for the user =
(financial=C2=A0and healthcare come to mind), but as a general rule the &qu=
ot;client" is not to be trusted by the user.
I understand mo=
st of the people=C2=A0on this list are paid by the client's of the worl=
d, but you are still bound by the laws that apply to those clients.

Peace ..to=
m


On Mon, Jul 13, 2020 at 12:31 PM J=
ustin Richer <jrich=
er@mit.edu> wrote:
A quick note, as my choice of language below seems to have =
been confusing. First there is a typo, where the word =E2=80=9Cit=E2=80=9D =
should have been =E2=80=9Cin=E2=80=9D to read:

I am saying that GNAP, in its definition withi=
n this working group, should be limited to identifier claims.

And second, there seems to be confusion around whe=
ther I=E2=80=99m trying to argue about the scope =E2=80=9Callowed=E2=80=9D =
by the charter by saying =E2=80=9Cits definition within this working group=
=E2=80=9D here.=C2=A0

To be clear, we as the worki=
ng group are defining GNAP the protocol. It has not yet been defined=
, and that=E2=80=99s why were all here. The charter doesn=E2=80=99t define =
it. The input specs don=E2=80=99t define it. The working group defines it, =
and my stance as a contributor to this WG is that we should focus on a dele=
gation protocol with some basic identifier query support and leave the full=
 fledged identity protocol to different work.=C2=A0

We=E2=80=99ve already got our hands full here without taking all of that =
on, especially since I do believe we need to build GNAP in such a way as to=
 facilitate its extension in several known directions, including a full ide=
ntity protocol. If we do things right here, we can see GNAP as the basis of=
 a large number of things out there in the world.=C2=A0

So my stance in what we should do, as we define GNAP as a protocol, i=
s focus on this one, limited slice of the identity space and not spiral int=
o others.

=C2=A0=E2=80=94 Justin

On Jul 13, 2020, at 2:51 PM, Justin Richer <jricher@mit.edu> =
wrote:



I am saying that GNAP, it its definition within this working group, sh=
ould be limited to identifier claims. Other claims can come from other prot=
ocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop them fro=
m being built, but in my opinion we shouldn=E2=80=99t be defining those her=
e. See the discussion below on the extensibility avenues of this approach.<=
div>
=C2=A0=E2=80=94 Justin

On Jul 13, 2020, at 2:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I agree that an API to return claims is useful=
. I think we have agreed on that.=C2=A0

Using the Subjec=
tIdentifiers schema is another schema that would be useful for GNAP to supp=
ort.=C2=A0

I disagree=C2=A0that GNAP should be lim=
ited to identifier claims.=C2=A0

3D""=E1=90=A7

On Mon, Jul 13, 2020 at 7:16 AM Justin Richer <jricher@mit.edu> wrote=
:
One thing=
 I think we should learn from OIDC is that returning claims from an API, an=
d not just an assertion or direct response, is a powerful and useful patter=
n. We have an opportunity to separate these cleanly, where OIDC didn=E2=80=
=99t have the opportunity in defining the =E2=80=9Cclaims=E2=80=9D request =
parameter.

As an alternative to the current XYZ and XAut=
h syntaxes, over the weekend I=E2=80=99ve been playing with something that =
would look like this strawman in the request:


=

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Codic_id_token=
=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
=C2=A0 =C2=A0}
}

T=
his request says that I=E2=80=99d like some subset of these identifiers (as=
 plain text in the response) and some subset of signed assertions in the gi=
ven formats. Each one would have an associated space in the return. I=E2=80=
=99m not picturing that the =E2=80=9Cid=E2=80=9D field values would affect =
the contents of the assertions: so I could ask for an email address identif=
ier but get back an ID token that had only the subject identifier. Maybe th=
at=E2=80=99s not the right model? But it=E2=80=99s at least simple and dete=
rministic this way, and it=E2=80=99s something to play with.

=

Note: The =E2=80=9Cid=E2=80=9D names are taken from=C2=A0https://tools.ietf.org/id/draft-ietf-secevent-subject=
-identifiers-05.html, the =E2=80=9Cassertion=E2=80=9D names are made up=
 as I didn=E2=80=99t see a source that collected them. If you wanted specif=
ic bundles of claims about the user from a UserInfoEndpoint, for example, y=
ou=E2=80=99d have something like:

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Cod=
ic_id_token=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csam=
l" ]
=C2=A0 =C2=A0},
=C2=A0 =
=C2=A0resources: [{
=C2=A0 =C2=A0 =C2=A0 =C2=A0type: =
=E2=80=9Cuserinfo=E2=80=9D,
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =E2=80=
=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
=C2=A0 }]=

}

This is=
 an example for a specific kind of resource, and I don=E2=80=99t think that=
 GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, or the data=
type values therein. That should be work outside of GNAP, probably for the =
OIDF.

This approach is extensible in several ways,=
 each of them for a specific reason that I think is clear:

=C2=A0- new values in the =E2=80=9Cid=E2=80=9D field to give new i=
dentifiers
=C2=A0- new values in the =E2=80=9Cassertion=E2=80=9D =
field to give new assertion formats
=C2=A0- new fields under the =
=E2=80=9Csubject=E2=80=9D heading=C2=A0
=C2=A0- new resource type=
s besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or =E2=
=80=9Cfacebook-profile=E2=80=9D for instance)
=C2=A0- new datatyp=
es within the =E2=80=9Cuserinfo=E2=80=9D resource type
=C2=A0- ne=
w top-level request parameters

As per the other th=
read, if you wanted to use the OIDC query language, you=E2=80=99d package i=
t separately as a top-level request parameter since it can include both the=
 ID token response and the access token response and we shouldn=E2=80=99t b=
e encouraging mixing these things together.

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

On Jul 10, 2020=
, at 5:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It looks to me that our different views of what is in scope for GNAP ar=
e the differences below.

Per the subject line, I'm l=
ooking at how the client acquires claims about the user. You don't thin=
k that is in scope, and that a different layer will solve that.
<=
br>
I think we should learn from OIDC being on top of OAuth, and =
GNAP should be able return ANY claim, not just identifier claims. There are=
 use cases that may be difficult to support if we do not have that function=
ality in scope, such as some of the ones I list below, and it seems pretty =
straightforward to support ANY claim if we are supporting identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09=
 PM Justin Richer <=
jricher@mit.edu> wrote:


On Jul 10, =
2020, at 2:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


inline ...=C2=A0

On Thu, Jul 9, 2020 at 5=
:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea is to not have to parse an assert=
ion to get back the core authentication information, which consists of an i=
dentifier (iss/sub pair in OIDC, but could be a number of things). Sometime=
s the client is going to want the rest of the identity information, but=C2=
=A0If the user=E2=80=99s logged into the client before, the client has like=
ly cached that info and probably won=E2=80=99t need it, and sending it woul=
d be a violation of privacy principles.. The client would want the info pre=
tty much just in these cases:

=C2=A01. The client has ne=
ver seen the user before.=C2=A0
=C2=A02. The user=E2=80=99s infor=
mation has been updated since the last time the client saw it.
<=
/blockquote>

Agreed
=C2=A0

Now for case (=
1), how would the client know if it wants to request the user=E2=80=99s pro=
file info or not, since it doesn=E2=80=99t know who the user is? 

But the client could know who the user i=
s. The client may have used a different AS to authenticate the user. 
=


In these cases, th=
e client is not going to be requesting identity information from the AS to =
log the user in, so it=E2=80=99s not relevant to the use case. The client w=
ill have an opportunity to push that information to the AS.

<=
div>The User may have self identified to the client. The client may have a =
cookie saying who the user was and the user said that was them. While the l=
atter cases are really a strong hint, they are likely right most of the tim=
e and can lead to a user experience basde on that hint

In these cases, the AS might be a=
ble to guess if the client has info about the user already, but probably no=
t. And the assumptions fall apart if it=E2=80=99s in fact a different user =
that ends up logging in, which is of course possible (the hint you gave doe=
sn=E2=80=99t match the identity of the current user after the AS validates =
them). This possibility leads to clients always asking for everything every=
 time and the server providing everything every time. That=E2=80=99s a patt=
ern I think we should avoid in an ultimate solution =E2=80=94 but ultimatel=
y, I don=E2=80=99t think that this kind of protocol decision is inside of G=
NAP.

=C2=A0
And the AS won=E2=80=99t know if client is going to wa=
nt the profile info, since the AS won=E2=80=99t know if the client has the =
user=E2=80=99s info or not. Sure, the AS might have seen that client and th=
at user combo previously, but it doesn=E2=80=99t know if the client needs a=
n update.

The client can share =
with the AS the user it knows or thinks it is dealing with, which could let=
 the AS respond if the information was new. This could be the case for an A=
S that is providing claims, but not authentication, and could happen silent=
ly. The user would only interact if the user information had changed, and t=
he client wanted the updated information.
=C2=A0

See above.


And =
for (2), the client won=E2=80=99t know if the user=E2=80=99s info has been =
updated or not because it doesn=E2=80=99t know who the user is yet. If the =
AS can provide some time of updated stamp to the client, the client can pul=
l the new info when it needs it.

See above.

See a=
bove.

=C2=A0

If you ignore both of these cases=
 and put all the user information inline with the main request/response, yo=
u end up in a situation where the client always requests everything and the=
 server always provides everything, since you can=E2=80=99t be sure you=E2=
=80=99re not in situation (1) or (2) ahead of time.

See above. There are a number of other states the clie=
nt could be in.

For example, the client could be s=
tateless about user information, so it knows it is ALWAYS in state 1.
=


A stateless client=
 would need to fetch appropriate user information every time, then. But tha=
t=E2=80=99s an optimization for a very specific case.

=
=C2=A0
This is really what I mean about the two-stage identity protoco=
l. 

I know what it is. Per abov=
e, GNAP lets us support a wider set of use cases. Why limit ourselves to wh=
at OIDC supported?

We aren=E2=80=99t limiting the protocol, but instead limiting the sco=
pe of what we define internal to the GNAP protocol. There=E2=80=99s a lot o=
f room for innovation on top of it.

=C2=A0
In the first stage, you=
 push the bare minimum of what you need to get the user known to the client=
. In the second stage, the client uses its access token to call an API to g=
et whatever else it needs to know about the user. 
=


From a privacy perspective in non-enterprise use cases,=
 I think the user should give consent to any updated personal information t=
o a client. In general, the=C2=A0client should not be able to get the lates=
t information about a user whenever it wants.
=


This is about the rights associated with t=
he access token, then. And an access token doesn=E2=80=99t have to keep wor=
king if the AS has a policy that says it won=E2=80=99t. The AS/RS could eas=
ily decide that a particular access token will only return data that hasn=
=E2=80=99t been changed. Maybe it stops working after the data changes, or =
it just returns old data, or any number of things. This is for the AS/RS to=
 decide and this is pretty standard interpretation of the token, nothing sp=
ecial here because we=E2=80=99re dealing with identity.

=C2=A0=E2=80=94 Justin

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







-- 
Txauth mailing list
Txauth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/txauth
<=
br>-- 

Txauth mailing list

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








--000000000000b5505205aae6d47c--


From nobody Mon Jul 20 18:01: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 883443A1254 for ; Mon, 20 Jul 2020 18:01:22 -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 7C3CJDeznTJO for ; Mon, 20 Jul 2020 18:01:20 -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 8D6103A1252 for ; Mon, 20 Jul 2020 18:01:20 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id r12so19425349wrj.13 for ; Mon, 20 Jul 2020 18:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google;  h=mime-version:from:date:message-id:subject:to:cc; bh=FCTFSiGKLovDUk8FLoOgMX3xkBxNIm19DMIMYLNAPeU=; b=TrimfxJIWLk9TfU1Vw7L9DVlrU67TENxLTG1kkhlqHc/wyXSgCAGJw/0eBTwQ/cPkB jKpX0S/EPXHsQJTVmHoiIqLBCHeJX19552RRBJyx8CA8OpqLIjHsVqLv587b0I3poSMo u2W+sU1AYU9BKRLSD7nzkHJ1vebMLTjNy3jcU=
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:cc; bh=FCTFSiGKLovDUk8FLoOgMX3xkBxNIm19DMIMYLNAPeU=; b=nY3xZO/vkF4ZlA3dWt182cYv4CNy7gbYNgWEQNbf7zVldE3/lulvn0cLR3BzIKy/VA sX/WQ7vG+0TZThLtgagLP+2ktBvLPHAJtuLA6MIz0wMPKM2BQcjTJWscSUv3DQNt8/db xjtfajHaUw2U0Nr0S0NaKDaO8/wNCTnevfBbJaDNvk+yjiTGPngWNWmjSDYbkZPGV2S+ lsJ6oCrIKqtGp8/ia4pqgJM6rhu9dVyhvHltBsP/8psqVM6fklNuuT45giYOQfZRPvws VNaEQDLjD2aQ5MrCNjdIDc4/QE9mM1pWogbKdhSFNgbpdhmu36KO/WwEs3PEM5/UoVVB 8/jA==
X-Gm-Message-State: AOAM530qDr1A73pTojmxSDRuHxHmVllkfBoBh4e7PR0QsLsXhDaekRVo QwF3GviDzxyKVr+7h7MAnFdYBQKUijdXP+2NMjR786FrI+8=
X-Google-Smtp-Source: ABdhPJwQAHYrtosl0niL8L2kQ8d5fOP6SYxZLa4O2h4JmT3KFFkkbz38fgAFvYX25Ror2/yQwg2CIUZFXTYZ4iJNHHI=
X-Received: by 2002:a5d:51c3:: with SMTP id n3mr14979766wrv.104.1595293278317;  Mon, 20 Jul 2020 18:01:18 -0700 (PDT)
MIME-Version: 1.0
From: Francis Pouatcha 
Date: Mon, 20 Jul 2020 21:01:07 -0400
Message-ID: 
To: txauth@ietf.org
Cc: Dick Hardt 
Content-Type: multipart/alternative; boundary="0000000000002ac94805aae9293e"
Archived-At: 
Subject: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 21 Jul 2020 01:01:23 -0000

--0000000000002ac94805aae9293e
Content-Type: text/plain; charset="UTF-8"

Hello Dick,

Here is (in a new thread) the promised attempt to define terms of interest
in the GNAP protocol.

Party - represents a role in the GNAP protocol flow. A party can take the
form of a web service, an application installed on the user device and
acting autonomously or the form of a natural person (resp. of an autonomous
device) using an application to interact with other parties.

Resource - a piece of data or web service
      - controlled by a Resource Owner (RO),
      - held and guarded by a Resource Server (RS) and
      - serviced by the RS to a Client, if the Client provides a valid
Authorization.

Resource Owner (RO) - the party that
      - owns a Resource,
      - relies on the services the GS to manage access to that Resource and
      - relies on the services of a RS to hold the Resource and guard
access to that Resource.

Resource Server (RS) - the party that
      - holds a resource and guards access to that resource on behalf of
the RO,
      - services the Resource to the requesting Client, provided the Client
presents a valid Authorization.
      The RS is generally deployed as a web service.

Grant Server (GS) - the party that manages access to a Resource on behalf
of the RO. For each Resource access request, the GS might request the
consent of the RO and produce a corresponding Authorization that is given
to the requesting Client.

Consent - act of an RO approving the release of a Resource he owns to a
Client.

Grant - material form of an RO Consent. In order not to interact with the
RO on each Resource access request, the GS might store the RO Consent in
the form of a Grant for reuse.

Authorization - externalized form of a Grant as known to the GS and the RS.
      - The GS converts a Grant into an Authorization for use in a Resource
access request.
      - The RS evaluates an Authorization to decide on whether or not to
release the Resource to the Client.

Client - the party that provides the infrastructure used by a User to
access a Resource. The client infrastructure is designed to:
      - Receive the resource access request from the User,
      - Interact with the RS to discover authorization requirements,
      - Interact with the GS to obtain an Authorization to access the
Resource,
      - Interact with the RS to access the Resource on behalf of the User.

User - the party using the infrastructure of the Client to gain access to a
Resource.

This dictionary is supposed to be the base for further discussions that
will allow us to provide each term with just enough description to reduce
ambiguities and misunderstandings in further exchanges. I intentionally
omitted the specification of the type and nature of each party (For example
Client / Registered Client / Dynamic Client). Such elaborations belong IMO
in proper subsections.

Comments are welcome.

Best regards.
-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--0000000000002ac94805aae9293e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Dick,

Here is (in a new thread) t=
he promised attempt=C2=A0to define terms of interest in the GNAP protocol. =

=C2=A0
Party - represents a role in the GNAP protocol =
flow. A party can take the form of a web service, an application installed =
on the user device and acting autonomously or the form of a natural person =
(resp. of an autonomous device) using an application to interact with other=
 parties.

Resource - a piece of data or web service
=C2=A0 =C2=A0=
 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - he=
ld and guarded by a Resource Server (RS) and
=C2=A0 =C2=A0 =C2=A0 - serv=
iced by the RS to a Client, if the Client provides a valid Authorization.
Resource Owner (RO) - the party that 
=C2=A0 =C2=A0 =C2=A0 - owns =
a Resource, 
=C2=A0 =C2=A0 =C2=A0 - relies on the services the GS to man=
age access to that Resource and 
=C2=A0 =C2=A0 =C2=A0 - relies on the se=
rvices of a RS to hold the Resource and guard access to that Resource.
<=
br>
Resource Server (RS) - the party that=C2=A0
=C2=A0 =C2=A0 =
=C2=A0 - holds a resource and guards access to that resource on behalf of t=
he RO,
=C2=A0 =C2=A0 =C2=A0 - services the Resource to the requesting Cl=
ient, provided the Client presents a valid Authorization.
=C2=A0 =C2=A0 =
=C2=A0 The RS is generally deployed as a web service.

Grant Server (=
GS) - the party that manages access to a Resource on behalf of the RO. For =
each Resource access request, the GS might request the consent of the RO an=
d produce a corresponding Authorization that is given to the requesting Cli=
ent.

Consent - act of an RO approving the release of a Resource he o=
wns to a Client.

Grant - material form of an RO Consent. In order no=
t to interact with the RO on each Resource access request, the GS might sto=
re the RO Consent in the form of a Grant for reuse.

Authorization - =
externalized form of a Grant as known to the GS and the RS.
=C2=A0 =C2=
=A0 =C2=A0 - The GS converts a Grant into an Authorization for use=C2=A0in =
a Resource access request.
=C2=A0 =C2=A0 =C2=A0 - The RS evaluates an Au=
thorization to decide on whether or not to release the Resource to the Clie=
nt.

Client - the party that provides the infrastructure used by a Us=
er to access a Resource. The client infrastructure is designed to:
=C2=
=A0 =C2=A0 =C2=A0 - Receive the resource access request from the User,
=
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to discover authorization requi=
rements,
=C2=A0 =C2=A0 =C2=A0 - Interact with the GS to obtain an Author=
ization to access the Resource,
=C2=A0 =C2=A0 =C2=A0 - Interact with the=
 RS to access the Resource on behalf of the User.

User - the party u=
sing the infrastructure of the Client to gain access to a Resource.

This dictionary is supposed to be the base for further di=
scussions that will allow us to provide each term with just enough descript=
ion to reduce ambiguities and misunderstandings in further exchanges. I int=
entionally omitted the specification of the type and nature of each party (=
For example Client / Registered Client / Dynamic Client). Such elaborations=
 belong IMO in proper subsections.

Comments are we=
lcome.

Best regards.
-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsy=
s GmbH & Co. KG


--0000000000002ac94805aae9293e--


From nobody Mon Jul 20 19:30: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 94C563A12F2 for ; Mon, 20 Jul 2020 19:30:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 M81a5EPYMKEL for ; Mon, 20 Jul 2020 19:30:48 -0700 (PDT)
Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0: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 B4E933A12F1 for ; Mon, 20 Jul 2020 19:30:48 -0700 (PDT)
Received: by mail-oi1-x22f.google.com with SMTP id h17so16044034oie.3 for ; Mon, 20 Jul 2020 19:30: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=McdVSZDwHLSZo3LITj810yKCOSQ1f+gk6+xskp5E4lc=; b=oeVAC1WqqHlKvvpca2Va/9RyOaY0paUmANRJ3PeJkG5YA4gkTFvKDHl2uGhzWBvLEi Lofar6BEAYIW8LqkmhnuK6sVJtF+2wmHz96OrxzT/gUVdnYYThepsZ+G6nl9dDcUxDD1 7UeB+Y+zMxQMByyfCJ2+Q3UOB2bP/PePEVRBEejfLvHan724OjTXu7yWPliiNIuhMcj2 GObXE/hwxsM2Z/iLi6hvTX5OlqGmXxwfEjYeN9tFDAKbBrzTz6DWO+blFrNmsv5m2q5D HxR3oZbDeQCVHK7NKhcca0n6cUbYn0Ca27TRyAEqlDbEyOCxq23P/FNj/FmCW8tro1Rx wURA==
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=McdVSZDwHLSZo3LITj810yKCOSQ1f+gk6+xskp5E4lc=; b=dflSEpVe96SE5ySgYCxxANHGtJvluj/sDSBLncbLJtxSk9z9/a0VBdOlDVQpO33aYt 6w1+ru5QL0FMsq71lU9n9OvT3Cp5itwOMF/ZESZ83cox+alxxVXvOwZ9fs0KPesxM+WH udxNprYDTOMqyAp/vJPAw2Zu77CFftO2J3R5BjnG2RIHU/Z4bI1zoq9xGBSHXmiYw1e3 ESKfPs/BjxePaZtYWiWUNeFZ51zwexBj/gusRS7stVw2SZH+o13NrLUIlm1J4DbI5oM/ 4OfuBfdHLqaOOMhN4j1wixf4JRLL3cSAEHXUERXpuic8Whs+oUnXtnA4iieq3lJnnAyz 1dNA==
X-Gm-Message-State: AOAM532g5jKHQXhxr8LR3CzyUMRu69KBUS24ynb5uGuUB9fUPtmSf01O dg3Hnr5OkBiXDffBnB2ocWbXBIpAYUVff2qtlk4=
X-Google-Smtp-Source: ABdhPJxKQtz7ScQUWTkn0DxgGQmMSWbmbBucBvAmEEuMTZLpGLtNETdX0ZZhtpjXsor4OBNK/XIhX0J7x/lJ5pNhNmo=
X-Received: by 2002:aca:aa57:: with SMTP id t84mr1620797oie.131.1595298647963;  Mon, 20 Jul 2020 19:30:47 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Tom Jones 
Date: Mon, 20 Jul 2020 19:30:35 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: txauth@ietf.org, Dick Hardt 
Content-Type: multipart/alternative; boundary="00000000000039003405aaea69b0"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 21 Jul 2020 02:30:51 -0000

--00000000000039003405aaea69b0
Content-Type: text/plain; charset="UTF-8"

that sounds like a good start - some points.
1. Many of the statements, like the RO owns the data, are technically or
legally incorrect, but i think we know what you mean. - controls access
might be more appropo.
2. the user may be a delegate of the RO and have some sort of token that
proves his authority. It would be interesting to know if that token is in
scope.  If not perhaps I can find someone else to own it.
Peace ..tom


On Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha  wrote:

> Hello Dick,
>
> Here is (in a new thread) the promised attempt to define terms of interest
> in the GNAP protocol.
>
> Party - represents a role in the GNAP protocol flow. A party can take the
> form of a web service, an application installed on the user device and
> acting autonomously or the form of a natural person (resp. of an autonomous
> device) using an application to interact with other parties.
>
> Resource - a piece of data or web service
>       - controlled by a Resource Owner (RO),
>       - held and guarded by a Resource Server (RS) and
>       - serviced by the RS to a Client, if the Client provides a valid
> Authorization.
>
> Resource Owner (RO) - the party that
>       - owns a Resource,
>       - relies on the services the GS to manage access to that Resource
> and
>       - relies on the services of a RS to hold the Resource and guard
> access to that Resource.
>
> Resource Server (RS) - the party that
>       - holds a resource and guards access to that resource on behalf of
> the RO,
>       - services the Resource to the requesting Client, provided the
> Client presents a valid Authorization.
>       The RS is generally deployed as a web service.
>
> Grant Server (GS) - the party that manages access to a Resource on behalf
> of the RO. For each Resource access request, the GS might request the
> consent of the RO and produce a corresponding Authorization that is given
> to the requesting Client.
>
> Consent - act of an RO approving the release of a Resource he owns to a
> Client.
>
> Grant - material form of an RO Consent. In order not to interact with the
> RO on each Resource access request, the GS might store the RO Consent in
> the form of a Grant for reuse.
>
> Authorization - externalized form of a Grant as known to the GS and the RS.
>       - The GS converts a Grant into an Authorization for use in a
> Resource access request.
>       - The RS evaluates an Authorization to decide on whether or not to
> release the Resource to the Client.
>
> Client - the party that provides the infrastructure used by a User to
> access a Resource. The client infrastructure is designed to:
>       - Receive the resource access request from the User,
>       - Interact with the RS to discover authorization requirements,
>       - Interact with the GS to obtain an Authorization to access the
> Resource,
>       - Interact with the RS to access the Resource on behalf of the User.
>
> User - the party using the infrastructure of the Client to gain access to
> a Resource.
>
> This dictionary is supposed to be the base for further discussions that
> will allow us to provide each term with just enough description to reduce
> ambiguities and misunderstandings in further exchanges. I intentionally
> omitted the specification of the type and nature of each party (For example
> Client / Registered Client / Dynamic Client). Such elaborations belong IMO
> in proper subsections.
>
> Comments are welcome.
>
> Best regards.
> --
> 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
>

--00000000000039003405aaea69b0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


that sounds like a good start - some points.
1. Many o=
f the statements, like the RO owns the data, are technically or legally inc=
orrect, but i think we know what you mean. - controls access might be more =
appropo.
2. the user may be a delegate of the RO and have some so=
rt of token that proves his authority. It would be interesting to know if t=
hat token is in scope.=C2=A0 If not perhaps I can find someone else to own =
it.
Peace ..tom
<=
/div>


On Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha <f=
po=3D40adorsys.de@dmarc.ietf=
.org> wrote:
Hello Dick,

Here is (in a new threa=
d) the promised attempt=C2=A0to define terms of interest in the GNAP protoc=
ol. 
=C2=A0
Party - represents a role in the GNAP proto=
col flow. A party can take the form of a web service, an application instal=
led on the user device and acting autonomously or the form of a natural per=
son (resp. of an autonomous device) using an application to interact with o=
ther parties.

Resource - a piece of data or web service
=C2=A0 =
=C2=A0 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=
=A0 - held and guarded by a Resource Server (RS) and
=C2=A0 =C2=A0 =C2=
=A0 - serviced by the RS to a Client, if the Client provides a valid Author=
ization.

Resource Owner (RO) - the party that 
=C2=A0 =C2=A0 =C2=
=A0 - owns a Resource, 
=C2=A0 =C2=A0 =C2=A0 - relies on the services th=
e GS to manage access to that Resource and 
=C2=A0 =C2=A0 =C2=A0 - relie=
s on the services of a RS to hold the Resource and guard access to that Res=
ource.

Resource Server (RS) - the party that=C2=A0
=C2=
=A0 =C2=A0 =C2=A0 - holds a resource and guards access to that resource on =
behalf of the RO,
=C2=A0 =C2=A0 =C2=A0 - services the Resource to the re=
questing Client, provided the Client presents a valid Authorization.
=C2=
=A0 =C2=A0 =C2=A0 The RS is generally deployed as a web service.

Gra=
nt Server (GS) - the party that manages access to a Resource on behalf of t=
he RO. For each Resource access request, the GS might request the consent o=
f the RO and produce a corresponding Authorization that is given to the req=
uesting Client.

Consent - act of an RO approving the release of a Re=
source he owns to a Client.

Grant - material form of an RO Consent. =
In order not to interact with the RO on each Resource access request, the G=
S might store the RO Consent in the form of a Grant for reuse.

Autho=
rization - externalized form of a Grant as known to the GS and the RS.
=
=C2=A0 =C2=A0 =C2=A0 - The GS converts a Grant into an Authorization for us=
e=C2=A0in a Resource access request.
=C2=A0 =C2=A0 =C2=A0 - The RS evalu=
ates an Authorization to decide on whether or not to release the Resource t=
o the Client.

Client - the party that provides the infrastructure us=
ed by a User to access a Resource. The client infrastructure is designed to=
:
=C2=A0 =C2=A0 =C2=A0 - Receive the resource access request from the Us=
er,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to discover authorizatio=
n requirements,
=C2=A0 =C2=A0 =C2=A0 - Interact with the GS to obtain an=
 Authorization to access the Resource,
=C2=A0 =C2=A0 =C2=A0 - Interact w=
ith the RS to access the Resource on behalf of the User.

User - the =
party using the infrastructure of the Client to gain access to a Resource.<=
/div>

This dictionary is supposed to be the base for fur=
ther discussions that will allow us to provide each term with just enough d=
escription to reduce ambiguities and misunderstandings in further exchanges=
. I intentionally omitted the specification of the type and nature of each =
party (For example Client / Registered Client / Dynamic Client). Such elabo=
rations belong IMO in proper subsections.

Comments=
 are welcome.

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

-- 

Txauth mailing list

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




--00000000000039003405aaea69b0--


From nobody Tue Jul 21 05: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 3E9753A07FB for ; Tue, 21 Jul 2020 05:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.63
X-Spam-Level: 
X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, 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 LlhokfIeGRMf for ; Tue, 21 Jul 2020 05:53:20 -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 38AC13A07F9 for ; Tue, 21 Jul 2020 05:53:19 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d34 with ME id 5otG230062bcEcA03otGYp; Tue, 21 Jul 2020 14:53:17 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 21 Jul 2020 14:53:17 +0200
X-ME-IP: 90.79.51.120
To: Francis Pouatcha 
Cc: Dick Hardt , txauth@ietf.org
References:              <8b08ff35-f1d5-ee65-c89a-c1f3191ae5b6@free.fr> 
From: Denis 
Message-ID: <90ef4919-ab50-4e90-9e4b-78a9ab06096d@free.fr>
Date: Tue, 21 Jul 2020 14:53:16 +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="------------F1D57AEE172FF9E595170C7B"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 21 Jul 2020 12:53:22 -0000

This is a multi-part message in MIME format.
--------------F1D57AEE172FF9E595170C7B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Francis,

> Hello Denis,
>
>>>
>>>             The good news first: we are making some progress. We are
>>>             now close to an agreement with steps (1) up to (3),
>>>             ... except that the place where the user consent is
>>>             captured is not mentioned/indicated.
>>>
>>
>>         This major question which is currently left unanswered is
>>         where, when and how the user consent is captured.
>>
> There is nothing like a User consent. It is essential for further 
> discussions to use the correct keywords.

The draft defines a user as "the person interacting with the Client". 
The User consent is the very first property related to privacy principles.
It is mentioned in clause 5.2  "Consent and choice" from ISO 29100. 
Before the release of personal attributes to a RS, the consent of the 
person
holding these personal attributes must  be obtained. Unfortunately, 
since this stage is not mentioned in the draft, it is very unlikely that
implementers will even think to implement it.

> Clarification 1: User vs. RO
> 1. User interacts with Client
> 2. RO interacts with GS

No. A RO interacts with its RS. Before any access, the RO defines the 
authorization conditions at the RS.
Once it is done, any client that fulfils these authorization conditions 
will be granted an access.

> Clarification 2: Consent vs. AuthZ (Authorization)
> 1. Consent is given by RO to GS and used to produce an Authz.

No. There is no need for a RO to interact with a GS.

> 2. AuthZ is given by GS to Client and used by Client to access 
> Resource at RS interface on behalf of User.

Authz is a set of attributes released to a Client in an access token. 
There is no need to have any RO involvement in that process.

>
> Modified Question: where, when and how the "RO" Consent is captured?
>
> Answer:
> how: Consent is given by the RO to the GS.
> where: Depend of interaction mode.
> when: before step (5).
>
>>
>>         Another important point to consider and to explain is related
>>         to the assurances that the user can obtain about
>>         the respect of his choices. This point is currently left
>>         unanswered in draft-hardt-xauth-protocol-13.
>>
>     [Denis] These two major points are still left unanswered at this time.
>
> I do not understand the question.

If access tokens are considered to be opaque to the client, then the 
client can verify that the "Consent and choices"
formulated by the user (i.e. person) have indeed been taken into 
consideration. On the contrary, if access tokens are
considered to be opaque to the client, such assurance cannot be obtained 
by the client and hence the user.

>>
>>>
>>>             If a RO needs to be involved and since a RO is directly
>>>             associated with a RS, why can't it be directly queried
>>>             by the appropriate RS after step (2) or later on ?
>>>
>>>
>>>         Good question. Perhaps you can expand on a use case where
>>>         that would be useful?
>>
>>         Before I expand, would you be able to explain first under
>>         which circumstances a RO needs to be queried by a GS ?
>>
>>     In all circumstances. Can you name a situation where this is not
>>     the case?
>
>     [Denis] This is quite easy. The final decision is always taken by
>     the RS. If a Client presents access tokens issued by ASs trusted
>     by the RS
>     that contain appropriate attributes to perform the requested
>     operation, then the operation is allowed.
>
> We should be using GS instead of AS to avoid confusion.
>
>     If really a human RO needs to be involved for whatever reason, it
>     is possible to get its involvement when the Client connects to the
>     RS.
>     However such involvement does not need to be formalized by a
>     protocol. It can be application specific.
>
> Client has no Relationship with the RO.
>
> There is no reference to a human here. User, Client, RS, GS, RO are 
> all roles. Nothing states the type of participants they are.

A user is currently defined as a person. The case of a "client 
application" interacting with the system through a Client
should however also be addressed. Both a user and a client application 
are interacting with the system through a Client.

>>         How can the GS identify which RO to query ?
>>
>>     There is supposed to be a preexisting relationship between GS and
>>     RO, If not RO will have to register with GS in the first
>>     interaction (onboarding).
>>
>>     How can the GS identify how to connect with RO?
>>     GS must evaluate the RS provided info in step (3)
>>     AuthZRequest(AuthZChallenge) to decide how to contact the RO.
>>     This is where selection of interaction mode takes place.
>
>     [Denis] This means that a GS must have prior relationships with
>     the RSs and ROs.
>
> No. Evaluating an AuthZChallenge to discover the RO:
> - does not assume GS knows RS.
> - does not presume RS knows GS.

Your position is in contradiction with the response from the editor of 
this draft (Dick) who wrote:

    If the RO is a separate entity, then the GS knows the RO from the RS
    being queried.

In order to discover the RO, the GS must know who the the RS is. 
However, while being necessary, this is insufficient. The GS must
be able to authenticate the RO and to associate it with the RS and there 
is no reason why this information shall necessarily be made
publicly available. Hence, this is why prior relationships between GSs 
and RSs/ROs  are necessary and this makes the whole architecture
complicated whereas it can be quite simple when the RO only interacts 
with its RS.

> - GS will generally have to know RO, as RO delegates the work to 
> produce authorizations on his behalf to GS.
> - RS will generally have to know RO, as RO custodies his Resources 
> with RS and trusts RS to only release it to authorized parties.
>
> How do you establish a contract without contracting parties knowing 
> each other?
>
>     While this should not be prevented for backward compatibility with
>     OAuth 2.0, this should not be the single case.
>     Prior relationships between ROs and GSs is a door half-opened for
>     Big Brother.
>     If in addition the GS is able to know which operation is attempted
>     by the client on which RSs, then it is a door wide-opened for Big
>     Brother.
>
> I do not understand this. GS is working for RO.

A GS is not "working for" any RO. A GS when receiving an access token 
request does not even know whether it should contact or not a RO.

>>>             Which information is supposed to be presented to the RO ?
>>>             Which information is supposed to be returned by the RO ?
>>>
>>>
>>>         Just like how the user authenticates to an AS, how the AS
>>>         and RO communicate is out of scope.
>>
>>         At the moment, the usefulness of a dialogue between a GS and
>>         a RO has not been explained, nor demonstrated.
>>         The question is about the functionality of that dialogue in
>>         terms of input and output information (and not about
>>         the design of a protocol or of a user interface). Anyway,
>>         AFAIU a dialogue between a GS and a RO is optional.
>>
>>>         For many use cases, the User is the RO, and the interaction
>>>         is through a user interface, not a machine protocol.
>>
>>         Wait a second. You wrote "the User is the RO". The User is
>>         attempting to make an access to a RS by using a Client.
>>         _That_ User is not the RO of the RS.
>>
>>     The User interacts with the Client.
>>     The RO interacts with the GS.
>>
>>     In some use cases (where we use redirect interaction) we assume
>>     the person controlling the "User-Agent" is also the person
>>     controlling the "RO-Agent" and they reside on the same device.
>>     These are cases where we say User equals RO.
>
>     [Denis] Sorry, I have difficulties to understand such a case. A
>     person giving his consent to himself ?
>
> We do not have people here, but roles.
> RO is consenting
>   - that the Client can access his Resource
>   - on behalf of the User [optional].
>
> So RO and User are different roles, even if they are sometimes assumed 
> by the same human/device/machine/...

If, prior to any access, authorization conditions are well defined and 
managed by the RO of the RS, then the RO does not need to be involved
in real time, in particular at the time of an access of a client.

Denis

> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/



--------------F1D57AEE172FF9E595170C7B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Francis,

    


    

    

      
      

        
Hello Denis,

        

        

          

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                

                                  


                                  

                                  
The good news first: we are
                                    making some progress. We are now
                                    close to an agreement with steps (1)
                                    up to (3), 

                                    ... except that the place where the
                                    user consent is captured is not
                                    mentioned/indicated.

                                

                              

                            

                          

                        

                        

                        This major question which is currently left
                        unanswered is where, when and how the user
                        consent is captured.

                      

                    

                  

                

              

            

          

          
There is nothing like a User consent. It is essential for
            further discussions to use the correct keywords.

        

      

    

    
The draft defines a user as "the person interacting with the
      Client". The User consent is the very first property related to
      privacy principles. 

      It is mentioned in clause 5.2  "Consent and choice" from ISO
      29100. Before the release of personal attributes to a RS, the
      consent of the person 

      holding these personal attributes must  be obtained.
      Unfortunately, since this stage is not mentioned in the draft, it
      is very unlikely that 

      implementers will even think to implement it. 

    

    

      

        

          
Clarification 1: User vs. RO

          

            
1. User interacts with Client 

            
2. RO interacts with GS

          

        

      

    

    
No. A RO interacts with its RS. Before any access, the RO defines
      the authorization conditions at the RS. 

      Once it is done, any client that fulfils these authorization
      conditions will be granted an access.

    

      

        

          

            

              
Clarification 2: Consent vs. AuthZ (Authorization)

              
1. Consent is given by RO to GS and used to produce
                an Authz.

            

          

        

      

    

    
No. There is no need for a RO to interact with a GS.

    

      

        

          

            

              
2. AuthZ is given by GS to Client and used by Client
                to access Resource at RS interface on behalf of User.

            

          

        

      

    

    
Authz is a set of attributes released to a Client in an access
      token. There is no need to have any RO involvement in that
      process.

    

      

        

          


          

          
Modified Question: where, when and how the "RO" Consent
            is captured?

          


          

          
Answer: 

          
how: Consent is given by the RO to the GS. 

          
where: Depend of interaction mode.

          
when: before step (5).

          

            

              

                

                  

                    

                      
 

                        Another important point to consider and to
                        explain is related to the assurances that the
                        user can obtain about 

                        the respect of his choices. This point is
                        currently left unanswered in
                        draft-hardt-xauth-protocol-13.

                      

                    

                  

                

              

              
[Denis] These two major points are still left
                unanswered at this time.

            

          

          
I do not understand the question. 

          

        

      

    

    
If access tokens are considered to be opaque to the client, then
      the client can verify that the "Consent and choices" 

      formulated by the user (i.e. person) have indeed been taken into
      consideration. On the contrary, if access tokens are 

      considered to be opaque to the client, such assurance cannot be
      obtained by the client and hence the user.

    

      

        

          

            

              

                

                  

                    

                      
 

                        

                          

                            

                              

                                

                                  


                                  

                                  
If a RO needs to be involved and
                                    since a RO is directly associated
                                    with a RS, why can't it be directly
                                    queried 

                                    by the appropriate RS after step (2)
                                    or later on ?

                                

                              

                              


                              

                              
Good question. Perhaps you can expand
                                on a use case where that would be
                                useful?

                            

                          

                        

                        
Before I expand, would you be able to explain
                          first under which circumstances a RO needs to
                          be queried by a GS ?

                        

                      

                    

                    
In all circumstances. Can you name a situation
                      where this is not the case?

                  

                

              

              
[Denis] This is quite easy. The final decision is
                always taken by the RS. If a Client presents access
                tokens issued by ASs trusted by the RS 

                that contain appropriate attributes to perform the
                requested operation, then the operation is allowed. 

              

            

          

          
We should be using GS instead of AS to avoid confusion. 

          

            

              
 

              
If really a human RO needs to be involved for whatever
                reason, it is possible to get its involvement when the
                Client connects to the RS. 

                However such involvement does not need to be formalized
                by a protocol. It can be application specific.

              

            

          

          
Client has no Relationship with the RO. 

          


          

          
There is no reference to a human here. User, Client, RS,
            GS, RO are all roles. Nothing states the type of
            participants they are.

        

      

    

    
A user is currently defined as a person. The case of a "client
      application" interacting with the system through a Client 

      should however also be addressed. Both a user and a client
      application are interacting with the system through a Client. 

    

      

        

          

            

              
 

              

                

                  

                    

                      

                        
 How can the GS identify which RO to query ?

                        

                      

                    

                    
There is supposed to be a preexisting
                      relationship between GS and RO, If not RO will
                      have to register with GS in the first interaction
                      (onboarding).

                    


                    

                    
How can the GS identify how to connect with RO?

                    
GS must evaluate the RS provided info in step
                      (3) AuthZRequest(AuthZChallenge) to decide how to
                      contact the RO. This is where selection of
                      interaction mode takes place.

                    

                  

                

              

              
[Denis] This means that a GS must have prior
                relationships with the RSs and ROs. 

            

          

          
No. Evaluating an AuthZChallenge to discover the RO:

          
- does not assume GS knows RS. 

          
- does not presume RS knows GS.

        

      

    

    
Your position is in contradiction with the response from the
      editor of this draft (Dick) who wrote:

    

      
If the RO is a separate entity, then the GS knows the RO from
        the RS being queried.

    

    
In order to discover the RO, the GS must know who the the RS is.
      However, while being necessary, this is insufficient. The GS must
      

      be able to authenticate the RO and to associate it with the RS and
      there is no reason why this information shall necessarily be made
      

      publicly available. Hence, this is why prior relationships between
      GSs and RSs/ROs  are necessary and this makes the whole
      architecture 

      complicated whereas it can be quite simple when the RO only
      interacts with its RS.

    

      

        

          
- GS will generally have to know RO, as RO delegates the
            work to produce authorizations on his behalf to GS.

          
- RS will generally have to know RO, as RO custodies his
            Resources with RS and trusts RS to only release it to
            authorized parties.

          


          

          
How do you establish a contract without contracting
            parties knowing each other?

          

            

              
While this should not be prevented for backward
                compatibility with OAuth 2.0, this should not be the
                single case. 

                Prior relationships between ROs and GSs is a door
                half-opened for Big Brother. 

                If in addition the GS is able to know which operation is
                attempted by the client on which RSs, then it is a door
                wide-opened for Big Brother.

            

          

          
I do not understand this. GS is working for RO.

        

      

    

    
A GS is not "working for" any RO. A GS when receiving an access
      token request does not even know whether it should contact or not
      a RO.

    

      

        

          

            

              

                

                  

                    

                      

                        

                          

                            

                              
 

                              

                                

                                  
Which information is supposed to
                                    be presented to the RO ?

                                    Which information is supposed to be
                                    returned by the RO ?

                                

                              

                              


                              

                              
Just like how the user authenticates
                                to an AS, how the AS and RO communicate
                                is out of scope.

                              

                            

                          

                        

                        
At the moment, the usefulness of a dialogue
                          between a GS and a RO has not been explained,
                          nor demonstrated.

                          The question is about the functionality of
                          that dialogue in terms of input and output
                          information (and not about 

                          the design of a protocol or of a user
                          interface). Anyway, AFAIU a dialogue between a
                          GS and a RO is optional.

                        

                        

                          

                            

                              
For many use cases, the User is the
                                RO, and the interaction is through a
                                user interface, not a machine protocol.
                                

                              

                            

                          

                        

                        
Wait a second. You wrote "the User is the
                          RO". The User is attempting to make an access
                          to a RS by using a Client. 

                          That User is not the RO of the RS.   

                          

                        

                      

                    

                    
The User interacts with the Client.

                    
The RO interacts with the GS.

                    


                    

                    
In some use cases (where we use redirect
                      interaction) we assume the person controlling the
                      "User-Agent" is also the person 

                      controlling the "RO-Agent" and they reside on the
                      same device. These are cases where we say User
                      equals RO.

                  

                

              

              
[Denis] Sorry, I have difficulties to understand such a
                case. A person giving his consent to himself ?

            

          

          
We do not have people here, but roles. 

          
RO is consenting

          
  - that the Client can access his Resource 

          
  - on behalf of the User [optional]. 

          


          

          
So RO and User are different roles, even if they are
            sometimes assumed by the same human/device/machine/...

        

      

    

    
If, prior to any access, authorization conditions are well
      defined and managed by the RO of the RS, then the RO does not need
      to be involved 

      in real time, in particular at the time of an access of a client.

    
Denis

    

      
-- 

        

          

            

              

                

                  

                    

                      

                        

                          
Francis Pouatcha

                          
Co-Founder and Technical Lead

                          
adorsys GmbH & Co. KG

                          
                        

                      

                    

                  

                

              

            

          

        

      

    

    


    

  


--------------F1D57AEE172FF9E595170C7B--


From nobody Tue Jul 21 06:03: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 78E113A084C for ; Tue, 21 Jul 2020 06:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.629
X-Spam-Level: 
X-Spam-Status: No, score=-1.629 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.267, NICE_REPLY_A=-0.001, 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 4dkaNvehLkrB for ; Tue, 21 Jul 2020 06:03:33 -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 4696C3A0847 for ; Tue, 21 Jul 2020 06:03:32 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d34 with ME id 5p3V2300P2bcEcA03p3W0F; Tue, 21 Jul 2020 15:03:30 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 21 Jul 2020 15:03:30 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt 
Cc: Francis Pouatcha , txauth@ietf.org
References:               
From: Denis 
Message-ID: <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>
Date: Tue, 21 Jul 2020 15:03:30 +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="------------F19537259E37EA6D43357774"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 21 Jul 2020 13:03:36 -0000

This is a multi-part message in MIME format.
--------------F19537259E37EA6D43357774
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Dick,

I duplicate the most important comment at the beginning of this email:

    You are considering using an access control model to build
    a**workflow model.
    **
    While it may be interesting to define a workflow model, this should
    be considered
    as a separate and different work item.

See the other comments between the lines.

> On Mon, Jul 20, 2020 at 2:05 AM Denis  > wrote:
>
>     Hi Dick,
>
>>     On Fri, Jul 17, 2020 at 9:21 AM Denis >     > wrote:
>>
>>         Hello Francis and Dick,
>>
>>         The good news first: we are making some progress. We are now
>>         close to an agreement with steps (1) up to (3),
>>         ... except that the place where the user consent is captured
>>         is not mentioned/indicated.
>>
>
>     This major question which is currently left unanswered is where,
>     when and how the user consent is captured.
>
>
> When is covered, per the sequence. How and where are out of scope of 
> what I drafted.

It is clear that the "User consent and choice" is not currently 
addressed in the draft, but it should.
The support of the "User consent and choice" has strong implications not 
only in the sequences of the exchanges
but also by which entity it should be performed.

>
>     Another important point to consider and to explain is related to
>     the assurances that the user can obtain about
>     the respect of his choices. This point is currently left
>     unanswered in draft-hardt-xauth-protocol-13.
>
This point is equally important: such assurance can only be obtained if 
the access token returned to the client
is not considered to be opaque to the client. This is a necessary 
condition but not the single condition:
the Client must also be in a position to capture/memorize the "User 
consent and choice" of the user in order to be able
to verify it afterwards using the content of the access token(s).

>
>>         If a RO needs to be involved and since a RO is directly
>>         associated with a RS, why can't it be directly queried
>>         by the appropriate RS after step (2) or later on ?
>>
>>
>>     Good question. Perhaps you can expand on a use case where that
>>     would be useful?
>
>     Before I expand, would you be able to explain first under which
>     circumstances a RO needs to be queried by a GS ?
>     How can the GS identify which RO to query ?
>
> If the User is the RO, then the GS knows who to query.

I still have difficulties to understand what you mean here.
How could a GS know that "the User is the RO" ?  If "the User is the 
RO", why does the GS needs to query the User ?

> If the RO is a separate entity, then the GS knows the RO from the RS 
> being queried.

  ... and this gives the ability for the GS to log/trace all the RSs 
accessed by a given User and at which instant of time the access token 
has been granted.

> An example is a user would like access to an enterprise asset where a 
> workflow is started to gain approval, and an administrator or manager 
> provides consent.

Thanks for this example. I finally understand what you have in mind: you 
are considering using an access control model to build a *workflow model*.
While it may be interesting to define a workflow model, this should be 
considered as a *separate and different work item*.

The model you propose may be suited for an enterprise environment but is 
not scalable over the Internet.
What is needed is an access control model usable over the Internet with 
millions of RSs and thousands of ASs/GSs.

>>         Which information is supposed to be presented to the RO ?
>>         Which information is supposed to be returned by the RO ?
>>
>>
>>     Just like how the user authenticates to an AS, how the AS and RO
>>     communicate is out of scope.
>
>     At the moment, the usefulness of a dialogue between a GS and a RO
>     has not been explained, nor demonstrated.
>     The question is about the functionality of that dialogue in terms
>     of input and output information (and not about
>     the design of a protocol or of a user interface). Anyway, AFAIU a
>     dialogue between a GS and a RO is optional.
>
>
> See enterprise example above.

It is not an access control example, but a workflow example.

Access  control has been defined a long time ago and the last edition of 
the model has been confirmed in year 1996: ISO/IEC 10181-3: 1996.
"Information technology — Open Systems Interconnection — Security 
frameworks for open systems: Access control framework — Part 3".

Two major functions have ben defined: an AccessControl Enforcement 
Function (AEF) and an AccessControl Decision Function(ADF).

    AccessControl Enforcement Function (AEF):
    A specialized function that is part of the access path between an
    initiator and a target on each access request and enforces the
    decision made by the ADF.

    AccessControl Decision Function (ADF) :
    A specialized function that makes access control decisions by
    applying access control policy rules to an access request, ADI (of
    initiators, targets, access requests,
    or that retained from prior decisions), and the context in which the
    access request is made.

The role of the RO is to define the "access control policy rules" at the 
RS according to thecontext in which the access request is made.

>>     For many use cases, the User is the RO, and the interaction is
>>     through a user interface, not a machine protocol.
>
>     Wait a second. You wrote "the User is the RO". The User is
>     attempting to make an access to a RS by using a Client.
>     _That_ User is not the RO of the RS.
>
> The user being the RO is the initial use case for OAuth.

OAuth 2.0 is no more mandating such a case.

> A client application would like access to the user's photos at a photo 
> sharing site. The resource is the user's photos. The user is the owner 
> of that resource.

If the user has already pre established the access control policy rules 
so that it can access to his own photos
then he does not need to grant in real time any additional authorization.

Denis

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



--------------F19537259E37EA6D43357774
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Dick,

    


    

    
I duplicate the most important comment
      at the beginning of this email:

    

      
You are considering using an access
        control model to build a workflow model.

         

        While it may be interesting to define a workflow model, this
        should be considered 

        as a separate and different work item.

    

    
See the other comments between the
      lines.

    

    


    

    

      
      
On Mon, Jul 20, 2020 at 2:05 AM Denis <denis.ietf@free.fr>
        wrote:

        

          

            

              
Hi Dick,

              


              

              

                
On Fri, Jul 17, 2020 at 9:21 AM Denis
                  <denis.ietf@free.fr>
                  wrote:

                  

                    

                      

                        
Hello Francis and Dick,

                        


                        

                        
The good news first: we are making some
                          progress. We are now close to an agreement
                          with steps (1) up to (3), 

                          ... except that the place where the user
                          consent is captured is not
                          mentioned/indicated.

                      

                    

                  

                

              

              

              This major question which is currently left unanswered is
              where, when and how the user consent is captured.

            

          

          


          

          
When is covered, per the sequence. How and where are out
            of scope of what I drafted. 

          

        

      

    

    
It is clear that the "User consent and choice" is not currently
      addressed in the draft, but it should.

      The support of the "User consent and choice" has strong
      implications not only in the sequences of the exchanges 

      but also by which entity it should be performed.

    

      

        

          


          

          

            
 Another important point to consider and to explain is
              related to the assurances that the user can obtain about 

              the respect of his choices. This point is currently left
              unanswered in draft-hardt-xauth-protocol-13.

            

          

        

      

    

    
This point is equally important: such assurance can only be
      obtained if the access token returned to the client 

      is not considered to be opaque to the client. This is a necessary
      condition but not the single condition: 

      the Client must also be in a position to capture/memorize the
      "User consent and choice" of the user in order to be able 

      to verify it afterwards using the content of the access token(s).

    

      

        

          

            
 

              

                

                  

                    

                      

                        
If a RO needs to be involved and since a RO
                          is directly associated with a RS, why can't it
                          be directly queried 

                          by the appropriate RS after step (2) or later
                          on ?

                      

                    

                    


                    

                    
Good question. Perhaps you can expand on a use
                      case where that would be useful?

                  

                

              

              
Before I expand, would you be able to explain first
                under which circumstances a RO needs to be queried by a
                GS ?

                How can the GS identify which RO to query ?

            

          

          
If the User is the RO, then the GS knows who to query. 

          

        

      

    

    
I still have difficulties to understand what you mean here. 

      How could a GS know that "the User is the RO" ?  If "the User is
      the RO", why does the GS needs to query the User ? 

    

    

      

        

          
If the RO is a separate entity, then the GS knows the RO
            from the RS being queried. 

          

        

      

    

    
 ... and this gives the ability for the GS to log/trace all the
      RSs accessed by a given User and at which instant of time the
      access token has been granted.

    

      

        

          
An example is a user would like access to an enterprise
            asset where a workflow is started to gain approval, and an
            administrator or manager provides consent.

        

      

    

    
Thanks for this example. I finally understand what you have in
      mind: you are considering using an access control model to build a
      workflow model. 

      While it may be interesting to define a workflow model, this
      should be considered as a separate and different work item.

    

    
The model you propose may be suited for an enterprise environment
      but is not scalable over the Internet.

      What is needed is an access control model usable over the Internet
      with millions of RSs and thousands of ASs/GSs.  

    

    

      

        

          

            

              

                

                  

                    

                      

                        
Which information is supposed to be
                          presented to the RO ?

                          Which information is supposed to be returned
                          by the RO ?

                      

                    

                    


                    

                    
Just like how the user authenticates to an AS,
                      how the AS and RO communicate is out of scope.

                    

                  

                

              

              
At the moment, the usefulness of a dialogue between a
                GS and a RO has not been explained, nor demonstrated.

                The question is about the functionality of that dialogue
                in terms of input and output information (and not about
                

                the design of a protocol or of a user interface).
                Anyway, AFAIU a dialogue between a GS and a RO is
                optional.

              

            

          

          


          

          
See enterprise example above.

        

      

    

    
It is not an access control example, but a workflow example.

    
Access  control has been defined a long time
      ago and the last edition of the model has been confirmed in year
      1996: ISO/IEC 10181-3: 1996.

      "Information
        technology — Open Systems Interconnection — Security frameworks
        for
        open systems: Access control framework — Part 3".

    
Two major
        functions have ben defined: an Access Control Enforcement
          Function (AEF) and an Access Control Decision
        Function(ADF).

    

      
Access Control Enforcement
          Function (AEF):

          A specialized function
          that is part of the access path between an initiator and a
          target on each
          access request and enforces the decision made by the ADF.

      Access Control Decision
        Function (ADF) :

      A specialized function
        that makes access control decisions by applying access control
        policy rules to
        an access request, ADI (of initiators, targets, access requests,
      

      or that
        retained from prior decisions), and the context in which the
        access request is
        made.

    
The role of the RO is to define the "access control policy rules" at the
        RS according to the context in which the access
          request is
          made.

    

      

        

          
 

          

            

              

                

                  

                    
For many use cases, the User is the RO, and the
                      interaction is through a user interface, not a
                      machine protocol. 

                    

                  

                

              

              
Wait a second. You wrote "the User is the RO". The User
                is attempting to make an access to a RS by using a
                Client. 

                That User is not the RO of the RS.   

              

            

          

          
The user being the RO is the initial use case for OAuth.
          

        

      

    

    
OAuth 2.0 is no more mandating such a case.

    

    

      

        

          
A client application would like access to the user's
            photos at a photo sharing site. The resource is the user's
            photos. The user is the owner of that resource.

        

      

    

    
If the user has already pre established the access control policy
      rules so that it can access to his own photos 

      then he does not need to grant in real time any additional
      authorization.

    
Denis

    

      
      
ᐧ

    

    


    

  


--------------F19537259E37EA6D43357774--


From nobody Tue Jul 21 09:00: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 AC27C3A0B65 for ; Tue, 21 Jul 2020 09:00: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 A8P4shDJHyPV for ; Tue, 21 Jul 2020 09:00:34 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450: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 9B1FE3A0B54 for ; Tue, 21 Jul 2020 09:00:33 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id k13so2988180lfo.0 for ; Tue, 21 Jul 2020 09:00: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=4r9NRCY7A+rY4Q1UeeqNFKLsCbgGWWTdy4a2KE9AOfo=; b=IjjYRQjDQdpOJoTSJ47q6PNbsI8UtdVFnwxPJyAR22tM96UH9zKaNMlh/oFzCCfl5J A3KCr0/KSB0HfTUmN+QLzxMJrw/hfwlpXcF7wQNUSTDoqy2ApjReCBtAzkB6B6DRUg/g zfpJXYiCKjKfc/gL3QoOgxW6PvWtgUc42uinJlJfdSnWHwf+BLwOnzJHURXPr/gN9RVs 7eV8b8BiKjXdN3JZiJ4gPFzXy4kJ/3qgs1FQHDgeW1Xzf4e0wUq8tQTTtpAA1IU7vfnR ooAYHoWsVZFjJ53GCFzFpOn3cU1K/S1Q9aS/e8fzTSMBSCfYp8P3nDDXlm59+c2BytKW 3KeA==
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=4r9NRCY7A+rY4Q1UeeqNFKLsCbgGWWTdy4a2KE9AOfo=; b=BurElsDpyCKnE/Ic8eSdExqjAuNIPSxlfxecClxe3NdoJZE+imYlek1ElNMrLSYiim ZytWq43m5JaaNAIVAGffSzrOfFBv/sqaxcmL5aBDfFl/jhUSqaj0hsSWCL+aywOrICfY 292BRZvFOCGDAa5eOl6lRwwgk60n7wp8p7TJrQmAdEFUNIFUI7Lg32kSnIqIjV20xMa+ p/zsEG+n2t1mCgTeRkwmn5fPZcfRjofspoJ54bMapjJmq/Je+DxMR4taoqOv1MhSCRKy EOs3b9x/FxCoKEOb2j0KcVab7RkVyy3Q28c0fS2jck9raoACKnaSJQkHzHnhz0ML1sKK 5X9Q==
X-Gm-Message-State: AOAM530/A26nuMEcZ4buBwnswpftJDQvOKnsWrBC/35Iy8dA+RB7zyC7 NszL0qMgtQZDbPSf0Mnf88bc+MVCP0km8Mgf6ePXkt/X
X-Google-Smtp-Source: ABdhPJyMmYKERAqOl/4wiAe5wLiAIf7urX4TUai1zVXBNna+VphSVpJaS0kfsm/sWgS30owTw9RzIt/holh+u6aeGgI=
X-Received: by 2002:ac2:5f48:: with SMTP id 8mr403890lfz.157.1595347231637; Tue, 21 Jul 2020 09:00:31 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Tue, 21 Jul 2020 08:59:55 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000905d205aaf5b9a8"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 21 Jul 2020 16:00:36 -0000

--0000000000000905d205aaf5b9a8
Content-Type: text/plain; charset="UTF-8"

Thanks for putting this together Francis. I like how you have put different
aspects of a definition into separate points. It reinforces the multiple
aspects.

I don't see identity claims in your definitions. Was that intentional, or
an oversight.

wrt. Registered Client / Dynamic Client - in my experience putting the
definitions together helps a reader grasp all the various terms used.

Curious why you include "party" in the definition. I would not have thought
that had a definition unique to GNAP.


On Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha  wrote:

> Hello Dick,
>
> Here is (in a new thread) the promised attempt to define terms of interest
> in the GNAP protocol.
>
> Party - represents a role in the GNAP protocol flow. A party can take the
> form of a web service, an application installed on the user device and
> acting autonomously or the form of a natural person (resp. of an autonomous
> device) using an application to interact with other parties.
>
> Resource - a piece of data or web service
>       - controlled by a Resource Owner (RO),
>       - held and guarded by a Resource Server (RS) and
>       - serviced by the RS to a Client, if the Client provides a valid
> Authorization.
>
> Resource Owner (RO) - the party that
>       - owns a Resource,
>       - relies on the services the GS to manage access to that Resource
> and
>       - relies on the services of a RS to hold the Resource and guard
> access to that Resource.
>
> Resource Server (RS) - the party that
>       - holds a resource and guards access to that resource on behalf of
> the RO,
>       - services the Resource to the requesting Client, provided the
> Client presents a valid Authorization.
>       The RS is generally deployed as a web service.
>
> Grant Server (GS) - the party that manages access to a Resource on behalf
> of the RO. For each Resource access request, the GS might request the
> consent of the RO and produce a corresponding Authorization that is given
> to the requesting Client.
>
> Consent - act of an RO approving the release of a Resource he owns to a
> Client.
>
> Grant - material form of an RO Consent. In order not to interact with the
> RO on each Resource access request, the GS might store the RO Consent in
> the form of a Grant for reuse.
>
> Authorization - externalized form of a Grant as known to the GS and the RS.
>       - The GS converts a Grant into an Authorization for use in a
> Resource access request.
>       - The RS evaluates an Authorization to decide on whether or not to
> release the Resource to the Client.
>
> Client - the party that provides the infrastructure used by a User to
> access a Resource. The client infrastructure is designed to:
>       - Receive the resource access request from the User,
>       - Interact with the RS to discover authorization requirements,
>       - Interact with the GS to obtain an Authorization to access the
> Resource,
>       - Interact with the RS to access the Resource on behalf of the User.
>
> User - the party using the infrastructure of the Client to gain access to
> a Resource.
>
> This dictionary is supposed to be the base for further discussions that
> will allow us to provide each term with just enough description to reduce
> ambiguities and misunderstandings in further exchanges. I intentionally
> omitted the specification of the type and nature of each party (For example
> Client / Registered Client / Dynamic Client). Such elaborations belong IMO
> in proper subsections.
>
> Comments are welcome.
>
> Best regards.
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>

--0000000000000905d205aaf5b9a8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks for putting this together Francis. I like how you h=
ave put different aspects of a definition into separate points. It reinforc=
es the multiple aspects.

I don't see identity claims=
 in your definitions. Was that intentional, or an oversight.

=

wrt. Registered Client / Dynamic Client - in my experience putti=
ng the definitions together helps a reader grasp all the various terms used=
.

Curious why you include "party" in the=
 definition. I would not have thought that had a definition=C2=A0unique to =
GNAP.


On Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha =
<fpo@adorsys.de> wrote:
Hello =
Dick,

Here is (in a new thread) the promised attempt=C2=
=A0to define terms of interest in the GNAP protocol. 
=C2=A0
Party - represents a role in the GNAP protocol flow. A party can take=
 the form of a web service, an application installed on the user device and=
 acting autonomously or the form of a natural person (resp. of an autonomou=
s device) using an application to interact with other parties.

Resou=
rce - a piece of data or web service
=C2=A0 =C2=A0 =C2=A0 - controlled b=
y a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - held and guarded by a Re=
source Server (RS) and
=C2=A0 =C2=A0 =C2=A0 - serviced by the RS to a Cl=
ient, if the Client provides a valid Authorization.

Resource Owner (=
RO) - the party that 
=C2=A0 =C2=A0 =C2=A0 - owns a Resource, 
=C2=A0=
 =C2=A0 =C2=A0 - relies on the services the GS to manage access to that Res=
ource and 
=C2=A0 =C2=A0 =C2=A0 - relies on the services of a RS to hold=
 the Resource and guard access to that Resource.

Resource=
 Server (RS) - the party that=C2=A0
=C2=A0 =C2=A0 =C2=A0 - holds a resou=
rce and guards access to that resource on behalf of the RO,
=C2=A0 =C2=
=A0 =C2=A0 - services the Resource to the requesting Client, provided the C=
lient presents a valid Authorization.
=C2=A0 =C2=A0 =C2=A0 The RS is gen=
erally deployed as a web service.

Grant Server (GS) - the party that=
 manages access to a Resource on behalf of the RO. For each Resource access=
 request, the GS might request the consent of the RO and produce a correspo=
nding Authorization that is given to the requesting Client.

Consent =
- act of an RO approving the release of a Resource he owns to a Client.
=

Grant - material form of an RO Consent. In order not to interact with t=
he RO on each Resource access request, the GS might store the RO Consent in=
 the form of a Grant for reuse.

Authorization - externalized form of=
 a Grant as known to the GS and the RS.
=C2=A0 =C2=A0 =C2=A0 - The GS co=
nverts a Grant into an Authorization for use=C2=A0in a Resource access requ=
est.
=C2=A0 =C2=A0 =C2=A0 - The RS evaluates an Authorization to decide =
on whether or not to release the Resource to the Client.

Client - th=
e party that provides the infrastructure used by a User to access a Resourc=
e. The client infrastructure is designed to:
=C2=A0 =C2=A0 =C2=A0 - Rece=
ive the resource access request from the User,
=C2=A0 =C2=A0 =C2=A0 - In=
teract with the RS to discover authorization requirements,
=C2=A0 =C2=A0=
 =C2=A0 - Interact with the GS to obtain an Authorization to access the Res=
ource,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to access the Resourc=
e on behalf of the User.

User - the party using the infrastructure o=
f the Client to gain access to a Resource.

This di=
ctionary is supposed to be the base for further discussions that will allow=
 us to provide each term with just enough description to reduce ambiguities=
 and misunderstandings in further exchanges. I intentionally omitted the sp=
ecification of the type and nature of each party (For example Client / Regi=
stered Client / Dynamic Client). Such elaborations belong IMO in proper sub=
sections.

Comments are welcome.

=

Best regards.
-- 
Francis P=
ouatcha
Co-Founder and Technical Lead
adorsys GmbH &=
; Co. KG




--0000000000000905d205aaf5b9a8--


From nobody Tue Jul 21 09:23: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 E52AD3A0B8D for ; Tue, 21 Jul 2020 09:23:46 -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 58OpAFmMZV77 for ; Tue, 21 Jul 2020 09:23:44 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 256C43A0B88 for ; Tue, 21 Jul 2020 09:23:43 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id x9so24712310ljc.5 for ; Tue, 21 Jul 2020 09:23: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=ihMbANiEagI/PvIUEdeKBaoahl0TW4kw4lgYcUGha7U=; b=jvl6N5aGO9+jzhZeTywu5HIZQ9R+EPwXhCGYx/dTm4QSlhoOV2QzNB3BQbqxQFxv9+ keTk/0o5rY+5uil2gHDPilJVpAlvu5/mlTUxr3h/ik1CVGaeF06hmS8uQv+OzJu0O4gs f0Ij8lFeGBH7z00KrbsMDVVte+GPMDmmovvnRcfEa9Z9ksUf++XBv01epGTVbmISaKBl IS8Lkqgr0i/lpmP1ak94OI4RPlut/rRAs+Ubdsg89KIxJeFj3WQmXmeUcssXMEWiilNA VH7KL7cWNrTn1KZHzYBiLMmdUq5cmL2C2IdIKDqJzm5VWyP352vT+PRVR6sHuiMIeRpR wVbw==
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=ihMbANiEagI/PvIUEdeKBaoahl0TW4kw4lgYcUGha7U=; b=gqD9ME02+si9187KmlIeb1AkbvvPxeGozC6Rcw1Pdi4lXaZ9pIuHRUvy7I/wUd9LZd qeGaouNtd4rqfS6zbmVydPw2y7hID7AEY5WHe/8Jw5Mjt3dShpF7Lt6Oum0i4QYzlVGV jlKo4AvHOlOJkIwO+MFH3RKdaQHJqmC+Rt8ZfWohx43Y6VCsEpJcCuuWrYXBg2FSYaLx znyiCZDygx6/o+JVxW4kdgI4SzZTTi7qkfdtC1REzJnZysWtMfeJ8mzDvvgK4Lcr5FX4 +rGVwpP6msHd+3rlZYXO8FbweLy0Hpy5ZO0TD3jaGPkUtbOjeM1fFkx370WVO/uAOg7M Hjpw==
X-Gm-Message-State: AOAM530P7OyENzGKE18zJWK8SCKjlxxc6CSluZn2wnhqNXT6l3KFrzs6 1x5G3Tu0otOXpgOgjkeKTIp1latogvGCACnd5aU=
X-Google-Smtp-Source: ABdhPJwZxG6REQcPGPw2CbivCAlMu8ikuJfdBDrVGGa/YI0cYDdH4ac77cCBgDDaKoJjziv9pnOa0mXV7YIyFnijlto=
X-Received: by 2002:a05:651c:552:: with SMTP id q18mr1997133ljp.437.1595348621925;  Tue, 21 Jul 2020 09:23:41 -0700 (PDT)
MIME-Version: 1.0
References:                <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>
In-Reply-To: <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>
From: Dick Hardt 
Date: Tue, 21 Jul 2020 09:23:05 -0700
Message-ID: 
To: Denis 
Cc: Francis Pouatcha , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e7250305aaf60b0d"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 21 Jul 2020 16:23:47 -0000

--000000000000e7250305aaf60b0d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

comments inserted ...

On Tue, Jul 21, 2020 at 6:03 AM Denis  wrote:

> Hello Dick,
>
> I duplicate the most important comment at the beginning of this email:
>
> You are considering using an access control model to build a workflow
> model.
>
> While it may be interesting to define a workflow model, this should be
> considered
> as a separate and different work item.
>
> See the other comments between the lines.
>
> On Mon, Jul 20, 2020 at 2:05 AM Denis  wrote:
>
>> Hi Dick,
>>
>> On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:
>>
>>> Hello Francis and Dick,
>>>
>>> The good news first: we are making some progress. We are now close to a=
n
>>> agreement with steps (1) up to (3),
>>> ... except that the place where the user consent is captured is not
>>> mentioned/indicated.
>>>
>>
>> This major question which is currently left unanswered is where, when an=
d
>> how the user consent is captured.
>>
>
> When is covered, per the sequence. How and where are out of scope of what
> I drafted.
>
> It is clear that the "User consent and choice" is not currently addressed
> in the draft, but it should.
> The support of the "User consent and choice" has strong implications not
> only in the sequences of the exchanges
> but also by which entity it should be performed.
>
"consent" is in the latest draft 7 times.

I think the abstract sequence as proposed by Francis is a great addition,
and would clarify where consent is in the sequence.


>
> Another important point to consider and to explain is related to the
>> assurances that the user can obtain about
>> the respect of his choices. This point is currently left unanswered in
>> draft-hardt-xauth-protocol-13.
>>
> This point is equally important: such assurance can only be obtained if
> the access token returned to the client
> is not considered to be opaque to the client. This is a necessary
> condition but not the single condition:
> the Client must also be in a position to capture/memorize the "User
> consent and choice" of the user in order to be able
> to verify it afterwards using the content of the access token(s).
>

We disagree on this being a requirement for all use cases. It may be in
some.


>
>> If a RO needs to be involved and since a RO is directly associated with =
a
>>> RS, why can't it be directly queried
>>> by the appropriate RS after step (2) or later on ?
>>>
>>
>> Good question. Perhaps you can expand on a use case where that would be
>> useful?
>>
>> Before I expand, would you be able to explain first under which
>> circumstances a RO needs to be queried by a GS ?
>> How can the GS identify which RO to query ?
>>
> If the User is the RO, then the GS knows who to query.
>
> I still have difficulties to understand what you mean here.
> How could a GS know that "the User is the RO" ?  If "the User is the RO",
> why does the GS needs to query the User ?
>

To get consent?


> If the RO is a separate entity, then the GS knows the RO from the RS bein=
g
> queried.
>
>  ... and this gives the ability for the GS to log/trace all the RSs
> accessed by a given User and at which instant of time the access token ha=
s
> been granted.
>
> An example is a user would like access to an enterprise asset where a
> workflow is started to gain approval, and an administrator or manager
> provides consent.
>
> Thanks for this example. I finally understand what you have in mind: you
> are considering using an access control model to build a *workflow model*=
.
>
> While it may be interesting to define a workflow model, this should be
> considered as a *separate and different work item*.
>

The actual workflow is out of scope. if the admin grants access, then the
access granted to the client changes.


> The model you propose may be suited for an enterprise environment but is
> not scalable over the Internet.
>

It is one of the use cases we are working to address.


> What is needed is an access control model usable over the Internet with
> millions of RSs and thousands of ASs/GSs.
>

I agree the model should also scale to internet scale.



> Which information is supposed to be presented to the RO ?
>>> Which information is supposed to be returned by the RO ?
>>>
>>
>> Just like how the user authenticates to an AS, how the AS and RO
>> communicate is out of scope.
>>
>> At the moment, the usefulness of a dialogue between a GS and a RO has no=
t
>> been explained, nor demonstrated.
>> The question is about the functionality of that dialogue in terms of
>> input and output information (and not about
>> the design of a protocol or of a user interface). Anyway, AFAIU a
>> dialogue between a GS and a RO is optional.
>>
>
> See enterprise example above.
>
> It is not an access control example, but a workflow example.
>
> Access  control has been defined a long time ago and the last edition of
> the model has been confirmed in year 1996: ISO/IEC 10181-3: 1996.
> "Information technology =E2=80=94 Open Systems Interconnection =E2=80=94 =
Security
> frameworks for open systems: Access control framework =E2=80=94 Part 3".
>
> Two major functions have ben defined: an Access Control Enforcement Funct=
ion
> (AEF) and an Access Control Decision Function(ADF).
>
> Access Control Enforcement Function (AEF):
> A specialized function that is part of the access path between an
> initiator and a target on each access request and enforces the decision
> made by the ADF.
> Access Control Decision Function (ADF) :
> A specialized function that makes access control decisions by applying
> access control policy rules to an access request, ADI (of initiators,
> targets, access requests,
> or that retained from prior decisions), and the context in which the
> access request is made.
>
> The role of the RO is to define the "access control policy rules" at the
> RS according to the context in which the access request is made.
>
I'm pretty familiar with access control systems. :)

I would say that the access control is happening at the RS. The client
presents a token when accessing an API. The RS uses the token, and any
policy required, to make an access decision.

Here is flow:

1) The Client requests access to an RS from the GS.
2) The GS queries the RS if access should be granted.
3) If access is granted, the GS creates an access token representing the
granted access, and returns it to the Client.
4) The Client presents the access token to the RS to show it has been
granted access.

A couple advantages of this model:
- that the RS does not need to know much, if anything about the Client.
- the access token MAY be self contained so that the Client does not need
to query the GS on each access.

I would not say that GNAP is an access control protocol, as how the RS uses
the token to determine access is out of scope.






>
>
>> For many use cases, the User is the RO, and the interaction is through a
>> user interface, not a machine protocol.
>>
>> Wait a second. You wrote "the User is the RO". The User is attempting to
>> make an access to a RS by using a Client.
>> *That* User is not the RO of the RS.
>>
> The user being the RO is the initial use case for OAuth.
>
> OAuth 2.0 is no more mandating such a case.
>

I don't know what you mean by that.


> A client application would like access to the user's photos at a photo
> sharing site. The resource is the user's photos. The user is the owner of
> that resource.
>
> If the user has already pre established the access control policy rules s=
o
> that it can access to his own photos
> then he does not need to grant in real time any additional authorization.
>

I don't understand what you are trying to say. The photo sharing example
was a driving use case for the creation of OAuth.

/Dick

--000000000000e7250305aaf60b0d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


comments inserted ...=C2=A0

On Tue, Jul 21=
, 2020 at 6:03 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hello Dick,

    


    

    
I duplicate the most important comment
      at the beginning of this email:

    

      
You are considering using an access
        control model to build a workflow model.

         

        While it may be interesting to define a workflow model, this
        should be considered 

        as a separate and different work item.

    

    
See the other comments between the
      lines.

    

    


    

    

     =20
      
On Mon, Jul 20, 2020 at 2:05 AM Denis <denis.ietf@free.fr>
        wrote:

        

          

            

              
Hi Dick,

              


              

              

                
On Fri, Jul 17, 2020 at 9:21 AM Denis
                  <denis.ietf@free.fr>
                  wrote:

                  

                    

                      

                        
Hello Francis and Dick,

                        


                        

                        
The good news first: we are making some
                          progress. We are now close to an agreement
                          with steps (1) up to (3), 

                          ... except that the place where the user
                          consent is captured is not
                          mentioned/indicated.

                      

                    

                  

                

              

              

              This major question which is currently left unanswered is
              where, when and how the user consent is captured.

            

          

          


          

          
When is covered, per the sequence. How and where are out
            of scope of what I drafted. 

          

        

      

    

    
It is clear that the "User consent and choice" is not curr=
ently
      addressed in the draft, but it should.

      The support of the "User consent and choice" has strong
      implications not only in the sequences of the exchanges 

      but also by which entity it should be performed.
"consent" is in the latest draft 7 times.=C2=A0
=

I think the abstract sequence as proposed by Francis is a gr=
eat addition, and would clarify where consent is in the sequence.
=C2=A0

    

      

        

          


          

          

            
 Another important point to consider and to explain is
              related to the assurances that the user can obtain about 

              the respect of his choices. This point is currently left
              unanswered in draft-hardt-xauth-protocol-13.

            

          

        

      

    

    
This point is equally important: such assurance can only be
      obtained if the access token returned to the client 

      is not considered to be opaque to the client. This is a necessary
      condition but not the single condition: 

      the Client must also be in a position to capture/memorize the
      "User consent and choice" of the user in order to be able <=
br>
      to verify it afterwards using the content of the access token(s).
=


We disagree on this being a requirem=
ent for all use cases. It may be in some.=C2=A0
=C2=A0

    

      

        

          

            
 

              

                

                  

                    

                      

                        
If a RO needs to be involved and since a RO
                          is directly associated with a RS, why can't i=
t
                          be directly queried 

                          by the appropriate RS after step (2) or later
                          on ?

                      

                    

                    


                    

                    
Good question. Perhaps you can expand on a use
                      case where that would be useful?

                  

                

              

              
Before I expand, would you be able to explain first
                under which circumstances a RO needs to be queried by a
                GS ?

                How can the GS identify which RO to query ?

            

          

          
If the User is the RO, then the GS knows who to query. 

          

        

      

    

    
I still have difficulties to understand what you mean here. 

      How could a GS know that "the User is the RO" ?=C2=A0 If &q=
uot;the User is
      the RO", why does the GS needs to query the User ? 

To get consent?
=C2=A0

    

    

      

        

          
If the RO is a separate entity, then the GS knows the RO
            from the RS being queried. 

          

        

      

    

    
=C2=A0... and this gives the ability for the GS to log/trace all the
      RSs accessed by a given User and at which instant of time the
      access token has been granted.

    

      

        

          
An example=C2=A0is a user would like access to an enterprise
            asset where a workflow is started to gain approval, and an
            administrator or manager provides consent.

        

      

    

    
Thanks for this example. I finally understand what you have in
      mind: you are considering using an access control model to build a
      workflow model. 

      While it may be interesting to define a workflow model, this
      should be considered as a separate and different work item.

The actual workflow is out of scope=
. if the admin grants access, then the access granted to the client changes=
.
=C2=A0
<=
div>

    

    
The model you propose may be suited for an enterprise environment
      but is not scalable over the Internet.

It is one of the use cases we are working to address.
=

=C2=A0

      What is needed is an access control model usable over the Internet
      with millions of RSs and thousands of ASs/GSs.=C2=A0 

I agree the model should also scale to inter=
net scale.=C2=A0

=C2=A0

    

    

      

        

          

            

              

                

                  

                    

                      

                        
Which information is supposed to be
                          presented to the RO ?

                          Which information is supposed to be returned
                          by the RO ?

                      

                    

                    


                    

                    
Just like how the user authenticates to an AS,
                      how the AS and RO communicate is out of scope.

                    

                  

                

              

              
At the moment, the usefulness of a dialogue between a
                GS and a RO has not been explained, nor demonstrated.

                The question is about the functionality of that dialogue
                in terms of input and output information (and not about
                

                the design of a protocol or of a user interface).
                Anyway, AFAIU a dialogue between a GS and a RO is
                optional.

              

            

          

          


          

          
See enterprise example above.

        

      

    

    
It is not an access control example, but a workflow example.

    
Access=C2=A0 control has been defined a long tim=
e
      ago and the last edition of the model has been confirmed in year
      1996: ISO/IEC=C2=A010181-3:=
 1996.

      "Information
        technology=C2=A0=E2=80=94 Open Systems Interconnection=C2=A0=E2=80=
=94 Security frameworks
        for
        open systems: Access control framework=C2=A0=E2=80=94 Part=C2=A03&q=
uot;.

    
Two major
        functions have ben defined: an Access Control Enforcement
          Function (AEF) and an Access Control Decision
        Function(ADF).

    

      
Acce=
ss Control Enforcem=
ent
          Function (AEF):

          A specialized function
          that is part of the access path between an initiator and a
          target on each
          access request and enforces the decision made by the ADF.<=
/p>
      Access Control Decision
        Function (A=
DF) :

      A specialized function
        that makes access control decisions by applying access control
        policy rules to
        an access request, ADI (of initiators, targets, access requests,
      

      or that
        retained from prior decisions), and the context in which the
        access request is
        made.

    
The role of the RO is to define the "access control policy rules" at the
        RS according to the context in which the access
          request is
          made.
I'm pretty fam=
iliar with access control systems. :)=C2=A0

I woul=
d say that the access control is happening at the RS. The client presents a=
 token when accessing an API. The RS uses the token, and any policy require=
d, to make an access decision.

Here is flow:
=


1) The Client requests access to an RS from the GS.=C2=
=A0
2) The GS queries the RS if access should be granted.=C2=A0
3) If access is granted, the GS creates an access token representi=
ng the granted access, and returns it to the Client.=C2=A0
4) The=
 Client presents the access token to the RS to show it has been granted acc=
ess.=C2=A0

A couple advantages of this model:
- that the RS does not need to know much, if anything about the Clien=
t.=C2=A0
- the access token MAY be self contained so that the Cli=
ent does not need to query the GS on each access.=C2=A0

I would not say that GNAP is an access control protocol, as how the R=
S uses the token to determine access is out of scope.

<=
div>


=C2=A0

    

      

        

          
=C2=A0

          

            

              

                

                  

                    
For many use cases, the User is the RO, and the
                      interaction is through a user interface, not a
                      machine protocol. 

                    

                  

                

              

              
Wait a second. You wrote "the User is the RO". T=
he User
                is attempting to make an access to a RS by using a
                Client. 

                That User is not the RO of the RS.=C2=A0=C2=A0 

              

            

          

          
The user being the RO is the initial use case for OAuth.
          

        

      

    

    
OAuth 2.0 is no more mandating such a case.

I don't know what you mean by that.
=C2=
=A0

    

    

      

        

          
A client application would like access to the user's
            photos at a photo sharing site. The resource is the user's
            photos. The user is the owner of that resource.

        

      

    

    
If the user has already pre established the access control policy
      rules so that it can access to his own photos 

      then he does not need to grant in real time any additional
      authorization.

I don't =
understand what you are trying to say. The photo sharing example was a driv=
ing use case for the creation of OAuth.

/Dick


--000000000000e7250305aaf60b0d--


From nobody Tue Jul 21 10:28: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 051D93A0CB9 for ; Tue, 21 Jul 2020 10:28: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, T_SPF_TEMPERROR=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 17Oizswkwjop for ; Tue, 21 Jul 2020 10:28:36 -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 0A8CA3A0C99 for ; Tue, 21 Jul 2020 10:28:35 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id r12so21883506wrj.13 for ; Tue, 21 Jul 2020 10:28:35 -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=dbc+HO7K0KYvqVU0YsAt271Ro+6tXF6+BlQuAGEQBbE=; b=LPuikorqEJd9uDgNviK4wne87rPi4CVXhozS2wcFsbnaM39qIWt4m+HQuTdIQJittI GtH9dKIzZFdLxItlXoabbIL61JNs6PTTInVmq+PivFz/Pc+xoutSgtRTLOTk+eaK7xSZ /T3RkRh3uaWEqv8jRUY9cb+FiB/jm/Lkr/ckQ=
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=dbc+HO7K0KYvqVU0YsAt271Ro+6tXF6+BlQuAGEQBbE=; b=li3kSd26yFjVbtLo7a671IKJQFFfRR2rzFxTWNcjDuPV8y1q5UwEeowKmvfALwr0bE D6UeZI2cmT/LvslzZ2kOlt6R6PL4/SG0S8ser9GI9kBSEwzsGaM/P8bk0iK1cxvcFtmt L6tMtEA1YMi4WSe2pHbAqWIQvH9D3+mpqRuxqTaG4fbwOaKps9TTEbDUsLqNX5K/Zp+E hHPYsVaQyFJW9UQ+/Idap5CIlSiWJ+Cd/nCqF1LU77dW0rLvTmjnvUpk9hESq4L6wP7a tceG07fQE5iyjeIGyfwkkjoy7PkbKa+aIt5JKOCCHYbwldHejxuY9Gkhaoe1wZO4nFRm yBIQ==
X-Gm-Message-State: AOAM531Z4ukBwJjRrq0MzYtHxG+erKHWCq0a7ayREq3sWbaLDqJWZOit /w2KyV8c41l9rbBrNMfnMRLg2oCj5P+0kC0M5vPv+g==
X-Google-Smtp-Source: ABdhPJy0K/sCQr1OGY+ubD8nbFmmBDL3mli7X3qmXphiyRJHn4FaMUZ0IIcuX9ddyACj5xZJcZ8yL2eBVmSj4aKgfZQ=
X-Received: by 2002:a5d:65d2:: with SMTP id e18mr11796250wrw.70.1595352514237;  Tue, 21 Jul 2020 10:28:34 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Francis Pouatcha 
Date: Tue, 21 Jul 2020 13:28:20 -0400
Message-ID: 
To: Tom Jones 
Cc: txauth@ietf.org, Dick Hardt 
Content-Type: multipart/alternative; boundary="000000000000e7428905aaf6f3a8"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 21 Jul 2020 17:28:47 -0000

--000000000000e7428905aaf6f3a8
Content-Type: text/plain; charset="UTF-8"

On Mon, Jul 20, 2020 at 10:30 PM Tom Jones 
wrote:

> that sounds like a good start - some points.
> 1. Many of the statements, like the RO owns the data, are technically or
> legally incorrect, but i think we know what you mean. - controls access
> might be more appropo.
>
OK.

> 2. the user may be a delegate of the RO and have some sort of token that
> proves his authority. It would be interesting to know if that token is in
> scope.  If not perhaps I can find someone else to own it.
>
Talking Grant Negotiation, the happy path assumes that the User/Client is
not in possession of an AuthZ.

- If a Client is in possession of an AuthZ he assumes valid, he can
directly proceed with step (6) ServiceRequest(AuthZ)
- If the client does not the authorization requirement, we could allow the
request in "step (1) ServiceIntent" to present an existing AuthZ to the RS.
If RS judges this AuthZ to be sufficient, the returned AuthZChallenge can
contain an Exemption from further Authorization, instructing the Client to
proceed with "step (6) ServiceRequest(AuthZ)".

Peace ..tom
>
>
> On Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha  40adorsys.de@dmarc.ietf..org <40adorsys.de@dmarc.ietf.org>> wrote:
>
>> Hello Dick,
>>
>> Here is (in a new thread) the promised attempt to define terms of
>> interest in the GNAP protocol.
>>
>> Party - represents a role in the GNAP protocol flow. A party can take the
>> form of a web service, an application installed on the user device and
>> acting autonomously or the form of a natural person (resp. of an autonomous
>> device) using an application to interact with other parties.
>>
>> Resource - a piece of data or web service
>>       - controlled by a Resource Owner (RO),
>>       - held and guarded by a Resource Server (RS) and
>>       - serviced by the RS to a Client, if the Client provides a valid
>> Authorization.
>>
>> Resource Owner (RO) - the party that
>>       - owns a Resource,
>>       - relies on the services the GS to manage access to that Resource
>> and
>>       - relies on the services of a RS to hold the Resource and guard
>> access to that Resource.
>>
>> Resource Server (RS) - the party that
>>       - holds a resource and guards access to that resource on behalf of
>> the RO,
>>       - services the Resource to the requesting Client, provided the
>> Client presents a valid Authorization.
>>       The RS is generally deployed as a web service.
>>
>> Grant Server (GS) - the party that manages access to a Resource on behalf
>> of the RO. For each Resource access request, the GS might request the
>> consent of the RO and produce a corresponding Authorization that is given
>> to the requesting Client.
>>
>> Consent - act of an RO approving the release of a Resource he owns to a
>> Client.
>>
>> Grant - material form of an RO Consent. In order not to interact with the
>> RO on each Resource access request, the GS might store the RO Consent in
>> the form of a Grant for reuse.
>>
>> Authorization - externalized form of a Grant as known to the GS and the
>> RS.
>>       - The GS converts a Grant into an Authorization for use in a
>> Resource access request.
>>       - The RS evaluates an Authorization to decide on whether or not to
>> release the Resource to the Client.
>>
>> Client - the party that provides the infrastructure used by a User to
>> access a Resource. The client infrastructure is designed to:
>>       - Receive the resource access request from the User,
>>       - Interact with the RS to discover authorization requirements,
>>       - Interact with the GS to obtain an Authorization to access the
>> Resource,
>>       - Interact with the RS to access the Resource on behalf of the User.
>>
>> User - the party using the infrastructure of the Client to gain access to
>> a Resource.
>>
>> This dictionary is supposed to be the base for further discussions that
>> will allow us to provide each term with just enough description to reduce
>> ambiguities and misunderstandings in further exchanges.. I intentionally
>> omitted the specification of the type and nature of each party (For example
>> Client / Registered Client / Dynamic Client). Such elaborations belong IMO
>> in proper subsections.
>>
>> Comments are welcome.
>>
>> Best regards.
>> --
>> 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/

--000000000000e7428905aaf6f3a8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Jul 20, 2020 at 10:30 PM Tom =
Jones <thomasclinganjones@gmail.com> wrote:
that sounds like a good start=
 - some points.
1. Many of the statements, like the RO owns the data, a=
re technically or legally incorrect, but i think we know what you mean. - c=
ontrols access might be more appropo.
OK.=C2=
=A0
2. the user may be a delegate of the RO and have some sort of token t=
hat proves his authority. It would be interesting to know if that token is =
in scope.=C2=A0 If not perhaps I can find someone else to own it.
Talking Grant Negotiation, the happy=
 path assumes that the=C2=A0User/Client is not in possession of an AuthZ.

- If a Client is in possession of an AuthZ he assum=
es valid, he can directly proceed with=C2=A0step (6) ServiceRequest(AuthZ)<=
/div>
- If the client does not the authorization requirement, we could =
allow the request in "step (1) ServiceIntent" to present an exist=
ing=C2=A0AuthZ to the RS. If RS judges this AuthZ to be sufficient, the ret=
urned AuthZChallenge can contain an Exemption from further Authorization,=
=C2=A0instructing the Client to proceed with "step (6) ServiceRequest(=
AuthZ)".

<=
div>Peace ..tom


On Mon, Jul 20, 2020 at 6:=
01 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf..org> wrote:
Hello D=
ick,

Here is (in a new thread) the promised attempt=C2=
=A0to define terms of interest in the GNAP protocol. 
=C2=A0
Party - represents a role in the GNAP protocol flow. A party can take=
 the form of a web service, an application installed on the user device and=
 acting autonomously or the form of a natural person (resp. of an autonomou=
s device) using an application to interact with other parties.

Resou=
rce - a piece of data or web service
=C2=A0 =C2=A0 =C2=A0 - controlled b=
y a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - held and guarded by a Re=
source Server (RS) and
=C2=A0 =C2=A0 =C2=A0 - serviced by the RS to a Cl=
ient, if the Client provides a valid Authorization.

Resource Owner (=
RO) - the party that 
=C2=A0 =C2=A0 =C2=A0 - owns a Resource, 
=C2=A0=
 =C2=A0 =C2=A0 - relies on the services the GS to manage access to that Res=
ource and 
=C2=A0 =C2=A0 =C2=A0 - relies on the services of a RS to hold=
 the Resource and guard access to that Resource.

Resource=
 Server (RS) - the party that=C2=A0
=C2=A0 =C2=A0 =C2=A0 - holds a resou=
rce and guards access to that resource on behalf of the RO,
=C2=A0 =C2=
=A0 =C2=A0 - services the Resource to the requesting Client, provided the C=
lient presents a valid Authorization.
=C2=A0 =C2=A0 =C2=A0 The RS is gen=
erally deployed as a web service.

Grant Server (GS) - the party that=
 manages access to a Resource on behalf of the RO. For each Resource access=
 request, the GS might request the consent of the RO and produce a correspo=
nding Authorization that is given to the requesting Client.

Consent =
- act of an RO approving the release of a Resource he owns to a Client.
=

Grant - material form of an RO Consent. In order not to interact with t=
he RO on each Resource access request, the GS might store the RO Consent in=
 the form of a Grant for reuse.

Authorization - externalized form of=
 a Grant as known to the GS and the RS.
=C2=A0 =C2=A0 =C2=A0 - The GS co=
nverts a Grant into an Authorization for use=C2=A0in a Resource access requ=
est.
=C2=A0 =C2=A0 =C2=A0 - The RS evaluates an Authorization to decide =
on whether or not to release the Resource to the Client.

Client - th=
e party that provides the infrastructure used by a User to access a Resourc=
e. The client infrastructure is designed to:
=C2=A0 =C2=A0 =C2=A0 - Rece=
ive the resource access request from the User,
=C2=A0 =C2=A0 =C2=A0 - In=
teract with the RS to discover authorization requirements,
=C2=A0 =C2=A0=
 =C2=A0 - Interact with the GS to obtain an Authorization to access the Res=
ource,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to access the Resourc=
e on behalf of the User.

User - the party using the infrastructure o=
f the Client to gain access to a Resource.

This di=
ctionary is supposed to be the base for further discussions that will allow=
 us to provide each term with just enough description to reduce ambiguities=
 and misunderstandings in further exchanges.. I intentionally omitted the s=
pecification of the type and nature of each party (For example Client / Reg=
istered Client / Dynamic Client). Such elaborations belong IMO in proper su=
bsections.

Comments are welcome.

Best regards.
-- 
Francis =
Pouatcha
Co-Founder and Technical Lead
adorsys GmbH &am=
p; Co. KG
<=
/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


--000000000000e7428905aaf6f3a8--


From nobody Tue Jul 21 10:42: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 5CDA33A0CC4 for ; Tue, 21 Jul 2020 10:42:49 -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 e6lP-ySqHIff for ; Tue, 21 Jul 2020 10:42:47 -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 2B2D23A0CBC for ; Tue, 21 Jul 2020 10:42:47 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id a14so7169972wra.5 for ; Tue, 21 Jul 2020 10:42: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=09polVp2S0vYz7zZuMX6pS6dsqJ9t4LKXtkObtiOdqs=; b=V05ciTMQ7kI2nn5UBQ4oNQ14P6N1wPK3B8eKMoLAj3OF+t/sPllINsVOOK8lJmWmI3 Uq2PEUxyu9fwRNwpJLbVecrOEDENMC99AOs4gLKc3ZOSRlAdq9VH8H4F3wr4y5gXJZoI cjJTnnvnKumRzIEVMtyMEltMQLzZnemm4e8h4=
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=09polVp2S0vYz7zZuMX6pS6dsqJ9t4LKXtkObtiOdqs=; b=CGO+FnyQDYtLKZS2wb4I27SqMgLQylMWdFs9UyXilRBKSdjj+oh9cV2ahQAZX7wYld 3t1Sgp6mnCLYWTjp/NZPOILqmbD36sgioJJ3wcC+UZT5/xmo6iTL4R01KmbGZQf9eI5W HBoytQLIENpWCOxwiYS+4BQGoz9aQFND1rdd3u/zdE3OqytpJlu9i3rqGPuZtyyxS77c hkRr3ahpPxY5iTcl4Av/irQoIe4R/uAqTIHS7L2g9gV5OsW1/G0MjCDSljcD+CK8j1a/ Uy9YDDeqh7D1C1oVbzGc7zn8aPaHT8I98jIS/fDRGLtzQreXjFYIjYbvPke3ncJlAfQ0 xA0Q==
X-Gm-Message-State: AOAM530FBlp4mJulw/2Tv1MxcEEBxnNwi2CwuhKHFmi7PAygMvKdF9Wb kcqu0kRizDCfTLv4mMFXAqLB0htj0v3d1W8u5sCnXQ==
X-Google-Smtp-Source: ABdhPJykwJY5L66I4OTFdAFvejdr/lGCMTo4BeF29PyRVOA4fVDsewWlG16vMF4pjEKNOX32+dVWmDjvrJ9b/CYaycs=
X-Received: by 2002:a5d:45c9:: with SMTP id b9mr14850272wrs.283.1595353365327;  Tue, 21 Jul 2020 10:42:45 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Francis Pouatcha 
Date: Tue, 21 Jul 2020 13:42:32 -0400
Message-ID: 
To: Dick Hardt 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a1cbb005aaf726cf"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 21 Jul 2020 17:42:49 -0000

--000000000000a1cbb005aaf726cf
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 21, 2020 at 12:00 PM Dick Hardt  wrote:

> Thanks for putting this together Francis. I like how you have put
> different aspects of a definition into separate points. It reinforces the
> multiple aspects.
>
> I don't see identity claims in your definitions. Was that intentional, or
> an oversight.
>
The extensive dictionary will surely include more terms.

I limited the list to terms relevant to the abstract sequence for now.
Making an effort to keep the discussion focused on the abstract sequence.

As we are talking authorization, identities are second class citizens,
focus shall be on Negotiating and Obtaining the AuthZ to access a Resource.

>
> wrt. Registered Client / Dynamic Client - in my experience putting the
> definitions together helps a reader grasp all the various terms used.
>
Yes, this clarification belongs in the dictionary. Intentionally left it
out here to avoid diverging the discussion.

>
> Curious why you include "party" in the definition. I would not have
> thought that had a definition unique to GNAP.
>
I derived this from your subsection "Parties". As all participants in the
abstract sequence are "parties", the word seems too heavy to be left
undefined. Also essential to know which words in the dictionary do not
refer to parties like Resource, Grant, AuthZ, ...

>
>
> On Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha  wrote:
>
>> Hello Dick,
>>
>> Here is (in a new thread) the promised attempt to define terms of
>> interest in the GNAP protocol.
>>
>> Party - represents a role in the GNAP protocol flow. A party can take the
>> form of a web service, an application installed on the user device and
>> acting autonomously or the form of a natural person (resp. of an autonomous
>> device) using an application to interact with other parties.
>>
>> Resource - a piece of data or web service
>>       - controlled by a Resource Owner (RO),
>>       - held and guarded by a Resource Server (RS) and
>>       - serviced by the RS to a Client, if the Client provides a valid
>> Authorization.
>>
>> Resource Owner (RO) - the party that
>>       - owns a Resource,
>>       - relies on the services the GS to manage access to that Resource
>> and
>>       - relies on the services of a RS to hold the Resource and guard
>> access to that Resource.
>>
>> Resource Server (RS) - the party that
>>       - holds a resource and guards access to that resource on behalf of
>> the RO,
>>       - services the Resource to the requesting Client, provided the
>> Client presents a valid Authorization.
>>       The RS is generally deployed as a web service.
>>
>> Grant Server (GS) - the party that manages access to a Resource on behalf
>> of the RO. For each Resource access request, the GS might request the
>> consent of the RO and produce a corresponding Authorization that is given
>> to the requesting Client.
>>
>> Consent - act of an RO approving the release of a Resource he owns to a
>> Client.
>>
>> Grant - material form of an RO Consent. In order not to interact with the
>> RO on each Resource access request, the GS might store the RO Consent in
>> the form of a Grant for reuse.
>>
>> Authorization - externalized form of a Grant as known to the GS and the
>> RS.
>>       - The GS converts a Grant into an Authorization for use in a
>> Resource access request.
>>       - The RS evaluates an Authorization to decide on whether or not to
>> release the Resource to the Client.
>>
>> Client - the party that provides the infrastructure used by a User to
>> access a Resource. The client infrastructure is designed to:
>>       - Receive the resource access request from the User,
>>       - Interact with the RS to discover authorization requirements,
>>       - Interact with the GS to obtain an Authorization to access the
>> Resource,
>>       - Interact with the RS to access the Resource on behalf of the User.
>>
>> User - the party using the infrastructure of the Client to gain access to
>> a Resource.
>>
>> This dictionary is supposed to be the base for further discussions that
>> will allow us to provide each term with just enough description to reduce
>> ambiguities and misunderstandings in further exchanges. I intentionally
>> omitted the specification of the type and nature of each party (For example
>> Client / Registered Client / Dynamic Client). Such elaborations belong IMO
>> in proper subsections.
>>
>> Comments are welcome.
>>
>> Best regards.
>> --
>> 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/

--000000000000a1cbb005aaf726cf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Tue, Jul 21, 2020 at 12:00 PM Dick Har=
dt <dick.hardt@gmail.com>=
 wrote:
Thanks for putting this together Francis. I like how you have put =
different aspects of a definition into separate points. It reinforces the m=
ultiple aspects.

I don't see identity claims in your=
 definitions. Was that intentional, or an oversight.
The extensive dictionary will surely include more terms.=C2=A0
=


I limited the list to terms relevant to the abstract se=
quence for now. Making an effort to keep the discussion focused=C2=A0on the=
 abstract sequence.

As we are talking authorizatio=
n, identities are second class citizens, focus shall be on Negotiating and =
Obtaining the AuthZ to access a Resource.

wrt. Registered =
Client / Dynamic Client - in my experience putting the definitions together=
 helps a reader grasp all the various terms used.
<=
div>Yes, this clarification belongs in the dictionary. Intentionally=C2=A0l=
eft it out here to avoid diverging the discussion.

Curio=
us why you include "party" in the definition. I would not have th=
ought that had a definition=C2=A0unique to GNAP.
I derived this from your subsection "Parties". As all particip=
ants in the abstract sequence are "parties", the word seems too h=
eavy to be left undefined. Also essential to know which words in the dictio=
nary do not refer to parties like Resource, Grant, AuthZ, ...

<=
/div>
O=
n Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick,
Here is (in a new thread) the promised attempt=C2=A0to defi=
ne terms of interest in the GNAP protocol. 
=C2=A0
Part=
y - represents a role in the GNAP protocol flow. A party can take the form =
of a web service, an application installed on the user device and acting au=
tonomously or the form of a natural person (resp. of an autonomous device) =
using an application to interact with other parties.

Resource - a pi=
ece of data or web service
=C2=A0 =C2=A0 =C2=A0 - controlled by a Resour=
ce Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - held and guarded by a Resource Ser=
ver (RS) and
=C2=A0 =C2=A0 =C2=A0 - serviced by the RS to a Client, if t=
he Client provides a valid Authorization.

Resource Owner (RO) - the =
party that 
=C2=A0 =C2=A0 =C2=A0 - owns a Resource, 
=C2=A0 =C2=A0 =
=C2=A0 - relies on the services the GS to manage access to that Resource an=
d 
=C2=A0 =C2=A0 =C2=A0 - relies on the services of a RS to hold the Res=
ource and guard access to that Resource.

Resource Server =
(RS) - the party that=C2=A0
=C2=A0 =C2=A0 =C2=A0 - holds a resource and =
guards access to that resource on behalf of the RO,
=C2=A0 =C2=A0 =C2=A0=
 - services the Resource to the requesting Client, provided the Client pres=
ents a valid Authorization.
=C2=A0 =C2=A0 =C2=A0 The RS is generally dep=
loyed as a web service.

Grant Server (GS) - the party that manages a=
ccess to a Resource on behalf of the RO. For each Resource access request, =
the GS might request the consent of the RO and produce a corresponding Auth=
orization that is given to the requesting Client.

Consent - act of a=
n RO approving the release of a Resource he owns to a Client.

Grant =
- material form of an RO Consent. In order not to interact with the RO on e=
ach Resource access request, the GS might store the RO Consent in the form =
of a Grant for reuse.

Authorization - externalized form of a Grant a=
s known to the GS and the RS.
=C2=A0 =C2=A0 =C2=A0 - The GS converts a G=
rant into an Authorization for use=C2=A0in a Resource access request.
=
=C2=A0 =C2=A0 =C2=A0 - The RS evaluates an Authorization to decide on wheth=
er or not to release the Resource to the Client.

Client - the party =
that provides the infrastructure used by a User to access a Resource. The c=
lient infrastructure is designed to:
=C2=A0 =C2=A0 =C2=A0 - Receive the =
resource access request from the User,
=C2=A0 =C2=A0 =C2=A0 - Interact w=
ith the RS to discover authorization requirements,
=C2=A0 =C2=A0 =C2=A0 =
- Interact with the GS to obtain an Authorization to access the Resource,=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to access the Resource on beh=
alf of the User.

User - the party using the infrastructure of the Cl=
ient to gain access to a Resource.

This dictionary=
 is supposed to be the base for further discussions that will allow us to p=
rovide each term with just enough description to reduce ambiguities and mis=
understandings in further exchanges. I intentionally omitted the specificat=
ion of the type and nature of each party (For example Client / Registered C=
lient / Dynamic Client). Such elaborations belong IMO in proper subsections=
.

Comments are welcome.

Bes=
t regards.
-- 
Francis Pouatcha<=
/div>
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/


--000000000000a1cbb005aaf726cf--


From nobody Tue Jul 21 10:59: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 125983A0D4D for ; Tue, 21 Jul 2020 10:59: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 VrTB46YoUYxE for ; Tue, 21 Jul 2020 10:59:05 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 E9A143A0D60 for ; Tue, 21 Jul 2020 10:59:04 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id q4so25122592lji.2 for ; Tue, 21 Jul 2020 10:59: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=pkOtdZw0uAEAsu2Xxku64D2MaNm0/kpgaBRLDj88mPI=; b=MHjQfV0P1GbE8AcZ0iYzCSQzwWxF3RaSSmmYcTl0D3vsuoJzGi2ddvPbAnO3TVzGVn JnCtQlwV1k4UvzDqcVz9XS4cEfz0dZpNoYtJoW9et4ZTZfTwnqEwAhbejsa1wkpX4AVd 8/RAehhUQkWtNqJNdOdJ+fBBtiWZgZQNBjuvPQZeMdxnGPr37hqwQRU28pXa31ZkSbyE zL7c/kF+2Nwxj90auHQdeYBYe9wwft1H33Jy7T8CwfGw0IxUY9y8MHKesjIySp+4L1Rq ixR0X68QVPTbU+c1OnBYHppLQlkwI3RULKrnzA2SlE5KrPxcvQmnR0RJaewp6tSF9wv0 MUyQ==
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=pkOtdZw0uAEAsu2Xxku64D2MaNm0/kpgaBRLDj88mPI=; b=TOgBjOdbOyFM4VPkVhzwy9KsmKlYKzPC7USF9gkBXpY97TgT6dWxr2buoCPTb96KRY PVdDkPEL9JMR5g480wNcJn/WND8C1XdmWjbz44Gb65Yloi3UHFY/OrYKTbYRgIhnEcyi s2E7PBOUyK4pSbt5OABL9QWfawY5ljMlOvLDupYXcerwGvyd6NYEortfAxAqB86/R38g JB0RVJNMsxa2VRKokufJJY9nj4Z7bHSNwophledC1HBzJrAwluRrL8tplgPCJJlBynVf 3Pz87wpPzBRR0R7C967hjRHi5VkOAyqcH2qfLNm+VUpxSqaZhwHrNz8HJ7NqZxVYeULw zlkg==
X-Gm-Message-State: AOAM5311w4JwgDn5J8rgozjDOFsK7yufbJmrpp/CV+Xpd8SWrMSYAX8K 9uQugO/Xbw+ubIwsW4hRtr6seQ602HXDMN44APaw0Yr6
X-Google-Smtp-Source: ABdhPJy/e81d+fhe8fNTkpbboGkOmX4gl7Aaky3nOHSb5+I4BzBlRHNQeG0H+8paIKG+JqCzlGcJIRl2g9/oSAYdYsE=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr13997814ljh.110.1595354342881;  Tue, 21 Jul 2020 10:59:02 -0700 (PDT)
MIME-Version: 1.0
References:   
In-Reply-To: 
From: Dick Hardt 
Date: Tue, 21 Jul 2020 10:58:26 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e5fe0005aaf760ba"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 21 Jul 2020 17:59:07 -0000

--000000000000e5fe0005aaf760ba
Content-Type: text/plain; charset="UTF-8"

FYI: I consider the release of claims to be an "authorization" as well.

IE, the user authorizes the GS to release a DOB claim to a Client.



On Tue, Jul 21, 2020 at 10:42 AM Francis Pouatcha  wrote:

>
> On Tue, Jul 21, 2020 at 12:00 PM Dick Hardt  wrote:
>
>> Thanks for putting this together Francis. I like how you have put
>> different aspects of a definition into separate points. It reinforces the
>> multiple aspects.
>>
>> I don't see identity claims in your definitions. Was that intentional, or
>> an oversight.
>>
> The extensive dictionary will surely include more terms.
>
> I limited the list to terms relevant to the abstract sequence for now.
> Making an effort to keep the discussion focused on the abstract sequence.
>
> As we are talking authorization, identities are second class citizens,
> focus shall be on Negotiating and Obtaining the AuthZ to access a Resource.
>
>>
>> wrt. Registered Client / Dynamic Client - in my experience putting the
>> definitions together helps a reader grasp all the various terms used.
>>
> Yes, this clarification belongs in the dictionary. Intentionally left it
> out here to avoid diverging the discussion.
>
>>
>> Curious why you include "party" in the definition. I would not have
>> thought that had a definition unique to GNAP.
>>
> I derived this from your subsection "Parties". As all participants in the
> abstract sequence are "parties", the word seems too heavy to be left
> undefined. Also essential to know which words in the dictionary do not
> refer to parties like Resource, Grant, AuthZ, ...
>
>>
>>
>> On Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha  wrote:
>>
>>> Hello Dick,
>>>
>>> Here is (in a new thread) the promised attempt to define terms of
>>> interest in the GNAP protocol.
>>>
>>> Party - represents a role in the GNAP protocol flow. A party can take
>>> the form of a web service, an application installed on the user device and
>>> acting autonomously or the form of a natural person (resp. of an autonomous
>>> device) using an application to interact with other parties.
>>>
>>> Resource - a piece of data or web service
>>>       - controlled by a Resource Owner (RO),
>>>       - held and guarded by a Resource Server (RS) and
>>>       - serviced by the RS to a Client, if the Client provides a valid
>>> Authorization.
>>>
>>> Resource Owner (RO) - the party that
>>>       - owns a Resource,
>>>       - relies on the services the GS to manage access to that Resource
>>> and
>>>       - relies on the services of a RS to hold the Resource and guard
>>> access to that Resource.
>>>
>>> Resource Server (RS) - the party that
>>>       - holds a resource and guards access to that resource on behalf of
>>> the RO,
>>>       - services the Resource to the requesting Client, provided the
>>> Client presents a valid Authorization.
>>>       The RS is generally deployed as a web service.
>>>
>>> Grant Server (GS) - the party that manages access to a Resource on
>>> behalf of the RO. For each Resource access request, the GS might request
>>> the consent of the RO and produce a corresponding Authorization that is
>>> given to the requesting Client.
>>>
>>> Consent - act of an RO approving the release of a Resource he owns to a
>>> Client.
>>>
>>> Grant - material form of an RO Consent. In order not to interact with
>>> the RO on each Resource access request, the GS might store the RO Consent
>>> in the form of a Grant for reuse.
>>>
>>> Authorization - externalized form of a Grant as known to the GS and the
>>> RS.
>>>       - The GS converts a Grant into an Authorization for use in a
>>> Resource access request.
>>>       - The RS evaluates an Authorization to decide on whether or not to
>>> release the Resource to the Client.
>>>
>>> Client - the party that provides the infrastructure used by a User to
>>> access a Resource. The client infrastructure is designed to:
>>>       - Receive the resource access request from the User,
>>>       - Interact with the RS to discover authorization requirements,
>>>       - Interact with the GS to obtain an Authorization to access the
>>> Resource,
>>>       - Interact with the RS to access the Resource on behalf of the
>>> User.
>>>
>>> User - the party using the infrastructure of the Client to gain access
>>> to a Resource.
>>>
>>> This dictionary is supposed to be the base for further discussions that
>>> will allow us to provide each term with just enough description to reduce
>>> ambiguities and misunderstandings in further exchanges. I intentionally
>>> omitted the specification of the type and nature of each party (For example
>>> Client / Registered Client / Dynamic Client). Such elaborations belong IMO
>>> in proper subsections.
>>>
>>> Comments are welcome.
>>>
>>> Best regards.
>>> --
>>> 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/
>

--000000000000e5fe0005aaf760ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


FYI: I consider the release of claims to be an "autho=
rization" as well.=C2=A0

IE, the user authorizes th=
e GS to release a DOB claim=C2=A0to a Client.


=


On Tue, Jul 21, 2020 at 10:42 AM Francis Pouatcha <fpo@adorsys.de> wrote:
On Tue, =
Jul 21, 2020 at 12:00 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Thanks for putt=
ing this together Francis. I like how you have put different aspects of a d=
efinition into separate points. It reinforces the multiple aspects.
I don't see identity claims in your definitions. Was that i=
ntentional, or an oversight.
The extensive dic=
tionary will surely include more terms.=C2=A0

I li=
mited the list to terms relevant to the abstract sequence for now. Making a=
n effort to keep the discussion focused=C2=A0on the abstract sequence.

As we are talking authorization, identities are second=
 class citizens, focus shall be on Negotiating and Obtaining the AuthZ to a=
ccess a Resource.

wrt. Registered Client / Dynamic Client =
- in my experience putting the definitions together helps a reader grasp al=
l the various terms used.
Yes, this clarificat=
ion belongs in the dictionary. Intentionally=C2=A0left it out here to avoid=
 diverging the discussion.

Curious why you include "p=
arty" in the definition. I would not have thought that had a definitio=
n=C2=A0unique to GNAP.
I derived this from you=
r subsection "Parties". As all participants in the abstract seque=
nce are "parties", the word seems too heavy to be left undefined.=
 Also essential to know which words in the dictionary do not refer to parti=
es like Resource, Grant, AuthZ, ...


On Mon, Jul 20, 2020 at 6:0=
1 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick,

Here is (i=
n a new thread) the promised attempt=C2=A0to define terms of interest in th=
e GNAP protocol. 
=C2=A0
Party - represents a role in t=
he GNAP protocol flow. A party can take the form of a web service, an appli=
cation installed on the user device and acting autonomously or the form of =
a natural person (resp. of an autonomous device) using an application to in=
teract with other parties.

Resource - a piece of data or web service=

=C2=A0 =C2=A0 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =
=C2=A0 =C2=A0 - held and guarded by a Resource Server (RS) and
=C2=A0 =
=C2=A0 =C2=A0 - serviced by the RS to a Client, if the Client provides a va=
lid Authorization.

Resource Owner (RO) - the party that 
=C2=A0 =
=C2=A0 =C2=A0 - owns a Resource, 
=C2=A0 =C2=A0 =C2=A0 - relies on the s=
ervices the GS to manage access to that Resource and 
=C2=A0 =C2=A0 =C2=
=A0 - relies on the services of a RS to hold the Resource and guard access =
to that Resource.

Resource Server (RS) - the party that=
=C2=A0
=C2=A0 =C2=A0 =C2=A0 - holds a resource and guards access to that=
 resource on behalf of the RO,
=C2=A0 =C2=A0 =C2=A0 - services the Resou=
rce to the requesting Client, provided the Client presents a valid Authoriz=
ation.
=C2=A0 =C2=A0 =C2=A0 The RS is generally deployed as a web servic=
e.

Grant Server (GS) - the party that manages access to a Resource o=
n behalf of the RO. For each Resource access request, the GS might request =
the consent of the RO and produce a corresponding Authorization that is giv=
en to the requesting Client.

Consent - act of an RO approving the re=
lease of a Resource he owns to a Client.

Grant - material form of an=
 RO Consent. In order not to interact with the RO on each Resource access r=
equest, the GS might store the RO Consent in the form of a Grant for reuse.=


Authorization - externalized form of a Grant as known to the GS and=
 the RS.
=C2=A0 =C2=A0 =C2=A0 - The GS converts a Grant into an Authoriz=
ation for use=C2=A0in a Resource access request.
=C2=A0 =C2=A0 =C2=A0 - =
The RS evaluates an Authorization to decide on whether or not to release th=
e Resource to the Client.

Client - the party that provides the infra=
structure used by a User to access a Resource. The client infrastructure is=
 designed to:
=C2=A0 =C2=A0 =C2=A0 - Receive the resource access request=
 from the User,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to discover =
authorization requirements,
=C2=A0 =C2=A0 =C2=A0 - Interact with the GS =
to obtain an Authorization to access the Resource,
=C2=A0 =C2=A0 =C2=A0 =
- Interact with the RS to access the Resource on behalf of the User.
User - the party using the infrastructure of the Client to gain access to =
a Resource.

This dictionary is supposed to be the =
base for further discussions that will allow us to provide each term with j=
ust enough description to reduce ambiguities and misunderstandings in furth=
er exchanges. I intentionally omitted the specification of the type and nat=
ure of each party (For example Client / Registered Client / Dynamic Client)=
. Such elaborations belong IMO in proper subsections.

<=
div>Comments are welcome.

Best regards.
-- 
=

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






-- 
Francis Pouatcha
Co-Founder and Technical Lead=

adorsys GmbH & Co. KG



--000000000000e5fe0005aaf760ba--


From nobody Tue Jul 21 11:09: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 D710E3A0D6F for ; Tue, 21 Jul 2020 11:09: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 WEeP1LvGBnjt for ; Tue, 21 Jul 2020 11:09:27 -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 B20D43A0D45 for ; Tue, 21 Jul 2020 11:09:26 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id a6so2717368wmm.0 for ; Tue, 21 Jul 2020 11:09:26 -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=AuyygC1Q/tQrXBT1Fmm9En+vtgSBQe9AFqmh1F3JgY4=; b=IxSxP4mAmXoeP/rzcSyF+Iyll6PLkcAi1Hxim05mQwmjO4Ln4kRk8VOgGEyD5chNDM BeZ6IRUfmD+yhrpaHBCo0vKG9VqOag+LVQL0pXrcnMRkNRDhomfRGekVUZs8VwtupRwl FGodJJlR6SRzpWt0BALwCtDCTLwUHAu+rJnyg=
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=AuyygC1Q/tQrXBT1Fmm9En+vtgSBQe9AFqmh1F3JgY4=; b=KeboOukmosWL3SoZyxZ4aFo8pJLwH0uAX/qkfKQNGjAbTeYK8lILI9QWPMgdOyZW/T L24IvQyJGM50mIu9WlPHIhUqHRwCjOt5tliuZLTCuj+CGdxXpWSUm0Ghp6DqcqvI5JA4 EaxOpaJ1hDKdQzuEHeO4oBKo6fIQozgdqOUUFYV0gwgWzvkL2TjVBHHW8xJyCl6rg7Nk EU+/frSKMyeUpl5r5P1O1BjXUENb9bcWnT63gCLNzLTVB1+zzuoQxPMRHRP3ZPAbUk2e kkI8RcavuA5Kh3oa/qA1Vz5mRawt68JiJkxUl+5wZkH84A6/54DovR7hPzhNchI/WkYt SWhw==
X-Gm-Message-State: AOAM531xWu8KITsK9/O98QQCFVzkh9IyhzN5wBeA8WNR74mzdh77j+Rq 5qJrtFbpTJuNqlpJC6Zvw480JqABbvgo5B+8JjRvQg==
X-Google-Smtp-Source: ABdhPJyyRDebdt/AsVE84cLbsTfrMJLuhRZ+SJ2E1LbgDRkOQ+0R43dEo3i9EZV2fZ4xIpyfBGscyQM2UdK54kH+63E=
X-Received: by 2002:a1c:f407:: with SMTP id z7mr5071728wma.8.1595354964979; Tue, 21 Jul 2020 11:09:24 -0700 (PDT)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Francis Pouatcha 
Date: Tue, 21 Jul 2020 14:09:10 -0400
Message-ID: 
To: Dick Hardt 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fa8fb205aaf7855b"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 21 Jul 2020 18:09:29 -0000

--000000000000fa8fb205aaf7855b
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt  wrote:

> FYI: I consider the release of claims to be an "authorization" as well.
>
Great. Then it is included.

>
> IE, the user authorizes the GS to release a DOB claim to a Client.
>
I guess you mean the "RO" authorizes the GS to release a DOB!

>
>
>
> On Tue, Jul 21, 2020 at 10:42 AM Francis Pouatcha  wrote:
>
>>
>> On Tue, Jul 21, 2020 at 12:00 PM Dick Hardt  wrote:
>>
>>> Thanks for putting this together Francis. I like how you have put
>>> different aspects of a definition into separate points. It reinforces the
>>> multiple aspects.
>>>
>>> I don't see identity claims in your definitions. Was that intentional,
>>> or an oversight.
>>>
>> The extensive dictionary will surely include more terms.
>>
>> I limited the list to terms relevant to the abstract sequence for now.
>> Making an effort to keep the discussion focused on the abstract sequence.
>>
>> As we are talking authorization, identities are second class citizens,
>> focus shall be on Negotiating and Obtaining the AuthZ to access a Resource.
>>
>>>
>>> wrt. Registered Client / Dynamic Client - in my experience putting the
>>> definitions together helps a reader grasp all the various terms used.
>>>
>> Yes, this clarification belongs in the dictionary. Intentionally left it
>> out here to avoid diverging the discussion.
>>
>>>
>>> Curious why you include "party" in the definition. I would not have
>>> thought that had a definition unique to GNAP.
>>>
>> I derived this from your subsection "Parties". As all participants in the
>> abstract sequence are "parties", the word seems too heavy to be left
>> undefined. Also essential to know which words in the dictionary do not
>> refer to parties like Resource, Grant, AuthZ, ...
>>
>>>
>>>
>>> On Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha  wrote:
>>>
>>>> Hello Dick,
>>>>
>>>> Here is (in a new thread) the promised attempt to define terms of
>>>> interest in the GNAP protocol.
>>>>
>>>> Party - represents a role in the GNAP protocol flow. A party can take
>>>> the form of a web service, an application installed on the user device and
>>>> acting autonomously or the form of a natural person (resp. of an autonomous
>>>> device) using an application to interact with other parties.
>>>>
>>>> Resource - a piece of data or web service
>>>>       - controlled by a Resource Owner (RO),
>>>>       - held and guarded by a Resource Server (RS) and
>>>>       - serviced by the RS to a Client, if the Client provides a valid
>>>> Authorization.
>>>>
>>>> Resource Owner (RO) - the party that
>>>>       - owns a Resource,
>>>>       - relies on the services the GS to manage access to that Resource
>>>> and
>>>>       - relies on the services of a RS to hold the Resource and guard
>>>> access to that Resource.
>>>>
>>>> Resource Server (RS) - the party that
>>>>       - holds a resource and guards access to that resource on behalf
>>>> of the RO,
>>>>       - services the Resource to the requesting Client, provided the
>>>> Client presents a valid Authorization.
>>>>       The RS is generally deployed as a web service.
>>>>
>>>> Grant Server (GS) - the party that manages access to a Resource on
>>>> behalf of the RO. For each Resource access request, the GS might request
>>>> the consent of the RO and produce a corresponding Authorization that is
>>>> given to the requesting Client.
>>>>
>>>> Consent - act of an RO approving the release of a Resource he owns to a
>>>> Client.
>>>>
>>>> Grant - material form of an RO Consent. In order not to interact with
>>>> the RO on each Resource access request, the GS might store the RO Consent
>>>> in the form of a Grant for reuse.
>>>>
>>>> Authorization - externalized form of a Grant as known to the GS and the
>>>> RS.
>>>>       - The GS converts a Grant into an Authorization for use in a
>>>> Resource access request.
>>>>       - The RS evaluates an Authorization to decide on whether or not
>>>> to release the Resource to the Client.
>>>>
>>>> Client - the party that provides the infrastructure used by a User to
>>>> access a Resource. The client infrastructure is designed to:
>>>>       - Receive the resource access request from the User,
>>>>       - Interact with the RS to discover authorization requirements,
>>>>       - Interact with the GS to obtain an Authorization to access the
>>>> Resource,
>>>>       - Interact with the RS to access the Resource on behalf of the
>>>> User.
>>>>
>>>> User - the party using the infrastructure of the Client to gain access
>>>> to a Resource.
>>>>
>>>> This dictionary is supposed to be the base for further discussions that
>>>> will allow us to provide each term with just enough description to reduce
>>>> ambiguities and misunderstandings in further exchanges. I intentionally
>>>> omitted the specification of the type and nature of each party (For example
>>>> Client / Registered Client / Dynamic Client). Such elaborations belong IMO
>>>> in proper subsections.
>>>>
>>>> Comments are welcome.
>>>>
>>>> Best regards.
>>>> --
>>>> 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/

--000000000000fa8fb205aaf7855b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt <dick.hardt@gmail.com> wrote:
=
FYI: I consider the release of claims to be an "authorization" as=
 well.=C2=A0
Great. Then it is included.=C2=A0
=

IE, the user authorizes the GS to release a DOB claim=C2=A0to a=
 Client.
I guess you mean the "RO" a=
uthorizes the GS to release a DOB!



On Tue, Jul 2=
1, 2020 at 10:42 AM Francis Pouatcha <fpo@adorsys.de> wrote:
On Tue, =
Jul 21, 2020 at 12:00 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Thanks for putt=
ing this together Francis. I like how you have put different aspects of a d=
efinition into separate points. It reinforces the multiple aspects.
I don't see identity claims in your definitions. Was that i=
ntentional, or an oversight.
The extensive dic=
tionary will surely include more terms.=C2=A0

I li=
mited the list to terms relevant to the abstract sequence for now. Making a=
n effort to keep the discussion focused=C2=A0on the abstract sequence.

As we are talking authorization, identities are second=
 class citizens, focus shall be on Negotiating and Obtaining the AuthZ to a=
ccess a Resource.

wrt. Registered Client / Dynamic Client =
- in my experience putting the definitions together helps a reader grasp al=
l the various terms used.
Yes, this clarificat=
ion belongs in the dictionary. Intentionally=C2=A0left it out here to avoid=
 diverging the discussion.

Curious why you include "p=
arty" in the definition. I would not have thought that had a definitio=
n=C2=A0unique to GNAP.
I derived this from you=
r subsection "Parties". As all participants in the abstract seque=
nce are "parties", the word seems too heavy to be left undefined.=
 Also essential to know which words in the dictionary do not refer to parti=
es like Resource, Grant, AuthZ, ...


On Mon, Jul 20, 2020 at 6:0=
1 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick,

Here is (i=
n a new thread) the promised attempt=C2=A0to define terms of interest in th=
e GNAP protocol. 
=C2=A0
Party - represents a role in t=
he GNAP protocol flow. A party can take the form of a web service, an appli=
cation installed on the user device and acting autonomously or the form of =
a natural person (resp. of an autonomous device) using an application to in=
teract with other parties.

Resource - a piece of data or web service=

=C2=A0 =C2=A0 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =
=C2=A0 =C2=A0 - held and guarded by a Resource Server (RS) and
=C2=A0 =
=C2=A0 =C2=A0 - serviced by the RS to a Client, if the Client provides a va=
lid Authorization.

Resource Owner (RO) - the party that 
=C2=A0 =
=C2=A0 =C2=A0 - owns a Resource, 
=C2=A0 =C2=A0 =C2=A0 - relies on the s=
ervices the GS to manage access to that Resource and 
=C2=A0 =C2=A0 =C2=
=A0 - relies on the services of a RS to hold the Resource and guard access =
to that Resource.

Resource Server (RS) - the party that=
=C2=A0
=C2=A0 =C2=A0 =C2=A0 - holds a resource and guards access to that=
 resource on behalf of the RO,
=C2=A0 =C2=A0 =C2=A0 - services the Resou=
rce to the requesting Client, provided the Client presents a valid Authoriz=
ation.
=C2=A0 =C2=A0 =C2=A0 The RS is generally deployed as a web servic=
e.

Grant Server (GS) - the party that manages access to a Resource o=
n behalf of the RO. For each Resource access request, the GS might request =
the consent of the RO and produce a corresponding Authorization that is giv=
en to the requesting Client.

Consent - act of an RO approving the re=
lease of a Resource he owns to a Client.

Grant - material form of an=
 RO Consent. In order not to interact with the RO on each Resource access r=
equest, the GS might store the RO Consent in the form of a Grant for reuse.=


Authorization - externalized form of a Grant as known to the GS and=
 the RS.
=C2=A0 =C2=A0 =C2=A0 - The GS converts a Grant into an Authoriz=
ation for use=C2=A0in a Resource access request.
=C2=A0 =C2=A0 =C2=A0 - =
The RS evaluates an Authorization to decide on whether or not to release th=
e Resource to the Client.

Client - the party that provides the infra=
structure used by a User to access a Resource. The client infrastructure is=
 designed to:
=C2=A0 =C2=A0 =C2=A0 - Receive the resource access request=
 from the User,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to discover =
authorization requirements,
=C2=A0 =C2=A0 =C2=A0 - Interact with the GS =
to obtain an Authorization to access the Resource,
=C2=A0 =C2=A0 =C2=A0 =
- Interact with the RS to access the Resource on behalf of the User.
User - the party using the infrastructure of the Client to gain access to =
a Resource.

This dictionary is supposed to be the =
base for further discussions that will allow us to provide each term with j=
ust enough description to reduce ambiguities and misunderstandings in furth=
er exchanges. I intentionally omitted the specification of the type and nat=
ure of each party (For example Client / Registered Client / Dynamic Client)=
. Such elaborations belong IMO in proper subsections.

<=
div>Comments are welcome.

Best regards.
-- 
=

Francis Pouatcha
Co-Founder an=
d 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/


--000000000000fa8fb205aaf7855b--


From nobody Tue Jul 21 11:15: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 7944F3A0DEC for ; Tue, 21 Jul 2020 11:15: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, 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 oCCLRRWh6bDB for ; Tue, 21 Jul 2020 11:15:43 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 1F7663A0DEA for ; Tue, 21 Jul 2020 11:15:43 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id e8so25132347ljb.0 for ; Tue, 21 Jul 2020 11:15: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=H1S+ohyGPmP9ZG4yUAmNr1KP04dmf51nlw/1NLNgVnk=; b=tozFPKVN7Af/R1JOtsPJUTJQlVVQe9XZzEEgecWbqDsHQ5Nzii3L38LH9V+ToyU40m C9THta48QZah8wWdBVRtzQZ1dek7L7dZ8aDjp4g5MvRHCZVQjCXlr+nqRyVYK4RHL/J5 9MsN9slZFowJUzp2yKJ4pkFWgH5sexj4kD66cHvYNJ3S43EWc2kQ8eOEm06fAyFARC3X tcddBFhML1Zl8drdfWR8mYvavWqL851L7F0TCxSzyIw/hOdW4/Sy6BP2niMOiFmF7m9H B6Kt2i5a4lZvMkbSVlcPmMJRSpCdhNATZdyyAn0LRAGEmMEPIeRbRGwkdzD2NbexkUwK xoDw==
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=H1S+ohyGPmP9ZG4yUAmNr1KP04dmf51nlw/1NLNgVnk=; b=GvGaeQsDluTnsGpXaVRz7se/jkY2gsl6n6gaEougtDdnxEaZrLKJOb7cBdcF2t7pQm IyCy23XS6shfx57akEGYStR3VPQiN8rKPvVluqobPcFWXJ6cJ2v58pYr/3JiJDCvzsGs KPMkV5arnTvx7o+em6QQtaXcMzFL2M5cz6VpZmu2e5/Q05MKxwyFXZd2FwOaZ7Bc0yaV bajaBOnoG1fOW2ynOqyEnAxAZrSwq15sw2Po2EB5UQdRIwLfSzy7Ts1LrWyYshwDfP6E LYB8keWWLNLgjjvAt6LDwPimc3pqgEg/EOC/CaJpaDg7oNY1+a5QaGzWDU5poF53DNe3 GV+g==
X-Gm-Message-State: AOAM532b/JZdNIz3Ano/jL7ZavNvlRLb9FitCh9AAxc67IfW9x17ywou uZrBGBBhbapkKu7cfl0ZquIaFUUks3eL0VwO/pY=
X-Google-Smtp-Source: ABdhPJxXfBL4qjT8oliRlBmLcS42zSOnVI9qFkJYPqtHprgtjIRKkdW8hPiUfjssjX8Y0RM2xkTN766oECAteZbdd70=
X-Received: by 2002:a2e:8316:: with SMTP id a22mr12614246ljh.246.1595355341102;  Tue, 21 Jul 2020 11:15:41 -0700 (PDT)
MIME-Version: 1.0
References:     
In-Reply-To: 
From: Dick Hardt 
Date: Tue, 21 Jul 2020 11:15:05 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000065a5d605aaf79cc9"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 21 Jul 2020 18:15:44 -0000

--00000000000065a5d605aaf79cc9
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha  wrote:

>
> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt  wrote:
>
>> FYI: I consider the release of claims to be an "authorization" as well.
>>
> Great. Then it is included.
>

I pivoted to using the term Grant rather than authorization so that it
included both authorizing access to a resource, and authorizing the release
of an identity claim.

Perhaps we should not use the word "authorization"?

"resource access" and "claim release"

A Grant then covers both?



>
>> IE, the user authorizes the GS to release a DOB claim to a Client.
>>
> I guess you mean the "RO" authorizes the GS to release a DOB!
>

Yes, thanks for clarifying!

/Dick

>

--00000000000065a5d605aaf79cc9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Jul 21, 2020 at 11:09 AM Fran=
cis Pouatcha <fpo@adorsys.de> w=
rote:

On =
Tue, Jul 21, 2020 at 1:59 PM Dick Hardt <dick.hardt@gmail.com> wrote:
FYI: I cons=
ider the release of claims to be an "authorization" as well.=C2=
=A0
Great. Then it is included.=C2=A0

I pivoted to using the term Grant rathe=
r than authorization so that it included both authorizing access to a resou=
rce, and authorizing the release of an identity claim.

=

Perhaps we should not use the word "authorization"?

"resource access" and "claim release"<=
/div>

A Grant then covers both?

=C2=A0

IE, the user authorizes the GS =
to release a DOB claim=C2=A0to a Client.
I gue=
ss you mean the "RO" authorizes the GS to release a DOB!

Yes, thanks for clarifying!
=

=C2=A0
/Dick




--00000000000065a5d605aaf79cc9--


From nobody Tue Jul 21 11:19: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 9E3D73A0DF2 for ; Tue, 21 Jul 2020 11:19:02 -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_FILL_THIS_FORM_SHORT=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 aHw9L1K-ZZyA for ; Tue, 21 Jul 2020 11:18:59 -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 D1C633A0DEE for ; Tue, 21 Jul 2020 11:18:58 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id o2so3815569wmh.2 for ; Tue, 21 Jul 2020 11:18: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=BIZpbCRnC2ScSc4VP6S+WHbUv8leSIisqeLKpJHEE/k=; b=ZbGX8ZOSivVIOBCvXz6gQYZR5r33M2YamF1iNSMpAS8w7MjboaxlJPZ4qpwugNWlU2 noYbhQEQXhaqfFAmW9TrJPHBVf3tI2TWpls7ZiSxGdlwJWxR9xT4a1BHRnVAtyS7QkvK bBR/uQqnE2Aj5V5mFU4dqC2l9Zg2WCPHEl+y4=
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=BIZpbCRnC2ScSc4VP6S+WHbUv8leSIisqeLKpJHEE/k=; b=Vz72ACCej/dxDGuI5xfq6jshd/zv5wlsFuwdDm4zNagaKuc8LUFjicXmCSqFMn0vV1 kNkCGJOddEVjjsaENE4b1ZGOToN2r2kvVCbDf6AehEas7WRYmJxkDdBZOfzN+HOldeRD 3B7TX1908xtlLPrNnZvuYMtnErJwIXlN+LTsWPu1Uy7ZRlP0NqiKmbsjkZVe19CRnoY8 3n7vqWkTD0IrMw9i9qPkEhq8q6mUwdoVV6aZ6ozv9KMnEN7ye0vHiE/dI0R2/16VYvYM PigFlxmlcY7eGY5gPF5hZ4y3EnfE11WXth11ou3xePOdGQZzT4p6djwNbFC7luqFqaW7 jbeQ==
X-Gm-Message-State: AOAM531G83EIM6M0xzoZVdvmGnj4fUcw0o3983INu7U90VkciVBf1yJA ABkHNTe5Gyg5FDjkbiz8lmDRLGmhLiIFRWqs1reohA==
X-Google-Smtp-Source: ABdhPJwZic2fTPfZ1eql2r/8vCsvFd+tLsKUkcFpOJIt0PPsBixnx3cLYbWlbgu6luWLMM92gxfUimbuAtizwYxpPhM=
X-Received: by 2002:a1c:f407:: with SMTP id z7mr5102522wma.8.1595355537086; Tue, 21 Jul 2020 11:18:57 -0700 (PDT)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Francis Pouatcha 
Date: Tue, 21 Jul 2020 14:18:42 -0400
Message-ID: 
To: Tom Jones 
Cc: Dick Hardt , txauth@ietf.org, Justin Richer 
Content-Type: multipart/alternative; boundary="000000000000142b5c05aaf7a877"
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 21 Jul 2020 18:19:03 -0000

--000000000000142b5c05aaf7a877
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Before we dive into discussion on claims, we really do need some sort of
agreement on words like:

- User : I am ok if we find a replacement for this word in the current
draft.
- RO
- Agents (user Agent, RO Agent, ...)

Privacy concerns can be discussed more effectively once we have settled on
those terms.

Best Regards.
/Francis

On Mon, Jul 20, 2020 at 6:14 PM Tom Jones 
wrote:

> if the user must authorize access to the resource, then what better place
> for it than their phone. I don't much worry about inconveniencing some
> gigantic corporation.
> I should be clear tho, *user agents* do not need to be on user phones, i
> was addressing my particular need.
> If the user has delegated authority to some cloud based service, then tha=
t *user
> agent *could could also host an as.
> It is interesting to speculate on whether an IdP (openId provider e.g.)
> could ever be a trusted *user agen*t. Given what I understand of the
> market today, I guess that is not possible. Markets do, however, change.
> Some on the list speculate that the client (sink of user resources) could
> be a *user agent*.  That is, at least, problematic, but conceivable.
> I, personally, would not conflate a client with a *user agent.* After
> all, the user agent has access to (at least some) user accessible resourc=
es.
> maybe you should just rename the as to be a *user agent.* Or at least
> state that the as is an endpoint of a user agent.
>
> BTW, for me a user is an identifier claiming to represent a human at a
> device. Whether they are the RO or a guardian is not of importance here. =
I
> know others have other definitions, sorry about that.
> Peace ..tom
>
>
> On Mon, Jul 20, 2020 at 12:30 PM Dick Hardt  wrote:
>
>> Curious: How are you envisioning the client communicates to the AS if it
>> is on the User's phone?
>> =E1=90=A7
>>
>> On Sun, Jul 19, 2020 at 9:13 PM Tom Jones 
>> wrote:
>>
>>> Well, that might work for you. It won=E2=80=99t work for me. I put the =
as on the
>>> user=E2=80=99s phone. The source and sink of the data can switch roles =
on a
>>> millisecond basis. I will track your progress and adopt what I can.
>>>
>>> ..Tom's phone
>>>
>>> On Jul 19, 2020, at 1:45 PM, Dick Hardt  wrote:
>>>
>>> =EF=BB=BF
>>> Hi Tom
>>>
>>> The proposal is that Client asks for a claim from the AS, the user
>>> consents at the AS, and the AS directly releases the claim directly to =
the
>>> Client. No access token. No resource server.
>>>
>>> Simpler for Client and Grant Server (AS)
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Jul 18, 2020 at 7:34 PM Tom Jones 
>>> wrote:
>>>
>>>> absolutely, yes, tha az token can authorize any resource held by the
>>>> resource server.
>>>> The ONLY thing special about PII is the protection granted by the
>>>> various privacy laws.
>>>>
>>>> As an aside, I don't find much in the current discussion that gives me
>>>> a warm feeling about privacy.
>>>> The stuff in the torsten tokens is about as anti-privacy an effort as
>>>> exists today.
>>>> Identity assurance does NOT need to be enabled by sending more and yet
>>>> again more PII.
>>>> Peace ..tom
>>>>
>>>>
>>>> On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt 
>>>> wrote:
>>>>
>>>>> Hey Tom
>>>>>
>>>>> While I think defining claims is out of scope of the WG, I think
>>>>> enabling a client to obtain claims about a user is in scope.
>>>>> Would you consider authorization for the release of claims to be part
>>>>> of the purpose of this WG?
>>>>>
>>>>> I'm concerned about the XYZ shift to subject identifiers from claims,
>>>>> and pushing claims to a higher layer, as it may indicate to developer=
s that
>>>>> they can ONLY ask for a user identifier.
>>>>>
>>>>> When I think of a claim, I include any and all identifiers, but I als=
o
>>>>> include user attributes such as under-13, over-21,
>>>>> student-at-an-accredited-school, resident of city/state/province/coun=
try.
>>>>>
>>>>> GNAP can enable a client to ask for only the claims it needs,
>>>>> preserving user privacy, and compliance with many privacy regulations=
.
>>>>>
>>>>> Would you agree?
>>>>>
>>>>> /Dick
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jul 18, 2020 at 9:56 AM Tom Jones <
>>>>> thomasclinganjones@gmail.com> wrote:
>>>>>
>>>>>> I agree with Justin's comment " what we should do, as we define GNAP
>>>>>> as a protocol, is focus on this one, limited slice of the identity s=
pace
>>>>>> and not spiral into others."
>>>>>> The title "Authorization" should rule the purposes of this group
>>>>>> above all else.
>>>>>>
>>>>>> The earlier statement that the client should know who the user is -
>>>>>> is just plain WRONG. The client should only know the information the=
 user
>>>>>> is willing to share with the client.
>>>>>> It is now the law in California that the client cannot
>>>>>> demand identity information that is not required for a legitimate bu=
siness
>>>>>> purpose.
>>>>>> There are some clients that act as fiduciaries for the user
>>>>>> (financial and healthcare come to mind), but as a general rule the "=
client"
>>>>>> is not to be trusted by the user.
>>>>>> I understand most of the people on this list are paid by the client'=
s
>>>>>> of the world, but you are still bound by the laws that apply to thos=
e
>>>>>> clients.
>>>>>>
>>>>>> Peace ..tom
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 13, 2020 at 12:31 PM Justin Richer 
>>>>>> wrote:
>>>>>>
>>>>>>> A quick note, as my choice of language below seems to have been
>>>>>>> confusing. First there is a typo, where the word =E2=80=9Cit=E2=80=
=9D should have been =E2=80=9Cin=E2=80=9D
>>>>>>> to read:
>>>>>>>
>>>>>>> I am saying that GNAP, *in* its definition within this working
>>>>>>> group, should be limited to identifier claims.
>>>>>>>
>>>>>>>
>>>>>>> And second, there seems to be confusion around whether I=E2=80=99m =
trying to
>>>>>>> argue about the scope =E2=80=9Callowed=E2=80=9D by the charter by s=
aying =E2=80=9Cits definition
>>>>>>> within this working group=E2=80=9D here.
>>>>>>>
>>>>>>> To be clear, we as the working group are *defining* GNAP the
>>>>>>> protocol. It has not yet been defined, and that=E2=80=99s why were =
all here. The
>>>>>>> charter doesn=E2=80=99t define it. The input specs don=E2=80=99t de=
fine it. The working
>>>>>>> group defines it, and my stance as a contributor to this WG is that=
 we
>>>>>>> should focus on a delegation protocol with some basic identifier qu=
ery
>>>>>>> support and leave the full fledged identity protocol to different w=
ork.
>>>>>>>
>>>>>>> We=E2=80=99ve already got our hands full here without taking all of=
 that on,
>>>>>>> especially since I do believe we need to build GNAP in such a way a=
s to
>>>>>>> facilitate its extension in several known directions, including a f=
ull
>>>>>>> identity protocol. If we do things right here, we can see GNAP as t=
he basis
>>>>>>> of a large number of things out there in the world.
>>>>>>>
>>>>>>> So my stance in what we should do, as we define GNAP as a protocol,
>>>>>>> is focus on this one, limited slice of the identity space and not s=
piral
>>>>>>> into others.
>>>>>>>
>>>>>>>  =E2=80=94 Justin
>>>>>>>
>>>>>>> On Jul 13, 2020, at 2:51 PM, Justin Richer  wrote:
>>>>>>>
>>>>>>> I am saying that GNAP, it its definition within this working group,
>>>>>>> should be limited to identifier claims. Other claims can come from =
other
>>>>>>> protocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t s=
top them from
>>>>>>> being built, but in my opinion we shouldn=E2=80=99t be defining tho=
se here. See the
>>>>>>> discussion below on the extensibility avenues of this approach.
>>>>>>>
>>>>>>>  =E2=80=94 Justin
>>>>>>>
>>>>>>> On Jul 13, 2020, at 2:12 PM, Dick Hardt 
>>>>>>> wrote:
>>>>>>>
>>>>>>> I agree that an API to return claims is useful.. I think we have
>>>>>>> agreed on that.
>>>>>>>
>>>>>>> Using the SubjectIdentifiers schema is another schema that would be
>>>>>>> useful for GNAP to support.
>>>>>>>
>>>>>>> I disagree that GNAP should be limited to identifier claims.
>>>>>>>
>>>>>>> =E1=90=A7
>>>>>>>
>>>>>>> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> One thing I think we should learn from OIDC is that returning
>>>>>>>> claims from an API, and not just an assertion or direct response, =
is a
>>>>>>>> powerful and useful pattern. We have an opportunity to separate th=
ese
>>>>>>>> cleanly, where OIDC didn=E2=80=99t have the opportunity in definin=
g the =E2=80=9Cclaims=E2=80=9D
>>>>>>>> request parameter.
>>>>>>>>
>>>>>>>> As an alternative to the current XYZ and XAuth syntaxes, over the
>>>>>>>> weekend I=E2=80=99ve been playing with something that would look l=
ike this strawman
>>>>>>>> in the request:
>>>>>>>>
>>>>>>>>
>>>>>>>> {
>>>>>>>>    subject: {
>>>>>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
>>>>>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverif=
iable_credential=E2=80=9D, =E2=80=9Csaml"
>>>>>>>> ]
>>>>>>>>    }
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> This request says that I=E2=80=99d like some subset of these ident=
ifiers
>>>>>>>> (as plain text in the response) and some subset of signed assertio=
ns in the
>>>>>>>> given formats. Each one would have an associated space in the retu=
rn. I=E2=80=99m
>>>>>>>> not picturing that the =E2=80=9Cid=E2=80=9D field values would aff=
ect the contents of the
>>>>>>>> assertions: so I could ask for an email address identifier but get=
 back an
>>>>>>>> ID token that had only the subject identifier. Maybe that=E2=80=99=
s not the right
>>>>>>>> model? But it=E2=80=99s at least simple and deterministic this way=
, and it=E2=80=99s
>>>>>>>> something to play with.
>>>>>>>>
>>>>>>>> Note: The =E2=80=9Cid=E2=80=9D names are taken from
>>>>>>>> https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-=
05.html,
>>>>>>>> the =E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=
=99t see a source that collected
>>>>>>>> them. If you wanted specific bundles of claims about the user from=
 a
>>>>>>>> UserInfoEndpoint, for example, you=E2=80=99d have something like:
>>>>>>>>
>>>>>>>> {
>>>>>>>>    subject: {
>>>>>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
>>>>>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =E2=80=9Cverif=
iable_credential=E2=80=9D, =E2=80=9Csaml"
>>>>>>>> ]
>>>>>>>>    },
>>>>>>>>    resources: [{
>>>>>>>>        type: =E2=80=9Cuserinfo=E2=80=9D,
>>>>>>>>        datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=
=80=9D, =E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
>>>>>>>>   }]
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> This is an example for a specific kind of resource, and I don=E2=
=80=99t
>>>>>>>> think that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schem=
a here, or the datatype
>>>>>>>> values therein. That should be work outside of GNAP, probably for =
the OIDF.
>>>>>>>>
>>>>>>>> This approach is extensible in several ways, each of them for a
>>>>>>>> specific reason that I think is clear:
>>>>>>>>
>>>>>>>>  - new values in the =E2=80=9Cid=E2=80=9D field to give new identi=
fiers
>>>>>>>>  - new values in the =E2=80=9Cassertion=E2=80=9D field to give new=
 assertion formats
>>>>>>>>  - new fields under the =E2=80=9Csubject=E2=80=9D heading
>>>>>>>>  - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=
=80=9Cscim-v1=E2=80=9D or
>>>>>>>> =E2=80=9Cfacebook-profile=E2=80=9D for instance)
>>>>>>>>  - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource ty=
pe
>>>>>>>>  - new top-level request parameters
>>>>>>>>
>>>>>>>> As per the other thread, if you wanted to use the OIDC query
>>>>>>>> language, you=E2=80=99d package it separately as a top-level reque=
st parameter
>>>>>>>> since it can include both the ID token response and the access tok=
en
>>>>>>>> response and we shouldn=E2=80=99t be encouraging mixing these thin=
gs together.
>>>>>>>>
>>>>>>>>  =E2=80=94 Justin
>>>>>>>>
>>>>>>>> On Jul 10, 2020, at 5:00 PM, Dick Hardt 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> It looks to me that our different views of what is in scope for
>>>>>>>> GNAP are the differences below.
>>>>>>>>
>>>>>>>> Per the subject line, I'm looking at how the client acquires claim=
s
>>>>>>>> about the user. You don't think that is in scope, and that a diffe=
rent
>>>>>>>> layer will solve that.
>>>>>>>>
>>>>>>>> I think we should learn from OIDC being on top of OAuth, and GNAP
>>>>>>>> should be able return ANY claim, not just identifier claims. There=
 are use
>>>>>>>> cases that may be difficult to support if we do not have that func=
tionality
>>>>>>>> in scope, such as some of the ones I list below, and it seems pret=
ty
>>>>>>>> straightforward to support ANY claim if we are supporting identifi=
ers.
>>>>>>>>
>>>>>>>> /Dick
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jul 10, 2020, at 2:15 PM, Dick Hardt 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> inline ...
>>>>>>>>>
>>>>>>>>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Yes, the core idea is to not have to parse an assertion to get
>>>>>>>>>> back the core authentication information, which consists of an i=
dentifier
>>>>>>>>>> (iss/sub pair in OIDC, but could be a number of things). Sometim=
es the
>>>>>>>>>> client is going to want the rest of the identity information, bu=
t If the
>>>>>>>>>> user=E2=80=99s logged into the client before, the client has lik=
ely cached that
>>>>>>>>>> info and probably won=E2=80=99t need it, and sending it would be=
 a violation of
>>>>>>>>>> privacy principles.. The client would want the info pretty much =
just in
>>>>>>>>>> these cases:
>>>>>>>>>>
>>>>>>>>>>  1. The client has never seen the user before.
>>>>>>>>>>  2. The user=E2=80=99s information has been updated since the la=
st time
>>>>>>>>>> the client saw it.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Agreed
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Now for case (1), how would the client know if it wants to
>>>>>>>>>> request the user=E2=80=99s profile info or not, since it doesn=
=E2=80=99t know who the user
>>>>>>>>>> is?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But the client could know who the user is. The client may have
>>>>>>>>> used a different AS to authenticate the user.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In these cases, the client is not going to be requesting identity
>>>>>>>>> information from the AS to log the user in, so it=E2=80=99s not r=
elevant to the use
>>>>>>>>> case. The client will have an opportunity to push that informatio=
n to the
>>>>>>>>> AS.
>>>>>>>>>
>>>>>>>>> The User may have self identified to the client. The client may
>>>>>>>>> have a cookie saying who the user was and the user said that was =
them.
>>>>>>>>> While the latter cases are really a strong hint, they are likely =
right most
>>>>>>>>> of the time and can lead to a user experience basde on that hint
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In these cases, the AS might be able to guess if the client has
>>>>>>>>> info about the user already, but probably not. And the assumption=
s fall
>>>>>>>>> apart if it=E2=80=99s in fact a different user that ends up loggi=
ng in, which is of
>>>>>>>>> course possible (the hint you gave doesn=E2=80=99t match the iden=
tity of the
>>>>>>>>> current user after the AS validates them). This possibility leads=
 to
>>>>>>>>> clients always asking for everything every time and the server pr=
oviding
>>>>>>>>> everything every time. That=E2=80=99s a pattern I think we should=
 avoid in an
>>>>>>>>> ultimate solution =E2=80=94 but ultimately, I don=E2=80=99t think=
 that this kind of
>>>>>>>>> protocol decision is inside of GNAP.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> And the AS won=E2=80=99t know if client is going to want the pro=
file
>>>>>>>>>> info, since the AS won=E2=80=99t know if the client has the user=
=E2=80=99s info or not.
>>>>>>>>>> Sure, the AS might have seen that client and that user combo pre=
viously,
>>>>>>>>>> but it doesn=E2=80=99t know if the client needs an update.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The client can share with the AS the user it knows or thinks it i=
s
>>>>>>>>> dealing with, which could let the AS respond if the information w=
as new.
>>>>>>>>> This could be the case for an AS that is providing claims, but no=
t
>>>>>>>>> authentication, and could happen silently. The user would only in=
teract if
>>>>>>>>> the user information had changed, and the client wanted the updat=
ed
>>>>>>>>> information.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> See above.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s=
 info has been
>>>>>>>>>> updated or not because it doesn=E2=80=99t know who the user is y=
et. If the AS can
>>>>>>>>>> provide some time of updated stamp to the client, the client can=
 pull the
>>>>>>>>>> new info when it needs it.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> See above.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> See above.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If you ignore both of these cases and put all the user
>>>>>>>>>> information inline with the main request/response, you end up in=
 a
>>>>>>>>>> situation where the client always requests everything and the se=
rver always
>>>>>>>>>> provides everything, since you can=E2=80=99t be sure you=E2=80=
=99re not in situation (1) or
>>>>>>>>>> (2) ahead of time.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> See above. There are a number of other states the client could be
>>>>>>>>> in.
>>>>>>>>>
>>>>>>>>> For example, the client could be stateless about user information=
,
>>>>>>>>> so it knows it is ALWAYS in state 1.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A stateless client would need to fetch appropriate user
>>>>>>>>> information every time, then. But that=E2=80=99s an optimization =
for a very
>>>>>>>>> specific case.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This is really what I mean about the two-stage identity protocol=
.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I know what it is. Per above, GNAP lets us support a wider set of
>>>>>>>>> use cases. Why limit ourselves to what OIDC supported?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We aren=E2=80=99t limiting the protocol, but instead limiting the=
 scope of
>>>>>>>>> what we define internal to the GNAP protocol. There=E2=80=99s a l=
ot of room for
>>>>>>>>> innovation on top of it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> In the first stage, you push the bare minimum of what you need t=
o
>>>>>>>>>> get the user known to the client.. In the second stage, the clie=
nt uses its
>>>>>>>>>> access token to call an API to get whatever else it needs to kno=
w about the
>>>>>>>>>> user.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> From a privacy perspective in non-enterprise use cases, I think
>>>>>>>>> the user should give consent to any updated personal information =
to a
>>>>>>>>> client. In general, the client should not be able to get the late=
st
>>>>>>>>> information about a user whenever it wants.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is about the rights associated with the access token, then.
>>>>>>>>> And an access token doesn=E2=80=99t have to keep working if the A=
S has a policy
>>>>>>>>> that says it won=E2=80=99t. The AS/RS could easily decide that a =
particular access
>>>>>>>>> token will only return data that hasn=E2=80=99t been changed. May=
be it stops
>>>>>>>>> working after the data changes, or it just returns old data, or a=
ny number
>>>>>>>>> of things. This is for the AS/RS to decide and this is pretty sta=
ndard
>>>>>>>>> interpretation of the token, nothing special here because we=E2=
=80=99re dealing
>>>>>>>>> with identity.
>>>>>>>>>
>>>>>>>>>  =E2=80=94 Justin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /Dick
>>>>>>>>> =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
>>>>>>>
>>>>>> --
> 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/

--000000000000142b5c05aaf7a877
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Before we dive into discussion on claims, we really do nee=
d some sort of agreement on words like:

- User : I am ok=
 if we find a replacement for this word in the current draft.
- R=
O
- Agents (user Agent, RO Agent, ...)

P=
rivacy concerns can be discussed=C2=A0more effectively once we have settled=
 on those terms.

Best Regards.
/Francis<=
/div>

On Mon, Jul 20, 2020 at 6:14 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
if the=
 user must authorize access to the resource, then what better place for it =
than their phone. I don't much worry about inconveniencing some giganti=
c corporation.
I should be clear tho, user agents do not need to=
 be on user phones, i was addressing my particular need.
If the u=
ser has delegated authority to some cloud=C2=A0based service, then that =
user agent could could also host an as.
It is interesting=C2=
=A0to speculate on whether an IdP (openId provider e.g.) could ever be a tr=
usted user agent. Given what I understand of the market today, I gue=
ss=C2=A0that is not possible. Markets do, however, change.
Some o=
n the list speculate that the client (sink of user resources) could be a user agent.=C2=A0 That is, at least, problematic, but conceivable. I,=
=C2=A0personally, would not conflate a client with a user agent. Aft=
er all, the user agent has access to (at least some) user accessible resour=
ces.
maybe you should just rename the as to be a user agent. Or at least state that the as is an endpoint of a user agent.
=

BTW, for me a user is an identifier claiming to represent a =
human at a device. Whether they are the RO or a guardian is not of importan=
ce here. I know others have other definitions, sorry about that.
Peace ..tom


On Mon, Jul 20, 2020 at 12:30 PM Dick Hardt <dick.hardt@gmail.com<=
/a>> wrote:
<=
div dir=3D"ltr">Curious: How are you envisioning the client communicates to=
 the AS if it is on the User's phone?

On Sun, Jul 19, 2020 at 9:13 PM Tom Jones <thomasclinganjones@gmail.com>=
; wrote:
Well, that might work for you. It won=E2=80=99t work for me. I p=
ut the as on the user=E2=80=99s phone. The source and sink of the data can =
switch roles on a millisecond basis. I will track your progress and adopt w=
hat I can.

..Tom's phone
=

On Jul 19, 2020, at 1:45 PM, Dick Hardt <<=
a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c=
om> wrote:

=EF=BB=BF
Hi Tom

The proposa=
l is that Client asks for a claim from the AS, the user consents at the AS,=
 and the AS directly releases the claim directly to the Client. No access t=
oken. No resource server.=C2=A0

Simpler for Client=
 and Grant Server (AS)






On Sat, Jul 18, 2020 at 7:34 PM Tom Jones <=
;thomascl=
inganjones@gmail.com> wrote:
absolutely, yes, tha az token can auth=
orize=C2=A0any resource held by the resource server.
The ONLY thing spe=
cial about PII is the protection granted by the various privacy laws.
=


As an aside, I don't find much in the current discu=
ssion that gives me a warm feeling about privacy.
The stuff in th=
e torsten tokens is about as anti-privacy an effort as exists today.
<=
div>Identity assurance does NOT need to be enabled by sending more and yet =
again more PII.
Peace ..tom


On Sat, Jul 18, 2020 at 5:58=
 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Tom

While I think defining claims=C2=A0is out of scope of the WG, I thi=
nk enabling a client to obtain claims about a user is in scope.
<=
div>Would you consider authorization for the release of claims to be part o=
f the purpose of this WG?

I'm=
 concerned about the XYZ shift to subject identifiers from claims, and push=
ing claims to a higher layer, as it may indicate to developers that they ca=
n ONLY ask for a user identifier.=C2=A0

When I thi=
nk of a claim, I include any and all identifiers, but I also include user a=
ttributes such as under-13, over-21, student-at-an-accredited-school, resid=
ent of city/state/province/country.

GNAP can enabl=
e a client to ask for only the claims it needs, preserving user privacy, an=
d compliance with many privacy regulations.

Would =
you agree?

/Dick



On Sat, Jul 18, 2020 at 9:56 AM Tom Jones=
 <thom=
asclinganjones@gmail.com> wrote:
I agree with Justin's comment =
"=C2=A0what we should do, as we define GNAP as a protocol, is focus on=
 this one, limited slice of the identity space and not spiral into others.&=
quot;
The title "Authorization" should rule the purposes of t=
his group above all else.

The earlier statement=C2=
=A0that the client should know who the user is - is just plain WRONG. The c=
lient should only know the information the user is willing to share with th=
e client.
It is now the law in California that the client cannot =
demand=C2=A0identity information that is not required for a legitimate busi=
ness purpose.
There are some clients that act as fiduciaries for =
the user (financial=C2=A0and healthcare come to mind), but as a general rul=
e the "client" is not to be trusted by the user.
I unde=
rstand most of the people=C2=A0on this list are paid by the client's of=
 the world, but you are still bound by the laws that apply to those clients=
.

P=
eace ..tom


On Mon, Jul 13, 2020 at 1=
2:31 PM Justin Richer <jricher@mit.edu> wrote:
A quick note, as my choice of language below seems =
to have been confusing. First there is a typo, where the word =E2=80=9Cit=
=E2=80=9D should have been =E2=80=9Cin=E2=80=9D to read:

I am saying that GNAP, in its defini=
tion within this working group, should be limited to identifier claims.

And second, there seems to be confusion =
around whether I=E2=80=99m trying to argue about the scope =E2=80=9Callowed=
=E2=80=9D by the charter by saying =E2=80=9Cits definition within this work=
ing group=E2=80=9D here.=C2=A0

To be clear, we as =
the working group are defining GNAP the protocol. It has not yet bee=
n defined, and that=E2=80=99s why were all here. The charter doesn=E2=80=99=
t define it. The input specs don=E2=80=99t define it. The working group def=
ines it, and my stance as a contributor to this WG is that we should focus =
on a delegation protocol with some basic identifier query support and leave=
 the full fledged identity protocol to different work.=C2=A0

=

We=E2=80=99ve already got our hands full here without taking all=
 of that on, especially since I do believe we need to build GNAP in such a =
way as to facilitate its extension in several known directions, including a=
 full identity protocol. If we do things right here, we can see GNAP as the=
 basis of a large number of things out there in the world.=C2=A0
=

So my stance in what we should do, as we define GNAP as a pr=
otocol, is focus on this one, limited slice of the identity space and not s=
piral into others.

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

On Jul 13, 2020, at 2:51 PM, Justin Rich=
er <jricher@mit.edu=
> wrote:



I am saying that GNAP, it its definition within this working group, sh=
ould be limited to identifier claims. Other claims can come from other prot=
ocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop them fro=
m being built, but in my opinion we shouldn=E2=80=99t be defining those her=
e. See the discussion below on the extensibility avenues of this approach.<=
div>
=C2=A0=E2=80=94 Justin

On Jul 13, 2020, at 2:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I agree that an API to return claims is useful=
.. I think we have agreed on that.=C2=A0

Using the Subje=
ctIdentifiers schema is another schema that would be useful for GNAP to sup=
port.=C2=A0

I disagree=C2=A0that GNAP should be li=
mited to identifier claims.=C2=A0

3D""=E1=90=A7

On Mon, Jul 13, 2020 at 7:16 AM Justin Richer <jricher@mit.edu> wrote=
:
One thing=
 I think we should learn from OIDC is that returning claims from an API, an=
d not just an assertion or direct response, is a powerful and useful patter=
n. We have an opportunity to separate these cleanly, where OIDC didn=E2=80=
=99t have the opportunity in defining the =E2=80=9Cclaims=E2=80=9D request =
parameter.

As an alternative to the current XYZ and XAut=
h syntaxes, over the weekend I=E2=80=99ve been playing with something that =
would look like this strawman in the request:


=

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Codic_id_token=
=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
=C2=A0 =C2=A0}
}

T=
his request says that I=E2=80=99d like some subset of these identifiers (as=
 plain text in the response) and some subset of signed assertions in the gi=
ven formats. Each one would have an associated space in the return. I=E2=80=
=99m not picturing that the =E2=80=9Cid=E2=80=9D field values would affect =
the contents of the assertions: so I could ask for an email address identif=
ier but get back an ID token that had only the subject identifier. Maybe th=
at=E2=80=99s not the right model? But it=E2=80=99s at least simple and dete=
rministic this way, and it=E2=80=99s something to play with.

=

Note: The =E2=80=9Cid=E2=80=9D names are taken from=C2=A0https://tools.ietf.org/id/draft-ietf-secevent-subject=
-identifiers-05.html, the =E2=80=9Cassertion=E2=80=9D names are made up=
 as I didn=E2=80=99t see a source that collected them. If you wanted specif=
ic bundles of claims about the user from a UserInfoEndpoint, for example, y=
ou=E2=80=99d have something like:

{
=C2=A0 =C2=A0subject: {
=C2=A0 =C2=A0 =C2=A0 id=
: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =E2=80=9Ciss-sub=E2=
=80=9D],
=C2=A0 =C2=A0 =C2=A0 assertion: [ =E2=80=9Cod=
ic_id_token=E2=80=9D, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csam=
l" ]
=C2=A0 =C2=A0},
=C2=A0 =
=C2=A0resources: [{
=C2=A0 =C2=A0 =C2=A0 =C2=A0type: =
=E2=80=9Cuserinfo=E2=80=9D,
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =E2=80=
=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
=C2=A0 }]=

}

This is=
 an example for a specific kind of resource, and I don=E2=80=99t think that=
 GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema here, or the data=
type values therein. That should be work outside of GNAP, probably for the =
OIDF.

This approach is extensible in several ways,=
 each of them for a specific reason that I think is clear:

=C2=A0- new values in the =E2=80=9Cid=E2=80=9D field to give new i=
dentifiers
=C2=A0- new values in the =E2=80=9Cassertion=E2=80=9D =
field to give new assertion formats
=C2=A0- new fields under the =
=E2=80=9Csubject=E2=80=9D heading=C2=A0
=C2=A0- new resource type=
s besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or =E2=
=80=9Cfacebook-profile=E2=80=9D for instance)
=C2=A0- new datatyp=
es within the =E2=80=9Cuserinfo=E2=80=9D resource type
=C2=A0- ne=
w top-level request parameters

As per the other th=
read, if you wanted to use the OIDC query language, you=E2=80=99d package i=
t separately as a top-level request parameter since it can include both the=
 ID token response and the access token response and we shouldn=E2=80=99t b=
e encouraging mixing these things together.

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

On Jul 10, 2020=
, at 5:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It looks to me that our different views of what is in scope for GNAP ar=
e the differences below.

Per the subject line, I'm l=
ooking at how the client acquires claims about the user. You don't thin=
k that is in scope, and that a different layer will solve that.
<=
br>
I think we should learn from OIDC being on top of OAuth, and =
GNAP should be able return ANY claim, not just identifier claims. There are=
 use cases that may be difficult to support if we do not have that function=
ality in scope, such as some of the ones I list below, and it seems pretty =
straightforward to support ANY claim if we are supporting identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09=
 PM Justin Richer <=
jricher@mit.edu> wrote:


On Jul 10, =
2020, at 2:15 PM, Dick Hardt <dick.hardt@gmail.com> wrote:


inline ...=C2=A0

On Thu, Jul 9, 2020 at 5=
:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea is to not have to parse an assert=
ion to get back the core authentication information, which consists of an i=
dentifier (iss/sub pair in OIDC, but could be a number of things). Sometime=
s the client is going to want the rest of the identity information, but=C2=
=A0If the user=E2=80=99s logged into the client before, the client has like=
ly cached that info and probably won=E2=80=99t need it, and sending it woul=
d be a violation of privacy principles.. The client would want the info pre=
tty much just in these cases:

=C2=A01. The client has ne=
ver seen the user before.=C2=A0
=C2=A02. The user=E2=80=99s infor=
mation has been updated since the last time the client saw it.
<=
/blockquote>

Agreed
=C2=A0

Now for case (=
1), how would the client know if it wants to request the user=E2=80=99s pro=
file info or not, since it doesn=E2=80=99t know who the user is? 

But the client could know who the user i=
s. The client may have used a different AS to authenticate the user. 
=


In these cases, th=
e client is not going to be requesting identity information from the AS to =
log the user in, so it=E2=80=99s not relevant to the use case. The client w=
ill have an opportunity to push that information to the AS.

<=
div>The User may have self identified to the client. The client may have a =
cookie saying who the user was and the user said that was them. While the l=
atter cases are really a strong hint, they are likely right most of the tim=
e and can lead to a user experience basde on that hint

In these cases, the AS might be a=
ble to guess if the client has info about the user already, but probably no=
t. And the assumptions fall apart if it=E2=80=99s in fact a different user =
that ends up logging in, which is of course possible (the hint you gave doe=
sn=E2=80=99t match the identity of the current user after the AS validates =
them). This possibility leads to clients always asking for everything every=
 time and the server providing everything every time. That=E2=80=99s a patt=
ern I think we should avoid in an ultimate solution =E2=80=94 but ultimatel=
y, I don=E2=80=99t think that this kind of protocol decision is inside of G=
NAP.

=C2=A0
And the AS won=E2=80=99t know if client is going to wa=
nt the profile info, since the AS won=E2=80=99t know if the client has the =
user=E2=80=99s info or not. Sure, the AS might have seen that client and th=
at user combo previously, but it doesn=E2=80=99t know if the client needs a=
n update.

The client can share =
with the AS the user it knows or thinks it is dealing with, which could let=
 the AS respond if the information was new. This could be the case for an A=
S that is providing claims, but not authentication, and could happen silent=
ly. The user would only interact if the user information had changed, and t=
he client wanted the updated information.
=C2=A0

See above.


And =
for (2), the client won=E2=80=99t know if the user=E2=80=99s info has been =
updated or not because it doesn=E2=80=99t know who the user is yet. If the =
AS can provide some time of updated stamp to the client, the client can pul=
l the new info when it needs it.

See above.

See a=
bove.

=C2=A0

If you ignore both of these cases=
 and put all the user information inline with the main request/response, yo=
u end up in a situation where the client always requests everything and the=
 server always provides everything, since you can=E2=80=99t be sure you=E2=
=80=99re not in situation (1) or (2) ahead of time.

See above. There are a number of other states the clie=
nt could be in.

For example, the client could be s=
tateless about user information, so it knows it is ALWAYS in state 1.
=


A stateless client=
 would need to fetch appropriate user information every time, then. But tha=
t=E2=80=99s an optimization for a very specific case.

=
=C2=A0

This=
 is really what I mean about the two-stage identity protocol. 
<=
/blockquote>

I know what it is. Per above, GNAP lets us =
support a wider set of use cases. Why limit ourselves to what OIDC supporte=
d?

We aren=E2=
=80=99t limiting the protocol, but instead limiting the scope of what we de=
fine internal to the GNAP protocol. There=E2=80=99s a lot of room for innov=
ation on top of it.

=C2=A0
In the first stage, you push the bare m=
inimum of what you need to get the user known to the client.. In the second=
 stage, the client uses its access token to call an API to get whatever els=
e it needs to know about the user. 

=

From a privacy perspective in non-enterprise use cases, I think the us=
er should give consent to any updated personal information to a client. In =
general, the=C2=A0client should not be able to get the latest information a=
bout a user whenever it wants.

This is about the rights associated with the access token=
, then. And an access token doesn=E2=80=99t have to keep working if the AS =
has a policy that says it won=E2=80=99t. The AS/RS could easily decide that=
 a particular access token will only return data that hasn=E2=80=99t been c=
hanged. Maybe it stops working after the data changes, or it just returns o=
ld data, or any number of things. This is for the AS/RS to decide and this =
is pretty standard interpretation of the token, nothing special here becaus=
e we=E2=80=99re dealing with identity.

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

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









-- 
Txauth mailing list
Txauth@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/txauth
<=
br>-- 

Txauth mailing 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/


--000000000000142b5c05aaf7a877--


From nobody Tue Jul 21 11:22: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 E65E53A0E03 for ; Tue, 21 Jul 2020 11:22: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 joVczapeTZCU for ; Tue, 21 Jul 2020 11:22:20 -0700 (PDT)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0: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 7B8FE3A0E02 for ; Tue, 21 Jul 2020 11:22:20 -0700 (PDT)
Received: by mail-oi1-x22c.google.com with SMTP id y22so18020063oie.8 for ; Tue, 21 Jul 2020 11:22:20 -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=YZyoOtrsibUUOUS+JVnQ6r6Wt4Ib0ewV1tFsM8XR8iU=; b=GIH6oKa8VZgymO6xx7eWaBAHHxMTaQs7CZp6XxXe61bAkqtpNR+I9QjrKppRRAOJ9U xWMgyt4jXmh111xAUUY88fUK9Y1ojpZpXGdpJ1odzQ9TlVFit5Mdynud7zejtuWkUjDW lu/MVJiR32DNyRmrFh4TRbg/9Eq1uYfSXIKoUQhk+bXC+m3V9gk/5HSh2suTluZ27iah QIA6l/UQqumTKyYAdRu6Xnc4Z/TOh7Ira62X37bvDgokqRk5RnO1rcM8XFdR8SnOKqNe 9yptkdBE7U5pD9uTH++OaOeKfFj+6pRNmT5z68iXo9NKGvz6FQ0QZ2Gylex+iDhG5+B4 RA+g==
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=YZyoOtrsibUUOUS+JVnQ6r6Wt4Ib0ewV1tFsM8XR8iU=; b=LDFf4YukRE/BhhA/OKJDywUFKzBAqhHBMxECqS0mJjHqzSgRsPjWoZH3bX5Ay8dI0H wtwWnHLhtZtPzH6APEtrUXV4FqvOR0DBhxktEjMYSoIADQUd+vMljNR7BQlqlGSreUYl 2bCKtd+9oqKL4acgdkmbfcDCovYQnWBn/hZ1W2g7jzhlRFA1JsCTVfmMcl62p0S2xrRX vkdeKhyxe7ptLljGXiRkHwhDYPDL1hAuCmnh4eZkyPvWaZwaWS7z7X+RuvxbDKjvEJRW 9ZnorINzs+LjKD/bgfrhgrcTfVjm8fhSiLN9U1+4NRZeUGiMtUycXz7JfRmizKtTM85y WE5w==
X-Gm-Message-State: AOAM530Ct5W0djv08V6WziKXLE4vw7lgCMrG5MqXN0mHI+Thr3N4WqE1 9cnrHcvD0KmV/jgqHHJgcQWgdGPYkUCFMpD9HJY=
X-Google-Smtp-Source: ABdhPJxrznQ/hx0xJJTnEv3+JX1Wyy4fOm6FwLRhcSKeIehsNM7JAuMHD/V4fQ1FElhLQ9/6sg4a5u8cT9kurzviYTo=
X-Received: by 2002:aca:aa57:: with SMTP id t84mr4252338oie.131.1595355739183;  Tue, 21 Jul 2020 11:22:19 -0700 (PDT)
MIME-Version: 1.0
References:      
In-Reply-To: 
From: Tom Jones 
Date: Tue, 21 Jul 2020 11:22:06 -0700
Message-ID: 
To: Dick Hardt 
Cc: Francis Pouatcha , txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001feb5b05aaf7b47c"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 21 Jul 2020 18:22:22 -0000

--0000000000001feb5b05aaf7b47c
Content-Type: text/plain; charset="UTF-8"

Peace ..tom


On Tue, Jul 21, 2020 at 11:15 AM Dick Hardt  wrote:

>
>
> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha  wrote:
>
>>
>> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt  wrote:
>>
>>> FYI: I consider the release of claims to be an "authorization" as well.
>>>
>> Great. Then it is included.
>>
>
> I pivoted to using the term Grant rather than authorization so that it
> included both authorizing access to a resource, and authorizing the release
> of an identity claim.
>
> Perhaps we should not use the word "authorization"?
>
> "resource access" and "claim release"
>
> A Grant then covers both?
>
>
>
>>
>>> IE, the user authorizes the GS to release a DOB claim to a Client.
>>>
>> I guess you mean the "RO" authorizes the GS to release a DOB!
>>
>
> Yes, thanks for clarifying!
>
> /Dick
>
>> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--0000000000001feb5b05aaf7b47c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Peace ..to=
m


On Tue, Jul 21, 2020 at 11:15 AM Dick Hardt &=
lt;dick.hardt@gmail.com> wro=
te:


On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha=
 <fpo@adorsys.de=
> wrote:

On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt <dick.hardt@gmail.com> wrote:
FYI: =
I consider the release of claims to be an "authorization" as well=
.=C2=A0
Great. Then it is included.=C2=A0

I pivoted to using the term Grant r=
ather than authorization so that it included both authorizing access to a r=
esource, and authorizing the release of an identity claim.

Perhaps we should not use the word "authorization"?

"resource access" and "claim release&qu=
ot;

A Grant then covers both?

=

=C2=A0

IE, the user authorizes the=
 GS to release a DOB claim=C2=A0to a Client.
I=
 guess you mean the "RO" authorizes the GS to release a DOB!

Yes, thanks for clarifying!
=C2=A0
/Dick
=




-- 

Txauth mailing list

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



--0000000000001feb5b05aaf7b47c--


From nobody Tue Jul 21 11:26: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 A98A93A02C1 for ; Tue, 21 Jul 2020 11:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.631
X-Spam-Level: 
X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, 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 YeliqKIoZvd9 for ; Tue, 21 Jul 2020 11:26:40 -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 D91913A0044 for ; Tue, 21 Jul 2020 11:26:39 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d36 with ME id 5uSd230012bcEcA03uSd9Y; Tue, 21 Jul 2020 20:26:37 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 21 Jul 2020 20:26:37 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt 
Cc: Francis Pouatcha , txauth@ietf.org
References:              <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr> 
From: Denis 
Message-ID: <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>
Date: Tue, 21 Jul 2020 20:26:36 +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="------------420AE9D2A04F2F5D33B6C6B3"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 21 Jul 2020 18:26:44 -0000

This is a multi-part message in MIME format.
--------------420AE9D2A04F2F5D33B6C6B3
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Dick,

Thank you for your feedback. Comments are between the lines.

> comments inserted ...
>
> On Tue, Jul 21, 2020 at 6:03 AM Denis  > wrote:
>
>     Hello Dick,
>
>     I duplicate the most important comment at the beginning of this email:
>
>         You are considering using an access control model to build
>         a**workflow model.
>         **
>         While it may be interesting to define a workflow model, this
>         should be considered
>         as a separate and different work item.
>
>     See the other comments between the lines.
>
>>     On Mon, Jul 20, 2020 at 2:05 AM Denis >     > wrote:
>>
>>         Hi Dick,
>>
>>>         On Fri, Jul 17, 2020 at 9:21 AM Denis >>         > wrote:
>>>
>>>             Hello Francis and Dick,
>>>
>>>             The good news first: we are making some progress. We are
>>>             now close to an agreement with steps (1) up to (3),
>>>             ... except that the place where the user consent is
>>>             captured is not mentioned/indicated.
>>>
>>
>>         This major question which is currently left unanswered is
>>         where, when and how the user consent is captured.
>>
>>
>>     When is covered, per the sequence. How and where are out of scope
>>     of what I drafted.
>
>     It is clear that the "User consent and choice" is not currently
>     addressed in the draft, but it should.
>     The support of the "User consent and choice" has strong
>     implications not only in the sequences of the exchanges
>     but also by which entity it should be performed.
>
> "consent" is in the latest draft 7 times.

"Consent" is present 5 times. The User consent is different from the RO 
consent (when/if it is required).

    The server acquires consent and authorization from the user
    *and/**or resource owner **if required.*

    User consent is *often required* at the GS. GNAP enables a Client
    and  GS to negotiate the interaction mode for the GS to obtain consent.

    The GS *may *require explicit consent from the RO or User to provide
    these to the Client.

The User consent is not an alternative to the RO consent. So using 
"and/or" in the first sentence is incorrect.

Since the second sentence is using the wording "often required" there is 
no requirement to get the User consent.

The second sentence does not consider the possibility to get the User 
consent in a place different from the GS.

IMO, the User consent should be captured by the Client, i.e. not by the GS.
The information used to obtain the User consent should be standardized 
(... and it can be standardized).

>
> I think the abstract sequence as proposed by Francis is a great 
> addition, and would clarify where consent is in the sequence.

The current sketch does not illustrate the place the User Consent is 
captured, in particular by the Client.

>>         Another important point to consider and to explain is related
>>         to the assurances that the user can obtain about
>>         the respect of his choices. This point is currently left
>>         unanswered in draft-hardt-xauth-protocol-13.
>>
>     This point is equally important: such assurance can only be
>     obtained if the access token returned to the client
>     is not considered to be opaque to the client. This is a necessary
>     condition but not the single condition:
>     the Client must also be in a position to capture/memorize the
>     "User consent and choice" of the user in order to be able
>     to verify it afterwards using the content of the access token(s).
>
>
> We disagree on this being a requirement for all use cases. It may be 
> in some.

OK. Then this means that there will be no sentence in the draft such as :
"access tokens returned to the client are not considered to be opaque to 
the client".

>>
>>>             If a RO needs to be involved and since a RO is directly
>>>             associated with a RS, why can't it be directly queried
>>>             by the appropriate RS after step (2) or later on ?
>>>
>>>
>>>         Good question. Perhaps you can expand on a use case where
>>>         that would be useful?
>>
>>         Before I expand, would you be able to explain first under
>>         which circumstances a RO needs to be queried by a GS ?
>>         How can the GS identify which RO to query ?
>>
>>     If the User is the RO, then the GS knows who to query.
>
>     I still have difficulties to understand what you mean here.
>     How could a GS know that "the User is the RO" ?  If "the User is
>     the RO", why does the GS needs to query the User ?
>
>
> To get consent?

To get a "RO consent" to himself ???

>>     If the RO is a separate entity, then the GS knows the RO from the
>>     RS being queried.
>
>      ... and this gives the ability for the GS to log/trace all the
>     RSs accessed by a given User and at which instant of time the
>     access token has been granted.
>
>>     An example is a user would like access to an enterprise asset
>>     where a workflow is started to gain approval, and an
>>     administrator or manager provides consent.
>
>     Thanks for this example. I finally understand what you have in
>     mind: you are considering using an access control model to build a
>     *workflow model*.
>     While it may be interesting to define a workflow model, this
>     should be considered as a *separate and different work item*.
>
>
> The actual workflow is out of scope.

I am glad you agree with this. But this means that your example was not 
appropriate to illustrate your point.

As soon as there is a RO consent obtained at the GS, the major problem 
is that the GS is able to act as Big Brother.
If a RO consent is performed at the RS, then the GS will not know who 
the RS is: it is then unable to act as Big Brother,
even if it would enjoy to play that role.

> if the admin grants access, then the access granted to the client 
> changes.
>
>     The model you propose may be suited for an enterprise environment
>     but is not scalable over the Internet.
>
> It is one of the use cases we are working to address.
>
>     What is needed is an access control model usable over the Internet
>     with millions of RSs and thousands of ASs/GSs.
>
> I agree the model should also scale to internet scale.

Fine. Another point on which we are in agreement.

The model can scale to the Internet based on the following assumptions:

    The flow starts with the steps (1) to (4) as illustrated by Francis,
    i.e. the flow starts with a contact with a RS.

*+----+  +------+  +---+  +---+  +---+
|User|  |Client|  |RS |  |GS |  |RO |
+----+  +------+  +---+  +-+-+  +-+-+
   |(1) Service Request     |      |
   |-------->|       |      |      |
   |         |(2) Service Intent   |
   |         |------>|      |      |
   |         |(3) AuthZ Challenge  |
   |         |<------|      |      |
   |         |(4) AuthZ Request    |
   |         |------------->|      |*

The GS/AS does not need to have any prior relationship with ROs and/or RSs.

Furthermore, it is possible to prevent the GS to act as Big Brother when 
the identity of the RS is not disclosed to the GS.

>>>             Which information is supposed to be presented to the RO ?
>>>             Which information is supposed to be returned by the RO ?
>>>
>>>
>>>         Just like how the user authenticates to an AS, how the AS
>>>         and RO communicate is out of scope.
>>
>>         At the moment, the usefulness of a dialogue between a GS and
>>         a RO has not been explained, nor demonstrated.
>>         The question is about the functionality of that dialogue in
>>         terms of input and output information (and not about
>>         the design of a protocol or of a user interface). Anyway,
>>         AFAIU a dialogue between a GS and a RO is optional.
>>
>>
>>     See enterprise example above.
>
>     It is not an access control example, but a workflow example.
>
>     Access  control has been defined a long time ago and the last
>     edition of the model has been confirmed in year 1996:
>     ISO/IEC 10181-3: 1996.
>     "Information technology — Open Systems Interconnection — Security
>     frameworks for open systems: Access control framework — Part 3".
>
>     Two major functions have ben defined: an AccessControl Enforcement
>     Function (AEF) and an AccessControl Decision Function(ADF).
>
>         AccessControl Enforcement Function (AEF):
>         A specialized function that is part of the access path between
>         an initiator and a target on each access request and enforces
>         the decision made by the ADF.
>
>         AccessControl Decision Function (ADF) :
>         A specialized function that makes access control decisions by
>         applying access control policy rules to an access request, ADI
>         (of initiators, targets, access requests,
>         or that retained from prior decisions), and the context in
>         which the access request is made.
>
>     The role of the RO is to define the "access control policy rules"
>     at the RS according to thecontext in which the access request is made.
>
> I'm pretty familiar with access control systems. :)
>
> I would say that the access control is happening at the RS. The client 
> presents a token when accessing an API.
> The RS uses the token, and any policy required, to make an access 
> decision.

Fine. It looks like we are in agreement. Unfortunately, this is not the 
case just below.

> Here is flow:
>
> 1) The Client requests access to an RS from the GS.

No. We are no more in agreement. This is different from the flow drawn 
by Francis.

> 2) The GS queries the RS if access should be granted.

  No. The GS should not be forced to have a flow with the RS.

> 3) If access is granted, the GS creates an access token representing 
> the granted access, and returns it to the Client.

This model is by no way conformant to ISO/IEC 10181-3: 1996

> 4) The Client presents the access token to the RS to show it has been 
> granted access.

No. The client presents a token when accessing an API. The RS uses the 
token, and any policy required, to make an access decision.
The token never contains an information like "Please grant an access to 
the holder of this token".

>
> A couple advantages of this model:
> - that the RS does not need to know much, if anything about the Client.
> - the access token MAY be self contained so that the Client does not 
> need to query the GS on each access.

There are so many disadvantages that I will not list them.

> I would not say that GNAP is an access control protocol, as how the RS 
> uses the token to determine access is out of scope.

This is where we have a major discrepancy: how the RS uses the token to 
determine access is *within* the scope.

The RS announces in advance to the client what it needs so that the 
client can perform a a given operation and if the client supplies the 
requested attributes
obtained from some GS/AS(s) trusted by the RS, then access to that RS is 
granted by the RS. If the RS cannot perform the requested operation on 
its own,
then the client should be informed about some requested attributes that 
need to be obtained from some GS/AS(s) trusted by the next RS(s) in a chain
for subsequent operations. The User consent should also be obtained 
before performing the chaining operation.

Chaining operations between RSs over the Internet is within the scope 
(... and may be achieved).

>>>         For many use cases, the User is the RO, and the interaction
>>>         is through a user interface, not a machine protocol.
>>
>>         Wait a second. You wrote "the User is the RO". The User is
>>         attempting to make an access to a RS by using a Client.
>>         _That_ User is not the RO of the RS.
>>
>>     The user being the RO is the initial use case for OAuth.
>
>     OAuth 2.0 is no more mandating such a case.
>
>
> I don't know what you mean by that.

Copy and paste from draft-ietf-oauth-security-topics:

    OAuth initially assumed a static relationship between client,
    authorization server and resource servers.  (...)
    With the increasing adoption of OAuth, this simple model dissolved
    and, in several scenarios, was replaced
    by a dynamic establishment of the relationship between clients on
    one side and the authorization and
    resource servers of a particular deployment on the other side.

    This way, the same client could be used to access services of
    different providers (in case of standard APIs,
    such as e-mail or OpenID Connect) or serve as a frontend to a
    particular tenant in a multi-tenancy environment.

>>     A client application would like access to the user's photos at a
>>     photo sharing site. The resource is the user's photos. The user
>>     is the owner of that resource.
>
>     If the user has already pre established the access control policy
>     rules so that it can access to his own photos
>     then he does not need to grant in real time any additional
>     authorization.
>
> I don't understand what you are trying to say. The photo sharing 
> example was a driving use case for the creation of OAuth.

We would need to revisit the original scenario and consider if it can be 
addressed in a different way than the original way.

Denis

>
> /Dick



--------------420AE9D2A04F2F5D33B6C6B3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Dick,

    


    

    
 Thank you for your feedback. Comments
      are between the lines.

    


    

    

      
      

        
comments inserted ... 

        

        

          
On Tue, Jul 21, 2020 at 6:03
            AM Denis <denis.ietf@free.fr>
            wrote:

          

          

            

              
Hello Dick,

              


              

              
I duplicate the most important comment at the
                beginning of this email:

              

                
You are considering using an access control model
                  to build a workflow model.

                   

                  While it may be interesting to define a workflow
                  model, this should be considered 

                  as a separate and different work item.

              

              
See the other comments between the lines.

              

              


              

              

                
On Mon, Jul 20, 2020 at 2:05 AM Denis
                  <denis.ietf@free.fr>
                  wrote:

                  

                    

                      

                        
Hi Dick,

                        


                        

                        

                          
On Fri, Jul 17, 2020 at 9:21 AM
                            Denis <denis.ietf@free.fr>
                            wrote:

                            

                              

                                

                                  
Hello Francis and Dick,

                                  


                                  

                                  
The good news first: we are
                                    making some progress. We are now
                                    close to an agreement with steps (1)
                                    up to (3), 

                                    ... except that the place where the
                                    user consent is captured is not
                                    mentioned/indicated.

                                

                              

                            

                          

                        

                        

                        This major question which is currently left
                        unanswered is where, when and how the user
                        consent is captured.

                      

                    

                    


                    

                    
When is covered, per the sequence. How and
                      where are out of scope of what I drafted. 

                    

                  

                

              

              
It is clear that the "User consent and choice" is not
                currently addressed in the draft, but it should.

                The support of the "User consent and choice" has strong
                implications not only in the sequences of the exchanges
                

                but also by which entity it should be performed.

            

          

          
"consent" is in the latest draft 7 times. 

          

        

      

    

    
"Consent" is present 5 times. The User consent is different from
      the RO consent (when/if it is required). 

    

    

      
The server acquires consent and authorization from the user and/or
          resource owner if required.

      

      
User consent is often required at the GS. GNAP enables
        a Client and  GS to negotiate the interaction mode for the GS to
        obtain consent.

      

      
 The GS may require explicit consent from the RO or
        User to provide these to the Client.

      

    

    
The User consent is not an alternative to the RO consent. So
      using "and/or" in the first sentence is incorrect.

    
Since the second sentence is using the wording "often required" there
      is no requirement to get the User consent.

    

    
The second sentence does not consider the possibility to get the
      User consent in a place different from the GS.

    
IMO, the User consent should be captured by the Client, i.e. not
      by the GS. 

      The information used to obtain the User consent should be
      standardized (... and it can be standardized).

    

    

      

        


          
I think the abstract sequence as proposed by Francis is a
            great addition, and would clarify where consent is in the
            sequence.

        

      

    

    
The current sketch does not illustrate the place the User Consent
      is captured, in particular by the Client.

    

      

        

          
 

          

            

              

                

                  

                    

                      
 Another important point to consider and to
                        explain is related to the assurances that the
                        user can obtain about 

                        the respect of his choices. This point is
                        currently left unanswered in
                        draft-hardt-xauth-protocol-13.

                      

                    

                  

                

              

              
This point is equally important: such assurance can
                only be obtained if the access token returned to the
                client 

                is not considered to be opaque to the client. This is a
                necessary condition but not the single condition: 

                the Client must also be in a position to
                capture/memorize the "User consent and choice" of the
                user in order to be able 

                to verify it afterwards using the content of the access
                token(s).

            

          

          


          

          
We disagree on this being a requirement for all use
            cases. It may be in some. 

          

        

      

    

    
OK. Then this means that there will be no sentence in the draft
      such as :

      "access tokens returned to the client are not considered to be
      opaque to the client".

    

      

        

          
 

          

            

              

                

                  

                    

                      
 

                        

                          

                            

                              

                                

                                  
If a RO needs to be involved and
                                    since a RO is directly associated
                                    with a RS, why can't it be directly
                                    queried 

                                    by the appropriate RS after step (2)
                                    or later on ?

                                

                              

                              


                              

                              
Good question. Perhaps you can expand
                                on a use case where that would be
                                useful?

                            

                          

                        

                        
Before I expand, would you be able to explain
                          first under which circumstances a RO needs to
                          be queried by a GS ?

                          How can the GS identify which RO to query ?

                      

                    

                    
If the User is the RO, then the GS knows who to
                      query. 

                    

                  

                

              

              
I still have difficulties to understand what you mean
                here. 

                How could a GS know that "the User is the RO" ?  If "the
                User is the RO", why does the GS needs to query the User
                ? 

              

            

          

          


          

          
To get consent?

        

      

    

    
To get a "RO consent" to himself ???

    

      

        

          
 

          

            

              

                

                  

                    
If the RO is a separate entity, then the GS
                      knows the RO from the RS being queried. 

                    

                  

                

              

              
 ... and this gives the ability for the GS to log/trace
                all the RSs accessed by a given User and at which
                instant of time the access token has been granted.

              

                

                  

                    
An example is a user would like access to an
                      enterprise asset where a workflow is started to
                      gain approval, and an administrator or manager
                      provides consent.

                  

                

              

              
Thanks for this example. I finally understand what you
                have in mind: you are considering using an access
                control model to build a workflow model. 

                While it may be interesting to define a workflow model,
                this should be considered as a separate and
                  different work item.

            

          

          


          

          
The actual workflow is out of scope. 

        

      

    

    
I am glad you agree with this. But this means that your example
      was not appropriate to illustrate your point.

      

      As soon as there is a RO consent obtained at the GS, the major
      problem is that the GS is able to act as Big Brother.

      If a RO consent is performed at the RS, then the GS will not know
      who the RS is: it is then unable to act as Big Brother, 

      even if it would enjoy to play that role.

    

      

        

          
if the admin grants access, then the access granted to
            the client changes. 

          

          

            

              
 

              
The model you propose may be suited for an enterprise
                environment but is not scalable over the Internet.

            

          

          
It is one of the use cases we are working to address. 

          

          

            

              
 What is needed is an access control model usable over
                the Internet with millions of RSs and thousands of
                ASs/GSs.  

              

            

          

          
I agree the model should also scale to internet scale. 

          

        

      

    

    
Fine. Another point on which we are in agreement. 

    

    
The model can scale to the Internet based on the following
      assumptions:

    

      
The flow starts with the steps (1) to (4) as illustrated by
        Francis, i.e. the flow starts with a contact with a RS.

    

    
+----+  +------+
           +---+  +---+  +---+

          |User|  |Client|  |RS |  |GS |  |RO |

          +----+  +------+  +---+  +-+-+  +-+-+

            |(1) Service Request     |      |

            |-------->|       |      |      |

            |         |(2) Service Intent   |

            |         |------>|      |      |

            |         |(3) AuthZ Challenge  |

            |         |<------|      |      |

            |         |(4) AuthZ Request    |

            |         |------------->|      |

    
The GS/AS does not need to have any prior relationship with ROs
      and/or RSs.

    
Furthermore, it is possible to prevent the GS to act as Big
      Brother when the identity of the RS is not disclosed to the GS.

    

    

      

        

          

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                

                                  
Which information is supposed to
                                    be presented to the RO ?

                                    Which information is supposed to be
                                    returned by the RO ?

                                

                              

                              


                              

                              
Just like how the user authenticates
                                to an AS, how the AS and RO communicate
                                is out of scope.

                              

                            

                          

                        

                        
At the moment, the usefulness of a dialogue
                          between a GS and a RO has not been explained,
                          nor demonstrated.

                          The question is about the functionality of
                          that dialogue in terms of input and output
                          information (and not about 

                          the design of a protocol or of a user
                          interface). Anyway, AFAIU a dialogue between a
                          GS and a RO is optional.

                        

                      

                    

                    


                    

                    
See enterprise example above.

                  

                

              

              
It is not an access control example, but a workflow
                example.

              
Access  control has been defined a
                long time ago and the last edition of the model has been
                confirmed in year 1996: ISO/IEC 10181-3: 1996.

                "Information
                  technology — Open Systems Interconnection — Security
                  frameworks for open systems: Access control
                  framework — Part 3".

              
Two
                  major functions have ben defined: an Access Control Enforcement
                    Function (AEF) and an Access Control Decision
                  Function(ADF).

              

                
Access Control Enforcement
                    Function (AEF):

                    A specialized function that is part of the access
                    path between an initiator and a target on each
                    access request and enforces the decision made by the
                    ADF.

                Access Control Decision
                  Function (ADF) :

                A specialized function
                  that makes access control decisions by applying access
                  control policy rules to an access request, ADI (of
                  initiators, targets, access requests, 

                or that retained from
                  prior decisions), and the context in which the access
                  request is made.

              
The role of the RO is to define the "access control policy
                  rules" at the RS according to the context in which the
                    access request is made.

            

          

          
I'm pretty familiar with access control systems. :) 

          


          

          
I would say that the access control is happening at the
            RS. The client presents a token when accessing an API. 

            The RS uses the token, and any policy required, to make an
            access decision.

        

      

    

    
Fine. It looks like we are in agreement. Unfortunately, this is
      not the case just below.

    

    

      

        

          
Here is flow:

          


          

          
1) The Client requests access to an RS from the GS. 

          

        

      

    

    
No. We are no more in agreement. This is different from the flow
      drawn by Francis.

    

      

        

          
2) The GS queries the RS if access should be granted. 

          

        

      

    

    
 No. The GS should not be forced to have a flow with the RS.

    

    

      

        

          
3) If access is granted, the GS creates an access token
            representing the granted access, and returns it to the
            Client. 

          

        

      

    

    
This model is by no way conformant to ISO/IEC 10181-3: 1996 

        

    

      

        

          
4) The Client presents the access token to the RS to show
            it has been granted access. 

          

        

      

    

    
No. The client presents a token when accessing an API. The RS
      uses the token, and any policy required, to make an access
      decision.

      The token never contains an information like "Please grant an
      access to the holder of this token".

    

      

        

          


          

          
A couple advantages of this model:

          
- that the RS does not need to know much, if anything
            about the Client. 

          
- the access token MAY be self contained so that the
            Client does not need to query the GS on each access. 

          

        

      

    

    
There are so many disadvantages that I will not list them.

    

      

        

          
I would not say that GNAP is an access control protocol,
            as how the RS uses the token to determine access is out of
            scope.

        

      

    

    
This is where we have a major
          discrepancy: how the RS uses the token to
      determine access is *within* the scope.

    
The RS announces in advance to the client what it needs so that
      the client can perform a a given operation and if the client
      supplies the requested attributes 

      obtained from some GS/AS(s) trusted by the RS, then access to that
      RS is granted by the RS. If the RS cannot perform the requested
      operation on its own, 

      then the client should be informed about some requested attributes
      that need to be obtained from some GS/AS(s) trusted by the next
      RS(s) in a chain

      for subsequent operations. The User consent should also be
      obtained before performing the chaining operation.

    

    
Chaining operations between RSs over the Internet is within the
      scope (... and may be achieved).

    

      

        

          

            

              

                

                  

                    
 

                    

                      

                        

                          

                            

                              
For many use cases, the User is the
                                RO, and the interaction is through a
                                user interface, not a machine protocol.
                                

                              

                            

                          

                        

                        
Wait a second. You wrote "the User is the
                          RO". The User is attempting to make an access
                          to a RS by using a Client. 

                          That User is not the RO of the RS.   

                        

                      

                    

                    
The user being the RO is the initial use case
                      for OAuth. 

                  

                

              

              
OAuth 2.0 is no more mandating such a case.

              

            

          

        

      

    

    

      

        


          
I don't know what you mean by that.

        

      

    

    
Copy and paste from draft-ietf-oauth-security-topics:

    

    

      
OAuth initially assumed a static relationship between client,
        authorization server and resource servers.  (...)  

        With the increasing adoption of OAuth, this simple model
        dissolved and, in several scenarios, was replaced 

        by a dynamic establishment of the relationship between clients
        on one side and the authorization and 

        resource servers of a particular deployment on the other side.

        

        This way, the same client could be used to access services of
        different providers (in case of standard APIs, 

        such as e-mail or OpenID Connect) or serve as a frontend to a
        particular tenant in a multi-tenancy environment. 

      

    

    

      

        

          
 

          

            

              

                

                  

                    
A client application would like access to the
                      user's photos at a photo sharing site. The
                      resource is the user's photos. The user is the
                      owner of that resource.

                  

                

              

              
If the user has already pre established the access
                control policy rules so that it can access to his own
                photos 

                then he does not need to grant in real time any
                additional authorization.

            

          

          
I don't understand what you are trying to say. The photo
            sharing example was a driving use case for the creation of
            OAuth.

        

      

    

    
We would need to revisit the original scenario and consider if it
      can be addressed in a different way than the original way.

    

    
Denis

    

    

      

        

          


          

          
/Dick

        

      

    

    


    

  


--------------420AE9D2A04F2F5D33B6C6B3--


From nobody Tue Jul 21 11:27: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 ECA973A0365 for ; Tue, 21 Jul 2020 11:27:25 -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 p29C2BWrbnLg for ; Tue, 21 Jul 2020 11:27:24 -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 416813A0303 for ; Tue, 21 Jul 2020 11:27:24 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id c80so3784035wme.0 for ; Tue, 21 Jul 2020 11:27:24 -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=n9tUL5QEfTEssa97/8pySic6tmQ2yfCULtz4vs4IiX8=; b=grr5C3dy2CXQ8ASZu2Hxbu+xy3QyympaSe9fgbfC45FL8UyUv0QRrAX0IDzePsfxwR KWj2OmWjlI229gbeM2cJbkScK/MEBWEnaeNRRLtQbXan5v60AgZP7IQ1kmvINnxFXZzW WaHqPEd8UVwF1rKD6yjUYfbIwygH2G2JBmPGQ=
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=n9tUL5QEfTEssa97/8pySic6tmQ2yfCULtz4vs4IiX8=; b=Yjr4L7N/gNOqFtcaQDTd0JoUBqBBVjDL/LsTsiCtfXdjXX4/tDkfCnDGk2tt7ZRkJv FHj/0sQ64VDWuHsccwbNnw5pLxMbzPZgwmY0tcCFBapOj8CtuNbDCL9aMfcZnYG/oAzm cjj0kBKSIw4OpTkS8l/56NAFmDcPKRK+DTWYXQEtuHOY8tQOpqfDU+jpgk1L8E2oHMZy 4ggc2yqK/O1UQdiCcM7JuiWUA/PvyQdskPqxOdWOOF2Hk1EkEgz088AyIem1GVRyf41Y 9yt+T7YiXwGZq2h8jQrncozN5O3XmS2e+4Pbc/kFabBv+VLFiwUarWmR1er/YRZGwFBY FI4g==
X-Gm-Message-State: AOAM53095cwoR54XVvFGDKWCQzjB5DLMWUP5bkNoh39sR0MOH8hrMkh9 diT0Iz3DUfWL1RApSUUTjKV4dxSEXsNmLimHmCBnrxye
X-Google-Smtp-Source: ABdhPJxbYaDbY5UvZIqca+XqNE5Dhcw/UqCAa4hI5mgHSqAikeODMXL2mHTUNFwMJRHjbhZ4AeF6Lvd2bhdxv3LefKs=
X-Received: by 2002:a1c:f407:: with SMTP id z7mr5128271wma.8.1595356042675; Tue, 21 Jul 2020 11:27:22 -0700 (PDT)
MIME-Version: 1.0
References:      
In-Reply-To: 
From: Francis Pouatcha 
Date: Tue, 21 Jul 2020 14:27:10 -0400
Message-ID: 
To: Dick Hardt 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000036d80905aaf7c629"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 21 Jul 2020 18:27:26 -0000

--00000000000036d80905aaf7c629
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt  wrote:

>
>
> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha  wrote:
>
>>
>> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt  wrote:
>>
>>> FYI: I consider the release of claims to be an "authorization" as well.
>>>
>> Great. Then it is included.
>>
>
> I pivoted to using the term Grant rather than authorization so that it
> included both authorizing access to a resource, and authorizing the release
> of an identity claim.
>
> Perhaps we should not use the word "authorization"?
>
Authorization is currently used to refer to the token issued by the GSand
presented to the RS by the Client. I have no alternative word for now.

>
> "resource access" and "claim release"
>
> A Grant then covers both?
>
Yes, Great! The word Grant fits best for both. I suggest adding this
clarification to that dictionary.

>
>
>
>>
>>> IE, the user authorizes the GS to release a DOB claim to a Client.
>>>
>> I guess you mean the "RO" authorizes the GS to release a DOB!
>>
>
> Yes, thanks for clarifying!
>
> /Dick
>
>>

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--00000000000036d80905aaf7c629
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Tue, Jul 21, 2020 at 2:15 PM Dick =
Hardt <dick.hardt@gmail.com&=
gt; wrote:


On Tue, Jul 21, 2020 at 11:09 AM Francis P=
ouatcha <fpo@adorsys=
.de> wrote:
<=
div dir=3D"ltr">
On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt <dick.hardt@gmail.com> wrote:=

FYI: I consider the release of claims to be an "authorization" =
as well.=C2=A0
Great. Then it is included.=C2=A0

I pivoted to using the term =
Grant rather than authorization so that it included both authorizing access=
 to a resource, and authorizing the release of an identity claim.

Perhaps we should not use the word "authorization"=
;?=C2=A0
Authorization is currently used=
 to refer to the token issued by the GSand presented to the RS by the Clien=
t. I have no alternative word for now.

"resource access" and "claim release"

A Grant then covers both?
Yes, Great! The word Grant fits best for both. I suggest adding this clar=
ification to that dictionary.

=
=C2=A0

IE, the user authorizes the GS t=
o release a DOB claim=C2=A0to a Client.
I gues=
s you mean the "RO" authorizes the GS to release a DOB!

Yes, thanks for clarifying!
<=
div>=C2=A0
/Dick






-- 
Francis Pouatcha
Co-=
Founder and Technical Lead
adorsys GmbH & Co. KG
https://=
adorsys-platform.de/solutions/


--00000000000036d80905aaf7c629--


From nobody Tue Jul 21 11: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 BAA903A0780 for ; Tue, 21 Jul 2020 11:50:11 -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 GGsuA3HoQYqD for ; Tue, 21 Jul 2020 11:50:08 -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 C7BC03A0772 for ; Tue, 21 Jul 2020 11:50:07 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id e8so25237318ljb.0 for ; Tue, 21 Jul 2020 11:50: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=iE7dtHb/hQLbONaABuUfgzJhqlXqCImgkvJ+YJnC0S8=; b=VL46TWOhjdGh6UNDdT/aY6nMdIbVaosRR2zQ6Pzb9GbvhidZ9+oOTpFbGpcifPHzPo UGmGJBh5aIyGelt6hgfju6nU/NmCb9aRFaLchzFFLLG3icIKH0icov0kNdTuVU9VIXXV haZSDRkAVDfrPOc+NAiljD91KDEvWZmya1nveEf2FB9XB1UkI9UGxhjwdBpF4GBGGJmG e7I/2N+066J1kJzmbJJg8Cu634iqSUXYOnCBQ6QWJ8FyYRkgRoHRsUQC+nXC7F0bllbl 2Q3osgYIju+U0duiZc5lbdM2Dp8+lyqP+OmGlkyg76smxRD1EnBdqrPgozuB9OqioZMV yWFQ==
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=iE7dtHb/hQLbONaABuUfgzJhqlXqCImgkvJ+YJnC0S8=; b=nwA/sr/MEZ24ZUR0frHs/JSP0BL6qKZjxBYdE2XYYEjNihAnsSKGwvARy+hn/zYyDH UNtA22EypVsfStrl8gkXp49CCGWMJi4vejSsq/3s8v/TgGNl3oTti3DdWHbr1/EL+Vim aYFRSQb86f5n7BQqDixNq+vct7wf/rPTBEkx9xG3+SD79tLuk2DaXz8GE3faBbpOz13a 7ed1OSQssyt/9v6XoIKZ/Jiyg9hwFMeLhc2n9++tTOup4bK4WA3LeXFodB0uxyF+HYq5 slVpUxr59BAuy5AEI0fbWayg+mWjhmRILzLPL2TM+EmRrO2VAWg2QTAGaneNod+05/uh jVMg==
X-Gm-Message-State: AOAM531sCR0VbwgBs2LiHONM3kPVuvIysAhTrxh/GP62oCUCyIo5Ahmc ywYlMT5hxfDgn1MJKeaeKpbWbBWc/ZyXCtESvG4=
X-Google-Smtp-Source: ABdhPJxxikMP/JI/Z4Hn6CvQxu+PVfDc0mAYZAv6FMk7mxziipXR0PM1LaMikpGH+gveVyQGkH1619x68+vH9UNCFP4=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr14077728ljn.5.1595357405574; Tue, 21 Jul 2020 11:50:05 -0700 (PDT)
MIME-Version: 1.0
References:              <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>
In-Reply-To: <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>
From: Dick Hardt 
Date: Tue, 21 Jul 2020 11:49:28 -0700
Message-ID: 
To: Denis 
Cc: Francis Pouatcha , txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000072fba805aaf81758"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 21 Jul 2020 18:50:12 -0000

--00000000000072fba805aaf81758
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 21, 2020 at 11:26 AM Denis  wrote:

> Hello Dick,
>
> Thank you for your feedback. Comments are between the lines.
>
> comments inserted ...
>
> On Tue, Jul 21, 2020 at 6:03 AM Denis  wrote:
>
>> Hello Dick,
>>
>> I duplicate the most important comment at the beginning of this email:
>>
>> You are considering using an access control model to build a workflow
>> model.
>>
>> While it may be interesting to define a workflow model, this should be
>> considered
>> as a separate and different work item.
>>
>> See the other comments between the lines.
>>
>> On Mon, Jul 20, 2020 at 2:05 AM Denis  wrote:
>>
>>> Hi Dick,
>>>
>>> On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:
>>>
>>>> Hello Francis and Dick,
>>>>
>>>> The good news first: we are making some progress. We are now close to
>>>> an agreement with steps (1) up to (3),
>>>> ... except that the place where the user consent is captured is not
>>>> mentioned/indicated.
>>>>
>>>
>>> This major question which is currently left unanswered is where, when
>>> and how the user consent is captured.
>>>
>>
>> When is covered, per the sequence. How and where are out of scope of wha=
t
>> I drafted.
>>
>> It is clear that the "User consent and choice" is not currently addresse=
d
>> in the draft, but it should.
>> The support of the "User consent and choice" has strong implications not
>> only in the sequences of the exchanges
>> but also by which entity it should be performed.
>>
> "consent" is in the latest draft 7 times.
>
> "Consent" is present 5 times. The User consent is different from the RO
> consent (when/if it is required).
>
> The server acquires consent and authorization from the user *and/**or
> resource owner **if required.*
>
> User consent is *often required* at the GS. GNAP enables a Client and  GS
> to negotiate the interaction mode for the GS to obtain consent.
>
> The GS *may *require explicit consent from the RO or User to provide
> these to the Client.
>
> The User consent is not an alternative to the RO consent. So using
> "and/or" in the first sentence is incorrect.
>

My language is sloppy there. Consent is always from the RO. The User may be
the RO.


> Since the second sentence is using the wording "often required" there is
> no requirement to get the User consent.
>

User consent may not be required. There may not be a User. The consent may
have been gathered previously.


> The second sentence does not consider the possibility to get the User
> consent in a place different from the GS.
>

Agreed. But we do agree that the GS gets the consent, either directly from
the RO, or from the Client (in your example)


> IMO, the User consent should be captured by the Client, i.e. not by the
> GS.
> The information used to obtain the User consent should be standardized
> (... and it can be standardized).
>
>
> I think the abstract sequence as proposed by Francis is a great addition,
> and would clarify where consent is in the sequence.
>
> The current sketch does not illustrate the place the User Consent is
> captured, in particular by the Client.
>

It is an abstraction. The GS receives the consent. How consent is gathered
is a detail that is dependent on the use case.


>
>
>> Another important point to consider and to explain is related to the
>>> assurances that the user can obtain about
>>> the respect of his choices. This point is currently left unanswered in
>>> draft-hardt-xauth-protocol-13.
>>>
>> This point is equally important: such assurance can only be obtained if
>> the access token returned to the client
>> is not considered to be opaque to the client. This is a necessary
>> condition but not the single condition:
>> the Client must also be in a position to capture/memorize the "User
>> consent and choice" of the user in order to be able
>> to verify it afterwards using the content of the access token(s).
>>
>
> We disagree on this being a requirement for all use cases. It may be in
> some.
>
> OK. Then this means that there will be no sentence in the draft such as :
> "access tokens returned to the client are not considered to be opaque to
> the client".
>

For OAuth use cases, which GNAP supports, the access token is opaque to the
Client. As you have noted, there are use cases where the access token is
NOT opaque.



>
>
>>
>>> If a RO needs to be involved and since a RO is directly associated with
>>>> a RS, why can't it be directly queried
>>>> by the appropriate RS after step (2) or later on ?
>>>>
>>>
>>> Good question. Perhaps you can expand on a use case where that would be
>>> useful?
>>>
>>> Before I expand, would you be able to explain first under which
>>> circumstances a RO needs to be queried by a GS ?
>>> How can the GS identify which RO to query ?
>>>
>> If the User is the RO, then the GS knows who to query.
>>
>> I still have difficulties to understand what you mean here.
>> How could a GS know that "the User is the RO" ?  If "the User is the RO"=
,
>> why does the GS needs to query the User ?
>>
>
> To get consent?
>
> To get a "RO consent" to himself ???
>

The GS needs consent from the RO. If the RO is the User, then consent from
the RO is equivalent to consent from the User.


>
>
>> If the RO is a separate entity, then the GS knows the RO from the RS
>> being queried.
>>
>>  ... and this gives the ability for the GS to log/trace all the RSs
>> accessed by a given User and at which instant of time the access token h=
as
>> been granted.
>>
>> An example is a user would like access to an enterprise asset where a
>> workflow is started to gain approval, and an administrator or manager
>> provides consent.
>>
>> Thanks for this example. I finally understand what you have in mind: you
>> are considering using an access control model to build a *workflow model=
*.
>>
>> While it may be interesting to define a workflow model, this should be
>> considered as a *separate and different work item*.
>>
>
> The actual workflow is out of scope.
>
> I am glad you agree with this. But this means that your example was not
> appropriate to illustrate your point.
>

It illustrates a use case where the RO and User are not the same party, and
why the GS needs to query the RO, which was your question if I understood
it correctly.


>
> As soon as there is a RO consent obtained at the GS, the major problem is
> that the GS is able to act as Big Brother.
> If a RO consent is performed at the RS, then the GS will not know who the
> RS is: it is then unable to act as Big Brother,
> even if it would enjoy to play that role.
>

In an enterprise use case, the GS's knowledge of who is accessing which RS
is a feature.

In your use cases, it seems that the RO is the User. The GS knows the User
is wanting to let a Client access something. If the access token is
generic, and could be presented to any RS that provides a standardized
function, then the GS does not know which RS is being accessed by a Client
for the User. This seems to meet your privacy objectives. If not, what is
wrong?



> if the admin grants access, then the access granted to the client changes=
.
>
>> The model you propose may be suited for an enterprise environment but is
>> not scalable over the Internet.
>>
> It is one of the use cases we are working to address.
>
>> What is needed is an access control model usable over the Internet with
>> millions of RSs and thousands of ASs/GSs.
>>
> I agree the model should also scale to internet scale.
>
> Fine. Another point on which we are in agreement.
>
> The model can scale to the Internet based on the following assumptions:
>
> The flow starts with the steps (1) to (4) as illustrated by Francis, i.e.
> the flow starts with a contact with a RS.
>
>
>
>
>
>
>
>
>
>
>
> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS |  |R=
O
> | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Request     |     =
 |
>   |-------->|       |      |      |   |         |(2) Service Intent   |  =
 |
>         |------>|      |      |   |         |(3) AuthZ Challenge  |   |
>     |<------|      |      |   |         |(4) AuthZ Request    |   |
> |------------->|      |*
>
> The GS/AS does not need to have any prior relationship with ROs and/or RS=
s.
>
> Furthermore, it is possible to prevent the GS to act as Big Brother when
> the identity of the RS is not disclosed to the GS.
>

What happens after (4) above?


> Which information is supposed to be presented to the RO ?
>>>> Which information is supposed to be returned by the RO ?
>>>>
>>>
>>> Just like how the user authenticates to an AS, how the AS and RO
>>> communicate is out of scope.
>>>
>>> At the moment, the usefulness of a dialogue between a GS and a RO has
>>> not been explained, nor demonstrated.
>>> The question is about the functionality of that dialogue in terms of
>>> input and output information (and not about
>>> the design of a protocol or of a user interface). Anyway, AFAIU a
>>> dialogue between a GS and a RO is optional.
>>>
>>
>> See enterprise example above.
>>
>> It is not an access control example, but a workflow example.
>>
>> Access  control has been defined a long time ago and the last edition of
>> the model has been confirmed in year 1996: ISO/IEC 10181-3: 1996.
>> "Information technology =E2=80=94 Open Systems Interconnection =E2=80=94=
 Security
>> frameworks for open systems: Access control framework =E2=80=94 Part 3".
>>
>> Two major functions have ben defined: an Access Control Enforcement Func=
tion
>> (AEF) and an Access Control Decision Function(ADF).
>>
>> Access Control Enforcement Function (AEF):
>> A specialized function that is part of the access path between an
>> initiator and a target on each access request and enforces the decision
>> made by the ADF.
>> Access Control Decision Function (ADF) :
>> A specialized function that makes access control decisions by applying
>> access control policy rules to an access request, ADI (of initiators,
>> targets, access requests,
>> or that retained from prior decisions), and the context in which the
>> access request is made.
>>
>> The role of the RO is to define the "access control policy rules" at the
>> RS according to the context in which the access request is made.
>>
> I'm pretty familiar with access control systems. :)
>
> I would say that the access control is happening at the RS. The client
> presents a token when accessing an API.
> The RS uses the token, and any policy required, to make an access decisio=
n.
>
> Fine. It looks like we are in agreement. Unfortunately, this is not the
> case just below.
>
> Here is flow:
>
> 1) The Client requests access to an RS from the GS.
>
> No. We are no more in agreement. This is different from the flow drawn by
> Francis.
>

My bad. Typo. I meant RO.


> 2) The GS queries the RS if access should be granted.
>
>  No. The GS should not be forced to have a flow with the RS.
>

Same mistake as above, I meant RO.

> 3) If access is granted, the GS creates an access token representing the
> granted access, and returns it to the Client.
>
> This model is by no way conformant to ISO/IEC 10181-3: 1996
>
I'm unclear on why, or why it is even relevant.


> 4) The Client presents the access token to the RS to show it has been
> granted access.
>
> No. The client presents a token when accessing an API. The RS uses the
> token, and any policy required, to make an access decision.
> The token never contains an information like "Please grant an access to
> the holder of this token".
>
Let me provide more clarity in the sentence:

The Client presents the access token to the RS, to show the RS that the
Client has been granted access to a resource at the RS by the GS.


>
> A couple advantages of this model:
> - that the RS does not need to know much, if anything about the Client.
> - the access token MAY be self contained so that the Client does not need
> to query the GS on each access.
>
> There are so many disadvantages that I will not list them.
>
Darn: I clearly was not firing on all cylinders when I typed this out. Let
me correct:

- the access token MAY be self contained so that the RS does not need to
query the GS on each access to the RS by the Client.



> I would not say that GNAP is an access control protocol, as how the RS
> uses the token to determine access is out of scope.
>
> This is where we have a major discrepancy: how the RS uses the token to
> determine access is *within* the scope.
>
> The RS announces in advance to the client what it needs so that the clien=
t
> can perform a a given operation and if the client supplies the requested
> attributes
> obtained from some GS/AS(s) trusted by the RS, then access to that RS is
> granted by the RS. If the RS cannot perform the requested operation on it=
s
> own,
> then the client should be informed about some requested attributes that
> need to be obtained from some GS/AS(s) trusted by the next RS(s) in a cha=
in
> for subsequent operations. The User consent should also be obtained befor=
e
> performing the chaining operation.
>
> Chaining operations between RSs over the Internet is within the scope (..=
.
> and may be achieved).
>
>
>>
>>> For many use cases, the User is the RO, and the interaction is through =
a
>>> user interface, not a machine protocol.
>>>
>>> Wait a second. You wrote "the User is the RO". The User is attempting t=
o
>>> make an access to a RS by using a Client.
>>> *That* User is not the RO of the RS.
>>>
>> The user being the RO is the initial use case for OAuth.
>>
>> OAuth 2.0 is no more mandating such a case.
>>
>
> I don't know what you mean by that.
>
> Copy and paste from draft-ietf-oauth-security-topics:
>
> OAuth initially assumed a static relationship between client,
> authorization server and resource servers.  (...)
> With the increasing adoption of OAuth, this simple model dissolved and, i=
n
> several scenarios, was replaced
> by a dynamic establishment of the relationship between clients on one sid=
e
> and the authorization and
> resource servers of a particular deployment on the other side.
>
> This way, the same client could be used to access services of different
> providers (in case of standard APIs,
> such as e-mail or OpenID Connect) or serve as a frontend to a particular
> tenant in a multi-tenancy environment.
>
>
This sentence does not mention the RO or the Client. I'm confused what we
are talking about

>
>
>> A client application would like access to the user's photos at a photo
>> sharing site. The resource is the user's photos. The user is the owner o=
f
>> that resource.
>>
>> If the user has already pre established the access control policy rules
>> so that it can access to his own photos
>> then he does not need to grant in real time any additional authorization=
.
>>
> I don't understand what you are trying to say. The photo sharing example
> was a driving use case for the creation of OAuth.
>
> We would need to revisit the original scenario and consider if it can be
> addressed in a different way than the original way.
>
The use case is the same. Is there a different solution you are proposing?

--00000000000072fba805aaf81758
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Tue, Jul 21, 2020=
 at 11:26 AM Denis <denis.ietf@fre=
e.fr> wrote:

 =20
   =20
 =20
  

    
Hello Dick,

    


    

    
 Thank you for your feedback. Comments
      are between the lines.

    


    

    

     =20
      

        
comments inserted ...=C2=A0

        

        

          
On Tue, Jul 21, 2020 at 6:0=
3
            AM Denis <denis.ietf@free.fr>
            wrote:

          

          

            

              
Hello Dick,

              


              

              
I duplicate the most important comment at the
                beginning of this email:

              

                
You are considering using an access control model
                  to build a workflow model.

                   

                  While it may be interesting to define a workflow
                  model, this should be considered 

                  as a separate and different work item.

              

              
See the other comments between the lines.

              

              


              

              

                
On Mon, Jul 20, 2020 at 2:05 AM Denis
                  <denis.ietf@free.fr>
                  wrote:

                  

                    

                      

                        
Hi Dick,

                        


                        

                        

                          
On Fri, Jul 17, 2020 at 9:21 AM
                            Denis <denis.ietf@free.fr>
                            wrote:

                            

                              

                                

                                  
Hello Francis and Dick,

                                  


                                  

                                  
The good news first: we are
                                    making some progress. We are now
                                    close to an agreement with steps (1)
                                    up to (3), 

                                    ... except that the place where the
                                    user consent is captured is not
                                    mentioned/indicated.

                                

                              

                            

                          

                        

                        

                        This major question which is currently left
                        unanswered is where, when and how the user
                        consent is captured.

                      

                    

                    


                    

                    
When is covered, per the sequence. How and
                      where are out of scope of what I drafted. 

                    

                  

                

              

              
It is clear that the "User consent and choice" i=
s not
                currently addressed in the draft, but it should.

                The support of the "User consent and choice" has =
strong
                implications not only in the sequences of the exchanges
                

                but also by which entity it should be performed.

            

          

          
"consent" is in the latest draft 7 times. 

          

        

      

    

    
"Consent" is present 5 times. The User consent is differen=
t from
      the RO consent (when/if it is required). 

    

    

      
The server acquires consent and authorization from the user and=
/or
          resource owner if required.

      

      
User consent is often required at the GS. GNAP enables
        a Client and=C2=A0 GS to negotiate the interaction mode for the GS =
to
        obtain consent.

      

      
 The GS may require explicit consent from the RO or
        User to provide these to the Client.

      

    

    
The User consent is not an alternative to the RO consent. So
      using "and/or" in the first sentence is incorrect.

My language is sloppy there. Consent is a=
lways from the RO. The User may be the RO.
=C2=A0

    
Since the second sentence is using the wording "often required&=
quot; there
      is no requirement to get the User consent.
=


User consent may not be required. There may not be a Us=
er. The consent may have been gathered previously.
=C2=A0

    

    
The second sentence does not consider the possibility to get the
      User consent in a place different from the GS.
=


Agreed. But we do agree that the GS gets the consent, e=
ither directly from the RO, or from the Client (in your example)
=
=C2=A0

    
IMO, the User consent should be captured by the Client, i.e. not
      by the GS. 

      The information used to obtain the User consent should be
      standardized (... and it can be standardized).

    

    

      

        


          
I think the abstract sequence as proposed by Francis is a
            great addition, and would clarify where consent is in the
            sequence.

        

      

    

    
The current sketch does not illustrate the place the User Consent
      is captured, in particular by the Client.
=

It is an abstraction. The GS receives the consent. How conse=
nt is gathered is a detail that is dependent on the use case.
=C2=
=A0

    

      

        

          
=C2=A0

          

            

              

                

                  

                    

                      
 Another important point to consider and to
                        explain is related to the assurances that the
                        user can obtain about 

                        the respect of his choices. This point is
                        currently left unanswered in
                        draft-hardt-xauth-protocol-13.

                      

                    

                  

                

              

              
This point is equally important: such assurance can
                only be obtained if the access token returned to the
                client 

                is not considered to be opaque to the client. This is a
                necessary condition but not the single condition: 

                the Client must also be in a position to
                capture/memorize the "User consent and choice" of=
 the
                user in order to be able 

                to verify it afterwards using the content of the access
                token(s).

            

          

          


          

          
We disagree on this being a requirement for all use
            cases. It may be in some. 

          

        

      

    

    
OK. Then this means that there will be no sentence in the draft
      such as :

      "access tokens returned to the client are not considered to be
      opaque to the client".

For OAuth use cases, which GNAP supports, the access token is opaque to th=
e Client. As you have noted, there are use cases where the access token is =
NOT opaque.

=C2=A0

    

      

        

          
=C2=A0

          

            

              

                

                  

                    

                      
 

                        

                          

                            

                              

                                

                                  
If a RO needs to be involved and
                                    since a RO is directly associated
                                    with a RS, why can't it be directly
                                    queried 

                                    by the appropriate RS after step (2)
                                    or later on ?

                                

                              

                              


                              

                              
Good question. Perhaps you can expand
                                on a use case where that would be
                                useful?

                            

                          

                        

                        
Before I expand, would you be able to explain
                          first under which circumstances a RO needs to
                          be queried by a GS ?

                          How can the GS identify which RO to query ?

                      

                    

                    
If the User is the RO, then the GS knows who to
                      query. 

                    

                  

                

              

              
I still have difficulties to understand what you mean
                here. 

                How could a GS know that "the User is the RO" ?=
=C2=A0 If "the
                User is the RO", why does the GS needs to query the Us=
er
                ? 

              

            

          

          


          

          
To get consent?

        

      

    

    
To get a "RO consent" to himself ???

The GS needs consent from the RO. If the RO is the Use=
r, then consent from the RO is equivalent to consent from the User.
=C2=A0

    

      

        

          
=C2=A0

          

            

              

                

                  

                    
If the RO is a separate entity, then the GS
                      knows the RO from the RS being queried. 

                    

                  

                

              

              
=C2=A0... and this gives the ability for the GS to log/tra=
ce
                all the RSs accessed by a given User and at which
                instant of time the access token has been granted.

              

                

                  

                    
An example=C2=A0is a user would like access to an
                      enterprise asset where a workflow is started to
                      gain approval, and an administrator or manager
                      provides consent.

                  

                

              

              
Thanks for this example. I finally understand what you
                have in mind: you are considering using an access
                control model to build a workflow model. 

                While it may be interesting to define a workflow model,
                this should be considered as a separate and
                  different work item.

            

          

          


          

          
The actual workflow is out of scope. 

        

      

    

    
I am glad you agree with this. But this means that your example
      was not appropriate to illustrate your point.

It illustrates a use case where the RO and User are =
not the same party, and why the GS needs to query the RO, which was your qu=
estion if I understood it correctly.
=C2=A0

      

      As soon as there is a RO consent obtained at the GS, the major
      problem is that the GS is able to act as Big Brother.

      If a RO consent is performed at the RS, then the GS will not know
      who the RS is: it is then unable to act as Big Brother, 

      even if it would enjoy to play that role.
=

In an enterprise use case, the GS's knowledge of who is =
accessing which RS is a feature.

In your use cases=
, it seems that the RO is the User. The GS knows the User is wanting to let=
 a Client access something. If the access token is generic, and could be pr=
esented to any RS that provides a standardized function, then the GS does n=
ot know which RS is being accessed by a Client for the User. This seems to =
meet your privacy objectives. If not, what is wrong?

=C2=A0

    

      

        

          
if the admin grants access, then the access granted to
            the client changes. 

          

          

            

              
 

              
The model you propose may be suited for an enterprise
                environment but is not scalable over the Internet.

            

          

          
It is one of the use cases we are working to address. 

          

          

            

              
 What is needed is an access control model usable over
                the Internet with millions of RSs and thousands of
                ASs/GSs.=C2=A0 

              

            

          

          
I agree the model should also scale to internet scale. 

          

        

      

    

    
Fine. Another point on which we are in agreement. 

    

    
The model can scale to the Internet based on the following
      assumptions:

    

      
The flow starts with the steps (1) to (4) as illustrated by
        Francis, i.e. the flow starts with a contact with a RS.

    

    
+----+ =C2=A0+----=
--+
          =C2=A0+---+ =C2=A0+---+ =C2=A0+---+

          |User| =C2=A0|Client| =C2=A0|RS | =C2=A0|GS | =C2=A0|RO |

          +----+ =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 |(2) Service Intent =C2=A0 |=


          =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =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) AuthZ Challenge =C2=A0|=


          =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =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) AuthZ Request =C2=A0 =
=C2=A0|

          =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |------------->| =C2=A0 =
=C2=A0 =C2=A0|

    
The GS/AS does not need to have any prior relationship with ROs
      and/or RSs.

    
Furthermore, it is possible to prevent the GS to act as Big
      Brother when the identity of the RS is not disclosed to the GS.

What happens after (4) above?=C2=
=A0
=C2=A0

    

    

      

        

          

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                

                                  
Which information is supposed to
                                    be presented to the RO ?

                                    Which information is supposed to be
                                    returned by the RO ?

                                

                              

                              


                              

                              
Just like how the user authenticates
                                to an AS, how the AS and RO communicate
                                is out of scope.

                              

                            

                          

                        

                        
At the moment, the usefulness of a dialogue
                          between a GS and a RO has not been explained,
                          nor demonstrated.

                          The question is about the functionality of
                          that dialogue in terms of input and output
                          information (and not about 

                          the design of a protocol or of a user
                          interface). Anyway, AFAIU a dialogue between a
                          GS and a RO is optional.

                        

                      

                    

                    


                    

                    
See enterprise example above.

                  

                

              

              
It is not an access control example, but a workflow
                example.

              
Access=C2=A0 control has been defined =
a
                long time ago and the last edition of the model has been
                confirmed in year 1996: ISO/IEC=C2=A010181-3: 1996.

                "Information
                  technology=C2=A0=E2=80=94 Open Systems Interconnection=C2=
=A0=E2=80=94 Security
                  frameworks for open systems: Access control
                  framework=C2=A0=E2=80=94 Part=C2=A03".

              
Tw=
o
                  major functions have ben defined: an Access Control Enforcement<=
/span>
                    Function (AEF) and an =
Access Control Decision
                  Function(ADF).

              

                
Access Control Enforcement
                    Function (AEF):

                    A specialized function that is part of the access
                    path between an initiator and a target on each
                    access request and enforces the decision made by the
                    ADF.

                Access Control Decision=

                  Function (ADF) :

                A specialized function
                  that makes access control decisions by applying access
                  control policy rules to an access request, ADI (of
                  initiators, targets, access requests, 

                or that retained from
                  prior decisions), and the context in which the access
                  request is made.

              
The role of the RO is to define the "access control policy
                  rules" at the RS according to the context in wh=
ich the
                    access request is made.

            

          

          
I'm pretty familiar with access control systems. :)=C2=
=A0

          


          

          
I would say that the access control is happening at the
            RS. The client presents a token when accessing an API. 

            The RS uses the token, and any policy required, to make an
            access decision.

        

      

    

    
Fine. It looks like we are in agreement. Unfortunately, this is
      not the case just below.

    

    

      

        

          
Here is flow:

          


          

          
1) The Client requests access to an RS from the GS. 

          

        

      

    

    
No. We are no more in agreement. This is different from the flow
      drawn by Francis.

My bad. T=
ypo. I meant RO.
=C2=A0

    

      

        

          
2) The GS queries the RS if access should be granted. 

          

        

      

    

    
=C2=A0No. The GS should not be forced to have a flow with the RS.

Same mistake as above, I meant =
RO.=C2=A0

    

    

      

        

          
3) If access is granted, the GS creates an access token
            representing the granted access, and returns it to the
            Client. 

          

        

      

    

    
This model is by no way conformant to ISO/IEC=C2=A010181-3: 1996 
I'm unclear on why, or why it is even relevant.
=C2=
=A0

        

    

      

        

          
4) The Client presents the access token to the RS to show
            it has been granted access. 

          

        

      

    

    
No. The client presents a token when accessing an API. The RS
      uses the token, and any policy required, to make an access
      decision.

      The token never contains an information like "Please grant an
      access to the holder of this token".
=
Let me provide more clarity in the sentence:

The C=
lient presents the access token to the RS, to show the RS that the Client h=
as been granted access to a resource at the RS by the GS.
=C2=A0<=
/div>

    

      

        

          


          

          
A couple advantages of this model:

          
- that the RS does not need to know much, if anything
            about the Client.=C2=A0

          
- the access token MAY be self contained so that the
            Client does not need to query the GS on each access. 

          

        

      

    

    
There are so many disadvantages that I will not list them.
=

Darn: I clearly was not firing on all cylinders when I ty=
ped this out. Let me correct:

- the access token M=
AY be self contained so that the
            RS does not need to query the GS on each access to the RS by th=
e Client.
=C2=A0

    

      

        

          
I would not say that GNAP is an access control protocol,
            as how the RS uses the token to determine access is out of
            scope.

        

      

    

    
This is where we have a major
          discrepancy: how the RS uses the token to
      determine access is *within* the scope.

    
The RS announces in advance to the client what it needs so that
      the client can perform a a given operation and if the client
      supplies the requested attributes 

      obtained from some GS/AS(s) trusted by the RS, then access to that
      RS is granted by the RS. If the RS cannot perform the requested
      operation on its own, 

      then the client should be informed about some requested attributes
      that need to be obtained from some GS/AS(s) trusted by the next
      RS(s) in a chain

      for subsequent operations. The User consent should also be
      obtained before performing the chaining operation.

    

    
Chaining operations between RSs over the Internet is within the
      scope (... and may be achieved).

    

      

        

          

            

              

                

                  

                    
=C2=A0

                    

                      

                        

                          

                            

                              
For many use cases, the User is the
                                RO, and the interaction is through a
                                user interface, not a machine protocol.
                                

                              

                            

                          

                        

                        
Wait a second. You wrote "the User is the
                          RO". The User is attempting to make an acces=
s
                          to a RS by using a Client. 

                          That User is not the RO of the RS.=C2=A0=
=C2=A0 

                        

                      

                    

                    
The user being the RO is the initial use case
                      for OAuth. 

                  

                

              

              
OAuth 2.0 is no more mandating such a case.

              

            

          

        

      

    

    

      

        


          
I don't know what you mean by that.

        

      

    

    
Copy and paste from draft-ietf-oauth-security-topics:

    

    

      
OAuth initially assumed a static relationship between client,
        authorization server and resource servers.=C2=A0 (...)=C2=A0 

        With the increasing adoption of OAuth, this simple model
        dissolved and, in several scenarios, was replaced 

        by a dynamic establishment of the relationship between clients
        on one side and the authorization and 

        resource servers of a particular deployment on the other side.

        

        This way, the same client could be used to access services of
        different providers (in case of standard APIs, 

        such as e-mail or OpenID Connect) or serve as a frontend to a
        particular tenant in a multi-tenancy environment. 

This sentence does not mention t=
he RO or the Client. I'm confused what we are talking about=C2=A0
=


      

    

    

      

        

          
=C2=A0

          

            

              

                

                  

                    
A client application would like access to the
                      user's photos at a photo sharing site. The
                      resource is the user's photos. The user is the
                      owner of that resource.

                  

                

              

              
If the user has already pre established the access
                control policy rules so that it can access to his own
                photos 

                then he does not need to grant in real time any
                additional authorization.

            

          

          
I don't understand what you are trying to say. The photo
            sharing example was a driving use case for the creation of
            OAuth.

        

      

    

    
We would need to revisit the original scenario and consider if it
      can be addressed in a different way than the original way.
<=
/blockquote>
The use case is the same. Is there a different solution yo=
u are proposing?
=C2=A0


--00000000000072fba805aaf81758--


From nobody Tue Jul 21 12:25: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 0F17B3A081F for ; Tue, 21 Jul 2020 12:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level: 
X-Spam-Status: No, score=-1.907 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 qxvpeRPfQxMr for ; Tue, 21 Jul 2020 12:25: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 739E23A0819 for ; Tue, 21 Jul 2020 12:25:23 -0700 (PDT)
Received: from [192.168.1.3] (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 06LJPIT9026799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jul 2020 15:25:18 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_D9478DAE-4353-4A27-B34C-0E036E3371F8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 21 Jul 2020 15:25:17 -0400
In-Reply-To: 
Cc: Tom Jones , Dick Hardt , txauth@ietf.org
To: Francis Pouatcha 
References:     
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] acquiring claims (was Polymorphism (Was: JSON Schema?))
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, 21 Jul 2020 19:25:28 -0000

--Apple-Mail=_D9478DAE-4353-4A27-B34C-0E036E3371F8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I completely agree that there=E2=80=99s been a lot of circular =
discussion due to mismatches in use of terminology here. I struggled =
with that on the pending update to the XYZ spec as well, specifically in =
separating the =E2=80=9Cuser=E2=80=99 from the =E2=80=9Cresource =
owner=E2=80=9D. The =E2=80=9Cuser=E2=80=9D is the person/entity =
currently operating the client software. The =E2=80=9CResource owner=E2=80=
=9D is the person/entity who can grant access. In OAuth 2 they=E2=80=99re =
the same thing, and in GNAP it=E2=80=99s important that they easily CAN =
be the same. But it=E2=80=99s also important to several members of the =
community, myself included, that they can be separated. There=E2=80=99s =
a lot that we can learn from how UMA handles this split, as well as =
CIBA=E2=80=99s call-center authentication use case. I=E2=80=99ve also =
helped deploy an OAuth device flow system where the approval happens at =
a controlled kiosk where the RO is a certified human agent separate from =
the user. Or at least, that party exists, it=E2=80=99s arguable whether =
they=E2=80=99re performing the =E2=80=9CRO=E2=80=9D role since it=E2=80=99=
s about identifying the user who=E2=80=99s got the client application on =
their device. It gets complex fast if we don=E2=80=99t have good terms =
that we can all agree to! And it=E2=80=99s made worse by the fact that =
many of these terms mean other things in other spaces.

 =E2=80=94 Justin

> On Jul 21, 2020, at 2:18 PM, Francis Pouatcha  wrote:
>=20
> Before we dive into discussion on claims, we really do need some sort =
of agreement on words like:
>=20
> - User : I am ok if we find a replacement for this word in the current =
draft.
> - RO
> - Agents (user Agent, RO Agent, ...)
>=20
> Privacy concerns can be discussed more effectively once we have =
settled on those terms.
>=20
> Best Regards.
> /Francis
>=20
> On Mon, Jul 20, 2020 at 6:14 PM Tom Jones =
> =
wrote:
> if the user must authorize access to the resource, then what better =
place for it than their phone. I don't much worry about inconveniencing =
some gigantic corporation.
> I should be clear tho, user agents do not need to be on user phones, i =
was addressing my particular need.
> If the user has delegated authority to some cloud based service, then =
that user agent could could also host an as.
> It is interesting to speculate on whether an IdP (openId provider =
e.g.) could ever be a trusted user agent. Given what I understand of the =
market today, I guess that is not possible. Markets do, however, change.
> Some on the list speculate that the client (sink of user resources) =
could be a user agent.  That is, at least, problematic, but conceivable. =
I, personally, would not conflate a client with a user agent. After all, =
the user agent has access to (at least some) user accessible resources.
> maybe you should just rename the as to be a user agent. Or at least =
state that the as is an endpoint of a user agent.
>=20
> BTW, for me a user is an identifier claiming to represent a human at a =
device. Whether they are the RO or a guardian is not of importance here. =
I know others have other definitions, sorry about that.
> Peace ..tom
>=20
>=20
> On Mon, Jul 20, 2020 at 12:30 PM Dick Hardt > wrote:
> Curious: How are you envisioning the client communicates to the AS if =
it is on the User's phone?
> =E1=90=A7
>=20
> On Sun, Jul 19, 2020 at 9:13 PM Tom Jones =
> =
wrote:
> Well, that might work for you. It won=E2=80=99t work for me. I put the =
as on the user=E2=80=99s phone. The source and sink of the data can =
switch roles on a millisecond basis. I will track your progress and =
adopt what I can.
>=20
> ..Tom's phone
>=20
>> On Jul 19, 2020, at 1:45 PM, Dick Hardt > wrote:
>>=20
>> =EF=BB=BF
>> Hi Tom
>>=20
>> The proposal is that Client asks for a claim from the AS, the user =
consents at the AS, and the AS directly releases the claim directly to =
the Client. No access token. No resource server.=20
>>=20
>> Simpler for Client and Grant Server (AS)
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On Sat, Jul 18, 2020 at 7:34 PM Tom Jones =
> =
wrote:
>> absolutely, yes, tha az token can authorize any resource held by the =
resource server.
>> The ONLY thing special about PII is the protection granted by the =
various privacy laws.
>>=20
>> As an aside, I don't find much in the current discussion that gives =
me a warm feeling about privacy.
>> The stuff in the torsten tokens is about as anti-privacy an effort as =
exists today.
>> Identity assurance does NOT need to be enabled by sending more and =
yet again more PII.
>> Peace ..tom
>>=20
>>=20
>> On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt > wrote:
>> Hey Tom
>>=20
>> While I think defining claims is out of scope of the WG, I think =
enabling a client to obtain claims about a user is in scope.
>> Would you consider authorization for the release of claims to be part =
of the purpose of this WG?
>>=20
>> I'm concerned about the XYZ shift to subject identifiers from claims, =
and pushing claims to a higher layer, as it may indicate to developers =
that they can ONLY ask for a user identifier.=20
>>=20
>> When I think of a claim, I include any and all identifiers, but I =
also include user attributes such as under-13, over-21, =
student-at-an-accredited-school, resident of =
city/state/province/country.
>>=20
>> GNAP can enable a client to ask for only the claims it needs, =
preserving user privacy, and compliance with many privacy regulations.
>>=20
>> Would you agree?
>>=20
>> /Dick
>>=20
>>=20
>>=20
>>=20
>> On Sat, Jul 18, 2020 at 9:56 AM Tom Jones =
> =
wrote:
>> I agree with Justin's comment " what we should do, as we define GNAP =
as a protocol, is focus on this one, limited slice of the identity space =
and not spiral into others."
>> The title "Authorization" should rule the purposes of this group =
above all else.
>>=20
>> The earlier statement that the client should know who the user is - =
is just plain WRONG. The client should only know the information the =
user is willing to share with the client.
>> It is now the law in California that the client cannot demand =
identity information that is not required for a legitimate business =
purpose.
>> There are some clients that act as fiduciaries for the user =
(financial and healthcare come to mind), but as a general rule the =
"client" is not to be trusted by the user.
>> I understand most of the people on this list are paid by the client's =
of the world, but you are still bound by the laws that apply to those =
clients.
>>=20
>> Peace ..tom
>>=20
>>=20
>> On Mon, Jul 13, 2020 at 12:31 PM Justin Richer > wrote:
>> A quick note, as my choice of language below seems to have been =
confusing. First there is a typo, where the word =E2=80=9Cit=E2=80=9D =
should have been =E2=80=9Cin=E2=80=9D to read:
>>=20
>>> I am saying that GNAP, in its definition within this working group, =
should be limited to identifier claims.
>>=20
>> And second, there seems to be confusion around whether I=E2=80=99m =
trying to argue about the scope =E2=80=9Callowed=E2=80=9D by the charter =
by saying =E2=80=9Cits definition within this working group=E2=80=9D =
here.=20
>>=20
>> To be clear, we as the working group are defining GNAP the protocol. =
It has not yet been defined, and that=E2=80=99s why were all here. The =
charter doesn=E2=80=99t define it. The input specs don=E2=80=99t define =
it. The working group defines it, and my stance as a contributor to this =
WG is that we should focus on a delegation protocol with some basic =
identifier query support and leave the full fledged identity protocol to =
different work.=20
>>=20
>> We=E2=80=99ve already got our hands full here without taking all of =
that on, especially since I do believe we need to build GNAP in such a =
way as to facilitate its extension in several known directions, =
including a full identity protocol. If we do things right here, we can =
see GNAP as the basis of a large number of things out there in the =
world.=20
>>=20
>> So my stance in what we should do, as we define GNAP as a protocol, =
is focus on this one, limited slice of the identity space and not spiral =
into others.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 13, 2020, at 2:51 PM, Justin Richer > wrote:
>>>=20
>>> I am saying that GNAP, it its definition within this working group, =
should be limited to identifier claims. Other claims can come from other =
protocols properly layered on top of GNAP. GNAP shouldn=E2=80=99t stop =
them from being built, but in my opinion we shouldn=E2=80=99t be =
defining those here. See the discussion below on the extensibility =
avenues of this approach.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>> On Jul 13, 2020, at 2:12 PM, Dick Hardt > wrote:
>>>>=20
>>>> I agree that an API to return claims is useful.. I think we have =
agreed on that.=20
>>>>=20
>>>> Using the SubjectIdentifiers schema is another schema that would be =
useful for GNAP to support.=20
>>>>=20
>>>> I disagree that GNAP should be limited to identifier claims.=20
>>>>=20
>>>> =E1=90=A7
>>>>=20
>>>> On Mon, Jul 13, 2020 at 7:16 AM Justin Richer > wrote:
>>>> One thing I think we should learn from OIDC is that returning =
claims from an API, and not just an assertion or direct response, is a =
powerful and useful pattern. We have an opportunity to separate these =
cleanly, where OIDC didn=E2=80=99t have the opportunity in defining the =
=E2=80=9Cclaims=E2=80=9D request parameter.
>>>>=20
>>>> As an alternative to the current XYZ and XAuth syntaxes, over the =
weekend I=E2=80=99ve been playing with something that would look like =
this strawman in the request:
>>>>=20
>>>>=20
>>>> {
>>>>    subject: {
>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =
=E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>>    }
>>>> }
>>>>=20
>>>> This request says that I=E2=80=99d like some subset of these =
identifiers (as plain text in the response) and some subset of signed =
assertions in the given formats. Each one would have an associated space =
in the return. I=E2=80=99m not picturing that the =E2=80=9Cid=E2=80=9D =
field values would affect the contents of the assertions: so I could ask =
for an email address identifier but get back an ID token that had only =
the subject identifier. Maybe that=E2=80=99s not the right model? But =
it=E2=80=99s at least simple and deterministic this way, and it=E2=80=99s =
something to play with.
>>>>=20
>>>> Note: The =E2=80=9Cid=E2=80=9D names are taken from =
https://tools.ietf.org/id/draft-ietf-secevent-subject-identifiers-05.html =
, the =E2=80=9Cassertion=E2=80=9D names are made up as I didn=E2=80=99t =
see a source that collected them. If you wanted specific bundles of =
claims about the user from a UserInfoEndpoint, for example, you=E2=80=99d =
have something like:
>>>>=20
>>>> {
>>>>    subject: {
>>>>       id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
>>>>       assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =
=E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
>>>>    },
>>>>    resources: [{
>>>>        type: =E2=80=9Cuserinfo=E2=80=9D,
>>>>        datatypes: [ =E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D=
, =E2=80=9Cphone=E2=80=9D, =E2=80=9Cemail=E2=80=9D ]
>>>>   }]
>>>> }
>>>>=20
>>>> This is an example for a specific kind of resource, and I don=E2=80=99=
t think that GNAP should define the =E2=80=9Cuserinfo=E2=80=9D schema =
here, or the datatype values therein. That should be work outside of =
GNAP, probably for the OIDF.
>>>>=20
>>>> This approach is extensible in several ways, each of them for a =
specific reason that I think is clear:
>>>>=20
>>>>  - new values in the =E2=80=9Cid=E2=80=9D field to give new =
identifiers
>>>>  - new values in the =E2=80=9Cassertion=E2=80=9D field to give new =
assertion formats
>>>>  - new fields under the =E2=80=9Csubject=E2=80=9D heading=20
>>>>  - new resource types besides =E2=80=9Cuserinfo=E2=80=9D (like =
=E2=80=9Cscim-v1=E2=80=9D or =E2=80=9Cfacebook-profile=E2=80=9D for =
instance)
>>>>  - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D resource =
type
>>>>  - new top-level request parameters
>>>>=20
>>>> As per the other thread, if you wanted to use the OIDC query =
language, you=E2=80=99d package it separately as a top-level request =
parameter since it can include both the ID token response and the access =
token response and we shouldn=E2=80=99t be encouraging mixing these =
things together.
>>>>=20
>>>>  =E2=80=94 Justin
>>>>=20
>>>>> On Jul 10, 2020, at 5:00 PM, Dick Hardt > wrote:
>>>>>=20
>>>>> It looks to me that our different views of what is in scope for =
GNAP are the differences below.
>>>>>=20
>>>>> Per the subject line, I'm looking at how the client acquires =
claims about the user. You don't think that is in scope, and that a =
different layer will solve that.
>>>>>=20
>>>>> I think we should learn from OIDC being on top of OAuth, and GNAP =
should be able return ANY claim, not just identifier claims. There are =
use cases that may be difficult to support if we do not have that =
functionality in scope, such as some of the ones I list below, and it =
seems pretty straightforward to support ANY claim if we are supporting =
identifiers.
>>>>>=20
>>>>> /Dick
>>>>>=20
>>>>>=20
>>>>> On Fri, Jul 10, 2020 at 1:09 PM Justin Richer > wrote:
>>>>>=20
>>>>>=20
>>>>>> On Jul 10, 2020, at 2:15 PM, Dick Hardt > wrote:
>>>>>>=20
>>>>>>=20
>>>>>> inline ...=20
>>>>>>=20
>>>>>> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer > wrote:
>>>>>> Yes, the core idea is to not have to parse an assertion to get =
back the core authentication information, which consists of an =
identifier (iss/sub pair in OIDC, but could be a number of things). =
Sometimes the client is going to want the rest of the identity =
information, but If the user=E2=80=99s logged into the client before, =
the client has likely cached that info and probably won=E2=80=99t need =
it, and sending it would be a violation of privacy principles.. The =
client would want the info pretty much just in these cases:
>>>>>>=20
>>>>>>  1. The client has never seen the user before.=20
>>>>>>  2. The user=E2=80=99s information has been updated since the =
last time the client saw it.
>>>>>>=20
>>>>>> Agreed
>>>>>> =20
>>>>>>=20
>>>>>> Now for case (1), how would the client know if it wants to =
request the user=E2=80=99s profile info or not, since it doesn=E2=80=99t =
know who the user is?
>>>>>>=20
>>>>>> But the client could know who the user is. The client may have =
used a different AS to authenticate the user.
>>>>>=20
>>>>> In these cases, the client is not going to be requesting identity =
information from the AS to log the user in, so it=E2=80=99s not relevant =
to the use case. The client will have an opportunity to push that =
information to the AS.
>>>>>=20
>>>>>> The User may have self identified to the client. The client may =
have a cookie saying who the user was and the user said that was them. =
While the latter cases are really a strong hint, they are likely right =
most of the time and can lead to a user experience basde on that hint
>>>>>=20
>>>>> In these cases, the AS might be able to guess if the client has =
info about the user already, but probably not. And the assumptions fall =
apart if it=E2=80=99s in fact a different user that ends up logging in, =
which is of course possible (the hint you gave doesn=E2=80=99t match the =
identity of the current user after the AS validates them). This =
possibility leads to clients always asking for everything every time and =
the server providing everything every time. That=E2=80=99s a pattern I =
think we should avoid in an ultimate solution =E2=80=94 but ultimately, =
I don=E2=80=99t think that this kind of protocol decision is inside of =
GNAP.
>>>>>=20
>>>>>> =20
>>>>>> And the AS won=E2=80=99t know if client is going to want the =
profile info, since the AS won=E2=80=99t know if the client has the =
user=E2=80=99s info or not. Sure, the AS might have seen that client and =
that user combo previously, but it doesn=E2=80=99t know if the client =
needs an update.
>>>>>>=20
>>>>>> The client can share with the AS the user it knows or thinks it =
is dealing with, which could let the AS respond if the information was =
new. This could be the case for an AS that is providing claims, but not =
authentication, and could happen silently. The user would only interact =
if the user information had changed, and the client wanted the updated =
information.
>>>>>> =20
>>>>>=20
>>>>> See above.
>>>>>=20
>>>>>>=20
>>>>>> And for (2), the client won=E2=80=99t know if the user=E2=80=99s =
info has been updated or not because it doesn=E2=80=99t know who the =
user is yet. If the AS can provide some time of updated stamp to the =
client, the client can pull the new info when it needs it.
>>>>>>=20
>>>>>> See above.
>>>>>=20
>>>>> See above.
>>>>>=20
>>>>>> =20
>>>>>>=20
>>>>>> If you ignore both of these cases and put all the user =
information inline with the main request/response, you end up in a =
situation where the client always requests everything and the server =
always provides everything, since you can=E2=80=99t be sure you=E2=80=99re=
 not in situation (1) or (2) ahead of time.
>>>>>>=20
>>>>>> See above. There are a number of other states the client could be =
in.
>>>>>>=20
>>>>>> For example, the client could be stateless about user =
information, so it knows it is ALWAYS in state 1.
>>>>>=20
>>>>> A stateless client would need to fetch appropriate user =
information every time, then. But that=E2=80=99s an optimization for a =
very specific case.
>>>>>=20
>>>>>> =20
>>>>>>=20
>>>>>> This is really what I mean about the two-stage identity protocol.
>>>>>>=20
>>>>>> I know what it is. Per above, GNAP lets us support a wider set of =
use cases. Why limit ourselves to what OIDC supported?
>>>>>=20
>>>>> We aren=E2=80=99t limiting the protocol, but instead limiting the =
scope of what we define internal to the GNAP protocol. There=E2=80=99s a =
lot of room for innovation on top of it.
>>>>>=20
>>>>>> =20
>>>>>> In the first stage, you push the bare minimum of what you need to =
get the user known to the client.. In the second stage, the client uses =
its access token to call an API to get whatever else it needs to know =
about the user.
>>>>>>=20
>>>>>> =46rom a privacy perspective in non-enterprise use cases, I think =
the user should give consent to any updated personal information to a =
client. In general, the client should not be able to get the latest =
information about a user whenever it wants.
>>>>>=20
>>>>> This is about the rights associated with the access token, then. =
And an access token doesn=E2=80=99t have to keep working if the AS has a =
policy that says it won=E2=80=99t. The AS/RS could easily decide that a =
particular access token will only return data that hasn=E2=80=99t been =
changed. Maybe it stops working after the data changes, or it just =
returns old data, or any number of things. This is for the AS/RS to =
decide and this is pretty standard interpretation of the token, nothing =
special here because we=E2=80=99re dealing with identity.
>>>>>=20
>>>>>  =E2=80=94 Justin
>>>>>=20
>>>>>> =20
>>>>>> /Dick
>>>>>> =E1=90=A7
>>>>>=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 =

> --=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/ =


--Apple-Mail=_D9478DAE-4353-4A27-B34C-0E036E3371F8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
completely agree that there=E2=80=99s been a lot of circular discussion =
due to mismatches in use of terminology here. I struggled with that on =
the pending update to the XYZ spec as well, specifically in separating =
the =E2=80=9Cuser=E2=80=99 from the =E2=80=9Cresource owner=E2=80=9D. =
The =E2=80=9Cuser=E2=80=9D is the person/entity currently operating the =
client software. The =E2=80=9CResource owner=E2=80=9D is the =
person/entity who can grant access. In OAuth 2 they=E2=80=99re the same =
thing, and in GNAP it=E2=80=99s important that they easily CAN be the =
same. But it=E2=80=99s also important to several members of the =
community, myself included, that they can be separated. There=E2=80=99s =
a lot that we can learn from how UMA handles this split, as well as =
CIBA=E2=80=99s call-center authentication use case. I=E2=80=99ve also =
helped deploy an OAuth device flow system where the approval happens at =
a controlled kiosk where the RO is a certified human agent separate from =
the user. Or at least, that party exists, it=E2=80=99s arguable whether =
they=E2=80=99re performing the =E2=80=9CRO=E2=80=9D role since it=E2=80=99=
s about identifying the user who=E2=80=99s got the client application on =
their device. It gets complex fast if we don=E2=80=99t have good terms =
that we can all agree to! And it=E2=80=99s made worse by the fact that =
many of these terms mean other things in other spaces.

 =E2=80=94 Justin

On Jul 21, 2020, at 2:18 PM, Francis Pouatcha <fpo@adorsys.de> =
wrote:

Before we dive into discussion on =
claims, we really do need some sort of agreement on words like:

- User : I am ok if we =
find a replacement for this word in the current draft.
- RO
- Agents (user Agent, RO Agent, =
...)

Privacy =
concerns can be discussed more effectively once we have settled on =
those terms.

Best Regards.
/Francis

On Mon, Jul 20, 2020 at 6:14 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
if the =
user must authorize access to the resource, then what better place for =
it than their phone. I don't much worry about inconveniencing some =
gigantic corporation.
I should be clear tho, user agents do not need to be on user phones, i was =
addressing my particular need.
If the user has =
delegated authority to some cloud based service, then that user agent could could also host an as.
It is interesting to speculate on whether an IdP (openId =
provider e.g.) could ever be a trusted user agent. =
Given what I understand of the market today, I guess that is not =
possible. Markets do, however, change.
Some on the =
list speculate that the client (sink of user resources) could be a user agent.  That is, at least, problematic, but =
conceivable. I, personally, would not conflate a client with a user agent. After all, the user agent has access to (at =
least some) user accessible resources.
maybe you =
should just rename the as to be a user agent. Or at =
least state that the as is an endpoint of a user agent.

BTW, for me a user is an =
identifier claiming to represent a human at a device. Whether they are =
the RO or a guardian is not of importance here. I know others have other =
definitions, sorry about that.
Peace ..tom


On Mon, Jul 20, 2020 at 12:30 PM Dick =
Hardt <dick.hardt@gmail.com> wrote:
Curious: =
How are you envisioning the client communicates to the AS if it is on =
the User's phone?
3D""=E1=90=A7

On Sun, Jul =
19, 2020 at 9:13 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
Well, =
that might work for you. It won=E2=80=99t work for me. I put the as on =
the user=E2=80=99s phone. The source and sink of the data can switch =
roles on a millisecond basis. I will track your progress and adopt what =
I can.

..Tom's =
phone

On Jul 19, 2020, at 1:45 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

=EF=BB=BF
Hi Tom

The proposal is that =
Client asks for a claim from the AS, the user consents at the AS, and =
the AS directly releases the claim directly to the Client. No access =
token. No resource server. 

Simpler for Client and Grant Server =
(AS)






On Sat, Jul 18, 2020 at 7:34 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
absolutely,=
 yes, tha az token can authorize any resource held by the resource =
server.
The ONLY thing special about PII is the =
protection granted by the various privacy laws.

As an aside, I don't find much in the =
current discussion that gives me a warm feeling about privacy.
The stuff in the torsten tokens is about as anti-privacy an =
effort as exists today.
Identity assurance does NOT =
need to be enabled by sending more and yet again more PII.
Peace =
..tom


On Sat, Jul 18, 2020 at 5:58 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Tom

While I think defining claims is out of scope of the WG, =
I think enabling a client to obtain claims about a user is in =
scope.
Would you consider =
authorization for the release of claims to be part of the purpose of =
this WG?

I'm concerned about the XYZ shift to =
subject identifiers from claims, and pushing claims to a higher layer, =
as it may indicate to developers that they can ONLY ask for a user =
identifier. 

When I think of a claim, I include any and all identifiers, =
but I also include user attributes such as under-13, over-21, =
student-at-an-accredited-school, resident of =
city/state/province/country.

GNAP can enable a client to ask for =
only the claims it needs, preserving user privacy, and compliance with =
many privacy regulations.

Would you agree?

/Dick




On Sat, Jul =
18, 2020 at 9:56 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
I agree =
with Justin's comment " what we should do, as we define GNAP as a =
protocol, is focus on this one, limited slice of the identity space and =
not spiral into others."
The title "Authorization" should =
rule the purposes of this group above all else.

The earlier =
statement that the client should know who the user is - is just =
plain WRONG. The client should only know the information the user is =
willing to share with the client.
It is now the law =
in California that the client cannot demand identity information =
that is not required for a legitimate business purpose.
There are some clients that act as fiduciaries for the user =
(financial and healthcare come to mind), but as a general rule the =
"client" is not to be trusted by the user.
I =
understand most of the people on this list are paid by the client's =
of the world, but you are still bound by the laws that apply to those =
clients.

Peace ..tom


On Mon, Jul =
13, 2020 at 12:31 PM Justin Richer <jricher@mit.edu> wrote:
A quick note, as my =
choice of language below seems to have been confusing. First there is a =
typo, where the word =E2=80=9Cit=E2=80=9D should have been =E2=80=9Cin=E2=80=
=9D to read:

I am =
saying that GNAP, in its definition within this =
working group, should be limited to identifier =
claims.

And second, there seems to be confusion around whether I=E2=80=99=
m trying to argue about the scope =E2=80=9Callowed=E2=80=9D by the =
charter by saying =E2=80=9Cits definition within this working group=E2=80=9D=
 here. 

To =
be clear, we as the working group are defining GNAP =
the protocol. It has not yet been defined, and that=E2=80=99s why were =
all here. The charter doesn=E2=80=99t define it. The input specs don=E2=80=
=99t define it. The working group defines it, and my stance as a =
contributor to this WG is that we should focus on a delegation protocol =
with some basic identifier query support and leave the full fledged =
identity protocol to different work. 

We=E2=80=99ve already got our hands =
full here without taking all of that on, especially since I do believe =
we need to build GNAP in such a way as to facilitate its extension in =
several known directions, including a full identity protocol. If we do =
things right here, we can see GNAP as the basis of a large number of =
things out there in the world. 

So my stance in what we should do, as =
we define GNAP as a protocol, is focus on this one, limited slice of the =
identity space and not spiral into others.

 =E2=80=94 Justin

On Jul 13, 2020, at 2:51 PM, Justin Richer <jricher@mit.edu> wrote:



I am saying that GNAP, it its definition within this =
working group, should be limited to identifier claims. Other claims can =
come from other protocols properly layered on top of GNAP. GNAP =
shouldn=E2=80=99t stop them from being built, but in my opinion we =
shouldn=E2=80=99t be defining those here. See the discussion below on =
the extensibility avenues of this approach.

 =E2=80=94 Justin

On Jul 13, 2020, at 2:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree that an API to return =
claims is useful.. I think we have agreed on that. 

Using the =
SubjectIdentifiers schema is another schema that would be useful for =
GNAP to support. 

I disagree that GNAP should be limited to identifier =
claims. 

3D""=E1=90=A7

On Mon, Jul =
13, 2020 at 7:16 AM Justin Richer <jricher@mit.edu> wrote:
One thing I think we =
should learn from OIDC is that returning claims from an API, and not =
just an assertion or direct response, is a powerful and useful pattern. =
We have an opportunity to separate these cleanly, where OIDC didn=E2=80=99=
t have the opportunity in defining the =E2=80=9Cclaims=E2=80=9D request =
parameter.

As an =
alternative to the current XYZ and XAuth syntaxes, over the weekend =
I=E2=80=99ve been playing with something that would look like this =
strawman in the request:


{
   subject: {
    =
  id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
      =
assertion: [ =E2=80=9Codic_id_token=E2=80=9D, =
=E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" ]
   }
}

This request says that =
I=E2=80=99d like some subset of these identifiers (as plain text in the =
response) and some subset of signed assertions in the given formats. =
Each one would have an associated space in the return. I=E2=80=99m not =
picturing that the =E2=80=9Cid=E2=80=9D field values would affect the =
contents of the assertions: so I could ask for an email address =
identifier but get back an ID token that had only the subject =
identifier. Maybe that=E2=80=99s not the right model? But it=E2=80=99s =
at least simple and deterministic this way, and it=E2=80=99s something =
to play with.

Note: The =E2=80=9Cid=E2=80=9D names are taken from https://tools.ietf.org/id/draft-ietf-secevent-subject-identifie=
rs-05.html, the =E2=80=9Cassertion=E2=80=9D names are made up as I =
didn=E2=80=99t see a source that collected them. If you wanted specific =
bundles of claims about the user from a UserInfoEndpoint, for example, =
you=E2=80=99d have something like:

{
  =
 subject: {
  =
    id: [ =E2=80=9Caccount=E2=80=9D, =E2=80=9Cemail=E2=80=9D, =
=E2=80=9Ciss-sub=E2=80=9D],
      assertion: [ =E2=80=9Codic_id_token=E2=80=9D=
, =E2=80=9Cverifiable_credential=E2=80=9D, =E2=80=9Csaml" =
]
  =
 },
  =
 resources: [{
  =
     type: =E2=80=9Cuserinfo=E2=80=9D,
       datatypes: [ =
=E2=80=9Copenid=E2=80=9D, =E2=80=9Cprofile=E2=80=9D, =E2=80=9Cphone=E2=80=9D=
, =E2=80=9Cemail=E2=80=9D ]
  }]
}

This is an example for a specific kind =
of resource, and I don=E2=80=99t think that GNAP should define the =
=E2=80=9Cuserinfo=E2=80=9D schema here, or the datatype values therein. =
That should be work outside of GNAP, probably for the OIDF.

This approach is =
extensible in several ways, each of them for a specific reason that I =
think is clear:

 - new values in the =E2=80=9Cid=E2=80=9D field to give =
new identifiers
 - new values in the =
=E2=80=9Cassertion=E2=80=9D field to give new assertion =
formats
 - new fields under the =E2=80=9Csubject=
=E2=80=9D heading 
 - new resource types =
besides =E2=80=9Cuserinfo=E2=80=9D (like =E2=80=9Cscim-v1=E2=80=9D or =
=E2=80=9Cfacebook-profile=E2=80=9D for instance)
 - new datatypes within the =E2=80=9Cuserinfo=E2=80=9D =
resource type
 - new top-level request =
parameters

As =
per the other thread, if you wanted to use the OIDC query language, =
you=E2=80=99d package it separately as a top-level request parameter =
since it can include both the ID token response and the access token =
response and we shouldn=E2=80=99t be encouraging mixing these things =
together.

 =E2=80=94 Justin

On Jul =
10, 2020, at 5:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It looks to me that our different =
views of what is in scope for GNAP are the differences below.

Per the subject line, =
I'm looking at how the client acquires claims about the user. You don't =
think that is in scope, and that a different layer will solve =
that.

I think =
we should learn from OIDC being on top of OAuth, and GNAP should be able =
return ANY claim, not just identifier claims. There are use cases that =
may be difficult to support if we do not have that functionality in =
scope, such as some of the ones I list below, and it seems pretty =
straightforward to support ANY claim if we are supporting =
identifiers.

/Dick


On Fri, Jul 10, 2020 at 1:09 PM Justin Richer =
<jricher@mit.edu> wrote:


On Jul 10, 2020, at 2:15 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:


inline ... 

On Thu, Jul =
9, 2020 at 5:44 PM Justin Richer <jricher@mit.edu> wrote:
Yes, the core idea is =
to not have to parse an assertion to get back the core authentication =
information, which consists of an identifier (iss/sub pair in OIDC, but =
could be a number of things). Sometimes the client is going to want the =
rest of the identity information, but If the user=E2=80=99s logged =
into the client before, the client has likely cached that info and =
probably won=E2=80=99t need it, and sending it would be a violation of =
privacy principles.. The client would want the info pretty much just in =
these cases:

 1. =
The client has never seen the user before. 
 2. The user=E2=80=99s information has been updated =
since the last time the client saw it.

Agreed
 

Now for case (1), how would the client =
know if it wants to request the user=E2=80=99s profile info or not, =
since it doesn=E2=80=99t know who the user is? =


But the client could know who the user is. The client may =
have used a different AS to authenticate the user. =


In these cases, the client is not going =
to be requesting identity information from the AS to log the user in, so =
it=E2=80=99s not relevant to the use case. The client will have an =
opportunity to push that information to the AS.

The User may have self identified to the client. The client =
may have a cookie saying who the user was and the user said that was =
them. While the latter cases are really a strong hint, they are likely =
right most of the time and can lead to a user experience basde on that =
hint

In these cases, the AS might be able to =
guess if the client has info about the user already, but probably not. =
And the assumptions fall apart if it=E2=80=99s in fact a different user =
that ends up logging in, which is of course possible (the hint you gave =
doesn=E2=80=99t match the identity of the current user after the AS =
validates them). This possibility leads to clients always asking for =
everything every time and the server providing everything every time. =
That=E2=80=99s a pattern I think we should avoid in an ultimate solution =
=E2=80=94 but ultimately, I don=E2=80=99t think that this kind of =
protocol decision is inside of GNAP.

 
And =
the AS won=E2=80=99t know if client is going to want the profile info, =
since the AS won=E2=80=99t know if the client has the user=E2=80=99s =
info or not. Sure, the AS might have seen that client and that user =
combo previously, but it doesn=E2=80=99t know if the client needs an =
update.

The client can share with the AS the user it knows or thinks =
it is dealing with, which could let the AS respond if the information =
was new. This could be the case for an AS that is providing claims, but =
not authentication, and could happen silently. The user would only =
interact if the user information had changed, and the client wanted the =
updated information.
 

See above.


And for (2), the client won=E2=80=99t =
know if the user=E2=80=99s info has been updated or not because it =
doesn=E2=80=99t know who the user is yet. If the AS can provide some =
time of updated stamp to the client, the client can pull the new info =
when it needs it.

See =
above.

See above.

 

If you ignore both of these cases and =
put all the user information inline with the main request/response, you =
end up in a situation where the client always requests everything and =
the server always provides everything, since you can=E2=80=99t be sure =
you=E2=80=99re not in situation (1) or (2) ahead of =
time.

See above. There are a number of other states the client =
could be in.

For=
 example, the client could be stateless about user information, so it =
knows it is ALWAYS in state =
1.

A stateless client would need to fetch =
appropriate user information every time, then. But that=E2=80=99s an =
optimization for a very specific case.

 

This is =
really what I mean about the two-stage identity protocol. =


I know what it is. Per above, GNAP lets us support a wider =
set of use cases. Why limit ourselves to what OIDC =
supported?

We aren=E2=80=99t limiting the =
protocol, but instead limiting the scope of what we define internal to =
the GNAP protocol. There=E2=80=99s a lot of room for innovation on top =
of it.

 
In the first stage, you push the bare minimum of what you =
need to get the user known to the client.. In the second stage, the =
client uses its access token to call an API to get whatever else it =
needs to know about the user. 
=46rom a privacy perspective in =
non-enterprise use cases, I think the user should give consent to any =
updated personal information to a client. In general, the client =
should not be able to get the latest information about a user whenever =
it wants.

This is about the rights associated =
with the access token, then. And an access token doesn=E2=80=99t have to =
keep working if the AS has a policy that says it won=E2=80=99t. The =
AS/RS could easily decide that a particular access token will only =
return data that hasn=E2=80=99t been changed. Maybe it stops working =
after the data changes, or it just returns old data, or any number of =
things. This is for the AS/RS to decide and this is pretty standard =
interpretation of the token, nothing special here because we=E2=80=99re =
dealing with identity.

 =E2=80=94 Justin

 
/Dick
3D""=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
=












-- 

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=_D9478DAE-4353-4A27-B34C-0E036E3371F8--


From nobody Tue Jul 21 17: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 5A0E63A08EC for ; Tue, 21 Jul 2020 17:33:43 -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 UqL1NgccPPrt for ; Tue, 21 Jul 2020 17:33:40 -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 7CA023A08E9 for ; Tue, 21 Jul 2020 17:33:40 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id 88so231491wrh.3 for ; Tue, 21 Jul 2020 17:33: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=XB8H1HruhbEYCU2oomBUQQ8TUICeGi23Of+ZESJNi+Q=; b=bKLBjtZWlIBpEhAZ2Iph4OdYciQRSDvcgTQU65rt7NgRDuDXXcyYAqFIoi3+07vfID GN5ukz1VB3aigkA6QWJuxMqiHIiKDvVX9o2ASZmWLC1TYgejZm5Lkj2xWRObmtAzSwrW lBnPsfDZ1RS7uQ3fzYsOpkzi0E5LYzDrx3mqQ=
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=XB8H1HruhbEYCU2oomBUQQ8TUICeGi23Of+ZESJNi+Q=; b=XnvAmHn1BQCO/6a/Lo4lYokW65fYZzBeuESdvG+UTgdFt2lHLvV1O0oDXDEwuMVZf3 cxx1dDGF5bpi9rb12pMgmKrJEK/tUtIFAEixyv2p144NX9tZxXPmlPtZMJJEoHW9+WZS w9KVs9mMTgqixxtP82edlp+RU2BHK33o7WPkqq5nRfnIlksZNvjFCp0WkFTOnhcpk/LO ff8l+VHuoWbCcnBQbrlXtRk90vCdtjcJhwuuhwsqnVPzFw3QIlRfPSbldFzLTvbnGObI Jct11dTZBcJpczjYm16ZvOUj6NGtcZ00Z8OrhJIwYc4LN4XluwBz067mTing7ry1c2Qy K90w==
X-Gm-Message-State: AOAM531qHKTe0WZOpsFlfNIISG/qxM6vbzF8GsIg3z3FkgVxI3xu8Nxb ar3m3wQNe4TrF0ntBLDpmiXua9h9MAn17Zi6Kj/hIp1N1ek=
X-Google-Smtp-Source: ABdhPJw7n2Q27dxLzsjsYOjtk+BhcTmDZusZtNBi/VL4EHeQC8CifEct4KZyF01sh1bUkukIZYD5SHv0FpVnOr2VoGQ=
X-Received: by 2002:a05:6000:36c:: with SMTP id f12mr20968713wrf.89.1595378018418;  Tue, 21 Jul 2020 17:33:38 -0700 (PDT)
MIME-Version: 1.0
References:       
In-Reply-To: 
From: Francis Pouatcha 
Date: Tue, 21 Jul 2020 20:33:27 -0400
Message-ID: 
To: txauth@ietf.org
Cc: Dick Hardt , Tom Jones , Justin Richer , Denis 
Content-Type: multipart/alternative; boundary="00000000000012165105aafce40f"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 22 Jul 2020 00:33:43 -0000

--00000000000012165105aafce40f
Content-Type: text/plain; charset="UTF-8"

Hello Dick, Justin, Tom, Denis,

Below is a new version of the dictionary includings comments from
different threads. Change log includes:
- avoided the expression "owns a resource" in favor of the expression
"controls a resource"
- included the clarification "resource access" and "claim release"
- included a clarification User vs. RO
- tried to clarify the word User-Agent
- added the definition of a Claim

Terms
=====

Party - represents a role in the GNAP protocol flow. A party can take the
form of a web service, an application installed on the user device and
acting autonomously or the form of a natural person (resp. of an autonomous
device) using an application to interact with other parties.

Resource - a piece of data or web service
      - controlled by a Resource Owner (RO),
      - held and guarded by a Resource Server (RS) and
      - serviced by the RS to a Client, if the Client provides a valid
Authorization.

Claim - a piece of data
      - controlled by a Resource Owner (RO),
      - held and guarded by the Grant Server (GS) and
      - released by the GS to a Client as part of an Authorization.

Resource Owner (RO) - the party that
      - controls a Resource,
      - relies on the services the GS to manage access to that Resource,
      - relies on the services of a RS to hold the Resource and guard
access to that Resource,
      - controls a Claim,
      - relies on the services the GS to release that Claim to a Client.

Resource Server (RS) - the party that
      - holds a resource and guards access to that resource on behalf of
the RO,
      - services the Resource to the requesting Client, provided the Client
presents a valid Authorization.
      The RS is generally deployed as a web service.

Grant Server (GS) - the party that
      - manages access to a Resource on behalf of the RO,
      - holds Claims and releases them when consented by the RO.
      For each Resource access request, the GS might request the Consent of
the RO and produce a corresponding Authorization that is given to the
requesting Client.

Consent - act of an RO :
      - approving access to a Resource, means approval that a Resource he
controls can be given to the Client by the RS.
      - approving release of a Claim, means approval that a Claim he
controls can be included by the GS in an Authorization to be returned to
the Client.

Grant - material form of an RO Consent. In order not to interact with the
RO on each Resource access request, the GS might store the RO Consent in
the form of a Grant for reuse.

Authorization - externalized form of a Grant as known to the GS and the RS.
      - The GS converts a Grant into an Authorization for use in a Resource
access request.
      - The RS evaluates an Authorization to decide on whether or not to
release the Resource to the Client.

Client - the party that provides the infrastructure used by a User to
access a Resource. The client infrastructure is designed to:
      - Receive the resource access request from the User,
      - Interact with the RS to discover authorization requirements,
      - Interact with the GS to obtain an Authorization to access the
Resource,
      - Interact with the RS to access the Resource on behalf of the User.

User - the party using the infrastructure of the Client to gain access to a
Resource or a Claim.


Clarifications:
==========

User vs. RO :
      - the User is the party using the infrastructure of the Client to
gain access to a Resource or a Claim,
      - the RO is the party controlling access to a Resource or controlling
the release of a Claim.
In many use cases, User and RO will be represented by the same party (see
oAuth2), but GNAP exposes use cases where User and RO are represented by
different parties.

User-Agent :
User and RO are parties that might be represented by a natural person or an
autonomous device. In those cases, User (resp. RO) might need the help of
an application to interact with other parties. Such an application is
generally referred to as the "User-Agent".

Feedbacks are welcome.

Best regards,
/Francis


On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha  wrote:

>
>
> On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt  wrote:
>
>>
>>
>> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha  wrote:
>>
>>>
>>> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt  wrote:
>>>
>>>> FYI: I consider the release of claims to be an "authorization" as well.
>>>>
>>> Great. Then it is included.
>>>
>>
>> I pivoted to using the term Grant rather than authorization so that it
>> included both authorizing access to a resource, and authorizing the release
>> of an identity claim.
>>
>> Perhaps we should not use the word "authorization"?
>>
> Authorization is currently used to refer to the token issued by the GSand
> presented to the RS by the Client. I have no alternative word for now.
>
>>
>> "resource access" and "claim release"
>>
>> A Grant then covers both?
>>
> Yes, Great! The word Grant fits best for both. I suggest adding this
> clarification to that dictionary.
>
>>
>>
>>
>>>
>>>> IE, the user authorizes the GS to release a DOB claim to a Client.
>>>>
>>> I guess you mean the "RO" authorizes the GS to release a DOB!
>>>
>>
>> Yes, thanks for clarifying!
>>
>> /Dick
>>
>>>
>
> --
> 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/

--00000000000012165105aafce40f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Dick, Justin, Tom, Denis,

Below=
=C2=A0is a new version of the dictionary includings comments=C2=A0from diff=
erent=C2=A0threads. Change log includes:
- avoided the expression=
 "owns a resource" in favor of the expression "controls=C2=
=A0a resource"
- included the clarification=C2=A0"resou=
rce access" and "claim release"
- included a clari=
fication User vs. RO
- tried to clarify the word User-Agent
=

- added the definition of a Claim

Terms
=
=3D=3D=3D=3D=3D

Party - represents a role in the GNAP protocol flow.=
 A party can take the form of a web service, an application installed on th=
e user device and acting autonomously or the form of a natural person (resp=
. of an autonomous device) using an application to interact with other part=
ies.

Resource - a piece of data or web service
=C2=A0 =C2=A0 =C2=
=A0 - controlled by a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - held a=
nd guarded by a Resource Server (RS) and
=C2=A0 =C2=A0 =C2=A0 - serviced=
 by the RS to a Client, if the Client provides a valid Authorization.
Claim - a piece of data
=C2=A0 =C2=A0 =C2=A0 - controlled by a Resourc=
e Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - held and guarded by the Grant Serve=
r (GS) and
=C2=A0 =C2=A0 =C2=A0 - released by the GS to a Client as part=
 of an Authorization.

Resource Owner (RO) - the party that
=C2=A0=
 =C2=A0 =C2=A0 - controls a Resource,
=C2=A0 =C2=A0 =C2=A0 - relies on t=
he services the GS to manage access to that Resource,
=C2=A0 =C2=A0 =C2=
=A0 - relies on the services of a RS to hold the Resource and guard access =
to that Resource,
=C2=A0 =C2=A0 =C2=A0 - controls a Claim,
=C2=A0 =C2=
=A0 =C2=A0 - relies on the services the GS to release that Claim to a Clien=
t.

Resource Server (RS) - the party that 
=C2=A0 =C2=A0 =C2=A0 - =
holds a resource and guards access to that resource on behalf of the RO,=C2=A0 =C2=A0 =C2=A0 - services the Resource to the requesting Client, pro=
vided the Client presents a valid Authorization.
=C2=A0 =C2=A0 =C2=A0 Th=
e RS is generally deployed as a web service.

Grant Server (GS) - the=
 party that 
=C2=A0 =C2=A0 =C2=A0 - manages access to a Resource on beha=
lf of the RO,
=C2=A0 =C2=A0 =C2=A0 - holds Claims and releases them when=
 consented by the RO.
=C2=A0 =C2=A0 =C2=A0 For each Resource access requ=
est, the GS might request the Consent of the RO and produce a corresponding=
 Authorization that is given to the requesting Client.

Consent - act=
 of an RO :
=C2=A0 =C2=A0 =C2=A0 - approving access to a Resource, means=
 approval that a Resource he controls can be given to the Client by the RS.=

=C2=A0 =C2=A0 =C2=A0 - approving release of a Claim, means approval tha=
t a Claim he controls can be included by the GS in an Authorization to be r=
eturned to the Client.

Grant - material form of an RO Consent. In or=
der not to interact with the RO on each Resource access request, the GS mig=
ht store the RO Consent in the form of a Grant for reuse.

Authorizat=
ion - externalized form of a Grant as known to the GS and the RS.
=C2=A0=
 =C2=A0 =C2=A0 - The GS converts a Grant into an Authorization for use in a=
 Resource access request.
=C2=A0 =C2=A0 =C2=A0 - The RS evaluates an Aut=
horization to decide on whether or not to release the Resource to the Clien=
t.

Client - the party that provides the infrastructure used by a Use=
r to access a Resource. The client infrastructure is designed to:
=C2=A0=
 =C2=A0 =C2=A0 - Receive the resource access request from the User,
=C2=
=A0 =C2=A0 =C2=A0 - Interact with the RS to discover authorization requirem=
ents,
=C2=A0 =C2=A0 =C2=A0 - Interact with the GS to obtain an Authoriza=
tion to access the Resource,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS=
 to access the Resource on behalf of the User.

User - the party usin=
g the infrastructure of the Client to gain access to a Resource or a Claim.=



Clarifications:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
User vs. RO : 
=C2=A0 =C2=A0 =C2=A0 - the User is the party using the i=
nfrastructure of the Client to gain access to a Resource or a Claim,
=C2=
=A0 =C2=A0 =C2=A0 - the RO is the party controlling access to a Resource or=
 controlling the release of a Claim.
In many use cases, User and RO will=
 be represented by the same party (see oAuth2), but GNAP exposes use cases =
where User and RO are represented by different parties.

User-Agent :=

User and RO are parties that might be represented by a natural person o=
r an autonomous device. In those cases, User (resp. RO) might need the help=
 of an application to interact with other parties. Such an application is g=
enerally referred to as the "User-Agent".

Feedbacks are we=
lcome.

Best regards,
/Francis


On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:

On Tue, =
Jul 21, 2020 at 2:15 PM Dick Hardt <dick.hardt@gmail.com> wrote:


On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha <fpo@adorsys.de> wrote:

On Tue, Jul 21, 20=
20 at 1:59 PM Dick Hardt <dick.hardt@gmail.com> wrote:
FYI: I consider the relea=
se of claims to be an "authorization" as well.=C2=A0
Great. Then it is included.=C2=A0
=


I pivoted to using the term Grant rather than authoriza=
tion so that it included both authorizing access to a resource, and authori=
zing the release of an identity claim.

Perhaps we =
should not use the word "authorization"?=C2=A0
<=
/blockquote>
Authorization is currently used to refer to the token issu=
ed by the GSand presented to the RS by the Client. I have no alternative wo=
rd for now.

"resource acce=
ss" and "claim release"

A Grant the=
n covers both?
Yes, Great! The word Gran=
t fits best for both. I suggest adding this clarification to that dictionar=
y.
=


=C2=A0
=

IE, the user authorizes the GS to release a DOB claim=C2=A0t=
o a Client.
I guess you mean the "RO"=
; authorizes the GS to release a DOB!
Yes, thanks for clarifying!
=C2=A0
/Di=
ck
=







-- 
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/


--00000000000012165105aafce40f--


From nobody Wed Jul 22 01:26: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 B24253A0FDE for ; Wed, 22 Jul 2020 01:26:01 -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 ywMRFR96HUwn for ; Wed, 22 Jul 2020 01:25:59 -0700 (PDT)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0: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 3EE6E3A0FDB for ; Wed, 22 Jul 2020 01:25:59 -0700 (PDT)
Received: by mail-il1-x12e.google.com with SMTP id t18so586645ilh.2 for ; Wed, 22 Jul 2020 01:25: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=NY2zhKSQN6hFcixx+0mKpQrO6ZGjrrmO2Us/7Q6rvVY=; b=pYKLYypDEVY6BNB6XZgMM+7WN5O+i96zqmRGeM+JLdSmXZOP962psCJXuuFAbIEnkD xFqPW1ffNCn6D1DRg7i/9rgG115sP0xPmAIr9xNGjdy0n5Uuj0iYc5wE4AdtXPh0C2zc 7YMQAiPc9eMiJjVvNxjYeDO9Uf5+tYZVKF+PCTtppWyuhdt4NyrsnjLE8x6uYIoOVpgC i67km0AAg+whjtqfwewfSQSDPh7KMjm+TXf2z3bupp9aQzS564gnfjx0qE8U6nzN2T/Y 4Ww2C5D8sjApNP78G5c4eZwbNX6moVv+sz4M+0j5WpNiyLxAEpmFAWxcWm4j6ENioR/6 +aUg==
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=NY2zhKSQN6hFcixx+0mKpQrO6ZGjrrmO2Us/7Q6rvVY=; b=HVzunGpJOLzy+zsRSwOnWYsA7cxOQ4NnP2wIbMEYGJJ06XNnDR6P08jXt8UQuahGf+ g68tsY8kK9BmFqhqLbY4rc5llmB6Ps4CujQEdZ/sAZaCwFYe37HSc8RfCDY2I7cooScd 7MuHg6DOFe5b7bwTc19g/mIyXCrSFeFxrLAd999cHFNtNbdQYP40HYYhLItY+P5pcPht WUbygrBMbJr3BMFpeFrdL0zARF4iWc2oG56iNMwmkPvrSE7WcH0U3/Zb/RG6aNcru+82 EPeIniKscRoQRvlII2NhP/VoJRo2bCAK2vh6fXNqxyo7wK5VhT04svbrts7418AIfJcZ 0EXg==
X-Gm-Message-State: AOAM530WQG3t6OMkC4FFv7QepumNJr5k4hDiE7nNHRRMMfi5VqR2jYKg Cv/B89GK+Bc/o6yP1vIrdnlu3tt/Lw/zY8bze5nkNj+jeAQ=
X-Google-Smtp-Source: ABdhPJzyyHZ99OwcOPB+6BPDgoG/W3vljPVzOCsTjP62L6iyyJd9Pxyfb7Vbo+vcppgAxj5Zn4XToZ79ymhOnh6cZBw=
X-Received: by 2002:a05:6e02:1313:: with SMTP id g19mr29799514ilr.123.1595406358462;  Wed, 22 Jul 2020 01:25:58 -0700 (PDT)
MIME-Version: 1.0
References:        
In-Reply-To: 
From: Fabien Imbault 
Date: Wed, 22 Jul 2020 10:25:46 +0200
Message-ID: 
To: Francis Pouatcha 
Cc: txauth@ietf.org, Tom Jones ,  Denis , Justin Richer , Dick Hardt 
Content-Type: multipart/alternative; boundary="00000000000044c5d105ab037df3"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 22 Jul 2020 08:26:02 -0000

--00000000000044c5d105ab037df3
Content-Type: text/plain; charset="UTF-8"

Hi all,

Thanks for that work.
It would make things easier if we could group the definitions which can be
generic (without any knowledge of the GNAP architecture) from the terms
which are dependent on the protocol flow itself.

For terminology, the way it is done in ISO standards is quite interesting
and we probably could reuse some ideas. The general rule of thumb is to
reuse definitions when that's possible and re-define only when necessary.
See for instance
https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en
You'll find :
- a definition
- potentially some notes (here we can explain how it differs from an
already existing term used in a different context) and some examples
- related reference (in many cases, we don't even need to reinvent
something, as we just need to be consistent with terms already used in the
community)

Generic definitions :
- resource, claim, consent, grant, authorization -> seems to me these are
generic. Why does it matter in the definition that we know which party is
doing it?
- in most cases, those definitions shouldn't be different from other WGs,
or else we should explain why that is.
- party : if we refer to roles, we need to define that too.
- grant : I don't get what you mean by "material form of an RO consent".
What is material?

Specific definitions :
- User, User-Agent, Client, RO, GS : all these are specific to the way the
protocol is specified, so it does make sense to relate to the parties doing
it.
- But even then, we need to check whether that specificity is required. I'm
not sure I agree with your definition of User, though. In 99% of use cases,
a user is just... a user, i.e. a natural person. Why do we need to make
this definition so convoluted? The User-Agent definition seems enough to
convey the idea that interactions can be done through real users or things.

Cheers

Fabien


On Wed, Jul 22, 2020 at 2:33 AM Francis Pouatcha  wrote:

> Hello Dick, Justin, Tom, Denis,
>
> Below is a new version of the dictionary includings comments from
> different threads. Change log includes:
> - avoided the expression "owns a resource" in favor of the expression
> "controls a resource"
> - included the clarification "resource access" and "claim release"
> - included a clarification User vs. RO
> - tried to clarify the word User-Agent
> - added the definition of a Claim
>
> Terms
> =====
>
> Party - represents a role in the GNAP protocol flow. A party can take the
> form of a web service, an application installed on the user device and
> acting autonomously or the form of a natural person (resp.. of an
> autonomous device) using an application to interact with other parties.
>
> Resource - a piece of data or web service
>       - controlled by a Resource Owner (RO),
>       - held and guarded by a Resource Server (RS) and
>       - serviced by the RS to a Client, if the Client provides a valid
> Authorization.
>
> Claim - a piece of data
>       - controlled by a Resource Owner (RO),
>       - held and guarded by the Grant Server (GS) and
>       - released by the GS to a Client as part of an Authorization.
>
> Resource Owner (RO) - the party that
>       - controls a Resource,
>       - relies on the services the GS to manage access to that Resource,
>       - relies on the services of a RS to hold the Resource and guard
> access to that Resource,
>       - controls a Claim,
>       - relies on the services the GS to release that Claim to a Client.
>
> Resource Server (RS) - the party that
>       - holds a resource and guards access to that resource on behalf of
> the RO,
>       - services the Resource to the requesting Client, provided the
> Client presents a valid Authorization.
>       The RS is generally deployed as a web service.
>
> Grant Server (GS) - the party that
>       - manages access to a Resource on behalf of the RO,
>       - holds Claims and releases them when consented by the RO.
>       For each Resource access request, the GS might request the Consent
> of the RO and produce a corresponding Authorization that is given to the
> requesting Client.
>
> Consent - act of an RO :
>       - approving access to a Resource, means approval that a Resource he
> controls can be given to the Client by the RS.
>       - approving release of a Claim, means approval that a Claim he
> controls can be included by the GS in an Authorization to be returned to
> the Client.
>
> Grant - material form of an RO Consent. In order not to interact with the
> RO on each Resource access request, the GS might store the RO Consent in
> the form of a Grant for reuse.
>
> Authorization - externalized form of a Grant as known to the GS and the RS.
>       - The GS converts a Grant into an Authorization for use in a
> Resource access request.
>       - The RS evaluates an Authorization to decide on whether or not to
> release the Resource to the Client.
>
> Client - the party that provides the infrastructure used by a User to
> access a Resource. The client infrastructure is designed to:
>       - Receive the resource access request from the User,
>       - Interact with the RS to discover authorization requirements,
>       - Interact with the GS to obtain an Authorization to access the
> Resource,
>       - Interact with the RS to access the Resource on behalf of the User.
>
> User - the party using the infrastructure of the Client to gain access to
> a Resource or a Claim.
>
>
> Clarifications:
> ==========
>
> User vs. RO :
>       - the User is the party using the infrastructure of the Client to
> gain access to a Resource or a Claim,
>       - the RO is the party controlling access to a Resource or
> controlling the release of a Claim.
> In many use cases, User and RO will be represented by the same party (see
> oAuth2), but GNAP exposes use cases where User and RO are represented by
> different parties.
>
> User-Agent :
> User and RO are parties that might be represented by a natural person or
> an autonomous device. In those cases, User (resp. RO) might need the help
> of an application to interact with other parties. Such an application is
> generally referred to as the "User-Agent".
>
> Feedbacks are welcome.
>
> Best regards,
> /Francis
>
>
> On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha  wrote:
>
>>
>>
>> On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt  wrote:
>>
>>>
>>>
>>> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha 
>>> wrote:
>>>
>>>>
>>>> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt 
>>>> wrote:
>>>>
>>>>> FYI: I consider the release of claims to be an "authorization" as
>>>>> well.
>>>>>
>>>> Great. Then it is included.
>>>>
>>>
>>> I pivoted to using the term Grant rather than authorization so that it
>>> included both authorizing access to a resource, and authorizing the release
>>> of an identity claim.
>>>
>>> Perhaps we should not use the word "authorization"?
>>>
>> Authorization is currently used to refer to the token issued by the GSand
>> presented to the RS by the Client. I have no alternative word for now.
>>
>>>
>>> "resource access" and "claim release"
>>>
>>> A Grant then covers both?
>>>
>> Yes, Great! The word Grant fits best for both. I suggest adding this
>> clarification to that dictionary.
>>
>>>
>>>
>>>
>>>>
>>>>> IE, the user authorizes the GS to release a DOB claim to a Client.
>>>>>
>>>> I guess you mean the "RO" authorizes the GS to release a DOB!
>>>>
>>>
>>> Yes, thanks for clarifying!
>>>
>>> /Dick
>>>
>>>>
>>
>> --
>> 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
>

--00000000000044c5d105ab037df3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi all,=C2=A0

Thanks f=
or that work.
It would make things easier if we could group the d=
efinitions which can be generic (without any knowledge of the GNAP architec=
ture) from the terms which are dependent on the protocol flow itself.=C2=A0=


For terminology, the way it is done in ISO standa=
rds is quite interesting and we probably could reuse some ideas. The genera=
l rule of thumb is to reuse definitions when that's possible and re-def=
ine only when necessary.
You'll find :=C2=
=A0
- a definition
- potentially some notes (here we ca=
n explain how it differs from an already existing term used in a different =
context) and some examples
- related reference (in many cases, we=
 don't even need to reinvent something, as we just need to be consisten=
t with terms already used in the community)

Generi=
c definitions :=C2=A0
- resource, claim, consent, grant, authoriz=
ation -> seems to me these are generic. Why does it matter in the defini=
tion that we know which party is doing it?
- in most cases, those=
 definitions shouldn't be different from other WGs, or else we should e=
xplain why that is.=C2=A0
- party : if we refer to roles, we need=
 to define that too.=C2=A0
- grant : I=C2=A0don't get wha=
t you mean by "material form of an RO consent". What is material?=


Specific definitions :=C2=A0
- User=
, User-Agent, Client, RO, GS : all these are specific to the way the protoc=
ol is specified, so it does make sense to relate to the parties doing it.
- But even then, we need to check whether that specificity is requ=
ired. I'm not sure I agree with your definition of User, though. In 99%=
 of use cases, a user is just... a user, i.e. a natural person. Why do we n=
eed to make this definition so convoluted? The User-Agent definition seems =
enough to convey the idea that interactions can be done through real users =
or things.

Cheers

Fabien<=
/div>


On Wed, Jul 22, 2020 at 2:33 AM Francis Pouatcha <fp=
o=3D40adorsys.de@dmarc.ietf.=
org> wrote:
Hello Dick, Justin, Tom, Denis,

Belo=
w=C2=A0is a new version of the dictionary includings comments=C2=A0from dif=
ferent=C2=A0threads. Change log includes:
- avoided the expressio=
n "owns a resource" in favor of the expression "controls=C2=
=A0a resource"
- included the clarification=C2=A0"resou=
rce access" and "claim release"
- included a clari=
fication User vs. RO
- tried to clarify the word User-Agent
=

- added the definition of a Claim

Terms
=
=3D=3D=3D=3D=3D

Party - represents a role in the GNAP protocol flow.=
 A party can take the form of a web service, an application installed on th=
e user device and acting autonomously or the form of a natural person (resp=
.. of an autonomous device) using an application to interact with other par=
ties.

Resource - a piece of data or web service
=C2=A0 =C2=A0 =C2=
=A0 - controlled by a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - held a=
nd guarded by a Resource Server (RS) and
=C2=A0 =C2=A0 =C2=A0 - serviced=
 by the RS to a Client, if the Client provides a valid Authorization.
Claim - a piece of data
=C2=A0 =C2=A0 =C2=A0 - controlled by a Resourc=
e Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - held and guarded by the Grant Serve=
r (GS) and
=C2=A0 =C2=A0 =C2=A0 - released by the GS to a Client as part=
 of an Authorization.

Resource Owner (RO) - the party that
=C2=A0=
 =C2=A0 =C2=A0 - controls a Resource,
=C2=A0 =C2=A0 =C2=A0 - relies on t=
he services the GS to manage access to that Resource,
=C2=A0 =C2=A0 =C2=
=A0 - relies on the services of a RS to hold the Resource and guard access =
to that Resource,
=C2=A0 =C2=A0 =C2=A0 - controls a Claim,
=C2=A0 =C2=
=A0 =C2=A0 - relies on the services the GS to release that Claim to a Clien=
t.

Resource Server (RS) - the party that 
=C2=A0 =C2=A0 =C2=A0 - =
holds a resource and guards access to that resource on behalf of the RO,=C2=A0 =C2=A0 =C2=A0 - services the Resource to the requesting Client, pro=
vided the Client presents a valid Authorization.
=C2=A0 =C2=A0 =C2=A0 Th=
e RS is generally deployed as a web service.

Grant Server (GS) - the=
 party that 
=C2=A0 =C2=A0 =C2=A0 - manages access to a Resource on beha=
lf of the RO,
=C2=A0 =C2=A0 =C2=A0 - holds Claims and releases them when=
 consented by the RO.
=C2=A0 =C2=A0 =C2=A0 For each Resource access requ=
est, the GS might request the Consent of the RO and produce a corresponding=
 Authorization that is given to the requesting Client.

Consent - act=
 of an RO :
=C2=A0 =C2=A0 =C2=A0 - approving access to a Resource, means=
 approval that a Resource he controls can be given to the Client by the RS.=

=C2=A0 =C2=A0 =C2=A0 - approving release of a Claim, means approval tha=
t a Claim he controls can be included by the GS in an Authorization to be r=
eturned to the Client.

Grant - material form of an RO Consent. In or=
der not to interact with the RO on each Resource access request, the GS mig=
ht store the RO Consent in the form of a Grant for reuse.

Authorizat=
ion - externalized form of a Grant as known to the GS and the RS.
=C2=A0=
 =C2=A0 =C2=A0 - The GS converts a Grant into an Authorization for use in a=
 Resource access request.
=C2=A0 =C2=A0 =C2=A0 - The RS evaluates an Aut=
horization to decide on whether or not to release the Resource to the Clien=
t.

Client - the party that provides the infrastructure used by a Use=
r to access a Resource. The client infrastructure is designed to:
=C2=A0=
 =C2=A0 =C2=A0 - Receive the resource access request from the User,
=C2=
=A0 =C2=A0 =C2=A0 - Interact with the RS to discover authorization requirem=
ents,
=C2=A0 =C2=A0 =C2=A0 - Interact with the GS to obtain an Authoriza=
tion to access the Resource,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS=
 to access the Resource on behalf of the User.

User - the party usin=
g the infrastructure of the Client to gain access to a Resource or a Claim.=



Clarifications:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
User vs. RO : 
=C2=A0 =C2=A0 =C2=A0 - the User is the party using the i=
nfrastructure of the Client to gain access to a Resource or a Claim,
=C2=
=A0 =C2=A0 =C2=A0 - the RO is the party controlling access to a Resource or=
 controlling the release of a Claim.
In many use cases, User and RO will=
 be represented by the same party (see oAuth2), but GNAP exposes use cases =
where User and RO are represented by different parties.

User-Agent :=

User and RO are parties that might be represented by a natural person o=
r an autonomous device. In those cases, User (resp. RO) might need the help=
 of an application to interact with other parties. Such an application is g=
enerally referred to as the "User-Agent".

Feedbacks are we=
lcome.

Best regards,
/Francis


On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:


On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt <dick.hardt@gmail.com> wrote:=



On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha &l=
t;fpo@adorsys.de>=
; wrote:

=
On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt <dick.hardt@gmail.com> wrote:
=

FYI: I c=
onsider the release of claims to be an "authorization" as well.=
=C2=A0
Great. Then it is included.=C2=A0
=


I pivoted to using the term Grant ra=
ther than authorization so that it included both authorizing access to a re=
source, and authorizing the release of an identity claim.

Perhaps we should not use the word "authorization"?=C2=A0=

Authorization is currently used to refe=
r to the token issued by the GSand presented to the RS by the Client. I hav=
e no alternative word for now.

=
"resource access" and "claim release"

A Grant then covers both?
Yes, G=
reat! The word Grant fits best for both. I suggest adding this clarificatio=
n to that dictionary.

=C2=A0

IE, the user authorizes the GS to release=
 a DOB claim=C2=A0to a Client.
I guess you mea=
n the "RO" authorizes the GS to release a DOB!
<=
/blockquote>

Yes, thanks for clarifying!
=C2=
=A0
/Dick
=







-- 
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




--00000000000044c5d105ab037df3--


From nobody Wed Jul 22 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 E290A3A0B01 for ; Wed, 22 Jul 2020 09:34:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.631
X-Spam-Level: 
X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, 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 5AFHXRnyDBeK for ; Wed, 22 Jul 2020 09:34:41 -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 E09133A0B13 for ; Wed, 22 Jul 2020 09:34:39 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d57 with ME id 6Gac230082bcEcA03Gacaf; Wed, 22 Jul 2020 18:34:37 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 22 Jul 2020 18:34:37 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt 
Cc: Francis Pouatcha , txauth@ietf.org
References:             <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr> 
From: Denis 
Message-ID: 
Date: Wed, 22 Jul 2020 18:34:36 +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="------------7164DB06918B102894D15FBF"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 22 Jul 2020 16:34:45 -0000

This is a multi-part message in MIME format.
--------------7164DB06918B102894D15FBF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Dick,

I have identified the reason of the major difference between our two 
approaches.

Access control may be performed using either ACLs (Access Control Lists) 
or Capabilities.

_Note _: a capability identifies a resource and an allowed operation 
that can be performed on that resource.

You are advocating a Capabilities approach while I am advocating an ACL 
approach.

The capabilities approach allows the GS to trace every operation 
performed by the users on any RS known by a GS.
The management of these capabilities is made via the GS or at the GS by 
the various ROs. If the management is made
via the GS, then a trusted communication channel needs to be established 
with every RO. If the management is made
at the GS, then an authentication mechanism needs to be established with 
every RO. In the last case, the GS has the
ability to know all the capabilities of the users whether they are used 
or not. The less that can be said is that this model
is not privacy friendly.

With the ACL approach, a RO directly manages an ACL placed in front of 
each RS. The AccessControl Decision Function
(ADF) at the RS is able to keep track from prior decisions. The GS is 
kept ignorant of the content of these ACLs and only
delivers to its clients attributes that are placed into access tokens. 
Such a model may be privacy friendly.

Other comments are between the lines prefixed with [Denis].

>
> On Tue, Jul 21, 2020 at 11:26 AM Denis  > wrote:
>
>     Hello Dick,
>
>     Thank you for your feedback. Comments are between the lines.
>
>>     comments inserted ...
>>
>>     On Tue, Jul 21, 2020 at 6:03 AM Denis >     > wrote:
>>
>>         Hello Dick,
>>
>>         I duplicate the most important comment at the beginning of
>>         this email:
>>
>>             You are considering using an access control model to
>>             build a**workflow model.
>>             **
>>             While it may be interesting to define a workflow model,
>>             this should be considered
>>             as a separate and different work item.
>>
>>         See the other comments between the lines.
>>
>>>         On Mon, Jul 20, 2020 at 2:05 AM Denis >>         > wrote:
>>>
>>>             Hi Dick,
>>>
>>>>             On Fri, Jul 17, 2020 at 9:21 AM Denis
>>>>             > wrote:
>>>>
>>>>                 Hello Francis and Dick,
>>>>
>>>>                 The good news first: we are making some progress.
>>>>                 We are now close to an agreement with steps (1) up
>>>>                 to (3),
>>>>                 ... except that the place where the user consent is
>>>>                 captured is not mentioned/indicated.
>>>>
>>>
>>>             This major question which is currently left unanswered
>>>             is where, when and how the user consent is captured.
>>>
>>>
>>>         When is covered, per the sequence. How and where are out of
>>>         scope of what I drafted.
>>
>>         It is clear that the "User consent and choice" is not
>>         currently addressed in the draft, but it should.
>>         The support of the "User consent and choice" has strong
>>         implications not only in the sequences of the exchanges
>>         but also by which entity it should be performed.
>>
>>     "consent" is in the latest draft 7 times.
>
>     "Consent" is present 5 times. The User consent is different from
>     the RO consent (when/if it is required).
>
>         The server acquires consent and authorization from the user
>         *and/**or resource owner **if required.*
>
>         User consent is *often required* at the GS. GNAP enables a
>         Client and  GS to negotiate the interaction mode for the GS to
>         obtain consent.
>
>         The GS *may *require explicit consent from the RO or User to
>         provide these to the Client.
>
>     The User consent is not an alternative to the RO consent. So using
>     "and/or" in the first sentence is incorrect.
>
>
> My language is sloppy there. Consent is always from the RO. The User 
> may be the RO.

[Denis] No. Once again: The "/User consent/" is different from what you 
call the "/RO consent/" (when/if it is required).
The "RO consent" is not in fact a consent but the release of a 
capability to a client by one of the many R0s with which
the GS has relationships.

>     Since the second sentence is using the wording "often required"
>     there is no requirement to get the User consent.
>
> User consent may not be required. There may not be a User. The consent 
> may have been gathered previously.

[Denis] In order to follow the privacy principles, a "User consent" 
phase is required. The User is a natural person.
A Client is called either by a User (i.e. a natural person) or by a 
Client application.

>     The second sentence does not consider the possibility to get the
>     User consent in a place different from the GS.
>
> Agreed. But we do agree that the GS gets the consent, either directly 
> from the RO, or from the Client (in your example).

[Denis] No. I disagree. In an ACL based systems, the GS does not need to 
ask or receive any consent.
The client selects the set of attributes that it wants to be inserted 
into an access token.
If the GS has the requested attributes, then it provides them, otherwise 
it returns an error to the Client.

>     IMO, the User consent should be captured by the Client, i.e. not
>     by the GS.
>     The information used to obtain the User consent should be
>     standardized (... and it can be standardized).
>
>>     I think the abstract sequence as proposed by Francis is a great
>>     addition, and would clarify where consent is in the sequence.
>
>     The current sketch does not illustrate the place the User Consent
>     is captured, in particular by the Client.
>
> It is an abstraction. The GS receives the consent. How consent is 
> gathered is a detail that is dependent on the use case.

[Denis] I really wonder whether there is really a "consent" to be 
received by the GS in both cases (i.e. ACLs or Capabilities).

  * For ACLs, the consent needs to be done by the Client.
  * For Capabilities, the current description is not clear since the
    inputs and the outputs for this "consent" phase
    are not currently described in the draft.

>>>             Another important point to consider and to explain is
>>>             related to the assurances that the user can obtain about
>>>             the respect of his choices. This point is currently left
>>>             unanswered in draft-hardt-xauth-protocol-13.
>>>
>>         This point is equally important: such assurance can only be
>>         obtained if the access token returned to the client
>>         is not considered to be opaque to the client. This is a
>>         necessary condition but not the single condition:
>>         the Client must also be in a position to capture/memorize the
>>         "User consent and choice" of the user in order to be able
>>         to verify it afterwards using the content of the access token(s).
>>
>>
>>     We disagree on this being a requirement for all use cases. It may
>>     be in some.
>
>     OK. Then this means that there will be no sentence in the draft
>     such as :
>     "access tokens returned to the client are not considered to be
>     opaque to the client".
>
>
> For OAuth use cases, which GNAP supports, the access token is opaque 
> to the Client. As you have noted, there are use cases where the access 
> token is NOT opaque.

[Denis] Wait a second. There is no requirement to support all OAuth use 
cases.
I believe that there is a requirement to support OAuth 2.0 ASs, while 
the clients may be different
and hence GNAP clients do not need to inherit of the limitations of 
OAuth 2.0 clients.

>>>
>>>>                 If a RO needs to be involved and since a RO is
>>>>                 directly associated with a RS, why can't it be
>>>>                 directly queried
>>>>                 by the appropriate RS after step (2) or later on ?
>>>>
>>>>
>>>>             Good question. Perhaps you can expand on a use case
>>>>             where that would be useful?
>>>
>>>             Before I expand, would you be able to explain first
>>>             under which circumstances a RO needs to be queried by a GS ?
>>>             How can the GS identify which RO to query ?
>>>
>>>         If the User is the RO, then the GS knows who to query.
>>
>>         I still have difficulties to understand what you mean here.
>>         How could a GS know that "the User is the RO" ?  If "the User
>>         is the RO", why does the GS needs to query the User ?
>>
>>
>>     To get consent?
>
>     To get a "RO consent" to himself ???
>
>
> The GS needs consent from the RO. If the RO is the User, then consent 
> from the RO is equivalent to consent from the User.

[Denis] See above.

>
>>>         If the RO is a separate entity, then the GS knows the RO
>>>         from the RS being queried.
>>
>>          ... and this gives the ability for the GS to log/trace all
>>         the RSs accessed by a given User and at which instant of time
>>         the access token has been granted.
>>
>>>         An example is a user would like access to an enterprise
>>>         asset where a workflow is started to gain approval, and an
>>>         administrator or manager provides consent.
>>
>>         Thanks for this example. I finally understand what you have
>>         in mind: you are considering using an access control model to
>>         build a *workflow model*.
>>         While it may be interesting to define a workflow model, this
>>         should be considered as a *separate and different work item*.
>>
>>
>>     The actual workflow is out of scope.
>
>     I am glad you agree with this. But this means that your example
>     was not appropriate to illustrate your point.
>
>
> It illustrates a use case where the RO and User are not the same 
> party, and why the GS needs to query the RO, which was your question 
> if I understood it correctly.

[Denis] Since the inputs and the outputs for this "RO consent" phase are 
not currently described in the draft, the point is still unsolved.

>     As soon as there is a RO consent obtained at the GS, the major
>     problem is that the GS is able to act as Big Brother.
>     If a RO consent is performed at the RS, then the GS will not know
>     who the RS is: it is then unable to act as Big Brother,
>     even if it would enjoy to play that role.
>
> In an enterprise use case, the GS's knowledge of who is accessing 
> which RS is a feature.

Do you mean that it is "normal" in an enterprise that a single point of 
control is able to trace all their actions ?
 From a security point of view, a single point of failure will have 
dramatic consequences.

> In your use cases, it seems that the RO is the User.

I do hope that you have finally understood that, in my use case, the RO 
is **not** the User.

> The GS knows the User is wanting to let a Client access something. If 
> the access token is generic, and could be presented to any RS that 
> provides a standardized function,
> then the GS does not know which RS is being accessed by a Client for 
> the User. This seems to meet your privacy objectives. If not, what is 
> wrong?

For security reasons, an access token needs to be targeted (which does 
not necessarily mean that an identifier of the RS shall be included into 
the access token).

>>     if the admin grants access, then the access granted to the client
>>     changes.
>>
>>         The model you propose may be suited for an enterprise
>>         environment but is not scalable over the Internet.
>>
>>     It is one of the use cases we are working to address.
>>
>>         What is needed is an access control model usable over the
>>         Internet with millions of RSs and thousands of ASs/GSs.
>>
>>     I agree the model should also scale to internet scale.
>
>     Fine. Another point on which we are in agreement.
>
>     The model can scale to the Internet based on the following
>     assumptions:
>
>         The flow starts with the steps (1) to (4) as illustrated by
>         Francis, i.e. the flow starts with a contact with a RS.
>
>     *+----+  +------+  +---+  +---+  +---+
>     |User|  |Client|  |RS |  |GS |  |RO |
>     +----+  +------+  +---+  +-+-+  +-+-+
>       |(1) Service Request     |      |
>       |-------->|       |      |      |
>       |         |(2) Service Intent   |
>       |         |------>|      |      |
>       |         |(3) AuthZ Challenge  |
>       |         |<------|      |      |
>       |         |(4) AuthZ Request    |
>       |         |------------->|      |*
>
>     The GS/AS does not need to have any prior relationship with ROs
>     and/or RSs.
>
>     Furthermore, it is possible to prevent the GS to act as Big
>     Brother when the identity of the RS is not disclosed to the GS.
>
>
> What happens after (4) above?

[Denis] The key point is that we first need to agree on the first four 
exchanges. Do we ?

The fifth exchange is different whether ACLs or Capabilities are being used.

>>>>                 Which information is supposed to be presented to
>>>>                 the RO ?
>>>>                 Which information is supposed to be returned by the
>>>>                 RO ?
>>>>
>>>>
>>>>             Just like how the user authenticates to an AS, how the
>>>>             AS and RO communicate is out of scope.
>>>
>>>             At the moment, the usefulness of a dialogue between a GS
>>>             and a RO has not been explained, nor demonstrated.
>>>             The question is about the functionality of that dialogue
>>>             in terms of input and output information (and not about
>>>             the design of a protocol or of a user interface).
>>>             Anyway, AFAIU a dialogue between a GS and a RO is optional.
>>>
>>>
>>>         See enterprise example above.
>>
>>         It is not an access control example, but a workflow example.
>>
>>         Access  control has been defined a long time ago and the last
>>         edition of the model has been confirmed in year 1996:
>>         ISO/IEC 10181-3: 1996.
>>         "Information technology — Open Systems Interconnection —
>>         Security frameworks for open systems: Access control
>>         framework — Part 3".
>>
>>         Two major functions have ben defined: an AccessControl
>>         Enforcement Function (AEF) and an AccessControl Decision
>>         Function(ADF).
>>
>>             AccessControl Enforcement Function (AEF):
>>             A specialized function that is part of the access path
>>             between an initiator and a target on each access request
>>             and enforces the decision made by the ADF.
>>
>>             AccessControl Decision Function (ADF) :
>>             A specialized function that makes access control
>>             decisions by applying access control policy rules to an
>>             access request, ADI (of initiators, targets, access
>>             requests,
>>             or that retained from prior decisions), and the context
>>             in which the access request is made.
>>
>>         The role of the RO is to define the "access control policy
>>         rules" at the RS according to thecontext in which the access
>>         request is made.
>>
>>     I'm pretty familiar with access control systems. :)
>>
>>     I would say that the access control is happening at the RS. The
>>     client presents a token when accessing an API.
>>     The RS uses the token, and any policy required, to make an access
>>     decision.
>
>     Fine. It looks like we are in agreement. Unfortunately, this is
>     not the case just below.
>
>>     Here is flow:
>>
>>     1) The Client requests access to an RS from the GS.
>
>     No. We are no more in agreement. This is different from the flow
>     drawn by Francis.
>
> My bad. Typo. I meant RO.
>
>>     2) The GS queries the RS if access should be granted.
>
>      No. The GS should not be forced to have a flow with the RS.
>
> Same mistake as above, I meant RO.
>
>>     3) If access is granted, the GS creates an access token
>>     representing the granted access, and returns it to the Client.
>
>     This model is by no way conformant to ISO/IEC 10181-3: 1996
>
> I'm unclear on why, or why it is even relevant.
>
>>     4) The Client presents the access token to the RS to show it has
>>     been granted access.
>
>     No. The client presents a token when accessing an API. The RS uses
>     the token, and any policy required, to make an access decision.
>     The token never contains an information like "Please grant an
>     access to the holder of this token".
>
> Let me provide more clarity in the sentence:
>
> The Client presents the access token to the RS, to show the RS that 
> the Client has been granted access to a resource at the RS by the GS.

[Denis] This time, please consider both the ACLs approach and the 
Capabilities approach.

>>     A couple advantages of this model:
>>     - that the RS does not need to know much, if anything about the
>>     Client.
>>     - the access token MAY be self contained so that the Client does
>>     not need to query the GS on each access.
>
>     There are so many disadvantages that I will not list them.
>
> Darn: I clearly was not firing on all cylinders when I typed this out. 
> Let me correct:
>
>> - the access token MAY be self contained so that the RS does not need 
>> to query the GS on each access to the RS by the Client.

[Denis] A few comments in the case of a capability approach:

    - for each GS, the RS needs to locally manage which operation(s)
    is/are allowed to it.

    - the GS needs to establish a trusted communication channel or an
    authentication mechanism with each RO
        (which is associated with an explicit RS identifier).

    - the GS could play the role of the RO and hence be in a position to
    issue any capability for any RS (without a "RO consent").

        The target of an attack will clearly be the GS.

>>     I would not say that GNAP is an access control protocol, as how
>>     the RS uses the token to determine access is out of scope.
>
>     This is where we have a major discrepancy: how the RS uses the
>     token to determine access is *within* the scope.
>
[Denis] Do you agree or disagree ?
>
>     The RS announces in advance to the client what it needs so that
>     the client can perform a a given operation and if the client
>     supplies the requested attributes
>     obtained from some GS/AS(s) trusted by the RS, then access to that
>     RS is granted by the RS. If the RS cannot perform the requested
>     operation on its own,
>     then the client should be informed about some requested attributes
>     that need to be obtained from some GS/AS(s) trusted by the next
>     RS(s) in a chain
>     for subsequent operations. The User consent should also be
>     obtained before performing the chaining operation.
>
>     Chaining operations between RSs over the Internet is within the
>     scope (... and may be achieved).
>
[Denis] Do you agree or disagree ?

Denis

>>>>             For many use cases, the User is the RO, and the
>>>>             interaction is through a user interface, not a machine
>>>>             protocol.
>>>
>>>             Wait a second. You wrote "the User is the RO". The User
>>>             is attempting to make an access to a RS by using a Client.
>>>             _That_ User is not the RO of the RS.
>>>
>>>         The user being the RO is the initial use case for OAuth.
>>
>>         OAuth 2.0 is no more mandating such a case.
>>
>>
>>     I don't know what you mean by that.
>
>     Copy and paste from draft-ietf-oauth-security-topics:
>
>         OAuth initially assumed a static relationship between client,
>         authorization server and resource servers.  (...)
>         With the increasing adoption of OAuth, this simple model
>         dissolved and, in several scenarios, was replaced
>         by a dynamic establishment of the relationship between clients
>         on one side and the authorization and
>         resource servers of a particular deployment on the other side.
>
>         This way, the same client could be used to access services of
>         different providers (in case of standard APIs,
>         such as e-mail or OpenID Connect) or serve as a frontend to a
>         particular tenant in a multi-tenancy environment.
>
>
> This sentence does not mention the RO or the Client. I'm confused what 
> we are talking about
>
>>>         A client application would like access to the user's photos
>>>         at a photo sharing site. The resource is the user's photos.
>>>         The user is the owner of that resource.
>>
>>         If the user has already pre established the access control
>>         policy rules so that it can access to his own photos
>>         then he does not need to grant in real time any additional
>>         authorization.
>>
>>     I don't understand what you are trying to say. The photo sharing
>>     example was a driving use case for the creation of OAuth.
>
>     We would need to revisit the original scenario and consider if it
>     can be addressed in a different way than the original way.
>
> The use case is the same. Is there a different solution you are proposing?



--------------7164DB06918B102894D15FBF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hello Dick,

    


    

    
I have identified the reason of the
      major difference between our two approaches.

    


    

    
Access control may be performed using
      either ACLs (Access Control Lists) or Capabilities.

    


    

    
Note : a capability identifies
      a resource and an allowed operation that can be performed on that
      resource.

    

    


    

    
You are advocating a Capabilities
      approach while I am advocating an ACL approach.

    
The capabilities approach allows the GS to trace every operation
      performed by the users on any RS known by a GS.

      The management of these capabilities is made via the GS or at the
      GS by the various ROs. If the management is made 

      via the GS, then a trusted communication channel needs to be
      established with every RO. If the management is made 

      at the GS, then an authentication mechanism needs to be
      established with every RO. In the last case, the GS has the 

      ability to know all the capabilities of the users whether they are
      used or not. The less that can be said is that this model 

      is not privacy friendly.

    
With the ACL approach, a RO directly manages an ACL placed in
      front of each RS. The Access Control Decision
        Function 

          (ADF) at the
        RS is able to keep track from prior decisions. The GS is
      kept ignorant of the content of these ACLs and only 

      delivers to its clients attributes that are placed into access
      tokens. Such a model may be privacy friendly.

    
Other comments are between the lines prefixed with [Denis].

    

      
      

        


          

            
On Tue, Jul 21, 2020 at
              11:26 AM Denis <denis.ietf@free.fr> wrote:

            

            

              

                
Hello Dick,

                


                

                
 Thank you for your feedback. Comments are between
                  the lines.

                


                

                

                  

                    
comments inserted ... 

                    

                    

                      
On Tue, Jul 21,
                        2020 at 6:03 AM Denis <denis.ietf@free.fr>
                        wrote:

                      

                      

                        

                          
Hello Dick,

                          


                          

                          
I duplicate the most important comment at
                            the beginning of this email:

                          

                            
You are considering using an access
                              control model to build a workflow
                              model.

                               

                              While it may be interesting to define a
                              workflow model, this should be considered
                              

                              as a separate and different work item.

                          

                          
See the other comments between the lines.

                          

                          


                          

                          

                            
On Mon, Jul 20, 2020 at 2:05
                              AM Denis <denis.ietf@free.fr>
                              wrote:

                              

                                

                                  

                                    
Hi Dick,

                                    


                                    

                                    

                                      
On Fri, Jul 17,
                                        2020 at 9:21 AM Denis <denis.ietf@free.fr>
                                        wrote:

                                        

                                          

                                            

                                              
Hello Francis and
                                                Dick,

                                              


                                              

                                              
The good news first:
                                                we are making some
                                                progress. We are now
                                                close to an agreement
                                                with steps (1) up to
                                                (3), 

                                                ... except that the
                                                place where the user
                                                consent is captured is
                                                not mentioned/indicated.

                                            

                                          

                                        

                                      

                                    

                                    

                                    This major question which is
                                    currently left unanswered is where,
                                    when and how the user consent is
                                    captured.

                                  

                                

                                


                                

                                
When is covered, per the sequence.
                                  How and where are out of scope of what
                                  I drafted. 

                                

                              

                            

                          

                          
It is clear that the "User consent and
                            choice" is not currently addressed in the
                            draft, but it should.

                            The support of the "User consent and choice"
                            has strong implications not only in the
                            sequences of the exchanges 

                            but also by which entity it should be
                            performed.

                        

                      

                      
"consent" is in the latest draft 7 times. 

                      

                    

                  

                

                
"Consent" is present 5 times. The User consent is
                  different from the RO consent (when/if it is
                  required). 

                

                

                  
The server acquires consent and authorization from
                    the user and/or resource owner if
                      required.

                  

                  
User consent is often required at the GS.
                    GNAP enables a Client and  GS to negotiate the
                    interaction mode for the GS to obtain consent.

                  

                  
 The GS may require explicit consent from
                    the RO or User to provide these to the Client.

                  

                

                
The User consent is not an alternative to the RO
                  consent. So using "and/or" in the first sentence is
                  incorrect.

              

            

            


            

            
My language is sloppy there. Consent is always from the
              RO. The User may be the RO.

          

        

      

    

    
[Denis] No. Once again: The "User consent" is different
      from what you call the "RO consent" (when/if it is
      required). 

      The "RO consent" is not in fact a consent but the release of a
      capability to a client by one of the many R0s with which 

      the GS has relationships. 

    

    

      

        

          

            

              

                
Since the second sentence is using the wording "often
                  required" there is no requirement to get the User
                  consent.

                

              

            

            
User consent may not be required. There may not be a
              User. The consent may have been gathered previously.

          

        

      

    

    
[Denis] In order to follow the privacy principles, a "User
      consent" phase is required. The User is a natural person.

      A Client is called either by a User (i.e. a natural person) or by
      a Client application. 

    

    

      

        

          

            

              

                
 

                
The second sentence does not consider the possibility
                  to get the User consent in a place different from the
                  GS.

              

            

            
Agreed. But we do agree that the GS gets the consent,
              either directly from the RO, or from the Client (in your
              example).

          

        

      

    

    
[Denis] No. I disagree. In an ACL based systems, the GS does not
      need to ask or receive any consent.

      The client selects the set of attributes that it wants to be
      inserted into an access token.

      If the GS has the requested attributes, then it provides them,
      otherwise it returns an error to the Client.

    

      

        

          

            

              

                
IMO, the User consent should be captured by the
                  Client, i.e. not by the GS. 

                  The information used to obtain the User consent should
                  be standardized (... and it can be standardized).

                

                

                  

                    
I think the abstract
                      sequence as proposed by Francis is a great
                      addition, and would clarify where consent is in
                      the sequence. 

                  

                

                
The current sketch does not illustrate the place the
                  User Consent is captured, in particular by the Client.

              

            

            
It is an abstraction. The GS receives the consent. How
              consent is gathered is a detail that is dependent on the
              use case.

          

        

      

    

    
[Denis] I really wonder whether there is really a "consent" to be
      received by the GS in both cases (i.e. ACLs or Capabilities).

    

    
    
      
  • For ACLs, the consent needs to be done by the Client.
    • 
      
  • For Capabilities, the current description is not clear since
        the inputs and the outputs for this "consent" phase
    
        are not currently described in the draft.
    • 
    

    

      

        

          

            
 

            

              

                

                  

                    

                      
 

                      

                        

                          

                            

                              

                                

                                  
 Another important point to
                                    consider and to explain is related
                                    to the assurances that the user can
                                    obtain about 

                                    the respect of his choices. This
                                    point is currently left unanswered
                                    in draft-hardt-xauth-protocol-13.

                                  

                                

                              

                            

                          

                          
This point is equally important: such
                            assurance can only be obtained if the access
                            token returned to the client 

                            is not considered to be opaque to the
                            client. This is a necessary condition but
                            not the single condition: 

                            the Client must also be in a position to
                            capture/memorize the "User consent and
                            choice" of the user in order to be able 

                            to verify it afterwards using the content of
                            the access token(s).

                        

                      

                      


                      

                      
We disagree on this being a requirement for
                        all use cases. It may be in some. 

                      

                    

                  

                

                
OK. Then this means that there will be no sentence in
                  the draft such as :

                  "access tokens returned to the client are not
                  considered to be opaque to the client".

              

            

            


            

            
For OAuth use cases, which GNAP supports, the access
              token is opaque to the Client. As you have noted, there
              are use cases where the access token is NOT opaque.

          

        

      

    

    
[Denis] Wait a second. There is no requirement to support all
      OAuth use cases. 

      I believe that there is a requirement to support OAuth 2.0 ASs,
      while the clients may be different 

      and hence GNAP clients do not need to inherit of the limitations
      of OAuth 2.0 clients.

    

      

        

          

            
 

            

              

                

                  

                    

                      
 

                      

                        

                          

                            

                              

                                

                                  
 

                                    

                                      

                                        

                                          

                                            

                                              
If a RO needs to be
                                                involved and since a RO
                                                is directly associated
                                                with a RS, why can't it
                                                be directly queried 

                                                by the appropriate RS
                                                after step (2) or later
                                                on ?

                                            

                                          

                                          


                                          

                                          
Good question. Perhaps
                                            you can expand on a use case
                                            where that would be useful?

                                        

                                      

                                    

                                    
Before I expand, would you be
                                      able to explain first under which
                                      circumstances a RO needs to be
                                      queried by a GS ?

                                      How can the GS identify which RO
                                      to query ?

                                  

                                

                                
If the User is the RO, then the GS
                                  knows who to query. 

                                

                              

                            

                          

                          
I still have difficulties to understand
                            what you mean here. 

                            How could a GS know that "the User is the
                            RO" ?  If "the User is the RO", why does the
                            GS needs to query the User ? 

                          

                        

                      

                      


                      

                      
To get consent?

                    

                  

                

                
To get a "RO consent" to himself ???

              

            

            


            

            
The GS needs consent from the RO. If the RO is the
              User, then consent from the RO is equivalent to consent
              from the User.

          

        

      

    

    
[Denis] See above.

    

    

      

        

          

            
 

            

            

              

                

                  

                    

                      
 

                      

                        

                          

                            

                              

                                
If the RO is a separate entity,
                                  then the GS knows the RO from the RS
                                  being queried. 

                                

                              

                            

                          

                          
 ... and this gives the ability for the GS
                            to log/trace all the RSs accessed by a given
                            User and at which instant of time the access
                            token has been granted.

                          

                            

                              

                                
An example is a user would like
                                  access to an enterprise asset where a
                                  workflow is started to gain approval,
                                  and an administrator or manager
                                  provides consent.

                              

                            

                          

                          
Thanks for this example. I finally
                            understand what you have in mind: you are
                            considering using an access control model to
                            build a workflow model. 

                            While it may be interesting to define a
                            workflow model, this should be considered as
                            a separate and different work item.

                        

                      

                      


                      

                      
The actual workflow is out of scope. 

                    

                  

                

                
I am glad you agree with this. But this means that
                  your example was not appropriate to illustrate your
                  point.

                

              

            

            


            

            
It illustrates a use case where the RO and User are not
              the same party, and why the GS needs to query the RO,
              which was your question if I understood it correctly.

          

        

      

    

    
[Denis] Since the inputs and the outputs for this "RO consent"
      phase are not currently described in the draft, the point is still
      unsolved.

    

    

      

        

          

            

              

                
 As soon as there is a RO consent obtained at the GS,
                  the major problem is that the GS is able to act as Big
                  Brother.

                  If a RO consent is performed at the RS, then the GS
                  will not know who the RS is: it is then unable to act
                  as Big Brother, 

                  even if it would enjoy to play that role.

              

            

            
In an enterprise use case, the GS's knowledge of who is
              accessing which RS is a feature.

          

        

      

    

    
Do you mean that it is "normal" in an enterprise that a single
      point of control is able to trace all their actions ? 

      From a security point of view, a single point of failure will have
      dramatic consequences.

    

      

        

          

            
In your use cases, it seems that the RO is the User. 

          

        

      

    

    
I do hope that you have finally understood that, in my use case,
      the RO is **not** the User.

    

      

        

          

            
The GS knows the User is wanting to let a Client access
              something. If the access token is generic, and could be
              presented to any RS that provides a standardized function,
              

              then the GS does not know which RS is being accessed by a
              Client for the User. This seems to meet your privacy
              objectives. If not, what is wrong?

          

        

      

    

    
For security reasons, an access token needs to be targeted (which
      does not necessarily mean that an identifier of the RS shall be
      included into the access token).

    

    

      

        

          

            

              

                

                  

                    

                      
if the admin grants access, then the access
                        granted to the client changes. 

                      

                      

                        

                          
 

                          
The model you propose may be suited for an
                            enterprise environment but is not scalable
                            over the Internet.

                        

                      

                      
It is one of the use cases we are working to
                        address. 

                      

                      

                        

                          
 What is needed is an access control model
                            usable over the Internet with millions of
                            RSs and thousands of ASs/GSs.  

                          

                        

                      

                      
I agree the model should also scale to
                        internet scale. 

                      

                    

                  

                

                
Fine. Another point on which we are in agreement. 

                

                
The model can scale to the Internet based on the
                  following assumptions:

                

                  
The flow starts with the steps (1) to (4) as
                    illustrated by Francis, i.e. the flow starts with a
                    contact with a RS.

                

                
+----+
                       +------+  +---+  +---+  +---+

                      |User|  |Client|  |RS |  |GS |  |RO |

                      +----+  +------+  +---+  +-+-+  +-+-+

                        |(1) Service Request     |      |

                        |-------->|       |      |      |

                        |         |(2) Service Intent   |

                        |         |------>|      |      |

                        |         |(3) AuthZ Challenge  |

                        |         |<------|      |      |

                        |         |(4) AuthZ Request    |

                        |         |------------->|      |

                
The GS/AS does not need to have any prior
                  relationship with ROs and/or RSs.

                
Furthermore, it is possible to prevent the GS to act
                  as Big Brother when the identity of the RS is not
                  disclosed to the GS.

                

              

            

            


            

            
What happens after (4) above? 

            

          

        

      

    

    
[Denis] The key point is that we first need to agree on the first
      four exchanges. Do we ?

    

    
The fifth exchange is different whether ACLs or Capabilities are
      being used.

    

    

      

        

          

            
 

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              
Which information is
                                                supposed to be presented
                                                to the RO ?

                                                Which information is
                                                supposed to be returned
                                                by the RO ?

                                            

                                          

                                          


                                          

                                          
Just like how the user
                                            authenticates to an AS, how
                                            the AS and RO communicate is
                                            out of scope.

                                          

                                        

                                      

                                    

                                    
At the moment, the usefulness of
                                      a dialogue between a GS and a RO
                                      has not been explained, nor
                                      demonstrated.

                                      The question is about the
                                      functionality of that dialogue in
                                      terms of input and output
                                      information (and not about 

                                      the design of a protocol or of a
                                      user interface). Anyway, AFAIU a
                                      dialogue between a GS and a RO is
                                      optional.

                                    

                                  

                                

                                


                                

                                
See enterprise example above.

                              

                            

                          

                          
It is not an access control example, but a
                            workflow example.

                          
Access  control has been
                            defined a long time ago and the last edition
                            of the model has been confirmed in year
                            1996: ISO/IEC 10181-3:
                                1996.

                            "Information
                              technology — Open Systems
                              Interconnection — Security frameworks for
                              open systems: Access control framework —
                              Part 3".

                          
Two major
                              functions have ben defined: an Access Control Enforcement
                                Function (AEF) and an Access Control
                              Decision Function(ADF).

                          

                            
Access Control Enforcement
                                Function (AEF):

                                A specialized function that is part of
                                the access path between an initiator and
                                a target on each access request and
                                enforces the decision made by the ADF.

                            Access Control
                              Decision Function (ADF) :

                            A
                              specialized function that makes access
                              control decisions by applying access
                              control policy rules to an access request,
                              ADI (of initiators, targets, access
                              requests, 

                            or that
                              retained from prior decisions), and the
                              context in which the access request is
                              made.

                          
The role of the RO is to define the "access control
                              policy rules" at the RS according to the context in
                                which the access request is made.

                        

                      

                      
I'm pretty familiar with access control
                        systems. :) 

                      


                      

                      
I would say that the access control is
                        happening at the RS. The client presents a token
                        when accessing an API. 

                        The RS uses the token, and any policy required,
                        to make an access decision.

                    

                  

                

                
Fine. It looks like we are in agreement.
                  Unfortunately, this is not the case just below.

                

                

                  

                    

                      
Here is flow:

                      


                      

                      
1) The Client requests access to an RS from
                        the GS. 

                      

                    

                  

                

                
No. We are no more in agreement. This is different
                  from the flow drawn by Francis.

              

            

            
My bad. Typo. I meant RO.

            
 

            

              

                

                  

                    

                      
2) The GS queries the RS if access should be
                        granted. 

                      

                    

                  

                

                
 No. The GS should not be forced to have a flow with
                  the RS.

              

            

            
Same mistake as above, I meant RO. 

            

              

                
 

                

                  

                    

                      
3) If access is granted, the GS creates an
                        access token representing the granted access,
                        and returns it to the Client. 

                      

                    

                  

                

                
This model is by no way conformant to ISO/IEC 10181-3: 1996 

                    

              

            

            
I'm unclear on why, or why it is even relevant. 

            

            

              

                
 

                

                  

                    

                      
4) The Client presents the access token to
                        the RS to show it has been granted access. 

                      

                    

                  

                

                
No. The client presents a token when accessing an
                  API. The RS uses the token, and any policy required,
                  to make an access decision.

                  The token never contains an information like "Please
                  grant an access to the holder of this token".

              

            

            
Let me provide more clarity in the sentence:

            


            

            
The Client presents the access token to the RS, to show
              the RS that the Client has been granted access to a
              resource at the RS by the GS.

          

        

      

    

    
[Denis] This time, please consider both the ACLs approach and the
      Capabilities approach.

    

      

        

          

            
 

            

              

                

                  

                    

                      
A couple advantages of this model:

                      
- that the RS does not need to know much, if
                        anything about the Client. 

                      
- the access token MAY be self contained so
                        that the Client does not need to query the GS on
                        each access. 

                      

                    

                  

                

                
There are so many disadvantages that I will not list
                  them.

              

            

            
Darn: I clearly was not firing on all cylinders when I
              typed this out. Let me correct:

            


            

            

              

                

                  

                    
- the access token MAY be self contained so
                      that the RS does not need to query the GS on each
                      access to the RS by the Client.

                  

                

              

            

          

        

      

    

    
[Denis] A few comments in the case of a capability approach:

    

      
- for each GS, the RS needs to locally manage which
        operation(s) is/are allowed to it.

        

        - the GS needs to establish a trusted communication channel or
        an authentication mechanism with each RO 

           (which is associated with an explicit RS identifier). 

      

      
- the GS could play the role of the RO and hence be in a
        position to issue any capability for any RS (without a "RO
        consent"). 

        

           The target of an attack will clearly be the GS.

      

    

    

      

        

          

            

              

                

                  

                    

                      
I would not say that GNAP is an access
                        control protocol, as how the RS uses the token
                        to determine access is out of scope.

                    

                  

                

                
This is where we have a major
                      discrepancy: how the RS uses the
                  token to determine access is *within* the scope.

              

            

          

        

      

    

    [Denis] Do you agree or disagree ?

    

      

        

          

            

              

                
The RS announces in advance to the client what it
                  needs so that the client can perform a a given
                  operation and if the client supplies the requested
                  attributes 

                  obtained from some GS/AS(s) trusted by the RS, then
                  access to that RS is granted by the RS. If the RS
                  cannot perform the requested operation on its own, 

                  then the client should be informed about some
                  requested attributes that need to be obtained from
                  some GS/AS(s) trusted by the next RS(s) in a chain

                  for subsequent operations. The User consent should
                  also be obtained before performing the chaining
                  operation.

                

                
Chaining operations between RSs over the Internet is
                  within the scope (... and may be achieved).

              

            

          

        

      

    

    
[Denis] Do you agree or disagree ?

    
Denis

    

    

      

        

          

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                
 

                                

                                  

                                    

                                      

                                        

                                          
For many use cases, the
                                            User is the RO, and the
                                            interaction is through a
                                            user interface, not a
                                            machine protocol. 

                                          

                                        

                                      

                                    

                                    
Wait a second. You wrote "the
                                      User is the RO". The User is
                                      attempting to make an access to a
                                      RS by using a Client. 

                                      That User is not the RO of
                                      the RS.   

                                    

                                  

                                

                                
The user being the RO is the
                                  initial use case for OAuth. 

                              

                            

                          

                          
OAuth 2.0 is no more mandating such a case.

                          

                        

                      

                    

                  

                

                

                  

                    


                      
I don't know what you mean by that.

                    

                  

                

                
Copy and paste from draft-ietf-oauth-security-topics:

                

                

                  
OAuth initially assumed a static relationship
                    between client, authorization server and resource
                    servers.  (...)  

                    With the increasing adoption of OAuth, this simple
                    model dissolved and, in several scenarios, was
                    replaced 

                    by a dynamic establishment of the relationship
                    between clients on one side and the authorization
                    and 

                    resource servers of a particular deployment on the
                    other side.

                    

                    This way, the same client could be used to access
                    services of different providers (in case of standard
                    APIs, 

                    such as e-mail or OpenID Connect) or serve as a
                    frontend to a particular tenant in a multi-tenancy
                    environment. 

                  

                

              

            

            


            

            
This sentence does not mention the RO or the Client.
              I'm confused what we are talking about 

            

              

                

                  
 

                

                

                  

                    

                      
 

                      

                        

                          

                            

                              

                                
A client application would like
                                  access to the user's photos at a photo
                                  sharing site. The resource is the
                                  user's photos. The user is the owner
                                  of that resource.

                              

                            

                          

                          
If the user has already pre established the
                            access control policy rules so that it can
                            access to his own photos 

                            then he does not need to grant in real time
                            any additional authorization.

                        

                      

                      
I don't understand what you are trying to
                        say. The photo sharing example was a driving use
                        case for the creation of OAuth.

                    

                  

                

                
We would need to revisit the original scenario and
                  consider if it can be addressed in a different way
                  than the original way.

              

            

            
The use case is the same. Is there a different solution
              you are proposing?

            
 

          

        

      

    

    


    

  


--------------7164DB06918B102894D15FBF--


From nobody Wed Jul 22 14:12: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 AB0B73A09A8 for ; Wed, 22 Jul 2020 14:12: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 OhpeMgdWcugU for ; Wed, 22 Jul 2020 14:12:51 -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 F18CD3A09A6 for ; Wed, 22 Jul 2020 14:12:50 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id c80so3143726wme.0 for ; Wed, 22 Jul 2020 14:12:50 -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=0GiYFlp7qNEZT8VJk0edYx3f5+cDd8lgo7/I46xJeh0=; b=KU+shBZsq1NegrYpaB4TXoPITCV4FshzAtGjhUo0GkWNmqMirD04bWBhQUMVOmworY D1M5n7ZkyjmKW13yZhvBwBB8h/v+nShhxpIi1toSiwB3GcoBUmiASFvqCej4bA5o8jCK /dniBWtwsE9N1z1XHKVseLU5sh+0kawuxPFy0=
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=0GiYFlp7qNEZT8VJk0edYx3f5+cDd8lgo7/I46xJeh0=; b=QeK+L5b2KZJ7e+PjlxU9gCmdMkCmOL/IBi1x/HIlEX+GWdp0c2jJzD9y2WSXVn3yvk E5F0shajMnuH3Nhsar4ZzklVbmP+QkSZAqtXgvIT5sp3X7O4NNEikl+P30cUjgxO1LER DgAV7/6iOwQBrGI1/SodCYpLfWkAX5KmevqpFzEupAFwMRgK5bOKB3PtGP8bG84McUA9 5th8NUPr0D8++EsmbkiHSTtjDTTqD7lcqrM9bEpzV4Vips6/0UoS5ea+C/Zx3220g/Cy uUCOn8hUc22tRyRwACTu1WlE2/rbotsoTscs2F1aaxlxwAQkEIqgARiHrbRhMk+sY9i5 69Rw==
X-Gm-Message-State: AOAM531mad9Tqts5qb4WwrgAjISi4HOxwAE/N2tObh5gUU0OjUU7w2ch MZoi4cxtzv3SDtwL2phG86/XPc+GF3j7dEpbHz2AIQ==
X-Google-Smtp-Source: ABdhPJy/8xzeb8iI880YCoBe5GhBzonMw/5ooiJpdwrDEDgYAxqTfd9+GcWUH1pXinRd95usU4g18+m5IkZjIp/+IrI=
X-Received: by 2002:a7b:c952:: with SMTP id i18mr1347539wml.65.1595452369280;  Wed, 22 Jul 2020 14:12:49 -0700 (PDT)
MIME-Version: 1.0
References:         
In-Reply-To: 
From: Francis Pouatcha 
Date: Wed, 22 Jul 2020 17:12:33 -0400
Message-ID: 
To: Fabien Imbault 
Cc: txauth@ietf.org, Tom Jones ,  Denis , Justin Richer , Dick Hardt 
Content-Type: multipart/alternative; boundary="000000000000ba353705ab0e3336"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 22 Jul 2020 21:12:54 -0000

--000000000000ba353705ab0e3336
Content-Type: text/plain; charset="UTF-8"

Hello Fabian,

On Wed, Jul 22, 2020 at 4:26 AM Fabien Imbault 
wrote:

> Hi all,
>
> Thanks for that work.
> It would make things easier if we could group the definitions which can be
> generic (without any knowledge of the GNAP architecture) from the terms
> which are dependent on the protocol flow itself.
>
> For terminology, the way it is done in ISO standards is quite interesting
> and we probably could reuse some ideas. The general rule of thumb is to
> reuse definitions when that's possible and re-define only when necessary.
> See for instance
> https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en
> You'll find :
> - a definition
> - potentially some notes (here we can explain how it differs from an
> already existing term used in a different context) and some examples
> - related reference (in many cases, we don't even need to reinvent
> something, as we just need to be consistent with terms already used in the
> community)
>
Good idea.


> Generic definitions :
> - resource, claim, consent, grant, authorization -> seems to me these are
> generic. Why does it matter in the definition that we know which party is
> doing it?
>
Relationship to parties is essential for the understanding of the GNAP
protocol.

- in most cases, those definitions shouldn't be different from other WGs,
> or else we should explain why that is.
> - party : if we refer to roles, we need to define that too.
>
party is defined to help delimitate User, Client, RS, GS, RO from other
terms.

> - grant : I don't get what you mean by "material form of an RO consent".
> What is material?
>
I meant: a Grant is a [materialization/database representation/...] of an
RO consent. GS stores the RO Consent in the form of a Grant.


> Specific definitions :
> - User, User-Agent, Client, RO, GS : all these are specific to the way the
> protocol is specified, so it does make sense to relate to the parties doing
> it.
>
Ok.

- But even then, we need to check whether that specificity is required. I'm
> not sure I agree with your definition of User, though. In 99% of use cases,
> a user is just... a user, i.e. a natural person. Why do we need to make
> this definition so convoluted?
>
Term User is introduced by Dick (see:
https://tools.ietf.org/html/draft-hardt-xauth-protocol-11#section-1.1). We
am trying to distance it from the RO. As this confusion leads to a lot of
misunderstandings in discussions in the group.

The User-Agent definition seems enough to convey the idea that interactions
> can be done through real users or things.
>
Not so sure. Precision helps reduce misunderstandings in discussions we are
conducting on GNAP.

Best regards.
/Francis


>
> Cheers
>
> Fabien
>
>
> On Wed, Jul 22, 2020 at 2:33 AM Francis Pouatcha  40adorsys.de@dmarc.ietf.org> wrote:
>
>> Hello Dick, Justin, Tom, Denis,
>>
>> Below is a new version of the dictionary includings comments from
>> different threads. Change log includes:
>> - avoided the expression "owns a resource" in favor of the expression
>> "controls a resource"
>> - included the clarification "resource access" and "claim release"
>> - included a clarification User vs. RO
>> - tried to clarify the word User-Agent
>> - added the definition of a Claim
>>
>> Terms
>> =====
>>
>> Party - represents a role in the GNAP protocol flow. A party can take the
>> form of a web service, an application installed on the user device and
>> acting autonomously or the form of a natural person (resp... of an
>> autonomous device) using an application to interact with other parties.
>>
>> Resource - a piece of data or web service
>>       - controlled by a Resource Owner (RO),
>>       - held and guarded by a Resource Server (RS) and
>>       - serviced by the RS to a Client, if the Client provides a valid
>> Authorization.
>>
>> Claim - a piece of data
>>       - controlled by a Resource Owner (RO),
>>       - held and guarded by the Grant Server (GS) and
>>       - released by the GS to a Client as part of an Authorization.
>>
>> Resource Owner (RO) - the party that
>>       - controls a Resource,
>>       - relies on the services the GS to manage access to that Resource,
>>       - relies on the services of a RS to hold the Resource and guard
>> access to that Resource,
>>       - controls a Claim,
>>       - relies on the services the GS to release that Claim to a Client.
>>
>> Resource Server (RS) - the party that
>>       - holds a resource and guards access to that resource on behalf of
>> the RO,
>>       - services the Resource to the requesting Client, provided the
>> Client presents a valid Authorization.
>>       The RS is generally deployed as a web service.
>>
>> Grant Server (GS) - the party that
>>       - manages access to a Resource on behalf of the RO,
>>       - holds Claims and releases them when consented by the RO.
>>       For each Resource access request, the GS might request the Consent
>> of the RO and produce a corresponding Authorization that is given to the
>> requesting Client.
>>
>> Consent - act of an RO :
>>       - approving access to a Resource, means approval that a Resource he
>> controls can be given to the Client by the RS.
>>       - approving release of a Claim, means approval that a Claim he
>> controls can be included by the GS in an Authorization to be returned to
>> the Client.
>>
>> Grant - material form of an RO Consent. In order not to interact with the
>> RO on each Resource access request, the GS might store the RO Consent in
>> the form of a Grant for reuse.
>>
>> Authorization - externalized form of a Grant as known to the GS and the
>> RS.
>>       - The GS converts a Grant into an Authorization for use in a
>> Resource access request.
>>       - The RS evaluates an Authorization to decide on whether or not to
>> release the Resource to the Client.
>>
>> Client - the party that provides the infrastructure used by a User to
>> access a Resource. The client infrastructure is designed to:
>>       - Receive the resource access request from the User,
>>       - Interact with the RS to discover authorization requirements,
>>       - Interact with the GS to obtain an Authorization to access the
>> Resource,
>>       - Interact with the RS to access the Resource on behalf of the User.
>>
>> User - the party using the infrastructure of the Client to gain access to
>> a Resource or a Claim.
>>
>>
>> Clarifications:
>> ==========
>>
>> User vs. RO :
>>       - the User is the party using the infrastructure of the Client to
>> gain access to a Resource or a Claim,
>>       - the RO is the party controlling access to a Resource or
>> controlling the release of a Claim.
>> In many use cases, User and RO will be represented by the same party (see
>> oAuth2), but GNAP exposes use cases where User and RO are represented by
>> different parties.
>>
>> User-Agent :
>> User and RO are parties that might be represented by a natural person or
>> an autonomous device. In those cases, User (resp. RO) might need the help
>> of an application to interact with other parties. Such an application is
>> generally referred to as the "User-Agent".
>>
>> Feedbacks are welcome.
>>
>> Best regards,
>> /Francis
>>
>>
>> On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha  wrote:
>>
>>>
>>>
>>> On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt  wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha 
>>>> wrote:
>>>>
>>>>>
>>>>> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt 
>>>>> wrote:
>>>>>
>>>>>> FYI: I consider the release of claims to be an "authorization" as
>>>>>> well.
>>>>>>
>>>>> Great. Then it is included.
>>>>>
>>>>
>>>> I pivoted to using the term Grant rather than authorization so that it
>>>> included both authorizing access to a resource, and authorizing the release
>>>> of an identity claim.
>>>>
>>>> Perhaps we should not use the word "authorization"?
>>>>
>>> Authorization is currently used to refer to the token issued by the
>>> GSand presented to the RS by the Client. I have no alternative word for now.
>>>
>>>>
>>>> "resource access" and "claim release"
>>>>
>>>> A Grant then covers both?
>>>>
>>> Yes, Great! The word Grant fits best for both. I suggest adding this
>>> clarification to that dictionary.
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>> IE, the user authorizes the GS to release a DOB claim to a Client.
>>>>>>
>>>>> I guess you mean the "RO" authorizes the GS to release a DOB!
>>>>>
>>>>
>>>> Yes, thanks for clarifying!
>>>>
>>>> /Dick
>>>>
>>>>>
>>>
>>> --
>>> 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/

--000000000000ba353705ab0e3336
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Fabian,

On Wed, Jul 22, 2020 at 4:26=
 AM Fabien Imbault <fabien.i=
mbault@gmail.com> wrote:
Hi all,=C2=A0

Thanks for that work.
It would make things easier if we c=
ould group the definitions which can be generic (without any knowledge of t=
he GNAP architecture) from the terms which are dependent on the protocol fl=
ow itself.=C2=A0

For terminology, the way it is do=
ne in ISO standards is quite interesting and we probably could reuse some i=
deas. The general rule of thumb is to reuse definitions when that's pos=
sible and re-define only when necessary.
See for instance=C2=A0https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en<=
/a>
You'll find :=C2=A0
- a definition
- =
potentially some notes (here we can explain how it differs from an already =
existing term used in a different context) and some examples
- re=
lated reference (in many cases, we don't even need to reinvent somethin=
g, as we just need to be consistent with terms already used in the communit=
y)
Good idea.=C2=A0

=


Generic definitions :=C2=A0
- resour=
ce, claim, consent, grant, authorization -> seems to me these are generi=
c. Why does it matter in the definition that we know which party is doing i=
t?
Relationship to parties is essential =
for the understanding of the GNAP protocol.

- in most cases, those definitions shouldn't be different from other=
 WGs, or else we should explain why that is.=C2=A0
- party : if w=
e refer to roles, we need to define that too.=C2=A0
party is defined to help delimitate User, Client, RS, GS, R=
O from other terms.
=

- grant : I=C2=A0don'=
t get what you mean by "material form of an RO consent". What is =
material?
I meant: a Grant is a [mat=
erialization/database representation/...] of an RO consent.=C2=A0GS stores =
the RO Consent in the form of a Grant.=C2=A0

<=
div>

Specific definitions :=C2=A0
- User=
, User-Agent, Client, RO, GS : all these are specific to the way the protoc=
ol is specified, so it does make sense to relate to the parties doing it.
Ok.=C2=A0

- But even then, we need to check whether that specificity is required. =
I'm not sure I agree with your definition of User, though. In 99% of us=
e cases, a user is just... a user, i.e. a natural person. Why do we need to=
 make this definition so convoluted? 
Te=
rm User is introduced by Dick (see: https://tools.ietf.org/html/draf=
t-hardt-xauth-protocol-11#section-1.1). We am trying to distance it fro=
m the RO. As this confusion leads to a lot of misunderstandings in discussi=
ons in the group.

The User-Agent definiti=
on seems enough to convey the idea that interactions can be done through re=
al users or things.
Not so sure. Precisi=
on helps reduce misunderstandings in discussions we are conducting on GNAP.=


Best regards.
/Francis
=C2=A0=


Cheers

Fabien


On Wed, Jul 22, 2020 at 2:33 AM Francis Pouatcha <fpo=
=3D40adors=
ys.de@dmarc.ietf.org> wrote:
Hello Dick, Justin, Tom, Denis,
Below=C2=A0is a new version of the dictionary includings comme=
nts=C2=A0from different=C2=A0threads. Change log includes:
- avoi=
ded the expression "owns a resource" in favor of the expression &=
quot;controls=C2=A0a resource"
- included the clarification=
=C2=A0"resource access" and "claim release"
-=
 included a clarification User vs. RO
- tried to clarify the word=
 User-Agent
- added the definition of a Claim

Terms
=3D=3D=3D=3D=3D

Party - represents a role in the GNAP=
 protocol flow. A party can take the form of a web service, an application =
installed on the user device and acting autonomously or the form of a natur=
al person (resp... of an autonomous device) using an application to interac=
t with other parties.

Resource - a piece of data or web service
=
=C2=A0 =C2=A0 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =C2=
=A0 =C2=A0 - held and guarded by a Resource Server (RS) and
=C2=A0 =C2=
=A0 =C2=A0 - serviced by the RS to a Client, if the Client provides a valid=
 Authorization.

Claim - a piece of data
=C2=A0 =C2=A0 =C2=A0 - co=
ntrolled by a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - held and guard=
ed by the Grant Server (GS) and
=C2=A0 =C2=A0 =C2=A0 - released by the G=
S to a Client as part of an Authorization.

Resource Owner (RO) - the=
 party that
=C2=A0 =C2=A0 =C2=A0 - controls a Resource,
=C2=A0 =C2=A0=
 =C2=A0 - relies on the services the GS to manage access to that Resource,<=
br>=C2=A0 =C2=A0 =C2=A0 - relies on the services of a RS to hold the Resour=
ce and guard access to that Resource,
=C2=A0 =C2=A0 =C2=A0 - controls a =
Claim,
=C2=A0 =C2=A0 =C2=A0 - relies on the services the GS to release t=
hat Claim to a Client.

Resource Server (RS) - the party that 
=C2=
=A0 =C2=A0 =C2=A0 - holds a resource and guards access to that resource on =
behalf of the RO,
=C2=A0 =C2=A0 =C2=A0 - services the Resource to the re=
questing Client, provided the Client presents a valid Authorization.
=C2=
=A0 =C2=A0 =C2=A0 The RS is generally deployed as a web service.

Gra=
nt Server (GS) - the party that 
=C2=A0 =C2=A0 =C2=A0 - manages access t=
o a Resource on behalf of the RO,
=C2=A0 =C2=A0 =C2=A0 - holds Claims an=
d releases them when consented by the RO.
=C2=A0 =C2=A0 =C2=A0 For each =
Resource access request, the GS might request the Consent of the RO and pro=
duce a corresponding Authorization that is given to the requesting Client.<=
br>
Consent - act of an RO :
=C2=A0 =C2=A0 =C2=A0 - approving access =
to a Resource, means approval that a Resource he controls can be given to t=
he Client by the RS.
=C2=A0 =C2=A0 =C2=A0 - approving release of a Claim=
, means approval that a Claim he controls can be included by the GS in an A=
uthorization to be returned to the Client.

Grant - material form of =
an RO Consent. In order not to interact with the RO on each Resource access=
 request, the GS might store the RO Consent in the form of a Grant for reus=
e.

Authorization - externalized form of a Grant as known to the GS a=
nd the RS.
=C2=A0 =C2=A0 =C2=A0 - The GS converts a Grant into an Author=
ization for use in a Resource access request.
=C2=A0 =C2=A0 =C2=A0 - The=
 RS evaluates an Authorization to decide on whether or not to release the R=
esource to the Client.

Client - the party that provides the infrastr=
ucture used by a User to access a Resource. The client infrastructure is de=
signed to:
=C2=A0 =C2=A0 =C2=A0 - Receive the resource access request fr=
om the User,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to discover aut=
horization requirements,
=C2=A0 =C2=A0 =C2=A0 - Interact with the GS to =
obtain an Authorization to access the Resource,
=C2=A0 =C2=A0 =C2=A0 - I=
nteract with the RS to access the Resource on behalf of the User.

Us=
er - the party using the infrastructure of the Client to gain access to a R=
esource or a Claim.


Clarifications:
=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

User vs. RO : 
=C2=A0 =C2=A0 =C2=A0 - the User is th=
e party using the infrastructure of the Client to gain access to a Resource=
 or a Claim,
=C2=A0 =C2=A0 =C2=A0 - the RO is the party controlling acce=
ss to a Resource or controlling the release of a Claim.
In many use case=
s, User and RO will be represented by the same party (see oAuth2), but GNAP=
 exposes use cases where User and RO are represented by different parties.<=
br>
User-Agent :
User and RO are parties that might be represented by=
 a natural person or an autonomous device. In those cases, User (resp. RO) =
might need the help of an application to interact with other parties. Such =
an application is generally referred to as the "User-Agent".
<=
br>Feedbacks are welcome.

Best regards,
=
/Francis


On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha <=
fpo@adorsys.de> =
wrote:




-- 




-- 

-- 

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/


--000000000000ba353705ab0e3336--


From nobody Wed Jul 22 17:51: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 7876B3A0AA6 for ; Wed, 22 Jul 2020 17:51:24 -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 m-4Q2103Javj for ; Wed, 22 Jul 2020 17:51:21 -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 131F33A0934 for ; Wed, 22 Jul 2020 17:51:20 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id l1so4532099ioh.5 for ; Wed, 22 Jul 2020 17:51:20 -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=RUuLI+uBxR3lHfceMX5DXucSo+dho3YKMFVyDg69JGE=; b=WoiR+rvzzl9n1dEFwCRnaGSXkr76SliHpuEGOjXMrJIuQ/uwEV0yVGVHV+xo6TK7qx PFHTk9IOHTMdZyn3gEBrmkxK4aR/kRtz3Y4Db5zRkt8zpDBhJamWDssfxw3gFDJzk0x3 etpBuBWeL86db+TgBnyzVfifxFkoS9YG3LAn9M33eYsZXNLB5a0CZXZfOocVqtBtJvXn 1hwINOKESvmQWjc+TW8egTKvrQlhzzlheDLW0DJwEqSxgwU+9qKQUjCrxiJH4SW9xzqH VsE/Ko+x0mDutYIITGHM1mX/fVKKoTP5j/WeIjNtIPldQCPccGm1GzelydYzUSr+gCDP eSTg==
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=RUuLI+uBxR3lHfceMX5DXucSo+dho3YKMFVyDg69JGE=; b=HUA3A8krfTBvdoFrf/0yVmGvgALWc2nQRd8RPxMWhg+CvUj88Q2T9o4dfH3tB+C7O2 9brKlglPgSS6le358HAfxYrfHqYKsfwST3UzzJ6hr0Xl7spLFrY6Tn1MsUVSMXJZQkIg +8llCZfEIwUG8drvPczmI3AdTydClBvacx1NUceovcKGHj/pBFEYXA9ISCjei8T4QdG6 wj7C96+kJEbHbIr7r+xh1DVHZ5pxCGVrD5C7+Uvz+qLr1xJQIf0ElVaJA2FNAwnr3q4R /EB4jWgdvhFucF8TnC1zxRLHWVRk1PdyeJ7TYJB4qjnWvHhxywsDVqEHsCwdgsgrf1I/ fFew==
X-Gm-Message-State: AOAM531GBwBaG25T9mTga6PSKISpus8dkW7N82JfQasV/cKmhBVYq5aT yERHppWftV8DB3uLuCijmkQF5Q0WkF/9d6DN61A=
X-Google-Smtp-Source: ABdhPJzHH4fiO350wA2ZYCap7bUoPYY5AplRcFpQWP79Acwlxq3SGP9m5X4YD3dTyiot6pO9WBsGvlDtREPzxOrkXhc=
X-Received: by 2002:a05:6638:69d:: with SMTP id i29mr2123938jab.47.1595465480036;  Wed, 22 Jul 2020 17:51:20 -0700 (PDT)
MIME-Version: 1.0
References:             <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>  
In-Reply-To: 
From: Fabien Imbault 
Date: Thu, 23 Jul 2020 02:51:07 +0200
Message-ID: 
To: Denis 
Cc: Dick Hardt , Francis Pouatcha , txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000030658b05ab114142"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 23 Jul 2020 00:51:25 -0000

--00000000000030658b05ab114142
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis,

I won't answer to most of your thread, as it is addressed to Dick.

However I'm puzzled by your comment, I think you're misunderstanding what
capabilities are about. As I understand it, this is due to the desire to
align your proposal with xauth/xyz, while a significant difference remains:
the agency model is different (and this reflects in the terminology work
started by Francis, which mandates some behaviour from the GS, which is
quite classical but that you don't agree with). But this has really nothing
to do with either capabilities or ACLs.

Most of existing access control systems are based on ACLs. This includes RS
protection endpoints with role based access, which is a very typical setup.
There's a practical reason why that is: with ACLs people tend to think
about who (individual or group) is making what action, and that is a simple
model to implement (albeit quite hard to maintain). There are downsides to
that approach both in terms of security (e.g. doesn't implement POLA) and
privacy that are well documented.

In no occurrence a capability system mandates that you trace anything,
quite the opposite actually. Capability systems work without a reference to
the user  identity, instead it works based on what the user proves it is
holding (such as a token). And therefore the privacy model is stronger (not
linked to an identity by default, although it probably will be at some
point in practice) and it allows properties which cannot be implemented
through ACLs, such as delegation (without the need of a third party such as
a GS). A downside is that it requires a more granular approach to rights
management (typical solutions for this include membranes) and traceability
can be challenging (see for instance Hortons "who's done it" for one
approach to this issue).

Fabien


Le mer. 22 juil. 2020 =C3=A0 18:34, Denis  a =C3=A9crit=
 :

> Hello Dick,
>
> I have identified the reason of the major difference between our two
> approaches.
>
> Access control may be performed using either ACLs (Access Control Lists)
> or Capabilities.
>
> *Note *: a capability identifies a resource and an allowed operation that
> can be performed on that resource.
>
> You are advocating a Capabilities approach while I am advocating an ACL
> approach.
>
> The capabilities approach allows the GS to trace every operation performe=
d
> by the users on any RS known by a GS.
> The management of these capabilities is made via the GS or at the GS by
> the various ROs. If the management is made
> via the GS, then a trusted communication channel needs to be established
> with every RO. If the management is made
> at the GS, then an authentication mechanism needs to be established with
> every RO. In the last case, the GS has the
> ability to know all the capabilities of the users whether they are used o=
r
> not. The less that can be said is that this model
> is not privacy friendly.
>
> With the ACL approach, a RO directly manages an ACL placed in front of
> each RS. The Access Control Decision Function
> (ADF) at the RS is able to keep track from prior decisions. The GS is
> kept ignorant of the content of these ACLs and only
> delivers to its clients attributes that are placed into access tokens.
> Such a model may be privacy friendly.
>
> Other comments are between the lines prefixed with [Denis].
>
>
> On Tue, Jul 21, 2020 at 11:26 AM Denis  wrote:
>
>> Hello Dick,
>>
>> Thank you for your feedback. Comments are between the lines.
>>
>> comments inserted ...
>>
>> On Tue, Jul 21, 2020 at 6:03 AM Denis  wrote:
>>
>>> Hello Dick,
>>>
>>> I duplicate the most important comment at the beginning of this email:
>>>
>>> You are considering using an access control model to build a workflow
>>> model.
>>>
>>> While it may be interesting to define a workflow model, this should be
>>> considered
>>> as a separate and different work item.
>>>
>>> See the other comments between the lines.
>>>
>>> On Mon, Jul 20, 2020 at 2:05 AM Denis  wrote:
>>>
>>>> Hi Dick,
>>>>
>>>> On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:
>>>>
>>>>> Hello Francis and Dick,
>>>>>
>>>>> The good news first: we are making some progress. We are now close to
>>>>> an agreement with steps (1) up to (3),
>>>>> ... except that the place where the user consent is captured is not
>>>>> mentioned/indicated.
>>>>>
>>>>
>>>> This major question which is currently left unanswered is where, when
>>>> and how the user consent is captured.
>>>>
>>>
>>> When is covered, per the sequence. How and where are out of scope of
>>> what I drafted.
>>>
>>> It is clear that the "User consent and choice" is not currently
>>> addressed in the draft, but it should.
>>> The support of the "User consent and choice" has strong implications no=
t
>>> only in the sequences of the exchanges
>>> but also by which entity it should be performed.
>>>
>> "consent" is in the latest draft 7 times.
>>
>> "Consent" is present 5 times. The User consent is different from the RO
>> consent (when/if it is required).
>>
>> The server acquires consent and authorization from the user *and/**or
>> resource owner **if required.*
>>
>> User consent is *often required* at the GS. GNAP enables a Client and
>> GS to negotiate the interaction mode for the GS to obtain consent.
>>
>> The GS *may *require explicit consent from the RO or User to provide
>> these to the Client.
>>
>> The User consent is not an alternative to the RO consent. So using
>> "and/or" in the first sentence is incorrect.
>>
>
> My language is sloppy there. Consent is always from the RO. The User may
> be the RO.
>
> [Denis] No. Once again: The "*User consent*" is different from what you
> call the "*RO consent*" (when/if it is required).
> The "RO consent" is not in fact a consent but the release of a capability
> to a client by one of the many R0s with which
> the GS has relationships.
>
> Since the second sentence is using the wording "often required" there is
>> no requirement to get the User consent.
>>
> User consent may not be required. There may not be a User. The consent ma=
y
> have been gathered previously.
>
> [Denis] In order to follow the privacy principles, a "User consent" phase
> is required. The User is a natural person.
> A Client is called either by a User (i.e. a natural person) or by a Clien=
t
> application.
>
> The second sentence does not consider the possibility to get the User
>> consent in a place different from the GS.
>>
> Agreed. But we do agree that the GS gets the consent, either directly fro=
m
> the RO, or from the Client (in your example).
>
> [Denis] No. I disagree. In an ACL based systems, the GS does not need to
> ask or receive any consent.
> The client selects the set of attributes that it wants to be inserted int=
o
> an access token.
> If the GS has the requested attributes, then it provides them, otherwise
> it returns an error to the Client.
>
> IMO, the User consent should be captured by the Client, i.e. not by the
>> GS.
>> The information used to obtain the User consent should be standardized
>> (... and it can be standardized).
>>
>> I think the abstract sequence as proposed by Francis is a great addition=
,
>> and would clarify where consent is in the sequence.
>>
>> The current sketch does not illustrate the place the User Consent is
>> captured, in particular by the Client.
>>
> It is an abstraction. The GS receives the consent. How consent is gathere=
d
> is a detail that is dependent on the use case.
>
> [Denis] I really wonder whether there is really a "consent" to be receive=
d
> by the GS in both cases (i.e. ACLs or Capabilities).
>
>    - For ACLs, the consent needs to be done by the Client.
>    - For Capabilities, the current description is not clear since the
>    inputs and the outputs for this "consent" phase
>    are not currently described in the draft.
>
>
>
>>
>>
>>> Another important point to consider and to explain is related to the
>>>> assurances that the user can obtain about
>>>> the respect of his choices. This point is currently left unanswered in
>>>> draft-hardt-xauth-protocol-13.
>>>>
>>> This point is equally important: such assurance can only be obtained if
>>> the access token returned to the client
>>> is not considered to be opaque to the client. This is a necessary
>>> condition but not the single condition:
>>> the Client must also be in a position to capture/memorize the "User
>>> consent and choice" of the user in order to be able
>>> to verify it afterwards using the content of the access token(s).
>>>
>>
>> We disagree on this being a requirement for all use cases. It may be in
>> some.
>>
>> OK. Then this means that there will be no sentence in the draft such as =
:
>> "access tokens returned to the client are not considered to be opaque to
>> the client".
>>
>
> For OAuth use cases, which GNAP supports, the access token is opaque to
> the Client. As you have noted, there are use cases where the access token
> is NOT opaque.
>
> [Denis] Wait a second. There is no requirement to support all OAuth use
> cases.
> I believe that there is a requirement to support OAuth 2.0 ASs, while the
> clients may be different
> and hence GNAP clients do not need to inherit of the limitations of OAuth
> 2.0 clients.
>
>
>
>>
>>
>>>
>>>> If a RO needs to be involved and since a RO is directly associated wit=
h
>>>>> a RS, why can't it be directly queried
>>>>> by the appropriate RS after step (2) or later on ?
>>>>>
>>>>
>>>> Good question. Perhaps you can expand on a use case where that would b=
e
>>>> useful?
>>>>
>>>> Before I expand, would you be able to explain first under which
>>>> circumstances a RO needs to be queried by a GS ?
>>>> How can the GS identify which RO to query ?
>>>>
>>> If the User is the RO, then the GS knows who to query.
>>>
>>> I still have difficulties to understand what you mean here.
>>> How could a GS know that "the User is the RO" ?  If "the User is the
>>> RO", why does the GS needs to query the User ?
>>>
>>
>> To get consent?
>>
>> To get a "RO consent" to himself ???
>>
>
> The GS needs consent from the RO. If the RO is the User, then consent fro=
m
> the RO is equivalent to consent from the User.
>
> [Denis] See above.
>
>
>
>>
>>
>>> If the RO is a separate entity, then the GS knows the RO from the RS
>>> being queried.
>>>
>>>  ... and this gives the ability for the GS to log/trace all the RSs
>>> accessed by a given User and at which instant of time the access token =
has
>>> been granted.
>>>
>>> An example is a user would like access to an enterprise asset where a
>>> workflow is started to gain approval, and an administrator or manager
>>> provides consent.
>>>
>>> Thanks for this example. I finally understand what you have in mind: yo=
u
>>> are considering using an access control model to build a *workflow
>>> model*.
>>> While it may be interesting to define a workflow model, this should be
>>> considered as a *separate and different work item*.
>>>
>>
>> The actual workflow is out of scope.
>>
>> I am glad you agree with this. But this means that your example was not
>> appropriate to illustrate your point.
>>
>
> It illustrates a use case where the RO and User are not the same party,
> and why the GS needs to query the RO, which was your question if I
> understood it correctly.
>
> [Denis] Since the inputs and the outputs for this "RO consent" phase are
> not currently described in the draft, the point is still unsolved.
>
> As soon as there is a RO consent obtained at the GS, the major problem is
>> that the GS is able to act as Big Brother.
>> If a RO consent is performed at the RS, then the GS will not know who th=
e
>> RS is: it is then unable to act as Big Brother,
>> even if it would enjoy to play that role.
>>
> In an enterprise use case, the GS's knowledge of who is accessing which R=
S
> is a feature.
>
> Do you mean that it is "normal" in an enterprise that a single point of
> control is able to trace all their actions ?
> From a security point of view, a single point of failure will have
> dramatic consequences.
>
> In your use cases, it seems that the RO is the User.
>
> I do hope that you have finally understood that, in my use case, the RO i=
s
> **not** the User.
>
> The GS knows the User is wanting to let a Client access something. If the
> access token is generic, and could be presented to any RS that provides a
> standardized function,
> then the GS does not know which RS is being accessed by a Client for the
> User. This seems to meet your privacy objectives. If not, what is wrong?
>
> For security reasons, an access token needs to be targeted (which does no=
t
> necessarily mean that an identifier of the RS shall be included into the
> access token).
>
> if the admin grants access, then the access granted to the client changes=
.
>>
>>> The model you propose may be suited for an enterprise environment but i=
s
>>> not scalable over the Internet.
>>>
>> It is one of the use cases we are working to address.
>>
>>> What is needed is an access control model usable over the Internet with
>>> millions of RSs and thousands of ASs/GSs.
>>>
>> I agree the model should also scale to internet scale.
>>
>> Fine. Another point on which we are in agreement.
>>
>> The model can scale to the Internet based on the following assumptions:
>>
>> The flow starts with the steps (1) to (4) as illustrated by Francis, i.e=
.
>> the flow starts with a contact with a RS.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS |
>>  |RO | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Request     =
|
>>    |   |-------->|       |      |      |   |         |(2) Service Intent
>> |   |         |------>|      |      |   |         |(3) AuthZ Challenge  =
|
>> |         |<------|      |      |   |         |(4) AuthZ Request    |   =
|
>>       |------------->|      |*
>>
>> The GS/AS does not need to have any prior relationship with ROs and/or
>> RSs.
>>
>> Furthermore, it is possible to prevent the GS to act as Big Brother when
>> the identity of the RS is not disclosed to the GS.
>>
>
> What happens after (4) above?
>
> [Denis] The key point is that we first need to agree on the first four
> exchanges. Do we ?
>
> The fifth exchange is different whether ACLs or Capabilities are being
> used.
>
>
>
>> Which information is supposed to be presented to the RO ?
>>>>> Which information is supposed to be returned by the RO ?
>>>>>
>>>>
>>>> Just like how the user authenticates to an AS, how the AS and RO
>>>> communicate is out of scope.
>>>>
>>>> At the moment, the usefulness of a dialogue between a GS and a RO has
>>>> not been explained, nor demonstrated.
>>>> The question is about the functionality of that dialogue in terms of
>>>> input and output information (and not about
>>>> the design of a protocol or of a user interface). Anyway, AFAIU a
>>>> dialogue between a GS and a RO is optional.
>>>>
>>>
>>> See enterprise example above.
>>>
>>> It is not an access control example, but a workflow example.
>>>
>>> Access  control has been defined a long time ago and the last edition o=
f
>>> the model has been confirmed in year 1996: ISO/IEC 10181-3: 1996.
>>> "Information technology =E2=80=94 Open Systems Interconnection =E2=80=
=94 Security
>>> frameworks for open systems: Access control framework =E2=80=94 Part 3"=
.
>>>
>>> Two major functions have ben defined: an Access Control Enforcement Fun=
ction
>>> (AEF) and an Access Control Decision Function(ADF).
>>>
>>> Access Control Enforcement Function (AEF):
>>> A specialized function that is part of the access path between an
>>> initiator and a target on each access request and enforces the decision
>>> made by the ADF.
>>> Access Control Decision Function (ADF) :
>>> A specialized function that makes access control decisions by applying
>>> access control policy rules to an access request, ADI (of initiators,
>>> targets, access requests,
>>> or that retained from prior decisions), and the context in which the
>>> access request is made.
>>>
>>> The role of the RO is to define the "access control policy rules" at
>>> the RS according to the context in which the access request is made.
>>>
>> I'm pretty familiar with access control systems. :)
>>
>> I would say that the access control is happening at the RS. The client
>> presents a token when accessing an API.
>> The RS uses the token, and any policy required, to make an access
>> decision.
>>
>> Fine. It looks like we are in agreement. Unfortunately, this is not the
>> case just below.
>>
>> Here is flow:
>>
>> 1) The Client requests access to an RS from the GS.
>>
>> No. We are no more in agreement. This is different from the flow drawn b=
y
>> Francis.
>>
> My bad. Typo. I meant RO.
>
>
>> 2) The GS queries the RS if access should be granted.
>>
>>  No. The GS should not be forced to have a flow with the RS.
>>
> Same mistake as above, I meant RO.
>
>> 3) If access is granted, the GS creates an access token representing the
>> granted access, and returns it to the Client.
>>
>> This model is by no way conformant to ISO/IEC 10181-3: 1996
>>
> I'm unclear on why, or why it is even relevant.
>
>> 4) The Client presents the access token to the RS to show it has been
>> granted access.
>>
>> No. The client presents a token when accessing an API. The RS uses the
>> token, and any policy required, to make an access decision.
>> The token never contains an information like "Please grant an access to
>> the holder of this token".
>>
> Let me provide more clarity in the sentence:
>
> The Client presents the access token to the RS, to show the RS that the
> Client has been granted access to a resource at the RS by the GS.
>
> [Denis] This time, please consider both the ACLs approach and the
> Capabilities approach.
>
>
>
>> A couple advantages of this model:
>> - that the RS does not need to know much, if anything about the Client.
>> - the access token MAY be self contained so that the Client does not nee=
d
>> to query the GS on each access.
>>
>> There are so many disadvantages that I will not list them.
>>
> Darn: I clearly was not firing on all cylinders when I typed this out. Le=
t
> me correct:
>
> - the access token MAY be self contained so that the RS does not need to
> query the GS on each access to the RS by the Client.
>
> [Denis] A few comments in the case of a capability approach:
>
> - for each GS, the RS needs to locally manage which operation(s) is/are
> allowed to it.
>
> - the GS needs to establish a trusted communication channel or an
> authentication mechanism with each RO
>    (which is associated with an explicit RS identifier).
>
> - the GS could play the role of the RO and hence be in a position to issu=
e
> any capability for any RS (without a "RO consent").
>
>    The target of an attack will clearly be the GS.
>
> I would not say that GNAP is an access control protocol, as how the RS
>> uses the token to determine access is out of scope.
>>
>> This is where we have a major discrepancy: how the RS uses the token to
>> determine access is *within* the scope.
>>
> [Denis] Do you agree or disagree ?
>
> The RS announces in advance to the client what it needs so that the clien=
t
>> can perform a a given operation and if the client supplies the requested
>> attributes
>> obtained from some GS/AS(s) trusted by the RS, then access to that RS is
>> granted by the RS. If the RS cannot perform the requested operation on i=
ts
>> own,
>> then the client should be informed about some requested attributes that
>> need to be obtained from some GS/AS(s) trusted by the next RS(s) in a ch=
ain
>> for subsequent operations. The User consent should also be obtained
>> before performing the chaining operation.
>>
>> Chaining operations between RSs over the Internet is within the scope
>> (... and may be achieved).
>>
> [Denis] Do you agree or disagree ?
>
> Denis
>
>
>>>
>>>> For many use cases, the User is the RO, and the interaction is through
>>>> a user interface, not a machine protocol.
>>>>
>>>> Wait a second. You wrote "the User is the RO". The User is attempting
>>>> to make an access to a RS by using a Client.
>>>> *That* User is not the RO of the RS.
>>>>
>>> The user being the RO is the initial use case for OAuth.
>>>
>>> OAuth 2.0 is no more mandating such a case.
>>>
>>
>> I don't know what you mean by that.
>>
>> Copy and paste from draft-ietf-oauth-security-topics:
>>
>> OAuth initially assumed a static relationship between client,
>> authorization server and resource servers.  (...)
>> With the increasing adoption of OAuth, this simple model dissolved and,
>> in several scenarios, was replaced
>> by a dynamic establishment of the relationship between clients on one
>> side and the authorization and
>> resource servers of a particular deployment on the other side.
>>
>> This way, the same client could be used to access services of different
>> providers (in case of standard APIs,
>> such as e-mail or OpenID Connect) or serve as a frontend to a particular
>> tenant in a multi-tenancy environment.
>>
>>
> This sentence does not mention the RO or the Client. I'm confused what we
> are talking about
>
>>
>>
>>> A client application would like access to the user's photos at a photo
>>> sharing site. The resource is the user's photos. The user is the owner =
of
>>> that resource.
>>>
>>> If the user has already pre established the access control policy rules
>>> so that it can access to his own photos
>>> then he does not need to grant in real time any additional authorizatio=
n.
>>>
>> I don't understand what you are trying to say. The photo sharing example
>> was a driving use case for the creation of OAuth.
>>
>> We would need to revisit the original scenario and consider if it can be
>> addressed in a different way than the original way.
>>
> The use case is the same. Is there a different solution you are proposing=
?
>
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--00000000000030658b05ab114142
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis,

I =
won't answer to most of your thread, as it is addressed to Dick.=C2=A0<=
/div>

However I'm puzzled =
by your comment, I think you're misunderstanding what capabilities are =
about. As I understand it, this is due to the desire to align your proposal=
 with xauth/xyz, while a significant difference remains: the agency model i=
s different (and this reflects in the terminology work started by Francis, =
which mandates some behaviour from the GS, which is quite classical but tha=
t you don't agree with). But this has really nothing to do with either =
capabilities or ACLs.=C2=A0

Mo=
st of existing access control systems are based on ACLs. This includes RS p=
rotection endpoints with role based access, which is a very typical setup. =
There's a practical reason why that is: with ACLs people tend to think =
about who (individual or group) is making what action, and that is a simple=
 model to implement (albeit quite hard to maintain). There are downsides to=
 that approach both in terms of security (e.g. doesn't implement POLA) =
and privacy that are well documented.=C2=A0

In no occurrence a capability system mandates that you =
trace anything, quite the opposite actually. Capability systems work withou=
t a reference to the user=C2=A0 identity, instead it works based on what th=
e user proves it is holding (such as a token). And therefore the privacy mo=
del is stronger (not linked to an identity by default, although it probably=
 will be at some point in practice) and it allows properties which cannot b=
e implemented through ACLs, such as delegation (without the need of a third=
 party such as a GS). A downside is that it requires a more granular approa=
ch to rights management (typical solutions for this include membranes) and =
traceability can be challenging (see for instance Hortons "who's d=
one it" for one approach to this issue).

Fabien=C2=A0


Le mer. 22 juil. 2020 =
=C3=A0 18:34, Denis <denis.ietf@free.fr> a =C3=A9crit=
=C2=A0:

 =20
   =20
 =20
  

    
Hello Dick,

    


    

    
I have identified the reason of the
      major difference between our two approaches.

    


    

    
Access control may be performed using
      either ACLs (Access Control Lists) or Capabilities.

    


    

    
Note : a capability identifies
      a resource and an allowed operation that can be performed on that
      resource.

    

    


    

    
You are advocating a Capabilities
      approach while I am advocating an ACL approach.

    
The capabilities approach allows the GS to trace every operation
      performed by the users on any RS known by a GS.

      The management of these capabilities is made via the GS or at the
      GS by the various ROs. If the management is made 

      via the GS, then a trusted communication channel needs to be
      established with every RO. If the management is made 

      at the GS, then an authentication mechanism needs to be
      established with every RO. In the last case, the GS has the 

      ability to know all the capabilities of the users whether they are
      used or not. The less that can be said is that this model 

      is not privacy friendly.

    
With the ACL approach, a RO directly manages an ACL placed in
      front of each RS. The Acces=
s Control Decision
        Function 

          (ADF) at the
        RS is able to keep track from prior decisions. The GS is
      kept ignorant of the content of these ACLs and only 

      delivers to its clients attributes that are placed into access
      tokens. Such a model may be privacy friendly.

    
Other comments are between the lines prefixed with [Denis].

    

     =20
      

        


          

            
On Tue, Jul 21, 2020 at
              11:26 AM Denis <denis.ietf@free.fr<=
/a>> wrote:

            

            

              

                
Hello Dick,

                


                

                
 Thank you for your feedback. Comments are between
                  the lines.

                


                

                

                  

                    
comments inserted ...=C2=A0

                    

                    

                      
On Tue, Jul 21,
                        2020 at 6:03 AM Denis <den=
is.ietf@free.fr>
                        wrote:

                      

                      

                        

                          
Hello Dick,

                          


                          

                          
I duplicate the most important comment at
                            the beginning of this email:

                          

                            
You are considering using an access
                              control model to build a workflow
                              model.

                               

                              While it may be interesting to define a
                              workflow model, this should be considered
                              

                              as a separate and different work item.

                          

                          
See the other comments between the lines.
                          

                          


                          

                          

                            
On Mon, Jul 20, 2020 at 2:05
                              AM Denis <denis.ietf=
@free.fr>
                              wrote:

                              

                                

                                  

                                    
Hi Dick,

                                    


                                    

                                    

                                      
On Fri, Jul 17,
                                        2020 at 9:21 AM Denis <denis.ietf@free.fr>
                                        wrote:

                                        

                                          

                                            

                                              
Hello Francis and
                                                Dick,

                                              


                                              

                                              
The good news first:
                                                we are making some
                                                progress. We are now
                                                close to an agreement
                                                with steps (1) up to
                                                (3), 

                                                ... except that the
                                                place where the user
                                                consent is captured is
                                                not mentioned/indicated.
                                            

                                          

                                        

                                      

                                    

                                    

                                    This major question which is
                                    currently left unanswered is where,
                                    when and how the user consent is
                                    captured.

                                  

                                

                                


                                

                                
When is covered, per the sequence.
                                  How and where are out of scope of what
                                  I drafted. 

                                

                              

                            

                          

                          
It is clear that the "User consent and
                            choice" is not currently addressed in the
                            draft, but it should.

                            The support of the "User consent and choic=
e"
                            has strong implications not only in the
                            sequences of the exchanges 

                            but also by which entity it should be
                            performed.

                        

                      

                      
"consent" is in the latest draft 7 tim=
es. 

                      

                    

                  

                

                
"Consent" is present 5 times. The User consent=
 is
                  different from the RO consent (when/if it is
                  required). 

                

                

                  
The server acquires consent and authorization from
                    the user and/or resource owner if
                      required.

                  

                  
User consent is often required at the GS.
                    GNAP enables a Client and=C2=A0 GS to negotiate the
                    interaction mode for the GS to obtain consent.

                  

                  
 The GS may require explicit consent from
                    the RO or User to provide these to the Client.

                  

                

                
The User consent is not an alternative to the RO
                  consent. So using "and/or" in the first sentenc=
e is
                  incorrect.

              

            

            


            

            
My language is sloppy there. Consent is always from the
              RO. The User may be the RO.

          

        

      

    

    
[Denis] No. Once again: The "User consent" is diffe=
rent
      from what you call the "RO consent" (when/if it is
      required). 

      The "RO consent" is not in fact a consent but the release o=
f a
      capability to a client by one of the many R0s with which 

      the GS has relationships. 

    

    

      

        

          

            

              

                
Since the second sentence is using the wording "oft=
en
                  required" there is no requirement to get the User
                  consent.

                

              

            

            
User consent may not be required. There may not be a
              User. The consent may have been gathered previously.

          

        

      

    

    
[Denis] In order to follow the privacy principles, a "User
      consent" phase is required. The User is a natural person.

      A Client is called either by a User (i.e. a natural person) or by
      a Client application. 

    

    

      

        

          

            

              

                
 

                
The second sentence does not consider the possibility
                  to get the User consent in a place different from the
                  GS.

              

            

            
Agreed. But we do agree that the GS gets the consent,
              either directly from the RO, or from the Client (in your
              example).

          

        

      

    

    
[Denis] No. I disagree. In an ACL based systems, the GS does not
      need to ask or receive any consent.

      The client selects the set of attributes that it wants to be
      inserted into an access token.

      If the GS has the requested attributes, then it provides them,
      otherwise it returns an error to the Client.

    

      

        

          

            

              

                
IMO, the User consent should be captured by the
                  Client, i.e. not by the GS. 

                  The information used to obtain the User consent should
                  be standardized (... and it can be standardized).

                

                

                  

                    
I think the abstract
                      sequence as proposed by Francis is a great
                      addition, and would clarify where consent is in
                      the sequence. 

                  

                

                
The current sketch does not illustrate the place the
                  User Consent is captured, in particular by the Client.
              

            

            
It is an abstraction. The GS receives the consent. How
              consent is gathered is a detail that is dependent on the
              use case.

          

        

      

    

    
[Denis] I really wonder whether there is really a "consent"=
; to be
      received by the GS in both cases (i.e. ACLs or Capabilities).

    

    
    
      
  • For ACLs, the consent needs to be done by the Client.
    • 
      
  • For Capabilities, the current description is not clear since
        the inputs and the outputs for this "consent" phase
    
        are not currently described in the draft.
    • 
    

    

      

        

          

            
=C2=A0

            

              

                

                  

                    

                      
=C2=A0

                      

                        

                          

                            

                              

                                

                                  
 Another important point to
                                    consider and to explain is related
                                    to the assurances that the user can
                                    obtain about 

                                    the respect of his choices. This
                                    point is currently left unanswered
                                    in draft-hardt-xauth-protocol-13.

                                  

                                

                              

                            

                          

                          
This point is equally important: such
                            assurance can only be obtained if the access
                            token returned to the client 

                            is not considered to be opaque to the
                            client. This is a necessary condition but
                            not the single condition: 

                            the Client must also be in a position to
                            capture/memorize the "User consent and
                            choice" of the user in order to be able 
                            to verify it afterwards using the content of
                            the access token(s).

                        

                      

                      


                      

                      
We disagree on this being a requirement for
                        all use cases. It may be in some. 

                      

                    

                  

                

                
OK. Then this means that there will be no sentence in
                  the draft such as :

                  "access tokens returned to the client are not
                  considered to be opaque to the client".

              

            

            


            

            
For OAuth use cases, which GNAP supports, the access
              token is opaque to the Client. As you have noted, there
              are use cases where the access token is NOT opaque.

          

        

      

    

    
[Denis] Wait a second. There is no requirement to support all
      OAuth use cases. 

      I believe that there is a requirement to support OAuth 2.0 ASs,
      while the clients may be different 

      and hence GNAP clients do not need to inherit of the limitations
      of OAuth 2.0 clients.

    

      

        

          

            
=C2=A0

            

              

                

                  

                    

                      
=C2=A0

                      

                        

                          

                            

                              

                                

                                  
 

                                    

                                      

                                        

                                          

                                            

                                              
If a RO needs to be
                                                involved and since a RO
                                                is directly associated
                                                with a RS, why can't it
                                                be directly queried 

                                                by the appropriate RS
                                                after step (2) or later
                                                on ?

                                            

                                          

                                          


                                          

                                          
Good question. Perhaps
                                            you can expand on a use case
                                            where that would be useful?
                                        

                                      

                                    

                                    
Before I expand, would you be
                                      able to explain first under which
                                      circumstances a RO needs to be
                                      queried by a GS ?

                                      How can the GS identify which RO
                                      to query ?

                                  

                                

                                
If the User is the RO, then the GS
                                  knows who to query. 

                                

                              

                            

                          

                          
I still have difficulties to understand
                            what you mean here. 

                            How could a GS know that "the User is the
                            RO" ?=C2=A0 If "the User is the RO&qu=
ot;, why does the
                            GS needs to query the User ? 

                          

                        

                      

                      


                      

                      
To get consent?

                    

                  

                

                
To get a "RO consent" to himself ???

              

            

            


            

            
The GS needs consent from the RO. If the RO is the
              User, then consent from the RO is equivalent to consent
              from the User.

          

        

      

    

    
[Denis] See above.

    

    

      

        

          

            
=C2=A0

            

            

              

                

                  

                    

                      
=C2=A0

                      

                        

                          

                            

                              

                                
If the RO is a separate entity,
                                  then the GS knows the RO from the RS
                                  being queried. 

                                

                              

                            

                          

                          
=C2=A0... and this gives the ability for the G=
S
                            to log/trace all the RSs accessed by a given
                            User and at which instant of time the access
                            token has been granted.

                          

                            

                              

                                
An example=C2=A0is a user would like
                                  access to an enterprise asset where a
                                  workflow is started to gain approval,
                                  and an administrator or manager
                                  provides consent.

                              

                            

                          

                          
Thanks for this example. I finally
                            understand what you have in mind: you are
                            considering using an access control model to
                            build a workflow model. 

                            While it may be interesting to define a
                            workflow model, this should be considered as
                            a separate and different work item.

                        

                      

                      


                      

                      
The actual workflow is out of scope. 

                    

                  

                

                
I am glad you agree with this. But this means that
                  your example was not appropriate to illustrate your
                  point.

                

              

            

            


            

            
It illustrates a use case where the RO and User are not
              the same party, and why the GS needs to query the RO,
              which was your question if I understood it correctly.

          

        

      

    

    
[Denis] Since the inputs and the outputs for this "RO consent&q=
uot;
      phase are not currently described in the draft, the point is still
      unsolved.

    

    

      

        

          

            

              

                
 As soon as there is a RO consent obtained at the GS,
                  the major problem is that the GS is able to act as Big
                  Brother.

                  If a RO consent is performed at the RS, then the GS
                  will not know who the RS is: it is then unable to act
                  as Big Brother, 

                  even if it would enjoy to play that role.

              

            

            
In an enterprise use case, the GS's knowledge of who i=
s
              accessing which RS is a feature.

          

        

      

    

    
Do you mean that it is "normal" in an enterprise that a si=
ngle
      point of control is able to trace all their actions ? 

      From a security point of view, a single point of failure will have
      dramatic consequences.

    

      

        

          

            
In your use cases, it seems that the RO is the User. 
          

        

      

    

    
I do hope that you have finally understood that, in my use case,
      the RO is **not** the User.

    

      

        

          

            
The GS knows the User is wanting to let a Client access
              something. If the access token is generic, and could be
              presented to any RS that provides a standardized function,
              

              then the GS does not know which RS is being accessed by a
              Client for the User. This seems to meet your privacy
              objectives. If not, what is wrong?

          

        

      

    

    
For security reasons, an access token needs to be targeted (which
      does not necessarily mean that an identifier of the RS shall be
      included into the access token).

    

    

      

        

          

            

              

                

                  

                    

                      
if the admin grants access, then the access
                        granted to the client changes. 

                      

                      

                        

                          
 

                          
The model you propose may be suited for an
                            enterprise environment but is not scalable
                            over the Internet.

                        

                      

                      
It is one of the use cases we are working to
                        address. 

                      

                      

                        

                          
 What is needed is an access control model
                            usable over the Internet with millions of
                            RSs and thousands of ASs/GSs.=C2=A0 

                          

                        

                      

                      
I agree the model should also scale to
                        internet scale. 

                      

                    

                  

                

                
Fine. Another point on which we are in agreement. 

                

                
The model can scale to the Internet based on the
                  following assumptions:

                

                  
The flow starts with the steps (1) to (4) as
                    illustrated by Francis, i.e. the flow starts with a
                    contact with a RS.

                

                
+----+
                      =C2=A0+------+ =C2=A0+---+ =C2=A0+---+ =C2=A0+---+
                      |User| =C2=A0|Client| =C2=A0|RS | =C2=A0|GS | =C2=A0|=
RO |

                      +----+ =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 |(2) Service Int=
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 |(3) AuthZ Chall=
enge =C2=A0|

                      =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =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) AuthZ Reque=
st =C2=A0 =C2=A0|

                      =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |-------------&g=
t;| =C2=A0 =C2=A0 =C2=A0|

                
The GS/AS does not need to have any prior
                  relationship with ROs and/or RSs.

                
Furthermore, it is possible to prevent the GS to act
                  as Big Brother when the identity of the RS is not
                  disclosed to the GS.

                

              

            

            


            

            
What happens after (4) above? 

            

          

        

      

    

    
[Denis] The key point is that we first need to agree on the first
      four exchanges. Do we ?

    

    
The fifth exchange is different whether ACLs or Capabilities are
      being used.

    

    

      

        

          

            
=C2=A0

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              
Which information is
                                                supposed to be presented
                                                to the RO ?

                                                Which information is
                                                supposed to be returned
                                                by the RO ?

                                            

                                          

                                          


                                          

                                          
Just like how the user
                                            authenticates to an AS, how
                                            the AS and RO communicate is
                                            out of scope.

                                          

                                        

                                      

                                    

                                    
At the moment, the usefulness of
                                      a dialogue between a GS and a RO
                                      has not been explained, nor
                                      demonstrated.

                                      The question is about the
                                      functionality of that dialogue in
                                      terms of input and output
                                      information (and not about 

                                      the design of a protocol or of a
                                      user interface). Anyway, AFAIU a
                                      dialogue between a GS and a RO is
                                      optional.

                                    

                                  

                                

                                


                                

                                
See enterprise example above.

                              

                            

                          

                          
It is not an access control example, but a
                            workflow example.

                          
Access=C2=A0 control has b=
een
                            defined a long time ago and the last edition
                            of the model has been confirmed in year
                            1996: ISO/IEC=C2=A010181-3:
                                1996.

                            "Infor=
mation
                              technology=C2=A0=E2=80=94 Open Systems
                              Interconnection=C2=A0=E2=80=94 Security frame=
works for
                              open systems: Access control framework=C2=A0=
=E2=80=94
                              Part=C2=A03".

                          
Two major
                              functions have ben defined: an Acce=
ss Control Enforcem=
ent
                                Function (AEF) and an <=
/span>Access Control
                              Decision Function(A=
DF).

                          

                            
Access =
Control Enforcement
                                Function (AEF):

                                A specialized function that is part of
                                the access path between an initiator and
                                a target on each access request and
                                enforces the decision made by the ADF.

                            Acces=
s Control
                              Decision Function (=
ADF) :

                            A
                              specialized function that makes access
                              control decisions by applying access
                              control policy rules to an access request,
                              ADI (of initiators, targets, access
                              requests, 

                            or that
                              retained from prior decisions), and the
                              context in which the access request is
                              made.

                          
The role of the RO is to define the "access control
                              policy rules" at the RS according to the=
 context in
                                which the access request is made.

                        

                      

                      
I'm pretty familiar with access control
                        systems. :)=C2=A0

                      


                      

                      
I would say that the access control is
                        happening at the RS. The client presents a token
                        when accessing an API. 

                        The RS uses the token, and any policy required,
                        to make an access decision.

                    

                  

                

                
Fine. It looks like we are in agreement.
                  Unfortunately, this is not the case just below.

                

                

                  

                    

                      
Here is flow:

                      


                      

                      
1) The Client requests access to an RS from
                        the GS. 

                      

                    

                  

                

                
No. We are no more in agreement. This is different
                  from the flow drawn by Francis.

              

            

            
My bad. Typo. I meant RO.

            
=C2=A0

            

              

                

                  

                    

                      
2) The GS queries the RS if access should be
                        granted. 

                      

                    

                  

                

                
=C2=A0No. The GS should not be forced to have a flow wit=
h
                  the RS.

              

            

            
Same mistake as above, I meant RO.=C2=A0

            

              

                
 

                

                  

                    

                      
3) If access is granted, the GS creates an
                        access token representing the granted access,
                        and returns it to the Client. 

                      

                    

                  

                

                
This model is by no way conformant to ISO/IEC=C2=A010181-3: 1996 

                    

              

            

            
I'm unclear on why, or why it is even relevant. 

            

            

              

                
 

                

                  

                    

                      
4) The Client presents the access token to
                        the RS to show it has been granted access. 

                      

                    

                  

                

                
No. The client presents a token when accessing an
                  API. The RS uses the token, and any policy required,
                  to make an access decision.

                  The token never contains an information like "Please
                  grant an access to the holder of this token".

              

            

            
Let me provide more clarity in the sentence:

            


            

            
The Client presents the access token to the RS, to show
              the RS that the Client has been granted access to a
              resource at the RS by the GS.

          

        

      

    

    
[Denis] This time, please consider both the ACLs approach and the
      Capabilities approach.

    

      

        

          

            
=C2=A0

            

              

                

                  

                    

                      
A couple advantages of this model:

                      
- that the RS does not need to know much, if
                        anything about the Client.=C2=A0

                      
- the access token MAY be self contained so
                        that the Client does not need to query the GS on
                        each access. 

                      

                    

                  

                

                
There are so many disadvantages that I will not list
                  them.

              

            

            
Darn: I clearly was not firing on all cylinders when I
              typed this out. Let me correct:

            


            

            

              

                

                  

                    
- the access token MAY be self contained so
                      that the RS does not need to query the GS on each
                      access to the RS by the Client.

                  

                

              

            

          

        

      

    

    
[Denis] A few comments in the case of a capability approach:

    

      
- for each GS, the RS needs to locally manage which
        operation(s) is/are allowed to it.

        

        - the GS needs to establish a trusted communication channel or
        an authentication mechanism with each RO 

        =C2=A0=C2=A0 (which is associated with an explicit RS identifier). =


      

      
- the GS could play the role of the RO and hence be in a
        position to issue any capability for any RS (without a "RO
        consent"). 

        

        =C2=A0=C2=A0 The target of an attack will clearly be the GS.

      

    

    

      

        

          

            

              

                

                  

                    

                      
I would not say that GNAP is an access
                        control protocol, as how the RS uses the token
                        to determine access is out of scope.

                    

                  

                

                
This is where we have a major
                      discrepancy: how the RS uses the
                  token to determine access is *within* the scope.

              

            

          

        

      

    

    [Denis] Do you agree or disagree ?

    

      

        

          

            

              

                
The RS announces in advance to the client what it
                  needs so that the client can perform a a given
                  operation and if the client supplies the requested
                  attributes 

                  obtained from some GS/AS(s) trusted by the RS, then
                  access to that RS is granted by the RS. If the RS
                  cannot perform the requested operation on its own, 

                  then the client should be informed about some
                  requested attributes that need to be obtained from
                  some GS/AS(s) trusted by the next RS(s) in a chain

                  for subsequent operations. The User consent should
                  also be obtained before performing the chaining
                  operation.

                

                
Chaining operations between RSs over the Internet is
                  within the scope (... and may be achieved).

              

            

          

        

      

    

    
[Denis] Do you agree or disagree ?

    
Denis

    

    

      

        

          

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                
=C2=A0

                                

                                  

                                    

                                      

                                        

                                          
For many use cases, the
                                            User is the RO, and the
                                            interaction is through a
                                            user interface, not a
                                            machine protocol. 

                                          

                                        

                                      

                                    

                                    
Wait a second. You wrote "the
                                      User is the RO". The User is
                                      attempting to make an access to a
                                      RS by using a Client. 

                                      That User is not the RO of
                                      the RS.=C2=A0=C2=A0 

                                    

                                  

                                

                                
The user being the RO is the
                                  initial use case for OAuth. 

                              

                            

                          

                          
OAuth 2.0 is no more mandating such a case.
                          

                        

                      

                    

                  

                

                

                  

                    


                      
I don't know what you mean by that.

                    

                  

                

                
Copy and paste from draft-ietf-oauth-security-topics:
                

                

                  
OAuth initially assumed a static relationship
                    between client, authorization server and resource
                    servers.=C2=A0 (...)=C2=A0 

                    With the increasing adoption of OAuth, this simple
                    model dissolved and, in several scenarios, was
                    replaced 

                    by a dynamic establishment of the relationship
                    between clients on one side and the authorization
                    and 

                    resource servers of a particular deployment on the
                    other side.

                    

                    This way, the same client could be used to access
                    services of different providers (in case of standard
                    APIs, 

                    such as e-mail or OpenID Connect) or serve as a
                    frontend to a particular tenant in a multi-tenancy
                    environment. 

                  

                

              

            

            


            

            
This sentence does not mention the RO or the Client.
              I'm confused what we are talking about=C2=A0

            

              

                

                  
 

                

                

                  

                    

                      
=C2=A0

                      

                        

                          

                            

                              

                                
A client application would like
                                  access to the user's photos at a phot=
o
                                  sharing site. The resource is the
                                  user's photos. The user is the owner
                                  of that resource.

                              

                            

                          

                          
If the user has already pre established the
                            access control policy rules so that it can
                            access to his own photos 

                            then he does not need to grant in real time
                            any additional authorization.

                        

                      

                      
I don't understand what you are trying to
                        say. The photo sharing example was a driving use
                        case for the creation of OAuth.

                    

                  

                

                
We would need to revisit the original scenario and
                  consider if it can be addressed in a different way
                  than the original way.

              

            

            
The use case is the same. Is there a different solution
              you are proposing?

            
=C2=A0

          

        

      

    

    


    

  


-- 

Txauth mailing list

Txauth@ietf.org

https://www.ietf.org/ma=
ilman/listinfo/txauth




--00000000000030658b05ab114142--


From nobody Thu Jul 23 08:07: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 8FF0B3A091F for ; Thu, 23 Jul 2020 08:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Zqb3rEMOKYBc for ; Thu, 23 Jul 2020 08:07:37 -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 06DCB3A0920 for ; Thu, 23 Jul 2020 08:07:32 -0700 (PDT)
Received: from [192.168.1.3] (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 06NF7Q9I029663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jul 2020 11:07:27 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_8C0070B5-1405-47DD-B72C-687FC347EF37"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 23 Jul 2020 11:07:26 -0400
In-Reply-To: 
Cc: txauth@ietf.org, Dick Hardt , Tom Jones , Denis 
To: Francis Pouatcha 
References:        
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 23 Jul 2020 15:07:40 -0000

--Apple-Mail=_8C0070B5-1405-47DD-B72C-687FC347EF37
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Up-front question to the Chairs, do we have a good place to capture this =
kind of thing? A non-spec document like this would be a good candidate =
for a wiki page. Do we have plans to set up a GitHub repository or =
similar? If so we could use the wiki capabilities there to at least get =
this stuff written down. Use cases would be good to capture there as =
well.=20



Francis,

First, I want to thank you for putting the work in to getting some =
vocabulary down. This is not an easy task! Some notes on specific items =
inline below.

> On Jul 21, 2020, at 8:33 PM, Francis Pouatcha  wrote:
>=20
> Hello Dick, Justin, Tom, Denis,
>=20
> Below is a new version of the dictionary includings comments from =
different threads. Change log includes:
> - avoided the expression "owns a resource" in favor of the expression =
"controls a resource"
> - included the clarification "resource access" and "claim release"
> - included a clarification User vs. RO
> - tried to clarify the word User-Agent
> - added the definition of a Claim
>=20
> Terms
> =3D=3D=3D=3D=3D
>=20
> Party - represents a role in the GNAP protocol flow. A party can take =
the form of a web service, an application installed on the user device =
and acting autonomously or the form of a natural person (resp. of an =
autonomous device) using an application to interact with other parties.
>=20
> Resource - a piece of data or web service
>       - controlled by a Resource Owner (RO),
>       - held and guarded by a Resource Server (RS) and
>       - serviced by the RS to a Client, if the Client provides a valid =
Authorization.
>=20
> Claim - a piece of data
>       - controlled by a Resource Owner (RO),
>       - held and guarded by the Grant Server (GS) and
>       - released by the GS to a Client as part of an Authorization.

The differentiation between =E2=80=9Cresource=E2=80=9D and =E2=80=9Cclaim=E2=
=80=9D is important since it separates items that get tied to an access =
token=E2=80=99s rights (=E2=80=9Cresources=E2=80=9D) with items that =
come back directly to the client without going through a separate API. =
The term =E2=80=9Cclaim=E2=80=9D is problematic here though because it =
is used broadly in the community to mean, roughly, =E2=80=9Ca statement =
about the end user=E2=80=9D. It=E2=80=99s therefore both too broad and =
too narrow in the wrong ways: a =E2=80=9Cclaim=E2=80=9D could come back =
as part of an API response, like the OIDC UserInfo Endpoint, and so =
it=E2=80=99s not a good name for this item. Even the OIDC =E2=80=9Cclaims=E2=
=80=9D query language defines several different targets for returning =
the =E2=80=9Cclaims=E2=80=9D about the user, and none of them match the =
method that GNAP is looking to use here. A =E2=80=9Cclaim=E2=80=9D is =
also generally understood in the identity community to be a statement =
about the user, and the data coming back directly to the client might be =
about the user or something else, especially as we look forward to =
extensions of GNAP.=20

I think we should focus on the separation of the delivery mechanism, but =
I=E2=80=99m not sure what good alternatives would be. Perhaps:

 - =E2=80=9Caccess right=E2=80=9D for things tied to the API/token
 - =E2=80=9Cdata response=E2=80=9D for things coming back directly to =
the client

I=E2=80=99m not particularly thrilled by these names, but I think recent =
list conversation shows that we need to get away from =E2=80=9Cclaim=E2=80=
=9D as it=E2=80=99s overloaded.

>=20
> Resource Owner (RO) - the party that
>       - controls a Resource,
>       - relies on the services the GS to manage access to that =
Resource,
>       - relies on the services of a RS to hold the Resource and guard =
access to that Resource,
>       - controls a Claim,
>       - relies on the services the GS to release that Claim to a =
Client.
>=20
> Resource Server (RS) - the party that=20
>       - holds a resource and guards access to that resource on behalf =
of the RO,
>       - services the Resource to the requesting Client, provided the =
Client presents a valid Authorization.
>       The RS is generally deployed as a web service.
>=20
> Grant Server (GS) - the party that=20
>       - manages access to a Resource on behalf of the RO,
>       - holds Claims and releases them when consented by the RO.
>       For each Resource access request, the GS might request the =
Consent of the RO and produce a corresponding Authorization that is =
given to the requesting Client.

I don=E2=80=99t like the shift from =E2=80=9CAuthorization Server=E2=80=9D=
 to =E2=80=9CGrant Server=E2=80=9D, and it especially doesn=E2=80=99t =
make sense in light of the definitions of =E2=80=9Cgrant=E2=80=9D and =
=E2=80=9Cauthorization=E2=80=9D above. I believe we should stick with =
=E2=80=9CAuthorization Server=E2=80=9D if it=E2=80=99s a single role. I =
would also propose that we have a separate term for the RO-interactive =
portion vs. the client-facing portion, as has been brought up in a few =
threads. Maybe these get different names entirely, or maybe they are =
=E2=80=9Caspects=E2=80=9D of the AS, I=E2=80=99m not sure.

>=20
> Consent - act of an RO :
>       - approving access to a Resource, means approval that a Resource =
he controls can be given to the Client by the RS.
>       - approving release of a Claim, means approval that a Claim he =
controls can be included by the GS in an Authorization to be returned to =
the Client.
>=20
> Grant - material form of an RO Consent. In order not to interact with =
the RO on each Resource access request, the GS might store the RO =
Consent in the form of a Grant for reuse.
>=20
> Authorization - externalized form of a Grant as known to the GS and =
the RS.
>       - The GS converts a Grant into an Authorization for use in a =
Resource access request.
>       - The RS evaluates an Authorization to decide on whether or not =
to release the Resource to the Client.
>=20
> Client - the party that provides the infrastructure used by a User to =
access a Resource. The client infrastructure is designed to:
>       - Receive the resource access request from the User,
>       - Interact with the RS to discover authorization requirements,
>       - Interact with the GS to obtain an Authorization to access the =
Resource,
>       - Interact with the RS to access the Resource on behalf of the =
User.

I think we should be clear that what we call the =E2=80=9Cclient=E2=80=9D =
is a piece of software operated by the user. It=E2=80=99s true that this =
software might have multiple parts of its =E2=80=9Cinfrastructure=E2=80=9D=
 but it=E2=80=99s always software.

>=20
> User - the party using the infrastructure of the Client to gain access =
to a Resource or a Claim.
>=20

In UMA, we call this the =E2=80=9CRequesting Party=E2=80=9D, or RqP. We =
might want to consider adopting this terminology here as well.

>=20
> Clarifications:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> User vs. RO :=20
>       - the User is the party using the infrastructure of the Client =
to gain access to a Resource or a Claim,
>       - the RO is the party controlling access to a Resource or =
controlling the release of a Claim.
> In many use cases, User and RO will be represented by the same party =
(see oAuth2), but GNAP exposes use cases where User and RO are =
represented by different parties.
>=20
> User-Agent :
> User and RO are parties that might be represented by a natural person =
or an autonomous device. In those cases, User (resp. RO) might need the =
help of an application to interact with other parties. Such an =
application is generally referred to as the "User-Agent".

The term =E2=80=9Cuser agent=E2=80=9D is often used to be equivalent to =
the web browser, and not the more general use here. I think we=E2=80=99re =
seeing more =E2=80=9Cagent=E2=80=9D terminology for helper applications =
like digital wallets and AI bots, which would seem to be covered under =
your definition here.

>=20
> Feedbacks are welcome.
>=20

Again, thanks so much for getting this going!

 =E2=80=94 Justin

> Best regards,
> /Francis
>=20
>=20
> On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha > wrote:
>=20
>=20
> On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt > wrote:
>=20
>=20
> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha > wrote:
>=20
> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt > wrote:
> FYI: I consider the release of claims to be an "authorization" as =
well.=20
> Great. Then it is included.=20
>=20
> I pivoted to using the term Grant rather than authorization so that it =
included both authorizing access to a resource, and authorizing the =
release of an identity claim.
>=20
> Perhaps we should not use the word "authorization"?=20
> Authorization is currently used to refer to the token issued by the =
GSand presented to the RS by the Client. I have no alternative word for =
now.
>=20
> "resource access" and "claim release"
>=20
> A Grant then covers both?
> Yes, Great! The word Grant fits best for both. I suggest adding this =
clarification to that dictionary.
>=20
> =20
>=20
> IE, the user authorizes the GS to release a DOB claim to a Client.
> I guess you mean the "RO" authorizes the GS to release a DOB!
>=20
> Yes, thanks for clarifying!
> =20
> /Dick
>=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=_8C0070B5-1405-47DD-B72C-687FC347EF37
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Up-front question to the Chairs, do we have a good place to =
capture this kind of thing? A non-spec document like this would be a =
good candidate for a wiki page. Do we have plans to set up a GitHub =
repository or similar? If so we could use the wiki capabilities there to =
at least get this stuff written down. Use cases would be good to capture =
there as well. 



Francis,

First, I want to thank you for putting the work in to getting =
some vocabulary down. This is not an easy task! Some notes on specific =
items inline below.

On Jul 21, 2020, at 8:33 PM, =
Francis Pouatcha <fpo@adorsys.de> wrote:

Hello =
Dick, Justin, Tom, Denis,

Below is a new version of the dictionary includings =
comments from different threads. Change log =
includes:
- avoided the expression "owns a =
resource" in favor of the expression "controls a =
resource"
- included the =
clarification "resource access" and "claim release"
- included a clarification User vs. RO
- =
tried to clarify the word User-Agent
- added the =
definition of a Claim

Terms
=3D=3D=3D=3D=3D

Party - represents a role in the GNAP protocol flow. A party =
can take the form of a web service, an application installed on the user =
device and acting autonomously or the form of a natural person (resp. of =
an autonomous device) using an application to interact with other =
parties.

Resource - a piece of data or web =
service
      - controlled by a Resource =
Owner (RO),
      - held and guarded by a =
Resource Server (RS) and
      - serviced =
by the RS to a Client, if the Client provides a valid Authorization.

Claim - a piece of data
  =
    - controlled by a Resource Owner (RO),
  =
    - held and guarded by the Grant Server (GS) and
      - released by the GS to a Client as part =
of an Authorization.
The differentiation between =E2=80=9Cresource=E2=80=
=9D and =E2=80=9Cclaim=E2=80=9D is important since it separates items =
that get tied to an access token=E2=80=99s rights (=E2=80=9Cresources=E2=80=
=9D) with items that come back directly to the client without going =
through a separate API. The term =E2=80=9Cclaim=E2=80=9D is problematic =
here though because it is used broadly in the community to mean, =
roughly, =E2=80=9Ca statement about the end user=E2=80=9D. It=E2=80=99s =
therefore both too broad and too narrow in the wrong ways: a =E2=80=9Cclai=
m=E2=80=9D could come back as part of an API response, like the OIDC =
UserInfo Endpoint, and so it=E2=80=99s not a good name for this item. =
Even the OIDC =E2=80=9Cclaims=E2=80=9D query language defines several =
different targets for returning the =E2=80=9Cclaims=E2=80=9D about the =
user, and none of them match the method that GNAP is looking to use =
here. A =E2=80=9Cclaim=E2=80=9D is also generally understood in the =
identity community to be a statement about the user, and the data coming =
back directly to the client might be about the user or something else, =
especially as we look forward to extensions of GNAP. 

I think we should focus on the separation of the =
delivery mechanism, but I=E2=80=99m not sure what good alternatives =
would be. Perhaps:

 - =E2=80=9Cac=
cess right=E2=80=9D for things tied to the API/token
 - =
=E2=80=9Cdata response=E2=80=9D for things coming back directly to the =
client

I=E2=80=99m not particularly =
thrilled by these names, but I think recent list conversation shows that =
we need to get away from =E2=80=9Cclaim=E2=80=9D as it=E2=80=99s =
overloaded.


Resource=
 Owner (RO) - the party that
      - =
controls a Resource,
      - relies on the =
services the GS to manage access to that Resource,
  =
    - relies on the services of a RS to hold the Resource and =
guard access to that Resource,
      - =
controls a Claim,
      - relies on the =
services the GS to release that Claim to a Client.

Resource Server (RS) - the party that 
  =
    - holds a resource and guards access to that resource on =
behalf of the RO,
      - services the =
Resource to the requesting Client, provided the Client presents a valid =
Authorization.
      The RS is generally =
deployed as a web service.

Grant Server =
(GS) - the party that 
  =
    - manages access to a Resource on behalf of the RO,
      - holds Claims and releases them when =
consented by the RO.
      For each =
Resource access request, the GS might request the Consent of the RO and =
produce a corresponding Authorization that is given to the requesting =
Client.

I don=E2=80=99t like the shift from =
=E2=80=9CAuthorization Server=E2=80=9D to =E2=80=9CGrant Server=E2=80=9D, =
and it especially doesn=E2=80=99t make sense in light of the definitions =
of =E2=80=9Cgrant=E2=80=9D and =E2=80=9Cauthorization=E2=80=9D above. I =
believe we should stick with =E2=80=9CAuthorization Server=E2=80=9D if =
it=E2=80=99s a single role. I would also propose that we have a separate =
term for the RO-interactive portion vs. the client-facing portion, as =
has been brought up in a few threads. Maybe these get different names =
entirely, or maybe they are =E2=80=9Caspects=E2=80=9D of the AS, I=E2=80=99=
m not sure.


Consent =
- act of an RO :
      - approving access =
to a Resource, means approval that a Resource he controls can be given =
to the Client by the RS.
      - approving =
release of a Claim, means approval that a Claim he controls can be =
included by the GS in an Authorization to be returned to the Client.

Grant - material form of an RO Consent. In =
order not to interact with the RO on each Resource access request, the =
GS might store the RO Consent in the form of a Grant for reuse.

Authorization - externalized form of a Grant =
as known to the GS and the RS.
      - The =
GS converts a Grant into an Authorization for use in a Resource access =
request.
      - The RS evaluates an =
Authorization to decide on whether or not to release the Resource to the =
Client.

Client - the party that provides =
the infrastructure used by a User to access a Resource. The client =
infrastructure is designed to:
      - =
Receive the resource access request from the User,
  =
    - Interact with the RS to discover authorization =
requirements,
      - Interact with the GS =
to obtain an Authorization to access the Resource,
  =
    - Interact with the RS to access the Resource on behalf of =
the User.

I think we should be clear that what we call the =
=E2=80=9Cclient=E2=80=9D is a piece of software operated by the user. =
It=E2=80=99s true that this software might have multiple parts of its =
=E2=80=9Cinfrastructure=E2=80=9D but it=E2=80=99s always =
software.


User - =
the party using the infrastructure of the Client to gain access to a =
Resource or a Claim.


In UMA, we call this the =E2=80=9CRequesting =
Party=E2=80=9D, or RqP. We might want to consider adopting this =
terminology here as well.


Clarifications:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

User vs. RO : 
  =
    - the User is the party using the infrastructure of the =
Client to gain access to a Resource or a Claim,
  =
    - the RO is the party controlling access to a Resource or =
controlling the release of a Claim.
In many use cases, =
User and RO will be represented by the same party (see oAuth2), but GNAP =
exposes use cases where User and RO are represented by different =
parties.

User-Agent :
User =
and RO are parties that might be represented by a natural person or an =
autonomous device. In those cases, User (resp. RO) might need the help =
of an application to interact with other parties. Such an application is =
generally referred to as the "User-Agent".

The term =E2=80=9Cuser agent=E2=80=9D is often =
used to be equivalent to the web browser, and not the more general use =
here. I think we=E2=80=99re seeing more =E2=80=9Cagent=E2=80=9D =
terminology for helper applications like digital wallets and AI bots, =
which would seem to be covered under your definition here.


Feedbacks are =
welcome.


Again, thanks so much for getting this =
going!

 =E2=80=94 =
Justin

Best =
regards,
/Francis


On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha =
<fpo@adorsys.de> =
wrote:


On Tue, Jul =
21, 2020 at 2:15 PM Dick Hardt <dick.hardt@gmail.com> wrote:


On Tue, Jul 21, 2020 at 11:09 AM =
Francis Pouatcha <fpo@adorsys.de> wrote:

On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt <dick.hardt@gmail.com> wrote:
FYI: I consider the release of claims to be an =
"authorization" as well. 
Great. =
Then it is included. 

I pivoted to using the =
term Grant rather than authorization so that it included both =
authorizing access to a resource, and authorizing the release of an =
identity claim.

Perhaps we should not use the word =
"authorization"? 
Authorization is currently used to refer to the token issued =
by the GSand presented to the RS by the Client. I have no alternative =
word for now.

"resource access" and "claim =
release"

A =
Grant then covers both?
Yes,=
 Great! The word Grant fits best for both. I suggest adding this =
clarification to that dictionary.

 

IE, the user authorizes =
the GS to release a DOB claim to a =
Client.
I guess you mean the =
"RO" authorizes the GS to release a =
DOB!

Yes, thanks for clarifying!
 
/Dick


-- 
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=_8C0070B5-1405-47DD-B72C-687FC347EF37--


From nobody Thu Jul 23 15: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 B8A483A07E1 for ; Thu, 23 Jul 2020 15:40:44 -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 efionCeCm4Ur for ; Thu, 23 Jul 2020 15:40:40 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 7AB553A07DF for ; Thu, 23 Jul 2020 15:40:39 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id z24so8048001ljn.8 for ; Thu, 23 Jul 2020 15: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=MpxDVPE2bI98126KaUVbNiC2zbkCGGnC7e3/RLZ8C1E=; b=ilgvbAnY3VdB8lWmD46htu820AOeq0j4IzHrij1Qt+bOmtmxJnD71J5vylXB9eVqFg JVRMKjoTCrWaOLkFKhr0vf+mr2NVPxdUN4+iCg0wHWwRS/K12os4Mr5jBQbY6piVjcXC y6e/zdm8UK9pKnDwPe0qeSTa6IFQcbzg5zJr8/EtWVnXQjoXjnBnGVOVNORLtly3XeTm 669cP9oh3MAV6wUCfd/imXoiT2eVaXbYE573m0Z+c4uAN1FMGdhQjiBr0PjFICpM2oUr LKkoKvquSqsZYeMDKqjeEEaEvKMSqQ48CGF3+i2zT5LzajmUv94p2Qb1yIFFi9h/lQso 1dDQ==
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=MpxDVPE2bI98126KaUVbNiC2zbkCGGnC7e3/RLZ8C1E=; b=mY3oxpDTcRKODPRlMNnEfZVzi7VZp8hndJQCPgoKpor0/aR++iFadWOR5MUNsaZ5lz f8kgfXwG29E75t7oWsOyFJrpLqAGp5rQT6mWGh2Jgcz32UOds9IpWKyui/EMYS0NSJ6q PuHIoCE/tqubCxYTXlfPNPGc3s0Hd+TIS9WruikKv/Ix5weFzisdQw+I7F1CYTXBFUzT J0eZXogQU8TXU0phXhlOAwRsK2x5ohrs3+73J/diF7kguWuvotoN9SHOWfaRQOirIfnT sM5FIPEQI+yVdCK14VxobycRDJbUXBz9tettCPTuMxM3k20g0qsm1bKZMHjJOeWmCSRs aa7w==
X-Gm-Message-State: AOAM531+F0H2pCcm+XZBdRHUpeNKSJJZKRo3sjzV0AFpHnWCXwc+u1wm rBvyMnJ8RrqhuP27RRdjSAZMzGvhS1/DihA7eYc=
X-Google-Smtp-Source: ABdhPJz+Svd2pPk+GtgNdMs3yX61d5nWQqxkT3byCDXEm3f/JXADPrLJ1qrqD9ZAzbYRX/Z+anQtxiwaaAN0HD2O180=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr3065709ljg.69.1595544037302; Thu, 23 Jul 2020 15:40:37 -0700 (PDT)
MIME-Version: 1.0
References:             <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>  
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 23 Jul 2020 15:40:00 -0700
Message-ID: 
To: Denis 
Cc: Francis Pouatcha , txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000091293605ab238b7c"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 23 Jul 2020 22:40:45 -0000

--00000000000091293605ab238b7c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis

I think it would be useful to take a step back and for you to describe your
use case. After that, we can explore the different ways that your use case
can be addressed.

Looking at your previous communication, it describes the solution, and the
justification, but it is not clear what use cases you are needing to solve.

/Dick


=E1=90=A7

On Wed, Jul 22, 2020 at 9:34 AM Denis  wrote:

> Hello Dick,
>
> I have identified the reason of the major difference between our two
> approaches.
>
> Access control may be performed using either ACLs (Access Control Lists)
> or Capabilities.
>
> *Note *: a capability identifies a resource and an allowed operation that
> can be performed on that resource.
>
> You are advocating a Capabilities approach while I am advocating an ACL
> approach.
>
> The capabilities approach allows the GS to trace every operation performe=
d
> by the users on any RS known by a GS.
> The management of these capabilities is made via the GS or at the GS by
> the various ROs. If the management is made
> via the GS, then a trusted communication channel needs to be established
> with every RO. If the management is made
> at the GS, then an authentication mechanism needs to be established with
> every RO. In the last case, the GS has the
> ability to know all the capabilities of the users whether they are used o=
r
> not. The less that can be said is that this model
> is not privacy friendly.
>
> With the ACL approach, a RO directly manages an ACL placed in front of
> each RS. The Access Control Decision Function
> (ADF) at the RS is able to keep track from prior decisions. The GS is
> kept ignorant of the content of these ACLs and only
> delivers to its clients attributes that are placed into access tokens.
> Such a model may be privacy friendly.
>
> Other comments are between the lines prefixed with [Denis].
>
>
> On Tue, Jul 21, 2020 at 11:26 AM Denis  wrote:
>
>> Hello Dick,
>>
>> Thank you for your feedback. Comments are between the lines.
>>
>> comments inserted ...
>>
>> On Tue, Jul 21, 2020 at 6:03 AM Denis  wrote:
>>
>>> Hello Dick,
>>>
>>> I duplicate the most important comment at the beginning of this email:
>>>
>>> You are considering using an access control model to build a workflow
>>> model.
>>>
>>> While it may be interesting to define a workflow model, this should be
>>> considered
>>> as a separate and different work item.
>>>
>>> See the other comments between the lines.
>>>
>>> On Mon, Jul 20, 2020 at 2:05 AM Denis  wrote:
>>>
>>>> Hi Dick,
>>>>
>>>> On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:
>>>>
>>>>> Hello Francis and Dick,
>>>>>
>>>>> The good news first: we are making some progress. We are now close to
>>>>> an agreement with steps (1) up to (3),
>>>>> ... except that the place where the user consent is captured is not
>>>>> mentioned/indicated.
>>>>>
>>>>
>>>> This major question which is currently left unanswered is where, when
>>>> and how the user consent is captured.
>>>>
>>>
>>> When is covered, per the sequence. How and where are out of scope of
>>> what I drafted.
>>>
>>> It is clear that the "User consent and choice" is not currently
>>> addressed in the draft, but it should.
>>> The support of the "User consent and choice" has strong implications no=
t
>>> only in the sequences of the exchanges
>>> but also by which entity it should be performed.
>>>
>> "consent" is in the latest draft 7 times.
>>
>> "Consent" is present 5 times. The User consent is different from the RO
>> consent (when/if it is required).
>>
>> The server acquires consent and authorization from the user *and/**or
>> resource owner **if required.*
>>
>> User consent is *often required* at the GS. GNAP enables a Client and
>> GS to negotiate the interaction mode for the GS to obtain consent.
>>
>> The GS *may *require explicit consent from the RO or User to provide
>> these to the Client.
>>
>> The User consent is not an alternative to the RO consent. So using
>> "and/or" in the first sentence is incorrect.
>>
>
> My language is sloppy there. Consent is always from the RO. The User may
> be the RO.
>
> [Denis] No. Once again: The "*User consent*" is different from what you
> call the "*RO consent*" (when/if it is required).
> The "RO consent" is not in fact a consent but the release of a capability
> to a client by one of the many R0s with which
> the GS has relationships.
>
> Since the second sentence is using the wording "often required" there is
>> no requirement to get the User consent.
>>
> User consent may not be required. There may not be a User. The consent ma=
y
> have been gathered previously.
>
> [Denis] In order to follow the privacy principles, a "User consent" phase
> is required. The User is a natural person.
> A Client is called either by a User (i.e. a natural person) or by a Clien=
t
> application.
>
> The second sentence does not consider the possibility to get the User
>> consent in a place different from the GS.
>>
> Agreed. But we do agree that the GS gets the consent, either directly fro=
m
> the RO, or from the Client (in your example).
>
> [Denis] No. I disagree. In an ACL based systems, the GS does not need to
> ask or receive any consent.
> The client selects the set of attributes that it wants to be inserted int=
o
> an access token.
> If the GS has the requested attributes, then it provides them, otherwise
> it returns an error to the Client.
>
> IMO, the User consent should be captured by the Client, i.e. not by the
>> GS.
>> The information used to obtain the User consent should be standardized
>> (... and it can be standardized).
>>
>> I think the abstract sequence as proposed by Francis is a great addition=
,
>> and would clarify where consent is in the sequence.
>>
>> The current sketch does not illustrate the place the User Consent is
>> captured, in particular by the Client.
>>
> It is an abstraction. The GS receives the consent. How consent is gathere=
d
> is a detail that is dependent on the use case.
>
> [Denis] I really wonder whether there is really a "consent" to be receive=
d
> by the GS in both cases (i.e. ACLs or Capabilities).
>
>    - For ACLs, the consent needs to be done by the Client.
>    - For Capabilities, the current description is not clear since the
>    inputs and the outputs for this "consent" phase
>    are not currently described in the draft.
>
>
>
>>
>>
>>> Another important point to consider and to explain is related to the
>>>> assurances that the user can obtain about
>>>> the respect of his choices. This point is currently left unanswered in
>>>> draft-hardt-xauth-protocol-13.
>>>>
>>> This point is equally important: such assurance can only be obtained if
>>> the access token returned to the client
>>> is not considered to be opaque to the client. This is a necessary
>>> condition but not the single condition:
>>> the Client must also be in a position to capture/memorize the "User
>>> consent and choice" of the user in order to be able
>>> to verify it afterwards using the content of the access token(s).
>>>
>>
>> We disagree on this being a requirement for all use cases. It may be in
>> some.
>>
>> OK. Then this means that there will be no sentence in the draft such as =
:
>> "access tokens returned to the client are not considered to be opaque to
>> the client".
>>
>
> For OAuth use cases, which GNAP supports, the access token is opaque to
> the Client. As you have noted, there are use cases where the access token
> is NOT opaque.
>
> [Denis] Wait a second. There is no requirement to support all OAuth use
> cases.
> I believe that there is a requirement to support OAuth 2.0 ASs, while the
> clients may be different
> and hence GNAP clients do not need to inherit of the limitations of OAuth
> 2.0 clients.
>
>
>
>>
>>
>>>
>>>> If a RO needs to be involved and since a RO is directly associated wit=
h
>>>>> a RS, why can't it be directly queried
>>>>> by the appropriate RS after step (2) or later on ?
>>>>>
>>>>
>>>> Good question. Perhaps you can expand on a use case where that would b=
e
>>>> useful?
>>>>
>>>> Before I expand, would you be able to explain first under which
>>>> circumstances a RO needs to be queried by a GS ?
>>>> How can the GS identify which RO to query ?
>>>>
>>> If the User is the RO, then the GS knows who to query.
>>>
>>> I still have difficulties to understand what you mean here.
>>> How could a GS know that "the User is the RO" ?  If "the User is the
>>> RO", why does the GS needs to query the User ?
>>>
>>
>> To get consent?
>>
>> To get a "RO consent" to himself ???
>>
>
> The GS needs consent from the RO. If the RO is the User, then consent fro=
m
> the RO is equivalent to consent from the User.
>
> [Denis] See above.
>
>
>
>>
>>
>>> If the RO is a separate entity, then the GS knows the RO from the RS
>>> being queried.
>>>
>>>  ... and this gives the ability for the GS to log/trace all the RSs
>>> accessed by a given User and at which instant of time the access token =
has
>>> been granted.
>>>
>>> An example is a user would like access to an enterprise asset where a
>>> workflow is started to gain approval, and an administrator or manager
>>> provides consent.
>>>
>>> Thanks for this example. I finally understand what you have in mind: yo=
u
>>> are considering using an access control model to build a *workflow
>>> model*.
>>> While it may be interesting to define a workflow model, this should be
>>> considered as a *separate and different work item*.
>>>
>>
>> The actual workflow is out of scope.
>>
>> I am glad you agree with this. But this means that your example was not
>> appropriate to illustrate your point.
>>
>
> It illustrates a use case where the RO and User are not the same party,
> and why the GS needs to query the RO, which was your question if I
> understood it correctly.
>
> [Denis] Since the inputs and the outputs for this "RO consent" phase are
> not currently described in the draft, the point is still unsolved.
>
> As soon as there is a RO consent obtained at the GS, the major problem is
>> that the GS is able to act as Big Brother.
>> If a RO consent is performed at the RS, then the GS will not know who th=
e
>> RS is: it is then unable to act as Big Brother,
>> even if it would enjoy to play that role.
>>
> In an enterprise use case, the GS's knowledge of who is accessing which R=
S
> is a feature.
>
> Do you mean that it is "normal" in an enterprise that a single point of
> control is able to trace all their actions ?
> From a security point of view, a single point of failure will have
> dramatic consequences.
>
> In your use cases, it seems that the RO is the User.
>
> I do hope that you have finally understood that, in my use case, the RO i=
s
> **not** the User.
>
> The GS knows the User is wanting to let a Client access something. If the
> access token is generic, and could be presented to any RS that provides a
> standardized function,
> then the GS does not know which RS is being accessed by a Client for the
> User. This seems to meet your privacy objectives. If not, what is wrong?
>
> For security reasons, an access token needs to be targeted (which does no=
t
> necessarily mean that an identifier of the RS shall be included into the
> access token).
>
> if the admin grants access, then the access granted to the client changes=
.
>>
>>> The model you propose may be suited for an enterprise environment but i=
s
>>> not scalable over the Internet.
>>>
>> It is one of the use cases we are working to address.
>>
>>> What is needed is an access control model usable over the Internet with
>>> millions of RSs and thousands of ASs/GSs.
>>>
>> I agree the model should also scale to internet scale.
>>
>> Fine. Another point on which we are in agreement.
>>
>> The model can scale to the Internet based on the following assumptions:
>>
>> The flow starts with the steps (1) to (4) as illustrated by Francis, i.e=
.
>> the flow starts with a contact with a RS.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS |
>>  |RO | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Request     =
|
>>    |   |-------->|       |      |      |   |         |(2) Service Intent
>> |   |         |------>|      |      |   |         |(3) AuthZ Challenge  =
|
>> |         |<------|      |      |   |         |(4) AuthZ Request    |   =
|
>>       |------------->|      |*
>>
>> The GS/AS does not need to have any prior relationship with ROs and/or
>> RSs.
>>
>> Furthermore, it is possible to prevent the GS to act as Big Brother when
>> the identity of the RS is not disclosed to the GS.
>>
>
> What happens after (4) above?
>
> [Denis] The key point is that we first need to agree on the first four
> exchanges. Do we ?
>
> The fifth exchange is different whether ACLs or Capabilities are being
> used.
>
>
>
>> Which information is supposed to be presented to the RO ?
>>>>> Which information is supposed to be returned by the RO ?
>>>>>
>>>>
>>>> Just like how the user authenticates to an AS, how the AS and RO
>>>> communicate is out of scope.
>>>>
>>>> At the moment, the usefulness of a dialogue between a GS and a RO has
>>>> not been explained, nor demonstrated.
>>>> The question is about the functionality of that dialogue in terms of
>>>> input and output information (and not about
>>>> the design of a protocol or of a user interface). Anyway, AFAIU a
>>>> dialogue between a GS and a RO is optional.
>>>>
>>>
>>> See enterprise example above.
>>>
>>> It is not an access control example, but a workflow example.
>>>
>>> Access  control has been defined a long time ago and the last edition o=
f
>>> the model has been confirmed in year 1996: ISO/IEC 10181-3: 1996.
>>> "Information technology =E2=80=94 Open Systems Interconnection =E2=80=
=94 Security
>>> frameworks for open systems: Access control framework =E2=80=94 Part 3"=
.
>>>
>>> Two major functions have ben defined: an Access Control Enforcement Fun=
ction
>>> (AEF) and an Access Control Decision Function(ADF).
>>>
>>> Access Control Enforcement Function (AEF):
>>> A specialized function that is part of the access path between an
>>> initiator and a target on each access request and enforces the decision
>>> made by the ADF.
>>> Access Control Decision Function (ADF) :
>>> A specialized function that makes access control decisions by applying
>>> access control policy rules to an access request, ADI (of initiators,
>>> targets, access requests,
>>> or that retained from prior decisions), and the context in which the
>>> access request is made.
>>>
>>> The role of the RO is to define the "access control policy rules" at
>>> the RS according to the context in which the access request is made.
>>>
>> I'm pretty familiar with access control systems. :)
>>
>> I would say that the access control is happening at the RS. The client
>> presents a token when accessing an API.
>> The RS uses the token, and any policy required, to make an access
>> decision.
>>
>> Fine. It looks like we are in agreement. Unfortunately, this is not the
>> case just below.
>>
>> Here is flow:
>>
>> 1) The Client requests access to an RS from the GS.
>>
>> No. We are no more in agreement. This is different from the flow drawn b=
y
>> Francis.
>>
> My bad. Typo. I meant RO.
>
>
>> 2) The GS queries the RS if access should be granted.
>>
>>  No. The GS should not be forced to have a flow with the RS.
>>
> Same mistake as above, I meant RO.
>
>> 3) If access is granted, the GS creates an access token representing the
>> granted access, and returns it to the Client.
>>
>> This model is by no way conformant to ISO/IEC 10181-3: 1996
>>
> I'm unclear on why, or why it is even relevant.
>
>> 4) The Client presents the access token to the RS to show it has been
>> granted access.
>>
>> No. The client presents a token when accessing an API. The RS uses the
>> token, and any policy required, to make an access decision.
>> The token never contains an information like "Please grant an access to
>> the holder of this token".
>>
> Let me provide more clarity in the sentence:
>
> The Client presents the access token to the RS, to show the RS that the
> Client has been granted access to a resource at the RS by the GS.
>
> [Denis] This time, please consider both the ACLs approach and the
> Capabilities approach.
>
>
>
>> A couple advantages of this model:
>> - that the RS does not need to know much, if anything about the Client.
>> - the access token MAY be self contained so that the Client does not nee=
d
>> to query the GS on each access.
>>
>> There are so many disadvantages that I will not list them.
>>
> Darn: I clearly was not firing on all cylinders when I typed this out. Le=
t
> me correct:
>
> - the access token MAY be self contained so that the RS does not need to
> query the GS on each access to the RS by the Client.
>
> [Denis] A few comments in the case of a capability approach:
>
> - for each GS, the RS needs to locally manage which operation(s) is/are
> allowed to it.
>
> - the GS needs to establish a trusted communication channel or an
> authentication mechanism with each RO
>    (which is associated with an explicit RS identifier).
>
> - the GS could play the role of the RO and hence be in a position to issu=
e
> any capability for any RS (without a "RO consent").
>
>    The target of an attack will clearly be the GS.
>
> I would not say that GNAP is an access control protocol, as how the RS
>> uses the token to determine access is out of scope.
>>
>> This is where we have a major discrepancy: how the RS uses the token to
>> determine access is *within* the scope.
>>
> [Denis] Do you agree or disagree ?
>
> The RS announces in advance to the client what it needs so that the clien=
t
>> can perform a a given operation and if the client supplies the requested
>> attributes
>> obtained from some GS/AS(s) trusted by the RS, then access to that RS is
>> granted by the RS. If the RS cannot perform the requested operation on i=
ts
>> own,
>> then the client should be informed about some requested attributes that
>> need to be obtained from some GS/AS(s) trusted by the next RS(s) in a ch=
ain
>> for subsequent operations. The User consent should also be obtained
>> before performing the chaining operation.
>>
>> Chaining operations between RSs over the Internet is within the scope
>> (... and may be achieved).
>>
> [Denis] Do you agree or disagree ?
>
> Denis
>
>
>>>
>>>> For many use cases, the User is the RO, and the interaction is through
>>>> a user interface, not a machine protocol.
>>>>
>>>> Wait a second. You wrote "the User is the RO". The User is attempting
>>>> to make an access to a RS by using a Client.
>>>> *That* User is not the RO of the RS.
>>>>
>>> The user being the RO is the initial use case for OAuth.
>>>
>>> OAuth 2.0 is no more mandating such a case.
>>>
>>
>> I don't know what you mean by that.
>>
>> Copy and paste from draft-ietf-oauth-security-topics:
>>
>> OAuth initially assumed a static relationship between client,
>> authorization server and resource servers.  (...)
>> With the increasing adoption of OAuth, this simple model dissolved and,
>> in several scenarios, was replaced
>> by a dynamic establishment of the relationship between clients on one
>> side and the authorization and
>> resource servers of a particular deployment on the other side.
>>
>> This way, the same client could be used to access services of different
>> providers (in case of standard APIs,
>> such as e-mail or OpenID Connect) or serve as a frontend to a particular
>> tenant in a multi-tenancy environment.
>>
>>
> This sentence does not mention the RO or the Client. I'm confused what we
> are talking about
>
>>
>>
>>> A client application would like access to the user's photos at a photo
>>> sharing site. The resource is the user's photos. The user is the owner =
of
>>> that resource.
>>>
>>> If the user has already pre established the access control policy rules
>>> so that it can access to his own photos
>>> then he does not need to grant in real time any additional authorizatio=
n.
>>>
>> I don't understand what you are trying to say. The photo sharing example
>> was a driving use case for the creation of OAuth.
>>
>> We would need to revisit the original scenario and consider if it can be
>> addressed in a different way than the original way.
>>
> The use case is the same. Is there a different solution you are proposing=
?
>
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--00000000000091293605ab238b7c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis

I think it would be useful to =
take a step back and for you to describe your use case. After that, we can =
explore the different ways that your use case can be addressed.=C2=A0
=


Looking at your previous communication, it describes th=
e solution, and the justification, but it is not clear what use cases you a=
re needing to solve.

/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=3D8f8501c4-4617-432e-836a-956c604e3e22">=E1=90=A7

On Wed, Jul 22, 2020 at 9:34 AM =
Denis <denis.ietf@free.fr> =
wrote:

 =20
   =20
 =20
  

    
Hello Dick,

    


    

    
I have identified the reason of the
      major difference between our two approaches.

    


    

    
Access control may be performed using
      either ACLs (Access Control Lists) or Capabilities.

    


    

    
Note : a capability identifies
      a resource and an allowed operation that can be performed on that
      resource.

    

    


    

    
You are advocating a Capabilities
      approach while I am advocating an ACL approach.

    
The capabilities approach allows the GS to trace every operation
      performed by the users on any RS known by a GS.

      The management of these capabilities is made via the GS or at the
      GS by the various ROs. If the management is made 

      via the GS, then a trusted communication channel needs to be
      established with every RO. If the management is made 

      at the GS, then an authentication mechanism needs to be
      established with every RO. In the last case, the GS has the 

      ability to know all the capabilities of the users whether they are
      used or not. The less that can be said is that this model 

      is not privacy friendly.

    
With the ACL approach, a RO directly manages an ACL placed in
      front of each RS. The Acces=
s Control Decision
        Function 

          (ADF) at the
        RS is able to keep track from prior decisions. The GS is
      kept ignorant of the content of these ACLs and only 

      delivers to its clients attributes that are placed into access
      tokens. Such a model may be privacy friendly.

    
Other comments are between the lines prefixed with [Denis].

    

     =20
      

        


          

            
On Tue, Jul 21, 2020 at
              11:26 AM Denis <denis.ietf@free.fr> wrote:

            

            

              

                
Hello Dick,

                


                

                
 Thank you for your feedback. Comments are between
                  the lines.

                


                

                

                  

                    
comments inserted ...=C2=A0

                    

                    

                      
On Tue, Jul 21,
                        2020 at 6:03 AM Denis <denis.ietf@free.fr>
                        wrote:

                      

                      

                        

                          
Hello Dick,

                          


                          

                          
I duplicate the most important comment at
                            the beginning of this email:

                          

                            
You are considering using an access
                              control model to build a workflow
                              model.

                               

                              While it may be interesting to define a
                              workflow model, this should be considered
                              

                              as a separate and different work item.

                          

                          
See the other comments between the lines.
                          

                          


                          

                          

                            
On Mon, Jul 20, 2020 at 2:05
                              AM Denis <denis.ietf@free.fr>
                              wrote:

                              

                                

                                  

                                    
Hi Dick,

                                    


                                    

                                    

                                      
On Fri, Jul 17,
                                        2020 at 9:21 AM Denis <denis.ietf@free.fr>
                                        wrote:

                                        

                                          

                                            

                                              
Hello Francis and
                                                Dick,

                                              


                                              

                                              
The good news first:
                                                we are making some
                                                progress. We are now
                                                close to an agreement
                                                with steps (1) up to
                                                (3), 

                                                ... except that the
                                                place where the user
                                                consent is captured is
                                                not mentioned/indicated.
                                            

                                          

                                        

                                      

                                    

                                    

                                    This major question which is
                                    currently left unanswered is where,
                                    when and how the user consent is
                                    captured.

                                  

                                

                                


                                

                                
When is covered, per the sequence.
                                  How and where are out of scope of what
                                  I drafted. 

                                

                              

                            

                          

                          
It is clear that the "User consent and
                            choice" is not currently addressed in the
                            draft, but it should.

                            The support of the "User consent and choic=
e"
                            has strong implications not only in the
                            sequences of the exchanges 

                            but also by which entity it should be
                            performed.

                        

                      

                      
"consent" is in the latest draft 7 tim=
es. 

                      

                    

                  

                

                
"Consent" is present 5 times. The User consent=
 is
                  different from the RO consent (when/if it is
                  required). 

                

                

                  
The server acquires consent and authorization from
                    the user and/or resource owner if
                      required.

                  

                  
User consent is often required at the GS.
                    GNAP enables a Client and=C2=A0 GS to negotiate the
                    interaction mode for the GS to obtain consent.

                  

                  
 The GS may require explicit consent from
                    the RO or User to provide these to the Client.

                  

                

                
The User consent is not an alternative to the RO
                  consent. So using "and/or" in the first sentenc=
e is
                  incorrect.

              

            

            


            

            
My language is sloppy there. Consent is always from the
              RO. The User may be the RO.

          

        

      

    

    
[Denis] No. Once again: The "User consent" is diffe=
rent
      from what you call the "RO consent" (when/if it is
      required). 

      The "RO consent" is not in fact a consent but the release o=
f a
      capability to a client by one of the many R0s with which 

      the GS has relationships. 

    

    

      

        

          

            

              

                
Since the second sentence is using the wording "oft=
en
                  required" there is no requirement to get the User
                  consent.

                

              

            

            
User consent may not be required. There may not be a
              User. The consent may have been gathered previously.

          

        

      

    

    
[Denis] In order to follow the privacy principles, a "User
      consent" phase is required. The User is a natural person.

      A Client is called either by a User (i.e. a natural person) or by
      a Client application. 

    

    

      

        

          

            

              

                
 

                
The second sentence does not consider the possibility
                  to get the User consent in a place different from the
                  GS.

              

            

            
Agreed. But we do agree that the GS gets the consent,
              either directly from the RO, or from the Client (in your
              example).

          

        

      

    

    
[Denis] No. I disagree. In an ACL based systems, the GS does not
      need to ask or receive any consent.

      The client selects the set of attributes that it wants to be
      inserted into an access token.

      If the GS has the requested attributes, then it provides them,
      otherwise it returns an error to the Client.

    

      

        

          

            

              

                
IMO, the User consent should be captured by the
                  Client, i.e. not by the GS. 

                  The information used to obtain the User consent should
                  be standardized (... and it can be standardized).

                

                

                  

                    
I think the abstract
                      sequence as proposed by Francis is a great
                      addition, and would clarify where consent is in
                      the sequence. 

                  

                

                
The current sketch does not illustrate the place the
                  User Consent is captured, in particular by the Client.
              

            

            
It is an abstraction. The GS receives the consent. How
              consent is gathered is a detail that is dependent on the
              use case.

          

        

      

    

    
[Denis] I really wonder whether there is really a "consent"=
; to be
      received by the GS in both cases (i.e. ACLs or Capabilities).

    

    
    
      
  • For ACLs, the consent needs to be done by the Client.
    • 
      
  • For Capabilities, the current description is not clear since
        the inputs and the outputs for this "consent" phase
    
        are not currently described in the draft.
    • 
    

    

      

        

          

            
=C2=A0

            

              

                

                  

                    

                      
=C2=A0

                      

                        

                          

                            

                              

                                

                                  
 Another important point to
                                    consider and to explain is related
                                    to the assurances that the user can
                                    obtain about 

                                    the respect of his choices. This
                                    point is currently left unanswered
                                    in draft-hardt-xauth-protocol-13.

                                  

                                

                              

                            

                          

                          
This point is equally important: such
                            assurance can only be obtained if the access
                            token returned to the client 

                            is not considered to be opaque to the
                            client. This is a necessary condition but
                            not the single condition: 

                            the Client must also be in a position to
                            capture/memorize the "User consent and
                            choice" of the user in order to be able 
                            to verify it afterwards using the content of
                            the access token(s).

                        

                      

                      


                      

                      
We disagree on this being a requirement for
                        all use cases. It may be in some. 

                      

                    

                  

                

                
OK. Then this means that there will be no sentence in
                  the draft such as :

                  "access tokens returned to the client are not
                  considered to be opaque to the client".

              

            

            


            

            
For OAuth use cases, which GNAP supports, the access
              token is opaque to the Client. As you have noted, there
              are use cases where the access token is NOT opaque.

          

        

      

    

    
[Denis] Wait a second. There is no requirement to support all
      OAuth use cases. 

      I believe that there is a requirement to support OAuth 2.0 ASs,
      while the clients may be different 

      and hence GNAP clients do not need to inherit of the limitations
      of OAuth 2.0 clients.

    

      

        

          

            
=C2=A0

            

              

                

                  

                    

                      
=C2=A0

                      

                        

                          

                            

                              

                                

                                  
 

                                    

                                      

                                        

                                          

                                            

                                              
If a RO needs to be
                                                involved and since a RO
                                                is directly associated
                                                with a RS, why can't it
                                                be directly queried 

                                                by the appropriate RS
                                                after step (2) or later
                                                on ?

                                            

                                          

                                          


                                          

                                          
Good question. Perhaps
                                            you can expand on a use case
                                            where that would be useful?
                                        

                                      

                                    

                                    
Before I expand, would you be
                                      able to explain first under which
                                      circumstances a RO needs to be
                                      queried by a GS ?

                                      How can the GS identify which RO
                                      to query ?

                                  

                                

                                
If the User is the RO, then the GS
                                  knows who to query. 

                                

                              

                            

                          

                          
I still have difficulties to understand
                            what you mean here. 

                            How could a GS know that "the User is the
                            RO" ?=C2=A0 If "the User is the RO&qu=
ot;, why does the
                            GS needs to query the User ? 

                          

                        

                      

                      


                      

                      
To get consent?

                    

                  

                

                
To get a "RO consent" to himself ???

              

            

            


            

            
The GS needs consent from the RO. If the RO is the
              User, then consent from the RO is equivalent to consent
              from the User.

          

        

      

    

    
[Denis] See above.

    

    

      

        

          

            
=C2=A0

            

            

              

                

                  

                    

                      
=C2=A0

                      

                        

                          

                            

                              

                                
If the RO is a separate entity,
                                  then the GS knows the RO from the RS
                                  being queried. 

                                

                              

                            

                          

                          
=C2=A0... and this gives the ability for the G=
S
                            to log/trace all the RSs accessed by a given
                            User and at which instant of time the access
                            token has been granted.

                          

                            

                              

                                
An example=C2=A0is a user would like
                                  access to an enterprise asset where a
                                  workflow is started to gain approval,
                                  and an administrator or manager
                                  provides consent.

                              

                            

                          

                          
Thanks for this example. I finally
                            understand what you have in mind: you are
                            considering using an access control model to
                            build a workflow model. 

                            While it may be interesting to define a
                            workflow model, this should be considered as
                            a separate and different work item.

                        

                      

                      


                      

                      
The actual workflow is out of scope. 

                    

                  

                

                
I am glad you agree with this. But this means that
                  your example was not appropriate to illustrate your
                  point.

                

              

            

            


            

            
It illustrates a use case where the RO and User are not
              the same party, and why the GS needs to query the RO,
              which was your question if I understood it correctly.

          

        

      

    

    
[Denis] Since the inputs and the outputs for this "RO consent&q=
uot;
      phase are not currently described in the draft, the point is still
      unsolved.

    

    

      

        

          

            

              

                
 As soon as there is a RO consent obtained at the GS,
                  the major problem is that the GS is able to act as Big
                  Brother.

                  If a RO consent is performed at the RS, then the GS
                  will not know who the RS is: it is then unable to act
                  as Big Brother, 

                  even if it would enjoy to play that role.

              

            

            
In an enterprise use case, the GS's knowledge of who i=
s
              accessing which RS is a feature.

          

        

      

    

    
Do you mean that it is "normal" in an enterprise that a si=
ngle
      point of control is able to trace all their actions ? 

      From a security point of view, a single point of failure will have
      dramatic consequences.

    

      

        

          

            
In your use cases, it seems that the RO is the User. 
          

        

      

    

    
I do hope that you have finally understood that, in my use case,
      the RO is **not** the User.

    

      

        

          

            
The GS knows the User is wanting to let a Client access
              something. If the access token is generic, and could be
              presented to any RS that provides a standardized function,
              

              then the GS does not know which RS is being accessed by a
              Client for the User. This seems to meet your privacy
              objectives. If not, what is wrong?

          

        

      

    

    
For security reasons, an access token needs to be targeted (which
      does not necessarily mean that an identifier of the RS shall be
      included into the access token).

    

    

      

        

          

            

              

                

                  

                    

                      
if the admin grants access, then the access
                        granted to the client changes. 

                      

                      

                        

                          
 

                          
The model you propose may be suited for an
                            enterprise environment but is not scalable
                            over the Internet.

                        

                      

                      
It is one of the use cases we are working to
                        address. 

                      

                      

                        

                          
 What is needed is an access control model
                            usable over the Internet with millions of
                            RSs and thousands of ASs/GSs.=C2=A0 

                          

                        

                      

                      
I agree the model should also scale to
                        internet scale. 

                      

                    

                  

                

                
Fine. Another point on which we are in agreement. 

                

                
The model can scale to the Internet based on the
                  following assumptions:

                

                  
The flow starts with the steps (1) to (4) as
                    illustrated by Francis, i.e. the flow starts with a
                    contact with a RS.

                

                
+----+
                      =C2=A0+------+ =C2=A0+---+ =C2=A0+---+ =C2=A0+---+
                      |User| =C2=A0|Client| =C2=A0|RS | =C2=A0|GS | =C2=A0|=
RO |

                      +----+ =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 |(2) Service Int=
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 |(3) AuthZ Chall=
enge =C2=A0|

                      =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =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) AuthZ Reque=
st =C2=A0 =C2=A0|

                      =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |-------------&g=
t;| =C2=A0 =C2=A0 =C2=A0|

                
The GS/AS does not need to have any prior
                  relationship with ROs and/or RSs.

                
Furthermore, it is possible to prevent the GS to act
                  as Big Brother when the identity of the RS is not
                  disclosed to the GS.

                

              

            

            


            

            
What happens after (4) above? 

            

          

        

      

    

    
[Denis] The key point is that we first need to agree on the first
      four exchanges. Do we ?

    

    
The fifth exchange is different whether ACLs or Capabilities are
      being used.

    

    

      

        

          

            
=C2=A0

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              
Which information is
                                                supposed to be presented
                                                to the RO ?

                                                Which information is
                                                supposed to be returned
                                                by the RO ?

                                            

                                          

                                          


                                          

                                          
Just like how the user
                                            authenticates to an AS, how
                                            the AS and RO communicate is
                                            out of scope.

                                          

                                        

                                      

                                    

                                    
At the moment, the usefulness of
                                      a dialogue between a GS and a RO
                                      has not been explained, nor
                                      demonstrated.

                                      The question is about the
                                      functionality of that dialogue in
                                      terms of input and output
                                      information (and not about 

                                      the design of a protocol or of a
                                      user interface). Anyway, AFAIU a
                                      dialogue between a GS and a RO is
                                      optional.

                                    

                                  

                                

                                


                                

                                
See enterprise example above.

                              

                            

                          

                          
It is not an access control example, but a
                            workflow example.

                          
Access=C2=A0 control has b=
een
                            defined a long time ago and the last edition
                            of the model has been confirmed in year
                            1996: ISO/IEC=C2=A010181-3:
                                1996.

                            "Infor=
mation
                              technology=C2=A0=E2=80=94 Open Systems
                              Interconnection=C2=A0=E2=80=94 Security frame=
works for
                              open systems: Access control framework=C2=A0=
=E2=80=94
                              Part=C2=A03".

                          
Two major
                              functions have ben defined: an Acce=
ss Control Enforcem=
ent
                                Function (AEF) and an <=
/span>Access Control
                              Decision Function(A=
DF).

                          

                            
Access =
Control Enforcement
                                Function (AEF):

                                A specialized function that is part of
                                the access path between an initiator and
                                a target on each access request and
                                enforces the decision made by the ADF.

                            Acces=
s Control
                              Decision Function (=
ADF) :

                            A
                              specialized function that makes access
                              control decisions by applying access
                              control policy rules to an access request,
                              ADI (of initiators, targets, access
                              requests, 

                            or that
                              retained from prior decisions), and the
                              context in which the access request is
                              made.

                          
The role of the RO is to define the "access control
                              policy rules" at the RS according to the=
 context in
                                which the access request is made.

                        

                      

                      
I'm pretty familiar with access control
                        systems. :)=C2=A0

                      


                      

                      
I would say that the access control is
                        happening at the RS. The client presents a token
                        when accessing an API. 

                        The RS uses the token, and any policy required,
                        to make an access decision.

                    

                  

                

                
Fine. It looks like we are in agreement.
                  Unfortunately, this is not the case just below.

                

                

                  

                    

                      
Here is flow:

                      


                      

                      
1) The Client requests access to an RS from
                        the GS. 

                      

                    

                  

                

                
No. We are no more in agreement. This is different
                  from the flow drawn by Francis.

              

            

            
My bad. Typo. I meant RO.

            
=C2=A0

            

              

                

                  

                    

                      
2) The GS queries the RS if access should be
                        granted. 

                      

                    

                  

                

                
=C2=A0No. The GS should not be forced to have a flow wit=
h
                  the RS.

              

            

            
Same mistake as above, I meant RO.=C2=A0

            

              

                
 

                

                  

                    

                      
3) If access is granted, the GS creates an
                        access token representing the granted access,
                        and returns it to the Client. 

                      

                    

                  

                

                
This model is by no way conformant to ISO/IEC=C2=A010181-3: 1996 

                    

              

            

            
I'm unclear on why, or why it is even relevant. 

            

            

              

                
 

                

                  

                    

                      
4) The Client presents the access token to
                        the RS to show it has been granted access. 

                      

                    

                  

                

                
No. The client presents a token when accessing an
                  API. The RS uses the token, and any policy required,
                  to make an access decision.

                  The token never contains an information like "Please
                  grant an access to the holder of this token".

              

            

            
Let me provide more clarity in the sentence:

            


            

            
The Client presents the access token to the RS, to show
              the RS that the Client has been granted access to a
              resource at the RS by the GS.

          

        

      

    

    
[Denis] This time, please consider both the ACLs approach and the
      Capabilities approach.

    

      

        

          

            
=C2=A0

            

              

                

                  

                    

                      
A couple advantages of this model:

                      
- that the RS does not need to know much, if
                        anything about the Client.=C2=A0

                      
- the access token MAY be self contained so
                        that the Client does not need to query the GS on
                        each access. 

                      

                    

                  

                

                
There are so many disadvantages that I will not list
                  them.

              

            

            
Darn: I clearly was not firing on all cylinders when I
              typed this out. Let me correct:

            


            

            

              

                

                  

                    
- the access token MAY be self contained so
                      that the RS does not need to query the GS on each
                      access to the RS by the Client.

                  

                

              

            

          

        

      

    

    
[Denis] A few comments in the case of a capability approach:

    

      
- for each GS, the RS needs to locally manage which
        operation(s) is/are allowed to it.

        

        - the GS needs to establish a trusted communication channel or
        an authentication mechanism with each RO 

        =C2=A0=C2=A0 (which is associated with an explicit RS identifier). =


      

      
- the GS could play the role of the RO and hence be in a
        position to issue any capability for any RS (without a "RO
        consent"). 

        

        =C2=A0=C2=A0 The target of an attack will clearly be the GS.

      

    

    

      

        

          

            

              

                

                  

                    

                      
I would not say that GNAP is an access
                        control protocol, as how the RS uses the token
                        to determine access is out of scope.

                    

                  

                

                
This is where we have a major
                      discrepancy: how the RS uses the
                  token to determine access is *within* the scope.

              

            

          

        

      

    

    [Denis] Do you agree or disagree ?

    

      

        

          

            

              

                
The RS announces in advance to the client what it
                  needs so that the client can perform a a given
                  operation and if the client supplies the requested
                  attributes 

                  obtained from some GS/AS(s) trusted by the RS, then
                  access to that RS is granted by the RS. If the RS
                  cannot perform the requested operation on its own, 

                  then the client should be informed about some
                  requested attributes that need to be obtained from
                  some GS/AS(s) trusted by the next RS(s) in a chain

                  for subsequent operations. The User consent should
                  also be obtained before performing the chaining
                  operation.

                

                
Chaining operations between RSs over the Internet is
                  within the scope (... and may be achieved).

              

            

          

        

      

    

    
[Denis] Do you agree or disagree ?

    
Denis

    

    

      

        

          

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                
=C2=A0

                                

                                  

                                    

                                      

                                        

                                          
For many use cases, the
                                            User is the RO, and the
                                            interaction is through a
                                            user interface, not a
                                            machine protocol. 

                                          

                                        

                                      

                                    

                                    
Wait a second. You wrote "the
                                      User is the RO". The User is
                                      attempting to make an access to a
                                      RS by using a Client. 

                                      That User is not the RO of
                                      the RS.=C2=A0=C2=A0 

                                    

                                  

                                

                                
The user being the RO is the
                                  initial use case for OAuth. 

                              

                            

                          

                          
OAuth 2.0 is no more mandating such a case.
                          

                        

                      

                    

                  

                

                

                  

                    


                      
I don't know what you mean by that.

                    

                  

                

                
Copy and paste from draft-ietf-oauth-security-topics:
                

                

                  
OAuth initially assumed a static relationship
                    between client, authorization server and resource
                    servers.=C2=A0 (...)=C2=A0 

                    With the increasing adoption of OAuth, this simple
                    model dissolved and, in several scenarios, was
                    replaced 

                    by a dynamic establishment of the relationship
                    between clients on one side and the authorization
                    and 

                    resource servers of a particular deployment on the
                    other side.

                    

                    This way, the same client could be used to access
                    services of different providers (in case of standard
                    APIs, 

                    such as e-mail or OpenID Connect) or serve as a
                    frontend to a particular tenant in a multi-tenancy
                    environment. 

                  

                

              

            

            


            

            
This sentence does not mention the RO or the Client.
              I'm confused what we are talking about=C2=A0

            

              

                

                  
 

                

                

                  

                    

                      
=C2=A0

                      

                        

                          

                            

                              

                                
A client application would like
                                  access to the user's photos at a phot=
o
                                  sharing site. The resource is the
                                  user's photos. The user is the owner
                                  of that resource.

                              

                            

                          

                          
If the user has already pre established the
                            access control policy rules so that it can
                            access to his own photos 

                            then he does not need to grant in real time
                            any additional authorization.

                        

                      

                      
I don't understand what you are trying to
                        say. The photo sharing example was a driving use
                        case for the creation of OAuth.

                    

                  

                

                
We would need to revisit the original scenario and
                  consider if it can be addressed in a different way
                  than the original way.

              

            

            
The use case is the same. Is there a different solution
              you are proposing?

            
=C2=A0

          

        

      

    

    


    

  


-- 

Txauth mailing list

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




--00000000000091293605ab238b7c--


From nobody Thu Jul 23 16:53: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 9D4923A0A0E for ; Thu, 23 Jul 2020 16:52:58 -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 bi13qUSdfVFZ for ; Thu, 23 Jul 2020 16:52:55 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450: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 AF9BF3A09C3 for ; Thu, 23 Jul 2020 16:52:54 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id j21so4234900lfe.6 for ; Thu, 23 Jul 2020 16:52: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=an9XLTax23n+WyeRIbSTk0DQ7vxQ+glPkcq/6MdwGNI=; b=bvX5w0BlSSEOSun/TCQTaSLW0Ayq/M0sFwJLl8np9Ot2bjxtjinqdsZbx2XHRULZ26 81iKC1ELPyDmarAQ7dNhOseW/vpfUdPgOFeRm1/2GT7MJ+Ux5RjPMkXf/QYxqIaeKhca HG6SmTDNI1Op0cFPK13dIGpdSoMfZnOU0SZc9GU/7WiWI8s3if+kGsMHoz6kChPYq6E9 uqDGvMlGJ9qiFVuWn4IkkgcvZei2U8nY3VkoG79md2tpLFSSwXX4tCZIoBL0ol8F0kiB dgMKD75IrQQqckIVYGDhSQe+QAoBDgwKTYGuNWWbNtUQzvewo3E+mnnApCW8I34Rwkgs bXUg==
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=an9XLTax23n+WyeRIbSTk0DQ7vxQ+glPkcq/6MdwGNI=; b=XR6dW6VdeqDyU84vnWQPIiNpQMU+vL6dTux8LWP4qn8+eOmTwcFQIyYNtQvusWM4dB QJC4TNMmAhW4DYh8ZEPC45Z1hC1v0rr02Mgs0VxUEReXJYGwMOeR8F+Df+DAtJxH6h+d 3G5cmelF5ttQRUHnFM79f/aHtDFg1Jm4sn6tCvP58kV+05xuqH9zcMO8nxRdAyGQNwfF +RbbrzGn4myKreh+Uh50hVWS/TDVWqYNG5ySialaGS0ynSs/0nHx1gLBsbhz+E1RWiIw jzH7fD0tVXwVJ/UepX8XzBQFodkCl5hCGygMDC7VtvwwwmMiAMIH0tDoqe5mKkmlg+II 7A5A==
X-Gm-Message-State: AOAM532es4QTKp6pHURvqzuI3xbztlGh4QZ3d4nP8MDH1qoLx235n5CE pKbpLddpyehm5TITUhrU/Ey+2hbbooQ0oZRRLGQ=
X-Google-Smtp-Source: ABdhPJyb/+3tiQZrJAIpyNYS0dhAHGy1L3xBUW8jo2SrVttDG96DtVGO22H74behnLY4iaxnXwfvyOv2Bdt9zSV6zCw=
X-Received: by 2002:ac2:4a9d:: with SMTP id l29mr3446650lfp.23.1595548372332;  Thu, 23 Jul 2020 16:52:52 -0700 (PDT)
MIME-Version: 1.0
References:         
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 23 Jul 2020 16:52:15 -0700
Message-ID: 
To: Justin Richer 
Cc: Francis Pouatcha , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="000000000000f474ea05ab248db6"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 23 Jul 2020 23:53:00 -0000

--000000000000f474ea05ab248db6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Francis

Thanks again for putting this together. I have taken your definitions and
adjusted them to match how I think of them. I dropped the term "parties"
because I did not think it added value. I am explicit about what each party
is -- software, a human, or an entity. Let me know where you disagree!


Resource - protected data or software functionality
      - controlled by a Resource Owner (RO),
      - protected by the Resource Server (RS)

Claim - a statement about the User
      - may be obtained from the Grant Server (GS) by a Client
      - may be a Resource the Client can access through an RS

Grant - the Claims and/or Resource Access the User and/or RO have granted
to the Client by the GS
    - requested by a Client
    - granted by a GS after any required consent has been obtained from the
User and/or RO

Access Token - an artifact representing the access a client has been
granted to one or more Resources
    - created by the GS
    - presented by the Client when accessing a Resource at an RS

Resource Owner (RO) - the entity that
      - controls a Resource,
      - has delegated Resource access control to one or more GSes
      - may be the User

Resource Server (RS) - the software that controls access to one or more
Resources
      - accessed via an API by Clients presenting an access token
      - accepts access tokens from one or more GSes

Grant Server (GS) - the software that manages Grants
    - has been delegated to manage Resource access by the RO
    - has been delegated to release Claims about the User
    - grants the Client access to Resources after obtaining the required
consent from the RO
    - provides the Client Claims about the User after obtaining the
required consent from the User

Client - the software that wants to access Resources and obtain Claims
    - executed by a User or a non-human service account
    - requests Grants from the Grant Server
    - accesses Resources at an RS using access tokens

User - the human using a Client
    - may also be the RO for one or more Resources
    - may have Claims managed at a GS

Some comments:

A Claim is a well understood term in the field. We should use it. It is
still a Claim if it comes directly from the GS or from an RS.

I think Grant Server is the right term. A Grant contains claims and/or
access to resources. I have defined all the terms above without using the
term authorization. :) -- I am pondering renaming most things called
Authorization in XAuth to Access.

Claim Issuer - I think we may need to add this party to our nomenclature.
This is the entity that issues Claims. It may be a GS or an RS.

/Dick

=E1=90=A7

On Thu, Jul 23, 2020 at 8:07 AM Justin Richer  wrote:

> Up-front question to the Chairs, do we have a good place to capture this
> kind of thing? A non-spec document like this would be a good candidate fo=
r
> a wiki page. Do we have plans to set up a GitHub repository or similar? I=
f
> so we could use the wiki capabilities there to at least get this stuff
> written down. Use cases would be good to capture there as well.
>
>
>
> Francis,
>
> First, I want to thank you for putting the work in to getting some
> vocabulary down. This is not an easy task! Some notes on specific items
> inline below.
>
> On Jul 21, 2020, at 8:33 PM, Francis Pouatcha  wrote:
>
> Hello Dick, Justin, Tom, Denis,
>
> Below is a new version of the dictionary includings comments from
> different threads. Change log includes:
> - avoided the expression "owns a resource" in favor of the expression
> "controls a resource"
> - included the clarification "resource access" and "claim release"
> - included a clarification User vs. RO
> - tried to clarify the word User-Agent
> - added the definition of a Claim
>
> Terms
> =3D=3D=3D=3D=3D
>
> Party - represents a role in the GNAP protocol flow. A party can take the
> form of a web service, an application installed on the user device and
> acting autonomously or the form of a natural person (resp. of an autonomo=
us
> device) using an application to interact with other parties.
>
> Resource - a piece of data or web service
>       - controlled by a Resource Owner (RO),
>       - held and guarded by a Resource Server (RS) and
>       - serviced by the RS to a Client, if the Client provides a valid
> Authorization.
>
> Claim - a piece of data
>       - controlled by a Resource Owner (RO),
>       - held and guarded by the Grant Server (GS) and
>       - released by the GS to a Client as part of an Authorization.
>
>
> The differentiation between =E2=80=9Cresource=E2=80=9D and =E2=80=9Cclaim=
=E2=80=9D is important since it
> separates items that get tied to an access token=E2=80=99s rights (=E2=80=
=9Cresources=E2=80=9D)
> with items that come back directly to the client without going through a
> separate API. The term =E2=80=9Cclaim=E2=80=9D is problematic here though=
 because it is
> used broadly in the community to mean, roughly, =E2=80=9Ca statement abou=
t the end
> user=E2=80=9D. It=E2=80=99s therefore both too broad and too narrow in th=
e wrong ways: a
> =E2=80=9Cclaim=E2=80=9D could come back as part of an API response, like =
the OIDC UserInfo
> Endpoint, and so it=E2=80=99s not a good name for this item. Even the OID=
C =E2=80=9Cclaims=E2=80=9D
> query language defines several different targets for returning the =E2=80=
=9Cclaims=E2=80=9D
> about the user, and none of them match the method that GNAP is looking to
> use here. A =E2=80=9Cclaim=E2=80=9D is also generally understood in the i=
dentity community
> to be a statement about the user, and the data coming back directly to th=
e
> client might be about the user or something else, especially as we look
> forward to extensions of GNAP.
>
> I think we should focus on the separation of the delivery mechanism, but
> I=E2=80=99m not sure what good alternatives would be. Perhaps:
>
>  - =E2=80=9Caccess right=E2=80=9D for things tied to the API/token
>  - =E2=80=9Cdata response=E2=80=9D for things coming back directly to the=
 client
>
> I=E2=80=99m not particularly thrilled by these names, but I think recent =
list
> conversation shows that we need to get away from =E2=80=9Cclaim=E2=80=9D =
as it=E2=80=99s overloaded.
>
>
> Resource Owner (RO) - the party that
>       - controls a Resource,
>       - relies on the services the GS to manage access to that Resource,
>       - relies on the services of a RS to hold the Resource and guard
> access to that Resource,
>       - controls a Claim,
>       - relies on the services the GS to release that Claim to a Client.
>
> Resource Server (RS) - the party that
>       - holds a resource and guards access to that resource on behalf of
> the RO,
>       - services the Resource to the requesting Client, provided the
> Client presents a valid Authorization.
>       The RS is generally deployed as a web service.
>
> Grant Server (GS) - the party that
>       - manages access to a Resource on behalf of the RO,
>       - holds Claims and releases them when consented by the RO.
>       For each Resource access request, the GS might request the Consent
> of the RO and produce a corresponding Authorization that is given to the
> requesting Client.
>
>
> I don=E2=80=99t like the shift from =E2=80=9CAuthorization Server=E2=80=
=9D to =E2=80=9CGrant Server=E2=80=9D, and
> it especially doesn=E2=80=99t make sense in light of the definitions of =
=E2=80=9Cgrant=E2=80=9D and
> =E2=80=9Cauthorization=E2=80=9D above. I believe we should stick with =E2=
=80=9CAuthorization
> Server=E2=80=9D if it=E2=80=99s a single role. I would also propose that =
we have a separate
> term for the RO-interactive portion vs. the client-facing portion, as has
> been brought up in a few threads. Maybe these get different names entirel=
y,
> or maybe they are =E2=80=9Caspects=E2=80=9D of the AS, I=E2=80=99m not su=
re.
>
>
> Consent - act of an RO :
>       - approving access to a Resource, means approval that a Resource he
> controls can be given to the Client by the RS.
>       - approving release of a Claim, means approval that a Claim he
> controls can be included by the GS in an Authorization to be returned to
> the Client.
>
> Grant - material form of an RO Consent. In order not to interact with the
> RO on each Resource access request, the GS might store the RO Consent in
> the form of a Grant for reuse.
>
> Authorization - externalized form of a Grant as known to the GS and the R=
S.
>       - The GS converts a Grant into an Authorization for use in a
> Resource access request.
>       - The RS evaluates an Authorization to decide on whether or not to
> release the Resource to the Client.
>
> Client - the party that provides the infrastructure used by a User to
> access a Resource. The client infrastructure is designed to:
>       - Receive the resource access request from the User,
>       - Interact with the RS to discover authorization requirements,
>       - Interact with the GS to obtain an Authorization to access the
> Resource,
>       - Interact with the RS to access the Resource on behalf of the User=
.
>
>
> I think we should be clear that what we call the =E2=80=9Cclient=E2=80=9D=
 is a piece of
> software operated by the user. It=E2=80=99s true that this software might=
 have
> multiple parts of its =E2=80=9Cinfrastructure=E2=80=9D but it=E2=80=99s a=
lways software.
>
>
> User - the party using the infrastructure of the Client to gain access to
> a Resource or a Claim.
>
>
> In UMA, we call this the =E2=80=9CRequesting Party=E2=80=9D, or RqP. We m=
ight want to
> consider adopting this terminology here as well.
>
>
> Clarifications:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> User vs. RO :
>       - the User is the party using the infrastructure of the Client to
> gain access to a Resource or a Claim,
>       - the RO is the party controlling access to a Resource or
> controlling the release of a Claim.
> In many use cases, User and RO will be represented by the same party (see
> oAuth2), but GNAP exposes use cases where User and RO are represented by
> different parties.
>
> User-Agent :
> User and RO are parties that might be represented by a natural person or
> an autonomous device. In those cases, User (resp. RO) might need the help
> of an application to interact with other parties. Such an application is
> generally referred to as the "User-Agent".
>
>
> The term =E2=80=9Cuser agent=E2=80=9D is often used to be equivalent to t=
he web browser,
> and not the more general use here. I think we=E2=80=99re seeing more =E2=
=80=9Cagent=E2=80=9D
> terminology for helper applications like digital wallets and AI bots, whi=
ch
> would seem to be covered under your definition here.
>
>
> Feedbacks are welcome.
>
>
> Again, thanks so much for getting this going!
>
>  =E2=80=94 Justin
>
> Best regards,
> /Francis
>
>
> On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha  wrote:
>
>>
>>
>> On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt  wrote:
>>
>>>
>>>
>>> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha 
>>> wrote:
>>>
>>>>
>>>> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt 
>>>> wrote:
>>>>
>>>>> FYI: I consider the release of claims to be an "authorization" as
>>>>> well.
>>>>>
>>>> Great. Then it is included.
>>>>
>>>
>>> I pivoted to using the term Grant rather than authorization so that it
>>> included both authorizing access to a resource, and authorizing the rel=
ease
>>> of an identity claim.
>>>
>>> Perhaps we should not use the word "authorization"?
>>>
>> Authorization is currently used to refer to the token issued by the GSan=
d
>> presented to the RS by the Client. I have no alternative word for now.
>>
>>>
>>> "resource access" and "claim release"
>>>
>>> A Grant then covers both?
>>>
>> Yes, Great! The word Grant fits best for both. I suggest adding this
>> clarification to that dictionary.
>>
>>>
>>>
>>>
>>>>
>>>>> IE, the user authorizes the GS to release a DOB claim to a Client.
>>>>>
>>>> I guess you mean the "RO" authorizes the GS to release a DOB!
>>>>
>>>
>>> Yes, thanks for clarifying!
>>>
>>> /Dick
>>>
>>>>
>>
>> --
>> 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/
>
>
>

--000000000000f474ea05ab248db6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Francis

Thanks again for putting=C2=
=A0this together. I have taken your definitions and adjusted them to match =
how I think of them. I dropped the term "parties" because I did n=
ot think it added value. I am explicit about what each party is -- software=
, a human, or an entity. Let me know where you disagree!


Resource - protected data or software functionality
=C2=A0 =
=C2=A0 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=
=A0 - protected by the Resource Server (RS)

Claim - a statement abou=
t the User
=C2=A0 =C2=A0 =C2=A0 - may be obtained from the Grant Server =
(GS) by a Client
=C2=A0 =C2=A0 =C2=A0 - may be a Resource the Client can=
 access through an RS

Grant - the Claims and/or Resource Access the =
User and/or RO have granted to the Client by the GS
=C2=A0 =C2=A0 - requ=
ested by a Client
=C2=A0 =C2=A0 - granted by a GS after any required con=
sent has been obtained from the User and/or RO

Access Token - an art=
ifact representing the access a client has been granted to one or more Reso=
urces
=C2=A0 =C2=A0 - created by the GS
=C2=A0 =C2=A0 - presen=
ted by the Client when accessing a Resource at an RS

Resource Owner =
(RO) - the entity that
=C2=A0 =C2=A0 =C2=A0 - controls a Resource,
=
=C2=A0 =C2=A0 =C2=A0 - has delegated Resource access control to one or more=
 GSes
=C2=A0 =C2=A0 =C2=A0 - may be the User

Resource Server (RS)=
 - the software that controls access to one or more Resources
=C2=A0 =C2=
=A0 =C2=A0 - accessed via an API by Clients presenting an access token
=
=C2=A0 =C2=A0 =C2=A0 - accepts access tokens from one or more GSes 

=
Grant Server (GS) - the software that manages Grants
=C2=A0 =C2=A0 - has=
 been delegated to manage Resource access by the RO
=C2=A0 =C2=A0 - has =
been delegated to release Claims about the User
=C2=A0 =C2=A0 - grants t=
he Client access to Resources after obtaining the required consent from the=
 RO
=C2=A0 =C2=A0 - provides the Client Claims about the User after obta=
ining the required consent from the User

Client - the software that =
wants to access Resources and obtain Claims
=C2=A0 =C2=A0 - executed by =
a User or a non-human service account 
=C2=A0 =C2=A0 - requests Grants f=
rom the Grant Server
=C2=A0 =C2=A0 - accesses Resources at an RS using a=
ccess tokens

User - the human using a Client
=C2=A0 =C2=A0 - may =
also be the RO for one or more Resources
=C2=A0 =C2=A0 - may have Claims=
 managed at a GS

Some comments:

=

A Claim is a well understood term in the field. We should use it=
. It is still a Claim if it comes directly from the GS or from an RS.=C2=A0=


I think Grant Server is the right term. A Grant c=
ontains claims and/or access to resources. I have defined all the terms abo=
ve without using the term authorization. :) -- I am pondering renaming most=
 things called Authorization in XAuth to Access.

C=
laim Issuer - I think we may need to add this party to our nomenclature. Th=
is is the entity that issues Claims. It may be a GS or an RS.=C2=A0

/Dick

3D""=E1=90=A7=


=
On Thu, Jul 23, 2020 at 8:07 AM Justin Richer <jricher@mit.edu> wrote:
Up-=
front question to the Chairs, do we have a good place to capture this kind =
of thing? A non-spec document like this would be a good candidate for a wik=
i page. Do we have plans to set up a GitHub repository or similar? If so we=
 could use the wiki capabilities there to at least get this stuff written d=
own. Use cases would be good to capture there as well.=C2=A0

=



Francis,

First, I wa=
nt to thank you for putting the work in to getting some vocabulary down. Th=
is is not an easy task! Some notes on specific items inline below.
=

On Jul 21, 2020, at 8:33 PM, Francis Pou=
atcha <fpo@adorsys.d=
e> wrote:

Hello Dick,=
 Justin, Tom, Denis,

Below=C2=A0is a new version of the =
dictionary includings comments=C2=A0from different=C2=A0threads. Change log=
 includes:
- avoided the expression "owns a resource" i=
n favor of the expression "controls=C2=A0a resource"
- =
included the clarification=C2=A0"resource access" and "claim=
 release"
- included a clarification User vs. RO
-=
 tried to clarify the word User-Agent
- added the definition of a=
 Claim

Terms
=3D=3D=3D=3D=3D

Party - rep=
resents a role in the GNAP protocol flow. A party can take the form of a we=
b service, an application installed on the user device and acting autonomou=
sly or the form of a natural person (resp. of an autonomous device) using a=
n application to interact with other parties.

Resource - a piece of =
data or web service
=C2=A0 =C2=A0 =C2=A0 - controlled by a Resource Owne=
r (RO),
=C2=A0 =C2=A0 =C2=A0 - held and guarded by a Resource Server (RS=
) and
=C2=A0 =C2=A0 =C2=A0 - serviced by the RS to a Client, if the Clie=
nt provides a valid Authorization.

Claim - a piece of data
=C2=A0=
 =C2=A0 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=
=A0 - held and guarded by the Grant Server (GS) and
=C2=A0 =C2=A0 =C2=A0=
 - released by the GS to a Client as part of an Authorization.

The differentiation between =E2=
=80=9Cresource=E2=80=9D and =E2=80=9Cclaim=E2=80=9D is important since it s=
eparates items that get tied to an access token=E2=80=99s rights (=E2=80=9C=
resources=E2=80=9D) with items that come back directly to the client withou=
t going through a separate API. The term =E2=80=9Cclaim=E2=80=9D is problem=
atic here though because it is used broadly in the community to mean, rough=
ly, =E2=80=9Ca statement about the end user=E2=80=9D. It=E2=80=99s therefor=
e both too broad and too narrow in the wrong ways: a =E2=80=9Cclaim=E2=80=
=9D could come back as part of an API response, like the OIDC UserInfo Endp=
oint, and so it=E2=80=99s not a good name for this item. Even the OIDC =E2=
=80=9Cclaims=E2=80=9D query language defines several different targets for =
returning the =E2=80=9Cclaims=E2=80=9D about the user, and none of them mat=
ch the method that GNAP is looking to use here. A =E2=80=9Cclaim=E2=80=9D i=
s also generally understood in the identity community to be a statement abo=
ut the user, and the data coming back directly to the client might be about=
 the user or something else, especially as we look forward to extensions of=
 GNAP.=C2=A0

I think we should focus on the separa=
tion of the delivery mechanism, but I=E2=80=99m not sure what good alternat=
ives would be. Perhaps:

=C2=A0- =E2=80=9Caccess ri=
ght=E2=80=9D for things tied to the API/token
=C2=A0- =E2=80=9Cda=
ta response=E2=80=9D for things coming back directly to the client

I=E2=80=99m not particularly thrilled by these names, but =
I think recent list conversation shows that we need to get away from =E2=80=
=9Cclaim=E2=80=9D as it=E2=80=99s overloaded.


Resource Owner (RO) - =
the party that
=C2=A0 =C2=A0 =C2=A0 - controls a Resource,
=C2=A0 =C2=
=A0 =C2=A0 - relies on the services the GS to manage access to that Resourc=
e,
=C2=A0 =C2=A0 =C2=A0 - relies on the services of a RS to hold the Res=
ource and guard access to that Resource,
=C2=A0 =C2=A0 =C2=A0 - controls=
 a Claim,
=C2=A0 =C2=A0 =C2=A0 - relies on the services the GS to releas=
e that Claim to a Client.

Resource Server (RS) - the party that=C2=A0
=C2=A0 =C2=A0 =C2=A0 - holds a resource and guards access=
 to that resource on behalf of the RO,
=C2=A0 =C2=A0 =C2=A0 - services t=
he Resource to the requesting Client, provided the Client presents a valid =
Authorization.
=C2=A0 =C2=A0 =C2=A0 The RS is generally deployed as a we=
b service.

Grant Server (GS) - the party that=C2=A0
=
=C2=A0 =C2=A0 =C2=A0 - manages access to a Resource on behalf of the RO,=C2=A0 =C2=A0 =C2=A0 - holds Claims and releases them when consented by th=
e RO.
=C2=A0 =C2=A0 =C2=A0 For each Resource access request, the GS migh=
t request the Consent of the RO and produce a corresponding Authorization t=
hat is given to the requesting Client.

I don=E2=80=99t like the shift from =E2=80=9CAuthorizatio=
n Server=E2=80=9D to =E2=80=9CGrant Server=E2=80=9D, and it especially does=
n=E2=80=99t make sense in light of the definitions of =E2=80=9Cgrant=E2=80=
=9D and =E2=80=9Cauthorization=E2=80=9D above. I believe we should stick wi=
th =E2=80=9CAuthorization Server=E2=80=9D if it=E2=80=99s a single role. I =
would also propose that we have a separate term for the RO-interactive port=
ion vs. the client-facing portion, as has been brought up in a few threads.=
 Maybe these get different names entirely, or maybe they are =E2=80=9Caspec=
ts=E2=80=9D of the AS, I=E2=80=99m not sure.


Consent - act of an RO =
:
=C2=A0 =C2=A0 =C2=A0 - approving access to a Resource, means approval =
that a Resource he controls can be given to the Client by the RS.
=C2=A0=
 =C2=A0 =C2=A0 - approving release of a Claim, means approval that a Claim =
he controls can be included by the GS in an Authorization to be returned to=
 the Client.

Grant - material form of an RO Consent. In order not to=
 interact with the RO on each Resource access request, the GS might store t=
he RO Consent in the form of a Grant for reuse.

Authorization - exte=
rnalized form of a Grant as known to the GS and the RS.
=C2=A0 =C2=A0 =
=C2=A0 - The GS converts a Grant into an Authorization for use in a Resourc=
e access request.
=C2=A0 =C2=A0 =C2=A0 - The RS evaluates an Authorizati=
on to decide on whether or not to release the Resource to the Client.
Client - the party that provides the infrastructure used by a User to acc=
ess a Resource. The client infrastructure is designed to:
=C2=A0 =C2=A0 =
=C2=A0 - Receive the resource access request from the User,
=C2=A0 =C2=
=A0 =C2=A0 - Interact with the RS to discover authorization requirements,=C2=A0 =C2=A0 =C2=A0 - Interact with the GS to obtain an Authorization to=
 access the Resource,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to acc=
ess the Resource on behalf of the User.
<=
div>
I think we should be clear that what we call the =E2=80=
=9Cclient=E2=80=9D is a piece of software operated by the user. It=E2=80=99=
s true that this software might have multiple parts of its =E2=80=9Cinfrast=
ructure=E2=80=9D but it=E2=80=99s always software.


User - the party =
using the infrastructure of the Client to gain access to a Resource or a Cl=
aim.


In UMA, we c=
all this the =E2=80=9CRequesting Party=E2=80=9D, or RqP. We might want to c=
onsider adopting this terminology here as well.


Clarifications:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

User vs. RO :=C2=A0
=C2=A0 =C2=A0 =C2=A0 - the User is the party using the infrastructur=
e of the Client to gain access to a Resource or a Claim,
=C2=A0 =C2=A0 =
=C2=A0 - the RO is the party controlling access to a Resource or controllin=
g the release of a Claim.
In many use cases, User and RO will be represe=
nted by the same party (see oAuth2), but GNAP exposes use cases where User =
and RO are represented by different parties.

User-Agent :
User an=
d RO are parties that might be represented by a natural person or an autono=
mous device. In those cases, User (resp. RO) might need the help of an appl=
ication to interact with other parties. Such an application is generally re=
ferred to as the "User-Agent".
=


The term =E2=80=9Cuser agent=E2=80=9D is often used to =
be equivalent to the web browser, and not the more general use here. I thin=
k we=E2=80=99re seeing more =E2=80=9Cagent=E2=80=9D terminology for helper =
applications like digital wallets and AI bots, which would seem to be cover=
ed under your definition here.


Feedbacks are welcome.

=


Again, thanks so much fo=
r getting this going!

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

Be=
st regards,
/Francis


On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:


On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt <dick.hardt@gmail.com> wrote:
=



On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha <=
fpo@adorsys.de> =
wrote:

On=
 Tue, Jul 21, 2020 at 1:59 PM Dick Hardt <dick.hardt@gmail.com> wrote:
FYI: I con=
sider the release of claims to be an "authorization" as well.=C2=
=A0
Great. Then it is included.=C2=A0

I pivoted to using the term Grant rathe=
r than authorization so that it included both authorizing access to a resou=
rce, and authorizing the release of an identity claim.

=

Perhaps we should not use the word "authorization"?=C2=A0
Authorization is currently used to refer t=
o the token issued by the GSand presented to the RS by the Client. I have n=
o alternative word for now.

&qu=
ot;resource access" and "claim release"

=

A Grant then covers both?
Yes, Grea=
t! The word Grant fits best for both. I suggest adding this clarification t=
o that dictionary.
<=
div dir=3D"ltr">

=C2=A0
=


IE, the user authorizes the GS to release a =
DOB claim=C2=A0to a Client.
I guess you mean t=
he "RO" authorizes the GS to release a DOB!

Yes, thanks for clarifying!
=C2=A0
/Dick
<=
div dir=3D"ltr">
=


--=C2=A0
=

Francis Pouatcha
Co-Founder and Technical Lead=

adorsys GmbH & Co. KG
<=
/blockquote>
--=C2=A0
=

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




--000000000000f474ea05ab248db6--


From nobody Thu Jul 23 18: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 9C4013A046A for ; Thu, 23 Jul 2020 18:02: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 T31EQ48_BLyg for ; Thu, 23 Jul 2020 18:02: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 9C1163A045B for ; Thu, 23 Jul 2020 18:02:11 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id a15so6788544wrh.10 for ; Thu, 23 Jul 2020 18:02:11 -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=P+CGIEnxE1mfDQypm+utqphTR5fPEUBSDRXDJiGP8q8=; b=ZGOsUbZVZze9goyA6ub8A0wtOecdGUKnQgTzZQPdgaiDpLfVUya3/dINVLMvERKthu VIqp4IFWpD0nMp5j/Dk8KhGm2YoQs30+pLF5mLI1yEkxheE5MO/5qy4JM4jZYE2Bp6CI MZuiYATfzbdJJjflnbZGEltt+tvpPlkpEI0WU=
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=P+CGIEnxE1mfDQypm+utqphTR5fPEUBSDRXDJiGP8q8=; b=RQeoIok6wJTXiPg/mbhuYn6hpUcl/28BrlS1o5HVxSLDVBBN7lC+NO3fMSuI65nu9v z5iN/3u8mhbGXdJLzESfei3Nm7UIj0/Ls0B7im9jHRxnEFoxsdDoJxtZgYq8R1RUORRw 78Ui1qC5LFxZLquTAIU/ix1YPlI1abzy1wRKJHwC23XrtmIprCwhU1E7qTFwopGexPv7 WL++I197EJQsuMnGDgIc6EXxDo79xkB0qDzsndDMKYh5wD6Gn1YNqjEGE2QAY5ccpNDw FqIv99QC6EweTdEEICSWfMkvZHPoQsD/b1nJ02QAqGYg8q1eRP2IpUv1nKTHZZhnLC/X KcPw==
X-Gm-Message-State: AOAM531+8TlmM67cJjgHMhJl2fm5BGBybj04eKSdzQqoCUHx4EMzXg4B bgZiV6HKP92VeMM5oeKJgHJQg01nI40+sbp2Nno/Ag==
X-Google-Smtp-Source: ABdhPJyFjQKp41G4v8CV6h5hmDf24sDzadoWZUJZMjS7KuWZi/W+qcHf0U0SwEa09gZKtE29kyaR9xoIPVg1r0xWH5Q=
X-Received: by 2002:a5d:4a41:: with SMTP id v1mr6846024wrs.371.1595552529788;  Thu, 23 Jul 2020 18:02:09 -0700 (PDT)
MIME-Version: 1.0
References:         
In-Reply-To: 
From: Francis Pouatcha 
Date: Thu, 23 Jul 2020 21:01:57 -0400
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org, Dick Hardt ,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="000000000000c2592105ab25857c"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 24 Jul 2020 01:02:15 -0000

--000000000000c2592105ab25857c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Justin,

thanks a lot for the feedback, some comments inline,

On Thu, Jul 23, 2020 at 11:07 AM Justin Richer  wrote:

> Up-front question to the Chairs, do we have a good place to capture this
> kind of thing? A non-spec document like this would be a good candidate fo=
r
> a wiki page. Do we have plans to set up a GitHub repository or similar? I=
f
> so we could use the wiki capabilities there to at least get this stuff
> written down. Use cases would be good to capture there as well.
>
>
>
> Francis,
>
> First, I want to thank you for putting the work in to getting some
> vocabulary down. This is not an easy task! Some notes on specific items
> inline below.
>
> On Jul 21, 2020, at 8:33 PM, Francis Pouatcha  wrote:
>
> Hello Dick, Justin, Tom, Denis,
>
> Below is a new version of the dictionary includings comments from
> different threads. Change log includes:
> - avoided the expression "owns a resource" in favor of the expression
> "controls a resource"
> - included the clarification "resource access" and "claim release"
> - included a clarification User vs. RO
> - tried to clarify the word User-Agent
> - added the definition of a Claim
>
> Terms
> =3D=3D=3D=3D=3D
>
> Party - represents a role in the GNAP protocol flow. A party can take the
> form of a web service, an application installed on the user device and
> acting autonomously or the form of a natural person (resp. of an autonomo=
us
> device) using an application to interact with other parties.
>
> Resource - a piece of data or web service
>       - controlled by a Resource Owner (RO),
>       - held and guarded by a Resource Server (RS) and
>       - serviced by the RS to a Client, if the Client provides a valid
> Authorization.
>
> Claim - a piece of data
>       - controlled by a Resource Owner (RO),
>       - held and guarded by the Grant Server (GS) and
>       - released by the GS to a Client as part of an Authorization.
>
>
> The differentiation between =E2=80=9Cresource=E2=80=9D and =E2=80=9Cclaim=
=E2=80=9D is important since it
> separates items that get tied to an access token=E2=80=99s rights (=E2=80=
=9Cresources=E2=80=9D)
> with items that come back directly to the client without going through a
> separate API. The term =E2=80=9Cclaim=E2=80=9D is problematic here though=
 because it is
> used broadly in the community to mean, roughly, =E2=80=9Ca statement abou=
t the end
> user=E2=80=9D. It=E2=80=99s therefore both too broad and too narrow in th=
e wrong ways: a
> =E2=80=9Cclaim=E2=80=9D could come back as part of an API response, like =
the OIDC UserInfo
> Endpoint, and so it=E2=80=99s not a good name for this item. Even the OID=
C =E2=80=9Cclaims=E2=80=9D
> query language defines several different targets for returning the =E2=80=
=9Cclaims=E2=80=9D
> about the user, and none of them match the method that GNAP is looking to
> use here. A =E2=80=9Cclaim=E2=80=9D is also generally understood in the i=
dentity community
> to be a statement about the user, and the data coming back directly to th=
e
> client might be about the user or something else, especially as we look
> forward to extensions of GNAP.
>
I fully understand your problem. It won't be obvious to find a replacement.
I often think about the word Assertion. But I not sure if the word won't
come with its own controversies.

Essential for us now is to narrow the intended meaning of the term in the
context of GNAP and then look for the correct replacement, if any.  What
about this?


A Claim
  - is an "assertion" of the truth of some properties or attributes of the
RO.
  Note-1: A Claim is produced either by the GS or by another claim source.
  Note-2: A Claim is held and guarded by the Grant Server (GS).
  Note-3: A Claim is released by the GS to a Client.
                  [REMOVED: "as part of an Authorization", as Justin
mentions bellow possibility of a claim to be included in userInfo and other
introspection responses]
  Note-4: The release of a Claim is controlled by the RO
                  [ADDED: "release", to distinguish it from the
"production" of the claim. Some Claims are just provided by the RO, some
other Claims are produced by authorities, that take care of verifying the
claim and/or legitimating them]


> I think we should focus on the separation of the delivery mechanism, but
> I=E2=80=99m not sure what good alternatives would be. Perhaps:
>
>  - =E2=80=9Caccess right=E2=80=9D for things tied to the API/token
>  - =E2=80=9Cdata response=E2=80=9D for things coming back directly to the=
 client
>
Here you are referring to the target of the information. And it is more
difficult to nail formalized. A claim might be targeted for the RS and not
the Client.

I suggest we first stay with: "resource access" and "claim release" (both
Grants as mentioned by Dick above). Rationale being:
- the clarification that a Resource is not a Claim, but that both are
controlled by the RO
- the clarification of a Claim is held by the GS,
- the clarification of a Resource is held by the RS,

>
> I=E2=80=99m not particularly thrilled by these names, but I think recent =
list
> conversation shows that we need to get away from =E2=80=9Cclaim=E2=80=9D =
as it=E2=80=99s overloaded.
>
Let us look at this after we have narrowed a definition in the context of
GNAP.


>
> Resource Owner (RO) - the party that
>       - controls a Resource,
>       - relies on the services the GS to manage access to that Resource,
>       - relies on the services of a RS to hold the Resource and guard
> access to that Resource,
>       - controls a Claim,
>       - relies on the services the GS to release that Claim to a Client.
>
> Resource Server (RS) - the party that
>       - holds a resource and guards access to that resource on behalf of
> the RO,
>       - services the Resource to the requesting Client, provided the
> Client presents a valid Authorization.
>       The RS is generally deployed as a web service.
>
> Grant Server (GS) - the party that
>       - manages access to a Resource on behalf of the RO,
>       - holds Claims and releases them when consented by the RO.
>       For each Resource access request, the GS might request the Consent
> of the RO and produce a corresponding Authorization that is given to the
> requesting Client.
>
>
> I don=E2=80=99t like the shift from =E2=80=9CAuthorization Server=E2=80=
=9D to =E2=80=9CGrant Server=E2=80=9D, and
> it especially doesn=E2=80=99t make sense in light of the definitions of =
=E2=80=9Cgrant=E2=80=9D and
> =E2=80=9Cauthorization=E2=80=9D above. I believe we should stick with =E2=
=80=9CAuthorization
> Server=E2=80=9D if it=E2=80=99s a single role. I would also propose that =
we have a separate
> term for the RO-interactive portion vs. the client-facing portion, as has
> been brought up in a few threads. Maybe these get different names entirel=
y,
> or maybe they are =E2=80=9Caspects=E2=80=9D of the AS, I=E2=80=99m not su=
re.
>
I also did not see any difference to functions of an AS. But i suggest we
shift the discussion on renaming the term GS to another thread and keep the
focus on this thread on elaborating terms in the context of GNAP.


>
> Consent - act of an RO :
>       - approving access to a Resource, means approval that a Resource he
> controls can be given to the Client by the RS.
>       - approving release of a Claim, means approval that a Claim he
> controls can be included by the GS in an Authorization to be returned to
> the Client.
>
> Grant - material form of an RO Consent. In order not to interact with the
> RO on each Resource access request, the GS might store the RO Consent in
> the form of a Grant for reuse.
>
> Authorization - externalized form of a Grant as known to the GS and the R=
S.
>       - The GS converts a Grant into an Authorization for use in a
> Resource access request.
>       - The RS evaluates an Authorization to decide on whether or not to
> release the Resource to the Client.
>
> Client - the party that provides the infrastructure used by a User to
> access a Resource. The client infrastructure is designed to:
>       - Receive the resource access request from the User,
>       - Interact with the RS to discover authorization requirements,
>       - Interact with the GS to obtain an Authorization to access the
> Resource,
>       - Interact with the RS to access the Resource on behalf of the User=
.
>
>
> I think we should be clear that what we call the =E2=80=9Cclient=E2=80=9D=
 is a piece of
> software operated by the user. It=E2=80=99s true that this software might=
 have
> multiple parts of its =E2=80=9Cinfrastructure=E2=80=9D but it=E2=80=99s a=
lways software.
>
Yes.
Client - the party that implements the infrastructure used by a User to
access a Resource:
   Note-1: a Client is always a piece of software running either on the
User device or as a web service.
   Note-2: The Client infrastructure is designed to:
      - receive the resource access request from the User,
      - interact with the RS to discover authorization requirements,
      - interact with the GS to obtain an Authorization to access the
Resource,
      - interact with the RS to access the Resource on behalf of the User.


>
> User - the party using the infrastructure of the Client to gain access to
> a Resource or a Claim.
>
>
> In UMA, we call this the =E2=80=9CRequesting Party=E2=80=9D, or RqP. We m=
ight want to
> consider adopting this terminology here as well.
>
I admit the term User is confusing. Like for GS vs AS above, let us start a
new thread on this.


>
> Clarifications:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> User vs. RO :
>       - the User is the party using the infrastructure of the Client to
> gain access to a Resource or a Claim,
>       - the RO is the party controlling access to a Resource or
> controlling the release of a Claim.
> In many use cases, User and RO will be represented by the same party (see
> oAuth2), but GNAP exposes use cases where User and RO are represented by
> different parties.
>
> User-Agent :
> User and RO are parties that might be represented by a natural person or
> an autonomous device. In those cases, User (resp. RO) might need the help
> of an application to interact with other parties. Such an application is
> generally referred to as the "User-Agent".
>
>
> The term =E2=80=9Cuser agent=E2=80=9D is often used to be equivalent to t=
he web browser,
> and not the more general use here. I think we=E2=80=99re seeing more =E2=
=80=9Cagent=E2=80=9D
> terminology for helper applications like digital wallets and AI bots, whi=
ch
> would seem to be covered under your definition here.
>
>
> Feedbacks are welcome.
>
> Yes. We do need feedback here.

Just as a summary:
- I will update the dictionary after we receive feedback on the definitions
of Claim and Client as reformulated in the answer.
- would you start a new thread for the renaming of GS to AS?
- would you start a new thread for the renaming of Client to Requesting
Party.

Thanks a lot for the feedback.

--=20
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--000000000000c2592105ab25857c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Justin,=C2=A0

thanks a lot for the feedback, some comments in=
line,

On Thu, Jul 23, 2020 at 11:07 AM Justin Richer <jricher@mit.edu> wrote:
=

Up-front question to the Chairs, do we have a good place to capture th=
is kind of thing? A non-spec document like this would be a good candidate f=
or a wiki page. Do we have plans to set up a GitHub repository or similar? =
If so we could use the wiki capabilities there to at least get this stuff w=
ritten down. Use cases would be good to capture there as well.=C2=A0
<=
div>


Francis,

Fir=
st, I want to thank you for putting the work in to getting some vocabulary =
down. This is not an easy task! Some notes on specific items inline below.<=
br>

On Jul 21, 2020, at 8:33 PM, Fra=
ncis Pouatcha <fpo@a=
dorsys.de> wrote:

Hel=
lo Dick, Justin, Tom, Denis,

Below=C2=A0is a new version=
 of the dictionary includings comments=C2=A0from different=C2=A0threads. Ch=
ange log includes:
- avoided the expression "owns a resource=
" in favor of the expression "controls=C2=A0a resource"
- included the clarification=C2=A0"resource access" and &qu=
ot;claim release"
- included a clarification User vs. RO
- tried to clarify the word User-Agent
- added the definit=
ion of a Claim

Terms
=3D=3D=3D=3D=3D

Par=
ty - represents a role in the GNAP protocol flow. A party can take the form=
 of a web service, an application installed on the user device and acting a=
utonomously or the form of a natural person (resp. of an autonomous device)=
 using an application to interact with other parties.

Resource - a p=
iece of data or web service
=C2=A0 =C2=A0 =C2=A0 - controlled by a Resou=
rce Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - held and guarded by a Resource Se=
rver (RS) and
=C2=A0 =C2=A0 =C2=A0 - serviced by the RS to a Client, if =
the Client provides a valid Authorization.

Claim - a piece of data=C2=A0 =C2=A0 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =C2=
=A0 =C2=A0 - held and guarded by the Grant Server (GS) and
=C2=A0 =C2=A0=
 =C2=A0 - released by the GS to a Client as part of an Authorization.

The differentiation betwee=
n =E2=80=9Cresource=E2=80=9D and =E2=80=9Cclaim=E2=80=9D is important since=
 it separates items that get tied to an access token=E2=80=99s rights (=E2=
=80=9Cresources=E2=80=9D) with items that come back directly to the client =
without going through a separate API. The term =E2=80=9Cclaim=E2=80=9D is p=
roblematic here though because it is used broadly in the community to mean,=
 roughly, =E2=80=9Ca statement about the end user=E2=80=9D. It=E2=80=99s th=
erefore both too broad and too narrow in the wrong ways: a =E2=80=9Cclaim=
=E2=80=9D could come back as part of an API response, like the OIDC UserInf=
o Endpoint, and so it=E2=80=99s not a good name for this item. Even the OID=
C =E2=80=9Cclaims=E2=80=9D query language defines several different targets=
 for returning the =E2=80=9Cclaims=E2=80=9D about the user, and none of the=
m match the method that GNAP is looking to use here. A =E2=80=9Cclaim=E2=80=
=9D is also generally understood in the identity community to be a statemen=
t about the user, and the data coming back directly to the client might be =
about the user or something else, especially as we look forward to extensio=
ns of GNAP.=C2=A0
I fully understa=
nd your problem. It won't be obvious to find a replacement. I often thi=
nk about the word Assertion. But I not=C2=A0sure if the word won't come=
=C2=A0with its own controversies.

Essential for us=
 now is to narrow the intended meaning of the term in the context of GNAP a=
nd then look for the correct replacement,=C2=A0if any.=C2=A0 What about thi=
s?

<In the context of GNAP>
A Clai=
m=C2=A0
=C2=A0 - is=C2=A0an "assertion" of the truth of some properties or att=
ributes of the RO.
=C2=A0 Note-1: A Claim is produced eith=
er by the GS or by another claim source.
=C2=A0 Note-2: A Claim i=
s held and guarded by the Grant Server (GS).
=C2=A0 No=
te-3: A Claim is released by the GS to a Client.=C2=A0
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [REMOVED: "as par=
t of an Authorization", as Justin mentions bellow possibility of a cla=
im to be included in userInfo and other introspection responses]=C2=A0
=C2=A0 Note-4: The release of a Claim is controlled=C2=A0by the RO
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ADD=
ED: "release", to distinguish=C2=A0it from the "production&q=
uot; of the claim. Some Claims are just provided by the RO, some other Clai=
ms are produced by authorities, that take care of verifying the claim and/o=
r legitimating them]=C2=A0=C2=A0

=


I think we should focus on the separation of the d=
elivery mechanism, but I=E2=80=99m not sure what good alternatives would be=
. Perhaps:

=C2=A0- =E2=80=9Caccess right=E2=80=9D =
for things tied to the API/token
=C2=A0- =E2=80=9Cdata response=
=E2=80=9D for things coming back directly to the client
Here you are referring=C2=A0to the target of the info=
rmation. And it is more difficult to nail formalized. A claim might be targ=
eted for the RS and not the Client.

I suggest we f=
irst stay with: "resource access" and "claim release" (=
both Grants as mentioned by Dick above). Rationale being:
- the c=
larification that a Resource is not a Claim, but that both are controlled b=
y the RO
- the clarification of a Claim is held by the GS,
<=
div>- the clarification of a Resource is held by the RS,

I=E2=80=99m not particularly thrilled by =
these names, but I think recent list conversation shows that we need to get=
 away from =E2=80=9Cclaim=E2=80=9D as it=E2=80=99s overloaded.
<=
/div>
Let us look at this after we have narrowed a d=
efinition in the context of GNAP.=C2=A0


Resource Owner (RO) - the party that
=C2=A0 =C2=A0 =C2=A0 =
- controls a Resource,
=C2=A0 =C2=A0 =C2=A0 - relies on the services the=
 GS to manage access to that Resource,
=C2=A0 =C2=A0 =C2=A0 - relies on =
the services of a RS to hold the Resource and guard access to that Resource=
,
=C2=A0 =C2=A0 =C2=A0 - controls a Claim,
=C2=A0 =C2=A0 =C2=A0 - rel=
ies on the services the GS to release that Claim to a Client.

Resour=
ce Server (RS) - the party that=C2=A0
=C2=A0 =C2=A0 =C2=A0 =
- holds a resource and guards access to that resource on behalf of the RO,<=
br>=C2=A0 =C2=A0 =C2=A0 - services the Resource to the requesting Client, p=
rovided the Client presents a valid Authorization.
=C2=A0 =C2=A0 =C2=A0 =
The RS is generally deployed as a web service.

Grant Server (GS) - t=
he party that=C2=A0
=C2=A0 =C2=A0 =C2=A0 - manages access t=
o a Resource on behalf of the RO,
=C2=A0 =C2=A0 =C2=A0 - holds Claims an=
d releases them when consented by the RO.
=C2=A0 =C2=A0 =C2=A0 For each =
Resource access request, the GS might request the Consent of the RO and pro=
duce a corresponding Authorization that is given to the requesting Client.<=
br>

I don=E2=80=99t like =
the shift from =E2=80=9CAuthorization Server=E2=80=9D to =E2=80=9CGrant Ser=
ver=E2=80=9D, and it especially doesn=E2=80=99t make sense in light of the =
definitions of =E2=80=9Cgrant=E2=80=9D and =E2=80=9Cauthorization=E2=80=9D =
above. I believe we should stick with =E2=80=9CAuthorization Server=E2=80=
=9D if it=E2=80=99s a single role. I would also propose that we have a sepa=
rate term for the RO-interactive portion vs. the client-facing portion, as =
has been brought up in a few threads. Maybe these get different names entir=
ely, or maybe they are =E2=80=9Caspects=E2=80=9D of the AS, I=E2=80=99m not=
 sure.
I also did not see any diff=
erence to functions of an AS. But i suggest we shift the discussion on rena=
ming the term GS to another thread and keep the focus on this thread on ela=
borating terms in the context of GNAP.



Consent - act of an RO :
=C2=A0 =C2=A0 =C2=A0 - approving a=
ccess to a Resource, means approval that a Resource he controls can be give=
n to the Client by the RS.
=C2=A0 =C2=A0 =C2=A0 - approving release of a=
 Claim, means approval that a Claim he controls can be included by the GS i=
n an Authorization to be returned to the Client.

Grant - material fo=
rm of an RO Consent. In order not to interact with the RO on each Resource =
access request, the GS might store the RO Consent in the form of a Grant fo=
r reuse.

Authorization - externalized form of a Grant as known to th=
e GS and the RS.
=C2=A0 =C2=A0 =C2=A0 - The GS converts a Grant into an =
Authorization for use in a Resource access request.
=C2=A0 =C2=A0 =C2=A0=
 - The RS evaluates an Authorization to decide on whether or not to release=
 the Resource to the Client.

Client - the party that provides the in=
frastructure used by a User to access a Resource. The client infrastructure=
 is designed to:
=C2=A0 =C2=A0 =C2=A0 - Receive the resource access requ=
est from the User,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to discov=
er authorization requirements,
=C2=A0 =C2=A0 =C2=A0 - Interact with the =
GS to obtain an Authorization to access the Resource,
=C2=A0 =C2=A0 =C2=
=A0 - Interact with the RS to access the Resource on behalf of the User.

I think we should be cl=
ear that what we call the =E2=80=9Cclient=E2=80=9D is a piece of software o=
perated by the user. It=E2=80=99s true that this software might have multip=
le parts of its =E2=80=9Cinfrastructure=E2=80=9D but it=E2=80=99s always so=
ftware.
Yes.=C2=A0
Clien=
t - the party that implements the infrastructure used by a User to access a=
 Resource:
=C2=A0 =C2=A0Note-1: a Client is always a piece of sof=
tware running either on the User device or as a web service.
=C2=
=A0 =C2=A0Note-2:=C2=A0The Client infrastructure is designed to:
=
=C2=A0 =C2=A0 =C2=A0 - receive the resource access request from the User,=C2=A0 =C2=A0 =C2=A0 - interact with the RS to discover authorization req=
uirements,
=C2=A0 =C2=A0 =C2=A0 - interact with the GS to obtain an Auth=
orization to access the Resource,
=C2=A0 =C2=A0 =C2=A0 - interact with t=
he RS to access the Resource on behalf of the User.



User - the party using the infrastructure of =
the Client to gain access to a Resource or a Claim.


In UMA, we call this the =E2=80=9CReques=
ting Party=E2=80=9D, or RqP. We might want to consider adopting this termin=
ology here as well.
I admit the te=
rm User is confusing. Like for GS vs AS above, let us start a new thread on=
 this.=C2=A0



Clarification=
s:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

User vs. RO :=C2=
=A0
=C2=A0 =C2=A0 =C2=A0 - the User is the party using the infras=
tructure of the Client to gain access to a Resource or a Claim,
=C2=A0 =
=C2=A0 =C2=A0 - the RO is the party controlling access to a Resource or con=
trolling the release of a Claim.
In many use cases, User and RO will be =
represented by the same party (see oAuth2), but GNAP exposes use cases wher=
e User and RO are represented by different parties.

User-Agent :
=
User and RO are parties that might be represented by a natural person or an=
 autonomous device. In those cases, User (resp. RO) might need the help of =
an application to interact with other parties. Such an application is gener=
ally referred to as the "User-Agent".

The term =E2=80=9Cuser agent=E2=80=9D is often u=
sed to be equivalent to the web browser, and not the more general use here.=
 I think we=E2=80=99re seeing more =E2=80=9Cagent=E2=80=9D terminology for =
helper applications like digital wallets and AI bots, which would seem to b=
e covered under your definition here.


Feedbacks are welcome.
Yes. We do need =
feedback here.

Just as a summary:=C2=A0
=
- I will update the dictionary after we receive feedback on the definitions=
 of Claim and Client as reformulated in the answer.
- would you s=
tart a new thread for the renaming of GS to AS?
- would you start=
 a new thread for the renaming of Client to Requesting Party.
Thanks a lot for the feedback.

-- 
Francis Poua=
tcha
Co-Founder and Technical Lead
adorsys GmbH & C=
o. KG


--000000000000c2592105ab25857c--


From nobody Thu Jul 23 18: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 3AD9D3A0496 for ; Thu, 23 Jul 2020 18:04:17 -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 Y6iTz2AKw2mi for ; Thu, 23 Jul 2020 18:04:16 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 CBE023A0476 for ; Thu, 23 Jul 2020 18:04:15 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id y3so6805836wrl.4 for ; Thu, 23 Jul 2020 18:04:15 -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=Laf8Z10IpHoV4iCTVfjUvTT9pllZbBjKvCUvLni+lx4=; b=UJtJfWVftakSQYJWnE/+qipOsIEvtX+QZ3K670Ok+G2z1EpL32iB+o4SHCLfhyk9+7 v5CIHnSnwFxJvt7C+pTwMV4vtbqb03GOPjZJfPPj2RA0FXKNzPcReO954yBFnLyEyaml hflfKgTBM0A5Zm7zlFv3RfHYoIFE71k/7T+sI=
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=Laf8Z10IpHoV4iCTVfjUvTT9pllZbBjKvCUvLni+lx4=; b=UmEqRixGQEBPtxJD1uqh+SKiTN0ohMM7RgO7prjAsUMcuvzcZ4h5iv9LYOlxfRZ6aI p8gMQFZnPHoXCkqyu5xJGU1jX6j8/nlXZf+hvyI0jvrzcphzzuNnkwQIA2jTVKiUcEzu 2/7KACHSjzQoiPJzxKiacNcWAGhKLIg0mYWuteTglaPxqQWViu2Bw0c0BNKJSo0KsTIt bP7tlXKaJ3urnPVJp07wp9+ctR4gNyADfGK7mAG9ZxoU5509rZXOa+lGcCksNJhVy01Q WV/BGfiqeGEhXvM/BalunHHRVx9Zzfh9CM58jDk+T5GWTJIc+TcpbJwe5XpYFc8AsEyv ZZ3g==
X-Gm-Message-State: AOAM532PBTIdgWFoCZ5yiPCpHrYHjKLNpzIwSuOSW8seI7OPqpdW2DDe gztkn2yUdO+yiSaA0FlatdEJAvT5CwJDXCubbxgwYvesZR4=
X-Google-Smtp-Source: ABdhPJwR+DMqMXa7WuhGOwME59lZRBFBQ3XVs+XDMQzI5rWAXLf5cd4o4scS2XvVPYHGP/h7OH/BXePO0ynI8Z6fNIQ=
X-Received: by 2002:a5d:45c9:: with SMTP id b9mr6102849wrs.283.1595552654131;  Thu, 23 Jul 2020 18:04:14 -0700 (PDT)
MIME-Version: 1.0
References:          
In-Reply-To: 
From: Francis Pouatcha 
Date: Thu, 23 Jul 2020 21:04:03 -0400
Message-ID: 
To: Justin Richer 
Cc: txauth@ietf.org, Dick Hardt ,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="0000000000002b9d7205ab258ded"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 24 Jul 2020 01:04:17 -0000

--0000000000002b9d7205ab258ded
Content-Type: text/plain; charset="UTF-8"

>
>
> Just as a summary:
> - I will update the dictionary after we receive feedback on the
> definitions of Claim and Client as reformulated in the answer.
> - would you start a new thread for the renaming of GS to AS?
> - would you start a new thread for the renaming of Client to Requesting
> Party.
>
> - would you start a new thread for the renaming of "User" to "Requesting
Party"

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--0000000000002b9d7205ab258ded
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




Just as a summary:=C2=A0
- I w=
ill update the dictionary after we receive feedback on the definitions of C=
laim and Client as reformulated in the answer.
- would you start =
a new thread for the renaming of GS to AS?
- would you start a ne=
w thread for the renaming of Client to Requesting Party.

- would you start a new thread for the rena=
ming of "User" to "Requesting Party"

-- 
=

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


--0000000000002b9d7205ab258ded--


From nobody Thu Jul 23 19:16: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 CC0893A07C2 for ; Thu, 23 Jul 2020 19:16:31 -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 nfLpO5TtgKio for ; Thu, 23 Jul 2020 19:16:28 -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 BF38F3A07BA for ; Thu, 23 Jul 2020 19:16:27 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id y24so2707772wma.1 for ; Thu, 23 Jul 2020 19:16:27 -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=OKXXd7A7NIz0a/kIg/5ex7rPneu/Br2XbsYMLqgnonQ=; b=Kts2J/sFWLcjTEnVkW1b8m36PCMsIFKPlrzjUvqEY/nwd+tmDBZDUiss7Fs6/lF9WR i9AeuPUmcsKV9jCu157qpqiN/yHXQRJevYN3hg7M/1lb+T/91Rh4HDMZ5I8NkRmQLnUV 5ec1M///NqMvpIPh5+mpj1DmNfUh0ooC5PnIU=
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=OKXXd7A7NIz0a/kIg/5ex7rPneu/Br2XbsYMLqgnonQ=; b=B1GYBKAlbbAtRes7p9ZtGS8nFiyvk/86lPkFWs8JnOSv36/RnjIWvRyog0s6LxIc/8 nC3MKXnKRyZkeFABfTY5xrZK7KdcDi4Osu3E6k1dBpiza6V1YisqorCCTwrvY6LWrx12 +f4B8jjaTv3J+3hCgq5/z2iSKWQ2TCkpUrNcPYggvYjVfjRb42NDMc7DYJPmM0+NoJM6 Bks62KBUdYRrxibneuFiv0C83n9W/n4yP0TnkJ64KDFfEiZBPQjkzR2LnlDgdiQK/uk8 a5HIQ1hPrktkGTFfk3ndPGGdcBAXwbJZWXF1PXbtayeWadglBGlWYDkw6eohT1tBeHgI zKVA==
X-Gm-Message-State: AOAM5337DyAvPp+MyrD7dF5AXd3UVtFTdq6nVIAmhmmSVq7pI6d0BVRd UY1ENN3dD9EBWZ+8jjlCoxzok/2R/nX9q9HUwASk/g==
X-Google-Smtp-Source: ABdhPJzhSaFQ0V/4pZLHtymhXh3zRGENg277TUJo/zXAL+g0z3U9oeUcxae+NY5q4jtvsvriZv2d92odUodIrvLH+t8=
X-Received: by 2002:a7b:c952:: with SMTP id i18mr6982295wml.65.1595556986049;  Thu, 23 Jul 2020 19:16:26 -0700 (PDT)
MIME-Version: 1.0
References:          
In-Reply-To: 
From: Francis Pouatcha 
Date: Thu, 23 Jul 2020 22:16:14 -0400
Message-ID: 
To: Dick Hardt 
Cc: Justin Richer , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="0000000000005f726105ab268f7f"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 24 Jul 2020 02:16:32 -0000

--0000000000005f726105ab268f7f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Dick, my feedback inline

@Fabian : i am not yet consistent with using the notation you referred to
in https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en. Still to
come.

On Thu, Jul 23, 2020 at 7:52 PM Dick Hardt  wrote:

> Hi Francis
>
> Thanks again for putting this together. I have taken your definitions and
> adjusted them to match how I think of them. I dropped the term "parties"
> because I did not think it added value. I am explicit about what each par=
ty
> is -- software, a human, or an entity. Let me know where you disagree!
>
>
> Resource - protected data or software functionality
>       - controlled by a Resource Owner (RO),
>       - protected by the Resource Server (RS)
>
Yes

>
> Claim - a statement about the User
>
I would stay with RO not User. I added some clarification after the
feedback of Justin (see below)

>       - may be obtained from the Grant Server (GS) by a Client
>
Yes.

>       - may be a Resource the Client can access through an RS
>
Not sure we need to refer to a Resource as a Claim.

A Claim - an assertion of the truth of some properties or attributes of the
RO.
  Note-1: A Claim is issued either by the GS or by another claim issuer.
  Note-2: A Claim is held and guarded by the Grant Server (GS).
  Note-3: A Claim is released by the GS to a Client.
  Note-4: The permission to release of a Claim is given by the RO.


> Grant - the Claims and/or Resource Access the User and/or RO have granted
> to the Client by the GS
>     - requested by a Client
>     - granted by a GS after any required consent has been obtained from
> the User and/or RO
>
"User and/or RO" is confusing. I suggest we keep the term User out. Term
User is even eligible for renaming. I suggest staying with RO.


> Access Token - an artifact representing the access a client has been
> granted to one or more Resources
>     - created by the GS
>     - presented by the Client when accessing a Resource at an RS
>
An access token might contain Claims.

Access Token - an artifact representing the access a client has been
granted to one or more Resources
  Note-1: An access token is created by the GS
  Note-2: An access token can also contain claims
  Note-3: An access token is presented by the Client when accessing a
Resource at an RS


> Resource Owner (RO) - the entity that
>       - controls a Resource,
>       - has delegated Resource access control to one or more GSes
>       - may be the User
>
Confused here with the word "controls" both at RO and GS. I think RO
delegates Resource access management to GS but keeps control (or decision).

Resource Owner (RO) - the entity that
      - controls a Resource,
      - relies on the services the GS to manage access to that Resource,
      - relies on the services of a RS to hold a Resource and guard access
to that Resource,
      - controls a Claim,
      - relies on the services the GS to release that Claim to a Client.

>
> Resource Server (RS) - the software that controls access to one or more
> Resources
>       - accessed via an API by Clients presenting an access token
>       - accepts access tokens from one or more GSes
>
I suggest "guards" instead of "controls". As access to a resource is
controlled by the RO.

Resource Server (RS) - the software that guards access to one or more
Resources
      - accessed by the Client that presents an access token
      - accepts access tokens from one or more GSes


>
> Grant Server (GS) - the software that manages Grants
>     - has been delegated to manage Resource access by the RO
>     - has been delegated to release Claims about the User
>     - grants the Client access to Resources after obtaining the required
> consent from the RO
>     - provides the Client Claims about the User after obtaining the
> required consent from the User
>
Term User is confusing here. This is why it is eligible for renaming.
- Claims are about RO not User
- Consent is from RO not User.

Grant Server (GS) - the software that manages Grants
    - has been delegated to manage Resource access by the RO
    - has been delegated to release Claims about the RO
    - grants the Client access to Resources after obtaining the required
consent from the RO
    - provides the Client Claims about the RO after obtaining the required
consent from the RO


> Client - the software that wants to access Resources and obtain Claims
>     - executed by a User or a non-human service account
>     - requests Grants from the Grant Server
>     - accesses Resources at an RS using access tokens
>
Client - the software that wants to access Resources and obtain Claims on
behalf of a User or non-human service account
   Note-1: in a typical interaction cycle, the client:
      - receives the resource access request from the User or acts
autonomously,
      - interacts with the RS to discover authorization requirements,
      - interacts with the GS to obtain Access Tokens,
      - interacts with the RS to access the Resource using Access Tokens.


>
> User - the human using a Client
>     - may also be the RO for one or more Resources
>     - may have Claims managed at a GS
>
Not sure a user has to be human.
Maybe first renaming to "Requesting Party" might help with narrowing the
term.


> Some comments:
>
> A Claim is a well understood term in the field. We should use it. It is
> still a Claim if it comes directly from the GS or from an RS.
>
I do not understand why a Resource release by an RS shall be h to as a
claim, even if the content of the Resource is an assertion. It will lead to
confusion. If we limit claims to information GS releases into Token, User
Info, and other objects it returns, this will help separate
responsibilities between GS and RS. As soon as RS services and information,
this is called a Resource, no matter the nature of the content of that
information.


> I think Grant Server is the right term. A Grant contains claims and/or
> access to resources. I have defined all the terms above without using the
> term authorization. :) -- I am pondering renaming most things called
> Authorization in XAuth to Access.
>
Ok.

>
> Claim Issuer - I think we may need to add this party to our nomenclature.
> This is the entity that issues Claims. It may be a GS or an RS.
>
Yes for the term "Claim Issuer".

No for a "Claim Issuer" being an RS. At least not in its role as an RS. RS
shall focus on guarding and serving a Resource. Issuing a claim is
authoritative and might come with more complexity (verification of
authenticity). Having an RS issue a claim will overload the role of an RS
and increase the complexity of the framework.

/Francis


> /Dick
>
> =E1=90=A7
>
> On Thu, Jul 23, 2020 at 8:07 AM Justin Richer  wrote:
>
>> Up-front question to the Chairs, do we have a good place to capture this
>> kind of thing? A non-spec document like this would be a good candidate f=
or
>> a wiki page. Do we have plans to set up a GitHub repository or similar? =
If
>> so we could use the wiki capabilities there to at least get this stuff
>> written down. Use cases would be good to capture there as well.
>>
>>
>>
>> Francis,
>>
>> First, I want to thank you for putting the work in to getting some
>> vocabulary down. This is not an easy task! Some notes on specific items
>> inline below.
>>
>> On Jul 21, 2020, at 8:33 PM, Francis Pouatcha  wrote:
>>
>> Hello Dick, Justin, Tom, Denis,
>>
>> Below is a new version of the dictionary includings comments from
>> different threads. Change log includes:
>> - avoided the expression "owns a resource" in favor of the expression
>> "controls a resource"
>> - included the clarification "resource access" and "claim release"
>> - included a clarification User vs. RO
>> - tried to clarify the word User-Agent
>> - added the definition of a Claim
>>
>> Terms
>> =3D=3D=3D=3D=3D
>>
>> Party - represents a role in the GNAP protocol flow. A party can take th=
e
>> form of a web service, an application installed on the user device and
>> acting autonomously or the form of a natural person (resp. of an autonom=
ous
>> device) using an application to interact with other parties.
>>
>> Resource - a piece of data or web service
>>       - controlled by a Resource Owner (RO),
>>       - held and guarded by a Resource Server (RS) and
>>       - serviced by the RS to a Client, if the Client provides a valid
>> Authorization.
>>
>> Claim - a piece of data
>>       - controlled by a Resource Owner (RO),
>>       - held and guarded by the Grant Server (GS) and
>>       - released by the GS to a Client as part of an Authorization.
>>
>>
>> The differentiation between =E2=80=9Cresource=E2=80=9D and =E2=80=9Cclai=
m=E2=80=9D is important since it
>> separates items that get tied to an access token=E2=80=99s rights (=E2=
=80=9Cresources=E2=80=9D)
>> with items that come back directly to the client without going through a
>> separate API. The term =E2=80=9Cclaim=E2=80=9D is problematic here thoug=
h because it is
>> used broadly in the community to mean, roughly, =E2=80=9Ca statement abo=
ut the end
>> user=E2=80=9D. It=E2=80=99s therefore both too broad and too narrow in t=
he wrong ways: a
>> =E2=80=9Cclaim=E2=80=9D could come back as part of an API response, like=
 the OIDC UserInfo
>> Endpoint, and so it=E2=80=99s not a good name for this item. Even the OI=
DC =E2=80=9Cclaims=E2=80=9D
>> query language defines several different targets for returning the =E2=
=80=9Cclaims=E2=80=9D
>> about the user, and none of them match the method that GNAP is looking t=
o
>> use here. A =E2=80=9Cclaim=E2=80=9D is also generally understood in the =
identity community
>> to be a statement about the user, and the data coming back directly to t=
he
>> client might be about the user or something else, especially as we look
>> forward to extensions of GNAP.
>>
>> I think we should focus on the separation of the delivery mechanism, but
>> I=E2=80=99m not sure what good alternatives would be. Perhaps:
>>
>>  - =E2=80=9Caccess right=E2=80=9D for things tied to the API/token
>>  - =E2=80=9Cdata response=E2=80=9D for things coming back directly to th=
e client
>>
>> I=E2=80=99m not particularly thrilled by these names, but I think recent=
 list
>> conversation shows that we need to get away from =E2=80=9Cclaim=E2=80=9D=
 as it=E2=80=99s overloaded.
>>
>>
>> Resource Owner (RO) - the party that
>>       - controls a Resource,
>>       - relies on the services the GS to manage access to that Resource,
>>       - relies on the services of a RS to hold the Resource and guard
>> access to that Resource,
>>       - controls a Claim,
>>       - relies on the services the GS to release that Claim to a Client.
>>
>> Resource Server (RS) - the party that
>>       - holds a resource and guards access to that resource on behalf of
>> the RO,
>>       - services the Resource to the requesting Client, provided the
>> Client presents a valid Authorization.
>>       The RS is generally deployed as a web service.
>>
>> Grant Server (GS) - the party that
>>       - manages access to a Resource on behalf of the RO,
>>       - holds Claims and releases them when consented by the RO.
>>       For each Resource access request, the GS might request the Consent
>> of the RO and produce a corresponding Authorization that is given to the
>> requesting Client.
>>
>>
>> I don=E2=80=99t like the shift from =E2=80=9CAuthorization Server=E2=80=
=9D to =E2=80=9CGrant Server=E2=80=9D, and
>> it especially doesn=E2=80=99t make sense in light of the definitions of =
=E2=80=9Cgrant=E2=80=9D and
>> =E2=80=9Cauthorization=E2=80=9D above. I believe we should stick with =
=E2=80=9CAuthorization
>> Server=E2=80=9D if it=E2=80=99s a single role. I would also propose that=
 we have a separate
>> term for the RO-interactive portion vs. the client-facing portion, as ha=
s
>> been brought up in a few threads. Maybe these get different names entire=
ly,
>> or maybe they are =E2=80=9Caspects=E2=80=9D of the AS, I=E2=80=99m not s=
ure.
>>
>>
>> Consent - act of an RO :
>>       - approving access to a Resource, means approval that a Resource h=
e
>> controls can be given to the Client by the RS.
>>       - approving release of a Claim, means approval that a Claim he
>> controls can be included by the GS in an Authorization to be returned to
>> the Client.
>>
>> Grant - material form of an RO Consent. In order not to interact with th=
e
>> RO on each Resource access request, the GS might store the RO Consent in
>> the form of a Grant for reuse.
>>
>> Authorization - externalized form of a Grant as known to the GS and the
>> RS.
>>       - The GS converts a Grant into an Authorization for use in a
>> Resource access request.
>>       - The RS evaluates an Authorization to decide on whether or not to
>> release the Resource to the Client.
>>
>> Client - the party that provides the infrastructure used by a User to
>> access a Resource. The client infrastructure is designed to:
>>       - Receive the resource access request from the User,
>>       - Interact with the RS to discover authorization requirements,
>>       - Interact with the GS to obtain an Authorization to access the
>> Resource,
>>       - Interact with the RS to access the Resource on behalf of the Use=
r.
>>
>>
>> I think we should be clear that what we call the =E2=80=9Cclient=E2=80=
=9D is a piece of
>> software operated by the user. It=E2=80=99s true that this software migh=
t have
>> multiple parts of its =E2=80=9Cinfrastructure=E2=80=9D but it=E2=80=99s =
always software.
>>
>>
>> User - the party using the infrastructure of the Client to gain access t=
o
>> a Resource or a Claim.
>>
>>
>> In UMA, we call this the =E2=80=9CRequesting Party=E2=80=9D, or RqP. We =
might want to
>> consider adopting this terminology here as well.
>>
>>
>> Clarifications:
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> User vs. RO :
>>       - the User is the party using the infrastructure of the Client to
>> gain access to a Resource or a Claim,
>>       - the RO is the party controlling access to a Resource or
>> controlling the release of a Claim.
>> In many use cases, User and RO will be represented by the same party (se=
e
>> oAuth2), but GNAP exposes use cases where User and RO are represented by
>> different parties.
>>
>> User-Agent :
>> User and RO are parties that might be represented by a natural person or
>> an autonomous device. In those cases, User (resp. RO) might need the hel=
p
>> of an application to interact with other parties. Such an application is
>> generally referred to as the "User-Agent".
>>
>>
>> The term =E2=80=9Cuser agent=E2=80=9D is often used to be equivalent to =
the web browser,
>> and not the more general use here. I think we=E2=80=99re seeing more =E2=
=80=9Cagent=E2=80=9D
>> terminology for helper applications like digital wallets and AI bots, wh=
ich
>> would seem to be covered under your definition here.
>>
>>
>> Feedbacks are welcome.
>>
>>
>> Again, thanks so much for getting this going!
>>
>>  =E2=80=94 Justin
>>
>> Best regards,
>> /Francis
>>
>>
>> On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha  wrote:
>>
>>>
>>>
>>> On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt  wrote=
:
>>>
>>>>
>>>>
>>>> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha 
>>>> wrote:
>>>>
>>>>>
>>>>> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt 
>>>>> wrote:
>>>>>
>>>>>> FYI: I consider the release of claims to be an "authorization" as
>>>>>> well.
>>>>>>
>>>>> Great. Then it is included.
>>>>>
>>>>
>>>> I pivoted to using the term Grant rather than authorization so that it
>>>> included both authorizing access to a resource, and authorizing the re=
lease
>>>> of an identity claim.
>>>>
>>>> Perhaps we should not use the word "authorization"?
>>>>
>>> Authorization is currently used to refer to the token issued by the
>>> GSand presented to the RS by the Client. I have no alternative word for=
 now.
>>>
>>>>
>>>> "resource access" and "claim release"
>>>>
>>>> A Grant then covers both?
>>>>
>>> Yes, Great! The word Grant fits best for both. I suggest adding this
>>> clarification to that dictionary.
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>> IE, the user authorizes the GS to release a DOB claim to a Client.
>>>>>>
>>>>> I guess you mean the "RO" authorizes the GS to release a DOB!
>>>>>
>>>>
>>>> Yes, thanks for clarifying!
>>>>
>>>> /Dick
>>>>
>>>>>
>>>
>>> --
>>> 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/
>>
>>
>>

--=20
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--0000000000005f726105ab268f7f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Dick, my feedback inline
=

@Fabian : i am not yet consistent with using the notation yo=
u referred=C2=A0to in=C2=A0https://www.iso.org/obp/ui/#iso:=
std:iso-iec:27000:ed-5:v1:en. Still to come.

On Thu, Jul 23, 2020 at 7:5=
2 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis

Thank=
s again for putting=C2=A0this together. I have taken your definitions and a=
djusted them to match how I think of them. I dropped the term "parties=
" because I did not think it added value. I am explicit about what eac=
h party is -- software, a human, or an entity. Let me know where you disagr=
ee!


Resource - protected data or software func=
tionality
=C2=A0 =C2=A0 =C2=A0 - controlled by a Resource Owner (RO),=C2=A0 =C2=A0 =C2=A0 - protected by the Resource Server (RS)
Yes=C2=A0

Claim - a statement about the User
=

I would stay with RO not User. I added some c=
larification=C2=A0after the feedback of Justin (see below)=C2=A0
=C2=A0 =
=C2=A0 =C2=A0 - may be obtained from the Grant Server (GS) by a Client
<=
/div>
Yes.=C2=A0
=C2=A0 =C2=A0 =C2=A0 - may be a R=
esource the Client can access through an RS
Not sure we need to refer to a Resource as a Claim.

<=
div>
A Claim - an a=
ssertion of the truth of some properties or attributes of the RO.
=C2=A0 Note-1: A Claim is issued either by the GS or by another cla=
im issuer.
=C2=A0 Note-2: A Claim is held and guarded by the Gran=
t Server (GS).
=C2=A0 Note-3: A Claim is released by t=
he GS to a Client.=C2=A0
=C2=A0 Note-4: The permission to release=
 of a Claim is given by the RO.


Grant - the =
Claims and/or Resource Access the User and/or RO have granted to the Client=
 by the GS
=C2=A0 =C2=A0 - requested by a Client
=C2=A0 =C2=A0 - gran=
ted by a GS after any required consent has been obtained from the User and/=
or RO
"User and/or RO" is confus=
ing. I suggest we keep the term User out. Term User is even eligible for re=
naming. I suggest staying with RO.


Access Token - an a=
rtifact representing the access a client has been granted to one or more Re=
sources
=C2=A0 =C2=A0 - created by the GS
=C2=A0 =C2=A0 - pres=
ented by the Client when accessing a Resource at an RS
An access token might contain=C2=A0Claims.

Access Token=C2=A0-=C2=A0an=
 artifact representing the access a client has been granted to one or more =
Resources
=C2=A0 Note-1: An access token is=C2=A0created by the G=
S
=C2=A0 Note-2:=C2=A0An access token can also contain claims
=C2=A0 Note-3: An access token is=C2=A0presented by the Client when =
accessing a Resource at an RS
=C2=A0
Resource Owner (RO) =
- the entity that
=C2=A0 =C2=A0 =C2=A0 - controls a Resource,
=C2=A0 =
=C2=A0 =C2=A0 - has delegated Resource access control to one or more GSes=C2=A0 =C2=A0 =C2=A0 - may be the User
C=
onfused here with the word "controls" both at RO and GS. I think =
RO delegates Resource access management to GS but keeps control (or decisio=
n).

Resource Ow=
ner (RO) - the entity that
=C2=A0 =C2=A0 =C2=A0 - controls a Reso=
urce,
=C2=A0 =C2=A0 =C2=A0 - relies on the services the GS to manage acc=
ess to that Resource,
=C2=A0 =C2=A0 =C2=A0 - relies on the services of a=
 RS to hold a Resource and guard access to that Resource,
=C2=A0 =C2=A0 =
=C2=A0 - controls a Claim,
=C2=A0 =C2=A0 =C2=A0 - relies on the services=
 the GS to release that Claim to a Client.

Resource Server (RS) -=
 the software that controls access to one or more Resources
=C2=A0 =C2=
=A0 =C2=A0 - accessed via an API by Clients presenting an access token
=
=C2=A0 =C2=A0 =C2=A0 - accepts access tokens from one or more GSes 
I suggest "guards" instead of "con=
trols". As access to a resource is controlled by the RO.=C2=A0

Resource Server (RS) -=C2=
=A0the software that guards access to one or more Resources
=C2=A0 =C2=A0 =
=C2=A0 - accessed by the Client that=C2=A0presents an access token
=C2=A0 =
=C2=A0 =C2=A0 - accepts access tokens from one or more GSes
=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">

=
Grant Server (GS) - the software that manages Grants
=C2=A0 =C2=A0 - has=
 been delegated to manage Resource access by the RO
=C2=A0 =C2=A0 - has =
been delegated to release Claims about the User
=C2=A0 =C2=A0 - grants t=
he Client access to Resources after obtaining the required consent from the=
 RO
=C2=A0 =C2=A0 - provides the Client Claims about the User after obta=
ining the required consent from the User
T=
erm User is confusing here. This is why it is eligible for renaming.
<=
div>- Claims are about RO=C2=A0not User
- Consent is from RO not =
User.
=C2=A0
Grant Server (GS) - the software that manages Grants=C2=A0 =
=C2=A0 - has been delegated to manage Resource access by the RO
=C2=A0 =C2=
=A0 - has been delegated to release Claims about the RO
=C2=A0 =C2=A0 - gr=
ants the Client access to Resources after obtaining the required consent fr=
om the RO
=C2=A0 =C2=A0 - provides the Client Claims about the RO after ob=
taining the required consent from the RO
=C2=A0
=

Client - the software that wants to access Resources and obtain Claims=

=C2=A0 =C2=A0 - executed by a User or a non-human service account 
=
=C2=A0 =C2=A0 - requests Grants from the Grant Server
=C2=A0 =C2=A0 - ac=
cesses Resources at an RS using access tokens
<=
span style=3D"color:rgb(80,0,80)">Client -=C2=A0the software that wa=
nts to access Resources and obtain Claims on behalf of a=C2=A0User or non-h=
uman service account
=C2=A0 =C2=A0Note-1: i=
n a typical interaction cycle, the client:
=C2=A0 =C2=A0 =C2=A0 - receives the resource access request from the =
User or acts autonomously,
=C2=A0 =C2=A0 =C2=A0 - interacts with the RS to d=
iscover authorization requirements,
=
=C2=A0 =C2=A0 =C2=A0 - interacts with th=
e GS to obtain Access Tokens,
<=
span style=3D"color:rgb(80,0,80)">=C2=A0 =C2=A0 =C2=A0 - interacts with the=
 RS to access the Resource using Access Tokens.
=C2=A0
<=
br>User - the human using a Client
=C2=A0 =C2=A0 - may also be the RO fo=
r one or more Resources
=C2=A0 =C2=A0 - may have Claims managed at a GS<=
br>
Not sure a user has to be human.=C2=A0
=

Maybe first renaming to "Requesting Party" might help =
with narrowing the term.


Some comments:

A Claim is a well understood =
term in the field. We should use it. It is still a Claim if it comes direct=
ly from the GS or from an RS.=C2=A0
I do not u=
nderstand why a Resource release by an RS shall be h to as a claim, even if=
 the content of the Resource is an assertion. It will lead to confusion. If=
 we limit claims to information GS releases into Token, User Info, and othe=
r objects it returns, this will help separate responsibilities between GS a=
nd RS. As soon as RS services and information, this is called a Resource, n=
o matter the nature of the content of that information.

I think Grant Server is the right term. A Grant contains claim=
s and/or access to resources. I have defined all the terms above without us=
ing the term authorization. :) -- I am pondering renaming most things calle=
d Authorization in XAuth to Access.
Ok.=C2=A0<=
/div>

Claim Issuer - I think we may need to add this party to ou=
r nomenclature. This is the entity that issues Claims. It may be a GS or an=
 RS.=C2=A0
Yes for the term "Claim Issuer=
".

No for a "Claim Issuer" being an=
 RS. At least not in its role as an RS. RS shall focus on guarding and serv=
ing a Resource. Issuing a claim is authoritative=C2=A0and might come with m=
ore complexity=C2=A0(verification of authenticity). Having an RS issue a cl=
aim will overload the role of an RS and increase the complexity of the fram=
ework.

/Francis


/D=
ick

3D""=E1=90=A7

On Thu, Jul 23, 2020=
 at 8:07 AM Justin Richer <jricher@mit.edu> wrote:
Up-front question to the Chairs, do we hav=
e a good place to capture this kind of thing? A non-spec document like this=
 would be a good candidate for a wiki page. Do we have plans to set up a Gi=
tHub repository or similar? If so we could use the wiki capabilities there =
to at least get this stuff written down. Use cases would be good to capture=
 there as well.=C2=A0



Fra=
ncis,

First, I want to thank you for putting the work in=
 to getting some vocabulary down. This is not an easy task! Some notes on s=
pecific items inline below.

On J=
ul 21, 2020, at 8:33 PM, Francis Pouatcha <fpo@adorsys.de> wrote:

Hello Dick, Justin, Tom, Denis,

Below=C2=A0is a new version of the dictionary includings comments=C2=A0fro=
m different=C2=A0threads. Change log includes:
- avoided the expr=
ession "owns a resource" in favor of the expression "control=
s=C2=A0a resource"
- included the clarification=C2=A0"r=
esource access" and "claim release"
- included a c=
larification User vs. RO
- tried to clarify the word User-Agent
- added the definition of a Claim

Terms=3D=3D=3D=3D=3D

Party - represents a role in the GNAP protocol flo=
w. A party can take the form of a web service, an application installed on =
the user device and acting autonomously or the form of a natural person (re=
sp. of an autonomous device) using an application to interact with other pa=
rties.

Resource - a piece of data or web service
=C2=A0 =C2=A0 =
=C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - hel=
d and guarded by a Resource Server (RS) and
=C2=A0 =C2=A0 =C2=A0 - servi=
ced by the RS to a Client, if the Client provides a valid Authorization.
Claim - a piece of data
=C2=A0 =C2=A0 =C2=A0 - controlled by a Reso=
urce Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - held and guarded by the Grant Se=
rver (GS) and
=C2=A0 =C2=A0 =C2=A0 - released by the GS to a Client as p=
art of an Authorization.

<=
div>The differentiation between =E2=80=9Cresource=E2=80=9D and =E2=80=9Ccla=
im=E2=80=9D is important since it separates items that get tied to an acces=
s token=E2=80=99s rights (=E2=80=9Cresources=E2=80=9D) with items that come=
 back directly to the client without going through a separate API. The term=
 =E2=80=9Cclaim=E2=80=9D is problematic here though because it is used broa=
dly in the community to mean, roughly, =E2=80=9Ca statement about the end u=
ser=E2=80=9D. It=E2=80=99s therefore both too broad and too narrow in the w=
rong ways: a =E2=80=9Cclaim=E2=80=9D could come back as part of an API resp=
onse, like the OIDC UserInfo Endpoint, and so it=E2=80=99s not a good name =
for this item. Even the OIDC =E2=80=9Cclaims=E2=80=9D query language define=
s several different targets for returning the =E2=80=9Cclaims=E2=80=9D abou=
t the user, and none of them match the method that GNAP is looking to use h=
ere. A =E2=80=9Cclaim=E2=80=9D is also generally understood in the identity=
 community to be a statement about the user, and the data coming back direc=
tly to the client might be about the user or something else, especially as =
we look forward to extensions of GNAP.=C2=A0

I thi=
nk we should focus on the separation of the delivery mechanism, but I=E2=80=
=99m not sure what good alternatives would be. Perhaps:

=C2=A0- =E2=80=9Caccess right=E2=80=9D for things tied to the API/tok=
en
=C2=A0- =E2=80=9Cdata response=E2=80=9D for things coming back=
 directly to the client

I=E2=80=99m not particular=
ly thrilled by these names, but I think recent list conversation shows that=
 we need to get away from =E2=80=9Cclaim=E2=80=9D as it=E2=80=99s overloade=
d.


Resource Owner (RO) - the party that
=C2=A0 =C2=A0 =C2=A0 - co=
ntrols a Resource,
=C2=A0 =C2=A0 =C2=A0 - relies on the services the GS =
to manage access to that Resource,
=C2=A0 =C2=A0 =C2=A0 - relies on the =
services of a RS to hold the Resource and guard access to that Resource,=C2=A0 =C2=A0 =C2=A0 - controls a Claim,
=C2=A0 =C2=A0 =C2=A0 - relies =
on the services the GS to release that Claim to a Client.

Resource S=
erver (RS) - the party that=C2=A0
=C2=A0 =C2=A0 =C2=A0 - ho=
lds a resource and guards access to that resource on behalf of the RO,
=
=C2=A0 =C2=A0 =C2=A0 - services the Resource to the requesting Client, prov=
ided the Client presents a valid Authorization.
=C2=A0 =C2=A0 =C2=A0 The=
 RS is generally deployed as a web service.

Grant Server (GS) - the =
party that=C2=A0
=C2=A0 =C2=A0 =C2=A0 - manages access to a=
 Resource on behalf of the RO,
=C2=A0 =C2=A0 =C2=A0 - holds Claims and r=
eleases them when consented by the RO.
=C2=A0 =C2=A0 =C2=A0 For each Res=
ource access request, the GS might request the Consent of the RO and produc=
e a corresponding Authorization that is given to the requesting Client.
=


I don=E2=80=99t like the=
 shift from =E2=80=9CAuthorization Server=E2=80=9D to =E2=80=9CGrant Server=
=E2=80=9D, and it especially doesn=E2=80=99t make sense in light of the def=
initions of =E2=80=9Cgrant=E2=80=9D and =E2=80=9Cauthorization=E2=80=9D abo=
ve. I believe we should stick with =E2=80=9CAuthorization Server=E2=80=9D i=
f it=E2=80=99s a single role. I would also propose that we have a separate =
term for the RO-interactive portion vs. the client-facing portion, as has b=
een brought up in a few threads. Maybe these get different names entirely, =
or maybe they are =E2=80=9Caspects=E2=80=9D of the AS, I=E2=80=99m not sure=
.

=


Consent - act of an RO :
=C2=A0 =C2=A0 =C2=A0 - approving acces=
s to a Resource, means approval that a Resource he controls can be given to=
 the Client by the RS.
=C2=A0 =C2=A0 =C2=A0 - approving release of a Cla=
im, means approval that a Claim he controls can be included by the GS in an=
 Authorization to be returned to the Client.

Grant - material form o=
f an RO Consent. In order not to interact with the RO on each Resource acce=
ss request, the GS might store the RO Consent in the form of a Grant for re=
use.

Authorization - externalized form of a Grant as known to the GS=
 and the RS.
=C2=A0 =C2=A0 =C2=A0 - The GS converts a Grant into an Auth=
orization for use in a Resource access request.
=C2=A0 =C2=A0 =C2=A0 - T=
he RS evaluates an Authorization to decide on whether or not to release the=
 Resource to the Client.

Client - the party that provides the infras=
tructure used by a User to access a Resource. The client infrastructure is =
designed to:
=C2=A0 =C2=A0 =C2=A0 - Receive the resource access request =
from the User,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to discover a=
uthorization requirements,
=C2=A0 =C2=A0 =C2=A0 - Interact with the GS t=
o obtain an Authorization to access the Resource,
=C2=A0 =C2=A0 =C2=A0 -=
 Interact with the RS to access the Resource on behalf of the User.

I think we should be clear t=
hat what we call the =E2=80=9Cclient=E2=80=9D is a piece of software operat=
ed by the user. It=E2=80=99s true that this software might have multiple pa=
rts of its =E2=80=9Cinfrastructure=E2=80=9D but it=E2=80=99s always softwar=
e.


User - the party using the infrastructure of the Client to gain a=
ccess to a Resource or a Claim.

=

In UMA, we call this the =E2=80=9CRequesting Party=E2=80=9D,=
 or RqP. We might want to consider adopting this terminology here as well.<=
/div>

Clarifications:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

User=
 vs. RO :=C2=A0
=C2=A0 =C2=A0 =C2=A0 - the User is the part=
y using the infrastructure of the Client to gain access to a Resource or a =
Claim,
=C2=A0 =C2=A0 =C2=A0 - the RO is the party controlling access to =
a Resource or controlling the release of a Claim.
In many use cases, Use=
r and RO will be represented by the same party (see oAuth2), but GNAP expos=
es use cases where User and RO are represented by different parties.
User-Agent :
User and RO are parties that might be represented by a nat=
ural person or an autonomous device. In those cases, User (resp. RO) might =
need the help of an application to interact with other parties. Such an app=
lication is generally referred to as the "User-Agent".
<=
/div>

The term =E2=80=9Cuser agent=E2=
=80=9D is often used to be equivalent to the web browser, and not the more =
general use here. I think we=E2=80=99re seeing more =E2=80=9Cagent=E2=80=9D=
 terminology for helper applications like digital wallets and AI bots, whic=
h would seem to be covered under your definition here.


Feedbacks are=
 welcome.


=
Again, thanks so much for getting this going!

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

Best regards,
/Francis

=

On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha =
<fpo@adorsys.de&=
gt; wrote:


--=C2=A0


--=C2=A0





-- 


--0000000000005f726105ab268f7f--


From nobody Thu Jul 23 19:17: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 56DA93A0811 for ; Thu, 23 Jul 2020 19:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.027
X-Spam-Level: 
X-Spam-Status: No, score=-0.027 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_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 xPwKHXZWuYQj for ; Thu, 23 Jul 2020 19:17:15 -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 A21EF3A080E for ; Thu, 23 Jul 2020 19:17:14 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id 140so4383209lfi.5 for ; Thu, 23 Jul 2020 19:17:14 -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:cc; bh=53mXCZfVGVQ0F/twVHGMRClbxXB6entXK9DM7dttnbU=; b=uQA5xUOTH6teDkZIncEJ+Vo35vpKnNpWSpGUyyXkQTs5d4cZhX/lBe9Zwfr1ndcEJ/ BhzWt0V39BzwLWI50n5zVShNWBW6Pnnsb+UJVlH5vfSKzq4pK5GQj/RIMRAgZMUn0KSB jxrnSE0XQqvqfXjYLH/zmDQHI1l+y/o1JzKgNoTaV8uH4tFVEzzKnIT4LY+HH1lI0sNB MCoMVHhZmL5qr3CNL6RnN+TzYsIzVTdI3ZdAwDKMc5gQlV9K1NLAhvdRonIlflp6YrjI //IXmhB74XHZCmbeyUX1Ol6kpYOhl42bCqajruKVnJiyvTMDgHTd4kBFHHbeVt414kqA q2Jg==
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:cc; bh=53mXCZfVGVQ0F/twVHGMRClbxXB6entXK9DM7dttnbU=; b=lMCIOGK+cI5qetQvtVLGeMt7SPLI+wXHGJtzROZVZlFQ1jXMxLx+0AZpt+1h/0skAj 7G+qmKnP04MI9+7hTuGEcxGouJ36INiaKOxx185y6R/gGtO7DAzcks37rUUvrt7uSrUL LKYQFXpZLnyqBy0wEOiqUyKybww0YmpJnj9Cjv+hNbUcev2/CYpuSiDAc3+88Y0IsGv+ KFPybmbuWsghiGuL0KQHUu0YhOWL/ujEmRICobV4flMFrFoqf5LW1fU5CQutvRw2b9Nd +epY4TlfaQotmw+OtyxiW63QB3nOy/FR89STRjJBjC9uX9AuXkq1peFK9ipyQvqQLQfl D/fQ==
X-Gm-Message-State: AOAM531rjKvOgVtESRty68jjxVhGJoo7ec/U+DJ5lHKs2BzUQNeKxztr yAx+Yg+A1811nUB8JTfYKz0SGdO2AaMi/Lh+evs=
X-Google-Smtp-Source: ABdhPJwkyqg8Jnw2L9e9aGyCoHFVHn3olB08/0YiLAmcsDov8rjvx1SFjyGzOsaf148gNNHlEvVjOzW74IDdQPIbFIU=
X-Received: by 2002:a19:fc14:: with SMTP id a20mr3722442lfi.0.1595557032680; Thu, 23 Jul 2020 19:17:12 -0700 (PDT)
MIME-Version: 1.0
From: Dick Hardt 
Date: Thu, 23 Jul 2020 19:16:36 -0700
Message-ID: 
To: Yaron Sheffer , Leif Johansson 
Cc: Justin Richer , txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000026e90c05ab269298"
Archived-At: 
Subject: [Txauth] using github.com/ietf-wg-gnap
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, 24 Jul 2020 02:17:23 -0000

--00000000000026e90c05ab269298
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Justin brought up the decision on where we are going to capture our work,
and if we would do it on GitHub.

I'm supportive of that. Per

https://tools.ietf.org/html/draft-ietf-git-using-github

there are a number of choices of how to use GitHub, and which features to
use in the WG.

Config is covered by:

https://tools.ietf.org/html/draft-ietf-git-github-wg-configuration

Note these documents are still being worked on, but perhaps we can give
that WG feedback on their docs?

/Dick


=E1=90=A7

--00000000000026e90c05ab269298
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Justin brought up the decision on where we are going to ca=
pture our work, and if we would do it on GitHub.

I'm=
 supportive of that. Per=C2=A0


there are a =
number of choices of how to use GitHub, and which features to use in the WG=
.

Config is covered by:

<=
a href=3D"https://tools.ietf.org/html/draft-ietf-git-github-wg-configuratio=
n">https://tools.ietf.org/html/draft-ietf-git-github-wg-configuration

Note these documents are still being worked on,=
 but perhaps we can give that WG feedback on their docs?

/Dick

=C2=A0
3D""=E1=90=
=A7


--00000000000026e90c05ab269298--


From nobody Thu Jul 23 19:44: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 404923A085C for ; Thu, 23 Jul 2020 19:44:06 -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 WOKGYqUMGuDg for ; Thu, 23 Jul 2020 19:44:02 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 BA3983A0859 for ; Thu, 23 Jul 2020 19:44:01 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id h22so8460600lji.9 for ; Thu, 23 Jul 2020 19:44:01 -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=mahh3VATUbUWGyB89r11OlYyQLby6OpJ/Zn1Xmt1gHY=; b=P5y5QJ2bnerO8g57aLZs4ZQItAiLE9zCviLKBp28vUJXZ3dd+K9ReKsBvy73p+g4LO cKxfC+rTJfRejzgM3a7BYq4cZgRgB2U/seEe0QZ3cx7Bfqaa+/AYWyI2pnun2LfWPMBv jItQNsbwrNw31r76SlN7Rh6OAuv4BvowomK3rAlqnW3NwZs+TKKGrzmgbSkg2hdszDcZ ZV4wO8C/ElN5GY/DCt6as06hvTCMhT81x2tczAs+QMh2azADOQ+oGPJKOS4ltWs2OAbm MkWTgeZtxKsFQBXMEsy+XgWr47ujbpPxLZdeL7q8MsrOQYjy0amCC1kx1ocUBwR6i2Ef l9xQ==
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=mahh3VATUbUWGyB89r11OlYyQLby6OpJ/Zn1Xmt1gHY=; b=qcLLydknxF2vdPjvuQHCS6h+dNyVOvu7tpe5eYq/dLirhprufLcFkeW4vtpiFfavPD MFVORYzq3mZ7j/VCeWaW/+b4JWrl/HjpIOKDqKUCLTqOywSPU5yDtc56wTzI2cpSt/79 dWIJf0DE0ONM0QzcjyedOHilLVPeddABlpggZ2vTYhp5BL6buwbks/OhYF+sTLlOp4Om ijgLPtENsCptO/o8Z3b6xZQaIQ2Iw6oUYutkQvMgrUMLmgqGnMFcdI1s3TaTtZiR9Efs G24PGxX60jyCyyLFWt6jD3DtbkcM5iSrLzWcru6+jPkgeD7BuiUDPOv92fJ7f5KiyAar k6mA==
X-Gm-Message-State: AOAM533tRkYKYvB6DKBFQwjVW+jqd/lytAnf29nLDU+xcMx594oh/OTo zl0iGIlTfxSgwdvmPujW27LrNnlZ1wrTzpfLiXU=
X-Google-Smtp-Source: ABdhPJzVupno+Lz7+bUaRO0n4poLOKDvxNJKPFCEPdC6V0oigAGQHOSg9rTAffqk1zZHLcgQKCZXYFzObfP8AKvWJFo=
X-Received: by 2002:a2e:8316:: with SMTP id a22mr3072026ljh.246.1595558639725;  Thu, 23 Jul 2020 19:43:59 -0700 (PDT)
MIME-Version: 1.0
References:           
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 23 Jul 2020 19:43:15 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: Justin Richer , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="000000000000f0721405ab26f1e4"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 24 Jul 2020 02:44:06 -0000

--000000000000f0721405ab26f1e4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 23, 2020 at 7:16 PM Francis Pouatcha  wrote:

> Hello Dick, my feedback inline
>
> @Fabian : i am not yet consistent with using the notation you referred to
> in https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en. Still to
> come.
>
> On Thu, Jul 23, 2020 at 7:52 PM Dick Hardt  wrote:
>
>> Hi Francis
>>
>> Thanks again for putting this together. I have taken your definitions an=
d
>> adjusted them to match how I think of them. I dropped the term "parties"
>> because I did not think it added value. I am explicit about what each pa=
rty
>> is -- software, a human, or an entity. Let me know where you disagree!
>>
>>
>> Resource - protected data or software functionality
>>       - controlled by a Resource Owner (RO),
>>       - protected by the Resource Server (RS)
>>
> Yes
>
>>
>> Claim - a statement about the User
>>
> I would stay with RO not User. I added some clarification after the
> feedback of Justin (see below)
>




>       - may be obtained from the Grant Server (GS) by a Client
>>
> Yes.
>
>>       - may be a Resource the Client can access through an RS
>>
> Not sure we need to refer to a Resource as a Claim.
>

Here is why I say a Claim may be a Resource.

A Claim may be obtained by a Client calling an RS. This is effectively what
the userinfo endpoint is in OpenID Connect. A Client may also update a
Claim that is managed by an RS.


>
> A Claim - an assertion of the truth of some properties or attributes of
> the RO.
>   Note-1: A Claim is issued either by the GS or by another claim issuer.
>


I'm viewing the Claims Issuer as an entity, not a piece of software. It is
the entity trusted by other parties to make a Claim about the User. The GS
and RS may issue claims on behalf of the Claims Issuer.



>   Note-2: A Claim is held and guarded by the Grant Server (GS).
>

What is the significance of this statement? Signed claims don't exist until
asked for, so they are not "held" anywhere.


>   Note-3: A Claim is released by the GS to a Client.
>

The model of a Claim being obtained from an RS is a common use case.


>   Note-4: The permission to release of a Claim is given by the RO.
>

I will see what you say below on User ...


>
>
>> Grant - the Claims and/or Resource Access the User and/or RO have grante=
d
>> to the Client by the GS
>>     - requested by a Client
>>     - granted by a GS after any required consent has been obtained from
>> the User and/or RO
>>
> "User and/or RO" is confusing. I suggest we keep the term User out. Term
> User is even eligible for renaming. I suggest staying with RO.
>

The User of the Client and the RO may not be the same entity. Some
resources may be controlled by the RO, and others by the User. That is why
User and/or RO. They are two different parties.


>
>
>> Access Token - an artifact representing the access a client has been
>> granted to one or more Resources
>>     - created by the GS
>>     - presented by the Client when accessing a Resource at an RS
>>
> An access token might contain Claims.
>

While there may be statements about the User in the access token, it is not
the mechanism for transmitting Claims to the Client -- and I think the
access token SHOULD be opaque to the Client most of the time.


>
> Access Token - an artifact representing the access a client has been
> granted to one or more Resources
>   Note-1: An access token is created by the GS
>   Note-2: An access token can also contain claims
>

See above.


>   Note-3: An access token is presented by the Client when accessing a
> Resource at an RS
>
>
>> Resource Owner (RO) - the entity that
>>       - controls a Resource,
>>       - has delegated Resource access control to one or more GSes
>>       - may be the User
>>
> Confused here with the word "controls" both at RO and GS. I think RO
> delegates Resource access management to GS but keeps control (or decision=
).
>

agreed - access management is better.


>
> Resource Owner (RO) - the entity that
>       - controls a Resource,
>       - relies on the services the GS to manage access to that Resource,
>       - relies on the services of a RS to hold a Resource and guard acces=
s
> to that Resource,
>

I don't think "guard" is a good verb. "protect" is often used.

If we are switching from "owns a resource" to "controls a resource", then
perhaps the entity should be a Resource Controller (RC)?



>       - controls a Claim,
>

Why does the RO control a claim?


>       - relies on the services the GS to release that Claim to a Client.
>
>>
>> Resource Server (RS) - the software that controls access to one or more
>> Resources
>>       - accessed via an API by Clients presenting an access token
>>       - accepts access tokens from one or more GSes
>>
> I suggest "guards" instead of "controls". As access to a resource is
> controlled by the RO.
>

How about "protects access"?


>
> Resource Server (RS) - the software that guards access to one or more
> Resources
>       - accessed by the Client that presents an access token
>       - accepts access tokens from one or more GSes
>
>
>>
>> Grant Server (GS) - the software that manages Grants
>>     - has been delegated to manage Resource access by the RO
>>     - has been delegated to release Claims about the User
>>     - grants the Client access to Resources after obtaining the required
>> consent from the RO
>>     - provides the Client Claims about the User after obtaining the
>> required consent from the User
>>
> Term User is confusing here. This is why it is eligible for renaming.
> - Claims are about RO not User
> - Consent is from RO not User.
>

I'm confused why the Claims are about the RO and not the User.

We have introduced the term RO so that entity can be differentiated from a
User, and there are many use cases where there is a User. Not having a User
seems very confusing to me.


>
> Grant Server (GS) - the software that manages Grants
>     - has been delegated to manage Resource access by the RO
>     - has been delegated to release Claims about the RO
>     - grants the Client access to Resources after obtaining the required
> consent from the RO
>     - provides the Client Claims about the RO after obtaining the require=
d
> consent from the RO
>
>
>> Client - the software that wants to access Resources and obtain Claims
>>     - executed by a User or a non-human service account
>>     - requests Grants from the Grant Server
>>     - accesses Resources at an RS using access tokens
>>
> Client - the software that wants to access Resources and obtain Claims on
> behalf of a User or non-human service account
>    Note-1: in a typical interaction cycle, the client:
>       - receives the resource access request from the User or acts
> autonomously,
>       - interacts with the RS to discover authorization requirements,
>       - interacts with the GS to obtain Access Tokens,
>       - interacts with the RS to access the Resource using Access Tokens.
>

The Client also transfers the user experience to the GS in some flows.

Where do Claims fit into the cycle above?


>
>
>>
>> User - the human using a Client
>>     - may also be the RO for one or more Resources
>>     - may have Claims managed at a GS
>>
> Not sure a user has to be human.
>

Why not? I think NOT having the User be a human is confusing.


> Maybe first renaming to "Requesting Party" might help with narrowing the
> term.
>

>
>> Some comments:
>>
>> A Claim is a well understood term in the field. We should use it. It is
>> still a Claim if it comes directly from the GS or from an RS.
>>
> I do not understand why a Resource release by an RS shall be h to as a
> claim, even if the content of the Resource is an assertion. It will lead =
to
> confusion. If we limit claims to information GS releases into Token, User
> Info, and other objects it returns, this will help separate
> responsibilities between GS and RS. As soon as RS services and informatio=
n,
> this is called a Resource, no matter the nature of the content of that
> information.
>
>
>> I think Grant Server is the right term. A Grant contains claims and/or
>> access to resources. I have defined all the terms above without using th=
e
>> term authorization. :) -- I am pondering renaming most things called
>> Authorization in XAuth to Access.
>>
> Ok.
>
>>
>> Claim Issuer - I think we may need to add this party to our nomenclature=
.
>> This is the entity that issues Claims. It may be a GS or an RS.
>>
> Yes for the term "Claim Issuer".
>
> No for a "Claim Issuer" being an RS. At least not in its role as an RS. R=
S
> shall focus on guarding and serving a Resource. Issuing a claim is
> authoritative and might come with more complexity (verification of
> authenticity). Having an RS issue a claim will overload the role of an RS
> and increase the complexity of the framework.
>
> /Francis
>
>
>> /Dick
>>
>> =E1=90=A7
>>
>> On Thu, Jul 23, 2020 at 8:07 AM Justin Richer  wrote:
>>
>>> Up-front question to the Chairs, do we have a good place to capture thi=
s
>>> kind of thing? A non-spec document like this would be a good candidate =
for
>>> a wiki page. Do we have plans to set up a GitHub repository or similar?=
 If
>>> so we could use the wiki capabilities there to at least get this stuff
>>> written down. Use cases would be good to capture there as well.
>>>
>>>
>>>
>>> Francis,
>>>
>>> First, I want to thank you for putting the work in to getting some
>>> vocabulary down. This is not an easy task! Some notes on specific items
>>> inline below.
>>>
>>> On Jul 21, 2020, at 8:33 PM, Francis Pouatcha  wrote:
>>>
>>> Hello Dick, Justin, Tom, Denis,
>>>
>>> Below is a new version of the dictionary includings comments from
>>> different threads. Change log includes:
>>> - avoided the expression "owns a resource" in favor of the expression
>>> "controls a resource"
>>> - included the clarification "resource access" and "claim release"
>>> - included a clarification User vs. RO
>>> - tried to clarify the word User-Agent
>>> - added the definition of a Claim
>>>
>>> Terms
>>> =3D=3D=3D=3D=3D
>>>
>>> Party - represents a role in the GNAP protocol flow. A party can take
>>> the form of a web service, an application installed on the user device =
and
>>> acting autonomously or the form of a natural person (resp. of an autono=
mous
>>> device) using an application to interact with other parties.
>>>
>>> Resource - a piece of data or web service
>>>       - controlled by a Resource Owner (RO),
>>>       - held and guarded by a Resource Server (RS) and
>>>       - serviced by the RS to a Client, if the Client provides a valid
>>> Authorization.
>>>
>>> Claim - a piece of data
>>>       - controlled by a Resource Owner (RO),
>>>       - held and guarded by the Grant Server (GS) and
>>>       - released by the GS to a Client as part of an Authorization.
>>>
>>>
>>> The differentiation between =E2=80=9Cresource=E2=80=9D and =E2=80=9Ccla=
im=E2=80=9D is important since it
>>> separates items that get tied to an access token=E2=80=99s rights (=E2=
=80=9Cresources=E2=80=9D)
>>> with items that come back directly to the client without going through =
a
>>> separate API. The term =E2=80=9Cclaim=E2=80=9D is problematic here thou=
gh because it is
>>> used broadly in the community to mean, roughly, =E2=80=9Ca statement ab=
out the end
>>> user=E2=80=9D. It=E2=80=99s therefore both too broad and too narrow in =
the wrong ways: a
>>> =E2=80=9Cclaim=E2=80=9D could come back as part of an API response, lik=
e the OIDC UserInfo
>>> Endpoint, and so it=E2=80=99s not a good name for this item. Even the O=
IDC =E2=80=9Cclaims=E2=80=9D
>>> query language defines several different targets for returning the =E2=
=80=9Cclaims=E2=80=9D
>>> about the user, and none of them match the method that GNAP is looking =
to
>>> use here. A =E2=80=9Cclaim=E2=80=9D is also generally understood in the=
 identity community
>>> to be a statement about the user, and the data coming back directly to =
the
>>> client might be about the user or something else, especially as we look
>>> forward to extensions of GNAP.
>>>
>>> I think we should focus on the separation of the delivery mechanism, bu=
t
>>> I=E2=80=99m not sure what good alternatives would be. Perhaps:
>>>
>>>  - =E2=80=9Caccess right=E2=80=9D for things tied to the API/token
>>>  - =E2=80=9Cdata response=E2=80=9D for things coming back directly to t=
he client
>>>
>>> I=E2=80=99m not particularly thrilled by these names, but I think recen=
t list
>>> conversation shows that we need to get away from =E2=80=9Cclaim=E2=80=
=9D as it=E2=80=99s overloaded.
>>>
>>>
>>> Resource Owner (RO) - the party that
>>>       - controls a Resource,
>>>       - relies on the services the GS to manage access to that Resource=
,
>>>       - relies on the services of a RS to hold the Resource and guard
>>> access to that Resource,
>>>       - controls a Claim,
>>>       - relies on the services the GS to release that Claim to a Client=
.
>>>
>>> Resource Server (RS) - the party that
>>>       - holds a resource and guards access to that resource on behalf o=
f
>>> the RO,
>>>       - services the Resource to the requesting Client, provided the
>>> Client presents a valid Authorization.
>>>       The RS is generally deployed as a web service.
>>>
>>> Grant Server (GS) - the party that
>>>       - manages access to a Resource on behalf of the RO,
>>>       - holds Claims and releases them when consented by the RO.
>>>       For each Resource access request, the GS might request the Consen=
t
>>> of the RO and produce a corresponding Authorization that is given to th=
e
>>> requesting Client.
>>>
>>>
>>> I don=E2=80=99t like the shift from =E2=80=9CAuthorization Server=E2=80=
=9D to =E2=80=9CGrant Server=E2=80=9D,
>>> and it especially doesn=E2=80=99t make sense in light of the definition=
s of =E2=80=9Cgrant=E2=80=9D
>>> and =E2=80=9Cauthorization=E2=80=9D above. I believe we should stick wi=
th =E2=80=9CAuthorization
>>> Server=E2=80=9D if it=E2=80=99s a single role. I would also propose tha=
t we have a separate
>>> term for the RO-interactive portion vs. the client-facing portion, as h=
as
>>> been brought up in a few threads. Maybe these get different names entir=
ely,
>>> or maybe they are =E2=80=9Caspects=E2=80=9D of the AS, I=E2=80=99m not =
sure.
>>>
>>>
>>> Consent - act of an RO :
>>>       - approving access to a Resource, means approval that a Resource
>>> he controls can be given to the Client by the RS.
>>>       - approving release of a Claim, means approval that a Claim he
>>> controls can be included by the GS in an Authorization to be returned t=
o
>>> the Client.
>>>
>>> Grant - material form of an RO Consent. In order not to interact with
>>> the RO on each Resource access request, the GS might store the RO Conse=
nt
>>> in the form of a Grant for reuse.
>>>
>>> Authorization - externalized form of a Grant as known to the GS and the
>>> RS.
>>>       - The GS converts a Grant into an Authorization for use in a
>>> Resource access request.
>>>       - The RS evaluates an Authorization to decide on whether or not t=
o
>>> release the Resource to the Client.
>>>
>>> Client - the party that provides the infrastructure used by a User to
>>> access a Resource. The client infrastructure is designed to:
>>>       - Receive the resource access request from the User,
>>>       - Interact with the RS to discover authorization requirements,
>>>       - Interact with the GS to obtain an Authorization to access the
>>> Resource,
>>>       - Interact with the RS to access the Resource on behalf of the
>>> User.
>>>
>>>
>>> I think we should be clear that what we call the =E2=80=9Cclient=E2=80=
=9D is a piece of
>>> software operated by the user. It=E2=80=99s true that this software mig=
ht have
>>> multiple parts of its =E2=80=9Cinfrastructure=E2=80=9D but it=E2=80=99s=
 always software.
>>>
>>>
>>> User - the party using the infrastructure of the Client to gain access
>>> to a Resource or a Claim.
>>>
>>>
>>> In UMA, we call this the =E2=80=9CRequesting Party=E2=80=9D, or RqP. We=
 might want to
>>> consider adopting this terminology here as well.
>>>
>>>
>>> Clarifications:
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> User vs. RO :
>>>       - the User is the party using the infrastructure of the Client to
>>> gain access to a Resource or a Claim,
>>>       - the RO is the party controlling access to a Resource or
>>> controlling the release of a Claim.
>>> In many use cases, User and RO will be represented by the same party
>>> (see oAuth2), but GNAP exposes use cases where User and RO are represen=
ted
>>> by different parties.
>>>
>>> User-Agent :
>>> User and RO are parties that might be represented by a natural person o=
r
>>> an autonomous device. In those cases, User (resp. RO) might need the he=
lp
>>> of an application to interact with other parties. Such an application i=
s
>>> generally referred to as the "User-Agent".
>>>
>>>
>>> The term =E2=80=9Cuser agent=E2=80=9D is often used to be equivalent to=
 the web browser,
>>> and not the more general use here. I think we=E2=80=99re seeing more =
=E2=80=9Cagent=E2=80=9D
>>> terminology for helper applications like digital wallets and AI bots, w=
hich
>>> would seem to be covered under your definition here.
>>>
>>>
>>> Feedbacks are welcome.
>>>
>>>
>>> Again, thanks so much for getting this going!
>>>
>>>  =E2=80=94 Justin
>>>
>>> Best regards,
>>> /Francis
>>>
>>>
>>> On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha  wrote=
:
>>>
>>>>
>>>>
>>>> On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt 
>>>>>> wrote:
>>>>>>
>>>>>>> FYI: I consider the release of claims to be an "authorization" as
>>>>>>> well.
>>>>>>>
>>>>>> Great. Then it is included.
>>>>>>
>>>>>
>>>>> I pivoted to using the term Grant rather than authorization so that i=
t
>>>>> included both authorizing access to a resource, and authorizing the r=
elease
>>>>> of an identity claim.
>>>>>
>>>>> Perhaps we should not use the word "authorization"?
>>>>>
>>>> Authorization is currently used to refer to the token issued by the
>>>> GSand presented to the RS by the Client. I have no alternative word fo=
r now.
>>>>
>>>>>
>>>>> "resource access" and "claim release"
>>>>>
>>>>> A Grant then covers both?
>>>>>
>>>> Yes, Great! The word Grant fits best for both. I suggest adding this
>>>> clarification to that dictionary.
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> IE, the user authorizes the GS to release a DOB claim to a Client.
>>>>>>>
>>>>>> I guess you mean the "RO" authorizes the GS to release a DOB!
>>>>>>
>>>>>
>>>>> Yes, thanks for clarifying!
>>>>>
>>>>> /Dick
>>>>>
>>>>>>
>>>>
>>>> --
>>>> 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/
>
=E1=90=A7

--000000000000f0721405ab26f1e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Jul 23, 2020 at 7:16 PM Franc=
is Pouatcha <fpo@adorsys.de> wr=
ote:
Hello Dick, my feedback inline

<=
div>@Fabian : i am not yet consistent with using the notation you referred=
=C2=A0to in=C2=A0https://www.iso.org/obp/ui/#iso:std:iso-ie=
c:27000:ed-5:v1:en. Still to come.

=

On Thu, Jul 23, 2020 at 7:52 PM Dick =
Hardt <dick.ha=
rdt@gmail.com> wrote:
Hi Francis

Thanks again fo=
r putting=C2=A0this together. I have taken your definitions and adjusted th=
em to match how I think of them. I dropped the term "parties" bec=
ause I did not think it added value. I am explicit about what each party is=
 -- software, a human, or an entity. Let me know where you disagree!
<=
div>

Resource - protected data or software functionality<=
br>=C2=A0 =C2=A0 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =
=C2=A0 =C2=A0 - protected by the Resource Server (RS)
Yes=C2=A0

Claim - a statement about the User
I would stay with RO not User. I added some clarificat=
ion=C2=A0after the feedback of Justin (see below)=C2=A0


=C2=A0
=
=C2=A0 =C2=A0 =C2=A0 - may be obtained from the Grant Server (GS) by a Clie=
nt
Yes.=C2=A0
=C2=A0 =C2=A0 =C2=A0 - may=
 be a Resource the Client can access through an RS
Not sure we need to refer to a Resource as a Claim.

Here is why I say a Claim may be a=C2=
=A0Resource.=C2=A0

A Claim may be obtained by a Cl=
ient calling an RS. This is effectively what the userinfo endpoint is in Op=
enID Connect. A Client may also update a Claim that is managed by an RS.=C2=
=A0
=C2=A0

A Cla=
im - an assertion of th=
e truth of some properties or attributes of the RO.
=C2=A0=
 Note-1: A Claim is issued either by the GS or by another claim issuer.


I'm=
 viewing the Claims Issuer as an entity, not a piece of software. It is the=
 entity trusted by other parties to make a Claim about the User. The GS and=
 RS may issue claims on behalf of the Claims Issuer.

=C2=A0
=C2=A0 Note-2: A Claim is hel=
d and guarded by the Grant Server (GS).

What is the significance of this statement? Signed cla=
ims don't exist until asked for, so they are not "held" anywh=
ere.
=C2=A0
=C2=A0 N=
ote-3: A Claim is released by the GS to a Client.=C2=A0

The model of a Claim being obtained fr=
om an RS is a common use case.=C2=A0
=C2=A0
=C2=A0 Note-4: The permission to release of a Claim is given b=
y the RO.

I wil=
l see what you say below on User ...
=C2=A0


Grant - the Claims and/or Resource=
 Access the User and/or RO have granted to the Client by the GS
=C2=A0 =
=C2=A0 - requested by a Client
=C2=A0 =C2=A0 - granted by a GS after any=
 required consent has been obtained from the User and/or RO
=

"User and/or RO" is confusing. I suggest we kee=
p the term User out. Term User is even eligible for renaming. I suggest sta=
ying with RO.

The User of=
 the Client and the RO may not be the same entity. Some resources may be co=
ntrolled by the RO, and others by the User. That is why User and/or RO. The=
y are two different parties.
=C2=A0
=


Access Token - an artifact representing the access a client has =
been granted to one or more Resources
=C2=A0 =C2=A0 - created by =
the GS
=C2=A0 =C2=A0 - presented by the Client when accessing a Resource=
 at an RS
An access token might contain=C2=
=A0Claims.

While there ma=
y be statements about the User in the access token, it is not the mechanism=
 for transmitting Claims to the Client -- and I think the access token SHOU=
LD be opaque to the Client most of the time.
=C2=A0

Access Token=C2=A0-=C2=A0an artifact representing the access a client has bee=
n granted to one or more Resources
=C2=A0 Note-1: An access token=
 is=C2=A0created by the GS
=C2=A0 Note-2:=C2=A0An access token ca=
n also contain claims

See=
 above.=C2=A0
=C2=A0
=C2=A0 Note-3: =
An access token is=C2=A0presented by the Client when accessing a Resource a=
t an RS
=C2=A0
Resource Owner (RO) - the entity that
=
=C2=A0 =C2=A0 =C2=A0 - controls a Resource,
=C2=A0 =C2=A0 =C2=A0 - has d=
elegated Resource access control to one or more GSes
=C2=A0 =C2=A0 =C2=
=A0 - may be the User
Confused here with t=
he word "controls" both at RO and GS. I think RO delegates Resour=
ce access management to GS but keeps control (or decision).

agreed - access management is better.
=C2=A0

Resource Owner (RO) - the entity that
=C2=A0 =
=C2=A0 =C2=A0 - controls a Resource,
=C2=A0 =C2=A0 =C2=A0 - relies on th=
e services the GS to manage access to that Resource,
=C2=A0 =C2=A0 =C2=
=A0 - relies on the services of a RS to hold a Resource and guard access to=
 that Resource,

I don=
't=C2=A0think "guard" is a good verb. "protect" is =
often used.

If we are switching from "owns a =
resource" to "controls a resource", then perhaps the entity =
should be a Resource Controller (RC)?

=C2=A0
=

=C2=A0 =C2=A0 =C2=A0 - controls a Claim,
<=
/div>

Why does the RO control a claim=
?
=C2=A0
<=
div dir=3D"ltr">
=C2=A0 =C2=A0 =C2=A0 - reli=
es on the services the GS to release that Claim to a Client.

Reso=
urce Server (RS) - the software that controls access to one or more Resourc=
es
=C2=A0 =C2=A0 =C2=A0 - accessed via an API by Clients presenting an a=
ccess token
=C2=A0 =C2=A0 =C2=A0 - accepts access tokens from one or mor=
e GSes 
I suggest "guards" inste=
ad of "controls". As access to a resource is controlled by the RO=
.=C2=A0

How about "p=
rotects access"?
=C2=A0

Resource Server (RS) -=C2=A0th=
e software that guards access to one or more Resources
=C2=A0 =C2=A0 =C2=A0 - acces=
sed by the Client that=C2=A0presents an access token
=C2=A0 =C2=A0 =C2=A0 - accepts access tokens from one or more GSes
=C2=A0

Grant Server (GS=
) - the software that manages Grants
=C2=A0 =C2=A0 - has been delegated =
to manage Resource access by the RO
=C2=A0 =C2=A0 - has been delegated t=
o release Claims about the User
=C2=A0 =C2=A0 - grants the Client access=
 to Resources after obtaining the required consent from the RO
=C2=A0 =
=C2=A0 - provides the Client Claims about the User after obtaining the requ=
ired consent from the User
Term User is co=
nfusing here. This is why it is eligible for renaming.
- Claims a=
re about RO=C2=A0not User
- Consent is from RO not User.

I'm confused why the Claims a=
re about the RO and not the User.

We have introduc=
ed the term RO so that entity can be differentiated from a User, and there =
are many use cases where there is a User. Not having a User seems very conf=
using to me.
=C2=A0
=C2=A0
Grant Server (GS) - =
the software that manages Grants
=C2=A0 =C2=A0 - has been delegated to man=
age Resource access by the RO
=C2=A0 =C2=A0 - has been delegated to releas=
e Claims about the RO
=C2=A0 =C2=A0 - grants the Client access to Resour=
ces after obtaining the required consent from the RO
=C2=A0 =C2=A0 - provi=
des the Client Claims about the RO after obtaining the required consent fro=
m the RO
=C2=A0
Client - the software that w=
ants to access Resources and obtain Claims
=C2=A0 =C2=A0 - executed by a=
 User or a non-human service account 
=C2=A0 =C2=A0 - requests Grants fr=
om the Grant Server
=C2=A0 =C2=A0 - accesses Resources at an RS using ac=
cess tokens
=
Client -=C2=A0the software that wants to access Resources and obtain=
 Claims on behalf of a=C2=A0User or non-human service account
=C2=A0 =C2=A0Note-1: in a typical interaction cycle, the=
 client:
=C2=A0 =C2=A0 =C2=A0 - recei=
ves the resource access request from the User or acts autonomously,<=
br style=3D"color:rgb(80,0,80)">=C2=A0 =
=C2=A0 =C2=A0 - interacts with the RS to discover authorization requirement=
s,
=C2=A0 =C2=A0 =C2=A0 - interacts with the GS to obtain Access Tokens,
=C2=A0 =C2=A0 =C2=A0 - interacts with the RS to access the Resource using =
Access Tokens.

The=
 Client also transfers the user experience to the GS in some flows.

Where do Claims fit into the cycle above?
=C2=
=A0
=C2=A0

User - the human using a Clie=
nt
=C2=A0 =C2=A0 - may also be the RO for one or more Resources
=C2=
=A0 =C2=A0 - may have Claims managed at a GS
Not sure a user has to be human.=C2=A0

Why not? I think NOT having the User be a human is con=
fusing.=C2=A0
=C2=A0
Mayb=
e first renaming to "Requesting Party" might help with narrowing =
the term.

<=
div>

Some comments:

A =
Claim is a well understood term in the field. We should use it. It is still=
 a Claim if it comes directly from the GS or from an RS.=C2=A0
<=
/blockquote>
I do not understand why a Resource release by an RS shall =
be h to as a claim, even if the content of the Resource is an assertion. It=
 will lead to confusion. If we limit claims to information GS releases into=
 Token, User Info, and other objects it returns, this will help separate re=
sponsibilities between GS and RS. As soon as RS services and information, t=
his is called a Resource, no matter the nature of the content of that infor=
mation.


I think Grant Server is the right t=
erm. A Grant contains claims and/or access to resources. I have defined all=
 the terms above without using the term authorization. :) -- I am pondering=
 renaming most things called Authorization in XAuth to Access.
<=
/blockquote>
Ok.=C2=A0

Claim Issuer - I think we may n=
eed to add this party to our nomenclature. This is the entity that issues C=
laims. It may be a GS or an RS.=C2=A0
Yes for =
the term "Claim Issuer".

No for a "=
Claim Issuer" being an RS. At least not in its role as an RS. RS shall=
 focus on guarding and serving a Resource. Issuing a claim is authoritative=
=C2=A0and might come with more complexity=C2=A0(verification of authenticit=
y). Having an RS issue a claim will overload the role of an RS and increase=
 the complexity of the framework.

/Francis


/Dick

3D""=E1=
=90=A7

On Thu, Jul 23, 2020 at 8:07 AM Justin Richer <jricher@mit.edu> wrote:
=

Up-front =
question to the Chairs, do we have a good place to capture this kind of thi=
ng? A non-spec document like this would be a good candidate for a wiki page=
. Do we have plans to set up a GitHub repository or similar? If so we could=
 use the wiki capabilities there to at least get this stuff written down. U=
se cases would be good to capture there as well.=C2=A0

=



Francis,

First, I want to =
thank you for putting the work in to getting some vocabulary down. This is =
not an easy task! Some notes on specific items inline below.

On Jul 21, 2020, at 8:33 PM, Francis Pouatcha =
<fpo@adorsys.de&=
gt; wrote:

Hello Dick, Justi=
n, Tom, Denis,

Below=C2=A0is a new version of the dictio=
nary includings comments=C2=A0from different=C2=A0threads. Change log inclu=
des:
- avoided the expression "owns a resource" in favo=
r of the expression "controls=C2=A0a resource"
- includ=
ed the clarification=C2=A0"resource access" and "claim relea=
se"
- included a clarification User vs. RO
- tried=
 to clarify the word User-Agent
- added the definition of a Claim=


Terms
=3D=3D=3D=3D=3D

Party - represent=
s a role in the GNAP protocol flow. A party can take the form of a web serv=
ice, an application installed on the user device and acting autonomously or=
 the form of a natural person (resp. of an autonomous device) using an appl=
ication to interact with other parties.

Resource - a piece of data o=
r web service
=C2=A0 =C2=A0 =C2=A0 - controlled by a Resource Owner (RO)=
,
=C2=A0 =C2=A0 =C2=A0 - held and guarded by a Resource Server (RS) and<=
br>=C2=A0 =C2=A0 =C2=A0 - serviced by the RS to a Client, if the Client pro=
vides a valid Authorization.

Claim - a piece of data
=C2=A0 =C2=
=A0 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=A0 -=
 held and guarded by the Grant Server (GS) and
=C2=A0 =C2=A0 =C2=A0 - re=
leased by the GS to a Client as part of an Authorization.

The differentiation between =E2=80=9Cr=
esource=E2=80=9D and =E2=80=9Cclaim=E2=80=9D is important since it separate=
s items that get tied to an access token=E2=80=99s rights (=E2=80=9Cresourc=
es=E2=80=9D) with items that come back directly to the client without going=
 through a separate API. The term =E2=80=9Cclaim=E2=80=9D is problematic he=
re though because it is used broadly in the community to mean, roughly, =E2=
=80=9Ca statement about the end user=E2=80=9D. It=E2=80=99s therefore both =
too broad and too narrow in the wrong ways: a =E2=80=9Cclaim=E2=80=9D could=
 come back as part of an API response, like the OIDC UserInfo Endpoint, and=
 so it=E2=80=99s not a good name for this item. Even the OIDC =E2=80=9Cclai=
ms=E2=80=9D query language defines several different targets for returning =
the =E2=80=9Cclaims=E2=80=9D about the user, and none of them match the met=
hod that GNAP is looking to use here. A =E2=80=9Cclaim=E2=80=9D is also gen=
erally understood in the identity community to be a statement about the use=
r, and the data coming back directly to the client might be about the user =
or something else, especially as we look forward to extensions of GNAP.=C2=
=A0

I think we should focus on the separation of t=
he delivery mechanism, but I=E2=80=99m not sure what good alternatives woul=
d be. Perhaps:

=C2=A0- =E2=80=9Caccess right=E2=80=
=9D for things tied to the API/token
=C2=A0- =E2=80=9Cdata respon=
se=E2=80=9D for things coming back directly to the client

I=E2=80=99m not particularly thrilled by these names, but I think r=
ecent list conversation shows that we need to get away from =E2=80=9Cclaim=
=E2=80=9D as it=E2=80=99s overloaded.


Resource Owner (RO) - the part=
y that
=C2=A0 =C2=A0 =C2=A0 - controls a Resource,
=C2=A0 =C2=A0 =C2=
=A0 - relies on the services the GS to manage access to that Resource,
=
=C2=A0 =C2=A0 =C2=A0 - relies on the services of a RS to hold the Resource =
and guard access to that Resource,
=C2=A0 =C2=A0 =C2=A0 - controls a Cla=
im,
=C2=A0 =C2=A0 =C2=A0 - relies on the services the GS to release that=
 Claim to a Client.

Resource Server (RS) - the party that=C2=
=A0
=C2=A0 =C2=A0 =C2=A0 - holds a resource and guards access to =
that resource on behalf of the RO,
=C2=A0 =C2=A0 =C2=A0 - services the R=
esource to the requesting Client, provided the Client presents a valid Auth=
orization.
=C2=A0 =C2=A0 =C2=A0 The RS is generally deployed as a web se=
rvice.

Grant Server (GS) - the party that=C2=A0
=C2=
=A0 =C2=A0 =C2=A0 - manages access to a Resource on behalf of the RO,
=
=C2=A0 =C2=A0 =C2=A0 - holds Claims and releases them when consented by the=
 RO.
=C2=A0 =C2=A0 =C2=A0 For each Resource access request, the GS might=
 request the Consent of the RO and produce a corresponding Authorization th=
at is given to the requesting Client.

I don=E2=80=99t like the shift from =E2=80=9CAuthorization=
 Server=E2=80=9D to =E2=80=9CGrant Server=E2=80=9D, and it especially doesn=
=E2=80=99t make sense in light of the definitions of =E2=80=9Cgrant=E2=80=
=9D and =E2=80=9Cauthorization=E2=80=9D above. I believe we should stick wi=
th =E2=80=9CAuthorization Server=E2=80=9D if it=E2=80=99s a single role. I =
would also propose that we have a separate term for the RO-interactive port=
ion vs. the client-facing portion, as has been brought up in a few threads.=
 Maybe these get different names entirely, or maybe they are =E2=80=9Caspec=
ts=E2=80=9D of the AS, I=E2=80=99m not sure.


Consent - act of an RO =
:
=C2=A0 =C2=A0 =C2=A0 - approving access to a Resource, means approval =
that a Resource he controls can be given to the Client by the RS.
=C2=A0=
 =C2=A0 =C2=A0 - approving release of a Claim, means approval that a Claim =
he controls can be included by the GS in an Authorization to be returned to=
 the Client.

Grant - material form of an RO Consent. In order not to=
 interact with the RO on each Resource access request, the GS might store t=
he RO Consent in the form of a Grant for reuse.

Authorization - exte=
rnalized form of a Grant as known to the GS and the RS.
=C2=A0 =C2=A0 =
=C2=A0 - The GS converts a Grant into an Authorization for use in a Resourc=
e access request.
=C2=A0 =C2=A0 =C2=A0 - The RS evaluates an Authorizati=
on to decide on whether or not to release the Resource to the Client.
Client - the party that provides the infrastructure used by a User to acc=
ess a Resource. The client infrastructure is designed to:
=C2=A0 =C2=A0 =
=C2=A0 - Receive the resource access request from the User,
=C2=A0 =C2=
=A0 =C2=A0 - Interact with the RS to discover authorization requirements,=C2=A0 =C2=A0 =C2=A0 - Interact with the GS to obtain an Authorization to=
 access the Resource,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to acc=
ess the Resource on behalf of the User.
<=
div>
I think we should be clear that what we call the =E2=80=
=9Cclient=E2=80=9D is a piece of software operated by the user. It=E2=80=99=
s true that this software might have multiple parts of its =E2=80=9Cinfrast=
ructure=E2=80=9D but it=E2=80=99s always software.


User - the party =
using the infrastructure of the Client to gain access to a Resource or a Cl=
aim.


In UMA, we c=
all this the =E2=80=9CRequesting Party=E2=80=9D, or RqP. We might want to c=
onsider adopting this terminology here as well.


Clarifications:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

User vs. RO :=C2=A0
=C2=A0 =C2=A0 =C2=A0 - the User is the party using the infrastructur=
e of the Client to gain access to a Resource or a Claim,
=C2=A0 =C2=A0 =
=C2=A0 - the RO is the party controlling access to a Resource or controllin=
g the release of a Claim.
In many use cases, User and RO will be represe=
nted by the same party (see oAuth2), but GNAP exposes use cases where User =
and RO are represented by different parties.

User-Agent :
User an=
d RO are parties that might be represented by a natural person or an autono=
mous device. In those cases, User (resp. RO) might need the help of an appl=
ication to interact with other parties. Such an application is generally re=
ferred to as the "User-Agent".
=


The term =E2=80=9Cuser agent=E2=80=9D is often used to =
be equivalent to the web browser, and not the more general use here. I thin=
k we=E2=80=99re seeing more =E2=80=9Cagent=E2=80=9D terminology for helper =
applications like digital wallets and AI bots, which would seem to be cover=
ed under your definition here.


Feedbacks are welcome.

=


Again, thanks so much fo=
r getting this going!

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

Be=
st regards,
/Francis


On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:


On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt <dick.hardt@gmail.com> wrote:
=



On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha <=
fpo@adorsys.de> =
wrote:

On=
 Tue, Jul 21, 2020 at 1:59 PM Dick Hardt <dick.hardt@gmail.com> wrote:
FYI: I con=
sider the release of claims to be an "authorization" as well.=C2=
=A0
Great. Then it is included.=C2=A0

I pivoted to using the term Grant rathe=
r than authorization so that it included both authorizing access to a resou=
rce, and authorizing the release of an identity claim.

=

Perhaps we should not use the word "authorization"?=C2=A0
Authorization is currently used to refer t=
o the token issued by the GSand presented to the RS by the Client. I have n=
o alternative word for now.

&qu=
ot;resource access" and "claim release"

=

A Grant then covers both?
Yes, Grea=
t! The word Grant fits best for both. I suggest adding this clarification t=
o that dictionary.
<=
div dir=3D"ltr">

=C2=A0
=


IE, the user authorizes the GS to release a =
DOB claim=C2=A0to a Client.
I guess you mean t=
he "RO" authorizes the GS to release a DOB!

Yes, thanks for clarifying!
=C2=A0
/Dick
<=
div dir=3D"ltr">
=


--=C2=A0
=

Francis Pouatcha
Co-Founder and Technical Lead=

adorsys GmbH & Co. KG
<=
/blockquote>
--=C2=A0
=

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





-- 
Francis Pouatcha
Co-Founder and Technical Lead=

adorsys GmbH & Co. KG


3D""=
=E1=90=A7


--000000000000f0721405ab26f1e4--


From nobody Thu Jul 23 22:29: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 C96C43A0C13 for ; Thu, 23 Jul 2020 22:29: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 7SrNPsD-AEnz for ; Thu, 23 Jul 2020 22:28:59 -0700 (PDT)
Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 D27DE3A0C0F for ; Thu, 23 Jul 2020 22:28:58 -0700 (PDT)
Received: by mail-oo1-xc33.google.com with SMTP id z23so1582363ood.8 for ; Thu, 23 Jul 2020 22:28:58 -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=mM5h/gu6ghZ8sWC37GIFeq5LrxKCO+lWPRJOtujcy90=; b=uWC9KONku3O+Mamxnbr452rCsPEIDF+RLlwByNaiwH7m+/gHqDm14mTuMoDDFYpLD/ ogpwXOqmArtnzNTYMUZhAnm2IDGXgAm5ic1BZZNtLkPGqzXWfC8CT4XLcIK2UExAFXMc w7icGBh4UBatW/kP9ECcdHdSxtKrXkHCn19J5tiLI2W/LgwTmsZHHHqLps0nZzFycAqY zgx1hUsxMtPC7OZ4nq5ogjEf1LyFmOM18RVTq2olkC850wrdnZIdRf1Iz3/ZwKBtdYvr ZTpS/MCnhnS0omYoO3jpJ9xBER5Ul523g/DZhCUUc1D81jbzyB/1Vsg7ntxkO2Qot7cV IkiQ==
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=mM5h/gu6ghZ8sWC37GIFeq5LrxKCO+lWPRJOtujcy90=; b=eI0bKjp4WrqjSgAMNiG1TxX8oHaUb9Qfk57Ic2SGowfpm4F8GukWFZ7LxNgmM5bsfg RihHxmeBKsL0Zim5vRRssI48cuFhRceBtGOwvc+V6hN02xCjNEBN5snYkzJo2cGmBilh F4TPogKRHCYy89PvxRaZ3e7X1+obO8BoOLSdq6ebUQM0IDAqrNqX2hsHE105eZBS29BJ rUMM41vF/mXQcnMrQeLG0LtYWp91jlpDrgWqlzDfXWGGwEUpP3VeD9EQD0y97m+lQrKa 8g/GYn/6+hmCPf1TjAGngFpcsZ95WDlPaSe5iRQYgI33jSGyoek4TniT9rrPiS3aZ8Ot aadA==
X-Gm-Message-State: AOAM530ObjKy/92fmRpURPFGtC+oHZSB7JM6gpJLICdsF8KlKte4LfpW kPDbQLBX7A8+WsVGacw2wrjWzpYN7jILJRyTHS8=
X-Google-Smtp-Source: ABdhPJwbHrzp5BcbGxH872Xi3+i1mXBda79oMoV6O5tHprvrQgYb6dRnvICAURqjfzfXaGxTNqchSiJPRmzoVCSJXy8=
X-Received: by 2002:a4a:dfb5:: with SMTP id k21mr7705756ook.27.1595568537818;  Thu, 23 Jul 2020 22:28:57 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Tom Jones 
Date: Thu, 23 Jul 2020 22:28:46 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: txauth@ietf.org, Dick Hardt 
Content-Type: multipart/alternative; boundary="000000000000e95a8305ab293f58"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 24 Jul 2020 05:29:01 -0000

--000000000000e95a8305ab293f58
Content-Type: text/plain; charset="UTF-8"

i generally like this - i guess. you decided to drop "claim" from the list?
that is probably for the best. Claims certainly can come from the resource
one minor suggestion resource is data or service.  (nit - a piece of data
is called a datum)

I must object to the statement that the resource owner actually owns the
resource. That is demonstrably untrue in all the systems I work on. It is a
holder-over from microsoft Sharepoint where it meant the business owner. It
has never meant the actual data owner. Then Sharepoint goes to the extreme
of claiming to be the resource owner, but it never actually sets the acls
which give the access. So it never met the conditions of being an RO. The
Sharepoint system rapidly became unmanageable by the very business owners
that were meant to control the access. It is not a good model to follow. I
would be much happier if we stopped calling it a RO, but if we are stuck
with that at least say that the RO controls access rather than perpetuate a
myth.
Peace ..tom


On Mon, Jul 20, 2020 at 6:01 PM Francis Pouatcha  wrote:

> Hello Dick,
>
> Here is (in a new thread) the promised attempt to define terms of interest
> in the GNAP protocol.
>
> Party - represents a role in the GNAP protocol flow. A party can take the
> form of a web service, an application installed on the user device and
> acting autonomously or the form of a natural person (resp. of an autonomous
> device) using an application to interact with other parties.
>
> Resource - a piece of data or web service
>       - controlled by a Resource Owner (RO),
>       - held and guarded by a Resource Server (RS) and
>       - serviced by the RS to a Client, if the Client provides a valid
> Authorization.
>
> Resource Owner (RO) - the party that
>       - owns a Resource,
>       - relies on the services the GS to manage access to that Resource
> and
>       - relies on the services of a RS to hold the Resource and guard
> access to that Resource.
>
> Resource Server (RS) - the party that
>       - holds a resource and guards access to that resource on behalf of
> the RO,
>       - services the Resource to the requesting Client, provided the
> Client presents a valid Authorization.
>       The RS is generally deployed as a web service.
>
> Grant Server (GS) - the party that manages access to a Resource on behalf
> of the RO. For each Resource access request, the GS might request the
> consent of the RO and produce a corresponding Authorization that is given
> to the requesting Client.
>
> Consent - act of an RO approving the release of a Resource he owns to a
> Client.
>
> Grant - material form of an RO Consent. In order not to interact with the
> RO on each Resource access request, the GS might store the RO Consent in
> the form of a Grant for reuse.
>
> Authorization - externalized form of a Grant as known to the GS and the RS.
>       - The GS converts a Grant into an Authorization for use in a
> Resource access request.
>       - The RS evaluates an Authorization to decide on whether or not to
> release the Resource to the Client.
>
> Client - the party that provides the infrastructure used by a User to
> access a Resource. The client infrastructure is designed to:
>       - Receive the resource access request from the User,
>       - Interact with the RS to discover authorization requirements,
>       - Interact with the GS to obtain an Authorization to access the
> Resource,
>       - Interact with the RS to access the Resource on behalf of the User.
>
> User - the party using the infrastructure of the Client to gain access to
> a Resource.
>
> This dictionary is supposed to be the base for further discussions that
> will allow us to provide each term with just enough description to reduce
> ambiguities and misunderstandings in further exchanges. I intentionally
> omitted the specification of the type and nature of each party (For example
> Client / Registered Client / Dynamic Client). Such elaborations belong IMO
> in proper subsections.
>
> Comments are welcome.
>
> Best regards.
> --
> 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
>

--000000000000e95a8305ab293f58
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


i generally like this - i guess. you decided to drop "=
;claim" from the list? that is probably for the best. Claims certainly=
 can come from the resource
one minor suggestion resource is data or se=
rvice.=C2=A0 (nit - a piece of data is called a datum)

=

I must object to the statement that the resource owner actually owns t=
he resource. That is demonstrably=C2=A0untrue in all the systems I work on.=
 It is a holder-over from microsoft Sharepoint where it meant the business =
owner. It has never meant the actual data owner. Then Sharepoint goes to th=
e extreme of claiming to be the resource owner, but it never actually=C2=A0=
sets the acls which give the access. So it never met the=C2=A0conditions=C2=
=A0of being an RO. The Sharepoint system=C2=A0rapidly became unmanageable=
=C2=A0by the very business owners that were meant to control the access. It=
 is not a good model to follow. I would be much happier if we stopped calli=
ng it a RO, but if we are stuck with that at least say that the RO controls=
 access rather than perpetuate a myth.
Peace ..tom


On Mon, Jul 20, 202=
0 at 6:01 PM Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
Hello Dick,
Here is (in a new thread) the promised attempt=C2=A0to define t=
erms of interest in the GNAP protocol. 
=C2=A0
Party - =
represents a role in the GNAP protocol flow. A party can take the form of a=
 web service, an application installed on the user device and acting autono=
mously or the form of a natural person (resp. of an autonomous device) usin=
g an application to interact with other parties.

Resource - a piece =
of data or web service
=C2=A0 =C2=A0 =C2=A0 - controlled by a Resource O=
wner (RO),
=C2=A0 =C2=A0 =C2=A0 - held and guarded by a Resource Server =
(RS) and
=C2=A0 =C2=A0 =C2=A0 - serviced by the RS to a Client, if the C=
lient provides a valid Authorization.

Resource Owner (RO) - the part=
y that 
=C2=A0 =C2=A0 =C2=A0 - owns a Resource, 
=C2=A0 =C2=A0 =C2=A0=
 - relies on the services the GS to manage access to that Resource and 
=
=C2=A0 =C2=A0 =C2=A0 - relies on the services of a RS to hold the Resource =
and guard access to that Resource.

Resource Server (RS) -=
 the party that=C2=A0
=C2=A0 =C2=A0 =C2=A0 - holds a resource and guards=
 access to that resource on behalf of the RO,
=C2=A0 =C2=A0 =C2=A0 - ser=
vices the Resource to the requesting Client, provided the Client presents a=
 valid Authorization.
=C2=A0 =C2=A0 =C2=A0 The RS is generally deployed =
as a web service.

Grant Server (GS) - the party that manages access =
to a Resource on behalf of the RO. For each Resource access request, the GS=
 might request the consent of the RO and produce a corresponding Authorizat=
ion that is given to the requesting Client.

Consent - act of an RO a=
pproving the release of a Resource he owns to a Client.

Grant - mate=
rial form of an RO Consent. In order not to interact with the RO on each Re=
source access request, the GS might store the RO Consent in the form of a G=
rant for reuse.

Authorization - externalized form of a Grant as know=
n to the GS and the RS.
=C2=A0 =C2=A0 =C2=A0 - The GS converts a Grant i=
nto an Authorization for use=C2=A0in a Resource access request.
=C2=A0 =
=C2=A0 =C2=A0 - The RS evaluates an Authorization to decide on whether or n=
ot to release the Resource to the Client.

Client - the party that pr=
ovides the infrastructure used by a User to access a Resource. The client i=
nfrastructure is designed to:
=C2=A0 =C2=A0 =C2=A0 - Receive the resourc=
e access request from the User,
=C2=A0 =C2=A0 =C2=A0 - Interact with the=
 RS to discover authorization requirements,
=C2=A0 =C2=A0 =C2=A0 - Inter=
act with the GS to obtain an Authorization to access the Resource,
=C2=
=A0 =C2=A0 =C2=A0 - Interact with the RS to access the Resource on behalf o=
f the User.

User - the party using the infrastructure of the Client =
to gain access to a Resource.

This dictionary is s=
upposed to be the base for further discussions that will allow us to provid=
e each term with just enough description to reduce ambiguities and misunder=
standings in further exchanges. I intentionally omitted the specification o=
f the type and nature of each party (For example Client / Registered Client=
 / Dynamic Client). Such elaborations belong IMO in proper subsections.

Comments are welcome.

Best reg=
ards.
-- 
<=
div>
Francis Pouatcha
=

Co-Founder and Technical Lead

-- 

Txauth mailing list

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




--000000000000e95a8305ab293f58--


From nobody Fri Jul 24 05:15: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 90E273A0881 for ; Fri, 24 Jul 2020 05:15:25 -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 sx-SgMn6wq_V for ; Fri, 24 Jul 2020 05:15:22 -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 8BAFD3A08A5 for ; Fri, 24 Jul 2020 05:15:21 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id b6so8097457wrs.11 for ; Fri, 24 Jul 2020 05:15:21 -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=mSzfKmWq3OkDBEhH3p6OQaA8vC7lPMBu3ZAXLXwxnGs=; b=QcTwYutNXO/G8xyYL16sc4AaH91TKoeRsRTX80G1Ty887dOPHavpBRxNB75wyV8egA tBxlMYXK3TSLYpTUpCPIJtdyB6wNuaYzxSOtYblUW4pSpvRBU3nqqayL00j6je1JT9Kg vR7lnGS9zLj4LqEraegTjWR025VLJARgohbc4=
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=mSzfKmWq3OkDBEhH3p6OQaA8vC7lPMBu3ZAXLXwxnGs=; b=OWx4NYGkqGPX7XOnhqV69xjvuph/HWaZgBljO9WQA+V76T2isXzxtZ/wmyF5O58jwB l1Ta3wZGUp26uxR4W+LUA9NHbIngXeD0KhId715t5HXq7mauZ/6RxaVKLUuBZ0Jt6Kzn 4aaP9Xi7IO1lGDO2B7tUoBwAZZIDJ4QIv9+djkjliZWSfzrETd3VZfIO49P4DVc5YzqH ynSr01i6wfGxZgwl9VUr/NPIllDuh6z+KepXX71wryCzwrz799Z6/dkO1jYX/YtV1St1 /ZOKfKwL1ibqi9vQSNdXyFJURs09yyHug+4Tp2qHYp3GKdCJPmHpmvWf+eHm4VTSAMwy ZnUw==
X-Gm-Message-State: AOAM532ax5QcmjGNMBAh9Dts/aGxAC0ewveGriBYagZJB5cldqYwSPQx hWI4hLFumm/5w1eFYEyx542k1zba2McFOG6NU8wiWg==
X-Google-Smtp-Source: ABdhPJyT0vEfDwcsi7VyycFjaImtYIedPnZna7u6DHjeH5gwcz1irbchFZzB5TmzqphaOq7HDR8YSfSHOEUSiOwaEI8=
X-Received: by 2002:a5d:45c9:: with SMTP id b9mr8199130wrs.283.1595592919666;  Fri, 24 Jul 2020 05:15:19 -0700 (PDT)
MIME-Version: 1.0
References:            
In-Reply-To: 
From: Francis Pouatcha 
Date: Fri, 24 Jul 2020 08:15:08 -0400
Message-ID: 
To: Dick Hardt 
Cc: Justin Richer , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="0000000000002ee98405ab2eed01"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 24 Jul 2020 12:15:26 -0000

--0000000000002ee98405ab2eed01
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 23, 2020 at 10:44 PM Dick Hardt  wrote:

>
>
> On Thu, Jul 23, 2020 at 7:16 PM Francis Pouatcha  wrote:
>
>> Hello Dick, my feedback inline
>>
>> @Fabian : i am not yet consistent with using the notation you referred t=
o
>> in https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en. Still
>> to come.
>>
>> On Thu, Jul 23, 2020 at 7:52 PM Dick Hardt  wrote:
>>
>>> Hi Francis
>>>
>>> Thanks again for putting this together. I have taken your definitions
>>> and adjusted them to match how I think of them. I dropped the term
>>> "parties" because I did not think it added value. I am explicit about w=
hat
>>> each party is -- software, a human, or an entity. Let me know where you
>>> disagree!
>>>
>>>
>>> Resource - protected data or software functionality
>>>       - controlled by a Resource Owner (RO),
>>>       - protected by the Resource Server (RS)
>>>
>> Yes
>>
>>>
>>> Claim - a statement about the User
>>>
>> I would stay with RO not User. I added some clarification after the
>> feedback of Justin (see below)
>>
>
>
>
>
>>       - may be obtained from the Grant Server (GS) by a Client
>>>
>> Yes.
>>
>>>       - may be a Resource the Client can access through an RS
>>>
>> Not sure we need to refer to a Resource as a Claim.
>>
>
> Here is why I say a Claim may be a Resource.
>
> A Claim may be obtained by a Client calling an RS. This is effectively
> what the userinfo endpoint is in OpenID Connect. A Client may also update=
 a
> Claim that is managed by an RS.
>
In OIDC the UserInfo endpoint is exposed by the OP not by an RP. Spec
wording is confusing because the endpoint is referred to as a protected
resource. If you derive from this that the OP is a resource server (RP),
you turn the OP into an RP relying on itself. This cyclic relationship has
to be broken in GNAP for simplicity.

Note-x on GS definition: having a GS protecting access to some Claims does
not make the GS a RS.

For simplicity, let us keep overlapping out:
- GS guards Claims
- RS guards Resources

I do not see a Client updating a Claim in the scope of any of these
protocols. Neither GNAP nor oAuth2 nor OIDC.

>
>
>>
>> A Claim - an assertion of the truth of some properties or attributes of
>> the RO.
>>   Note-1: A Claim is issued either by the GS or by another claim issuer.
>>
>
>
> I'm viewing the Claims Issuer as an entity, not a piece of software. It i=
s
> the entity trusted by other parties to make a Claim about the User. The G=
S
> and RS may issue claims on behalf of the Claims Issuer.
>
No. Issuer is GS. Any twiking of the word will diverge it from oAuth2 and
OIDC and increase complexity.

This is why RS shall not issue anything, shall not deal with claims, ....
RS guards Resources. If you start dealing with RS issuing claims, you start
dealing with RS exposing jwks-url so issued claims can be verified, then
you fall back at having those RSes being GSes.

>
>
>
>>   Note-2: A Claim is held and guarded by the Grant Server (GS).
>>
>
> What is the significance of this statement? Signed claims don't exist
> until asked for, so they are not "held" anywhere.
>
A Claim can exist before. GS might hold a Claim issued by an external
"Claim Issued".

>
>
>>   Note-3: A Claim is released by the GS to a Client.
>>
>
> The model of a Claim being obtained from an RS is a common use case.
>
I am not aware of any of them. Unless we are calling a GS a RS.

>
>
>>   Note-4: The permission to release of a Claim is given by the RO.
>>
>
> I will see what you say below on User ...
>
>
>>
>>
>>> Grant - the Claims and/or Resource Access the User and/or RO have
>>> granted to the Client by the GS
>>>     - requested by a Client
>>>     - granted by a GS after any required consent has been obtained from
>>> the User and/or RO
>>>
>> "User and/or RO" is confusing. I suggest we keep the term User out. Term
>> User is even eligible for renaming. I suggest staying with RO.
>>
>
> The User of the Client and the RO may not be the same entity. Some
> resources may be controlled by the RO, and others by the User. That is wh=
y
> User and/or RO. They are two different parties.
>
I need the example of a User that is different from the RO and that
controls the RO's Resource.

And if a User controls a Resource, then he does it as the "Owner" of that
Resource(playing the role of the RO for that Resource).

If we talk about roles and not entities, we will not fall into this
confusion.

>
>
>>
>>
>>> Access Token - an artifact representing the access a client has been
>>> granted to one or more Resources
>>>     - created by the GS
>>>     - presented by the Client when accessing a Resource at an RS
>>>
>> An access token might contain Claims.
>>
>
> While there may be statements about the User in the access token, it is
> not the mechanism for transmitting Claims to the Client -- and I think th=
e
> access token SHOULD be opaque to the Client most of the time.
>
- Access "might" contain a claim ("must" not). Precision is essential as we
can not kill this practice without removing the concept of assertion based
tokens.
- Returning the information to the client does not mean the client is the
consumer of the information. The client might not have access to the
content of an encrypted token, or even just to the embedded encrypted
claim. The intended destination of the claim will consume the claim. But
for the GNAP, the GS returns the token to the client.

>
>
>>
>> Access Token - an artifact representing the access a client has been
>> granted to one or more Resources
>>   Note-1: An access token is created by the GS
>>   Note-2: An access token can also contain claims
>>
>
> See above.
>
>
>>   Note-3: An access token is presented by the Client when accessing a
>> Resource at an RS
>>
>>
>>> Resource Owner (RO) - the entity that
>>>       - controls a Resource,
>>>       - has delegated Resource access control to one or more GSes
>>>       - may be the User
>>>
>> Confused here with the word "controls" both at RO and GS. I think RO
>> delegates Resource access management to GS but keeps control (or decisio=
n).
>>
>
> agreed - access management is better.
>
>
>>
>> Resource Owner (RO) - the entity that
>>       - controls a Resource,
>>       - relies on the services the GS to manage access to that Resource,
>>       - relies on the services of a RS to hold a Resource and guard
>> access to that Resource,
>>
>
> I don't think "guard" is a good verb. "protect" is often used.
>
OK.

>
> If we are switching from "owns a resource" to "controls a resource", then
> perhaps the entity should be a Resource Controller (RC)?
>
Great. Will remove confusion.

>
>
>
>>       - controls a Claim,
>>
>
> Why does the RO control a claim?
>
because a Claim is an assertion of the truth of some properties or
attributes of the RO.

>
>
>>       - relies on the services the GS to release that Claim to a Client.
>>
>>>
>>> Resource Server (RS) - the software that controls access to one or more
>>> Resources
>>>       - accessed via an API by Clients presenting an access token
>>>       - accepts access tokens from one or more GSes
>>>
>> I suggest "guards" instead of "controls". As access to a resource is
>> controlled by the RO.
>>
>
> How about "protects access"?
>
OK for me.

>
>
>>
>> Resource Server (RS) - the software that guards access to one or more
>> Resources
>>       - accessed by the Client that presents an access token
>>       - accepts access tokens from one or more GSes
>>
>>
>>>
>>> Grant Server (GS) - the software that manages Grants
>>>     - has been delegated to manage Resource access by the RO
>>>     - has been delegated to release Claims about the User
>>>     - grants the Client access to Resources after obtaining the require=
d
>>> consent from the RO
>>>     - provides the Client Claims about the User after obtaining the
>>> required consent from the User
>>>
>> Term User is confusing here. This is why it is eligible for renaming.
>> - Claims are about RO not User
>> - Consent is from RO not User.
>>
>
> I'm confused why the Claims are about the RO and not the User.
>
Because the  user consumes the resource and the claim. I do like Justin's
suggestion to call user the "Requesting Party"

>
> We have introduced the term RO so that entity can be differentiated from =
a
> User, and there are many use cases where there is a User. Not having a Us=
er
> seems very confusing to me.
>
Then let us call him a  "Requesting Party"

>
>
>>
>> Grant Server (GS) - the software that manages Grants
>>     - has been delegated to manage Resource access by the RO
>>     - has been delegated to release Claims about the RO
>>     - grants the Client access to Resources after obtaining the required
>> consent from the RO
>>     - provides the Client Claims about the RO after obtaining the
>> required consent from the RO
>>
>>
>>> Client - the software that wants to access Resources and obtain Claims
>>>     - executed by a User or a non-human service account
>>>     - requests Grants from the Grant Server
>>>     - accesses Resources at an RS using access tokens
>>>
>> Client - the software that wants to access Resources and obtain Claims
>> on behalf of a User or non-human service account
>>    Note-1: in a typical interaction cycle, the client:
>>       - receives the resource access request from the User or acts
>> autonomously,
>>       - interacts with the RS to discover authorization requirements,
>>       - interacts with the GS to obtain Access Tokens,
>>       - interacts with the RS to access the Resource using Access Tokens=
.
>>
>
> The Client also transfers the user experience to the GS in some flows.
>
Yes but this is just a mechanism. Not an act.

>
> Where do Claims fit into the cycle above?
>
A claim is just an Assertion (attribute, property) related to the RO. This
can be part of the authorization requirements. e.g. User/Client/RS are
requesting to know the e-mail of the RO.

>
>
>>
>>
>>>
>>> User - the human using a Client
>>>     - may also be the RO for one or more Resources
>>>     - may have Claims managed at a GS
>>>
>> Not sure a user has to be human.
>>
>
> Why not? I think NOT having the User be a human is confusing.
>
Let us stay by the role "Requesting Party"instead of the entity "User"

>
>
>> Maybe first renaming to "Requesting Party" might help with narrowing the
>> term.
>>
>
>>
>>> Some comments:
>>>
>>> A Claim is a well understood term in the field. We should use it. It is
>>> still a Claim if it comes directly from the GS or from an RS.
>>>
>> I do not understand why a Resource release by an RS shall be h to as a
>> claim, even if the content of the Resource is an assertion. It will lead=
 to
>> confusion. If we limit claims to information GS releases into Token, Use=
r
>> Info, and other objects it returns, this will help separate
>> responsibilities between GS and RS. As soon as RS services and informati=
on,
>> this is called a Resource, no matter the nature of the content of that
>> information.
>>
>>
>>> I think Grant Server is the right term. A Grant contains claims and/or
>>> access to resources. I have defined all the terms above without using t=
he
>>> term authorization. :) -- I am pondering renaming most things called
>>> Authorization in XAuth to Access.
>>>
>> Ok.
>>
>>>
>>> Claim Issuer - I think we may need to add this party to our
>>> nomenclature. This is the entity that issues Claims. It may be a GS or =
an
>>> RS.
>>>
>> Yes for the term "Claim Issuer".
>>
>> No for a "Claim Issuer" being an RS. At least not in its role as an RS.
>> RS shall focus on guarding and serving a Resource. Issuing a claim is
>> authoritative and might come with more complexity (verification of
>> authenticity). Having an RS issue a claim will overload the role of an R=
S
>> and increase the complexity of the framework.
>>
>> /Francis
>>
>>
>>> /Dick
>>>
>>> =E1=90=A7
>>>
>>> On Thu, Jul 23, 2020 at 8:07 AM Justin Richer  wrote:
>>>
>>>> Up-front question to the Chairs, do we have a good place to capture
>>>> this kind of thing? A non-spec document like this would be a good cand=
idate
>>>> for a wiki page. Do we have plans to set up a GitHub repository or sim=
ilar?
>>>> If so we could use the wiki capabilities there to at least get this st=
uff
>>>> written down. Use cases would be good to capture there as well.
>>>>
>>>>
>>>>
>>>> Francis,
>>>>
>>>> First, I want to thank you for putting the work in to getting some
>>>> vocabulary down. This is not an easy task! Some notes on specific item=
s
>>>> inline below.
>>>>
>>>> On Jul 21, 2020, at 8:33 PM, Francis Pouatcha  wrote:
>>>>
>>>> Hello Dick, Justin, Tom, Denis,
>>>>
>>>> Below is a new version of the dictionary includings comments from
>>>> different threads. Change log includes:
>>>> - avoided the expression "owns a resource" in favor of the expression
>>>> "controls a resource"
>>>> - included the clarification "resource access" and "claim release"
>>>> - included a clarification User vs. RO
>>>> - tried to clarify the word User-Agent
>>>> - added the definition of a Claim
>>>>
>>>> Terms
>>>> =3D=3D=3D=3D=3D
>>>>
>>>> Party - represents a role in the GNAP protocol flow. A party can take
>>>> the form of a web service, an application installed on the user device=
 and
>>>> acting autonomously or the form of a natural person (resp. of an auton=
omous
>>>> device) using an application to interact with other parties.
>>>>
>>>> Resource - a piece of data or web service
>>>>       - controlled by a Resource Owner (RO),
>>>>       - held and guarded by a Resource Server (RS) and
>>>>       - serviced by the RS to a Client, if the Client provides a valid
>>>> Authorization.
>>>>
>>>> Claim - a piece of data
>>>>       - controlled by a Resource Owner (RO),
>>>>       - held and guarded by the Grant Server (GS) and
>>>>       - released by the GS to a Client as part of an Authorization.
>>>>
>>>>
>>>> The differentiation between =E2=80=9Cresource=E2=80=9D and =E2=80=9Ccl=
aim=E2=80=9D is important since
>>>> it separates items that get tied to an access token=E2=80=99s rights (=
=E2=80=9Cresources=E2=80=9D)
>>>> with items that come back directly to the client without going through=
 a
>>>> separate API. The term =E2=80=9Cclaim=E2=80=9D is problematic here tho=
ugh because it is
>>>> used broadly in the community to mean, roughly, =E2=80=9Ca statement a=
bout the end
>>>> user=E2=80=9D. It=E2=80=99s therefore both too broad and too narrow in=
 the wrong ways: a
>>>> =E2=80=9Cclaim=E2=80=9D could come back as part of an API response, li=
ke the OIDC UserInfo
>>>> Endpoint, and so it=E2=80=99s not a good name for this item. Even the =
OIDC =E2=80=9Cclaims=E2=80=9D
>>>> query language defines several different targets for returning the =E2=
=80=9Cclaims=E2=80=9D
>>>> about the user, and none of them match the method that GNAP is looking=
 to
>>>> use here. A =E2=80=9Cclaim=E2=80=9D is also generally understood in th=
e identity community
>>>> to be a statement about the user, and the data coming back directly to=
 the
>>>> client might be about the user or something else, especially as we loo=
k
>>>> forward to extensions of GNAP.
>>>>
>>>> I think we should focus on the separation of the delivery mechanism,
>>>> but I=E2=80=99m not sure what good alternatives would be. Perhaps:
>>>>
>>>>  - =E2=80=9Caccess right=E2=80=9D for things tied to the API/token
>>>>  - =E2=80=9Cdata response=E2=80=9D for things coming back directly to =
the client
>>>>
>>>> I=E2=80=99m not particularly thrilled by these names, but I think rece=
nt list
>>>> conversation shows that we need to get away from =E2=80=9Cclaim=E2=80=
=9D as it=E2=80=99s overloaded.
>>>>
>>>>
>>>> Resource Owner (RO) - the party that
>>>>       - controls a Resource,
>>>>       - relies on the services the GS to manage access to that Resourc=
e,
>>>>       - relies on the services of a RS to hold the Resource and guard
>>>> access to that Resource,
>>>>       - controls a Claim,
>>>>       - relies on the services the GS to release that Claim to a Clien=
t.
>>>>
>>>> Resource Server (RS) - the party that
>>>>       - holds a resource and guards access to that resource on behalf
>>>> of the RO,
>>>>       - services the Resource to the requesting Client, provided the
>>>> Client presents a valid Authorization.
>>>>       The RS is generally deployed as a web service.
>>>>
>>>> Grant Server (GS) - the party that
>>>>       - manages access to a Resource on behalf of the RO,
>>>>       - holds Claims and releases them when consented by the RO.
>>>>       For each Resource access request, the GS might request the
>>>> Consent of the RO and produce a corresponding Authorization that is gi=
ven
>>>> to the requesting Client.
>>>>
>>>>
>>>> I don=E2=80=99t like the shift from =E2=80=9CAuthorization Server=E2=
=80=9D to =E2=80=9CGrant Server=E2=80=9D,
>>>> and it especially doesn=E2=80=99t make sense in light of the definitio=
ns of =E2=80=9Cgrant=E2=80=9D
>>>> and =E2=80=9Cauthorization=E2=80=9D above. I believe we should stick w=
ith =E2=80=9CAuthorization
>>>> Server=E2=80=9D if it=E2=80=99s a single role. I would also propose th=
at we have a separate
>>>> term for the RO-interactive portion vs. the client-facing portion, as =
has
>>>> been brought up in a few threads. Maybe these get different names enti=
rely,
>>>> or maybe they are =E2=80=9Caspects=E2=80=9D of the AS, I=E2=80=99m not=
 sure.
>>>>
>>>>
>>>> Consent - act of an RO :
>>>>       - approving access to a Resource, means approval that a Resource
>>>> he controls can be given to the Client by the RS.
>>>>       - approving release of a Claim, means approval that a Claim he
>>>> controls can be included by the GS in an Authorization to be returned =
to
>>>> the Client.
>>>>
>>>> Grant - material form of an RO Consent. In order not to interact with
>>>> the RO on each Resource access request, the GS might store the RO Cons=
ent
>>>> in the form of a Grant for reuse.
>>>>
>>>> Authorization - externalized form of a Grant as known to the GS and th=
e
>>>> RS.
>>>>       - The GS converts a Grant into an Authorization for use in a
>>>> Resource access request.
>>>>       - The RS evaluates an Authorization to decide on whether or not
>>>> to release the Resource to the Client.
>>>>
>>>> Client - the party that provides the infrastructure used by a User to
>>>> access a Resource. The client infrastructure is designed to:
>>>>       - Receive the resource access request from the User,
>>>>       - Interact with the RS to discover authorization requirements,
>>>>       - Interact with the GS to obtain an Authorization to access the
>>>> Resource,
>>>>       - Interact with the RS to access the Resource on behalf of the
>>>> User.
>>>>
>>>>
>>>> I think we should be clear that what we call the =E2=80=9Cclient=E2=80=
=9D is a piece of
>>>> software operated by the user. It=E2=80=99s true that this software mi=
ght have
>>>> multiple parts of its =E2=80=9Cinfrastructure=E2=80=9D but it=E2=80=99=
s always software.
>>>>
>>>>
>>>> User - the party using the infrastructure of the Client to gain access
>>>> to a Resource or a Claim.
>>>>
>>>>
>>>> In UMA, we call this the =E2=80=9CRequesting Party=E2=80=9D, or RqP. W=
e might want to
>>>> consider adopting this terminology here as well.
>>>>
>>>>
>>>> Clarifications:
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>
>>>> User vs. RO :
>>>>       - the User is the party using the infrastructure of the Client t=
o
>>>> gain access to a Resource or a Claim,
>>>>       - the RO is the party controlling access to a Resource or
>>>> controlling the release of a Claim.
>>>> In many use cases, User and RO will be represented by the same party
>>>> (see oAuth2), but GNAP exposes use cases where User and RO are represe=
nted
>>>> by different parties.
>>>>
>>>> User-Agent :
>>>> User and RO are parties that might be represented by a natural person
>>>> or an autonomous device. In those cases, User (resp. RO) might need th=
e
>>>> help of an application to interact with other parties. Such an applica=
tion
>>>> is generally referred to as the "User-Agent".
>>>>
>>>>
>>>> The term =E2=80=9Cuser agent=E2=80=9D is often used to be equivalent t=
o the web
>>>> browser, and not the more general use here. I think we=E2=80=99re seei=
ng more
>>>> =E2=80=9Cagent=E2=80=9D terminology for helper applications like digit=
al wallets and AI
>>>> bots, which would seem to be covered under your definition here.
>>>>
>>>>
>>>> Feedbacks are welcome.
>>>>
>>>>
>>>> Again, thanks so much for getting this going!
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> Best regards,
>>>> /Francis
>>>>
>>>>
>>>> On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> FYI: I consider the release of claims to be an "authorization" as
>>>>>>>> well.
>>>>>>>>
>>>>>>> Great. Then it is included.
>>>>>>>
>>>>>>
>>>>>> I pivoted to using the term Grant rather than authorization so that
>>>>>> it included both authorizing access to a resource, and authorizing t=
he
>>>>>> release of an identity claim.
>>>>>>
>>>>>> Perhaps we should not use the word "authorization"?
>>>>>>
>>>>> Authorization is currently used to refer to the token issued by the
>>>>> GSand presented to the RS by the Client. I have no alternative word f=
or now.
>>>>>
>>>>>>
>>>>>> "resource access" and "claim release"
>>>>>>
>>>>>> A Grant then covers both?
>>>>>>
>>>>> Yes, Great! The word Grant fits best for both. I suggest adding this
>>>>> clarification to that dictionary.
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> IE, the user authorizes the GS to release a DOB claim to a Client.
>>>>>>>>
>>>>>>> I guess you mean the "RO" authorizes the GS to release a DOB!
>>>>>>>
>>>>>>
>>>>>> Yes, thanks for clarifying!
>>>>>>
>>>>>> /Dick
>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> 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/
>>
> =E1=90=A7
>


--=20
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--0000000000002ee98405ab2eed01
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Thu, Jul 23, 2020 at 10:44 PM Dick=
 Hardt <dick.hardt@gmail.com=
> wrote:


On Thu, Jul 23, 2020 at 7:16 PM Francis P=
ouatcha <fpo@adorsys=
.de> wrote:
Hello Dick, my feedback inline

@Fabian : i am not yet consistent with using the notation=
 you referred=C2=A0to in=C2=A0https://www.iso.org/obp/ui/#i=
so:std:iso-iec:27000:ed-5:v1:en. Still to come.

On Thu, Jul 23, 2020 at =
7:52 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis

Th=
anks again for putting=C2=A0this together. I have taken your definitions an=
d adjusted them to match how I think of them. I dropped the term "part=
ies" because I did not think it added value. I am explicit about what =
each party is -- software, a human, or an entity. Let me know where you dis=
agree!


Resource - protected data or software f=
unctionality
=C2=A0 =C2=A0 =C2=A0 - controlled by a Resource Owner (RO),=

=C2=A0 =C2=A0 =C2=A0 - protected by the Resource Server (RS)
<=
/div>
Yes=C2=A0

Claim - a statement about the User
I would stay with RO not User. I added some=
 clarification=C2=A0after the feedback of Justin (see below)=C2=A0


=C2=A0
=C2=A0 =C2=A0 =C2=A0 - may be obtained from the Grant Server (GS)=
 by a Client
Yes.=C2=A0
=C2=A0 =C2=A0 =
=C2=A0 - may be a Resource the Client can access through an RS
Not sure we need to refer to a Resource as a Claim.

Here is why I say a Claim m=
ay be a=C2=A0Resource.=C2=A0

A Claim may be obtain=
ed by a Client calling an RS. This is effectively what the userinfo endpoin=
t is in OpenID Connect. A Client may also update a Claim that is managed by=
 an RS.=C2=A0
In OIDC the UserInfo endpo=
int is exposed by the OP not by an RP. Spec wording is confusing because th=
e endpoint is referred to as a protected resource. If you derive from this =
that the OP is a resource server (RP), you turn the OP into an RP relying o=
n itself. This cyclic relationship has to be broken in GNAP for simplicity.=


Note-x on GS definition: having a GS protecting a=
ccess to some Claims does not make the GS a RS.

Fo=
r simplicity, let us keep overlapping=C2=A0out:=C2=A0
- GS guards=
 Claims
- RS guards Resources

I do not s=
ee a Client updating a Claim in the scope of any of these protocols. Neithe=
r GNAP nor oAuth2 nor OIDC.
=C2=A0

A Claim - an assertion of the truth of some properties or at=
tributes of the RO.
=C2=A0 Note-1: A Claim is issued eithe=
r by the GS or by another claim issuer.


I'm viewing the Claims Issuer as an=
 entity, not a piece of software. It is the entity trusted by other parties=
 to make a Claim about the User. The GS and RS may issue claims on behalf o=
f the Claims Issuer.
No. Issuer is GS. A=
ny twiking=C2=A0of the word will diverge it from oAuth2 and OIDC and increa=
se complexity.

This is why RS shall not issue anyt=
hing,=C2=A0shall not deal with claims, .... RS guards Resources. If you sta=
rt dealing with RS issuing claims, you start dealing with RS exposing jwks-=
url so issued claims can be verified, then you fall back at having those RS=
es being GSes.

=C2=A0
=C2=A0 Note-2: A Claim is held and guarded by th=
e Grant Server (GS).

What is the significance of this statement? Signed claims don't exist=
 until asked for, so they are not "held" anywhere.
A Claim can exist before. GS might hold a Claim issued=
 by an external "Claim Issued".
=C2=
=A0
=C2=A0 Note-3: A Claim is =
released by the GS to a Client.=C2=A0
<=
div>
The model of a Claim being obtained from an RS is a comm=
on use case.=C2=A0
I am not aware of any=
 of them. Unless=C2=A0we are calling a GS a RS.
=C2=A0
=C2=A0 Note-4: The permission to=
 release of a Claim is given by the RO.

I will see what you say below on User ...
=C2=A0


Gran=
t - the Claims and/or Resource Access the User and/or RO have granted to th=
e Client by the GS
=C2=A0 =C2=A0 - requested by a Client
=C2=A0 =C2=
=A0 - granted by a GS after any required consent has been obtained from the=
 User and/or RO
"User and/or RO"=
 is confusing. I suggest we keep the term User out. Term User is even eligi=
ble for renaming. I suggest staying with RO.
=


The User of the Client and the RO may not be the same e=
ntity. Some resources may be controlled by the RO, and others by the User. =
That is why User and/or RO. They are two different parties.
I need the example of a User that is different from the=
 RO and that controls=C2=A0the RO's Resource.=C2=A0

And if a User controls a Resource, then he does it as the "Owner=
" of that Resource(playing the role of the RO for that Resource).

If we talk about roles and not entities, we will not f=
all into this confusion.
=C2=A0

=


Access Token - an artifact representing the acces=
s a client has been granted to one or more Resources
=C2=A0 =C2=
=A0 - created by the GS
=C2=A0 =C2=A0 - presented by the Client when acc=
essing a Resource at an RS
An access token=
 might contain=C2=A0Claims.

While there may be statements about the User in the access token, it is =
not the mechanism for transmitting Claims to the Client -- and I think the =
access token SHOULD be opaque to the Client most of the time.
- Access "might" contain a claim ("mus=
t" not). Precision is essential as we can not kill this practice witho=
ut removing the concept of assertion based tokens.
- Returning th=
e information to the client does not mean the client is the consumer of the=
 information. The client might not have access to the content of an encrypt=
ed token, or even just to the embedded encrypted claim. The intended destin=
ation of the claim will consume the claim. But for the GNAP, the GS returns=
 the token to the client.
=C2=A0

Access Token=C2=A0-=C2=A0an artifact representing the access a client has bee=
n granted to one or more Resources
=C2=A0 Note-1: An access token=
 is=C2=A0created by the GS
=C2=A0 Note-2:=C2=A0An access token ca=
n also contain claims

See=
 above.=C2=A0
=C2=A0
=C2=A0 Note-3: =
An access token is=C2=A0presented by the Client when accessing a Resource a=
t an RS
=C2=A0
Resource Owner (RO) - the entity that
=
=C2=A0 =C2=A0 =C2=A0 - controls a Resource,
=C2=A0 =C2=A0 =C2=A0 - has d=
elegated Resource access control to one or more GSes
=C2=A0 =C2=A0 =C2=
=A0 - may be the User
Confused here with t=
he word "controls" both at RO and GS. I think RO delegates Resour=
ce access management to GS but keeps control (or decision).

agreed - access management is better.
=C2=A0

Resource Owner (RO) - the entity that
=C2=A0 =
=C2=A0 =C2=A0 - controls a Resource,
=C2=A0 =C2=A0 =C2=A0 - relies on th=
e services the GS to manage access to that Resource,
=C2=A0 =C2=A0 =C2=
=A0 - relies on the services of a RS to hold a Resource and guard access to=
 that Resource,

I don=
't=C2=A0think "guard" is a good verb. "protect" is =
often used.
OK.=C2=A0

If we are switching from "owns a resource&qu=
ot; to "controls a resource", then perhaps the entity should be a=
 Resource Controller (RC)?
Great. Will r=
emove confusion.=C2=A0

=C2=A0
=C2=A0 =C2=A0 =C2=A0 - controls a Claim,

Why does the RO control a c=
laim?
because a Claim is=C2=A0an assertion of the truth of some=
 properties or attributes of the RO.=C2=A0
<=
div>=C2=A0
=C2=A0 =C2=A0 =C2=A0 - relies on t=
he services the GS to release that Claim to a Client.

Resource Se=
rver (RS) - the software that controls access to one or more Resources
=
=C2=A0 =C2=A0 =C2=A0 - accessed via an API by Clients presenting an access =
token
=C2=A0 =C2=A0 =C2=A0 - accepts access tokens from one or more GSes=
 
I suggest "guards" instead of =
"controls". As access to a resource is controlled by the RO.=C2=
=A0

How about "prote=
cts access"?
OK for me.=C2=A0
=

=C2=A0

Resource Server (RS) -=C2=A0the softwa=
re that guards access to one or more Resources
=C2=A0 =C2=A0 =C2=A0 - accessed by t=
he Client that=C2=A0presents an access token
=C2=A0 =C2=A0 =C2=A0 - a=
ccepts access tokens from one or more GSes
=

=C2=A0

Grant Server (GS) - the =
software that manages Grants
=C2=A0 =C2=A0 - has been delegated to manag=
e Resource access by the RO
=C2=A0 =C2=A0 - has been delegated to releas=
e Claims about the User
=C2=A0 =C2=A0 - grants the Client access to Reso=
urces after obtaining the required consent from the RO
=C2=A0 =C2=A0 - p=
rovides the Client Claims about the User after obtaining the required conse=
nt from the User
Term User is confusing he=
re. This is why it is eligible for renaming.
- Claims are about R=
O=C2=A0not User
- Consent is from RO not User.
<=
/blockquote>

I'm confused why the Claims are about t=
he RO and not the User.
Because the=C2=
=A0 user consumes the resource and the claim. I do like Justin's sugges=
tion=C2=A0to call user the "Requesting Party"

We have introduced the term RO so that entity can =
be differentiated from a User, and there are many use cases where there is =
a User. Not having a User seems very confusing to me.
Then let us call him a=C2=A0=C2=A0"Requesting Party"=
;
<=
div class=3D"gmail_quote">
=C2=A0
=C2=A0
Grant Server =
(GS) - the software that manages Grants
=C2=A0 =C2=A0 - has been delegated=
 to manage Resource access by the RO
=C2=A0 =C2=A0 - has been delegated to=
 release Claims about the RO
=C2=A0 =C2=A0 - grants the Client access to R=
esources after obtaining the required consent from the RO
=C2=A0 =C2=A0 =
- provides the Client Claims about the RO after obtaining the required cons=
ent from the RO
=C2=A0
Client - the softwar=
e that wants to access Resources and obtain Claims
=C2=A0 =C2=A0 - execu=
ted by a User or a non-human service account 
=C2=A0 =C2=A0 - requests G=
rants from the Grant Server
=C2=A0 =C2=A0 - accesses Resources at an RS =
using access tokens
Client -=C2=A0the software that wants to access Resources an=
d obtain Claims on behalf of a=C2=A0User or non-human service account
=

=C2=A0 =C2=A0Note-1: in a typical interaction cy=
cle, the client:
=C2=A0 =C2=A0 =C2=A0=
 - receives the resource access request from the User or acts autonomously,=

=
=C2=A0 =C2=A0 =C2=A0 - interacts with the RS to discover authorization requ=
irements,
=C2=A0 =C2=A0 =C2=A0 - interacts with the GS to obtain Access Toke=
ns,
=C2=A0 =C2=A0 =C2=A0 - interacts with the RS to access the Resource=
 using Access Tokens.

<=
div>The Client also transfers the user experience to the GS in some flows.<=
/div>
Yes but this is just a mechanism. Not an=
 act.=C2=A0

Where do Claims fit=
 into the cycle above?
A claim is just a=
n Assertion (attribute, property) related to the RO. This can be part of th=
e authorization requirements. e.g. User/Client/RS are requesting to know th=
e e-mail=C2=A0of the RO.
=C2=A0
=C2=A0

User - the human using a Client
=C2=A0 =C2=
=A0 - may also be the RO for one or more Resources
=C2=A0 =C2=A0 - may h=
ave Claims managed at a GS
Not sure a user=
 has to be human.=C2=A0

Why not? I think NOT having the User be a human is confusing.=C2=A0
Let us stay by the role=C2=A0"Requestin=
g Party"instead of the entity "User"=C2=A0
=C2=A0
<=
div dir=3D"ltr">
Maybe first rena=
ming to "Requesting Party" might help with narrowing the term.


Some comments:

A Claim is a w=
ell understood term in the field. We should use it. It is still a Claim if =
it comes directly from the GS or from an RS.=C2=A0
=

I do not understand why a Resource release by an RS shall be h to as a=
 claim, even if the content of the Resource is an assertion. It will lead t=
o confusion. If we limit claims to information GS releases into Token, User=
 Info, and other objects it returns, this will help separate responsibiliti=
es between GS and RS. As soon as RS services and information, this is calle=
d a Resource, no matter the nature of the content of that information.


I think Grant Server is the right term. A Gran=
t contains claims and/or access to resources. I have defined all the terms =
above without using the term authorization. :) -- I am pondering renaming m=
ost things called Authorization in XAuth to Access.
Ok.=C2=A0

Claim Issuer - I think we may need to add =
this party to our nomenclature. This is the entity that issues Claims. It m=
ay be a GS or an RS.=C2=A0
Yes for the term &q=
uot;Claim Issuer".

No for a "Claim Issue=
r" being an RS. At least not in its role as an RS. RS shall focus on g=
uarding and serving a Resource. Issuing a claim is authoritative=C2=A0and m=
ight come with more complexity=C2=A0(verification of authenticity). Having =
an RS issue a claim will overload the role of an RS and increase the comple=
xity of the framework.

/Francis

<=
br>
/Dick

3D""=E1=90=A7

On Thu, Jul 23, 2020 at 8:07 AM Justin Richer <jricher@mit.edu> wrote:
Up-front question to=
 the Chairs, do we have a good place to capture this kind of thing? A non-s=
pec document like this would be a good candidate for a wiki page. Do we hav=
e plans to set up a GitHub repository or similar? If so we could use the wi=
ki capabilities there to at least get this stuff written down. Use cases wo=
uld be good to capture there as well.=C2=A0



Francis,

First, I want to thank you f=
or putting the work in to getting some vocabulary down. This is not an easy=
 task! Some notes on specific items inline below.

On Jul 21, 2020, at 8:33 PM, Francis Pouatcha <fpo@adorsys.de> wrote:<=
/div>
Hello Dick, Justin, Tom, Den=
is,

Below=C2=A0is a new version of the dictionary includ=
ings comments=C2=A0from different=C2=A0threads. Change log includes:
<=
div>- avoided the expression "owns a resource" in favor of the ex=
pression "controls=C2=A0a resource"
- included the clar=
ification=C2=A0"resource access" and "claim release"
- included a clarification User vs. RO
- tried to clarify=
 the word User-Agent
- added the definition of a Claim
=

Terms
=3D=3D=3D=3D=3D

Party - represents a role in=
 the GNAP protocol flow. A party can take the form of a web service, an app=
lication installed on the user device and acting autonomously or the form o=
f a natural person (resp. of an autonomous device) using an application to =
interact with other parties.

Resource - a piece of data or web servi=
ce
=C2=A0 =C2=A0 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0=
 =C2=A0 =C2=A0 - held and guarded by a Resource Server (RS) and
=C2=A0 =
=C2=A0 =C2=A0 - serviced by the RS to a Client, if the Client provides a va=
lid Authorization.

Claim - a piece of data
=C2=A0 =C2=A0 =C2=A0 -=
 controlled by a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=A0 - held and gu=
arded by the Grant Server (GS) and
=C2=A0 =C2=A0 =C2=A0 - released by th=
e GS to a Client as part of an Authorization.

The differentiation between =E2=80=9Cresource=E2=
=80=9D and =E2=80=9Cclaim=E2=80=9D is important since it separates items th=
at get tied to an access token=E2=80=99s rights (=E2=80=9Cresources=E2=80=
=9D) with items that come back directly to the client without going through=
 a separate API. The term =E2=80=9Cclaim=E2=80=9D is problematic here thoug=
h because it is used broadly in the community to mean, roughly, =E2=80=9Ca =
statement about the end user=E2=80=9D. It=E2=80=99s therefore both too broa=
d and too narrow in the wrong ways: a =E2=80=9Cclaim=E2=80=9D could come ba=
ck as part of an API response, like the OIDC UserInfo Endpoint, and so it=
=E2=80=99s not a good name for this item. Even the OIDC =E2=80=9Cclaims=E2=
=80=9D query language defines several different targets for returning the =
=E2=80=9Cclaims=E2=80=9D about the user, and none of them match the method =
that GNAP is looking to use here. A =E2=80=9Cclaim=E2=80=9D is also general=
ly understood in the identity community to be a statement about the user, a=
nd the data coming back directly to the client might be about the user or s=
omething else, especially as we look forward to extensions of GNAP.=C2=A0

I think we should focus on the separation of the de=
livery mechanism, but I=E2=80=99m not sure what good alternatives would be.=
 Perhaps:

=C2=A0- =E2=80=9Caccess right=E2=80=9D f=
or things tied to the API/token
=C2=A0- =E2=80=9Cdata response=E2=
=80=9D for things coming back directly to the client

I=E2=80=99m not particularly thrilled by these names, but I think recent=
 list conversation shows that we need to get away from =E2=80=9Cclaim=E2=80=
=9D as it=E2=80=99s overloaded.


Resource Owner (RO) - the party that=

=C2=A0 =C2=A0 =C2=A0 - controls a Resource,
=C2=A0 =C2=A0 =C2=A0 - r=
elies on the services the GS to manage access to that Resource,
=C2=A0 =
=C2=A0 =C2=A0 - relies on the services of a RS to hold the Resource and gua=
rd access to that Resource,
=C2=A0 =C2=A0 =C2=A0 - controls a Claim,
=
=C2=A0 =C2=A0 =C2=A0 - relies on the services the GS to release that Claim =
to a Client.

Resource Server (RS) - the party that=C2=A0
=C2=A0 =C2=A0 =C2=A0 - holds a resource and guards access to that reso=
urce on behalf of the RO,
=C2=A0 =C2=A0 =C2=A0 - services the Resource t=
o the requesting Client, provided the Client presents a valid Authorization=
.
=C2=A0 =C2=A0 =C2=A0 The RS is generally deployed as a web service.
Grant Server (GS) - the party that=C2=A0
=C2=A0 =C2=A0=
 =C2=A0 - manages access to a Resource on behalf of the RO,
=C2=A0 =C2=
=A0 =C2=A0 - holds Claims and releases them when consented by the RO.
=
=C2=A0 =C2=A0 =C2=A0 For each Resource access request, the GS might request=
 the Consent of the RO and produce a corresponding Authorization that is gi=
ven to the requesting Client.

I don=E2=80=99t like the shift from =E2=80=9CAuthorization Server=
=E2=80=9D to =E2=80=9CGrant Server=E2=80=9D, and it especially doesn=E2=80=
=99t make sense in light of the definitions of =E2=80=9Cgrant=E2=80=9D and =
=E2=80=9Cauthorization=E2=80=9D above. I believe we should stick with =E2=
=80=9CAuthorization Server=E2=80=9D if it=E2=80=99s a single role. I would =
also propose that we have a separate term for the RO-interactive portion vs=
. the client-facing portion, as has been brought up in a few threads. Maybe=
 these get different names entirely, or maybe they are =E2=80=9Caspects=E2=
=80=9D of the AS, I=E2=80=99m not sure.

=


Consent - act of an RO :
=
=C2=A0 =C2=A0 =C2=A0 - approving access to a Resource, means approval that =
a Resource he controls can be given to the Client by the RS.
=C2=A0 =C2=
=A0 =C2=A0 - approving release of a Claim, means approval that a Claim he c=
ontrols can be included by the GS in an Authorization to be returned to the=
 Client.

Grant - material form of an RO Consent. In order not to int=
eract with the RO on each Resource access request, the GS might store the R=
O Consent in the form of a Grant for reuse.

Authorization - external=
ized form of a Grant as known to the GS and the RS.
=C2=A0 =C2=A0 =C2=A0=
 - The GS converts a Grant into an Authorization for use in a Resource acce=
ss request.
=C2=A0 =C2=A0 =C2=A0 - The RS evaluates an Authorization to =
decide on whether or not to release the Resource to the Client.

Clie=
nt - the party that provides the infrastructure used by a User to access a =
Resource. The client infrastructure is designed to:
=C2=A0 =C2=A0 =C2=A0=
 - Receive the resource access request from the User,
=C2=A0 =C2=A0 =C2=
=A0 - Interact with the RS to discover authorization requirements,
=C2=
=A0 =C2=A0 =C2=A0 - Interact with the GS to obtain an Authorization to acce=
ss the Resource,
=C2=A0 =C2=A0 =C2=A0 - Interact with the RS to access t=
he Resource on behalf of the User.
<=
br>
I think we should be clear that what we call the =E2=80=9Ccli=
ent=E2=80=9D is a piece of software operated by the user. It=E2=80=99s true=
 that this software might have multiple parts of its =E2=80=9Cinfrastructur=
e=E2=80=9D but it=E2=80=99s always software.


User - the party using =
the infrastructure of the Client to gain access to a Resource or a Claim.

In UMA, we call th=
is the =E2=80=9CRequesting Party=E2=80=9D, or RqP. We might want to conside=
r adopting this terminology here as well.


Clarifications:
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

User vs. RO :=C2=A0
=
=C2=A0 =C2=A0 =C2=A0 - the User is the party using the infrastructure of th=
e Client to gain access to a Resource or a Claim,
=C2=A0 =C2=A0 =C2=A0 -=
 the RO is the party controlling access to a Resource or controlling the re=
lease of a Claim.
In many use cases, User and RO will be represented by =
the same party (see oAuth2), but GNAP exposes use cases where User and RO a=
re represented by different parties.

User-Agent :
User and RO are=
 parties that might be represented by a natural person or an autonomous dev=
ice. In those cases, User (resp. RO) might need the help of an application =
to interact with other parties. Such an application is generally referred t=
o as the "User-Agent".
The term =E2=80=9Cuser agent=E2=80=9D is often used to be equiv=
alent to the web browser, and not the more general use here. I think we=E2=
=80=99re seeing more =E2=80=9Cagent=E2=80=9D terminology for helper applica=
tions like digital wallets and AI bots, which would seem to be covered unde=
r your definition here.


Feedbacks are welcome.

<=
/div>

Again, thanks so much for getti=
ng this going!

=C2=A0=E2=80=94 Justin

Best rega=
rds,
/Francis


On T=
ue, Jul 21, 2020 at 2:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:
<=
br>

On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt <dick.hardt@gmail.com> wrote:


On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha <fpo@adorsys.de> wrote=
:
<=
br>
On Tue,=
 Jul 21, 2020 at 1:59 PM Dick Hardt <dick.hardt@gmail.com> wrote:
FYI: I consider=
 the release of claims to be an "authorization" as well.=C2=A0
Great. Then it is included.=C2=A0

I pivoted to using the term Grant rather than=
 authorization so that it included both authorizing access to a resource, a=
nd authorizing the release of an identity claim.

P=
erhaps we should not use the word "authorization"?=C2=A0
Authorization is currently used to refer to the =
token issued by the GSand presented to the RS by the Client. I have no alte=
rnative word for now.

"res=
ource access" and "claim release"

A=
 Grant then covers both?
Yes, Great! The=
 word Grant fits best for both. I suggest adding this clarification to that=
 dictionary.

=C2=A0

IE, the user authorizes the GS to release a DOB cl=
aim=C2=A0to a Client.
I guess you mean the &qu=
ot;RO" authorizes the GS to release a DOB!

Yes, thanks for clarifying!
=C2=A0
/Dick


--=C2=A0
Francis Pouatcha
Co-Founder and Technical Lead
<=
div>adorsys GmbH & Co. KG




-- 


3D""=E1=90=A7



-- 


--0000000000002ee98405ab2eed01--


From nobody Fri Jul 24 05:53: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 9A28A3A0AA5 for ; Fri, 24 Jul 2020 05:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 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, MALFORMED_FREEMAIL=0.116, MIME_QP_LONG_LINE=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 c5pMGJUqw6vs for ; Fri, 24 Jul 2020 05:53:19 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 113853A0AA2 for ; Fri, 24 Jul 2020 05:53:18 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id f1so7665818wro.2 for ; Fri, 24 Jul 2020 05:53:18 -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=lqj5bOOXK16knhgDbXFUTpMeV3iV9K38r3sZEs2B7CE=; b=GtbsxHPRE5PTkD4XZv0ecqRx56NpkDlqWhpzXPhxTPctpKmJH/TDyHiNghyTeZXffT MZQvOyrK+8X+BvK0BWpDcLS7/ED9TLPhoAe/sVSS41D8Mx+ZLhniysDR9gH5XqbAMoq/ Y6R/Z8B32U2tHPvtV3URRVf/v2kAZIjy5Nc5lMr0yX9cz8ClxTLIzQtcbyN6pjpnje/A szQBJHi3HGf7i0OpLL6bDUtRcAE60BICtUgZ18sdrpc8EuYEFcFxSo8ghViDgun1JZRc RDm9La3ejaFdEhFth0I3bP+/9XsT2mz7cv8UNrZuKdAszKI7SnXQiFn+BVj9KiXxbIC+ Ot5A==
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=lqj5bOOXK16knhgDbXFUTpMeV3iV9K38r3sZEs2B7CE=; b=b9AlvJHTyGc+Mn9PV4n6fdEyHacnGIiAtehIpHiUmJxZFw7X8jh0LH+/8MdpAZNXs9 F43wYQSIN7VksLWXfXSiDT9SyjnGv3gKcrcPdNXNPnMyZSIvhxcw8H/G6YSAcMbhfMgr 4IJzXDPemwH1khSeXU4Z7ANjSW0KPW+eXkHxm18CoVQkZ5SyhdcORXxutJrgf3i5/O3W A8gotGu9d3VmGMdUdQfGgGtA4O8BKnWrX2Hktw+PFiK8gMsVJRDBr2jS1+WB2HG/z01O HdVWIHJoYtQAR3rNC2KX0q35fWH6Quz1rLRWCgY7S6RlLbK5ypCYU7P5rLqNr/m4WypJ hPBA==
X-Gm-Message-State: AOAM532sVTSlzwlVH8CVNxYkbAEzCEZ4ODRoS2LPZX9RJpWJSyFRCci/ uS1dfl0MRQsos6+UdXccTiY=
X-Google-Smtp-Source: ABdhPJxNt/6DDqlaK3xYvX4WI6/YuaTky2sX8smTTEGC2Xr6LyM2znRuykP82cQoGlsFleZZVqFGVg==
X-Received: by 2002:a5d:6846:: with SMTP id o6mr8632390wrw.370.1595595197457;  Fri, 24 Jul 2020 05:53:17 -0700 (PDT)
Received: from [10.0.0.140] (bzq-109-66-125-13.red.bezeqint.net. [109.66.125.13]) by smtp.gmail.com with ESMTPSA id p11sm1354764wre.32.2020.07.24.05.53.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2020 05:53:16 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.39.20071300
Date: Fri, 24 Jul 2020 15:53:15 +0300
From: Yaron Sheffer 
To: Dick Hardt , Leif Johansson 
CC: Justin Richer , 
Message-ID: <608866FE-01F2-4933-B906-D19A8CDB8AEB@gmail.com>
Thread-Topic: using github.com/ietf-wg-gnap
References: 
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3678450796_1838864019"
Archived-At: 
Subject: Re: [Txauth] using github.com/ietf-wg-gnap
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, 24 Jul 2020 12:53:21 -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_3678450796_1838864019
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Hi Dick,

=20

I just created the GitHub org with Leif as co-owner, but from a quick read =
of the I-D, I don=E2=80=99t think we have any use for it until we have adopted wor=
king group documents. Am I missing anything?

=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: Dick Hardt 
Date: Friday, July 24, 2020 at 05:17
To: Yaron Sheffer , Leif Johansson 
Cc: Justin Richer , 
Subject: using github.com/ietf-wg-gnap

=20

Justin brought up the decision on where we are going to capture our work, a=
nd if we would do it on GitHub.

=20

I'm supportive of that. Per=20

=20

https://tools.ietf.org/html/draft-ietf-git-using-github

=20

there are a number of choices of how to use GitHub, and which features to u=
se in the WG.

=20

Config is covered by:

=20

https://tools.ietf.org/html/draft-ietf-git-github-wg-configuration

=20

Note these documents are still being worked on, but perhaps we can give tha=
t WG feedback on their docs?

=20

/Dick

=20

=20

=E1=90=A7


--B_3678450796_1838864019
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Hi Dick,
 
I just created the Gi=
tHub org with Leif as co-owner, but from a quick read of the I-D, I don=E2=80=99t =
think we have any use for it until we have adopted working group documents. =
Am I missing anything?
 
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:=
 Dick Hardt <dick.h=
ardt@gmail.com>
Date: Friday, July 24, 2020 at 05:17
To: =
Yaron Sheffer <yaronf.ietf@gmail.com>, Leif Johansson <leifj@su=
net.se>
Cc: Justin Richer <jricher@mit.edu>, <txauth@i=
etf.org>
Subject: using github.com/ietf-wg-gnap
 
Justin brought up the decision on where we are going to capture o=
ur work, and if we would do it on GitHub.
 
I'm supportive of tha=
t. Per 
 
 
there are a number of choices of how to use GitHub,=
 and which features to use in the WG.
 
Config is covered b=
y:
 
https://tools.ietf.org/html/draft-ietf-git-github-wg-=
configuration
 
Note these documents are still being wo=
rked on, but perhaps we can give that WG feedback on their docs?<=
/p>
 
/Dick
 <=
/p>
 
3D"Image=E1=90=A7<=
o:p>


--B_3678450796_1838864019--



From nobody Fri Jul 24 05:58:32 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 A45043A0A2C for ; Fri, 24 Jul 2020 05:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level: 
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QzxyEJe62Keb for ; Fri, 24 Jul 2020 05:58: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 417A23A0A29 for ; Fri, 24 Jul 2020 05:58:29 -0700 (PDT)
Received: from [192.168.1.3] (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 06OCwOoN023121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Jul 2020 08:58:25 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_F9B2FD24-14E0-4A5A-A088-0D5C5A064D2E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 24 Jul 2020 08:58:24 -0400
In-Reply-To: 
Cc: Dick Hardt , txauth@ietf.org, Tom Jones , Denis 
To: Francis Pouatcha 
References:           
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 12:58:32 -0000

--Apple-Mail=_F9B2FD24-14E0-4A5A-A088-0D5C5A064D2E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I want to focus on one aspect here:

>=20
> A Claim is a well understood term in the field. We should use it. It =
is still a Claim if it comes directly from the GS or from an RS.=20
> I do not understand why a Resource release by an RS shall be h to as a =
claim, even if the content of the Resource is an assertion. It will lead =
to confusion. If we limit claims to information GS releases into Token, =
User Info, and other objects it returns, this will help separate =
responsibilities between GS and RS. As soon as RS services and =
information, this is called a Resource, no matter the nature of the =
content of that information.

This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=E2=80=
=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D=
 could come back through an RS =E2=80=94 but in the context of GNAP, =
that makes it a resource. So we need a different word for data coming =
back directly from the AS to the client. Sometimes it=E2=80=99s going to =
be about the user, and that=E2=80=99s what we=E2=80=99re going to focus =
on here, but since you can also get information about the user from a =
resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I =
think this has been at the heart of a lot of confusion in recent =
threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does, =
and let=E2=80=99s find a way to differentiate between when an item, =
claim or otherwise,  comes as part of a resource and when it comes back =
directly. This is an important differentiating feature for GNAP.

Some straw man ideas, none of which I=E2=80=99m particularly in love =
with:

 - direct data
 - properties
 - details
 - statements

The important thing here is that it=E2=80=99s not necessarily :about: =
the RO, and that it is :not: in a resource.

Any other thoughts?

 =E2=80=94 Justin=

--Apple-Mail=_F9B2FD24-14E0-4A5A-A088-0D5C5A064D2E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
want to focus on one aspect here:


A Claim is a well =
understood term in the field. We should use it. It is still a Claim if =
it comes directly from the GS or from an =
RS. 
I do not understand =
why a Resource release by an RS shall be h to as a claim, even if the =
content of the Resource is an assertion. It will lead to confusion. If =
we limit claims to information GS releases into Token, User Info, and =
other objects it returns, this will help separate responsibilities =
between GS and RS. As soon as RS services and information, this is =
called a Resource, no matter the nature of the content of that =
information.

This is exactly why I don=E2=80=99t think we =
should use =E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using =
it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94=
 but in the context of GNAP, that makes it a resource. So we need a =
different word for data coming back directly from the AS to the client. =
Sometimes it=E2=80=99s going to be about the user, and that=E2=80=99s =
what we=E2=80=99re going to focus on here, but since you can also get =
information about the user from a resource we can=E2=80=99t just call it =
a =E2=80=9Cclaim=E2=80=9D. I think this has been at the heart of a lot =
of confusion in recent threads, as well as confusion about the scope of =
the inclusion of identity in the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean =
what it already does, and let=E2=80=99s find a way to differentiate =
between when an item, claim or otherwise,  comes as part of a =
resource and when it comes back directly. This is an important =
differentiating feature for GNAP.

Some=
 straw man ideas, none of which I=E2=80=99m particularly in love =
with:

 - direct =
data
 - properties
 - =
details
 - statements

The important thing here is that it=E2=80=99s not =
necessarily :about: the RO, and that it is :not: in a =
resource.

Any other thoughts?

 =E2=80=94 =
Justin
=

--Apple-Mail=_F9B2FD24-14E0-4A5A-A088-0D5C5A064D2E--


From nobody Fri Jul 24 06:04: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 6BA3B3A0AC1 for ; Fri, 24 Jul 2020 06:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 tvjHMrpXlkkz for ; Fri, 24 Jul 2020 06:04:49 -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 0FE643A0ABD for ; Fri, 24 Jul 2020 06:04:48 -0700 (PDT)
Received: from [192.168.1.3] (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 06OD4kf1025927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Jul 2020 09:04:46 -0400
From: Justin Richer 
Message-Id: <6415D0F2-B45F-4B76-8E89-2E0E95E63DE2@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_856EE74A-E8C1-47B2-93CA-AC6F78F8948B"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 24 Jul 2020 09:04:45 -0400
In-Reply-To: <608866FE-01F2-4933-B906-D19A8CDB8AEB@gmail.com>
Cc: Dick Hardt , Leif Johansson , txauth@ietf.org
To: Yaron Sheffer 
References:  <608866FE-01F2-4933-B906-D19A8CDB8AEB@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] using github.com/ietf-wg-gnap
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, 24 Jul 2020 13:04:50 -0000

--Apple-Mail=_856EE74A-E8C1-47B2-93CA-AC6F78F8948B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yaron, thanks for doing that! This will be a very helpful set of tools =
for the WG.=20

Yes, it will be very important when we have adopted WG documents, but =
ahead of that, there are other features that we can use. We can create a =
repository to get access to an issue tracker and wiki, before we have =
any documents. These might be very useful, especially coming out of next =
week=E2=80=99s meeting.

 =E2=80=94 Justin

> On Jul 24, 2020, at 8:53 AM, Yaron Sheffer  =
wrote:
>=20
> Hi Dick,
> =20
> I just created the GitHub org with Leif as co-owner, but from a quick =
read of the I-D, I don=E2=80=99t think we have any use for it until we =
have adopted working group documents. Am I missing anything?
> =20
> Thanks,
>                 Yaron
> =20
> From: Dick Hardt 
> Date: Friday, July 24, 2020 at 05:17
> To: Yaron Sheffer , Leif Johansson =

> Cc: Justin Richer , 
> Subject: using github.com/ietf-wg-gnap
> =20
> Justin brought up the decision on where we are going to capture our =
work, and if we would do it on GitHub.
> =20
> I'm supportive of that. Per=20
> =20
> https://tools.ietf.org/html/draft-ietf-git-using-github =

> =20
> there are a number of choices of how to use GitHub, and which features =
to use in the WG.
> =20
> Config is covered by:
> =20
> https://tools.ietf.org/html/draft-ietf-git-github-wg-configuration =

> =20
> Note these documents are still being worked on, but perhaps we can =
give that WG feedback on their docs?
> =20
> /Dick
> =20
> =20
> =E1=90=A7


--Apple-Mail=_856EE74A-E8C1-47B2-93CA-AC6F78F8948B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yaron, thanks for doing that! This will be a very helpful set =
of tools for the WG. 

Yes, it will be very important when we have adopted WG =
documents, but ahead of that, there are other features that we can use. =
We can create a repository to get access to an issue tracker and wiki, =
before we have any documents. These might be very useful, especially =
coming out of next week=E2=80=99s meeting.

 =E2=80=94 =
Justin

On Jul 24, 2020, at 8:53 AM, Yaron Sheffer =
<yaronf.ietf@gmail.com> wrote:

Hi Dick,
 
I just created the GitHub =
org with Leif as co-owner, but from a quick read of the I-D, I don=E2=80=99=
t think we have any use for it until we have adopted working group =
documents. Am I missing anything?
 
Thanks,
          &nb=
sp;     Yaron
 
From: Dick Hardt <dick.hardt@gmail.com>
Date: Friday, July 24, 2020 =
at 05:17
To: Yaron Sheffer <yaronf.ietf@gmail.com>, Leif Johansson <leifj@sunet.se>
Cc: Justin Richer <jricher@mit.edu>, =
<txauth@ietf.org>
Subject: using github.com/ietf-wg-gnap
 
Justin=
 brought up the decision on where we are going to capture our work, and =
if we would do it on GitHub.
 
I'm =
supportive of that. Per 
 
https://tools.ietf.org/html/draft-ietf-git-using-github
 
there =
are a number of choices of how to use GitHub, and which features to use =
in the WG.
 
Config is covered by:
 
https://tools.ietf.org/html/draft-ietf-git-github-wg-configurat=
ion
 
Note these documents are still being =
worked on, but perhaps we can give that WG feedback on their docs?
 
/Dick
 
 
3D"Image=E1=90=A7

=

--Apple-Mail=_856EE74A-E8C1-47B2-93CA-AC6F78F8948B--


From nobody Fri Jul 24 07: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 F333D3A0B8F for ; Fri, 24 Jul 2020 07:58:03 -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 xpx7s0ElRwrV for ; Fri, 24 Jul 2020 07:58:02 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 A7EF13A0B80 for ; Fri, 24 Jul 2020 07:58:01 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id r2so3506921wrs.8 for ; Fri, 24 Jul 2020 07:58:01 -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=uQ3SNCKbfdPLoCULXVcMCsFXsmXKrtFZAN9v02KUWlM=; b=djpJExb49ms/1ngi3i7ajzfsIF+RzKW8/6Suxfzt/4XPi/RcWuD3EhRG8Hr03xWlxe JYVj/ecvYAqQlefAI1UQ80KN2LlypK4Cw+iFFSTXFBcgGcPerOcM03vg1QTEmj1evcNH ZnR9f9DcO8gtyd+vGZbojhUMjoW3N1gQ0Yrrk=
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=uQ3SNCKbfdPLoCULXVcMCsFXsmXKrtFZAN9v02KUWlM=; b=VXeeBvn9Of6roaKUmVT6LAzPqD4WbiElXLKuxgFLDXuwceHCnmU0CwiXt7Wxq1nC3N 2QSTMfgp1pA8VuJuhBAylLMmzhfonLS19pQ7KLBqrhqLGQ1LTvuQ6HF7IlDz+oCuKKHB ermhxdPKKIOdG6ZEUq0ToMZGscIZRgwGlDoRFW9oTyzopTr+l+qZYdNxLvM7tDqUsfoX RTJ/jM0PJGcfh5SGRKkGMrePVxYg2a6f0sWcqHcdNQH+of1dy/9Zf1SWBAYUuE0RdbdL BslrlRvJfgUfmWZZUkrU9zGezPNRHsMSMuR9IfSJppehzv8H1cO9IPPBz7IDhTL+miGd LaEA==
X-Gm-Message-State: AOAM530jBosXpRFRCI7g9N5ekfLZPmazEbS4ZymfuWHN4SwiOLPZrOwf qIwtjuDpVHwjfAS2SSEdwy1maS4nMwxfKshZ+ohlqg==
X-Google-Smtp-Source: ABdhPJwC0vRo2DbdGJtooIQiAE3reefSh5PxOQDkeuWfZul5tnPDqffLQ6Ztyj583uIqNiZ1XwheufcKz0KjY4DUuIk=
X-Received: by 2002:a5d:45c9:: with SMTP id b9mr8774681wrs.283.1595602679780;  Fri, 24 Jul 2020 07:57:59 -0700 (PDT)
MIME-Version: 1.0
References: <6CC714D8-2FB2-4BE6-B70B-659C4A8198AB@gmail.com>
In-Reply-To: <6CC714D8-2FB2-4BE6-B70B-659C4A8198AB@gmail.com>
From: Francis Pouatcha 
Date: Fri, 24 Jul 2020 10:57:47 -0400
Message-ID: 
To: Yaron Sheffer 
Cc: "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000ee63df05ab3132a5"
Archived-At: 
Subject: Re: [Txauth] GNAP agenda uploaded
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, 24 Jul 2020 14:58:04 -0000

--000000000000ee63df05ab3132a5
Content-Type: text/plain; charset="UTF-8"

When and how is next week's meeting taking place? Who is invited, can
attend or is supposed to attend? Best regards. /Francis

On Mon, Jul 20, 2020 at 3:46 PM Yaron Sheffer  wrote:

> Leif and I uploaded the agenda for next week:
> https://www.ietf.org/proceedings/108/agenda/agenda-108-gnap-00.html
>
>
>
> Thanks,
>
>                 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/

--000000000000ee63df05ab3132a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


When and how is next week's=C2=A0meeting taking place?=
 Who is=C2=A0invited, can attend=C2=A0or is supposed to attend? Best regard=
s. /Francis

On Mon, Jul 20, 2020 at 3:46 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Leif and I uploaded the=
 agenda for next week: https://www.ietf.org/proceedi=
ngs/108/agenda/agenda-108-gnap-00.html
=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 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/


--000000000000ee63df05ab3132a5--


From nobody Fri Jul 24 09:08: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 1DCFA3A0EAC for ; Fri, 24 Jul 2020 09:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.629
X-Spam-Level: 
X-Spam-Status: No, score=-1.629 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.267, NICE_REPLY_A=-0.001, 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 EHouRrndzHkE for ; Fri, 24 Jul 2020 09:08:03 -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 7D52D3A0E9C for ; Fri, 24 Jul 2020 09:08:02 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d14 with ME id 747w2300R2bcEcA0347x72; Fri, 24 Jul 2020 18:08:00 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 24 Jul 2020 18:08:00 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt 
Cc: txauth@ietf.org
References:           <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>   
From: Denis 
Message-ID: 
Date: Fri, 24 Jul 2020 18:07:58 +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="------------5575EDBC1B6F6485968D4F72"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 24 Jul 2020 16:08:09 -0000

This is a multi-part message in MIME format.
--------------5575EDBC1B6F6485968D4F72
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Dick,

draft-hardt-xauth-protocol-13 describes a solution without clearly 
stating what the problem(s) to be solved is/are.

At the moment, draft-hardt-xauth-protocol-13 includes a single figure on 
page 4 and from previous discussions I understood that
it is no more up-to-date since the first data flow is now a contact with 
a RS. The reason(s) for the GS to contact a RO has still not
been explained (since the inputs and outputs are not described). The 
discovery information made available at various steps at the RS
is not described.

Figure 4 shows only a single RS. Is the relaying of one operation by 
that RS to a second RS in the scope of this document ?
If yes, how is it handled ?

Figure 4 shows only a single GS. How would be the data flow when access 
tokens from two GSs are needed by a RS ?

What we need first is not a set of "use cases" but a clear model with a 
data flows and a list of its properties/characteristics.
Then after, we can understand much better which use cases can/will be 
supported. For example, shall a RS (or its RO) have
prior relationships with the GS ? What is the difference/implications 
when it has or it hasn't ?

In order to have a fair comparison, we should try to list model 
properties/characteristics.

At the moment, the model I have described including the data flows is 
clear. The discovery information made available by a RS is clear.
I have not listed all its properties/characteristics of that model, but 
I am pretty sure that you already have a flavour of it.

In the mean time, it would be nice if you could show using two figures:

  * the case of the relaying of one operation by one RS to a second RS
    (if it is in the scope of your document),
  * the case where access tokens from two GSs are needed by one RS (if
    it is in the scope of your document).

Denis

> Hi Denis
>
> I think it would be useful to take a step back and for you to describe 
> your use case.
> After that, we can explore the different ways that your use case can 
> be addressed.
>
> Looking at your previous communication, it describes the solution, and 
> the justification,
> but it is not clear what use cases you are needing to solve.
>
> /Dick
>
>
> ᐧ
>
> On Wed, Jul 22, 2020 at 9:34 AM Denis  > wrote:
>
>     Hello Dick,
>
>     I have identified the reason of the major difference between our
>     two approaches.
>
>     Access control may be performed using either ACLs (Access Control
>     Lists) or Capabilities.
>
>     _Note _: a capability identifies a resource and an allowed
>     operation that can be performed on that resource.
>
>     You are advocating a Capabilities approach while I am advocating
>     an ACL approach.
>
>     The capabilities approach allows the GS to trace every operation
>     performed by the users on any RS known by a GS.
>     The management of these capabilities is made via the GS or at the
>     GS by the various ROs. If the management is made
>     via the GS, then a trusted communication channel needs to be
>     established with every RO. If the management is made
>     at the GS, then an authentication mechanism needs to be
>     established with every RO. In the last case, the GS has the
>     ability to know all the capabilities of the users whether they are
>     used or not. The less that can be said is that this model
>     is not privacy friendly.
>
>     With the ACL approach, a RO directly manages an ACL placed in
>     front of each RS. The AccessControl Decision Function
>     (ADF) at the RS is able to keep track from prior decisions. The GS
>     is kept ignorant of the content of these ACLs and only
>     delivers to its clients attributes that are placed into access
>     tokens. Such a model may be privacy friendly.
>
>     Other comments are between the lines prefixed with [Denis].
>
>>
>>     On Tue, Jul 21, 2020 at 11:26 AM Denis >     > wrote:
>>
>>         Hello Dick,
>>
>>         Thank you for your feedback. Comments are between the lines.
>>
>>>         comments inserted ...
>>>
>>>         On Tue, Jul 21, 2020 at 6:03 AM Denis >>         > wrote:
>>>
>>>             Hello Dick,
>>>
>>>             I duplicate the most important comment at the beginning
>>>             of this email:
>>>
>>>                 You are considering using an access control model to
>>>                 build a**workflow model.
>>>                 **
>>>                 While it may be interesting to define a workflow
>>>                 model, this should be considered
>>>                 as a separate and different work item.
>>>
>>>             See the other comments between the lines.
>>>
>>>>             On Mon, Jul 20, 2020 at 2:05 AM Denis
>>>>             > wrote:
>>>>
>>>>                 Hi Dick,
>>>>
>>>>>                 On Fri, Jul 17, 2020 at 9:21 AM Denis
>>>>>                 >
>>>>>                 wrote:
>>>>>
>>>>>                     Hello Francis and Dick,
>>>>>
>>>>>                     The good news first: we are making some
>>>>>                     progress. We are now close to an agreement
>>>>>                     with steps (1) up to (3),
>>>>>                     ... except that the place where the user
>>>>>                     consent is captured is not mentioned/indicated.
>>>>>
>>>>
>>>>                 This major question which is currently left
>>>>                 unanswered is where, when and how the user consent
>>>>                 is captured.
>>>>
>>>>
>>>>             When is covered, per the sequence. How and where are
>>>>             out of scope of what I drafted.
>>>
>>>             It is clear that the "User consent and choice" is not
>>>             currently addressed in the draft, but it should.
>>>             The support of the "User consent and choice" has strong
>>>             implications not only in the sequences of the exchanges
>>>             but also by which entity it should be performed.
>>>
>>>         "consent" is in the latest draft 7 times.
>>
>>         "Consent" is present 5 times. The User consent is different
>>         from the RO consent (when/if it is required).
>>
>>             The server acquires consent and authorization from the
>>             user *and/**or resource owner **if required.*
>>
>>             User consent is *often required* at the GS. GNAP enables
>>             a Client and  GS to negotiate the interaction mode for
>>             the GS to obtain consent.
>>
>>             The GS *may *require explicit consent from the RO or User
>>             to provide these to the Client.
>>
>>         The User consent is not an alternative to the RO consent. So
>>         using "and/or" in the first sentence is incorrect.
>>
>>
>>     My language is sloppy there. Consent is always from the RO. The
>>     User may be the RO.
>
>     [Denis] No. Once again: The "/User consent/" is different from
>     what you call the "/RO consent/" (when/if it is required).
>     The "RO consent" is not in fact a consent but the release of a
>     capability to a client by one of the many R0s with which
>     the GS has relationships.
>
>>         Since the second sentence is using the wording "often
>>         required" there is no requirement to get the User consent.
>>
>>     User consent may not be required. There may not be a User. The
>>     consent may have been gathered previously.
>
>     [Denis] In order to follow the privacy principles, a "User
>     consent" phase is required. The User is a natural person.
>     A Client is called either by a User (i.e. a natural person) or by
>     a Client application.
>
>>         The second sentence does not consider the possibility to get
>>         the User consent in a place different from the GS.
>>
>>     Agreed. But we do agree that the GS gets the consent, either
>>     directly from the RO, or from the Client (in your example).
>
>     [Denis] No. I disagree. In an ACL based systems, the GS does not
>     need to ask or receive any consent.
>     The client selects the set of attributes that it wants to be
>     inserted into an access token.
>     If the GS has the requested attributes, then it provides them,
>     otherwise it returns an error to the Client.
>
>>         IMO, the User consent should be captured by the Client, i.e.
>>         not by the GS.
>>         The information used to obtain the User consent should be
>>         standardized (... and it can be standardized).
>>
>>>         I think the abstract sequence as proposed by Francis is a
>>>         great addition, and would clarify where consent is in the
>>>         sequence.
>>
>>         The current sketch does not illustrate the place the User
>>         Consent is captured, in particular by the Client.
>>
>>     It is an abstraction. The GS receives the consent. How consent is
>>     gathered is a detail that is dependent on the use case.
>
>     [Denis] I really wonder whether there is really a "consent" to be
>     received by the GS in both cases (i.e. ACLs or Capabilities).
>
>       * For ACLs, the consent needs to be done by the Client.
>       * For Capabilities, the current description is not clear since
>         the inputs and the outputs for this "consent" phase
>         are not currently described in the draft.
>
>>>>                 Another important point to consider and to explain
>>>>                 is related to the assurances that the user can
>>>>                 obtain about
>>>>                 the respect of his choices. This point is currently
>>>>                 left unanswered in draft-hardt-xauth-protocol-13.
>>>>
>>>             This point is equally important: such assurance can only
>>>             be obtained if the access token returned to the client
>>>             is not considered to be opaque to the client. This is a
>>>             necessary condition but not the single condition:
>>>             the Client must also be in a position to
>>>             capture/memorize the "User consent and choice" of the
>>>             user in order to be able
>>>             to verify it afterwards using the content of the access
>>>             token(s).
>>>
>>>
>>>         We disagree on this being a requirement for all use cases.
>>>         It may be in some.
>>
>>         OK. Then this means that there will be no sentence in the
>>         draft such as :
>>         "access tokens returned to the client are not considered to
>>         be opaque to the client".
>>
>>
>>     For OAuth use cases, which GNAP supports, the access token is
>>     opaque to the Client. As you have noted, there are use cases
>>     where the access token is NOT opaque.
>
>     [Denis] Wait a second. There is no requirement to support all
>     OAuth use cases.
>     I believe that there is a requirement to support OAuth 2.0 ASs,
>     while the clients may be different
>     and hence GNAP clients do not need to inherit of the limitations
>     of OAuth 2.0 clients.
>
>>>>
>>>>>                     If a RO needs to be involved and since a RO is
>>>>>                     directly associated with a RS, why can't it be
>>>>>                     directly queried
>>>>>                     by the appropriate RS after step (2) or later on ?
>>>>>
>>>>>
>>>>>                 Good question. Perhaps you can expand on a use
>>>>>                 case where that would be useful?
>>>>
>>>>                 Before I expand, would you be able to explain first
>>>>                 under which circumstances a RO needs to be queried
>>>>                 by a GS ?
>>>>                 How can the GS identify which RO to query ?
>>>>
>>>>             If the User is the RO, then the GS knows who to query.
>>>
>>>             I still have difficulties to understand what you mean here.
>>>             How could a GS know that "the User is the RO" ?  If "the
>>>             User is the RO", why does the GS needs to query the User ?
>>>
>>>
>>>         To get consent?
>>
>>         To get a "RO consent" to himself ???
>>
>>
>>     The GS needs consent from the RO. If the RO is the User, then
>>     consent from the RO is equivalent to consent from the User.
>
>     [Denis] See above.
>
>>
>>>>             If the RO is a separate entity, then the GS knows the
>>>>             RO from the RS being queried.
>>>
>>>              ... and this gives the ability for the GS to log/trace
>>>             all the RSs accessed by a given User and at which
>>>             instant of time the access token has been granted.
>>>
>>>>             An example is a user would like access to an enterprise
>>>>             asset where a workflow is started to gain approval, and
>>>>             an administrator or manager provides consent.
>>>
>>>             Thanks for this example. I finally understand what you
>>>             have in mind: you are considering using an access
>>>             control model to build a *workflow model*.
>>>             While it may be interesting to define a workflow model,
>>>             this should be considered as a *separate and different
>>>             work item*.
>>>
>>>
>>>         The actual workflow is out of scope.
>>
>>         I am glad you agree with this. But this means that your
>>         example was not appropriate to illustrate your point.
>>
>>
>>     It illustrates a use case where the RO and User are not the same
>>     party, and why the GS needs to query the RO, which was your
>>     question if I understood it correctly.
>
>     [Denis] Since the inputs and the outputs for this "RO consent"
>     phase are not currently described in the draft, the point is still
>     unsolved.
>
>>         As soon as there is a RO consent obtained at the GS, the
>>         major problem is that the GS is able to act as Big Brother.
>>         If a RO consent is performed at the RS, then the GS will not
>>         know who the RS is: it is then unable to act as Big Brother,
>>         even if it would enjoy to play that role.
>>
>>     In an enterprise use case, the GS's knowledge of who is accessing
>>     which RS is a feature.
>
>     Do you mean that it is "normal" in an enterprise that a single
>     point of control is able to trace all their actions ?
>     From a security point of view, a single point of failure will have
>     dramatic consequences.
>
>>     In your use cases, it seems that the RO is the User.
>
>     I do hope that you have finally understood that, in my use case,
>     the RO is **not** the User.
>
>>     The GS knows the User is wanting to let a Client access
>>     something. If the access token is generic, and could be presented
>>     to any RS that provides a standardized function,
>>     then the GS does not know which RS is being accessed by a Client
>>     for the User. This seems to meet your privacy objectives. If not,
>>     what is wrong?
>
>     For security reasons, an access token needs to be targeted (which
>     does not necessarily mean that an identifier of the RS shall be
>     included into the access token).
>
>>>         if the admin grants access, then the access granted to the
>>>         client changes.
>>>
>>>             The model you propose may be suited for an enterprise
>>>             environment but is not scalable over the Internet.
>>>
>>>         It is one of the use cases we are working to address.
>>>
>>>             What is needed is an access control model usable over
>>>             the Internet with millions of RSs and thousands of ASs/GSs.
>>>
>>>         I agree the model should also scale to internet scale.
>>
>>         Fine. Another point on which we are in agreement.
>>
>>         The model can scale to the Internet based on the following
>>         assumptions:
>>
>>             The flow starts with the steps (1) to (4) as illustrated
>>             by Francis, i.e. the flow starts with a contact with a RS.
>>
>>         *+----+  +------+  +---+  +---+  +---+
>>         |User|  |Client|  |RS |  |GS |  |RO |
>>         +----+  +------+  +---+  +-+-+  +-+-+
>>           |(1) Service Request     |      |
>>           |-------->|       |      |      |
>>           |         |(2) Service Intent   |
>>           |         |------>|      |      |
>>           |         |(3) AuthZ Challenge  |
>>           |         |<------|      |      |
>>           |         |(4) AuthZ Request    |
>>           |         |------------->|      |*
>>
>>         The GS/AS does not need to have any prior relationship with
>>         ROs and/or RSs.
>>
>>         Furthermore, it is possible to prevent the GS to act as Big
>>         Brother when the identity of the RS is not disclosed to the GS.
>>
>>
>>     What happens after (4) above?
>
>     [Denis] The key point is that we first need to agree on the first
>     four exchanges. Do we ?
>
>     The fifth exchange is different whether ACLs or Capabilities are
>     being used.
>
>>>>>                     Which information is supposed to be presented
>>>>>                     to the RO ?
>>>>>                     Which information is supposed to be returned
>>>>>                     by the RO ?
>>>>>
>>>>>
>>>>>                 Just like how the user authenticates to an AS, how
>>>>>                 the AS and RO communicate is out of scope.
>>>>
>>>>                 At the moment, the usefulness of a dialogue between
>>>>                 a GS and a RO has not been explained, nor demonstrated.
>>>>                 The question is about the functionality of that
>>>>                 dialogue in terms of input and output information
>>>>                 (and not about
>>>>                 the design of a protocol or of a user interface).
>>>>                 Anyway, AFAIU a dialogue between a GS and a RO is
>>>>                 optional.
>>>>
>>>>
>>>>             See enterprise example above.
>>>
>>>             It is not an access control example, but a workflow example.
>>>
>>>             Access  control has been defined a long time ago and the
>>>             last edition of the model has been confirmed in year
>>>             1996: ISO/IEC 10181-3: 1996.
>>>             "Information technology — Open Systems Interconnection —
>>>             Security frameworks for open systems: Access control
>>>             framework — Part 3".
>>>
>>>             Two major functions have ben defined: an AccessControl
>>>             Enforcement Function (AEF) and an AccessControl Decision
>>>             Function(ADF).
>>>
>>>                 AccessControl Enforcement Function (AEF):
>>>                 A specialized function that is part of the access
>>>                 path between an initiator and a target on each
>>>                 access request and enforces the decision made by the
>>>                 ADF.
>>>
>>>                 AccessControl Decision Function (ADF) :
>>>                 A specialized function that makes access control
>>>                 decisions by applying access control policy rules to
>>>                 an access request, ADI (of initiators, targets,
>>>                 access requests,
>>>                 or that retained from prior decisions), and the
>>>                 context in which the access request is made.
>>>
>>>             The role of the RO is to define the "access control
>>>             policy rules" at the RS according to thecontext in which
>>>             the access request is made.
>>>
>>>         I'm pretty familiar with access control systems. :)
>>>
>>>         I would say that the access control is happening at the RS.
>>>         The client presents a token when accessing an API.
>>>         The RS uses the token, and any policy required, to make an
>>>         access decision.
>>
>>         Fine. It looks like we are in agreement. Unfortunately, this
>>         is not the case just below.
>>
>>>         Here is flow:
>>>
>>>         1) The Client requests access to an RS from the GS.
>>
>>         No. We are no more in agreement. This is different from the
>>         flow drawn by Francis.
>>
>>     My bad. Typo. I meant RO.
>>
>>>         2) The GS queries the RS if access should be granted.
>>
>>          No. The GS should not be forced to have a flow with the RS.
>>
>>     Same mistake as above, I meant RO.
>>
>>>         3) If access is granted, the GS creates an access token
>>>         representing the granted access, and returns it to the Client.
>>
>>         This model is by no way conformant to ISO/IEC 10181-3: 1996
>>
>>     I'm unclear on why, or why it is even relevant.
>>
>>>         4) The Client presents the access token to the RS to show it
>>>         has been granted access.
>>
>>         No. The client presents a token when accessing an API. The RS
>>         uses the token, and any policy required, to make an access
>>         decision.
>>         The token never contains an information like "Please grant an
>>         access to the holder of this token".
>>
>>     Let me provide more clarity in the sentence:
>>
>>     The Client presents the access token to the RS, to show the RS
>>     that the Client has been granted access to a resource at the RS
>>     by the GS.
>
>     [Denis] This time, please consider both the ACLs approach and the
>     Capabilities approach.
>
>>>         A couple advantages of this model:
>>>         - that the RS does not need to know much, if anything about
>>>         the Client.
>>>         - the access token MAY be self contained so that the Client
>>>         does not need to query the GS on each access.
>>
>>         There are so many disadvantages that I will not list them.
>>
>>     Darn: I clearly was not firing on all cylinders when I typed this
>>     out. Let me correct:
>>
>>>     - the access token MAY be self contained so that the RS does not
>>>     need to query the GS on each access to the RS by the Client.
>
>     [Denis] A few comments in the case of a capability approach:
>
>         - for each GS, the RS needs to locally manage which
>         operation(s) is/are allowed to it.
>
>         - the GS needs to establish a trusted communication channel or
>         an authentication mechanism with each RO
>            (which is associated with an explicit RS identifier).
>
>         - the GS could play the role of the RO and hence be in a
>         position to issue any capability for any RS (without a "RO
>         consent").
>
>            The target of an attack will clearly be the GS.
>
>>>         I would not say that GNAP is an access control protocol, as
>>>         how the RS uses the token to determine access is out of scope.
>>
>>         This is where we have a major discrepancy: how the RS uses
>>         the token to determine access is *within* the scope.
>>
>     [Denis] Do you agree or disagree ?
>>
>>         The RS announces in advance to the client what it needs so
>>         that the client can perform a a given operation and if the
>>         client supplies the requested attributes
>>         obtained from some GS/AS(s) trusted by the RS, then access to
>>         that RS is granted by the RS. If the RS cannot perform the
>>         requested operation on its own,
>>         then the client should be informed about some requested
>>         attributes that need to be obtained from some GS/AS(s)
>>         trusted by the next RS(s) in a chain
>>         for subsequent operations. The User consent should also be
>>         obtained before performing the chaining operation.
>>
>>         Chaining operations between RSs over the Internet is within
>>         the scope (... and may be achieved).
>>
>     [Denis] Do you agree or disagree ?
>
>     Denis
>
>>>>>                 For many use cases, the User is the RO, and the
>>>>>                 interaction is through a user interface, not a
>>>>>                 machine protocol.
>>>>
>>>>                 Wait a second. You wrote "the User is the RO". The
>>>>                 User is attempting to make an access to a RS by
>>>>                 using a Client.
>>>>                 _That_ User is not the RO of the RS.
>>>>
>>>>             The user being the RO is the initial use case for OAuth.
>>>
>>>             OAuth 2.0 is no more mandating such a case.
>>>
>>>
>>>         I don't know what you mean by that.
>>
>>         Copy and paste from draft-ietf-oauth-security-topics:
>>
>>             OAuth initially assumed a static relationship between
>>             client, authorization server and resource servers.  (...)
>>             With the increasing adoption of OAuth, this simple model
>>             dissolved and, in several scenarios, was replaced
>>             by a dynamic establishment of the relationship between
>>             clients on one side and the authorization and
>>             resource servers of a particular deployment on the other
>>             side.
>>
>>             This way, the same client could be used to access
>>             services of different providers (in case of standard APIs,
>>             such as e-mail or OpenID Connect) or serve as a frontend
>>             to a particular tenant in a multi-tenancy environment.
>>
>>
>>     This sentence does not mention the RO or the Client. I'm confused
>>     what we are talking about
>>
>>>>             A client application would like access to the user's
>>>>             photos at a photo sharing site. The resource is the
>>>>             user's photos. The user is the owner of that resource.
>>>
>>>             If the user has already pre established the access
>>>             control policy rules so that it can access to his own
>>>             photos
>>>             then he does not need to grant in real time any
>>>             additional authorization.
>>>
>>>         I don't understand what you are trying to say. The photo
>>>         sharing example was a driving use case for the creation of
>>>         OAuth.
>>
>>         We would need to revisit the original scenario and consider
>>         if it can be addressed in a different way than the original way.
>>
>>     The use case is the same. Is there a different solution you are
>>     proposing?
>
>
>     -- 
>     Txauth mailing list
>     Txauth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/txauth
>


--------------5575EDBC1B6F6485968D4F72
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

      
Hi Dick,

      


      

      
draft-hardt-xauth-protocol-13
        describes a solution without clearly stating what the problem(s)
        to be solved is/are.

      


      

      
At the moment,
        draft-hardt-xauth-protocol-13 includes a single figure on page 4
        and from previous discussions I understood that 

        it is no more up-to-date since the first data flow is now a
        contact with a RS. The reason(s) for the GS to contact a RO has
        still not 

        been explained (since the inputs and outputs are not described).
        The discovery information made available at various steps at the
        RS 

        is not described.

        


        

      

      
Figure 4 shows only a single RS. Is
        the relaying of one operation by that RS to a second RS in the
        scope of this document ?

        If yes, how is it handled ?

      

      


      

      
Figure 4 shows only a single GS. How
        would be the data flow when access tokens from two GSs are
        needed by a RS ?

      

      

      What we need first is not a set of "use cases" but a clear model
      with a data flows and a list of its properties/characteristics. 

    

    
Then after, we can understand much
      better which use cases can/will be supported. For example, shall a
      RS (or its RO) have 

      prior relationships with the GS ? What is the
      difference/implications when it has or it hasn't ?

    

    


    

    
In order to have a fair comparison, we
      should try to list model properties/characteristics.

    


    

    
At the moment, the model I have
      described including the data flows is clear. The discovery
      information made available by a RS is clear.

    
I have not listed all its
      properties/characteristics of that model, but I am pretty sure
      that you already have a flavour of it.

    


    

    
In the mean time, it would be nice if
      you could show using two figures:

    
    
      
  • the case of the relaying of one operation by one RS to a
        second RS (if it is in the scope of your document),
    • 
      
  • the case where access tokens from two GSs are needed by one RS
        (if it is in the scope of your document).
    
      
    • 
    

    

      
Denis

    

    


    

    

      
      
Hi Denis
        


        

        
I think it would be useful to take a step back and for you
          to describe your use case. 

          After that, we can explore the different ways that your use
          case can be addressed. 

        


        

        
Looking at your previous communication, it describes the
          solution, and the justification, 

          but it is not clear what use cases you are needing to solve.

        


        

        
/Dick

        


        

        


        

      

      
ᐧ

      

      

        
On Wed, Jul 22, 2020 at 9:34
          AM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hello Dick,

            


            

            
I have identified the reason of the major difference
              between our two approaches.

            


            

            
Access control may be performed using either ACLs
              (Access Control Lists) or Capabilities.

            


            

            
Note : a capability identifies a resource and
              an allowed operation that can be performed on that
              resource.

            

            


            

            
You are advocating a Capabilities approach while I am
              advocating an ACL approach.

            
The capabilities approach allows the GS to trace every
              operation performed by the users on any RS known by a GS.

              The management of these capabilities is made via the GS or
              at the GS by the various ROs. If the management is made 

              via the GS, then a trusted communication channel needs to
              be established with every RO. If the management is made 

              at the GS, then an authentication mechanism needs to be
              established with every RO. In the last case, the GS has
              the 

              ability to know all the capabilities of the users whether
              they are used or not. The less that can be said is that
              this model 

              is not privacy friendly.

            
With the ACL approach, a RO directly manages an ACL
              placed in front of each RS. The Access Control Decision
                Function 

                  (ADF)
                at the RS is able to keep track from prior decisions. The
              GS is kept ignorant of the content of these ACLs and only
              

              delivers to its clients attributes that are placed into
              access tokens. Such a model may be privacy friendly.

            
Other comments are between the lines prefixed with
              [Denis].

            

              

                


                  

                    
On Tue, Jul 21,
                      2020 at 11:26 AM Denis <denis.ietf@free.fr>
                      wrote:

                    

                    

                      

                        
Hello Dick,

                        


                        

                        
 Thank you for your feedback. Comments are
                          between the lines.

                        


                        

                        

                          

                            
comments inserted ... 

                            

                            

                              
On Tue,
                                Jul 21, 2020 at 6:03 AM Denis <denis.ietf@free.fr>
                                wrote:

                              

                              

                                

                                  
Hello Dick,

                                  


                                  

                                  
I duplicate the most important
                                    comment at the beginning of this
                                    email:

                                  

                                    
You are considering using an
                                      access control model to build a
                                      workflow model.

                                       

                                      While it may be interesting to
                                      define a workflow model, this
                                      should be considered 

                                      as a separate and different work
                                      item.

                                  

                                  
See the other comments between
                                    the lines.

                                  

                                  


                                  

                                  

                                    
On Mon, Jul 20, 2020
                                      at 2:05 AM Denis <denis.ietf@free.fr>
                                      wrote:

                                      

                                        

                                          

                                            
Hi Dick,

                                            


                                            

                                            

                                              
On Fri, Jul
                                                17, 2020 at 9:21 AM
                                                Denis <denis.ietf@free.fr>
                                                wrote:

                                                

                                                  

                                                    

                                                      
Hello Francis
                                                        and Dick,

                                                      


                                                      

                                                      
The good news
                                                        first: we are
                                                        making some
                                                        progress. We are
                                                        now close to an
                                                        agreement with
                                                        steps (1) up to
                                                        (3), 

                                                        ... except that
                                                        the place where
                                                        the user consent
                                                        is captured is
                                                        not
                                                        mentioned/indicated.

                                                    

                                                  

                                                

                                              

                                            

                                            

                                            This major question which is
                                            currently left unanswered is
                                            where, when and how the user
                                            consent is captured.

                                          

                                        

                                        


                                        

                                        
When is covered, per the
                                          sequence. How and where are
                                          out of scope of what I
                                          drafted. 

                                        

                                      

                                    

                                  

                                  
It is clear that the "User consent
                                    and choice" is not currently
                                    addressed in the draft, but it
                                    should.

                                    The support of the "User consent and
                                    choice" has strong implications not
                                    only in the sequences of the
                                    exchanges 

                                    but also by which entity it should
                                    be performed.

                                

                              

                              
"consent" is in the latest draft 7
                                times. 

                              

                            

                          

                        

                        
"Consent" is present 5 times. The User
                          consent is different from the RO consent
                          (when/if it is required). 

                        

                        

                          
The server acquires consent and
                            authorization from the user and/or
                              resource owner if required.

                          

                          
User consent is often required at
                            the GS. GNAP enables a Client and  GS to
                            negotiate the interaction mode for the GS to
                            obtain consent.

                          

                          
 The GS may require explicit
                            consent from the RO or User to provide these
                            to the Client.

                          

                        

                        
The User consent is not an alternative to the
                          RO consent. So using "and/or" in the first
                          sentence is incorrect.

                      

                    

                    


                    

                    
My language is sloppy there. Consent is always
                      from the RO. The User may be the RO.

                  

                

              

            

            
[Denis] No. Once again: The "User consent" is
              different from what you call the "RO consent"
              (when/if it is required). 

              The "RO consent" is not in fact a consent but the release
              of a capability to a client by one of the many R0s with
              which 

              the GS has relationships. 

            

            

              

                

                  

                    

                      

                        
Since the second sentence is using the
                          wording "often required" there is no
                          requirement to get the User consent.

                        

                      

                    

                    
User consent may not be required. There may not
                      be a User. The consent may have been gathered
                      previously.

                  

                

              

            

            
[Denis] In order to follow the privacy principles, a
              "User consent" phase is required. The User is a natural
              person.

              A Client is called either by a User (i.e. a natural
              person) or by a Client application. 

            

            

              

                

                  

                    

                      

                        
 

                        
The second sentence does not consider the
                          possibility to get the User consent in a place
                          different from the GS.

                      

                    

                    
Agreed. But we do agree that the GS gets the
                      consent, either directly from the RO, or from the
                      Client (in your example).

                  

                

              

            

            
[Denis] No. I disagree. In an ACL based systems, the GS
              does not need to ask or receive any consent.

              The client selects the set of attributes that it wants to
              be inserted into an access token.

              If the GS has the requested attributes, then it provides
              them, otherwise it returns an error to the Client.

            

              

                

                  

                    

                      

                        
IMO, the User consent should be captured by
                          the Client, i.e. not by the GS. 

                          The information used to obtain the User
                          consent should be standardized (... and it can
                          be standardized).

                        

                        

                          

                            
I think the
                              abstract sequence as proposed by Francis
                              is a great addition, and would clarify
                              where consent is in the sequence. 

                          

                        

                        
The current sketch does not illustrate the
                          place the User Consent is captured, in
                          particular by the Client.

                      

                    

                    
It is an abstraction. The GS receives the
                      consent. How consent is gathered is a detail that
                      is dependent on the use case.

                  

                

              

            

            
[Denis] I really wonder whether there is really a
              "consent" to be received by the GS in both cases (i.e.
              ACLs or Capabilities).

            

            
    
              
  • For ACLs, the consent needs to be done by the Client.
    • 
              
  • For Capabilities, the current description is not clear
                since the inputs and the outputs for this "consent"
                phase
    
                are not currently described in the draft.
    • 
            

            

              

                

                  

                    
 

                    

                      

                        

                          

                            

                              
 

                              

                                

                                  

                                    

                                      

                                        

                                          
 Another important point
                                            to consider and to explain
                                            is related to the assurances
                                            that the user can obtain
                                            about 

                                            the respect of his choices.
                                            This point is currently left
                                            unanswered in
                                            draft-hardt-xauth-protocol-13.

                                          

                                        

                                      

                                    

                                  

                                  
This point is equally important:
                                    such assurance can only be obtained
                                    if the access token returned to the
                                    client 

                                    is not considered to be opaque to
                                    the client. This is a necessary
                                    condition but not the single
                                    condition: 

                                    the Client must also be in a
                                    position to capture/memorize the
                                    "User consent and choice" of the
                                    user in order to be able 

                                    to verify it afterwards using the
                                    content of the access token(s).

                                

                              

                              


                              

                              
We disagree on this being a
                                requirement for all use cases. It may be
                                in some. 

                              

                            

                          

                        

                        
OK. Then this means that there will be no
                          sentence in the draft such as :

                          "access tokens returned to the client are not
                          considered to be opaque to the client".

                      

                    

                    


                    

                    
For OAuth use cases, which GNAP supports, the
                      access token is opaque to the Client. As you have
                      noted, there are use cases where the access token
                      is NOT opaque.

                  

                

              

            

            
[Denis] Wait a second. There is no requirement to support
              all OAuth use cases. 

              I believe that there is a requirement to support OAuth 2.0
              ASs, while the clients may be different 

              and hence GNAP clients do not need to inherit of the
              limitations of OAuth 2.0 clients.

            

              

                

                  

                    
 

                    

                      

                        

                          

                            

                              
 

                              

                                

                                  

                                    

                                      

                                        

                                          
 

                                            

                                              

                                                

                                                  

                                                    

                                                      
If a RO needs
                                                        to be involved
                                                        and since a RO
                                                        is directly
                                                        associated with
                                                        a RS, why can't
                                                        it be directly
                                                        queried 

                                                        by the
                                                        appropriate RS
                                                        after step (2)
                                                        or later on ?

                                                    

                                                  

                                                  


                                                  

                                                  
Good question.
                                                    Perhaps you can
                                                    expand on a use case
                                                    where that would be
                                                    useful?

                                                

                                              

                                            

                                            
Before I expand, would
                                              you be able to explain
                                              first under which
                                              circumstances a RO needs
                                              to be queried by a GS ?

                                              How can the GS identify
                                              which RO to query ?

                                          

                                        

                                        
If the User is the RO, then
                                          the GS knows who to query. 

                                        

                                      

                                    

                                  

                                  
I still have difficulties to
                                    understand what you mean here. 

                                    How could a GS know that "the User
                                    is the RO" ?  If "the User is the
                                    RO", why does the GS needs to query
                                    the User ? 

                                  

                                

                              

                              


                              

                              
To get consent?

                            

                          

                        

                        
To get a "RO consent" to himself ???

                      

                    

                    


                    

                    
The GS needs consent from the RO. If the RO is
                      the User, then consent from the RO is equivalent
                      to consent from the User.

                  

                

              

            

            
[Denis] See above.

            

            

              

                

                  

                    
 

                    

                    

                      

                        

                          

                            

                              
 

                              

                                

                                  

                                    

                                      

                                        
If the RO is a separate
                                          entity, then the GS knows the
                                          RO from the RS being queried.
                                          

                                        

                                      

                                    

                                  

                                  
 ... and this gives the ability for
                                    the GS to log/trace all the RSs
                                    accessed by a given User and at
                                    which instant of time the access
                                    token has been granted.

                                  

                                    

                                      

                                        
An example is a user would
                                          like access to an enterprise
                                          asset where a workflow is
                                          started to gain approval, and
                                          an administrator or manager
                                          provides consent.

                                      

                                    

                                  

                                  
Thanks for this example. I finally
                                    understand what you have in mind:
                                    you are considering using an access
                                    control model to build a workflow
                                      model. 

                                    While it may be interesting to
                                    define a workflow model, this should
                                    be considered as a separate and
                                      different work item.

                                

                              

                              


                              

                              
The actual workflow is out of scope.
                              

                            

                          

                        

                        
I am glad you agree with this. But this means
                          that your example was not appropriate to
                          illustrate your point.

                        

                      

                    

                    


                    

                    
It illustrates a use case where the RO and User
                      are not the same party, and why the GS needs to
                      query the RO, which was your question if I
                      understood it correctly.

                  

                

              

            

            
[Denis] Since the inputs and the outputs for this "RO
              consent" phase are not currently described in the draft,
              the point is still unsolved.

            

            

              

                

                  

                    

                      

                        
 As soon as there is a RO consent obtained at
                          the GS, the major problem is that the GS is
                          able to act as Big Brother.

                          If a RO consent is performed at the RS, then
                          the GS will not know who the RS is: it is then
                          unable to act as Big Brother, 

                          even if it would enjoy to play that role.

                      

                    

                    
In an enterprise use case, the GS's knowledge
                      of who is accessing which RS is a feature.

                  

                

              

            

            
Do you mean that it is "normal" in an enterprise that a
              single point of control is able to trace all their actions
              ? 

              From a security point of view, a single point of failure
              will have dramatic consequences.

            

              

                

                  

                    
In your use cases, it seems that the RO is the
                      User. 

                  

                

              

            

            
I do hope that you have finally understood that, in my
              use case, the RO is **not** the User.

            

              

                

                  

                    
The GS knows the User is wanting to let a
                      Client access something. If the access token is
                      generic, and could be presented to any RS that
                      provides a standardized function, 

                      then the GS does not know which RS is being
                      accessed by a Client for the User. This seems to
                      meet your privacy objectives. If not, what is
                      wrong?

                  

                

              

            

            
For security reasons, an access token needs to be
              targeted (which does not necessarily mean that an
              identifier of the RS shall be included into the access
              token).

            

            

              

                

                  

                    

                      

                        

                          

                            

                              
if the admin grants access, then the
                                access granted to the client changes. 

                              

                              

                                

                                  
 

                                  
The model you propose may be suited
                                    for an enterprise environment but is
                                    not scalable over the Internet.

                                

                              

                              
It is one of the use cases we are
                                working to address. 

                              

                              

                                

                                  
 What is needed is an access
                                    control model usable over the
                                    Internet with millions of RSs and
                                    thousands of ASs/GSs.  

                                  

                                

                              

                              
I agree the model should also scale
                                to internet scale. 

                              

                            

                          

                        

                        
Fine. Another point on which we are in
                          agreement. 

                        

                        
The model can scale to the Internet based on
                          the following assumptions:

                        

                          
The flow starts with the steps (1) to (4)
                            as illustrated by Francis, i.e. the flow
                            starts with a contact with a RS.

                        

                        
+----+  +------+  +---+  +---+
                               +---+

                              |User|  |Client|  |RS |  |GS |  |RO |

                              +----+  +------+  +---+  +-+-+  +-+-+

                                |(1) Service Request     |      |

                                |-------->|       |      |      |

                                |         |(2) Service Intent   |

                                |         |------>|      |      |

                                |         |(3) AuthZ Challenge  |

                                |         |<------|      |      |

                                |         |(4) AuthZ Request    |

                                |         |------------->|      |

                        
The GS/AS does not need to have any prior
                          relationship with ROs and/or RSs.

                        
Furthermore, it is possible to prevent the GS
                          to act as Big Brother when the identity of the
                          RS is not disclosed to the GS.

                        

                      

                    

                    


                    

                    
What happens after (4) above? 

                    

                  

                

              

            

            
[Denis] The key point is that we first need to agree on
              the first four exchanges. Do we ?

            

            
The fifth exchange is different whether ACLs or
              Capabilities are being used.

            

            

              

                

                  

                    
 

                    

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
Which
                                                        information is
                                                        supposed to be
                                                        presented to the
                                                        RO ?

                                                        Which
                                                        information is
                                                        supposed to be
                                                        returned by the
                                                        RO ?

                                                    

                                                  

                                                  


                                                  

                                                  
Just like how the
                                                    user authenticates
                                                    to an AS, how the AS
                                                    and RO communicate
                                                    is out of scope.

                                                  

                                                

                                              

                                            

                                            
At the moment, the
                                              usefulness of a dialogue
                                              between a GS and a RO has
                                              not been explained, nor
                                              demonstrated.

                                              The question is about the
                                              functionality of that
                                              dialogue in terms of input
                                              and output information
                                              (and not about 

                                              the design of a protocol
                                              or of a user interface).
                                              Anyway, AFAIU a dialogue
                                              between a GS and a RO is
                                              optional.

                                            

                                          

                                        

                                        


                                        

                                        
See enterprise example
                                          above.

                                      

                                    

                                  

                                  
It is not an access control
                                    example, but a workflow example.

                                  
Access  control
                                    has been defined a long time ago and
                                    the last edition of the model has
                                    been confirmed in year 1996: ISO/IEC 10181-3:
                                        1996.

                                    "Information
                                      technology — Open Systems
                                      Interconnection — Security
                                      frameworks for open systems:
                                      Access control framework —
                                      Part 3".

                                  
Two
                                      major functions have ben defined:
                                      an Access
                                        Control Enforcement
                                        Function (AEF) and an Access Control
                                      Decision Function(ADF).

                                  

                                    
Access
                                        Control Enforcement
                                        Function (AEF):

                                        A specialized function that is
                                        part of the access path between
                                        an initiator and a target on
                                        each access request and enforces
                                        the decision made by the ADF.

                                    Access Control
                                      Decision Function
                                        (ADF) :

                                    A
                                      specialized function that makes
                                      access control decisions by
                                      applying access control policy
                                      rules to an access request, ADI
                                      (of initiators, targets, access
                                      requests, 

                                    or
                                      that retained from prior
                                      decisions), and the context in
                                      which the access request is made.

                                  
The role of the RO is to define the
                                    "access
                                      control policy rules" at the RS
                                      according to the
                                        context in which the access
                                        request is made.

                                

                              

                              
I'm pretty familiar with access
                                control systems. :) 

                              


                              

                              
I would say that the access control
                                is happening at the RS. The client
                                presents a token when accessing an API.
                                

                                The RS uses the token, and any policy
                                required, to make an access decision.

                            

                          

                        

                        
Fine. It looks like we are in agreement.
                          Unfortunately, this is not the case just
                          below.

                        

                        

                          

                            

                              
Here is flow:

                              


                              

                              
1) The Client requests access to an
                                RS from the GS. 

                              

                            

                          

                        

                        
No. We are no more in agreement. This is
                          different from the flow drawn by Francis.

                      

                    

                    
My bad. Typo. I meant RO.

                    
 

                    

                      

                        

                          

                            

                              
2) The GS queries the RS if access
                                should be granted. 

                              

                            

                          

                        

                        
 No. The GS should not be forced to have a
                          flow with the RS.

                      

                    

                    
Same mistake as above, I meant RO. 

                    

                      

                        
 

                        

                          

                            

                              
3) If access is granted, the GS
                                creates an access token representing the
                                granted access, and returns it to the
                                Client. 

                              

                            

                          

                        

                        
This model is by no way conformant to ISO/IEC 10181-3:
                              1996 

                            

                      

                    

                    
I'm unclear on why, or why it is even relevant.
                      

                    

                    

                      

                        
 

                        

                          

                            

                              
4) The Client presents the access
                                token to the RS to show it has been
                                granted access. 

                              

                            

                          

                        

                        
No. The client presents a token when
                          accessing an API. The RS uses the token, and
                          any policy required, to make an access
                          decision.

                          The token never contains an information like
                          "Please grant an access to the holder of this
                          token".

                      

                    

                    
Let me provide more clarity in the sentence:

                    


                    

                    
The Client presents the access token to the RS,
                      to show the RS that the Client has been granted
                      access to a resource at the RS by the GS.

                  

                

              

            

            
[Denis] This time, please consider both the ACLs approach
              and the Capabilities approach.

            

              

                

                  

                    
 

                    

                      

                        

                          

                            

                              
A couple advantages of this model:

                              
- that the RS does not need to know
                                much, if anything about the Client. 

                              
- the access token MAY be self
                                contained so that the Client does not
                                need to query the GS on each access. 

                              

                            

                          

                        

                        
There are so many disadvantages that I will
                          not list them.

                      

                    

                    
Darn: I clearly was not firing on all cylinders
                      when I typed this out. Let me correct:

                    


                    

                    

                      

                        

                          

                            
- the access token MAY be self
                              contained so that the RS does not need to
                              query the GS on each access to the RS by
                              the Client.

                          

                        

                      

                    

                  

                

              

            

            
[Denis] A few comments in the case of a capability
              approach:

            

              
- for each GS, the RS needs to locally manage which
                operation(s) is/are allowed to it.

                

                - the GS needs to establish a trusted communication
                channel or an authentication mechanism with each RO 

                   (which is associated with an explicit RS identifier).
                

              

              
- the GS could play the role of the RO and hence be in
                a position to issue any capability for any RS (without a
                "RO consent"). 

                

                   The target of an attack will clearly be the GS.

              

            

            

              

                

                  

                    

                      

                        

                          

                            

                              
I would not say that GNAP is an
                                access control protocol, as how the RS
                                uses the token to determine access is
                                out of scope.

                            

                          

                        

                        
This is where we have a major
                              discrepancy: how the RS uses
                          the token to determine access is *within* the
                          scope.

                      

                    

                  

                

              

            

            [Denis] Do you agree or disagree ?

            

              

                

                  

                    

                      

                        
The RS announces in advance to the client
                          what it needs so that the client can perform a
                          a given operation and if the client supplies
                          the requested attributes 

                          obtained from some GS/AS(s) trusted by the RS,
                          then access to that RS is granted by the RS.
                          If the RS cannot perform the requested
                          operation on its own, 

                          then the client should be informed about some
                          requested attributes that need to be obtained
                          from some GS/AS(s) trusted by the next RS(s)
                          in a chain

                          for subsequent operations. The User consent
                          should also be obtained before performing the
                          chaining operation.

                        

                        
Chaining operations between RSs over the
                          Internet is within the scope (... and may be
                          achieved).

                      

                    

                  

                

              

            

            
[Denis] Do you agree or disagree ?

            
Denis

            

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
 

                                        

                                          

                                            

                                              

                                                

                                                  
For many use
                                                    cases, the User is
                                                    the RO, and the
                                                    interaction is
                                                    through a user
                                                    interface, not a
                                                    machine protocol. 

                                                  

                                                

                                              

                                            

                                            
Wait a second. You wrote
                                              "the User is the RO". The
                                              User is attempting to make
                                              an access to a RS by using
                                              a Client. 

                                              That User is not
                                              the RO of the RS.   

                                            

                                          

                                        

                                        
The user being the RO is
                                          the initial use case for
                                          OAuth. 

                                      

                                    

                                  

                                  
OAuth 2.0 is no more mandating such
                                    a case.

                                  

                                

                              

                            

                          

                        

                        

                          

                            


                              
I don't know what you mean by that.

                            

                          

                        

                        
Copy and paste from
                          draft-ietf-oauth-security-topics:

                        

                        

                          
OAuth initially assumed a static
                            relationship between client, authorization
                            server and resource servers.  (...)  

                            With the increasing adoption of OAuth, this
                            simple model dissolved and, in several
                            scenarios, was replaced 

                            by a dynamic establishment of the
                            relationship between clients on one side and
                            the authorization and 

                            resource servers of a particular deployment
                            on the other side.

                            

                            This way, the same client could be used to
                            access services of different providers (in
                            case of standard APIs, 

                            such as e-mail or OpenID Connect) or serve
                            as a frontend to a particular tenant in a
                            multi-tenancy environment. 

                          

                        

                      

                    

                    


                    

                    
This sentence does not mention the RO or the
                      Client. I'm confused what we are talking about 

                    

                      

                        

                          
 

                        

                        

                          

                            

                              
 

                              

                                

                                  

                                    

                                      

                                        
A client application would
                                          like access to the user's
                                          photos at a photo sharing
                                          site. The resource is the
                                          user's photos. The user is the
                                          owner of that resource.

                                      

                                    

                                  

                                  
If the user has already pre
                                    established the access control
                                    policy rules so that it can access
                                    to his own photos 

                                    then he does not need to grant in
                                    real time any additional
                                    authorization.

                                

                              

                              
I don't understand what you are
                                trying to say. The photo sharing example
                                was a driving use case for the creation
                                of OAuth.

                            

                          

                        

                        
We would need to revisit the original
                          scenario and consider if it can be addressed
                          in a different way than the original way.

                      

                    

                    
The use case is the same. Is there a different
                      solution you are proposing?

                    
 

                  

                

              

            

            


            

          

          -- 

          Txauth mailing list

          Txauth@ietf.org

          https://www.ietf.org/mailman/listinfo/txauth

        

      

    

    


    

  


--------------5575EDBC1B6F6485968D4F72--


From nobody Fri Jul 24 10:11: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 8C04D3A0FF2 for ; Fri, 24 Jul 2020 10:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 CvxfA6Lk4XSS for ; Fri, 24 Jul 2020 10:11:22 -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 D83E13A1001 for ; Fri, 24 Jul 2020 10:11:19 -0700 (PDT)
Received: from [192.168.1.3] (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 06OHBDXj016670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Jul 2020 13:11:17 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_9ECB5977-134B-4A48-999A-118C132483B6"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 24 Jul 2020 13:11:13 -0400
In-Reply-To: 
Cc: Yaron Sheffer , "txauth@ietf.org" 
To: Francis Pouatcha 
References: <6CC714D8-2FB2-4BE6-B70B-659C4A8198AB@gmail.com> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] GNAP agenda uploaded
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, 24 Jul 2020 17:11:24 -0000

--Apple-Mail=_9ECB5977-134B-4A48-999A-118C132483B6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Francis,

The IETF=E2=80=99s 108th meeting will be fully virtual. You can register =
and get additional information from this page:

https://www.ietf.org/how/meetings/108/ =


Anybody can attend. All conversations fall under the IETF=E2=80=99s Note =
Well policy, just like posts to the mailing list.

 =E2=80=94 Justin

> On Jul 24, 2020, at 10:57 AM, Francis Pouatcha =
 wrote:
>=20
> When and how is next week's meeting taking place? Who is invited, can =
attend or is supposed to attend? Best regards. /Francis
>=20
> On Mon, Jul 20, 2020 at 3:46 PM Yaron Sheffer > wrote:
> Leif and I uploaded the agenda for next week: =
https://www.ietf.org/proceedings/108/agenda/agenda-108-gnap-00.html =

> =20
>=20
> Thanks,
>=20
>                 Yaron
>=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=_9ECB5977-134B-4A48-999A-118C132483B6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Francis,

The =
IETF=E2=80=99s 108th meeting will be fully virtual. You can register and =
get additional information from this page:

https://www.ietf.org/how/meetings/108/

Anybody can attend. All =
conversations fall under the IETF=E2=80=99s Note Well policy, just like =
posts to the mailing list.

 =E2=80=94 Justin

On Jul =
24, 2020, at 10:57 AM, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:

When and how is next =
week's meeting taking place? Who is invited, can =
attend or is supposed to attend? Best regards. /Francis

On Mon, Jul 20, 2020 at 3:46 PM Yaron Sheffer =
<yaronf.ietf@gmail.com> wrote:
Leif and I uploaded the agenda for next week: https://www.ietf.org/proceedings/108/agenda/agenda-108-gnap-00.=
html
 
Thanks,
          &nb=
sp;     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=_9ECB5977-134B-4A48-999A-118C132483B6--


From nobody Fri Jul 24 10: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 E35663A1039 for ; Fri, 24 Jul 2020 10:17:09 -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 JpWne1OhudWT for ; Fri, 24 Jul 2020 10:17:05 -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 452CB3A1021 for ; Fri, 24 Jul 2020 10:17:05 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id 140so5586214lfi.5 for ; Fri, 24 Jul 2020 10:17: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=oUoMu/XpdjqVJ2Br/mslgyfQDEtVYo86K5Fvoo3AQt8=; b=FzCBfv5HuZ4sN+CObXlq9z/o3glLmN88spSHYy1hKtCJC0hq7e5h+VlqGKpnoRbePg 8n0P7uZbNXw3tvut31MagtqpoOxcLmkwxPAmVDyNfmGpbAQEcP3hYcyrb1XPGRIF7gle Wp4KzY67/WmkO2VP2TQ7BrcxVgY48b2J1uipvFNMJWNwbuwtCbI+Nt3D4S5iVjpu4cXB SRsZXbsScM9iOU7wcUX/OiHpETBbCJnCJTlmUme4aOW+BSph6k3RQVVJWBOpymOr6UgS IC4mfC4dA69R57UgANsYlWAbmmLVvYClVtl1TW2mQvs/nK2cJ/7cQN2oLAUKtf9XUF1C 5GQw==
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=oUoMu/XpdjqVJ2Br/mslgyfQDEtVYo86K5Fvoo3AQt8=; b=ToH/ObeHDe0mTf8VUXXAwwV+iZMGMgM9jP9aKrmpYwnYj3h4LWLPHpoAsuh3qNC3ya MgA4bWM1Gk2PUrBaYuS0TqxDH8hQpYw1KRiQjnysxY2s2coRCZsxE3uceoD2gRzejmWq v3cZ6cZmdlB70e20xQaLeRrYmNa6Ih2FgdmO52e112dlSd+BKTsUhCWgIkfd8qc+gogB EOrU6mb65yrkWlIu/wT89NaJ48UaYZnZuPcogSOGw/fQcQZUZPuKYA0vUnZvAPduOJYN DVEiapuze5FhIgyxto3JLFADD8CGzpRjvykMJCKSfeiu++FRdvfYXOQksVhdIDGwYtDC krJg==
X-Gm-Message-State: AOAM5316ddgYqBcvLlrQ8FjolLGKne8gRoWt5wSCGaVme8M74JCsxdL2 TJbt7ASdRCKUhF40H7zRh6Vu1GHfnJZKVZ8c2Ng=
X-Google-Smtp-Source: ABdhPJys0MNJO37S2hywTI0pf3fwM9hUriq618aPJqdPVXqbwh+dCyLmQH6nHC88xlwJHwdsqJf+QscEEbF2Nzq5iJM=
X-Received: by 2002:a19:70c:: with SMTP id 12mr5579619lfh.207.1595611023203; Fri, 24 Jul 2020 10:17:03 -0700 (PDT)
MIME-Version: 1.0
References:             
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 24 Jul 2020 10:16:26 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: Justin Richer , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="0000000000003ce32905ab332474"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 24 Jul 2020 17:17:10 -0000

--0000000000003ce32905ab332474
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Francis

It appears we have two areas to provide additional clarity:

1) In OIDC, the UserInfo endpoint is NOT part of the OP. It is a Protected
Resource. Per
https://openid.net/specs/openid-connect-core-1_0.html#Terminology

UserInfo Endpoint
Protected Resource that, when presented with an Access Token by the Client,
returns authorized information about the End-User represented by the
corresponding Authorization Grant. The UserInfo Endpoint URL MUST use the
https scheme and MAY contain port, path, and query parameter components.


Therefore a RS is providing Claims in OIDC. (RS is the same as a Protected
Resource)

2) The RO may be the User, or it may be some other entity. For example, the
Client may want access to a Resource owned/controlled by an enterprise. The
RO is not the User, and there may not be a User using the Client.

See the Independent RO Authorization sequence as an example:

https://tools.ietf.org/html/draft-hardt-xauth-protocol-13#section-2.3

Note there is no User in this sequence


more detailed comments inserted ...


On Fri, Jul 24, 2020 at 5:15 AM Francis Pouatcha  wrote:

>
>
> On Thu, Jul 23, 2020 at 10:44 PM Dick Hardt  wrote:
>
>>
>>
>> On Thu, Jul 23, 2020 at 7:16 PM Francis Pouatcha  wrote:
>>
>>> Hello Dick, my feedback inline
>>>
>>> @Fabian : i am not yet consistent with using the notation you
>>> referred to in
>>> https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en. Still to
>>> come.
>>>
>>> On Thu, Jul 23, 2020 at 7:52 PM Dick Hardt  wrote=
:
>>>
>>>> Hi Francis
>>>>
>>>> Thanks again for putting this together. I have taken your definitions
>>>> and adjusted them to match how I think of them. I dropped the term
>>>> "parties" because I did not think it added value. I am explicit about =
what
>>>> each party is -- software, a human, or an entity. Let me know where yo=
u
>>>> disagree!
>>>>
>>>>
>>>> Resource - protected data or software functionality
>>>>       - controlled by a Resource Owner (RO),
>>>>       - protected by the Resource Server (RS)
>>>>
>>> Yes
>>>
>>>>
>>>> Claim - a statement about the User
>>>>
>>> I would stay with RO not User. I added some clarification after the
>>> feedback of Justin (see below)
>>>
>>
>>
>>
>>
>>>       - may be obtained from the Grant Server (GS) by a Client
>>>>
>>> Yes.
>>>
>>>>       - may be a Resource the Client can access through an RS
>>>>
>>> Not sure we need to refer to a Resource as a Claim.
>>>
>>
>> Here is why I say a Claim may be a Resource.
>>
>> A Claim may be obtained by a Client calling an RS. This is effectively
>> what the userinfo endpoint is in OpenID Connect. A Client may also updat=
e a
>> Claim that is managed by an RS.
>>
> In OIDC the UserInfo endpoint is exposed by the OP not by an RP. Spec
> wording is confusing because the endpoint is referred to as a protected
> resource. If you derive from this that the OP is a resource server (RP),
> you turn the OP into an RP relying on itself. This cyclic relationship ha=
s
> to be broken in GNAP for simplicity.
>

(I'm assuming you intended RS, not RP above)

See above per the UserInfo endpoint being a Protected Resource, and is not
the OP.


>
> Note-x on GS definition: having a GS protecting access to some Claims doe=
s
> not make the GS a RS.
>
> For simplicity, let us keep overlapping out:
> - GS guards Claims
> - RS guards Resources
>
> I do not see a Client updating a Claim in the scope of any of these
> protocols. Neither GNAP nor oAuth2 nor OIDC.
>

I agree that how a Client updates a Claim is out of scope (at least in the
core protocol).



>
>>
>>>
>>> A Claim - an assertion of the truth of some properties or attributes of
>>> the RO.
>>>   Note-1: A Claim is issued either by the GS or by another claim issuer=
.
>>>
>>
>>
>> I'm viewing the Claims Issuer as an entity, not a piece of software. It
>> is the entity trusted by other parties to make a Claim about the User. T=
he
>> GS and RS may issue claims on behalf of the Claims Issuer.
>>
> No. Issuer is GS. Any twiking of the word will diverge it from oAuth2 and
> OIDC and increase complexity.
>

The Issuer is an entity. The GS is software.


>
> This is why RS shall not issue anything, shall not deal with claims, ....
> RS guards Resources. If you start dealing with RS issuing claims, you sta=
rt
> dealing with RS exposing jwks-url so issued claims can be verified, then
> you fall back at having those RSes being GSes.
>

I'm saying a Resource *may* be a Claim, just as it is in OIDC UserInfo.



>
>>
>>
>>>   Note-2: A Claim is held and guarded by the Grant Server (GS).
>>>
>>
>> What is the significance of this statement? Signed claims don't exist
>> until asked for, so they are not "held" anywhere.
>>
> A Claim can exist before. GS might hold a Claim issued by an external
> "Claim Issued".
>

Would you provide an example?


>
>>
>>>   Note-3: A Claim is released by the GS to a Client.
>>>
>>
>> The model of a Claim being obtained from an RS is a common use case.
>>
> I am not aware of any of them. Unless we are calling a GS a RS.
>

See UserInfo above. Also, the APIs at Twitter, Facebook, Google etc. are
RSes, that may return Claims about the User.


>
>>
>>>   Note-4: The permission to release of a Claim is given by the RO.
>>>
>>
>> I will see what you say below on User ...
>>
>>
>>>
>>>
>>>> Grant - the Claims and/or Resource Access the User and/or RO have
>>>> granted to the Client by the GS
>>>>     - requested by a Client
>>>>     - granted by a GS after any required consent has been obtained fro=
m
>>>> the User and/or RO
>>>>
>>> "User and/or RO" is confusing. I suggest we keep the term User out. Ter=
m
>>> User is even eligible for renaming. I suggest staying with RO.
>>>
>>
>> The User of the Client and the RO may not be the same entity. Some
>> resources may be controlled by the RO, and others by the User. That is w=
hy
>> User and/or RO. They are two different parties.
>>
> I need the example of a User that is different from the RO and that
> controls the RO's Resource.
>

See above.


>
> And if a User controls a Resource, then he does it as the "Owner" of that
> Resource(playing the role of the RO for that Resource).
>
> If we talk about roles and not entities, we will not fall into this
> confusion.
>

I think we are defining an entity playing a specific role.


>
>>
>>>
>>>
>>>> Access Token - an artifact representing the access a client has been
>>>> granted to one or more Resources
>>>>     - created by the GS
>>>>     - presented by the Client when accessing a Resource at an RS
>>>>
>>> An access token might contain Claims.
>>>
>>
>> While there may be statements about the User in the access token, it is
>> not the mechanism for transmitting Claims to the Client -- and I think t=
he
>> access token SHOULD be opaque to the Client most of the time.
>>
> - Access "might" contain a claim ("must" not). Precision is essential as
> we can not kill this practice without removing the concept of assertion
> based tokens.
> - Returning the information to the client does not mean the client is the
> consumer of the information. The client might not have access to the
> content of an encrypted token, or even just to the embedded encrypted
> claim. The intended destination of the claim will consume the claim. But
> for the GNAP, the GS returns the token to the client.
>

Let me restate my position. Any claim that might be in the access token is
out of scope of GNAP, or at least the core protocol. How the RS uses the
access token to protect access is out of scope, so the contents of the
access token is out of scope.



>
>>
>>>
>>> Access Token - an artifact representing the access a client has been
>>> granted to one or more Resources
>>>   Note-1: An access token is created by the GS
>>>   Note-2: An access token can also contain claims
>>>
>>
>> See above.
>>
>>
>>>   Note-3: An access token is presented by the Client when accessing a
>>> Resource at an RS
>>>
>>>
>>>> Resource Owner (RO) - the entity that
>>>>       - controls a Resource,
>>>>       - has delegated Resource access control to one or more GSes
>>>>       - may be the User
>>>>
>>> Confused here with the word "controls" both at RO and GS. I think RO
>>> delegates Resource access management to GS but keeps control (or decisi=
on).
>>>
>>
>> agreed - access management is better.
>>
>>
>>>
>>> Resource Owner (RO) - the entity that
>>>       - controls a Resource,
>>>       - relies on the services the GS to manage access to that Resource=
,
>>>       - relies on the services of a RS to hold a Resource and guard
>>> access to that Resource,
>>>
>>
>> I don't think "guard" is a good verb. "protect" is often used.
>>
> OK.
>
>>
>> If we are switching from "owns a resource" to "controls a resource", the=
n
>> perhaps the entity should be a Resource Controller (RC)?
>>
> Great. Will remove confusion.
>
>>
>>
>>
>>>       - controls a Claim,
>>>
>>
>> Why does the RO control a claim?
>>
> because a Claim is an assertion of the truth of some properties or
> attributes of the RO.
>

The RO may or may not be a User. If the RO is not a User, who is the claim
about? What does "control" mean?



>
>>
>>>       - relies on the services the GS to release that Claim to a Client=
.
>>>
>>>>
>>>> Resource Server (RS) - the software that controls access to one or mor=
e
>>>> Resources
>>>>       - accessed via an API by Clients presenting an access token
>>>>       - accepts access tokens from one or more GSes
>>>>
>>> I suggest "guards" instead of "controls". As access to a resource is
>>> controlled by the RO.
>>>
>>
>> How about "protects access"?
>>
> OK for me.
>
>>
>>
>>>
>>> Resource Server (RS) - the software that guards access to one or more
>>> Resources
>>>       - accessed by the Client that presents an access token
>>>       - accepts access tokens from one or more GSes
>>>
>>>
>>>>
>>>> Grant Server (GS) - the software that manages Grants
>>>>     - has been delegated to manage Resource access by the RO
>>>>     - has been delegated to release Claims about the User
>>>>     - grants the Client access to Resources after obtaining the
>>>> required consent from the RO
>>>>     - provides the Client Claims about the User after obtaining the
>>>> required consent from the User
>>>>
>>> Term User is confusing here. This is why it is eligible for renaming.
>>> - Claims are about RO not User
>>> - Consent is from RO not User.
>>>
>>
>> I'm confused why the Claims are about the RO and not the User.
>>
> Because the  user consumes the resource and the claim. I do like Justin's
> suggestion to call user the "Requesting Party"
>

The Client consumes the Resource and the Claims

The Requesting Party sounds more like the Client than the User.


>
>> We have introduced the term RO so that entity can be differentiated from
>> a User, and there are many use cases where there is a User. Not having a
>> User seems very confusing to me.
>>
> Then let us call him a  "Requesting Party"
>
>>
>>
>>>
>>> Grant Server (GS) - the software that manages Grants
>>>     - has been delegated to manage Resource access by the RO
>>>     - has been delegated to release Claims about the RO
>>>     - grants the Client access to Resources after obtaining the require=
d
>>> consent from the RO
>>>     - provides the Client Claims about the RO after obtaining the
>>> required consent from the RO
>>>
>>>
>>>> Client - the software that wants to access Resources and obtain Claims
>>>>     - executed by a User or a non-human service account
>>>>     - requests Grants from the Grant Server
>>>>     - accesses Resources at an RS using access tokens
>>>>
>>> Client - the software that wants to access Resources and obtain Claims
>>> on behalf of a User or non-human service account
>>>    Note-1: in a typical interaction cycle, the client:
>>>       - receives the resource access request from the User or acts
>>> autonomously,
>>>       - interacts with the RS to discover authorization requirements,
>>>       - interacts with the GS to obtain Access Tokens,
>>>       - interacts with the RS to access the Resource using Access Token=
s.
>>>
>>
>> The Client also transfers the user experience to the GS in some flows.
>>
> Yes but this is just a mechanism. Not an act.
>
>>
>> Where do Claims fit into the cycle above?
>>
> A claim is just an Assertion (attribute, property) related to the RO. Thi=
s
> can be part of the authorization requirements. e.g. User/Client/RS are
> requesting to know the e-mail of the RO.
>

I still view Claims are about the User. The RO is who controls a Resource,
since it is the *Resource* Owner.

/Dick

> =E1=90=A7

--0000000000003ce32905ab332474
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Francis

It appears =
we have two areas to provide additional clarity:

1=
) In OIDC, the UserInfo endpoint is NOT part of the OP. It is a Protected R=
esource. Per=C2=A0https://openid.net/specs/openid-connect-core-1_0.html#=
Terminology

UserInfo Endpoint
Protected Resourc=
e that, when presented with an Access Token by the Client, returns authoriz=
ed information about the End-User represented by the corresponding Authoriz=
ation Grant. The UserInfo Endpoint URL MUST use the https scheme and MAY co=
ntain port, path, and query parameter components.
Therefore a RS is providing Claims in OIDC. (RS is the same as=
 a Protected Resource)

2) The RO may be the User, =
or it may be some other entity. For example, the Client may want access to =
a Resource owned/controlled by an enterprise. The RO is not the User, and t=
here may not be a User using the Client.=C2=A0

See=
 the=C2=A0Independent RO Authorization sequence as an example:
Note there is no User in this sequence

=


more detailed comments inserted ...


On Fri, Jul 24, 2020 at 5:15 AM Francis Pouatcha <fpo@adorsys.de> wrote:


=

On Thu, Ju=
l 23, 2020 at 10:44 PM Dick Hardt <dick.hardt@gmail.com> wrote:
=


On Thu, Jul 23, 2020 at 7:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick, my feedback inline

@Fabian : =
i am not yet consistent with using the notation you referred=C2=A0to in=C2=
=A0https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v=
1:en. Still to come.

On Thu, Jul 23, 2020 at 7:52 PM Dick Hardt <dick.hardt@gmail.com<=
/a>> wrote:
<=
div dir=3D"ltr">Hi Francis

Thanks again for putting=C2=
=A0this together. I have taken your definitions and adjusted them to match =
how I think of them. I dropped the term "parties" because I did n=
ot think it added value. I am explicit about what each party is -- software=
, a human, or an entity. Let me know where you disagree!


Resource - protected data or software functionality
=C2=A0 =
=C2=A0 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=
=A0 - protected by the Resource Server (RS)
Yes=C2=A0










I'm viewing the Claims Issuer as an entity, not a piece of software.=
 It is the entity trusted by other parties to make a Claim about the User. =
The GS and RS may issue claims on behalf of the Claims Issuer.
<=
/div>
No. Issuer is GS. Any twiking=C2=A0of the word will =
diverge it from oAuth2 and OIDC and increase complexity.
<=
/blockquote>

The Issuer is an entity. The GS is software=
.
=C2=A0
<=
div dir=3D"ltr">

This is why =
RS shall not issue anything,=C2=A0shall not deal with claims, .... RS guard=
s Resources. If you start dealing with RS issuing claims, you start dealing=
 with RS exposing jwks-url so issued claims can be verified, then you fall =
back at having those RSes being GSes.
I'm saying a Resource *may* be a Claim, just as it is in O=
IDC UserInfo.

=C2=A0

=C2=A0
=
=C2=A0 Note-2: A Claim is held and guarded by the Grant Server (GS).
<=
/div>

What is the significance =
of this statement? Signed claims don't exist until asked for, so they a=
re not "held" anywhere.
A Clai=
m can exist before. GS might hold a Claim issued by an external "Claim=
 Issued".

Would you =
provide an example?
=C2=A0
=C2=A0
=C2=A0 Note-3=
: A Claim is released by the GS to a Client.=C2=A0
<=
/blockquote>

The model of a Claim being obtained from an=
 RS is a common use case.=C2=A0
I am not=
 aware of any of them. Unless=C2=A0we are calling a GS a RS.



I think we are defining an entity playing a specific role=
.
=C2=A0
<=
div dir=3D"ltr">
=C2=A0


Access Token - an artifact represent=
ing the access a client has been granted to one or more Resources
=C2=A0 =C2=A0 - created by the GS
=C2=A0 =C2=A0 - presented by the Clie=
nt when accessing a Resource at an RS
An a=
ccess token might contain=C2=A0Claims.
<=
br>
While there may be statements about the User in the access to=
ken, it is not the mechanism for transmitting Claims to the Client -- and I=
 think the access token SHOULD be opaque to the Client most of the time.
- Access "might" contain a claim=
 ("must" not). Precision is essential as we can not kill this pra=
ctice without removing the concept of assertion based tokens.
- R=
eturning the information to the client does not mean the client is the cons=
umer of the information. The client might not have access to the content of=
 an encrypted token, or even just to the embedded encrypted claim. The inte=
nded destination of the claim will consume the claim. But for the GNAP, the=
 GS returns the token to the client.

=C2=A0

Access Token=C2=A0-=C2=
=A0an artifact representing the access a client has been granted to =
one or more Resources
=C2=A0 Note-1: An access token is=C2=A0crea=
ted by the GS
=C2=A0 Note-2:=C2=A0An access token can also contai=
n claims

See above.=C2=A0=

=C2=A0
=C2=A0 Note-3: An access tok=
en is=C2=A0presented by the Client when accessing a Resource at an RS
=

=C2=A0
Resource Owner (RO) - the entity that
=C2=A0 =C2=A0 =
=C2=A0 - controls a Resource,
=C2=A0 =C2=A0 =C2=A0 - has delegated Resou=
rce access control to one or more GSes
=C2=A0 =C2=A0 =C2=A0 - may be the=
 User
Confused here with the word "co=
ntrols" both at RO and GS. I think RO delegates Resource access manage=
ment to GS but keeps control (or decision).
<=
div>
agreed - access management is better.
=C2=A0

Resource Owner (RO) - the entity that
=C2=A0 =C2=A0 =C2=A0 - c=
ontrols a Resource,
=C2=A0 =C2=A0 =C2=A0 - relies on the services the GS=
 to manage access to that Resource,
=C2=A0 =C2=A0 =C2=A0 - relies on the=
 services of a RS to hold a Resource and guard access to that Resource,
=


I don't=C2=A0think &=
quot;guard" is a good verb. "protect" is often used.
OK.=C2=A0

If we are switching from "owns a resource" to "contro=
ls a resource", then perhaps the entity should be a Resource Controlle=
r (RC)?
Great. Will remove confusion.=C2=
=A0

=C2=A0
=C2=A0 =C2=A0 =C2=A0 - controls a Claim,

Why does the RO control a claim?
because a Claim is=C2=A0an assertion of the truth of some properties or attr=
ibutes of the RO.=C2=A0

The RO may or may not be a User. If the RO is not a User, who is the =
claim about? What does "control" mean?

=
=C2=A0
=C2=A0
=C2=A0 =C2=A0 =C2=A0 - relies on the services the GS to rel=
ease that Claim to a Client.

Resource Server (RS) - the software =
that controls access to one or more Resources
=C2=A0 =C2=A0 =C2=A0 - acc=
essed via an API by Clients presenting an access token
=C2=A0 =C2=A0 =C2=
=A0 - accepts access tokens from one or more GSes 
I suggest "guards" instead of "controls". As a=
ccess to a resource is controlled by the RO.=C2=A0

How about "protects access"?
OK for me.=C2=A0
=C2=
=A0

Resource Server (RS) -=C2=A0the software that guards access to on=
e or more Resources
=C2=A0 =C2=A0 =C2=A0 - accessed by the Client that=C2=A0=
presents an access token
=C2=A0 =C2=A0 =C2=A0 - accepts access tokens from o=
ne or more GSes
=C2=A0

Grant Server (GS) - the software that manages Grant=
s
=C2=A0 =C2=A0 - has been delegated to manage Resource access by the RO=

=C2=A0 =C2=A0 - has been delegated to release Claims about the User
=
=C2=A0 =C2=A0 - grants the Client access to Resources after obtaining the r=
equired consent from the RO
=C2=A0 =C2=A0 - provides the Client Claims a=
bout the User after obtaining the required consent from the User
<=
/div>
Term User is confusing here. This is why it is eligi=
ble for renaming.
- Claims are about RO=C2=A0not User
-=
 Consent is from RO not User.

=

I'm confused why the Claims are about the RO and not the User.
Because the=C2=A0 user consumes the resourc=
e and the claim. I do like Justin's suggestion=C2=A0to call user the &q=
uot;Requesting Party"

The Client consumes the Resource and the Claims

=
The Requesting Party sounds more like the Client than the User.
=
=C2=A0

We ha=
ve introduced the term RO so that entity can be differentiated from a User,=
 and there are many use cases where there is a User. Not having a User seem=
s very confusing to me.
Then let us call=
 him a=C2=A0=C2=A0"Requesting Party"
=C2=A0
=C2=A0
Grant Server (GS) - the software that manag=
es Grants
=C2=A0 =C2=A0 - has been delegated to manage Resource access by =
the RO
=C2=A0 =C2=A0 - has been delegated to release Claims about the RO
=
=C2=A0 =C2=A0 - grants the Client access to Resources after obtaining the r=
equired consent from the RO
=C2=A0 =C2=A0 - provides the Client Claims abo=
ut the RO after obtaining the required consent from the RO
=C2=
=A0
Client - the software that wants to access Resource=
s and obtain Claims
=C2=A0 =C2=A0 - executed by a User or a non-human se=
rvice account 
=C2=A0 =C2=A0 - requests Grants from the Grant Server
=
=C2=A0 =C2=A0 - accesses Resources at an RS using access tokens
Client -=C2=A0th=
e software that wants to access Resources and obtain Claims on behalf of a=
=C2=A0User or non-human service account
=C2=
=A0 =C2=A0Note-1: in a typical interaction cycle, the client:
=C2=A0 =C2=A0 =C2=A0 - receives the resource acces=
s request from the User or acts autonomously,
=C2=A0 =C2=A0 =C2=A0 - interac=
ts with the RS to discover authorization requirements,
=C2=A0 =C2=A0 =C2=A0 =
- interacts with the GS to obtain Access Tokens,
=C2=A0 =C2=A0 =C2=A0 -=
 interacts with the RS to access the Resource using Access Tokens.

The Client also transfers =
the user experience to the GS in some flows.
=

Yes but this is just a mechanism. Not an act.=C2=A0

Where do Claims fit into the cycle above?
A claim is just an Assertion (attribute, proper=
ty) related to the RO. This can be part of the authorization requirements. =
e.g. User/Client/RS are requesting to know the e-mail=C2=A0of the RO.
=


I still view Claims are about =
the User. The RO is who controls a Resource, since it is the *Resource* Own=
er.=C2=A0

/Dick
<=
/div>


3D""=
=E1=90=A7


--0000000000003ce32905ab332474--


From nobody Fri Jul 24 10:25: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 5BC4A3A1050 for ; Fri, 24 Jul 2020 10:25: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 xHrhoNxC_AKh for ; Fri, 24 Jul 2020 10:25:08 -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 ECCF23A104C for ; Fri, 24 Jul 2020 10:25:07 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id r19so10708336ljn.12 for ; Fri, 24 Jul 2020 10:25: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=55tWg9kEsMPbmLuAPKlMX9oTpjj0IHC+Vkd8B2ZT6+s=; b=opOb4mSJ8cyUptevOJZoRHrxcwpZB4Qd4K1RQoSsIEyYR+oKGALd02lyIUyIV/Hbi4 g1w1IaxWzYY99muwh9rmFFg3Z/nsSrAyX5l3JGj+mO3uye9x/d03JLS5r8HRMMsAG4Pc FoM4Nbin5xeujh6nTDECdvVgxv8LfgwULiQSfisKj/mn6YvPZXF6zDOBXdv31GiEtc53 7rSqR0tYouCnehOqXWVZoh4BQ9Sgz9SN/w2PmyTd3cQJs0r6rQUzLE5b5fWImfiKAUuF ugf4PkQTCQ0CicHdlJLSTvOlCYFkAiBpN/TdFDjzLBbiAQ6CHero0QuaMBjFMyMO6nuP KkQA==
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=55tWg9kEsMPbmLuAPKlMX9oTpjj0IHC+Vkd8B2ZT6+s=; b=Y0zIqMZYbilQGcOEgxql1Jx0oBIls2fYIpOyytrOeKIW81F7lqim0CcHUGc30m4m0o Kcl3mfQSOi13YgEffbxti3kSepgFSb0JyQFFIY+Zzvwx+vkW0Ozp4XbCb2fKhBupsjJJ 8fMsxAsn+1pC//emtLLicFNKFWDvoldlyKL43JMCV2/ZY4DHZb3F+rF3Os4L/5I2qUY+ VlPSCdM+5ou7//FSv0kah0GUHvlb9w9RviyICkXjA9rqYyIeFn1DaYEYdSKzBUPbHCQz zLBN2rzMTfYH2FkP8h19AsigwWhDUdRegOvERD2Jl0GevbUHoWB3ETCcVS1fNrYF4Pg/ 0mpw==
X-Gm-Message-State: AOAM532xg1PflOwGV5rs2S2O7CjhwQc5TwAP7JoMKwUIEt5rgpR6yIZf eyd2a+B3ULISVjRonLfA0FMZaBiKTNOiCr/+7as=
X-Google-Smtp-Source: ABdhPJzJZMdBYar8p6UFf3yHxyergCUchRTvY5pI5dwL8BwAuamGi+1Jt5MCOEqq/jp7MMXGexfsJDfiiJUWQopfZgY=
X-Received: by 2002:a2e:900a:: with SMTP id h10mr4996267ljg.242.1595611506083;  Fri, 24 Jul 2020 10:25:06 -0700 (PDT)
MIME-Version: 1.0
References:            
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 24 Jul 2020 10:24:30 -0700
Message-ID: 
To: Justin Richer 
Cc: Francis Pouatcha , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="000000000000050e6005ab3341d8"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 17:25:12 -0000

--000000000000050e6005ab3341d8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

In OpenID Connect (OIDC), the Client can obtain Claims directly from the OP
in an ID Token, or the Client can obtain Claims using an access token to
call the UserInfo endpoint, a Protected Resource[1].

The Claims are about the User (not a RO).

In XAuth, I'm proposing the Client may obtain bare claims from the GS
directly in addition to the mechanisms in ODIC.

So I don't think we are changing the definition of Claim from how it has
been used in OIDC, and I fail to see any reason to NOT use Claim.

Justin: you allude to Claims being about a party other than the User. Would
you provide an example?

/Dick

[1]

UserInfo Endpoint
Protected Resource that, when presented with an Access Token by the Client,
returns authorized information about the End-User represented by the
corresponding Authorization Grant. The UserInfo Endpoint URL MUST use the
https scheme and MAY contain port, path, and query parameter components.




=E1=90=A7

On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote:

> I want to focus on one aspect here:
>
>
>> A Claim is a well understood term in the field. We should use it. It is
>> still a Claim if it comes directly from the GS or from an RS.
>>
> I do not understand why a Resource release by an RS shall be h to as a
> claim, even if the content of the Resource is an assertion. It will lead =
to
> confusion. If we limit claims to information GS releases into Token, User
> Info, and other objects it returns, this will help separate
> responsibilities between GS and RS. As soon as RS services and informatio=
n,
> this is called a Resource, no matter the nature of the content of that
> information.
>
>
> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=E2=
=80=9D in the way that
> we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back th=
rough an RS =E2=80=94 but in the
> context of GNAP, that makes it a resource. So we need a different word fo=
r
> data coming back directly from the AS to the client. Sometimes it=E2=80=
=99s going
> to be about the user, and that=E2=80=99s what we=E2=80=99re going to focu=
s on here, but
> since you can also get information about the user from a resource we can=
=E2=80=99t
> just call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the hear=
t of a lot of
> confusion in recent threads, as well as confusion about the scope of the
> inclusion of identity in the GNAP protocol.
>
> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does, a=
nd let=E2=80=99s find a way to
> differentiate between when an item, claim or otherwise,  comes as part of=
 a
> resource and when it comes back directly. This is an important
> differentiating feature for GNAP.
>
> Some straw man ideas, none of which I=E2=80=99m particularly in love with=
:
>
>  - direct data
>  - properties
>  - details
>  - statements
>
> The important thing here is that it=E2=80=99s not necessarily :about: the=
 RO, and
> that it is :not: in a resource.
>
> Any other thoughts?
>
>  =E2=80=94 Justin
>

--000000000000050e6005ab3341d8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


In OpenID Connect (OIDC), the Client can obtain Claims dir=
ectly from the OP in an ID Token, or the Client can obtain Claims using an =
access token to call the UserInfo endpoint, a Protected Resource[1].
The Claims are about the User (not a RO).

=

In XAuth, I'm proposing the Client may obtain bare claims from the=
 GS directly in addition to the mechanisms in ODIC.

So I don't think we are changing the definition of Claim from how it =
has been used in OIDC, and I fail to see any reason to NOT use Claim.
=


Justin: you allude to Claims being about a party other =
than the User. Would you provide an example?

/Dick=


[1]
UserInfo Endpoint
Protected Resource=
 that, when presented with an Access Token by the Client, returns authorize=
d information about the End-User represented by the corresponding Authoriza=
tion Grant. The UserInfo Endpoint URL MUST use the https scheme and MAY con=
tain port, path, and query parameter components.


3D""=E1=90=A7
<=
br>
On Fri,=
 Jul 24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus=
 on one aspect here:


A Claim is a well understoo=
d term in the field. We should use it. It is still a Claim if it comes dire=
ctly from the GS or from an RS.=C2=A0
I do not=
 understand why a Resource release by an RS shall be h to as a claim, even =
if the content of the Resource is an assertion. It will lead to confusion. =
If we limit claims to information GS releases into Token, User Info, and ot=
her objects it returns, this will help separate responsibilities between GS=
 and RS. As soon as RS services and information, this is called a Resource,=
 no matter the nature of the content of that information.
=


This is exactly why I don=E2=80=99t think=
 we should use =E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using =
it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 =
but in the context of GNAP, that makes it a resource. So we need a differen=
t word for data coming back directly from the AS to the client. Sometimes i=
t=E2=80=99s going to be about the user, and that=E2=80=99s what we=E2=80=99=
re going to focus on here, but since you can also get information about the=
 user from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=
=9D. I think this has been at the heart of a lot of confusion in recent thr=
eads, as well as confusion about the scope of the inclusion of identity in =
the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cc=
laim=E2=80=9D mean what it already does, and let=E2=80=99s find a way to di=
fferentiate between when an item, claim or otherwise,=C2=A0=C2=A0comes as p=
art of a resource and when it comes back directly. This is an important dif=
ferentiating feature for GNAP.

Some straw man idea=
s, none of which I=E2=80=99m particularly in love with:

=C2=A0- direct data
=C2=A0- properties
=C2=A0- de=
tails
=C2=A0- statements

The important t=
hing here is that it=E2=80=99s not necessarily :about: the RO, and that it =
is :not: in a resource.

Any other thoughts?
<=
br>
=C2=A0=E2=80=94 Justin


--000000000000050e6005ab3341d8--


From nobody Fri Jul 24 10:31: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 402863A1087 for ; Fri, 24 Jul 2020 10:31:44 -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 GEe9_xoCo9Ip for ; Fri, 24 Jul 2020 10:31:42 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450: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 259263A1085 for ; Fri, 24 Jul 2020 10:31:42 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id v15so1067182lfg.6 for ; Fri, 24 Jul 2020 10:31: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=KevwD0OFOgP6NMcZSmeZ/Xxc5HJw1ZE5SAc27R7AoU0=; b=l6ZHhcHZUcoSMrnXdAFFNPTO0mvdW1iOzv6qx35P5ksBc2cB8JTapT80Z+dC730Dtd A7M4B0dHTd+MOq/uxKY6FQMKhKpGVdAPb0nFQbgJIjADhqTp4FW5eP/whIY8Ha89qNb/ mUXdycspGC9R23e/S+cf+eBligM43NrXroNB3ZYs+yIx31qe6OHNfvT4xl/HhuZ2WqmM 6GRQquzKqgZwCqBl+kEMcb5LEiWGwhFGGYMgGm1lNLQ5+a1SuQRfaLeaA4Zl+nrADljQ gd6POjjpLW1YcVUBxaihooQnbatubfjxtKR3z1oqneFnf3OD3kmjVumVNMWETpFqNG41 G4mA==
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=KevwD0OFOgP6NMcZSmeZ/Xxc5HJw1ZE5SAc27R7AoU0=; b=rredNW5ExN7iWQRfgZ+88P2yirhEekplEQq0P46V2sg32RJbBMzTh0i0TRxPVYeHjk DJT3nwOCZb1aV2d3NZzlsSJk/tk3cw3nh3Nbr/85AL++6G2CejQlUKASGKz3vQhTKPic YIkvS4SaopqOEOwO9imSJqOIZxnASVYcEmwuhKfB8Ym0UscWB8vqd7N5b+genqm3nn0l IOhYvzmabjUDwK8r7sKUUStvyvUso8kDFHnw7we3lQtCzCtGSeToaTmGTZuuEt3lksIM iYpiFoGGETJdcnW/slFeNxzkwzExvlWHJN2Uj/WlgZ56d4zt0nIlRWIYN9TdZjo6KP4l +AMw==
X-Gm-Message-State: AOAM533FcowxaT2UNBsyTLNkg2JlwNodPnFW6reg/mCRT/c6OKT9aK3k PDFFtaQQH0st3SJXQi9SD+cODGnXZ3LhgSRgApU=
X-Google-Smtp-Source: ABdhPJzDoftL2WvFH04rPtETzqTh9DSEyBsZ3TxD6bsoPiZiDG+buaUbLz2o1Go2IMSf0rPAU2sEA9dV5ErFfigiMgQ=
X-Received: by 2002:a19:fc14:: with SMTP id a20mr5540525lfi.0.1595611900098; Fri, 24 Jul 2020 10:31:40 -0700 (PDT)
MIME-Version: 1.0
References:  <608866FE-01F2-4933-B906-D19A8CDB8AEB@gmail.com> <6415D0F2-B45F-4B76-8E89-2E0E95E63DE2@mit.edu>
In-Reply-To: <6415D0F2-B45F-4B76-8E89-2E0E95E63DE2@mit.edu>
From: Dick Hardt 
Date: Fri, 24 Jul 2020 10:31:03 -0700
Message-ID: 
To: Justin Richer 
Cc: Yaron Sheffer , Leif Johansson , txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000813e7005ab3358bc"
Archived-At: 
Subject: Re: [Txauth] using github.com/ietf-wg-gnap
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, 24 Jul 2020 17:31:45 -0000

--000000000000813e7005ab3358bc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Yaron!

Assuming the WG wants to follow the ID, the IETF Secretariat and
responsible AD are the owners, and there is a team with Administrative
access that includes the WG Chairs.

The chairs also ask for WG consensus on using GitHub, and which features to
use.

Presuming there is WG consensus, I propose we create a use case repo where
we can document start documenting use cases. I agree with Justin's earlier
comments that there is no use case document that is a product of the WG as
an ID, but that it is used to get consensus on use cases that are in scope,
and aligns the WG on the requirements.


=E1=90=A7

On Fri, Jul 24, 2020 at 6:04 AM Justin Richer  wrote:

> Yaron, thanks for doing that! This will be a very helpful set of tools fo=
r
> the WG.
>
> Yes, it will be very important when we have adopted WG documents, but
> ahead of that, there are other features that we can use. We can create a
> repository to get access to an issue tracker and wiki, before we have any
> documents. These might be very useful, especially coming out of next week=
=E2=80=99s
> meeting.
>
>  =E2=80=94 Justin
>
> On Jul 24, 2020, at 8:53 AM, Yaron Sheffer  wrote:
>
> Hi Dick,
>
> I just created the GitHub org with Leif as co-owner, but from a quick rea=
d
> of the I-D, I don=E2=80=99t think we have any use for it until we have ad=
opted
> working group documents. Am I missing anything?
>
> Thanks,
>                 Yaron
>
> *From: *Dick Hardt 
> *Date: *Friday, July 24, 2020 at 05:17
> *To: *Yaron Sheffer , Leif Johansson <
> leifj@sunet.se>
> *Cc: *Justin Richer , 
> *Subject: *using github.com/ietf-wg-gnap
>
> Justin brought up the decision on where we are going to capture our work,
> and if we would do it on GitHub.
>
> I'm supportive of that. Per
>
> https://tools.ietf.org/html/draft-ietf-git-using-github
>
> there are a number of choices of how to use GitHub, and which features to
> use in the WG.
>
> Config is covered by:
>
> https://tools.ietf.org/html/draft-ietf-git-github-wg-configuration
>
> Note these documents are still being worked on, but perhaps we can give
> that WG feedback on their docs?
>
> /Dick
>
>
> [image: Image removed by sender.]=E1=90=A7
>
>
>

--000000000000813e7005ab3358bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Yaron!

Assuming the=C2=A0WG want=
s to follow the ID, the=C2=A0IETF Secretariat and responsible AD are the ow=
ners, and there=C2=A0is a team with=C2=A0Administrative access that include=
s the WG Chairs.

The chairs also ask for WG consen=
sus on using GitHub, and which features to use.=C2=A0

<=
div>Presuming there is WG consensus, I propose we create a use case repo wh=
ere we can document start documenting use cases. I agree with Justin's =
earlier comments that there is no use case document that is a product of th=
e WG as an ID, but that it is used to get consensus on use cases that are i=
n scope, and aligns the WG on the requirements.

3D""=E1=90=A7

On Fri, Jul 24, 2020 at 6:04 AM Jus=
tin Richer <jricher@mit.edu> w=
rote:
Yaron, thanks for doing that! This will be =
a very helpful set of tools for the WG.=C2=A0

Yes, it wi=
ll be very important when we have adopted WG documents, but ahead of that, =
there are other features that we can use. We can create a repository to get=
 access to an issue tracker and wiki, before we have any documents. These m=
ight be very useful, especially coming out of next week=E2=80=99s meeting.<=
/div>

=C2=A0=E2=80=94 Justin

On Jul 24, 2020, at 8:53 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Justin brought up the decision on where we are g=
oing to capture our work, and if we would do it on GitHub.
=C2=A0
I'm supportive of that. Per=C2=
=A0
=C2=A0
=C2=A0=

there are a number of choices of how to use GitHub, an=
d which features to use in the WG.
=C2=A0=

Config is covered by:
=C2=A0
=C2=A0
Note these documents are still being worked on, but perhaps we can giv=
e that WG feedback on their docs?
=C2=A0=

/Dick
=C2=A0<=
/div>
=C2=A0
3D"Image=E1=90=A7



--000000000000813e7005ab3358bc--


From nobody Fri Jul 24 10:32: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 4E2313A1092 for ; Fri, 24 Jul 2020 10:32:38 -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 9knRwWVOzPeE for ; Fri, 24 Jul 2020 10:32:36 -0700 (PDT)
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0: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 54B133A1089 for ; Fri, 24 Jul 2020 10:32:36 -0700 (PDT)
Received: by mail-oi1-x230.google.com with SMTP id t4so8637598oij.9 for ; Fri, 24 Jul 2020 10:32: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=73aMI1/FOoliR+n0uVKBy7MHLv6+rgEjK8tAUIzd0O4=; b=EKrqOU0kPnY5fOUeY8+h5+apSkJEjlfEScIfRfGU8mIsDiMgKv1SUnTimv2ArdApcB 60WwBFiGholJECl0ge3bTPhmU6C7rW2JwGkfnv7aho0FmsHCvMdlQUf4W5pR3CQ6e1jQ 24wfeRh3+QGj2D8kHOw1ZzxXL+Op+2EDRwOyZ7Vknb5VgKeE4Af2OHyvLJLFx3Ji+6yI HGMLM794LFYOx/mXDSfXpGq9b5BsjuC1zx5p+f4unx2rXBGxWYkQIn3MpmQqh6un7YCG qj8OHn4ru5nkGauxcbe90BKLVWVFN6OnuSs7jl70v786Lf/YFM15ACBKClQT53y6cu8o WxlA==
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=73aMI1/FOoliR+n0uVKBy7MHLv6+rgEjK8tAUIzd0O4=; b=dZidJlFiL8gnQXYHkjKS7bO6deTM0iEP1aANL3wg3Nfv1fj6cwTthWDS4Ng7BX9UEK HAsrgWrRhsoK0L5yT7tUVqgQ/hVagTvrSOqyqIifcRxoDuAkIMZdMeFaktZp1W4++x6f f00Dm2oEfin6fJJrZqnORT5lgyPpMbRu5BUzc9Gkyc9VGha8Sokl0pTgN2uUUyAUrbiJ e9ZW7/N6DKZ5Q3P9sh4F1CatDDgWXdNmW7GJDhSV0STozcZA3rwq1h0PpjMWXHO2RMyK EIzw8wuvEpgiCcTghznuScMKyJEreMODXITBPP6YwbQwBv8GTueIpBgvRs7jkzMsSV3V DBZg==
X-Gm-Message-State: AOAM532cq4gA1IELHJ74/JoDSpXpk9msliTmPM8lDc6jhRbqVVPLhKxf lyx71G+bj/8FIoR4IP/yOJp3bmhhGowEbIpCI/0=
X-Google-Smtp-Source: ABdhPJxAxSYL4+6Q9w3+tq9inAk7rR1CsZeS7o0Qg3npZtMtSyvmQE+JO5HB1/PmsHl8QzuwzxkzZW7XR1awYr0xD9I=
X-Received: by 2002:aca:aa57:: with SMTP id t84mr9231254oie.131.1595611955574;  Fri, 24 Jul 2020 10:32:35 -0700 (PDT)
MIME-Version: 1.0
References:             
In-Reply-To: 
From: Tom Jones 
Date: Fri, 24 Jul 2020 10:32:24 -0700
Message-ID: 
To: Dick Hardt 
Cc: Justin Richer , Francis Pouatcha , txauth@ietf.org, Denis 
Content-Type: multipart/alternative; boundary="000000000000cfba7505ab335b3b"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 17:32:39 -0000

--000000000000cfba7505ab335b3b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Nat and I just had this discussion about claims & the claims aggregation
spec.
An example about claims that are not entirely about the user is the gurdian
ship case.
That case can be solved by creating a signed set if claims (which needs a
name) from the RO granting approval to the user to make a "ID Token"
(whatever) from the as to the client to be passed to the RS.
my suggesting is that claim as not necessarily attributes and the data
about the ro from the rs are distinct from the claims about the user from
the as.
I do not believe that claims aggregation is about claims (at least not
often).
so then the data from. the ro would never be a claim, even tho it was
identical in form and substance from the claim produced by the as.
Peace ..tom


On Fri, Jul 24, 2020 at 10:25 AM Dick Hardt  wrote:

> In OpenID Connect (OIDC), the Client can obtain Claims directly from the
> OP in an ID Token, or the Client can obtain Claims using an access token =
to
> call the UserInfo endpoint, a Protected Resource[1].
>
> The Claims are about the User (not a RO).
>
> In XAuth, I'm proposing the Client may obtain bare claims from the GS
> directly in addition to the mechanisms in ODIC.
>
> So I don't think we are changing the definition of Claim from how it has
> been used in OIDC, and I fail to see any reason to NOT use Claim.
>
> Justin: you allude to Claims being about a party other than the User.
> Would you provide an example?
>
> /Dick
>
> [1]
>
> UserInfo Endpoint
> Protected Resource that, when presented with an Access Token by the
> Client, returns authorized information about the End-User represented by
> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST use
> the https scheme and MAY contain port, path, and query parameter componen=
ts.
>
>
>
>
> =E1=90=A7
>
> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote:
>
>> I want to focus on one aspect here:
>>
>>
>>> A Claim is a well understood term in the field. We should use it. It is
>>> still a Claim if it comes directly from the GS or from an RS.
>>>
>> I do not understand why a Resource release by an RS shall be h to as a
>> claim, even if the content of the Resource is an assertion. It will lead=
 to
>> confusion. If we limit claims to information GS releases into Token, Use=
r
>> Info, and other objects it returns, this will help separate
>> responsibilities between GS and RS. As soon as RS services and informati=
on,
>> this is called a Resource, no matter the nature of the content of that
>> information.
>>
>>
>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=
=E2=80=9D in the way that
>> we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back t=
hrough an RS =E2=80=94 but in the
>> context of GNAP, that makes it a resource. So we need a different word f=
or
>> data coming back directly from the AS to the client. Sometimes it=E2=80=
=99s going
>> to be about the user, and that=E2=80=99s what we=E2=80=99re going to foc=
us on here, but
>> since you can also get information about the user from a resource we can=
=E2=80=99t
>> just call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the hea=
rt of a lot of
>> confusion in recent threads, as well as confusion about the scope of the
>> inclusion of identity in the GNAP protocol.
>>
>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does, =
and let=E2=80=99s find a way to
>> differentiate between when an item, claim or otherwise,  comes as part o=
f a
>> resource and when it comes back directly. This is an important
>> differentiating feature for GNAP.
>>
>> Some straw man ideas, none of which I=E2=80=99m particularly in love wit=
h:
>>
>>  - direct data
>>  - properties
>>  - details
>>  - statements
>>
>> The important thing here is that it=E2=80=99s not necessarily :about: th=
e RO, and
>> that it is :not: in a resource.
>>
>> Any other thoughts?
>>
>>  =E2=80=94 Justin
>>
>

--000000000000cfba7505ab335b3b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Nat and I just had this discussion about claims & the =
claims aggregation spec.
An example about claims that are not entirely =
about the user is the gurdian ship=C2=A0case.
That case can be so=
lved by creating a signed set if claims (which needs a name) from the RO gr=
anting approval to the user to make a "ID Token" (whatever) from =
the as to the client to be passed to the RS.
my suggesting is tha=
t claim as not necessarily attributes and the data about the ro from the rs=
 are distinct from the claims about the user from the as.
I do no=
t believe that claims aggregation=C2=A0is about claims (at least not often)=
.
so then the data from. the ro would=C2=A0never be a claim, even=
 tho it was identical=C2=A0in form and substance from the claim produced by=
 the as.
Peace ..tom


On Fri, Jul 24, 2020 at 10:25 AM Dick Hardt <<=
a href=3D"mailto:dick.hardt@gmail.com">dick.hardt@gmail.com> wrote:<=
br>
In OpenID Connect (OIDC), the Client can obtain Claims directly from the O=
P in an ID Token, or the Client can obtain Claims using an access token to =
call the UserInfo endpoint, a Protected Resource[1].

The=
 Claims are about the User (not a RO).

In XAuth, I=
'm proposing the Client may obtain bare claims from the GS directly in =
addition to the mechanisms in ODIC.

So I don't=
 think we are changing the definition of Claim from how it has been used in=
 OIDC, and I fail to see any reason to NOT use Claim.

<=
div>Justin: you allude to Claims being about a party other than the User. W=
ould you provide an example?

/Dick

<=
/div>
[1]
UserInfo Endpoint
Protected Resource that, whe=
n presented with an Access Token by the Client, returns authorized informat=
ion about the End-User represented by the corresponding Authorization Grant=
. The UserInfo Endpoint URL MUST use the https scheme and MAY contain port,=
 path, and query parameter components.



3D""=E1=90=A7

<=
div class=3D"gmail_quote">
On Fri, Jul=
 24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspect here:

A Claim is a well understood term in the field. We =
should use it. It is still a Claim if it comes directly from the GS or from=
 an RS.=C2=A0
I do not understand why a Resour=
ce release by an RS shall be h to as a claim, even if the content of the Re=
source is an assertion. It will lead to confusion. If we limit claims to in=
formation GS releases into Token, User Info, and other objects it returns, =
this will help separate responsibilities between GS and RS. As soon as RS s=
ervices and information, this is called a Resource, no matter the nature of=
 the content of that information.

<=
/div>
This is exactly why I don=E2=80=99t think we should use =E2=80=9C=
claim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclai=
m=E2=80=9D could come back through an RS =E2=80=94 but in the context of GN=
AP, that makes it a resource. So we need a different word for data coming b=
ack directly from the AS to the client. Sometimes it=E2=80=99s going to be =
about the user, and that=E2=80=99s what we=E2=80=99re going to focus on her=
e, but since you can also get information about the user from a resource we=
 can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this has bee=
n at the heart of a lot of confusion in recent threads, as well as confusio=
n about the scope of the inclusion of identity in the GNAP protocol.
<=
div>
So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what i=
t already does, and let=E2=80=99s find a way to differentiate between when =
an item, claim or otherwise,=C2=A0=C2=A0comes as part of a resource and whe=
n it comes back directly. This is an important differentiating feature for =
GNAP.

Some straw man ideas, none of which I=E2=80=
=99m particularly in love with:

=C2=A0- direct dat=
a
=C2=A0- properties
=C2=A0- details
=C2=A0- =
statements

The important thing here is that it=E2=
=80=99s not necessarily :about: the RO, and that it is :not: in a resource.=


Any other thoughts?

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



--000000000000cfba7505ab335b3b--


From nobody Fri Jul 24 10:45: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 4E3053A109A for ; Fri, 24 Jul 2020 10:45:44 -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 m83D0SC3RDF9 for ; Fri, 24 Jul 2020 10:45:38 -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 8C2633A1099 for ; Fri, 24 Jul 2020 10:45:37 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id q7so10828050ljm.1 for ; Fri, 24 Jul 2020 10:45:37 -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=XjSi3Hve6OmQX0M8rkrhW9Q5XHZ4zzicNGYBvUwB9ko=; b=mzCnKzJcSFmtLQVAMqIuzRDN7AuazUHpQLEkSSAVVJzH8q+t7IY8NexbYlFbh/RlYE ym+lcQbxgIYfxjIcsPheMRW3lVkY/wIBQXVMPmlUZI+/pwHnNu6rKWZ+welfGvq+N1jS jkk/lv9Z5xhccLrkzTwGvUKm6iWoMwxtJFp0JmSajYMy/9lXEXl6X5KlomXpEhvVMSWr KTwv3t9Lg0jWtgg6hjyMfSMezMGFZ/88GT7SshiibkONH4jXyrwR+dUXKVuWNqcfNsKu CVl2G3+IyqAY6RB2EcuTWEoj2HiRtb9Y2GohYE78mFmcSQnt4rlLo68GcvguQhcdRH8g 59Eg==
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=XjSi3Hve6OmQX0M8rkrhW9Q5XHZ4zzicNGYBvUwB9ko=; b=ZHM3d8LqXvNhRQTll8kCv41Iw+zVOBVd/c60cjHDd8w17Bmudi9DREHSHnZ05GN+rp sktZMWHgRyunCpr2Q7hSjirjLiUZxcC4esY5L2XrUXzFcn/BcNGL3bbGO0ujm8aMBHhn h6BTuw0Qw0w6+DnGzGaOjnaKkyQixZrw0GVTyMBnK0J0qNQCrW/djFBPaH9GnRxiax8x lc+zev1u9rju+cSs5ykWHyG1XXbKI/nM2ySv04JXaWRrkfnZwPI4N9MZf5hho5cvUE9S XaDDboY/Ejg/RM7ByzlUwcCTKaXprY2RTHfLXed9glWqBz2Fq+1LlJV20msOqik5RDOe zvdQ==
X-Gm-Message-State: AOAM532Tke5l3943jP97HsrYSeTrKA63k5wQyVEfebBeccFdlxLl3l73 Pf4rEohv4el0nIYFME+N9LrghOJqJ44A8qnJCacUZAIC
X-Google-Smtp-Source: ABdhPJzoXl0eDHNG+nYFER02laiPkrbIRQfWzT50OpsZBJ9yOOktJwse/0s8NiiNIU+zLZmQbN6lWJPi84cd2io670o=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr5061728ljh.110.1595612735439;  Fri, 24 Jul 2020 10:45:35 -0700 (PDT)
MIME-Version: 1.0
References:           <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>    
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 24 Jul 2020 10:44:58 -0700
Message-ID: 
To: Denis 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004b87f505ab338a85"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 24 Jul 2020 17:45:44 -0000

--0000000000004b87f505ab338a85
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis, comments inserted ...

On Fri, Jul 24, 2020 at 9:08 AM Denis  wrote:

> Hi Dick,
>
> draft-hardt-xauth-protocol-13 describes a solution without clearly statin=
g
> what the problem(s) to be solved is/are.
>

I agree that the problem description is not as crisp as I would like it to
be. A challenge is that there is a broad spectrum of use cases solved by
OAuth 2, and OpenID Connect, as well as the new use cases that are solved
by GNAP.

That is why I am suggesting we gather some use cases so we have a common
understanding of the problems that are in scope.


>
> At the moment, draft-hardt-xauth-protocol-13 includes a single figure on
> page 4 and from previous discussions I understood that
> it is no more up-to-date since the first data flow is now a contact with =
a
> RS. The reason(s) for the GS to contact a RO has still not
> been explained (since the inputs and outputs are not described). The
> discovery information made available at various steps at the RS
> is not described.
>

I have made no updates as we are in a quiet period prior to the WG meeting
next week when documents cannot be updated.


>
> Figure 4 shows only a single RS. Is the relaying of one operation by that
> RS to a second RS in the scope of this document ?
> If yes, how is it handled ?
>

I view that as an advanced use case that would be covered in a separate
document.


>
> Figure 4 shows only a single GS. How would be the data flow when access
> tokens from two GSs are needed by a RS ?
>

I don't know of a use case where two tokens would be needed by an RS. Would
you elaborate?
The RS being able to accept tokens from two different GSes is covered, but
the Client is only using a token from one GS at a time.



>
> What we need first is not a set of "use cases" but a clear model with a
> data flows and a list of its properties/characteristics.
>

I disagree. The use cases describe the problems we are looking to solve.
The data flows are part of the solution. For example, from my understanding
of your use case, you don't want the GS to have visibility into the User's
activity. Am I correct that this is one of your requirements for your use
case?



> Then after, we can understand much better which use cases can/will be
> supported. For example, shall a RS (or its RO) have
> prior relationships with the GS ? What is the difference/implications whe=
n
> it has or it hasn't ?
>
> In order to have a fair comparison, we should try to list model
> properties/characteristics.
>
> At the moment, the model I have described including the data flows is
> clear. The discovery information made available by a RS is clear.
> I have not listed all its properties/characteristics of that model, but I
> am pretty sure that you already have a flavour of it.
>
> In the mean time, it would be nice if you could show using two figures:
>
>    - the case of the relaying of one operation by one RS to a second RS
>    (if it is in the scope of your document),
>    - the case where access tokens from two GSs are needed by one RS (if
>    it is in the scope of your document).
>
>
See above


>
>    -
>
> Denis
>
> Hi Denis
>
> I think it would be useful to take a step back and for you to describe
> your use case.
> After that, we can explore the different ways that your use case can be
> addressed.
>
> Looking at your previous communication, it describes the solution, and th=
e
> justification,
> but it is not clear what use cases you are needing to solve.
>
> /Dick
>
>
> =E1=90=A7
>
> On Wed, Jul 22, 2020 at 9:34 AM Denis  wrote:
>
>> Hello Dick,
>>
>> I have identified the reason of the major difference between our two
>> approaches.
>>
>> Access control may be performed using either ACLs (Access Control Lists)
>> or Capabilities.
>>
>> *Note *: a capability identifies a resource and an allowed operation
>> that can be performed on that resource.
>>
>> You are advocating a Capabilities approach while I am advocating an ACL
>> approach.
>>
>> The capabilities approach allows the GS to trace every operation
>> performed by the users on any RS known by a GS.
>> The management of these capabilities is made via the GS or at the GS by
>> the various ROs. If the management is made
>> via the GS, then a trusted communication channel needs to be established
>> with every RO. If the management is made
>> at the GS, then an authentication mechanism needs to be established with
>> every RO. In the last case, the GS has the
>> ability to know all the capabilities of the users whether they are used
>> or not. The less that can be said is that this model
>> is not privacy friendly.
>>
>> With the ACL approach, a RO directly manages an ACL placed in front of
>> each RS. The Access Control Decision Function
>> (ADF) at the RS is able to keep track from prior decisions. The GS is
>> kept ignorant of the content of these ACLs and only
>> delivers to its clients attributes that are placed into access tokens.
>> Such a model may be privacy friendly.
>>
>> Other comments are between the lines prefixed with [Denis].
>>
>>
>> On Tue, Jul 21, 2020 at 11:26 AM Denis  wrote:
>>
>>> Hello Dick,
>>>
>>> Thank you for your feedback. Comments are between the lines.
>>>
>>> comments inserted ...
>>>
>>> On Tue, Jul 21, 2020 at 6:03 AM Denis  wrote:
>>>
>>>> Hello Dick,
>>>>
>>>> I duplicate the most important comment at the beginning of this email:
>>>>
>>>> You are considering using an access control model to build a workflow
>>>> model.
>>>>
>>>> While it may be interesting to define a workflow model, this should be
>>>> considered
>>>> as a separate and different work item.
>>>>
>>>> See the other comments between the lines.
>>>>
>>>> On Mon, Jul 20, 2020 at 2:05 AM Denis  wrote:
>>>>
>>>>> Hi Dick,
>>>>>
>>>>> On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:
>>>>>
>>>>>> Hello Francis and Dick,
>>>>>>
>>>>>> The good news first: we are making some progress. We are now close t=
o
>>>>>> an agreement with steps (1) up to (3),
>>>>>> ... except that the place where the user consent is captured is not
>>>>>> mentioned/indicated.
>>>>>>
>>>>>
>>>>> This major question which is currently left unanswered is where, when
>>>>> and how the user consent is captured.
>>>>>
>>>>
>>>> When is covered, per the sequence. How and where are out of scope of
>>>> what I drafted.
>>>>
>>>> It is clear that the "User consent and choice" is not currently
>>>> addressed in the draft, but it should.
>>>> The support of the "User consent and choice" has strong implications
>>>> not only in the sequences of the exchanges
>>>> but also by which entity it should be performed.
>>>>
>>> "consent" is in the latest draft 7 times.
>>>
>>> "Consent" is present 5 times. The User consent is different from the RO
>>> consent (when/if it is required).
>>>
>>> The server acquires consent and authorization from the user *and/**or
>>> resource owner **if required.*
>>>
>>> User consent is *often required* at the GS. GNAP enables a Client and
>>> GS to negotiate the interaction mode for the GS to obtain consent.
>>>
>>> The GS *may *require explicit consent from the RO or User to provide
>>> these to the Client.
>>>
>>> The User consent is not an alternative to the RO consent. So using
>>> "and/or" in the first sentence is incorrect.
>>>
>>
>> My language is sloppy there. Consent is always from the RO. The User may
>> be the RO.
>>
>> [Denis] No. Once again: The "*User consent*" is different from what you
>> call the "*RO consent*" (when/if it is required).
>> The "RO consent" is not in fact a consent but the release of a capabilit=
y
>> to a client by one of the many R0s with which
>> the GS has relationships.
>>
>> Since the second sentence is using the wording "often required" there is
>>> no requirement to get the User consent.
>>>
>> User consent may not be required. There may not be a User. The consent
>> may have been gathered previously.
>>
>> [Denis] In order to follow the privacy principles, a "User consent" phas=
e
>> is required. The User is a natural person.
>> A Client is called either by a User (i.e. a natural person) or by a
>> Client application.
>>
>> The second sentence does not consider the possibility to get the User
>>> consent in a place different from the GS.
>>>
>> Agreed. But we do agree that the GS gets the consent, either directly
>> from the RO, or from the Client (in your example).
>>
>> [Denis] No. I disagree. In an ACL based systems, the GS does not need to
>> ask or receive any consent.
>> The client selects the set of attributes that it wants to be inserted
>> into an access token.
>> If the GS has the requested attributes, then it provides them, otherwise
>> it returns an error to the Client.
>>
>> IMO, the User consent should be captured by the Client, i.e. not by the
>>> GS.
>>> The information used to obtain the User consent should be standardized
>>> (... and it can be standardized).
>>>
>>> I think the abstract sequence as proposed by Francis is a great
>>> addition, and would clarify where consent is in the sequence.
>>>
>>> The current sketch does not illustrate the place the User Consent is
>>> captured, in particular by the Client.
>>>
>> It is an abstraction. The GS receives the consent. How consent is
>> gathered is a detail that is dependent on the use case.
>>
>> [Denis] I really wonder whether there is really a "consent" to be
>> received by the GS in both cases (i.e. ACLs or Capabilities).
>>
>>    - For ACLs, the consent needs to be done by the Client.
>>    - For Capabilities, the current description is not clear since the
>>    inputs and the outputs for this "consent" phase
>>    are not currently described in the draft.
>>
>>
>>
>>>
>>>
>>>> Another important point to consider and to explain is related to the
>>>>> assurances that the user can obtain about
>>>>> the respect of his choices. This point is currently left unanswered i=
n
>>>>> draft-hardt-xauth-protocol-13.
>>>>>
>>>> This point is equally important: such assurance can only be obtained i=
f
>>>> the access token returned to the client
>>>> is not considered to be opaque to the client. This is a necessary
>>>> condition but not the single condition:
>>>> the Client must also be in a position to capture/memorize the "User
>>>> consent and choice" of the user in order to be able
>>>> to verify it afterwards using the content of the access token(s).
>>>>
>>>
>>> We disagree on this being a requirement for all use cases. It may be in
>>> some.
>>>
>>> OK. Then this means that there will be no sentence in the draft such as=
 :
>>> "access tokens returned to the client are not considered to be opaque t=
o
>>> the client".
>>>
>>
>> For OAuth use cases, which GNAP supports, the access token is opaque to
>> the Client. As you have noted, there are use cases where the access toke=
n
>> is NOT opaque.
>>
>> [Denis] Wait a second. There is no requirement to support all OAuth use
>> cases.
>> I believe that there is a requirement to support OAuth 2.0 ASs, while th=
e
>> clients may be different
>> and hence GNAP clients do not need to inherit of the limitations of OAut=
h
>> 2.0 clients.
>>
>>
>>
>>>
>>>
>>>>
>>>>> If a RO needs to be involved and since a RO is directly associated
>>>>>> with a RS, why can't it be directly queried
>>>>>> by the appropriate RS after step (2) or later on ?
>>>>>>
>>>>>
>>>>> Good question. Perhaps you can expand on a use case where that would
>>>>> be useful?
>>>>>
>>>>> Before I expand, would you be able to explain first under which
>>>>> circumstances a RO needs to be queried by a GS ?
>>>>> How can the GS identify which RO to query ?
>>>>>
>>>> If the User is the RO, then the GS knows who to query.
>>>>
>>>> I still have difficulties to understand what you mean here.
>>>> How could a GS know that "the User is the RO" ?  If "the User is the
>>>> RO", why does the GS needs to query the User ?
>>>>
>>>
>>> To get consent?
>>>
>>> To get a "RO consent" to himself ???
>>>
>>
>> The GS needs consent from the RO. If the RO is the User, then consent
>> from the RO is equivalent to consent from the User.
>>
>> [Denis] See above.
>>
>>
>>
>>>
>>>
>>>> If the RO is a separate entity, then the GS knows the RO from the RS
>>>> being queried.
>>>>
>>>>  ... and this gives the ability for the GS to log/trace all the RSs
>>>> accessed by a given User and at which instant of time the access token=
 has
>>>> been granted.
>>>>
>>>> An example is a user would like access to an enterprise asset where a
>>>> workflow is started to gain approval, and an administrator or manager
>>>> provides consent.
>>>>
>>>> Thanks for this example. I finally understand what you have in mind:
>>>> you are considering using an access control model to build a *workflow
>>>> model*.
>>>> While it may be interesting to define a workflow model, this should be
>>>> considered as a *separate and different work item*.
>>>>
>>>
>>> The actual workflow is out of scope.
>>>
>>> I am glad you agree with this. But this means that your example was not
>>> appropriate to illustrate your point.
>>>
>>
>> It illustrates a use case where the RO and User are not the same party,
>> and why the GS needs to query the RO, which was your question if I
>> understood it correctly.
>>
>> [Denis] Since the inputs and the outputs for this "RO consent" phase are
>> not currently described in the draft, the point is still unsolved.
>>
>> As soon as there is a RO consent obtained at the GS, the major problem i=
s
>>> that the GS is able to act as Big Brother.
>>> If a RO consent is performed at the RS, then the GS will not know who
>>> the RS is: it is then unable to act as Big Brother,
>>> even if it would enjoy to play that role.
>>>
>> In an enterprise use case, the GS's knowledge of who is accessing which
>> RS is a feature.
>>
>> Do you mean that it is "normal" in an enterprise that a single point of
>> control is able to trace all their actions ?
>> From a security point of view, a single point of failure will have
>> dramatic consequences.
>>
>> In your use cases, it seems that the RO is the User.
>>
>> I do hope that you have finally understood that, in my use case, the RO
>> is **not** the User.
>>
>> The GS knows the User is wanting to let a Client access something. If th=
e
>> access token is generic, and could be presented to any RS that provides =
a
>> standardized function,
>> then the GS does not know which RS is being accessed by a Client for the
>> User. This seems to meet your privacy objectives. If not, what is wrong?
>>
>> For security reasons, an access token needs to be targeted (which does
>> not necessarily mean that an identifier of the RS shall be included into
>> the access token).
>>
>> if the admin grants access, then the access granted to the client
>>> changes.
>>>
>>>> The model you propose may be suited for an enterprise environment but
>>>> is not scalable over the Internet.
>>>>
>>> It is one of the use cases we are working to address.
>>>
>>>> What is needed is an access control model usable over the Internet wit=
h
>>>> millions of RSs and thousands of ASs/GSs.
>>>>
>>> I agree the model should also scale to internet scale.
>>>
>>> Fine. Another point on which we are in agreement.
>>>
>>> The model can scale to the Internet based on the following assumptions:
>>>
>>> The flow starts with the steps (1) to (4) as illustrated by Francis,
>>> i.e. the flow starts with a contact with a RS.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS |
>>>  |RO | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Request    =
 |
>>>    |   |-------->|       |      |      |   |         |(2) Service Inten=
t
>>> |   |         |------>|      |      |   |         |(3) AuthZ Challenge =
 |
>>> |         |<------|      |      |   |         |(4) AuthZ Request    |  =
 |
>>>       |------------->|      |*
>>>
>>> The GS/AS does not need to have any prior relationship with ROs and/or
>>> RSs.
>>>
>>> Furthermore, it is possible to prevent the GS to act as Big Brother whe=
n
>>> the identity of the RS is not disclosed to the GS.
>>>
>>
>> What happens after (4) above?
>>
>> [Denis] The key point is that we first need to agree on the first four
>> exchanges. Do we ?
>>
>> The fifth exchange is different whether ACLs or Capabilities are being
>> used.
>>
>>
>>
>>> Which information is supposed to be presented to the RO ?
>>>>>> Which information is supposed to be returned by the RO ?
>>>>>>
>>>>>
>>>>> Just like how the user authenticates to an AS, how the AS and RO
>>>>> communicate is out of scope.
>>>>>
>>>>> At the moment, the usefulness of a dialogue between a GS and a RO has
>>>>> not been explained, nor demonstrated.
>>>>> The question is about the functionality of that dialogue in terms of
>>>>> input and output information (and not about
>>>>> the design of a protocol or of a user interface). Anyway, AFAIU a
>>>>> dialogue between a GS and a RO is optional.
>>>>>
>>>>
>>>> See enterprise example above.
>>>>
>>>> It is not an access control example, but a workflow example.
>>>>
>>>> Access  control has been defined a long time ago and the last edition
>>>> of the model has been confirmed in year 1996: ISO/IEC 10181-3: 1996.
>>>> "Information technology =E2=80=94 Open Systems Interconnection =E2=80=
=94 Security
>>>> frameworks for open systems: Access control framework =E2=80=94 Part 3=
".
>>>>
>>>> Two major functions have ben defined: an Access Control Enforcement Fu=
nction
>>>> (AEF) and an Access Control Decision Function(ADF).
>>>>
>>>> Access Control Enforcement Function (AEF):
>>>> A specialized function that is part of the access path between an
>>>> initiator and a target on each access request and enforces the decisio=
n
>>>> made by the ADF.
>>>> Access Control Decision Function (ADF) :
>>>> A specialized function that makes access control decisions by applying
>>>> access control policy rules to an access request, ADI (of initiators,
>>>> targets, access requests,
>>>> or that retained from prior decisions), and the context in which the
>>>> access request is made.
>>>>
>>>> The role of the RO is to define the "access control policy rules" at
>>>> the RS according to the context in which the access request is made.
>>>>
>>> I'm pretty familiar with access control systems. :)
>>>
>>> I would say that the access control is happening at the RS. The client
>>> presents a token when accessing an API.
>>> The RS uses the token, and any policy required, to make an access
>>> decision.
>>>
>>> Fine. It looks like we are in agreement. Unfortunately, this is not the
>>> case just below.
>>>
>>> Here is flow:
>>>
>>> 1) The Client requests access to an RS from the GS.
>>>
>>> No. We are no more in agreement. This is different from the flow drawn
>>> by Francis.
>>>
>> My bad. Typo. I meant RO.
>>
>>
>>> 2) The GS queries the RS if access should be granted.
>>>
>>>  No. The GS should not be forced to have a flow with the RS.
>>>
>> Same mistake as above, I meant RO.
>>
>>> 3) If access is granted, the GS creates an access token representing th=
e
>>> granted access, and returns it to the Client.
>>>
>>> This model is by no way conformant to ISO/IEC 10181-3: 1996
>>>
>> I'm unclear on why, or why it is even relevant.
>>
>>> 4) The Client presents the access token to the RS to show it has been
>>> granted access.
>>>
>>> No. The client presents a token when accessing an API. The RS uses the
>>> token, and any policy required, to make an access decision.
>>> The token never contains an information like "Please grant an access to
>>> the holder of this token".
>>>
>> Let me provide more clarity in the sentence:
>>
>> The Client presents the access token to the RS, to show the RS that the
>> Client has been granted access to a resource at the RS by the GS.
>>
>> [Denis] This time, please consider both the ACLs approach and the
>> Capabilities approach.
>>
>>
>>
>>> A couple advantages of this model:
>>> - that the RS does not need to know much, if anything about the Client.
>>> - the access token MAY be self contained so that the Client does not
>>> need to query the GS on each access.
>>>
>>> There are so many disadvantages that I will not list them.
>>>
>> Darn: I clearly was not firing on all cylinders when I typed this out.
>> Let me correct:
>>
>> - the access token MAY be self contained so that the RS does not need to
>> query the GS on each access to the RS by the Client.
>>
>> [Denis] A few comments in the case of a capability approach:
>>
>> - for each GS, the RS needs to locally manage which operation(s) is/are
>> allowed to it.
>>
>> - the GS needs to establish a trusted communication channel or an
>> authentication mechanism with each RO
>>    (which is associated with an explicit RS identifier).
>>
>> - the GS could play the role of the RO and hence be in a position to
>> issue any capability for any RS (without a "RO consent").
>>
>>    The target of an attack will clearly be the GS.
>>
>> I would not say that GNAP is an access control protocol, as how the RS
>>> uses the token to determine access is out of scope.
>>>
>>> This is where we have a major discrepancy: how the RS uses the token to
>>> determine access is *within* the scope.
>>>
>> [Denis] Do you agree or disagree ?
>>
>> The RS announces in advance to the client what it needs so that the
>>> client can perform a a given operation and if the client supplies the
>>> requested attributes
>>> obtained from some GS/AS(s) trusted by the RS, then access to that RS i=
s
>>> granted by the RS. If the RS cannot perform the requested operation on =
its
>>> own,
>>> then the client should be informed about some requested attributes that
>>> need to be obtained from some GS/AS(s) trusted by the next RS(s) in a c=
hain
>>> for subsequent operations. The User consent should also be obtained
>>> before performing the chaining operation.
>>>
>>> Chaining operations between RSs over the Internet is within the scope
>>> (... and may be achieved).
>>>
>> [Denis] Do you agree or disagree ?
>>
>> Denis
>>
>>
>>>>
>>>>> For many use cases, the User is the RO, and the interaction is throug=
h
>>>>> a user interface, not a machine protocol.
>>>>>
>>>>> Wait a second. You wrote "the User is the RO". The User is attempting
>>>>> to make an access to a RS by using a Client.
>>>>> *That* User is not the RO of the RS.
>>>>>
>>>> The user being the RO is the initial use case for OAuth.
>>>>
>>>> OAuth 2.0 is no more mandating such a case.
>>>>
>>>
>>> I don't know what you mean by that.
>>>
>>> Copy and paste from draft-ietf-oauth-security-topics:
>>>
>>> OAuth initially assumed a static relationship between client,
>>> authorization server and resource servers.  (...)
>>> With the increasing adoption of OAuth, this simple model dissolved and,
>>> in several scenarios, was replaced
>>> by a dynamic establishment of the relationship between clients on one
>>> side and the authorization and
>>> resource servers of a particular deployment on the other side.
>>>
>>> This way, the same client could be used to access services of different
>>> providers (in case of standard APIs,
>>> such as e-mail or OpenID Connect) or serve as a frontend to a particula=
r
>>> tenant in a multi-tenancy environment.
>>>
>>>
>> This sentence does not mention the RO or the Client. I'm confused what w=
e
>> are talking about
>>
>>>
>>>
>>>> A client application would like access to the user's photos at a photo
>>>> sharing site. The resource is the user's photos. The user is the owner=
 of
>>>> that resource.
>>>>
>>>> If the user has already pre established the access control policy rule=
s
>>>> so that it can access to his own photos
>>>> then he does not need to grant in real time any additional
>>>> authorization.
>>>>
>>> I don't understand what you are trying to say. The photo sharing exampl=
e
>>> was a driving use case for the creation of OAuth.
>>>
>>> We would need to revisit the original scenario and consider if it can b=
e
>>> addressed in a different way than the original way.
>>>
>> The use case is the same. Is there a different solution you are proposin=
g?
>>
>>
>>
>> --
>> Txauth mailing 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

--0000000000004b87f505ab338a85
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis, comments inserted ...=C2=A0

On Fri, Jul 24, =
2020 at 9:08 AM Denis <denis.ietf@=
free.fr> wrote:

 =20
   =20
 =20
  

    

      
Hi Dick,

      


      

      
draft-hardt-xauth-protocol-13
        describes a solution without clearly stating what the problem(s)
        to be solved is/are.

<=
div>I agree that the problem description is not as crisp as I would like it=
 to be. A challenge is that there is a broad spectrum of use cases solved b=
y OAuth 2, and OpenID Connect, as well as the new use cases that are solved=
 by GNAP.

That is why I am suggesting we gather so=
me use cases so we have a common understanding of the problems that are in =
scope.
=C2=A0

      


      

      
At the moment,
        draft-hardt-xauth-protocol-13 includes a single figure on page 4
        and from previous discussions I understood that 

        it is no more up-to-date since the first data flow is now a
        contact with a RS. The reason(s) for the GS to contact a RO has
        still not 

        been explained (since the inputs and outputs are not described).
        The discovery information made available at various steps at the
        RS 

        is not described.

=

I have made no updates as we are in a quiet period prior to the WG mee=
ting next week when documents cannot be updated.
=C2=A0

        


        

      

      
Figure 4 shows only a single RS. Is
        the relaying of one operation by that RS to a second RS in the
        scope of this document ?

        If yes, how is it handled ?
=

I view that as an advanced use case that would be covered in=
 a separate document.
=C2=A0

      

      


      

      
Figure 4 shows only a single GS. How
        would be the data flow when access tokens from two GSs are
        needed by a RS ?

<=
div>I don't know of a use case where two tokens would be needed by an R=
S. Would you elaborate?
The RS being able to accept tokens from t=
wo different GSes is covered, but the Client is only using a token from one=
 GS at a time.

=C2=A0

      

      

      What we need first is not a set of "use cases" but a clear =
model
      with a data flows and a list of its properties/characteristics. 
<=
/div>

I disagree. The use cases descr=
ibe the problems we are looking to solve. The data flows are part of the so=
lution. For example, from my understanding of your use case, you don't =
want the GS to have visibility into the User's activity. Am I correct t=
hat this is one of your requirements for your use case?

=C2=A0

    

    
Then after, we can understand much
      better which use cases can/will be supported. For example, shall a
      RS (or its RO) have 

      prior relationships with the GS ? What is the
      difference/implications when it has or it hasn't ?

    

    


    

    
In order to have a fair comparison, we
      should try to list model properties/characteristics.

    


    

    
At the moment, the model I have
      described including the data flows is clear. The discovery
      information made available by a RS is clear.

    
I have not listed all its
      properties/characteristics of that model, but I am pretty sure
      that you already have a flavour of it.

    


    

    
In the mean time, it would be nice if
      you could show using two figures:

    
    
      
  • the case of the relaying of one operation by one RS to a
        second RS (if it is in the scope of your document),
    • 
      
  • the case where access tokens from two GSs are needed by one RS
        (if it is in the scope of your document).

See above
=C2=A0
  • 
      
    • 
    

    

      
Denis

    

    


    

    

     =20
      
Hi Denis
        


        

        
I think it would be useful to take a step back and for you
          to describe your use case. 

          After that, we can explore the different ways that your use
          case can be addressed.=C2=A0

        


        

        
Looking at your previous communication, it describes the
          solution, and the justification, 

          but it is not clear what use cases you are needing to solve.
        


        

        
/Dick

        


        

        


        

      

      
3D""==E1=90=A7

      

      

        
On Wed, Jul 22, 2020 at 9:34
          AM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hello Dick,

            


            

            
I have identified the reason of the major difference
              between our two approaches.

            


            

            
Access control may be performed using either ACLs
              (Access Control Lists) or Capabilities.

            


            

            
Note : a capability identifies a resource and
              an allowed operation that can be performed on that
              resource.

            

            


            

            
You are advocating a Capabilities approach while I am
              advocating an ACL approach.

            
The capabilities approach allows the GS to trace every
              operation performed by the users on any RS known by a GS.

              The management of these capabilities is made via the GS or
              at the GS by the various ROs. If the management is made 

              via the GS, then a trusted communication channel needs to
              be established with every RO. If the management is made 

              at the GS, then an authentication mechanism needs to be
              established with every RO. In the last case, the GS has
              the 

              ability to know all the capabilities of the users whether
              they are used or not. The less that can be said is that
              this model 

              is not privacy friendly.

            
With the ACL approach, a RO directly manages an ACL
              placed in front of each RS. The Access Control Decision
                Function 

                  (ADF)
                at the RS is able to keep track from prior decisions. The
              GS is kept ignorant of the content of these ACLs and only
              

              delivers to its clients attributes that are placed into
              access tokens. Such a model may be privacy friendly.

            
Other comments are between the lines prefixed with
              [Denis].

            

              

                


                  

                    
On Tue, Jul 21,
                      2020 at 11:26 AM Denis <denis.ietf@free.fr>
                      wrote:

                    

                    

                      

                        
Hello Dick,

                        


                        

                        
 Thank you for your feedback. Comments are
                          between the lines.

                        


                        

                        

                          

                            
comments inserted ...=C2=A0
                            

                            

                              
On Tue,
                                Jul 21, 2020 at 6:03 AM Denis <denis.ietf@free.fr>
                                wrote:

                              

                              

                                

                                  
Hello Dick,

                                  


                                  

                                  
I duplicate the most important
                                    comment at the beginning of this
                                    email:

                                  

                                    
You are considering using an
                                      access control model to build a
                                      workflow model.

                                       

                                      While it may be interesting to
                                      define a workflow model, this
                                      should be considered 

                                      as a separate and different work
                                      item.

                                  

                                  
See the other comments between
                                    the lines.

                                  

                                  


                                  

                                  

                                    
On Mon, Jul 20, 2020
                                      at 2:05 AM Denis <denis.ietf@free.fr>
                                      wrote:

                                      

                                        

                                          

                                            
Hi Dick,

                                            


                                            

                                            

                                              
On Fri, Jul
                                                17, 2020 at 9:21 AM
                                                Denis <denis.ietf@free.fr>
                                                wrote:

                                                

                                                  

                                                    

                                                      
Hello Francis
                                                        and Dick,

                                                      


                                                      

                                                      
The good news
                                                        first: we are
                                                        making some
                                                        progress. We are
                                                        now close to an
                                                        agreement with
                                                        steps (1) up to
                                                        (3), 

                                                        ... except that
                                                        the place where
                                                        the user consent
                                                        is captured is
                                                        not
                                                        mentioned/indicated=
.

                                                    

                                                  

                                                

                                              

                                            

                                            

                                            This major question which is
                                            currently left unanswered is
                                            where, when and how the user
                                            consent is captured.

                                          

                                        

                                        


                                        

                                        
When is covered, per the
                                          sequence. How and where are
                                          out of scope of what I
                                          drafted. 

                                        

                                      

                                    

                                  

                                  
It is clear that the "User consen=
t
                                    and choice" is not currently
                                    addressed in the draft, but it
                                    should.

                                    The support of the "User consent a=
nd
                                    choice" has strong implications no=
t
                                    only in the sequences of the
                                    exchanges 

                                    but also by which entity it should
                                    be performed.

                                

                              

                              
"consent" is in the latest dra=
ft 7
                                times. 

                              

                            

                          

                        

                        
"Consent" is present 5 times. The User
                          consent is different from the RO consent
                          (when/if it is required). 

                        

                        

                          
The server acquires consent and
                            authorization from the user and/or
                              resource owner if required.

                          

                          
User consent is often required at
                            the GS. GNAP enables a Client and=C2=A0 GS to
                            negotiate the interaction mode for the GS to
                            obtain consent.

                          

                          
 The GS may require explicit
                            consent from the RO or User to provide these
                            to the Client.

                          

                        

                        
The User consent is not an alternative to the
                          RO consent. So using "and/or" in the fi=
rst
                          sentence is incorrect.

                      

                    

                    


                    

                    
My language is sloppy there. Consent is always
                      from the RO. The User may be the RO.

                  

                

              

            

            
[Denis] No. Once again: The "User consent" =
is
              different from what you call the "RO consent"=
;
              (when/if it is required). 

              The "RO consent" is not in fact a consent but the r=
elease
              of a capability to a client by one of the many R0s with
              which 

              the GS has relationships. 

            

            

              

                

                  

                    

                      

                        
Since the second sentence is using the
                          wording "often required" there is no
                          requirement to get the User consent.

                        

                      

                    

                    
User consent may not be required. There may not
                      be a User. The consent may have been gathered
                      previously.

                  

                

              

            

            
[Denis] In order to follow the privacy principles, a
              "User consent" phase is required. The User is a nat=
ural
              person.

              A Client is called either by a User (i.e. a natural
              person) or by a Client application. 

            

            

              

                

                  

                    

                      

                        
 

                        
The second sentence does not consider the
                          possibility to get the User consent in a place
                          different from the GS.

                      

                    

                    
Agreed. But we do agree that the GS gets the
                      consent, either directly from the RO, or from the
                      Client (in your example).

                  

                

              

            

            
[Denis] No. I disagree. In an ACL based systems, the GS
              does not need to ask or receive any consent.

              The client selects the set of attributes that it wants to
              be inserted into an access token.

              If the GS has the requested attributes, then it provides
              them, otherwise it returns an error to the Client.

            

              

                

                  

                    

                      

                        
IMO, the User consent should be captured by
                          the Client, i.e. not by the GS. 

                          The information used to obtain the User
                          consent should be standardized (... and it can
                          be standardized).

                        

                        

                          

                            
I think the
                              abstract sequence as proposed by Francis
                              is a great addition, and would clarify
                              where consent is in the sequence. 

                          

                        

                        
The current sketch does not illustrate the
                          place the User Consent is captured, in
                          particular by the Client.

                      

                    

                    
It is an abstraction. The GS receives the
                      consent. How consent is gathered is a detail that
                      is dependent on the use case.

                  

                

              

            

            
[Denis] I really wonder whether there is really a
              "consent" to be received by the GS in both cases (i=
.e.
              ACLs or Capabilities).

            

            
    
              
  • For ACLs, the consent needs to be done by the Client.
              
  • For Capabilities, the current description is not clear
                since the inputs and the outputs for this "consent&quo=
t;
                phase
    
                are not currently described in the draft.
    • 
            

            

              

                

                  

                    
=C2=A0

                    

                      

                        

                          

                            

                              
=C2=A0

                              

                                

                                  

                                    

                                      

                                        

                                          
 Another important point
                                            to consider and to explain
                                            is related to the assurances
                                            that the user can obtain
                                            about 

                                            the respect of his choices.
                                            This point is currently left
                                            unanswered in
                                            draft-hardt-xauth-protocol-13.<=
br>
                                          

                                        

                                      

                                    

                                  

                                  
This point is equally important:
                                    such assurance can only be obtained
                                    if the access token returned to the
                                    client 

                                    is not considered to be opaque to
                                    the client. This is a necessary
                                    condition but not the single
                                    condition: 

                                    the Client must also be in a
                                    position to capture/memorize the
                                    "User consent and choice" of =
the
                                    user in order to be able 

                                    to verify it afterwards using the
                                    content of the access token(s).

                                

                              

                              


                              

                              
We disagree on this being a
                                requirement for all use cases. It may be
                                in some. 

                              

                            

                          

                        

                        
OK. Then this means that there will be no
                          sentence in the draft such as :

                          "access tokens returned to the client are no=
t
                          considered to be opaque to the client".

                      

                    

                    


                    

                    
For OAuth use cases, which GNAP supports, the
                      access token is opaque to the Client. As you have
                      noted, there are use cases where the access token
                      is NOT opaque.

                  

                

              

            

            
[Denis] Wait a second. There is no requirement to support
              all OAuth use cases. 

              I believe that there is a requirement to support OAuth 2.0
              ASs, while the clients may be different 

              and hence GNAP clients do not need to inherit of the
              limitations of OAuth 2.0 clients.

            

              

                

                  

                    
=C2=A0

                    

                      

                        

                          

                            

                              
=C2=A0

                              

                                

                                  

                                    

                                      

                                        

                                          
 

                                            

                                              

                                                

                                                  

                                                    

                                                      
If a RO needs
                                                        to be involved
                                                        and since a RO
                                                        is directly
                                                        associated with
                                                        a RS, why can't
                                                        it be directly
                                                        queried 

                                                        by the
                                                        appropriate RS
                                                        after step (2)
                                                        or later on ?

                                                    

                                                  

                                                  


                                                  

                                                  
Good question.
                                                    Perhaps you can
                                                    expand on a use case
                                                    where that would be
                                                    useful?

                                                

                                              

                                            

                                            
Before I expand, would
                                              you be able to explain
                                              first under which
                                              circumstances a RO needs
                                              to be queried by a GS ?

                                              How can the GS identify
                                              which RO to query ?

                                          

                                        

                                        
If the User is the RO, then
                                          the GS knows who to query. 

                                        

                                      

                                    

                                  

                                  
I still have difficulties to
                                    understand what you mean here. 

                                    How could a GS know that "the User
                                    is the RO" ?=C2=A0 If "the Us=
er is the
                                    RO", why does the GS needs to quer=
y
                                    the User ? 

                                  

                                

                              

                              


                              

                              
To get consent?

                            

                          

                        

                        
To get a "RO consent" to himself ???
                      

                    

                    


                    

                    
The GS needs consent from the RO. If the RO is
                      the User, then consent from the RO is equivalent
                      to consent from the User.

                  

                

              

            

            
[Denis] See above.

            

            

              

                

                  

                    
=C2=A0

                    

                    

                      

                        

                          

                            

                              
=C2=A0

                              

                                

                                  

                                    

                                      

                                        
If the RO is a separate
                                          entity, then the GS knows the
                                          RO from the RS being queried.
                                          

                                        

                                      

                                    

                                  

                                  
=C2=A0... and this gives the ability f=
or
                                    the GS to log/trace all the RSs
                                    accessed by a given User and at
                                    which instant of time the access
                                    token has been granted.

                                  

                                    

                                      

                                        
An example=C2=A0is a user woul=
d
                                          like access to an enterprise
                                          asset where a workflow is
                                          started to gain approval, and
                                          an administrator or manager
                                          provides consent.

                                      

                                    

                                  

                                  
Thanks for this example. I finally
                                    understand what you have in mind:
                                    you are considering using an access
                                    control model to build a workflow
                                      model. 

                                    While it may be interesting to
                                    define a workflow model, this should
                                    be considered as a separate and
                                      different work item.

                                

                              

                              


                              

                              
The actual workflow is out of scope.
                              

                            

                          

                        

                        
I am glad you agree with this. But this means
                          that your example was not appropriate to
                          illustrate your point.

                        

                      

                    

                    


                    

                    
It illustrates a use case where the RO and User
                      are not the same party, and why the GS needs to
                      query the RO, which was your question if I
                      understood it correctly.

                  

                

              

            

            
[Denis] Since the inputs and the outputs for this "RO
              consent" phase are not currently described in the draft,
              the point is still unsolved.

            

            

              

                

                  

                    

                      

                        
 As soon as there is a RO consent obtained at
                          the GS, the major problem is that the GS is
                          able to act as Big Brother.

                          If a RO consent is performed at the RS, then
                          the GS will not know who the RS is: it is then
                          unable to act as Big Brother, 

                          even if it would enjoy to play that role.

                      

                    

                    
In an enterprise use case, the GS's knowledge
                      of who is accessing which RS is a feature.

                  

                

              

            

            
Do you mean that it is "normal" in an enterprise t=
hat a
              single point of control is able to trace all their actions
              ? 

              From a security point of view, a single point of failure
              will have dramatic consequences.

            

              

                

                  

                    
In your use cases, it seems that the RO is the
                      User. 

                  

                

              

            

            
I do hope that you have finally understood that, in my
              use case, the RO is **not** the User.

            

              

                

                  

                    
The GS knows the User is wanting to let a
                      Client access something. If the access token is
                      generic, and could be presented to any RS that
                      provides a standardized function, 

                      then the GS does not know which RS is being
                      accessed by a Client for the User. This seems to
                      meet your privacy objectives. If not, what is
                      wrong?

                  

                

              

            

            
For security reasons, an access token needs to be
              targeted (which does not necessarily mean that an
              identifier of the RS shall be included into the access
              token).

            

            

              

                

                  

                    

                      

                        

                          

                            

                              
if the admin grants access, then the
                                access granted to the client changes. 

                              

                              

                                

                                  
 

                                  
The model you propose may be suited
                                    for an enterprise environment but is
                                    not scalable over the Internet.

                                

                              

                              
It is one of the use cases we are
                                working to address. 

                              

                              

                                

                                  
 What is needed is an access
                                    control model usable over the
                                    Internet with millions of RSs and
                                    thousands of ASs/GSs.=C2=A0 

                                  

                                

                              

                              
I agree the model should also scale
                                to internet scale. 

                              

                            

                          

                        

                        
Fine. Another point on which we are in
                          agreement. 

                        

                        
The model can scale to the Internet based on
                          the following assumptions:

                        

                          
The flow starts with the steps (1) to (4)
                            as illustrated by Francis, i.e. the flow
                            starts with a contact with a RS.

                        

                        
+----+ =C2=A0+------+ =C2=A0+---+ =
=C2=A0+---+
                              =C2=A0+---+

                              |User| =C2=A0|Client| =C2=A0|RS | =C2=A0|GS |=
 =C2=A0|RO |

                              +----+ =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 |(2) Ser=
vice Intent =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 |(3) Aut=
hZ Challenge =C2=A0|

                              =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =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) Aut=
hZ Request =C2=A0 =C2=A0|

                              =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |-------=
------>| =C2=A0 =C2=A0 =C2=A0|

                        
The GS/AS does not need to have any prior
                          relationship with ROs and/or RSs.

                        
Furthermore, it is possible to prevent the GS
                          to act as Big Brother when the identity of the
                          RS is not disclosed to the GS.

                        

                      

                    

                    


                    

                    
What happens after (4) above? 

                    

                  

                

              

            

            
[Denis] The key point is that we first need to agree on
              the first four exchanges. Do we ?

            

            
The fifth exchange is different whether ACLs or
              Capabilities are being used.

            

            

              

                

                  

                    
=C2=A0

                    

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
Which
                                                        information is
                                                        supposed to be
                                                        presented to the
                                                        RO ?

                                                        Which
                                                        information is
                                                        supposed to be
                                                        returned by the
                                                        RO ?

                                                    

                                                  

                                                  


                                                  

                                                  
Just like how the
                                                    user authenticates
                                                    to an AS, how the AS
                                                    and RO communicate
                                                    is out of scope.

                                                  

                                                

                                              

                                            

                                            
At the moment, the
                                              usefulness of a dialogue
                                              between a GS and a RO has
                                              not been explained, nor
                                              demonstrated.

                                              The question is about the
                                              functionality of that
                                              dialogue in terms of input
                                              and output information
                                              (and not about 

                                              the design of a protocol
                                              or of a user interface).
                                              Anyway, AFAIU a dialogue
                                              between a GS and a RO is
                                              optional.

                                            

                                          

                                        

                                        


                                        

                                        
See enterprise example
                                          above.

                                      

                                    

                                  

                                  
It is not an access control
                                    example, but a workflow example.

                                  
Access=C2=A0 contr=
ol
                                    has been defined a long time ago and
                                    the last edition of the model has
                                    been confirmed in year 1996: ISO/IEC=C2=A010181-3:
                                        1996.

                                    &qu=
ot;Information
                                      technology=C2=A0=E2=80=94 Open System=
s
                                      Interconnection=C2=A0=E2=80=94 Securi=
ty
                                      frameworks for open systems:
                                      Access control framework=C2=A0=E2=80=
=94
                                      Part=C2=A03".

                                  
Two
                                      major functions have ben defined:
                                      an Access
                                        Control Enforcement
                                        Function (AEF) and an =
Access Control
                                      Decision Function<=
/span>(ADF).

                                  

                                    
Access
                                        Control Enforcement
                                        Function (AEF):

                                        A specialized function that is
                                        part of the access path between
                                        an initiator and a target on
                                        each access request and enforces
                                        the decision made by the ADF.

                                    Access Control
                                      Decision Function
                                        (ADF) :
                                    A
                                      specialized function that makes
                                      access control decisions by
                                      applying access control policy
                                      rules to an access request, ADI
                                      (of initiators, targets, access
                                      requests, 

                                    or
                                      that retained from prior
                                      decisions), and the context in
                                      which the access request is made.

                                  
The role of the RO is to define the
                                    "access
                                      control policy rules" at the RS
                                      according to the
                                        context in which the access
                                        request is made.

                                

                              

                              
I'm pretty familiar with access
                                control systems. :)=C2=A0

                              


                              

                              
I would say that the access control
                                is happening at the RS. The client
                                presents a token when accessing an API.
                                

                                The RS uses the token, and any policy
                                required, to make an access decision.

                            

                          

                        

                        
Fine. It looks like we are in agreement.
                          Unfortunately, this is not the case just
                          below.

                        

                        

                          

                            

                              
Here is flow:

                              


                              

                              
1) The Client requests access to an
                                RS from the GS. 

                              

                            

                          

                        

                        
No. We are no more in agreement. This is
                          different from the flow drawn by Francis.

                      

                    

                    
My bad. Typo. I meant RO.

                    
=C2=A0

                    

                      

                        

                          

                            

                              
2) The GS queries the RS if access
                                should be granted. 

                              

                            

                          

                        

                        
=C2=A0No. The GS should not be forced to have a
                          flow with the RS.

                      

                    

                    
Same mistake as above, I meant RO.=C2=A0

                    

                      

                        
 

                        

                          

                            

                              
3) If access is granted, the GS
                                creates an access token representing the
                                granted access, and returns it to the
                                Client. 

                              

                            

                          

                        

                        
This model is by no way conformant to ISO/IEC=C2=A010181-3:
                              1996 

                            

                      

                    

                    
I'm unclear on why, or why it is even relevant=
.
                      

                    

                    

                      

                        
 

                        

                          

                            

                              
4) The Client presents the access
                                token to the RS to show it has been
                                granted access. 

                              

                            

                          

                        

                        
No. The client presents a token when
                          accessing an API. The RS uses the token, and
                          any policy required, to make an access
                          decision.

                          The token never contains an information like
                          "Please grant an access to the holder of thi=
s
                          token".

                      

                    

                    
Let me provide more clarity in the sentence:

                    


                    

                    
The Client presents the access token to the RS,
                      to show the RS that the Client has been granted
                      access to a resource at the RS by the GS.

                  

                

              

            

            
[Denis] This time, please consider both the ACLs approach
              and the Capabilities approach.

            

              

                

                  

                    
=C2=A0

                    

                      

                        

                          

                            

                              
A couple advantages of this model:

                              
- that the RS does not need to know
                                much, if anything about the Client.=C2=A0
                              
- the access token MAY be self
                                contained so that the Client does not
                                need to query the GS on each access. 

                              

                            

                          

                        

                        
There are so many disadvantages that I will
                          not list them.

                      

                    

                    
Darn: I clearly was not firing on all cylinders
                      when I typed this out. Let me correct:

                    


                    

                    

                      

                        

                          

                            
- the access token MAY be self
                              contained so that the RS does not need to
                              query the GS on each access to the RS by
                              the Client.

                          

                        

                      

                    

                  

                

              

            

            
[Denis] A few comments in the case of a capability
              approach:

            

              
- for each GS, the RS needs to locally manage which
                operation(s) is/are allowed to it.

                

                - the GS needs to establish a trusted communication
                channel or an authentication mechanism with each RO 

                =C2=A0=C2=A0 (which is associated with an explicit RS ident=
ifier).
                

              

              
- the GS could play the role of the RO and hence be in
                a position to issue any capability for any RS (without a
                "RO consent"). 

                

                =C2=A0=C2=A0 The target of an attack will clearly be the GS=
.

              

            

            

              

                

                  

                    

                      

                        

                          

                            

                              
I would not say that GNAP is an
                                access control protocol, as how the RS
                                uses the token to determine access is
                                out of scope.

                            

                          

                        

                        
This is where we have a major
                              discrepancy: how the RS uses
                          the token to determine access is *within* the
                          scope.

                      

                    

                  

                

              

            

            [Denis] Do you agree or disagree ?

            

              

                

                  

                    

                      

                        
The RS announces in advance to the client
                          what it needs so that the client can perform a
                          a given operation and if the client supplies
                          the requested attributes 

                          obtained from some GS/AS(s) trusted by the RS,
                          then access to that RS is granted by the RS.
                          If the RS cannot perform the requested
                          operation on its own, 

                          then the client should be informed about some
                          requested attributes that need to be obtained
                          from some GS/AS(s) trusted by the next RS(s)
                          in a chain

                          for subsequent operations. The User consent
                          should also be obtained before performing the
                          chaining operation.

                        

                        
Chaining operations between RSs over the
                          Internet is within the scope (... and may be
                          achieved).

                      

                    

                  

                

              

            

            
[Denis] Do you agree or disagree ?

            
Denis

            

            

              

                

                  

                    

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
=C2=A0

                                        

                                          

                                            

                                              

                                                

                                                  
For many use
                                                    cases, the User is
                                                    the RO, and the
                                                    interaction is
                                                    through a user
                                                    interface, not a
                                                    machine protocol. 

                                                  

                                                

                                              

                                            

                                            
Wait a second. You wrote
                                              "the User is the RO"=
;. The
                                              User is attempting to make
                                              an access to a RS by using
                                              a Client. 

                                              That User is not
                                              the RO of the RS.=C2=A0=C2=A0=
 

                                            

                                          

                                        

                                        
The user being the RO is
                                          the initial use case for
                                          OAuth. 

                                      

                                    

                                  

                                  
OAuth 2.0 is no more mandating such
                                    a case.

                                  

                                

                              

                            

                          

                        

                        

                          

                            


                              
I don't know what you mean by that.<=
/div>
                            

                          

                        

                        
Copy and paste from
                          draft-ietf-oauth-security-topics:

                        

                        

                          
OAuth initially assumed a static
                            relationship between client, authorization
                            server and resource servers.=C2=A0 (...)=C2=A0 =


                            With the increasing adoption of OAuth, this
                            simple model dissolved and, in several
                            scenarios, was replaced 

                            by a dynamic establishment of the
                            relationship between clients on one side and
                            the authorization and 

                            resource servers of a particular deployment
                            on the other side.

                            

                            This way, the same client could be used to
                            access services of different providers (in
                            case of standard APIs, 

                            such as e-mail or OpenID Connect) or serve
                            as a frontend to a particular tenant in a
                            multi-tenancy environment. 

                          

                        

                      

                    

                    


                    

                    
This sentence does not mention the RO or the
                      Client. I'm confused what we are talking about=C2=
=A0

                    

                      

                        

                          
 

                        

                        

                          

                            

                              
=C2=A0

                              

                                

                                  

                                    

                                      

                                        
A client application would
                                          like access to the user's
                                          photos at a photo sharing
                                          site. The resource is the
                                          user's photos. The user is th=
e
                                          owner of that resource.

                                      

                                    

                                  

                                  
If the user has already pre
                                    established the access control
                                    policy rules so that it can access
                                    to his own photos 

                                    then he does not need to grant in
                                    real time any additional
                                    authorization.

                                

                              

                              
I don't understand what you are
                                trying to say. The photo sharing example
                                was a driving use case for the creation
                                of OAuth.

                            

                          

                        

                        
We would need to revisit the original
                          scenario and consider if it can be addressed
                          in a different way than the original way.

                      

                    

                    
The use case is the same. Is there a different
                      solution you are proposing?

                    
=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


3D""=
=E1=90=A7


--0000000000004b87f505ab338a85--


From nobody Fri Jul 24 10:51: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 2F6243A0D09 for ; Fri, 24 Jul 2020 10:51: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 jgSQoglevTar for ; Fri, 24 Jul 2020 10:51:22 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450: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 F0FE63A10DD for ; Fri, 24 Jul 2020 10:50:26 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id b11so5623108lfe.10 for ; Fri, 24 Jul 2020 10:50: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=ulOK73Je97H94uJDHOozLb4mTcjWmT/wMRLAQBuSflM=; b=L5oGzeAJNefG0Uibflp33cwocpiWGekSB5HYG4CMyZ20Tuxxze38SNN0gzunndYrJU 5S7rjp6Dnw28rDa213fnYRlhCqmTU+nqtsuvSosHx5WLIkK2hjgZ54aq9OEd4othlMIC 2VIhlyHq8LWEYweduEbBc4u9Vq1BW+N9IpJFS7NrVNsylZBF4PnjGh2RXoYbgwVSVjAc QVeOLN+vHBFw8mxN+ydtTH1hMeLLe9bKlYhoPFGm2SGnHmbqb4Ku3mh/zo6xTRfs6o+x Z7GBWPoG+4ipLESN+jTrn637Fu/XA44aw4Go3VniVHNSJGfO3+enaEsWb/BSGt2a23Oo hxsw==
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=ulOK73Je97H94uJDHOozLb4mTcjWmT/wMRLAQBuSflM=; b=YXRNyxbzCW5cvTmJzeoddlRv8n4HafvhPVWFOrjQwU4E1+QyHAaUcd5zE+uPPtKPdt bRPkUbYqShdDNdE7EU6CfbA3WnuT8frbw0thWimYI9LHb7kXNLrGj+IWSCXWMqKvaBaL cJR6X3ZEQ2UNbgwGaGdjki6Bu75QFpRFHbHAGu0d69tYpopxaatAxFNrDnU6L6cFIVua KYDTgTb257PVfy5wKplErBTxOjcQk3Fozp9AL1eXwgZe7Pnf73Px3JTyktStRc07jtLV JnjG6Epg8Kah3+H+gsrmc1fMAKBg8JpF10q8nkBgqOr3lyGmDbDuR2lomJ6wMi5ouei8 Kv8w==
X-Gm-Message-State: AOAM530v1fP574D915FIkVVL8XzmAc8Y674pMCGpPv2WYDB1PT6W5KBK /R0HHlnsIcYTEfC+cTZSVhA5IrRlS6RHuAoAehk=
X-Google-Smtp-Source: ABdhPJxRCSyzfuFid/a8AixokvAeN5W/7m76/9yeMihHnyaAhpo8BL38Nq0RLVemoA4IyICM+Eg/BmW2JtzRoMxYamI=
X-Received: by 2002:ac2:5f48:: with SMTP id 8mr5522176lfz.157.1595613024990; Fri, 24 Jul 2020 10:50:24 -0700 (PDT)
MIME-Version: 1.0
References:              
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 24 Jul 2020 10:49:48 -0700
Message-ID: 
To: Tom Jones 
Cc: Justin Richer , Francis Pouatcha , txauth@ietf.org, Denis 
Content-Type: multipart/alternative; boundary="0000000000008dbb9605ab339be7"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 17:51:24 -0000

--0000000000008dbb9605ab339be7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tom, thanks for sharing.

I would consider the guardianship use case to be issuing an access token,
not claims, as it is being used to access an RS.

In my view, we keep Claims in GNAP to be only about the User, and the only
consumer of the Claims is the Client the User is using. This keeps Claims
from being overly complex.

=E1=90=A7

On Fri, Jul 24, 2020 at 10:32 AM Tom Jones 
wrote:

> Nat and I just had this discussion about claims & the claims aggregation
> spec.
> An example about claims that are not entirely about the user is the
> gurdian ship case.
> That case can be solved by creating a signed set if claims (which needs a
> name) from the RO granting approval to the user to make a "ID Token"
> (whatever) from the as to the client to be passed to the RS.
> my suggesting is that claim as not necessarily attributes and the data
> about the ro from the rs are distinct from the claims about the user from
> the as.
> I do not believe that claims aggregation is about claims (at least not
> often).
> so then the data from. the ro would never be a claim, even tho it was
> identical in form and substance from the claim produced by the as.
> Peace ..tom
>
>
> On Fri, Jul 24, 2020 at 10:25 AM Dick Hardt  wrote:
>
>> In OpenID Connect (OIDC), the Client can obtain Claims directly from the
>> OP in an ID Token, or the Client can obtain Claims using an access token=
 to
>> call the UserInfo endpoint, a Protected Resource[1].
>>
>> The Claims are about the User (not a RO).
>>
>> In XAuth, I'm proposing the Client may obtain bare claims from the GS
>> directly in addition to the mechanisms in ODIC.
>>
>> So I don't think we are changing the definition of Claim from how it has
>> been used in OIDC, and I fail to see any reason to NOT use Claim.
>>
>> Justin: you allude to Claims being about a party other than the User.
>> Would you provide an example?
>>
>> /Dick
>>
>> [1]
>>
>> UserInfo Endpoint
>> Protected Resource that, when presented with an Access Token by the
>> Client, returns authorized information about the End-User represented by
>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST us=
e
>> the https scheme and MAY contain port, path, and query parameter compone=
nts.
>>
>>
>>
>>
>> =E1=90=A7
>>
>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote:
>>
>>> I want to focus on one aspect here:
>>>
>>>
>>>> A Claim is a well understood term in the field. We should use it. It i=
s
>>>> still a Claim if it comes directly from the GS or from an RS.
>>>>
>>> I do not understand why a Resource release by an RS shall be h to as a
>>> claim, even if the content of the Resource is an assertion. It will lea=
d to
>>> confusion. If we limit claims to information GS releases into Token, Us=
er
>>> Info, and other objects it returns, this will help separate
>>> responsibilities between GS and RS. As soon as RS services and informat=
ion,
>>> this is called a Resource, no matter the nature of the content of that
>>> information.
>>>
>>>
>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=
=E2=80=9D in the way that
>>> we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back =
through an RS =E2=80=94 but in the
>>> context of GNAP, that makes it a resource. So we need a different word =
for
>>> data coming back directly from the AS to the client. Sometimes it=E2=80=
=99s going
>>> to be about the user, and that=E2=80=99s what we=E2=80=99re going to fo=
cus on here, but
>>> since you can also get information about the user from a resource we ca=
n=E2=80=99t
>>> just call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the he=
art of a lot of
>>> confusion in recent threads, as well as confusion about the scope of th=
e
>>> inclusion of identity in the GNAP protocol.
>>>
>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does,=
 and let=E2=80=99s find a way to
>>> differentiate between when an item, claim or otherwise,  comes as part =
of a
>>> resource and when it comes back directly. This is an important
>>> differentiating feature for GNAP.
>>>
>>> Some straw man ideas, none of which I=E2=80=99m particularly in love wi=
th:
>>>
>>>  - direct data
>>>  - properties
>>>  - details
>>>  - statements
>>>
>>> The important thing here is that it=E2=80=99s not necessarily :about: t=
he RO,
>>> and that it is :not: in a resource.
>>>
>>> Any other thoughts?
>>>
>>>  =E2=80=94 Justin
>>>
>>

--0000000000008dbb9605ab339be7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Tom, thanks for sharing.

I would con=
sider the guardianship=C2=A0use case to be issuing=C2=A0an access token, no=
t claims, as it is being used to access an RS.

In =
my view, we keep Claims in GNAP to be only about the User, and the only con=
sumer of the Claims is the Client the User is using. This keeps Claims from=
 being overly complex.
=C2=A0
3D""=E1=90=A7

On Fri, Jul 24, 2020 at 10:32 AM Tom Jones <thomasclinganjones@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">
Nat and I=
 just had this discussion about claims & the claims aggregation spec.An example about claims that are not entirely about the user is the gurd=
ian ship=C2=A0case.
That case can be solved by creating a signed =
set if claims (which needs a name) from the RO granting approval to the use=
r to make a "ID Token" (whatever) from the as to the client to be=
 passed to the RS.
my suggesting is that claim as not necessarily=
 attributes and the data about the ro from the rs are distinct from the cla=
ims about the user from the as.
I do not believe that claims aggr=
egation=C2=A0is about claims (at least not often).
so then the da=
ta from. the ro would=C2=A0never be a claim, even tho it was identical=C2=
=A0in form and substance from the claim produced by the as.
Peace ..tom
=



On Fri, Jul 24, 2020 at 10:25 AM Dick Hardt <dick.hardt@gmail.com>=
 wrote:
In OpenID Connect (OIDC), the Client can obtain Claims directly fr=
om the OP in an ID Token, or the Client can obtain Claims using an access t=
oken to call the UserInfo endpoint, a Protected Resource[1].

=

The Claims are about the User (not a RO).

In =
XAuth, I'm proposing the Client may obtain bare claims from the GS dire=
ctly in addition to the mechanisms in ODIC.

So I d=
on't think we are changing the definition of Claim from how it has been=
 used in OIDC, and I fail to see any reason to NOT use Claim.
Justin: you allude to Claims being about a party other than the=
 User. Would you provide an example?

/Dick

[1]
UserInfo Endpoint
Protected Resource t=
hat, when presented with an Access Token by the Client, returns authorized =
information about the End-User represented by the corresponding Authorizati=
on Grant. The UserInfo Endpoint URL MUST use the https scheme and MAY conta=
in port, path, and query parameter components.

<=
/div>


3D""=E1=90=A7
On =
Fri, Jul 24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspect =
here:


A Claim is a well understood term in the fie=
ld. We should use it. It is still a Claim if it comes directly from the GS =
or from an RS.=C2=A0
I do not understand why a=
 Resource release by an RS shall be h to as a claim, even if the content of=
 the Resource is an assertion. It will lead to confusion. If we limit claim=
s to information GS releases into Token, User Info, and other objects it re=
turns, this will help separate responsibilities between GS and RS. As soon =
as RS services and information, this is called a Resource, no matter the na=
ture of the content of that information.

This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=
=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in the con=
text of GNAP, that makes it a resource. So we need a different word for dat=
a coming back directly from the AS to the client. Sometimes it=E2=80=99s go=
ing to be about the user, and that=E2=80=99s what we=E2=80=99re going to fo=
cus on here, but since you can also get information about the user from a r=
esource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think th=
is has been at the heart of a lot of confusion in recent threads, as well a=
s confusion about the scope of the inclusion of identity in the GNAP protoc=
ol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D m=
ean what it already does, and let=E2=80=99s find a way to differentiate bet=
ween when an item, claim or otherwise,=C2=A0=C2=A0comes as part of a resour=
ce and when it comes back directly. This is an important differentiating fe=
ature for GNAP.

Some straw man ideas, none of whic=
h I=E2=80=99m particularly in love with:

=C2=A0- d=
irect data
=C2=A0- properties
=C2=A0- details
=C2=A0- statements

The important thing here is th=
at it=E2=80=99s not necessarily :about: the RO, and that it is :not: in a r=
esource.

Any other thoughts?

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




--0000000000008dbb9605ab339be7--


From nobody Fri Jul 24 11:10: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 22E793A0C75 for ; Fri, 24 Jul 2020 11:10:24 -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=[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, 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 3569LPpVperX for ; Fri, 24 Jul 2020 11:10:22 -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 0CF0C3A0C54 for ; Fri, 24 Jul 2020 11:10:22 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id v21so373498otj.9 for ; Fri, 24 Jul 2020 11:10: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=wRuhdHTRiuV8hGWBwECy5+jjElIK7WHLUPrhZWKofQ8=; b=t/3apSG+qPKGJbYFlHv8CVPDCzVWWcURGIGVsPPuugwe/t7JF4YQs0B3zDY/pp4p8D vrclMVF8SDKSZ8Xlqx0WgXsoOQrWzouU+qsfw07UU7I4fk513bOeRLh0RehFHVoCSwbo zJppVdVCG17uzX/div+slFKvmdScDc8J0L2L8W+/Vb1+wtHQb11Zms9K523Yrs/myjX2 j1axYwxkz8ywD3eMlJ8NzcV6RpspTM++QkgjbhtJ70xbvh9/wbvRvshGNektEH8gmtzK LnDdPFyayRMVY5TxNJZbExiyinXfYYu1bWZeQeLK99Ynm0O9aJU8HkhGKAZnO6it3vBw KS1Q==
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=wRuhdHTRiuV8hGWBwECy5+jjElIK7WHLUPrhZWKofQ8=; b=HPOkjfeZWhFzRDwWdyUza0L9pWKBufzqEHt8omMgekLxdgXC0pvEZYAvt+CdOU0oyG KKROT38/2MSTu6E4mnpsH3BO2+DKgau23/CxJFgFj2JXix+OajXpNyUccuIuGEriJxCm YbdbuVAhJjTAYT63u4K+Ojiq/vPGMsDytCehjKBbrkYt9/dVmo4Ij4ZS5buaprDecX27 DJVArKPg6fS8g2/ZhYVxYSy6pR32R+32BpmbLUtaM1cW0JlpCq7axzEjkugiIOmk0fgx mf79Lzz7RqUmagLfQl2vlUs3+Zbb3HgDhFgKo8VRAyHBjyAmtpyRvYGCNeW/paD4A5hK 63WQ==
X-Gm-Message-State: AOAM532fJiZuKTPKnPlMs41nOyHjFy4mcm7Pr8D6QiOo5NlYkf3V5eFV bKM+7YyJ98sXK0WhKBRje/6Q9z9NSBMEC7VDw8I=
X-Google-Smtp-Source: ABdhPJw7UWvfYSKSYNkU/gJnLJo5N6MvHWDLDsw6pdVGsaHq5wP5qrWrMYshnL1XNJ8J0J2pEu0v7boXbPIPD7QTX/0=
X-Received: by 2002:a9d:a03:: with SMTP id 3mr9617333otg.87.1595614221229; Fri, 24 Jul 2020 11:10:21 -0700 (PDT)
MIME-Version: 1.0
References:               
In-Reply-To: 
From: Tom Jones 
Date: Fri, 24 Jul 2020 11:10:09 -0700
Message-ID: 
To: Dick Hardt 
Cc: Justin Richer , Francis Pouatcha , txauth@ietf.org, Denis 
Content-Type: multipart/alternative; boundary="000000000000dae3ee05ab33e224"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 18:10:24 -0000

--000000000000dae3ee05ab33e224
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

now that is interesting.
So that i can understand what you're saying.
the access token that is issued (somehow) by the user to give the client
access to rs resources, does not have claims?
boy am i in the wrong place.

Peace ..tom


On Fri, Jul 24, 2020 at 10:50 AM Dick Hardt  wrote:

> Hi Tom, thanks for sharing.
>
> I would consider the guardianship use case to be issuing an access token,
> not claims, as it is being used to access an RS.
>
> In my view, we keep Claims in GNAP to be only about the User, and the onl=
y
> consumer of the Claims is the Client the User is using. This keeps Claims
> from being overly complex.
>
> =E1=90=A7
>
> On Fri, Jul 24, 2020 at 10:32 AM Tom Jones 
> wrote:
>
>> Nat and I just had this discussion about claims & the claims aggregation
>> spec.
>> An example about claims that are not entirely about the user is the
>> gurdian ship case.
>> That case can be solved by creating a signed set if claims (which needs =
a
>> name) from the RO granting approval to the user to make a "ID Token"
>> (whatever) from the as to the client to be passed to the RS.
>> my suggesting is that claim as not necessarily attributes and the data
>> about the ro from the rs are distinct from the claims about the user fro=
m
>> the as.
>> I do not believe that claims aggregation is about claims (at least not
>> often).
>> so then the data from. the ro would never be a claim, even tho it was
>> identical in form and substance from the claim produced by the as.
>> Peace ..tom
>>
>>
>> On Fri, Jul 24, 2020 at 10:25 AM Dick Hardt  wrote=
:
>>
>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from th=
e
>>> OP in an ID Token, or the Client can obtain Claims using an access toke=
n to
>>> call the UserInfo endpoint, a Protected Resource[1].
>>>
>>> The Claims are about the User (not a RO).
>>>
>>> In XAuth, I'm proposing the Client may obtain bare claims from the GS
>>> directly in addition to the mechanisms in ODIC.
>>>
>>> So I don't think we are changing the definition of Claim from how it ha=
s
>>> been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>
>>> Justin: you allude to Claims being about a party other than the User.
>>> Would you provide an example?
>>>
>>> /Dick
>>>
>>> [1]
>>>
>>> UserInfo Endpoint
>>> Protected Resource that, when presented with an Access Token by the
>>> Client, returns authorized information about the End-User represented b=
y
>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST u=
se
>>> the https scheme and MAY contain port, path, and query parameter compon=
ents.
>>>
>>>
>>>
>>>
>>> =E1=90=A7
>>>
>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote:
>>>
>>>> I want to focus on one aspect here:
>>>>
>>>>
>>>>> A Claim is a well understood term in the field. We should use it. It
>>>>> is still a Claim if it comes directly from the GS or from an RS.
>>>>>
>>>> I do not understand why a Resource release by an RS shall be h to as a
>>>> claim, even if the content of the Resource is an assertion. It will le=
ad to
>>>> confusion. If we limit claims to information GS releases into Token, U=
ser
>>>> Info, and other objects it returns, this will help separate
>>>> responsibilities between GS and RS. As soon as RS services and informa=
tion,
>>>> this is called a Resource, no matter the nature of the content of that
>>>> information.
>>>>
>>>>
>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=
=E2=80=9D in the way that
>>>> we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back=
 through an RS =E2=80=94 but in the
>>>> context of GNAP, that makes it a resource. So we need a different word=
 for
>>>> data coming back directly from the AS to the client. Sometimes it=E2=
=80=99s going
>>>> to be about the user, and that=E2=80=99s what we=E2=80=99re going to f=
ocus on here, but
>>>> since you can also get information about the user from a resource we c=
an=E2=80=99t
>>>> just call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the h=
eart of a lot of
>>>> confusion in recent threads, as well as confusion about the scope of t=
he
>>>> inclusion of identity in the GNAP protocol.
>>>>
>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does=
, and let=E2=80=99s find a way to
>>>> differentiate between when an item, claim or otherwise,  comes as part=
 of a
>>>> resource and when it comes back directly. This is an important
>>>> differentiating feature for GNAP.
>>>>
>>>> Some straw man ideas, none of which I=E2=80=99m particularly in love w=
ith:
>>>>
>>>>  - direct data
>>>>  - properties
>>>>  - details
>>>>  - statements
>>>>
>>>> The important thing here is that it=E2=80=99s not necessarily :about: =
the RO,
>>>> and that it is :not: in a resource.
>>>>
>>>> Any other thoughts?
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>

--000000000000dae3ee05ab33e224
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


now that is interesting.
So that i can understand what=
 you're saying.
the access token that is issued (somehow) by =
the user to give the client access to rs resources, does not have claims?
boy am i in the wrong place.=C2=A0

Peace ..tom


On =
Fri, Jul 24, 2020 at 10:50 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom, thanks for sharing.<=
div>
I would consider the guardianship=C2=A0use case to be is=
suing=C2=A0an access token, not claims, as it is being used to access an RS=
.

In my view, we keep Claims in GNAP to be only ab=
out the User, and the only consumer of the Claims is the Client the User is=
 using. This keeps Claims from being overly complex.
=C2=A0
=

3D""==E1=90=A7

<=
div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 24, 2020 at 10:32 AM Tom J=
ones <=
thomasclinganjones@gmail.com> wrote:
Nat and I just had this discus=
sion about claims & the claims aggregation spec.
An example about c=
laims that are not entirely about the user is the gurdian ship=C2=A0case.
That case can be solved by creating a signed set if claims (which =
needs a name) from the RO granting approval to the user to make a "ID =
Token" (whatever) from the as to the client to be passed to the RS.
my suggesting is that claim as not necessarily attributes and the d=
ata about the ro from the rs are distinct from the claims about the user fr=
om the as.
I do not believe that claims aggregation=C2=A0is about=
 claims (at least not often).
so then the data from. the ro would=
=C2=A0never be a claim, even tho it was identical=C2=A0in form and substanc=
e from the claim produced by the as.
Peace ..tom

<=
br>
On Fri,=
 Jul 24, 2020 at 10:25 AM Dick Hardt <dick.hardt@gmail.com> wrote:
In OpenID Conn=
ect (OIDC), the Client can obtain Claims directly from the OP in an ID Toke=
n, or the Client can obtain Claims using an access token to call the UserIn=
fo endpoint, a Protected Resource[1].

The Claims are abo=
ut the User (not a RO).

In XAuth, I'm proposin=
g the Client may obtain bare claims from the GS directly in addition to the=
 mechanisms in ODIC.

So I don't think we are c=
hanging the definition of Claim from how it has been used in OIDC, and I fa=
il to see any reason to NOT use Claim.

Justin: you=
 allude to Claims being about a party other than the User. Would you provid=
e an example?

/Dick

[1]
<=
div>UserInfo Endpoint
Protected Resource that, when presented wit=
h an Access Token by the Client, returns authorized information about the E=
nd-User represented by the corresponding Authorization Grant. The UserInfo =
Endpoint URL MUST use the https scheme and MAY contain port, path, and quer=
y parameter components.



<=
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=3D423af76b-40f5-4bab-ac59-2b640944e5cd">=
=E1=90=A7

On Fri, Jul 24, 2020 at =
5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspect here:


<=
/div>
A Claim is a well understood term in the field. We should use it.=
 It is still a Claim if it comes directly from the GS or from an RS.=C2=A0<=
/div>
I do not understand why a Resource release by =
an RS shall be h to as a claim, even if the content of the Resource is an a=
ssertion. It will lead to confusion. If we limit claims to information GS r=
eleases into Token, User Info, and other objects it returns, this will help=
 separate responsibilities between GS and RS. As soon as RS services and in=
formation, this is called a Resource, no matter the nature of the content o=
f that information.

This=
 is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=E2=80=9D=
 in the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D cou=
ld come back through an RS =E2=80=94 but in the context of GNAP, that makes=
 it a resource. So we need a different word for data coming back directly f=
rom the AS to the client. Sometimes it=E2=80=99s going to be about the user=
, and that=E2=80=99s what we=E2=80=99re going to focus on here, but since y=
ou can also get information about the user from a resource we can=E2=80=99t=
 just call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the heart=
 of a lot of confusion in recent threads, as well as confusion about the sc=
ope of the inclusion of identity in the GNAP protocol.

=

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does=
, and let=E2=80=99s find a way to differentiate between when an item, claim=
 or otherwise,=C2=A0=C2=A0comes as part of a resource and when it comes bac=
k directly. This is an important differentiating feature for GNAP.

Some straw man ideas, none of which I=E2=80=99m particular=
ly in love with:

=C2=A0- direct data
=C2=
=A0- properties
=C2=A0- details
=C2=A0- statements

The important thing here is that it=E2=80=99s not nece=
ssarily :about: the RO, and that it is :not: in a resource.

<=
/div>Any other thoughts?

=C2=A0=E2=80=94 Justin





--000000000000dae3ee05ab33e224--


From nobody Fri Jul 24 11:27: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 92F9C3A118D for ; Fri, 24 Jul 2020 11:27:53 -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 A4C_7iZii8ST for ; Fri, 24 Jul 2020 11:27:51 -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 6F9A33A1184 for ; Fri, 24 Jul 2020 11:27:51 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id 140so5696040lfi.5 for ; Fri, 24 Jul 2020 11:27: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=vpoUyOJbyQpMhcBpL9QDpwwOejgnHm0Okvx/PZolRZk=; b=UO1MeIAfP1EDEuXt75oOc/mylr83qO+prv/l+ok07gq7MPvx97qk5gpk8FxU5Z63Is XeQtb05A/s5FoPSx8shOxVbwoCuPGvyBHnA33uVI6Gl5Szh/8PXq+474sgVBeHTNogoM VTGD+nYtY1a9EHJu6wI6FP3Vq5sJOEcDRuSGCCQBTn90W0fJ89MrmaDQD9S+H4aHedRw tv/jL208zm7Ese1F2PWmE0QVnLd9KbugliZWvoMSvjntGZBjlrWDqxvDwlXl1le7T3Nh mQ0ykDmXaxpAS0GO1aB5+yWNCHpMt7XmQiAZsnUlbrBNaTtZ6d+Lf7nO1WNXSUE8Vdve szqg==
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=vpoUyOJbyQpMhcBpL9QDpwwOejgnHm0Okvx/PZolRZk=; b=NFDT0zCE33KscD/yjkgsUhltQGR5dB1q5tdvOGpcFNsYRfFUaPau6X7yFYOYtVniOM J4hHGgiLjvBSr7eD+XXr8ZObkk1t3fWWCHzt7g5k4IyKQ2QDxXf8KLnpYuZYHGgBtl5d uNDvMyydwvmfPZahEQvwFRmUayFUpW2rMH9dFQghEUJdTvzPLw1f24JH7/l6TM2jbmbt svluGObuEuCheryQ3SzvmQdBR57/YjH9iqgDTtU9Wnxm5lx29c1Y8G11JtayUAKYRKB7 COQXxD6YYf5biQwH5rCwZjl1q+J6KYIsaGNd4DtR6erbX06inuHfDpNre0E1CDNbo15w ASMw==
X-Gm-Message-State: AOAM532NUBGl3bm+VMLtwKEvNq41RJSV/sJ9TA4S3sfqG+ZYAPsoiKW6 nL9t3r7frpqdrUBhPbDcyI28JUTREJcM6rzO7wI=
X-Google-Smtp-Source: ABdhPJw0Rswlf2GPYG+XTBMsxKdQJ/csErxMVH765rAWrwNWGLzOOpM7tlex05aYQBtcm25T7jeW1I6Vgt2Vr6E9Odc=
X-Received: by 2002:a19:70c:: with SMTP id 12mr5713542lfh.207.1595615269385; Fri, 24 Jul 2020 11:27:49 -0700 (PDT)
MIME-Version: 1.0
References:                
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 24 Jul 2020 11:27:13 -0700
Message-ID: 
To: Tom Jones 
Cc: Justin Richer , Francis Pouatcha , txauth@ietf.org, Denis 
Content-Type: multipart/alternative; boundary="000000000000547c6d05ab342145"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 18:27:54 -0000

--000000000000547c6d05ab342145
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm not saying an access token cannot have claims. I'm saying what the
Client communicates to the GS so that there are claims in an access token
is out of scope for GNAP.

Said another way, GNAP specifies a container used by the Client to request
access tokens from the GS, and then presents those access tokens to the RS.
The contents of the container in the Client request, and the access token
contents, are out of scope of the core GNAP protocol.







On Fri, Jul 24, 2020 at 11:10 AM Tom Jones 
wrote:

> now that is interesting.
> So that i can understand what you're saying.
> the access token that is issued (somehow) by the user to give the client
> access to rs resources, does not have claims?
> boy am i in the wrong place.
>
> Peace ..tom
>
>
> On Fri, Jul 24, 2020 at 10:50 AM Dick Hardt  wrote:
>
>> Hi Tom, thanks for sharing.
>>
>> I would consider the guardianship use case to be issuing an access token=
,
>> not claims, as it is being used to access an RS.
>>
>> In my view, we keep Claims in GNAP to be only about the User, and the
>> only consumer of the Claims is the Client the User is using. This keeps
>> Claims from being overly complex.
>>
>> =E1=90=A7
>>
>> On Fri, Jul 24, 2020 at 10:32 AM Tom Jones 
>> wrote:
>>
>>> Nat and I just had this discussion about claims & the claims aggregatio=
n
>>> spec.
>>> An example about claims that are not entirely about the user is the
>>> gurdian ship case.
>>> That case can be solved by creating a signed set if claims (which needs
>>> a name) from the RO granting approval to the user to make a "ID Token"
>>> (whatever) from the as to the client to be passed to the RS.
>>> my suggesting is that claim as not necessarily attributes and the data
>>> about the ro from the rs are distinct from the claims about the user fr=
om
>>> the as.
>>> I do not believe that claims aggregation is about claims (at least not
>>> often).
>>> so then the data from. the ro would never be a claim, even tho it was
>>> identical in form and substance from the claim produced by the as.
>>> Peace ..tom
>>>
>>>
>>> On Fri, Jul 24, 2020 at 10:25 AM Dick Hardt 
>>> wrote:
>>>
>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from
>>>> the OP in an ID Token, or the Client can obtain Claims using an access
>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>
>>>> The Claims are about the User (not a RO).
>>>>
>>>> In XAuth, I'm proposing the Client may obtain bare claims from the GS
>>>> directly in addition to the mechanisms in ODIC.
>>>>
>>>> So I don't think we are changing the definition of Claim from how it
>>>> has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>
>>>> Justin: you allude to Claims being about a party other than the User.
>>>> Would you provide an example?
>>>>
>>>> /Dick
>>>>
>>>> [1]
>>>>
>>>> UserInfo Endpoint
>>>> Protected Resource that, when presented with an Access Token by the
>>>> Client, returns authorized information about the End-User represented =
by
>>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST =
use
>>>> the https scheme and MAY contain port, path, and query parameter compo=
nents.
>>>>
>>>>
>>>>
>>>>
>>>> =E1=90=A7
>>>>
>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote:
>>>>
>>>>> I want to focus on one aspect here:
>>>>>
>>>>>
>>>>>> A Claim is a well understood term in the field. We should use it. It
>>>>>> is still a Claim if it comes directly from the GS or from an RS.
>>>>>>
>>>>> I do not understand why a Resource release by an RS shall be h to as =
a
>>>>> claim, even if the content of the Resource is an assertion. It will l=
ead to
>>>>> confusion. If we limit claims to information GS releases into Token, =
User
>>>>> Info, and other objects it returns, this will help separate
>>>>> responsibilities between GS and RS. As soon as RS services and inform=
ation,
>>>>> this is called a Resource, no matter the nature of the content of tha=
t
>>>>> information.
>>>>>
>>>>>
>>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclai=
m=E2=80=9D in the way
>>>>> that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could com=
e back through an RS =E2=80=94 but in
>>>>> the context of GNAP, that makes it a resource. So we need a different=
 word
>>>>> for data coming back directly from the AS to the client. Sometimes it=
=E2=80=99s
>>>>> going to be about the user, and that=E2=80=99s what we=E2=80=99re goi=
ng to focus on here,
>>>>> but since you can also get information about the user from a resource=
 we
>>>>> can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this ha=
s been at the heart of a lot
>>>>> of confusion in recent threads, as well as confusion about the scope =
of the
>>>>> inclusion of identity in the GNAP protocol.
>>>>>
>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already doe=
s, and let=E2=80=99s find a way
>>>>> to differentiate between when an item, claim or otherwise,  comes as =
part
>>>>> of a resource and when it comes back directly. This is an important
>>>>> differentiating feature for GNAP.
>>>>>
>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in love =
with:
>>>>>
>>>>>  - direct data
>>>>>  - properties
>>>>>  - details
>>>>>  - statements
>>>>>
>>>>> The important thing here is that it=E2=80=99s not necessarily :about:=
 the RO,
>>>>> and that it is :not: in a resource.
>>>>>
>>>>> Any other thoughts?
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>

--000000000000547c6d05ab342145
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'm not saying an access token cannot have claims. I&#=
39;m saying what the Client communicates to the GS so that there are claims=
 in an access token is out of scope for GNAP.

Said anoth=
er way, GNAP specifies a container used by the Client to request access tok=
ens from the GS, and then presents those access tokens to the RS. The conte=
nts of the container in the Client request, and the access token contents, =
are out of scope of the core GNAP protocol.







<=
div class=3D"gmail_quote">
On Fri, Jul=
 24, 2020 at 11:10 AM Tom Jones <thomasclinganjones@gmail.com> wrote:
now that is interesti=
ng.
So that i can understand what you're saying.
the acce=
ss token that is issued (somehow) by the user to give the client access to =
rs resources, does not have claims?
boy am i in the wrong place.=
=C2=A0

<=
div>Peace ..tom


On Fri, Jul 24, 2020 at 10=
:50 AM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom, thanks for sharing.
<=
br>
I would consider the guardianship=C2=A0use case to be issuing=
=C2=A0an access token, not claims, as it is being used to access an RS.

In my view, we keep Claims in GNAP to be only about t=
he User, and the only consumer of the Claims is the Client the User is usin=
g. This keeps Claims from being overly complex.
=C2=A0
3D""=E1=90=A7

On Fri, Jul 24, 2020 at 10:32 AM Tom Jones =
<thoma=
sclinganjones@gmail.com> wrote:
Nat and I just had this discussion =
about claims & the claims aggregation spec.
An example about claims=
 that are not entirely about the user is the gurdian ship=C2=A0case.
<=
div>That case can be solved by creating a signed set if claims (which needs=
 a name) from the RO granting approval to the user to make a "ID Token=
" (whatever) from the as to the client to be passed to the RS.
my suggesting is that claim as not necessarily attributes and the data a=
bout the ro from the rs are distinct from the claims about the user from th=
e as.
I do not believe that claims aggregation=C2=A0is about clai=
ms (at least not often).
so then the data from. the ro would=C2=
=A0never be a claim, even tho it was identical=C2=A0in form and substance f=
rom the claim produced by the as.
Peace ..tom


=

On Fri, Ju=
l 24, 2020 at 10:25 AM Dick Hardt <dick.hardt@gmail.com> wrote:
In OpenID Connect=
 (OIDC), the Client can obtain Claims directly from the OP in an ID Token, =
or the Client can obtain Claims using an access token to call the UserInfo =
endpoint, a Protected Resource[1].

The Claims are about =
the User (not a RO).

In XAuth, I'm proposing t=
he Client may obtain bare claims from the GS directly in addition to the me=
chanisms in ODIC.

So I don't think we are chan=
ging the definition of Claim from how it has been used in OIDC, and I fail =
to see any reason to NOT use Claim.

Justin: you al=
lude to Claims being about a party other than the User. Would you provide a=
n example?

/Dick

[1]
UserInfo Endpoint
Protected Resource that, when presented with a=
n Access Token by the Client, returns authorized information about the End-=
User represented by the corresponding Authorization Grant. The UserInfo End=
point URL MUST use the https scheme and MAY contain port, path, and query p=
arameter components.


<=
br>
=E1=90=A7

On Fri, Jul 24, 2020 at 5:58 =
AM Justin Richer <j=
richer@mit.edu> wrote:
I want to focus on one aspect here:


=

A Claim is a well understood term in the field. We should use it. It i=
s still a Claim if it comes directly from the GS or from an RS.=C2=A0
=

I do not understand why a Resource release by an RS=
 shall be h to as a claim, even if the content of the Resource is an assert=
ion. It will lead to confusion. If we limit claims to information GS releas=
es into Token, User Info, and other objects it returns, this will help sepa=
rate responsibilities between GS and RS. As soon as RS services and informa=
tion, this is called a Resource, no matter the nature of the content of tha=
t information.

This is e=
xactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=E2=80=9D in t=
he way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could co=
me back through an RS =E2=80=94 but in the context of GNAP, that makes it a=
 resource. So we need a different word for data coming back directly from t=
he AS to the client. Sometimes it=E2=80=99s going to be about the user, and=
 that=E2=80=99s what we=E2=80=99re going to focus on here, but since you ca=
n also get information about the user from a resource we can=E2=80=99t just=
 call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the heart of a=
 lot of confusion in recent threads, as well as confusion about the scope o=
f the inclusion of identity in the GNAP protocol.

=
So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does, and=
 let=E2=80=99s find a way to differentiate between when an item, claim or o=
therwise,=C2=A0=C2=A0comes as part of a resource and when it comes back dir=
ectly. This is an important differentiating feature for GNAP.
Some straw man ideas, none of which I=E2=80=99m particularly in=
 love with:

=C2=A0- direct data
=C2=A0- =
properties
=C2=A0- details
=C2=A0- statements

The important thing here is that it=E2=80=99s not necessari=
ly :about: the RO, and that it is :not: in a resource.

=
Any other thoughts?

=C2=A0=E2=80=94 Justin






--000000000000547c6d05ab342145--


From nobody Fri Jul 24 11:32: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 065273A11A0 for ; Fri, 24 Jul 2020 11:31:44 -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 YQcUWDUNMWJW for ; Fri, 24 Jul 2020 11:31:39 -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 9F6823A11F1 for ; Fri, 24 Jul 2020 11:31:39 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id 95so7691870otw.10 for ; Fri, 24 Jul 2020 11:31: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=ERNnRS+lSC8jeSk36EjZtyxsPy+2g3T0U/l6pfNzon4=; b=ekNmJdkcZihqlRv40m8aGbvf5bw0uKgwsXqe3rdRn8CKAFD2UNUVSDfU/muT74xUVL JQ50ga5HFf5uAQfCXlMaMgulYbAvYgzDEITT5PJhOtkHPLYy5lgfVYCEoq4Q3DXgv6fw vhbEBchiFOw5pzTMpNRsPURqhgalavmZlP8SoXjy3CZ5/IgB/EtNWxHYASQCoDOns117 pQOaRlYnQRDbkEGdkCVMdZ/rU/J6UJEb731ZK9fSuBRXyl7GgLH8I7rn6OTIIYDCraRz hFmNJQiwVQbKZdSyziJ2yLKtCm8q4rNiSn+fMuYt8FlbzW6BROrUPG8c7cSkCHo4SNhf mdXA==
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=ERNnRS+lSC8jeSk36EjZtyxsPy+2g3T0U/l6pfNzon4=; b=J1InnK66i3aK/UAXmGemiOksycRY3pgCeJviid5aZpA/fR0+/THCz3ukS5SMVm9L1N JtaS/9Cy1fpA/+y9IR63JJxvMCRiT+hN+ogPOJedQKnu13UY/R1H82gdUfNuf0VNDFJT xggFdlsKgJyzArOufjg/XxjMEoH9pDl1W8vUNNiNJkS0+bhC4AM0vsxTKrg05ifJemIg FF3mVA1L7W2OEly94Z+lKtYZmW3pZLtmeYEJQFfP/QJunHYB2H81VTEby9k36YKEh6M1 dmVKa2iLSVA2O1lLDRAYvbDZFmntVu4PeyZLsAJJDc7Xlpuc/A0pnH82dNtHv1ZpRMNp kKBQ==
X-Gm-Message-State: AOAM533hwvcZPLh7dDmbeuEvbdcsuLHCNTXR6sMIuWpG3l1M+NNun6it AsDEXlO8iNtGnwZSoFSpZtfB9vyISPgDfMs+PWs=
X-Google-Smtp-Source: ABdhPJyCdEWuuVm9stRLpcXX27xQU5SGMVq+0CBLnE8O7UxSmg0Vp9WT3is9Jlb06CKD3nr3wuDZI3gqD+nSDYuEZdg=
X-Received: by 2002:a9d:66ca:: with SMTP id t10mr9733489otm.358.1595615498819;  Fri, 24 Jul 2020 11:31:38 -0700 (PDT)
MIME-Version: 1.0
References:                 
In-Reply-To: 
From: Tom Jones 
Date: Fri, 24 Jul 2020 11:31:27 -0700
Message-ID: 
To: Dick Hardt 
Cc: Justin Richer , Francis Pouatcha , txauth@ietf.org, Denis 
Content-Type: multipart/alternative; boundary="000000000000015daf05ab342fae"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 18:31:51 -0000

--000000000000015daf05ab342fae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

right - & i want the client to be the as, so i guess there is no need for
what you claim to be the purpose of GNAP in self-issed ids.
Since that is what i want, i am outta here.
Peace ..tom


On Fri, Jul 24, 2020 at 11:27 AM Dick Hardt  wrote:

> I'm not saying an access token cannot have claims. I'm saying what the
> Client communicates to the GS so that there are claims in an access token
> is out of scope for GNAP.
>
> Said another way, GNAP specifies a container used by the Client to reques=
t
> access tokens from the GS, and then presents those access tokens to the R=
S.
> The contents of the container in the Client request, and the access token
> contents, are out of scope of the core GNAP protocol.
>
>
>
>
>
>
>
> On Fri, Jul 24, 2020 at 11:10 AM Tom Jones 
> wrote:
>
>> now that is interesting.
>> So that i can understand what you're saying.
>> the access token that is issued (somehow) by the user to give the client
>> access to rs resources, does not have claims?
>> boy am i in the wrong place.
>>
>> Peace ..tom
>>
>>
>> On Fri, Jul 24, 2020 at 10:50 AM Dick Hardt  wrote=
:
>>
>>> Hi Tom, thanks for sharing.
>>>
>>> I would consider the guardianship use case to be issuing an access
>>> token, not claims, as it is being used to access an RS.
>>>
>>> In my view, we keep Claims in GNAP to be only about the User, and the
>>> only consumer of the Claims is the Client the User is using. This keeps
>>> Claims from being overly complex.
>>>
>>> =E1=90=A7
>>>
>>> On Fri, Jul 24, 2020 at 10:32 AM Tom Jones 
>>> wrote:
>>>
>>>> Nat and I just had this discussion about claims & the claims
>>>> aggregation spec.
>>>> An example about claims that are not entirely about the user is the
>>>> gurdian ship case.
>>>> That case can be solved by creating a signed set if claims (which need=
s
>>>> a name) from the RO granting approval to the user to make a "ID Token"
>>>> (whatever) from the as to the client to be passed to the RS.
>>>> my suggesting is that claim as not necessarily attributes and the data
>>>> about the ro from the rs are distinct from the claims about the user f=
rom
>>>> the as.
>>>> I do not believe that claims aggregation is about claims (at least not
>>>> often).
>>>> so then the data from. the ro would never be a claim, even tho it was
>>>> identical in form and substance from the claim produced by the as.
>>>> Peace ..tom
>>>>
>>>>
>>>> On Fri, Jul 24, 2020 at 10:25 AM Dick Hardt 
>>>> wrote:
>>>>
>>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from
>>>>> the OP in an ID Token, or the Client can obtain Claims using an acces=
s
>>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>>
>>>>> The Claims are about the User (not a RO).
>>>>>
>>>>> In XAuth, I'm proposing the Client may obtain bare claims from the GS
>>>>> directly in addition to the mechanisms in ODIC.
>>>>>
>>>>> So I don't think we are changing the definition of Claim from how it
>>>>> has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>>
>>>>> Justin: you allude to Claims being about a party other than the User.
>>>>> Would you provide an example?
>>>>>
>>>>> /Dick
>>>>>
>>>>> [1]
>>>>>
>>>>> UserInfo Endpoint
>>>>> Protected Resource that, when presented with an Access Token by the
>>>>> Client, returns authorized information about the End-User represented=
 by
>>>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST=
 use
>>>>> the https scheme and MAY contain port, path, and query parameter comp=
onents.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> =E1=90=A7
>>>>>
>>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote=
:
>>>>>
>>>>>> I want to focus on one aspect here:
>>>>>>
>>>>>>
>>>>>>> A Claim is a well understood term in the field. We should use it. I=
t
>>>>>>> is still a Claim if it comes directly from the GS or from an RS.
>>>>>>>
>>>>>> I do not understand why a Resource release by an RS shall be h to as
>>>>>> a claim, even if the content of the Resource is an assertion. It wil=
l lead
>>>>>> to confusion. If we limit claims to information GS releases into Tok=
en,
>>>>>> User Info, and other objects it returns, this will help separate
>>>>>> responsibilities between GS and RS. As soon as RS services and infor=
mation,
>>>>>> this is called a Resource, no matter the nature of the content of th=
at
>>>>>> information.
>>>>>>
>>>>>>
>>>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Ccla=
im=E2=80=9D in the way
>>>>>> that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could co=
me back through an RS =E2=80=94 but in
>>>>>> the context of GNAP, that makes it a resource. So we need a differen=
t word
>>>>>> for data coming back directly from the AS to the client. Sometimes i=
t=E2=80=99s
>>>>>> going to be about the user, and that=E2=80=99s what we=E2=80=99re go=
ing to focus on here,
>>>>>> but since you can also get information about the user from a resourc=
e we
>>>>>> can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this h=
as been at the heart of a lot
>>>>>> of confusion in recent threads, as well as confusion about the scope=
 of the
>>>>>> inclusion of identity in the GNAP protocol.
>>>>>>
>>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already do=
es, and let=E2=80=99s find a way
>>>>>> to differentiate between when an item, claim or otherwise,  comes as=
 part
>>>>>> of a resource and when it comes back directly. This is an important
>>>>>> differentiating feature for GNAP.
>>>>>>
>>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in love=
 with:
>>>>>>
>>>>>>  - direct data
>>>>>>  - properties
>>>>>>  - details
>>>>>>  - statements
>>>>>>
>>>>>> The important thing here is that it=E2=80=99s not necessarily :about=
: the RO,
>>>>>> and that it is :not: in a resource.
>>>>>>
>>>>>> Any other thoughts?
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>

--000000000000015daf05ab342fae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


right - & i want the client to be the as, so i guess t=
here is no need for what you claim to be the purpose of GNAP in self-issed=
=C2=A0ids.
Since that is what i want, i am outta here.
Peace ..tom


On Fri, Jul 24, 2020 at 11:27 AM Dick Hardt <dick.hardt@gmail.com> wrote:
I'm not saying an ac=
cess token cannot have claims. I'm saying what the Client communicates =
to the GS so that there are claims in an access token is out of scope for G=
NAP.

Said another way, GNAP specifies a container used b=
y the Client to request access tokens from the GS, and then presents those =
access tokens to the RS. The contents of the container in the Client reques=
t, and the access token contents, are out of scope of the core GNAP protoco=
l.







On Fri, Jul 24, 2020 at 11:10 AM Tom Jones <thomasclinganj=
ones@gmail.com> wrote:
now that is interesting.
So that i can u=
nderstand what you're saying.
the access token that is issued=
 (somehow) by the user to give the client access to rs resources, does not =
have claims?
boy am i in the wrong place.=C2=A0

Peace ..tom


On Fri, Jul 24, 2020 at 10:50 AM Dick Hardt <dick.hardt@gmail.co=
m> wrote:
Hi Tom, thanks for sharing.

I would co=
nsider the guardianship=C2=A0use case to be issuing=C2=A0an access token, n=
ot claims, as it is being used to access an RS.

In=
 my view, we keep Claims in GNAP to be only about the User, and the only co=
nsumer of the Claims is the Client the User is using. This keeps Claims fro=
m being overly complex.
=C2=A0
3D""=E1=90=
=A7

On Fri, Jul 24, 2020 at 10:32 AM Tom Jones <thomasclinganjones@gmail.co=
m> wrote:
Nat and I just had this discussion about claims & the=
 claims aggregation spec.
An example about claims that are not entirely=
 about the user is the gurdian ship=C2=A0case.
That case can be s=
olved by creating a signed set if claims (which needs a name) from the RO g=
ranting approval to the user to make a "ID Token" (whatever) from=
 the as to the client to be passed to the RS.
my suggesting is th=
at claim as not necessarily attributes and the data about the ro from the r=
s are distinct from the claims about the user from the as.
I do n=
ot believe that claims aggregation=C2=A0is about claims (at least not often=
).
so then the data from. the ro would=C2=A0never be a claim, eve=
n tho it was identical=C2=A0in form and substance from the claim produced b=
y the as.
Peac=
e ..tom


On Fri, Jul 24, 2020 at 10:25 AM D=
ick Hardt <dic=
k.hardt@gmail.com> wrote:
In OpenID Connect (OIDC), the Client can =
obtain Claims directly from the OP in an ID Token, or the Client can obtain=
 Claims using an access token to call the UserInfo endpoint, a Protected Re=
source[1].

The Claims are about the User (not a RO).

In XAuth, I'm proposing the Client may obtain bar=
e claims from the GS directly in addition to the mechanisms in ODIC.
<=
div>
So I don't think we are changing the definition of C=
laim from how it has been used in OIDC, and I fail to see any reason to NOT=
 use Claim.

Justin: you allude to Claims being abo=
ut a party other than the User. Would you provide an example?
/Dick

[1]
UserInfo Endpoint
=

Protected Resource that, when presented with an Access Token by the Cl=
ient, returns authorized information about the End-User represented by the =
corresponding Authorization Grant. The UserInfo Endpoint URL MUST use the h=
ttps scheme and MAY contain port, path, and query parameter components.



3D""=E1=90=A7

On Fri, Jul 24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> =
wrote:
I wa=
nt to focus on one aspect here:


A Claim is a well =
understood term in the field. We should use it. It is still a Claim if it c=
omes directly from the GS or from an RS.=C2=A0
I do not understand why a Resource release by an RS shall be h to as a cla=
im, even if the content of the Resource is an assertion. It will lead to co=
nfusion. If we limit claims to information GS releases into Token, User Inf=
o, and other objects it returns, this will help separate responsibilities b=
etween GS and RS. As soon as RS services and information, this is called a =
Resource, no matter the nature of the content of that information.

This is exactly why I don=E2=80=
=99t think we should use =E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=
=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back through an R=
S =E2=80=94 but in the context of GNAP, that makes it a resource. So we nee=
d a different word for data coming back directly from the AS to the client.=
 Sometimes it=E2=80=99s going to be about the user, and that=E2=80=99s what=
 we=E2=80=99re going to focus on here, but since you can also get informati=
on about the user from a resource we can=E2=80=99t just call it a =E2=80=9C=
claim=E2=80=9D. I think this has been at the heart of a lot of confusion in=
 recent threads, as well as confusion about the scope of the inclusion of i=
dentity in the GNAP protocol.

So let=E2=80=99s let=
 =E2=80=9Cclaim=E2=80=9D mean what it already does, and let=E2=80=99s find =
a way to differentiate between when an item, claim or otherwise,=C2=A0=C2=
=A0comes as part of a resource and when it comes back directly. This is an =
important differentiating feature for GNAP.

Some s=
traw man ideas, none of which I=E2=80=99m particularly in love with:
<=
div>
=C2=A0- direct data
=C2=A0- properties
=C2=A0- details
=C2=A0- statements

Th=
e important thing here is that it=E2=80=99s not necessarily :about: the RO,=
 and that it is :not: in a resource.

Any other thoughts=
?

=C2=A0=E2=80=94 Justin
<=
/div>








--000000000000015daf05ab342fae--


From nobody Fri Jul 24 11:46: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 9A12B3A041A for ; Fri, 24 Jul 2020 11:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 SONnVJuV2P05 for ; Fri, 24 Jul 2020 11:46:37 -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 3E8D23A03EA for ; Fri, 24 Jul 2020 11:46:36 -0700 (PDT)
Received: from [192.168.1.3] (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 06OIkVn4019872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Jul 2020 14:46:31 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_02656EBA-127C-440A-B310-694B7495E89E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 24 Jul 2020 14:46:30 -0400
In-Reply-To: 
Cc: Francis Pouatcha , txauth@ietf.org, Tom Jones , Denis 
To: Dick Hardt 
References:             
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 18:46:42 -0000

--Apple-Mail=_02656EBA-127C-440A-B310-694B7495E89E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m =
saying. I agree that =E2=80=9Cclaims=E2=80=9D are about the user, in =
this context*. But the AS could return other data directly to the client =
that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=
=80=9D by the classical definition. Also since =E2=80=9Cclaims=E2=80=9D =
can come back from places other than directly, then we shouldn=E2=80=99t =
call everything that comes back a =E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean what =
it already means and come up with a new word to mean =E2=80=9Cthings =
that come back directly from the AS=E2=80=9D. These aren=E2=80=99t meant =
to replace Francis=E2=80=99s more complete definitions, but to simplify:

Claims:
	- information about the user
	- can come back directly from the AS
	- can come back in a resource from the RS

Resource:
	- Returned from an RS
	- Protected by access token
	- Could contain claims about the user

Direct data (or some better name):
	- Returned directly from AS
	- Could contain claims about the user

I think the problem is that some people are using =E2=80=9Cclaims=E2=80=9D=
 to mean #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: =
It=E2=80=99s important to remember, when talking about OIDC, that an IdP =
in OIDC combines an AS and an RS into one entity for identity =
information. There can be other RS=E2=80=99s as well, and there usually =
are in the wild, but the one defined by OIDC is the UserInfo Endpoint. =
The fact that it returns user data doesn=E2=80=99t make it any less of =
an RS.

 =E2=80=94 Justin

* In the wider context of things like the information claims inside a =
JWT, the claims could be about literally anything, but that=E2=80=99s =
not what we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99=
s being used.


> On Jul 24, 2020, at 1:24 PM, Dick Hardt  wrote:
>=20
> In OpenID Connect (OIDC), the Client can obtain Claims directly from =
the OP in an ID Token, or the Client can obtain Claims using an access =
token to call the UserInfo endpoint, a Protected Resource[1].
>=20
> The Claims are about the User (not a RO).
>=20
> In XAuth, I'm proposing the Client may obtain bare claims from the GS =
directly in addition to the mechanisms in ODIC.
>=20
> So I don't think we are changing the definition of Claim from how it =
has been used in OIDC, and I fail to see any reason to NOT use Claim.
>=20
> Justin: you allude to Claims being about a party other than the User. =
Would you provide an example?
>=20
> /Dick
>=20
> [1]
> UserInfo Endpoint
> Protected Resource that, when presented with an Access Token by the =
Client, returns authorized information about the End-User represented by =
the corresponding Authorization Grant. The UserInfo Endpoint URL MUST =
use the https scheme and MAY contain port, path, and query parameter =
components.
>=20
>=20
>=20
> =E1=90=A7
>=20
> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer > wrote:
> I want to focus on one aspect here:
>=20
>>=20
>> A Claim is a well understood term in the field. We should use it. It =
is still a Claim if it comes directly from the GS or from an RS.=20
>> I do not understand why a Resource release by an RS shall be h to as =
a claim, even if the content of the Resource is an assertion. It will =
lead to confusion. If we limit claims to information GS releases into =
Token, User Info, and other objects it returns, this will help separate =
responsibilities between GS and RS. As soon as RS services and =
information, this is called a Resource, no matter the nature of the =
content of that information.
>=20
> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=E2=
=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=
=9D could come back through an RS =E2=80=94 but in the context of GNAP, =
that makes it a resource. So we need a different word for data coming =
back directly from the AS to the client. Sometimes it=E2=80=99s going to =
be about the user, and that=E2=80=99s what we=E2=80=99re going to focus =
on here, but since you can also get information about the user from a =
resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I =
think this has been at the heart of a lot of confusion in recent =
threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.
>=20
> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already =
does, and let=E2=80=99s find a way to differentiate between when an =
item, claim or otherwise,  comes as part of a resource and when it comes =
back directly. This is an important differentiating feature for GNAP.
>=20
> Some straw man ideas, none of which I=E2=80=99m particularly in love =
with:
>=20
>  - direct data
>  - properties
>  - details
>  - statements
>=20
> The important thing here is that it=E2=80=99s not necessarily :about: =
the RO, and that it is :not: in a resource.
>=20
> Any other thoughts?
>=20
>  =E2=80=94 Justin


--Apple-Mail=_02656EBA-127C-440A-B310-694B7495E89E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Dick:=
 No, I think you=E2=80=99re misunderstanding what I=E2=80=99m saying. I =
agree that =E2=80=9Cclaims=E2=80=9D are about the user, in this =
context*. But the AS could return other data directly to the client that =
isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=80=9D=
 by the classical definition. Also since =E2=80=9Cclaims=E2=80=9D can =
come back from places other than directly, then we shouldn=E2=80=99t =
call everything that comes back a =E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m arguing that =
we keep =E2=80=9Cclaims=E2=80=9D to mean what it already means and come =
up with a new word to mean =E2=80=9Cthings that come back directly from =
the AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s =
more complete definitions, but to simplify:

Claims:
	- =
information about the user
	- can =
come back directly from the AS
	- can =
come back in a resource from the RS

Resource:
	- =
Returned from an RS
	- Protected by access =
token
	- Could contain claims about the =
user

Direct =
data (or some better name):
	- =
Returned directly from AS
	- Could =
contain claims about the user

I think the problem is that some people =
are using =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. =
It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s important to =
remember, when talking about OIDC, that an IdP in OIDC combines an AS =
and an RS into one entity for identity information. There can be other =
RS=E2=80=99s as well, and there usually are in the wild, but the one =
defined by OIDC is the UserInfo Endpoint. The fact that it returns user =
data doesn=E2=80=99t make it any less of an RS.

 =E2=80=94 Justin

* In the wider context =
of things like the information claims inside a JWT, the claims could be =
about literally anything, but that=E2=80=99s not what we=E2=80=99re =
discussing here and it=E2=80=99s not how it=E2=80=99s being =
used.


On Jul 24, 2020, at 1:24 PM, =
Dick Hardt <dick.hardt@gmail.com> wrote:

In OpenID Connect (OIDC), the =
Client can obtain Claims directly from the OP in an ID Token, or the =
Client can obtain Claims using an access token to call the UserInfo =
endpoint, a Protected Resource[1].

The Claims are about the User (not a =
RO).

In XAuth, =
I'm proposing the Client may obtain bare claims from the GS directly in =
addition to the mechanisms in ODIC.

So I don't think we are changing the =
definition of Claim from how it has been used in OIDC, and I fail to see =
any reason to NOT use Claim.

Justin: you allude to Claims being =
about a party other than the User. Would you provide an =
example?

/Dick

[1]
UserInfo =
Endpoint
Protected Resource that, when presented =
with an Access Token by the Client, returns authorized information about =
the End-User represented by the corresponding Authorization Grant. The =
UserInfo Endpoint URL MUST use the https scheme and MAY contain port, =
path, and query parameter components.



3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspect here:


A Claim is a well =
understood term in the field. We should use it. It is still a Claim if =
it comes directly from the GS or from an =
RS. 
I do not understand =
why a Resource release by an RS shall be h to as a claim, even if the =
content of the Resource is an assertion. It will lead to confusion. If =
we limit claims to information GS releases into Token, User Info, and =
other objects it returns, this will help separate responsibilities =
between GS and RS. As soon as RS services and information, this is =
called a Resource, no matter the nature of the content of that =
information.

This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =
=E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in =
the context of GNAP, that makes it a resource. So we need a different =
word for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s going to be about the user, and that=E2=80=99s what we=E2=80=99=
re going to focus on here, but since you can also get information about =
the user from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=
=80=9D. I think this has been at the heart of a lot of confusion in =
recent threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=
=9D mean what it already does, and let=E2=80=99s find a way to =
differentiate between when an item, claim or otherwise,  comes =
as part of a resource and when it comes back directly. This is an =
important differentiating feature for GNAP.

Some straw man ideas, none of which =
I=E2=80=99m particularly in love with:

 - direct data
 - properties
 - =
details
 - statements

The important thing here is that it=E2=80=
=99s not necessarily :about: the RO, and that it is :not: in a =
resource.

Any other =
thoughts?

 =E2=80=94 Justin



=

--Apple-Mail=_02656EBA-127C-440A-B310-694B7495E89E--


From nobody Fri Jul 24 12:05: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 0BD773A090E for ; Fri, 24 Jul 2020 12:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level: 
X-Spam-Status: No, score=-1.619 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.267, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=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 MCtIRHX92qzi for ; Fri, 24 Jul 2020 12:05:17 -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 2185E3A091C for ; Fri, 24 Jul 2020 12:04:33 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d67 with ME id 774X230012bcEcA0374X7n; Fri, 24 Jul 2020 21:04:32 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Fri, 24 Jul 2020 21:04:32 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt 
Cc: txauth@ietf.org
References:         <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>     
From: Denis 
Message-ID: 
Date: Fri, 24 Jul 2020 21:04:33 +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="------------9B01394042B761375535B355"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 24 Jul 2020 19:05:21 -0000

This is a multi-part message in MIME format.
--------------9B01394042B761375535B355
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Dick,

In order to send back a quick reply tonight, I will only respond to one 
of your questions:

    [Denis] How would be the data flow when access tokens from two GSs
    are needed by a RS ?

    [Dick] I don't know of a use case where two tokens would be needed
    by an RS. Would you elaborate?

I already described on the list the case of a student registering to a 
new University.

First, the student connects to the RS from the new University and opens 
an account
(at this time the student is using a pseudo and a private key to 
authenticate). He fills some forms
and indicate its citizenship, his home address and his graduation in his 
current university.

When he is finished, he indicates that he wants to perform a 
Registration operation.

 From the information gathered in the forms, the RS informs the client 
that it needs two access tokens:

  * one to demonstrate that his name and current home address are
    correct,and
  * another one to demonstrate that he got a graduation from its current
    University.

Depending upon the information captured in the forms, the RS also 
indicates which ASs/GSs are acceptable
and which kind of attributes are requested.

The user consent and choice is performed by the client and once approved 
by the student, two access tokens are separately requested.
Finally, two access tokens are presented to the RS while invoking a 
Registration operation.

Note that the start of the story is to open an account, e.g. using FIDO. 
The needs of the RS are only disclosed to the student once he has filled 
some forms
and indicated that he wanted to perform a Registration operation. Thus, 
the needs that are revealed by the RS are dependant both upon the operation
that the student is willing to perform and the information collected in 
the forms.

Denis

> Hi Denis, comments inserted ...
>
> On Fri, Jul 24, 2020 at 9:08 AM Denis  > wrote:
>
>     Hi Dick,
>
>     draft-hardt-xauth-protocol-13 describes a solution without clearly
>     stating what the problem(s) to be solved is/are.
>
>
> I agree that the problem description is not as crisp as I would like 
> it to be. A challenge is that there is a broad spectrum of use cases 
> solved by OAuth 2, and OpenID Connect, as well as the new use cases 
> that are solved by GNAP.
>
> That is why I am suggesting we gather some use cases so we have a 
> common understanding of the problems that are in scope.
>
>
>     At the moment, draft-hardt-xauth-protocol-13 includes a single
>     figure on page 4 and from previous discussions I understood that
>     it is no more up-to-date since the first data flow is now a
>     contact with a RS. The reason(s) for the GS to contact a RO has
>     still not
>     been explained (since the inputs and outputs are not described).
>     The discovery information made available at various steps at the RS
>     is not described.
>
>
> I have made no updates as we are in a quiet period prior to the WG 
> meeting next week when documents cannot be updated.
>
>
>     Figure 4 shows only a single RS. Is the relaying of one operation
>     by that RS to a second RS in the scope of this document ?
>     If yes, how is it handled ?
>
>
> I view that as an advanced use case that would be covered in a 
> separate document.
>
>
>     Figure 4 shows only a single GS. How would be the data flow when
>     access tokens from two GSs are needed by a RS ?
>
>
> I don't know of a use case where two tokens would be needed by an RS. 
> Would you elaborate?
> The RS being able to accept tokens from two different GSes is covered, 
> but the Client is only using a token from one GS at a time.
>
>
>     What we need first is not a set of "use cases" but a clear model
>     with a data flows and a list of its properties/characteristics.
>
>
> I disagree. The use cases describe the problems we are looking to 
> solve. The data flows are part of the solution. For example, from my 
> understanding of your use case, you don't want the GS to have 
> visibility into the User's activity. Am I correct that this is one of 
> your requirements for your use case?
>
>     Then after, we can understand much better which use cases can/will
>     be supported. For example, shall a RS (or its RO) have
>     prior relationships with the GS ? What is the
>     difference/implications when it has or it hasn't ?
>
>     In order to have a fair comparison, we should try to list model
>     properties/characteristics.
>
>     At the moment, the model I have described including the data flows
>     is clear. The discovery information made available by a RS is clear.
>     I have not listed all its properties/characteristics of that
>     model, but I am pretty sure that you already have a flavour of it.
>
>     In the mean time, it would be nice if you could show using two
>     figures:
>
>       * the case of the relaying of one operation by one RS to a
>         second RS (if it is in the scope of your document),
>       * the case where access tokens from two GSs are needed by one RS
>         (if it is in the scope of your document).
>
>
> See above
>
>      *
>
>
>     Denis
>
>>     Hi Denis
>>
>>     I think it would be useful to take a step back and for you to
>>     describe your use case.
>>     After that, we can explore the different ways that your use case
>>     can be addressed.
>>
>>     Looking at your previous communication, it describes the
>>     solution, and the justification,
>>     but it is not clear what use cases you are needing to solve.
>>
>>     /Dick
>>
>>
>>     ᐧ
>>
>>     On Wed, Jul 22, 2020 at 9:34 AM Denis >     > wrote:
>>
>>         Hello Dick,
>>
>>         I have identified the reason of the major difference between
>>         our two approaches.
>>
>>         Access control may be performed using either ACLs (Access
>>         Control Lists) or Capabilities.
>>
>>         _Note _: a capability identifies a resource and an allowed
>>         operation that can be performed on that resource.
>>
>>         You are advocating a Capabilities approach while I am
>>         advocating an ACL approach.
>>
>>         The capabilities approach allows the GS to trace every
>>         operation performed by the users on any RS known by a GS.
>>         The management of these capabilities is made via the GS or at
>>         the GS by the various ROs. If the management is made
>>         via the GS, then a trusted communication channel needs to be
>>         established with every RO. If the management is made
>>         at the GS, then an authentication mechanism needs to be
>>         established with every RO. In the last case, the GS has the
>>         ability to know all the capabilities of the users whether
>>         they are used or not. The less that can be said is that this
>>         model
>>         is not privacy friendly.
>>
>>         With the ACL approach, a RO directly manages an ACL placed in
>>         front of each RS. The AccessControl Decision Function
>>         (ADF) at the RS is able to keep track from prior decisions.
>>         The GS is kept ignorant of the content of these ACLs and only
>>         delivers to its clients attributes that are placed into
>>         access tokens. Such a model may be privacy friendly.
>>
>>         Other comments are between the lines prefixed with [Denis].
>>
>>>
>>>         On Tue, Jul 21, 2020 at 11:26 AM Denis >>         > wrote:
>>>
>>>             Hello Dick,
>>>
>>>             Thank you for your feedback. Comments are between the lines.
>>>
>>>>             comments inserted ...
>>>>
>>>>             On Tue, Jul 21, 2020 at 6:03 AM Denis
>>>>             > wrote:
>>>>
>>>>                 Hello Dick,
>>>>
>>>>                 I duplicate the most important comment at the
>>>>                 beginning of this email:
>>>>
>>>>                     You are considering using an access control
>>>>                     model to build a**workflow model.
>>>>                     **
>>>>                     While it may be interesting to define a
>>>>                     workflow model, this should be considered
>>>>                     as a separate and different work item.
>>>>
>>>>                 See the other comments between the lines.
>>>>
>>>>>                 On Mon, Jul 20, 2020 at 2:05 AM Denis
>>>>>                 >
>>>>>                 wrote:
>>>>>
>>>>>                     Hi Dick,
>>>>>
>>>>>>                     On Fri, Jul 17, 2020 at 9:21 AM Denis
>>>>>>                     >>>>>                     > wrote:
>>>>>>
>>>>>>                         Hello Francis and Dick,
>>>>>>
>>>>>>                         The good news first: we are making some
>>>>>>                         progress. We are now close to an
>>>>>>                         agreement with steps (1) up to (3),
>>>>>>                         ... except that the place where the user
>>>>>>                         consent is captured is not
>>>>>>                         mentioned/indicated.
>>>>>>
>>>>>
>>>>>                     This major question which is currently left
>>>>>                     unanswered is where, when and how the user
>>>>>                     consent is captured.
>>>>>
>>>>>
>>>>>                 When is covered, per the sequence. How and where
>>>>>                 are out of scope of what I drafted.
>>>>
>>>>                 It is clear that the "User consent and choice" is
>>>>                 not currently addressed in the draft, but it should.
>>>>                 The support of the "User consent and choice" has
>>>>                 strong implications not only in the sequences of
>>>>                 the exchanges
>>>>                 but also by which entity it should be performed.
>>>>
>>>>             "consent" is in the latest draft 7 times.
>>>
>>>             "Consent" is present 5 times. The User consent is
>>>             different from the RO consent (when/if it is required).
>>>
>>>                 The server acquires consent and authorization from
>>>                 the user *and/**or resource owner **if required.*
>>>
>>>                 User consent is *often required* at the GS. GNAP
>>>                 enables a Client and  GS to negotiate the
>>>                 interaction mode for the GS to obtain consent.
>>>
>>>                 The GS *may *require explicit consent from the RO or
>>>                 User to provide these to the Client.
>>>
>>>             The User consent is not an alternative to the RO
>>>             consent. So using "and/or" in the first sentence is
>>>             incorrect.
>>>
>>>
>>>         My language is sloppy there. Consent is always from the RO.
>>>         The User may be the RO.
>>
>>         [Denis] No. Once again: The "/User consent/" is different
>>         from what you call the "/RO consent/" (when/if it is required).
>>         The "RO consent" is not in fact a consent but the release of
>>         a capability to a client by one of the many R0s with which
>>         the GS has relationships.
>>
>>>             Since the second sentence is using the wording "often
>>>             required" there is no requirement to get the User consent.
>>>
>>>         User consent may not be required. There may not be a User.
>>>         The consent may have been gathered previously.
>>
>>         [Denis] In order to follow the privacy principles, a "User
>>         consent" phase is required. The User is a natural person.
>>         A Client is called either by a User (i.e. a natural person)
>>         or by a Client application.
>>
>>>             The second sentence does not consider the possibility to
>>>             get the User consent in a place different from the GS.
>>>
>>>         Agreed. But we do agree that the GS gets the consent, either
>>>         directly from the RO, or from the Client (in your example).
>>
>>         [Denis] No. I disagree. In an ACL based systems, the GS does
>>         not need to ask or receive any consent.
>>         The client selects the set of attributes that it wants to be
>>         inserted into an access token.
>>         If the GS has the requested attributes, then it provides
>>         them, otherwise it returns an error to the Client.
>>
>>>             IMO, the User consent should be captured by the Client,
>>>             i.e. not by the GS.
>>>             The information used to obtain the User consent should
>>>             be standardized (... and it can be standardized).
>>>
>>>>             I think the abstract sequence as proposed by Francis is
>>>>             a great addition, and would clarify where consent is in
>>>>             the sequence.
>>>
>>>             The current sketch does not illustrate the place the
>>>             User Consent is captured, in particular by the Client.
>>>
>>>         It is an abstraction. The GS receives the consent. How
>>>         consent is gathered is a detail that is dependent on the use
>>>         case.
>>
>>         [Denis] I really wonder whether there is really a "consent"
>>         to be received by the GS in both cases (i.e. ACLs or
>>         Capabilities).
>>
>>           * For ACLs, the consent needs to be done by the Client.
>>           * For Capabilities, the current description is not clear
>>             since the inputs and the outputs for this "consent" phase
>>             are not currently described in the draft.
>>
>>>>>                     Another important point to consider and to
>>>>>                     explain is related to the assurances that the
>>>>>                     user can obtain about
>>>>>                     the respect of his choices. This point is
>>>>>                     currently left unanswered in
>>>>>                     draft-hardt-xauth-protocol-13.
>>>>>
>>>>                 This point is equally important: such assurance can
>>>>                 only be obtained if the access token returned to
>>>>                 the client
>>>>                 is not considered to be opaque to the client. This
>>>>                 is a necessary condition but not the single condition:
>>>>                 the Client must also be in a position to
>>>>                 capture/memorize the "User consent and choice" of
>>>>                 the user in order to be able
>>>>                 to verify it afterwards using the content of the
>>>>                 access token(s).
>>>>
>>>>
>>>>             We disagree on this being a requirement for all use
>>>>             cases. It may be in some.
>>>
>>>             OK. Then this means that there will be no sentence in
>>>             the draft such as :
>>>             "access tokens returned to the client are not considered
>>>             to be opaque to the client".
>>>
>>>
>>>         For OAuth use cases, which GNAP supports, the access token
>>>         is opaque to the Client. As you have noted, there are use
>>>         cases where the access token is NOT opaque.
>>
>>         [Denis] Wait a second. There is no requirement to support all
>>         OAuth use cases.
>>         I believe that there is a requirement to support OAuth 2.0
>>         ASs, while the clients may be different
>>         and hence GNAP clients do not need to inherit of the
>>         limitations of OAuth 2.0 clients.
>>
>>>>>
>>>>>>                         If a RO needs to be involved and since a
>>>>>>                         RO is directly associated with a RS, why
>>>>>>                         can't it be directly queried
>>>>>>                         by the appropriate RS after step (2) or
>>>>>>                         later on ?
>>>>>>
>>>>>>
>>>>>>                     Good question. Perhaps you can expand on a
>>>>>>                     use case where that would be useful?
>>>>>
>>>>>                     Before I expand, would you be able to explain
>>>>>                     first under which circumstances a RO needs to
>>>>>                     be queried by a GS ?
>>>>>                     How can the GS identify which RO to query ?
>>>>>
>>>>>                 If the User is the RO, then the GS knows who to
>>>>>                 query.
>>>>
>>>>                 I still have difficulties to understand what you
>>>>                 mean here.
>>>>                 How could a GS know that "the User is the RO" ?  If
>>>>                 "the User is the RO", why does the GS needs to
>>>>                 query the User ?
>>>>
>>>>
>>>>             To get consent?
>>>
>>>             To get a "RO consent" to himself ???
>>>
>>>
>>>         The GS needs consent from the RO. If the RO is the User,
>>>         then consent from the RO is equivalent to consent from the User.
>>
>>         [Denis] See above.
>>
>>>
>>>>>                 If the RO is a separate entity, then the GS knows
>>>>>                 the RO from the RS being queried.
>>>>
>>>>                  ... and this gives the ability for the GS to
>>>>                 log/trace all the RSs accessed by a given User and
>>>>                 at which instant of time the access token has been
>>>>                 granted.
>>>>
>>>>>                 An example is a user would like access to an
>>>>>                 enterprise asset where a workflow is started to
>>>>>                 gain approval, and an administrator or manager
>>>>>                 provides consent.
>>>>
>>>>                 Thanks for this example. I finally understand what
>>>>                 you have in mind: you are considering using an
>>>>                 access control model to build a *workflow model*.
>>>>                 While it may be interesting to define a workflow
>>>>                 model, this should be considered as a *separate and
>>>>                 different work item*.
>>>>
>>>>
>>>>             The actual workflow is out of scope.
>>>
>>>             I am glad you agree with this. But this means that your
>>>             example was not appropriate to illustrate your point.
>>>
>>>
>>>         It illustrates a use case where the RO and User are not the
>>>         same party, and why the GS needs to query the RO, which was
>>>         your question if I understood it correctly.
>>
>>         [Denis] Since the inputs and the outputs for this "RO
>>         consent" phase are not currently described in the draft, the
>>         point is still unsolved.
>>
>>>             As soon as there is a RO consent obtained at the GS, the
>>>             major problem is that the GS is able to act as Big Brother.
>>>             If a RO consent is performed at the RS, then the GS will
>>>             not know who the RS is: it is then unable to act as Big
>>>             Brother,
>>>             even if it would enjoy to play that role.
>>>
>>>         In an enterprise use case, the GS's knowledge of who is
>>>         accessing which RS is a feature.
>>
>>         Do you mean that it is "normal" in an enterprise that a
>>         single point of control is able to trace all their actions ?
>>         From a security point of view, a single point of failure will
>>         have dramatic consequences.
>>
>>>         In your use cases, it seems that the RO is the User.
>>
>>         I do hope that you have finally understood that, in my use
>>         case, the RO is **not** the User.
>>
>>>         The GS knows the User is wanting to let a Client access
>>>         something. If the access token is generic, and could be
>>>         presented to any RS that provides a standardized function,
>>>         then the GS does not know which RS is being accessed by a
>>>         Client for the User. This seems to meet your privacy
>>>         objectives. If not, what is wrong?
>>
>>         For security reasons, an access token needs to be targeted
>>         (which does not necessarily mean that an identifier of the RS
>>         shall be included into the access token).
>>
>>>>             if the admin grants access, then the access granted to
>>>>             the client changes.
>>>>
>>>>                 The model you propose may be suited for an
>>>>                 enterprise environment but is not scalable over the
>>>>                 Internet.
>>>>
>>>>             It is one of the use cases we are working to address.
>>>>
>>>>                 What is needed is an access control model usable
>>>>                 over the Internet with millions of RSs and
>>>>                 thousands of ASs/GSs.
>>>>
>>>>             I agree the model should also scale to internet scale.
>>>
>>>             Fine. Another point on which we are in agreement.
>>>
>>>             The model can scale to the Internet based on the
>>>             following assumptions:
>>>
>>>                 The flow starts with the steps (1) to (4) as
>>>                 illustrated by Francis, i.e. the flow starts with a
>>>                 contact with a RS.
>>>
>>>             *+----+  +------+  +---+  +---+  +---+
>>>             |User|  |Client|  |RS |  |GS |  |RO |
>>>             +----+  +------+  +---+  +-+-+  +-+-+
>>>               |(1) Service Request     |  |
>>>               |-------->|       |      |      |
>>>               |         |(2) Service Intent   |
>>>               |         |------>|      |      |
>>>               |         |(3) AuthZ Challenge  |
>>>               |         |<------|      |      |
>>>               |         |(4) AuthZ Request  |
>>>               |         |------------->|      |*
>>>
>>>             The GS/AS does not need to have any prior relationship
>>>             with ROs and/or RSs.
>>>
>>>             Furthermore, it is possible to prevent the GS to act as
>>>             Big Brother when the identity of the RS is not disclosed
>>>             to the GS.
>>>
>>>
>>>         What happens after (4) above?
>>
>>         [Denis] The key point is that we first need to agree on the
>>         first four exchanges. Do we ?
>>
>>         The fifth exchange is different whether ACLs or Capabilities
>>         are being used.
>>
>>>>>>                         Which information is supposed to be
>>>>>>                         presented to the RO ?
>>>>>>                         Which information is supposed to be
>>>>>>                         returned by the RO ?
>>>>>>
>>>>>>
>>>>>>                     Just like how the user authenticates to an
>>>>>>                     AS, how the AS and RO communicate is out of
>>>>>>                     scope.
>>>>>
>>>>>                     At the moment, the usefulness of a dialogue
>>>>>                     between a GS and a RO has not been explained,
>>>>>                     nor demonstrated.
>>>>>                     The question is about the functionality of
>>>>>                     that dialogue in terms of input and output
>>>>>                     information (and not about
>>>>>                     the design of a protocol or of a user
>>>>>                     interface). Anyway, AFAIU a dialogue between a
>>>>>                     GS and a RO is optional.
>>>>>
>>>>>
>>>>>                 See enterprise example above.
>>>>
>>>>                 It is not an access control example, but a workflow
>>>>                 example.
>>>>
>>>>                 Access control has been defined a long time ago and
>>>>                 the last edition of the model has been confirmed in
>>>>                 year 1996: ISO/IEC 10181-3: 1996.
>>>>                 "Information technology — Open Systems
>>>>                 Interconnection — Security frameworks for open
>>>>                 systems: Access control framework — Part 3".
>>>>
>>>>                 Two major functions have ben defined: an
>>>>                 AccessControl Enforcement Function (AEF) and an
>>>>                 AccessControl Decision Function(ADF).
>>>>
>>>>                     AccessControl Enforcement Function (AEF):
>>>>                     A specialized function that is part of the
>>>>                     access path between an initiator and a target
>>>>                     on each access request and enforces the
>>>>                     decision made by the ADF.
>>>>
>>>>                     AccessControl Decision Function (ADF) :
>>>>                     A specialized function that makes access
>>>>                     control decisions by applying access control
>>>>                     policy rules to an access request, ADI (of
>>>>                     initiators, targets, access requests,
>>>>                     or that retained from prior decisions), and the
>>>>                     context in which the access request is made.
>>>>
>>>>                 The role of the RO is to define the "access control
>>>>                 policy rules" at the RS according to thecontext in
>>>>                 which the access request is made.
>>>>
>>>>             I'm pretty familiar with access control systems. :)
>>>>
>>>>             I would say that the access control is happening at the
>>>>             RS. The client presents a token when accessing an API.
>>>>             The RS uses the token, and any policy required, to make
>>>>             an access decision.
>>>
>>>             Fine. It looks like we are in agreement. Unfortunately,
>>>             this is not the case just below.
>>>
>>>>             Here is flow:
>>>>
>>>>             1) The Client requests access to an RS from the GS.
>>>
>>>             No. We are no more in agreement. This is different from
>>>             the flow drawn by Francis.
>>>
>>>         My bad. Typo. I meant RO.
>>>
>>>>             2) The GS queries the RS if access should be granted.
>>>
>>>              No. The GS should not be forced to have a flow with the RS.
>>>
>>>         Same mistake as above, I meant RO.
>>>
>>>>             3) If access is granted, the GS creates an access token
>>>>             representing the granted access, and returns it to the
>>>>             Client.
>>>
>>>             This model is by no way conformant to ISO/IEC 10181-3: 1996
>>>
>>>         I'm unclear on why, or why it is even relevant.
>>>
>>>>             4) The Client presents the access token to the RS to
>>>>             show it has been granted access.
>>>
>>>             No. The client presents a token when accessing an API.
>>>             The RS uses the token, and any policy required, to make
>>>             an access decision.
>>>             The token never contains an information like "Please
>>>             grant an access to the holder of this token".
>>>
>>>         Let me provide more clarity in the sentence:
>>>
>>>         The Client presents the access token to the RS, to show the
>>>         RS that the Client has been granted access to a resource at
>>>         the RS by the GS.
>>
>>         [Denis] This time, please consider both the ACLs approach and
>>         the Capabilities approach.
>>
>>>>             A couple advantages of this model:
>>>>             - that the RS does not need to know much, if anything
>>>>             about the Client.
>>>>             - the access token MAY be self contained so that the
>>>>             Client does not need to query the GS on each access.
>>>
>>>             There are so many disadvantages that I will not list them.
>>>
>>>         Darn: I clearly was not firing on all cylinders when I typed
>>>         this out. Let me correct:
>>>
>>>>         - the access token MAY be self contained so that the RS
>>>>         does not need to query the GS on each access to the RS by
>>>>         the Client.
>>
>>         [Denis] A few comments in the case of a capability approach:
>>
>>             - for each GS, the RS needs to locally manage which
>>             operation(s) is/are allowed to it.
>>
>>             - the GS needs to establish a trusted communication
>>             channel or an authentication mechanism with each RO
>>                (which is associated with an explicit RS identifier).
>>
>>             - the GS could play the role of the RO and hence be in a
>>             position to issue any capability for any RS (without a
>>             "RO consent").
>>
>>                The target of an attack will clearly be the GS.
>>
>>>>             I would not say that GNAP is an access control
>>>>             protocol, as how the RS uses the token to determine
>>>>             access is out of scope.
>>>
>>>             This is where we have a major discrepancy: how the RS
>>>             uses the token to determine access is *within* the scope.
>>>
>>         [Denis] Do you agree or disagree ?
>>>
>>>             The RS announces in advance to the client what it needs
>>>             so that the client can perform a a given operation and
>>>             if the client supplies the requested attributes
>>>             obtained from some GS/AS(s) trusted by the RS, then
>>>             access to that RS is granted by the RS. If the RS cannot
>>>             perform the requested operation on its own,
>>>             then the client should be informed about some requested
>>>             attributes that need to be obtained from some GS/AS(s)
>>>             trusted by the next RS(s) in a chain
>>>             for subsequent operations. The User consent should also
>>>             be obtained before performing the chaining operation.
>>>
>>>             Chaining operations between RSs over the Internet is
>>>             within the scope (... and may be achieved).
>>>
>>         [Denis] Do you agree or disagree ?
>>
>>         Denis
>>
>>>>>>                     For many use cases, the User is the RO, and
>>>>>>                     the interaction is through a user interface,
>>>>>>                     not a machine protocol.
>>>>>
>>>>>                     Wait a second. You wrote "the User is the RO".
>>>>>                     The User is attempting to make an access to a
>>>>>                     RS by using a Client.
>>>>>                     _That_ User is not the RO of the RS.
>>>>>
>>>>>                 The user being the RO is the initial use case for
>>>>>                 OAuth.
>>>>
>>>>                 OAuth 2.0 is no more mandating such a case.
>>>>
>>>>
>>>>             I don't know what you mean by that.
>>>
>>>             Copy and paste from draft-ietf-oauth-security-topics:
>>>
>>>                 OAuth initially assumed a static relationship
>>>                 between client, authorization server and resource
>>>                 servers.  (...)
>>>                 With the increasing adoption of OAuth, this simple
>>>                 model dissolved and, in several scenarios, was replaced
>>>                 by a dynamic establishment of the relationship
>>>                 between clients on one side and the authorization and
>>>                 resource servers of a particular deployment on the
>>>                 other side.
>>>
>>>                 This way, the same client could be used to access
>>>                 services of different providers (in case of standard
>>>                 APIs,
>>>                 such as e-mail or OpenID Connect) or serve as a
>>>                 frontend to a particular tenant in a multi-tenancy
>>>                 environment.
>>>
>>>
>>>         This sentence does not mention the RO or the Client. I'm
>>>         confused what we are talking about
>>>
>>>>>                 A client application would like access to the
>>>>>                 user's photos at a photo sharing site. The
>>>>>                 resource is the user's photos. The user is the
>>>>>                 owner of that resource.
>>>>
>>>>                 If the user has already pre established the access
>>>>                 control policy rules so that it can access to his
>>>>                 own photos
>>>>                 then he does not need to grant in real time any
>>>>                 additional authorization.
>>>>
>>>>             I don't understand what you are trying to say. The
>>>>             photo sharing example was a driving use case for the
>>>>             creation of OAuth.
>>>
>>>             We would need to revisit the original scenario and
>>>             consider if it can be addressed in a different way than
>>>             the original way.
>>>
>>>         The use case is the same. Is there a different solution you
>>>         are proposing?
>>
>>
>>         -- 
>>         Txauth mailing list
>>         Txauth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/txauth
>>
>
>     -- 
>     Txauth mailing list
>     Txauth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/txauth
>
> ᐧ



--------------9B01394042B761375535B355
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Dick,

      

    

    
In order to send back a quick reply
      tonight, I will only respond to one of your questions:

    

      
 [Denis] How would be the data flow when access tokens
        from two GSs are needed by a RS ?

        


        

        
[Dick] I don't know of a use case where two tokens would be
          needed by an RS. Would you elaborate?

      

      
I already described on the list the case of a student
        registering to a new University.

      
 

      

      
First, the student connects to the RS from the new University
        and opens an account 

        (at this time the student is using a pseudo and a private key to
        authenticate). He fills some forms 

        and indicate its citizenship, his home address and his
        graduation in his current university. 

        

        When he is finished, he indicates that he wants to perform a
        Registration operation.

      


      

      
From the information gathered in the forms, the RS informs
        the client that it needs two access tokens:

      
    
        
  • one to demonstrate that his name and current home address
          are correct,and
    • 
        
  • another one to demonstrate that he got a graduation from its
          current University.
    • 
      

      
Depending upon the information captured in the forms, the RS
        also indicates which ASs/GSs are acceptable 

        and which kind of attributes are requested.

      
 

      

      
The user consent and choice is performed by the client and
        once approved by the student, two access tokens are separately
        requested.

        Finally, two access tokens are presented to the RS while
        invoking a Registration operation.

      


      

      
Note that the start of the story is to open an account, e.g.
        using FIDO. The needs of the RS are only disclosed to the
        student once he has filled some forms 

        and indicated that he wanted to perform a Registration
        operation. Thus, the needs that are revealed by the RS are
        dependant both upon the operation 

        that the student is willing to perform and the information
        collected in the forms.

      


      

      
Denis

    

    

    

      
      

        
Hi Denis, comments inserted ... 

        

        

          
On Fri, Jul 24, 2020 at 9:08
            AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              

                
Hi Dick,

                


                

                
draft-hardt-xauth-protocol-13 describes a solution
                  without clearly stating what the problem(s) to be
                  solved is/are.

              

            

          

          


          

          
I agree that the problem description is not as crisp as I
            would like it to be. A challenge is that there is a broad
            spectrum of use cases solved by OAuth 2, and OpenID Connect,
            as well as the new use cases that are solved by GNAP.

          


          

          
That is why I am suggesting we gather some use cases so
            we have a common understanding of the problems that are in
            scope.

          
 

          

            

              

                


                

                
At the moment, draft-hardt-xauth-protocol-13
                  includes a single figure on page 4 and from previous
                  discussions I understood that 

                  it is no more up-to-date since the first data flow is
                  now a contact with a RS. The reason(s) for the GS to
                  contact a RO has still not 

                  been explained (since the inputs and outputs are not
                  described). The discovery information made available
                  at various steps at the RS 

                  is not described.

                

              

            

          

          


          

          
I have made no updates as we are in a quiet period prior
            to the WG meeting next week when documents cannot be
            updated.

          
 

          

            

              

                

                  


                  

                

                
Figure 4 shows only a single RS. Is the relaying of
                  one operation by that RS to a second RS in the scope
                  of this document ?

                  If yes, how is it handled ?

                

              

            

          

          


          

          
I view that as an advanced use case that would be covered
            in a separate document.

          
 

          

            

              

                
 

                


                

                
Figure 4 shows only a single GS. How would be the
                  data flow when access tokens from two GSs are needed
                  by a RS ?

                

              

            

          

          


          

          
I don't know of a use case where two tokens would be
            needed by an RS. Would you elaborate?

          
The RS being able to accept tokens from two different
            GSes is covered, but the Client is only using a token from
            one GS at a time.

          


          

          
 

          

            

              

                
 

                

                What we need first is not a set of "use cases" but a
                clear model with a data flows and a list of its
                properties/characteristics. 

              

            

          

          


          

          
I disagree. The use cases describe the problems we are
            looking to solve. The data flows are part of the solution.
            For example, from my understanding of your use case, you
            don't want the GS to have visibility into the User's
            activity. Am I correct that this is one of your requirements
            for your use case?

          


          

          
 

          

            

              
 

              
Then after, we can understand much better which use
                cases can/will be supported. For example, shall a RS (or
                its RO) have 

                prior relationships with the GS ? What is the
                difference/implications when it has or it hasn't ?

              

              


              

              
In order to have a fair comparison, we should try to
                list model properties/characteristics.

              


              

              
At the moment, the model I have described including
                the data flows is clear. The discovery information made
                available by a RS is clear.

              
I have not listed all its properties/characteristics
                of that model, but I am pretty sure that you already
                have a flavour of it.

              


              

              
In the mean time, it would be nice if you could show
                using two figures:

              
    
                
  • the case of the relaying of one operation by one RS
                  to a second RS (if it is in the scope of your
                  document),
    • 
                
  • the case where access tokens from two GSs are needed
                  by one RS (if it is in the scope of your document).
    
                
    • 
              

            

          

          


          

          
See above

          
 

          

            

              
    
                
  •  
    
                
    • 
              

              

                
Denis

              

              


              

              

                
Hi Denis
                  


                  

                  
I think it would be useful to take a step back
                    and for you to describe your use case. 

                    After that, we can explore the different ways that
                    your use case can be addressed. 

                  


                  

                  
Looking at your previous communication, it
                    describes the solution, and the justification, 

                    but it is not clear what use cases you are needing
                    to solve.

                  


                  

                  
/Dick

                  


                  

                  


                  

                

                
ᐧ

                

                

                  
On Wed, Jul 22, 2020
                    at 9:34 AM Denis <denis.ietf@free.fr>
                    wrote:

                  

                  

                    

                      
Hello Dick,

                      


                      

                      
I have identified the reason of the major
                        difference between our two approaches.

                      


                      

                      
Access control may be performed using either
                        ACLs (Access Control Lists) or Capabilities.

                      


                      

                      
Note : a capability identifies a
                        resource and an allowed operation that can be
                        performed on that resource.

                      

                      


                      

                      
You are advocating a Capabilities approach
                        while I am advocating an ACL approach.

                      
The capabilities approach allows the GS to
                        trace every operation performed by the users on
                        any RS known by a GS.

                        The management of these capabilities is made via
                        the GS or at the GS by the various ROs. If the
                        management is made 

                        via the GS, then a trusted communication channel
                        needs to be established with every RO. If the
                        management is made 

                        at the GS, then an authentication mechanism
                        needs to be established with every RO. In the
                        last case, the GS has the 

                        ability to know all the capabilities of the
                        users whether they are used or not. The less
                        that can be said is that this model 

                        is not privacy friendly.

                      
With the ACL approach, a RO directly manages an
                        ACL placed in front of each RS. The Access Control Decision
                          Function 

                            (ADF) at the RS is
                          able to keep track from prior decisions. The
                        GS is kept ignorant of the content of these ACLs
                        and only 

                        delivers to its clients attributes that are
                        placed into access tokens. Such a model may be
                        privacy friendly.

                      
Other comments are between the lines prefixed
                        with [Denis].

                      

                        

                          


                            

                              
On Tue,
                                Jul 21, 2020 at 11:26 AM Denis <denis.ietf@free.fr>
                                wrote:

                              

                              

                                

                                  
Hello Dick,

                                  


                                  

                                  
 Thank you for your feedback.
                                    Comments are between the lines.

                                  


                                  

                                  

                                    

                                      
comments inserted
                                        ... 

                                      

                                      

                                        
On Tue, Jul
                                          21, 2020 at 6:03 AM Denis <denis.ietf@free.fr>
                                          wrote:

                                        

                                        

                                          

                                            
Hello Dick,

                                            


                                            

                                            
I duplicate the most
                                              important comment at the
                                              beginning of this email:

                                            

                                              
You are considering
                                                using an access control
                                                model to build a workflow
                                                model.

                                                 

                                                While it may be
                                                interesting to define a
                                                workflow model, this
                                                should be considered 

                                                as a separate and
                                                different work item.

                                            

                                            
See the other comments
                                              between the lines.

                                            

                                            


                                            

                                            

                                              
On Mon, Jul
                                                20, 2020 at 2:05 AM
                                                Denis <denis.ietf@free.fr>
                                                wrote:

                                                

                                                  

                                                    

                                                      
Hi Dick,

                                                      


                                                      

                                                      

                                                        
On
                                                          Fri, Jul 17,
                                                          2020 at 9:21
                                                          AM Denis <denis.ietf@free.fr>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Francis and
                                                          Dick,

                                                          


                                                          

                                                          
The good
                                                          news first: we
                                                          are making
                                                          some progress.
                                                          We are now
                                                          close to an
                                                          agreement with
                                                          steps (1) up
                                                          to (3), 

                                                          ... except
                                                          that the place
                                                          where the user
                                                          consent is
                                                          captured is
                                                          not
                                                          mentioned/indicated.

                                                          

                                                          

                                                          

                                                        

                                                      

                                                      

                                                      This major
                                                      question which is
                                                      currently left
                                                      unanswered is
                                                      where, when and
                                                      how the user
                                                      consent is
                                                      captured.

                                                    

                                                  

                                                  


                                                  

                                                  
When is covered,
                                                    per the sequence.
                                                    How and where are
                                                    out of scope of what
                                                    I drafted. 

                                                  

                                                

                                              

                                            

                                            
It is clear that the
                                              "User consent and choice"
                                              is not currently addressed
                                              in the draft, but it
                                              should.

                                              The support of the "User
                                              consent and choice" has
                                              strong implications not
                                              only in the sequences of
                                              the exchanges 

                                              but also by which entity
                                              it should be performed.

                                          

                                        

                                        
"consent" is in the latest
                                          draft 7 times. 

                                        

                                      

                                    

                                  

                                  
"Consent" is present 5 times. The
                                    User consent is different from the
                                    RO consent (when/if it is required).
                                    

                                  

                                  

                                    
The server acquires consent and
                                      authorization from the user and/or
                                        resource owner if
                                        required.

                                    

                                    
User consent is often
                                        required at the GS. GNAP
                                      enables a Client and  GS to
                                      negotiate the interaction mode for
                                      the GS to obtain consent.

                                    

                                    
 The GS may require
                                      explicit consent from the RO or
                                      User to provide these to the
                                      Client.

                                    

                                  

                                  
The User consent is not an
                                    alternative to the RO consent. So
                                    using "and/or" in the first sentence
                                    is incorrect.

                                

                              

                              


                              

                              
My language is sloppy there. Consent
                                is always from the RO. The User may be
                                the RO.

                            

                          

                        

                      

                      
[Denis] No. Once again: The "User consent"
                        is different from what you call the "RO
                          consent" (when/if it is required). 

                        The "RO consent" is not in fact a consent but
                        the release of a capability to a client by one
                        of the many R0s with which 

                        the GS has relationships. 

                      

                      

                        

                          

                            

                              

                                

                                  
Since the second sentence is using
                                    the wording "often required" there
                                    is no requirement to get the User
                                    consent.

                                  

                                

                              

                              
User consent may not be required.
                                There may not be a User. The consent may
                                have been gathered previously.

                            

                          

                        

                      

                      
[Denis] In order to follow the privacy
                        principles, a "User consent" phase is required.
                        The User is a natural person.

                        A Client is called either by a User (i.e. a
                        natural person) or by a Client application. 

                      

                      

                        

                          

                            

                              

                                

                                  
 

                                  
The second sentence does not
                                    consider the possibility to get the
                                    User consent in a place different
                                    from the GS.

                                

                              

                              
Agreed. But we do agree that the GS
                                gets the consent, either directly from
                                the RO, or from the Client (in your
                                example).

                            

                          

                        

                      

                      
[Denis] No. I disagree. In an ACL based
                        systems, the GS does not need to ask or receive
                        any consent.

                        The client selects the set of attributes that it
                        wants to be inserted into an access token.

                        If the GS has the requested attributes, then it
                        provides them, otherwise it returns an error to
                        the Client.

                      

                        

                          

                            

                              

                                

                                  
IMO, the User consent should be
                                    captured by the Client, i.e. not by
                                    the GS. 

                                    The information used to obtain the
                                    User consent should be standardized
                                    (... and it can be standardized).

                                  

                                  

                                    

                                      
I think
                                        the abstract sequence as
                                        proposed by Francis is a great
                                        addition, and would clarify
                                        where consent is in the
                                        sequence. 

                                    

                                  

                                  
The current sketch does not
                                    illustrate the place the User
                                    Consent is captured, in particular
                                    by the Client.

                                

                              

                              
It is an abstraction. The GS receives
                                the consent. How consent is gathered is
                                a detail that is dependent on the use
                                case.

                            

                          

                        

                      

                      
[Denis] I really wonder whether there is really
                        a "consent" to be received by the GS in both
                        cases (i.e. ACLs or Capabilities).

                      

                      
    
                        
  • For ACLs, the consent needs to be done by
                          the Client.
    • 
                        
  • For Capabilities, the current description is
                          not clear since the inputs and the outputs for
                          this "consent" phase
    
                          are not currently described in the draft.
    • 
                      

                      

                        

                          

                            

                              
 

                              

                                

                                  

                                    

                                      

                                        
 

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    
 Another
                                                      important point to
                                                      consider and to
                                                      explain is related
                                                      to the assurances
                                                      that the user can
                                                      obtain about 

                                                      the respect of his
                                                      choices. This
                                                      point is currently
                                                      left unanswered in
draft-hardt-xauth-protocol-13.

                                                    

                                                  

                                                

                                              

                                            

                                            
This point is equally
                                              important: such assurance
                                              can only be obtained if
                                              the access token returned
                                              to the client 

                                              is not considered to be
                                              opaque to the client. This
                                              is a necessary condition
                                              but not the single
                                              condition: 

                                              the Client must also be in
                                              a position to
                                              capture/memorize the "User
                                              consent and choice" of the
                                              user in order to be able 

                                              to verify it afterwards
                                              using the content of the
                                              access token(s).

                                          

                                        

                                        


                                        

                                        
We disagree on this being a
                                          requirement for all use cases.
                                          It may be in some. 

                                        

                                      

                                    

                                  

                                  
OK. Then this means that there will
                                    be no sentence in the draft such as
                                    :

                                    "access tokens returned to the
                                    client are not considered to be
                                    opaque to the client".

                                

                              

                              


                              

                              
For OAuth use cases, which GNAP
                                supports, the access token is opaque to
                                the Client. As you have noted, there are
                                use cases where the access token is NOT
                                opaque.

                            

                          

                        

                      

                      
[Denis] Wait a second. There is no requirement
                        to support all OAuth use cases. 

                        I believe that there is a requirement to support
                        OAuth 2.0 ASs, while the clients may be
                        different 

                        and hence GNAP clients do not need to inherit of
                        the limitations of OAuth 2.0 clients.

                      

                        

                          

                            

                              
 

                              

                                

                                  

                                    

                                      

                                        
 

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    
 

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          
If a RO
                                                          needs to be
                                                          involved and
                                                          since a RO is
                                                          directly
                                                          associated
                                                          with a RS, why
                                                          can't it be
                                                          directly
                                                          queried 

                                                          by the
                                                          appropriate RS
                                                          after step (2)
                                                          or later on ?

                                                          

                                                          

                                                          


                                                          

                                                          
Good
                                                          question.
                                                          Perhaps you
                                                          can expand on
                                                          a use case
                                                          where that
                                                          would be
                                                          useful?

                                                          

                                                        

                                                      

                                                      
Before I
                                                        expand, would
                                                        you be able to
                                                        explain first
                                                        under which
                                                        circumstances a
                                                        RO needs to be
                                                        queried by a GS
                                                        ?

                                                        How can the GS
                                                        identify which
                                                        RO to query ?

                                                    

                                                  

                                                  
If the User is
                                                    the RO, then the GS
                                                    knows who to query.
                                                    

                                                  

                                                

                                              

                                            

                                            
I still have difficulties
                                              to understand what you
                                              mean here. 

                                              How could a GS know that
                                              "the User is the RO" ?  If
                                              "the User is the RO", why
                                              does the GS needs to query
                                              the User ? 

                                            

                                          

                                        

                                        


                                        

                                        
To get consent?

                                      

                                    

                                  

                                  
To get a "RO consent" to himself
                                    ???

                                

                              

                              


                              

                              
The GS needs consent from the RO. If
                                the RO is the User, then consent from
                                the RO is equivalent to consent from the
                                User.

                            

                          

                        

                      

                      
[Denis] See above.

                      

                      

                        

                          

                            

                              
 

                              

                              

                                

                                  

                                    

                                      

                                        
 

                                        

                                          

                                            

                                              

                                                

                                                  
If the RO is a
                                                    separate entity,
                                                    then the GS knows
                                                    the RO from the RS
                                                    being queried. 

                                                  

                                                

                                              

                                            

                                            
 ... and this gives the
                                              ability for the GS to
                                              log/trace all the RSs
                                              accessed by a given User
                                              and at which instant of
                                              time the access token has
                                              been granted.

                                            

                                              

                                                

                                                  
An example is a
                                                    user would like
                                                    access to an
                                                    enterprise asset
                                                    where a workflow is
                                                    started to gain
                                                    approval, and an
                                                    administrator or
                                                    manager provides
                                                    consent.

                                                

                                              

                                            

                                            
Thanks for this example.
                                              I finally understand what
                                              you have in mind: you are
                                              considering using an
                                              access control model to
                                              build a workflow model.
                                              

                                              While it may be
                                              interesting to define a
                                              workflow model, this
                                              should be considered as a
                                              separate and different
                                                work item.

                                          

                                        

                                        


                                        

                                        
The actual workflow is out
                                          of scope. 

                                      

                                    

                                  

                                  
I am glad you agree with this. But
                                    this means that your example was not
                                    appropriate to illustrate your
                                    point.

                                  

                                

                              

                              


                              

                              
It illustrates a use case where the
                                RO and User are not the same party, and
                                why the GS needs to query the RO, which
                                was your question if I understood it
                                correctly.

                            

                          

                        

                      

                      
[Denis] Since the inputs and the outputs for
                        this "RO consent" phase are not currently
                        described in the draft, the point is still
                        unsolved.

                      

                      

                        

                          

                            

                              

                                

                                  
 As soon as there is a RO consent
                                    obtained at the GS, the major
                                    problem is that the GS is able to
                                    act as Big Brother.

                                    If a RO consent is performed at the
                                    RS, then the GS will not know who
                                    the RS is: it is then unable to act
                                    as Big Brother, 

                                    even if it would enjoy to play that
                                    role.

                                

                              

                              
In an enterprise use case, the GS's
                                knowledge of who is accessing which RS
                                is a feature.

                            

                          

                        

                      

                      
Do you mean that it is "normal" in an
                        enterprise that a single point of control is
                        able to trace all their actions ? 

                        From a security point of view, a single point of
                        failure will have dramatic consequences.

                      

                        

                          

                            

                              
In your use cases, it seems that the
                                RO is the User. 

                            

                          

                        

                      

                      
I do hope that you have finally understood
                        that, in my use case, the RO is **not** the
                        User.

                      

                        

                          

                            

                              
The GS knows the User is wanting to
                                let a Client access something. If the
                                access token is generic, and could be
                                presented to any RS that provides a
                                standardized function, 

                                then the GS does not know which RS is
                                being accessed by a Client for the User.
                                This seems to meet your privacy
                                objectives. If not, what is wrong?

                            

                          

                        

                      

                      
For security reasons, an access token needs to
                        be targeted (which does not necessarily mean
                        that an identifier of the RS shall be included
                        into the access token).

                      

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
if the admin grants access,
                                          then the access granted to the
                                          client changes. 

                                        

                                        

                                          

                                            
 

                                            
The model you propose may
                                              be suited for an
                                              enterprise environment but
                                              is not scalable over the
                                              Internet.

                                          

                                        

                                        
It is one of the use cases
                                          we are working to address. 

                                        

                                        

                                          

                                            
 What is needed is an
                                              access control model
                                              usable over the Internet
                                              with millions of RSs and
                                              thousands of ASs/GSs.  

                                            

                                          

                                        

                                        
I agree the model should
                                          also scale to internet scale.
                                          

                                        

                                      

                                    

                                  

                                  
Fine. Another point on which we are
                                    in agreement. 

                                  

                                  
The model can scale to the Internet
                                    based on the following assumptions:

                                  

                                    
The flow starts with the steps
                                      (1) to (4) as illustrated by
                                      Francis, i.e. the flow starts with
                                      a contact with a RS.

                                  

                                  
+----+
                                         +------+  +---+  +---+  +---+

                                        |User|  |Client|  |RS |  |GS |
                                         |RO |

                                        +----+  +------+  +---+  +-+-+
                                         +-+-+

                                          |(1) Service Request     |    
                                         |

                                          |-------->|       |      |
                                             |

                                          |         |(2) Service Intent
                                          |

                                          |         |------>|      |
                                             |

                                          |         |(3) AuthZ Challenge
                                         |

                                          |         |<------|      |
                                             |

                                          |         |(4) AuthZ Request  
                                         |

                                          |         |------------->|
                                             |

                                  
The GS/AS does not need to have any
                                    prior relationship with ROs and/or
                                    RSs.

                                  
Furthermore, it is possible to
                                    prevent the GS to act as Big Brother
                                    when the identity of the RS is not
                                    disclosed to the GS.

                                  

                                

                              

                              


                              

                              
What happens after (4) above? 

                              

                            

                          

                        

                      

                      
[Denis] The key point is that we first need to
                        agree on the first four exchanges. Do we ?

                      

                      
The fifth exchange is different whether ACLs or
                        Capabilities are being used.

                      

                      

                        

                          

                            

                              
 

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          
Which
                                                          information is
                                                          supposed to be
                                                          presented to
                                                          the RO ?

                                                          Which
                                                          information is
                                                          supposed to be
                                                          returned by
                                                          the RO ?

                                                          

                                                          

                                                          


                                                          

                                                          
Just like
                                                          how the user
                                                          authenticates
                                                          to an AS, how
                                                          the AS and RO
                                                          communicate is
                                                          out of scope.

                                                          

                                                          

                                                        

                                                      

                                                      
At the moment,
                                                        the usefulness
                                                        of a dialogue
                                                        between a GS and
                                                        a RO has not
                                                        been explained,
                                                        nor
                                                        demonstrated.

                                                        The question is
                                                        about the
                                                        functionality of
                                                        that dialogue in
                                                        terms of input
                                                        and output
                                                        information (and
                                                        not about 

                                                        the design of a
                                                        protocol or of a
                                                        user interface).
                                                        Anyway, AFAIU a
                                                        dialogue between
                                                        a GS and a RO is
                                                        optional.

                                                      

                                                    

                                                  

                                                  


                                                  

                                                  
See enterprise
                                                    example above.

                                                

                                              

                                            

                                            
It is not an access
                                              control example, but a
                                              workflow example.

                                            
Access 
                                              control has been defined a
                                              long time ago and the last
                                              edition of the model has
                                              been confirmed in year
                                              1996: ISO/IEC 10181-3:
                                                  1996.

                                              "Information
                                                technology — Open
                                                Systems
                                                Interconnection —
                                                Security frameworks for
                                                open systems: Access
                                                control framework —
                                                Part 3".

                                            
Two
                                                major functions have ben
                                                defined: an Access Control Enforcement Function
                                                    (AEF) and an Access
                                                Control Decision
                                                Function(ADF).

                                            

                                              
Access
                                                  Control Enforcement
                                                  Function (AEF):

                                                  A specialized function
                                                  that is part of the
                                                  access path between an
                                                  initiator and a target
                                                  on each access request
                                                  and enforces the
                                                  decision made by the
                                                  ADF.

                                              Access Control Decision
                                                Function (ADF) :

                                              A
                                                specialized function
                                                that makes access
                                                control decisions by
                                                applying access control
                                                policy rules to an
                                                access request, ADI (of
                                                initiators, targets,
                                                access requests, 

                                              or
                                                that retained from prior
                                                decisions), and the
                                                context in which the
                                                access request is made.

                                            
The role of the RO is to
                                              define the "access
                                                control policy rules" at
                                                the RS according to the context
                                                  in which the access
                                                  request is made.

                                          

                                        

                                        
I'm pretty familiar with
                                          access control systems. :) 

                                        


                                        

                                        
I would say that the access
                                          control is happening at the
                                          RS. The client presents a
                                          token when accessing an API. 

                                          The RS uses the token, and any
                                          policy required, to make an
                                          access decision.

                                      

                                    

                                  

                                  
Fine. It looks like we are in
                                    agreement. Unfortunately, this is
                                    not the case just below.

                                  

                                  

                                    

                                      

                                        
Here is flow:

                                        


                                        

                                        
1) The Client requests
                                          access to an RS from the GS. 

                                        

                                      

                                    

                                  

                                  
No. We are no more in agreement.
                                    This is different from the flow
                                    drawn by Francis.

                                

                              

                              
My bad. Typo. I meant RO.

                              
 

                              

                                

                                  

                                    

                                      

                                        
2) The GS queries the RS if
                                          access should be granted. 

                                        

                                      

                                    

                                  

                                  
 No. The GS should not be forced to
                                    have a flow with the RS.

                                

                              

                              
Same mistake as above, I meant RO. 

                              

                                

                                  
 

                                  

                                    

                                      

                                        
3) If access is granted,
                                          the GS creates an access token
                                          representing the granted
                                          access, and returns it to the
                                          Client. 

                                        

                                      

                                    

                                  

                                  
This model is by no way conformant
                                    to ISO/IEC 10181-3:
                                        1996 

                                      

                                

                              

                              
I'm unclear on why, or why it is even
                                relevant. 

                              

                              

                                

                                  
 

                                  

                                    

                                      

                                        
4) The Client presents the
                                          access token to the RS to show
                                          it has been granted access. 

                                        

                                      

                                    

                                  

                                  
No. The client presents a token
                                    when accessing an API. The RS uses
                                    the token, and any policy required,
                                    to make an access decision.

                                    The token never contains an
                                    information like "Please grant an
                                    access to the holder of this token".

                                

                              

                              
Let me provide more clarity in the
                                sentence:

                              


                              

                              
The Client presents the access token
                                to the RS, to show the RS that the
                                Client has been granted access to a
                                resource at the RS by the GS.

                            

                          

                        

                      

                      
[Denis] This time, please consider both the
                        ACLs approach and the Capabilities approach.

                      

                        

                          

                            

                              
 

                              

                                

                                  

                                    

                                      

                                        
A couple advantages of this
                                          model:

                                        
- that the RS does not need
                                          to know much, if anything
                                          about the Client. 

                                        
- the access token MAY be
                                          self contained so that the
                                          Client does not need to query
                                          the GS on each access. 

                                        

                                      

                                    

                                  

                                  
There are so many disadvantages
                                    that I will not list them.

                                

                              

                              
Darn: I clearly was not firing on all
                                cylinders when I typed this out. Let me
                                correct:

                              


                              

                              

                                

                                  

                                    

                                      
- the access token MAY be
                                        self contained so that the RS
                                        does not need to query the GS on
                                        each access to the RS by the
                                        Client.

                                    

                                  

                                

                              

                            

                          

                        

                      

                      
[Denis] A few comments in the case of a
                        capability approach:

                      

                        
- for each GS, the RS needs to locally manage
                          which operation(s) is/are allowed to it.

                          

                          - the GS needs to establish a trusted
                          communication channel or an authentication
                          mechanism with each RO 

                             (which is associated with an explicit RS
                          identifier). 

                        

                        
- the GS could play the role of the RO and
                          hence be in a position to issue any capability
                          for any RS (without a "RO consent"). 

                          

                             The target of an attack will clearly be the
                          GS.

                        

                      

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
I would not say that GNAP
                                          is an access control protocol,
                                          as how the RS uses the token
                                          to determine access is out of
                                          scope.

                                      

                                    

                                  

                                  
This is where we have a major
                                        discrepancy: how
                                    the RS uses the token to determine
                                    access is *within* the scope.

                                

                              

                            

                          

                        

                      

                      [Denis] Do you agree or disagree ?

                      

                        

                          

                            

                              

                                

                                  
The RS announces in advance to the
                                    client what it needs so that the
                                    client can perform a a given
                                    operation and if the client supplies
                                    the requested attributes 

                                    obtained from some GS/AS(s) trusted
                                    by the RS, then access to that RS is
                                    granted by the RS. If the RS cannot
                                    perform the requested operation on
                                    its own, 

                                    then the client should be informed
                                    about some requested attributes that
                                    need to be obtained from some
                                    GS/AS(s) trusted by the next RS(s)
                                    in a chain

                                    for subsequent operations. The User
                                    consent should also be obtained
                                    before performing the chaining
                                    operation.

                                  

                                  
Chaining operations between RSs
                                    over the Internet is within the
                                    scope (... and may be achieved).

                                

                              

                            

                          

                        

                      

                      
[Denis] Do you agree or disagree ?

                      
Denis

                      

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
 

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
For many
                                                          use cases, the
                                                          User is the
                                                          RO, and the
                                                          interaction is
                                                          through a user
                                                          interface, not
                                                          a machine
                                                          protocol. 

                                                          

                                                          

                                                        

                                                      

                                                      
Wait a second.
                                                        You wrote "the
                                                        User is the RO".
                                                        The User is
                                                        attempting to
                                                        make an access
                                                        to a RS by using
                                                        a Client. 

                                                        That User
                                                        is not the RO of
                                                        the RS.   

                                                      

                                                    

                                                  

                                                  
The user being
                                                    the RO is the
                                                    initial use case for
                                                    OAuth. 

                                                

                                              

                                            

                                            
OAuth 2.0 is no more
                                              mandating such a case.

                                            

                                          

                                        

                                      

                                    

                                  

                                  

                                    

                                      


                                        
I don't know what you mean
                                          by that.

                                      

                                    

                                  

                                  
Copy and paste from
                                    draft-ietf-oauth-security-topics:

                                  

                                  

                                    
OAuth initially assumed a static
                                      relationship between client,
                                      authorization server and resource
                                      servers.  (...)  

                                      With the increasing adoption of
                                      OAuth, this simple model dissolved
                                      and, in several scenarios, was
                                      replaced 

                                      by a dynamic establishment of the
                                      relationship between clients on
                                      one side and the authorization and
                                      

                                      resource servers of a particular
                                      deployment on the other side.

                                      

                                      This way, the same client could be
                                      used to access services of
                                      different providers (in case of
                                      standard APIs, 

                                      such as e-mail or OpenID Connect)
                                      or serve as a frontend to a
                                      particular tenant in a
                                      multi-tenancy environment. 

                                    

                                  

                                

                              

                              


                              

                              
This sentence does not mention the RO
                                or the Client. I'm confused what we are
                                talking about 

                              

                                

                                  

                                    
 

                                  

                                  

                                    

                                      

                                        
 

                                        

                                          

                                            

                                              

                                                

                                                  
A client
                                                    application would
                                                    like access to the
                                                    user's photos at a
                                                    photo sharing site.
                                                    The resource is the
                                                    user's photos. The
                                                    user is the owner of
                                                    that resource.

                                                

                                              

                                            

                                            
If the user has already
                                              pre established the access
                                              control policy rules so
                                              that it can access to his
                                              own photos 

                                              then he does not need to
                                              grant in real time any
                                              additional authorization.

                                          

                                        

                                        
I don't understand what you
                                          are trying to say. The photo
                                          sharing example was a driving
                                          use case for the creation of
                                          OAuth.

                                      

                                    

                                  

                                  
We would need to revisit the
                                    original scenario and consider if it
                                    can be addressed in a different way
                                    than the original way.

                                

                              

                              
The use case is the same. Is there a
                                different solution you are proposing?

                              
 

                            

                          

                        

                      

                      


                      

                    

                    -- 

                    Txauth mailing list

                    Txauth@ietf.org

                    https://www.ietf.org/mailman/listinfo/txauth

                  

                

              

              


              

            

            -- 

            Txauth mailing list

            Txauth@ietf.org

            https://www.ietf.org/mailman/listinfo/txauth

          

        

      

      
ᐧ

    

    


    

  


--------------9B01394042B761375535B355--


From nobody Fri Jul 24 12:07: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 F38013A08FA for ; Fri, 24 Jul 2020 12:07: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 g--ultf4hxLT for ; Fri, 24 Jul 2020 12:07:07 -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 04FD63A08F5 for ; Fri, 24 Jul 2020 12:07:06 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id h22so11035031lji.9 for ; Fri, 24 Jul 2020 12:07: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=hmns8f0Fg4QMAjVprMKQP8heu8St/yCbqgHQpxGh5Tk=; b=Pu102gZUmzU2B8F9X1cH+c3k729CsPI84bqIGkpZvSaxZdo5be7rYp9OBUF7wm+/AL APj+zmrGnM+S9satjiuBxdNBlw2KX6c07nFaY7hzMbzI7m4CyAwzO/voLz/gNYdi+maJ ZucXWNfoGS3/BjUXMXvEqXrYNAOZnrYj4e9IkKQfrVG8CVZLvawjUVAvh1xd8ap+PYC2 R0H2evRKaDXPbwtnkNjEC1kV/C+7yIVWNfUQNqp4KcFqeZLIVjhycIAh/b+bwN7tlAoN ZP5MUVBpCx7EI2bvE5YGr/54AnzYr3JCDJzCJ/ESqidPpufkmb0GTUtehhpfUk1PFXwO vrAA==
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=hmns8f0Fg4QMAjVprMKQP8heu8St/yCbqgHQpxGh5Tk=; b=GfrXwwt1Gt4wv5eUSwxpKr/fwI7cONHBhWLrayn7wDbEdXmBEauFKmcJ0nbt+HI9v5 JH1aUu4nYxI65Gy6OF45ciGESQWar9rHpoe9ZATIx4bMO/hgTzPq6c1YrisBAdkDBvcm hT5BswEz4XpdbGznA6vkCpuKtYtM2bcErSoFyD3EgvNnVXg3N2ffkSqMbvLYaAJWRPj9 B5tmL4kxEHIuV/cBoFpwdMHpuNjvyx9MELL2aWhHUQTZZlOt7ibyWyY0B3rG9yua7R9/ ZCO0vdpl0yTSTANje79I3+WyTeqazT5T7qR0OD+Dc1QVTZmUiggsxfNtRV4JmWoly0fj e5ow==
X-Gm-Message-State: AOAM533/cDzAY843vnc+6afV7DPNvFkMZsbXLlu+FH/5c1imh4c2Njxe 29WFyuP5SaXDl35Z36AAx5+K86A/u4M16jN2guU=
X-Google-Smtp-Source: ABdhPJzw65Z7S41gRa0xPSxnVyKnvrTQmO4EGNCXmOJ4JJTwK7wYF7O9q7wz4k/nOgCQcfWx0J738y2QOpT82ViHTTM=
X-Received: by 2002:a2e:900a:: with SMTP id h10mr5154816ljg.242.1595617624903;  Fri, 24 Jul 2020 12:07:04 -0700 (PDT)
MIME-Version: 1.0
References:              
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 24 Jul 2020 12:06:28 -0700
Message-ID: 
To: Justin Richer 
Cc: Francis Pouatcha , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="000000000000bad5bb05ab34adfc"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 19:07:09 -0000

--000000000000bad5bb05ab34adfc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Justin, thanks for clarifying.

What are some examples of other "direct data" that the GS may return? If it
is not in core GNAP, do we need to worry about now? We can then give the
direct data from the GS that is not a claim, an appropriate name in that
document.



On Fri, Jul 24, 2020 at 11:46 AM Justin Richer  wrote:

> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m saying=
. I agree that
> =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But the AS=
 could return
> other data directly to the client that isn=E2=80=99t about the user. Thos=
e aren=E2=80=99t
> =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=80=
=9Cclaims=E2=80=9D can come back
> from places other than directly, then we shouldn=E2=80=99t call everythin=
g that
> comes back a =E2=80=9Cclaim=E2=80=9D.
>
> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean what it=
 already means and come
> up with a new word to mean =E2=80=9Cthings that come back directly from t=
he AS=E2=80=9D.
> These aren=E2=80=99t meant to replace Francis=E2=80=99s more complete def=
initions, but to
> simplify:
>
> Claims:
> - information about the user
> - can come back directly from the AS
> - can come back in a resource from the RS
>
> Resource:
> - Returned from an RS
> - Protected by access token
> - Could contain claims about the user
>
> Direct data (or some better name):
> - Returned directly from AS
> - Could contain claims about the user
>
> I think the problem is that some people are using =E2=80=9Cclaims=E2=80=
=9D to mean #1 and
> some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s impor=
tant to remember,
> when talking about OIDC, that an IdP in OIDC combines an AS and an RS int=
o
> one entity for identity information. There can be other RS=E2=80=99s as w=
ell, and
> there usually are in the wild, but the one defined by OIDC is the UserInf=
o
> Endpoint. The fact that it returns user data doesn=E2=80=99t make it any =
less of an
> RS.
>
>  =E2=80=94 Justin
>
> * In the wider context of things like the information claims inside a JWT=
,
> the claims could be about literally anything, but that=E2=80=99s not what=
 we=E2=80=99re
> discussing here and it=E2=80=99s not how it=E2=80=99s being used.
>
>
> On Jul 24, 2020, at 1:24 PM, Dick Hardt  wrote:
>
> In OpenID Connect (OIDC), the Client can obtain Claims directly from the
> OP in an ID Token, or the Client can obtain Claims using an access token =
to
> call the UserInfo endpoint, a Protected Resource[1].
>
> The Claims are about the User (not a RO).
>
> In XAuth, I'm proposing the Client may obtain bare claims from the GS
> directly in addition to the mechanisms in ODIC.
>
> So I don't think we are changing the definition of Claim from how it has
> been used in OIDC, and I fail to see any reason to NOT use Claim.
>
> Justin: you allude to Claims being about a party other than the User.
> Would you provide an example?
>
> /Dick
>
> [1]
>
> UserInfo Endpoint
> Protected Resource that, when presented with an Access Token by the
> Client, returns authorized information about the End-User represented by
> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST use
> the https scheme and MAY contain port, path, and query parameter componen=
ts.
>
>
>
>
> =E1=90=A7
>
> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote:
>
>> I want to focus on one aspect here:
>>
>>
>>> A Claim is a well understood term in the field. We should use it. It is
>>> still a Claim if it comes directly from the GS or from an RS.
>>>
>> I do not understand why a Resource release by an RS shall be h to as a
>> claim, even if the content of the Resource is an assertion. It will lead=
 to
>> confusion. If we limit claims to information GS releases into Token, Use=
r
>> Info, and other objects it returns, this will help separate
>> responsibilities between GS and RS. As soon as RS services and informati=
on,
>> this is called a Resource, no matter the nature of the content of that
>> information.
>>
>>
>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=
=E2=80=9D in the way that
>> we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back t=
hrough an RS =E2=80=94 but in the
>> context of GNAP, that makes it a resource. So we need a different word f=
or
>> data coming back directly from the AS to the client. Sometimes it=E2=80=
=99s going
>> to be about the user, and that=E2=80=99s what we=E2=80=99re going to foc=
us on here, but
>> since you can also get information about the user from a resource we can=
=E2=80=99t
>> just call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the hea=
rt of a lot of
>> confusion in recent threads, as well as confusion about the scope of the
>> inclusion of identity in the GNAP protocol.
>>
>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does, =
and let=E2=80=99s find a way to
>> differentiate between when an item, claim or otherwise,  comes as part o=
f a
>> resource and when it comes back directly. This is an important
>> differentiating feature for GNAP.
>>
>> Some straw man ideas, none of which I=E2=80=99m particularly in love wit=
h:
>>
>>  - direct data
>>  - properties
>>  - details
>>  - statements
>>
>> The important thing here is that it=E2=80=99s not necessarily :about: th=
e RO, and
>> that it is :not: in a resource.
>>
>> Any other thoughts?
>>
>>  =E2=80=94 Justin
>>
>
>

--000000000000bad5bb05ab34adfc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Justin, thanks for clarifying.

What are=
 some examples of other "direct data" that the GS may return? If =
it is not in core GNAP, do we need to worry about now? We can then give the=
 direct data from the GS that is not a claim, an appropriate name in that d=
ocument.



On Fri, Jul 24, 2020 at 11:46 A=
M Justin Richer <jricher@mit.edu&=
gt; wrote:
Dick: No, I think you=E2=80=99re misun=
derstanding what I=E2=80=99m saying. I agree that =E2=80=9Cclaims=E2=80=9D =
are about the user, in this context*. But the AS could return other data di=
rectly to the client that isn=E2=80=99t about the user. Those aren=E2=80=99=
t =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=80=
=9Cclaims=E2=80=9D can come back from places other than directly, then we s=
houldn=E2=80=99t call everything that comes back a =E2=80=9Cclaim=E2=80=9D.=


I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=
=9D to mean what it already means and come up with a new word to mean =E2=
=80=9Cthings that come back directly from the AS=E2=80=9D. These aren=E2=80=
=99t meant to replace Francis=E2=80=99s more complete definitions, but to s=
implify:

Claims:
	- information about the user
	- can come back directly from the AS
	- can come back in a resour=
ce from the RS

Resource:
	- Returned from an RS
	- Protected by access token
	- Could contain claims about the =
user

Direct data (or some better name):
=
	- Returned directly from AS
	- Could contain claims=
 about the user

I think the problem is that some p=
eople are using =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. It=
=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s important to remember, whe=
n talking about OIDC, that an IdP in OIDC combines an AS and an RS into one=
 entity for identity information. There can be other RS=E2=80=99s as well, =
and there usually are in the wild, but the one defined by OIDC is the UserI=
nfo Endpoint. The fact that it returns user data doesn=E2=80=99t make it an=
y less of an RS.

=C2=A0=E2=80=94 Justin

* In the wider context of things like the information claims insid=
e a JWT, the claims could be about literally anything, but that=E2=80=99s n=
ot what we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s=
 being used.


On Jul 2=
4, 2020, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

In OpenID Connect (OIDC), the Client can obtain Claims directly =
from the OP in an ID Token, or the Client can obtain Claims using an access=
 token to call the UserInfo endpoint, a Protected Resource[1].

The Claims are about the User (not a RO).

I=
n XAuth, I'm proposing the Client may obtain bare claims from the GS di=
rectly in addition to the mechanisms in ODIC.

So I=
 don't think we are changing the definition of Claim from how it has be=
en used in OIDC, and I fail to see any reason to NOT use Claim.
<=
br>
Justin: you allude to Claims being about a party other than t=
he User. Would you provide an example?

/Dick
=


[1]
UserInfo Endpoint
Protected Resource=
 that, when presented with an Access Token by the Client, returns authorize=
d information about the End-User represented by the corresponding Authoriza=
tion Grant. The UserInfo Endpoint URL MUST use the https scheme and MAY con=
tain port, path, and query parameter components.


3D""=E1=90=A7<=
/div>
O=
n Fri, Jul 24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspec=
t here:


A Claim is a well understood term in the f=
ield. We should use it. It is still a Claim if it comes directly from the G=
S or from an RS.=C2=A0
I do not understand why=
 a Resource release by an RS shall be h to as a claim, even if the content =
of the Resource is an assertion. It will lead to confusion. If we limit cla=
ims to information GS releases into Token, User Info, and other objects it =
returns, this will help separate responsibilities between GS and RS. As soo=
n as RS services and information, this is called a Resource, no matter the =
nature of the content of that information.

This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=
=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in the con=
text of GNAP, that makes it a resource. So we need a different word for dat=
a coming back directly from the AS to the client. Sometimes it=E2=80=99s go=
ing to be about the user, and that=E2=80=99s what we=E2=80=99re going to fo=
cus on here, but since you can also get information about the user from a r=
esource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think th=
is has been at the heart of a lot of confusion in recent threads, as well a=
s confusion about the scope of the inclusion of identity in the GNAP protoc=
ol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D m=
ean what it already does, and let=E2=80=99s find a way to differentiate bet=
ween when an item, claim or otherwise,=C2=A0=C2=A0comes as part of a resour=
ce and when it comes back directly. This is an important differentiating fe=
ature for GNAP.

Some straw man ideas, none of whic=
h I=E2=80=99m particularly in love with:

=C2=A0- d=
irect data
=C2=A0- properties
=C2=A0- details
=C2=A0- statements

The important thing here is th=
at it=E2=80=99s not necessarily :about: the RO, and that it is :not: in a r=
esource.

Any other thoughts?

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





--000000000000bad5bb05ab34adfc--


From nobody Fri Jul 24 12:10: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 DA8593A08FA for ; Fri, 24 Jul 2020 12:10:57 -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_FILL_THIS_FORM_SHORT=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 XVZDy_OQ6U_8 for ; Fri, 24 Jul 2020 12:10:53 -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 7BB103A08F5 for ; Fri, 24 Jul 2020 12:10:52 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id a27so1560831ljn.8 for ; Fri, 24 Jul 2020 12:10: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=Z7Foa3c+NIo6bhC0hQu2HrzIQ+1hne+okRAhgQjZSOs=; b=szVpxHvNoFjO3Fk79yRUsj20cDtWp6tiI8u19jwhOhq9UXrvH5ANm8S+mWwfnwmsis lgZH1Mz5HzaKRptlxjwqcwMHHeLeb82sifBjl+BifBxYHrwVGOaE0/13tUHv1xMr3VYa PwSZvehN7mHfVu6J/x0wwMbjMdipS5MmPA/a9MO4FvdK+1QE0mEseNbnKJYRyHKwZAop f1L/q+L2I43/OrfDjsRBoPxnrV0+JgOwBOBHwuJ3Br0TlqAW0em/I0T01E0gtkqCuz+m iLk+qUqEuJdCbABZrDg/f1hN+kobeqAq49+owhVXmO9MV4eDfBwSM+s0fzea1T1TaaH+ bS+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=Z7Foa3c+NIo6bhC0hQu2HrzIQ+1hne+okRAhgQjZSOs=; b=RUwE4ibzWLrSWtJQCwkk6ySfHC0QEXN44c07UXJm2A6RuRbdT7BBtrCGO29OCtX8y8 LUb+iOlrMpk0TEpRV8NBrg4NVS9hcZmu5KSoaBOhWV7BDaXMR67z5q/b6VzN+i7saxS4 txTLEBSNh5MjhrsCmBgxqz6aCxyMX/rb4/i/puwt66bOoua06juyZ2P7rYk2cS5n0L0d 2YNGfMBIHhofxvAQip6WxxjnOvPdqPJ+RNLDhO7rHo3n3t6gLCmZgzYYgpvw7wfCz2/E 5df3k4pANSu8FJDmZnCZ2/32Jpm44b2p2f1mZT5eGwTMYtkZfY9cbztOFULhcSv87frJ 5WKw==
X-Gm-Message-State: AOAM532DvLYOE8GSQRCfdXuD3B8fy/TBOYHA34USWgPDFYD4M9piR1hz RdMBsYIt/TA84riPrj2hiK84Wrp8sSHhrfDYIZRXldyP
X-Google-Smtp-Source: ABdhPJy1DdMkBWWC4762R+mdbDhsC3rIl2WjoPHt3vdH/kIYdUns2a+8eOiGyDRUTbQK4hRjhBnsl4PueSXgE00zR5Q=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr5194417ljh.110.1595617850208;  Fri, 24 Jul 2020 12:10:50 -0700 (PDT)
MIME-Version: 1.0
References:         <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>      
In-Reply-To: 
From: Dick Hardt 
Date: Fri, 24 Jul 2020 12:10:13 -0700
Message-ID: 
To: Denis 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000028b79605ab34bb44"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 24 Jul 2020 19:10:58 -0000

--00000000000028b79605ab34bb44
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis

I would think in your example below, that the University's registration
system is the Client, not a Resource Server.

Have a good night's sleep!



On Fri, Jul 24, 2020 at 12:04 PM Denis  wrote:

> Hi Dick,
>
> In order to send back a quick reply tonight, I will only respond to one o=
f
> your questions:
>
> [Denis] How would be the data flow when access tokens from two GSs are
> needed by a RS ?
>
> [Dick] I don't know of a use case where two tokens would be needed by an
> RS. Would you elaborate?
>
> I already described on the list the case of a student registering to a ne=
w
> University.
>
> First, the student connects to the RS from the new University and opens a=
n
> account
> (at this time the student is using a pseudo and a private key to
> authenticate). He fills some forms
> and indicate its citizenship, his home address and his graduation in his
> current university.
>
> When he is finished, he indicates that he wants to perform a Registration
> operation.
>
> From the information gathered in the forms, the RS informs the client tha=
t
> it needs two access tokens:
>
>    - one to demonstrate that his name and current home address are
>    correct,and
>    - another one to demonstrate that he got a graduation from its current
>    University.
>
> Depending upon the information captured in the forms, the RS also
> indicates which ASs/GSs are acceptable
> and which kind of attributes are requested.
>
> The user consent and choice is performed by the client and once approved
> by the student, two access tokens are separately requested.
> Finally, two access tokens are presented to the RS while invoking a
> Registration operation.
>
> Note that the start of the story is to open an account, e.g. using FIDO.
> The needs of the RS are only disclosed to the student once he has filled
> some forms
> and indicated that he wanted to perform a Registration operation. Thus,
> the needs that are revealed by the RS are dependant both upon the operati=
on
> that the student is willing to perform and the information collected in
> the forms.
>
> Denis
>
> Hi Denis, comments inserted ...
>
> On Fri, Jul 24, 2020 at 9:08 AM Denis  wrote:
>
>> Hi Dick,
>>
>> draft-hardt-xauth-protocol-13 describes a solution without clearly
>> stating what the problem(s) to be solved is/are.
>>
>
> I agree that the problem description is not as crisp as I would like it t=
o
> be. A challenge is that there is a broad spectrum of use cases solved by
> OAuth 2, and OpenID Connect, as well as the new use cases that are solved
> by GNAP.
>
> That is why I am suggesting we gather some use cases so we have a common
> understanding of the problems that are in scope.
>
>
>>
>> At the moment, draft-hardt-xauth-protocol-13 includes a single figure on
>> page 4 and from previous discussions I understood that
>> it is no more up-to-date since the first data flow is now a contact with
>> a RS. The reason(s) for the GS to contact a RO has still not
>> been explained (since the inputs and outputs are not described). The
>> discovery information made available at various steps at the RS
>> is not described.
>>
>
> I have made no updates as we are in a quiet period prior to the WG meetin=
g
> next week when documents cannot be updated.
>
>
>>
>> Figure 4 shows only a single RS. Is the relaying of one operation by tha=
t
>> RS to a second RS in the scope of this document ?
>> If yes, how is it handled ?
>>
>
> I view that as an advanced use case that would be covered in a separate
> document.
>
>
>>
>> Figure 4 shows only a single GS. How would be the data flow when access
>> tokens from two GSs are needed by a RS ?
>>
>
> I don't know of a use case where two tokens would be needed by an RS.
> Would you elaborate?
> The RS being able to accept tokens from two different GSes is covered, bu=
t
> the Client is only using a token from one GS at a time.
>
>
>
>>
>> What we need first is not a set of "use cases" but a clear model with a
>> data flows and a list of its properties/characteristics.
>>
>
> I disagree. The use cases describe the problems we are looking to solve.
> The data flows are part of the solution. For example, from my understandi=
ng
> of your use case, you don't want the GS to have visibility into the User'=
s
> activity. Am I correct that this is one of your requirements for your use
> case?
>
>
>
>> Then after, we can understand much better which use cases can/will be
>> supported. For example, shall a RS (or its RO) have
>> prior relationships with the GS ? What is the difference/implications
>> when it has or it hasn't ?
>>
>> In order to have a fair comparison, we should try to list model
>> properties/characteristics.
>>
>> At the moment, the model I have described including the data flows is
>> clear. The discovery information made available by a RS is clear.
>> I have not listed all its properties/characteristics of that model, but =
I
>> am pretty sure that you already have a flavour of it.
>>
>> In the mean time, it would be nice if you could show using two figures:
>>
>>    - the case of the relaying of one operation by one RS to a second RS
>>    (if it is in the scope of your document),
>>    - the case where access tokens from two GSs are needed by one RS (if
>>    it is in the scope of your document).
>>
>>
> See above
>
>
>>
>>    -
>>
>> Denis
>>
>> Hi Denis
>>
>> I think it would be useful to take a step back and for you to describe
>> your use case.
>> After that, we can explore the different ways that your use case can be
>> addressed.
>>
>> Looking at your previous communication, it describes the solution, and
>> the justification,
>> but it is not clear what use cases you are needing to solve.
>>
>> /Dick
>>
>>
>> =E1=90=A7
>>
>> On Wed, Jul 22, 2020 at 9:34 AM Denis  wrote:
>>
>>> Hello Dick,
>>>
>>> I have identified the reason of the major difference between our two
>>> approaches.
>>>
>>> Access control may be performed using either ACLs (Access Control Lists=
)
>>> or Capabilities.
>>>
>>> *Note *: a capability identifies a resource and an allowed operation
>>> that can be performed on that resource.
>>>
>>> You are advocating a Capabilities approach while I am advocating an ACL
>>> approach.
>>>
>>> The capabilities approach allows the GS to trace every operation
>>> performed by the users on any RS known by a GS.
>>> The management of these capabilities is made via the GS or at the GS by
>>> the various ROs. If the management is made
>>> via the GS, then a trusted communication channel needs to be establishe=
d
>>> with every RO. If the management is made
>>> at the GS, then an authentication mechanism needs to be established wit=
h
>>> every RO. In the last case, the GS has the
>>> ability to know all the capabilities of the users whether they are used
>>> or not. The less that can be said is that this model
>>> is not privacy friendly.
>>>
>>> With the ACL approach, a RO directly manages an ACL placed in front of
>>> each RS. The Access Control Decision Function
>>> (ADF) at the RS is able to keep track from prior decisions. The GS is
>>> kept ignorant of the content of these ACLs and only
>>> delivers to its clients attributes that are placed into access tokens.
>>> Such a model may be privacy friendly.
>>>
>>> Other comments are between the lines prefixed with [Denis].
>>>
>>>
>>> On Tue, Jul 21, 2020 at 11:26 AM Denis  wrote:
>>>
>>>> Hello Dick,
>>>>
>>>> Thank you for your feedback. Comments are between the lines.
>>>>
>>>> comments inserted ...
>>>>
>>>> On Tue, Jul 21, 2020 at 6:03 AM Denis  wrote:
>>>>
>>>>> Hello Dick,
>>>>>
>>>>> I duplicate the most important comment at the beginning of this email=
:
>>>>>
>>>>> You are considering using an access control model to build a workflow
>>>>> model.
>>>>>
>>>>> While it may be interesting to define a workflow model, this should b=
e
>>>>> considered
>>>>> as a separate and different work item.
>>>>>
>>>>> See the other comments between the lines.
>>>>>
>>>>> On Mon, Jul 20, 2020 at 2:05 AM Denis  wrote:
>>>>>
>>>>>> Hi Dick,
>>>>>>
>>>>>> On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:
>>>>>>
>>>>>>> Hello Francis and Dick,
>>>>>>>
>>>>>>> The good news first: we are making some progress. We are now close
>>>>>>> to an agreement with steps (1) up to (3),
>>>>>>> ... except that the place where the user consent is captured is not
>>>>>>> mentioned/indicated.
>>>>>>>
>>>>>>
>>>>>> This major question which is currently left unanswered is where, whe=
n
>>>>>> and how the user consent is captured.
>>>>>>
>>>>>
>>>>> When is covered, per the sequence. How and where are out of scope of
>>>>> what I drafted.
>>>>>
>>>>> It is clear that the "User consent and choice" is not currently
>>>>> addressed in the draft, but it should.
>>>>> The support of the "User consent and choice" has strong implications
>>>>> not only in the sequences of the exchanges
>>>>> but also by which entity it should be performed.
>>>>>
>>>> "consent" is in the latest draft 7 times.
>>>>
>>>> "Consent" is present 5 times. The User consent is different from the R=
O
>>>> consent (when/if it is required).
>>>>
>>>> The server acquires consent and authorization from the user *and/**or
>>>> resource owner **if required.*
>>>>
>>>> User consent is *often required* at the GS. GNAP enables a Client and
>>>> GS to negotiate the interaction mode for the GS to obtain consent.
>>>>
>>>> The GS *may *require explicit consent from the RO or User to provide
>>>> these to the Client.
>>>>
>>>> The User consent is not an alternative to the RO consent. So using
>>>> "and/or" in the first sentence is incorrect.
>>>>
>>>
>>> My language is sloppy there. Consent is always from the RO. The User ma=
y
>>> be the RO.
>>>
>>> [Denis] No. Once again: The "*User consent*" is different from what you
>>> call the "*RO consent*" (when/if it is required).
>>> The "RO consent" is not in fact a consent but the release of a
>>> capability to a client by one of the many R0s with which
>>> the GS has relationships.
>>>
>>> Since the second sentence is using the wording "often required" there i=
s
>>>> no requirement to get the User consent.
>>>>
>>> User consent may not be required. There may not be a User. The consent
>>> may have been gathered previously.
>>>
>>> [Denis] In order to follow the privacy principles, a "User consent"
>>> phase is required. The User is a natural person.
>>> A Client is called either by a User (i.e. a natural person) or by a
>>> Client application.
>>>
>>> The second sentence does not consider the possibility to get the User
>>>> consent in a place different from the GS.
>>>>
>>> Agreed. But we do agree that the GS gets the consent, either directly
>>> from the RO, or from the Client (in your example).
>>>
>>> [Denis] No. I disagree. In an ACL based systems, the GS does not need t=
o
>>> ask or receive any consent.
>>> The client selects the set of attributes that it wants to be inserted
>>> into an access token.
>>> If the GS has the requested attributes, then it provides them, otherwis=
e
>>> it returns an error to the Client.
>>>
>>> IMO, the User consent should be captured by the Client, i.e. not by the
>>>> GS.
>>>> The information used to obtain the User consent should be standardized
>>>> (... and it can be standardized).
>>>>
>>>> I think the abstract sequence as proposed by Francis is a great
>>>> addition, and would clarify where consent is in the sequence.
>>>>
>>>> The current sketch does not illustrate the place the User Consent is
>>>> captured, in particular by the Client.
>>>>
>>> It is an abstraction. The GS receives the consent. How consent is
>>> gathered is a detail that is dependent on the use case.
>>>
>>> [Denis] I really wonder whether there is really a "consent" to be
>>> received by the GS in both cases (i.e. ACLs or Capabilities).
>>>
>>>    - For ACLs, the consent needs to be done by the Client.
>>>    - For Capabilities, the current description is not clear since the
>>>    inputs and the outputs for this "consent" phase
>>>    are not currently described in the draft.
>>>
>>>
>>>
>>>>
>>>>
>>>>> Another important point to consider and to explain is related to the
>>>>>> assurances that the user can obtain about
>>>>>> the respect of his choices. This point is currently left unanswered
>>>>>> in draft-hardt-xauth-protocol-13.
>>>>>>
>>>>> This point is equally important: such assurance can only be obtained
>>>>> if the access token returned to the client
>>>>> is not considered to be opaque to the client. This is a necessary
>>>>> condition but not the single condition:
>>>>> the Client must also be in a position to capture/memorize the "User
>>>>> consent and choice" of the user in order to be able
>>>>> to verify it afterwards using the content of the access token(s).
>>>>>
>>>>
>>>> We disagree on this being a requirement for all use cases. It may be i=
n
>>>> some.
>>>>
>>>> OK. Then this means that there will be no sentence in the draft such a=
s
>>>> :
>>>> "access tokens returned to the client are not considered to be opaque
>>>> to the client".
>>>>
>>>
>>> For OAuth use cases, which GNAP supports, the access token is opaque to
>>> the Client. As you have noted, there are use cases where the access tok=
en
>>> is NOT opaque.
>>>
>>> [Denis] Wait a second. There is no requirement to support all OAuth use
>>> cases.
>>> I believe that there is a requirement to support OAuth 2.0 ASs, while
>>> the clients may be different
>>> and hence GNAP clients do not need to inherit of the limitations of
>>> OAuth 2.0 clients.
>>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>> If a RO needs to be involved and since a RO is directly associated
>>>>>>> with a RS, why can't it be directly queried
>>>>>>> by the appropriate RS after step (2) or later on ?
>>>>>>>
>>>>>>
>>>>>> Good question. Perhaps you can expand on a use case where that would
>>>>>> be useful?
>>>>>>
>>>>>> Before I expand, would you be able to explain first under which
>>>>>> circumstances a RO needs to be queried by a GS ?
>>>>>> How can the GS identify which RO to query ?
>>>>>>
>>>>> If the User is the RO, then the GS knows who to query.
>>>>>
>>>>> I still have difficulties to understand what you mean here.
>>>>> How could a GS know that "the User is the RO" ?  If "the User is the
>>>>> RO", why does the GS needs to query the User ?
>>>>>
>>>>
>>>> To get consent?
>>>>
>>>> To get a "RO consent" to himself ???
>>>>
>>>
>>> The GS needs consent from the RO. If the RO is the User, then consent
>>> from the RO is equivalent to consent from the User.
>>>
>>> [Denis] See above.
>>>
>>>
>>>
>>>>
>>>>
>>>>> If the RO is a separate entity, then the GS knows the RO from the RS
>>>>> being queried.
>>>>>
>>>>>  ... and this gives the ability for the GS to log/trace all the RSs
>>>>> accessed by a given User and at which instant of time the access toke=
n has
>>>>> been granted.
>>>>>
>>>>> An example is a user would like access to an enterprise asset where a
>>>>> workflow is started to gain approval, and an administrator or manager
>>>>> provides consent.
>>>>>
>>>>> Thanks for this example. I finally understand what you have in mind:
>>>>> you are considering using an access control model to build a *workflo=
w
>>>>> model*.
>>>>> While it may be interesting to define a workflow model, this should b=
e
>>>>> considered as a *separate and different work item*.
>>>>>
>>>>
>>>> The actual workflow is out of scope.
>>>>
>>>> I am glad you agree with this. But this means that your example was no=
t
>>>> appropriate to illustrate your point.
>>>>
>>>
>>> It illustrates a use case where the RO and User are not the same party,
>>> and why the GS needs to query the RO, which was your question if I
>>> understood it correctly.
>>>
>>> [Denis] Since the inputs and the outputs for this "RO consent" phase ar=
e
>>> not currently described in the draft, the point is still unsolved.
>>>
>>> As soon as there is a RO consent obtained at the GS, the major problem
>>>> is that the GS is able to act as Big Brother.
>>>> If a RO consent is performed at the RS, then the GS will not know who
>>>> the RS is: it is then unable to act as Big Brother,
>>>> even if it would enjoy to play that role.
>>>>
>>> In an enterprise use case, the GS's knowledge of who is accessing which
>>> RS is a feature.
>>>
>>> Do you mean that it is "normal" in an enterprise that a single point of
>>> control is able to trace all their actions ?
>>> From a security point of view, a single point of failure will have
>>> dramatic consequences.
>>>
>>> In your use cases, it seems that the RO is the User.
>>>
>>> I do hope that you have finally understood that, in my use case, the RO
>>> is **not** the User.
>>>
>>> The GS knows the User is wanting to let a Client access something. If
>>> the access token is generic, and could be presented to any RS that prov=
ides
>>> a standardized function,
>>> then the GS does not know which RS is being accessed by a Client for th=
e
>>> User. This seems to meet your privacy objectives. If not, what is wrong=
?
>>>
>>> For security reasons, an access token needs to be targeted (which does
>>> not necessarily mean that an identifier of the RS shall be included int=
o
>>> the access token).
>>>
>>> if the admin grants access, then the access granted to the client
>>>> changes.
>>>>
>>>>> The model you propose may be suited for an enterprise environment but
>>>>> is not scalable over the Internet.
>>>>>
>>>> It is one of the use cases we are working to address.
>>>>
>>>>> What is needed is an access control model usable over the Internet
>>>>> with millions of RSs and thousands of ASs/GSs.
>>>>>
>>>> I agree the model should also scale to internet scale.
>>>>
>>>> Fine. Another point on which we are in agreement.
>>>>
>>>> The model can scale to the Internet based on the following assumptions=
:
>>>>
>>>> The flow starts with the steps (1) to (4) as illustrated by Francis,
>>>> i.e. the flow starts with a contact with a RS.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS |
>>>>  |RO | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Request   =
  |
>>>>    |   |-------->|       |      |      |   |         |(2) Service Inte=
nt
>>>> |   |         |------>|      |      |   |         |(3) AuthZ Challenge=
  |
>>>> |         |<------|      |      |   |         |(4) AuthZ Request    | =
  |
>>>>       |------------->|      |*
>>>>
>>>> The GS/AS does not need to have any prior relationship with ROs and/or
>>>> RSs.
>>>>
>>>> Furthermore, it is possible to prevent the GS to act as Big Brother
>>>> when the identity of the RS is not disclosed to the GS.
>>>>
>>>
>>> What happens after (4) above?
>>>
>>> [Denis] The key point is that we first need to agree on the first four
>>> exchanges. Do we ?
>>>
>>> The fifth exchange is different whether ACLs or Capabilities are being
>>> used.
>>>
>>>
>>>
>>>> Which information is supposed to be presented to the RO ?
>>>>>>> Which information is supposed to be returned by the RO ?
>>>>>>>
>>>>>>
>>>>>> Just like how the user authenticates to an AS, how the AS and RO
>>>>>> communicate is out of scope.
>>>>>>
>>>>>> At the moment, the usefulness of a dialogue between a GS and a RO ha=
s
>>>>>> not been explained, nor demonstrated.
>>>>>> The question is about the functionality of that dialogue in terms of
>>>>>> input and output information (and not about
>>>>>> the design of a protocol or of a user interface). Anyway, AFAIU a
>>>>>> dialogue between a GS and a RO is optional.
>>>>>>
>>>>>
>>>>> See enterprise example above.
>>>>>
>>>>> It is not an access control example, but a workflow example.
>>>>>
>>>>> Access  control has been defined a long time ago and the last edition
>>>>> of the model has been confirmed in year 1996: ISO/IEC 10181-3: 1996.
>>>>> "Information technology =E2=80=94 Open Systems Interconnection =E2=80=
=94 Security
>>>>> frameworks for open systems: Access control framework =E2=80=94 Part =
3".
>>>>>
>>>>> Two major functions have ben defined: an Access Control Enforcement F=
unction
>>>>> (AEF) and an Access Control Decision Function(ADF).
>>>>>
>>>>> Access Control Enforcement Function (AEF):
>>>>> A specialized function that is part of the access path between an
>>>>> initiator and a target on each access request and enforces the decisi=
on
>>>>> made by the ADF.
>>>>> Access Control Decision Function (ADF) :
>>>>> A specialized function that makes access control decisions by applyin=
g
>>>>> access control policy rules to an access request, ADI (of initiators,
>>>>> targets, access requests,
>>>>> or that retained from prior decisions), and the context in which the
>>>>> access request is made.
>>>>>
>>>>> The role of the RO is to define the "access control policy rules" at
>>>>> the RS according to the context in which the access request is made.
>>>>>
>>>> I'm pretty familiar with access control systems. :)
>>>>
>>>> I would say that the access control is happening at the RS. The client
>>>> presents a token when accessing an API.
>>>> The RS uses the token, and any policy required, to make an access
>>>> decision.
>>>>
>>>> Fine. It looks like we are in agreement. Unfortunately, this is not th=
e
>>>> case just below.
>>>>
>>>> Here is flow:
>>>>
>>>> 1) The Client requests access to an RS from the GS.
>>>>
>>>> No. We are no more in agreement. This is different from the flow drawn
>>>> by Francis.
>>>>
>>> My bad. Typo. I meant RO.
>>>
>>>
>>>> 2) The GS queries the RS if access should be granted.
>>>>
>>>>  No. The GS should not be forced to have a flow with the RS.
>>>>
>>> Same mistake as above, I meant RO.
>>>
>>>> 3) If access is granted, the GS creates an access token representing
>>>> the granted access, and returns it to the Client.
>>>>
>>>> This model is by no way conformant to ISO/IEC 10181-3: 1996
>>>>
>>> I'm unclear on why, or why it is even relevant.
>>>
>>>> 4) The Client presents the access token to the RS to show it has been
>>>> granted access.
>>>>
>>>> No. The client presents a token when accessing an API. The RS uses the
>>>> token, and any policy required, to make an access decision.
>>>> The token never contains an information like "Please grant an access t=
o
>>>> the holder of this token".
>>>>
>>> Let me provide more clarity in the sentence:
>>>
>>> The Client presents the access token to the RS, to show the RS that the
>>> Client has been granted access to a resource at the RS by the GS.
>>>
>>> [Denis] This time, please consider both the ACLs approach and the
>>> Capabilities approach.
>>>
>>>
>>>
>>>> A couple advantages of this model:
>>>> - that the RS does not need to know much, if anything about the Client=
.
>>>> - the access token MAY be self contained so that the Client does not
>>>> need to query the GS on each access.
>>>>
>>>> There are so many disadvantages that I will not list them.
>>>>
>>> Darn: I clearly was not firing on all cylinders when I typed this out.
>>> Let me correct:
>>>
>>> - the access token MAY be self contained so that the RS does not need t=
o
>>> query the GS on each access to the RS by the Client.
>>>
>>> [Denis] A few comments in the case of a capability approach:
>>>
>>> - for each GS, the RS needs to locally manage which operation(s) is/are
>>> allowed to it.
>>>
>>> - the GS needs to establish a trusted communication channel or an
>>> authentication mechanism with each RO
>>>    (which is associated with an explicit RS identifier).
>>>
>>> - the GS could play the role of the RO and hence be in a position to
>>> issue any capability for any RS (without a "RO consent").
>>>
>>>    The target of an attack will clearly be the GS.
>>>
>>> I would not say that GNAP is an access control protocol, as how the RS
>>>> uses the token to determine access is out of scope.
>>>>
>>>> This is where we have a major discrepancy: how the RS uses the token
>>>> to determine access is *within* the scope.
>>>>
>>> [Denis] Do you agree or disagree ?
>>>
>>> The RS announces in advance to the client what it needs so that the
>>>> client can perform a a given operation and if the client supplies the
>>>> requested attributes
>>>> obtained from some GS/AS(s) trusted by the RS, then access to that RS
>>>> is granted by the RS. If the RS cannot perform the requested operation=
 on
>>>> its own,
>>>> then the client should be informed about some requested attributes tha=
t
>>>> need to be obtained from some GS/AS(s) trusted by the next RS(s) in a =
chain
>>>> for subsequent operations. The User consent should also be obtained
>>>> before performing the chaining operation.
>>>>
>>>> Chaining operations between RSs over the Internet is within the scope
>>>> (... and may be achieved).
>>>>
>>> [Denis] Do you agree or disagree ?
>>>
>>> Denis
>>>
>>>
>>>>>
>>>>>> For many use cases, the User is the RO, and the interaction is
>>>>>> through a user interface, not a machine protocol.
>>>>>>
>>>>>> Wait a second. You wrote "the User is the RO". The User is attemptin=
g
>>>>>> to make an access to a RS by using a Client.
>>>>>> *That* User is not the RO of the RS.
>>>>>>
>>>>> The user being the RO is the initial use case for OAuth.
>>>>>
>>>>> OAuth 2.0 is no more mandating such a case.
>>>>>
>>>>
>>>> I don't know what you mean by that.
>>>>
>>>> Copy and paste from draft-ietf-oauth-security-topics:
>>>>
>>>> OAuth initially assumed a static relationship between client,
>>>> authorization server and resource servers.  (...)
>>>> With the increasing adoption of OAuth, this simple model dissolved and=
,
>>>> in several scenarios, was replaced
>>>> by a dynamic establishment of the relationship between clients on one
>>>> side and the authorization and
>>>> resource servers of a particular deployment on the other side.
>>>>
>>>> This way, the same client could be used to access services of differen=
t
>>>> providers (in case of standard APIs,
>>>> such as e-mail or OpenID Connect) or serve as a frontend to a
>>>> particular tenant in a multi-tenancy environment.
>>>>
>>>>
>>> This sentence does not mention the RO or the Client. I'm confused what
>>> we are talking about
>>>
>>>>
>>>>
>>>>> A client application would like access to the user's photos at a phot=
o
>>>>> sharing site. The resource is the user's photos. The user is the owne=
r of
>>>>> that resource.
>>>>>
>>>>> If the user has already pre established the access control policy
>>>>> rules so that it can access to his own photos
>>>>> then he does not need to grant in real time any additional
>>>>> authorization.
>>>>>
>>>> I don't understand what you are trying to say. The photo sharing
>>>> example was a driving use case for the creation of OAuth.
>>>>
>>>> We would need to revisit the original scenario and consider if it can
>>>> be addressed in a different way than the original way.
>>>>
>>> The use case is the same. Is there a different solution you are
>>> proposing?
>>>
>>>
>>>
>>> --
>>> Txauth mailing 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
>
>
>

--00000000000028b79605ab34bb44
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis

I would think in your example =
below, that the University's=C2=A0registration system is the Client, no=
t a Resource Server.

Have a good night's sleep=
!



<=
div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 24, 2020 at 12:04 PM Denis=
 <denis.ietf@free.fr> wrote=
:


--00000000000028b79605ab34bb44--


From nobody Fri Jul 24 12:42: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 736933A0AA6 for ; Fri, 24 Jul 2020 12:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 vzXu1cplgwVb for ; Fri, 24 Jul 2020 12:42:36 -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 C011C3A0AA1 for ; Fri, 24 Jul 2020 12:42:35 -0700 (PDT)
Received: from [192.168.1.3] (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 06OJgT1b005562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Jul 2020 15:42:29 -0400
From: Justin Richer 
Message-Id: <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BC36E589-DDF9-4F6D-8768-EC701EC5B3CB"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 24 Jul 2020 15:42:28 -0400
In-Reply-To: 
Cc: Francis Pouatcha , txauth@ietf.org, Tom Jones , Denis 
To: Dick Hardt 
References:               
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 19:42:39 -0000

--Apple-Mail=_BC36E589-DDF9-4F6D-8768-EC701EC5B3CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes, I do think we need to worry about it to the extent that we are not =
creating something that is over-fit to a limited set of use cases.=20

GNAP should be a foundation that many amazing new things can be built on =
top of.

 =E2=80=94 Justin

> On Jul 24, 2020, at 3:06 PM, Dick Hardt  wrote:
>=20
> Justin, thanks for clarifying.
>=20
> What are some examples of other "direct data" that the GS may return? =
If it is not in core GNAP, do we need to worry about now? We can then =
give the direct data from the GS that is not a claim, an appropriate =
name in that document.
>=20
>=20
>=20
> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer > wrote:
> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m =
saying. I agree that =E2=80=9Cclaims=E2=80=9D are about the user, in =
this context*. But the AS could return other data directly to the client =
that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=
=80=9D by the classical definition. Also since =E2=80=9Cclaims=E2=80=9D =
can come back from places other than directly, then we shouldn=E2=80=99t =
call everything that comes back a =E2=80=9Cclaim=E2=80=9D.
>=20
> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean what =
it already means and come up with a new word to mean =E2=80=9Cthings =
that come back directly from the AS=E2=80=9D. These aren=E2=80=99t meant =
to replace Francis=E2=80=99s more complete definitions, but to simplify:
>=20
> Claims:
> 	- information about the user
> 	- can come back directly from the AS
> 	- can come back in a resource from the RS
>=20
> Resource:
> 	- Returned from an RS
> 	- Protected by access token
> 	- Could contain claims about the user
>=20
> Direct data (or some better name):
> 	- Returned directly from AS
> 	- Could contain claims about the user
>=20
> I think the problem is that some people are using =E2=80=9Cclaims=E2=80=9D=
 to mean #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: =
It=E2=80=99s important to remember, when talking about OIDC, that an IdP =
in OIDC combines an AS and an RS into one entity for identity =
information. There can be other RS=E2=80=99s as well, and there usually =
are in the wild, but the one defined by OIDC is the UserInfo Endpoint. =
The fact that it returns user data doesn=E2=80=99t make it any less of =
an RS.
>=20
>  =E2=80=94 Justin
>=20
> * In the wider context of things like the information claims inside a =
JWT, the claims could be about literally anything, but that=E2=80=99s =
not what we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99=
s being used.
>=20
>=20
>> On Jul 24, 2020, at 1:24 PM, Dick Hardt > wrote:
>>=20
>> In OpenID Connect (OIDC), the Client can obtain Claims directly from =
the OP in an ID Token, or the Client can obtain Claims using an access =
token to call the UserInfo endpoint, a Protected Resource[1].
>>=20
>> The Claims are about the User (not a RO).
>>=20
>> In XAuth, I'm proposing the Client may obtain bare claims from the GS =
directly in addition to the mechanisms in ODIC.
>>=20
>> So I don't think we are changing the definition of Claim from how it =
has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>=20
>> Justin: you allude to Claims being about a party other than the User. =
Would you provide an example?
>>=20
>> /Dick
>>=20
>> [1]
>> UserInfo Endpoint
>> Protected Resource that, when presented with an Access Token by the =
Client, returns authorized information about the End-User represented by =
the corresponding Authorization Grant. The UserInfo Endpoint URL MUST =
use the https scheme and MAY contain port, path, and query parameter =
components.
>>=20
>>=20
>>=20
>> =E1=90=A7
>>=20
>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer > wrote:
>> I want to focus on one aspect here:
>>=20
>>>=20
>>> A Claim is a well understood term in the field. We should use it. It =
is still a Claim if it comes directly from the GS or from an RS.=20
>>> I do not understand why a Resource release by an RS shall be h to as =
a claim, even if the content of the Resource is an assertion. It will =
lead to confusion. If we limit claims to information GS releases into =
Token, User Info, and other objects it returns, this will help separate =
responsibilities between GS and RS. As soon as RS services and =
information, this is called a Resource, no matter the nature of the =
content of that information.
>>=20
>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=E2=
=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=
=9D could come back through an RS =E2=80=94 but in the context of GNAP, =
that makes it a resource. So we need a different word for data coming =
back directly from the AS to the client. Sometimes it=E2=80=99s going to =
be about the user, and that=E2=80=99s what we=E2=80=99re going to focus =
on here, but since you can also get information about the user from a =
resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I =
think this has been at the heart of a lot of confusion in recent =
threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.
>>=20
>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already =
does, and let=E2=80=99s find a way to differentiate between when an =
item, claim or otherwise,  comes as part of a resource and when it comes =
back directly. This is an important differentiating feature for GNAP.
>>=20
>> Some straw man ideas, none of which I=E2=80=99m particularly in love =
with:
>>=20
>>  - direct data
>>  - properties
>>  - details
>>  - statements
>>=20
>> The important thing here is that it=E2=80=99s not necessarily :about: =
the RO, and that it is :not: in a resource.
>>=20
>> Any other thoughts?
>>=20
>>  =E2=80=94 Justin
>=20


--Apple-Mail=_BC36E589-DDF9-4F6D-8768-EC701EC5B3CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes, =
I do think we need to worry about it to the extent that we are not =
creating something that is over-fit to a limited set of use =
cases. 

GNAP =
should be a foundation that many amazing new things can be built on top =
of.

 =E2=80=94 Justin

On Jul =
24, 2020, at 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, thanks for =
clarifying.

What are =
some examples of other "direct data" that the GS may return? If it is =
not in core GNAP, do we need to worry about now? We can then give the =
direct data from the GS that is not a claim, an appropriate name in that =
document.



On Fri, Jul 24, 2020 at 11:46 AM Justin =
Richer <jricher@mit.edu> wrote:
Dick: No, I think you=E2=80=99re =
misunderstanding what I=E2=80=99m saying. I agree that =E2=80=9Cclaims=E2=80=
=9D are about the user, in this context*. But the AS could return other =
data directly to the client that isn=E2=80=99t about the user. Those =
aren=E2=80=99t =E2=80=9Cclaims=E2=80=9D by the classical definition. =
Also since =E2=80=9Cclaims=E2=80=9D can come back from places other than =
directly, then we shouldn=E2=80=99t call everything that comes back a =
=E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to =
mean what it already means and come up with a new word to mean =E2=80=9Cth=
ings that come back directly from the AS=E2=80=9D. These aren=E2=80=99t =
meant to replace Francis=E2=80=99s more complete definitions, but to =
simplify:

Claims:
	- information =
about the user
	- can come back directly from the AS
	- =
can come back in a resource from the RS

Resource:
	- Returned from =
an RS
	- Protected by access token
	- =
Could contain claims about the user

Direct data (or some better =
name):
	- Returned directly from AS
	- =
Could contain claims about the user

I think the problem is that some people =
are using =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. =
It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s important to =
remember, when talking about OIDC, that an IdP in OIDC combines an AS =
and an RS into one entity for identity information. There can be other =
RS=E2=80=99s as well, and there usually are in the wild, but the one =
defined by OIDC is the UserInfo Endpoint. The fact that it returns user =
data doesn=E2=80=99t make it any less of an RS.

 =E2=80=94 Justin

* In the wider context =
of things like the information claims inside a JWT, the claims could be =
about literally anything, but that=E2=80=99s not what we=E2=80=99re =
discussing here and it=E2=80=99s not how it=E2=80=99s being =
used.


On Jul =
24, 2020, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

In OpenID Connect (OIDC), the =
Client can obtain Claims directly from the OP in an ID Token, or the =
Client can obtain Claims using an access token to call the UserInfo =
endpoint, a Protected Resource[1].

The Claims are about the User (not a =
RO).

In XAuth, =
I'm proposing the Client may obtain bare claims from the GS directly in =
addition to the mechanisms in ODIC.

So I don't think we are changing the =
definition of Claim from how it has been used in OIDC, and I fail to see =
any reason to NOT use Claim.

Justin: you allude to Claims being =
about a party other than the User. Would you provide an =
example?

/Dick

[1]
UserInfo =
Endpoint
Protected Resource that, when presented =
with an Access Token by the Client, returns authorized information about =
the End-User represented by the corresponding Authorization Grant. The =
UserInfo Endpoint URL MUST use the https scheme and MAY contain port, =
path, and query parameter components.



3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on =
one aspect here:


A Claim is a well =
understood term in the field. We should use it. It is still a Claim if =
it comes directly from the GS or from an =
RS. 
I do not understand =
why a Resource release by an RS shall be h to as a claim, even if the =
content of the Resource is an assertion. It will lead to confusion. If =
we limit claims to information GS releases into Token, User Info, and =
other objects it returns, this will help separate responsibilities =
between GS and RS. As soon as RS services and information, this is =
called a Resource, no matter the nature of the content of that =
information.

This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =
=E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in =
the context of GNAP, that makes it a resource. So we need a different =
word for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s going to be about the user, and that=E2=80=99s what we=E2=80=99=
re going to focus on here, but since you can also get information about =
the user from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=
=80=9D. I think this has been at the heart of a lot of confusion in =
recent threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=
=9D mean what it already does, and let=E2=80=99s find a way to =
differentiate between when an item, claim or otherwise,  comes =
as part of a resource and when it comes back directly. This is an =
important differentiating feature for GNAP.

Some straw man ideas, none of which =
I=E2=80=99m particularly in love with:

 - direct data
 - properties
 - =
details
 - statements

The important thing here is that it=E2=80=
=99s not necessarily :about: the RO, and that it is :not: in a =
resource.

Any other =
thoughts?

 =E2=80=94 Justin





=

--Apple-Mail=_BC36E589-DDF9-4F6D-8768-EC701EC5B3CB--


From nobody Fri Jul 24 12:58:43 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 83AEA3A0AE8 for ; Fri, 24 Jul 2020 12:58:41 -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 VhUpA0peGvJn for ; Fri, 24 Jul 2020 12:58:39 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450: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 08CC63A0AE7 for ; Fri, 24 Jul 2020 12:58:39 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id s9so5824386lfs.4 for ; Fri, 24 Jul 2020 12:58: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=WLkWi7gznqUpZTL1hTDj04F4Cd8TlhdwpjnDNC/T7D8=; b=OMxJgH7pC0YW3yFLP6LtQFE1q4QbSAeNKIUiyyTtb/gnDZSSNnfzFHpY5k9oDMZVBV zVNEzJ55xUJOxvEabt/Du/J8tdynsmkk4WPXm8IsJCHln2e6GdBD9/F8jDG6RZ4MTVGd +SnRDnLJCDcV9lOsoZheb7VtOlTSWwd/S7gUnS8Pj+NpBeR23mWMMUjrNo5O/rUaBVsD EK8g1VkTNfQwTEfCeMGeQDDuDh8JJbv88Jwog/RF262nhu9eUZnJIjMsphZ+83AxuutC sz8DzHBv+MWYiioQU8ftmmBx6uDtJwrQlDQcp2StwcdBv90v8y9ug2t9upqy0ziLFbBl H6Mw==
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=WLkWi7gznqUpZTL1hTDj04F4Cd8TlhdwpjnDNC/T7D8=; b=IcRzMCPkpxBXtsnudOmuPm24Rzk7pntvpC/soFYNU7EmBG7o+vFQQh6tSLDRcEp4Zb lCfijyqt69Fysa0px5gdLJcPjjAkPzNZuBCYfh+BXS2/vsJe7j3lc7uU8cyra1DKKIcF Ls5XQIuBe0mHnYrLTNb2flT+/5xssiVB0uQ5VY5ZRqxL/KXerANxOejcOlj7MMw5Vcvz V6cGHBrzkwnvKPNLX9BY9+y9wdsLFuOQYHB8vfg77iB7xUMxVhejD3snm+lhaAt65CSu +Lonp3qvcBs6jSe+tIJz3GbuK++FQ8drjaPBGDrf4o3DZroPwVELsda2WGgYor1X1/od PBFg==
X-Gm-Message-State: AOAM5339hPTjiNbEXbpQLDpYhpF0r438O+eNPQVjCVy15JioSRynPQqT b4hqt5V5f4OX3hDagk92Dh6rIxo4Z0PPhv0DeGw=
X-Google-Smtp-Source: ABdhPJzdGJvkXRZT7+UgoZCcM/fWwTWq5BvaH9vuRU9nNCU09VXzS6L5IWwIC6IW9zasgzDcKi5ns7P8JZTlXXq61KA=
X-Received: by 2002:ac2:5f48:: with SMTP id 8mr5737765lfz.157.1595620716977; Fri, 24 Jul 2020 12:58:36 -0700 (PDT)
MIME-Version: 1.0
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>
In-Reply-To: <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>
From: Dick Hardt 
Date: Fri, 24 Jul 2020 12:58:00 -0700
Message-ID: 
To: Justin Richer 
Cc: Francis Pouatcha , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="0000000000000823c305ab35669c"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 19:58:42 -0000

--0000000000000823c305ab35669c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree we want GNAP to be a strong foundation.

Do you have an example of other "direct data"? If so, do you expect it to
be defined in the core protocol?

I would expect an extension for other "direct data" to define top level
objects, and an appropriate definition for that "direct data".

My "do we need to worry about it now" comment was on creating a generic
term for "direct data". Unless we are solving those now, we can let further
work define that "direct data" explicitly.




=E1=90=A7

On Fri, Jul 24, 2020 at 12:42 PM Justin Richer  wrote:

> Yes, I do think we need to worry about it to the extent that we are not
> creating something that is over-fit to a limited set of use cases.
>
> GNAP should be a foundation that many amazing new things can be built on
> top of.
>
>  =E2=80=94 Justin
>
> On Jul 24, 2020, at 3:06 PM, Dick Hardt  wrote:
>
> Justin, thanks for clarifying.
>
> What are some examples of other "direct data" that the GS may return? If
> it is not in core GNAP, do we need to worry about now? We can then give t=
he
> direct data from the GS that is not a claim, an appropriate name in that
> document.
>
>
>
> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer  wrote:
>
>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m sayin=
g. I agree that
>> =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But the A=
S could return
>> other data directly to the client that isn=E2=80=99t about the user. Tho=
se aren=E2=80=99t
>> =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=80=
=9Cclaims=E2=80=9D can come back
>> from places other than directly, then we shouldn=E2=80=99t call everythi=
ng that
>> comes back a =E2=80=9Cclaim=E2=80=9D.
>>
>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean what i=
t already means and come
>> up with a new word to mean =E2=80=9Cthings that come back directly from =
the AS=E2=80=9D.
>> These aren=E2=80=99t meant to replace Francis=E2=80=99s more complete de=
finitions, but to
>> simplify:
>>
>> Claims:
>> - information about the user
>> - can come back directly from the AS
>> - can come back in a resource from the RS
>>
>> Resource:
>> - Returned from an RS
>> - Protected by access token
>> - Could contain claims about the user
>>
>> Direct data (or some better name):
>> - Returned directly from AS
>> - Could contain claims about the user
>>
>> I think the problem is that some people are using =E2=80=9Cclaims=E2=80=
=9D to mean #1 and
>> some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s impo=
rtant to remember,
>> when talking about OIDC, that an IdP in OIDC combines an AS and an RS in=
to
>> one entity for identity information. There can be other RS=E2=80=99s as =
well, and
>> there usually are in the wild, but the one defined by OIDC is the UserIn=
fo
>> Endpoint. The fact that it returns user data doesn=E2=80=99t make it any=
 less of an
>> RS.
>>
>>  =E2=80=94 Justin
>>
>> * In the wider context of things like the information claims inside a
>> JWT, the claims could be about literally anything, but that=E2=80=99s no=
t what
>> we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s bein=
g used.
>>
>>
>> On Jul 24, 2020, at 1:24 PM, Dick Hardt  wrote:
>>
>> In OpenID Connect (OIDC), the Client can obtain Claims directly from the
>> OP in an ID Token, or the Client can obtain Claims using an access token=
 to
>> call the UserInfo endpoint, a Protected Resource[1].
>>
>> The Claims are about the User (not a RO).
>>
>> In XAuth, I'm proposing the Client may obtain bare claims from the GS
>> directly in addition to the mechanisms in ODIC.
>>
>> So I don't think we are changing the definition of Claim from how it has
>> been used in OIDC, and I fail to see any reason to NOT use Claim.
>>
>> Justin: you allude to Claims being about a party other than the User.
>> Would you provide an example?
>>
>> /Dick
>>
>> [1]
>>
>> UserInfo Endpoint
>> Protected Resource that, when presented with an Access Token by the
>> Client, returns authorized information about the End-User represented by
>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST us=
e
>> the https scheme and MAY contain port, path, and query parameter compone=
nts.
>>
>>
>>
>>
>> =E1=90=A7
>>
>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote:
>>
>>> I want to focus on one aspect here:
>>>
>>>
>>>> A Claim is a well understood term in the field. We should use it. It i=
s
>>>> still a Claim if it comes directly from the GS or from an RS.
>>>>
>>> I do not understand why a Resource release by an RS shall be h to as a
>>> claim, even if the content of the Resource is an assertion. It will lea=
d to
>>> confusion. If we limit claims to information GS releases into Token, Us=
er
>>> Info, and other objects it returns, this will help separate
>>> responsibilities between GS and RS. As soon as RS services and informat=
ion,
>>> this is called a Resource, no matter the nature of the content of that
>>> information.
>>>
>>>
>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=
=E2=80=9D in the way that
>>> we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back =
through an RS =E2=80=94 but in the
>>> context of GNAP, that makes it a resource. So we need a different word =
for
>>> data coming back directly from the AS to the client. Sometimes it=E2=80=
=99s going
>>> to be about the user, and that=E2=80=99s what we=E2=80=99re going to fo=
cus on here, but
>>> since you can also get information about the user from a resource we ca=
n=E2=80=99t
>>> just call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the he=
art of a lot of
>>> confusion in recent threads, as well as confusion about the scope of th=
e
>>> inclusion of identity in the GNAP protocol.
>>>
>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does,=
 and let=E2=80=99s find a way to
>>> differentiate between when an item, claim or otherwise,  comes as part =
of a
>>> resource and when it comes back directly. This is an important
>>> differentiating feature for GNAP.
>>>
>>> Some straw man ideas, none of which I=E2=80=99m particularly in love wi=
th:
>>>
>>>  - direct data
>>>  - properties
>>>  - details
>>>  - statements
>>>
>>> The important thing here is that it=E2=80=99s not necessarily :about: t=
he RO,
>>> and that it is :not: in a resource.
>>>
>>> Any other thoughts?
>>>
>>>  =E2=80=94 Justin
>>>
>>
>>
>

--0000000000000823c305ab35669c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I agree we want GNAP to be a strong foundation.=C2=A0
=

Do you have an example of other "direct data"? If =
so, do you expect it to be defined in the core protocol?

I would expect an extension for other "direct data" to def=
ine top level objects, and an appropriate definition for that "direct =
data".

My "do we need to worry about it =
now" comment was on creating a generic term for "direct data"=
;. Unless we are solving those now, we can let further work define that &qu=
ot;direct data" explicitly.



3D""=E1=90=A7

On Fri, Jul 24, 2020=
 at 12:42 PM Justin Richer <jricher@m=
it.edu> wrote:
Yes, I do think we need to =
worry about it to the extent that we are not creating something that is ove=
r-fit to a limited set of use cases.=C2=A0

GNAP should b=
e a foundation that many amazing new things can be built on top of.

=C2=A0=E2=80=94 Justin

On Jul 24, 2020, at 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
=

Justin, thanks for clarifying.

What are some examples of other "direct data" that the GS may re=
turn? If it is not in core GNAP, do we need to worry about now? We can then=
 give the direct data from the GS that is not a claim, an appropriate name =
in that document.



On Fri, Jul 24, 2020=
 at 11:46 AM Justin Richer <jricher@mit.edu> wrote:
Dick: No, I think you=E2=80=99re misunderstand=
ing what I=E2=80=99m saying. I agree that =E2=80=9Cclaims=E2=80=9D are abou=
t the user, in this context*. But the AS could return other data directly t=
o the client that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=
=9Cclaims=E2=80=9D by the classical definition. Also since =E2=80=9Cclaims=
=E2=80=9D can come back from places other than directly, then we shouldn=E2=
=80=99t call everything that comes back a =E2=80=9Cclaim=E2=80=9D.

=

I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mea=
n what it already means and come up with a new word to mean =E2=80=9Cthings=
 that come back directly from the AS=E2=80=9D. These aren=E2=80=99t meant t=
o replace Francis=E2=80=99s more complete definitions, but to simplify:

Claims:
	- information about the user
	- can come back directly from the AS
	- can come back in a resource from the =
RS

Resource:
	- Returned from an RS
	- Protected by access token
	- Could contain claims about the user

Direct data (or some better name):
	- Returned directly from AS
	- Could contain claims about the use=
r

I think the problem is that some people are usin=
g =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. It=E2=80=99s cle=
arly #1 in OIDC. But: It=E2=80=99s important to remember, when talking abou=
t OIDC, that an IdP in OIDC combines an AS and an RS into one entity for id=
entity information. There can be other RS=E2=80=99s as well, and there usua=
lly are in the wild, but the one defined by OIDC is the UserInfo Endpoint. =
The fact that it returns user data doesn=E2=80=99t make it any less of an R=
S.

=C2=A0=E2=80=94 Justin

* In =
the wider context of things like the information claims inside a JWT, the c=
laims could be about literally anything, but that=E2=80=99s not what we=E2=
=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s being used.<=
/div>


On Jul 24, 2020, at 1=
:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

In=
 OpenID Connect (OIDC), the Client can obtain Claims directly from the OP i=
n an ID Token, or the Client can obtain Claims using an access token to cal=
l the UserInfo endpoint, a Protected Resource[1].

The Cl=
aims are about the User (not a RO).

In XAuth, I=
9;m proposing the Client may obtain bare claims from the GS directly in add=
ition to the mechanisms in ODIC.

So I don't th=
ink we are changing the definition of Claim from how it has been used in OI=
DC, and I fail to see any reason to NOT use Claim.

Justin: you allude to Claims being about a party other than the User. Woul=
d you provide an example?

/Dick

[1]
UserInfo Endpoint
Protected Resource that, when p=
resented with an Access Token by the Client, returns authorized information=
 about the End-User represented by the corresponding Authorization Grant. T=
he UserInfo Endpoint URL MUST use the https scheme and MAY contain port, pa=
th, and query parameter components.

<=
br>

3D""=E1=90=A7

On Fri, Jul 24=
, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspect here:
<=
br>
=


A Claim is a well understood term in the field. We shou=
ld use it. It is still a Claim if it comes directly from the GS or from an =
RS.=C2=A0
I do not understand why a Resource r=
elease by an RS shall be h to as a claim, even if the content of the Resour=
ce is an assertion. It will lead to confusion. If we limit claims to inform=
ation GS releases into Token, User Info, and other objects it returns, this=
 will help separate responsibilities between GS and RS. As soon as RS servi=
ces and information, this is called a Resource, no matter the nature of the=
 content of that information.

This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclai=
m=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=
=80=9D could come back through an RS =E2=80=94 but in the context of GNAP, =
that makes it a resource. So we need a different word for data coming back =
directly from the AS to the client. Sometimes it=E2=80=99s going to be abou=
t the user, and that=E2=80=99s what we=E2=80=99re going to focus on here, b=
ut since you can also get information about the user from a resource we can=
=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at=
 the heart of a lot of confusion in recent threads, as well as confusion ab=
out the scope of the inclusion of identity in the GNAP protocol.
=

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it al=
ready does, and let=E2=80=99s find a way to differentiate between when an i=
tem, claim or otherwise,=C2=A0=C2=A0comes as part of a resource and when it=
 comes back directly. This is an important differentiating feature for GNAP=
.

Some straw man ideas, none of which I=E2=80=99m =
particularly in love with:

=C2=A0- direct data
=C2=A0- properties
=C2=A0- details
=C2=A0- state=
ments

The important thing here is that it=E2=80=99=
s not necessarily :about: the RO, and that it is :not: in a resource.
=


Any other thoughts?

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








--0000000000000823c305ab35669c--


From nobody Fri Jul 24 13:40: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 07B753A0B87 for ; Fri, 24 Jul 2020 13:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 eT_UxQUD1xHh for ; Fri, 24 Jul 2020 13:39:56 -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 BB6393A0B85 for ; Fri, 24 Jul 2020 13:39:55 -0700 (PDT)
Received: from [192.168.1.3] (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 06OKdnsZ023849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Jul 2020 16:39:50 -0400
From: Justin Richer 
Message-Id: <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_767AB839-4187-4664-B87D-D69900CDEF54"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 24 Jul 2020 16:39:49 -0400
In-Reply-To: 
Cc: Francis Pouatcha , txauth@ietf.org, Tom Jones , Denis 
To: Dick Hardt 
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 20:39:59 -0000

--Apple-Mail=_767AB839-4187-4664-B87D-D69900CDEF54
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Since we=E2=80=99re already talking about returning claims as direct =
data as well as a part of the resource API being protected, so we =
already need a way to differentiate the two kinds of items. Just calling =
it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, because as you=E2=80=99v=
e pointed out they could show up in both places. So yes, defining that =
difference is something we should worry about now, even if the core =
protocol only uses it for claims.

The two forms of direct data that XYZ returns are subject identifiers (a =
subset of identity claims) and assertions =E2=80=94 the latter being a =
container not just for identity claims but also authentication =
information and other elements. Assertions are not claims themselves.=20

Other use cases that have been brought up include verifiable credentials =
and proofs, user-bound keys, payment processing information, and =
distributed network storage locations. I=E2=80=99m sure there are a lot =
more. To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D but =
not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be =
defining what all of these look like, but it should define a way to talk =
about them.

I think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=
=9D request, which allows targeting of its claims information into =
different return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D=
 request at the very least. I don=E2=80=99t think GNAP should define how =
to do this specific combination, that should be for OIDF to debate and =
apply. The same with a DID service based query, or Presentation Exchange =
[1], or anything else that people want to come up with.

In my view, GNAP should define query structures for two things: rights =
that get tied to an access token and data that comes back directly to =
the client. For the latter, I think we can do some very limited and very =
useful specific items, which is what I=E2=80=99ve put into XYZ.

 =E2=80=94 Justin

[1] https://identity.foundation/presentation-exchange/

> On Jul 24, 2020, at 3:58 PM, Dick Hardt  wrote:
>=20
> I agree we want GNAP to be a strong foundation.=20
>=20
> Do you have an example of other "direct data"? If so, do you expect it =
to be defined in the core protocol?
>=20
> I would expect an extension for other "direct data" to define top =
level objects, and an appropriate definition for that "direct data".
>=20
> My "do we need to worry about it now" comment was on creating a =
generic term for "direct data". Unless we are solving those now, we can =
let further work define that "direct data" explicitly.
>=20
>=20
>=20
>=20
> =E1=90=A7
>=20
> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer > wrote:
> Yes, I do think we need to worry about it to the extent that we are =
not creating something that is over-fit to a limited set of use cases.=20=

>=20
> GNAP should be a foundation that many amazing new things can be built =
on top of.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 24, 2020, at 3:06 PM, Dick Hardt > wrote:
>>=20
>> Justin, thanks for clarifying.
>>=20
>> What are some examples of other "direct data" that the GS may return? =
If it is not in core GNAP, do we need to worry about now? We can then =
give the direct data from the GS that is not a claim, an appropriate =
name in that document.
>>=20
>>=20
>>=20
>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer > wrote:
>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m =
saying. I agree that =E2=80=9Cclaims=E2=80=9D are about the user, in =
this context*. But the AS could return other data directly to the client =
that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=
=80=9D by the classical definition. Also since =E2=80=9Cclaims=E2=80=9D =
can come back from places other than directly, then we shouldn=E2=80=99t =
call everything that comes back a =E2=80=9Cclaim=E2=80=9D.
>>=20
>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean =
what it already means and come up with a new word to mean =E2=80=9Cthings =
that come back directly from the AS=E2=80=9D. These aren=E2=80=99t meant =
to replace Francis=E2=80=99s more complete definitions, but to simplify:
>>=20
>> Claims:
>> 	- information about the user
>> 	- can come back directly from the AS
>> 	- can come back in a resource from the RS
>>=20
>> Resource:
>> 	- Returned from an RS
>> 	- Protected by access token
>> 	- Could contain claims about the user
>>=20
>> Direct data (or some better name):
>> 	- Returned directly from AS
>> 	- Could contain claims about the user
>>=20
>> I think the problem is that some people are using =E2=80=9Cclaims=E2=80=
=9D to mean #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. =
But: It=E2=80=99s important to remember, when talking about OIDC, that =
an IdP in OIDC combines an AS and an RS into one entity for identity =
information. There can be other RS=E2=80=99s as well, and there usually =
are in the wild, but the one defined by OIDC is the UserInfo Endpoint. =
The fact that it returns user data doesn=E2=80=99t make it any less of =
an RS.
>>=20
>>  =E2=80=94 Justin
>>=20
>> * In the wider context of things like the information claims inside a =
JWT, the claims could be about literally anything, but that=E2=80=99s =
not what we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99=
s being used.
>>=20
>>=20
>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt > wrote:
>>>=20
>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from =
the OP in an ID Token, or the Client can obtain Claims using an access =
token to call the UserInfo endpoint, a Protected Resource[1].
>>>=20
>>> The Claims are about the User (not a RO).
>>>=20
>>> In XAuth, I'm proposing the Client may obtain bare claims from the =
GS directly in addition to the mechanisms in ODIC.
>>>=20
>>> So I don't think we are changing the definition of Claim from how it =
has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>=20
>>> Justin: you allude to Claims being about a party other than the =
User. Would you provide an example?
>>>=20
>>> /Dick
>>>=20
>>> [1]
>>> UserInfo Endpoint
>>> Protected Resource that, when presented with an Access Token by the =
Client, returns authorized information about the End-User represented by =
the corresponding Authorization Grant. The UserInfo Endpoint URL MUST =
use the https scheme and MAY contain port, path, and query parameter =
components.
>>>=20
>>>=20
>>>=20
>>> =E1=90=A7
>>>=20
>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer > wrote:
>>> I want to focus on one aspect here:
>>>=20
>>>>=20
>>>> A Claim is a well understood term in the field. We should use it. =
It is still a Claim if it comes directly from the GS or from an RS.=20
>>>> I do not understand why a Resource release by an RS shall be h to =
as a claim, even if the content of the Resource is an assertion. It will =
lead to confusion. If we limit claims to information GS releases into =
Token, User Info, and other objects it returns, this will help separate =
responsibilities between GS and RS. As soon as RS services and =
information, this is called a Resource, no matter the nature of the =
content of that information.
>>>=20
>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=
=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=
=80=9D could come back through an RS =E2=80=94 but in the context of =
GNAP, that makes it a resource. So we need a different word for data =
coming back directly from the AS to the client. Sometimes it=E2=80=99s =
going to be about the user, and that=E2=80=99s what we=E2=80=99re going =
to focus on here, but since you can also get information about the user =
from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. =
I think this has been at the heart of a lot of confusion in recent =
threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.
>>>=20
>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already =
does, and let=E2=80=99s find a way to differentiate between when an =
item, claim or otherwise,  comes as part of a resource and when it comes =
back directly. This is an important differentiating feature for GNAP.
>>>=20
>>> Some straw man ideas, none of which I=E2=80=99m particularly in love =
with:
>>>=20
>>>  - direct data
>>>  - properties
>>>  - details
>>>  - statements
>>>=20
>>> The important thing here is that it=E2=80=99s not necessarily =
:about: the RO, and that it is :not: in a resource.
>>>=20
>>> Any other thoughts?
>>>=20
>>>  =E2=80=94 Justin
>>=20
>=20


--Apple-Mail=_767AB839-4187-4664-B87D-D69900CDEF54
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Since=
 we=E2=80=99re already talking about returning claims as direct data as =
well as a part of the resource API being protected, so we already need a =
way to differentiate the two kinds of items. Just calling it =
=E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, because as you=E2=80=99ve =
pointed out they could show up in both places. So yes, defining that =
difference is something we should worry about now, even if the core =
protocol only uses it for claims.

The two forms of direct data that XYZ returns are subject =
identifiers (a subset of identity claims) and assertions =E2=80=94 the =
latter being a container not just for identity claims but also =
authentication information and other elements. Assertions are not claims =
themselves. 

Other use cases that have been brought up include verifiable =
credentials and proofs, user-bound keys, payment processing information, =
and distributed network storage locations. I=E2=80=99m sure there are a =
lot more. To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D =
but not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be =
defining what all of these look like, but it should define a way to talk =
about them.

I =
think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=
=9D request, which allows targeting of its claims information into =
different return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D=
 request at the very least. I don=E2=80=99t think GNAP should define how =
to do this specific combination, that should be for OIDF to debate and =
apply. The same with a DID service based query, or Presentation Exchange =
[1], or anything else that people want to come up with.

In my view, GNAP should =
define query structures for two things: rights that get tied to an =
access token and data that comes back directly to the client. For the =
latter, I think we can do some very limited and very useful specific =
items, which is what I=E2=80=99ve put into XYZ.

 =E2=80=
=94 Justin

[1] https://identity.foundation/presentation-exchange/

On Jul 24, 2020, at 3:58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree we want GNAP to be a =
strong foundation. 

Do you have an example of other "direct data"? If so, do you =
expect it to be defined in the core protocol?

I would expect an extension for other =
"direct data" to define top level objects, and an appropriate definition =
for that "direct data".

My "do we need to worry about it now" comment was on creating =
a generic term for "direct data". Unless we are solving those now, we =
can let further work define that "direct data" explicitly.




3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
Yes, I do think we need to worry about it to the =
extent that we are not creating something that is over-fit to a limited =
set of use cases. 

GNAP should be a foundation that many amazing new things can =
be built on top of.

 =E2=80=94 Justin

On Jul 24, 2020, at 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, thanks for =
clarifying.

What are =
some examples of other "direct data" that the GS may return? If it is =
not in core GNAP, do we need to worry about now? We can then give the =
direct data from the GS that is not a claim, an appropriate name in that =
document.



On Fri, Jul 24, 2020 at 11:46 AM Justin =
Richer <jricher@mit.edu> wrote:
Dick: No, I =
think you=E2=80=99re misunderstanding what I=E2=80=99m saying. I agree =
that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But =
the AS could return other data directly to the client that isn=E2=80=99t =
about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=80=9D by the =
classical definition. Also since =E2=80=9Cclaims=E2=80=9D can come back =
from places other than directly, then we shouldn=E2=80=99t call =
everything that comes back a =E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m arguing that we keep =
=E2=80=9Cclaims=E2=80=9D to mean what it already means and come up with =
a new word to mean =E2=80=9Cthings that come back directly from the =
AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s =
more complete definitions, but to simplify:

Claims:
	- information =
about the user
	- can come back directly from the AS
	- =
can come back in a resource from the RS

Resource:
	- Returned from =
an RS
	- Protected by access token
	- =
Could contain claims about the user

Direct data (or some better =
name):
	- Returned directly from AS
	- =
Could contain claims about the user

I think the problem is that some people =
are using =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. =
It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s important to =
remember, when talking about OIDC, that an IdP in OIDC combines an AS =
and an RS into one entity for identity information. There can be other =
RS=E2=80=99s as well, and there usually are in the wild, but the one =
defined by OIDC is the UserInfo Endpoint. The fact that it returns user =
data doesn=E2=80=99t make it any less of an RS.

 =E2=80=94 Justin

* In the wider context =
of things like the information claims inside a JWT, the claims could be =
about literally anything, but that=E2=80=99s not what we=E2=80=99re =
discussing here and it=E2=80=99s not how it=E2=80=99s being =
used.


On Jul =
24, 2020, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

In OpenID Connect (OIDC), the =
Client can obtain Claims directly from the OP in an ID Token, or the =
Client can obtain Claims using an access token to call the UserInfo =
endpoint, a Protected Resource[1].

The Claims are about the User (not a =
RO).

In XAuth, =
I'm proposing the Client may obtain bare claims from the GS directly in =
addition to the mechanisms in ODIC.

So I don't think we are changing the =
definition of Claim from how it has been used in OIDC, and I fail to see =
any reason to NOT use Claim.

Justin: you allude to Claims being =
about a party other than the User. Would you provide an =
example?

/Dick

[1]
UserInfo =
Endpoint
Protected Resource that, when presented =
with an Access Token by the Client, returns authorized information about =
the End-User represented by the corresponding Authorization Grant. The =
UserInfo Endpoint URL MUST use the https scheme and MAY contain port, =
path, and query parameter components.



3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on =
one aspect here:


A Claim is a well =
understood term in the field. We should use it. It is still a Claim if =
it comes directly from the GS or from an =
RS. 
I do not understand =
why a Resource release by an RS shall be h to as a claim, even if the =
content of the Resource is an assertion. It will lead to confusion. If =
we limit claims to information GS releases into Token, User Info, and =
other objects it returns, this will help separate responsibilities =
between GS and RS. As soon as RS services and information, this is =
called a Resource, no matter the nature of the content of that =
information.

This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =
=E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in =
the context of GNAP, that makes it a resource. So we need a different =
word for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s going to be about the user, and that=E2=80=99s what we=E2=80=99=
re going to focus on here, but since you can also get information about =
the user from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=
=80=9D. I think this has been at the heart of a lot of confusion in =
recent threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=
=9D mean what it already does, and let=E2=80=99s find a way to =
differentiate between when an item, claim or otherwise,  comes =
as part of a resource and when it comes back directly. This is an =
important differentiating feature for GNAP.

Some straw man ideas, none of which =
I=E2=80=99m particularly in love with:

 - direct data
 - properties
 - =
details
 - statements

The important thing here is that it=E2=80=
=99s not necessarily :about: the RO, and that it is :not: in a =
resource.

Any other =
thoughts?

 =E2=80=94 Justin








=

--Apple-Mail=_767AB839-4187-4664-B87D-D69900CDEF54--


From nobody Fri Jul 24 13:58: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 706FC3A0BDC for ; Fri, 24 Jul 2020 13:58: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_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 sD0jMZ6jA6fF for ; Fri, 24 Jul 2020 13:58:29 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 E8AD13A0BD3 for ; Fri, 24 Jul 2020 13:58:28 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id x9so11311589ljc.5 for ; Fri, 24 Jul 2020 13:58: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=a6n3s1H3GhabMn7F6NqmKmec6OMMD9ebq+3NwIt9QKg=; b=QRx+Dq9h/W6DgPzJeDkybmDzBeji4IcsKvc8dybQbP/6DJ21qfga7a+BR2NyGw14ra cypa1rnm8vtoIbDCxAJK/rcgpbFOLyYfe4Ytla+BT2b4R8V6wH4PmsuO3dMRFt+pXHeA 87LYjvcf5XWdKmLmq0gOfZchb8MBZk0WmVlaAaRFbWw2VANTDl8TDl6lfAFuzncqCVGm 3teI2OPnrhQ0Fcf0YJHcH6fY+PF74ZQ5sEm4QMWQOG1Cl5L8WbbcbQllNQWfVIJroL6i zhDiUt8Dj47UrWu9CXlKkm3H0mre6ltOeOU3qH+7YON+3y3eB7zXREfzqDeZ2sNwuYWw yEZQ==
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=a6n3s1H3GhabMn7F6NqmKmec6OMMD9ebq+3NwIt9QKg=; b=ccQLn8WZpQOFv71pK8qIsMEZk9dRUDunRTFI7L2WFQnYi2yp14HUujQbalezgOtd/i Fz+spt4qlUSNNDtmmCpuuJpGbKRq2Ueb8/6ZYLW1JoKF4KSHN+Tn2fl7iQtCapiWTW/C AHTI6HHeXAv/GM7BY6mNzvnpvWJ087L8okhWx3ml2hCdr/t2GDdPgbczLdVhldM6WuIv 5aE8Sy4aVSxOSrmvPsnYYo4DUKIwmGAMntfvHzxZcjej3BhJpAHvx0XJh4Q7X4S5RE+T SoFd1DPm2oLmBTtXqa0GjRWfkzXcp9Sk7bkJzcO+4BOB2nsPlvWvteKGRqjDD70LoAsG tCug==
X-Gm-Message-State: AOAM5306zM+yElPbLLsZ9pdFLt2reXX5viuEfP0uFDOHUSL2r2TuILEz 9cUSFXQmHD+DlEYvkA0EPtyo7lZTAkRhVHcdtKo=
X-Google-Smtp-Source: ABdhPJxVV7X/ItMGIZ4ob5K8YdLrG+t8Cge/2UIf5TTGhRf4S1UNlZXa8TK2btYBSBbUyx/+3amTSrgQVVqhv5V5G1Y=
X-Received: by 2002:a2e:80c9:: with SMTP id r9mr5242263ljg.69.1595624306799; Fri, 24 Jul 2020 13:58:26 -0700 (PDT)
MIME-Version: 1.0
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>
In-Reply-To: <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>
From: Dick Hardt 
Date: Fri, 24 Jul 2020 13:57:50 -0700
Message-ID: 
To: Justin Richer 
Cc: Francis Pouatcha , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="000000000000009b5005ab363cb0"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 24 Jul 2020 20:58:32 -0000

--000000000000009b5005ab363cb0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It is not clear to me what it matters if a Claim comes from an RS, or from
the GS, so I don't see a need to differentiate them.

I would include verifiable credentials and user-bound keys as Claims.

All the payment processing information I have seen has been in RAR. When
would the Client get payment processing directly from the GS?

What is your example for distributed networks storage locations? If what is
stored is a statement about the user, then I would consider that a Claim as
well.

We disagree on how to map OIDC to GNAP.  The direct data is a claims
request, the data coming indirectly is an access token request.



On Fri, Jul 24, 2020 at 1:39 PM Justin Richer  wrote:

> Since we=E2=80=99re already talking about returning claims as direct data=
 as well
> as a part of the resource API being protected, so we already need a way t=
o
> differentiate the two kinds of items. Just calling it =E2=80=9Cclaims=E2=
=80=9D doesn=E2=80=99t
> help, because as you=E2=80=99ve pointed out they could show up in both pl=
aces. So
> yes, defining that difference is something we should worry about now, eve=
n
> if the core protocol only uses it for claims.
>
> The two forms of direct data that XYZ returns are subject identifiers (a
> subset of identity claims) and assertions =E2=80=94 the latter being a co=
ntainer
> not just for identity claims but also authentication information and othe=
r
> elements. Assertions are not claims themselves.
>
> Other use cases that have been brought up include verifiable credentials
> and proofs, user-bound keys, payment processing information, and
> distributed network storage locations. I=E2=80=99m sure there are a lot m=
ore. To
> me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D but not subset=
s of =E2=80=9Cclaims=E2=80=9D.
> GNAP shouldn=E2=80=99t be defining what all of these look like, but it sh=
ould
> define a way to talk about them.
>
> I think different top-level request objects are better suited for
> different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=
=80=9D request,
> which allows targeting of its claims information into different return
> buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D request at th=
e very least. I
> don=E2=80=99t think GNAP should define how to do this specific combinatio=
n, that
> should be for OIDF to debate and apply. The same with a DID service based
> query, or Presentation Exchange [1], or anything else that people want to
> come up with.
>
> In my view, GNAP should define query structures for two things: rights
> that get tied to an access token and data that comes back directly to the
> client. For the latter, I think we can do some very limited and very usef=
ul
> specific items, which is what I=E2=80=99ve put into XYZ.
>
>  =E2=80=94 Justin
>
> [1] https://identity.foundation/presentation-exchange/
>
> On Jul 24, 2020, at 3:58 PM, Dick Hardt  wrote:
>
> I agree we want GNAP to be a strong foundation.
>
> Do you have an example of other "direct data"? If so, do you expect it to
> be defined in the core protocol?
>
> I would expect an extension for other "direct data" to define top level
> objects, and an appropriate definition for that "direct data".
>
> My "do we need to worry about it now" comment was on creating a generic
> term for "direct data". Unless we are solving those now, we can let furth=
er
> work define that "direct data" explicitly.
>
>
>
>
> =E1=90=A7
>
> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer  wrote:
>
>> Yes, I do think we need to worry about it to the extent that we are not
>> creating something that is over-fit to a limited set of use cases.
>>
>> GNAP should be a foundation that many amazing new things can be built on
>> top of.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 24, 2020, at 3:06 PM, Dick Hardt  wrote:
>>
>> Justin, thanks for clarifying.
>>
>> What are some examples of other "direct data" that the GS may return? If
>> it is not in core GNAP, do we need to worry about now? We can then give =
the
>> direct data from the GS that is not a claim, an appropriate name in that
>> document.
>>
>>
>>
>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer  wrote:
>>
>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m sayi=
ng. I agree that
>>> =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But the =
AS could return
>>> other data directly to the client that isn=E2=80=99t about the user. Th=
ose aren=E2=80=99t
>>> =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=80=
=9Cclaims=E2=80=9D can come back
>>> from places other than directly, then we shouldn=E2=80=99t call everyth=
ing that
>>> comes back a =E2=80=9Cclaim=E2=80=9D.
>>>
>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean what =
it already means and come
>>> up with a new word to mean =E2=80=9Cthings that come back directly from=
 the AS=E2=80=9D.
>>> These aren=E2=80=99t meant to replace Francis=E2=80=99s more complete d=
efinitions, but to
>>> simplify:
>>>
>>> Claims:
>>> - information about the user
>>> - can come back directly from the AS
>>> - can come back in a resource from the RS
>>>
>>> Resource:
>>> - Returned from an RS
>>> - Protected by access token
>>> - Could contain claims about the user
>>>
>>> Direct data (or some better name):
>>> - Returned directly from AS
>>> - Could contain claims about the user
>>>
>>> I think the problem is that some people are using =E2=80=9Cclaims=E2=80=
=9D to mean #1
>>> and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s=
 important to
>>> remember, when talking about OIDC, that an IdP in OIDC combines an AS a=
nd
>>> an RS into one entity for identity information. There can be other RS=
=E2=80=99s as
>>> well, and there usually are in the wild, but the one defined by OIDC is=
 the
>>> UserInfo Endpoint. The fact that it returns user data doesn=E2=80=99t m=
ake it any
>>> less of an RS.
>>>
>>>  =E2=80=94 Justin
>>>
>>> * In the wider context of things like the information claims inside a
>>> JWT, the claims could be about literally anything, but that=E2=80=99s n=
ot what
>>> we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s bei=
ng used.
>>>
>>>
>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt  wrote:
>>>
>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from th=
e
>>> OP in an ID Token, or the Client can obtain Claims using an access toke=
n to
>>> call the UserInfo endpoint, a Protected Resource[1].
>>>
>>> The Claims are about the User (not a RO).
>>>
>>> In XAuth, I'm proposing the Client may obtain bare claims from the GS
>>> directly in addition to the mechanisms in ODIC.
>>>
>>> So I don't think we are changing the definition of Claim from how it ha=
s
>>> been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>
>>> Justin: you allude to Claims being about a party other than the User.
>>> Would you provide an example?
>>>
>>> /Dick
>>>
>>> [1]
>>>
>>> UserInfo Endpoint
>>> Protected Resource that, when presented with an Access Token by the
>>> Client, returns authorized information about the End-User represented b=
y
>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST u=
se
>>> the https scheme and MAY contain port, path, and query parameter compon=
ents.
>>>
>>>
>>>
>>>
>>> =E1=90=A7
>>>
>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote:
>>>
>>>> I want to focus on one aspect here:
>>>>
>>>>
>>>>> A Claim is a well understood term in the field. We should use it. It
>>>>> is still a Claim if it comes directly from the GS or from an RS.
>>>>>
>>>> I do not understand why a Resource release by an RS shall be h to as a
>>>> claim, even if the content of the Resource is an assertion. It will le=
ad to
>>>> confusion. If we limit claims to information GS releases into Token, U=
ser
>>>> Info, and other objects it returns, this will help separate
>>>> responsibilities between GS and RS. As soon as RS services and informa=
tion,
>>>> this is called a Resource, no matter the nature of the content of that
>>>> information.
>>>>
>>>>
>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=
=E2=80=9D in the way that
>>>> we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back=
 through an RS =E2=80=94 but in the
>>>> context of GNAP, that makes it a resource. So we need a different word=
 for
>>>> data coming back directly from the AS to the client. Sometimes it=E2=
=80=99s going
>>>> to be about the user, and that=E2=80=99s what we=E2=80=99re going to f=
ocus on here, but
>>>> since you can also get information about the user from a resource we c=
an=E2=80=99t
>>>> just call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the h=
eart of a lot of
>>>> confusion in recent threads, as well as confusion about the scope of t=
he
>>>> inclusion of identity in the GNAP protocol.
>>>>
>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does=
, and let=E2=80=99s find a way to
>>>> differentiate between when an item, claim or otherwise,  comes as part=
 of a
>>>> resource and when it comes back directly. This is an important
>>>> differentiating feature for GNAP.
>>>>
>>>> Some straw man ideas, none of which I=E2=80=99m particularly in love w=
ith:
>>>>
>>>>  - direct data
>>>>  - properties
>>>>  - details
>>>>  - statements
>>>>
>>>> The important thing here is that it=E2=80=99s not necessarily :about: =
the RO,
>>>> and that it is :not: in a resource.
>>>>
>>>> Any other thoughts?
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>
>>>
>>
>

--000000000000009b5005ab363cb0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


It is not clear to me what it matters if a Claim come=
s from an RS, or from the GS, so I don't see a need to differentiate th=
em.

I would include verifiable credentials and use=
r-bound keys as Claims.

All the payment processing=
 information I have=C2=A0seen has been in RAR. When would=C2=A0the Client g=
et payment processing directly from the GS?

What i=
s your example for distributed networks storage locations? If what is store=
d is a statement about the user, then I would consider that a Claim as well=
.

We disagree on how to map OIDC to GNAP.=C2=A0 Th=
e direct data is a claims request, the data coming indirectly is an access =
token request.



On Fri, Jul 24, 2020 at 1=
:39 PM Justin Richer <jricher@mit.edu=
> wrote:
=

Since we=E2=80=99re already talki=
ng about returning claims as direct data as well as a part of the resource =
API being protected, so we already need a way to differentiate the two kind=
s of items. Just calling it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, =
because as you=E2=80=99ve pointed out they could show up in both places. So=
 yes, defining that difference is something we should worry about now, even=
 if the core protocol only uses it for claims.

The two f=
orms of direct data that XYZ returns are subject identifiers (a subset of i=
dentity claims) and assertions =E2=80=94 the latter being a container not j=
ust for identity claims but also authentication information and other eleme=
nts. Assertions are not claims themselves.=C2=A0

O=
ther use cases that have been brought up include verifiable credentials and=
 proofs, user-bound keys, payment processing information, and distributed n=
etwork storage locations. I=E2=80=99m sure there are a lot more. To me, the=
se are subsets of the =E2=80=9Cdirect data=E2=80=9D but not subsets of =E2=
=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be defining what all of these=
 look like, but it should define a way to talk about them.

I think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=
=80=9D request, which allows targeting of its claims information into diffe=
rent return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D req=
uest at the very least. I don=E2=80=99t think GNAP should define how to do =
this specific combination, that should be for OIDF to debate and apply. The=
 same with a DID service based query, or Presentation Exchange [1], or anyt=
hing else that people want to come up with.

In my =
view, GNAP should define query structures for two things: rights that get t=
ied to an access token and data that comes back directly to the client. For=
 the latter, I think we can do some very limited and very useful specific i=
tems, which is what I=E2=80=99ve put into XYZ.

=C2=A0=E2=80=94 Justin

[1]=C2=A0https=
://identity.foundation/presentation-exchange/

On Jul 24, 2020, at 3:58 PM, Dick Hardt <dick.hardt@gmail.com> w=
rote:

I agree we want GNAP to be a strong fo=
undation.=C2=A0

Do you have an example of other "di=
rect data"? If so, do you expect it to be defined in the core protocol=
?

I would expect an extension for other "dire=
ct data" to define top level objects, and an appropriate definition fo=
r that "direct data".

My "do we nee=
d to worry about it now" comment was on creating a generic term for &q=
uot;direct data". Unless we are solving those now, we can let further =
work define that "direct data" explicitly.




3D""=E1=90=A7

On Fri, Jul 24, 2020 at 12:42 PM Justin Richer <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">
Yes, I do think we ne=
ed to worry about it to the extent that we are not creating something that =
is over-fit to a limited set of use cases.=C2=A0

GNAP sh=
ould be a foundation that many amazing new things can be built on top of.

=C2=A0=E2=80=94 Justin

On Jul 24, 2020, at 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrot=
e:

Justin, thanks for clarifying.

What are some examples of other "direct data" that the G=
S may return? If it is not in core GNAP, do we need to worry about now? We =
can then give the direct data from the GS that is not a claim, an appropria=
te name in that document.



On Fri, Jul 24=
, 2020 at 11:46 AM Justin Richer <jricher@mit.edu> wrote:
Dick: No, I think you=E2=80=99re misunde=
rstanding what I=E2=80=99m saying. I agree that =E2=80=9Cclaims=E2=80=9D ar=
e about the user, in this context*. But the AS could return other data dire=
ctly to the client that isn=E2=80=99t about the user. Those aren=E2=80=99t =
=E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=80=9Cc=
laims=E2=80=9D can come back from places other than directly, then we shoul=
dn=E2=80=99t call everything that comes back a =E2=80=9Cclaim=E2=80=9D.
I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D t=
o mean what it already means and come up with a new word to mean =E2=80=9Ct=
hings that come back directly from the AS=E2=80=9D. These aren=E2=80=99t me=
ant to replace Francis=E2=80=99s more complete definitions, but to simplify=
:

Claims:
	- information about the user
	- can come back directly from the AS
	- can come back in a resource from=
 the RS

Resource:
	- Returned from an RS
	- Protected by access token
	- Could contain claims about the user

Direct data (or some better name):
	- Returned directly from AS
=
	- Could contain claims about t=
he user

I think the problem is that some people ar=
e using =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. It=E2=80=
=99s clearly #1 in OIDC. But: It=E2=80=99s important to remember, when talk=
ing about OIDC, that an IdP in OIDC combines an AS and an RS into one entit=
y for identity information. There can be other RS=E2=80=99s as well, and th=
ere usually are in the wild, but the one defined by OIDC is the UserInfo En=
dpoint. The fact that it returns user data doesn=E2=80=99t make it any less=
 of an RS.

=C2=A0=E2=80=94 Justin

* In the wider context of things like the information claims inside a JW=
T, the claims could be about literally anything, but that=E2=80=99s not wha=
t we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s being=
 used.


On Jul 24, 202=
0, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

In OpenID Connect (OIDC), the Client can obtain Claims directly from t=
he OP in an ID Token, or the Client can obtain Claims using an access token=
 to call the UserInfo endpoint, a Protected Resource[1].

The Claims are about the User (not a RO).

In XAut=
h, I'm proposing the Client may obtain bare claims from the GS directly=
 in addition to the mechanisms in ODIC.

So I don&#=
39;t think we are changing the definition of Claim from how it has been use=
d in OIDC, and I fail to see any reason to NOT use Claim.

Justin: you allude to Claims being about a party other than the Use=
r. Would you provide an example?

/Dick
<=
br>
[1]
UserInfo Endpoint
Protected Resource that,=
 when presented with an Access Token by the Client, returns authorized info=
rmation about the End-User represented by the corresponding Authorization G=
rant. The UserInfo Endpoint URL MUST use the https scheme and MAY contain p=
ort, path, and query parameter components.



3D""=E1=90=A7
On Fr=
i, Jul 24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspect he=
re:


A Claim is a well understood term in the field=
. We should use it. It is still a Claim if it comes directly from the GS or=
 from an RS.=C2=A0
I do not understand why a R=
esource release by an RS shall be h to as a claim, even if the content of t=
he Resource is an assertion. It will lead to confusion. If we limit claims =
to information GS releases into Token, User Info, and other objects it retu=
rns, this will help separate responsibilities between GS and RS. As soon as=
 RS services and information, this is called a Resource, no matter the natu=
re of the content of that information.
=

This is exactly why I don=E2=80=99t think we should use =E2=
=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=
=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in the contex=
t of GNAP, that makes it a resource. So we need a different word for data c=
oming back directly from the AS to the client. Sometimes it=E2=80=99s going=
 to be about the user, and that=E2=80=99s what we=E2=80=99re going to focus=
 on here, but since you can also get information about the user from a reso=
urce we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this =
has been at the heart of a lot of confusion in recent threads, as well as c=
onfusion about the scope of the inclusion of identity in the GNAP protocol.=


So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean=
 what it already does, and let=E2=80=99s find a way to differentiate betwee=
n when an item, claim or otherwise,=C2=A0=C2=A0comes as part of a resource =
and when it comes back directly. This is an important differentiating featu=
re for GNAP.

Some straw man ideas, none of which I=
=E2=80=99m particularly in love with:

=C2=A0- dire=
ct data
=C2=A0- properties
=C2=A0- details
=
=C2=A0- statements

The important thing here is tha=
t it=E2=80=99s not necessarily :about: the RO, and that it is :not: in a re=
source.

Any other thoughts?

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










--000000000000009b5005ab363cb0--


From nobody Fri Jul 24 17:06: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 0331B3A0C8F for ; Fri, 24 Jul 2020 17:06:17 -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 65OnRJXUmvId for ; Fri, 24 Jul 2020 17:06:15 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 10DE03A0C99 for ; Fri, 24 Jul 2020 17:06:14 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id f7so9720203wrw.1 for ; Fri, 24 Jul 2020 17:06:14 -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=7GgZpFLD/2vDjNItgn77r9YO+PIEb6bnKgigVFYZ9FM=; b=DPNSKgkLkmSULCklRw10ldRPmKxcX1eEEYiM5Kwr522fcqT90iEJOJKuXRMQENGxb0 CkrNvJKz0D7HGlyfLBchVcyP5d0Rw72XUBxEPziNR22WfmZbOJclUqtRwddDejEPmnI/ JoSpHLblXie+nbppdezaZl+qn+jpIlB3mXTUQ=
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=7GgZpFLD/2vDjNItgn77r9YO+PIEb6bnKgigVFYZ9FM=; b=W32xdy0lW5GRxJxwOi3mG/amKdJKdYxUB+nsq4kZYx7k3YBvKMCl95FwaKViVgYUMm H7uKC99KT/BR3zih2bfjcFcVN6kXjjMAldxvZ4XWfpv8Ag3X3KJj0jRzYmxTs26+8U1w Sf8PEAGqBR6ikx3dAZsPT5S0fSnJas1oqe4+LHEH9QHNTAJUfmLukMt8a8LXVd5A71ag B/MH0CfINgoG+k9sVQKEnR5qbgCKhb9ASvODKDK8X8ZwFe7KMOJMa0ZkPs8A7mPYBBgG oep8oZtF9Lq9YjVPo6mUXRawUdttr7ryJ/eb9IkVVqFHKcauWt+if5wT4ByAcnUhk8DU ep2A==
X-Gm-Message-State: AOAM532/ap3zBxtim8+tyR0nA9APTxvECAsWRvGlwBUfCwTA0/TsS+tf kzObaTznsxKGJYcjgkyk3E0cdVgntEb6/XKxGVss7g==
X-Google-Smtp-Source: ABdhPJyv+7Sk+v2EA6qTo8PRgv7X9UFrPCRM06CywDTjkAjIqgAIngKNhGT/ggy/o/LaRZLj8Ly//jLkV2WWhwVTSQg=
X-Received: by 2002:a5d:45c9:: with SMTP id b9mr10303744wrs.283.1595635573162;  Fri, 24 Jul 2020 17:06:13 -0700 (PDT)
MIME-Version: 1.0
References: <6CC714D8-2FB2-4BE6-B70B-659C4A8198AB@gmail.com>  
In-Reply-To: 
From: Francis Pouatcha 
Date: Fri, 24 Jul 2020 20:06:02 -0400
Message-ID: 
To: Justin Richer 
Cc: Yaron Sheffer , "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000879a4e05ab38db46"
Archived-At: 
Subject: Re: [Txauth] GNAP agenda uploaded
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, 25 Jul 2020 00:06:17 -0000

--000000000000879a4e05ab38db46
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you Justin...

On Fri, Jul 24, 2020 at 1:11 PM Justin Richer  wrote:

> Hi Francis,
>
> The IETF=E2=80=99s 108th meeting will be fully virtual. You can register =
and get
> additional information from this page:
>
> https://www.ietf.org/how/meetings/108/
>
> Anybody can attend. All conversations fall under the IETF=E2=80=99s Note =
Well
> policy, just like posts to the mailing list.
>
>  =E2=80=94 Justin
>
> On Jul 24, 2020, at 10:57 AM, Francis Pouatcha <
> fpo=3D40adorsys.de@dmarc.ietf.org> wrote:
>
> When and how is next week's meeting taking place? Who is invited, can
> attend or is supposed to attend? Best regards. /Francis
>
> On Mon, Jul 20, 2020 at 3:46 PM Yaron Sheffer 
> wrote:
>
>> Leif and I uploaded the agenda for next week:
>> https://www.ietf.org/proceedings/108/agenda/agenda-108-gnap-00.html
>>
>>
>>
>> Thanks,
>>
>>                 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/

--000000000000879a4e05ab38db46
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thank you Justin...

On Fri, Jul 24, 2020 at 1:11 PM Justin =
Richer <jricher@mit.edu> wrote=
:
Hi Francis,

The IETF=E2=80=
=99s 108th meeting will be fully virtual. You can register and get addition=
al information from this page:


Anybody can attend. All conversa=
tions fall under the IETF=E2=80=99s Note Well policy, just like posts to th=
e mailing list.

=C2=A0=E2=80=94 Justin
On Jul 24, 2020, at 10:57 AM, Francis Pouat=
cha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:

When and how is next week's=C2=A0meeting taking place? Who is=
=C2=A0invited, can attend=C2=A0or is supposed to attend? Best regards. /Fra=
ncis

On Mon, Jul 20, 2020 at 3:46 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:<=
br>
Leif and I u=
ploaded the agenda for next week: https://www.ietf.o=
rg/proceedings/108/agenda/agenda-108-gnap-00.html<=
/p>
=C2=A0
Thanks,<=
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 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


--000000000000879a4e05ab38db46--


From nobody Fri Jul 24 19:21: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 2DC903A10CB for ; Fri, 24 Jul 2020 19:21:43 -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 uuQOa2EL5ahi for ; Fri, 24 Jul 2020 19:21:40 -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 7E6BB3A10CC for ; Fri, 24 Jul 2020 19:21:39 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id f7so9855608wrw.1 for ; Fri, 24 Jul 2020 19:21:39 -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=IwxHphGzkLy+IE1rN4yJKKBVMdUUCS7dAol3zqIpMfM=; b=ace3O1oQXLLgLv+fnpln8uYWt/apgE6drgXSrZtwy1IZ/iRq976N5H0UnhmifWNmOW 85ExYgVpx1nSdbPZ8Z2DKtzuiCXvlItB65t7p8AdsCsnY+8zya88EltaxYzq1pxJxc+I D/rfuu8RDJjdMuo749Dhapsim9t9v4+wY5ptI=
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=IwxHphGzkLy+IE1rN4yJKKBVMdUUCS7dAol3zqIpMfM=; b=WsI6AyjrRz+s0aFmaqjSCktnRryGykLe7uez3aWNFClWV9iT8n41CdhyH/RcEu4QaC +Mh8BfSG5ZQWPO80vuyOmAagRFPcAWt1IAU9sE1308QoH6k1QaWc97QrN/xBmoi0/fXF lXScbBOPEob0Yja7FrO9kA07y4S9Rvy/dGAgPDMrRhU6OVtpX2e+G4f5NvvgvNva6GWi tMuKr9B1RyJYWbvUaNCaOl8aukXXu44djoMfF1deOFR8TJMsN1zcEIbpMGVKBB1lb6tJ Ot3SExp9IIe5tl1EEoXEFafhAkrHqipwsYdNIPoZtcAkJtNxriCfC1qYPz7wIVATkypH 9L3w==
X-Gm-Message-State: AOAM532dFkxngBXP70JAt/62wLK2VYoIsSteuCBpiBYyr6BWiMGKq4xH veavSndG+pUWbKnMUjfBNrQFc4Do2+uDyRzuCXuGAvo2aMY=
X-Google-Smtp-Source: ABdhPJzF2Y0HqB0pbm2N159imI70BHwqxRzV1MirQ8KtFaTJUkzIbJ6Ab6IM+46vq+pMhWxJpow9vAm87UvPtMYu3xQ=
X-Received: by 2002:a5d:65d2:: with SMTP id e18mr10577456wrw.70.1595643697266;  Fri, 24 Jul 2020 19:21:37 -0700 (PDT)
MIME-Version: 1.0
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu> 
In-Reply-To: 
From: Francis Pouatcha 
Date: Fri, 24 Jul 2020 22:21:26 -0400
Message-ID: 
To: txauth@ietf.org
Cc: Justin Richer , Dick Hardt ,  Tom Jones , Denis ,  Fabien Imbault 
Content-Type: multipart/alternative; boundary="000000000000c39f9805ab3abf38"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 25 Jul 2020 02:21:43 -0000

--000000000000c39f9805ab3abf38
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Below my opinion on the term Claim:

Starting with illustration of parties/roles:

User:
This word is misleading because of its double role in oAuth2 and OIDC (see
below). In GNAP let us have the User play only the role of a requestor.
(from Justin reference to "Requesting Party").

Client:
This is also tightly bound to the oAuth2 and OIDC. The real purpose of this
role is to orchestrate resource access on behalf of the "Requestor". Let us
call this for now the "Orchestrator"

Resource Owner (RO):
This is IMO the most correct word in the entire protocol. Authorisation is
always about the owner of something granting access to a requestor. It
really does not matter if a human interaction is involved. We will have to
forget oAuth2 and OIDC of also calling this a User.

Grant Server:
Even though the definition of the UserInfo endpoint in OIDC as a protected
resource hazardously makes an OP an RS, we shall not repeat the same
mistake here. We need a clear separation between roles of GS and RS without
overlapping.

Resource Server: services resources.

Unless I got it wrong, GNAP is about grant negotiation and authorization.
This means:

GNAP is about some party requesting access to some resources.
GNAP is about the resource owner consenting access to that resource.
GNAP is about defining the infrastructure that allows the requesting party
to access a resource.

GNAP designs this infrastructure around:
- an orchestrator (what we refer to as a client)
- an grant manager (what we refer to as a GS/AS)
- the custodian of the resource (what we call a RS)

As you see:
- The word User does not appear here, and is not relevant as the focus is
on authorizing access to a resource.
- The word Claim is as well absent.

Claim related to RO:
The word Claim might start getting visible if the orchestrator (a.k.a.
Client) or the custodian (a.k.a RS) needs some additional information on
the RO to proceed with the access control decision. These claims refer to
assertions of attributes or properties of the RO. These claims are issued
by the GS as the GS manages interaction with the RO (see below). In this
first place information about the requesting party (erroneously.k.a. User)
is not relevant to the negotiation and provisioning framework. Let us call
this sort of claim "RO-Attributes". A better name is welcome.

Some advanced resource provisioning frameworks might require knowledge on
attributes of the requesting party (e.k.a User). These attributes shall be
collected by the orchestrator (a.k.a Client) and added to the resource
request. There is no way the GS can collect these attributes as the GS role
has no interaction with the requesting party (e.k.a User). Let us call this
sort of claim "Requestor-Attributes". A better name will be welcome.

Some assertions are even related to the orchestrator (a.k.a Client) itself.
This is the case of the public key of an orchestrator used by the GS to
"sender constrain" an access token. Let us call this type of claim
"Orchestrator-Attributes".

This is a sample mapping of OIDC.

+----+    +---+   +---+  +---+
|User|    |RP |   |OP |  |RS |
+----+    +---+   +-+-+  +---+
  |(1) ServiceRequest      |
  |-------->|       |      |
  |(2) redirect     |      |
  |<--------|       |      |
=3D=3D=3D User (requestor) passes control to User (RO) =3D=3D=3D
  |(3) Auth + Consent      |
  |---------------->|      |
  |(4) redirect (code)     |
  |<----------------|      |
=3D=3D=3D User (RO) passes control back to User (requestor) =3D=3D=3D
  |(5) get(code)    |      |
  |-------->|       |      |
  |         |(6) token (code)
  |         |------>|      |
  |         |(7) token     |
  |         |<------|      |
  |         |(8) ServiceRequest(token)
  |         |------------->|
  |         |(9) ServiceResponse
  |         |<-------------|
  |(10) ServiceResponse    |
  |<--------|       |      |
  +         +       +      +

- RP orchestrates interaction between User and OP to enable the user to
obtain the protected resource.
- In step 1 & 10 User plays the role of the requestor of the resource.
- In step 2 User-Browser is used to pass control from User (in his role as
the requestor) to User (in his role as the RO)
- In step 4 User-Browser is used to pass control from User (in his role as
the RO) back to User (in his role as the requestor)

When we are talking claims here, we are talking claims on the User (in his
role as the RO). The OP does not have any interaction with the User (in his
role as the requestor). In the case of an App2App redirection, the OP can
not even assert about the user agent of the User (requestor).

If there is any claim the OP can provide, it is a claim on the User (RO).

I hope this example clarifies the misunderstanding. Any attempt of bringing
this double role of the User into GNAP will also bring this confusion. In
order to keep this out of GNAP let us look for the right term for User (as
a requestor) using the diagram displayed below.

+----+  +------+  +---+  +---+  +---+
|Reqs|  |Orchst|  |RS |  |GS |  |RO |
+----+  +------+  +---+  +-+-+  +-+-+
  |(1) ServiceRequest      |      |
  |-------->|       |      |      |
  |         |(2) ServiceIntent:AuthZChallenge
  |         |<----->|      |      |
  |         |       |      |      |
  |         |(3) AuthZRequest(AuthZChallenge)
  |         |------------->|      |
  |         |       |      |(4) ConsentRequest:Grant
  |         |       |      |<---->|
  |         |(5) GrantAccess(AuthZ)
  |         |<-------------|      |
  |         |       |      |      |
  |         |(6) ServiceRequest(AuthZ):ServiceResponse
  |         |<----->|      |      |
  |(7) ServiceResponse     |      |
  |<--------|       |      |      |
  +         +       +      +      +

- Replacing the word User helps clarify the difference between both roles
"Requestor" and "Resource Owner"
- Renaming claim by attaching the Object/target of the claim (e.g.:
RO-attributes, Requestor-Attributes, Orchestrator-Attributes) also helps
identify the source of those attributes (GS, RS, Client):

Best regards.
/Francis

On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt  wrote:

> It is not clear to me what it matters if a Claim comes from an RS, or fro=
m
> the GS, so I don't see a need to differentiate them.
>
> I would include verifiable credentials and user-bound keys as Claims.
>
> All the payment processing information I have seen has been in RAR. When
> would the Client get payment processing directly from the GS?
>
> What is your example for distributed networks storage locations? If what
> is stored is a statement about the user, then I would consider that a Cla=
im
> as well.
>
> We disagree on how to map OIDC to GNAP.  The direct data is a claims
> request, the data coming indirectly is an access token request.
>
>
>
> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer  wrote:
>
>> Since we=E2=80=99re already talking about returning claims as direct dat=
a as well
>> as a part of the resource API being protected, so we already need a way =
to
>> differentiate the two kinds of items. Just calling it =E2=80=9Cclaims=E2=
=80=9D doesn=E2=80=99t
>> help, because as you=E2=80=99ve pointed out they could show up in both p=
laces. So
>> yes, defining that difference is something we should worry about now, ev=
en
>> if the core protocol only uses it for claims.
>>
>> The two forms of direct data that XYZ returns are subject identifiers (a
>> subset of identity claims) and assertions =E2=80=94 the latter being a c=
ontainer
>> not just for identity claims but also authentication information and oth=
er
>> elements. Assertions are not claims themselves.
>>
>> Other use cases that have been brought up include verifiable credentials
>> and proofs, user-bound keys, payment processing information, and
>> distributed network storage locations. I=E2=80=99m sure there are a lot =
more. To
>> me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D but not subse=
ts of =E2=80=9Cclaims=E2=80=9D.
>> GNAP shouldn=E2=80=99t be defining what all of these look like, but it s=
hould
>> define a way to talk about them.
>>
>> I think different top-level request objects are better suited for
>> different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=
=E2=80=9D request,
>> which allows targeting of its claims information into different return
>> buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D request at t=
he very least. I
>> don=E2=80=99t think GNAP should define how to do this specific combinati=
on, that
>> should be for OIDF to debate and apply. The same with a DID service base=
d
>> query, or Presentation Exchange [1], or anything else that people want t=
o
>> come up with.
>>
>> In my view, GNAP should define query structures for two things: rights
>> that get tied to an access token and data that comes back directly to th=
e
>> client. For the latter, I think we can do some very limited and very use=
ful
>> specific items, which is what I=E2=80=99ve put into XYZ.
>>
>>  =E2=80=94 Justin
>>
>> [1] https://identity.foundation/presentation-exchange/
>>
>> On Jul 24, 2020, at 3:58 PM, Dick Hardt  wrote:
>>
>> I agree we want GNAP to be a strong foundation.
>>
>> Do you have an example of other "direct data"? If so, do you expect it t=
o
>> be defined in the core protocol?
>>
>> I would expect an extension for other "direct data" to define top level
>> objects, and an appropriate definition for that "direct data".
>>
>> My "do we need to worry about it now" comment was on creating a generic
>> term for "direct data". Unless we are solving those now, we can let furt=
her
>> work define that "direct data" explicitly.
>>
>>
>>
>>
>> =E1=90=A7
>>
>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer  wrote:
>>
>>> Yes, I do think we need to worry about it to the extent that we are not
>>> creating something that is over-fit to a limited set of use cases.
>>>
>>> GNAP should be a foundation that many amazing new things can be built o=
n
>>> top of.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt  wrote:
>>>
>>> Justin, thanks for clarifying.
>>>
>>> What are some examples of other "direct data" that the GS may return? I=
f
>>> it is not in core GNAP, do we need to worry about now? We can then give=
 the
>>> direct data from the GS that is not a claim, an appropriate name in tha=
t
>>> document.
>>>
>>>
>>>
>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer  wrote:
>>>
>>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m say=
ing. I agree that
>>>> =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But the=
 AS could return
>>>> other data directly to the client that isn=E2=80=99t about the user. T=
hose aren=E2=80=99t
>>>> =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=
=80=9Cclaims=E2=80=9D can come back
>>>> from places other than directly, then we shouldn=E2=80=99t call everyt=
hing that
>>>> comes back a =E2=80=9Cclaim=E2=80=9D.
>>>>
>>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean what=
 it already means and
>>>> come up with a new word to mean =E2=80=9Cthings that come back directl=
y from the
>>>> AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s m=
ore complete definitions, but
>>>> to simplify:
>>>>
>>>> Claims:
>>>> - information about the user
>>>> - can come back directly from the AS
>>>> - can come back in a resource from the RS
>>>>
>>>> Resource:
>>>> - Returned from an RS
>>>> - Protected by access token
>>>> - Could contain claims about the user
>>>>
>>>> Direct data (or some better name):
>>>> - Returned directly from AS
>>>> - Could contain claims about the user
>>>>
>>>> I think the problem is that some people are using =E2=80=9Cclaims=E2=
=80=9D to mean #1
>>>> and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99=
s important to
>>>> remember, when talking about OIDC, that an IdP in OIDC combines an AS =
and
>>>> an RS into one entity for identity information. There can be other RS=
=E2=80=99s as
>>>> well, and there usually are in the wild, but the one defined by OIDC i=
s the
>>>> UserInfo Endpoint. The fact that it returns user data doesn=E2=80=99t =
make it any
>>>> less of an RS.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> * In the wider context of things like the information claims inside a
>>>> JWT, the claims could be about literally anything, but that=E2=80=99s =
not what
>>>> we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s be=
ing used.
>>>>
>>>>
>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt  wrote:
>>>>
>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from
>>>> the OP in an ID Token, or the Client can obtain Claims using an access
>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>
>>>> The Claims are about the User (not a RO).
>>>>
>>>> In XAuth, I'm proposing the Client may obtain bare claims from the GS
>>>> directly in addition to the mechanisms in ODIC.
>>>>
>>>> So I don't think we are changing the definition of Claim from how it
>>>> has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>
>>>> Justin: you allude to Claims being about a party other than the User.
>>>> Would you provide an example?
>>>>
>>>> /Dick
>>>>
>>>> [1]
>>>>
>>>> UserInfo Endpoint
>>>> Protected Resource that, when presented with an Access Token by the
>>>> Client, returns authorized information about the End-User represented =
by
>>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST =
use
>>>> the https scheme and MAY contain port, path, and query parameter compo=
nents.
>>>>
>>>>
>>>>
>>>>
>>>> =E1=90=A7
>>>>
>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote:
>>>>
>>>>> I want to focus on one aspect here:
>>>>>
>>>>>
>>>>>> A Claim is a well understood term in the field. We should use it. It
>>>>>> is still a Claim if it comes directly from the GS or from an RS.
>>>>>>
>>>>> I do not understand why a Resource release by an RS shall be h to as =
a
>>>>> claim, even if the content of the Resource is an assertion. It will l=
ead to
>>>>> confusion. If we limit claims to information GS releases into Token, =
User
>>>>> Info, and other objects it returns, this will help separate
>>>>> responsibilities between GS and RS. As soon as RS services and inform=
ation,
>>>>> this is called a Resource, no matter the nature of the content of tha=
t
>>>>> information.
>>>>>
>>>>>
>>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclai=
m=E2=80=9D in the way
>>>>> that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could com=
e back through an RS =E2=80=94 but in
>>>>> the context of GNAP, that makes it a resource. So we need a different=
 word
>>>>> for data coming back directly from the AS to the client. Sometimes it=
=E2=80=99s
>>>>> going to be about the user, and that=E2=80=99s what we=E2=80=99re goi=
ng to focus on here,
>>>>> but since you can also get information about the user from a resource=
 we
>>>>> can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this ha=
s been at the heart of a lot
>>>>> of confusion in recent threads, as well as confusion about the scope =
of the
>>>>> inclusion of identity in the GNAP protocol.
>>>>>
>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already doe=
s, and let=E2=80=99s find a way
>>>>> to differentiate between when an item, claim or otherwise,  comes as =
part
>>>>> of a resource and when it comes back directly. This is an important
>>>>> differentiating feature for GNAP.
>>>>>
>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in love =
with:
>>>>>
>>>>>  - direct data
>>>>>  - properties
>>>>>  - details
>>>>>  - statements
>>>>>
>>>>> The important thing here is that it=E2=80=99s not necessarily :about:=
 the RO,
>>>>> and that it is :not: in a resource.
>>>>>
>>>>> Any other thoughts?
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>
>>>>
>>>
>>

--=20
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--000000000000c39f9805ab3abf38
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Below my opinion=C2=A0on the term=
 Claim:

Starting with illustration of parties/roles:

=
User:=C2=A0
This word is misleadi=
ng because of its double role in oAuth2 and OIDC (see below). In GNAP let u=
s have the User play only the role of a requestor. (from Justin reference t=
o "Requesting Party").
=

Client:
This is also tightly=C2=A0bound to the oAuth2 and OID=
C. The real purpose of this role is to orchestrate resource access on behal=
f of the "Requestor". Let us call this for now the "Orchestr=
ator"

=
Resource Owner (RO):

 =20
   =20
 =20
  

    
Hi Dick,

      

    

    
In order to send back a quick reply
      tonight, I will only respond to one of your questions:

    

      
 [Denis] How would be the data flow when access tokens
        from two GSs are needed by a RS ?

        


        

        
[Dick] I don't know of a use case where two tokens would b=
e
          needed by an RS. Would you elaborate?

      

      
I already described on the list the case of a student
        registering to a new University.

      
 

      

      
First, the student connects to the RS from the new University
        and opens an account 

        (at this time the student is using a pseudo and a private key to
        authenticate). He fills some forms 

        and indicate its citizenship, his home address and his
        graduation in his current university. 

        

        When he is finished, he indicates that he wants to perform a
        Registration operation.

      


      

      
From the information gathered in the forms, the RS informs
        the client that it needs two access tokens:

      
    
        
  • one to demonstrate that his name and current home address
          are correct,and
    • 
        
  • another one to demonstrate that he got a graduation from its
          current University.
    • 
      

      
Depending upon the information captured in the forms, the RS
        also indicates which ASs/GSs are acceptable 

        and which kind of attributes are requested.

      
 

      

      
The user consent and choice is performed by the client and
        once approved by the student, two access tokens are separately
        requested.

        Finally, two access tokens are presented to the RS while
        invoking a Registration operation.

      


      

      
Note that the start of the story is to open an account, e.g.
        using FIDO. The needs of the RS are only disclosed to the
        student once he has filled some forms 

        and indicated that he wanted to perform a Registration
        operation. Thus, the needs that are revealed by the RS are
        dependant both upon the operation 

        that the student is willing to perform and the information
        collected in the forms.

      


      

      
Denis

    

    

    

     =20
      

        
Hi Denis, comments inserted ...=C2=A0

        

        

          
On Fri, Jul 24, 2020 at 9:0=
8
            AM Denis <denis.ietf@free.fr> wrote:

          

          

            

              

                
Hi Dick,

                


                

                
draft-hardt-xauth-protocol-13 describes a solution
                  without clearly stating what the problem(s) to be
                  solved is/are.

              

            

          

          


          

          
I agree that the problem description is not as crisp as I
            would like it to be. A challenge is that there is a broad
            spectrum of use cases solved by OAuth 2, and OpenID Connect,
            as well as the new use cases that are solved by GNAP.

          


          

          
That is why I am suggesting we gather some use cases so
            we have a common understanding of the problems that are in
            scope.

          
=C2=A0

          

            

              

                


                

                
At the moment, draft-hardt-xauth-protocol-13
                  includes a single figure on page 4 and from previous
                  discussions I understood that 

                  it is no more up-to-date since the first data flow is
                  now a contact with a RS. The reason(s) for the GS to
                  contact a RO has still not 

                  been explained (since the inputs and outputs are not
                  described). The discovery information made available
                  at various steps at the RS 

                  is not described.

                

              

            

          

          


          

          
I have made no updates as we are in a quiet period prior
            to the WG meeting next week when documents cannot be
            updated.

          
=C2=A0

          

            

              

                

                  


                  

                

                
Figure 4 shows only a single RS. Is the relaying of
                  one operation by that RS to a second RS in the scope
                  of this document ?

                  If yes, how is it handled ?

                

              

            

          

          


          

          
I view that as an advanced use case that would be covered
            in a separate document.

          
=C2=A0

          

            

              

                
 

                


                

                
Figure 4 shows only a single GS. How would be the
                  data flow when access tokens from two GSs are needed
                  by a RS ?

                

              

            

          

          


          

          
I don't know of a use case where two tokens would be
            needed by an RS. Would you elaborate?

          
The RS being able to accept tokens from two different
            GSes is covered, but the Client is only using a token from
            one GS at a time.

          


          

          
=C2=A0

          

            

              

                
 

                

                What we need first is not a set of "use cases" bu=
t a
                clear model with a data flows and a list of its
                properties/characteristics. 

              

            

          

          


          

          
I disagree. The use cases describe the problems we are
            looking to solve. The data flows are part of the solution.
            For example, from my understanding of your use case, you
            don't want the GS to have visibility into the User's
            activity. Am I correct that this is one of your requirements
            for your use case?

          


          

          
=C2=A0

          

            

              
 

              
Then after, we can understand much better which use
                cases can/will be supported. For example, shall a RS (or
                its RO) have 

                prior relationships with the GS ? What is the
                difference/implications when it has or it hasn't ?

              

              


              

              
In order to have a fair comparison, we should try to
                list model properties/characteristics.

              


              

              
At the moment, the model I have described including
                the data flows is clear. The discovery information made
                available by a RS is clear.

              
I have not listed all its properties/characteristics
                of that model, but I am pretty sure that you already
                have a flavour of it.

              


              

              
In the mean time, it would be nice if you could show
                using two figures:

              
    
                
  • the case of the relaying of one operation by one RS
                  to a second RS (if it is in the scope of your
                  document),
    • 
                
  • the case where access tokens from two GSs are needed
                  by one RS (if it is in the scope of your document).
    
                
    • 
              

            

          

          


          

          
See above

          
=C2=A0

          

            

              
    
                
  •  
    
                
    • 
              

              

                
Denis

              

              


              

              

                
Hi Denis
                  


                  

                  
I think it would be useful to take a step back
                    and for you to describe your use case. 

                    After that, we can explore the different ways that
                    your use case can be addressed.=C2=A0

                  


                  

                  
Looking at your previous communication, it
                    describes the solution, and the justification, 

                    but it is not clear what use cases you are needing
                    to solve.

                  


                  

                  
/Dick

                  


                  

                  


                  

                

                
=E1=90=A7

                

                

                  
On Wed, Jul 22, 202=
0
                    at 9:34 AM Denis <denis.ietf@free.fr>
                    wrote:

                  

                  

                    

                      
Hello Dick,

                      


                      

                      
I have identified the reason of the major
                        difference between our two approaches.

                      


                      

                      
Access control may be performed using either
                        ACLs (Access Control Lists) or Capabilities.

                      


                      

                      
Note : a capability identifies a
                        resource and an allowed operation that can be
                        performed on that resource.

                      

                      


                      

                      
You are advocating a Capabilities approach
                        while I am advocating an ACL approach.

                      
The capabilities approach allows the GS to
                        trace every operation performed by the users on
                        any RS known by a GS.

                        The management of these capabilities is made via
                        the GS or at the GS by the various ROs. If the
                        management is made 

                        via the GS, then a trusted communication channel
                        needs to be established with every RO. If the
                        management is made 

                        at the GS, then an authentication mechanism
                        needs to be established with every RO. In the
                        last case, the GS has the 

                        ability to know all the capabilities of the
                        users whether they are used or not. The less
                        that can be said is that this model 

                        is not privacy friendly.

                      
With the ACL approach, a RO directly manages an
                        ACL placed in front of each RS. The Access Control Decision
                          Function 

                            (ADF) at the RS is
                          able to keep track from prior decisions. T=
he
                        GS is kept ignorant of the content of these ACLs
                        and only 

                        delivers to its clients attributes that are
                        placed into access tokens. Such a model may be
                        privacy friendly.

                      
Other comments are between the lines prefixed
                        with [Denis].

                      

                        

                          


                            

                              
On Tue,
                                Jul 21, 2020 at 11:26 AM Denis <denis.ietf@free.fr>
                                wrote:

                              

                              

                                

                                  
Hello Dick,

                                  


                                  

                                  
 Thank you for your feedback.
                                    Comments are between the lines.

                                  


                                  

                                  

                                    

                                      
comments inserted
                                        ...=C2=A0

                                      

                                      

                                        
On Tue, Jul
                                          21, 2020 at 6:03 AM Denis <denis.ietf@free.fr=
>
                                          wrote:

                                        

                                        

                                          

                                            
Hello Dick,

                                            


                                            

                                            
I duplicate the most
                                              important comment at the
                                              beginning of this email:
                                            

                                              
You are considering
                                                using an access control
                                                model to build a wor=
kflow
                                                model.

                                                 

                                                While it may be
                                                interesting to define a
                                                workflow model, this
                                                should be considered 

                                                as a separate and
                                                different work item.

                                            

                                            
See the other comments
                                              between the lines.

                                            

                                            


                                            

                                            

                                              
On Mon, Jul
                                                20, 2020 at 2:05 AM
                                                Denis <denis.ietf@free.fr>
                                                wrote:

                                                

                                                  

                                                    

                                                      
Hi Dick,

                                                      


                                                      

                                                      

                                                        
On
                                                          Fri, Jul 17,
                                                          2020 at 9:21
                                                          AM Denis <denis.ietf@free.fr&=
gt;
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Francis and
                                                          Dick,

                                                          


                                                          

                                                          
The good
                                                          news first: we
                                                          are making
                                                          some progress.
                                                          We are now
                                                          close to an
                                                          agreement with
                                                          steps (1) up
                                                          to (3), 

                                                          ... except
                                                          that the place
                                                          where the user
                                                          consent is
                                                          captured is
                                                          not
                                                          mentioned/indicat=
ed.

                                                          

                                                          

                                                          

                                                        

                                                      

                                                      

                                                      This major
                                                      question which is
                                                      currently left
                                                      unanswered is
                                                      where, when and
                                                      how the user
                                                      consent is
                                                      captured.

                                                    

                                                  

                                                  


                                                  

                                                  
When is covered,
                                                    per the sequence.
                                                    How and where are
                                                    out of scope of what
                                                    I drafted. 

                                                  

                                                

                                              

                                            

                                            
It is clear that the
                                              "User consent and choice=
"
                                              is not currently addressed
                                              in the draft, but it
                                              should.

                                              The support of the "User
                                              consent and choice" has
                                              strong implications not
                                              only in the sequences of
                                              the exchanges 

                                              but also by which entity
                                              it should be performed.

                                          

                                        

                                        
"consent" is in the =
latest
                                          draft 7 times. 

                                        

                                      

                                    

                                  

                                  
"Consent" is present 5 times=
. The
                                    User consent is different from the
                                    RO consent (when/if it is required).
                                    

                                  

                                  

                                    
The server acquires consent and
                                      authorization from the user and/or
                                        resource owner if
                                        required.

                                    

                                    
User consent is often
                                        required at the GS. GNAP
                                      enables a Client and=C2=A0 GS to
                                      negotiate the interaction mode for
                                      the GS to obtain consent.

                                    

                                    
 The GS may require
                                      explicit consent from the RO or
                                      User to provide these to the
                                      Client.

                                    

                                  

                                  
The User consent is not an
                                    alternative to the RO consent. So
                                    using "and/or" in the first s=
entence
                                    is incorrect.

                                

                              

                              


                              

                              
My language is sloppy there. Consent
                                is always from the RO. The User may be
                                the RO.

                            

                          

                        

                      

                      
[Denis] No. Once again: The "User consent<=
/i>"
                        is different from what you call the "RO
                          consent" (when/if it is required). 

                        The "RO consent" is not in fact a consent=
 but
                        the release of a capability to a client by one
                        of the many R0s with which 

                        the GS has relationships. 

                      

                      

                        

                          

                            

                              

                                

                                  
Since the second sentence is using
                                    the wording "often required" =
there
                                    is no requirement to get the User
                                    consent.

                                  

                                

                              

                              
User consent may not be required.
                                There may not be a User. The consent may
                                have been gathered previously.

                            

                          

                        

                      

                      
[Denis] In order to follow the privacy
                        principles, a "User consent" phase is req=
uired.
                        The User is a natural person.

                        A Client is called either by a User (i.e. a
                        natural person) or by a Client application. 

                      

                      

                        

                          

                            

                              

                                

                                  
 

                                  
The second sentence does not
                                    consider the possibility to get the
                                    User consent in a place different
                                    from the GS.

                                

                              

                              
Agreed. But we do agree that the GS
                                gets the consent, either directly from
                                the RO, or from the Client (in your
                                example).

                            

                          

                        

                      

                      
[Denis] No. I disagree. In an ACL based
                        systems, the GS does not need to ask or receive
                        any consent.

                        The client selects the set of attributes that it
                        wants to be inserted into an access token.

                        If the GS has the requested attributes, then it
                        provides them, otherwise it returns an error to
                        the Client.

                      

                        

                          

                            

                              

                                

                                  
IMO, the User consent should be
                                    captured by the Client, i.e. not by
                                    the GS. 

                                    The information used to obtain the
                                    User consent should be standardized
                                    (... and it can be standardized).

                                  

                                  

                                    

                                      
I think
                                        the abstract sequence as
                                        proposed by Francis is a great
                                        addition, and would clarify
                                        where consent is in the
                                        sequence. 

                                    

                                  

                                  
The current sketch does not
                                    illustrate the place the User
                                    Consent is captured, in particular
                                    by the Client.

                                

                              

                              
It is an abstraction. The GS receives
                                the consent. How consent is gathered is
                                a detail that is dependent on the use
                                case.

                            

                          

                        

                      

                      
[Denis] I really wonder whether there is really
                        a "consent" to be received by the GS in b=
oth
                        cases (i.e. ACLs or Capabilities).

                      

                      
    
                        
  • For ACLs, the consent needs to be done by
                          the Client.
    • 
                        
  • For Capabilities, the current description is
                          not clear since the inputs and the outputs for
                          this "consent" phase
    
                          are not currently described in the draft.
    • 
                      

                      

                        

                          

                            

                              
=C2=A0

                              

                                

                                  

                                    

                                      

                                        
=C2=A0

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    
 Another
                                                      important point to
                                                      consider and to
                                                      explain is related
                                                      to the assurances
                                                      that the user can
                                                      obtain about 

                                                      the respect of his
                                                      choices. This
                                                      point is currently
                                                      left unanswered in
draft-hardt-xauth-protocol-13.

                                                    

                                                  

                                                

                                              

                                            

                                            
This point is equally
                                              important: such assurance
                                              can only be obtained if
                                              the access token returned
                                              to the client 

                                              is not considered to be
                                              opaque to the client. This
                                              is a necessary condition
                                              but not the single
                                              condition: 

                                              the Client must also be in
                                              a position to
                                              capture/memorize the "Us=
er
                                              consent and choice" of t=
he
                                              user in order to be able 

                                              to verify it afterwards
                                              using the content of the
                                              access token(s).

                                          

                                        

                                        


                                        

                                        
We disagree on this being a
                                          requirement for all use cases.
                                          It may be in some. 

                                        

                                      

                                    

                                  

                                  
OK. Then this means that there will
                                    be no sentence in the draft such as
                                    :

                                    "access tokens returned to the
                                    client are not considered to be
                                    opaque to the client".

                                

                              

                              


                              

                              
For OAuth use cases, which GNAP
                                supports, the access token is opaque to
                                the Client. As you have noted, there are
                                use cases where the access token is NOT
                                opaque.

                            

                          

                        

                      

                      
[Denis] Wait a second. There is no requirement
                        to support all OAuth use cases. 

                        I believe that there is a requirement to support
                        OAuth 2.0 ASs, while the clients may be
                        different 

                        and hence GNAP clients do not need to inherit of
                        the limitations of OAuth 2.0 clients.

                      

                        

                          

                            

                              
=C2=A0

                              

                                

                                  

                                    

                                      

                                        
=C2=A0

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    
 

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          
If a RO
                                                          needs to be
                                                          involved and
                                                          since a RO is
                                                          directly
                                                          associated
                                                          with a RS, why
                                                          can't it be
                                                          directly
                                                          queried 

                                                          by the
                                                          appropriate RS
                                                          after step (2)
                                                          or later on ?
                                                          

                                                          

                                                          


                                                          

                                                          
Good
                                                          question.
                                                          Perhaps you
                                                          can expand on
                                                          a use case
                                                          where that
                                                          would be
                                                          useful?

                                                          

                                                        

                                                      

                                                      
Before I
                                                        expand, would
                                                        you be able to
                                                        explain first
                                                        under which
                                                        circumstances a
                                                        RO needs to be
                                                        queried by a GS
                                                        ?

                                                        How can the GS
                                                        identify which
                                                        RO to query ?

                                                    

                                                  

                                                  
If the User is
                                                    the RO, then the GS
                                                    knows who to query.
                                                    

                                                  

                                                

                                              

                                            

                                            
I still have difficulties
                                              to understand what you
                                              mean here. 

                                              How could a GS know that
                                              "the User is the RO"=
; ?=C2=A0 If
                                              "the User is the RO"=
;, why
                                              does the GS needs to query
                                              the User ? 

                                            

                                          

                                        

                                        


                                        

                                        
To get consent?

                                      

                                    

                                  

                                  
To get a "RO consent" to him=
self
                                    ???

                                

                              

                              


                              

                              
The GS needs consent from the RO. If
                                the RO is the User, then consent from
                                the RO is equivalent to consent from the
                                User.

                            

                          

                        

                      

                      
[Denis] See above.

                      

                      

                        

                          

                            

                              
=C2=A0

                              

                              

                                

                                  

                                    

                                      

                                        
=C2=A0

                                        

                                          

                                            

                                              

                                                

                                                  
If the RO is a
                                                    separate entity,
                                                    then the GS knows
                                                    the RO from the RS
                                                    being queried. 

                                                  

                                                

                                              

                                            

                                            
=C2=A0... and this gives the
                                              ability for the GS to
                                              log/trace all the RSs
                                              accessed by a given User
                                              and at which instant of
                                              time the access token has
                                              been granted.

                                            

                                              

                                                

                                                  
An example=C2=A0is a
                                                    user would like
                                                    access to an
                                                    enterprise asset
                                                    where a workflow is
                                                    started to gain
                                                    approval, and an
                                                    administrator or
                                                    manager provides
                                                    consent.

                                                

                                              

                                            

                                            
Thanks for this example.
                                              I finally understand what
                                              you have in mind: you are
                                              considering using an
                                              access control model to
                                              build a workflow model=
.
                                              

                                              While it may be
                                              interesting to define a
                                              workflow model, this
                                              should be considered as a
                                              separate and different
                                                work item.

                                          

                                        

                                        


                                        

                                        
The actual workflow is out
                                          of scope. 

                                      

                                    

                                  

                                  
I am glad you agree with this. But
                                    this means that your example was not
                                    appropriate to illustrate your
                                    point.

                                  

                                

                              

                              


                              

                              
It illustrates a use case where the
                                RO and User are not the same party, and
                                why the GS needs to query the RO, which
                                was your question if I understood it
                                correctly.

                            

                          

                        

                      

                      
[Denis] Since the inputs and the outputs for
                        this "RO consent" phase are not currently
                        described in the draft, the point is still
                        unsolved.

                      

                      

                        

                          

                            

                              

                                

                                  
 As soon as there is a RO consent
                                    obtained at the GS, the major
                                    problem is that the GS is able to
                                    act as Big Brother.

                                    If a RO consent is performed at the
                                    RS, then the GS will not know who
                                    the RS is: it is then unable to act
                                    as Big Brother, 

                                    even if it would enjoy to play that
                                    role.

                                

                              

                              
In an enterprise use case, the GS's
                                knowledge of who is accessing which RS
                                is a feature.

                            

                          

                        

                      

                      
Do you mean that it is "normal" in an
                        enterprise that a single point of control is
                        able to trace all their actions ? 

                        From a security point of view, a single point of
                        failure will have dramatic consequences.

                      

                        

                          

                            

                              
In your use cases, it seems that the
                                RO is the User. 

                            

                          

                        

                      

                      
I do hope that you have finally understood
                        that, in my use case, the RO is **not** the
                        User.

                      

                        

                          

                            

                              
The GS knows the User is wanting to
                                let a Client access something. If the
                                access token is generic, and could be
                                presented to any RS that provides a
                                standardized function, 

                                then the GS does not know which RS is
                                being accessed by a Client for the User.
                                This seems to meet your privacy
                                objectives. If not, what is wrong?

                            

                          

                        

                      

                      
For security reasons, an access token needs to
                        be targeted (which does not necessarily mean
                        that an identifier of the RS shall be included
                        into the access token).

                      

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
if the admin grants access,
                                          then the access granted to the
                                          client changes. 

                                        

                                        

                                          

                                            
 

                                            
The model you propose may
                                              be suited for an
                                              enterprise environment but
                                              is not scalable over the
                                              Internet.

                                          

                                        

                                        
It is one of the use cases
                                          we are working to address. 

                                        

                                        

                                          

                                            
 What is needed is an
                                              access control model
                                              usable over the Internet
                                              with millions of RSs and
                                              thousands of ASs/GSs.=C2=A0 <=
br>
                                            

                                          

                                        

                                        
I agree the model should
                                          also scale to internet scale.
                                          

                                        

                                      

                                    

                                  

                                  
Fine. Another point on which we are
                                    in agreement. 

                                  

                                  
The model can scale to the Internet
                                    based on the following assumptions:

                                  

                                    
The flow starts with the steps
                                      (1) to (4) as illustrated by
                                      Francis, i.e. the flow starts with
                                      a contact with a RS.

                                  

                                  
+----+
                                        =C2=A0+------+ =C2=A0+---+ =C2=A0+-=
--+ =C2=A0+---+

                                        |User| =C2=A0|Client| =C2=A0|RS | =
=C2=A0|GS |
                                        =C2=A0|RO |

                                        +----+ =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 |(2) Service Intent
                                        =C2=A0 |

                                        =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =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) AuthZ Challenge
                                        =C2=A0|

                                        =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =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) AuthZ Request =C2=A0
                                        =C2=A0|

                                        =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 |------------->|
                                        =C2=A0 =C2=A0 =C2=A0|
                                  
The GS/AS does not need to have any
                                    prior relationship with ROs and/or
                                    RSs.

                                  
Furthermore, it is possible to
                                    prevent the GS to act as Big Brother
                                    when the identity of the RS is not
                                    disclosed to the GS.

                                  

                                

                              

                              


                              

                              
What happens after (4) above? 

                              

                            

                          

                        

                      

                      
[Denis] The key point is that we first need to
                        agree on the first four exchanges. Do we ?

                      

                      
The fifth exchange is different whether ACLs or
                        Capabilities are being used.

                      

                      

                        

                          

                            

                              
=C2=A0

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          
Which
                                                          information is
                                                          supposed to be
                                                          presented to
                                                          the RO ?

                                                          Which
                                                          information is
                                                          supposed to be
                                                          returned by
                                                          the RO ?

                                                          

                                                          

                                                          


                                                          

                                                          
Just like
                                                          how the user
                                                          authenticates
                                                          to an AS, how
                                                          the AS and RO
                                                          communicate is
                                                          out of scope.

                                                          

                                                          

                                                        

                                                      

                                                      
At the moment,
                                                        the usefulness
                                                        of a dialogue
                                                        between a GS and
                                                        a RO has not
                                                        been explained,
                                                        nor
                                                        demonstrated.

                                                        The question is
                                                        about the
                                                        functionality of
                                                        that dialogue in
                                                        terms of input
                                                        and output
                                                        information (and
                                                        not about 

                                                        the design of a
                                                        protocol or of a
                                                        user interface).
                                                        Anyway, AFAIU a
                                                        dialogue between
                                                        a GS and a RO is
                                                        optional.

                                                      

                                                    

                                                  

                                                  


                                                  

                                                  
See enterprise
                                                    example above.

                                                

                                              

                                            

                                            
It is not an access
                                              control example, but a
                                              workflow example.

                                            
Access=
=C2=A0
                                              control has been defined a
                                              long time ago and the last
                                              edition of the model has
                                              been confirmed in year
                                              1996: ISO/IEC=C2=A010181-3:
                                                  1996.

                                              "Information
                                                technology=C2=A0=E2=80=94 O=
pen
                                                Systems
                                                Interconnection=C2=A0=E2=80=
=94
                                                Security frameworks for
                                                open systems: Access
                                                control framework=C2=A0=E2=
=80=94
                                                Part=C2=A03".
                                            
Two
                                                major functions have ben
                                                defined: an Acces=
s Control Enforceme=
nt Function
                                                    (AEF) and an Access
                                                Control =
Decision
                                                Function(ADF).=


                                            

                                              
=
Access
                                                  Control Enforcement=

                                                  Function (AE=
F):

                                                  A specialized function
                                                  that is part of the
                                                  access path between an
                                                  initiator and a target
                                                  on each access request
                                                  and enforces the
                                                  decision made by the
                                                  ADF.

                                              Access Control Decision
                                                Function (ADF) :

                                              A
                                                specialized function
                                                that makes access
                                                control decisions by
                                                applying access control
                                                policy rules to an
                                                access request, ADI (of
                                                initiators, targets,
                                                access requests, 
                                              or
                                                that retained from prior
                                                decisions), and the
                                                context in which the
                                                access request is made.

                                            
The role of the RO is to
                                              define the "access
                                                control policy rules" =
at
                                                the RS according to the=
 context
                                                  in which the access
                                                  request is made.

                                          

                                        

                                        
I'm pretty familiar with
                                          access control systems. :)=C2=A0<=
/div>
                                        


                                        

                                        
I would say that the access
                                          control is happening at the
                                          RS. The client presents a
                                          token when accessing an API. 

                                          The RS uses the token, and any
                                          policy required, to make an
                                          access decision.

                                      

                                    

                                  

                                  
Fine. It looks like we are in
                                    agreement. Unfortunately, this is
                                    not the case just below.

                                  

                                  

                                    

                                      

                                        
Here is flow:

                                        


                                        

                                        
1) The Client requests
                                          access to an RS from the GS. 

                                        

                                      

                                    

                                  

                                  
No. We are no more in agreement.
                                    This is different from the flow
                                    drawn by Francis.

                                

                              

                              
My bad. Typo. I meant RO.

                              
=C2=A0

                              

                                

                                  

                                    

                                      

                                        
2) The GS queries the RS if
                                          access should be granted. 

                                        

                                      

                                    

                                  

                                  
=C2=A0No. The GS should not be forced =
to
                                    have a flow with the RS.

                                

                              

                              
Same mistake as above, I meant RO.=C2=A0=


                              

                                

                                  
 

                                  

                                    

                                      

                                        
3) If access is granted,
                                          the GS creates an access token
                                          representing the granted
                                          access, and returns it to the
                                          Client. 

                                        

                                      

                                    

                                  

                                  
This model is by no way conformant
                                    to ISO/IEC=C2=A010181-3:
                                        1996 

                                      

                                

                              

                              
I'm unclear on why, or why it is eve=
n
                                relevant. 

                              

                              

                                

                                  
 

                                  

                                    

                                      

                                        
4) The Client presents the
                                          access token to the RS to show
                                          it has been granted access. 

                                        

                                      

                                    

                                  

                                  
No. The client presents a token
                                    when accessing an API. The RS uses
                                    the token, and any policy required,
                                    to make an access decision.

                                    The token never contains an
                                    information like "Please grant an
                                    access to the holder of this token"=
;.

                                

                              

                              
Let me provide more clarity in the
                                sentence:

                              


                              

                              
The Client presents the access token
                                to the RS, to show the RS that the
                                Client has been granted access to a
                                resource at the RS by the GS.

                            

                          

                        

                      

                      
[Denis] This time, please consider both the
                        ACLs approach and the Capabilities approach.

                      

                        

                          

                            

                              
=C2=A0

                              

                                

                                  

                                    

                                      

                                        
A couple advantages of this
                                          model:

                                        
- that the RS does not need
                                          to know much, if anything
                                          about the Client.=C2=A0

                                        
- the access token MAY be
                                          self contained so that the
                                          Client does not need to query
                                          the GS on each access. 

                                        

                                      

                                    

                                  

                                  
There are so many disadvantages
                                    that I will not list them.

                                

                              

                              
Darn: I clearly was not firing on all
                                cylinders when I typed this out. Let me
                                correct:

                              


                              

                              

                                

                                  

                                    

                                      
- the access token MAY be
                                        self contained so that the RS
                                        does not need to query the GS on
                                        each access to the RS by the
                                        Client.

                                    

                                  

                                

                              

                            

                          

                        

                      

                      
[Denis] A few comments in the case of a
                        capability approach:

                      

                        
- for each GS, the RS needs to locally manage
                          which operation(s) is/are allowed to it.

                          

                          - the GS needs to establish a trusted
                          communication channel or an authentication
                          mechanism with each RO 

                          =C2=A0=C2=A0 (which is associated with an explici=
t RS
                          identifier). 

                        

                        
- the GS could play the role of the RO and
                          hence be in a position to issue any capability
                          for any RS (without a "RO consent"). 
                          

                          =C2=A0=C2=A0 The target of an attack will clearly=
 be the
                          GS.

                        

                      

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        
I would not say that GNAP
                                          is an access control protocol,
                                          as how the RS uses the token
                                          to determine access is out of
                                          scope.

                                      

                                    

                                  

                                  
This is where we have a ma=
jor
                                        discrepancy: how
                                    the RS uses the token to determine
                                    access is *within* the scope.

                                

                              

                            

                          

                        

                      

                      [Denis] Do you agree or disagree ?

                      

                        

                          

                            

                              

                                

                                  
The RS announces in advance to the
                                    client what it needs so that the
                                    client can perform a a given
                                    operation and if the client supplies
                                    the requested attributes 

                                    obtained from some GS/AS(s) trusted
                                    by the RS, then access to that RS is
                                    granted by the RS. If the RS cannot
                                    perform the requested operation on
                                    its own, 

                                    then the client should be informed
                                    about some requested attributes that
                                    need to be obtained from some
                                    GS/AS(s) trusted by the next RS(s)
                                    in a chain

                                    for subsequent operations. The User
                                    consent should also be obtained
                                    before performing the chaining
                                    operation.

                                  

                                  
Chaining operations between RSs
                                    over the Internet is within the
                                    scope (... and may be achieved).

                                

                              

                            

                          

                        

                      

                      
[Denis] Do you agree or disagree ?

                      
Denis

                      

                      

                        

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
=C2=A0

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
For many
                                                          use cases, the
                                                          User is the
                                                          RO, and the
                                                          interaction is
                                                          through a user
                                                          interface, not
                                                          a machine
                                                          protocol. 

                                                          

                                                          

                                                        

                                                      

                                                      
Wait a second.
                                                        You wrote "the
                                                        User is the RO"=
;.
                                                        The User is
                                                        attempting to
                                                        make an access
                                                        to a RS by using
                                                        a Client. 

                                                        That User
                                                        is not the RO of
                                                        the RS.=C2=A0=C2=A0=
 

                                                      

                                                    

                                                  

                                                  
The user being
                                                    the RO is the
                                                    initial use case for
                                                    OAuth. 

                                                

                                              

                                            

                                            
OAuth 2.0 is no more
                                              mandating such a case.

                                            

                                          

                                        

                                      

                                    

                                  

                                  

                                    

                                      


                                        
I don't know what you mean
                                          by that.

                                      

                                    

                                  

                                  
Copy and paste from
                                    draft-ietf-oauth-security-topics:

                                  

                                  

                                    
OAuth initially assumed a static
                                      relationship between client,
                                      authorization server and resource
                                      servers.=C2=A0 (...)=C2=A0 

                                      With the increasing adoption of
                                      OAuth, this simple model dissolved
                                      and, in several scenarios, was
                                      replaced 

                                      by a dynamic establishment of the
                                      relationship between clients on
                                      one side and the authorization and
                                      

                                      resource servers of a particular
                                      deployment on the other side.

                                      

                                      This way, the same client could be
                                      used to access services of
                                      different providers (in case of
                                      standard APIs, 

                                      such as e-mail or OpenID Connect)
                                      or serve as a frontend to a
                                      particular tenant in a
                                      multi-tenancy environment. 

                                    

                                  

                                

                              

                              


                              

                              
This sentence does not mention the RO
                                or the Client. I'm confused what we are
                                talking about=C2=A0

                              

                                

                                  

                                    
 

                                  

                                  

                                    

                                      

                                        
=C2=A0

                                        

                                          

                                            

                                              

                                                

                                                  
A client
                                                    application would
                                                    like access to the
                                                    user's photos at a
                                                    photo sharing site.
                                                    The resource is the
                                                    user's photos. The
                                                    user is the owner of
                                                    that resource.

                                                

                                              

                                            

                                            
If the user has already
                                              pre established the access
                                              control policy rules so
                                              that it can access to his
                                              own photos 

                                              then he does not need to
                                              grant in real time any
                                              additional authorization.

                                          

                                        

                                        
I don't understand what yo=
u
                                          are trying to say. The photo
                                          sharing example was a driving
                                          use case for the creation of
                                          OAuth.

                                      

                                    

                                  

                                  
We would need to revisit the
                                    original scenario and consider if it
                                    can be addressed in a different way
                                    than the original way.

                                

                              

                              
The use case is the same. Is there a
                                different solution you are proposing?

                              
=C2=A0

                            

                          

                        

                      

                      


                      

                    

                    -- 

                    Txauth mailing list

                    Tx=
auth@ietf.org

                    https://www.ietf.org/mailman/listinf=
o/txauth

                  

                

              

              


              

            

            -- 

            Txauth mailing list

            Txauth@iet=
f.org

            https://www.ietf.org/mailman/listinfo/txauth=


          

        

      

      
3D""==E1=90=A7

    

    


    

  



This is IMO the most correct word in the entire protocol. Au=
thorisation is always about the owner of something granting access to a req=
uestor. It really=C2=A0does not matter if a human interaction is involved. =
We will have to forget oAuth2 and OIDC of also calling this a User.<=
/div>

Grant Server:=C2=A0
Even t=
hough the definition of the UserInfo endpoint in OIDC as a protected resour=
ce hazardously makes an OP an RS, we shall not repeat the same mistake here=
. We need a clear separation between roles of GS and RS without overlapping=
.

Resource Server: services resources.

Unless I=
 got=C2=A0it wrong, GNAP is about grant negotiation and authorization. This=
 means:

GNAP is about some party requesting access=
 to some resources.
GNAP is about=
 the resource owner consenting access to that resource.
GNAP is about defining the infrastructure that allow=
s the requesting party to access a resource.=C2=A0

GNAP desig=
ns this infrastructure around:
- =
an orchestrator (what we refer to as a client)
- an grant manager (what we refer to as a GS/AS)
- the custodian of the resource (what we cal=
l a RS)

As you see:
- The word User does not appear here, and is not relevant as the focus=C2=
=A0is on authorizing access to a resource.
- The word Claim is as well absent.

Claim related=
 to RO:
The word Claim might star=
t getting visible if the orchestrator (a.k.a. Client) or the custodian (a.k=
.a RS) needs some additional information on the RO to proceed with the acce=
ss control decision. These claims refer to assertions of attributes or prop=
erties of the RO. These claims are issued by the GS as the GS manages inter=
action with the RO (see below). In this first place information about the r=
equesting party (erroneously.k.a. User) is =
not relevant to the negotiation and provisioning framework. Let us call thi=
s sort of claim "RO-Attributes". A better name is welcome.=


Some advanced resource provisioning frameworks might require knowle=
dge on attributes of the requesting party (e.k.a User). These attributes sh=
all be collected by the=C2=A0orchestrator (a.k.a Client) and added to the r=
esource request. There is no way the GS can collect these attributes as the=
 GS role has no interaction with the requesting party (e.k.a User).=C2=A0Le=
t us call this sort of claim "Requestor-Attributes". A better nam=
e will be welcome.

Some assertions are even related to the or=
chestrator=C2=A0(a.k.a Client) itself. This is the case of the public key o=
f an orchestrator=C2=A0used by the GS to "sender constrain" an ac=
cess token. Let us call this type of claim "Orchestrator-Attributes&qu=
ot;.

This is a sample mapping of OIDC.

+----+ =
=C2=A0 =C2=A0+---+ =C2=A0 +---+ =C2=A0+---+
|User| =C2=A0 =C2=A0|RP | =
=C2=A0 |OP | =C2=A0|RS |
+----+ =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 |(2) redirect=
=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |<--------| =C2=A0=
 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=3D=3D=3D User (requestor) passes control to User (RO) =3D=3D=3D
=C2=A0 |(3) Auth + Consent =C2=A0 =C2=
=A0 =C2=A0|
=C2=A0 |---------------->| =C2=A0 =C2=A0 =C2=A0|
=C2=
=A0 |(4) redirect (code) =C2=A0 =C2=A0 |
=C2=A0 |<----------------| =
=C2=A0 =C2=A0 =C2=A0|
=3D=3D=3D U=
ser (RO) passes control back to User (requestor) =3D=3D=3D
=C2=A0 |(5) g=
et(code) =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |-------->| =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) token (code)
=C2=A0 | =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=
) token =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<------=
| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(8) Servic=
eRequest(token)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |------------->|=

=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(9) ServiceResponse
=C2=A0 | =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |<-------------|
=C2=A0 |(10) ServiceResp=
onse =C2=A0 =C2=A0|
=C2=A0 |<--------| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =
=C2=A0 =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>
- RP orchestrates interaction=
 between User and OP to enable the user to obtain the protected resource.
- In step 1 & 10 User plays th=
e role of the requestor of the resource.
- In step 2 User-Browser is used to pass control from User (in his =
role as the requestor) to User (in his role as the RO)
- In step 4=C2=A0User-Browser is used to pass control=
 from User (in his role as the RO) back to=C2=A0User (in his role as the re=
questor)

When we are talking claims here, we are talking clai=
ms on the User (in his role as the RO). The OP does not have any interactio=
n with the User (in his role as the requestor). In the case of an App2App r=
edirection, the OP can not even assert about the user agent of the User (re=
questor).

<=
font face=3D"monospace">If there is any claim the OP can provide, it is a c=
laim on the User (RO).

I hope this example clarifies the misu=
nderstanding. Any attempt of bringing this double role of the User into GNA=
P will also bring this confusion. In order to keep this out of GNAP let us =
look for the right term for User (as a requestor) using the diagram display=
ed below.

<=
font face=3D"monospace">+----+ =C2=A0+------+ =C2=A0+---+ =C2=A0+---+ =C2=
=A0+---+
|Reqs| =C2=A0|Orchst| =C2=A0|RS | =C2=A0|GS | =C2=A0|RO |
+-=
---+ =C2=A0+------+ =C2=A0+---+ =C2=A0+-+-+ =C2=A0+-+-+
=C2=A0 |(1) Serv=
iceRequest =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 |(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 |(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|(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 |(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 |(6) ServiceRequest(=
AuthZ):ServiceResponse
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<-----&g=
t;| =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+

- Replacing the word User helps clarif=
y the difference between both roles "Requestor" and "Resourc=
e Owner"
- Renaming claim by=
 attaching the Object/target of the claim (e.g.: RO-attributes, Requestor-A=
ttributes, Orchestrator-Attributes) also helps identify the source of those=
 attributes (GS, RS, Client):

Best regards.=

/Francis

On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt <dick.hardt@gmail.com> wrote:
<=
div>It is not clear to me what it matters if a Claim comes from an RS, or f=
rom the GS, so I don't see a need to differentiate them.

=

I would include verifiable credentials and user-bound keys as Cl=
aims.

All the payment processing information I hav=
e=C2=A0seen has been in RAR. When would=C2=A0the Client get payment process=
ing directly from the GS?

What is your example for=
 distributed networks storage locations? If what is stored is a statement a=
bout the user, then I would consider that a Claim as well.

We disagree on how to map OIDC to GNAP.=C2=A0 The direct data is a=
 claims request, the data coming indirectly is an access token request.



On Fri, Jul 24, 2020 at 1:39 PM Justin Rich=
er <jricher@mit.edu=
> wrote:
=

Since we=E2=80=99re already talking about returning claims as direct d=
ata as well as a part of the resource API being protected, so we already ne=
ed a way to differentiate the two kinds of items. Just calling it =E2=80=9C=
claims=E2=80=9D doesn=E2=80=99t help, because as you=E2=80=99ve pointed out=
 they could show up in both places. So yes, defining that difference is som=
ething we should worry about now, even if the core protocol only uses it fo=
r claims.

The two forms of direct data that XYZ returns =
are subject identifiers (a subset of identity claims) and assertions =E2=80=
=94 the latter being a container not just for identity claims but also auth=
entication information and other elements. Assertions are not claims themse=
lves.=C2=A0

Other use cases that have been brought=
 up include verifiable credentials and proofs, user-bound keys, payment pro=
cessing information, and distributed network storage locations. I=E2=80=99m=
 sure there are a lot more. To me, these are subsets of the =E2=80=9Cdirect=
 data=E2=80=9D but not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=
=80=99t be defining what all of these look like, but it should define a way=
 to talk about them.

I think different top-level r=
equest objects are better suited for different query semantics. Like, for e=
xample, the OIDC =E2=80=9Cclaims=E2=80=9D request, which allows targeting o=
f its claims information into different return buckets. This overlaps with =
the =E2=80=9Cresources=E2=80=9D request at the very least. I don=E2=80=99t =
think GNAP should define how to do this specific combination, that should b=
e for OIDF to debate and apply. The same with a DID service based query, or=
 Presentation Exchange [1], or anything else that people want to come up wi=
th.

In my view, GNAP should define query structure=
s for two things: rights that get tied to an access token and data that com=
es back directly to the client. For the latter, I think we can do some very=
 limited and very useful specific items, which is what I=E2=80=99ve put int=
o XYZ.

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

[1]=C2=A0https://identity.foundation/presentation-exch=
ange/

On Jul 24, 2020, at 3:=
58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I a=
gree we want GNAP to be a strong foundation.=C2=A0

Do yo=
u have an example of other "direct data"? If so, do you expect it=
 to be defined in the core protocol?

I would expec=
t an extension for other "direct data" to define top level object=
s, and an appropriate definition for that "direct data".

My "do we need to worry about it now" comment wa=
s on creating a generic term for "direct data". Unless we are sol=
ving those now, we can let further work define that "direct data"=
 explicitly.




=3D""=E1=90=A7

On Fri, Jul 24, 2020 at 12:42 PM =
Justin Richer <jric=
her@mit.edu> wrote:
Yes, I do think we need to worry about it to the extent tha=
t we are not creating something that is over-fit to a limited set of use ca=
ses.=C2=A0

GNAP should be a foundation that many amazing=
 new things can be built on top of.

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

On Jul 24, 2020, at 3:06 =
PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin=
, thanks for clarifying.

What are some examples of other=
 "direct data" that the GS may return? If it is not in core GNAP,=
 do we need to worry about now? We can then give the direct data from the G=
S that is not a claim, an appropriate name in that document.

=



On Fri, Jul 24, 2020 at 11:46 AM Justin Richer <jricher@mit.edu> w=
rote:
Dick:=
 No, I think you=E2=80=99re misunderstanding what I=E2=80=99m saying. I agr=
ee that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But =
the AS could return other data directly to the client that isn=E2=80=99t ab=
out the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=80=9D by the classica=
l definition. Also since =E2=80=9Cclaims=E2=80=9D can come back from places=
 other than directly, then we shouldn=E2=80=99t call everything that comes =
back a =E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m arguing that=
 we keep =E2=80=9Cclaims=E2=80=9D to mean what it already means and come up=
 with a new word to mean =E2=80=9Cthings that come back directly from the A=
S=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s more co=
mplete definitions, but to simplify:

Claims:
=

	- information about the u=
ser
	- can come back =
directly from the AS
	- can come back in a resource from the RS

Resourc=
e:
	- Returned from a=
n RS
	- Protected by =
access token
	- Could=
 contain claims about the user

Direct data (or som=
e better name):
	- Re=
turned directly from AS
	- Could contain claims about the user

I think =
the problem is that some people are using =E2=80=9Cclaims=E2=80=9D to mean =
#1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s =
important to remember, when talking about OIDC, that an IdP in OIDC combine=
s an AS and an RS into one entity for identity information. There can be ot=
her RS=E2=80=99s as well, and there usually are in the wild, but the one de=
fined by OIDC is the UserInfo Endpoint. The fact that it returns user data =
doesn=E2=80=99t make it any less of an RS.

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

* In the wider context of things like t=
he information claims inside a JWT, the claims could be about literally any=
thing, but that=E2=80=99s not what we=E2=80=99re discussing here and it=E2=
=80=99s not how it=E2=80=99s being used.


On Jul 24, 2020, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com>=
 wrote:

In OpenID Connect (OIDC), the Client=
 can obtain Claims directly from the OP in an ID Token, or the Client can o=
btain Claims using an access token to call the UserInfo endpoint, a Protect=
ed Resource[1].

The Claims are about the User (not a RO)=
.

In XAuth, I'm proposing the Client may obtai=
n bare claims from the GS directly in addition to the mechanisms in ODIC.

So I don't think we are changing the definition=
 of Claim from how it has been used in OIDC, and I fail to see any reason t=
o NOT use Claim.

Justin: you allude to Claims bein=
g about a party other than the User. Would you provide an example?

/Dick

[1]
UserInfo Endpoint=

Protected Resource that, when presented with an Access Token by =
the Client, returns authorized information about the End-User represented b=
y the corresponding Authorization Grant. The UserInfo Endpoint URL MUST use=
 the https scheme and MAY contain port, path, and query parameter component=
s.



3D""=E1=90=A7

On Fri, Jul 24, 2020 at 5:58 AM Justin Richer=
 <jricher@mit.edu> wrote:
I want to focus on one aspect here:


A Claim is =
a well understood term in the field. We should use it. It is still a Claim =
if it comes directly from the GS or from an RS.=C2=A0
I do not understand why a Resource release by an RS shall be h to a=
s a claim, even if the content of the Resource is an assertion. It will lea=
d to confusion. If we limit claims to information GS releases into Token, U=
ser Info, and other objects it returns, this will help separate responsibil=
ities between GS and RS. As soon as RS services and information, this is ca=
lled a Resource, no matter the nature of the content of that information.

This is exactly why I don=
=E2=80=99t think we should use =E2=80=9Cclaim=E2=80=9D in the way that we=
=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back throug=
h an RS =E2=80=94 but in the context of GNAP, that makes it a resource. So =
we need a different word for data coming back directly from the AS to the c=
lient. Sometimes it=E2=80=99s going to be about the user, and that=E2=80=99=
s what we=E2=80=99re going to focus on here, but since you can also get inf=
ormation about the user from a resource we can=E2=80=99t just call it a =E2=
=80=9Cclaim=E2=80=9D. I think this has been at the heart of a lot of confus=
ion in recent threads, as well as confusion about the scope of the inclusio=
n of identity in the GNAP protocol.

So let=E2=80=
=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does, and let=E2=80=
=99s find a way to differentiate between when an item, claim or otherwise,=
=C2=A0=C2=A0comes as part of a resource and when it comes back directly. Th=
is is an important differentiating feature for GNAP.

Some straw man ideas, none of which I=E2=80=99m particularly in love wit=
h:

=C2=A0- direct data
=C2=A0- propertie=
s
=C2=A0- details
=C2=A0- statements

The important thing here is that it=E2=80=99s not necessarily :about=
: the RO, and that it is :not: in a resource.

Any other=
 thoughts?

=C2=A0=E2=80=94 Justin












-- 


--000000000000c39f9805ab3abf38--


From nobody Fri Jul 24 19:49: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 8DF573A1131 for ; Fri, 24 Jul 2020 19:49:06 -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 d_w92Z3khJcC for ; Fri, 24 Jul 2020 19:49:03 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 B77EB3A112B for ; Fri, 24 Jul 2020 19:49:02 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id a15so9857698wrh.10 for ; Fri, 24 Jul 2020 19:49: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=CHw4fC7i0MAW9+c/M9ror9G9FZogewcqMNp2+395phc=; b=CWIDv9dfuIwWS5uShvpJ8KtIRmc8wsP3NTva/Eamy4fEZidQFxmzm7CqcLL4exmyaI 5v66piZ9WA6611iJ1PoNwYCgooV4QhlKUXY5x1Ua+Ae4LvMZVgaDk0IZvw1Cy1jA2vzz 8dvc4eRaEVkrZv8pQfDmkFr4njoUMMC0rMI6Q=
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=CHw4fC7i0MAW9+c/M9ror9G9FZogewcqMNp2+395phc=; b=P2F5JiVSHXzKGQE7hHYOBKVJGp5E2YbCMSaUjCKiws8J39lje2DmCFJKSViFXKb4pz Inxf+TgO3zQTNe3X51oY1G/dgR0OL8E48uRJSkIojM3BZAh4q4KLYkBjoPOMEwjlUYyT tig8hUcZR6DKG+y90BUkV8t0adSrAx/4slLgC7/Ve+J9wLC3XnZ0VNbMaoMBvTec4/R0 CXXS73FNsNeEfZrBo5QQxt99+NFF5sT3qxepOaK1OOzicfgigQHv2zSGf9lh4pZZNBEU H3UQ1d6k3tCAVpoZ5d4reB4sykVWw8gJMv76hhpy/FVaqXUGVS1sxlzA5/051aqO64D0 9vQw==
X-Gm-Message-State: AOAM531fWwJ3aqu+OcVPsAzzzyWINFpw7mjGLnNP4UF1daGdjeqo7h2b A1hE9dslgwjRG7oKU4m4qI5Yxjz5+3I2ISuH/kP8+w==
X-Google-Smtp-Source: ABdhPJxleDc/P0waloZWjH73fFfko01F7DUshBxRgtvqBschLn2n3DnC/3YDMTClH0OGUdhXePQ2s14uytO3xSzH0rM=
X-Received: by 2002:a5d:65d2:: with SMTP id e18mr10635974wrw.70.1595645340915;  Fri, 24 Jul 2020 19:49:00 -0700 (PDT)
MIME-Version: 1.0
References:              
In-Reply-To: 
From: Francis Pouatcha 
Date: Fri, 24 Jul 2020 22:48:49 -0400
Message-ID: 
To: Dick Hardt 
Cc: Justin Richer , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="000000000000bba64c05ab3b211c"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 25 Jul 2020 02:49:07 -0000

--000000000000bba64c05ab3b211c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Dick,

On Fri, Jul 24, 2020 at 1:17 PM Dick Hardt  wrote:

> Hi Francis
>
> It appears we have two areas to provide additional clarity:
>
> 1) In OIDC, the UserInfo endpoint is NOT part of the OP. It is a Protecte=
d
> Resource. Per
> https://openid.net/specs/openid-connect-core-1_0.html#Terminology
>
> UserInfo Endpoint
> Protected Resource that, when presented with an Access Token by the
> Client, returns authorized information about the End-User represented by
> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST use
> the https scheme and MAY contain port, path, and query parameter componen=
ts.
>
>
> Therefore a RS is providing Claims in OIDC. (RS is the same as a Protecte=
d
> Resource)
>

UserInfo Endpoint
Protected Resource that, when presented with an Access Token by the Client,
returns authorized information about the End-User represented by the
corresponding Authorization Grant. The UserInfo Endpoint URL MUST use the
https scheme and MAY contain port, path, and query parameter components.

This definition transported to GNAP will lead to confusion. The term user
in OIDC refers to both the User and the RO. Correct mapping to GNAP will
lead to the RoInfo Endpoint...

See [Txauth] Claims [was: - Dictionary]

>
> 2) The RO may be the User, or it may be some other entity. For example,
> the Client may want access to a Resource owned/controlled by an enterpris=
e.
> The RO is not the User, and there may not be a User using the Client.
>
> See the Independent RO Authorization sequence as an example:
>
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-13#section-2.3
>
> Note there is no User in this sequence
>
>
> more detailed comments inserted ...
>
Have an illustration in the thread on Claims. User in oAuth and OIDC plays
both roles of User (as requestor of a resource) and User (as owner of a
resource)

>
>
> On Fri, Jul 24, 2020 at 5:15 AM Francis Pouatcha  wrote:
>
>>
>>
>> On Thu, Jul 23, 2020 at 10:44 PM Dick Hardt  wrote=
:
>>
>>>
>>>
>>> On Thu, Jul 23, 2020 at 7:16 PM Francis Pouatcha  wrote=
:
>>>
>>>> Hello Dick, my feedback inline
>>>>
>>>> @Fabian : i am not yet consistent with using the notation you
>>>> referred to in
>>>> https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en. Still to
>>>> come.
>>>>
>>>> On Thu, Jul 23, 2020 at 7:52 PM Dick Hardt 
>>>> wrote:
>>>>
>>>>> Hi Francis
>>>>>
>>>>> Thanks again for putting this together. I have taken your definitions
>>>>> and adjusted them to match how I think of them. I dropped the term
>>>>> "parties" because I did not think it added value. I am explicit about=
 what
>>>>> each party is -- software, a human, or an entity. Let me know where y=
ou
>>>>> disagree!
>>>>>
>>>>>
>>>>> Resource - protected data or software functionality
>>>>>       - controlled by a Resource Owner (RO),
>>>>>       - protected by the Resource Server (RS)
>>>>>
>>>> Yes
>>>>
>>>>>
>>>>> Claim - a statement about the User
>>>>>
>>>> I would stay with RO not User. I added some clarification after the
>>>> feedback of Justin (see below)
>>>>
>>>
>>>
>>>
>>>
>>>>       - may be obtained from the Grant Server (GS) by a Client
>>>>>
>>>> Yes.
>>>>
>>>>>       - may be a Resource the Client can access through an RS
>>>>>
>>>> Not sure we need to refer to a Resource as a Claim.
>>>>
>>>
>>> Here is why I say a Claim may be a Resource.
>>>
>>> A Claim may be obtained by a Client calling an RS. This is effectively
>>> what the userinfo endpoint is in OpenID Connect. A Client may also upda=
te a
>>> Claim that is managed by an RS.
>>>
>> In OIDC the UserInfo endpoint is exposed by the OP not by an RP. Spec
>> wording is confusing because the endpoint is referred to as a protected
>> resource. If you derive from this that the OP is a resource server (RP),
>> you turn the OP into an RP relying on itself. This cyclic relationship h=
as
>> to be broken in GNAP for simplicity.
>>
>
> (I'm assuming you intended RS, not RP above)
>
yes. Sorry. RS....

>
> See above per the UserInfo endpoint being a Protected Resource, and is no=
t
> the OP.
>
This endpoint is generally provided by the OP. Means the OP plays the role
of an RS.

>
>
>>
>> Note-x on GS definition: having a GS protecting access to some Claims
>> does not make the GS a RS.
>>
>> For simplicity, let us keep overlapping out:
>> - GS guards Claims
>> - RS guards Resources
>>
>> I do not see a Client updating a Claim in the scope of any of these
>> protocols. Neither GNAP nor oAuth2 nor OIDC.
>>
>
> I agree that how a Client updates a Claim is out of scope (at least in th=
e
> core protocol).
>
>
>
>>
>>>
>>>>
>>>> A Claim - an assertion of the truth of some properties or attributes
>>>> of the RO.
>>>>   Note-1: A Claim is issued either by the GS or by another claim issue=
r.
>>>>
>>>
>>>
>>> I'm viewing the Claims Issuer as an entity, not a piece of software. It
>>> is the entity trusted by other parties to make a Claim about the User. =
The
>>> GS and RS may issue claims on behalf of the Claims Issuer.
>>>
>> No. Issuer is GS. Any twiking of the word will diverge it from oAuth2 an=
d
>> OIDC and increase complexity.
>>
>
> The Issuer is an entity. The GS is software.
>
What do we refer to with the "iss" in a JWT?

>
>
>>
>> This is why RS shall not issue anything, shall not deal with claims, ...=
.
>> RS guards Resources. If you start dealing with RS issuing claims, you st=
art
>> dealing with RS exposing jwks-url so issued claims can be verified, then
>> you fall back at having those RSes being GSes.
>>
>
> I'm saying a Resource *may* be a Claim, just as it is in OIDC UserInfo.
>
The word UserInfo in OIDC is misleading. This is the Info on User in it's
role as the RO. It is the RoInfo...

>
>
>
>>
>>>
>>>
>>>>   Note-2: A Claim is held and guarded by the Grant Server (GS).
>>>>
>>>
>>> What is the significance of this statement? Signed claims don't exist
>>> until asked for, so they are not "held" anywhere.
>>>
>> A Claim can exist before. GS might hold a Claim issued by an external
>> "Claim Issued".
>>
>
> Would you provide an example?
>
RO Identity Card signed by another authority, given to GS by RO, guarded by
GS and returned on request to Client/RS.

>
>
>>
>>>
>>>>   Note-3: A Claim is released by the GS to a Client.
>>>>
>>>
>>> The model of a Claim being obtained from an RS is a common use case.
>>>
>> I am not aware of any of them. Unless we are calling a GS a RS.
>>
>
> See UserInfo above. Also, the APIs at Twitter, Facebook, Google etc. are
> RSes, that may return Claims about the User.
>
These are all OP/AS. They don't see the user, but the RO.

>
>
>>
>>>
>>>>   Note-4: The permission to release of a Claim is given by the RO.
>>>>
>>>
>>> I will see what you say below on User ...
>>>
>>>
>>>>
>>>>
>>>>> Grant - the Claims and/or Resource Access the User and/or RO have
>>>>> granted to the Client by the GS
>>>>>     - requested by a Client
>>>>>     - granted by a GS after any required consent has been obtained
>>>>> from the User and/or RO
>>>>>
>>>> "User and/or RO" is confusing. I suggest we keep the term User out.
>>>> Term User is even eligible for renaming. I suggest staying with RO.
>>>>
>>>
>>> The User of the Client and the RO may not be the same entity. Some
>>> resources may be controlled by the RO, and others by the User. That is =
why
>>> User and/or RO. They are two different parties.
>>>
>> I need the example of a User that is different from the RO and that
>> controls the RO's Resource.
>>
>
> See above.
>
>
>>
>> And if a User controls a Resource, then he does it as the "Owner" of tha=
t
>> Resource(playing the role of the RO for that Resource).
>>
>> If we talk about roles and not entities, we will not fall into this
>> confusion.
>>
>
> I think we are defining an entity playing a specific role.
>
>
>>
>>>
>>>>
>>>>
>>>>> Access Token - an artifact representing the access a client has been
>>>>> granted to one or more Resources
>>>>>     - created by the GS
>>>>>     - presented by the Client when accessing a Resource at an RS
>>>>>
>>>> An access token might contain Claims.
>>>>
>>>
>>> While there may be statements about the User in the access token, it is
>>> not the mechanism for transmitting Claims to the Client -- and I think =
the
>>> access token SHOULD be opaque to the Client most of the time.
>>>
>> - Access "might" contain a claim ("must" not). Precision is essential as
>> we can not kill this practice without removing the concept of assertion
>> based tokens.
>> - Returning the information to the client does not mean the client is th=
e
>> consumer of the information. The client might not have access to the
>> content of an encrypted token, or even just to the embedded encrypted
>> claim. The intended destination of the claim will consume the claim. But
>> for the GNAP, the GS returns the token to the client.
>>
>
> Let me restate my position. Any claim that might be in the access token i=
s
> out of scope of GNAP, or at least the core protocol. How the RS uses the
> access token to protect access is out of scope, so the contents of the
> access token is out of scope.
>
Ok.

>
>
>
>>
>>>
>>>>
>>>> Access Token - an artifact representing the access a client has been
>>>> granted to one or more Resources
>>>>   Note-1: An access token is created by the GS
>>>>   Note-2: An access token can also contain claims
>>>>
>>>
>>> See above.
>>>
>>>
>>>>   Note-3: An access token is presented by the Client when accessing a
>>>> Resource at an RS
>>>>
>>>>
>>>>> Resource Owner (RO) - the entity that
>>>>>       - controls a Resource,
>>>>>       - has delegated Resource access control to one or more GSes
>>>>>       - may be the User
>>>>>
>>>> Confused here with the word "controls" both at RO and GS. I think RO
>>>> delegates Resource access management to GS but keeps control (or decis=
ion).
>>>>
>>>
>>> agreed - access management is better.
>>>
>>>
>>>>
>>>> Resource Owner (RO) - the entity that
>>>>       - controls a Resource,
>>>>       - relies on the services the GS to manage access to that Resourc=
e,
>>>>       - relies on the services of a RS to hold a Resource and guard
>>>> access to that Resource,
>>>>
>>>
>>> I don't think "guard" is a good verb. "protect" is often used.
>>>
>> OK.
>>
>>>
>>> If we are switching from "owns a resource" to "controls a resource",
>>> then perhaps the entity should be a Resource Controller (RC)?
>>>
>> Great. Will remove confusion.
>>
>>>
>>>
>>>
>>>>       - controls a Claim,
>>>>
>>>
>>> Why does the RO control a claim?
>>>
>> because a Claim is an assertion of the truth of some properties or
>> attributes of the RO.
>>
>
> The RO may or may not be a User. If the RO is not a User, who is the clai=
m
> about? What does "control" mean?
>
Claim of User (in his role as an RO) -> RO-Attributed
Claim of User (in his role as a requesting party) -> Requestor Attributes.
See [Txauth] Claims [was: - Dictionary]

>
>
>
>>
>>>
>>>>       - relies on the services the GS to release that Claim to a Clien=
t.
>>>>
>>>>>
>>>>> Resource Server (RS) - the software that controls access to one or
>>>>> more Resources
>>>>>       - accessed via an API by Clients presenting an access token
>>>>>       - accepts access tokens from one or more GSes
>>>>>
>>>> I suggest "guards" instead of "controls". As access to a resource is
>>>> controlled by the RO.
>>>>
>>>
>>> How about "protects access"?
>>>
>> OK for me.
>>
>>>
>>>
>>>>
>>>> Resource Server (RS) - the software that guards access to one or more
>>>> Resources
>>>>       - accessed by the Client that presents an access token
>>>>       - accepts access tokens from one or more GSes
>>>>
>>>>
>>>>>
>>>>> Grant Server (GS) - the software that manages Grants
>>>>>     - has been delegated to manage Resource access by the RO
>>>>>     - has been delegated to release Claims about the User
>>>>>     - grants the Client access to Resources after obtaining the
>>>>> required consent from the RO
>>>>>     - provides the Client Claims about the User after obtaining the
>>>>> required consent from the User
>>>>>
>>>> Term User is confusing here. This is why it is eligible for renaming.
>>>> - Claims are about RO not User
>>>> - Consent is from RO not User.
>>>>
>>>
>>> I'm confused why the Claims are about the RO and not the User.
>>>
>> Because the  user consumes the resource and the claim. I do like Justin'=
s
>> suggestion to call user the "Requesting Party"
>>
>
> The Client consumes the Resource and the Claims
>
> The Requesting Party sounds more like the Client than the User.
>
I have a more extensive elaboration in : [Txauth] Claims [was: -
Dictionary]

>
>
>>
>>> We have introduced the term RO so that entity can be differentiated fro=
m
>>> a User, and there are many use cases where there is a User. Not having =
a
>>> User seems very confusing to me.
>>>
>> Then let us call him a  "Requesting Party"
>>
>>>
>>>
>>>>
>>>> Grant Server (GS) - the software that manages Grants
>>>>     - has been delegated to manage Resource access by the RO
>>>>     - has been delegated to release Claims about the RO
>>>>     - grants the Client access to Resources after obtaining the
>>>> required consent from the RO
>>>>     - provides the Client Claims about the RO after obtaining the
>>>> required consent from the RO
>>>>
>>>>
>>>>> Client - the software that wants to access Resources and obtain Claim=
s
>>>>>     - executed by a User or a non-human service account
>>>>>     - requests Grants from the Grant Server
>>>>>     - accesses Resources at an RS using access tokens
>>>>>
>>>> Client - the software that wants to access Resources and obtain Claims
>>>> on behalf of a User or non-human service account
>>>>    Note-1: in a typical interaction cycle, the client:
>>>>       - receives the resource access request from the User or acts
>>>> autonomously,
>>>>       - interacts with the RS to discover authorization requirements,
>>>>       - interacts with the GS to obtain Access Tokens,
>>>>       - interacts with the RS to access the Resource using Access
>>>> Tokens.
>>>>
>>>
>>> The Client also transfers the user experience to the GS in some flows.
>>>
>> Yes but this is just a mechanism. Not an act.
>>
>>>
>>> Where do Claims fit into the cycle above?
>>>
>> A claim is just an Assertion (attribute, property) related to the RO.
>> This can be part of the authorization requirements. e.g. User/Client/RS =
are
>> requesting to know the e-mail of the RO.
>>
>
> I still view Claims are about the User. The RO is who controls a Resource=
,
> since it is the *Resource* Owner.
>
See [Txauth] Claims [was: - Dictionary]

> =E1=90=A7
>


--=20
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--000000000000bba64c05ab3b211c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Dick,

On Fri, Jul 24, 2020 at 1:17 P=
M Dick Hardt <dick.hardt@gmail.c=
om> wrote:
Hi Francis

It appear=
s we have two areas to provide additional clarity:

1) In OIDC, the UserInfo endpoint is NOT part of the OP. It is a Protected=
 Resource. Per=C2=A0https://openid.net/specs/openid-co=
nnect-core-1_0.html#Terminology

UserInfo Endpoint=

Protected Resource that, when presented with an Access Token by =
the Client, returns authorized information about the End-User represented b=
y the corresponding Authorization Grant. The UserInfo Endpoint URL MUST use=
 the https scheme and MAY contain port, path, and query parameter component=
s.

Therefore a RS is providing Claims=
 in OIDC. (RS is the same as a Protected Resource)

UserInfo Endpoint
P=
rotected Resource that, when presented with an Access Token by the Client, =
returns authorized information about the End-User represented by the corres=
ponding Authorization Grant. The UserInfo Endpoint URL MUST use the<=
span style=3D"color:rgb(0,0,0);font-family:verdana,charcoal,helvetica,arial=
,sans-serif">=C2=A0https=C2=A0scheme and MAY contain port, path, and query parameter compo=
nents.=C2=A0

This definition transported to=
 GNAP will lead to confusion. The term user in OIDC refers to both the User=
 and the RO. Correct mapping to GNAP will lead to the RoInfo Endpoint...

See=C2=A0[Txauth] Claims [was: - Dictionary]

2) The RO may be the User, or it may be some o=
ther entity. For example, the Client may want access to a Resource owned/co=
ntrolled by an enterprise. The RO is not the User, and there may not be a U=
ser using the Client.=C2=A0

See the=C2=A0Independe=
nt RO Authorization sequence as an example:
Note there is no User in this sequence

<=
/div>

more detailed comments inserted ...
Have an illustration in the thread on Claims. User in =
oAuth and OIDC plays both roles of User (as requestor of a resource) and Us=
er (as owner of a resource)=C2=A0


On Fri, Jul =
24, 2020 at 5:15 AM Francis Pouatcha <fpo@adorsys.de> wrote:


On T=
hu, Jul 23, 2020 at 10:44 PM Dick Hardt <dick.hardt@gmail.com> wrote:


On Thu, Jul 23, 2020 at 7:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick, my feedback inline

@Fabia=
n : i am not yet consistent with using the notation you referred=C2=A0to in=
=C2=A0https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-=
5:v1:en. Still to come.

On Thu, Jul 23, 2020 at 7:52 PM Dick Hardt <<=
a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gmail.c=
om> wrote:
Hi Francis

Thanks again for putting=
=C2=A0this together. I have taken your definitions and adjusted them to mat=
ch how I think of them. I dropped the term "parties" because I di=
d not think it added value. I am explicit about what each party is -- softw=
are, a human, or an entity. Let me know where you disagree!

<=
/div>

Resource - protected data or software functionality
=C2=A0=
 =C2=A0 =C2=A0 - controlled by a Resource Owner (RO),
=C2=A0 =C2=A0 =C2=
=A0 - protected by the Resource Server (RS)
Yes=C2=A0

Claim - a statement about the User
I would stay with RO not User. I added some clarification=C2=A0a=
fter the feedback of Justin (see below)=C2=A0


=C2=A0
=C2=A0 =C2=
=A0 =C2=A0 - may be obtained from the Grant Server (GS) by a Client
Yes.=C2=A0
=C2=A0 =C2=A0 =C2=A0 - may be a Reso=
urce the Client can access through an RS
N=
ot sure we need to refer to a Resource as a Claim.

Here is why I say a Claim may be a=C2=A0Resource.=
=C2=A0

A Claim may be obtained by a Client calling=
 an RS. This is effectively what the userinfo endpoint is in OpenID Connect=
. A Client may also update a Claim that is managed by an RS.=C2=A0
In OIDC the UserInfo endpoint is exposed by the =
OP not by an RP. Spec wording is confusing because the endpoint is referred=
 to as a protected resource. If you derive from this that the OP is a resou=
rce server (RP), you turn the OP into an RP relying on itself. This cyclic =
relationship has to be broken in GNAP for simplicity.

(I'm assuming you intended RS, not RP abov=
e)
yes. Sorry. RS....=C2=A0

See above per the UserInfo endpoint being a=
 Protected Resource, and is not the OP.
=
This endpoint is generally provided by the OP. Means the OP plays the role =
of an RS.
=C2=A0

Note-x on GS definition: having a GS protecting access to =
some Claims does not make the GS a RS.

For simplic=
ity, let us keep overlapping=C2=A0out:=C2=A0
- GS guards Claims
- RS guards Resources

I do not see a Clie=
nt updating a Claim in the scope of any of these protocols. Neither GNAP no=
r oAuth2 nor OIDC.

I agre=
e that how a Client updates a Claim is out of scope (at least in the core p=
rotocol).

=C2=A0
=C2=A0

A Cl=
aim - an assertion of t=
he truth of some properties or attributes of the RO.
=C2=
=A0 Note-1: A Claim is issued either by the GS or by another claim issuer.<=
/div>


I=
9;m viewing the Claims Issuer as an entity, not a piece of software. It is =
the entity trusted by other parties to make a Claim about the User. The GS =
and RS may issue claims on behalf of the Claims Issuer.
No. Issuer is GS. Any twiking=C2=A0of the word will diverge=
 it from oAuth2 and OIDC and increase complexity.

The Issuer is an entity. The GS is software.
=

What do we refer to with the "iss" =
in a JWT?=C2=A0
=C2=A0

This is why RS shall not issue anything,=C2=A0shall n=
ot deal with claims, .... RS guards Resources. If you start dealing with RS=
 issuing claims, you start dealing with RS exposing jwks-url so issued clai=
ms can be verified, then you fall back at having those RSes being GSes.

I'm saying a Resource *m=
ay* be a Claim, just as it is in OIDC UserInfo.
The word UserInfo in OIDC is misleading. This is the Info on User i=
n it's role as the RO. It is the RoInfo...

=C2=A0

=

=C2=A0
=C2=A0 Note-2: A Claim =
is held and guarded by the Grant Server (GS).

What is the significance of this statement? Sign=
ed claims don't exist until asked for, so they are not "held"=
 anywhere.
A Claim can exist before. GS =
might hold a Claim issued by an external "Claim Issued".

Would you provide an example?
RO Identity Card signed by another authorit=
y, given to GS by RO, guarded by GS and returned on request to Client/RS.=
=C2=A0=C2=A0
=C2=A0
=C2=A0
=C2=A0 Note-3: A Claim is released by the GS to a Client.=C2=A0

The model of a Claim being ob=
tained from an RS is a common use case.=C2=A0
I am not aware of any of them. Unless=C2=A0we are calling a GS a RS.<=
/div>

See UserInfo above. Also,=
 the APIs at Twitter, Facebook, Google etc. are RSes, that may return Claim=
s about the User.=C2=A0
These are all OP=
/AS. They don't see the user, but the RO.=C2=A0
=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">
=C2=A0 Note-4: The permission to release of a C=
laim is given by the RO.

<=
/div>
I will see what you say below on User ...
=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">


Grant - the Claims =
and/or Resource Access the User and/or RO have granted to the Client by the=
 GS
=C2=A0 =C2=A0 - requested by a Client
=C2=A0 =C2=A0 - granted by =
a GS after any required consent has been obtained from the User and/or RO
"User and/or RO" is confusing. I =
suggest we keep the term User out. Term User is even eligible for renaming.=
 I suggest staying with RO.

The User of the Client and the RO may not be the same entity. Some resou=
rces may be controlled by the RO, and others by the User. That is why User =
and/or RO. They are two different parties.
I need the example of a User that is different from the RO and that cont=
rols=C2=A0the RO's Resource.=C2=A0
<=
br>
See above.
=C2=A0

=

And if a User controls a Resource, then he does it as the "=
Owner" of that Resource(playing the role of the RO for that Resource).=


If we talk about roles and not entities, we will =
not fall into this confusion.

=

I think we are defining an entity playing a specific role.
=
=C2=A0
=C2=A0


Access Token - an artifact representing the acce=
ss a client has been granted to one or more Resources
=C2=A0 =C2=
=A0 - created by the GS
=C2=A0 =C2=A0 - presented by the Client when acc=
essing a Resource at an RS
An access token=
 might contain=C2=A0Claims.

While there may be statements about the User in the access token, it is =
not the mechanism for transmitting Claims to the Client -- and I think the =
access token SHOULD be opaque to the Client most of the time.
- Access "might" contain a claim ("mus=
t" not). Precision is essential as we can not kill this practice witho=
ut removing the concept of assertion based tokens.
- Returning th=
e information to the client does not mean the client is the consumer of the=
 information. The client might not have access to the content of an encrypt=
ed token, or even just to the embedded encrypted claim. The intended destin=
ation of the claim will consume the claim. But for the GNAP, the GS returns=
 the token to the client.

Let me restate my position. Any claim that might be in the access token is=
 out of scope of GNAP, or at least the core protocol. How the RS uses the a=
ccess token to protect access is out of scope, so the contents of the acces=
s token is out of scope.
Ok.=C2=A0
=


=C2=A0
=C2=A0

Acces=
s Token=C2=A0-=C2=A0an artifact r=
epresenting the access a client has been granted to one or more Resources
=C2=A0 Note-1: An access token is=C2=A0created by the GS
=C2=A0 Note-2:=C2=A0An access token can also contain claims

See above.=C2=A0
=C2=A0
=

=C2=A0 Note-3: An access token is=C2=A0presented by=
 the Client when accessing a Resource at an RS
=C2=A0
Resou=
rce Owner (RO) - the entity that
=C2=A0 =C2=A0 =C2=A0 - controls a Resou=
rce,
=C2=A0 =C2=A0 =C2=A0 - has delegated Resource access control to one=
 or more GSes
=C2=A0 =C2=A0 =C2=A0 - may be the User
Confused here with the word "controls" both at RO a=
nd GS. I think RO delegates Resource access management to GS but keeps cont=
rol (or decision).

agreed=
 - access management is better.
=C2=A0

Resource Owner (RO) - =
the entity that
=C2=A0 =C2=A0 =C2=A0 - controls a Resource,
=
=C2=A0 =C2=A0 =C2=A0 - relies on the services the GS to manage access to th=
at Resource,
=C2=A0 =C2=A0 =C2=A0 - relies on the services of a RS to ho=
ld a Resource and guard access to that Resource,

I don't=C2=A0think "guard" is a g=
ood verb. "protect" is often used.
=

OK.=C2=A0

If we are switch=
ing from "owns a resource" to "controls a resource", th=
en perhaps the entity should be a Resource Controller (RC)?
Great. Will remove confusion.=C2=A0

=C2=A0
=C2=A0 =C2=A0 =
=C2=A0 - controls a Claim,

Why does the RO control a claim?
b=
ecause a Claim is=C2=A0=
an assertion of the truth of some properties or attributes of the RO=
.=C2=A0

The RO may or may=
 not be a User. If the RO is not a User, who is the claim about? What does =
"control" mean?
Claim of User =
(in his role as an RO) -> RO-Attributed
Claim of User (in his =
role as a requesting party) -> Requestor Attributes.
See [=
Txauth] Claims [was: - Dictionary]

=C2=A0
=C2=A0
=

=C2=A0 =C2=A0 =C2=A0 - relies on the services the G=
S to release that Claim to a Client.

Resource Server (RS) - the s=
oftware that controls access to one or more Resources
=C2=A0 =C2=A0 =C2=
=A0 - accessed via an API by Clients presenting an access token
=C2=A0 =
=C2=A0 =C2=A0 - accepts access tokens from one or more GSes 
I suggest "guards" instead of "controls&q=
uot;. As access to a resource is controlled by the RO.=C2=A0

How about "protects access"?<=
/div>
OK for me.=C2=A0
=C2=A0

Resource Server (RS) -=C2=A0the software that guards ac=
cess to one or more Resources
=C2=A0 =C2=A0 =C2=A0 - accessed by the Client that=
=C2=A0presents an access token
=C2=A0 =C2=A0 =C2=A0 - accepts access =
tokens from one or more GSes
=C2=A0

Grant Server (GS) - the software that =
manages Grants
=C2=A0 =C2=A0 - has been delegated to manage Resource acc=
ess by the RO
=C2=A0 =C2=A0 - has been delegated to release Claims about=
 the User
=C2=A0 =C2=A0 - grants the Client access to Resources after ob=
taining the required consent from the RO
=C2=A0 =C2=A0 - provides the Cl=
ient Claims about the User after obtaining the required consent from the Us=
er
Term User is confusing here. This is wh=
y it is eligible for renaming.
- Claims are about RO=C2=A0not Use=
r
- Consent is from RO not User.

I'm confused why the Claims are about the RO and not =
the User.
Because the=C2=A0 user consume=
s the resource and the claim. I do like Justin's suggestion=C2=A0to cal=
l user the "Requesting Party"
=

The Client consumes the Resource and the Claims
The Requesting Party sounds more like the Client than the User=
.
I have a more extensive elaboration in=
 : [Txauth] Claims [was: - Dictionary]=C2=A0
=
=C2=A0

We ha=
ve introduced the term RO so that entity can be differentiated from a User,=
 and there are many use cases where there is a User. Not having a User seem=
s very confusing to me.
Then let us call=
 him a=C2=A0=C2=A0"Requesting Party"
=C2=A0
=C2=A0
Grant Server (GS) - the software that manag=
es Grants
=C2=A0 =C2=A0 - has been delegated to manage Resource access by =
the RO
=C2=A0 =C2=A0 - has been delegated to release Claims about the RO
=
=C2=A0 =C2=A0 - grants the Client access to Resources after obtaining the r=
equired consent from the RO
=C2=A0 =C2=A0 - provides the Client Claims abo=
ut the RO after obtaining the required consent from the RO
=C2=
=A0
Client - the software that wants to access Resource=
s and obtain Claims
=C2=A0 =C2=A0 - executed by a User or a non-human se=
rvice account 
=C2=A0 =C2=A0 - requests Grants from the Grant Server
=
=C2=A0 =C2=A0 - accesses Resources at an RS using access tokens
Client -=C2=A0th=
e software that wants to access Resources and obtain Claims on behalf of a=
=C2=A0User or non-human service account
=C2=
=A0 =C2=A0Note-1: in a typical interaction cycle, the client:
=C2=A0 =C2=A0 =C2=A0 - receives the resource acces=
s request from the User or acts autonomously,
=C2=A0 =C2=A0 =C2=A0 - interac=
ts with the RS to discover authorization requirements,
=C2=A0 =C2=A0 =C2=A0 =
- interacts with the GS to obtain Access Tokens,
=C2=A0 =C2=A0 =C2=A0 -=
 interacts with the RS to access the Resource using Access Tokens.

The Client also transfers =
the user experience to the GS in some flows.
=

Yes but this is just a mechanism. Not an act.=C2=A0

Where do Claims fit into the cycle above?
A claim is just an Assertion (attribute, proper=
ty) related to the RO. This can be part of the authorization requirements. =
e.g. User/Client/RS are requesting to know the e-mail=C2=A0of the RO.
=


I still view Claims are about =
the User. The RO is who controls a Resource, since it is the *Resource* Own=
er.=C2=A0
See=C2=A0[Txauth] Claims [was:=
 - Dictionary]=C2=A0


3D""=E1=90=A7




-- 
Francis Pouatcha
Co-=
Founder and Technical Lead
adorsys GmbH & Co. KG
https://=
adorsys-platform.de/solutions/


--000000000000bba64c05ab3b211c--


From nobody Sat Jul 25 18:45: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 18D363A082F for ; Sat, 25 Jul 2020 18:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.081
X-Spam-Level: 
X-Spam-Status: No, score=0.081 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 fs9ULSBrHi0E for ; Sat, 25 Jul 2020 18:45:39 -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 BB5243A082D for ; Sat, 25 Jul 2020 18:45:39 -0700 (PDT)
Received: from [192.168.1.3] (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 06Q1jbAD003767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 25 Jul 2020 21:45:38 -0400
From: Justin Richer 
Content-Type: multipart/alternative; boundary="Apple-Mail=_7E59D1E6-F704-47E3-9729-5B145EA9B8F5"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: 
Date: Sat, 25 Jul 2020 21:45:37 -0400
To: txauth@ietf.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: [Txauth] Updated XYZ Draft -09 published
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, 26 Jul 2020 01:45:42 -0000

--Apple-Mail=_7E59D1E6-F704-47E3-9729-5B145EA9B8F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi everyone,

Ahead of Monday=E2=80=99s very-first GNAP working group meeting, I=E2=80=99=
ve uploaded the new version of my input proposal to the working group, =
known as XYZ, into the Datatracker:

https://tools.ietf.org/html/draft-richer-transactional-authz-09 =


This is materially the same as what I posted to the list last week just =
after I realized I had missed the publication cutoff. I=E2=80=99ve =
expanded a couple of sections, fixed some examples and other errors, and =
cleaned up the cross-links throughout the document. The contents of the =
URL I posted previously have also been updated to match this updated =
text:

https://oauth.xyz/draft-richer-transactional-authz =


Thanks everyone, and I look forward to seeing you all virtually in a =
couple days!

 =E2=80=94 Justin=

--Apple-Mail=_7E59D1E6-F704-47E3-9729-5B145EA9B8F5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
everyone,

Ahead of =
Monday=E2=80=99s very-first GNAP working group meeting, I=E2=80=99ve =
uploaded the new version of my input proposal to the working group, =
known as XYZ, into the Datatracker:

https://tools.ietf.org/html/draft-richer-transactional-authz-09=


This is =
materially the same as what I posted to the list last week just after I =
realized I had missed the publication cutoff. I=E2=80=99ve expanded a =
couple of sections, fixed some examples and other errors, and cleaned up =
the cross-links throughout the document. The contents of the URL I =
posted previously have also been updated to match this updated =
text:

https://oauth.xyz/draft-richer-transactional-authz

Thanks everyone, and I =
look forward to seeing you all virtually in a couple days!

 =E2=80=94 =
Justin
=

--Apple-Mail=_7E59D1E6-F704-47E3-9729-5B145EA9B8F5--


From nobody Sat Jul 25 20:41: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 D6CBA3A0A41 for ; Sat, 25 Jul 2020 20:41: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, 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 (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 58yRE7R1B0jQ for ; Sat, 25 Jul 2020 20:41:24 -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 B85A53A0A31 for ; Sat, 25 Jul 2020 20:41:23 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id f18so11647432wrs.0 for ; Sat, 25 Jul 2020 20:41: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=gx96YeFxRmp49MFeFOua4rDdhL+ppjQNfnvYfiFa1AU=; b=d3nb0n1pPT/MjpDRP5zSbVQehY3JL840ej3HN6kOnpovCj5oq0s6L8dP2n7uKM8Ona Y5GSreEXCUjhj1h5HVYul2I4Cy7bBti8+yJ/35E7NU//HFWZEatNZjcSBVNZFK+yt6jk f7HDyXOuDTIPIBorbhW4vTy8uQrnoo/eN16xk=
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=gx96YeFxRmp49MFeFOua4rDdhL+ppjQNfnvYfiFa1AU=; b=ujwN5iAiYU78Qcs4nWbKfeVq6ucRY7zbrX8cZG9VVAqy7JCuG5Ca4abJNTTR6714s4 w2R9eAy7q36Dqzux2TT/c49el9TtR/z0pNLPf2AgCdVJ5Mkt3HAUQ5UWFkAesaDylMr0 wFU9C+lqBGdsM8M/s1h9MByAN9jt69HUw0ORbz5Zm2FQWjbsuVh5Dn8Au35b7wbMs1ZZ 3fK6VS7JzF/SgevtYQLVHMnc682YRoZZiub3dWoo9+/iXLMykLJ8Umj81Fzaof6Louv4 eQXbNNbrAHzeNqtXZwW5yYg4VKogWjxeidDVcU603kuSf0rWN66D4tieE5N8NHFwZkd5 kxMA==
X-Gm-Message-State: AOAM533U5ByHw+rgU1ZSpz7f/KOUMHP2099xb2yZ04RXI8pWsIEtCooU 8kRLhoN0LhBIDqd28bKv9RRB+EBOcCkSWMgVUxmkAQ==
X-Google-Smtp-Source: ABdhPJyuLIzH19YaZoBpedYkJUL/6lagg3nPv0BLXUgkgqSsuUlvTArrEbL5y3v/zDjXawCiRdjnbiGm0JE/t4VcD8Q=
X-Received: by 2002:a5d:65d2:: with SMTP id e18mr14371130wrw.70.1595734881854;  Sat, 25 Jul 2020 20:41:21 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>    <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>   
In-Reply-To: 
From: Francis Pouatcha 
Date: Sat, 25 Jul 2020 23:41:10 -0400
Message-ID: 
To: Tom Jones 
Cc: Justin Richer ,  Mike Jones ,  Fabien Imbault , Mike Varley ,  "txauth@ietf.org" , Dick Hardt 
Content-Type: multipart/alternative; boundary="000000000000c9fa1005ab4ffa6b"
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 26 Jul 2020 03:41:29 -0000

--000000000000c9fa1005ab4ffa6b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I just read through some work being done by Tom at the FIRE (Federated
Identifiers for Resilient Ecosystems) working group and it confirms my
intention of suggesting the consideration of a "Trust Framework" as a
context defining how to handle the client_id.

The procedure the GS applies to trust a client is derived from the "Trust
Framework" that governs the environment in which GS and Client are
operating.

In the European PSD2 ecosystem, National Country Authorities (a.k.a Market
Authorities or Regulators):
- delegate the production of client certificates to Trust Service Providers
(TSPs). TSPs are known certification authorities (CAs) in the corresponding
countries.
- maintain a register of Certified Third Party Providers (TPPs) at the
European Banking Association (EBA), where the validity of the TPP license
can be verified, in addition to the client certificate.

Designing an authorization framework around the PSD2 ecosystem, there is no
need to maintain any static or dynamic client_id. Each request is
associated with an SSL client certificate called QWAC (Qualified Website
Assertion Certificate).
- This certificate can be verified as the GS maintains a list of all known
TSP's CA authorized to release PSD2 client certificates.
- This certificate also contains the list of roles assigned to the TPP by
the regulator PSP_AS (bank), PSP_PI (payment initiation), PSP_AI (account
information), PSP_IC (card) sufficient for the client access control in the
PSD2 trust framework.
- This certificate contains a permanent "Competent Authority" that
uniquely identifies the NCA issuing the TPP license.
- This certificate contains a permanent "Authorization Number" that is
unique in the context of the NCA.
- so AuthorizationNumber@CompetentAuthority is globally unique in the
context of the PSD2 trust framework.

Given these facts, GS implementing PSD2 do not need to register clients.
- Each request of the client to the GS can be mTLS secured using the QWAC.
- GS can extract all information needed to perform authorization from that
certificate.

This use case does not need an extra client_id at the protocol level.

This is:
- based on the experience we are making implementing PSD2,
- based on my reading Tom's FIRE use case in the health sector on the
sharing of Patient Health Information (PHI) among health care providers,

I suggest GNAP introduces the notion of "Trust framework" that governs the
environment in which RS, GS and Client interoperate. We can then delegate
the decision on specifying the necessity and functions of a client_id to
the trust framework.


On Thu, Jul 16, 2020 at 7:58 PM Tom Jones 
wrote:

> I have been working on different level s of identifier, but from the
> mobile app perspective. That's the hardest case as you need to boot strap
> trust. I suspect that in the web site case you will need these levels.
> Transport, application, real world.
>
> If anyone wants to work on these, let me know and I'll get you the links
> in Kantara.
>
> thx ..Tom (mobile)
>
> On Thu, Jul 16, 2020, 2:47 PM Justin Richer  wrote:
>
>> For all of these, I still say we should have different levels of
>> identifier. A =E2=80=9Cclient ID=E2=80=9D should identify the client, an=
d not be used as a
>> stand-in for other things.
>>
>> Off the top of my head I think we might want to have identifiers,
>> assertions, proofs, and other trust-binding items for:
>>
>>  - Organizations
>>  - Devices
>>  - Software applications
>>  - Software instances
>>  - Software versions
>>
>> So if we=E2=80=99re going to talk about identifying these aspects, we sh=
ould
>> tackle each as its own thing and not mush it all into =E2=80=9Cclient_id=
=E2=80=9D. That
>> way, hopefully, GNAP can have a much better idea what a =E2=80=9Cclient=
=E2=80=9D is than
>> OAuth 2 currently does.
>>
>>  =E2=80=94 Justin
>>
>> On Jul 16, 2020, at 4:34 PM, Dick Hardt  wrote:
>>
>> One client identifier was a simplistic example. Org A may have numerous
>> clients, perhaps in different teams, perhaps in different services, each
>> with their own policy at Org B.
>>
>> When one of the Org A clients makes a call to the Org B AS, it needs to
>> identify itself with some identifier so that Org B knows which policy to
>> enforce. Why not the Client ID?
>>
>> I also agree with your comments that other client identification
>> situations are different, and forcing the same identification model on t=
hem
>> does not make sense, but I fail to see the value throwing out a concept
>> (client_id) that has worked well for the use cases it was designed for.
>>
>>
>> =E1=90=A7
>>
>> On Thu, Jul 16, 2020 at 1:08 PM Justin Richer  wrote:
>>
>>> I think that the cross-organizational trust model is an interesting one=
,
>>> and in fact it=E2=80=99s one of the things that=E2=80=99s pushed me awa=
y from a client_id.
>>> In the scenario that you describe, =E2=80=9Cclient_id=E2=80=9D is used =
to represent
>>> something that it was never meant to represent: the organization runnin=
g
>>> the software, not the software itself. It isn=E2=80=99t a client_id, an=
d while in
>>> OAuth 2 the client_id could be co-opted to carry that information, it=
=E2=80=99s
>>> considered bad practice to share client_ids between multiple pieces of
>>> software.
>>>
>>> I would argue that to address this use case properly, there should be
>>> another level of identifier to bridge that trust that the software can
>>> present, showing that it is a part of Organization A, and not Organizat=
ion
>>> C. This isn=E2=80=99t a client identifier, it=E2=80=99s an organization=
 identifier, and it
>>> should be separate. You might want to identify both the client instance=
 as
>>> well as the organization it=E2=80=99s a part of, for example. This is p=
art of the
>>> motivation behind putting =E2=80=9Corganizational data=E2=80=9D within =
scope for the client
>>> to send to the AS, after all.
>>>
>>> Therefore, I strongly disagree that this scenario =E2=80=9Crequires=E2=
=80=9D a client_id
>>> to be solved. In fact, I think that solving this scenario with a client=
_id
>>> is an anti-pattern that stems from OAuth 2=E2=80=99s over-reliance on c=
lient_id as
>>> a persistent identifier within the protocol, and we can and should do
>>> better with GNAP. It=E2=80=99s very similar to Mike Jones=E2=80=99s ref=
erenced federation
>>> document, where the client_id is co-opted as a means of bootstrapping
>>> client registration and discovery, or in the Solid Authentication
>>> specification which stuffs a WebID into the client_id field.
>>>
>>> With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools that we =
had to solve our
>>> problems, and come up with some very clever solutions. What I=E2=80=99m=
 trying to
>>> argue to this community is that we are in a position to create our own,
>>> better tools.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 16, 2020, at 2:00 PM, Dick Hardt  wrote:
>>>
>>> Justin,
>>>
>>> While I agree that the assumption in OAuth 2 that all Clients have a
>>> client_id is problematic, the requirement for a client_id in many use c=
ases
>>> is still there, and it does not represent a piece of software, but a
>>> relationship between parties.
>>>
>>> Organization A writes client software that calls resources managed by
>>> the AS in Organization B. The client_id represents Organization A to
>>> Organization B. Organization B does not care what software Organization=
 A
>>> is running, and there may be numerous pieces of software at Organizatio=
n A
>>> that use the same client_id. The access granted by Organization B to
>>> Organization A needs to be able to be different than the rights granted=
 to
>>> Organization C.
>>>
>>> I agree that we don't want to force all clients to have a client_id, an=
d
>>> as discussed, there are a variety of inputs for an AS to accept calls f=
rom
>>> a piece of software, and often, that will be a particular *instance* of
>>> the software, but we also don't want to force clients to all be treated=
 the
>>> same, because they are not..
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer  wrote:
>>>
>>>> Exactly =E2=80=94 when we start to look at it as managing the lifecycl=
e of a
>>>> piece of software, instead of a registration at the AS, we can start
>>>> thinking in different terms what =E2=80=9Ctrusting=E2=80=9D the client=
 means in the context
>>>> of what the client is doing. That trust could come from some kind of s=
igned
>>>> attestation about the software (like the OAuth 2 DynReg software
>>>> statement), or it could come from some externally fetchable item (like=
 a
>>>> Solid WebID, a DID, or the OIDC Federation extension), or it could com=
e
>>>> from someone sitting at a console and typing in information and gettin=
g
>>>> back an identifier. And none of these need to pretend to be a global
>>>> =E2=80=9Cclient id=E2=80=9D for it to work. The world of clients is mu=
ch more diverse than
>>>> OAuth 2 likes to admit, and we see that with trying to nail down a
>>>> =E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=80=
=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautomatic=E2=
=80=9D vs.
>>>> =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of other things.
>>>>
>>>> OAuth 2 only needs client IDs because the front channel needs a way to
>>>> pass client identifiers when the client can=E2=80=99t authenticate its=
elf directly.
>>>> We tried to get rid of this restriction with PAR and JAR together, but
>>>> there turned out to be corner cases in OAuth 2=E2=80=99s world that st=
ill needed
>>>> client_id, and implementations assumed it would be there anyway.
>>>>
>>>> In GNAP, we can avoid that problem from the beginning by looking at th=
e
>>>> model differently and understanding where we=E2=80=99re coming from, a=
nd why.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault 
>>>> wrote:
>>>>
>>>> +1 on that.
>>>>
>>>> We can then see it more as life cycle management of the client than
>>>> registration per say, and this comes with many benefits compared to th=
e
>>>> current client_id.
>>>>
>>>> Fabien
>>>>
>>>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer  wrote:
>>>>
>>>>> I not only agree with Mike Jones that =E2=80=9Cautomatic registration=
=E2=80=9D should
>>>>> be part of the process, but I would argue that that kind of model sho=
uld be
>>>>> a default mode of operation. If you have an identifier that you can s=
end to
>>>>> short-circuit that, great! But we should focus on having the capabili=
ty of
>>>>> inlining a lot of this information wherever possible. This is already=
 the
>>>>> direction that the input proposals are heading.
>>>>>
>>>>> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope fo=
r the protocol in
>>>>> general, and since both XYZ and Xauth have mechanisms that allow the =
client
>>>>> to present a key and get back an identifier that it can use in the fu=
ture
>>>>> we have something equivalent.
>>>>>
>>>>> But I think there=E2=80=99s a little more to it than that: Ultimately=
, I think
>>>>> we should question thinking in terms of =E2=80=9Cregistration=E2=80=
=9D, a model which has
>>>>> hampered the OAuth 2 model in a lot of use cases. For example, the
>>>>> federation draft Mike Jones references below hacks the =E2=80=9Cclien=
t_id=E2=80=9D
>>>>> parameter and makes it point to a document that the AS has to fetch. =
This
>>>>> construct is done for two reasons: (1) Oauth requires a =E2=80=9Cclie=
nt_id=E2=80=9D in the
>>>>> request and (2) it=E2=80=99s difficult to pass information by value t=
o the AS due
>>>>> to front-channel restrictions. Since we=E2=80=99re defining a new pro=
tocol, we
>>>>> don=E2=80=99t need to hack that functionality into a =E2=80=9Cclient =
ID=E2=80=9D or equivalent and
>>>>> instead we can pass that information directly in the protocol. If we =
don=E2=80=99t
>>>>> assume that the client *has* to have a client ID equivalent, but it *=
can*
>>>>> have one in a set of defined circumstances, then I think we are in a =
much
>>>>> better spot. This is the reasoning for XYZ=E2=80=99s model of having =
clients
>>>>> identified by the key, and that key can potentially be passed by a
>>>>> reference identifier.
>>>>>
>>>>> I think all of the use cases that Mike Varley presents below are all
>>>>> valid directions, with the caveat that we shouldn=E2=80=99t assume a =
client should
>>>>> be presenting an ID at all steps. Mechanisms like software statements
>>>>> should be presentable apart from a client ID, as should on-device key=
s.
>>>>> We=E2=80=99re probably going to want extensions for device posture an=
d other forms
>>>>> of attestation as well.
>>>>>
>>>>> This is one of the domains that I think we can clearly surpass OAuth
>>>>> 2=E2=80=99s flexibility and capabilities if we are willing to look pa=
st OAuth 2=E2=80=99s
>>>>> assumptions of what=E2=80=99s needed inline in the protocol.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> On Jul 14, 2020, at 1:54 PM, Mike Varley 
>>>>> wrote:
>>>>>
>>>>> Is client registration in scope for the protocol?
>>>>>
>>>>> A generic way of handling clients (via ID or Handle or Key or
>>>>> whatever) is to have processing rule on the AS such as =E2=80=9Cif th=
e AS
>>>>> recognizes the client ID (and authentication of that client ID) then =
it may
>>>>> process the request on behalf of that client. If the AS does not reco=
gnize
>>>>> the client ID, it must treat this as a new client registration and ev=
aluate
>>>>> any authorization evidence the client provides before enabling the cl=
ient
>>>>> and mapping policies to that client=E2=80=9D (this means dynamic or a=
utomatic
>>>>> clients need to provide additional assertions / software statements
>>>>> whatever to register their ID.
>>>>>
>>>>> Something like this allows for very flexible systems:
>>>>> System A can be unknown to the AS but can dynamically registered each
>>>>> time with an appropriate software statement
>>>>> System B can have a fairly stable client ID at the AS, but rotate tha=
t
>>>>> ID every month through automatic registration (with an assertion it g=
ot
>>>>> from the AS during a pre-registration for example)
>>>>> System C can pre-register with the AS for a client ID because it
>>>>> doesn=E2=80=99t deal with software statements etc=E2=80=A6
>>>>> =E2=80=A6
>>>>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing c=
lient IDs because
>>>>> it will always just rely on the software statements.
>>>>>
>>>>> I think a client registration protocol that allows these scenarios
>>>>> would be very useful in GNAP, but hopefully avoiding having to define=
 what
>>>>> =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> MV
>>>>>
>>>>> *From: *Txauth  on behalf of Mike Jones <
>>>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
>>>>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>>>>> *To: *Dick Hardt , "txauth@ietf.org" <
>>>>> txauth@ietf.org>, Justin Richer 
>>>>> *Subject: *Re: [Txauth] Key handle vs client id & handle
>>>>>
>>>>> I agree that there are significant differences between statically and
>>>>> dynamically registered clients and that=E2=80=99s appropriate to be a=
ble to
>>>>> syntactically differentiate between them at runtime.  For one thing, =
the
>>>>> resource requirements at the authorization server can be very differe=
nt.
>>>>>
>>>>> We should also be thinking about how to include what the OpenID
>>>>> Connect Federation spec
>>>>> https://openid.net/specs/openid-connect-federation-1_0.html calls
>>>>> =E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client encod=
e a registration
>>>>> request reference in the client ID, so no static or dynamic registrat=
ion
>>>>> even occurs.  See
>>>>> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.se=
ction.9.1
>>>>> 
>>>>> .
>>>>>
>>>>>                                                        -- Mike
>>>>>
>>>>> *From:* Dick Hardt 
>>>>> *Sent:* Friday, July 10, 2020 1:17 PM
>>>>> *To:* txauth@ietf.org; Justin Richer ; Mike Jones <
>>>>> Michael.Jones@microsoft.com>
>>>>> *Subject:* Key handle vs client id & handle
>>>>>
>>>>> + Mike as he had interest in this topic
>>>>>
>>>>> My understanding is that an existing OAuth 2 client would use their
>>>>> current client id as their key handle, and a dynamic client (one that=
 was
>>>>> not pre-registered) would be given a key handle by the AS.
>>>>>
>>>>> There are potentially some significant differences between a
>>>>> registered client, and a dynamic client to an AS.
>>>>>
>>>>> The AS is likely to know the identity of a registered client, and hav=
e
>>>>> different policies between the two types of clients. For example, a
>>>>> registered client may have access to a 'write" scope, while a dynamic
>>>>> client does not.
>>>>>
>>>>> The AS may have 100s or 1000s of registered clients, but a dynamic
>>>>> client may have 10Ms or 100Ms of instances, which may dictate
>>>>> separate storage services. Additionally, internal to the AS, which sy=
stems
>>>>> can write to the registered client store is going to be different tha=
n the
>>>>> dynamic client store.
>>>>>
>>>>> In XYZ, subsequent calls to the AS, both registered clients and
>>>>> dynamic clients pass a key handle, so there is no easy way to differe=
ntiate
>>>>> between the two.
>>>>>
>>>>> While the AS could embed semantics in the key handle identifier to
>>>>> indicate which identifiers are pre-registered vs dynamic, there are m=
any
>>>>> cases where the AS does need to know the difference, so making the
>>>>> difference a feature of GNAP seems like a better path.
>>>>>
>>>>>
>>>>>
>>>>> This email and any attachments are for the sole use of the intended
>>>>> recipients and may be privileged, confidential or otherwise exempt fr=
om
>>>>> disclosure under law. Any distribution, printing or other use by anyo=
ne
>>>>> other than the intended recipient is prohibited. If you are not an in=
tended
>>>>> recipient, please contact the sender immediately, and permanently del=
ete
>>>>> this email and its attachments.
>>>>>
>>>>>
>>>>> --
>>>>> Txauth mailing 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/

--000000000000c9fa1005ab4ffa6b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I just read through some work being done by Tom at the FIR=
E (Federated Identifiers for Resilient Ecosystems) working=C2=A0group and i=
t confirms my intention of suggesting the consideration of a "Trust Fr=
amework" as a context defining how to handle the client_id.

The procedure the GS applies to trust a client is derived from the=
 "Trust Framework" that governs the environment in which GS and C=
lient are operating.

In the European PSD2 ecos=
ystem, National Country Authorities (a.k.a Market Authorities or Regulators=
):
- delegate the production of client certificates to Trust Serv=
ice Providers (TSPs). TSPs are known certification authorities (CAs) in the=
 corresponding countries.
- maintain a register of Certified Thir=
d Party Providers (TPPs) at the European Banking Association (EBA), where t=
he validity of the TPP license can be verified,=C2=A0in addition=C2=A0to th=
e client certificate.

Designing an authorization f=
ramework around=C2=A0the PSD2 ecosystem, there is no need to maintain any s=
tatic or dynamic client_id. Each request is associated with an SSL client c=
ertificate called QWAC (Qualified Website Assertion Certificate).=C2=A0
- This certificate can be verified as the GS maintains a list of all=
 known TSP's CA authorized to release PSD2 client certificates.
- This certificate also contains the list of roles assigned to the TPP b=
y the regulator=C2=A0PSP_AS (bank), PSP_PI (payment initiation), PSP_AI (ac=
count information), PSP_IC (card) sufficient for the client access control =
in the PSD2 trust framework.
- This certificate contains a perman=
ent "Competent Authority" that uniquely=C2=A0identifies the NCA i=
ssuing the TPP license.
- This certificate contains a permanent &=
quot;Authorization Number" that is unique in the context of the NCA.
- so=C2=A0AuthorizationNumber@CompetentAuthority is globally=C2=A0=
unique in the context of the PSD2 trust framework.

Given these facts, GS implementing PSD2 do not need to register clients.=
=C2=A0
- Each request of the client to the GS can be mTLS secured=
 using the QWAC.
- GS can extract all information needed to perfo=
rm=C2=A0authorization from that certificate.

This =
use case does not need an extra client_id at the protocol level.=C2=A0

This is:
- based on the experience we are ma=
king implementing PSD2,
- based on my reading Tom's FIRE use =
case in the health sector on the sharing of Patient Health Information (PHI=
) among health care providers,

I suggest GNAP intr=
oduces the notion of "Trust framework" that governs the environme=
nt in which RS, GS and Client interoperate. We can then delegate the decisi=
on on specifying the necessity and functions of a client_id to the trust fr=
amework.


On Thu, Jul 16, 2020 at 7:58 PM Tom Jones <=
;thomasclinganjones@gmail.c=
om> wrote:
I have been working on different level s of identifier,=
 but from the mobile app perspective. That's the hardest case as you ne=
ed to boot strap trust. I suspect that in the web site case you will need t=
hese levels. Transport, application, real world.

If anyone wants to work on these, let me know and I'=
ll get you the links in Kantara.

thx ..Tom (mobile=
)

On Thu, Jul 16, 2020, 2:47 PM Justin Richer <jricher@mit.edu> wrote:
For all of these, I still say we should have different levels of ident=
ifier. A =E2=80=9Cclient ID=E2=80=9D should identify the client, and not be=
 used as a stand-in for other things.=C2=A0

Off the top =
of my head I think we might want to have identifiers, assertions, proofs, a=
nd other trust-binding items for:

=C2=A0- Organiza=
tions
=C2=A0- Devices
=C2=A0- Software applications
=C2=A0- Software instances
=C2=A0- Software versions
=


So if we=E2=80=99re going to talk about identifying the=
se aspects, we should tackle each as its own thing and not mush it all into=
 =E2=80=9Cclient_id=E2=80=9D. That way, hopefully, GNAP can have a much bet=
ter idea what a =E2=80=9Cclient=E2=80=9D is than OAuth 2 currently does.

=C2=A0=E2=80=94 Justin

On Jul 16, 2020, at 4:34 PM, Dick Hardt <dick.hardt@gma=
il.com> wrote:

One client identifier =
was a simplistic example. Org A may have numerous clients, perhaps in diffe=
rent teams, perhaps in different services, each with their own policy at Or=
g B.

When one of the Org A clients makes a call to t=
he Org B AS, it needs to identify itself with some identifier so that Org B=
 knows which policy to enforce. Why not the Client ID?

=

I also agree with your comments that other client identification situa=
tions are different, and forcing the same identification model on them does=
 not make sense, but I fail=C2=A0to see the value throwing out a concept (c=
lient_id) that has worked well for the use cases it was designed for.=C2=A0=



3D""=E1=90=A7
On=
 Thu, Jul 16, 2020 at 1:08 PM Justin Richer <jricher@mit.edu> wrote:=

I think th=
at the cross-organizational trust model is an interesting one, and in fact =
it=E2=80=99s one of the things that=E2=80=99s pushed me away from a client_=
id. In the scenario that you describe, =E2=80=9Cclient_id=E2=80=9D is used =
to represent something that it was never meant to represent: the organizati=
on running the software, not the software itself. It isn=E2=80=99t a client=
_id, and while in OAuth 2 the client_id could be co-opted to carry that inf=
ormation, it=E2=80=99s considered bad practice to share client_ids between =
multiple pieces of software.=C2=A0

I would argue that to=
 address this use case properly, there should be another level of identifie=
r to bridge that trust that the software can present, showing that it is a =
part of Organization A, and not Organization C. This isn=E2=80=99t a client=
 identifier, it=E2=80=99s an organization identifier, and it should be sepa=
rate. You might want to identify both the client instance as well as the or=
ganization it=E2=80=99s a part of, for example. This is part of the motivat=
ion behind putting =E2=80=9Corganizational data=E2=80=9D within scope for t=
he client to send to the AS, after all.

Therefore,=
 I strongly disagree that this scenario =E2=80=9Crequires=E2=80=9D a client=
_id to be solved. In fact, I think that solving this scenario with a client=
_id is an anti-pattern that stems from OAuth 2=E2=80=99s over-reliance on c=
lient_id as a persistent identifier within the protocol, and we can and sho=
uld do better with GNAP. It=E2=80=99s very similar to Mike Jones=E2=80=99s =
referenced federation document, where the client_id is co-opted as a means =
of bootstrapping client registration and discovery, or in the Solid Authent=
ication specification which stuffs a WebID into the client_id field.
<=
div>
With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the=
 tools that we had to solve our problems, and come up with some very clever=
 solutions. What I=E2=80=99m trying to argue to this community is that we a=
re in a position to create our own, better tools.=C2=A0

=C2=A0=E2=80=94 Justin

On =
Jul 16, 2020, at 2:00 PM, Dick Hardt <dick.hardt@gmail.com> wro=
te:

Justin,=C2=A0

While I=
 agree that the assumption in OAuth 2 that all Clients have a client_id is =
problematic, the requirement for a client_id in many use cases is still the=
re, and it does not represent a piece of software, but a relationship betwe=
en parties.

Organization A writes client soft=
ware that calls resources managed by the AS in Organization B. The client_i=
d represents Organization A to Organization B. Organization B does not care=
 what software Organization A is running, and there may be numerous=C2=A0pi=
eces of software at Organization A that use the same client_id. The access =
granted by Organization B to Organization A needs to be able to be differen=
t than the rights granted to Organization C.=C2=A0

I agree that we don't want to force all clients to have a client=
_id, and as discussed, there are a variety of inputs for an AS to accept ca=
lls from a piece of software, and often, that will be a particular insta=
nce of the software, but we also don't want to force clients to all=
 be treated the same, because they are not..=C2=A0






On Thu, Jul 16, 202=
0 at 8:24 AM Justin Richer <jricher@mit.edu> wrote:
Exactly =E2=80=94 when we s=
tart to look at it as managing the lifecycle of a piece of software, instea=
d of a registration at the AS, we can start thinking in different terms wha=
t =E2=80=9Ctrusting=E2=80=9D the client means in the context of what the cl=
ient is doing. That trust could come from some kind of signed attestation a=
bout the software (like the OAuth 2 DynReg software statement), or it could=
 come from some externally fetchable item (like a Solid WebID, a DID, or th=
e OIDC Federation extension), or it could come from someone sitting at a co=
nsole and typing in information and getting back an identifier. And none of=
 these need to pretend to be a global =E2=80=9Cclient id=E2=80=9D for it to=
 work. The world of clients is much more diverse than OAuth 2 likes to admi=
t, and we see that with trying to nail down a =E2=80=9Cconfidential=E2=80=
=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=80=9Cdynamic=E2=80=9D vs. =E2=80=
=9Cstatic=E2=80=9D vs. =E2=80=9Cautomatic=E2=80=9D vs. =E2=80=9Cephemeral=
=E2=80=9D vs. =E2=80=A6 any number of other things.=C2=A0

OAuth 2 only needs client IDs because the front channel needs a way =
to pass client identifiers when the client can=E2=80=99t authenticate itsel=
f directly. We tried to get rid of this restriction with PAR and JAR togeth=
er, but there turned out to be corner cases in OAuth 2=E2=80=99s world that=
 still needed client_id, and implementations assumed it would be there anyw=
ay.=C2=A0

In GNAP, we can avoid that problem from =
the beginning by looking at the model differently and understanding where w=
e=E2=80=99re coming from, and why.

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

On Jul 16, 2020, at 3:49=
 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:
=

+1 on that.

We can then see it=
 more as life cycle management of the client than registration per say, and=
 this comes with many benefits compared to the current client_id.

Fabien

On Tue, Jul 14, 2020 at 9:32 PM Justin Richer=
 <jricher@mit.edu> wrote:
I not only agree with Mike Jones that =E2=80=9Cautoma=
tic registration=E2=80=9D should be part of the process, but I would argue =
that that kind of model should be a default mode of operation. If you have =
an identifier that you can send to short-circuit that, great! But we should=
 focus on having the capability of inlining a lot of this information where=
ver possible. This is already the direction that the input proposals are he=
ading.

So I kind-of agree that =E2=80=9Cregistration=E2=
=80=9D is in scope for the protocol in general, and since both XYZ and Xaut=
h have mechanisms that allow the client to present a key and get back an id=
entifier that it can use in the future we have something equivalent.=C2=A0<=
/div>

But I think there=E2=80=99s a little more to it th=
an that: Ultimately, I think we should question thinking in terms of =E2=80=
=9Cregistration=E2=80=9D, a model which has hampered the OAuth 2 model in a=
 lot of use cases. For example, the federation draft Mike Jones references =
below hacks the =E2=80=9Cclient_id=E2=80=9D parameter and makes it point to=
 a document that the AS has to fetch. This construct is done for two reason=
s: (1) Oauth requires a =E2=80=9Cclient_id=E2=80=9D in the request and (2) =
it=E2=80=99s difficult to pass information by value to the AS due to front-=
channel restrictions. Since we=E2=80=99re defining a new protocol, we don=
=E2=80=99t need to hack that functionality into a =E2=80=9Cclient ID=E2=80=
=9D or equivalent and instead we can pass that information directly in the =
protocol. If we don=E2=80=99t assume that the client *has* to have a client=
 ID equivalent, but it *can* have one in a set of defined circumstances, th=
en I think we are in a much better spot. This is the reasoning for XYZ=E2=
=80=99s model of having clients identified by the key, and that key can pot=
entially be passed by a reference identifier.

I th=
ink all of the use cases that Mike Varley presents below are all valid dire=
ctions, with the caveat that we shouldn=E2=80=99t assume a client should be=
 presenting an ID at all steps. Mechanisms like software statements should =
be presentable apart from a client ID, as should on-device keys. We=E2=80=
=99re probably going to want extensions for device posture and other forms =
of attestation as well.

This is one of the domains=
 that I think we can clearly surpass OAuth 2=E2=80=99s flexibility and capa=
bilities if we are willing to look past OAuth 2=E2=80=99s assumptions of wh=
at=E2=80=99s needed inline in the protocol.=C2=A0

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

On=
 Jul 14, 2020, at 1:54 PM, Mike Varley <mike.varley@securekey.com=
> wrote:

Is client regi=
stration in scope for the protocol?
=C2=
=A0
A generic way of handling clients (via ID or Hand=
le or Key or whatever) is to have processing rule on the AS such as =E2=80=
=9Cif the AS recognizes the client ID (and authentication of that client ID=
) then it may process the request on behalf of that client. If the AS does =
not recognize the client ID, it must treat this as a new client registratio=
n and evaluate any authorization evidence the client provides before enabli=
ng the client and mapping policies to that client=E2=80=9D (this means dyna=
mic or automatic clients need to provide additional assertions / software s=
tatements whatever to register their ID.
=C2=A0
Something like this allows for very flexible=
 systems:
System A can be unknown to the AS bu=
t can dynamically registered each time with an appropriate software stateme=
nt
System B can have a fairly stable client ID=
 at the AS, but rotate that ID every month through automatic registration (=
with an assertion it got from the AS during a pre-registration for example)=

System C can pre-register with the AS for a c=
lient ID because it doesn=E2=80=99t deal with software statements etc=E2=80=
=A6
=E2=80=A6
And=
 even =E2=80=98StatelessAS=E2=80=99 can operate by never storing client IDs=
 because it will always just rely on the software statements.=

=C2=A0
I think a client regist=
ration protocol that allows these scenarios would be very useful in GNAP, b=
ut hopefully avoiding having to define what =E2=80=98evidence=E2=80=99 the =
AS needs to accept for each scenario.
=
=C2=A0
Thanks,
=
=C2=A0
MV
=C2=A0<=
u>
<=
span style=3D"font-size:12pt">From:=C2=A0Txauth <txauth-bounces@ietf.org> on behalf of Mike Jones &=
lt;Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
D=
ate:=C2=A0Tuesday, July 14, 2020 at 12:18 PM
To:=C2=A0Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>, Justin Rich=
er <jricher@mit.edu=
>
Subject:=C2=A0Re: [Txauth] Key handle vs cl=
ient id & handle
=C2=A0
I agree that there are significant differences between statically and =
dynamically registered clients and that=E2=80=99s appropriate to be able to=
 syntactically differentiate between them at runtime.=C2=A0 For one thing, =
the resource requirements at the authorization server can be very different=
.
=C2=A0
We should also be thinking about how to include what the OpenID =
Connect Federation spec=C2=A0https://ope=
nid.net/specs/openid-connect-federation-1_0.html=C2=A0call=
s =E2=80=9CAutomatic Registration=E2=80=9D.=C2=A0 This lets the client enco=
de a registration request reference in the client ID, so no static or dynam=
ic registration even occurs.=C2=A0 See=C2=A0https://openid.net/specs/openid-connect-federation-1_0-12=
.html#rfc.section.9.1.
=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>
F=
rom:=C2=A0Dick Hardt <dick.hardt@gmail.com>=C2=A0Sent:=C2=A0Friday, July 10, 2020 1:17 PM
To:=
=C2=A0txa=
uth@ietf.org; Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com=
>
Subject:=C2=A0Key handle vs client id & han=
dle
=C2=A0
=

+ Mike as he had interest in this topic
<=
div>
=C2=A0
My underst=
anding is that an existing OAuth 2 client would use their current client id=
 as their key handle, and a dynamic client (one that was not pre-registered=
) would be given a key handle by the AS.
=C2=A0
There are po=
tentially some significant differences between a registered client, and a d=
ynamic client to an AS.
=C2=A0=

The AS is likely to know the =
identity of a registered client, and have different policies between the tw=
o types of clients. For example, a registered client may have access to a &=
#39;write" scope, while a dynamic client does not.
=

=C2=A0
The AS may have 100s or 1000s of registered clients, but a dynamic cli=
ent may have 10Ms or 100Ms of instances, which may dictate separate=C2=A0st=
orage services. Additionally, internal to the AS, which systems can write t=
o the registered=C2=A0client store is going to be different than the dynami=
c client=C2=A0store.
=C2=A0=

In XYZ, subsequent calls to the =
AS, both registered clients and dynamic clients pass a key handle, so there=
 is no easy way to differentiate between the two.
=

=C2=A0
Whi=
le the AS could embed semantics in the key handle identifier to indicate wh=
ich identifiers are pre-registered vs dynamic, there are many cases where t=
he AS does need to know the difference, so making=C2=A0the difference a fea=
ture of GNAP seems like a better path.
=

=C2=A0
=C2=A0
This email and any attachments are for the sole use of the intend=
ed recipients and may be privileged, confidential or otherwise exempt from =
disclosure under law. Any distribution, printing or other use by anyone oth=
er than the intended recipient is prohibited. If you are not an intended re=
cipient, please contact the sender immediately, and permanently delete this=
 email and its attachments.

-- 

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/


--000000000000c9fa1005ab4ffa6b--


From nobody Sun Jul 26 08:03: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 38C013A0F32 for ; Sun, 26 Jul 2020 08:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 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=0.116, MIME_QP_LONG_LINE=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 rdaMJOk6MMxv for ; Sun, 26 Jul 2020 08:02:58 -0700 (PDT)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 44F853A0F31 for ; Sun, 26 Jul 2020 08:02:58 -0700 (PDT)
Received: by mail-wm1-x342.google.com with SMTP id f18so3091065wmc.0 for ; Sun, 26 Jul 2020 08:02:58 -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=nRIRsf9v1J48HFJNfjpEkyW+1MjwTbzFf3EOgG5NJlE=; b=em7y6ATJhuOTpwL+R5KxMW3qyXzLc6OBeUPVRkLWf2GpWy3IixMjmizGoaiTQcepOl Q/OnHEbJxpw55Tkg+d9zPt8THJ0RIytqlaVd0xdk0DG00ka9txqOJj2w/gLkLSVwOe4r rRP7D9gfhiuWMtenJMxW5Sm7rqaKYExc6Y05dalv3rDhDw4QDf0TF1d9uC90H143otNR UMAe3zzeaCZzCNfyjiUWY4ugwh957epBoPvCQdtdyvwHDL7eQ4qMPGl6+7/pRYx3mINN Yb8jGGZS3159L1Q5kSIYo1Q76kaTXAIt038Gm/sk0vQrBjgZPpynigjcBSCs6F1NL5OY BewQ==
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=nRIRsf9v1J48HFJNfjpEkyW+1MjwTbzFf3EOgG5NJlE=; b=GtZEMaydAvFbZkX4GqlF3TxCk5nCjjEgjmJcnGaUqixoBWrsbjgiawlQ3pUzrfPpdX rKcvQAhrvHbqePVl0Uxd0PdByI6WlAIG3K5suD8/ou2QsVDlSLI+EiI5rEvnqFCHXLfW MvDMH3E6xf1QxnKTo/0VrUgV7V3E4t/CfMrLnasJjbt77kh2tYL1sRQeyapAB5E9p5JU 6tYsgecZ8qH1kmZmYurJLHYdH1xtROkgqqcE7LeLsimCKVJB19t4KpkTtMl70W80mNCh P+Whn+wMeU/QjIWwlNKWhPOU8rgBnNmQau94p940IwFRcxN+isZwbiXg4ICtjwlF6ZYJ sucA==
X-Gm-Message-State: AOAM533VvcULjypd/kpUPCH4FpM0Kf/RZNPOMFf8Q7QvBY/n4YOKsBMY FGv/JFWOpEjR7HIjwi+fgiU=
X-Google-Smtp-Source: ABdhPJyognbNGZMvBKbzOxnMdeDdUdwIZ3cTfagRQBAIuUsiOcsuHUmz/t4k77nOErXnNmoAoqUR2A==
X-Received: by 2002:a1c:f704:: with SMTP id v4mr5087876wmh.98.1595775776698; Sun, 26 Jul 2020 08:02:56 -0700 (PDT)
Received: from [10.0.0.140] (bzq-109-66-125-13.red.bezeqint.net. [109.66.125.13]) by smtp.gmail.com with ESMTPSA id b8sm8614981wrv.4.2020.07.26.08.02.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2020 08:02:55 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.39.20071300
Date: Sun, 26 Jul 2020 18:02:54 +0300
From: Yaron Sheffer 
To: Justin Richer , Francis Pouatcha 
CC: Tom Jones , Denis , , Dick Hardt 
Message-ID: <074B0DF2-EE58-424D-9D02-EEEE3427D65B@gmail.com>
Thread-Topic: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
References:         
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3678631375_1506353479"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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, 26 Jul 2020 15:03:02 -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_3678631375_1506353479
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Hi Justin,

=20

No. Unlike the use cases (which we agree should not be published as an RFC)=
, a glossary is clearly a part of the specification. So it can be parked her=
e on the mailing list until we have a WG document, and then copied over into=
 the I-D.

=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: Txauth  on behalf of Justin Richer 
Date: Thursday, July 23, 2020 at 18:07
To: Francis Pouatcha 
Cc: Tom Jones , Denis , <=
txauth@ietf.org>, Dick Hardt 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary

=20

Up-front question to the Chairs, do we have a good place to capture this ki=
nd of thing? A non-spec document like this would be a good candidate for a w=
iki page. Do we have plans to set up a GitHub repository or similar? If so w=
e could use the wiki capabilities there to at least get this stuff written d=
own. Use cases would be good to capture there as well.=20

=20

=20

=20

Francis,

=20

First, I want to thank you for putting the work in to getting some vocabula=
ry down. This is not an easy task! Some notes on specific items inline below=
.



On Jul 21, 2020, at 8:33 PM, Francis Pouatcha  wrote:

=20

Hello Dick, Justin, Tom, Denis,

=20

Below is a new version of the dictionary includings comments from different=
 threads. Change log includes:

- avoided the expression "owns a resource" in favor of the expression "cont=
rols a resource"

- included the clarification "resource access" and "claim release"

- included a clarification User vs. RO

- tried to clarify the word User-Agent

- added the definition of a Claim

=20

Terms
=3D=3D=3D=3D=3D

Party - represents a role in the GNAP protocol flow. A party can take the f=
orm of a web service, an application installed on the user device and acting=
 autonomously or the form of a natural person (resp. of an autonomous device=
) using an application to interact with other parties.

Resource - a piece of data or web service
      - controlled by a Resource Owner (RO),
      - held and guarded by a Resource Server (RS) and
      - serviced by the RS to a Client, if the Client provides a valid Auth=
orization.

Claim - a piece of data
      - controlled by a Resource Owner (RO),
      - held and guarded by the Grant Server (GS) and
      - released by the GS to a Client as part of an Authorization.

=20

The differentiation between =E2=80=9Cresource=E2=80=9D and =E2=80=9Cclaim=E2=80=9D is important sin=
ce it separates items that get tied to an access token=E2=80=99s rights (=E2=80=9Cresour=
ces=E2=80=9D) with items that come back directly to the client without going throu=
gh a separate API. The term =E2=80=9Cclaim=E2=80=9D is problematic here though because i=
t is used broadly in the community to mean, roughly, =E2=80=9Ca statement about th=
e end user=E2=80=9D. It=E2=80=99s therefore both too broad and too narrow in the wrong w=
ays: a =E2=80=9Cclaim=E2=80=9D could come back as part of an API response, like the OIDC=
 UserInfo Endpoint, and so it=E2=80=99s not a good name for this item. Even the OI=
DC =E2=80=9Cclaims=E2=80=9D query language defines several different targets for returni=
ng the =E2=80=9Cclaims=E2=80=9D about the user, and none of them match the method that G=
NAP is looking to use here. A =E2=80=9Cclaim=E2=80=9D is also generally understood in th=
e identity community to be a statement about the user, and the data coming b=
ack directly to the client might be about the user or something else, especi=
ally as we look forward to extensions of GNAP.=20

=20

I think we should focus on the separation of the delivery mechanism, but I=E2=
=80=99m not sure what good alternatives would be. Perhaps:

=20

 - =E2=80=9Caccess right=E2=80=9D for things tied to the API/token

 - =E2=80=9Cdata response=E2=80=9D for things coming back directly to the client

=20

I=E2=80=99m not particularly thrilled by these names, but I think recent list con=
versation shows that we need to get away from =E2=80=9Cclaim=E2=80=9D as it=E2=80=99s overload=
ed.




Resource Owner (RO) - the party that
      - controls a Resource,
      - relies on the services the GS to manage access to that Resource,
      - relies on the services of a RS to hold the Resource and guard acces=
s to that Resource,
      - controls a Claim,
      - relies on the services the GS to release that Claim to a Client.

Resource Server (RS) - the party that=20
      - holds a resource and guards access to that resource on behalf of th=
e RO,
      - services the Resource to the requesting Client, provided the Client=
 presents a valid Authorization.
      The RS is generally deployed as a web service.

Grant Server (GS) - the party that=20
      - manages access to a Resource on behalf of the RO,
      - holds Claims and releases them when consented by the RO.
      For each Resource access request, the GS might request the Consent of=
 the RO and produce a corresponding Authorization that is given to the reque=
sting Client.

=20

I don=E2=80=99t like the shift from =E2=80=9CAuthorization Server=E2=80=9D to =E2=80=9CGrant Server=
=E2=80=9D, and it especially doesn=E2=80=99t make sense in light of the definitions of =E2=
=80=9Cgrant=E2=80=9D and =E2=80=9Cauthorization=E2=80=9D above. I believe we should stick with =E2=80=9C=
Authorization Server=E2=80=9D if it=E2=80=99s a single role. I would also propose that w=
e have a separate term for the RO-interactive portion vs. the client-facing =
portion, as has been brought up in a few threads. Maybe these get different =
names entirely, or maybe they are =E2=80=9Caspects=E2=80=9D of the AS, I=E2=80=99m not sure.




Consent - act of an RO :
      - approving access to a Resource, means approval that a Resource he c=
ontrols can be given to the Client by the RS.
      - approving release of a Claim, means approval that a Claim he contro=
ls can be included by the GS in an Authorization to be returned to the Clien=
t.

Grant - material form of an RO Consent. In order not to interact with the R=
O on each Resource access request, the GS might store the RO Consent in the =
form of a Grant for reuse.

Authorization - externalized form of a Grant as known to the GS and the RS.
      - The GS converts a Grant into an Authorization for use in a Resource=
 access request.
      - The RS evaluates an Authorization to decide on whether or not to re=
lease the Resource to the Client.

Client - the party that provides the infrastructure used by a User to acces=
s a Resource. The client infrastructure is designed to:
      - Receive the resource access request from the User,
      - Interact with the RS to discover authorization requirements,
      - Interact with the GS to obtain an Authorization to access the Resou=
rce,
      - Interact with the RS to access the Resource on behalf of the User.

=20

I think we should be clear that what we call the =E2=80=9Cclient=E2=80=9D is a piece of=
 software operated by the user. It=E2=80=99s true that this software might have mu=
ltiple parts of its =E2=80=9Cinfrastructure=E2=80=9D but it=E2=80=99s always software.




User - the party using the infrastructure of the Client to gain access to a=
 Resource or a Claim.

=20

In UMA, we call this the =E2=80=9CRequesting Party=E2=80=9D, or RqP. We might want to c=
onsider adopting this terminology here as well.




Clarifications:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

User vs. RO :=20
      - the User is the party using the infrastructure of the Client to gai=
n access to a Resource or a Claim,
      - the RO is the party controlling access to a Resource or controlling=
 the release of a Claim.
In many use cases, User and RO will be represented by the same party (see o=
Auth2), but GNAP exposes use cases where User and RO are represented by diff=
erent parties.

User-Agent :
User and RO are parties that might be represented by a natural person or an=
 autonomous device. In those cases, User (resp. RO) might need the help of a=
n application to interact with other parties. Such an application is general=
ly referred to as the "User-Agent".

=20

The term =E2=80=9Cuser agent=E2=80=9D is often used to be equivalent to the web browser=
, and not the more general use here. I think we=E2=80=99re seeing more =E2=80=9Cagent=E2=80=9D=
 terminology for helper applications like digital wallets and AI bots, which=
 would seem to be covered under your definition here.




Feedbacks are welcome.

=20

=20

Again, thanks so much for getting this going!

=20

 =E2=80=94 Justin



Best regards,

/Francis

=20

On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha  wrote:

=20

=20

On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt  wrote:

=20

=20

On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha  wrote:

=20

On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt  wrote:

FYI: I consider the release of claims to be an "authorization" as well.=20

Great. Then it is included.=20

=20

I pivoted to using the term Grant rather than authorization so that it incl=
uded both authorizing access to a resource, and authorizing the release of a=
n identity claim.

=20

Perhaps we should not use the word "authorization"?=20

Authorization is currently used to refer to the token issued by the GSand p=
resented to the RS by the Client. I have no alternative word for now.

=20

"resource access" and "claim release"

=20

A Grant then covers both?

Yes, Great! The word Grant fits best for both. I suggest adding this clarif=
ication to that dictionary.

=20

=20

=20

IE, the user authorizes the GS to release a DOB claim to a Client.

I guess you mean the "RO" authorizes the GS to release a DOB!

=20

Yes, thanks for clarifying!

=20

/Dick


=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

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf=
o/txauth=20


--B_3678631375_1506353479
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Hi Justin,
&=
nbsp;
No. Unlike the use cases (which we agree s=
hould not be published as an RFC), a glossary is clearly a part of the speci=
fication. So it can be parked here on the mailing list until we have a WG do=
cument, and then copied over into the I-D.
=
 
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
<=
o:p> 
From: T=
xauth <txauth-bounces@ietf.org> on behalf of Justin Richer <jricher=
@mit.edu>
Date: Thursday, July 23, 2020 at 18:07
To: =
Francis Pouatcha <fpo@adorsys.de>
Cc: Tom Jones <thomascl=
inganjones@gmail.com>, Denis <denis.ietf@free.fr>, <txauth@ietf.=
org>, Dick Hardt <dick.hardt@gmail.com>
Subject: Re: [Txa=
uth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary<=
/p>
 
Up-front question to the Chairs, do we have a good place to capture =
this kind of thing? A non-spec document like this would be a good candidate =
for a wiki page. Do we have plans to set up a GitHub repository or similar? =
If so we could use the wiki capabilities there to at least get this stuff wr=
itten down. Use cases would be good to capture there as well. 
 
 
 
Francis,
 
First, I want to thank=
 you for putting the work in to getting some vocabulary down. This is not an=
 easy task! Some notes on specific items inline below.


On Jul 21, 2020, at 8:33 PM, Fr=
ancis Pouatcha <fpo@adorsys.de> wr=
ote:
 
<=
p class=3DMsoNormal>Hello =
Dick, Justin, Tom, Denis,
 
<=
/div>
Below is a new version of the dictionary includings comments =
from different threads. Change log includes:
- avoided the expression "owns a resource" in favor of the expres=
sion "controls a resource"
- inclu=
ded the clarification "resource access" and "claim relea=
se"
- included a clarification User vs. RO
- tried to clarify the word User-Agent<=
/span>
- added the definition of a Claim
 
Terms
=3D=3D=3D=3D=3D

Party - represents =
a role in the GNAP protocol flow. A party can take the form of a web service=
, an application installed on the user device and acting autonomously or the=
 form of a natural person (resp. of an autonomous device) using an applicati=
on to interact with other parties.

Resource - a piece of data or web =
service
      - controlled by a Resource Owner (RO),
&n=
bsp;     - held and guarded by a Resource Server (RS) and
 =
;     - serviced by the RS to a Client, if the Client provides a v=
alid Authorization.

Claim - a piece of data
      -=
 controlled by a Resource Owner (RO),
      - held and gua=
rded by the Grant Server (GS) and
      - released by the =
GS to a Client as part of an Authorization.
 
=

The differentiation between =E2=80=9Cresource=E2=80=9D and =E2=80=9Cclaim=E2=80=
=9D is important since it separates items that get tied to an access token=E2=80=99s=
 rights (=E2=80=9Cresources=E2=80=9D) with items that come back directly to the client w=
ithout going through a separate API. The term =E2=80=9Cclaim=E2=80=9D is problematic her=
e though because it is used broadly in the community to mean, roughly, =E2=80=9Ca =
statement about the end user=E2=80=9D. It=E2=80=99s therefore both too broad and too nar=
row in the wrong ways: a =E2=80=9Cclaim=E2=80=9D could come back as part of an API respo=
nse, like the OIDC UserInfo Endpoint, and so it=E2=80=99s not a good name for this=
 item. Even the OIDC =E2=80=9Cclaims=E2=80=9D query language defines several different t=
argets for returning the =E2=80=9Cclaims=E2=80=9D about the user, and none of them match=
 the method that GNAP is looking to use here. A =E2=80=9Cclaim=E2=80=9D is also generall=
y understood in the identity community to be a statement about the user, and=
 the data coming back directly to the client might be about the user or some=
thing else, especially as we look forward to extensions of GNAP. <=
/o:p>
 
I think we should focus on the separation of the delivery mech=
anism, but I=E2=80=99m not sure what good alternatives would be. Perhaps:
 
 - =E2=80=9Caccess right=E2=80=9D for things tied to the API/token<=
/o:p>
 - =E2=80=9Cdata response=E2=80=9D for thing=
s coming back directly to the client
 
I=E2=80=99m not particular=
ly thrilled by these names, but I think recent list conversation shows that =
we need to get away from =E2=80=9Cclaim=E2=80=9D as it=E2=80=99s overloaded.



Resource Owner (RO) - the party that=

      - controls a Resource,
      - re=
lies on the services the GS to manage access to that Resource,
  &nb=
sp;   - relies on the services of a RS to hold the Resource and guard a=
ccess to that Resource,
      - controls a Claim,
 =
;     - relies on the services the GS to release that Claim to a C=
lient.

Resource Server (RS) - the party that 
      - holds a resource and guards=
 access to that resource on behalf of the RO,
      - serv=
ices the Resource to the requesting Client, provided the Client presents a v=
alid Authorization.
      The RS is generally deployed as =
a web service.

Grant Server (GS) - the party that 
      - manages access to a Re=
source on behalf of the RO,
      - holds Claims and relea=
ses them when consented by the RO.
      For each Resource=
 access request, the GS might request the Consent of the RO and produce a co=
rresponding Authorization that is given to the requesting Client.=

 =
;
I don=E2=80=99t like the shift from =E2=80=9CAu=
thorization Server=E2=80=9D to =E2=80=9CGrant Server=E2=80=9D, and it especially doesn=E2=80=99t mak=
e sense in light of the definitions of =E2=80=9Cgrant=E2=80=9D and =E2=80=9Cauthorization=E2=80=9D a=
bove. I believe we should stick with =E2=80=9CAuthorization Server=E2=80=9D if it=E2=80=99s a =
single role. I would also propose that we have a separate term for the RO-in=
teractive portion vs. the client-facing portion, as has been brought up in a=
 few threads. Maybe these get different names entirely, or maybe they are =E2=80=
=9Caspects=E2=80=9D of the AS, I=E2=80=99m not sure.



Consent - act of an RO :
      - appro=
ving access to a Resource, means approval that a Resource he controls can be=
 given to the Client by the RS.
      - approving release =
of a Claim, means approval that a Claim he controls can be included by the G=
S in an Authorization to be returned to the Client.

Grant - material =
form of an RO Consent. In order not to interact with the RO on each Resource=
 access request, the GS might store the RO Consent in the form of a Grant fo=
r reuse.

Authorization - externalized form of a Grant as known to the=
 GS and the RS.
      - The GS converts a Grant into an Au=
thorization for use in a Resource access request.
      - =
The RS evaluates an Authorization to decide on whether or not to release the=
 Resource to the Client.

Client - the party that provides the infrast=
ructure used by a User to access a Resource. The client infrastructure is de=
signed to:
      - Receive the resource access request fro=
m the User,
      - Interact with the RS to discover autho=
rization requirements,
      - Interact with the GS to obt=
ain an Authorization to access the Resource,
      - Inter=
act with the RS to access the Resource on behalf of the User.
 
I think we should be clear that what we=
 call the =E2=80=9Cclient=E2=80=9D is a piece of software operated by the user. It=E2=80=99s t=
rue that this software might have multiple parts of its =E2=80=9Cinfrastructure=E2=80=9D=
 but it=E2=80=99s always software.


=


User - the party using the infrastruc=
ture of the Client to gain access to a Resource or a Claim.
 
In UMA, we call this the =E2=80=9CRequesting Pa=
rty=E2=80=9D, or RqP. We might want to consider adopting this terminology here as =
well.



Clarification=
s:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

User vs. RO : 
      - the User is the p=
arty using the infrastructure of the Client to gain access to a Resource or =
a Claim,
      - the RO is the party controlling access to=
 a Resource or controlling the release of a Claim.
In many use cases, Use=
r and RO will be represented by the same party (see oAuth2), but GNAP expose=
s use cases where User and RO are represented by different parties.

U=
ser-Agent :
User and RO are parties that might be represented by a natura=
l person or an autonomous device. In those cases, User (resp. RO) might need=
 the help of an application to interact with other parties. Such an applicat=
ion is generally referred to as the "User-Agent".
 
The term =E2=80=9Cuser agent=E2=80=9D is often used t=
o be equivalent to the web browser, and not the more general use here. I thi=
nk we=E2=80=99re seeing more =E2=80=9Cagent=E2=80=9D terminology for helper applications like =
digital wallets and AI bots, which would seem to be covered under your defin=
ition here.



Feedbac=
ks are welcome.
 
 
Again, thanks so much for getting this going!<=
/o:p>
 
 =E2=80=94 Justin

Best regards,
/Francis
 
On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha <fpo@adorsys.de> wrote:
 
 
On Tue, Jul 21, 2020 at 2:15 PM D=
ick Hardt <dick.har=
dt@gmail.com> wrote:
 
 
On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha <fpo@adorsys.de> wrote:
<=
div>
<=
o:p> 
On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt &=
lt;dick.hardt@gmail.co=
m> wrote:
FYI: I consider the release of claims to be an "author=
ization" as well. 
Great. =
Then it is included. 
 
I pivoted to using the term Grant rathe=
r than authorization so that it included both authorizing access to a resour=
ce, and authorizing the release of an identity claim.
<=
/div>
 
Perhaps we should not use the word &q=
uot;authorization"? 
Authorization is currently used to refer to the token issued by the G=
Sand presented to the RS by the Client. I have no alternative word for now.<=
o:p>
=

 
"resource access" and =
"claim release"
 
A Grant then covers both?
=

Yes, Great! The word Grant fits best for both. I suggest adding=
 this clarification to that dictionary.
 
 
 
IE, the user authorizes the GS to relea=
se a DOB claim to a Client.
I guess you mean the "RO" authorizes the GS to release a DOB!
<=
span style=3D'font-size:9.0pt;font-family:Helvetica'> <=
/p>
Yes, thanks for clarifying!
 <=
/o:p>
/Dick

 
<=
p class=3DMsoNormal>-- 
<=
div>
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH &=
; Co. KG

 
-- 
<=
div>
Francis Pouatcha
Co-Founder an=
d Technical Lead
adorsys GmbH & Co. KG
 
-- T=
xauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txa=
uth 


--B_3678631375_1506353479--




From nobody Sun Jul 26 18:14: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 4C3E83A15B2 for ; Sun, 26 Jul 2020 18:14:15 -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 Z8qD7roSKsLP for ; Sun, 26 Jul 2020 18:14:11 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450: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 36DE73A15B6 for ; Sun, 26 Jul 2020 18:14:11 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id v15so3542819lfg.6 for ; Sun, 26 Jul 2020 18:14: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=BhRam/+B2pv+XeqlWNNDcStSIPyPDmr5EoRo+KHqGBA=; b=jEI4uFZcvx50g9fj30E3hMZXyLoeEkP5cFQHTTiW3EXRe7TTiIqIcRTuMlOpo5WZ2L yGjWallCK61azhf7U9WZpMdoVEBr3m1scHYgNZ0HT4SC02WAQqCBZF8ogLtuMktZ/X3Q gjLCTJREQE9gLCT4HoiNjVgKqig0gjrRTcUfCyV+Pi21Srq7rwy3HGex3s52KN5YUw07 O0LlyY2/3Pn7zW+jsvaouznNy8KhcCJg2AJafqO2XtkwzWzA3ij2bzgcua7P36UqvaHm KyxnR3TaFXprXkPTk9bcWqalVSZBk2OlcD31x9gtAvoJiqK3wpjvJrFRvPolXrbjiJrT +B/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=BhRam/+B2pv+XeqlWNNDcStSIPyPDmr5EoRo+KHqGBA=; b=PlEb+sxutRpqNRbVWK8Q/JBBisNGOsL2nLWSJtP4YEjxkoq2xADhYj5d50TRSUaX2l tHRUzO+/TSp+nSBXGpBwyY0elZYU4CLY2kVR5YSY4p2/pvLSd1xhW/Q+U763QGJ4Isqn 1EVQccmwBYBvsJtSAV2aNdGcaZoxye8WIbqyopUy485R9gdoFORIRaa9h34KAwbfmeci wornpD18mdHd4nW1C5lESqrT2IzuBR0aWHr3pEgFQCmNv7J9u/cgSGZQUuc6c3z7TgQx 8IjOZ/ai6c/Br46J/wonVvJyPooe6io7syLP0JZVP6OMn4f6K1f+6F/HNs655E4Omban ijBA==
X-Gm-Message-State: AOAM531qr8nHWU1lpZjFa17bznjw1f/MR2ev0/DmWeShYs9/KYcZ4N4w VgYgG44LdAEddI3dM+ctY2D3RvzZvT0KngxeoEM=
X-Google-Smtp-Source: ABdhPJykwUtGF6PVZ4aOsEYtVttKLRK2zfyZz+ATvkSpTOhwnoOehT9zEduUXj/PhkFySPSOTsn4AgSrBhLLw+HxVb8=
X-Received: by 2002:ac2:4a9d:: with SMTP id l29mr10412534lfp.23.1595812449065;  Sun, 26 Jul 2020 18:14:09 -0700 (PDT)
MIME-Version: 1.0
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>  
In-Reply-To: 
From: Dick Hardt 
Date: Sun, 26 Jul 2020 18:13:32 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: txauth@ietf.org, Justin Richer ,  Tom Jones , Denis ,  Fabien Imbault 
Content-Type: multipart/alternative; boundary="00000000000027a19205ab620ad3"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 01:14:15 -0000

--00000000000027a19205ab620ad3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Francis

User is a well understood term in OIDC and OAuth -- and User means the same
in both.

Resource Owner is who owns the resource, and the term is introduced for
when the User is NOT the Resource Owner.

I also think that Client and Resource Server are well understood terms.

It is not clear to me why we would want to reinvent these terms. Reading
over your flows, I think it would be useful to understand the requirements
you have for your use case, otherwise I fear we will be talking past each
other.

/Dick

=E1=90=A7

On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha  wrote:

> Below my opinion on the term Claim:
>
> Starting with illustration of parties/roles:
>
> User:
> This word is misleading because of its double role in oAuth2 and OIDC (se=
e
> below). In GNAP let us have the User play only the role of a requestor.
> (from Justin reference to "Requesting Party").
>
> Client:
> This is also tightly bound to the oAuth2 and OIDC. The real purpose of
> this role is to orchestrate resource access on behalf of the "Requestor".
> Let us call this for now the "Orchestrator"
>
> Resource Owner (RO):
> This is IMO the most correct word in the entire protocol. Authorisation i=
s
> always about the owner of something granting access to a requestor. It
> really does not matter if a human interaction is involved. We will have t=
o
> forget oAuth2 and OIDC of also calling this a User.
>
> Grant Server:
> Even though the definition of the UserInfo endpoint in OIDC as a protecte=
d
> resource hazardously makes an OP an RS, we shall not repeat the same
> mistake here. We need a clear separation between roles of GS and RS witho=
ut
> overlapping.
>
> Resource Server: services resources.
>
> Unless I got it wrong, GNAP is about grant negotiation and authorization.
> This means:
>
> GNAP is about some party requesting access to some resources.
> GNAP is about the resource owner consenting access to that resource.
> GNAP is about defining the infrastructure that allows the requesting part=
y
> to access a resource.
>
> GNAP designs this infrastructure around:
> - an orchestrator (what we refer to as a client)
> - an grant manager (what we refer to as a GS/AS)
> - the custodian of the resource (what we call a RS)
>
> As you see:
> - The word User does not appear here, and is not relevant as the focus is
> on authorizing access to a resource.
> - The word Claim is as well absent.
>
> Claim related to RO:
> The word Claim might start getting visible if the orchestrator (a.k.a.
> Client) or the custodian (a.k.a RS) needs some additional information on
> the RO to proceed with the access control decision. These claims refer to
> assertions of attributes or properties of the RO. These claims are issued
> by the GS as the GS manages interaction with the RO (see below). In this
> first place information about the requesting party (erroneously.k.a.
> User) is not relevant to the negotiation and provisioning framework. Let =
us
> call this sort of claim "RO-Attributes". A better name is welcome.
>
> Some advanced resource provisioning frameworks might require knowledge on
> attributes of the requesting party (e.k.a User). These attributes shall b=
e
> collected by the orchestrator (a.k.a Client) and added to the resource
> request. There is no way the GS can collect these attributes as the GS ro=
le
> has no interaction with the requesting party (e.k.a User). Let us call th=
is
> sort of claim "Requestor-Attributes". A better name will be welcome.
>
> Some assertions are even related to the orchestrator (a.k.a Client)
> itself. This is the case of the public key of an orchestrator used by the
> GS to "sender constrain" an access token. Let us call this type of claim
> "Orchestrator-Attributes".
>
> This is a sample mapping of OIDC.
>
> +----+    +---+   +---+  +---+
> |User|    |RP |   |OP |  |RS |
> +----+    +---+   +-+-+  +---+
>   |(1) ServiceRequest      |
>   |-------->|       |      |
>   |(2) redirect     |      |
>   |<--------|       |      |
> =3D=3D=3D User (requestor) passes control to User (RO) =3D=3D=3D
>   |(3) Auth + Consent      |
>   |---------------->|      |
>   |(4) redirect (code)     |
>   |<----------------|      |
> =3D=3D=3D User (RO) passes control back to User (requestor) =3D=3D=3D
>   |(5) get(code)    |      |
>   |-------->|       |      |
>   |         |(6) token (code)
>   |         |------>|      |
>   |         |(7) token     |
>   |         |<------|      |
>   |         |(8) ServiceRequest(token)
>   |         |------------->|
>   |         |(9) ServiceResponse
>   |         |<-------------|
>   |(10) ServiceResponse    |
>   |<--------|       |      |
>   +         +       +      +
>
> - RP orchestrates interaction between User and OP to enable the user to
> obtain the protected resource.
> - In step 1 & 10 User plays the role of the requestor of the resource.
> - In step 2 User-Browser is used to pass control from User (in his role a=
s
> the requestor) to User (in his role as the RO)
> - In step 4 User-Browser is used to pass control from User (in his role a=
s
> the RO) back to User (in his role as the requestor)
>
> When we are talking claims here, we are talking claims on the User (in hi=
s
> role as the RO). The OP does not have any interaction with the User (in h=
is
> role as the requestor). In the case of an App2App redirection, the OP can
> not even assert about the user agent of the User (requestor).
>
> If there is any claim the OP can provide, it is a claim on the User (RO).
>
> I hope this example clarifies the misunderstanding. Any attempt of
> bringing this double role of the User into GNAP will also bring this
> confusion. In order to keep this out of GNAP let us look for the right te=
rm
> for User (as a requestor) using the diagram displayed below.
>
> +----+  +------+  +---+  +---+  +---+
> |Reqs|  |Orchst|  |RS |  |GS |  |RO |
> +----+  +------+  +---+  +-+-+  +-+-+
>   |(1) ServiceRequest      |      |
>   |-------->|       |      |      |
>   |         |(2) ServiceIntent:AuthZChallenge
>   |         |<----->|      |      |
>   |         |       |      |      |
>   |         |(3) AuthZRequest(AuthZChallenge)
>   |         |------------->|      |
>   |         |       |      |(4) ConsentRequest:Grant
>   |         |       |      |<---->|
>   |         |(5) GrantAccess(AuthZ)
>   |         |<-------------|      |
>   |         |       |      |      |
>   |         |(6) ServiceRequest(AuthZ):ServiceResponse
>   |         |<----->|      |      |
>   |(7) ServiceResponse     |      |
>   |<--------|       |      |      |
>   +         +       +      +      +
>
> - Replacing the word User helps clarify the difference between both roles
> "Requestor" and "Resource Owner"
> - Renaming claim by attaching the Object/target of the claim (e.g.:
> RO-attributes, Requestor-Attributes, Orchestrator-Attributes) also helps
> identify the source of those attributes (GS, RS, Client):
>
> Best regards.
> /Francis
>
> On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt  wrote:
>
>> It is not clear to me what it matters if a Claim comes from an RS, or
>> from the GS, so I don't see a need to differentiate them.
>>
>> I would include verifiable credentials and user-bound keys as Claims.
>>
>> All the payment processing information I have seen has been in RAR. When
>> would the Client get payment processing directly from the GS?
>>
>> What is your example for distributed networks storage locations? If what
>> is stored is a statement about the user, then I would consider that a Cl=
aim
>> as well.
>>
>> We disagree on how to map OIDC to GNAP.  The direct data is a claims
>> request, the data coming indirectly is an access token request.
>>
>>
>>
>> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer  wrote:
>>
>>> Since we=E2=80=99re already talking about returning claims as direct da=
ta as
>>> well as a part of the resource API being protected, so we already need =
a
>>> way to differentiate the two kinds of items. Just calling it =E2=80=9Cc=
laims=E2=80=9D
>>> doesn=E2=80=99t help, because as you=E2=80=99ve pointed out they could =
show up in both
>>> places. So yes, defining that difference is something we should worry a=
bout
>>> now, even if the core protocol only uses it for claims.
>>>
>>> The two forms of direct data that XYZ returns are subject identifiers (=
a
>>> subset of identity claims) and assertions =E2=80=94 the latter being a =
container
>>> not just for identity claims but also authentication information and ot=
her
>>> elements. Assertions are not claims themselves.
>>>
>>> Other use cases that have been brought up include verifiable credential=
s
>>> and proofs, user-bound keys, payment processing information, and
>>> distributed network storage locations. I=E2=80=99m sure there are a lot=
 more. To
>>> me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D but not subs=
ets of =E2=80=9Cclaims=E2=80=9D.
>>> GNAP shouldn=E2=80=99t be defining what all of these look like, but it =
should
>>> define a way to talk about them.
>>>
>>> I think different top-level request objects are better suited for
>>> different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=
=E2=80=9D request,
>>> which allows targeting of its claims information into different return
>>> buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D request at =
the very least. I
>>> don=E2=80=99t think GNAP should define how to do this specific combinat=
ion, that
>>> should be for OIDF to debate and apply. The same with a DID service bas=
ed
>>> query, or Presentation Exchange [1], or anything else that people want =
to
>>> come up with.
>>>
>>> In my view, GNAP should define query structures for two things: rights
>>> that get tied to an access token and data that comes back directly to t=
he
>>> client. For the latter, I think we can do some very limited and very us=
eful
>>> specific items, which is what I=E2=80=99ve put into XYZ.
>>>
>>>  =E2=80=94 Justin
>>>
>>> [1] https://identity.foundation/presentation-exchange/
>>>
>>> On Jul 24, 2020, at 3:58 PM, Dick Hardt  wrote:
>>>
>>> I agree we want GNAP to be a strong foundation.
>>>
>>> Do you have an example of other "direct data"? If so, do you expect it
>>> to be defined in the core protocol?
>>>
>>> I would expect an extension for other "direct data" to define top level
>>> objects, and an appropriate definition for that "direct data".
>>>
>>> My "do we need to worry about it now" comment was on creating a generic
>>> term for "direct data". Unless we are solving those now, we can let fur=
ther
>>> work define that "direct data" explicitly.
>>>
>>>
>>>
>>>
>>> =E1=90=A7
>>>
>>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer  wrote:
>>>
>>>> Yes, I do think we need to worry about it to the extent that we are no=
t
>>>> creating something that is over-fit to a limited set of use cases.
>>>>
>>>> GNAP should be a foundation that many amazing new things can be built
>>>> on top of.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt  wrote:
>>>>
>>>> Justin, thanks for clarifying.
>>>>
>>>> What are some examples of other "direct data" that the GS may return?
>>>> If it is not in core GNAP, do we need to worry about now? We can then =
give
>>>> the direct data from the GS that is not a claim, an appropriate name i=
n
>>>> that document.
>>>>
>>>>
>>>>
>>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer  wrote=
:
>>>>
>>>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m sa=
ying. I agree
>>>>> that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. B=
ut the AS could return
>>>>> other data directly to the client that isn=E2=80=99t about the user. =
Those aren=E2=80=99t
>>>>> =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=
=80=9Cclaims=E2=80=9D can come back
>>>>> from places other than directly, then we shouldn=E2=80=99t call every=
thing that
>>>>> comes back a =E2=80=9Cclaim=E2=80=9D.
>>>>>
>>>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean wha=
t it already means and
>>>>> come up with a new word to mean =E2=80=9Cthings that come back direct=
ly from the
>>>>> AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s =
more complete definitions, but
>>>>> to simplify:
>>>>>
>>>>> Claims:
>>>>> - information about the user
>>>>> - can come back directly from the AS
>>>>> - can come back in a resource from the RS
>>>>>
>>>>> Resource:
>>>>> - Returned from an RS
>>>>> - Protected by access token
>>>>> - Could contain claims about the user
>>>>>
>>>>> Direct data (or some better name):
>>>>> - Returned directly from AS
>>>>> - Could contain claims about the user
>>>>>
>>>>> I think the problem is that some people are using =E2=80=9Cclaims=E2=
=80=9D to mean #1
>>>>> and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=
=99s important to
>>>>> remember, when talking about OIDC, that an IdP in OIDC combines an AS=
 and
>>>>> an RS into one entity for identity information. There can be other RS=
=E2=80=99s as
>>>>> well, and there usually are in the wild, but the one defined by OIDC =
is the
>>>>> UserInfo Endpoint. The fact that it returns user data doesn=E2=80=99t=
 make it any
>>>>> less of an RS.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> * In the wider context of things like the information claims inside a
>>>>> JWT, the claims could be about literally anything, but that=E2=80=99s=
 not what
>>>>> we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s b=
eing used.
>>>>>
>>>>>
>>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt  wrote:
>>>>>
>>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from
>>>>> the OP in an ID Token, or the Client can obtain Claims using an acces=
s
>>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>>
>>>>> The Claims are about the User (not a RO).
>>>>>
>>>>> In XAuth, I'm proposing the Client may obtain bare claims from the GS
>>>>> directly in addition to the mechanisms in ODIC.
>>>>>
>>>>> So I don't think we are changing the definition of Claim from how it
>>>>> has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>>
>>>>> Justin: you allude to Claims being about a party other than the User.
>>>>> Would you provide an example?
>>>>>
>>>>> /Dick
>>>>>
>>>>> [1]
>>>>>
>>>>> UserInfo Endpoint
>>>>> Protected Resource that, when presented with an Access Token by the
>>>>> Client, returns authorized information about the End-User represented=
 by
>>>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST=
 use
>>>>> the https scheme and MAY contain port, path, and query parameter comp=
onents.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> =E1=90=A7
>>>>>
>>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote=
:
>>>>>
>>>>>> I want to focus on one aspect here:
>>>>>>
>>>>>>
>>>>>>> A Claim is a well understood term in the field. We should use it. I=
t
>>>>>>> is still a Claim if it comes directly from the GS or from an RS.
>>>>>>>
>>>>>> I do not understand why a Resource release by an RS shall be h to as
>>>>>> a claim, even if the content of the Resource is an assertion. It wil=
l lead
>>>>>> to confusion. If we limit claims to information GS releases into Tok=
en,
>>>>>> User Info, and other objects it returns, this will help separate
>>>>>> responsibilities between GS and RS. As soon as RS services and infor=
mation,
>>>>>> this is called a Resource, no matter the nature of the content of th=
at
>>>>>> information.
>>>>>>
>>>>>>
>>>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Ccla=
im=E2=80=9D in the way
>>>>>> that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could co=
me back through an RS =E2=80=94 but in
>>>>>> the context of GNAP, that makes it a resource. So we need a differen=
t word
>>>>>> for data coming back directly from the AS to the client. Sometimes i=
t=E2=80=99s
>>>>>> going to be about the user, and that=E2=80=99s what we=E2=80=99re go=
ing to focus on here,
>>>>>> but since you can also get information about the user from a resourc=
e we
>>>>>> can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this h=
as been at the heart of a lot
>>>>>> of confusion in recent threads, as well as confusion about the scope=
 of the
>>>>>> inclusion of identity in the GNAP protocol.
>>>>>>
>>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already do=
es, and let=E2=80=99s find a way
>>>>>> to differentiate between when an item, claim or otherwise,  comes as=
 part
>>>>>> of a resource and when it comes back directly. This is an important
>>>>>> differentiating feature for GNAP.
>>>>>>
>>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in love=
 with:
>>>>>>
>>>>>>  - direct data
>>>>>>  - properties
>>>>>>  - details
>>>>>>  - statements
>>>>>>
>>>>>> The important thing here is that it=E2=80=99s not necessarily :about=
: the RO,
>>>>>> and that it is :not: in a resource.
>>>>>>
>>>>>> Any other thoughts?
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>

--00000000000027a19205ab620ad3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Francis

User is a well understood te=
rm in OIDC and OAuth -- and User means the same in both.

Resource Owner is who owns the resource, and the term is introduced =
for when the User is NOT the Resource Owner.=C2=A0

I also think that Client and Resource Server are well understood terms.

It is not clear to me why we would want to reinvent =
these terms. Reading over your flows, I think it would be useful=C2=A0to un=
derstand the requirements you have for your use case, otherwise I fear we w=
ill be talking past each other.

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

On Fri, Jul 24, 2020 at 7:21 PM Fra=
ncis Pouatcha <fpo@adorsys.de> =
wrote:
Below my opinion=C2=A0on the term Claim:<=
/font>

Starting with illustration of parties/roles:

User:=C2=
=A0
This word is misleading becau=
se of its double role in oAuth2 and OIDC (see below). In GNAP let us have t=
he User play only the role of a requestor. (from Justin reference to "=
Requesting Party").

Client:
This is also tightly=C2=A0bound to the oAuth2 and OIDC. The =
real purpose of this role is to orchestrate resource access on behalf of th=
e "Requestor". Let us call this for now the "Orchestrator&qu=
ot;

Resource Owner (RO):
This is IMO the most correct word in the entire protocol. Authorisati=
on is always about the owner of something granting access to a requestor. I=
t really=C2=A0does not matter if a human interaction is involved. We will h=
ave to forget oAuth2 and OIDC of also calling this a User.

Gr=
ant Server:=C2=A0
Even though the=
 definition of the UserInfo endpoint in OIDC as a protected resource hazard=
ously makes an OP an RS, we shall not repeat the same mistake here. We need=
 a clear separation between roles of GS and RS without overlapping.<=
/div>

Resource Server: services resources.

Unless I got=C2=
=A0it wrong, GNAP is about grant negotiation and authorization. This means:=


GNAP is about some party requesting access to som=
e resources.
GNAP is about the re=
source owner consenting access to that resource.
GNAP is about defining the infrastructure that allows the r=
equesting party to access a resource.=C2=A0

GNAP designs this=
 infrastructure around:
- an orch=
estrator (what we refer to as a client)
- an grant manager (what we refer to as a GS/AS)
- the custodian of the resource (what we call a RS)<=
/font>

As you see:
- The =
word User does not appear here, and is not relevant as the focus=C2=A0is on=
 authorizing access to a resource.
- The word Claim is as well absent.

Claim related to RO:
The word Claim might start getting =
visible if the orchestrator (a.k.a. Client) or the custodian (a.k.a RS) nee=
ds some additional information on the RO to proceed with the access control=
 decision. These claims refer to assertions of attributes or properties of =
the RO. These claims are issued by the GS as the GS manages interaction wit=
h the RO (see below). In this first place information about the requesting =
party (erroneously.k.a. User) is not releva=
nt to the negotiation and provisioning framework. Let us call this sort of =
claim "RO-Attributes". A better name is welcome.

So=
me advanced resource provisioning frameworks might require knowledge on att=
ributes of the requesting party (e.k.a User). These attributes shall be col=
lected by the=C2=A0orchestrator (a.k.a Client) and added to the resource re=
quest. There is no way the GS can collect these attributes as the GS role h=
as no interaction with the requesting party (e.k.a User).=C2=A0Let us call =
this sort of claim "Requestor-Attributes". A better name will be =
welcome.

Some assertions are even related to the orchestrator=
=C2=A0(a.k.a Client) itself. This is the case of the public key of an orche=
strator=C2=A0used by the GS to "sender constrain" an access token=
. Let us call this type of claim "Orchestrator-Attributes".

This is a sample mapping of OIDC.

+----+ =C2=A0 =C2=
=A0+---+ =C2=A0 +---+ =C2=A0+---+
|User| =C2=A0 =C2=A0|RP | =C2=A0 |OP |=
 =C2=A0|RS |
+----+ =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 |(2) redirect=C2=A0 =C2=
=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |<--------| =C2=A0 =C2=A0 =
=C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=
=3D=3D=3D User (requestor) passes control to User (RO) =3D=3D=3D
=C2=A0 |(3) Auth + Consent =C2=A0 =C2=A0 =
=C2=A0|
=C2=A0 |---------------->| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |(=
4) redirect (code) =C2=A0 =C2=A0 |
=C2=A0 |<----------------| =C2=A0 =
=C2=A0 =C2=A0|
=3D=3D=3D User (RO=
) passes control back to User (requestor) =3D=3D=3D
=C2=A0 |(5) get(code=
) =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |-------->| =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) token (code)
=C2=A0 | =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) token=
 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<------| =C2=
=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(8) ServiceRequ=
est(token)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |------------->|
=
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(9) ServiceResponse
=C2=A0 | =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |<-------------|
=C2=A0 |(10) ServiceRespons=
e =C2=A0 =C2=A0|
=C2=A0 |<--------| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=
=A0 =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>
- RP orchestrates interaction bet=
ween User and OP to enable the user to obtain the protected resource.
- In step 1 & 10 User plays the ro=
le of the requestor of the resource.
- In step 2 User-Browser is used to pass control from User (in his role=
 as the requestor) to User (in his role as the RO)
- In step 4=C2=A0User-Browser is used to pass control fro=
m User (in his role as the RO) back to=C2=A0User (in his role as the reques=
tor)

When we are talking claims here, we are talking claims o=
n the User (in his role as the RO). The OP does not have any interaction wi=
th the User (in his role as the requestor). In the case of an App2App redir=
ection, the OP can not even assert about the user agent of the User (reques=
tor).

If there is any claim the OP can provide, it is a claim=
 on the User (RO).

I hope this example clarifies the misunder=
standing. Any attempt of bringing this double role of the User into GNAP wi=
ll also bring this confusion. In order to keep this out of GNAP let us look=
 for the right term for User (as a requestor) using the diagram displayed b=
elow.

+----+ =C2=A0+------+ =C2=A0+---+ =C2=A0+---+ =C2=A0+--=
-+
|Reqs| =C2=A0|Orchst| =C2=A0|RS | =C2=A0|GS | =C2=A0|RO |
+----+ =
=C2=A0+------+ =C2=A0+---+ =C2=A0+-+-+ =C2=A0+-+-+
=C2=A0 |(1) ServiceRe=
quest =C2=A0=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |-------->| =
=C2=A0 =C2=A0 =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 |(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|(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 |(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 |(6) ServiceRequest(=
AuthZ):ServiceResponse
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<-----&g=
t;| =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+

- Replacing the word User helps clarif=
y the difference between both roles "Requestor" and "Resourc=
e Owner"
- Renaming claim by=
 attaching the Object/target of the claim (e.g.: RO-attributes, Requestor-A=
ttributes, Orchestrator-Attributes) also helps identify the source of those=
 attributes (GS, RS, Client):

Best regards.=

/Francis

On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt <dick.hardt@gmail.com=
> wrote:
=

It is not clear to me what it matters if a Claim come=
s from an RS, or from the GS, so I don't see a need to differentiate th=
em.

I would include verifiable credentials and use=
r-bound keys as Claims.

All the payment processing=
 information I have=C2=A0seen has been in RAR. When would=C2=A0the Client g=
et payment processing directly from the GS?

What i=
s your example for distributed networks storage locations? If what is store=
d is a statement about the user, then I would consider that a Claim as well=
.

We disagree on how to map OIDC to GNAP.=C2=A0 Th=
e direct data is a claims request, the data coming indirectly is an access =
token request.



On Fri, Jul 24, 2020 at 1=
:39 PM Justin Richer <jricher@mit.edu> wrote:
Since we=E2=80=99re already talking about returning =
claims as direct data as well as a part of the resource API being protected=
, so we already need a way to differentiate the two kinds of items. Just ca=
lling it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, because as you=E2=
=80=99ve pointed out they could show up in both places. So yes, defining th=
at difference is something we should worry about now, even if the core prot=
ocol only uses it for claims.

The two forms of direct da=
ta that XYZ returns are subject identifiers (a subset of identity claims) a=
nd assertions =E2=80=94 the latter being a container not just for identity =
claims but also authentication information and other elements. Assertions a=
re not claims themselves.=C2=A0

Other use cases th=
at have been brought up include verifiable credentials and proofs, user-bou=
nd keys, payment processing information, and distributed network storage lo=
cations. I=E2=80=99m sure there are a lot more. To me, these are subsets of=
 the =E2=80=9Cdirect data=E2=80=9D but not subsets of =E2=80=9Cclaims=E2=80=
=9D. GNAP shouldn=E2=80=99t be defining what all of these look like, but it=
 should define a way to talk about them.

I think d=
ifferent top-level request objects are better suited for different query se=
mantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=9D request, whic=
h allows targeting of its claims information into different return buckets.=
 This overlaps with the =E2=80=9Cresources=E2=80=9D request at the very lea=
st. I don=E2=80=99t think GNAP should define how to do this specific combin=
ation, that should be for OIDF to debate and apply. The same with a DID ser=
vice based query, or Presentation Exchange [1], or anything else that peopl=
e want to come up with.

In my view, GNAP should de=
fine query structures for two things: rights that get tied to an access tok=
en and data that comes back directly to the client. For the latter, I think=
 we can do some very limited and very useful specific items, which is what =
I=E2=80=99ve put into XYZ.

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

[1]=C2=A0https://identity.foundat=
ion/presentation-exchange/

O=
n Jul 24, 2020, at 3:58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree we want GNAP to be a strong foundation.=C2=A0
Do you have an example of other "direct data"? If=
 so, do you expect it to be defined in the core protocol?

I would expect an extension for other "direct data" to de=
fine top level objects, and an appropriate definition for that "direct=
 data".

My "do we need to worry about it=
 now" comment was on creating a generic term for "direct data&quo=
t;. Unless we are solving those now, we can let further work define that &q=
uot;direct data" explicitly.


<=
br>

3D""=E1=90=A7

On Fri, Jul 24=
, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
Yes, I do think we need to worry about i=
t to the extent that we are not creating something that is over-fit to a li=
mited set of use cases.=C2=A0

GNAP should be a foundatio=
n that many amazing new things can be built on top of.

=C2=A0=E2=80=94 Justin

On Jul=
 24, 2020, at 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, thanks for clarifying.

What are som=
e examples of other "direct data" that the GS may return? If it i=
s not in core GNAP, do we need to worry about now? We can then give the dir=
ect data from the GS that is not a claim, an appropriate name in that docum=
ent.



On Fri, Jul 24, 2020 at 11:46 AM Ju=
stin Richer <jriche=
r@mit.edu> wrote:
Dick: No, I think you=E2=80=99re misunderstanding what I=E2=
=80=99m saying. I agree that =E2=80=9Cclaims=E2=80=9D are about the user, i=
n this context*. But the AS could return other data directly to the client =
that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=
=80=9D by the classical definition. Also since =E2=80=9Cclaims=E2=80=9D can=
 come back from places other than directly, then we shouldn=E2=80=99t call =
everything that comes back a =E2=80=9Cclaim=E2=80=9D.

I=
=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean what it al=
ready means and come up with a new word to mean =E2=80=9Cthings that come b=
ack directly from the AS=E2=80=9D. These aren=E2=80=99t meant to replace Fr=
ancis=E2=80=99s more complete definitions, but to simplify:

<=
/div>
Claims:
	- =
information about the user
	=
- can come back directly from the AS
	- can come back in a resource from the RS

Resource:
	<=
/span>- Returned from an RS
=
	- Protected by access token
	- Could contain claims about the user

<=
div>Direct data (or some better name):
	- Returned directly from AS
	- Could contain claims about the user
=

I think the problem is that some people are using =E2=80=9Cc=
laims=E2=80=9D to mean #1 and some to mean #3. It=E2=80=99s clearly #1 in O=
IDC. But: It=E2=80=99s important to remember, when talking about OIDC, that=
 an IdP in OIDC combines an AS and an RS into one entity for identity infor=
mation. There can be other RS=E2=80=99s as well, and there usually are in t=
he wild, but the one defined by OIDC is the UserInfo Endpoint. The fact tha=
t it returns user data doesn=E2=80=99t make it any less of an RS.

<=
/div>
=C2=A0=E2=80=94 Justin

* In the wider co=
ntext of things like the information claims inside a JWT, the claims could =
be about literally anything, but that=E2=80=99s not what we=E2=80=99re disc=
ussing here and it=E2=80=99s not how it=E2=80=99s being used.

On Jul 24, 2020, at 1:24 PM, Dick =
Hardt <dick.ha=
rdt@gmail.com> wrote:

In OpenID Conne=
ct (OIDC), the Client can obtain Claims directly from the OP in an ID Token=
, or the Client can obtain Claims using an access token to call the UserInf=
o endpoint, a Protected Resource[1].

The Claims are abou=
t the User (not a RO).

In XAuth, I'm proposing=
 the Client may obtain bare claims from the GS directly in addition to the =
mechanisms in ODIC.

So I don't think we are ch=
anging the definition of Claim from how it has been used in OIDC, and I fai=
l to see any reason to NOT use Claim.

Justin: you =
allude to Claims being about a party other than the User. Would you provide=
 an example?

/Dick

[1]
UserInfo Endpoint
Protected Resource that, when presented with=
 an Access Token by the Client, returns authorized information about the En=
d-User represented by the corresponding Authorization Grant. The UserInfo E=
ndpoint URL MUST use the https scheme and MAY contain port, path, and query=
 parameter components.



=E1=90=A7

On Fri, Jul 24, 2020 at 5:5=
8 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspect here:


A Claim is a well understood term in the field. We should use it. It=
 is still a Claim if it comes directly from the GS or from an RS.=C2=A0
I do not understand why a Resource release by an =
RS shall be h to as a claim, even if the content of the Resource is an asse=
rtion. It will lead to confusion. If we limit claims to information GS rele=
ases into Token, User Info, and other objects it returns, this will help se=
parate responsibilities between GS and RS. As soon as RS services and infor=
mation, this is called a Resource, no matter the nature of the content of t=
hat information.

This is=
 exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=E2=80=9D in=
 the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could =
come back through an RS =E2=80=94 but in the context of GNAP, that makes it=
 a resource. So we need a different word for data coming back directly from=
 the AS to the client. Sometimes it=E2=80=99s going to be about the user, a=
nd that=E2=80=99s what we=E2=80=99re going to focus on here, but since you =
can also get information about the user from a resource we can=E2=80=99t ju=
st call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the heart of=
 a lot of confusion in recent threads, as well as confusion about the scope=
 of the inclusion of identity in the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does, a=
nd let=E2=80=99s find a way to differentiate between when an item, claim or=
 otherwise,=C2=A0=C2=A0comes as part of a resource and when it comes back d=
irectly. This is an important differentiating feature for GNAP.
<=
br>
Some straw man ideas, none of which I=E2=80=99m particularly =
in love with:

=C2=A0- direct data
=C2=A0=
- properties
=C2=A0- details
=C2=A0- statements

The important thing here is that it=E2=80=99s not necessa=
rily :about: the RO, and that it is :not: in a resource.

Any other thoughts?

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











-- 
Francis Pouatcha
Co-Founder and Technical Lead=

adorsys GmbH & Co. KG



--00000000000027a19205ab620ad3--


From nobody Sun Jul 26 18:19: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 6C3CB3A15B7 for ; Sun, 26 Jul 2020 18:19: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 Cwv_nCxWO3yL for ; Sun, 26 Jul 2020 18:19:01 -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 49F773A156F for ; Sun, 26 Jul 2020 18:19:00 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id j22so2180382lfm.2 for ; Sun, 26 Jul 2020 18:19: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=wn1SecjbfTllxJuv4uJp0HOf4zC3PC4AuDloQrI10Fw=; b=eN4bYTe7RjeAfTXqOFKapDml/SMxnzKb9riaTHTIfGLhBAKrtJpCvFdYkY45y6WEs8 lp7MUCI3vjaTbEW9To9mWnQZtx3alH2uzBb68FnysMLJcEVL34lYIQRKCwvbCkIxa8Sj ONhOU/sFtNJSThxO6bjIvCVL04HAzsnCO5GrDtHSrMu4YjsGkrX6kcMY+ZEf3eTmbGCd DGNK1hCw0FKBGtB+1UX4ZOmQrHqISyS+kM8j/XOFdiS45HiHKb6kbM0XQVuX5RZwc1tH qtlpei9GXw7ix4+gJAemAbnOxTZIlWw/+0eHEPCj5R4UqoU9SCYULDwtguR88hqH8iWV DGFA==
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=wn1SecjbfTllxJuv4uJp0HOf4zC3PC4AuDloQrI10Fw=; b=o32T61+4vhq/FZgdkQgBzuJZy5VllyhAng5dPdNg12mkSdCyo4c6PdvTOlRL4Cmosi 7fMfzkbzMNxLM15syztYQH6KUaD/nOzHgd6Uqvak7yALuKwhyEeDW5cvs2NXVh5Mf76H 2p2oYO4DJ//g60G8Qk5bheD+eY3JAo6v62unnwHwW4zhfM47kGN2+lrGhbVwDdbKuwPd cH/ea4b3EdaMtq49HHtVLK1RkcAXB/TQj0n/vORoGADF+89mh49p7DhRELsETQ1dujzF HK2zdpR11sbRqz6fBj8VjxY2nNVlDw8d3mPlKmWtIIZuVQbMtI/TRIwhJxuWokM3rJxz wuDw==
X-Gm-Message-State: AOAM530fOBx9BsxPIvrMptE/Dhu1fTRhT6A/hpV3k4H8Qn4n4HlMJv9o qBdM7cQjwSm1bE8Pb4O+N6LeKTHBvpoZkU8fb8qDIjNm
X-Google-Smtp-Source: ABdhPJw9F7XZGoy8VY7/XshhK45jNhMPPkRHnSkXSkKCGPZH7UzVgysFXNZdbMC0UCN0JYh0fNQCPJwyEHu5nvh+9qg=
X-Received: by 2002:a19:8044:: with SMTP id b65mr10537307lfd.91.1595812738355;  Sun, 26 Jul 2020 18:18:58 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>    <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>    
In-Reply-To: 
From: Dick Hardt 
Date: Sun, 26 Jul 2020 18:18:22 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: Tom Jones , Justin Richer ,  Mike Jones ,  Fabien Imbault , Mike Varley ,  "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000065d7de05ab621bf1"
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 27 Jul 2020 01:19:04 -0000

--00000000000065d7de05ab621bf1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Francis

While a Trust Framework concept looks to make sense for PSD2 use cases,
there are lots of other use cases.

How would you see existing OAuth 2 and OIDC concepts fitting into a Trust
Framework concept?

/Dick

=E1=90=A7

On Sat, Jul 25, 2020 at 8:41 PM Francis Pouatcha  wrote:

> I just read through some work being done by Tom at the FIRE (Federated
> Identifiers for Resilient Ecosystems) working group and it confirms my
> intention of suggesting the consideration of a "Trust Framework" as a
> context defining how to handle the client_id.
>
> The procedure the GS applies to trust a client is derived from the "Trust
> Framework" that governs the environment in which GS and Client are
> operating.
>
> In the European PSD2 ecosystem, National Country Authorities (a.k.a Marke=
t
> Authorities or Regulators):
> - delegate the production of client certificates to Trust Service
> Providers (TSPs). TSPs are known certification authorities (CAs) in the
> corresponding countries.
> - maintain a register of Certified Third Party Providers (TPPs) at the
> European Banking Association (EBA), where the validity of the TPP license
> can be verified, in addition to the client certificate.
>
> Designing an authorization framework around the PSD2 ecosystem, there is
> no need to maintain any static or dynamic client_id. Each request is
> associated with an SSL client certificate called QWAC (Qualified Website
> Assertion Certificate).
> - This certificate can be verified as the GS maintains a list of all know=
n
> TSP's CA authorized to release PSD2 client certificates.
> - This certificate also contains the list of roles assigned to the TPP by
> the regulator PSP_AS (bank), PSP_PI (payment initiation), PSP_AI (account
> information), PSP_IC (card) sufficient for the client access control in t=
he
> PSD2 trust framework.
> - This certificate contains a permanent "Competent Authority" that
> uniquely identifies the NCA issuing the TPP license.
> - This certificate contains a permanent "Authorization Number" that is
> unique in the context of the NCA.
> - so AuthorizationNumber@CompetentAuthority is globally unique in the
> context of the PSD2 trust framework.
>
> Given these facts, GS implementing PSD2 do not need to register clients.
> - Each request of the client to the GS can be mTLS secured using the QWAC=
.
> - GS can extract all information needed to perform authorization from tha=
t
> certificate.
>
> This use case does not need an extra client_id at the protocol level.
>
> This is:
> - based on the experience we are making implementing PSD2,
> - based on my reading Tom's FIRE use case in the health sector on the
> sharing of Patient Health Information (PHI) among health care providers,
>
> I suggest GNAP introduces the notion of "Trust framework" that governs th=
e
> environment in which RS, GS and Client interoperate. We can then delegate
> the decision on specifying the necessity and functions of a client_id to
> the trust framework.
>
>
> On Thu, Jul 16, 2020 at 7:58 PM Tom Jones 
> wrote:
>
>> I have been working on different level s of identifier, but from the
>> mobile app perspective. That's the hardest case as you need to boot stra=
p
>> trust. I suspect that in the web site case you will need these levels.
>> Transport, application, real world.
>>
>> If anyone wants to work on these, let me know and I'll get you the links
>> in Kantara.
>>
>> thx ..Tom (mobile)
>>
>> On Thu, Jul 16, 2020, 2:47 PM Justin Richer  wrote:
>>
>>> For all of these, I still say we should have different levels of
>>> identifier. A =E2=80=9Cclient ID=E2=80=9D should identify the client, a=
nd not be used as a
>>> stand-in for other things.
>>>
>>> Off the top of my head I think we might want to have identifiers,
>>> assertions, proofs, and other trust-binding items for:
>>>
>>>  - Organizations
>>>  - Devices
>>>  - Software applications
>>>  - Software instances
>>>  - Software versions
>>>
>>> So if we=E2=80=99re going to talk about identifying these aspects, we s=
hould
>>> tackle each as its own thing and not mush it all into =E2=80=9Cclient_i=
d=E2=80=9D. That
>>> way, hopefully, GNAP can have a much better idea what a =E2=80=9Cclient=
=E2=80=9D is than
>>> OAuth 2 currently does.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 16, 2020, at 4:34 PM, Dick Hardt  wrote:
>>>
>>> One client identifier was a simplistic example. Org A may have numerous
>>> clients, perhaps in different teams, perhaps in different services, eac=
h
>>> with their own policy at Org B.
>>>
>>> When one of the Org A clients makes a call to the Org B AS, it needs to
>>> identify itself with some identifier so that Org B knows which policy t=
o
>>> enforce. Why not the Client ID?
>>>
>>> I also agree with your comments that other client identification
>>> situations are different, and forcing the same identification model on =
them
>>> does not make sense, but I fail to see the value throwing out a concept
>>> (client_id) that has worked well for the use cases it was designed for.
>>>
>>>
>>> =E1=90=A7
>>>
>>> On Thu, Jul 16, 2020 at 1:08 PM Justin Richer  wrote:
>>>
>>>> I think that the cross-organizational trust model is an interesting
>>>> one, and in fact it=E2=80=99s one of the things that=E2=80=99s pushed =
me away from a
>>>> client_id. In the scenario that you describe, =E2=80=9Cclient_id=E2=80=
=9D is used to
>>>> represent something that it was never meant to represent: the organiza=
tion
>>>> running the software, not the software itself. It isn=E2=80=99t a clie=
nt_id, and
>>>> while in OAuth 2 the client_id could be co-opted to carry that informa=
tion,
>>>> it=E2=80=99s considered bad practice to share client_ids between multi=
ple pieces of
>>>> software.
>>>>
>>>> I would argue that to address this use case properly, there should be
>>>> another level of identifier to bridge that trust that the software can
>>>> present, showing that it is a part of Organization A, and not Organiza=
tion
>>>> C. This isn=E2=80=99t a client identifier, it=E2=80=99s an organizatio=
n identifier, and it
>>>> should be separate. You might want to identify both the client instanc=
e as
>>>> well as the organization it=E2=80=99s a part of, for example. This is =
part of the
>>>> motivation behind putting =E2=80=9Corganizational data=E2=80=9D within=
 scope for the client
>>>> to send to the AS, after all.
>>>>
>>>> Therefore, I strongly disagree that this scenario =E2=80=9Crequires=E2=
=80=9D a
>>>> client_id to be solved. In fact, I think that solving this scenario wi=
th a
>>>> client_id is an anti-pattern that stems from OAuth 2=E2=80=99s over-re=
liance on
>>>> client_id as a persistent identifier within the protocol, and we can a=
nd
>>>> should do better with GNAP. It=E2=80=99s very similar to Mike Jones=E2=
=80=99s referenced
>>>> federation document, where the client_id is co-opted as a means of
>>>> bootstrapping client registration and discovery, or in the Solid
>>>> Authentication specification which stuffs a WebID into the client_id f=
ield.
>>>>
>>>> With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools that we=
 had to solve our
>>>> problems, and come up with some very clever solutions. What I=E2=80=99=
m trying to
>>>> argue to this community is that we are in a position to create our own=
,
>>>> better tools.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Jul 16, 2020, at 2:00 PM, Dick Hardt  wrote:
>>>>
>>>> Justin,
>>>>
>>>> While I agree that the assumption in OAuth 2 that all Clients have a
>>>> client_id is problematic, the requirement for a client_id in many use =
cases
>>>> is still there, and it does not represent a piece of software, but a
>>>> relationship between parties.
>>>>
>>>> Organization A writes client software that calls resources managed by
>>>> the AS in Organization B. The client_id represents Organization A to
>>>> Organization B. Organization B does not care what software Organizatio=
n A
>>>> is running, and there may be numerous pieces of software at Organizati=
on A
>>>> that use the same client_id. The access granted by Organization B to
>>>> Organization A needs to be able to be different than the rights grante=
d to
>>>> Organization C.
>>>>
>>>> I agree that we don't want to force all clients to have a client_id,
>>>> and as discussed, there are a variety of inputs for an AS to accept ca=
lls
>>>> from a piece of software, and often, that will be a particular
>>>> *instance* of the software, but we also don't want to force clients to
>>>> all be treated the same, because they are not..
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer  wrote:
>>>>
>>>>> Exactly =E2=80=94 when we start to look at it as managing the lifecyc=
le of a
>>>>> piece of software, instead of a registration at the AS, we can start
>>>>> thinking in different terms what =E2=80=9Ctrusting=E2=80=9D the clien=
t means in the context
>>>>> of what the client is doing. That trust could come from some kind of =
signed
>>>>> attestation about the software (like the OAuth 2 DynReg software
>>>>> statement), or it could come from some externally fetchable item (lik=
e a
>>>>> Solid WebID, a DID, or the OIDC Federation extension), or it could co=
me
>>>>> from someone sitting at a console and typing in information and getti=
ng
>>>>> back an identifier. And none of these need to pretend to be a global
>>>>> =E2=80=9Cclient id=E2=80=9D for it to work. The world of clients is m=
uch more diverse than
>>>>> OAuth 2 likes to admit, and we see that with trying to nail down a
>>>>> =E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=
=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautomatic=
=E2=80=9D vs.
>>>>> =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of other things.
>>>>>
>>>>> OAuth 2 only needs client IDs because the front channel needs a way t=
o
>>>>> pass client identifiers when the client can=E2=80=99t authenticate it=
self directly.
>>>>> We tried to get rid of this restriction with PAR and JAR together, bu=
t
>>>>> there turned out to be corner cases in OAuth 2=E2=80=99s world that s=
till needed
>>>>> client_id, and implementations assumed it would be there anyway.
>>>>>
>>>>> In GNAP, we can avoid that problem from the beginning by looking at
>>>>> the model differently and understanding where we=E2=80=99re coming fr=
om, and why.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault 
>>>>> wrote:
>>>>>
>>>>> +1 on that.
>>>>>
>>>>> We can then see it more as life cycle management of the client than
>>>>> registration per say, and this comes with many benefits compared to t=
he
>>>>> current client_id.
>>>>>
>>>>> Fabien
>>>>>
>>>>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer  wrote=
:
>>>>>
>>>>>> I not only agree with Mike Jones that =E2=80=9Cautomatic registratio=
n=E2=80=9D should
>>>>>> be part of the process, but I would argue that that kind of model sh=
ould be
>>>>>> a default mode of operation. If you have an identifier that you can =
send to
>>>>>> short-circuit that, great! But we should focus on having the capabil=
ity of
>>>>>> inlining a lot of this information wherever possible. This is alread=
y the
>>>>>> direction that the input proposals are heading.
>>>>>>
>>>>>> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope f=
or the protocol
>>>>>> in general, and since both XYZ and Xauth have mechanisms that allow =
the
>>>>>> client to present a key and get back an identifier that it can use i=
n the
>>>>>> future we have something equivalent.
>>>>>>
>>>>>> But I think there=E2=80=99s a little more to it than that: Ultimatel=
y, I
>>>>>> think we should question thinking in terms of =E2=80=9Cregistration=
=E2=80=9D, a model which
>>>>>> has hampered the OAuth 2 model in a lot of use cases. For example, t=
he
>>>>>> federation draft Mike Jones references below hacks the =E2=80=9Cclie=
nt_id=E2=80=9D
>>>>>> parameter and makes it point to a document that the AS has to fetch.=
 This
>>>>>> construct is done for two reasons: (1) Oauth requires a =E2=80=9Ccli=
ent_id=E2=80=9D in the
>>>>>> request and (2) it=E2=80=99s difficult to pass information by value =
to the AS due
>>>>>> to front-channel restrictions. Since we=E2=80=99re defining a new pr=
otocol, we
>>>>>> don=E2=80=99t need to hack that functionality into a =E2=80=9Cclient=
 ID=E2=80=9D or equivalent and
>>>>>> instead we can pass that information directly in the protocol. If we=
 don=E2=80=99t
>>>>>> assume that the client *has* to have a client ID equivalent, but it =
*can*
>>>>>> have one in a set of defined circumstances, then I think we are in a=
 much
>>>>>> better spot. This is the reasoning for XYZ=E2=80=99s model of having=
 clients
>>>>>> identified by the key, and that key can potentially be passed by a
>>>>>> reference identifier.
>>>>>>
>>>>>> I think all of the use cases that Mike Varley presents below are all
>>>>>> valid directions, with the caveat that we shouldn=E2=80=99t assume a=
 client should
>>>>>> be presenting an ID at all steps. Mechanisms like software statement=
s
>>>>>> should be presentable apart from a client ID, as should on-device ke=
ys.
>>>>>> We=E2=80=99re probably going to want extensions for device posture a=
nd other forms
>>>>>> of attestation as well.
>>>>>>
>>>>>> This is one of the domains that I think we can clearly surpass OAuth
>>>>>> 2=E2=80=99s flexibility and capabilities if we are willing to look p=
ast OAuth 2=E2=80=99s
>>>>>> assumptions of what=E2=80=99s needed inline in the protocol.
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>> On Jul 14, 2020, at 1:54 PM, Mike Varley 
>>>>>> wrote:
>>>>>>
>>>>>> Is client registration in scope for the protocol?
>>>>>>
>>>>>> A generic way of handling clients (via ID or Handle or Key or
>>>>>> whatever) is to have processing rule on the AS such as =E2=80=9Cif t=
he AS
>>>>>> recognizes the client ID (and authentication of that client ID) then=
 it may
>>>>>> process the request on behalf of that client. If the AS does not rec=
ognize
>>>>>> the client ID, it must treat this as a new client registration and e=
valuate
>>>>>> any authorization evidence the client provides before enabling the c=
lient
>>>>>> and mapping policies to that client=E2=80=9D (this means dynamic or =
automatic
>>>>>> clients need to provide additional assertions / software statements
>>>>>> whatever to register their ID.
>>>>>>
>>>>>> Something like this allows for very flexible systems:
>>>>>> System A can be unknown to the AS but can dynamically registered eac=
h
>>>>>> time with an appropriate software statement
>>>>>> System B can have a fairly stable client ID at the AS, but rotate
>>>>>> that ID every month through automatic registration (with an assertio=
n it
>>>>>> got from the AS during a pre-registration for example)
>>>>>> System C can pre-register with the AS for a client ID because it
>>>>>> doesn=E2=80=99t deal with software statements etc=E2=80=A6
>>>>>> =E2=80=A6
>>>>>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing =
client IDs
>>>>>> because it will always just rely on the software statements.
>>>>>>
>>>>>> I think a client registration protocol that allows these scenarios
>>>>>> would be very useful in GNAP, but hopefully avoiding having to defin=
e what
>>>>>> =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> MV
>>>>>>
>>>>>> *From: *Txauth  on behalf of Mike Jones <
>>>>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
>>>>>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>>>>>> *To: *Dick Hardt , "txauth@ietf.org" <
>>>>>> txauth@ietf.org>, Justin Richer 
>>>>>> *Subject: *Re: [Txauth] Key handle vs client id & handle
>>>>>>
>>>>>> I agree that there are significant differences between statically an=
d
>>>>>> dynamically registered clients and that=E2=80=99s appropriate to be =
able to
>>>>>> syntactically differentiate between them at runtime.  For one thing,=
 the
>>>>>> resource requirements at the authorization server can be very differ=
ent.
>>>>>>
>>>>>> We should also be thinking about how to include what the OpenID
>>>>>> Connect Federation spec
>>>>>> https://openid.net/specs/openid-connect-federation-1_0.html calls
>>>>>> =E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client enco=
de a registration
>>>>>> request reference in the client ID, so no static or dynamic registra=
tion
>>>>>> even occurs.  See
>>>>>> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.s=
ection.9.1
>>>>>> 
>>>>>> .
>>>>>>
>>>>>>                                                        -- Mike
>>>>>>
>>>>>> *From:* Dick Hardt 
>>>>>> *Sent:* Friday, July 10, 2020 1:17 PM
>>>>>> *To:* txauth@ietf.org; Justin Richer ; Mike Jones <
>>>>>> Michael.Jones@microsoft.com>
>>>>>> *Subject:* Key handle vs client id & handle
>>>>>>
>>>>>> + Mike as he had interest in this topic
>>>>>>
>>>>>> My understanding is that an existing OAuth 2 client would use their
>>>>>> current client id as their key handle, and a dynamic client (one tha=
t was
>>>>>> not pre-registered) would be given a key handle by the AS.
>>>>>>
>>>>>> There are potentially some significant differences between a
>>>>>> registered client, and a dynamic client to an AS.
>>>>>>
>>>>>> The AS is likely to know the identity of a registered client, and
>>>>>> have different policies between the two types of clients. For exampl=
e, a
>>>>>> registered client may have access to a 'write" scope, while a dynami=
c
>>>>>> client does not.
>>>>>>
>>>>>> The AS may have 100s or 1000s of registered clients, but a dynamic
>>>>>> client may have 10Ms or 100Ms of instances, which may dictate
>>>>>> separate storage services. Additionally, internal to the AS, which s=
ystems
>>>>>> can write to the registered client store is going to be different th=
an the
>>>>>> dynamic client store.
>>>>>>
>>>>>> In XYZ, subsequent calls to the AS, both registered clients and
>>>>>> dynamic clients pass a key handle, so there is no easy way to differ=
entiate
>>>>>> between the two.
>>>>>>
>>>>>> While the AS could embed semantics in the key handle identifier to
>>>>>> indicate which identifiers are pre-registered vs dynamic, there are =
many
>>>>>> cases where the AS does need to know the difference, so making the
>>>>>> difference a feature of GNAP seems like a better path.
>>>>>>
>>>>>>
>>>>>>
>>>>>> This email and any attachments are for the sole use of the intended
>>>>>> recipients and may be privileged, confidential or otherwise exempt f=
rom
>>>>>> disclosure under law. Any distribution, printing or other use by any=
one
>>>>>> other than the intended recipient is prohibited. If you are not an i=
ntended
>>>>>> recipient, please contact the sender immediately, and permanently de=
lete
>>>>>> this email and its attachments.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Txauth mailing 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/
>

--00000000000065d7de05ab621bf1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Francis

While a Trust Framework conc=
ept looks to make sense for PSD2 use cases, there are lots of other use cas=
es.

How would you see existing OAuth 2 and OIDC concepts=
 fitting into a Trust Framework concept?

/Di=
ck

3D""=E1=90=A7

On Sat, Jul 25, 2020=
 at 8:41 PM Francis Pouatcha <fpo@ador=
sys.de> wrote:
I just read through some work being done by Tom at t=
he FIRE (Federated Identifiers for Resilient Ecosystems) working=C2=A0group=
 and it confirms my intention of suggesting the consideration of a "Tr=
ust Framework" as a context defining how to handle the client_id.
=

The procedure the GS applies to trust a client is derived fr=
om the "Trust Framework" that governs the environment in which GS=
 and Client are operating.

In the European PSD=
2 ecosystem, National Country Authorities (a.k.a Market Authorities or Regu=
lators):
- delegate the production of client certificates to Trus=
t Service Providers (TSPs). TSPs are known certification authorities (CAs) =
in the corresponding countries.
- maintain a register of Certifie=
d Third Party Providers (TPPs) at the European Banking Association (EBA), w=
here the validity of the TPP license can be verified,=C2=A0in addition=C2=
=A0to the client certificate.

Designing an authori=
zation framework around=C2=A0the PSD2 ecosystem, there is no need to mainta=
in any static or dynamic client_id. Each request is associated with an SSL =
client certificate called QWAC (Qualified Website Assertion Certificate).=
=C2=A0
- This certificate can be verified as the GS maintains a l=
ist of all known TSP's CA authorized to release PSD2 client certificate=
s.
- This certificate also contains the list of roles assigned to=
 the TPP by the regulator=C2=A0PSP_AS (bank), PSP_PI (payment initiation), =
PSP_AI (account information), PSP_IC (card) sufficient for the client acces=
s control in the PSD2 trust framework.
- This certificate contain=
s a permanent "Competent Authority" that uniquely=C2=A0identifies=
 the NCA issuing the TPP license.
- This certificate contains a p=
ermanent "Authorization Number" that is unique in the context of =
the NCA.
- so=C2=A0AuthorizationNumber@CompetentAuthority is glob=
ally=C2=A0unique in the context of the PSD2 trust framework.

=

Given these facts, GS implementing PSD2 do not need to register =
clients.=C2=A0
- Each request of the client to the GS can be mTLS=
 secured using the QWAC.
- GS can extract all information needed =
to perform=C2=A0authorization from that certificate.

This use case does not need an extra client_id at the protocol level.=C2=
=A0

This is:
- based on the experience w=
e are making implementing PSD2,
- based on my reading Tom's F=
IRE use case in the health sector on the sharing of Patient Health Informat=
ion (PHI) among health care providers,

I suggest G=
NAP introduces the notion of "Trust framework" that governs the e=
nvironment in which RS, GS and Client interoperate. We can then delegate th=
e decision on specifying the necessity and functions of a client_id to the =
trust framework.


<=
div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 16, 2020 at 7:58 PM Tom Jo=
nes <t=
homasclinganjones@gmail.com> wrote:
I have been working on differe=
nt level s of identifier, but from the mobile app perspective. That's t=
he hardest case as you need to boot strap trust. I suspect that in the web =
site case you will need these levels. Transport, application, real world.
If anyone wants to work on thes=
e, let me know and I'll get you the links in Kantara.

thx ..Tom (mobile)

On Thu, Jul 16, 2020, 2:47 PM Justi=
n Richer <jricher@m=
it.edu> wrote:
For a=
ll of these, I still say we should have different levels of identifier. A =
=E2=80=9Cclient ID=E2=80=9D should identify the client, and not be used as =
a stand-in for other things.=C2=A0

Off the top of my hea=
d I think we might want to have identifiers, assertions, proofs, and other =
trust-binding items for:

=C2=A0- Organizations
=C2=A0- Devices
=C2=A0- Software applications
=
=C2=A0- Software instances
=C2=A0- Software versions
So if we=E2=80=99re going to talk about identifying these aspe=
cts, we should tackle each as its own thing and not mush it all into =E2=80=
=9Cclient_id=E2=80=9D. That way, hopefully, GNAP can have a much better ide=
a what a =E2=80=9Cclient=E2=80=9D is than OAuth 2 currently does.

=C2=A0=E2=80=94 Justin

On Jul 16, 2020, at 4:34 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

One client identifier was a si=
mplistic example. Org A may have numerous clients, perhaps in different tea=
ms, perhaps in different services, each with their own policy at Org B.
=


When one of the Org A clients makes a call to the Org B=
 AS, it needs to identify itself with some identifier so that Org B knows w=
hich policy to enforce. Why not the Client ID?

I a=
lso agree with your comments that other client identification situations ar=
e different, and forcing the same identification model on them does not mak=
e sense, but I fail=C2=A0to see the value throwing out a concept (client_id=
) that has worked well for the use cases it was designed for.=C2=A0


3D""=E1=90=A7

=

On Thu, Ju=
l 16, 2020 at 1:08 PM Justin Richer <jricher@mit.edu> wrote:
I think that the c=
ross-organizational trust model is an interesting one, and in fact it=E2=80=
=99s one of the things that=E2=80=99s pushed me away from a client_id. In t=
he scenario that you describe, =E2=80=9Cclient_id=E2=80=9D is used to repre=
sent something that it was never meant to represent: the organization runni=
ng the software, not the software itself. It isn=E2=80=99t a client_id, and=
 while in OAuth 2 the client_id could be co-opted to carry that information=
, it=E2=80=99s considered bad practice to share client_ids between multiple=
 pieces of software.=C2=A0

I would argue that to address=
 this use case properly, there should be another level of identifier to bri=
dge that trust that the software can present, showing that it is a part of =
Organization A, and not Organization C. This isn=E2=80=99t a client identif=
ier, it=E2=80=99s an organization identifier, and it should be separate. Yo=
u might want to identify both the client instance as well as the organizati=
on it=E2=80=99s a part of, for example. This is part of the motivation behi=
nd putting =E2=80=9Corganizational data=E2=80=9D within scope for the clien=
t to send to the AS, after all.

Therefore, I stron=
gly disagree that this scenario =E2=80=9Crequires=E2=80=9D a client_id to b=
e solved. In fact, I think that solving this scenario with a client_id is a=
n anti-pattern that stems from OAuth 2=E2=80=99s over-reliance on client_id=
 as a persistent identifier within the protocol, and we can and should do b=
etter with GNAP. It=E2=80=99s very similar to Mike Jones=E2=80=99s referenc=
ed federation document, where the client_id is co-opted as a means of boots=
trapping client registration and discovery, or in the Solid Authentication =
specification which stuffs a WebID into the client_id field.

=

With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools t=
hat we had to solve our problems, and come up with some very clever solutio=
ns. What I=E2=80=99m trying to argue to this community is that we are in a =
position to create our own, better tools.=C2=A0

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

On Jul 16=
, 2020, at 2:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
Justin,=C2=A0

While I agree=
 that the assumption in OAuth 2 that all Clients have a client_id is proble=
matic, the requirement for a client_id in many use cases is still there, an=
d it does not represent a piece of software, but a relationship between par=
ties.

Organization A writes client software t=
hat calls resources managed by the AS in Organization B. The client_id repr=
esents Organization A to Organization B. Organization B does not care what =
software Organization A is running, and there may be numerous=C2=A0pieces o=
f software at Organization A that use the same client_id. The access grante=
d by Organization B to Organization A needs to be able to be different than=
 the rights granted to Organization C.=C2=A0

I agree that we don't want to force all clients to have a client_id, a=
nd as discussed, there are a variety of inputs for an AS to accept calls fr=
om a piece of software, and often, that will be a particular instance of the software, but we also don't want to force clients to all be tr=
eated the same, because they are not..=C2=A0


<=
/div>




On Thu, Jul 16, 2020 at 8=
:24 AM Justin Richer <jricher@mit.edu> wrote:
Exactly =E2=80=94 when we start t=
o look at it as managing the lifecycle of a piece of software, instead of a=
 registration at the AS, we can start thinking in different terms what =E2=
=80=9Ctrusting=E2=80=9D the client means in the context of what the client =
is doing. That trust could come from some kind of signed attestation about =
the software (like the OAuth 2 DynReg software statement), or it could come=
 from some externally fetchable item (like a Solid WebID, a DID, or the OID=
C Federation extension), or it could come from someone sitting at a console=
 and typing in information and getting back an identifier. And none of thes=
e need to pretend to be a global =E2=80=9Cclient id=E2=80=9D for it to work=
. The world of clients is much more diverse than OAuth 2 likes to admit, an=
d we see that with trying to nail down a =E2=80=9Cconfidential=E2=80=9D vs.=
 =E2=80=9Cpublic=E2=80=9D vs. =E2=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=
=E2=80=9D vs. =E2=80=9Cautomatic=E2=80=9D vs. =E2=80=9Cephemeral=E2=80=9D v=
s. =E2=80=A6 any number of other things.=C2=A0

OAut=
h 2 only needs client IDs because the front channel needs a way to pass cli=
ent identifiers when the client can=E2=80=99t authenticate itself directly.=
 We tried to get rid of this restriction with PAR and JAR together, but the=
re turned out to be corner cases in OAuth 2=E2=80=99s world that still need=
ed client_id, and implementations assumed it would be there anyway.=C2=A0

In GNAP, we can avoid that problem from the beginni=
ng by looking at the model differently and understanding where we=E2=80=99r=
e coming from, and why.

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


On Jul 16, 2020, at 3:49 AM, Fabien=
 Imbault <fabien.imbault@gmail.com> wrote:

+1 on that.

We can then see it more as li=
fe cycle management of the client than registration per say, and this comes=
 with many benefits compared to the current client_id.

=

Fabien

On Tue, Jul 14, 2020 at 9:32 PM Justin Richer <jricher@mi=
t.edu> wrote:
I not only agree with Mike Jones that =E2=80=9Cautomatic registra=
tion=E2=80=9D should be part of the process, but I would argue that that ki=
nd of model should be a default mode of operation. If you have an identifie=
r that you can send to short-circuit that, great! But we should focus on ha=
ving the capability of inlining a lot of this information wherever possible=
. This is already the direction that the input proposals are heading.
<=
br>
So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in =
scope for the protocol in general, and since both XYZ and Xauth have mechan=
isms that allow the client to present a key and get back an identifier that=
 it can use in the future we have something equivalent.=C2=A0
But I think there=E2=80=99s a little more to it than that: Ulti=
mately, I think we should question thinking in terms of =E2=80=9Cregistrati=
on=E2=80=9D, a model which has hampered the OAuth 2 model in a lot of use c=
ases. For example, the federation draft Mike Jones references below hacks t=
he =E2=80=9Cclient_id=E2=80=9D parameter and makes it point to a document t=
hat the AS has to fetch. This construct is done for two reasons: (1) Oauth =
requires a =E2=80=9Cclient_id=E2=80=9D in the request and (2) it=E2=80=99s =
difficult to pass information by value to the AS due to front-channel restr=
ictions. Since we=E2=80=99re defining a new protocol, we don=E2=80=99t need=
 to hack that functionality into a =E2=80=9Cclient ID=E2=80=9D or equivalen=
t and instead we can pass that information directly in the protocol. If we =
don=E2=80=99t assume that the client *has* to have a client ID equivalent, =
but it *can* have one in a set of defined circumstances, then I think we ar=
e in a much better spot. This is the reasoning for XYZ=E2=80=99s model of h=
aving clients identified by the key, and that key can potentially be passed=
 by a reference identifier.

I think all of the use=
 cases that Mike Varley presents below are all valid directions, with the c=
aveat that we shouldn=E2=80=99t assume a client should be presenting an ID =
at all steps. Mechanisms like software statements should be presentable apa=
rt from a client ID, as should on-device keys. We=E2=80=99re probably going=
 to want extensions for device posture and other forms of attestation as we=
ll.

This is one of the domains that I think we can=
 clearly surpass OAuth 2=E2=80=99s flexibility and capabilities if we are w=
illing to look past OAuth 2=E2=80=99s assumptions of what=E2=80=99s needed =
inline in the protocol.=C2=A0

=C2=A0=E2=80=94 Just=
in

On Jul 14, 2020, at 1:=
54 PM, Mike Varley <mike.varley@securekey.com> wrote:
Is client registration in scope fo=
r the protocol?
=C2=A0
A generic way of handling clients (via ID or Handle or Key or whateve=
r) is to have processing rule on the AS such as =E2=80=9Cif the AS recogniz=
es the client ID (and authentication of that client ID) then it may process=
 the request on behalf of that client. If the AS does not recognize the cli=
ent ID, it must treat this as a new client registration and evaluate any au=
thorization evidence the client provides before enabling the client and map=
ping policies to that client=E2=80=9D (this means dynamic or automatic clie=
nts need to provide additional assertions / software statements whatever to=
 register their ID.
=C2=A0
=

Something like this allows for very flexible systems:
System A can be unknown to the AS but can dynamically reg=
istered each time with an appropriate software statement
System B can have a fairly stable client ID at the AS, but rotat=
e that ID every month through automatic registration (with an assertion it =
got from the AS during a pre-registration for example)
<=
div style=3D"margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,san=
s-serif">System C can pre-register with the AS for a client ID because it d=
oesn=E2=80=99t deal with software statements etc=E2=80=A6
=E2=80=A6
And even =E2=80=98Statel=
essAS=E2=80=99 can operate by never storing client IDs because it will alwa=
ys just rely on the software statements.
=C2=A0
I think a client registration protocol that =
allows these scenarios would be very useful in GNAP, but hopefully avoiding=
 having to define what =E2=80=98evidence=E2=80=99 the AS needs to accept fo=
r each scenario.
=C2=A0
Thanks,
=C2=A0
MV
=C2=A0
From:=C2=A0T=
xauth <txau=
th-bounces@ietf.org> on behalf of Mike Jones <Michael.Jo=
nes=3D40microsoft.com@dmarc.ietf.org>
Date:=C2=A0=
Tuesday, July 14, 2020 at 12:18 PM
To:=C2=A0Dick=
 Hardt <dick.h=
ardt@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
Subject:=
=C2=A0Re: [Txauth] Key handle vs client id & handle=

=C2=A0
I agree that there=
 are significant differences between statically and dynamically registered =
clients and that=E2=80=99s appropriate to be able to syntactically differen=
tiate between them at runtime.=C2=A0 For one thing, the resource requiremen=
ts at the authorization server can be very different.<=
/div>
=C2=A0=

We should al=
so be thinking about how to include what the OpenID Connect Federation spec=
=C2=A0https://openid.net/specs/openid-co=
nnect-federation-1_0.html=C2=A0calls =E2=80=9CAutomatic Re=
gistration=E2=80=9D.=C2=A0 This lets the client encode a registration reque=
st reference in the client ID, so no static or dynamic registration even oc=
curs.=C2=A0 See=C2=A0https=
://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section.9.1.
From:=C2=A0<=
/span>Dick Hardt <dick.hardt@gmail.com>=C2=A0
Sent:=
=C2=A0Friday, July 10, 2020 1:17 PM
To:=C2=A0=
txauth@ietf.org; J=
ustin Richer <jrich=
er@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Subject:=
=C2=A0Key handle vs client id & handle
=C2=A0
+ Mi=
ke as he had interest in this topic
=
=C2=A0
My understanding is that an e=
xisting OAuth 2 client would use their current client id as their key handl=
e, and a dynamic client (one that was not pre-registered) would be given a =
key handle by the AS.
=C2=A0
There are potentially some sign=
ificant differences between a registered client, and a dynamic client to an=
 AS.
=C2=A0
The AS is likely to know the identity of a regis=
tered client, and have different policies between the two types of clients.=
 For example, a registered client may have access to a 'write" sco=
pe, while a dynamic client does not.
=C2=A0
The AS may have =
100s or 1000s of registered clients, but a dynamic client may have 10Ms or =
100Ms of instances, which may dictate separate=C2=A0storage services. Addit=
ionally, internal to the AS, which systems can write to the registered=C2=
=A0client store is going to be different than the dynamic client=C2=A0store=
.
=C2=A0
In XYZ, subsequent calls to the AS, both registered=
 clients and dynamic clients pass a key handle, so there is no easy way to =
differentiate between the two.
=C2=A0
While the AS could emb=
ed semantics in the key handle identifier to indicate which identifiers are=
 pre-registered vs dynamic, there are many cases where the AS does need to =
know the difference, so making=C2=A0the difference a feature of GNAP seems =
like a better path.
=C2=
=A0
=C2=A0
=

This email and any attachments are for the sole use of t=
he intended recipients and may be privileged, confidential or otherwise exe=
mpt from disclosure under law. Any distribution, printing or other use by a=
nyone other than the intended recipient is prohibited. If you are not an in=
tended recipient, please contact the sender immediately, and permanently de=
lete this email and its attachments.

=

-- 

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



--00000000000065d7de05ab621bf1--


From nobody Sun Jul 26 18:43: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 5A29F3A15D9 for ; Sun, 26 Jul 2020 18:43:37 -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 NZbvt5y38NFV for ; Sun, 26 Jul 2020 18:43:33 -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 9ABF13A15D8 for ; Sun, 26 Jul 2020 18:43:33 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id o72so5604682ota.11 for ; Sun, 26 Jul 2020 18:43: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=CN6xH3RRyifLOmDOaBVpvX6BkBSEtj0GR4QNB8hoD4s=; b=DSbZq3HAQUD46ufMfyrTMBY9cYiPvcvoKabY9tLMdiXENbVqR4e3H6askEOKFY6LYU 4BQ2Ftheb9ndo6sFCQi/wqrKrcdLSEzpoEyC7PHnFK5NbNZVgIk3hkEAW0Mam5IxVsAB EyCDSogIM+gIj6yx8Kz0RgzvoDZ/JkdvZNJlMdiN8hxkYyb7GL7wxl3xxQbs2FNPNfkP ZWgaBBzsUuuJ6JiVYHlxELs3fQY7mRSHQFKPLpj/oZfzmAQoE7fjdHhUqXVR2m4SylVo O5LS6pfwNF3LZLkLO5o6vgUcX7s07v/M8DJ0aTJkOC22EfG+16eJ8HYeUBm5AB4+mo/C kJGg==
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=CN6xH3RRyifLOmDOaBVpvX6BkBSEtj0GR4QNB8hoD4s=; b=nyLsBHVLsFox1UXABrDCcZp5yTndzv3MlHJcRXXecew71YlrdHTdG0J6IT7VPzrxo3 YhLAeq4KetgIkY7eRcaeNWvL8+jraT/wUC49kSkGxncnQ3nr+lrBCWYZ3bDPLfQf/vAW 62Q/QahDjxOCd5CuQjbu6MrqBXuXKbPIpQX6w1v+HkwO8LXfVLXeV5+esAQZdMBI2PX7 mThsf8WvuiD5Hs4yO0K5raZa5QqItjQxuaJEi5AoMGohuR8ZGAV1wq14R7lRhg19rkVq sukJu2ti7NE7IyhHKNhmfPZ9+ALTMwqfWm6MoNtXRuaQzsily/0XlfGVs9mUwmrvFo59 qTjg==
X-Gm-Message-State: AOAM531hKZkZHfc8e8UPkftzgVHKDhJTCmNW9bsR8undO+sWvfLxLAc5 gV0MdlR7Ag9PyOuDh6ZaTe2QfccTP2csJkUnhEA=
X-Google-Smtp-Source: ABdhPJzscho+WAUueP+nR798hXcJOXE2HnuCLqMI/9IVzrtSjTN1o/o+BJjnyPr3V9d1SfCF+wMRN++Aws2hQSRj9lk=
X-Received: by 2002:a9d:a03:: with SMTP id 3mr17770559otg.87.1595814212681; Sun, 26 Jul 2020 18:43:32 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>    <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>     
In-Reply-To: 
From: Tom Jones 
Date: Sun, 26 Jul 2020 18:43:20 -0700
Message-ID: 
To: Dick Hardt 
Cc: Francis Pouatcha , Justin Richer ,  Mike Jones ,  Fabien Imbault , Mike Varley ,  "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000464eb405ab627302"
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 27 Jul 2020 01:43:38 -0000

--000000000000464eb405ab627302
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

You should consider a trust framework to be first of all a set of
qualifying criteria above and beyond the literal meaning of the standard.
Ours is focused on US Healthcare, but lots of others make sense. The
international R&E org is the basis for the openid federation doc.
Secondarily the trust framework could vet members so that they made
affirmative statements about their compliance.
Tertiary they tf could mandate testing of the members. That is the case for
US Healthcare.
the tf could be blank for sites with no moral scruples whatsoever. (the
majority of sites i am sure.)
Peace ..tom


On Sun, Jul 26, 2020 at 6:18 PM Dick Hardt  wrote:

> Hi Francis
>
> While a Trust Framework concept looks to make sense for PSD2 use cases,
> there are lots of other use cases.
>
> How would you see existing OAuth 2 and OIDC concepts fitting into a Trust
> Framework concept?
>
> /Dick
>
> =E1=90=A7
>
> On Sat, Jul 25, 2020 at 8:41 PM Francis Pouatcha  wrote:
>
>> I just read through some work being done by Tom at the FIRE (Federated
>> Identifiers for Resilient Ecosystems) working group and it confirms my
>> intention of suggesting the consideration of a "Trust Framework" as a
>> context defining how to handle the client_id.
>>
>> The procedure the GS applies to trust a client is derived from the "Trus=
t
>> Framework" that governs the environment in which GS and Client are
>> operating.
>>
>> In the European PSD2 ecosystem, National Country Authorities (a.k.a
>> Market Authorities or Regulators):
>> - delegate the production of client certificates to Trust Service
>> Providers (TSPs). TSPs are known certification authorities (CAs) in the
>> corresponding countries.
>> - maintain a register of Certified Third Party Providers (TPPs) at the
>> European Banking Association (EBA), where the validity of the TPP licens=
e
>> can be verified, in addition to the client certificate.
>>
>> Designing an authorization framework around the PSD2 ecosystem, there is
>> no need to maintain any static or dynamic client_id. Each request is
>> associated with an SSL client certificate called QWAC (Qualified Website
>> Assertion Certificate).
>> - This certificate can be verified as the GS maintains a list of all
>> known TSP's CA authorized to release PSD2 client certificates.
>> - This certificate also contains the list of roles assigned to the TPP b=
y
>> the regulator PSP_AS (bank), PSP_PI (payment initiation), PSP_AI (accoun=
t
>> information), PSP_IC (card) sufficient for the client access control in =
the
>> PSD2 trust framework.
>> - This certificate contains a permanent "Competent Authority" that
>> uniquely identifies the NCA issuing the TPP license.
>> - This certificate contains a permanent "Authorization Number" that is
>> unique in the context of the NCA.
>> - so AuthorizationNumber@CompetentAuthority is globally unique in the
>> context of the PSD2 trust framework.
>>
>> Given these facts, GS implementing PSD2 do not need to register clients.
>> - Each request of the client to the GS can be mTLS secured using the QWA=
C.
>> - GS can extract all information needed to perform authorization from
>> that certificate.
>>
>> This use case does not need an extra client_id at the protocol level.
>>
>> This is:
>> - based on the experience we are making implementing PSD2,
>> - based on my reading Tom's FIRE use case in the health sector on the
>> sharing of Patient Health Information (PHI) among health care providers,
>>
>> I suggest GNAP introduces the notion of "Trust framework" that governs
>> the environment in which RS, GS and Client interoperate. We can then
>> delegate the decision on specifying the necessity and functions of a
>> client_id to the trust framework.
>>
>>
>> On Thu, Jul 16, 2020 at 7:58 PM Tom Jones 
>> wrote:
>>
>>> I have been working on different level s of identifier, but from the
>>> mobile app perspective. That's the hardest case as you need to boot str=
ap
>>> trust. I suspect that in the web site case you will need these levels.
>>> Transport, application, real world.
>>>
>>> If anyone wants to work on these, let me know and I'll get you the link=
s
>>> in Kantara.
>>>
>>> thx ..Tom (mobile)
>>>
>>> On Thu, Jul 16, 2020, 2:47 PM Justin Richer  wrote:
>>>
>>>> For all of these, I still say we should have different levels of
>>>> identifier. A =E2=80=9Cclient ID=E2=80=9D should identify the client, =
and not be used as a
>>>> stand-in for other things.
>>>>
>>>> Off the top of my head I think we might want to have identifiers,
>>>> assertions, proofs, and other trust-binding items for:
>>>>
>>>>  - Organizations
>>>>  - Devices
>>>>  - Software applications
>>>>  - Software instances
>>>>  - Software versions
>>>>
>>>> So if we=E2=80=99re going to talk about identifying these aspects, we =
should
>>>> tackle each as its own thing and not mush it all into =E2=80=9Cclient_=
id=E2=80=9D. That
>>>> way, hopefully, GNAP can have a much better idea what a =E2=80=9Cclien=
t=E2=80=9D is than
>>>> OAuth 2 currently does.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Jul 16, 2020, at 4:34 PM, Dick Hardt  wrote:
>>>>
>>>> One client identifier was a simplistic example. Org A may have numerou=
s
>>>> clients, perhaps in different teams, perhaps in different services, ea=
ch
>>>> with their own policy at Org B.
>>>>
>>>> When one of the Org A clients makes a call to the Org B AS, it needs t=
o
>>>> identify itself with some identifier so that Org B knows which policy =
to
>>>> enforce. Why not the Client ID?
>>>>
>>>> I also agree with your comments that other client identification
>>>> situations are different, and forcing the same identification model on=
 them
>>>> does not make sense, but I fail to see the value throwing out a concep=
t
>>>> (client_id) that has worked well for the use cases it was designed for=
.
>>>>
>>>>
>>>> =E1=90=A7
>>>>
>>>> On Thu, Jul 16, 2020 at 1:08 PM Justin Richer  wrote:
>>>>
>>>>> I think that the cross-organizational trust model is an interesting
>>>>> one, and in fact it=E2=80=99s one of the things that=E2=80=99s pushed=
 me away from a
>>>>> client_id. In the scenario that you describe, =E2=80=9Cclient_id=E2=
=80=9D is used to
>>>>> represent something that it was never meant to represent: the organiz=
ation
>>>>> running the software, not the software itself. It isn=E2=80=99t a cli=
ent_id, and
>>>>> while in OAuth 2 the client_id could be co-opted to carry that inform=
ation,
>>>>> it=E2=80=99s considered bad practice to share client_ids between mult=
iple pieces of
>>>>> software.
>>>>>
>>>>> I would argue that to address this use case properly, there should be
>>>>> another level of identifier to bridge that trust that the software ca=
n
>>>>> present, showing that it is a part of Organization A, and not Organiz=
ation
>>>>> C. This isn=E2=80=99t a client identifier, it=E2=80=99s an organizati=
on identifier, and it
>>>>> should be separate. You might want to identify both the client instan=
ce as
>>>>> well as the organization it=E2=80=99s a part of, for example. This is=
 part of the
>>>>> motivation behind putting =E2=80=9Corganizational data=E2=80=9D withi=
n scope for the client
>>>>> to send to the AS, after all.
>>>>>
>>>>> Therefore, I strongly disagree that this scenario =E2=80=9Crequires=
=E2=80=9D a
>>>>> client_id to be solved. In fact, I think that solving this scenario w=
ith a
>>>>> client_id is an anti-pattern that stems from OAuth 2=E2=80=99s over-r=
eliance on
>>>>> client_id as a persistent identifier within the protocol, and we can =
and
>>>>> should do better with GNAP. It=E2=80=99s very similar to Mike Jones=
=E2=80=99s referenced
>>>>> federation document, where the client_id is co-opted as a means of
>>>>> bootstrapping client registration and discovery, or in the Solid
>>>>> Authentication specification which stuffs a WebID into the client_id =
field.
>>>>>
>>>>> With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools that w=
e had to solve
>>>>> our problems, and come up with some very clever solutions. What I=E2=
=80=99m trying
>>>>> to argue to this community is that we are in a position to create our=
 own,
>>>>> better tools.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> On Jul 16, 2020, at 2:00 PM, Dick Hardt  wrote:
>>>>>
>>>>> Justin,
>>>>>
>>>>> While I agree that the assumption in OAuth 2 that all Clients have a
>>>>> client_id is problematic, the requirement for a client_id in many use=
 cases
>>>>> is still there, and it does not represent a piece of software, but a
>>>>> relationship between parties.
>>>>>
>>>>> Organization A writes client software that calls resources managed by
>>>>> the AS in Organization B. The client_id represents Organization A to
>>>>> Organization B. Organization B does not care what software Organizati=
on A
>>>>> is running, and there may be numerous pieces of software at Organizat=
ion A
>>>>> that use the same client_id. The access granted by Organization B to
>>>>> Organization A needs to be able to be different than the rights grant=
ed to
>>>>> Organization C.
>>>>>
>>>>> I agree that we don't want to force all clients to have a client_id,
>>>>> and as discussed, there are a variety of inputs for an AS to accept c=
alls
>>>>> from a piece of software, and often, that will be a particular
>>>>> *instance* of the software, but we also don't want to force clients
>>>>> to all be treated the same, because they are not..
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer  wrote=
:
>>>>>
>>>>>> Exactly =E2=80=94 when we start to look at it as managing the lifecy=
cle of a
>>>>>> piece of software, instead of a registration at the AS, we can start
>>>>>> thinking in different terms what =E2=80=9Ctrusting=E2=80=9D the clie=
nt means in the context
>>>>>> of what the client is doing. That trust could come from some kind of=
 signed
>>>>>> attestation about the software (like the OAuth 2 DynReg software
>>>>>> statement), or it could come from some externally fetchable item (li=
ke a
>>>>>> Solid WebID, a DID, or the OIDC Federation extension), or it could c=
ome
>>>>>> from someone sitting at a console and typing in information and gett=
ing
>>>>>> back an identifier. And none of these need to pretend to be a global
>>>>>> =E2=80=9Cclient id=E2=80=9D for it to work. The world of clients is =
much more diverse than
>>>>>> OAuth 2 likes to admit, and we see that with trying to nail down a
>>>>>> =E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=
=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautomatic=
=E2=80=9D vs.
>>>>>> =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of other things=
.
>>>>>>
>>>>>> OAuth 2 only needs client IDs because the front channel needs a way
>>>>>> to pass client identifiers when the client can=E2=80=99t authenticat=
e itself
>>>>>> directly. We tried to get rid of this restriction with PAR and JAR
>>>>>> together, but there turned out to be corner cases in OAuth 2=E2=80=
=99s world that
>>>>>> still needed client_id, and implementations assumed it would be ther=
e
>>>>>> anyway.
>>>>>>
>>>>>> In GNAP, we can avoid that problem from the beginning by looking at
>>>>>> the model differently and understanding where we=E2=80=99re coming f=
rom, and why.
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault 
>>>>>> wrote:
>>>>>>
>>>>>> +1 on that.
>>>>>>
>>>>>> We can then see it more as life cycle management of the client than
>>>>>> registration per say, and this comes with many benefits compared to =
the
>>>>>> current client_id.
>>>>>>
>>>>>> Fabien
>>>>>>
>>>>>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer 
>>>>>> wrote:
>>>>>>
>>>>>>> I not only agree with Mike Jones that =E2=80=9Cautomatic registrati=
on=E2=80=9D
>>>>>>> should be part of the process, but I would argue that that kind of =
model
>>>>>>> should be a default mode of operation. If you have an identifier th=
at you
>>>>>>> can send to short-circuit that, great! But we should focus on havin=
g the
>>>>>>> capability of inlining a lot of this information wherever possible.=
 This is
>>>>>>> already the direction that the input proposals are heading.
>>>>>>>
>>>>>>> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope =
for the protocol
>>>>>>> in general, and since both XYZ and Xauth have mechanisms that allow=
 the
>>>>>>> client to present a key and get back an identifier that it can use =
in the
>>>>>>> future we have something equivalent.
>>>>>>>
>>>>>>> But I think there=E2=80=99s a little more to it than that: Ultimate=
ly, I
>>>>>>> think we should question thinking in terms of =E2=80=9Cregistration=
=E2=80=9D, a model which
>>>>>>> has hampered the OAuth 2 model in a lot of use cases. For example, =
the
>>>>>>> federation draft Mike Jones references below hacks the =E2=80=9Ccli=
ent_id=E2=80=9D
>>>>>>> parameter and makes it point to a document that the AS has to fetch=
. This
>>>>>>> construct is done for two reasons: (1) Oauth requires a =E2=80=9Ccl=
ient_id=E2=80=9D in the
>>>>>>> request and (2) it=E2=80=99s difficult to pass information by value=
 to the AS due
>>>>>>> to front-channel restrictions. Since we=E2=80=99re defining a new p=
rotocol, we
>>>>>>> don=E2=80=99t need to hack that functionality into a =E2=80=9Cclien=
t ID=E2=80=9D or equivalent and
>>>>>>> instead we can pass that information directly in the protocol. If w=
e don=E2=80=99t
>>>>>>> assume that the client *has* to have a client ID equivalent, but it=
 *can*
>>>>>>> have one in a set of defined circumstances, then I think we are in =
a much
>>>>>>> better spot. This is the reasoning for XYZ=E2=80=99s model of havin=
g clients
>>>>>>> identified by the key, and that key can potentially be passed by a
>>>>>>> reference identifier.
>>>>>>>
>>>>>>> I think all of the use cases that Mike Varley presents below are al=
l
>>>>>>> valid directions, with the caveat that we shouldn=E2=80=99t assume =
a client should
>>>>>>> be presenting an ID at all steps. Mechanisms like software statemen=
ts
>>>>>>> should be presentable apart from a client ID, as should on-device k=
eys.
>>>>>>> We=E2=80=99re probably going to want extensions for device posture =
and other forms
>>>>>>> of attestation as well.
>>>>>>>
>>>>>>> This is one of the domains that I think we can clearly surpass OAut=
h
>>>>>>> 2=E2=80=99s flexibility and capabilities if we are willing to look =
past OAuth 2=E2=80=99s
>>>>>>> assumptions of what=E2=80=99s needed inline in the protocol.
>>>>>>>
>>>>>>>  =E2=80=94 Justin
>>>>>>>
>>>>>>> On Jul 14, 2020, at 1:54 PM, Mike Varley 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Is client registration in scope for the protocol?
>>>>>>>
>>>>>>> A generic way of handling clients (via ID or Handle or Key or
>>>>>>> whatever) is to have processing rule on the AS such as =E2=80=9Cif =
the AS
>>>>>>> recognizes the client ID (and authentication of that client ID) the=
n it may
>>>>>>> process the request on behalf of that client. If the AS does not re=
cognize
>>>>>>> the client ID, it must treat this as a new client registration and =
evaluate
>>>>>>> any authorization evidence the client provides before enabling the =
client
>>>>>>> and mapping policies to that client=E2=80=9D (this means dynamic or=
 automatic
>>>>>>> clients need to provide additional assertions / software statements
>>>>>>> whatever to register their ID.
>>>>>>>
>>>>>>> Something like this allows for very flexible systems:
>>>>>>> System A can be unknown to the AS but can dynamically registered
>>>>>>> each time with an appropriate software statement
>>>>>>> System B can have a fairly stable client ID at the AS, but rotate
>>>>>>> that ID every month through automatic registration (with an asserti=
on it
>>>>>>> got from the AS during a pre-registration for example)
>>>>>>> System C can pre-register with the AS for a client ID because it
>>>>>>> doesn=E2=80=99t deal with software statements etc=E2=80=A6
>>>>>>> =E2=80=A6
>>>>>>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing=
 client IDs
>>>>>>> because it will always just rely on the software statements.
>>>>>>>
>>>>>>> I think a client registration protocol that allows these scenarios
>>>>>>> would be very useful in GNAP, but hopefully avoiding having to defi=
ne what
>>>>>>> =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario=
.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> MV
>>>>>>>
>>>>>>> *From: *Txauth  on behalf of Mike Jones <
>>>>>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
>>>>>>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>>>>>>> *To: *Dick Hardt , "txauth@ietf.org" <
>>>>>>> txauth@ietf.org>, Justin Richer 
>>>>>>> *Subject: *Re: [Txauth] Key handle vs client id & handle
>>>>>>>
>>>>>>> I agree that there are significant differences between statically
>>>>>>> and dynamically registered clients and that=E2=80=99s appropriate t=
o be able to
>>>>>>> syntactically differentiate between them at runtime.  For one thing=
, the
>>>>>>> resource requirements at the authorization server can be very diffe=
rent.
>>>>>>>
>>>>>>> We should also be thinking about how to include what the OpenID
>>>>>>> Connect Federation spec
>>>>>>> https://openid.net/specs/openid-connect-federation-1_0.html calls
>>>>>>> =E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client enc=
ode a registration
>>>>>>> request reference in the client ID, so no static or dynamic registr=
ation
>>>>>>> even occurs.  See
>>>>>>> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.=
section.9.1
>>>>>>> 
>>>>>>> .
>>>>>>>
>>>>>>>                                                        -- Mike
>>>>>>>
>>>>>>> *From:* Dick Hardt 
>>>>>>> *Sent:* Friday, July 10, 2020 1:17 PM
>>>>>>> *To:* txauth@ietf.org; Justin Richer ; Mike Jones =
<
>>>>>>> Michael.Jones@microsoft.com>
>>>>>>> *Subject:* Key handle vs client id & handle
>>>>>>>
>>>>>>> + Mike as he had interest in this topic
>>>>>>>
>>>>>>> My understanding is that an existing OAuth 2 client would use their
>>>>>>> current client id as their key handle, and a dynamic client (one th=
at was
>>>>>>> not pre-registered) would be given a key handle by the AS.
>>>>>>>
>>>>>>> There are potentially some significant differences between a
>>>>>>> registered client, and a dynamic client to an AS.
>>>>>>>
>>>>>>> The AS is likely to know the identity of a registered client, and
>>>>>>> have different policies between the two types of clients. For examp=
le, a
>>>>>>> registered client may have access to a 'write" scope, while a dynam=
ic
>>>>>>> client does not.
>>>>>>>
>>>>>>> The AS may have 100s or 1000s of registered clients, but a dynamic
>>>>>>> client may have 10Ms or 100Ms of instances, which may dictate
>>>>>>> separate storage services. Additionally, internal to the AS, which =
systems
>>>>>>> can write to the registered client store is going to be different t=
han the
>>>>>>> dynamic client store.
>>>>>>>
>>>>>>> In XYZ, subsequent calls to the AS, both registered clients and
>>>>>>> dynamic clients pass a key handle, so there is no easy way to diffe=
rentiate
>>>>>>> between the two.
>>>>>>>
>>>>>>> While the AS could embed semantics in the key handle identifier to
>>>>>>> indicate which identifiers are pre-registered vs dynamic, there are=
 many
>>>>>>> cases where the AS does need to know the difference, so making the
>>>>>>> difference a feature of GNAP seems like a better path.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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 an=
yone
>>>>>>> other than the intended recipient is prohibited. If you are not an =
intended
>>>>>>> recipient, please contact the sender immediately, and permanently d=
elete
>>>>>>> this email and its attachments.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Txauth mailing 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/
>>
>

--000000000000464eb405ab627302
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


You=C2=A0should consider a trust=C2=A0framework to be firs=
t of all a set of qualifying=C2=A0criteria above and beyond the literal mea=
ning of the standard.
Ours is focused on US Healthcare, but lots of oth=
ers make sense. The international R&E org is the basis for the openid f=
ederation doc.
Secondarily the trust framework could vet members =
so that they made affirmative statements about their compliance.
=
Tertiary they tf could mandate testing of the members. That is the case for=
 US Healthcare.
the tf could be blank for sites with no moral scr=
uples whatsoever. (the majority of sites i am sure.)
=

Peace ..tom


On Su=
n, Jul 26, 2020 at 6:18 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis

W=
hile a Trust Framework concept looks to make sense for PSD2 use cases, ther=
e are lots of other use cases.

How would you see existin=
g OAuth 2 and OIDC concepts fitting into a Trust Framework concept?

/Dick

3D""=E1=
=90=A7

On Sat, Jul 25, 2020 at 8:41 PM Francis Pouatcha <fpo@adorsys.de> wrote:<=
br>
I just read through some work being done by Tom at the FIRE (Federated Ide=
ntifiers for Resilient Ecosystems) working=C2=A0group and it confirms my in=
tention of suggesting the consideration of a "Trust Framework" as=
 a context defining how to handle the client_id.

The pro=
cedure the GS applies to trust a client is derived from the "Trust Fra=
mework" that governs the environment in which GS and Client are operat=
ing.

In the European PSD2 ecosystem, National =
Country Authorities (a.k.a Market Authorities or Regulators):
- d=
elegate the production of client certificates to Trust Service Providers (T=
SPs). TSPs are known certification authorities (CAs) in the corresponding c=
ountries.
- maintain a register of Certified Third Party Provider=
s (TPPs) at the European Banking Association (EBA), where the validity of t=
he TPP license can be verified,=C2=A0in addition=C2=A0to the client certifi=
cate.

Designing an authorization framework around=
=C2=A0the PSD2 ecosystem, there is no need to maintain any static or dynami=
c client_id. Each request is associated with an SSL client certificate call=
ed QWAC (Qualified Website Assertion Certificate).=C2=A0
- This c=
ertificate can be verified as the GS maintains a list of all known TSP'=
s CA authorized to release PSD2 client certificates.
- This certi=
ficate also contains the list of roles assigned to the TPP by the regulator=
=C2=A0PSP_AS (bank), PSP_PI (payment initiation), PSP_AI (account informati=
on), PSP_IC (card) sufficient for the client access control in the PSD2 tru=
st framework.
- This certificate contains a permanent "Compe=
tent Authority" that uniquely=C2=A0identifies the NCA issuing the TPP =
license.
- This certificate contains a permanent "Authorizat=
ion Number" that is unique in the context of the NCA.
- so=
=C2=A0AuthorizationNumber@CompetentAuthority is globally=C2=A0unique in the=
 context of the PSD2 trust framework.

Given these =
facts, GS implementing PSD2 do not need to register clients.=C2=A0
- Each request of the client to the GS can be mTLS secured using the QWAC=
.
- GS can extract all information needed to perform=C2=A0authori=
zation from that certificate.

This use case does n=
ot need an extra client_id at the protocol level.=C2=A0

This is:
- based on the experience we are making implementi=
ng PSD2,
- based on my reading Tom's FIRE use case in the hea=
lth sector on the sharing of Patient Health Information (PHI) among health =
care providers,

I suggest GNAP introduces the noti=
on of "Trust framework" that governs the environment in which RS,=
 GS and Client interoperate. We can then delegate the decision on specifyin=
g the necessity and functions of a client_id to the trust framework.
<=
div>

On Thu, Jul 16, 2020 at 7:58 PM Tom Jones <thomasclinganjones@gma=
il.com> wrote:
I have been working on different level s of identif=
ier, but from the mobile app perspective. That's the hardest case as yo=
u need to boot strap trust. I suspect that in the web site case you will ne=
ed these levels. Transport, application, real world.

<=
/div>
If anyone wants to work on these, let me know and I&=
#39;ll get you the links in Kantara.

thx ..Tom (mo=
bile)

On Thu, Jul 16, 2020, 2:47 PM Justin Richer <jricher@mit.edu> wrote:
For all of these, I still sa=
y we should have different levels of identifier. A =E2=80=9Cclient ID=E2=80=
=9D should identify the client, and not be used as a stand-in for other thi=
ngs.=C2=A0

Off the top of my head I think we might want =
to have identifiers, assertions, proofs, and other trust-binding items for:=


=C2=A0- Organizations
=C2=A0- Devices
=C2=A0- Software applications
=C2=A0- Software instances=

=C2=A0- Software versions

So if we=E2=
=80=99re going to talk about identifying these aspects, we should tackle ea=
ch as its own thing and not mush it all into =E2=80=9Cclient_id=E2=80=9D. T=
hat way, hopefully, GNAP can have a much better idea what a =E2=80=9Cclient=
=E2=80=9D is than OAuth 2 currently does.

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

On Jul 16, 2020=
, at 4:34 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
One client identifier was a simplistic example. Org =
A may have numerous clients, perhaps in different teams, perhaps in differe=
nt services, each with their own policy at Org B.

Wh=
en one of the Org A clients makes a call to the Org B AS, it needs to ident=
ify itself with some identifier so that Org B knows which policy to enforce=
. Why not the Client ID?

I also agree with your co=
mments that other client identification situations are different, and forci=
ng the same identification model on them does not make sense, but I fail=C2=
=A0to see the value throwing out a concept (client_id) that has worked well=
 for the use cases it was designed for.=C2=A0


=

=E1=90=A7

On Thu, Jul 16, 2020 at 1:08 PM =
Justin Richer <jricher@mit.edu> wrote:
I think that the cross-organizational tr=
ust model is an interesting one, and in fact it=E2=80=99s one of the things=
 that=E2=80=99s pushed me away from a client_id. In the scenario that you d=
escribe, =E2=80=9Cclient_id=E2=80=9D is used to represent something that it=
 was never meant to represent: the organization running the software, not t=
he software itself. It isn=E2=80=99t a client_id, and while in OAuth 2 the =
client_id could be co-opted to carry that information, it=E2=80=99s conside=
red bad practice to share client_ids between multiple pieces of software.=
=C2=A0

I would argue that to address this use case prope=
rly, there should be another level of identifier to bridge that trust that =
the software can present, showing that it is a part of Organization A, and =
not Organization C. This isn=E2=80=99t a client identifier, it=E2=80=99s an=
 organization identifier, and it should be separate. You might want to iden=
tify both the client instance as well as the organization it=E2=80=99s a pa=
rt of, for example. This is part of the motivation behind putting =E2=80=9C=
organizational data=E2=80=9D within scope for the client to send to the AS,=
 after all.

Therefore, I strongly disagree that th=
is scenario =E2=80=9Crequires=E2=80=9D a client_id to be solved. In fact, I=
 think that solving this scenario with a client_id is an anti-pattern that =
stems from OAuth 2=E2=80=99s over-reliance on client_id as a persistent ide=
ntifier within the protocol, and we can and should do better with GNAP. It=
=E2=80=99s very similar to Mike Jones=E2=80=99s referenced federation docum=
ent, where the client_id is co-opted as a means of bootstrapping client reg=
istration and discovery, or in the Solid Authentication specification which=
 stuffs a WebID into the client_id field.

With OAu=
th 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools that we had to solve=
 our problems, and come up with some very clever solutions. What I=E2=80=99=
m trying to argue to this community is that we are in a position to create =
our own, better tools.=C2=A0

=C2=A0=E2=80=94 Justi=
n

On Jul 16, 2020, at 2:00 PM, D=
ick Hardt <dick.hardt@gmail.com> wrote:

Justin,=C2=A0

While I agree that the assumption=
 in OAuth 2 that all Clients have a client_id is problematic, the requireme=
nt for a client_id in many use cases is still there, and it does not repres=
ent a piece of software, but a relationship between parties.

Organization A writes client software that calls resources =
managed by the AS in Organization B. The client_id represents Organization =
A to Organization B. Organization B does not care what software Organizatio=
n A is running, and there may be numerous=C2=A0pieces of software at Organi=
zation A that use the same client_id. The access granted by Organization B =
to Organization A needs to be able to be different than the rights granted =
to Organization C.=C2=A0

I agree that we don=
't want to force all clients to have a client_id, and as discussed, the=
re are a variety of inputs for an AS to accept calls from a piece of softwa=
re, and often, that will be a particular instance of the software, b=
ut we also don't want to force clients to all be treated the same, beca=
use they are not..=C2=A0



=




On Thu, Jul 16, 2020 at 8:24 AM Justin Richer=
 <jricher@mit.edu> wrote:
Exactly =E2=80=94 when we start to look at it as mana=
ging the lifecycle of a piece of software, instead of a registration at the=
 AS, we can start thinking in different terms what =E2=80=9Ctrusting=E2=80=
=9D the client means in the context of what the client is doing. That trust=
 could come from some kind of signed attestation about the software (like t=
he OAuth 2 DynReg software statement), or it could come from some externall=
y fetchable item (like a Solid WebID, a DID, or the OIDC Federation extensi=
on), or it could come from someone sitting at a console and typing in infor=
mation and getting back an identifier. And none of these need to pretend to=
 be a global =E2=80=9Cclient id=E2=80=9D for it to work. The world of clien=
ts is much more diverse than OAuth 2 likes to admit, and we see that with t=
rying to nail down a =E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=
=80=9D vs. =E2=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =E2=
=80=9Cautomatic=E2=80=9D vs. =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any =
number of other things.=C2=A0

OAuth 2 only needs cl=
ient IDs because the front channel needs a way to pass client identifiers w=
hen the client can=E2=80=99t authenticate itself directly. We tried to get =
rid of this restriction with PAR and JAR together, but there turned out to =
be corner cases in OAuth 2=E2=80=99s world that still needed client_id, and=
 implementations assumed it would be there anyway.=C2=A0

In GNAP, we can avoid that problem from the beginning by looking at =
the model differently and understanding where we=E2=80=99re coming from, an=
d why.

=C2=A0=E2=80=94 Justin

On Jul 16, 2020, at 3:49 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

+1=
 on that.

We can then see it more as life cycle manageme=
nt of the client than registration per say, and this comes with many benefi=
ts compared to the current client_id.

Fabien
=


=
On Tue, Jul 14, 2020 at 9:32 PM Justin Richer <jricher@mit.edu> wrot=
e:
I not on=
ly agree with Mike Jones that =E2=80=9Cautomatic registration=E2=80=9D shou=
ld be part of the process, but I would argue that that kind of model should=
 be a default mode of operation. If you have an identifier that you can sen=
d to short-circuit that, great! But we should focus on having the capabilit=
y of inlining a lot of this information wherever possible. This is already =
the direction that the input proposals are heading.

So I=
 kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope for the prot=
ocol in general, and since both XYZ and Xauth have mechanisms that allow th=
e client to present a key and get back an identifier that it can use in the=
 future we have something equivalent.=C2=A0

But I =
think there=E2=80=99s a little more to it than that: Ultimately, I think we=
 should question thinking in terms of =E2=80=9Cregistration=E2=80=9D, a mod=
el which has hampered the OAuth 2 model in a lot of use cases. For example,=
 the federation draft Mike Jones references below hacks the =E2=80=9Cclient=
_id=E2=80=9D parameter and makes it point to a document that the AS has to =
fetch. This construct is done for two reasons: (1) Oauth requires a =E2=80=
=9Cclient_id=E2=80=9D in the request and (2) it=E2=80=99s difficult to pass=
 information by value to the AS due to front-channel restrictions. Since we=
=E2=80=99re defining a new protocol, we don=E2=80=99t need to hack that fun=
ctionality into a =E2=80=9Cclient ID=E2=80=9D or equivalent and instead we =
can pass that information directly in the protocol. If we don=E2=80=99t ass=
ume that the client *has* to have a client ID equivalent, but it *can* have=
 one in a set of defined circumstances, then I think we are in a much bette=
r spot. This is the reasoning for XYZ=E2=80=99s model of having clients ide=
ntified by the key, and that key can potentially be passed by a reference i=
dentifier.

I think all of the use cases that Mike =
Varley presents below are all valid directions, with the caveat that we sho=
uldn=E2=80=99t assume a client should be presenting an ID at all steps. Mec=
hanisms like software statements should be presentable apart from a client =
ID, as should on-device keys. We=E2=80=99re probably going to want extensio=
ns for device posture and other forms of attestation as well.
This is one of the domains that I think we can clearly surpass =
OAuth 2=E2=80=99s flexibility and capabilities if we are willing to look pa=
st OAuth 2=E2=80=99s assumptions of what=E2=80=99s needed inline in the pro=
tocol.=C2=A0

=C2=A0=E2=80=94 Justin

On Jul 14, 2020, at 1:54 PM, Mike Varle=
y <mike.varley@securekey.com> wrote:

Is client registration in scope for the protocol?
=C2=A0
A generic w=
ay of handling clients (via ID or Handle or Key or whatever) is to have pro=
cessing rule on the AS such as =E2=80=9Cif the AS recognizes the client ID =
(and authentication of that client ID) then it may process the request on b=
ehalf of that client. If the AS does not recognize the client ID, it must t=
reat this as a new client registration and evaluate any authorization evide=
nce the client provides before enabling the client and mapping policies to =
that client=E2=80=9D (this means dynamic or automatic clients need to provi=
de additional assertions / software statements whatever to register their I=
D.
=C2=A0
Somethi=
ng like this allows for very flexible systems:
System A can be unknown to the AS but can dynamically registered each time=
 with an appropriate software statement
System=
 B can have a fairly stable client ID at the AS, but rotate that ID every m=
onth through automatic registration (with an assertion it got from the AS d=
uring a pre-registration for example)
System C=
 can pre-register with the AS for a client ID because it doesn=E2=80=99t de=
al with software statements etc=E2=80=A6
=E2=
=80=A6
And even =E2=80=98StatelessAS=E2=80=99 =
can operate by never storing client IDs because it will always just rely on=
 the software statements.
=C2=A0=

I think a client registration protocol that allows these sc=
enarios would be very useful in GNAP, but hopefully avoiding having to defi=
ne what =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario=
.
=C2=A0
Thanks,<=
u>
=C2=A0
MV<=
u>
=C2=A0
From:=C2=A0Txauth <txauth-bounces@ietf.o=
rg> on behalf of Mike Jones <Michael.Jones=3D40microsoft=
.com@dmarc.ietf.org>
Date:=C2=A0Tuesday, July=
 14, 2020 at 12:18 PM
To:=C2=A0Dick Hardt <dick.hardt@gmail.com>, "txauth@ie=
tf.org" <t=
xauth@ietf.org>, Justin Richer <jricher@mit.edu>
Subject:=C2=A0Re: [Txauth] Key handle vs client id & handle
=C2=A0
I agree that there are significant =
differences between statically and dynamically registered clients and that=
=E2=80=99s appropriate to be able to syntactically differentiate between th=
em at runtime.=C2=A0 For one thing, the resource requirements at the author=
ization server can be very different.
=C2=A0
We should also be thinking =
about how to include what the OpenID Connect Federation spec=C2=A0https://openid.net/specs/openid-connect-federatio=
n-1_0.html=C2=A0calls =E2=80=9CAutomatic Registration=E2=
=80=9D.=C2=A0 This lets the client encode a registration request reference =
in the client ID, so no static or dynamic registration even occurs.=C2=A0 S=
ee=C2=A0https://openid.net=
/specs/openid-connect-federation-1_0-12.html#rfc.section.9.1.=

=C2=A0
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=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:=C2=A0Dick Hard=
t <dick.hardt@=
gmail.com>=C2=A0
Sent:=C2=A0Frid=
ay, July 10, 2020 1:17 PM
To:=C2=A0txauth@ietf.org; Justin Richer <=
jricher@mit.edu>=
;; Mike Jones <Michael.Jones@microsoft.com>
Subject:=C2=A0<=
/span>Key handle vs client id & handle
=C2=A0
+ Mike as he had inte=
rest in this topic
=C2=A0<=
/u>
My understanding is that an existing OAuth 2 c=
lient would use their current client id as their key handle, and a dynamic =
client (one that was not pre-registered) would be given a key handle by the=
 AS.
=C2=A0
There are potentially some significant differenc=
es between a registered client, and a dynamic client to an AS.
=C2=A0
The AS is likely to know the identity of a registered client, and=
 have different policies between the two types of clients. For example, a r=
egistered client may have access to a 'write" scope, while a dynam=
ic client does not.
=C2=A0<=
/u>
The AS may have 100s or 1000s of =
registered clients, but a dynamic client may have 10Ms or 100Ms of instance=
s, which may dictate separate=C2=A0storage services. Additionally, internal=
 to the AS, which systems can write to the registered=C2=A0client store is =
going to be different than the dynamic client=C2=A0store.
=C2=A0
In XYZ, subsequent calls to the AS, both registered clients and dynami=
c clients pass a key handle, so there is no easy way to differentiate betwe=
en the two.
=C2=A0
While the AS could embed semantics in the=
 key handle identifier to indicate which identifiers are pre-registered vs =
dynamic, there are many cases where the AS does need to know the difference=
, so making=C2=A0the difference a feature of GNAP seems like a better path.=

=C2=A0
=C2=A0
This email and any attachments are for the sole =
use of the intended recipients and may be privileged, confidential or other=
wise exempt from disclosure under law. Any distribution, printing or other =
use by anyone other than the intended recipient is prohibited. If you are n=
ot an intended recipient, please contact the sender immediately, and perman=
ently delete this email and its attachments.

-- 

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




--000000000000464eb405ab627302--


From nobody Sun Jul 26 18:45: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 60E903A15D9 for ; Sun, 26 Jul 2020 18:45:25 -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 HxodRKIac_iP for ; Sun, 26 Jul 2020 18:45:22 -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 A4FD33A15D8 for ; Sun, 26 Jul 2020 18:45:21 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id k8so2786271wma.2 for ; Sun, 26 Jul 2020 18:45:21 -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=nOeut6oFH95peb8A/mZJOd53k/sP3j5SG+fGnVe6QZA=; b=a3JLbuS0HSjDLse/bJQgl9L6iV/3Urg95Vo0I30uQkQ35V+khbuIo2LRIzWKZIcMG0 1bZQjLu3/chxqPtP6qAcLAxT8JV8aXKa+p9uYxDklLFyW0eJLNGylRaXZQLIIWxpBhCV 89L0B4VX/pj6XGKvZxUkFJLpApXcc8Qkqi6Jw=
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=nOeut6oFH95peb8A/mZJOd53k/sP3j5SG+fGnVe6QZA=; b=q+TUOlZ9+sQUqSHpWwHRtdFBs8C2LG1FHat7/tkV6EmVnQE2EOZ1P7cK+ahyWQ7yD5 CfaiI8VmtXJvofgaYHbsJsO1p3MSCkR3OWslBFT4exfbc5b5VTvn2NhbHPJUNDYpy8cN OKBACt04WVMiQVF/A7VgB1NPFJf8PrsH9pjZaDqUpgmqf95Ui7YMa2tUjxCvhEQBv7bh oncv6FjkiYDXJ9y9mTKSfVB0BNR7a8UFku2R3GZZcXpRb9vPr+J9hRjCojQKGP92Lwkh XrizyPZD7BgeNnZxMWAzVBCHLyo+gyJNmou4KLbu+eGVKOmgm6iL2iMgkhZZQI0PMdMS loIg==
X-Gm-Message-State: AOAM53365uaw+xyK3KvolFHkniokG4z/hgcttzNkMTAsCSbW7DlRrNRg GwSgAl7P/BtCKpoNesqzYP3QLqc2/a8MWPoRIeKbXBy5cD0=
X-Google-Smtp-Source: ABdhPJwlyDujTZO2dciNZ2Os05GDohSnoQtUvJ4nt9JJA8AzA5OnzyCkEZcKf1hAvrQwIIX/nYBTHzIP2Ge0Q/QSL34=
X-Received: by 2002:a1c:770c:: with SMTP id t12mr1672449wmi.65.1595814320057;  Sun, 26 Jul 2020 18:45:20 -0700 (PDT)
MIME-Version: 1.0
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>   
In-Reply-To: 
From: Francis Pouatcha 
Date: Sun, 26 Jul 2020 21:45:09 -0400
Message-ID: 
To: Dick Hardt 
Cc: txauth@ietf.org, Justin Richer ,  Tom Jones , Denis ,  Fabien Imbault 
Content-Type: multipart/alternative; boundary="000000000000acc09905ab627912"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 01:45:26 -0000

--000000000000acc09905ab627912
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Dick,

On Sun, Jul 26, 2020 at 9:14 PM Dick Hardt  wrote:

> Hi Francis
>
> User is a well understood term in OIDC and OAuth -- and User means the
> same in both.
>

> Resource Owner is who owns the resource, and the term is introduced for
> when the User is NOT the Resource Owner.
>
This distinction is what makes it confusing as we are comparing an Entity
(the User) to a Role (the RO). We need two roles.


>
> I also think that Client and Resource Server are well understood terms.
>
Looks like contributors on the list still need clarification on the
"orchestration" role of a client.

>
> It is not clear to me why we would want to reinvent these terms. Reading
> over your flows, I think it would be useful to understand the requirement=
s
> you have for your use case, otherwise I fear we will be talking past each
> other.
>
The oAuth flow is there as a memo. The other flow is what I proposed
before. Is there to emphasize we need to work on roles and not on entities.
It is not a suggestion to rename well known idioms. It is an attempt to
give them a proper definition in the context of this protocol. Definition
based on their roles in the protocol flows.

Best regards.
/Francis

>
> /Dick
>
> =E1=90=A7
>
> On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha  wrote:
>
>> Below my opinion on the term Claim:
>>
>> Starting with illustration of parties/roles:
>>
>> User:
>> This word is misleading because of its double role in oAuth2 and OIDC
>> (see below). In GNAP let us have the User play only the role of a
>> requestor. (from Justin reference to "Requesting Party").
>>
>> Client:
>> This is also tightly bound to the oAuth2 and OIDC. The real purpose of
>> this role is to orchestrate resource access on behalf of the "Requestor"=
.
>> Let us call this for now the "Orchestrator"
>>
>> Resource Owner (RO):
>> This is IMO the most correct word in the entire protocol. Authorisation
>> is always about the owner of something granting access to a requestor. I=
t
>> really does not matter if a human interaction is involved. We will have =
to
>> forget oAuth2 and OIDC of also calling this a User.
>>
>> Grant Server:
>> Even though the definition of the UserInfo endpoint in OIDC as a
>> protected resource hazardously makes an OP an RS, we shall not repeat th=
e
>> same mistake here. We need a clear separation between roles of GS and RS
>> without overlapping.
>>
>> Resource Server: services resources.
>>
>> Unless I got it wrong, GNAP is about grant negotiation and authorization=
.
>> This means:
>>
>> GNAP is about some party requesting access to some resources.
>> GNAP is about the resource owner consenting access to that resource.
>> GNAP is about defining the infrastructure that allows the requesting
>> party to access a resource.
>>
>> GNAP designs this infrastructure around:
>> - an orchestrator (what we refer to as a client)
>> - an grant manager (what we refer to as a GS/AS)
>> - the custodian of the resource (what we call a RS)
>>
>> As you see:
>> - The word User does not appear here, and is not relevant as the focus i=
s
>> on authorizing access to a resource.
>> - The word Claim is as well absent.
>>
>> Claim related to RO:
>> The word Claim might start getting visible if the orchestrator (a.k.a.
>> Client) or the custodian (a.k.a RS) needs some additional information on
>> the RO to proceed with the access control decision. These claims refer t=
o
>> assertions of attributes or properties of the RO. These claims are issue=
d
>> by the GS as the GS manages interaction with the RO (see below). In this
>> first place information about the requesting party (erroneously.k.a.
>> User) is not relevant to the negotiation and provisioning framework. Let=
 us
>> call this sort of claim "RO-Attributes". A better name is welcome.
>>
>> Some advanced resource provisioning frameworks might require knowledge o=
n
>> attributes of the requesting party (e.k.a User). These attributes shall =
be
>> collected by the orchestrator (a.k.a Client) and added to the resource
>> request. There is no way the GS can collect these attributes as the GS r=
ole
>> has no interaction with the requesting party (e.k.a User). Let us call t=
his
>> sort of claim "Requestor-Attributes". A better name will be welcome.
>>
>> Some assertions are even related to the orchestrator (a.k.a Client)
>> itself. This is the case of the public key of an orchestrator used by th=
e
>> GS to "sender constrain" an access token. Let us call this type of claim
>> "Orchestrator-Attributes".
>>
>> This is a sample mapping of OIDC.
>>
>> +----+    +---+   +---+  +---+
>> |User|    |RP |   |OP |  |RS |
>> +----+    +---+   +-+-+  +---+
>>   |(1) ServiceRequest      |
>>   |-------->|       |      |
>>   |(2) redirect     |      |
>>   |<--------|       |      |
>> =3D=3D=3D User (requestor) passes control to User (RO) =3D=3D=3D
>>   |(3) Auth + Consent      |
>>   |---------------->|      |
>>   |(4) redirect (code)     |
>>   |<----------------|      |
>> =3D=3D=3D User (RO) passes control back to User (requestor) =3D=3D=3D
>>   |(5) get(code)    |      |
>>   |-------->|       |      |
>>   |         |(6) token (code)
>>   |         |------>|      |
>>   |         |(7) token     |
>>   |         |<------|      |
>>   |         |(8) ServiceRequest(token)
>>   |         |------------->|
>>   |         |(9) ServiceResponse
>>   |         |<-------------|
>>   |(10) ServiceResponse    |
>>   |<--------|       |      |
>>   +         +       +      +
>>
>> - RP orchestrates interaction between User and OP to enable the user to
>> obtain the protected resource.
>> - In step 1 & 10 User plays the role of the requestor of the resource.
>> - In step 2 User-Browser is used to pass control from User (in his role
>> as the requestor) to User (in his role as the RO)
>> - In step 4 User-Browser is used to pass control from User (in his role
>> as the RO) back to User (in his role as the requestor)
>>
>> When we are talking claims here, we are talking claims on the User (in
>> his role as the RO). The OP does not have any interaction with the User =
(in
>> his role as the requestor). In the case of an App2App redirection, the O=
P
>> can not even assert about the user agent of the User (requestor).
>>
>> If there is any claim the OP can provide, it is a claim on the User (RO)=
.
>>
>> I hope this example clarifies the misunderstanding. Any attempt of
>> bringing this double role of the User into GNAP will also bring this
>> confusion. In order to keep this out of GNAP let us look for the right t=
erm
>> for User (as a requestor) using the diagram displayed below.
>>
>> +----+  +------+  +---+  +---+  +---+
>> |Reqs|  |Orchst|  |RS |  |GS |  |RO |
>> +----+  +------+  +---+  +-+-+  +-+-+
>>   |(1) ServiceRequest      |      |
>>   |-------->|       |      |      |
>>   |         |(2) ServiceIntent:AuthZChallenge
>>   |         |<----->|      |      |
>>   |         |       |      |      |
>>   |         |(3) AuthZRequest(AuthZChallenge)
>>   |         |------------->|      |
>>   |         |       |      |(4) ConsentRequest:Grant
>>   |         |       |      |<---->|
>>   |         |(5) GrantAccess(AuthZ)
>>   |         |<-------------|      |
>>   |         |       |      |      |
>>   |         |(6) ServiceRequest(AuthZ):ServiceResponse
>>   |         |<----->|      |      |
>>   |(7) ServiceResponse     |      |
>>   |<--------|       |      |      |
>>   +         +       +      +      +
>>
>> - Replacing the word User helps clarify the difference between both role=
s
>> "Requestor" and "Resource Owner"
>> - Renaming claim by attaching the Object/target of the claim (e.g.:
>> RO-attributes, Requestor-Attributes, Orchestrator-Attributes) also helps
>> identify the source of those attributes (GS, RS, Client):
>>
>> Best regards.
>> /Francis
>>
>> On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt  wrote:
>>
>>> It is not clear to me what it matters if a Claim comes from an RS, or
>>> from the GS, so I don't see a need to differentiate them.
>>>
>>> I would include verifiable credentials and user-bound keys as Claims.
>>>
>>> All the payment processing information I have seen has been in RAR. Whe=
n
>>> would the Client get payment processing directly from the GS?
>>>
>>> What is your example for distributed networks storage locations? If wha=
t
>>> is stored is a statement about the user, then I would consider that a C=
laim
>>> as well.
>>>
>>> We disagree on how to map OIDC to GNAP.  The direct data is a claims
>>> request, the data coming indirectly is an access token request.
>>>
>>>
>>>
>>> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer  wrote:
>>>
>>>> Since we=E2=80=99re already talking about returning claims as direct d=
ata as
>>>> well as a part of the resource API being protected, so we already need=
 a
>>>> way to differentiate the two kinds of items. Just calling it =E2=80=9C=
claims=E2=80=9D
>>>> doesn=E2=80=99t help, because as you=E2=80=99ve pointed out they could=
 show up in both
>>>> places. So yes, defining that difference is something we should worry =
about
>>>> now, even if the core protocol only uses it for claims.
>>>>
>>>> The two forms of direct data that XYZ returns are subject identifiers
>>>> (a subset of identity claims) and assertions =E2=80=94 the latter bein=
g a container
>>>> not just for identity claims but also authentication information and o=
ther
>>>> elements. Assertions are not claims themselves.
>>>>
>>>> Other use cases that have been brought up include verifiable
>>>> credentials and proofs, user-bound keys, payment processing informatio=
n,
>>>> and distributed network storage locations. I=E2=80=99m sure there are =
a lot more.
>>>> To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D but not =
subsets of =E2=80=9Cclaims=E2=80=9D.
>>>> GNAP shouldn=E2=80=99t be defining what all of these look like, but it=
 should
>>>> define a way to talk about them.
>>>>
>>>> I think different top-level request objects are better suited for
>>>> different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=
=E2=80=9D request,
>>>> which allows targeting of its claims information into different return
>>>> buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D request at=
 the very least. I
>>>> don=E2=80=99t think GNAP should define how to do this specific combina=
tion, that
>>>> should be for OIDF to debate and apply. The same with a DID service ba=
sed
>>>> query, or Presentation Exchange [1], or anything else that people want=
 to
>>>> come up with.
>>>>
>>>> In my view, GNAP should define query structures for two things: rights
>>>> that get tied to an access token and data that comes back directly to =
the
>>>> client. For the latter, I think we can do some very limited and very u=
seful
>>>> specific items, which is what I=E2=80=99ve put into XYZ.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> [1] https://identity.foundation/presentation-exchange/
>>>>
>>>> On Jul 24, 2020, at 3:58 PM, Dick Hardt  wrote:
>>>>
>>>> I agree we want GNAP to be a strong foundation.
>>>>
>>>> Do you have an example of other "direct data"? If so, do you expect it
>>>> to be defined in the core protocol?
>>>>
>>>> I would expect an extension for other "direct data" to define top leve=
l
>>>> objects, and an appropriate definition for that "direct data".
>>>>
>>>> My "do we need to worry about it now" comment was on creating a generi=
c
>>>> term for "direct data". Unless we are solving those now, we can let fu=
rther
>>>> work define that "direct data" explicitly.
>>>>
>>>>
>>>>
>>>>
>>>> =E1=90=A7
>>>>
>>>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer  wrote=
:
>>>>
>>>>> Yes, I do think we need to worry about it to the extent that we are
>>>>> not creating something that is over-fit to a limited set of use cases=
.
>>>>>
>>>>> GNAP should be a foundation that many amazing new things can be built
>>>>> on top of.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt  wrote:
>>>>>
>>>>> Justin, thanks for clarifying.
>>>>>
>>>>> What are some examples of other "direct data" that the GS may return?
>>>>> If it is not in core GNAP, do we need to worry about now? We can then=
 give
>>>>> the direct data from the GS that is not a claim, an appropriate name =
in
>>>>> that document.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer 
>>>>> wrote:
>>>>>
>>>>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m s=
aying. I agree
>>>>>> that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. =
But the AS could return
>>>>>> other data directly to the client that isn=E2=80=99t about the user.=
 Those aren=E2=80=99t
>>>>>> =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=
=80=9Cclaims=E2=80=9D can come back
>>>>>> from places other than directly, then we shouldn=E2=80=99t call ever=
ything that
>>>>>> comes back a =E2=80=9Cclaim=E2=80=9D.
>>>>>>
>>>>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean wh=
at it already means and
>>>>>> come up with a new word to mean =E2=80=9Cthings that come back direc=
tly from the
>>>>>> AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s=
 more complete definitions, but
>>>>>> to simplify:
>>>>>>
>>>>>> Claims:
>>>>>> - information about the user
>>>>>> - can come back directly from the AS
>>>>>> - can come back in a resource from the RS
>>>>>>
>>>>>> Resource:
>>>>>> - Returned from an RS
>>>>>> - Protected by access token
>>>>>> - Could contain claims about the user
>>>>>>
>>>>>> Direct data (or some better name):
>>>>>> - Returned directly from AS
>>>>>> - Could contain claims about the user
>>>>>>
>>>>>> I think the problem is that some people are using =E2=80=9Cclaims=E2=
=80=9D to mean #1
>>>>>> and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=
=99s important to
>>>>>> remember, when talking about OIDC, that an IdP in OIDC combines an A=
S and
>>>>>> an RS into one entity for identity information. There can be other R=
S=E2=80=99s as
>>>>>> well, and there usually are in the wild, but the one defined by OIDC=
 is the
>>>>>> UserInfo Endpoint. The fact that it returns user data doesn=E2=80=99=
t make it any
>>>>>> less of an RS.
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>> * In the wider context of things like the information claims inside =
a
>>>>>> JWT, the claims could be about literally anything, but that=E2=80=99=
s not what
>>>>>> we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s =
being used.
>>>>>>
>>>>>>
>>>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt  wrote=
:
>>>>>>
>>>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from
>>>>>> the OP in an ID Token, or the Client can obtain Claims using an acce=
ss
>>>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>>>
>>>>>> The Claims are about the User (not a RO).
>>>>>>
>>>>>> In XAuth, I'm proposing the Client may obtain bare claims from the G=
S
>>>>>> directly in addition to the mechanisms in ODIC.
>>>>>>
>>>>>> So I don't think we are changing the definition of Claim from how it
>>>>>> has been used in OIDC, and I fail to see any reason to NOT use Claim=
.
>>>>>>
>>>>>> Justin: you allude to Claims being about a party other than the User=
.
>>>>>> Would you provide an example?
>>>>>>
>>>>>> /Dick
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>> UserInfo Endpoint
>>>>>> Protected Resource that, when presented with an Access Token by the
>>>>>> Client, returns authorized information about the End-User represente=
d by
>>>>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUS=
T use
>>>>>> the https scheme and MAY contain port, path, and query parameter com=
ponents.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> =E1=90=A7
>>>>>>
>>>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer 
>>>>>> wrote:
>>>>>>
>>>>>>> I want to focus on one aspect here:
>>>>>>>
>>>>>>>
>>>>>>>> A Claim is a well understood term in the field. We should use it.
>>>>>>>> It is still a Claim if it comes directly from the GS or from an RS=
.
>>>>>>>>
>>>>>>> I do not understand why a Resource release by an RS shall be h to a=
s
>>>>>>> a claim, even if the content of the Resource is an assertion. It wi=
ll lead
>>>>>>> to confusion. If we limit claims to information GS releases into To=
ken,
>>>>>>> User Info, and other objects it returns, this will help separate
>>>>>>> responsibilities between GS and RS. As soon as RS services and info=
rmation,
>>>>>>> this is called a Resource, no matter the nature of the content of t=
hat
>>>>>>> information.
>>>>>>>
>>>>>>>
>>>>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Ccl=
aim=E2=80=9D in the way
>>>>>>> that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could c=
ome back through an RS =E2=80=94 but in
>>>>>>> the context of GNAP, that makes it a resource. So we need a differe=
nt word
>>>>>>> for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s
>>>>>>> going to be about the user, and that=E2=80=99s what we=E2=80=99re g=
oing to focus on here,
>>>>>>> but since you can also get information about the user from a resour=
ce we
>>>>>>> can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this =
has been at the heart of a lot
>>>>>>> of confusion in recent threads, as well as confusion about the scop=
e of the
>>>>>>> inclusion of identity in the GNAP protocol.
>>>>>>>
>>>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already d=
oes, and let=E2=80=99s find a way
>>>>>>> to differentiate between when an item, claim or otherwise,  comes a=
s part
>>>>>>> of a resource and when it comes back directly. This is an important
>>>>>>> differentiating feature for GNAP.
>>>>>>>
>>>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in lov=
e with:
>>>>>>>
>>>>>>>  - direct data
>>>>>>>  - properties
>>>>>>>  - details
>>>>>>>  - statements
>>>>>>>
>>>>>>> The important thing here is that it=E2=80=99s not necessarily :abou=
t: the
>>>>>>> RO, and that it is :not: in a resource.
>>>>>>>
>>>>>>> Any other thoughts?
>>>>>>>
>>>>>>>  =E2=80=94 Justin
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>> --
>> 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/

--000000000000acc09905ab627912
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




-- 
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/


--000000000000acc09905ab627912--


From nobody Sun Jul 26 18:56: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 A86BF3A15DC for ; Sun, 26 Jul 2020 18:56:01 -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=unavailable 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 n68qLqY_wPI8 for ; Sun, 26 Jul 2020 18:55:57 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450: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 32B693A07C5 for ; Sun, 26 Jul 2020 18:55:57 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id x5so12096190wmi.2 for ; Sun, 26 Jul 2020 18:55: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=pSs60gbpD7sN7TVin2M9VXOMc0yXAwO0ugGajuQS9v0=; b=ABbKoCRG+V+/Z8my/PqhBc7NeP4Yl94p/YPoiyNLH+UuHSf9mhO+exLofxECaySAcP ZHE/h0zBuzxnTiS4savrsNa99zDDXd/BK//9zQ96PbLNQnrpDbp3UXFRN5K2qm6ANQL2 NnB+lEIqr5IqvdwP/8qnz4gFizY9rRbakeZyg=
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=pSs60gbpD7sN7TVin2M9VXOMc0yXAwO0ugGajuQS9v0=; b=nZtLanBw+/R/TlqPHLpKqscZxKsDwgrMeoKctUVdRg4igAgsJ35UwzzqmzmfltZumo IriX2XQcZzUEreDPlnh7s0pbniOFxVRuopzeo2Ln1P8eawevy7SbrL3wjK2q1z+VWsul f5CxEUedXTuaHgXkktRZJt0pPV4Bm3j0CSTzzYePpFIskgnzDOOUIEk094zjSYmqmlrs +EvxOb9MH/13N25wZHLL5T7eHUuv/PrreWG+JjL8Q8NG21cvA3dTfXKfcRYy0tVXnmFQ nCf1H+dyyUSPEUK87HgXeE2H1FLa2Q6wnIt4LOxqiK4SKekmH0DS1U4Ig50qqpt2Z7hG P1XQ==
X-Gm-Message-State: AOAM532Wp0E9hPx25PUpUI8jeM2zom2IV8TGBs/ihyF2BmLJvITkm4iP 2kG+NGR+iYBSO5JBzKS80N/jZd1nxva6bUs+O0oIwA==
X-Google-Smtp-Source: ABdhPJxfHl8tNP5VKzibb0TXXZOu1SuMd5btZ+23LzfkBb0DdFDMG67tquKTbb2xrM9+821FtQIkPt7508un4lC9/w4=
X-Received: by 2002:a1c:2bc1:: with SMTP id r184mr19302994wmr.133.1595814955397;  Sun, 26 Jul 2020 18:55:55 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>    <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>      
In-Reply-To: 
From: Francis Pouatcha 
Date: Sun, 26 Jul 2020 21:55:44 -0400
Message-ID: 
To: Tom Jones 
Cc: Dick Hardt , Justin Richer ,  Mike Jones ,  Fabien Imbault , Mike Varley ,  "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000008b479a05ab629f28"
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 27 Jul 2020 01:56:02 -0000

--0000000000008b479a05ab629f28
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1 Tom's input.

This discussion about Key Handle vs. client id & handle wouldn't exist if
GNAP had the notion of TF defining how the GS/RS/Clients identify
and authenticate each other.

A simple TF can describe the standard case (happy path) without having to
foresee all eventualities.

A GNAP profile will also be simple as it will keep out everything else
(e.g. US Healthcare, PSD2).

BR
/Francis


On Sun, Jul 26, 2020 at 9:43 PM Tom Jones 
wrote:

> You should consider a trust framework to be first of all a set of
> qualifying criteria above and beyond the literal meaning of the standard.
> Ours is focused on US Healthcare, but lots of others make sense. The
> international R&E org is the basis for the openid federation doc.
> Secondarily the trust framework could vet members so that they made
> affirmative statements about their compliance.
> Tertiary they tf could mandate testing of the members. That is the case
> for US Healthcare.
> the tf could be blank for sites with no moral scruples whatsoever. (the
> majority of sites i am sure.)
> Peace ..tom
>
>
> On Sun, Jul 26, 2020 at 6:18 PM Dick Hardt  wrote:
>
>> Hi Francis
>>
>> While a Trust Framework concept looks to make sense for PSD2 use cases,
>> there are lots of other use cases.
>>
>> How would you see existing OAuth 2 and OIDC concepts fitting into a Trus=
t
>> Framework concept?
>>
>> /Dick
>>
>> =E1=90=A7
>>
>> On Sat, Jul 25, 2020 at 8:41 PM Francis Pouatcha  wrote:
>>
>>> I just read through some work being done by Tom at the FIRE (Federated
>>> Identifiers for Resilient Ecosystems) working group and it confirms my
>>> intention of suggesting the consideration of a "Trust Framework" as a
>>> context defining how to handle the client_id.
>>>
>>> The procedure the GS applies to trust a client is derived from the
>>> "Trust Framework" that governs the environment in which GS and Client a=
re
>>> operating.
>>>
>>> In the European PSD2 ecosystem, National Country Authorities (a.k.a
>>> Market Authorities or Regulators):
>>> - delegate the production of client certificates to Trust Service
>>> Providers (TSPs). TSPs are known certification authorities (CAs) in the
>>> corresponding countries.
>>> - maintain a register of Certified Third Party Providers (TPPs) at the
>>> European Banking Association (EBA), where the validity of the TPP licen=
se
>>> can be verified, in addition to the client certificate.
>>>
>>> Designing an authorization framework around the PSD2 ecosystem, there i=
s
>>> no need to maintain any static or dynamic client_id. Each request is
>>> associated with an SSL client certificate called QWAC (Qualified Websit=
e
>>> Assertion Certificate).
>>> - This certificate can be verified as the GS maintains a list of all
>>> known TSP's CA authorized to release PSD2 client certificates.
>>> - This certificate also contains the list of roles assigned to the TPP
>>> by the regulator PSP_AS (bank), PSP_PI (payment initiation), PSP_AI
>>> (account information), PSP_IC (card) sufficient for the client access
>>> control in the PSD2 trust framework.
>>> - This certificate contains a permanent "Competent Authority" that
>>> uniquely identifies the NCA issuing the TPP license.
>>> - This certificate contains a permanent "Authorization Number" that is
>>> unique in the context of the NCA.
>>> - so AuthorizationNumber@CompetentAuthority is globally unique in the
>>> context of the PSD2 trust framework.
>>>
>>> Given these facts, GS implementing PSD2 do not need to register clients=
.
>>> - Each request of the client to the GS can be mTLS secured using the
>>> QWAC.
>>> - GS can extract all information needed to perform authorization from
>>> that certificate.
>>>
>>> This use case does not need an extra client_id at the protocol level.
>>>
>>> This is:
>>> - based on the experience we are making implementing PSD2,
>>> - based on my reading Tom's FIRE use case in the health sector on the
>>> sharing of Patient Health Information (PHI) among health care providers=
,
>>>
>>> I suggest GNAP introduces the notion of "Trust framework" that governs
>>> the environment in which RS, GS and Client interoperate. We can then
>>> delegate the decision on specifying the necessity and functions of a
>>> client_id to the trust framework.
>>>
>>>
>>> On Thu, Jul 16, 2020 at 7:58 PM Tom Jones 
>>> wrote:
>>>
>>>> I have been working on different level s of identifier, but from the
>>>> mobile app perspective. That's the hardest case as you need to boot st=
rap
>>>> trust. I suspect that in the web site case you will need these levels.
>>>> Transport, application, real world.
>>>>
>>>> If anyone wants to work on these, let me know and I'll get you the
>>>> links in Kantara.
>>>>
>>>> thx ..Tom (mobile)
>>>>
>>>> On Thu, Jul 16, 2020, 2:47 PM Justin Richer  wrote:
>>>>
>>>>> For all of these, I still say we should have different levels of
>>>>> identifier. A =E2=80=9Cclient ID=E2=80=9D should identify the client,=
 and not be used as a
>>>>> stand-in for other things.
>>>>>
>>>>> Off the top of my head I think we might want to have identifiers,
>>>>> assertions, proofs, and other trust-binding items for:
>>>>>
>>>>>  - Organizations
>>>>>  - Devices
>>>>>  - Software applications
>>>>>  - Software instances
>>>>>  - Software versions
>>>>>
>>>>> So if we=E2=80=99re going to talk about identifying these aspects, we=
 should
>>>>> tackle each as its own thing and not mush it all into =E2=80=9Cclient=
_id=E2=80=9D. That
>>>>> way, hopefully, GNAP can have a much better idea what a =E2=80=9Cclie=
nt=E2=80=9D is than
>>>>> OAuth 2 currently does.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> On Jul 16, 2020, at 4:34 PM, Dick Hardt  wrote:
>>>>>
>>>>> One client identifier was a simplistic example. Org A may have
>>>>> numerous clients, perhaps in different teams, perhaps in different
>>>>> services, each with their own policy at Org B.
>>>>>
>>>>> When one of the Org A clients makes a call to the Org B AS, it needs
>>>>> to identify itself with some identifier so that Org B knows which pol=
icy to
>>>>> enforce. Why not the Client ID?
>>>>>
>>>>> I also agree with your comments that other client identification
>>>>> situations are different, and forcing the same identification model o=
n them
>>>>> does not make sense, but I fail to see the value throwing out a conce=
pt
>>>>> (client_id) that has worked well for the use cases it was designed fo=
r.
>>>>>
>>>>>
>>>>> =E1=90=A7
>>>>>
>>>>> On Thu, Jul 16, 2020 at 1:08 PM Justin Richer  wrote=
:
>>>>>
>>>>>> I think that the cross-organizational trust model is an interesting
>>>>>> one, and in fact it=E2=80=99s one of the things that=E2=80=99s pushe=
d me away from a
>>>>>> client_id. In the scenario that you describe, =E2=80=9Cclient_id=E2=
=80=9D is used to
>>>>>> represent something that it was never meant to represent: the organi=
zation
>>>>>> running the software, not the software itself. It isn=E2=80=99t a cl=
ient_id, and
>>>>>> while in OAuth 2 the client_id could be co-opted to carry that infor=
mation,
>>>>>> it=E2=80=99s considered bad practice to share client_ids between mul=
tiple pieces of
>>>>>> software.
>>>>>>
>>>>>> I would argue that to address this use case properly, there should b=
e
>>>>>> another level of identifier to bridge that trust that the software c=
an
>>>>>> present, showing that it is a part of Organization A, and not Organi=
zation
>>>>>> C. This isn=E2=80=99t a client identifier, it=E2=80=99s an organizat=
ion identifier, and it
>>>>>> should be separate. You might want to identify both the client insta=
nce as
>>>>>> well as the organization it=E2=80=99s a part of, for example. This i=
s part of the
>>>>>> motivation behind putting =E2=80=9Corganizational data=E2=80=9D with=
in scope for the client
>>>>>> to send to the AS, after all.
>>>>>>
>>>>>> Therefore, I strongly disagree that this scenario =E2=80=9Crequires=
=E2=80=9D a
>>>>>> client_id to be solved. In fact, I think that solving this scenario =
with a
>>>>>> client_id is an anti-pattern that stems from OAuth 2=E2=80=99s over-=
reliance on
>>>>>> client_id as a persistent identifier within the protocol, and we can=
 and
>>>>>> should do better with GNAP. It=E2=80=99s very similar to Mike Jones=
=E2=80=99s referenced
>>>>>> federation document, where the client_id is co-opted as a means of
>>>>>> bootstrapping client registration and discovery, or in the Solid
>>>>>> Authentication specification which stuffs a WebID into the client_id=
 field.
>>>>>>
>>>>>> With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools that =
we had to solve
>>>>>> our problems, and come up with some very clever solutions. What I=E2=
=80=99m trying
>>>>>> to argue to this community is that we are in a position to create ou=
r own,
>>>>>> better tools.
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>> On Jul 16, 2020, at 2:00 PM, Dick Hardt  wrote=
:
>>>>>>
>>>>>> Justin,
>>>>>>
>>>>>> While I agree that the assumption in OAuth 2 that all Clients have a
>>>>>> client_id is problematic, the requirement for a client_id in many us=
e cases
>>>>>> is still there, and it does not represent a piece of software, but a
>>>>>> relationship between parties.
>>>>>>
>>>>>> Organization A writes client software that calls resources managed b=
y
>>>>>> the AS in Organization B. The client_id represents Organization A to
>>>>>> Organization B. Organization B does not care what software Organizat=
ion A
>>>>>> is running, and there may be numerous pieces of software at Organiza=
tion A
>>>>>> that use the same client_id. The access granted by Organization B to
>>>>>> Organization A needs to be able to be different than the rights gran=
ted to
>>>>>> Organization C.
>>>>>>
>>>>>> I agree that we don't want to force all clients to have a client_id,
>>>>>> and as discussed, there are a variety of inputs for an AS to accept =
calls
>>>>>> from a piece of software, and often, that will be a particular
>>>>>> *instance* of the software, but we also don't want to force clients
>>>>>> to all be treated the same, because they are not..
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer 
>>>>>> wrote:
>>>>>>
>>>>>>> Exactly =E2=80=94 when we start to look at it as managing the lifec=
ycle of a
>>>>>>> piece of software, instead of a registration at the AS, we can star=
t
>>>>>>> thinking in different terms what =E2=80=9Ctrusting=E2=80=9D the cli=
ent means in the context
>>>>>>> of what the client is doing. That trust could come from some kind o=
f signed
>>>>>>> attestation about the software (like the OAuth 2 DynReg software
>>>>>>> statement), or it could come from some externally fetchable item (l=
ike a
>>>>>>> Solid WebID, a DID, or the OIDC Federation extension), or it could =
come
>>>>>>> from someone sitting at a console and typing in information and get=
ting
>>>>>>> back an identifier. And none of these need to pretend to be a globa=
l
>>>>>>> =E2=80=9Cclient id=E2=80=9D for it to work. The world of clients is=
 much more diverse than
>>>>>>> OAuth 2 likes to admit, and we see that with trying to nail down a
>>>>>>> =E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=
=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautomatic=
=E2=80=9D vs.
>>>>>>> =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of other thing=
s.
>>>>>>>
>>>>>>> OAuth 2 only needs client IDs because the front channel needs a way
>>>>>>> to pass client identifiers when the client can=E2=80=99t authentica=
te itself
>>>>>>> directly. We tried to get rid of this restriction with PAR and JAR
>>>>>>> together, but there turned out to be corner cases in OAuth 2=E2=80=
=99s world that
>>>>>>> still needed client_id, and implementations assumed it would be the=
re
>>>>>>> anyway.
>>>>>>>
>>>>>>> In GNAP, we can avoid that problem from the beginning by looking at
>>>>>>> the model differently and understanding where we=E2=80=99re coming =
from, and why.
>>>>>>>
>>>>>>>  =E2=80=94 Justin
>>>>>>>
>>>>>>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault <
>>>>>>> fabien.imbault@gmail.com> wrote:
>>>>>>>
>>>>>>> +1 on that.
>>>>>>>
>>>>>>> We can then see it more as life cycle management of the client than
>>>>>>> registration per say, and this comes with many benefits compared to=
 the
>>>>>>> current client_id.
>>>>>>>
>>>>>>> Fabien
>>>>>>>
>>>>>>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I not only agree with Mike Jones that =E2=80=9Cautomatic registrat=
ion=E2=80=9D
>>>>>>>> should be part of the process, but I would argue that that kind of=
 model
>>>>>>>> should be a default mode of operation. If you have an identifier t=
hat you
>>>>>>>> can send to short-circuit that, great! But we should focus on havi=
ng the
>>>>>>>> capability of inlining a lot of this information wherever possible=
. This is
>>>>>>>> already the direction that the input proposals are heading.
>>>>>>>>
>>>>>>>> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope=
 for the protocol
>>>>>>>> in general, and since both XYZ and Xauth have mechanisms that allo=
w the
>>>>>>>> client to present a key and get back an identifier that it can use=
 in the
>>>>>>>> future we have something equivalent.
>>>>>>>>
>>>>>>>> But I think there=E2=80=99s a little more to it than that: Ultimat=
ely, I
>>>>>>>> think we should question thinking in terms of =E2=80=9Cregistratio=
n=E2=80=9D, a model which
>>>>>>>> has hampered the OAuth 2 model in a lot of use cases. For example,=
 the
>>>>>>>> federation draft Mike Jones references below hacks the =E2=80=9Ccl=
ient_id=E2=80=9D
>>>>>>>> parameter and makes it point to a document that the AS has to fetc=
h. This
>>>>>>>> construct is done for two reasons: (1) Oauth requires a =E2=80=9Cc=
lient_id=E2=80=9D in the
>>>>>>>> request and (2) it=E2=80=99s difficult to pass information by valu=
e to the AS due
>>>>>>>> to front-channel restrictions. Since we=E2=80=99re defining a new =
protocol, we
>>>>>>>> don=E2=80=99t need to hack that functionality into a =E2=80=9Cclie=
nt ID=E2=80=9D or equivalent and
>>>>>>>> instead we can pass that information directly in the protocol. If =
we don=E2=80=99t
>>>>>>>> assume that the client *has* to have a client ID equivalent, but i=
t *can*
>>>>>>>> have one in a set of defined circumstances, then I think we are in=
 a much
>>>>>>>> better spot. This is the reasoning for XYZ=E2=80=99s model of havi=
ng clients
>>>>>>>> identified by the key, and that key can potentially be passed by a
>>>>>>>> reference identifier.
>>>>>>>>
>>>>>>>> I think all of the use cases that Mike Varley presents below are
>>>>>>>> all valid directions, with the caveat that we shouldn=E2=80=99t as=
sume a client
>>>>>>>> should be presenting an ID at all steps. Mechanisms like software
>>>>>>>> statements should be presentable apart from a client ID, as should
>>>>>>>> on-device keys. We=E2=80=99re probably going to want extensions fo=
r device posture
>>>>>>>> and other forms of attestation as well.
>>>>>>>>
>>>>>>>> This is one of the domains that I think we can clearly surpass
>>>>>>>> OAuth 2=E2=80=99s flexibility and capabilities if we are willing t=
o look past OAuth
>>>>>>>> 2=E2=80=99s assumptions of what=E2=80=99s needed inline in the pro=
tocol.
>>>>>>>>
>>>>>>>>  =E2=80=94 Justin
>>>>>>>>
>>>>>>>> On Jul 14, 2020, at 1:54 PM, Mike Varley 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Is client registration in scope for the protocol?
>>>>>>>>
>>>>>>>> A generic way of handling clients (via ID or Handle or Key or
>>>>>>>> whatever) is to have processing rule on the AS such as =E2=80=9Cif=
 the AS
>>>>>>>> recognizes the client ID (and authentication of that client ID) th=
en it may
>>>>>>>> process the request on behalf of that client. If the AS does not r=
ecognize
>>>>>>>> the client ID, it must treat this as a new client registration and=
 evaluate
>>>>>>>> any authorization evidence the client provides before enabling the=
 client
>>>>>>>> and mapping policies to that client=E2=80=9D (this means dynamic o=
r automatic
>>>>>>>> clients need to provide additional assertions / software statement=
s
>>>>>>>> whatever to register their ID.
>>>>>>>>
>>>>>>>> Something like this allows for very flexible systems:
>>>>>>>> System A can be unknown to the AS but can dynamically registered
>>>>>>>> each time with an appropriate software statement
>>>>>>>> System B can have a fairly stable client ID at the AS, but rotate
>>>>>>>> that ID every month through automatic registration (with an assert=
ion it
>>>>>>>> got from the AS during a pre-registration for example)
>>>>>>>> System C can pre-register with the AS for a client ID because it
>>>>>>>> doesn=E2=80=99t deal with software statements etc=E2=80=A6
>>>>>>>> =E2=80=A6
>>>>>>>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never storin=
g client IDs
>>>>>>>> because it will always just rely on the software statements.
>>>>>>>>
>>>>>>>> I think a client registration protocol that allows these scenarios
>>>>>>>> would be very useful in GNAP, but hopefully avoiding having to def=
ine what
>>>>>>>> =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenari=
o.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> MV
>>>>>>>>
>>>>>>>> *From: *Txauth  on behalf of Mike Jones <
>>>>>>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
>>>>>>>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>>>>>>>> *To: *Dick Hardt , "txauth@ietf.org" <
>>>>>>>> txauth@ietf.org>, Justin Richer 
>>>>>>>> *Subject: *Re: [Txauth] Key handle vs client id & handle
>>>>>>>>
>>>>>>>> I agree that there are significant differences between statically
>>>>>>>> and dynamically registered clients and that=E2=80=99s appropriate =
to be able to
>>>>>>>> syntactically differentiate between them at runtime.  For one thin=
g, the
>>>>>>>> resource requirements at the authorization server can be very diff=
erent.
>>>>>>>>
>>>>>>>> We should also be thinking about how to include what the OpenID
>>>>>>>> Connect Federation spec
>>>>>>>> https://openid.net/specs/openid-connect-federation-1_0.html calls
>>>>>>>> =E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client en=
code a registration
>>>>>>>> request reference in the client ID, so no static or dynamic regist=
ration
>>>>>>>> even occurs.  See
>>>>>>>> https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc=
.section.9.1
>>>>>>>> 
>>>>>>>> .
>>>>>>>>
>>>>>>>>                                                        -- Mike
>>>>>>>>
>>>>>>>> *From:* Dick Hardt 
>>>>>>>> *Sent:* Friday, July 10, 2020 1:17 PM
>>>>>>>> *To:* txauth@ietf.org; Justin Richer ; Mike Jones
>>>>>>>> 
>>>>>>>> *Subject:* Key handle vs client id & handle
>>>>>>>>
>>>>>>>> + Mike as he had interest in this topic
>>>>>>>>
>>>>>>>> My understanding is that an existing OAuth 2 client would use thei=
r
>>>>>>>> current client id as their key handle, and a dynamic client (one t=
hat was
>>>>>>>> not pre-registered) would be given a key handle by the AS.
>>>>>>>>
>>>>>>>> There are potentially some significant differences between a
>>>>>>>> registered client, and a dynamic client to an AS.
>>>>>>>>
>>>>>>>> The AS is likely to know the identity of a registered client, and
>>>>>>>> have different policies between the two types of clients. For exam=
ple, a
>>>>>>>> registered client may have access to a 'write" scope, while a dyna=
mic
>>>>>>>> client does not.
>>>>>>>>
>>>>>>>> The AS may have 100s or 1000s of registered clients, but a dynamic
>>>>>>>> client may have 10Ms or 100Ms of instances, which may dictate
>>>>>>>> separate storage services. Additionally, internal to the AS, which=
 systems
>>>>>>>> can write to the registered client store is going to be different =
than the
>>>>>>>> dynamic client store.
>>>>>>>>
>>>>>>>> In XYZ, subsequent calls to the AS, both registered clients and
>>>>>>>> dynamic clients pass a key handle, so there is no easy way to diff=
erentiate
>>>>>>>> between the two.
>>>>>>>>
>>>>>>>> While the AS could embed semantics in the key handle identifier to
>>>>>>>> indicate which identifiers are pre-registered vs dynamic, there ar=
e many
>>>>>>>> cases where the AS does need to know the difference, so making the
>>>>>>>> difference a feature of GNAP seems like a better path.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This email and any attachments are for the sole use of the intende=
d
>>>>>>>> recipients and may be privileged, confidential or otherwise exempt=
 from
>>>>>>>> disclosure under law. Any distribution, printing or other use by a=
nyone
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Txauth mailing 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/

--0000000000008b479a05ab629f28
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


+1 Tom's input.

This discussion=
 about Key Handle vs. client id & handle wouldn't exist if GNAP had=
 the notion of TF defining how the GS/RS/Clients identify and=C2=A0authenti=
cate=C2=A0each other.

A simple TF can=C2=A0describ=
e the standard case (happy path) without=C2=A0having to foresee all eventua=
lities.

A GNAP profile will also be simple as it w=
ill keep out everything=C2=A0else (e.g. US Healthcare, PSD2).
BR=C2=A0
/Francis


On Sun, Jul 26,=
 2020 at 9:43 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
You=C2=A0should consider =
a trust=C2=A0framework to be first of all a set of qualifying=C2=A0criteria=
 above and beyond the literal meaning of the standard.
Ours is focused =
on US Healthcare, but lots of others make sense. The international R&E =
org is the basis for the openid federation doc.
Secondarily the t=
rust framework could vet members so that they made affirmative statements a=
bout their compliance.
Tertiary they tf could mandate testing of =
the members. That is the case for US Healthcare.
the tf could be =
blank for sites with no moral scruples whatsoever. (the majority of sites i=
 am sure.)
Pea=
ce ..tom


On Sun, Jul 26, 2020 at 6:18 PM D=
ick Hardt <dic=
k.hardt@gmail.com> wrote:
Hi Francis

While a Tru=
st Framework concept looks to make sense for PSD2 use cases, there are lots=
 of other use cases.

How would you see existing OAuth 2 =
and OIDC concepts fitting into a Trust Framework concept?
<=
br>
/Dick

3D""=E1=90=A7

On Sat, Jul 25, 2020 at 8:41 PM Francis Pouatcha <fpo@adorsys.de> wrote:
I just read =
through some work being done by Tom at the FIRE (Federated Identifiers for =
Resilient Ecosystems) working=C2=A0group and it confirms my intention of su=
ggesting the consideration of a "Trust Framework" as a context de=
fining how to handle the client_id.

The procedure the GS=
 applies to trust a client is derived from the "Trust Framework" =
that governs the environment in which GS and Client are operating.
=

In the European PSD2 ecosystem, National Country Autho=
rities (a.k.a Market Authorities or Regulators):
- delegate the p=
roduction of client certificates to Trust Service Providers (TSPs). TSPs ar=
e known certification authorities (CAs) in the corresponding countries.
- maintain a register of Certified Third Party Providers (TPPs) at t=
he European Banking Association (EBA), where the validity of the TPP licens=
e can be verified,=C2=A0in addition=C2=A0to the client certificate.

Designing an authorization framework around=C2=A0the PSD2=
 ecosystem, there is no need to maintain any static or dynamic client_id. E=
ach request is associated with an SSL client certificate called QWAC (Quali=
fied Website Assertion Certificate).=C2=A0
- This certificate can=
 be verified as the GS maintains a list of all known TSP's CA authorize=
d to release PSD2 client certificates.
- This certificate also co=
ntains the list of roles assigned to the TPP by the regulator=C2=A0PSP_AS (=
bank), PSP_PI (payment initiation), PSP_AI (account information), PSP_IC (c=
ard) sufficient for the client access control in the PSD2 trust framework.<=
/div>
- This certificate contains a permanent "Competent Authority=
" that uniquely=C2=A0identifies the NCA issuing the TPP license.
=

- This certificate contains a permanent "Authorization Number&quo=
t; that is unique in the context of the NCA.
- so=C2=A0Authorizat=
ionNumber@CompetentAuthority is globally=C2=A0unique in the context of the =
PSD2 trust framework.

Given these facts, GS implem=
enting PSD2 do not need to register clients.=C2=A0
- Each request=
 of the client to the GS can be mTLS secured using the QWAC.
- GS=
 can extract all information needed to perform=C2=A0authorization from that=
 certificate.

This use case does not need an extra=
 client_id at the protocol level.=C2=A0

This is:
- based on the experience we are making implementing PSD2,
- based on my reading Tom's FIRE use case in the health sector on th=
e sharing of Patient Health Information (PHI) among health care providers,<=
/div>

I suggest GNAP introduces the notion of "Trus=
t framework" that governs the environment in which RS, GS and Client i=
nteroperate. We can then delegate the decision on specifying the necessity =
and functions of a client_id to the trust framework.


On=
 Thu, Jul 16, 2020 at 7:58 PM Tom Jones <thomasclinganjones@gmail.com> wro=
te:
I have been working on different level s of identifier, but from the =
mobile app perspective. That's the hardest case as you need to boot str=
ap trust. I suspect that in the web site case you will need these levels. T=
ransport, application, real world.

If anyone wants to work on these, let me know and I'll get you the=
 links in Kantara.

thx ..Tom (mobile)
<=
/div>
O=
n Thu, Jul 16, 2020, 2:47 PM Justin Richer <jricher@mit.edu> wrote:
For all of these, I still say we should have d=
ifferent levels of identifier. A =E2=80=9Cclient ID=E2=80=9D should identif=
y the client, and not be used as a stand-in for other things.=C2=A0
Off the top of my head I think we might want to have identifier=
s, assertions, proofs, and other trust-binding items for:

=C2=A0- Organizations
=C2=A0- Devices
=C2=A0- S=
oftware applications
=C2=A0- Software instances
=C2=A0-=
 Software versions

So if we=E2=80=99re going to ta=
lk about identifying these aspects, we should tackle each as its own thing =
and not mush it all into =E2=80=9Cclient_id=E2=80=9D. That way, hopefully, =
GNAP can have a much better idea what a =E2=80=9Cclient=E2=80=9D is than OA=
uth 2 currently does.

=C2=A0=E2=80=94 Justin

On Jul 16, 2020, at 4:34 PM, Dick Har=
dt <dick.hardt@gmail.com> wrote:

One client identifier was a simplistic example. Org A may have numerous cl=
ients, perhaps in different teams, perhaps in different services, each with=
 their own policy at Org B.

When one of the Org A cl=
ients makes a call to the Org B AS, it needs to identify itself with some i=
dentifier so that Org B knows which policy to enforce. Why not the Client I=
D?

I also agree with your comments that other clie=
nt identification situations are different, and forcing the same identifica=
tion model on them does not make sense, but I fail=C2=A0to see the value th=
rowing out a concept (client_id) that has worked well for the use cases it =
was designed for.=C2=A0


3D""=E1=90=A7

On Thu, Jul 16, 2020 at 1:08 PM Justin Richer <jrich=
er@mit.edu> wrote:
I think that the cross-organizational trust model is an int=
eresting one, and in fact it=E2=80=99s one of the things that=E2=80=99s pus=
hed me away from a client_id. In the scenario that you describe, =E2=80=9Cc=
lient_id=E2=80=9D is used to represent something that it was never meant to=
 represent: the organization running the software, not the software itself.=
 It isn=E2=80=99t a client_id, and while in OAuth 2 the client_id could be =
co-opted to carry that information, it=E2=80=99s considered bad practice to=
 share client_ids between multiple pieces of software.=C2=A0

=

I would argue that to address this use case properly, there should be =
another level of identifier to bridge that trust that the software can pres=
ent, showing that it is a part of Organization A, and not Organization C. T=
his isn=E2=80=99t a client identifier, it=E2=80=99s an organization identif=
ier, and it should be separate. You might want to identify both the client =
instance as well as the organization it=E2=80=99s a part of, for example. T=
his is part of the motivation behind putting =E2=80=9Corganizational data=
=E2=80=9D within scope for the client to send to the AS, after all.

Therefore, I strongly disagree that this scenario =E2=80=
=9Crequires=E2=80=9D a client_id to be solved. In fact, I think that solvin=
g this scenario with a client_id is an anti-pattern that stems from OAuth 2=
=E2=80=99s over-reliance on client_id as a persistent identifier within the=
 protocol, and we can and should do better with GNAP. It=E2=80=99s very sim=
ilar to Mike Jones=E2=80=99s referenced federation document, where the clie=
nt_id is co-opted as a means of bootstrapping client registration and disco=
very, or in the Solid Authentication specification which stuffs a WebID int=
o the client_id field.

With OAuth 2=E2=80=99s ecos=
ystem, we=E2=80=99ve used the tools that we had to solve our problems, and =
come up with some very clever solutions. What I=E2=80=99m trying to argue t=
o this community is that we are in a position to create our own, better too=
ls.=C2=A0

=C2=A0=E2=80=94 Justin

On Jul 16, 2020, at 2:00 PM, Dick Hardt <dic=
k.hardt@gmail.com> wrote:

Justin,=C2=
=A0

While I agree that the assumption in OAuth 2 that al=
l Clients have a client_id is problematic, the requirement for a client_id =
in many use cases is still there, and it does not represent a piece of soft=
ware, but a relationship between parties.

Org=
anization A writes client software that calls resources managed by the AS i=
n Organization B. The client_id represents Organization A to Organization B=
. Organization B does not care what software Organization A is running, and=
 there may be numerous=C2=A0pieces of software at Organization A that use t=
he same client_id. The access granted by Organization B to Organization A n=
eeds to be able to be different than the rights granted to Organization C.=
=C2=A0

I agree that we don't want to for=
ce all clients to have a client_id, and as discussed, there are a variety o=
f inputs for an AS to accept calls from a piece of software, and often, tha=
t will be a particular instance of the software, but we also don'=
;t want to force clients to all be treated the same, because they are not..=
=C2=A0






On Thu, Jul 16, 2020 at 8:24 AM Justin Richer <jricher@mit.edu<=
/a>> wrote:
<=
div>Exactly =E2=80=94 when we start to look at it as managing the lifecycle=
 of a piece of software, instead of a registration at the AS, we can start =
thinking in different terms what =E2=80=9Ctrusting=E2=80=9D the client mean=
s in the context of what the client is doing. That trust could come from so=
me kind of signed attestation about the software (like the OAuth 2 DynReg s=
oftware statement), or it could come from some externally fetchable item (l=
ike a Solid WebID, a DID, or the OIDC Federation extension), or it could co=
me from someone sitting at a console and typing in information and getting =
back an identifier. And none of these need to pretend to be a global =E2=80=
=9Cclient id=E2=80=9D for it to work. The world of clients is much more div=
erse than OAuth 2 likes to admit, and we see that with trying to nail down =
a =E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=80=9C=
dynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautomatic=E2=80=
=9D vs. =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of other thing=
s.=C2=A0

OAuth 2 only needs client IDs because the =
front channel needs a way to pass client identifiers when the client can=E2=
=80=99t authenticate itself directly. We tried to get rid of this restricti=
on with PAR and JAR together, but there turned out to be corner cases in OA=
uth 2=E2=80=99s world that still needed client_id, and implementations assu=
med it would be there anyway.=C2=A0

In GNAP, we ca=
n avoid that problem from the beginning by looking at the model differently=
 and understanding where we=E2=80=99re coming from, and why.

=

=C2=A0=E2=80=94 Justin

+1 on that.

We can then see it more as life cycle management of the client than=
 registration per say, and this comes with many benefits compared to the cu=
rrent client_id.

Fabien

On Tue, Jul 14, 2020=
 at 9:32 PM Justin Richer <jricher@mit.edu> wrote:
I not only agree with Mike J=
ones that =E2=80=9Cautomatic registration=E2=80=9D should be part of the pr=
ocess, but I would argue that that kind of model should be a default mode o=
f operation. If you have an identifier that you can send to short-circuit t=
hat, great! But we should focus on having the capability of inlining a lot =
of this information wherever possible. This is already the direction that t=
he input proposals are heading.

So I kind-of agree that =
=E2=80=9Cregistration=E2=80=9D is in scope for the protocol in general, and=
 since both XYZ and Xauth have mechanisms that allow the client to present =
a key and get back an identifier that it can use in the future we have some=
thing equivalent.=C2=A0

But I think there=E2=80=99=
s a little more to it than that: Ultimately, I think we should question thi=
nking in terms of =E2=80=9Cregistration=E2=80=9D, a model which has hampere=
d the OAuth 2 model in a lot of use cases. For example, the federation draf=
t Mike Jones references below hacks the =E2=80=9Cclient_id=E2=80=9D paramet=
er and makes it point to a document that the AS has to fetch. This construc=
t is done for two reasons: (1) Oauth requires a =E2=80=9Cclient_id=E2=80=9D=
 in the request and (2) it=E2=80=99s difficult to pass information by value=
 to the AS due to front-channel restrictions. Since we=E2=80=99re defining =
a new protocol, we don=E2=80=99t need to hack that functionality into a =E2=
=80=9Cclient ID=E2=80=9D or equivalent and instead we can pass that informa=
tion directly in the protocol. If we don=E2=80=99t assume that the client *=
has* to have a client ID equivalent, but it *can* have one in a set of defi=
ned circumstances, then I think we are in a much better spot. This is the r=
easoning for XYZ=E2=80=99s model of having clients identified by the key, a=
nd that key can potentially be passed by a reference identifier.
=

I think all of the use cases that Mike Varley presents below=
 are all valid directions, with the caveat that we shouldn=E2=80=99t assume=
 a client should be presenting an ID at all steps. Mechanisms like software=
 statements should be presentable apart from a client ID, as should on-devi=
ce keys. We=E2=80=99re probably going to want extensions for device posture=
 and other forms of attestation as well.

This is o=
ne of the domains that I think we can clearly surpass OAuth 2=E2=80=99s fle=
xibility and capabilities if we are willing to look past OAuth 2=E2=80=99s =
assumptions of what=E2=80=99s needed inline in the protocol.=C2=A0

=C2=A0=E2=80=94 Justin

On Jul 14, 2020, at 1:54 PM, Mike Varley <mike.var=
ley@securekey.com> wrote:

Is client registration in scope for the protocol?
=C2=A0
A generic way of handling client=
s (via ID or Handle or Key or whatever) is to have processing rule on the A=
S such as =E2=80=9Cif the AS recognizes the client ID (and authentication o=
f that client ID) then it may process the request on behalf of that client.=
 If the AS does not recognize the client ID, it must treat this as a new cl=
ient registration and evaluate any authorization evidence the client provid=
es before enabling the client and mapping policies to that client=E2=80=9D =
(this means dynamic or automatic clients need to provide additional asserti=
ons / software statements whatever to register their ID.
=C2=A0
Something like this allows f=
or very flexible systems:
System A can be unkn=
own to the AS but can dynamically registered each time with an appropriate =
software statement
System B can have a fairly =
stable client ID at the AS, but rotate that ID every month through automati=
c registration (with an assertion it got from the AS during a pre-registrat=
ion for example)
System C can pre-register wit=
h the AS for a client ID because it doesn=E2=80=99t deal with software stat=
ements etc=E2=80=A6
=E2=80=A6
And even =E2=80=98StatelessAS=E2=80=99 can operate by never st=
oring client IDs because it will always just rely on the software statement=
s.
=C2=A0
I think=
 a client registration protocol that allows these scenarios would be very u=
seful in GNAP, but hopefully avoiding having to define what =E2=80=98eviden=
ce=E2=80=99 the AS needs to accept for each scenario.
=C2=A0
Thanks,
=C2=A0
MV
=
=C2=A0
From:=C2=A0=
Txauth <txauth-bounces@ietf.org> on behalf=
 of Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org<=
/a>>
Date:=C2=A0Tuesday, July 14, 2020 at 12:18 P=
M
To:=C2=A0Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" &=
lt;txauth@ietf.org=
>, Justin Richer <jricher@mit.edu>
Subject:=C2=A0Re: [Txauth]=
 Key handle vs client id & handle
=

=C2=A0
I agree that there are significant differences betw=
een statically and dynamically registered clients and that=E2=80=99s approp=
riate to be able to syntactically differentiate between them at runtime.=C2=
=A0 For one thing, the resource requirements at the authorization server ca=
n be very different.
=C2=A0
We should also be thinking about how to inc=
lude what the OpenID Connect Federation spec=C2=A0https://openid.net/specs/openid-connect-federation-1_0.html=
=C2=A0calls =E2=80=9CAutomatic Registration=E2=80=9D.=C2=A0 Th=
is lets the client encode a registration request reference in the client ID=
, so no static or dynamic registration even occurs.=C2=A0 See=C2=A0https://openid.net/specs/openid-co=
nnect-federation-1_0-12.html#rfc.section.9.1.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=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:=C2=A0Dick Hardt <dick.hardt@gmail.com=
>=C2=A0
Sent:=C2=A0Friday, July 10, =
2020 1:17 PM
To:=C2=A0txauth@ietf.org; Justin Richer <jricher@mit.edu>; Mike Jones=
 <Micha=
el.Jones@microsoft.com>
Subject:=C2=A0Key han=
dle vs client id & handle
=C2=
=A0
+ Mike as he had interest in thi=
s topic
=C2=A0
My understanding is that an existing OAuth 2 client would=
 use their current client id as their key handle, and a dynamic client (one=
 that was not pre-registered) would be given a key handle by the AS.=

=C2=A0
There are potentially some significant differences between =
a registered client, and a dynamic client to an AS.
=C2=A0
T=
he AS is likely to know the identity of a registered client, and have diffe=
rent policies between the two types of clients. For example, a registered c=
lient may have access to a 'write" scope, while a dynamic client d=
oes not.
=C2=A0<=
/div>
The AS may have 100s or 1000s of registered =
clients, but a dynamic client may have 10Ms or 100Ms of instances, which ma=
y dictate separate=C2=A0storage services. Additionally, internal to the AS,=
 which systems can write to the registered=C2=A0client store is going to be=
 different than the dynamic client=C2=A0store.
=C2=A0
In XYZ=
, subsequent calls to the AS, both registered clients and dynamic clients p=
ass a key handle, so there is no easy way to differentiate between the two.=

=C2=A0
While the AS could embed semantics in the key handle=
 identifier to indicate which identifiers are pre-registered vs dynamic, th=
ere are many cases where the AS does need to know the difference, so making=
=C2=A0the difference a feature of GNAP seems like a better path.<=
/u>
=C2=A0
=C2=A0
This email and any attachments =
are for the sole use of the intended recipients and may be privileged, conf=
idential or otherwise exempt from disclosure under law. Any distribution, p=
rinting or other use by anyone other than the intended recipient is prohibi=
ted. If you are not an intended recipient, please contact the sender immedi=
ately, and permanently delete this email and its attachments.

-- 

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/


--0000000000008b479a05ab629f28--


From nobody Sun Jul 26 19: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 3EB673A15F0 for ; Sun, 26 Jul 2020 19:15:40 -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 ghJznb_4o_-t for ; Sun, 26 Jul 2020 19:15:36 -0700 (PDT)
Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 415EE3A15E9 for ; Sun, 26 Jul 2020 19:15:36 -0700 (PDT)
Received: by mail-oo1-xc2b.google.com with SMTP id t6so2876259ooh.4 for ; Sun, 26 Jul 2020 19:15: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=fYNFZ5v+8E7CUjhMndioVY11XMIZ7sMiA65CdzPl9Do=; b=kgxQbIrsC6BgN5TCMOFiNttJHWZ9M2DrTmcFPN+itPHwLQBa9Nfn1Qz34yeEtyYRMr qZ5YAf80Pvib1HITq1J+klO6pttIxolQiJrNgkMAc+WCMg4HmF4AHA5BOUdUgbQsplhj SMYQsJe/D0BvfHe9ygRtpGpYD9kwiXPCV/A/eghR0LZX/gr48mPPGS37xawOJB+aaQAP FXqFtck6sIBrlBo7R9zns5wxq2Nkwl0r2k8KXA0db4bzGi5YtteucvVsxCTMimGrobwL jT6Jq2dJcfQzx01WI0M5yX57N3nkQpw7D8TTHwcEuA5PRfoWeMXvdzZ8Cbhpmcc3sm/E WzYg==
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=fYNFZ5v+8E7CUjhMndioVY11XMIZ7sMiA65CdzPl9Do=; b=GMp1CK+XGuwKAGRcepwwq2bItisnG9P8GiY+7br7BuKQZprOJ8jxaInNYHOoevlWvR kSH6w6/ZTLKnYLjYoF/66wIWVTMQV9uosBC1mqolCVO3qoauB3Y+TCdKRbxycbW1Ov+Z X0aFh19l8gg0b3aa39IX6/8W3iNbM6+SFmx3XEE5OocyOA+nODUeEhXlA+Yixk/KZcAY aHqSpW2QUKifJPOibBti1AXtaHqCQNZhykQbn6qe82D2M5HmvKkePwF4j9hPGgJ1LWlE VE+itpI1RULIwYmdI5ZiZ4ePjbgsBmYYT+V7at239ZHsDmwah5CJNEXxXUkcgSHG47RK 7THA==
X-Gm-Message-State: AOAM530wimbjqPM3mNHZiGjgv0g+JNGSd8R5kXext+1eEp1NiEkZdblv n4JqOVQFEPJBHxgfo/2M/KrZvI4DyX/+ftQ5N2c=
X-Google-Smtp-Source: ABdhPJysDaCfULAaFg0q7BTrFZ/H+oE1IGXoD2/N9c9cLl3Rst1YluSs84wNcuJiJZi7yND9Ev6yZbe3XZahE5Y2wPw=
X-Received: by 2002:a4a:ac8c:: with SMTP id b12mr5522237oon.27.1595816135278;  Sun, 26 Jul 2020 19:15:35 -0700 (PDT)
MIME-Version: 1.0
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>    <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>       
In-Reply-To: 
From: Tom Jones 
Date: Sun, 26 Jul 2020 19:15:23 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: Dick Hardt , Justin Richer ,  Mike Jones ,  Fabien Imbault , Mike Varley ,  "txauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000dec4f005ab62e513"
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 27 Jul 2020 02:15:40 -0000

--000000000000dec4f005ab62e513
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

one other tf could be "I am bound the terms of the GDPR".
If we go that way at all, I would also recommend a MUST or at least a
SHOULD "jurisdiction" field.
GNAP may as well take the moral high ground, it is pretty much empty space
right now.
Peace ..tom


On Sun, Jul 26, 2020 at 6:55 PM Francis Pouatcha  wrote:

> +1 Tom's input.
>
> This discussion about Key Handle vs. client id & handle wouldn't exist if
> GNAP had the notion of TF defining how the GS/RS/Clients identify
> and authenticate each other.
>
> A simple TF can describe the standard case (happy path) without having to
> foresee all eventualities.
>
> A GNAP profile will also be simple as it will keep out everything else
> (e.g. US Healthcare, PSD2).
>
> BR
> /Francis
>
>
> On Sun, Jul 26, 2020 at 9:43 PM Tom Jones 
> wrote:
>
>> You should consider a trust framework to be first of all a set of
>> qualifying criteria above and beyond the literal meaning of the standard=
.
>> Ours is focused on US Healthcare, but lots of others make sense. The
>> international R&E org is the basis for the openid federation doc.
>> Secondarily the trust framework could vet members so that they made
>> affirmative statements about their compliance.
>> Tertiary they tf could mandate testing of the members. That is the case
>> for US Healthcare.
>> the tf could be blank for sites with no moral scruples whatsoever. (the
>> majority of sites i am sure.)
>> Peace ..tom
>>
>>
>> On Sun, Jul 26, 2020 at 6:18 PM Dick Hardt  wrote:
>>
>>> Hi Francis
>>>
>>> While a Trust Framework concept looks to make sense for PSD2 use cases,
>>> there are lots of other use cases.
>>>
>>> How would you see existing OAuth 2 and OIDC concepts fitting into a
>>> Trust Framework concept?
>>>
>>> /Dick
>>>
>>> =E1=90=A7
>>>
>>> On Sat, Jul 25, 2020 at 8:41 PM Francis Pouatcha  wrote=
:
>>>
>>>> I just read through some work being done by Tom at the FIRE (Federated
>>>> Identifiers for Resilient Ecosystems) working group and it confirms my
>>>> intention of suggesting the consideration of a "Trust Framework" as a
>>>> context defining how to handle the client_id.
>>>>
>>>> The procedure the GS applies to trust a client is derived from the
>>>> "Trust Framework" that governs the environment in which GS and Client =
are
>>>> operating.
>>>>
>>>> In the European PSD2 ecosystem, National Country Authorities (a.k.a
>>>> Market Authorities or Regulators):
>>>> - delegate the production of client certificates to Trust Service
>>>> Providers (TSPs). TSPs are known certification authorities (CAs) in th=
e
>>>> corresponding countries.
>>>> - maintain a register of Certified Third Party Providers (TPPs) at the
>>>> European Banking Association (EBA), where the validity of the TPP lice=
nse
>>>> can be verified, in addition to the client certificate.
>>>>
>>>> Designing an authorization framework around the PSD2 ecosystem, there
>>>> is no need to maintain any static or dynamic client_id. Each request i=
s
>>>> associated with an SSL client certificate called QWAC (Qualified Websi=
te
>>>> Assertion Certificate).
>>>> - This certificate can be verified as the GS maintains a list of all
>>>> known TSP's CA authorized to release PSD2 client certificates.
>>>> - This certificate also contains the list of roles assigned to the TPP
>>>> by the regulator PSP_AS (bank), PSP_PI (payment initiation), PSP_AI
>>>> (account information), PSP_IC (card) sufficient for the client access
>>>> control in the PSD2 trust framework.
>>>> - This certificate contains a permanent "Competent Authority" that
>>>> uniquely identifies the NCA issuing the TPP license.
>>>> - This certificate contains a permanent "Authorization Number" that is
>>>> unique in the context of the NCA.
>>>> - so AuthorizationNumber@CompetentAuthority is globally unique in the
>>>> context of the PSD2 trust framework.
>>>>
>>>> Given these facts, GS implementing PSD2 do not need to register
>>>> clients.
>>>> - Each request of the client to the GS can be mTLS secured using the
>>>> QWAC.
>>>> - GS can extract all information needed to perform authorization from
>>>> that certificate.
>>>>
>>>> This use case does not need an extra client_id at the protocol level.
>>>>
>>>> This is:
>>>> - based on the experience we are making implementing PSD2,
>>>> - based on my reading Tom's FIRE use case in the health sector on the
>>>> sharing of Patient Health Information (PHI) among health care provider=
s,
>>>>
>>>> I suggest GNAP introduces the notion of "Trust framework" that governs
>>>> the environment in which RS, GS and Client interoperate. We can then
>>>> delegate the decision on specifying the necessity and functions of a
>>>> client_id to the trust framework.
>>>>
>>>>
>>>> On Thu, Jul 16, 2020 at 7:58 PM Tom Jones 
>>>> wrote:
>>>>
>>>>> I have been working on different level s of identifier, but from the
>>>>> mobile app perspective. That's the hardest case as you need to boot s=
trap
>>>>> trust. I suspect that in the web site case you will need these levels=
.
>>>>> Transport, application, real world.
>>>>>
>>>>> If anyone wants to work on these, let me know and I'll get you the
>>>>> links in Kantara.
>>>>>
>>>>> thx ..Tom (mobile)
>>>>>
>>>>> On Thu, Jul 16, 2020, 2:47 PM Justin Richer  wrote:
>>>>>
>>>>>> For all of these, I still say we should have different levels of
>>>>>> identifier. A =E2=80=9Cclient ID=E2=80=9D should identify the client=
, and not be used as a
>>>>>> stand-in for other things.
>>>>>>
>>>>>> Off the top of my head I think we might want to have identifiers,
>>>>>> assertions, proofs, and other trust-binding items for:
>>>>>>
>>>>>>  - Organizations
>>>>>>  - Devices
>>>>>>  - Software applications
>>>>>>  - Software instances
>>>>>>  - Software versions
>>>>>>
>>>>>> So if we=E2=80=99re going to talk about identifying these aspects, w=
e should
>>>>>> tackle each as its own thing and not mush it all into =E2=80=9Cclien=
t_id=E2=80=9D. That
>>>>>> way, hopefully, GNAP can have a much better idea what a =E2=80=9Ccli=
ent=E2=80=9D is than
>>>>>> OAuth 2 currently does.
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>> On Jul 16, 2020, at 4:34 PM, Dick Hardt  wrote=
:
>>>>>>
>>>>>> One client identifier was a simplistic example. Org A may have
>>>>>> numerous clients, perhaps in different teams, perhaps in different
>>>>>> services, each with their own policy at Org B.
>>>>>>
>>>>>> When one of the Org A clients makes a call to the Org B AS, it needs
>>>>>> to identify itself with some identifier so that Org B knows which po=
licy to
>>>>>> enforce. Why not the Client ID?
>>>>>>
>>>>>> I also agree with your comments that other client identification
>>>>>> situations are different, and forcing the same identification model =
on them
>>>>>> does not make sense, but I fail to see the value throwing out a conc=
ept
>>>>>> (client_id) that has worked well for the use cases it was designed f=
or.
>>>>>>
>>>>>>
>>>>>> =E1=90=A7
>>>>>>
>>>>>> On Thu, Jul 16, 2020 at 1:08 PM Justin Richer 
>>>>>> wrote:
>>>>>>
>>>>>>> I think that the cross-organizational trust model is an interesting
>>>>>>> one, and in fact it=E2=80=99s one of the things that=E2=80=99s push=
ed me away from a
>>>>>>> client_id. In the scenario that you describe, =E2=80=9Cclient_id=E2=
=80=9D is used to
>>>>>>> represent something that it was never meant to represent: the organ=
ization
>>>>>>> running the software, not the software itself. It isn=E2=80=99t a c=
lient_id, and
>>>>>>> while in OAuth 2 the client_id could be co-opted to carry that info=
rmation,
>>>>>>> it=E2=80=99s considered bad practice to share client_ids between mu=
ltiple pieces of
>>>>>>> software.
>>>>>>>
>>>>>>> I would argue that to address this use case properly, there should
>>>>>>> be another level of identifier to bridge that trust that the softwa=
re can
>>>>>>> present, showing that it is a part of Organization A, and not Organ=
ization
>>>>>>> C. This isn=E2=80=99t a client identifier, it=E2=80=99s an organiza=
tion identifier, and it
>>>>>>> should be separate. You might want to identify both the client inst=
ance as
>>>>>>> well as the organization it=E2=80=99s a part of, for example. This =
is part of the
>>>>>>> motivation behind putting =E2=80=9Corganizational data=E2=80=9D wit=
hin scope for the client
>>>>>>> to send to the AS, after all.
>>>>>>>
>>>>>>> Therefore, I strongly disagree that this scenario =E2=80=9Crequires=
=E2=80=9D a
>>>>>>> client_id to be solved. In fact, I think that solving this scenario=
 with a
>>>>>>> client_id is an anti-pattern that stems from OAuth 2=E2=80=99s over=
-reliance on
>>>>>>> client_id as a persistent identifier within the protocol, and we ca=
n and
>>>>>>> should do better with GNAP. It=E2=80=99s very similar to Mike Jones=
=E2=80=99s referenced
>>>>>>> federation document, where the client_id is co-opted as a means of
>>>>>>> bootstrapping client registration and discovery, or in the Solid
>>>>>>> Authentication specification which stuffs a WebID into the client_i=
d field.
>>>>>>>
>>>>>>> With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools that=
 we had to solve
>>>>>>> our problems, and come up with some very clever solutions. What I=
=E2=80=99m trying
>>>>>>> to argue to this community is that we are in a position to create o=
ur own,
>>>>>>> better tools.
>>>>>>>
>>>>>>>  =E2=80=94 Justin
>>>>>>>
>>>>>>> On Jul 16, 2020, at 2:00 PM, Dick Hardt 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Justin,
>>>>>>>
>>>>>>> While I agree that the assumption in OAuth 2 that all Clients have =
a
>>>>>>> client_id is problematic, the requirement for a client_id in many u=
se cases
>>>>>>> is still there, and it does not represent a piece of software, but =
a
>>>>>>> relationship between parties.
>>>>>>>
>>>>>>> Organization A writes client software that calls resources managed
>>>>>>> by the AS in Organization B. The client_id represents Organization =
A to
>>>>>>> Organization B. Organization B does not care what software Organiza=
tion A
>>>>>>> is running, and there may be numerous pieces of software at Organiz=
ation A
>>>>>>> that use the same client_id. The access granted by Organization B t=
o
>>>>>>> Organization A needs to be able to be different than the rights gra=
nted to
>>>>>>> Organization C.
>>>>>>>
>>>>>>> I agree that we don't want to force all clients to have a client_id=
,
>>>>>>> and as discussed, there are a variety of inputs for an AS to accept=
 calls
>>>>>>> from a piece of software, and often, that will be a particular
>>>>>>> *instance* of the software, but we also don't want to force clients
>>>>>>> to all be treated the same, because they are not..
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Exactly =E2=80=94 when we start to look at it as managing the life=
cycle of
>>>>>>>> a piece of software, instead of a registration at the AS, we can s=
tart
>>>>>>>> thinking in different terms what =E2=80=9Ctrusting=E2=80=9D the cl=
ient means in the context
>>>>>>>> of what the client is doing. That trust could come from some kind =
of signed
>>>>>>>> attestation about the software (like the OAuth 2 DynReg software
>>>>>>>> statement), or it could come from some externally fetchable item (=
like a
>>>>>>>> Solid WebID, a DID, or the OIDC Federation extension), or it could=
 come
>>>>>>>> from someone sitting at a console and typing in information and ge=
tting
>>>>>>>> back an identifier. And none of these need to pretend to be a glob=
al
>>>>>>>> =E2=80=9Cclient id=E2=80=9D for it to work. The world of clients i=
s much more diverse than
>>>>>>>> OAuth 2 likes to admit, and we see that with trying to nail down a
>>>>>>>> =E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =
=E2=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautomat=
ic=E2=80=9D vs.
>>>>>>>> =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of other thin=
gs.
>>>>>>>>
>>>>>>>> OAuth 2 only needs client IDs because the front channel needs a wa=
y
>>>>>>>> to pass client identifiers when the client can=E2=80=99t authentic=
ate itself
>>>>>>>> directly. We tried to get rid of this restriction with PAR and JAR
>>>>>>>> together, but there turned out to be corner cases in OAuth 2=E2=80=
=99s world that
>>>>>>>> still needed client_id, and implementations assumed it would be th=
ere
>>>>>>>> anyway.
>>>>>>>>
>>>>>>>> In GNAP, we can avoid that problem from the beginning by looking a=
t
>>>>>>>> the model differently and understanding where we=E2=80=99re coming=
 from, and why.
>>>>>>>>
>>>>>>>>  =E2=80=94 Justin
>>>>>>>>
>>>>>>>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault <
>>>>>>>> fabien.imbault@gmail.com> wrote:
>>>>>>>>
>>>>>>>> +1 on that.
>>>>>>>>
>>>>>>>> We can then see it more as life cycle management of the client tha=
n
>>>>>>>> registration per say, and this comes with many benefits compared t=
o the
>>>>>>>> current client_id.
>>>>>>>>
>>>>>>>> Fabien
>>>>>>>>
>>>>>>>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I not only agree with Mike Jones that =E2=80=9Cautomatic registra=
tion=E2=80=9D
>>>>>>>>> should be part of the process, but I would argue that that kind o=
f model
>>>>>>>>> should be a default mode of operation. If you have an identifier =
that you
>>>>>>>>> can send to short-circuit that, great! But we should focus on hav=
ing the
>>>>>>>>> capability of inlining a lot of this information wherever possibl=
e. This is
>>>>>>>>> already the direction that the input proposals are heading.
>>>>>>>>>
>>>>>>>>> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scop=
e for the
>>>>>>>>> protocol in general, and since both XYZ and Xauth have mechanisms=
 that
>>>>>>>>> allow the client to present a key and get back an identifier that=
 it can
>>>>>>>>> use in the future we have something equivalent.
>>>>>>>>>
>>>>>>>>> But I think there=E2=80=99s a little more to it than that: Ultima=
tely, I
>>>>>>>>> think we should question thinking in terms of =E2=80=9Cregistrati=
on=E2=80=9D, a model which
>>>>>>>>> has hampered the OAuth 2 model in a lot of use cases. For example=
, the
>>>>>>>>> federation draft Mike Jones references below hacks the =E2=80=9Cc=
lient_id=E2=80=9D
>>>>>>>>> parameter and makes it point to a document that the AS has to fet=
ch. This
>>>>>>>>> construct is done for two reasons: (1) Oauth requires a =E2=80=9C=
client_id=E2=80=9D in the
>>>>>>>>> request and (2) it=E2=80=99s difficult to pass information by val=
ue to the AS due
>>>>>>>>> to front-channel restrictions. Since we=E2=80=99re defining a new=
 protocol, we
>>>>>>>>> don=E2=80=99t need to hack that functionality into a =E2=80=9Ccli=
ent ID=E2=80=9D or equivalent and
>>>>>>>>> instead we can pass that information directly in the protocol. If=
 we don=E2=80=99t
>>>>>>>>> assume that the client *has* to have a client ID equivalent, but =
it *can*
>>>>>>>>> have one in a set of defined circumstances, then I think we are i=
n a much
>>>>>>>>> better spot. This is the reasoning for XYZ=E2=80=99s model of hav=
ing clients
>>>>>>>>> identified by the key, and that key can potentially be passed by =
a
>>>>>>>>> reference identifier.
>>>>>>>>>
>>>>>>>>> I think all of the use cases that Mike Varley presents below are
>>>>>>>>> all valid directions, with the caveat that we shouldn=E2=80=99t a=
ssume a client
>>>>>>>>> should be presenting an ID at all steps. Mechanisms like software
>>>>>>>>> statements should be presentable apart from a client ID, as shoul=
d
>>>>>>>>> on-device keys. We=E2=80=99re probably going to want extensions f=
or device posture
>>>>>>>>> and other forms of attestation as well.
>>>>>>>>>
>>>>>>>>> This is one of the domains that I think we can clearly surpass
>>>>>>>>> OAuth 2=E2=80=99s flexibility and capabilities if we are willing =
to look past OAuth
>>>>>>>>> 2=E2=80=99s assumptions of what=E2=80=99s needed inline in the pr=
otocol.
>>>>>>>>>
>>>>>>>>>  =E2=80=94 Justin
>>>>>>>>>
>>>>>>>>> On Jul 14, 2020, at 1:54 PM, Mike Varley <
>>>>>>>>> mike.varley@securekey.com> wrote:
>>>>>>>>>
>>>>>>>>> Is client registration in scope for the protocol?
>>>>>>>>>
>>>>>>>>> A generic way of handling clients (via ID or Handle or Key or
>>>>>>>>> whatever) is to have processing rule on the AS such as =E2=80=9Ci=
f the AS
>>>>>>>>> recognizes the client ID (and authentication of that client ID) t=
hen it may
>>>>>>>>> process the request on behalf of that client. If the AS does not =
recognize
>>>>>>>>> the client ID, it must treat this as a new client registration an=
d evaluate
>>>>>>>>> any authorization evidence the client provides before enabling th=
e client
>>>>>>>>> and mapping policies to that client=E2=80=9D (this means dynamic =
or automatic
>>>>>>>>> clients need to provide additional assertions / software statemen=
ts
>>>>>>>>> whatever to register their ID.
>>>>>>>>>
>>>>>>>>> Something like this allows for very flexible systems:
>>>>>>>>> System A can be unknown to the AS but can dynamically registered
>>>>>>>>> each time with an appropriate software statement
>>>>>>>>> System B can have a fairly stable client ID at the AS, but rotate
>>>>>>>>> that ID every month through automatic registration (with an asser=
tion it
>>>>>>>>> got from the AS during a pre-registration for example)
>>>>>>>>> System C can pre-register with the AS for a client ID because it
>>>>>>>>> doesn=E2=80=99t deal with software statements etc=E2=80=A6
>>>>>>>>> =E2=80=A6
>>>>>>>>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never stori=
ng client IDs
>>>>>>>>> because it will always just rely on the software statements.
>>>>>>>>>
>>>>>>>>> I think a client registration protocol that allows these scenario=
s
>>>>>>>>> would be very useful in GNAP, but hopefully avoiding having to de=
fine what
>>>>>>>>> =E2=80=98evidence=E2=80=99 the AS needs to accept for each scenar=
io.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> MV
>>>>>>>>>
>>>>>>>>> *From: *Txauth  on behalf of Mike Jones =
<
>>>>>>>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
>>>>>>>>> *Date: *Tuesday, July 14, 2020 at 12:18 PM
>>>>>>>>> *To: *Dick Hardt , "txauth@ietf.org" <
>>>>>>>>> txauth@ietf.org>, Justin Richer 
>>>>>>>>> *Subject: *Re: [Txauth] Key handle vs client id & handle
>>>>>>>>>
>>>>>>>>> I agree that there are significant differences between statically
>>>>>>>>> and dynamically registered clients and that=E2=80=99s appropriate=
 to be able to
>>>>>>>>> syntactically differentiate between them at runtime.  For one thi=
ng, the
>>>>>>>>> resource requirements at the authorization server can be very dif=
ferent.
>>>>>>>>>
>>>>>>>>> We should also be thinking about how to include what the OpenID
>>>>>>>>> Connect Federation spec
>>>>>>>>> https://openid.net/specs/openid-connect-federation-1_0.html calls
>>>>>>>>> =E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client e=
ncode a registration
>>>>>>>>> request reference in the client ID, so no static or dynamic regis=
tration
>>>>>>>>> even occurs.  See
>>>>>>>>> https://openid.net/specs/openid-connect-federation-1_0-12.html#rf=
c.section.9.1
>>>>>>>>> 
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>>                                                        -- Mike
>>>>>>>>>
>>>>>>>>> *From:* Dick Hardt 
>>>>>>>>> *Sent:* Friday, July 10, 2020 1:17 PM
>>>>>>>>> *To:* txauth@ietf.org; Justin Richer ; Mike
>>>>>>>>> Jones 
>>>>>>>>> *Subject:* Key handle vs client id & handle
>>>>>>>>>
>>>>>>>>> + Mike as he had interest in this topic
>>>>>>>>>
>>>>>>>>> My understanding is that an existing OAuth 2 client would use
>>>>>>>>> their current client id as their key handle, and a dynamic client=
 (one that
>>>>>>>>> was not pre-registered) would be given a key handle by the AS.
>>>>>>>>>
>>>>>>>>> There are potentially some significant differences between a
>>>>>>>>> registered client, and a dynamic client to an AS.
>>>>>>>>>
>>>>>>>>> The AS is likely to know the identity of a registered client, and
>>>>>>>>> have different policies between the two types of clients. For exa=
mple, a
>>>>>>>>> registered client may have access to a 'write" scope, while a dyn=
amic
>>>>>>>>> client does not.
>>>>>>>>>
>>>>>>>>> The AS may have 100s or 1000s of registered clients, but a dynami=
c
>>>>>>>>> client may have 10Ms or 100Ms of instances, which may dictate
>>>>>>>>> separate storage services. Additionally, internal to the AS, whic=
h systems
>>>>>>>>> can write to the registered client store is going to be different=
 than the
>>>>>>>>> dynamic client store.
>>>>>>>>>
>>>>>>>>> In XYZ, subsequent calls to the AS, both registered clients and
>>>>>>>>> dynamic clients pass a key handle, so there is no easy way to dif=
ferentiate
>>>>>>>>> between the two.
>>>>>>>>>
>>>>>>>>> While the AS could embed semantics in the key handle identifier t=
o
>>>>>>>>> indicate which identifiers are pre-registered vs dynamic, there a=
re many
>>>>>>>>> cases where the AS does need to know the difference, so making th=
e
>>>>>>>>> difference a feature of GNAP seems like a better path.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This email and any attachments are for the sole use of the
>>>>>>>>> intended recipients and may be privileged, confidential or otherw=
ise exempt
>>>>>>>>> from disclosure under law. Any distribution, printing or other us=
e by
>>>>>>>>> anyone other than the intended recipient is prohibited. If you ar=
e not an
>>>>>>>>> intended recipient, please contact the sender immediately, and pe=
rmanently
>>>>>>>>> delete this email and its attachments.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Txauth mailing 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/
>

--000000000000dec4f005ab62e513
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


one other tf could be "I am bound=C2=A0the terms of t=
he GDPR".
If we go that way at all, I would also recommend a MUST =
or at least a SHOULD "jurisdiction" field.
GNAP may as =
well take the moral high ground, it is pretty much empty space right now.
Peace ..tom
=



On Sun, Jul 26, 2020 at 6:55 PM Francis Pouatcha <fpo@adorsys.de> wrote:
+1 Tom's inp=
ut.

This discussion about Key Handle vs. client id &=
amp; handle wouldn't exist if GNAP had the notion of TF defining how th=
e GS/RS/Clients identify and=C2=A0authenticate=C2=A0each other.
<=
br>
A simple TF can=C2=A0describe the standard case (happy path) =
without=C2=A0having to foresee all eventualities.

=
A GNAP profile will also be simple as it will keep out everything=C2=A0else=
 (e.g. US Healthcare, PSD2).

BR=C2=A0
/F=
rancis


On Sun, Jul 26, 2020 at 9:43 PM Tom Jones <thomascling=
anjones@gmail.com> wrote:
You=C2=A0should consider a trust=C2=A0fra=
mework to be first of all a set of qualifying=C2=A0criteria above and beyon=
d the literal meaning of the standard.
Ours is focused on US Healthcare=
, but lots of others make sense. The international R&E org is the basis=
 for the openid federation doc.
Secondarily the trust framework c=
ould vet members so that they made affirmative statements about their compl=
iance.
Tertiary they tf could mandate testing of the members. Tha=
t is the case for US Healthcare.
the tf could be blank for sites =
with no moral scruples whatsoever. (the majority of sites i am sure.)
Peace ..tom


On Sun, Jul 26, 2020 at 6:18 PM Dick Hardt <dick.hardt@gmail.co=
m> wrote:
Hi Francis

While a Trust Framework con=
cept looks to make sense for PSD2 use cases, there are lots of other use ca=
ses.

How would you see existing OAuth 2 and OIDC concept=
s fitting into a Trust Framework concept?

/D=
ick

3D""=E1=90=A7

On Sat, Jul 25=
, 2020 at 8:41 PM Francis Pouatcha <fpo@adorsys.de> wrote:
I just read through some wor=
k being done by Tom at the FIRE (Federated Identifiers for Resilient Ecosys=
tems) working=C2=A0group and it confirms my intention of suggesting the con=
sideration of a "Trust Framework" as a context defining how to ha=
ndle the client_id.

The procedure the GS applies to trus=
t a client is derived from the "Trust Framework" that governs the=
 environment in which GS and Client are operating.

=

In the European PSD2 ecosystem, National Country Authorities (a.k.a Ma=
rket Authorities or Regulators):
- delegate the production of cli=
ent certificates to Trust Service Providers (TSPs). TSPs are known certific=
ation authorities (CAs) in the corresponding countries.
- maintai=
n a register of Certified Third Party Providers (TPPs) at the European Bank=
ing Association (EBA), where the validity of the TPP license can be verifie=
d,=C2=A0in addition=C2=A0to the client certificate.

Designing an authorization framework around=C2=A0the PSD2 ecosystem, ther=
e is no need to maintain any static or dynamic client_id. Each request is a=
ssociated with an SSL client certificate called QWAC (Qualified Website Ass=
ertion Certificate).=C2=A0
- This certificate can be verified as =
the GS maintains a list of all known TSP's CA authorized to release PSD=
2 client certificates.
- This certificate also contains the list =
of roles assigned to the TPP by the regulator=C2=A0PSP_AS (bank), PSP_PI (p=
ayment initiation), PSP_AI (account information), PSP_IC (card) sufficient =
for the client access control in the PSD2 trust framework.
- This=
 certificate contains a permanent "Competent Authority" that uniq=
uely=C2=A0identifies the NCA issuing the TPP license.
- This cert=
ificate contains a permanent "Authorization Number" that is uniqu=
e in the context of the NCA.
- so=C2=A0AuthorizationNumber@Compet=
entAuthority is globally=C2=A0unique in the context of the PSD2 trust frame=
work.

Given these facts, GS implementing PSD2 do n=
ot need to register clients.=C2=A0
- Each request of the client t=
o the GS can be mTLS secured using the QWAC.
- GS can extract all=
 information needed to perform=C2=A0authorization from that certificate.

This use case does not need an extra client_id at th=
e protocol level.=C2=A0

This is:
- based=
 on the experience we are making implementing PSD2,
- based on my=
 reading Tom's FIRE use case in the health sector on the sharing of Pat=
ient Health Information (PHI) among health care providers,

I suggest GNAP introduces the notion of "Trust framework"=
; that governs the environment in which RS, GS and Client interoperate. We =
can then delegate the decision on specifying the necessity and functions of=
 a client_id to the trust framework.


On Thu, Jul 16, 20=
20 at 7:58 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
I have bee=
n working on different level s of identifier, but from the mobile app persp=
ective. That's the hardest case as you need to boot strap trust. I susp=
ect that in the web site case you will need these levels. Transport, applic=
ation, real world.

If anyone w=
ants to work on these, let me know and I'll get you the links in Kantar=
a.

thx ..Tom (mobile)

On Thu, Jul 16, 2=
020, 2:47 PM Justin Richer <jricher@mit.edu> wrote:
For all of these, I still say we should have different levels =
of identifier. A =E2=80=9Cclient ID=E2=80=9D should identify the client, an=
d not be used as a stand-in for other things.=C2=A0

Off =
the top of my head I think we might want to have identifiers, assertions, p=
roofs, and other trust-binding items for:

=C2=A0- =
Organizations
=C2=A0- Devices
=C2=A0- Software applicat=
ions
=C2=A0- Software instances
=C2=A0- Software versio=
ns

So if we=E2=80=99re going to talk about identif=
ying these aspects, we should tackle each as its own thing and not mush it =
all into =E2=80=9Cclient_id=E2=80=9D. That way, hopefully, GNAP can have a =
much better idea what a =E2=80=9Cclient=E2=80=9D is than OAuth 2 currently =
does.

=C2=A0=E2=80=94 Justin

On Jul 16, 2020, at 4:34 PM, Dick Hardt <dick.=
hardt@gmail.com> wrote:

One client id=
entifier was a simplistic example. Org A may have numerous clients, perhaps=
 in different teams, perhaps in different services, each with their own pol=
icy at Org B.

When one of the Org A clients makes a =
call to the Org B AS, it needs to identify itself with some identifier so t=
hat Org B knows which policy to enforce. Why not the Client ID?
<=
br>
I also agree with your comments that other client identificat=
ion situations are different, and forcing the same identification model on =
them does not make sense, but I fail=C2=A0to see the value throwing out a c=
oncept (client_id) that has worked well for the use cases it was designed f=
or.=C2=A0


3D""=E1=90=
=A7

On Thu, Jul 16, 2020 at 1:08 PM Justin Richer <jricher@mit.edu> wrote:
I think that the cross-organizational trust model is an interesting one, =
and in fact it=E2=80=99s one of the things that=E2=80=99s pushed me away fr=
om a client_id. In the scenario that you describe, =E2=80=9Cclient_id=E2=80=
=9D is used to represent something that it was never meant to represent: th=
e organization running the software, not the software itself. It isn=E2=80=
=99t a client_id, and while in OAuth 2 the client_id could be co-opted to c=
arry that information, it=E2=80=99s considered bad practice to share client=
_ids between multiple pieces of software.=C2=A0

I would =
argue that to address this use case properly, there should be another level=
 of identifier to bridge that trust that the software can present, showing =
that it is a part of Organization A, and not Organization C. This isn=E2=80=
=99t a client identifier, it=E2=80=99s an organization identifier, and it s=
hould be separate. You might want to identify both the client instance as w=
ell as the organization it=E2=80=99s a part of, for example. This is part o=
f the motivation behind putting =E2=80=9Corganizational data=E2=80=9D withi=
n scope for the client to send to the AS, after all.

Therefore, I strongly disagree that this scenario =E2=80=9Crequires=E2=
=80=9D a client_id to be solved. In fact, I think that solving this scenari=
o with a client_id is an anti-pattern that stems from OAuth 2=E2=80=99s ove=
r-reliance on client_id as a persistent identifier within the protocol, and=
 we can and should do better with GNAP. It=E2=80=99s very similar to Mike J=
ones=E2=80=99s referenced federation document, where the client_id is co-op=
ted as a means of bootstrapping client registration and discovery, or in th=
e Solid Authentication specification which stuffs a WebID into the client_i=
d field.

With OAuth 2=E2=80=99s ecosystem, we=E2=
=80=99ve used the tools that we had to solve our problems, and come up with=
 some very clever solutions. What I=E2=80=99m trying to argue to this commu=
nity is that we are in a position to create our own, better tools.=C2=A0

=C2=A0=E2=80=94 Justin


Justin,=C2=A0

=

While I agree that the assumption in OAuth 2 that all Clients ha=
ve a client_id is problematic, the requirement for a client_id in many use =
cases is still there, and it does not represent a piece of software, but a =
relationship between parties.

Organization A =
writes client software that calls resources managed by the AS in Organizati=
on B. The client_id represents Organization A to Organization B. Organizati=
on B does not care what software Organization A is running, and there may b=
e numerous=C2=A0pieces of software at Organization A that use the same clie=
nt_id. The access granted by Organization B to Organization A needs to be a=
ble to be different than the rights granted to Organization C.=C2=A0
<=
/div>

I agree that we don't want to force all client=
s to have a client_id, and as discussed, there are a variety of inputs for =
an AS to accept calls from a piece of software, and often, that will be a p=
articular instance of the software, but we also don't want to fo=
rce clients to all be treated the same, because they are not..=C2=A0
<=
div>




<=
/div>
O=
n Thu, Jul 16, 2020 at 8:24 AM Justin Richer <jricher@mit.edu> wrote=
:
Exactly =
=E2=80=94 when we start to look at it as managing the lifecycle of a piece =
of software, instead of a registration at the AS, we can start thinking in =
different terms what =E2=80=9Ctrusting=E2=80=9D the client means in the con=
text of what the client is doing. That trust could come from some kind of s=
igned attestation about the software (like the OAuth 2 DynReg software stat=
ement), or it could come from some externally fetchable item (like a Solid =
WebID, a DID, or the OIDC Federation extension), or it could come from some=
one sitting at a console and typing in information and getting back an iden=
tifier. And none of these need to pretend to be a global =E2=80=9Cclient id=
=E2=80=9D for it to work. The world of clients is much more diverse than OA=
uth 2 likes to admit, and we see that with trying to nail down a =E2=80=9Cc=
onfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=80=9Cdynamic=E2=
=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautomatic=E2=80=9D vs. =E2=
=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of other things.=C2=A0

OAuth 2 only needs client IDs because the front chann=
el needs a way to pass client identifiers when the client can=E2=80=99t aut=
henticate itself directly. We tried to get rid of this restriction with PAR=
 and JAR together, but there turned out to be corner cases in OAuth 2=E2=80=
=99s world that still needed client_id, and implementations assumed it woul=
d be there anyway.=C2=A0

In GNAP, we can avoid tha=
t problem from the beginning by looking at the model differently and unders=
tanding where we=E2=80=99re coming from, and why.

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

On Jul 16=
, 2020, at 3:49 AM, Fabien Imbault <fabien.imbault@gmail.com&g=
t; wrote:

+1 on that.

We =
can then see it more as life cycle management of the client than registrati=
on per say, and this comes with many benefits compared to the current clien=
t_id.

Fabien

On Tue, Jul 14, 2020 at 9:32 PM =
Justin Richer <jricher@mit.edu> wrote:
I not only agree with Mike Jones that =
=E2=80=9Cautomatic registration=E2=80=9D should be part of the process, but=
 I would argue that that kind of model should be a default mode of operatio=
n. If you have an identifier that you can send to short-circuit that, great=
! But we should focus on having the capability of inlining a lot of this in=
formation wherever possible. This is already the direction that the input p=
roposals are heading.

So I kind-of agree that =E2=80=9Cr=
egistration=E2=80=9D is in scope for the protocol in general, and since bot=
h XYZ and Xauth have mechanisms that allow the client to present a key and =
get back an identifier that it can use in the future we have something equi=
valent.=C2=A0

But I think there=E2=80=99s a little=
 more to it than that: Ultimately, I think we should question thinking in t=
erms of =E2=80=9Cregistration=E2=80=9D, a model which has hampered the OAut=
h 2 model in a lot of use cases. For example, the federation draft Mike Jon=
es references below hacks the =E2=80=9Cclient_id=E2=80=9D parameter and mak=
es it point to a document that the AS has to fetch. This construct is done =
for two reasons: (1) Oauth requires a =E2=80=9Cclient_id=E2=80=9D in the re=
quest and (2) it=E2=80=99s difficult to pass information by value to the AS=
 due to front-channel restrictions. Since we=E2=80=99re defining a new prot=
ocol, we don=E2=80=99t need to hack that functionality into a =E2=80=9Cclie=
nt ID=E2=80=9D or equivalent and instead we can pass that information direc=
tly in the protocol. If we don=E2=80=99t assume that the client *has* to ha=
ve a client ID equivalent, but it *can* have one in a set of defined circum=
stances, then I think we are in a much better spot. This is the reasoning f=
or XYZ=E2=80=99s model of having clients identified by the key, and that ke=
y can potentially be passed by a reference identifier.

=

I think all of the use cases that Mike Varley presents below are all v=
alid directions, with the caveat that we shouldn=E2=80=99t assume a client =
should be presenting an ID at all steps. Mechanisms like software statement=
s should be presentable apart from a client ID, as should on-device keys. W=
e=E2=80=99re probably going to want extensions for device posture and other=
 forms of attestation as well.

This is one of the =
domains that I think we can clearly surpass OAuth 2=E2=80=99s flexibility a=
nd capabilities if we are willing to look past OAuth 2=E2=80=99s assumption=
s of what=E2=80=99s needed inline in the protocol.=C2=A0

=C2=A0=E2=80=94 Justin

=

On Jul 14, 2020, at 1:54 PM, Mike Varley <mike.varley@secure=
key.com> wrote:

Is clie=
nt registration in scope for the protocol?
=
=C2=A0
A generic way of handling clients (via ID =
or Handle or Key or whatever) is to have processing rule on the AS such as =
=E2=80=9Cif the AS recognizes the client ID (and authentication of that cli=
ent ID) then it may process the request on behalf of that client. If the AS=
 does not recognize the client ID, it must treat this as a new client regis=
tration and evaluate any authorization evidence the client provides before =
enabling the client and mapping policies to that client=E2=80=9D (this mean=
s dynamic or automatic clients need to provide additional assertions / soft=
ware statements whatever to register their ID.
=C2=A0
Something like this allows for very fl=
exible systems:
System A can be unknown to the=
 AS but can dynamically registered each time with an appropriate software s=
tatement
System B can have a fairly stable cli=
ent ID at the AS, but rotate that ID every month through automatic registra=
tion (with an assertion it got from the AS during a pre-registration for ex=
ample)
System C can pre-register with the AS f=
or a client ID because it doesn=E2=80=99t deal with software statements etc=
=E2=80=A6
=E2=80=A6
And even =E2=80=98StatelessAS=E2=80=99 can operate by never storing clie=
nt IDs because it will always just rely on the software statements.<=
u>
=C2=A0
I think a client =
registration protocol that allows these scenarios would be very useful in G=
NAP, but hopefully avoiding having to define what =E2=80=98evidence=E2=80=
=99 the AS needs to accept for each scenario.
=
=C2=A0
Thanks,
=
=C2=A0
MV
=
=C2=A0
From:=C2=A0<=
span style=3D"font-size:12pt">Txauth <txauth-bounces@ietf.org> on behalf of Mik=
e Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>=

Date:=C2=A0Tuesday, July 14, 2020 at 12:18 PM
To:=C2=A0Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>, Jus=
tin Richer <jricher=
@mit.edu>
Subject:=C2=A0Re: [Txauth] Key hand=
le vs client id & handle
=C2=A0
I agree that there are significant differences between statica=
lly and dynamically registered clients and that=E2=80=99s appropriate to be=
 able to syntactically differentiate between them at runtime.=C2=A0 For one=
 thing, the resource requirements at the authorization server can be very d=
ifferent.
=C2=A0
We should also be thinking about how to include what the=
 OpenID Connect Federation spec=C2=A0htt=
ps://openid.net/specs/openid-connect-federation-1_0.html=C2=A0calls =E2=80=9CAutomatic Registration=E2=80=9D.=C2=A0 This lets the cli=
ent encode a registration request reference in the client ID, so no static =
or dynamic registration even occurs.=C2=A0 See=C2=A0https://openid.net/specs/openid-connect-federatio=
n-1_0-12.html#rfc.section.9.1.
=C2=A0=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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:=C2=A0Dick Hardt <dick.hardt@gmail.com>=C2=A0<=
/span>
Sent:=C2=A0Friday, July 10, 2020 1:17 PM
<=
b>To:=C2=A0txauth@ietf.org; Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsof=
t.com>
Subject:=C2=A0Key handle vs client id =
& handle
=C2=A0
+ Mike as he had interest in this topic
=C2=A0
M=
y understanding is that an existing OAuth 2 client would use their current =
client id as their key handle, and a dynamic client (one that was not pre-r=
egistered) would be given a key handle by the AS.
=

=C2=A0
The=
re are potentially some significant differences between a registered client=
, and a dynamic client to an AS.
=C2=A0
The AS is likely t=
o know the identity of a registered client, and have different policies bet=
ween the two types of clients. For example, a registered client may have ac=
cess to a 'write" scope, while a dynamic client does not.
=C2=A0
<=
div style=3D"margin:0cm 0cm 0.0001pt 36pt;font-size:11pt;font-family:Calibr=
i,sans-serif">The AS may have 100s or 1000s of registered clients, but a dy=
namic client may have 10Ms or 100Ms of instances, which may dictate separat=
e=C2=A0storage services. Additionally, internal to the AS, which systems ca=
n write to the registered=C2=A0client store is going to be different than t=
he dynamic client=C2=A0store.
=
=C2=A0
In XYZ, subsequent call=
s to the AS, both registered clients and dynamic clients pass a key handle,=
 so there is no easy way to differentiate between the two.
=C2=A0
While the AS could embed semantics in the key handle identifier to in=
dicate which identifiers are pre-registered vs dynamic, there are many case=
s where the AS does need to know the difference, so making=C2=A0the differe=
nce a feature of GNAP seems like a better path.
=C2=A0
=C2=A0
This email and any at=
tachments are for the sole use of the intended recipients and may be privil=
eged, confidential or otherwise exempt from disclosure under law. Any distr=
ibution, printing or other use by anyone other than the intended recipient =
is prohibited. If you are not an intended recipient, please contact the sen=
der immediately, and permanently delete this email and its attachments.
=


-- 

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



--000000000000dec4f005ab62e513--


From nobody Sun Jul 26 20:45: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 2C0CB3A166B for ; Sun, 26 Jul 2020 20:44:58 -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 AeRqAEsyPWhW for ; Sun, 26 Jul 2020 20:44:56 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 768433A1669 for ; Sun, 26 Jul 2020 20:44:56 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id r21so786209ota.10 for ; Sun, 26 Jul 2020 20:44: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=uYDW5PAeC6l+QxxLie+XNTD4Uls4n1ixNK+OCpS2xus=; b=hDeDnDAuJmizg9hQJg8m3U6XvaWCet5JtJggF5Lu9maGmL5hyA3J9/WAVKuIBkvwOU 4RGNHlzV+jdnzUJUPHcxxSkMFY2b1ZbbruX8mp+njnjlAw8EqW+axby++OxF62c2qX25 ODF/crmGmSTNUktetp3z4wLKGUH3ejPDBKq0EHRzr6fbzix+VJFo4q7mmeqVcvDZCFyA +vO3537Rq/V5fE7RS8ze+t+OsF7wYZ2MT5JArQIdCZwn7RO/6HbruH583BtIeB/+vYqA 5P2bFwpfXRVUzg9y/inbmE8TbWb54TTtSfi/RHPiCH6adpKhifw8aFY67y3XzhTy/VCV bphg==
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=uYDW5PAeC6l+QxxLie+XNTD4Uls4n1ixNK+OCpS2xus=; b=rha01DfmBr0HGqL477Xtugs7PyQzmsrZeESRwoYD3ohC5VFvwXTD+9yogqNWWiLuwv Vjcl346Ou6pdrlKGeQBsIrVQ/pi5Ji6I/u5n9CwZQgqZBjcrwlda4YYIC4SRDm1OmSmx VYnRnhHHLu+1GZ7ESLOyYdX1hrXroJlaEG9+LSFy3Hy5RF9lsJAJuMBM41ofH9Hmf0EA /nz1eBuyO80wkhKA7bQXdYQLnz20TVq/PdvpguTBOJwOHEYVtOLjDdLjV0mdm9TCV9cQ J5rQn0/yOgN3+xCtS41RP6aG3jQ6Y7vXnbrBzukDrPYV8eF+zaYGO+S+8NeE9oFvWTya ovNQ==
X-Gm-Message-State: AOAM530y7mfTu+7NAA2vVu6UDlLhzNY868CfiNP4AijjY2dj7B8d5q2L hObdxnMYhgwa9DWAUliDQ1V4a8u2v5PL9FOf+pc=
X-Google-Smtp-Source: ABdhPJxNmVqGTfS5O1zmff9PYZ9yAR46KH0r6t9QQ+ydW5TAlabea3QKgVcNgiHNf+STWvBwwAMmCeDFayHj3sSP+U4=
X-Received: by 2002:a9d:66ca:: with SMTP id t10mr18023175otm.358.1595821495565;  Sun, 26 Jul 2020 20:44:55 -0700 (PDT)
MIME-Version: 1.0
References:            
In-Reply-To: 
From: Tom Jones 
Date: Sun, 26 Jul 2020 20:44:44 -0700
Message-ID: 
To: Justin Richer 
Cc: Francis Pouatcha , Dick Hardt , txauth gnap , Denis 
Content-Type: multipart/alternative; boundary="0000000000005e3f7005ab64257e"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 03:44:59 -0000

--0000000000005e3f7005ab64257e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

yeah. - one thought
let's look at a token issued by a user - so here's a guess.
1, a claim is a statement made about themself by the user (or the RO when
that is different.)
2. a grant is an authz for the client to acquire data about (inter alia)
data about the user.
Peace ..tom


On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote:

> I want to focus on one aspect here:
>
>
>> A Claim is a well understood term in the field. We should use it. It is
>> still a Claim if it comes directly from the GS or from an RS.
>>
> I do not understand why a Resource release by an RS shall be h to as a
> claim, even if the content of the Resource is an assertion. It will lead =
to
> confusion. If we limit claims to information GS releases into Token, User
> Info, and other objects it returns, this will help separate
> responsibilities between GS and RS. As soon as RS services and informatio=
n,
> this is called a Resource, no matter the nature of the content of that
> information.
>
>
> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=E2=
=80=9D in the way that
> we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back th=
rough an RS =E2=80=94 but in the
> context of GNAP, that makes it a resource. So we need a different word fo=
r
> data coming back directly from the AS to the client. Sometimes it=E2=80=
=99s going
> to be about the user, and that=E2=80=99s what we=E2=80=99re going to focu=
s on here, but
> since you can also get information about the user from a resource we can=
=E2=80=99t
> just call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the hear=
t of a lot of
> confusion in recent threads, as well as confusion about the scope of the
> inclusion of identity in the GNAP protocol.
>
> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does, a=
nd let=E2=80=99s find a way to
> differentiate between when an item, claim or otherwise,  comes as part of=
 a
> resource and when it comes back directly. This is an important
> differentiating feature for GNAP.
>
> Some straw man ideas, none of which I=E2=80=99m particularly in love with=
:
>
>  - direct data
>  - properties
>  - details
>  - statements
>
> The important thing here is that it=E2=80=99s not necessarily :about: the=
 RO, and
> that it is :not: in a resource.
>
> Any other thoughts?
>
>  =E2=80=94 Justin
>

--0000000000005e3f7005ab64257e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


yeah. - one thought
let's look at a token issued b=
y a user - so here's a guess.
1,=C2=A0a claim is a statement =
made about themself by the user (or the RO when that is different.)
2. a grant is an authz for the client to acquire data about (inter alia)=
 data about the user.
Peace =
..tom


On Fri, Jul 24, 2020 at 5:58 AM Just=
in Richer <jricher@mit.edu> wr=
ote:
I want to focus on one aspect here:

A Claim is a well understood term in the field. We should=
 use it. It is still a Claim if it comes directly from the GS or from an RS=
.=C2=A0
I do not understand why a Resource rel=
ease by an RS shall be h to as a claim, even if the content of the Resource=
 is an assertion. It will lead to confusion. If we limit claims to informat=
ion GS releases into Token, User Info, and other objects it returns, this w=
ill help separate responsibilities between GS and RS. As soon as RS service=
s and information, this is called a Resource, no matter the nature of the c=
ontent of that information.

<=
div>This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=
=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=
=80=9D could come back through an RS =E2=80=94 but in the context of GNAP, =
that makes it a resource. So we need a different word for data coming back =
directly from the AS to the client. Sometimes it=E2=80=99s going to be abou=
t the user, and that=E2=80=99s what we=E2=80=99re going to focus on here, b=
ut since you can also get information about the user from a resource we can=
=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at=
 the heart of a lot of confusion in recent threads, as well as confusion ab=
out the scope of the inclusion of identity in the GNAP protocol.
=

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it al=
ready does, and let=E2=80=99s find a way to differentiate between when an i=
tem, claim or otherwise,=C2=A0=C2=A0comes as part of a resource and when it=
 comes back directly. This is an important differentiating feature for GNAP=
.

Some straw man ideas, none of which I=E2=80=99m =
particularly in love with:

=C2=A0- direct data
=C2=A0- properties
=C2=A0- details
=C2=A0- state=
ments

The important thing here is that it=E2=80=99=
s not necessarily :about: the RO, and that it is :not: in a resource.
=


Any other thoughts?

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


--0000000000005e3f7005ab64257e--


From nobody Sun Jul 26 20:58: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 610F73A1680 for ; Sun, 26 Jul 2020 20:58: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 uwd2j_6X24kn for ; Sun, 26 Jul 2020 20:58:10 -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 B5AAF3A167C for ; Sun, 26 Jul 2020 20:58:09 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id h19so15609850ljg.13 for ; Sun, 26 Jul 2020 20:58: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=tH4/JLmFODdJpFOsUBo9b7fbzUrbZFWlSg8hTLAq3NU=; b=eBqAIlMnaOU4vBAyAbo0g08IegJz0vcdLkTvbyNTGmc2vbavAL8WqmoM0rD1xj/DbM s2enRnNfBFqgRBzLPOaTEEUIK0LcbdZAn39jphH/L4mlfihgqJHIpix9lxRqJ4uMI/GG J2tetZ6Lbmk1rMpEKeBeyuktmnW9V2U2SWZzmKrLnRQJqbeRubR4jhear4tBbaRcfLcS 7c7qRtHIyy1JHOGHAfUSvVKax1UfDImMq1nkM9cN/zrSwxSS+SXY5xtXoei7g+r18qD5 ORtScEo6yHp+PAIB8TTbIM0bLOGGF4mJW2Tmt1lb6nrbd7Zdk6bUTgrpu0r2BopZAjRP fbBA==
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=tH4/JLmFODdJpFOsUBo9b7fbzUrbZFWlSg8hTLAq3NU=; b=dStzLbjlqYDYVbwtKlFZA+j8FfWwMJ2KX2M3P/644cSlohq7Rkb1vhOECSr3k/p1Rm b643V4UL5i9o0daH4lgJmfiVimLEUtE4guTws8CK2EQr2DZMUqE6phnc0sd7HGC+ptaH OzO46GrqiIL0uohEkmq1VBHHOHPPw2GTScwg5yoUxMM/WMAvWEyY+kyKII8U4Amoyfi7 xMJCPSUPbj2R17BTZyflp9ToYCtFnr3NBeek43lsSN/EOVYUQzQuyoyL6mPumIiyxnQy eRSDtprjwr7xzIrSBN1QPw7CrrJTtesEq/blAyKgEdNCK+xX/q8CvRDRIKjPfCaP8FMc T4PA==
X-Gm-Message-State: AOAM530qWJFCW+42pZRQ8eBoS6b/Lmu+kuu6dbsEacRzc0qQHm04FhFV eXTzPLPiGMHDii/LSk7TZS6AQKuehxEywpgraKE=
X-Google-Smtp-Source: ABdhPJwEgZADFj9UTuRd37qz1vrEU3fP5a0FbxHMntb8okZ050XAtgNEC3Q1WGCl957SgJn6keRH6AIyzIyHZIrUMOw=
X-Received: by 2002:a2e:b607:: with SMTP id r7mr9660309ljn.5.1595822287527; Sun, 26 Jul 2020 20:58:07 -0700 (PDT)
MIME-Version: 1.0
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>    
In-Reply-To: 
From: Dick Hardt 
Date: Sun, 26 Jul 2020 20:57:31 -0700
Message-ID: 
To: Francis Pouatcha 
Cc: txauth@ietf.org, Justin Richer ,  Tom Jones , Denis ,  Fabien Imbault 
Content-Type: multipart/alternative; boundary="00000000000092a79605ab645442"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 03:58:14 -0000

--00000000000092a79605ab645442
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 26, 2020 at 6:45 PM Francis Pouatcha  wrote:

> Hello Dick,
>
> On Sun, Jul 26, 2020 at 9:14 PM Dick Hardt  wrote:
>
>> Hi Francis
>>
>> User is a well understood term in OIDC and OAuth -- and User means the
>> same in both.
>>
>
>> Resource Owner is who owns the resource, and the term is introduced for
>> when the User is NOT the Resource Owner.
>>
> This distinction is what makes it confusing as we are comparing an Entity
> (the User) to a Role (the RO). We need two roles.
>

Or we could think of them all as entities. The RO is the entity that owns
the resource. The User is the human that is using the Client.


>
>
>>
>> I also think that Client and Resource Server are well understood terms.
>>
> Looks like contributors on the list still need clarification on the
> "orchestration" role of a client.
>

When I think of orchestration, I think of coordinating, which is not what I
think the Client is doing. The Client wants to consume the Claims and the
Resources (combined are a Grant). The Client requests the Grant from the
Grant Server. Where is the orchestration?


>
>> It is not clear to me why we would want to reinvent these terms. Reading
>> over your flows, I think it would be useful to understand the requiremen=
ts
>> you have for your use case, otherwise I fear we will be talking past eac=
h
>> other.
>>
> The oAuth flow is there as a memo. The other flow is what I proposed
> before. Is there to emphasize we need to work on roles and not on entitie=
s.
> It is not a suggestion to rename well known idioms. It is an attempt to
> give them a proper definition in the context of this protocol. Definition
> based on their roles in the protocol flows.
>

I'd like to take a step back and understand the requirements. We are deep
into solutions.


>
> Best regards.
> /Francis
>
>>
>> /Dick
>>
>> =E1=90=A7
>>
>> On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha  wrote:
>>
>>> Below my opinion on the term Claim:
>>>
>>> Starting with illustration of parties/roles:
>>>
>>> User:
>>> This word is misleading because of its double role in oAuth2 and OIDC
>>> (see below). In GNAP let us have the User play only the role of a
>>> requestor. (from Justin reference to "Requesting Party").
>>>
>>> Client:
>>> This is also tightly bound to the oAuth2 and OIDC. The real purpose of
>>> this role is to orchestrate resource access on behalf of the "Requestor=
".
>>> Let us call this for now the "Orchestrator"
>>>
>>> Resource Owner (RO):
>>> This is IMO the most correct word in the entire protocol. Authorisation
>>> is always about the owner of something granting access to a requestor. =
It
>>> really does not matter if a human interaction is involved. We will have=
 to
>>> forget oAuth2 and OIDC of also calling this a User.
>>>
>>> Grant Server:
>>> Even though the definition of the UserInfo endpoint in OIDC as a
>>> protected resource hazardously makes an OP an RS, we shall not repeat t=
he
>>> same mistake here. We need a clear separation between roles of GS and R=
S
>>> without overlapping.
>>>
>>> Resource Server: services resources.
>>>
>>> Unless I got it wrong, GNAP is about grant negotiation and
>>> authorization. This means:
>>>
>>> GNAP is about some party requesting access to some resources.
>>> GNAP is about the resource owner consenting access to that resource.
>>> GNAP is about defining the infrastructure that allows the requesting
>>> party to access a resource.
>>>
>>> GNAP designs this infrastructure around:
>>> - an orchestrator (what we refer to as a client)
>>> - an grant manager (what we refer to as a GS/AS)
>>> - the custodian of the resource (what we call a RS)
>>>
>>> As you see:
>>> - The word User does not appear here, and is not relevant as the
>>> focus is on authorizing access to a resource.
>>> - The word Claim is as well absent.
>>>
>>> Claim related to RO:
>>> The word Claim might start getting visible if the orchestrator (a.k.a.
>>> Client) or the custodian (a.k.a RS) needs some additional information o=
n
>>> the RO to proceed with the access control decision. These claims refer =
to
>>> assertions of attributes or properties of the RO. These claims are issu=
ed
>>> by the GS as the GS manages interaction with the RO (see below). In thi=
s
>>> first place information about the requesting party (erroneously.k.a.
>>> User) is not relevant to the negotiation and provisioning framework. Le=
t us
>>> call this sort of claim "RO-Attributes". A better name is welcome.
>>>
>>> Some advanced resource provisioning frameworks might require knowledge
>>> on attributes of the requesting party (e.k.a User). These attributes sh=
all
>>> be collected by the orchestrator (a.k.a Client) and added to the resour=
ce
>>> request. There is no way the GS can collect these attributes as the GS =
role
>>> has no interaction with the requesting party (e.k.a User). Let us call =
this
>>> sort of claim "Requestor-Attributes". A better name will be welcome.
>>>
>>> Some assertions are even related to the orchestrator (a.k.a Client)
>>> itself. This is the case of the public key of an orchestrator used by t=
he
>>> GS to "sender constrain" an access token. Let us call this type of clai=
m
>>> "Orchestrator-Attributes".
>>>
>>> This is a sample mapping of OIDC.
>>>
>>> +----+    +---+   +---+  +---+
>>> |User|    |RP |   |OP |  |RS |
>>> +----+    +---+   +-+-+  +---+
>>>   |(1) ServiceRequest      |
>>>   |-------->|       |      |
>>>   |(2) redirect     |      |
>>>   |<--------|       |      |
>>> =3D=3D=3D User (requestor) passes control to User (RO) =3D=3D=3D
>>>   |(3) Auth + Consent      |
>>>   |---------------->|      |
>>>   |(4) redirect (code)     |
>>>   |<----------------|      |
>>> =3D=3D=3D User (RO) passes control back to User (requestor) =3D=3D=3D
>>>   |(5) get(code)    |      |
>>>   |-------->|       |      |
>>>   |         |(6) token (code)
>>>   |         |------>|      |
>>>   |         |(7) token     |
>>>   |         |<------|      |
>>>   |         |(8) ServiceRequest(token)
>>>   |         |------------->|
>>>   |         |(9) ServiceResponse
>>>   |         |<-------------|
>>>   |(10) ServiceResponse    |
>>>   |<--------|       |      |
>>>   +         +       +      +
>>>
>>> - RP orchestrates interaction between User and OP to enable the user to
>>> obtain the protected resource.
>>> - In step 1 & 10 User plays the role of the requestor of the resource.
>>> - In step 2 User-Browser is used to pass control from User (in his role
>>> as the requestor) to User (in his role as the RO)
>>> - In step 4 User-Browser is used to pass control from User (in his role
>>> as the RO) back to User (in his role as the requestor)
>>>
>>> When we are talking claims here, we are talking claims on the User (in
>>> his role as the RO). The OP does not have any interaction with the User=
 (in
>>> his role as the requestor). In the case of an App2App redirection, the =
OP
>>> can not even assert about the user agent of the User (requestor).
>>>
>>> If there is any claim the OP can provide, it is a claim on the User (RO=
).
>>>
>>> I hope this example clarifies the misunderstanding. Any attempt of
>>> bringing this double role of the User into GNAP will also bring this
>>> confusion. In order to keep this out of GNAP let us look for the right =
term
>>> for User (as a requestor) using the diagram displayed below.
>>>
>>> +----+  +------+  +---+  +---+  +---+
>>> |Reqs|  |Orchst|  |RS |  |GS |  |RO |
>>> +----+  +------+  +---+  +-+-+  +-+-+
>>>   |(1) ServiceRequest      |      |
>>>   |-------->|       |      |      |
>>>   |         |(2) ServiceIntent:AuthZChallenge
>>>   |         |<----->|      |      |
>>>   |         |       |      |      |
>>>   |         |(3) AuthZRequest(AuthZChallenge)
>>>   |         |------------->|      |
>>>   |         |       |      |(4) ConsentRequest:Grant
>>>   |         |       |      |<---->|
>>>   |         |(5) GrantAccess(AuthZ)
>>>   |         |<-------------|      |
>>>   |         |       |      |      |
>>>   |         |(6) ServiceRequest(AuthZ):ServiceResponse
>>>   |         |<----->|      |      |
>>>   |(7) ServiceResponse     |      |
>>>   |<--------|       |      |      |
>>>   +         +       +      +      +
>>>
>>> - Replacing the word User helps clarify the difference between both
>>> roles "Requestor" and "Resource Owner"
>>> - Renaming claim by attaching the Object/target of the claim (e.g.:
>>> RO-attributes, Requestor-Attributes, Orchestrator-Attributes) also help=
s
>>> identify the source of those attributes (GS, RS, Client):
>>>
>>> Best regards.
>>> /Francis
>>>
>>> On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt  wrote=
:
>>>
>>>> It is not clear to me what it matters if a Claim comes from an RS, or
>>>> from the GS, so I don't see a need to differentiate them.
>>>>
>>>> I would include verifiable credentials and user-bound keys as Claims.
>>>>
>>>> All the payment processing information I have seen has been in RAR.
>>>> When would the Client get payment processing directly from the GS?
>>>>
>>>> What is your example for distributed networks storage locations? If
>>>> what is stored is a statement about the user, then I would consider th=
at a
>>>> Claim as well.
>>>>
>>>> We disagree on how to map OIDC to GNAP.  The direct data is a claims
>>>> request, the data coming indirectly is an access token request.
>>>>
>>>>
>>>>
>>>> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer  wrote:
>>>>
>>>>> Since we=E2=80=99re already talking about returning claims as direct =
data as
>>>>> well as a part of the resource API being protected, so we already nee=
d a
>>>>> way to differentiate the two kinds of items. Just calling it =E2=80=
=9Cclaims=E2=80=9D
>>>>> doesn=E2=80=99t help, because as you=E2=80=99ve pointed out they coul=
d show up in both
>>>>> places. So yes, defining that difference is something we should worry=
 about
>>>>> now, even if the core protocol only uses it for claims.
>>>>>
>>>>> The two forms of direct data that XYZ returns are subject identifiers
>>>>> (a subset of identity claims) and assertions =E2=80=94 the latter bei=
ng a container
>>>>> not just for identity claims but also authentication information and =
other
>>>>> elements. Assertions are not claims themselves.
>>>>>
>>>>> Other use cases that have been brought up include verifiable
>>>>> credentials and proofs, user-bound keys, payment processing informati=
on,
>>>>> and distributed network storage locations. I=E2=80=99m sure there are=
 a lot more.
>>>>> To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D but not=
 subsets of =E2=80=9Cclaims=E2=80=9D.
>>>>> GNAP shouldn=E2=80=99t be defining what all of these look like, but i=
t should
>>>>> define a way to talk about them.
>>>>>
>>>>> I think different top-level request objects are better suited for
>>>>> different query semantics. Like, for example, the OIDC =E2=80=9Cclaim=
s=E2=80=9D request,
>>>>> which allows targeting of its claims information into different retur=
n
>>>>> buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D request a=
t the very least. I
>>>>> don=E2=80=99t think GNAP should define how to do this specific combin=
ation, that
>>>>> should be for OIDF to debate and apply. The same with a DID service b=
ased
>>>>> query, or Presentation Exchange [1], or anything else that people wan=
t to
>>>>> come up with.
>>>>>
>>>>> In my view, GNAP should define query structures for two things: right=
s
>>>>> that get tied to an access token and data that comes back directly to=
 the
>>>>> client. For the latter, I think we can do some very limited and very =
useful
>>>>> specific items, which is what I=E2=80=99ve put into XYZ.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> [1] https://identity.foundation/presentation-exchange/
>>>>>
>>>>> On Jul 24, 2020, at 3:58 PM, Dick Hardt  wrote:
>>>>>
>>>>> I agree we want GNAP to be a strong foundation.
>>>>>
>>>>> Do you have an example of other "direct data"? If so, do you expect i=
t
>>>>> to be defined in the core protocol?
>>>>>
>>>>> I would expect an extension for other "direct data" to define top
>>>>> level objects, and an appropriate definition for that "direct data".
>>>>>
>>>>> My "do we need to worry about it now" comment was on creating a
>>>>> generic term for "direct data". Unless we are solving those now, we c=
an let
>>>>> further work define that "direct data" explicitly.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> =E1=90=A7
>>>>>
>>>>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer 
>>>>> wrote:
>>>>>
>>>>>> Yes, I do think we need to worry about it to the extent that we are
>>>>>> not creating something that is over-fit to a limited set of use case=
s.
>>>>>>
>>>>>> GNAP should be a foundation that many amazing new things can be buil=
t
>>>>>> on top of.
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt  wrote=
:
>>>>>>
>>>>>> Justin, thanks for clarifying.
>>>>>>
>>>>>> What are some examples of other "direct data" that the GS may return=
?
>>>>>> If it is not in core GNAP, do we need to worry about now? We can the=
n give
>>>>>> the direct data from the GS that is not a claim, an appropriate name=
 in
>>>>>> that document.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer 
>>>>>> wrote:
>>>>>>
>>>>>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m =
saying. I agree
>>>>>>> that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*.=
 But the AS could return
>>>>>>> other data directly to the client that isn=E2=80=99t about the user=
. Those aren=E2=80=99t
>>>>>>> =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =
=E2=80=9Cclaims=E2=80=9D can come back
>>>>>>> from places other than directly, then we shouldn=E2=80=99t call eve=
rything that
>>>>>>> comes back a =E2=80=9Cclaim=E2=80=9D.
>>>>>>>
>>>>>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean w=
hat it already means and
>>>>>>> come up with a new word to mean =E2=80=9Cthings that come back dire=
ctly from the
>>>>>>> AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99=
s more complete definitions, but
>>>>>>> to simplify:
>>>>>>>
>>>>>>> Claims:
>>>>>>> - information about the user
>>>>>>> - can come back directly from the AS
>>>>>>> - can come back in a resource from the RS
>>>>>>>
>>>>>>> Resource:
>>>>>>> - Returned from an RS
>>>>>>> - Protected by access token
>>>>>>> - Could contain claims about the user
>>>>>>>
>>>>>>> Direct data (or some better name):
>>>>>>> - Returned directly from AS
>>>>>>> - Could contain claims about the user
>>>>>>>
>>>>>>> I think the problem is that some people are using =E2=80=9Cclaims=
=E2=80=9D to mean
>>>>>>> #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=E2=
=80=99s important to
>>>>>>> remember, when talking about OIDC, that an IdP in OIDC combines an =
AS and
>>>>>>> an RS into one entity for identity information. There can be other =
RS=E2=80=99s as
>>>>>>> well, and there usually are in the wild, but the one defined by OID=
C is the
>>>>>>> UserInfo Endpoint. The fact that it returns user data doesn=E2=80=
=99t make it any
>>>>>>> less of an RS.
>>>>>>>
>>>>>>>  =E2=80=94 Justin
>>>>>>>
>>>>>>> * In the wider context of things like the information claims inside
>>>>>>> a JWT, the claims could be about literally anything, but that=E2=80=
=99s not what
>>>>>>> we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s=
 being used.
>>>>>>>
>>>>>>>
>>>>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt 
>>>>>>> wrote:
>>>>>>>
>>>>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly fro=
m
>>>>>>> the OP in an ID Token, or the Client can obtain Claims using an acc=
ess
>>>>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>>>>
>>>>>>> The Claims are about the User (not a RO).
>>>>>>>
>>>>>>> In XAuth, I'm proposing the Client may obtain bare claims from the
>>>>>>> GS directly in addition to the mechanisms in ODIC.
>>>>>>>
>>>>>>> So I don't think we are changing the definition of Claim from how i=
t
>>>>>>> has been used in OIDC, and I fail to see any reason to NOT use Clai=
m.
>>>>>>>
>>>>>>> Justin: you allude to Claims being about a party other than the
>>>>>>> User. Would you provide an example?
>>>>>>>
>>>>>>> /Dick
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>> UserInfo Endpoint
>>>>>>> Protected Resource that, when presented with an Access Token by the
>>>>>>> Client, returns authorized information about the End-User represent=
ed by
>>>>>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MU=
ST use
>>>>>>> the https scheme and MAY contain port, path, and query parameter co=
mponents.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =E1=90=A7
>>>>>>>
>>>>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I want to focus on one aspect here:
>>>>>>>>
>>>>>>>>
>>>>>>>>> A Claim is a well understood term in the field. We should use it.
>>>>>>>>> It is still a Claim if it comes directly from the GS or from an R=
S.
>>>>>>>>>
>>>>>>>> I do not understand why a Resource release by an RS shall be h to
>>>>>>>> as a claim, even if the content of the Resource is an assertion. I=
t will
>>>>>>>> lead to confusion. If we limit claims to information GS releases i=
nto
>>>>>>>> Token, User Info, and other objects it returns, this will help sep=
arate
>>>>>>>> responsibilities between GS and RS. As soon as RS services and inf=
ormation,
>>>>>>>> this is called a Resource, no matter the nature of the content of =
that
>>>>>>>> information.
>>>>>>>>
>>>>>>>>
>>>>>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cc=
laim=E2=80=9D in the way
>>>>>>>> that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could =
come back through an RS =E2=80=94 but in
>>>>>>>> the context of GNAP, that makes it a resource. So we need a differ=
ent word
>>>>>>>> for data coming back directly from the AS to the client. Sometimes=
 it=E2=80=99s
>>>>>>>> going to be about the user, and that=E2=80=99s what we=E2=80=99re =
going to focus on here,
>>>>>>>> but since you can also get information about the user from a resou=
rce we
>>>>>>>> can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this=
 has been at the heart of a lot
>>>>>>>> of confusion in recent threads, as well as confusion about the sco=
pe of the
>>>>>>>> inclusion of identity in the GNAP protocol.
>>>>>>>>
>>>>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already =
does, and let=E2=80=99s find a
>>>>>>>> way to differentiate between when an item, claim or otherwise,  co=
mes as
>>>>>>>> part of a resource and when it comes back directly. This is an imp=
ortant
>>>>>>>> differentiating feature for GNAP.
>>>>>>>>
>>>>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in lo=
ve with:
>>>>>>>>
>>>>>>>>  - direct data
>>>>>>>>  - properties
>>>>>>>>  - details
>>>>>>>>  - statements
>>>>>>>>
>>>>>>>> The important thing here is that it=E2=80=99s not necessarily :abo=
ut: the
>>>>>>>> RO, and that it is :not: in a resource.
>>>>>>>>
>>>>>>>> Any other thoughts?
>>>>>>>>
>>>>>>>>  =E2=80=94 Justin
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>> --
>>> 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/
>

--00000000000092a79605ab645442
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Jul 26, 2020 at 6:45 PM Franc=
is Pouatcha <fpo@adorsys.de> wr=
ote:
Hello Dick,

On Sun, Jul 26, 2020 at 9:14 PM Dick Hard=
t <dick.hardt@=
gmail.com> wrote:
Hi Francis

User is a well un=
derstood term in OIDC and OAuth -- and User means the same in both.=C2=A0

Resource Owner is who owns the resource,=
 and the term is introduced for when the User is NOT the Resource Owner.=C2=
=A0
This distinction is what makes it confusin=
g as we are comparing an Entity (the User) to a Role (the RO). We need two =
roles.

Or we could think =
of them all as entities. The RO is the entity that owns the resource. The U=
ser is the human that is using the Client.=C2=A0
=C2=A0
=C2=A0

I also think that Client an=
d Resource Server are well understood terms.
L=
ooks like contributors on the list still need clarification on=C2=A0the &qu=
ot;orchestration" role of a client.

When I think of orchestration, I think of coordinating,=C2=
=A0which is not what I think the=C2=A0Client is doing. The Client wants to =
consume the Claims and the Resources (combined are a Grant). The Client req=
uests the Grant from the Grant Server. Where is the orchestration?
=C2=A0

It is not clear to me why we w=
ould want to reinvent these terms. Reading over your flows, I think it woul=
d be useful=C2=A0to understand the requirements you have for your use case,=
 otherwise I fear we will be talking past each other.
The oAuth flow is there as a memo. The other flow is what I propose=
d before. Is there to emphasize we need to work on roles and not on entitie=
s. It is not a suggestion=C2=A0to rename=C2=A0well known idioms. It is an a=
ttempt=C2=A0to give=C2=A0them a proper definition in the context of this pr=
otocol. Definition based on their roles in the protocol flows.
<=
/div>

I'd like to take a step back and =
understand the requirements. We are deep into solutions.
=C2=A0

Best regards.
/Francis=


/Dick

3D""=E1=90=
=A7

On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Below my opinion=C2=A0on the term Claim:

Start=
ing with illustration of parties/roles:

User:=C2=A0
This word is misleading because of its dou=
ble role in oAuth2 and OIDC (see below). In GNAP let us have the User play =
only the role of a requestor. (from Justin reference to "Requesting Pa=
rty").

Client:
This is also tightly=C2=A0bound to the oAuth2 and OIDC. The real purpose o=
f this role is to orchestrate resource access on behalf of the "Reques=
tor". Let us call this for now the "Orchestrator"

Resource Owner (RO):
This is =
IMO the most correct word in the entire protocol. Authorisation is always a=
bout the owner of something granting access to a requestor. It really=C2=A0=
does not matter if a human interaction is involved. We will have to forget =
oAuth2 and OIDC of also calling this a User.

Grant Server:=C2=
=A0
Even though the definition of=
 the UserInfo endpoint in OIDC as a protected resource hazardously makes an=
 OP an RS, we shall not repeat the same mistake here. We need a clear separ=
ation between roles of GS and RS without overlapping.

Resourc=
e Server: services resources.
Unless I got=C2=A0it wrong, GNA=
P is about grant negotiation and authorization. This means:

GNAP is about some party requesting access to some resources.
GNAP is about the resource owner con=
senting access to that resource.
=
GNAP is about defining the infrastructure that allows the requesting party =
to access a resource.=C2=A0

<=
/font>
GNAP designs this infrastructure =
around:
- an orchestrator (what w=
e refer to as a client)
- an gran=
t manager (what we refer to as a GS/AS)
- the custodian of the resource (what we call a RS)

As=
 you see:
- The word User does no=
t appear here, and is not relevant as the focus=C2=A0is on authorizing acce=
ss to a resource.
- The word Clai=
m is as well absent.

<=
/div>
Claim related to RO:
The word Claim might start getting visible if the or=
chestrator (a.k.a. Client) or the custodian (a.k.a RS) needs some additiona=
l information on the RO to proceed with the access control decision. These =
claims refer to assertions of attributes or properties of the RO. These cla=
ims are issued by the GS as the GS manages interaction with the RO (see bel=
ow). In this first place information about the requesting party (erroneously.k.a. User) is not relevant to the negotia=
tion and provisioning framework. Let us call this sort of claim "RO-At=
tributes". A better name is welcome.

Some advanced resou=
rce provisioning frameworks might require knowledge on attributes of the re=
questing party (e.k.a User). These attributes shall be collected by the=C2=
=A0orchestrator (a.k.a Client) and added to the resource request. There is =
no way the GS can collect these attributes as the GS role has no interactio=
n with the requesting party (e.k.a User).=C2=A0Let us call this sort of cla=
im "Requestor-Attributes". A better name will be welcome.<=
/div>

Some assertions are even related to the orchestrator=C2=A0(a.k.a Cli=
ent) itself. This is the case of the public key of an orchestrator=C2=A0use=
d by the GS to "sender constrain" an access token. Let us call th=
is type of claim "Orchestrator-Attributes".

This is=
 a sample mapping of OIDC.

+----+ =C2=A0 =C2=A0+---+ =C2=A0 +=
---+ =C2=A0+---+
|User| =C2=A0 =C2=A0|RP | =C2=A0 |OP | =C2=A0|RS |
+=
----+ =C2=A0 =C2=A0+---+ =C2=A0 +-+-+ =C2=A0+---+
=C2=A0 |(1) ServiceReq=
uest =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |-------->| =C2=A0 =C2=A0 =C2=A0 | =
=C2=A0 =C2=A0 =C2=A0|
=C2=A0 |(2) redirect=C2=A0 =C2=A0 =C2=A0| =C2=A0 =
=C2=A0 =C2=A0|
=C2=A0 |<--------| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=
=A0 =C2=A0|
=3D=3D=3D User (reque=
stor) passes control to User (RO) =3D=3D=3D
=C2=A0 |(3) Auth + Consent =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |----=
------------>| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |(4) redirect (code) =C2=
=A0 =C2=A0 |
=C2=A0 |<----------------| =C2=A0 =C2=A0 =C2=A0|<=
/div>
=3D=3D=3D User (RO) passes control back =
to User (requestor) =3D=3D=3D
=C2=A0 |(5) get(code) =C2=A0 =C2=A0| =C2=
=A0 =C2=A0 =C2=A0|
=C2=A0 |-------->| =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) token (code=
)
=C2=A0 | =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) token =C2=A0 =C2=A0 |
=C2=
=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<------| =C2=A0 =C2=A0 =C2=A0|
=C2=
=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(8) ServiceRequest(token)
=C2=A0 | =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |------------->|
=C2=A0 | =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 |(9) ServiceResponse
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
|<-------------|
=C2=A0 |(10) 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+=


- RP orchestrates interaction between User and OP to ena=
ble the user to obtain the protected resource.
- In step 1 & 10 User plays the role of the requestor of=
 the resource.
- In step 2 User-B=
rowser is used to pass control from User (in his role as the requestor) to =
User (in his role as the RO)
- In=
 step 4=C2=A0User-Browser is used to pass control from User (in his role as=
 the RO) back to=C2=A0User (in his role as the requestor)
=

Whe=
n we are talking claims here, we are talking claims on the User (in his rol=
e as the RO). The OP does not have any interaction with the User (in his ro=
le as the requestor). In the case of an App2App redirection, the OP can not=
 even assert about the user agent of the User (requestor).

If=
 there is any claim the OP can provide, it is a claim on the User (RO).

I hope this example clarifies the misunderstanding. Any attempt =
of bringing this double role of the User into GNAP will also bring this con=
fusion. In order to keep this out of GNAP let us look for the right term fo=
r User (as a requestor) using the diagram displayed below.

+-=
---+ =C2=A0+------+ =C2=A0+---+ =C2=A0+---+ =C2=A0+---+
|Reqs| =C2=A0|Or=
chst| =C2=A0|RS | =C2=A0|GS | =C2=A0|RO |
+----+ =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 |(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 |(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|(4) ConsentRequ=
est: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 =
|(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 |(6) ServiceRequest(AuthZ):ServiceRespons=
e
=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+=


- Replacing the word User helps clarify the difference b=
etween both roles "Requestor" and "Resource Owner"
- Renaming claim by attaching the Obj=
ect/target of the claim (e.g.: RO-attributes, Requestor-Attributes, Orchest=
rator-Attributes) also helps identify the source of those attributes (GS, R=
S, Client):

Best regards.
/Franci=
s

On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt <dick.hardt@gmail.com> wrote:
<=
div>It is not clear to me what it matters if a Claim comes from an RS, or f=
rom the GS, so I don't see a need to differentiate them.

=

I would include verifiable credentials and user-bound keys as Cl=
aims.

All the payment processing information I hav=
e=C2=A0seen has been in RAR. When would=C2=A0the Client get payment process=
ing directly from the GS?

What is your example for=
 distributed networks storage locations? If what is stored is a statement a=
bout the user, then I would consider that a Claim as well.

We disagree on how to map OIDC to GNAP.=C2=A0 The direct data is a=
 claims request, the data coming indirectly is an access token request.



On Fri, Jul 24, 2020 at 1:39 PM Justin Rich=
er <jricher@mit.edu=
> wrote:
=

Since we=E2=80=99re already talking about returning claims as direct d=
ata as well as a part of the resource API being protected, so we already ne=
ed a way to differentiate the two kinds of items. Just calling it =E2=80=9C=
claims=E2=80=9D doesn=E2=80=99t help, because as you=E2=80=99ve pointed out=
 they could show up in both places. So yes, defining that difference is som=
ething we should worry about now, even if the core protocol only uses it fo=
r claims.

The two forms of direct data that XYZ returns =
are subject identifiers (a subset of identity claims) and assertions =E2=80=
=94 the latter being a container not just for identity claims but also auth=
entication information and other elements. Assertions are not claims themse=
lves.=C2=A0

Other use cases that have been brought=
 up include verifiable credentials and proofs, user-bound keys, payment pro=
cessing information, and distributed network storage locations. I=E2=80=99m=
 sure there are a lot more. To me, these are subsets of the =E2=80=9Cdirect=
 data=E2=80=9D but not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=
=80=99t be defining what all of these look like, but it should define a way=
 to talk about them.

I think different top-level r=
equest objects are better suited for different query semantics. Like, for e=
xample, the OIDC =E2=80=9Cclaims=E2=80=9D request, which allows targeting o=
f its claims information into different return buckets. This overlaps with =
the =E2=80=9Cresources=E2=80=9D request at the very least. I don=E2=80=99t =
think GNAP should define how to do this specific combination, that should b=
e for OIDF to debate and apply. The same with a DID service based query, or=
 Presentation Exchange [1], or anything else that people want to come up wi=
th.

In my view, GNAP should define query structure=
s for two things: rights that get tied to an access token and data that com=
es back directly to the client. For the latter, I think we can do some very=
 limited and very useful specific items, which is what I=E2=80=99ve put int=
o XYZ.

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

[1]=C2=A0https://identity.foundation/presentation-exch=
ange/

On Jul 24, 2020, at 3:=
58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I a=
gree we want GNAP to be a strong foundation.=C2=A0

Do yo=
u have an example of other "direct data"? If so, do you expect it=
 to be defined in the core protocol?

I would expec=
t an extension for other "direct data" to define top level object=
s, and an appropriate definition for that "direct data".

My "do we need to worry about it now" comment wa=
s on creating a generic term for "direct data". Unless we are sol=
ving those now, we can let further work define that "direct data"=
 explicitly.




=3D""=E1=90=A7

On Fri, Jul 24, 2020 at 12:42 PM =
Justin Richer <jric=
her@mit.edu> wrote:
Yes, I do think we need to worry about it to the extent tha=
t we are not creating something that is over-fit to a limited set of use ca=
ses.=C2=A0

GNAP should be a foundation that many amazing=
 new things can be built on top of.

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

On Jul 24, 2020, at 3:06 =
PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin=
, thanks for clarifying.

What are some examples of other=
 "direct data" that the GS may return? If it is not in core GNAP,=
 do we need to worry about now? We can then give the direct data from the G=
S that is not a claim, an appropriate name in that document.

=



On Fri, Jul 24, 2020 at 11:46 AM Justin Richer <jricher@mit.edu> w=
rote:
Dick:=
 No, I think you=E2=80=99re misunderstanding what I=E2=80=99m saying. I agr=
ee that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But =
the AS could return other data directly to the client that isn=E2=80=99t ab=
out the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=80=9D by the classica=
l definition. Also since =E2=80=9Cclaims=E2=80=9D can come back from places=
 other than directly, then we shouldn=E2=80=99t call everything that comes =
back a =E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m arguing that=
 we keep =E2=80=9Cclaims=E2=80=9D to mean what it already means and come up=
 with a new word to mean =E2=80=9Cthings that come back directly from the A=
S=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s more co=
mplete definitions, but to simplify:

Claims:
=

	- information about the u=
ser
	- can come back =
directly from the AS
	- can come back in a resource from the RS

Resourc=
e:
	- Returned from a=
n RS
	- Protected by =
access token
	- Could=
 contain claims about the user

Direct data (or som=
e better name):
	- Re=
turned directly from AS
	- Could contain claims about the user

I think =
the problem is that some people are using =E2=80=9Cclaims=E2=80=9D to mean =
#1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s =
important to remember, when talking about OIDC, that an IdP in OIDC combine=
s an AS and an RS into one entity for identity information. There can be ot=
her RS=E2=80=99s as well, and there usually are in the wild, but the one de=
fined by OIDC is the UserInfo Endpoint. The fact that it returns user data =
doesn=E2=80=99t make it any less of an RS.

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

* In the wider context of things like t=
he information claims inside a JWT, the claims could be about literally any=
thing, but that=E2=80=99s not what we=E2=80=99re discussing here and it=E2=
=80=99s not how it=E2=80=99s being used.


On Jul 24, 2020, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com>=
 wrote:

In OpenID Connect (OIDC), the Client=
 can obtain Claims directly from the OP in an ID Token, or the Client can o=
btain Claims using an access token to call the UserInfo endpoint, a Protect=
ed Resource[1].

The Claims are about the User (not a RO)=
.

In XAuth, I'm proposing the Client may obtai=
n bare claims from the GS directly in addition to the mechanisms in ODIC.

So I don't think we are changing the definition=
 of Claim from how it has been used in OIDC, and I fail to see any reason t=
o NOT use Claim.

Justin: you allude to Claims bein=
g about a party other than the User. Would you provide an example?

/Dick

[1]
UserInfo Endpoint=

Protected Resource that, when presented with an Access Token by =
the Client, returns authorized information about the End-User represented b=
y the corresponding Authorization Grant. The UserInfo Endpoint URL MUST use=
 the https scheme and MAY contain port, path, and query parameter component=
s.



3D""=E1=90=A7

On Fri, Jul 24, 2020 at 5:58 AM Justin Richer=
 <jricher@mit.edu> wrote:
I want to focus on one aspect here:


A Claim is =
a well understood term in the field. We should use it. It is still a Claim =
if it comes directly from the GS or from an RS.=C2=A0
I do not understand why a Resource release by an RS shall be h to a=
s a claim, even if the content of the Resource is an assertion. It will lea=
d to confusion. If we limit claims to information GS releases into Token, U=
ser Info, and other objects it returns, this will help separate responsibil=
ities between GS and RS. As soon as RS services and information, this is ca=
lled a Resource, no matter the nature of the content of that information.

This is exactly why I don=
=E2=80=99t think we should use =E2=80=9Cclaim=E2=80=9D in the way that we=
=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come back throug=
h an RS =E2=80=94 but in the context of GNAP, that makes it a resource. So =
we need a different word for data coming back directly from the AS to the c=
lient. Sometimes it=E2=80=99s going to be about the user, and that=E2=80=99=
s what we=E2=80=99re going to focus on here, but since you can also get inf=
ormation about the user from a resource we can=E2=80=99t just call it a =E2=
=80=9Cclaim=E2=80=9D. I think this has been at the heart of a lot of confus=
ion in recent threads, as well as confusion about the scope of the inclusio=
n of identity in the GNAP protocol.

So let=E2=80=
=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does, and let=E2=80=
=99s find a way to differentiate between when an item, claim or otherwise,=
=C2=A0=C2=A0comes as part of a resource and when it comes back directly. Th=
is is an important differentiating feature for GNAP.

Some straw man ideas, none of which I=E2=80=99m particularly in love wit=
h:

=C2=A0- direct data
=C2=A0- propertie=
s
=C2=A0- details
=C2=A0- statements

The important thing here is that it=E2=80=99s not necessarily :about=
: the RO, and that it is :not: in a resource.

Any other=
 thoughts?

=C2=A0=E2=80=94 Justin












-- 




-- 



--00000000000092a79605ab645442--


From nobody Mon Jul 27 00:49: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 C6B073A177E for ; Mon, 27 Jul 2020 00:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level: 
X-Spam-Status: No, score=-1.619 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.267, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=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 kAp9LTZTNJse for ; Mon, 27 Jul 2020 00:49:27 -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 6B4B13A1781 for ; Mon, 27 Jul 2020 00:49:25 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d26 with ME id 87pN230012bcEcA037pNrk; Mon, 27 Jul 2020 09:49:23 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Mon, 27 Jul 2020 09:49:23 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt 
Cc: txauth@ietf.org
References:       <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>       
From: Denis 
Message-ID: <7b313658-f7f1-dad1-33aa-7d2107436856@free.fr>
Date: Mon, 27 Jul 2020 09:49: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="------------C04F4BBCDF80D6707A7F9D13"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 27 Jul 2020 07:49:32 -0000

This is a multi-part message in MIME format.
--------------C04F4BBCDF80D6707A7F9D13
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Dick,

The floor is yours.

Would you explain how you would handle the use case of a student 
registering to a new University ?

Would you also elaborate why in my explanations below, you think that 
"the University's registration system is the Client, not a Resource 
Server" ?

Denis

> Hi Denis
>
> I would think in your example below, that the 
> University's registration system is the Client, not a Resource Server.
>
> Have a good night's sleep!
>
>
>
> On Fri, Jul 24, 2020 at 12:04 PM Denis  > wrote:
>
>     Hi Dick,
>
>     In order to send back a quick reply tonight, I will only respond
>     to one of your questions:
>
>         [Denis] How would be the data flow when access tokens from two
>         GSs are needed by a RS ?
>
>         [Dick] I don't know of a use case where two tokens would be
>         needed by an RS. Would you elaborate?
>
>     I already described on the list the case of a student registering
>     to a new University.
>
>     First, the student connects to the RS from the new University and
>     opens an account
>     (at this time the student is using a pseudo and a private key to
>     authenticate). He fills some forms
>     and indicate its citizenship, his home address and his graduation
>     in his current university.
>
>     When he is finished, he indicates that he wants to perform a
>     Registration operation.
>
>     From the information gathered in the forms, the RS informs the
>     client that it needs two access tokens:
>
>       * one to demonstrate that his name and current home address are
>         correct,and
>       * another one to demonstrate that he got a graduation from its
>         current University.
>
>     Depending upon the information captured in the forms, the RS also
>     indicates which ASs/GSs are acceptable
>     and which kind of attributes are requested.
>
>     The user consent and choice is performed by the client and once
>     approved by the student, two access tokens are separately requested.
>     Finally, two access tokens are presented to the RS while invoking
>     a Registration operation.
>
>     Note that the start of the story is to open an account, e.g. using
>     FIDO. The needs of the RS are only disclosed to the student once
>     he has filled some forms
>     and indicated that he wanted to perform a Registration operation.
>     Thus, the needs that are revealed by the RS are dependant both
>     upon the operation
>     that the student is willing to perform and the information
>     collected in the forms.
>
>     Denis
>
>>     Hi Denis, comments inserted ...
>>
>>     On Fri, Jul 24, 2020 at 9:08 AM Denis >     > wrote:
>>
>>         Hi Dick,
>>
>>         draft-hardt-xauth-protocol-13 describes a solution without
>>         clearly stating what the problem(s) to be solved is/are.
>>
>>
>>     I agree that the problem description is not as crisp as I would
>>     like it to be. A challenge is that there is a broad spectrum of
>>     use cases solved by OAuth 2, and OpenID Connect, as well as the
>>     new use cases that are solved by GNAP.
>>
>>     That is why I am suggesting we gather some use cases so we have a
>>     common understanding of the problems that are in scope.
>>
>>
>>         At the moment, draft-hardt-xauth-protocol-13 includes a
>>         single figure on page 4 and from previous discussions I
>>         understood that
>>         it is no more up-to-date since the first data flow is now a
>>         contact with a RS. The reason(s) for the GS to contact a RO
>>         has still not
>>         been explained (since the inputs and outputs are not
>>         described). The discovery information made available at
>>         various steps at the RS
>>         is not described.
>>
>>
>>     I have made no updates as we are in a quiet period prior to the
>>     WG meeting next week when documents cannot be updated.
>>
>>
>>         Figure 4 shows only a single RS. Is the relaying of one
>>         operation by that RS to a second RS in the scope of this
>>         document ?
>>         If yes, how is it handled ?
>>
>>
>>     I view that as an advanced use case that would be covered in a
>>     separate document.
>>
>>
>>         Figure 4 shows only a single GS. How would be the data flow
>>         when access tokens from two GSs are needed by a RS ?
>>
>>
>>     I don't know of a use case where two tokens would be needed by an
>>     RS. Would you elaborate?
>>     The RS being able to accept tokens from two different GSes is
>>     covered, but the Client is only using a token from one GS at a time.
>>
>>
>>         What we need first is not a set of "use cases" but a clear
>>         model with a data flows and a list of its
>>         properties/characteristics.
>>
>>
>>     I disagree. The use cases describe the problems we are looking to
>>     solve. The data flows are part of the solution. For example, from
>>     my understanding of your use case, you don't want the GS to have
>>     visibility into the User's activity. Am I correct that this is
>>     one of your requirements for your use case?
>>
>>         Then after, we can understand much better which use cases
>>         can/will be supported. For example, shall a RS (or its RO) have
>>         prior relationships with the GS ? What is the
>>         difference/implications when it has or it hasn't ?
>>
>>         In order to have a fair comparison, we should try to list
>>         model properties/characteristics.
>>
>>         At the moment, the model I have described including the data
>>         flows is clear. The discovery information made available by a
>>         RS is clear.
>>         I have not listed all its properties/characteristics of that
>>         model, but I am pretty sure that you already have a flavour
>>         of it.
>>
>>         In the mean time, it would be nice if you could show using
>>         two figures:
>>
>>           * the case of the relaying of one operation by one RS to a
>>             second RS (if it is in the scope of your document),
>>           * the case where access tokens from two GSs are needed by
>>             one RS (if it is in the scope of your document).
>>
>>
>>     See above
>>
>>          *
>>
>>
>>         Denis
>>
>>>         Hi Denis
>>>
>>>         I think it would be useful to take a step back and for you
>>>         to describe your use case.
>>>         After that, we can explore the different ways that your use
>>>         case can be addressed.
>>>
>>>         Looking at your previous communication, it describes the
>>>         solution, and the justification,
>>>         but it is not clear what use cases you are needing to solve.
>>>
>>>         /Dick
>>>
>>>
>>>         ᐧ
>>>
>>>         On Wed, Jul 22, 2020 at 9:34 AM Denis >>         > wrote:
>>>
>>>             Hello Dick,
>>>
>>>             I have identified the reason of the major difference
>>>             between our two approaches.
>>>
>>>             Access control may be performed using either ACLs
>>>             (Access Control Lists) or Capabilities.
>>>
>>>             _Note _: a capability identifies a resource and an
>>>             allowed operation that can be performed on that resource.
>>>
>>>             You are advocating a Capabilities approach while I am
>>>             advocating an ACL approach.
>>>
>>>             The capabilities approach allows the GS to trace every
>>>             operation performed by the users on any RS known by a GS.
>>>             The management of these capabilities is made via the GS
>>>             or at the GS by the various ROs. If the management is made
>>>             via the GS, then a trusted communication channel needs
>>>             to be established with every RO. If the management is made
>>>             at the GS, then an authentication mechanism needs to be
>>>             established with every RO. In the last case, the GS has the
>>>             ability to know all the capabilities of the users
>>>             whether they are used or not. The less that can be said
>>>             is that this model
>>>             is not privacy friendly.
>>>
>>>             With the ACL approach, a RO directly manages an ACL
>>>             placed in front of each RS. The AccessControl Decision
>>>             Function
>>>             (ADF) at the RS is able to keep track from prior
>>>             decisions. The GS is kept ignorant of the content of
>>>             these ACLs and only
>>>             delivers to its clients attributes that are placed into
>>>             access tokens. Such a model may be privacy friendly.
>>>
>>>             Other comments are between the lines prefixed with [Denis].
>>>
>>>>
>>>>             On Tue, Jul 21, 2020 at 11:26 AM Denis
>>>>             > wrote:
>>>>
>>>>                 Hello Dick,
>>>>
>>>>                 Thank you for your feedback. Comments are between
>>>>                 the lines.
>>>>
>>>>>                 comments inserted ...
>>>>>
>>>>>                 On Tue, Jul 21, 2020 at 6:03 AM Denis
>>>>>                 >
>>>>>                 wrote:
>>>>>
>>>>>                     Hello Dick,
>>>>>
>>>>>                     I duplicate the most important comment at the
>>>>>                     beginning of this email:
>>>>>
>>>>>                         You are considering using an access
>>>>>                         control model to build a**workflow model.
>>>>>                         **
>>>>>                         While it may be interesting to define a
>>>>>                         workflow model, this should be considered
>>>>>                         as a separate and different work item.
>>>>>
>>>>>                     See the other comments between the lines.
>>>>>
>>>>>>                     On Mon, Jul 20, 2020 at 2:05 AM Denis
>>>>>>                     >>>>>                     > wrote:
>>>>>>
>>>>>>                         Hi Dick,
>>>>>>
>>>>>>>                         On Fri, Jul 17, 2020 at 9:21 AM Denis
>>>>>>>                         >>>>>>                         > wrote:
>>>>>>>
>>>>>>>                             Hello Francis and Dick,
>>>>>>>
>>>>>>>                             The good news first: we are making
>>>>>>>                             some progress. We are now close to
>>>>>>>                             an agreement with steps (1) up to (3),
>>>>>>>                             ... except that the place where the
>>>>>>>                             user consent is captured is not
>>>>>>>                             mentioned/indicated.
>>>>>>>
>>>>>>
>>>>>>                         This major question which is currently
>>>>>>                         left unanswered is where, when and how
>>>>>>                         the user consent is captured.
>>>>>>
>>>>>>
>>>>>>                     When is covered, per the sequence. How and
>>>>>>                     where are out of scope of what I drafted.
>>>>>
>>>>>                     It is clear that the "User consent and choice"
>>>>>                     is not currently addressed in the draft, but
>>>>>                     it should.
>>>>>                     The support of the "User consent and choice"
>>>>>                     has strong implications not only in the
>>>>>                     sequences of the exchanges
>>>>>                     but also by which entity it should be performed.
>>>>>
>>>>>                 "consent" is in the latest draft 7 times.
>>>>
>>>>                 "Consent" is present 5 times. The User consent is
>>>>                 different from the RO consent (when/if it is
>>>>                 required).
>>>>
>>>>                     The server acquires consent and authorization
>>>>                     from the user *and/**or resource owner **if
>>>>                     required.*
>>>>
>>>>                     User consent is *often required* at the GS.
>>>>                     GNAP enables a Client and GS to negotiate the
>>>>                     interaction mode for the GS to obtain consent.
>>>>
>>>>                     The GS *may *require explicit consent from the
>>>>                     RO or User to provide these to the Client.
>>>>
>>>>                 The User consent is not an alternative to the RO
>>>>                 consent. So using "and/or" in the first sentence is
>>>>                 incorrect.
>>>>
>>>>
>>>>             My language is sloppy there. Consent is always from the
>>>>             RO. The User may be the RO.
>>>
>>>             [Denis] No. Once again: The "/User consent/" is
>>>             different from what you call the "/RO consent/" (when/if
>>>             it is required).
>>>             The "RO consent" is not in fact a consent but the
>>>             release of a capability to a client by one of the many
>>>             R0s with which
>>>             the GS has relationships.
>>>
>>>>                 Since the second sentence is using the wording
>>>>                 "often required" there is no requirement to get the
>>>>                 User consent.
>>>>
>>>>             User consent may not be required. There may not be a
>>>>             User. The consent may have been gathered previously.
>>>
>>>             [Denis] In order to follow the privacy principles, a
>>>             "User consent" phase is required. The User is a natural
>>>             person.
>>>             A Client is called either by a User (i.e. a natural
>>>             person) or by a Client application.
>>>
>>>>                 The second sentence does not consider the
>>>>                 possibility to get the User consent in a place
>>>>                 different from the GS.
>>>>
>>>>             Agreed. But we do agree that the GS gets the consent,
>>>>             either directly from the RO, or from the Client (in
>>>>             your example).
>>>
>>>             [Denis] No. I disagree. In an ACL based systems, the GS
>>>             does not need to ask or receive any consent.
>>>             The client selects the set of attributes that it wants
>>>             to be inserted into an access token.
>>>             If the GS has the requested attributes, then it provides
>>>             them, otherwise it returns an error to the Client.
>>>
>>>>                 IMO, the User consent should be captured by the
>>>>                 Client, i.e. not by the GS.
>>>>                 The information used to obtain the User consent
>>>>                 should be standardized (... and it can be
>>>>                 standardized).
>>>>
>>>>>                 I think the abstract sequence as proposed by
>>>>>                 Francis is a great addition, and would clarify
>>>>>                 where consent is in the sequence.
>>>>
>>>>                 The current sketch does not illustrate the place
>>>>                 the User Consent is captured, in particular by the
>>>>                 Client.
>>>>
>>>>             It is an abstraction. The GS receives the consent. How
>>>>             consent is gathered is a detail that is dependent on
>>>>             the use case.
>>>
>>>             [Denis] I really wonder whether there is really a
>>>             "consent" to be received by the GS in both cases (i.e.
>>>             ACLs or Capabilities).
>>>
>>>               * For ACLs, the consent needs to be done by the Client.
>>>               * For Capabilities, the current description is not
>>>                 clear since the inputs and the outputs for this
>>>                 "consent" phase
>>>                 are not currently described in the draft.
>>>
>>>>>>                         Another important point to consider and
>>>>>>                         to explain is related to the assurances
>>>>>>                         that the user can obtain about
>>>>>>                         the respect of his choices. This point is
>>>>>>                         currently left unanswered in
>>>>>>                         draft-hardt-xauth-protocol-13.
>>>>>>
>>>>>                     This point is equally important: such
>>>>>                     assurance can only be obtained if the access
>>>>>                     token returned to the client
>>>>>                     is not considered to be opaque to the client.
>>>>>                     This is a necessary condition but not the
>>>>>                     single condition:
>>>>>                     the Client must also be in a position to
>>>>>                     capture/memorize the "User consent and choice"
>>>>>                     of the user in order to be able
>>>>>                     to verify it afterwards using the content of
>>>>>                     the access token(s).
>>>>>
>>>>>
>>>>>                 We disagree on this being a requirement for all
>>>>>                 use cases. It may be in some.
>>>>
>>>>                 OK. Then this means that there will be no sentence
>>>>                 in the draft such as :
>>>>                 "access tokens returned to the client are not
>>>>                 considered to be opaque to the client".
>>>>
>>>>
>>>>             For OAuth use cases, which GNAP supports, the access
>>>>             token is opaque to the Client. As you have noted, there
>>>>             are use cases where the access token is NOT opaque.
>>>
>>>             [Denis] Wait a second. There is no requirement to
>>>             support all OAuth use cases.
>>>             I believe that there is a requirement to support OAuth
>>>             2.0 ASs, while the clients may be different
>>>             and hence GNAP clients do not need to inherit of the
>>>             limitations of OAuth 2.0 clients.
>>>
>>>>>>
>>>>>>>                             If a RO needs to be involved and
>>>>>>>                             since a RO is directly associated
>>>>>>>                             with a RS, why can't it be directly
>>>>>>>                             queried
>>>>>>>                             by the appropriate RS after step (2)
>>>>>>>                             or later on ?
>>>>>>>
>>>>>>>
>>>>>>>                         Good question. Perhaps you can expand on
>>>>>>>                         a use case where that would be useful?
>>>>>>
>>>>>>                         Before I expand, would you be able to
>>>>>>                         explain first under which circumstances a
>>>>>>                         RO needs to be queried by a GS ?
>>>>>>                         How can the GS identify which RO to query ?
>>>>>>
>>>>>>                     If the User is the RO, then the GS knows who
>>>>>>                     to query.
>>>>>
>>>>>                     I still have difficulties to understand what
>>>>>                     you mean here.
>>>>>                     How could a GS know that "the User is the RO"
>>>>>                     ? If "the User is the RO", why does the GS
>>>>>                     needs to query the User ?
>>>>>
>>>>>
>>>>>                 To get consent?
>>>>
>>>>                 To get a "RO consent" to himself ???
>>>>
>>>>
>>>>             The GS needs consent from the RO. If the RO is the
>>>>             User, then consent from the RO is equivalent to consent
>>>>             from the User.
>>>
>>>             [Denis] See above.
>>>
>>>>
>>>>>>                     If the RO is a separate entity, then the GS
>>>>>>                     knows the RO from the RS being queried.
>>>>>
>>>>>                      ... and this gives the ability for the GS to
>>>>>                     log/trace all the RSs accessed by a given User
>>>>>                     and at which instant of time the access token
>>>>>                     has been granted.
>>>>>
>>>>>>                     An example is a user would like access to an
>>>>>>                     enterprise asset where a workflow is started
>>>>>>                     to gain approval, and an administrator or
>>>>>>                     manager provides consent.
>>>>>
>>>>>                     Thanks for this example. I finally understand
>>>>>                     what you have in mind: you are considering
>>>>>                     using an access control model to build a
>>>>>                     *workflow model*.
>>>>>                     While it may be interesting to define a
>>>>>                     workflow model, this should be considered as a
>>>>>                     *separate and different work item*.
>>>>>
>>>>>
>>>>>                 The actual workflow is out of scope.
>>>>
>>>>                 I am glad you agree with this. But this means that
>>>>                 your example was not appropriate to illustrate your
>>>>                 point.
>>>>
>>>>
>>>>             It illustrates a use case where the RO and User are not
>>>>             the same party, and why the GS needs to query the RO,
>>>>             which was your question if I understood it correctly.
>>>
>>>             [Denis] Since the inputs and the outputs for this "RO
>>>             consent" phase are not currently described in the draft,
>>>             the point is still unsolved.
>>>
>>>>                 As soon as there is a RO consent obtained at the
>>>>                 GS, the major problem is that the GS is able to act
>>>>                 as Big Brother.
>>>>                 If a RO consent is performed at the RS, then the GS
>>>>                 will not know who the RS is: it is then unable to
>>>>                 act as Big Brother,
>>>>                 even if it would enjoy to play that role.
>>>>
>>>>             In an enterprise use case, the GS's knowledge of who is
>>>>             accessing which RS is a feature.
>>>
>>>             Do you mean that it is "normal" in an enterprise that a
>>>             single point of control is able to trace all their
>>>             actions ?
>>>             From a security point of view, a single point of failure
>>>             will have dramatic consequences.
>>>
>>>>             In your use cases, it seems that the RO is the User.
>>>
>>>             I do hope that you have finally understood that, in my
>>>             use case, the RO is **not** the User.
>>>
>>>>             The GS knows the User is wanting to let a Client access
>>>>             something. If the access token is generic, and could be
>>>>             presented to any RS that provides a standardized function,
>>>>             then the GS does not know which RS is being accessed by
>>>>             a Client for the User. This seems to meet your privacy
>>>>             objectives. If not, what is wrong?
>>>
>>>             For security reasons, an access token needs to be
>>>             targeted (which does not necessarily mean that an
>>>             identifier of the RS shall be included into the access
>>>             token).
>>>
>>>>>                 if the admin grants access, then the access
>>>>>                 granted to the client changes.
>>>>>
>>>>>                     The model you propose may be suited for an
>>>>>                     enterprise environment but is not scalable
>>>>>                     over the Internet.
>>>>>
>>>>>                 It is one of the use cases we are working to address.
>>>>>
>>>>>                     What is needed is an access control model
>>>>>                     usable over the Internet with millions of RSs
>>>>>                     and thousands of ASs/GSs.
>>>>>
>>>>>                 I agree the model should also scale to internet
>>>>>                 scale.
>>>>
>>>>                 Fine. Another point on which we are in agreement.
>>>>
>>>>                 The model can scale to the Internet based on the
>>>>                 following assumptions:
>>>>
>>>>                     The flow starts with the steps (1) to (4) as
>>>>                     illustrated by Francis, i.e. the flow starts
>>>>                     with a contact with a RS.
>>>>
>>>>                 *+----+  +------+  +---+  +---+  +---+
>>>>                 |User|  |Client|  |RS |  |GS |  |RO |
>>>>                 +----+  +------+  +---+  +-+-+  +-+-+
>>>>                   |(1) Service Request   |      |
>>>>                   |-------->|       |      |      |
>>>>                   |         |(2) Service Intent   |
>>>>                   |         |------>|      |      |
>>>>                   |         |(3) AuthZ Challenge  |
>>>>                   |         |<------|      |      |
>>>>                   |         |(4) AuthZ Request    |
>>>>                   | |------------->|  |*
>>>>
>>>>                 The GS/AS does not need to have any prior
>>>>                 relationship with ROs and/or RSs.
>>>>
>>>>                 Furthermore, it is possible to prevent the GS to
>>>>                 act as Big Brother when the identity of the RS is
>>>>                 not disclosed to the GS.
>>>>
>>>>
>>>>             What happens after (4) above?
>>>
>>>             [Denis] The key point is that we first need to agree on
>>>             the first four exchanges. Do we ?
>>>
>>>             The fifth exchange is different whether ACLs or
>>>             Capabilities are being used.
>>>
>>>>>>>                             Which information is supposed to be
>>>>>>>                             presented to the RO ?
>>>>>>>                             Which information is supposed to be
>>>>>>>                             returned by the RO ?
>>>>>>>
>>>>>>>
>>>>>>>                         Just like how the user authenticates to
>>>>>>>                         an AS, how the AS and RO communicate is
>>>>>>>                         out of scope.
>>>>>>
>>>>>>                         At the moment, the usefulness of a
>>>>>>                         dialogue between a GS and a RO has not
>>>>>>                         been explained, nor demonstrated.
>>>>>>                         The question is about the functionality
>>>>>>                         of that dialogue in terms of input and
>>>>>>                         output information (and not about
>>>>>>                         the design of a protocol or of a user
>>>>>>                         interface). Anyway, AFAIU a dialogue
>>>>>>                         between a GS and a RO is optional.
>>>>>>
>>>>>>
>>>>>>                     See enterprise example above.
>>>>>
>>>>>                     It is not an access control example, but a
>>>>>                     workflow example.
>>>>>
>>>>>                     Access control has been defined a long time
>>>>>                     ago and the last edition of the model has been
>>>>>                     confirmed in year 1996: ISO/IEC 10181-3: 1996.
>>>>>                     "Information technology — Open Systems
>>>>>                     Interconnection — Security frameworks for open
>>>>>                     systems: Access control framework — Part 3".
>>>>>
>>>>>                     Two major functions have ben defined: an
>>>>>                     AccessControl Enforcement Function (AEF) and
>>>>>                     an AccessControl Decision Function(ADF).
>>>>>
>>>>>                         AccessControl Enforcement Function (AEF):
>>>>>                         A specialized function that is part of the
>>>>>                         access path between an initiator and a
>>>>>                         target on each access request and enforces
>>>>>                         the decision made by the ADF.
>>>>>
>>>>>                         AccessControl Decision Function (ADF) :
>>>>>                         A specialized function that makes access
>>>>>                         control decisions by applying access
>>>>>                         control policy rules to an access request,
>>>>>                         ADI (of initiators, targets, access requests,
>>>>>                         or that retained from prior decisions),
>>>>>                         and the context in which the access
>>>>>                         request is made.
>>>>>
>>>>>                     The role of the RO is to define the "access
>>>>>                     control policy rules" at the RS according to
>>>>>                     thecontext in which the access request is made.
>>>>>
>>>>>                 I'm pretty familiar with access control systems. :)
>>>>>
>>>>>                 I would say that the access control is happening
>>>>>                 at the RS. The client presents a token when
>>>>>                 accessing an API.
>>>>>                 The RS uses the token, and any policy required, to
>>>>>                 make an access decision.
>>>>
>>>>                 Fine. It looks like we are in agreement.
>>>>                 Unfortunately, this is not the case just below.
>>>>
>>>>>                 Here is flow:
>>>>>
>>>>>                 1) The Client requests access to an RS from the GS.
>>>>
>>>>                 No. We are no more in agreement. This is different
>>>>                 from the flow drawn by Francis.
>>>>
>>>>             My bad. Typo. I meant RO.
>>>>
>>>>>                 2) The GS queries the RS if access should be granted.
>>>>
>>>>                  No. The GS should not be forced to have a flow
>>>>                 with the RS.
>>>>
>>>>             Same mistake as above, I meant RO.
>>>>
>>>>>                 3) If access is granted, the GS creates an access
>>>>>                 token representing the granted access, and returns
>>>>>                 it to the Client.
>>>>
>>>>                 This model is by no way conformant to
>>>>                 ISO/IEC 10181-3: 1996
>>>>
>>>>             I'm unclear on why, or why it is even relevant.
>>>>
>>>>>                 4) The Client presents the access token to the RS
>>>>>                 to show it has been granted access.
>>>>
>>>>                 No. The client presents a token when accessing an
>>>>                 API. The RS uses the token, and any policy
>>>>                 required, to make an access decision.
>>>>                 The token never contains an information like
>>>>                 "Please grant an access to the holder of this token".
>>>>
>>>>             Let me provide more clarity in the sentence:
>>>>
>>>>             The Client presents the access token to the RS, to show
>>>>             the RS that the Client has been granted access to a
>>>>             resource at the RS by the GS.
>>>
>>>             [Denis] This time, please consider both the ACLs
>>>             approach and the Capabilities approach.
>>>
>>>>>                 A couple advantages of this model:
>>>>>                 - that the RS does not need to know much, if
>>>>>                 anything about the Client.
>>>>>                 - the access token MAY be self contained so that
>>>>>                 the Client does not need to query the GS on each
>>>>>                 access.
>>>>
>>>>                 There are so many disadvantages that I will not
>>>>                 list them.
>>>>
>>>>             Darn: I clearly was not firing on all cylinders when I
>>>>             typed this out. Let me correct:
>>>>
>>>>>             - the access token MAY be self contained so that the
>>>>>             RS does not need to query the GS on each access to the
>>>>>             RS by the Client.
>>>
>>>             [Denis] A few comments in the case of a capability approach:
>>>
>>>                 - for each GS, the RS needs to locally manage which
>>>                 operation(s) is/are allowed to it.
>>>
>>>                 - the GS needs to establish a trusted communication
>>>                 channel or an authentication mechanism with each RO
>>>                    (which is associated with an explicit RS
>>>                 identifier).
>>>
>>>                 - the GS could play the role of the RO and hence be
>>>                 in a position to issue any capability for any RS
>>>                 (without a "RO consent").
>>>
>>>                    The target of an attack will clearly be the GS.
>>>
>>>>>                 I would not say that GNAP is an access control
>>>>>                 protocol, as how the RS uses the token to
>>>>>                 determine access is out of scope.
>>>>
>>>>                 This is where we have a major discrepancy: how the
>>>>                 RS uses the token to determine access is *within*
>>>>                 the scope.
>>>>
>>>             [Denis] Do you agree or disagree ?
>>>>
>>>>                 The RS announces in advance to the client what it
>>>>                 needs so that the client can perform a a given
>>>>                 operation and if the client supplies the requested
>>>>                 attributes
>>>>                 obtained from some GS/AS(s) trusted by the RS, then
>>>>                 access to that RS is granted by the RS. If the RS
>>>>                 cannot perform the requested operation on its own,
>>>>                 then the client should be informed about some
>>>>                 requested attributes that need to be obtained from
>>>>                 some GS/AS(s) trusted by the next RS(s) in a chain
>>>>                 for subsequent operations. The User consent should
>>>>                 also be obtained before performing the chaining
>>>>                 operation.
>>>>
>>>>                 Chaining operations between RSs over the Internet
>>>>                 is within the scope (... and may be achieved).
>>>>
>>>             [Denis] Do you agree or disagree ?
>>>
>>>             Denis
>>>
>>>>>>>                         For many use cases, the User is the RO,
>>>>>>>                         and the interaction is through a user
>>>>>>>                         interface, not a machine protocol.
>>>>>>
>>>>>>                         Wait a second. You wrote "the User is the
>>>>>>                         RO". The User is attempting to make an
>>>>>>                         access to a RS by using a Client.
>>>>>>                         _That_ User is not the RO of the RS.
>>>>>>
>>>>>>                     The user being the RO is the initial use case
>>>>>>                     for OAuth.
>>>>>
>>>>>                     OAuth 2.0 is no more mandating such a case.
>>>>>
>>>>>
>>>>>                 I don't know what you mean by that.
>>>>
>>>>                 Copy and paste from draft-ietf-oauth-security-topics:
>>>>
>>>>                     OAuth initially assumed a static relationship
>>>>                     between client, authorization server and
>>>>                     resource servers.  (...)
>>>>                     With the increasing adoption of OAuth, this
>>>>                     simple model dissolved and, in several
>>>>                     scenarios, was replaced
>>>>                     by a dynamic establishment of the relationship
>>>>                     between clients on one side and the
>>>>                     authorization and
>>>>                     resource servers of a particular deployment on
>>>>                     the other side.
>>>>
>>>>                     This way, the same client could be used to
>>>>                     access services of different providers (in case
>>>>                     of standard APIs,
>>>>                     such as e-mail or OpenID Connect) or serve as a
>>>>                     frontend to a particular tenant in a
>>>>                     multi-tenancy environment.
>>>>
>>>>
>>>>             This sentence does not mention the RO or the Client.
>>>>             I'm confused what we are talking about
>>>>
>>>>>>                     A client application would like access to the
>>>>>>                     user's photos at a photo sharing site. The
>>>>>>                     resource is the user's photos. The user is
>>>>>>                     the owner of that resource.
>>>>>
>>>>>                     If the user has already pre established the
>>>>>                     access control policy rules so that it can
>>>>>                     access to his own photos
>>>>>                     then he does not need to grant in real time
>>>>>                     any additional authorization.
>>>>>
>>>>>                 I don't understand what you are trying to say. The
>>>>>                 photo sharing example was a driving use case for
>>>>>                 the creation of OAuth.
>>>>
>>>>                 We would need to revisit the original scenario and
>>>>                 consider if it can be addressed in a different way
>>>>                 than the original way.
>>>>
>>>>             The use case is the same. Is there a different solution
>>>>             you are proposing?
>>>
>>>
>>>             -- 
>>>             Txauth mailing list
>>>             Txauth@ietf.org 
>>>             https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>>         -- 
>>         Txauth mailing list
>>         Txauth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/txauth
>>
>>     ᐧ
>
>


--------------C04F4BBCDF80D6707A7F9D13
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Dick,

    


    

    
The floor is yours.

    


    

    
Would you explain how you would handle
      the use case of a student registering to a new University ?

    


    

    
Would you also elaborate why in my
      explanations below, you think that "the University's registration
      system is the Client, not a Resource Server" ?
      


      

    

    
Denis

    

    

    

      
      
Hi Denis
        


        

        
I would think in your example below, that the
          University's registration system is the Client, not a Resource
          Server.

        


        

        
Have a good night's sleep!

        


        

        


        

      

      

      

        
On Fri, Jul 24, 2020 at 12:04
          PM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hi Dick,

              

            

            
In order to send back a quick reply tonight, I will
              only respond to one of your questions:

            

              
 [Denis] How would be the data flow when
                access tokens from two GSs are needed by a RS ?

                


                

                
[Dick] I don't know of a use case where two tokens
                  would be needed by an RS. Would you elaborate?

              

              
I already described on the list the case of a student
                registering to a new University.

              
 

              

              
First, the student connects to the RS from the new
                University and opens an account 

                (at this time the student is using a pseudo and a
                private key to authenticate). He fills some forms 

                and indicate its citizenship, his home address and his
                graduation in his current university. 

                

                When he is finished, he indicates that he wants to
                perform a Registration operation.

              


              

              
From the information gathered in the forms, the RS
                informs the client that it needs two access tokens:

              
    
                
  • one to demonstrate that his name and current home
                  address are correct,and
    • 
                
  • another one to demonstrate that he got a graduation
                  from its current University.
    • 
              

              
Depending upon the information captured in the forms,
                the RS also indicates which ASs/GSs are acceptable 

                and which kind of attributes are requested.

              
 

              

              
The user consent and choice is performed by the
                client and once approved by the student, two access
                tokens are separately requested.

                Finally, two access tokens are presented to the RS while
                invoking a Registration operation.

              


              

              
Note that the start of the story is to open an
                account, e.g. using FIDO. The needs of the RS are only
                disclosed to the student once he has filled some forms 

                and indicated that he wanted to perform a Registration
                operation. Thus, the needs that are revealed by the RS
                are dependant both upon the operation 

                that the student is willing to perform and the
                information collected in the forms.

              


              

              
Denis

            

            

            

              

                
Hi Denis, comments inserted ... 

                

                

                  
On Fri, Jul 24, 2020
                    at 9:08 AM Denis <denis.ietf@free.fr>
                    wrote:

                  

                  

                    

                      

                        
Hi Dick,

                        


                        

                        
draft-hardt-xauth-protocol-13 describes a
                          solution without clearly stating what the
                          problem(s) to be solved is/are.

                      

                    

                  

                  


                  

                  
I agree that the problem description is not as
                    crisp as I would like it to be. A challenge is that
                    there is a broad spectrum of use cases solved by
                    OAuth 2, and OpenID Connect, as well as the new use
                    cases that are solved by GNAP.

                  


                  

                  
That is why I am suggesting we gather some use
                    cases so we have a common understanding of the
                    problems that are in scope.

                  
 

                  

                    

                      

                        


                        

                        
At the moment,
                          draft-hardt-xauth-protocol-13 includes a
                          single figure on page 4 and from previous
                          discussions I understood that 

                          it is no more up-to-date since the first data
                          flow is now a contact with a RS. The reason(s)
                          for the GS to contact a RO has still not 

                          been explained (since the inputs and outputs
                          are not described). The discovery information
                          made available at various steps at the RS 

                          is not described.

                        

                      

                    

                  

                  


                  

                  
I have made no updates as we are in a quiet
                    period prior to the WG meeting next week when
                    documents cannot be updated.

                  
 

                  

                    

                      

                        

                          


                          

                        

                        
Figure 4 shows only a single RS. Is the
                          relaying of one operation by that RS to a
                          second RS in the scope of this document ?

                          If yes, how is it handled ?

                        

                      

                    

                  

                  


                  

                  
I view that as an advanced use case that would be
                    covered in a separate document.

                  
 

                  

                    

                      

                        
 

                        


                        

                        
Figure 4 shows only a single GS. How would
                          be the data flow when access tokens from two
                          GSs are needed by a RS ?

                        

                      

                    

                  

                  


                  

                  
I don't know of a use case where two tokens would
                    be needed by an RS. Would you elaborate?

                  
The RS being able to accept tokens from two
                    different GSes is covered, but the Client is only
                    using a token from one GS at a time.

                  


                  

                  
 

                  

                    

                      

                        
 

                        

                        What we need first is not a set of "use cases"
                        but a clear model with a data flows and a list
                        of its properties/characteristics. 

                      

                    

                  

                  


                  

                  
I disagree. The use cases describe the problems
                    we are looking to solve. The data flows are part of
                    the solution. For example, from my understanding of
                    your use case, you don't want the GS to have
                    visibility into the User's activity. Am I correct
                    that this is one of your requirements for your use
                    case?

                  


                  

                  
 

                  

                    

                      
 

                      
Then after, we can understand much better
                        which use cases can/will be supported. For
                        example, shall a RS (or its RO) have 

                        prior relationships with the GS ? What is the
                        difference/implications when it has or it hasn't
                        ?

                      

                      


                      

                      
In order to have a fair comparison, we should
                        try to list model properties/characteristics.

                      


                      

                      
At the moment, the model I have described
                        including the data flows is clear. The discovery
                        information made available by a RS is clear.

                      
I have not listed all its
                        properties/characteristics of that model, but I
                        am pretty sure that you already have a flavour
                        of it.

                      


                      

                      
In the mean time, it would be nice if you
                        could show using two figures:

                      
    
                        
  • the case of the relaying of one operation by
                          one RS to a second RS (if it is in the scope
                          of your document),
    • 
                        
  • the case where access tokens from two GSs
                          are needed by one RS (if it is in the scope of
                          your document).
    
                        
    • 
                      

                    

                  

                  


                  

                  
See above

                  
 

                  

                    

                      
    
                        
  •  
    
                        
    • 
                      

                      

                        
Denis

                      

                      


                      

                      

                        
Hi Denis
                          


                          

                          
I think it would be useful to take a step
                            back and for you to describe your use case.
                            

                            After that, we can explore the different
                            ways that your use case can be addressed. 

                          


                          

                          
Looking at your previous communication,
                            it describes the solution, and the
                            justification, 

                            but it is not clear what use cases you are
                            needing to solve.

                          


                          

                          
/Dick

                          


                          

                          


                          

                        

                        
ᐧ

                        

                        

                          
On Wed, Jul
                            22, 2020 at 9:34 AM Denis <denis.ietf@free.fr>
                            wrote:

                          

                          

                            

                              
Hello Dick,

                              


                              

                              
I have identified the reason of the
                                major difference between our two
                                approaches.

                              


                              

                              
Access control may be performed using
                                either ACLs (Access Control Lists) or
                                Capabilities.

                              


                              

                              
Note : a capability
                                identifies a resource and an allowed
                                operation that can be performed on that
                                resource.

                              

                              


                              

                              
You are advocating a Capabilities
                                approach while I am advocating an ACL
                                approach.

                              
The capabilities approach allows the GS
                                to trace every operation performed by
                                the users on any RS known by a GS.

                                The management of these capabilities is
                                made via the GS or at the GS by the
                                various ROs. If the management is made 

                                via the GS, then a trusted communication
                                channel needs to be established with
                                every RO. If the management is made 

                                at the GS, then an authentication
                                mechanism needs to be established with
                                every RO. In the last case, the GS has
                                the 

                                ability to know all the capabilities of
                                the users whether they are used or not.
                                The less that can be said is that this
                                model 

                                is not privacy friendly.

                              
With the ACL approach, a RO directly
                                manages an ACL placed in front of each
                                RS. The Access Control
                                  Decision Function
                                    

                                    (ADF) at
                                  the RS is able to keep track from
                                  prior decisions. The GS is
                                kept ignorant of the content of these
                                ACLs and only 

                                delivers to its clients attributes that
                                are placed into access tokens. Such a
                                model may be privacy friendly.

                              
Other comments are between the lines
                                prefixed with [Denis].

                              

                                

                                  


                                    

                                      
On
                                        Tue, Jul 21, 2020 at 11:26 AM
                                        Denis <denis.ietf@free.fr>
                                        wrote:

                                      

                                      

                                        

                                          
Hello Dick,

                                          


                                          

                                          
 Thank you for your
                                            feedback. Comments are
                                            between the lines.

                                          


                                          

                                          

                                            

                                              
comments
                                                inserted ... 

                                              

                                              

                                                
On
                                                  Tue, Jul 21, 2020 at
                                                  6:03 AM Denis <denis.ietf@free.fr>
                                                  wrote:

                                                

                                                

                                                  

                                                    
Hello Dick,

                                                    


                                                    

                                                    
I duplicate the
                                                      most important
                                                      comment at the
                                                      beginning of this
                                                      email:

                                                    

                                                      
You are
                                                        considering
                                                        using an access
                                                        control model to
                                                        build a workflow
                                                        model.

                                                         

                                                        While it may be
                                                        interesting to
                                                        define a
                                                        workflow model,
                                                        this should be
                                                        considered 

                                                        as a separate
                                                        and different
                                                        work item.

                                                    

                                                    
See the other
                                                      comments between
                                                      the lines.

                                                    

                                                    


                                                    

                                                    

                                                      
On
                                                        Mon, Jul 20,
                                                        2020 at 2:05 AM
                                                        Denis <denis.ietf@free.fr> wrote:

                                                        

                                                          

                                                          

                                                          
Hi Dick,

                                                          


                                                          

                                                          

                                                          
On
                                                          Fri, Jul 17,
                                                          2020 at 9:21
                                                          AM Denis <denis.ietf@free.fr>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Francis and
                                                          Dick,

                                                          


                                                          

                                                          
The good
                                                          news first: we
                                                          are making
                                                          some progress.
                                                          We are now
                                                          close to an
                                                          agreement with
                                                          steps (1) up
                                                          to (3), 

                                                          ... except
                                                          that the place
                                                          where the user
                                                          consent is
                                                          captured is
                                                          not
                                                          mentioned/indicated.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          This major
                                                          question which
                                                          is currently
                                                          left
                                                          unanswered is
                                                          where, when
                                                          and how the
                                                          user consent
                                                          is captured.

                                                          

                                                          

                                                          


                                                          

                                                          
When is
                                                          covered, per
                                                          the sequence.
                                                          How and where
                                                          are out of
                                                          scope of what
                                                          I drafted. 

                                                          

                                                        

                                                      

                                                    

                                                    
It is clear that
                                                      the "User consent
                                                      and choice" is not
                                                      currently
                                                      addressed in the
                                                      draft, but it
                                                      should.

                                                      The support of the
                                                      "User consent and
                                                      choice" has strong
                                                      implications not
                                                      only in the
                                                      sequences of the
                                                      exchanges 

                                                      but also by which
                                                      entity it should
                                                      be performed.

                                                  

                                                

                                                
"consent" is in the
                                                  latest draft 7 times.
                                                  

                                                

                                              

                                            

                                          

                                          
"Consent" is present 5
                                            times. The User consent is
                                            different from the RO
                                            consent (when/if it is
                                            required). 

                                          

                                          

                                            
The server acquires
                                              consent and authorization
                                              from the user and/or
                                                resource owner if
                                                required.

                                            

                                            
User consent is often
                                                required at the GS.
                                              GNAP enables a Client and 
                                              GS to negotiate the
                                              interaction mode for the
                                              GS to obtain consent.

                                            

                                            
 The GS may require
                                              explicit consent from the
                                              RO or User to provide
                                              these to the Client.

                                            

                                          

                                          
The User consent is not an
                                            alternative to the RO
                                            consent. So using "and/or"
                                            in the first sentence is
                                            incorrect.

                                        

                                      

                                      


                                      

                                      
My language is sloppy there.
                                        Consent is always from the RO.
                                        The User may be the RO.

                                    

                                  

                                

                              

                              
[Denis] No. Once again: The "User
                                  consent" is different from what
                                you call the "RO consent"
                                (when/if it is required). 

                                The "RO consent" is not in fact a
                                consent but the release of a capability
                                to a client by one of the many R0s with
                                which 

                                the GS has relationships. 

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
Since the second sentence
                                            is using the wording "often
                                            required" there is no
                                            requirement to get the User
                                            consent.

                                          

                                        

                                      

                                      
User consent may not be
                                        required. There may not be a
                                        User. The consent may have been
                                        gathered previously.

                                    

                                  

                                

                              

                              
[Denis] In order to follow the privacy
                                principles, a "User consent" phase is
                                required. The User is a natural person.

                                A Client is called either by a User
                                (i.e. a natural person) or by a Client
                                application. 

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
 

                                          
The second sentence does
                                            not consider the possibility
                                            to get the User consent in a
                                            place different from the GS.

                                        

                                      

                                      
Agreed. But we do agree that
                                        the GS gets the consent, either
                                        directly from the RO, or from
                                        the Client (in your example).

                                    

                                  

                                

                              

                              
[Denis] No. I disagree. In an ACL based
                                systems, the GS does not need to ask or
                                receive any consent.

                                The client selects the set of attributes
                                that it wants to be inserted into an
                                access token.

                                If the GS has the requested attributes,
                                then it provides them, otherwise it
                                returns an error to the Client.

                              

                                

                                  

                                    

                                      

                                        

                                          
IMO, the User consent
                                            should be captured by the
                                            Client, i.e. not by the GS.
                                            

                                            The information used to
                                            obtain the User consent
                                            should be standardized (...
                                            and it can be standardized).

                                          

                                          

                                            

                                              
I
                                                think the abstract
                                                sequence as proposed by
                                                Francis is a great
                                                addition, and would
                                                clarify where consent is
                                                in the sequence. 

                                            

                                          

                                          
The current sketch does not
                                            illustrate the place the
                                            User Consent is captured, in
                                            particular by the Client.

                                        

                                      

                                      
It is an abstraction. The GS
                                        receives the consent. How
                                        consent is gathered is a detail
                                        that is dependent on the use
                                        case.

                                    

                                  

                                

                              

                              
[Denis] I really wonder whether there
                                is really a "consent" to be received by
                                the GS in both cases (i.e. ACLs or
                                Capabilities).

                              

                              
    
                                
  • For ACLs, the consent needs to be
                                  done by the Client.
    • 
                                
  • For Capabilities, the current
                                  description is not clear since the
                                  inputs and the outputs for this
                                  "consent" phase
    
                                  are not currently described in the
                                  draft.
    • 
                              

                              

                                

                                  

                                    

                                      
 

                                      

                                        

                                          

                                            

                                              

                                                
 

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
 Another
                                                          important
                                                          point to
                                                          consider and
                                                          to explain is
                                                          related to the
                                                          assurances
                                                          that the user
                                                          can obtain
                                                          about 

                                                          the respect of
                                                          his choices.
                                                          This point is
                                                          currently left
                                                          unanswered in
draft-hardt-xauth-protocol-13.

                                                          

                                                          

                                                        

                                                      

                                                    

                                                    
This point is
                                                      equally important:
                                                      such assurance can
                                                      only be obtained
                                                      if the access
                                                      token returned to
                                                      the client 

                                                      is not considered
                                                      to be opaque to
                                                      the client. This
                                                      is a necessary
                                                      condition but not
                                                      the single
                                                      condition: 

                                                      the Client must
                                                      also be in a
                                                      position to
                                                      capture/memorize
                                                      the "User consent
                                                      and choice" of the
                                                      user in order to
                                                      be able 

                                                      to verify it
                                                      afterwards using
                                                      the content of the
                                                      access token(s).

                                                  

                                                

                                                


                                                

                                                
We disagree on this
                                                  being a requirement
                                                  for all use cases. It
                                                  may be in some. 

                                                

                                              

                                            

                                          

                                          
OK. Then this means that
                                            there will be no sentence in
                                            the draft such as :

                                            "access tokens returned to
                                            the client are not
                                            considered to be opaque to
                                            the client".

                                        

                                      

                                      


                                      

                                      
For OAuth use cases, which
                                        GNAP supports, the access token
                                        is opaque to the Client. As you
                                        have noted, there are use cases
                                        where the access token is NOT
                                        opaque.

                                    

                                  

                                

                              

                              
[Denis] Wait a second. There is no
                                requirement to support all OAuth use
                                cases. 

                                I believe that there is a requirement to
                                support OAuth 2.0 ASs, while the clients
                                may be different 

                                and hence GNAP clients do not need to
                                inherit of the limitations of OAuth 2.0
                                clients.

                              

                                

                                  

                                    

                                      
 

                                      

                                        

                                          

                                            

                                              

                                                
 

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
If a RO
                                                          needs to be
                                                          involved and
                                                          since a RO is
                                                          directly
                                                          associated
                                                          with a RS, why
                                                          can't it be
                                                          directly
                                                          queried 

                                                          by the
                                                          appropriate RS
                                                          after step (2)
                                                          or later on ?

                                                          

                                                          

                                                          


                                                          

                                                          
Good
                                                          question.
                                                          Perhaps you
                                                          can expand on
                                                          a use case
                                                          where that
                                                          would be
                                                          useful?

                                                          

                                                          

                                                          

                                                          
Before I
                                                          expand, would
                                                          you be able to
                                                          explain first
                                                          under which
                                                          circumstances
                                                          a RO needs to
                                                          be queried by
                                                          a GS ?

                                                          How can the GS
                                                          identify which
                                                          RO to query ?

                                                          

                                                          

                                                          
If the
                                                          User is the
                                                          RO, then the
                                                          GS knows who
                                                          to query. 

                                                          

                                                        

                                                      

                                                    

                                                    
I still have
                                                      difficulties to
                                                      understand what
                                                      you mean here. 

                                                      How could a GS
                                                      know that "the
                                                      User is the RO" ? 
                                                      If "the User is
                                                      the RO", why does
                                                      the GS needs to
                                                      query the User ? 

                                                    

                                                  

                                                

                                                


                                                

                                                
To get consent?

                                              

                                            

                                          

                                          
To get a "RO consent" to
                                            himself ???

                                        

                                      

                                      


                                      

                                      
The GS needs consent from the
                                        RO. If the RO is the User, then
                                        consent from the RO is
                                        equivalent to consent from the
                                        User.

                                    

                                  

                                

                              

                              
[Denis] See above.

                              

                              

                                

                                  

                                    

                                      
 

                                      

                                      

                                        

                                          

                                            

                                              

                                                
 

                                                

                                                  

                                                    

                                                      

                                                        

                                                          
If the RO
                                                          is a separate
                                                          entity, then
                                                          the GS knows
                                                          the RO from
                                                          the RS being
                                                          queried. 

                                                          

                                                        

                                                      

                                                    

                                                    
 ... and this
                                                      gives the ability
                                                      for the GS to
                                                      log/trace all the
                                                      RSs accessed by a
                                                      given User and at
                                                      which instant of
                                                      time the access
                                                      token has been
                                                      granted.

                                                    

                                                      

                                                        

                                                          
An
                                                          example is a
                                                          user would
                                                          like access to
                                                          an enterprise
                                                          asset where a
                                                          workflow is
                                                          started to
                                                          gain approval,
                                                          and an
                                                          administrator
                                                          or manager
                                                          provides
                                                          consent.

                                                        

                                                      

                                                    

                                                    
Thanks for this
                                                      example. I finally
                                                      understand what
                                                      you have in mind:
                                                      you are
                                                      considering using
                                                      an access control
                                                      model to build a workflow
                                                        model. 

                                                      While it may be
                                                      interesting to
                                                      define a workflow
                                                      model, this should
                                                      be considered as a
                                                      separate and
                                                        different work
                                                        item.

                                                  

                                                

                                                


                                                

                                                
The actual workflow
                                                  is out of scope. 

                                              

                                            

                                          

                                          
I am glad you agree with
                                            this. But this means that
                                            your example was not
                                            appropriate to illustrate
                                            your point.

                                          

                                        

                                      

                                      


                                      

                                      
It illustrates a use case
                                        where the RO and User are not
                                        the same party, and why the GS
                                        needs to query the RO, which was
                                        your question if I understood it
                                        correctly.

                                    

                                  

                                

                              

                              
[Denis] Since the inputs and the
                                outputs for this "RO consent" phase are
                                not currently described in the draft,
                                the point is still unsolved.

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
 As soon as there is a RO
                                            consent obtained at the GS,
                                            the major problem is that
                                            the GS is able to act as Big
                                            Brother.

                                            If a RO consent is performed
                                            at the RS, then the GS will
                                            not know who the RS is: it
                                            is then unable to act as Big
                                            Brother, 

                                            even if it would enjoy to
                                            play that role.

                                        

                                      

                                      
In an enterprise use case,
                                        the GS's knowledge of who is
                                        accessing which RS is a feature.

                                    

                                  

                                

                              

                              
Do you mean that it is "normal" in an
                                enterprise that a single point of
                                control is able to trace all their
                                actions ? 

                                From a security point of view, a single
                                point of failure will have dramatic
                                consequences.

                              

                                

                                  

                                    

                                      
In your use cases, it seems
                                        that the RO is the User. 

                                    

                                  

                                

                              

                              
I do hope that you have finally
                                understood that, in my use case, the RO
                                is **not** the User.

                              

                                

                                  

                                    

                                      
The GS knows the User is
                                        wanting to let a Client access
                                        something. If the access token
                                        is generic, and could be
                                        presented to any RS that
                                        provides a standardized
                                        function, 

                                        then the GS does not know which
                                        RS is being accessed by a Client
                                        for the User. This seems to meet
                                        your privacy objectives. If not,
                                        what is wrong?

                                    

                                  

                                

                              

                              
For security reasons, an access token
                                needs to be targeted (which does not
                                necessarily mean that an identifier of
                                the RS shall be included into the access
                                token).

                              

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                
if the admin grants
                                                  access, then the
                                                  access granted to the
                                                  client changes. 

                                                

                                                

                                                  

                                                    
 

                                                    
The model you
                                                      propose may be
                                                      suited for an
                                                      enterprise
                                                      environment but is
                                                      not scalable over
                                                      the Internet.

                                                  

                                                

                                                
It is one of the
                                                  use cases we are
                                                  working to address. 

                                                

                                                

                                                  

                                                    
 What is needed
                                                      is an access
                                                      control model
                                                      usable over the
                                                      Internet with
                                                      millions of RSs
                                                      and thousands of
                                                      ASs/GSs.  

                                                    

                                                  

                                                

                                                
I agree the model
                                                  should also scale to
                                                  internet scale. 

                                                

                                              

                                            

                                          

                                          
Fine. Another point on
                                            which we are in agreement. 

                                          

                                          
The model can scale to the
                                            Internet based on the
                                            following assumptions:

                                          

                                            
The flow starts with the
                                              steps (1) to (4) as
                                              illustrated by Francis,
                                              i.e. the flow starts with
                                              a contact with a RS.

                                          

                                          
+----+
                                                 +------+  +---+  +---+
                                                 +---+

                                                |User|  |Client|  |RS |
                                                 |GS |  |RO |

                                                +----+  +------+  +---+
                                                 +-+-+  +-+-+

                                                  |(1) Service Request  
                                                  |      |

                                                  |-------->|       |
                                                     |      |

                                                  |         |(2) Service
                                                Intent   |

                                                  |         |------>|
                                                     |      |

                                                  |         |(3) AuthZ
                                                Challenge  |

                                                  |         |<------|
                                                     |      |

                                                  |         |(4) AuthZ
                                                Request    |

                                                  |        
                                                |------------->|    
                                                 |

                                          
The GS/AS does not need to
                                            have any prior relationship
                                            with ROs and/or RSs.

                                          
Furthermore, it is possible
                                            to prevent the GS to act as
                                            Big Brother when the
                                            identity of the RS is not
                                            disclosed to the GS.

                                          

                                        

                                      

                                      


                                      

                                      
What happens after (4) above?
                                        

                                      

                                    

                                  

                                

                              

                              
[Denis] The key point is that we first
                                need to agree on the first four
                                exchanges. Do we ?

                              

                              
The fifth exchange is different whether
                                ACLs or Capabilities are being used.

                              

                              

                                

                                  

                                    

                                      
 

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
Which
                                                          information is
                                                          supposed to be
                                                          presented to
                                                          the RO ?

                                                          Which
                                                          information is
                                                          supposed to be
                                                          returned by
                                                          the RO ?

                                                          

                                                          

                                                          


                                                          

                                                          
Just like
                                                          how the user
                                                          authenticates
                                                          to an AS, how
                                                          the AS and RO
                                                          communicate is
                                                          out of scope.

                                                          

                                                          

                                                          

                                                          

                                                          
At the
                                                          moment, the
                                                          usefulness of
                                                          a dialogue
                                                          between a GS
                                                          and a RO has
                                                          not been
                                                          explained, nor
                                                          demonstrated.

                                                          The question
                                                          is about the
                                                          functionality
                                                          of that
                                                          dialogue in
                                                          terms of input
                                                          and output
                                                          information
                                                          (and not about
                                                          

                                                          the design of
                                                          a protocol or
                                                          of a user
                                                          interface).
                                                          Anyway, AFAIU
                                                          a dialogue
                                                          between a GS
                                                          and a RO is
                                                          optional.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
See
                                                          enterprise
                                                          example above.

                                                        

                                                      

                                                    

                                                    
It is not an
                                                      access control
                                                      example, but a
                                                      workflow example.

                                                    
Access 
                                                      control has been
                                                      defined a long
                                                      time ago and the
                                                      last edition of
                                                      the model has been
                                                      confirmed in year
                                                      1996: ISO/IEC 10181-3: 1996.

                                                      "Information
                                                        technology —
                                                        Open Systems
                                                        Interconnection —
                                                        Security
                                                        frameworks for
                                                        open systems:
                                                        Access control
                                                        framework —
                                                        Part 3".

                                                    
Two major functions have ben defined: an Access Control Enforcement Function
                                                          (AEF) and an Access
                                                        Control
                                                        Decision
                                                        Function(ADF).

                                                    

                                                      
Access
                                                          Control Enforcement
                                                          Function
                                                          (AEF):

                                                          A specialized
                                                          function that
                                                          is part of the
                                                          access path
                                                          between an
                                                          initiator and
                                                          a target on
                                                          each access
                                                          request and
                                                          enforces the
                                                          decision made
                                                          by the ADF.

                                                      Access Control Decision
                                                        Function (ADF) :

                                                      A
                                                        specialized
                                                        function that
                                                        makes access
                                                        control
                                                        decisions by
                                                        applying access
                                                        control policy
                                                        rules to an
                                                        access request,
                                                        ADI (of
                                                        initiators,
                                                        targets, access
                                                        requests, 

                                                      or
                                                        that retained
                                                        from prior
                                                        decisions), and
                                                        the context in
                                                        which the access
                                                        request is made.

                                                    
The role of the
                                                      RO is to define
                                                      the "access
                                                        control policy
                                                        rules" at the RS
                                                        according to the context
                                                          in which the
                                                          access request
                                                          is made.

                                                  

                                                

                                                
I'm pretty familiar
                                                  with access control
                                                  systems. :) 

                                                


                                                

                                                
I would say that
                                                  the access control is
                                                  happening at the RS.
                                                  The client presents a
                                                  token when accessing
                                                  an API. 

                                                  The RS uses the token,
                                                  and any policy
                                                  required, to make an
                                                  access decision.

                                              

                                            

                                          

                                          
Fine. It looks like we are
                                            in agreement. Unfortunately,
                                            this is not the case just
                                            below.

                                          

                                          

                                            

                                              

                                                
Here is flow:

                                                


                                                

                                                
1) The Client
                                                  requests access to an
                                                  RS from the GS. 

                                                

                                              

                                            

                                          

                                          
No. We are no more in
                                            agreement. This is different
                                            from the flow drawn by
                                            Francis.

                                        

                                      

                                      
My bad. Typo. I meant RO.

                                      
 

                                      

                                        

                                          

                                            

                                              

                                                
2) The GS queries
                                                  the RS if access
                                                  should be granted. 

                                                

                                              

                                            

                                          

                                          
 No. The GS should not be
                                            forced to have a flow with
                                            the RS.

                                        

                                      

                                      
Same mistake as above, I
                                        meant RO. 

                                      

                                        

                                          
 

                                          

                                            

                                              

                                                
3) If access is
                                                  granted, the GS
                                                  creates an access
                                                  token representing the
                                                  granted access, and
                                                  returns it to the
                                                  Client. 

                                                

                                              

                                            

                                          

                                          
This model is by no way
                                            conformant to ISO/IEC 10181-3:
                                                1996 

                                              

                                        

                                      

                                      
I'm unclear on why, or why it
                                        is even relevant. 

                                      

                                      

                                        

                                          

                                              

                                          

                                            

                                              

                                                
4) The Client
                                                  presents the access
                                                  token to the RS to
                                                  show it has been
                                                  granted access. 

                                                

                                              

                                            

                                          

                                          
No. The client presents a
                                            token when accessing an API.
                                            The RS uses the token, and
                                            any policy required, to make
                                            an access decision.

                                            The token never contains an
                                            information like "Please
                                            grant an access to the
                                            holder of this token".

                                        

                                      

                                      
Let me provide more clarity
                                        in the sentence:

                                      


                                      

                                      
The Client presents the
                                        access token to the RS, to show
                                        the RS that the Client has been
                                        granted access to a resource at
                                        the RS by the GS.

                                    

                                  

                                

                              

                              
[Denis] This time, please consider both
                                the ACLs approach and the Capabilities
                                approach.

                              

                                

                                  

                                    

                                      
 

                                      

                                        

                                          

                                            

                                              

                                                
A couple advantages
                                                  of this model:

                                                
- that the RS does
                                                  not need to know much,
                                                  if anything about the
                                                  Client. 

                                                
- the access token
                                                  MAY be self contained
                                                  so that the Client
                                                  does not need to query
                                                  the GS on each access.
                                                  

                                                

                                              

                                            

                                          

                                          
There are so many
                                            disadvantages that I will
                                            not list them.

                                        

                                      

                                      
Darn: I clearly was not
                                        firing on all cylinders when I
                                        typed this out. Let me correct:

                                      


                                      

                                      

                                        

                                          

                                            

                                              
- the access token
                                                MAY be self contained so
                                                that the RS does not
                                                need to query the GS on
                                                each access to the RS by
                                                the Client.

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                              
[Denis] A few comments in the case of a
                                capability approach:

                              

                                
- for each GS, the RS needs to
                                  locally manage which operation(s)
                                  is/are allowed to it.

                                  

                                  - the GS needs to establish a trusted
                                  communication channel or an
                                  authentication mechanism with each RO
                                  

                                     (which is associated with an
                                  explicit RS identifier). 

                                

                                
- the GS could play the role of the
                                  RO and hence be in a position to issue
                                  any capability for any RS (without a
                                  "RO consent"). 

                                  

                                     The target of an attack will
                                  clearly be the GS.

                                

                              

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                
I would not say
                                                  that GNAP is an access
                                                  control protocol, as
                                                  how the RS uses the
                                                  token to determine
                                                  access is out of
                                                  scope.

                                              

                                            

                                          

                                          
This is where we have a major
                                                discrepancy:
                                            how the RS uses the token to
                                            determine access is *within*
                                            the scope.

                                        

                                      

                                    

                                  

                                

                              

                              [Denis] Do you agree or disagree ?

                              

                                

                                  

                                    

                                      

                                        

                                          
The RS announces in advance
                                            to the client what it needs
                                            so that the client can
                                            perform a a given operation
                                            and if the client supplies
                                            the requested attributes 

                                            obtained from some GS/AS(s)
                                            trusted by the RS, then
                                            access to that RS is granted
                                            by the RS. If the RS cannot
                                            perform the requested
                                            operation on its own, 

                                            then the client should be
                                            informed about some
                                            requested attributes that
                                            need to be obtained from
                                            some GS/AS(s) trusted by the
                                            next RS(s) in a chain

                                            for subsequent operations.
                                            The User consent should also
                                            be obtained before
                                            performing the chaining
                                            operation.

                                          

                                          
Chaining operations between
                                            RSs over the Internet is
                                            within the scope (... and
                                            may be achieved).

                                        

                                      

                                    

                                  

                                

                              

                              
[Denis] Do you agree or disagree ?

                              
Denis

                              

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
For many
                                                          use cases, the
                                                          User is the
                                                          RO, and the
                                                          interaction is
                                                          through a user
                                                          interface, not
                                                          a machine
                                                          protocol. 

                                                          

                                                          

                                                          

                                                          

                                                          
Wait a
                                                          second. You
                                                          wrote "the
                                                          User is the
                                                          RO". The User
                                                          is attempting
                                                          to make an
                                                          access to a RS
                                                          by using a
                                                          Client. 

                                                          That
                                                          User is not
                                                          the RO of the
                                                          RS.   

                                                          

                                                          

                                                          

                                                          
The user
                                                          being the RO
                                                          is the initial
                                                          use case for
                                                          OAuth. 

                                                        

                                                      

                                                    

                                                    
OAuth 2.0 is no
                                                      more mandating
                                                      such a case.

                                                    

                                                  

                                                

                                              

                                            

                                          

                                          

                                            

                                              


                                                
I don't know what
                                                  you mean by that.

                                              

                                            

                                          

                                          
Copy and paste from
                                            draft-ietf-oauth-security-topics:

                                          

                                          

                                            
OAuth initially assumed a
                                              static relationship
                                              between client,
                                              authorization server and
                                              resource servers.  (...) 
                                              

                                              With the increasing
                                              adoption of OAuth, this
                                              simple model dissolved
                                              and, in several scenarios,
                                              was replaced 

                                              by a dynamic establishment
                                              of the relationship
                                              between clients on one
                                              side and the authorization
                                              and 

                                              resource servers of a
                                              particular deployment on
                                              the other side.

                                              

                                              This way, the same client
                                              could be used to access
                                              services of different
                                              providers (in case of
                                              standard APIs, 

                                              such as e-mail or OpenID
                                              Connect) or serve as a
                                              frontend to a particular
                                              tenant in a multi-tenancy
                                              environment. 

                                            

                                          

                                        

                                      

                                      


                                      

                                      
This sentence does not
                                        mention the RO or the Client.
                                        I'm confused what we are talking
                                        about 

                                      

                                        

                                          

                                            
 

                                          

                                          

                                            

                                              

                                                
 

                                                

                                                  

                                                    

                                                      

                                                        

                                                          
A client
                                                          application
                                                          would like
                                                          access to the
                                                          user's photos
                                                          at a photo
                                                          sharing site.
                                                          The resource
                                                          is the user's
                                                          photos. The
                                                          user is the
                                                          owner of that
                                                          resource.

                                                        

                                                      

                                                    

                                                    
If the user has
                                                      already pre
                                                      established the
                                                      access control
                                                      policy rules so
                                                      that it can access
                                                      to his own photos
                                                      

                                                      then he does not
                                                      need to grant in
                                                      real time any
                                                      additional
                                                      authorization.

                                                  

                                                

                                                
I don't understand
                                                  what you are trying to
                                                  say. The photo sharing
                                                  example was a driving
                                                  use case for the
                                                  creation of OAuth.

                                              

                                            

                                          

                                          
We would need to revisit
                                            the original scenario and
                                            consider if it can be
                                            addressed in a different way
                                            than the original way.

                                        

                                      

                                      
The use case is the same. Is
                                        there a different solution you
                                        are proposing?

                                      
 

                                    

                                  

                                

                              

                              


                              

                            

                            -- 

                            Txauth mailing list

                            Txauth@ietf.org

                            https://www.ietf.org/mailman/listinfo/txauth

                          

                        

                      

                      


                      

                    

                    -- 

                    Txauth mailing list

                    Txauth@ietf.org

                    https://www.ietf.org/mailman/listinfo/txauth

                  

                

              

              
ᐧ

            

            


            

          

        

      

    

    


    

  


--------------C04F4BBCDF80D6707A7F9D13--


From nobody Mon Jul 27 03:12: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 04F923A183D for ; Mon, 27 Jul 2020 03:12: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, 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 flFb_TupUBSg for ; Mon, 27 Jul 2020 03:12:41 -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 C28A83A1836 for ; Mon, 27 Jul 2020 03:12:40 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id l2so3711901wrc.7 for ; Mon, 27 Jul 2020 03:12: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=keqBieRKpLQlntq7k0gVIFNQfar2rCIwDE7qF+twFXA=; b=YiFkrseTw7cuVQ/ZULeSNZSZ/MlLZG6BrUb89LHH0+9YVibiyE/yvQ25oGfwlt1Ua7 WccpBIwf7B6933vnq6gCwaBqm5N680fGwGAND6xPIwlSSIy/iUtB1F5YFXRw898lPGpg sqPssktcj+YGHz013DI2Ov7kb9W38b+BMFuoc=
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=keqBieRKpLQlntq7k0gVIFNQfar2rCIwDE7qF+twFXA=; b=n04PanW3BQlxoKbN+CqWUSUCtLW3cz2fHdFcgpkHZRnwYuqisD2FG2SPem5QS/KaNQ wr72A84iYDWB3rh+HU4Zb0lLRKGLLQXljPDwX4lAF5XdCWu2IbYiHEBH5xdW9QmYXfL3 1Q7EUsI5rytSQhm9cJDdG68WpuNQ+paPNCC4rMHrYymYmclfFu8z9bTFL1dZOF0tYrOV CUfIz6zLqciTA7aqAoGxhf9psUzNHQn4a2pvJ/5Z4RwM6j67DUI2L98moIpRCEE1JdBb mrU6vnMb/8Cdhdpv/Kb3xv3OJZm0lxfVT5TIoDlkT79Hn9Rg1ysDMusqqnCbXBoFQBJA iydQ==
X-Gm-Message-State: AOAM533MJat8iA7VTVh3dLtn9hgyM00+3paXkBA4R8d88Okm6ImYUyh2 NGKShqCRhVim/h6O0GEERwo5nD2okK9WZlGrzun9Xg==
X-Google-Smtp-Source: ABdhPJy2fyzqg20ekhs0v5KOUdnAHHT6Zk0Gq7w4SITAYH+JqbKG6ovKBaUNYe9sh8z37HB/R2S0hlmqwhEUKpWDBtM=
X-Received: by 2002:a5d:51c3:: with SMTP id n3mr20011070wrv.104.1595844758826;  Mon, 27 Jul 2020 03:12:38 -0700 (PDT)
MIME-Version: 1.0
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>     
In-Reply-To: 
From: Francis Pouatcha 
Date: Mon, 27 Jul 2020 06:12:27 -0400
Message-ID: 
To: Dick Hardt 
Cc: txauth@ietf.org, Justin Richer ,  Tom Jones , Denis ,  Fabien Imbault 
Content-Type: multipart/alternative; boundary="000000000000f7817405ab698fe4"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 10:12:46 -0000

--000000000000f7817405ab698fe4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 26, 2020 at 11:58 PM Dick Hardt  wrote:

>
>
> On Sun, Jul 26, 2020 at 6:45 PM Francis Pouatcha  wrote:
>
>> Hello Dick,
>>
>> On Sun, Jul 26, 2020 at 9:14 PM Dick Hardt  wrote:
>>
>>> Hi Francis
>>>
>>> User is a well understood term in OIDC and OAuth -- and User means the
>>> same in both.
>>>
>>
>>> Resource Owner is who owns the resource, and the term is introduced for
>>> when the User is NOT the Resource Owner.
>>>
>> This distinction is what makes it confusing as we are comparing an Entit=
y
>> (the User) to a Role (the RO). We need two roles.
>>
>
> Or we could think of them all as entities. The RO is the entity that owns
> the resource. The User is the human that is using the Client.
>
When we think of them as entities, we run into conflicts when Entity-User
eq. Entity-RO.
When we think of them as roles, Role-User is always !=3D Role-RO

>
>
>>
>>
>>>
>>> I also think that Client and Resource Server are well understood terms.
>>>
>> Looks like contributors on the list still need clarification on the
>> "orchestration" role of a client.
>>
>
> When I think of orchestration, I think of coordinating, which is not what
> I think the Client is doing. The Client wants to consume the Claims and t=
he
> Resources (combined are a Grant). The Client requests the Grant from the
> Grant Server. Where is the orchestration?
>
Look at the client. It is the center of interaction between User, GS and RS=
.

>
>
>>
>>> It is not clear to me why we would want to reinvent these terms. Readin=
g
>>> over your flows, I think it would be useful to understand the requireme=
nts
>>> you have for your use case, otherwise I fear we will be talking past ea=
ch
>>> other.
>>>
>> The oAuth flow is there as a memo. The other flow is what I proposed
>> before. Is there to emphasize we need to work on roles and not on entiti=
es.
>> It is not a suggestion to rename well known idioms. It is an attempt to
>> give them a proper definition in the context of this protocol. Definitio=
n
>> based on their roles in the protocol flows.
>>
>
> I'd like to take a step back and understand the requirements. We are deep
> into solutions.
>
No, we are at the fundamental level. We Have to decide on whether to build
a model based on roles oron entities... Then we use the result [ENTITY XOR
ROLES] to define the use cases.
/Francis

>
>
>>
>> Best regards.
>> /Francis
>>
>>>
>>> /Dick
>>>
>>> =E1=90=A7
>>>
>>> On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha  wrote=
:
>>>
>>>> Below my opinion on the term Claim:
>>>>
>>>> Starting with illustration of parties/roles:
>>>>
>>>> User:
>>>> This word is misleading because of its double role in oAuth2 and OIDC
>>>> (see below). In GNAP let us have the User play only the role of a
>>>> requestor. (from Justin reference to "Requesting Party").
>>>>
>>>> Client:
>>>> This is also tightly bound to the oAuth2 and OIDC. The real purpose of
>>>> this role is to orchestrate resource access on behalf of the "Requesto=
r".
>>>> Let us call this for now the "Orchestrator"
>>>>
>>>> Resource Owner (RO):
>>>> This is IMO the most correct word in the entire protocol. Authorisatio=
n
>>>> is always about the owner of something granting access to a requestor.=
 It
>>>> really does not matter if a human interaction is involved. We will hav=
e to
>>>> forget oAuth2 and OIDC of also calling this a User.
>>>>
>>>> Grant Server:
>>>> Even though the definition of the UserInfo endpoint in OIDC as a
>>>> protected resource hazardously makes an OP an RS, we shall not repeat =
the
>>>> same mistake here. We need a clear separation between roles of GS and =
RS
>>>> without overlapping.
>>>>
>>>> Resource Server: services resources.
>>>>
>>>> Unless I got it wrong, GNAP is about grant negotiation and
>>>> authorization. This means:
>>>>
>>>> GNAP is about some party requesting access to some resources.
>>>> GNAP is about the resource owner consenting access to that resource.
>>>> GNAP is about defining the infrastructure that allows the requesting
>>>> party to access a resource.
>>>>
>>>> GNAP designs this infrastructure around:
>>>> - an orchestrator (what we refer to as a client)
>>>> - an grant manager (what we refer to as a GS/AS)
>>>> - the custodian of the resource (what we call a RS)
>>>>
>>>> As you see:
>>>> - The word User does not appear here, and is not relevant as the
>>>> focus is on authorizing access to a resource.
>>>> - The word Claim is as well absent.
>>>>
>>>> Claim related to RO:
>>>> The word Claim might start getting visible if the orchestrator (a.k.a.
>>>> Client) or the custodian (a.k.a RS) needs some additional information =
on
>>>> the RO to proceed with the access control decision. These claims refer=
 to
>>>> assertions of attributes or properties of the RO. These claims are iss=
ued
>>>> by the GS as the GS manages interaction with the RO (see below). In th=
is
>>>> first place information about the requesting party (erroneously.k.a.
>>>> User) is not relevant to the negotiation and provisioning framework. L=
et us
>>>> call this sort of claim "RO-Attributes". A better name is welcome.
>>>>
>>>> Some advanced resource provisioning frameworks might require knowledge
>>>> on attributes of the requesting party (e.k.a User). These attributes s=
hall
>>>> be collected by the orchestrator (a.k.a Client) and added to the resou=
rce
>>>> request. There is no way the GS can collect these attributes as the GS=
 role
>>>> has no interaction with the requesting party (e.k.a User). Let us call=
 this
>>>> sort of claim "Requestor-Attributes". A better name will be welcome.
>>>>
>>>> Some assertions are even related to the orchestrator (a.k.a Client)
>>>> itself. This is the case of the public key of an orchestrator used by =
the
>>>> GS to "sender constrain" an access token. Let us call this type of cla=
im
>>>> "Orchestrator-Attributes".
>>>>
>>>> This is a sample mapping of OIDC.
>>>>
>>>> +----+    +---+   +---+  +---+
>>>> |User|    |RP |   |OP |  |RS |
>>>> +----+    +---+   +-+-+  +---+
>>>>   |(1) ServiceRequest      |
>>>>   |-------->|       |      |
>>>>   |(2) redirect     |      |
>>>>   |<--------|       |      |
>>>> =3D=3D=3D User (requestor) passes control to User (RO) =3D=3D=3D
>>>>   |(3) Auth + Consent      |
>>>>   |---------------->|      |
>>>>   |(4) redirect (code)     |
>>>>   |<----------------|      |
>>>> =3D=3D=3D User (RO) passes control back to User (requestor) =3D=3D=3D
>>>>   |(5) get(code)    |      |
>>>>   |-------->|       |      |
>>>>   |         |(6) token (code)
>>>>   |         |------>|      |
>>>>   |         |(7) token     |
>>>>   |         |<------|      |
>>>>   |         |(8) ServiceRequest(token)
>>>>   |         |------------->|
>>>>   |         |(9) ServiceResponse
>>>>   |         |<-------------|
>>>>   |(10) ServiceResponse    |
>>>>   |<--------|       |      |
>>>>   +         +       +      +
>>>>
>>>> - RP orchestrates interaction between User and OP to enable the user t=
o
>>>> obtain the protected resource.
>>>> - In step 1 & 10 User plays the role of the requestor of the resource.
>>>> - In step 2 User-Browser is used to pass control from User (in his rol=
e
>>>> as the requestor) to User (in his role as the RO)
>>>> - In step 4 User-Browser is used to pass control from User (in his rol=
e
>>>> as the RO) back to User (in his role as the requestor)
>>>>
>>>> When we are talking claims here, we are talking claims on the User (in
>>>> his role as the RO). The OP does not have any interaction with the Use=
r (in
>>>> his role as the requestor). In the case of an App2App redirection, the=
 OP
>>>> can not even assert about the user agent of the User (requestor).
>>>>
>>>> If there is any claim the OP can provide, it is a claim on the User
>>>> (RO).
>>>>
>>>> I hope this example clarifies the misunderstanding. Any attempt of
>>>> bringing this double role of the User into GNAP will also bring this
>>>> confusion. In order to keep this out of GNAP let us look for the right=
 term
>>>> for User (as a requestor) using the diagram displayed below.
>>>>
>>>> +----+  +------+  +---+  +---+  +---+
>>>> |Reqs|  |Orchst|  |RS |  |GS |  |RO |
>>>> +----+  +------+  +---+  +-+-+  +-+-+
>>>>   |(1) ServiceRequest      |      |
>>>>   |-------->|       |      |      |
>>>>   |         |(2) ServiceIntent:AuthZChallenge
>>>>   |         |<----->|      |      |
>>>>   |         |       |      |      |
>>>>   |         |(3) AuthZRequest(AuthZChallenge)
>>>>   |         |------------->|      |
>>>>   |         |       |      |(4) ConsentRequest:Grant
>>>>   |         |       |      |<---->|
>>>>   |         |(5) GrantAccess(AuthZ)
>>>>   |         |<-------------|      |
>>>>   |         |       |      |      |
>>>>   |         |(6) ServiceRequest(AuthZ):ServiceResponse
>>>>   |         |<----->|      |      |
>>>>   |(7) ServiceResponse     |      |
>>>>   |<--------|       |      |      |
>>>>   +         +       +      +      +
>>>>
>>>> - Replacing the word User helps clarify the difference between both
>>>> roles "Requestor" and "Resource Owner"
>>>> - Renaming claim by attaching the Object/target of the claim (e.g.:
>>>> RO-attributes, Requestor-Attributes, Orchestrator-Attributes) also hel=
ps
>>>> identify the source of those attributes (GS, RS, Client):
>>>>
>>>> Best regards.
>>>> /Francis
>>>>
>>>> On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt 
>>>> wrote:
>>>>
>>>>> It is not clear to me what it matters if a Claim comes from an RS, or
>>>>> from the GS, so I don't see a need to differentiate them.
>>>>>
>>>>> I would include verifiable credentials and user-bound keys as Claims.
>>>>>
>>>>> All the payment processing information I have seen has been in RAR.
>>>>> When would the Client get payment processing directly from the GS?
>>>>>
>>>>> What is your example for distributed networks storage locations? If
>>>>> what is stored is a statement about the user, then I would consider t=
hat a
>>>>> Claim as well.
>>>>>
>>>>> We disagree on how to map OIDC to GNAP.  The direct data is a claims
>>>>> request, the data coming indirectly is an access token request.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer  wrote=
:
>>>>>
>>>>>> Since we=E2=80=99re already talking about returning claims as direct=
 data as
>>>>>> well as a part of the resource API being protected, so we already ne=
ed a
>>>>>> way to differentiate the two kinds of items. Just calling it =E2=80=
=9Cclaims=E2=80=9D
>>>>>> doesn=E2=80=99t help, because as you=E2=80=99ve pointed out they cou=
ld show up in both
>>>>>> places. So yes, defining that difference is something we should worr=
y about
>>>>>> now, even if the core protocol only uses it for claims.
>>>>>>
>>>>>> The two forms of direct data that XYZ returns are subject identifier=
s
>>>>>> (a subset of identity claims) and assertions =E2=80=94 the latter be=
ing a container
>>>>>> not just for identity claims but also authentication information and=
 other
>>>>>> elements. Assertions are not claims themselves.
>>>>>>
>>>>>> Other use cases that have been brought up include verifiable
>>>>>> credentials and proofs, user-bound keys, payment processing informat=
ion,
>>>>>> and distributed network storage locations. I=E2=80=99m sure there ar=
e a lot more.
>>>>>> To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D but no=
t subsets of =E2=80=9Cclaims=E2=80=9D.
>>>>>> GNAP shouldn=E2=80=99t be defining what all of these look like, but =
it should
>>>>>> define a way to talk about them.
>>>>>>
>>>>>> I think different top-level request objects are better suited for
>>>>>> different query semantics. Like, for example, the OIDC =E2=80=9Cclai=
ms=E2=80=9D request,
>>>>>> which allows targeting of its claims information into different retu=
rn
>>>>>> buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D request =
at the very least. I
>>>>>> don=E2=80=99t think GNAP should define how to do this specific combi=
nation, that
>>>>>> should be for OIDF to debate and apply. The same with a DID service =
based
>>>>>> query, or Presentation Exchange [1], or anything else that people wa=
nt to
>>>>>> come up with.
>>>>>>
>>>>>> In my view, GNAP should define query structures for two things:
>>>>>> rights that get tied to an access token and data that comes back dir=
ectly
>>>>>> to the client. For the latter, I think we can do some very limited a=
nd very
>>>>>> useful specific items, which is what I=E2=80=99ve put into XYZ.
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>> [1] https://identity.foundation/presentation-exchange/
>>>>>>
>>>>>> On Jul 24, 2020, at 3:58 PM, Dick Hardt  wrote=
:
>>>>>>
>>>>>> I agree we want GNAP to be a strong foundation.
>>>>>>
>>>>>> Do you have an example of other "direct data"? If so, do you expect
>>>>>> it to be defined in the core protocol?
>>>>>>
>>>>>> I would expect an extension for other "direct data" to define top
>>>>>> level objects, and an appropriate definition for that "direct data".
>>>>>>
>>>>>> My "do we need to worry about it now" comment was on creating a
>>>>>> generic term for "direct data". Unless we are solving those now, we =
can let
>>>>>> further work define that "direct data" explicitly.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> =E1=90=A7
>>>>>>
>>>>>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer 
>>>>>> wrote:
>>>>>>
>>>>>>> Yes, I do think we need to worry about it to the extent that we are
>>>>>>> not creating something that is over-fit to a limited set of use cas=
es.
>>>>>>>
>>>>>>> GNAP should be a foundation that many amazing new things can be
>>>>>>> built on top of.
>>>>>>>
>>>>>>>  =E2=80=94 Justin
>>>>>>>
>>>>>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Justin, thanks for clarifying.
>>>>>>>
>>>>>>> What are some examples of other "direct data" that the GS may
>>>>>>> return? If it is not in core GNAP, do we need to worry about now? W=
e can
>>>>>>> then give the direct data from the GS that is not a claim, an appro=
priate
>>>>>>> name in that document.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m=
 saying. I agree
>>>>>>>> that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*=
. But the AS could return
>>>>>>>> other data directly to the client that isn=E2=80=99t about the use=
r. Those aren=E2=80=99t
>>>>>>>> =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =
=E2=80=9Cclaims=E2=80=9D can come back
>>>>>>>> from places other than directly, then we shouldn=E2=80=99t call ev=
erything that
>>>>>>>> comes back a =E2=80=9Cclaim=E2=80=9D.
>>>>>>>>
>>>>>>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean =
what it already means and
>>>>>>>> come up with a new word to mean =E2=80=9Cthings that come back dir=
ectly from the
>>>>>>>> AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=
=99s more complete definitions, but
>>>>>>>> to simplify:
>>>>>>>>
>>>>>>>> Claims:
>>>>>>>> - information about the user
>>>>>>>> - can come back directly from the AS
>>>>>>>> - can come back in a resource from the RS
>>>>>>>>
>>>>>>>> Resource:
>>>>>>>> - Returned from an RS
>>>>>>>> - Protected by access token
>>>>>>>> - Could contain claims about the user
>>>>>>>>
>>>>>>>> Direct data (or some better name):
>>>>>>>> - Returned directly from AS
>>>>>>>> - Could contain claims about the user
>>>>>>>>
>>>>>>>> I think the problem is that some people are using =E2=80=9Cclaims=
=E2=80=9D to mean
>>>>>>>> #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=
=E2=80=99s important to
>>>>>>>> remember, when talking about OIDC, that an IdP in OIDC combines an=
 AS and
>>>>>>>> an RS into one entity for identity information. There can be other=
 RS=E2=80=99s as
>>>>>>>> well, and there usually are in the wild, but the one defined by OI=
DC is the
>>>>>>>> UserInfo Endpoint. The fact that it returns user data doesn=E2=80=
=99t make it any
>>>>>>>> less of an RS.
>>>>>>>>
>>>>>>>>  =E2=80=94 Justin
>>>>>>>>
>>>>>>>> * In the wider context of things like the information claims insid=
e
>>>>>>>> a JWT, the claims could be about literally anything, but that=E2=
=80=99s not what
>>>>>>>> we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99=
s being used.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly
>>>>>>>> from the OP in an ID Token, or the Client can obtain Claims using =
an access
>>>>>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>>>>>
>>>>>>>> The Claims are about the User (not a RO).
>>>>>>>>
>>>>>>>> In XAuth, I'm proposing the Client may obtain bare claims from the
>>>>>>>> GS directly in addition to the mechanisms in ODIC.
>>>>>>>>
>>>>>>>> So I don't think we are changing the definition of Claim from how
>>>>>>>> it has been used in OIDC, and I fail to see any reason to NOT use =
Claim.
>>>>>>>>
>>>>>>>> Justin: you allude to Claims being about a party other than the
>>>>>>>> User. Would you provide an example?
>>>>>>>>
>>>>>>>> /Dick
>>>>>>>>
>>>>>>>> [1]
>>>>>>>>
>>>>>>>> UserInfo Endpoint
>>>>>>>> Protected Resource that, when presented with an Access Token by th=
e
>>>>>>>> Client, returns authorized information about the End-User represen=
ted by
>>>>>>>> the corresponding Authorization Grant. The UserInfo Endpoint URL M=
UST use
>>>>>>>> the https scheme and MAY contain port, path, and query parameter c=
omponents.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> =E1=90=A7
>>>>>>>>
>>>>>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I want to focus on one aspect here:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> A Claim is a well understood term in the field. We should use it=
.
>>>>>>>>>> It is still a Claim if it comes directly from the GS or from an =
RS.
>>>>>>>>>>
>>>>>>>>> I do not understand why a Resource release by an RS shall be h to
>>>>>>>>> as a claim, even if the content of the Resource is an assertion. =
It will
>>>>>>>>> lead to confusion. If we limit claims to information GS releases =
into
>>>>>>>>> Token, User Info, and other objects it returns, this will help se=
parate
>>>>>>>>> responsibilities between GS and RS. As soon as RS services and in=
formation,
>>>>>>>>> this is called a Resource, no matter the nature of the content of=
 that
>>>>>>>>> information.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9C=
claim=E2=80=9D in the way
>>>>>>>>> that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could=
 come back through an RS =E2=80=94 but in
>>>>>>>>> the context of GNAP, that makes it a resource. So we need a diffe=
rent word
>>>>>>>>> for data coming back directly from the AS to the client. Sometime=
s it=E2=80=99s
>>>>>>>>> going to be about the user, and that=E2=80=99s what we=E2=80=99re=
 going to focus on here,
>>>>>>>>> but since you can also get information about the user from a reso=
urce we
>>>>>>>>> can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think thi=
s has been at the heart of a lot
>>>>>>>>> of confusion in recent threads, as well as confusion about the sc=
ope of the
>>>>>>>>> inclusion of identity in the GNAP protocol.
>>>>>>>>>
>>>>>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already=
 does, and let=E2=80=99s find a
>>>>>>>>> way to differentiate between when an item, claim or otherwise,  c=
omes as
>>>>>>>>> part of a resource and when it comes back directly. This is an im=
portant
>>>>>>>>> differentiating feature for GNAP.
>>>>>>>>>
>>>>>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in l=
ove with:
>>>>>>>>>
>>>>>>>>>  - direct data
>>>>>>>>>  - properties
>>>>>>>>>  - details
>>>>>>>>>  - statements
>>>>>>>>>
>>>>>>>>> The important thing here is that it=E2=80=99s not necessarily :ab=
out: the
>>>>>>>>> RO, and that it is :not: in a resource.
>>>>>>>>>
>>>>>>>>> Any other thoughts?
>>>>>>>>>
>>>>>>>>>  =E2=80=94 Justin
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>> --
>>>> 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/
>>
>

--=20
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/

--000000000000f7817405ab698fe4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Sun, Jul 26, 2020 at 11:58 PM Dick=
 Hardt <dick.hardt@gmail.com=
> wrote:


On Sun, Jul 26, 2020 at 6:45 PM Francis P=
ouatcha <fpo@adorsys=
.de> wrote:
Hello Dick,

On Sun, Jul 26, 2020 at 9:1=
4 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis

User =
is a well understood term in OIDC and OAuth -- and User means the same in b=
oth.=C2=A0

Resource Owner is who owns =
the resource, and the term is introduced for when the User is NOT the Resou=
rce Owner.=C2=A0
This distinction is what make=
s it confusing as we are comparing an Entity (the User) to a Role (the RO).=
 We need two roles.

Or we=
 could think of them all as entities. The RO is the entity that owns the re=
source. The User is the human that is using the Client.=C2=A0
When we think of them as entities, we run into confli=
cts when Entity-User eq. Entity-RO.
When we think of them as role=
s, Role-User is always !=3D Role-RO=C2=A0
=C2=
=A0
=C2=A0

I also think that =
Client and Resource Server are well understood terms.
Looks like contributors on the list still need clarification on=C2=
=A0the "orchestration" role of a client.

When I think of orchestration, I think of coordin=
ating,=C2=A0which is not what I think the=C2=A0Client is doing. The Client =
wants to consume the Claims and the Resources (combined are a Grant). The C=
lient requests the Grant from the Grant Server. Where is the orchestration?=

Look at the client. It is the center of=
 interaction between User, GS and RS.
=C2=A0

It is not clear to me why we would want =
to reinvent these terms. Reading over your flows, I think it would be usefu=
l=C2=A0to understand the requirements you have for your use case, otherwise=
 I fear we will be talking past each other.
Th=
e oAuth flow is there as a memo. The other flow is what I proposed before. =
Is there to emphasize we need to work on roles and not on entities. It is n=
ot a suggestion=C2=A0to rename=C2=A0well known idioms. It is an attempt=C2=
=A0to give=C2=A0them a proper definition in the context of this protocol. D=
efinition based on their roles in the protocol flows.

I'd like to take a step back and understan=
d the requirements. We are deep into solutions.
No, we are at the fundamental level. We Have to decide on=C2=A0whet=
her=C2=A0to build a model based on roles oron entities... Then we use the r=
esult [ENTITY XOR ROLES] to define the use cases.
/Francis
<=
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">
=C2=A0

=
Best regards.
/Francis

/Dick

3D"==E1=90=A7

On Fri, Jul 24, 2020 at 7:21 PM Fra=
ncis Pouatcha <fpo@a=
dorsys.de> wrote:
Below my opinion=C2=A0=
on the term Claim:

Starting with illustration of parties/roles:

User:=C2=A0
This word =
is misleading because of its double role in oAuth2 and OIDC (see below). In=
 GNAP let us have the User play only the role of a requestor. (from Justin =
reference to "Requesting Party").

Client:
This is also tightly=C2=A0bound to the oAu=
th2 and OIDC. The real purpose of this role is to orchestrate resource acce=
ss on behalf of the "Requestor". Let us call this for now the &qu=
ot;Orchestrator"

=

Resource Owner (RO):
<=
font face=3D"monospace">This is IMO the most correct word in the entire pro=
tocol. Authorisation is always about the owner of something granting access=
 to a requestor. It really=C2=A0does not matter if a human interaction is i=
nvolved. We will have to forget oAuth2 and OIDC of also calling this a User=
.

Grant Server:=C2=A0
Even though the definition of the UserInfo endpoint in OIDC as a protect=
ed resource hazardously makes an OP an RS, we shall not repeat the same mis=
take here. We need a clear separation between roles of GS and RS without ov=
erlapping.

=
Resource Server: services resources.
<=
div>
Unless I got=C2=A0it wrong, GNAP is about grant negotiation and authorizat=
ion. This means:

GNAP is about some party requesti=
ng access to some resources.
GNAP=
 is about the resource owner consenting access to that resource.
GNAP is about defining the infrastructure t=
hat allows the requesting party to access a resource.=C2=A0

G=
NAP designs this infrastructure around:
- an orchestrator (what we refer to as a client)
- an grant manager (what we refer to as a GS/AS)
- the custodian of the resource (wha=
t we call a RS)

=

As you see:
- The word User does not appear here, and is not relevant as the f=
ocus=C2=A0is on authorizing access to a resource.
- The word Claim is as well absent.

Claim re=
lated to RO:
The word Claim might=
 start getting visible if the orchestrator (a.k.a. Client) or the custodian=
 (a.k.a RS) needs some additional information on the RO to proceed with the=
 access control decision. These claims refer to assertions of attributes or=
 properties of the RO. These claims are issued by the GS as the GS manages =
interaction with the RO (see below). In this first place information about =
the requesting party (erroneously.k.a. User=
) is not relevant to the negotiation and provisioning framework. Let us cal=
l this sort of claim "RO-Attributes". A better name is welcome.

Some advanced resource provisioning frameworks might require=
 knowledge on attributes of the requesting party (e.k.a User). These attrib=
utes shall be collected by the=C2=A0orchestrator (a.k.a Client) and added t=
o the resource request. There is no way the GS can collect these attributes=
 as the GS role has no interaction with the requesting party (e.k.a User).=
=C2=A0Let us call this sort of claim "Requestor-Attributes". A be=
tter name will be welcome.

Some assertions are even related t=
o the orchestrator=C2=A0(a.k.a Client) itself. This is the case of the publ=
ic key of an orchestrator=C2=A0used by the GS to "sender constrain&quo=
t; an access token. Let us call this type of claim "Orchestrator-Attri=
butes".

This is a sample mapping of OIDC.

=
+----+ =C2=A0 =C2=A0+---+ =C2=A0 +---+ =C2=A0+---+
|User| =C2=A0 =C2=A0|=
RP | =C2=A0 |OP | =C2=A0|RS |
+----+ =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 |(2) redi=
rect=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |<--------| =
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=3D=3D=3D User (requestor) passes control to User (RO) =3D=3D=
=3D
=C2=A0 |(3) Auth + Consent =
=C2=A0 =C2=A0 =C2=A0|
=C2=A0 |---------------->| =C2=A0 =C2=A0 =C2=A0=
|
=C2=A0 |(4) redirect (code) =C2=A0 =C2=A0 |
=C2=A0 |<-----------=
-----| =C2=A0 =C2=A0 =C2=A0|
=3D=
=3D=3D User (RO) passes control back to User (requestor) =3D=3D=3D
=C2=
=A0 |(5) get(code) =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |--------=
>| =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) token (code)
=C2=A0 | =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) token =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<=
;------| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(8)=
 ServiceRequest(token)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |-----------=
-->|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(9) ServiceResponse
=C2=
=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<-------------|
=C2=A0 |(10) Servi=
ceResponse =C2=A0 =C2=A0|
=C2=A0 |<--------| =C2=A0 =C2=A0 =C2=A0 | =
=C2=A0 =C2=A0 =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 orchestrates inte=
raction between User and OP to enable the user to obtain the protected reso=
urce.
- In step 1 & 10 User p=
lays the role of the requestor of the resource.
- In step 2 User-Browser is used to pass control from User (=
in his role as the requestor) to User (in his role as the RO)
<=
div>- In step 4=C2=A0User-Browser is used to pass =
control from User (in his role as the RO) back to=C2=A0User (in his role as=
 the requestor)

=

When we are talking claims here, we are talki=
ng claims on the User (in his role as the RO). The OP does not have any int=
eraction with the User (in his role as the requestor). In the case of an Ap=
p2App redirection, the OP can not even assert about the user agent of the U=
ser (requestor).

If there is any claim the OP can provide, it=
 is a claim on the User (RO).
I hope this example clarifies t=
he misunderstanding. Any attempt of bringing this double role of the User i=
nto GNAP will also bring this confusion. In order to keep this out of GNAP =
let us look for the right term for User (as a requestor) using the diagram =
displayed below.

+----+ =C2=A0+------+ =C2=A0+---+ =C2=A0+---=
+ =C2=A0+---+
|Reqs| =C2=A0|Orchst| =C2=A0|RS | =C2=A0|GS | =C2=A0|RO |<=
br>+----+ =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 |(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 |(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|(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 |(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 |(6) ServiceRequ=
est(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 |(7) ServiceR=
esponse =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |<--------| =C2=
=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 +=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0 + =C2=A0 =C2=A0 =C2=A0+=
 =C2=A0 =C2=A0 =C2=A0+

- Replacing the word User helps cl=
arify the difference between both roles "Requestor" and "Res=
ource Owner"
- Renaming clai=
m by attaching the Object/target of the claim (e.g.: RO-attributes, Request=
or-Attributes, Orchestrator-Attributes) also helps identify the source of t=
hose attributes (GS, RS, Client):

Best rega=
rds.
/Francis

On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt &l=
t;dick.hardt@gmai=
l.com> wrote:
It is not clear to me what it matters if a Claim=
 comes from an RS, or from the GS, so I don't see a need to differentia=
te them.

I would include verifiable credentials an=
d user-bound keys as Claims.

All the payment proce=
ssing information I have=C2=A0seen has been in RAR. When would=C2=A0the Cli=
ent get payment processing directly from the GS?

W=
hat is your example for distributed networks storage locations? If what is =
stored is a statement about the user, then I would consider that a Claim as=
 well.

We disagree on how to map OIDC to GNAP.=C2=
=A0 The direct data is a claims request, the data coming indirectly is an a=
ccess token request.



On Fri, Jul 24, 202=
0 at 1:39 PM Justin Richer <jricher@mit.edu> wrote:
Since we=E2=80=99re already talking about retu=
rning claims as direct data as well as a part of the resource API being pro=
tected, so we already need a way to differentiate the two kinds of items. J=
ust calling it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, because as yo=
u=E2=80=99ve pointed out they could show up in both places. So yes, definin=
g that difference is something we should worry about now, even if the core =
protocol only uses it for claims.

The two forms of direc=
t data that XYZ returns are subject identifiers (a subset of identity claim=
s) and assertions =E2=80=94 the latter being a container not just for ident=
ity claims but also authentication information and other elements. Assertio=
ns are not claims themselves.=C2=A0

Other use case=
s that have been brought up include verifiable credentials and proofs, user=
-bound keys, payment processing information, and distributed network storag=
e locations. I=E2=80=99m sure there are a lot more. To me, these are subset=
s of the =E2=80=9Cdirect data=E2=80=9D but not subsets of =E2=80=9Cclaims=
=E2=80=9D. GNAP shouldn=E2=80=99t be defining what all of these look like, =
but it should define a way to talk about them.

I t=
hink different top-level request objects are better suited for different qu=
ery semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=9D request=
, which allows targeting of its claims information into different return bu=
ckets. This overlaps with the =E2=80=9Cresources=E2=80=9D request at the ve=
ry least. I don=E2=80=99t think GNAP should define how to do this specific =
combination, that should be for OIDF to debate and apply. The same with a D=
ID service based query, or Presentation Exchange [1], or anything else that=
 people want to come up with.

In my view, GNAP sho=
uld define query structures for two things: rights that get tied to an acce=
ss token and data that comes back directly to the client. For the latter, I=
 think we can do some very limited and very useful specific items, which is=
 what I=E2=80=99ve put into XYZ.

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

[1]=C2=A0https://identity.f=
oundation/presentation-exchange/

=

On Jul 24, 2020, at 3:58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I agree we want GNAP to be a strong foundation.=C2=
=A0

Do you have an example of other "direct data&qu=
ot;? If so, do you expect it to be defined in the core protocol?
=

I would expect an extension for other "direct data"=
; to define top level objects, and an appropriate definition for that "=
;direct data".

My "do we need to worry a=
bout it now" comment was on creating a generic term for "direct d=
ata". Unless we are solving those now, we can let further work define =
that "direct data" explicitly.




3D""=E1=90=A7
On Fr=
i, Jul 24, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
Yes, I do think we need to worr=
y about it to the extent that we are not creating something that is over-fi=
t to a limited set of use cases.=C2=A0

GNAP should be a =
foundation that many amazing new things can be built on top of.
=C2=A0=E2=80=94 Justin

On Jul 24, 2020, at 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

=

Justin, thanks for clarifying.

Wha=
t are some examples of other "direct data" that the GS may return=
? If it is not in core GNAP, do we need to worry about now? We can then giv=
e the direct data from the GS that is not a claim, an appropriate name in t=
hat document.



On Fri, Jul 24, 2020 at 11=
:46 AM Justin Richer <jricher@mit.edu> wrote:
Dick: No, I think you=E2=80=99re misunderstanding wh=
at I=E2=80=99m saying. I agree that =E2=80=9Cclaims=E2=80=9D are about the =
user, in this context*. But the AS could return other data directly to the =
client that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=9Ccla=
ims=E2=80=9D by the classical definition. Also since =E2=80=9Cclaims=E2=80=
=9D can come back from places other than directly, then we shouldn=E2=80=99=
t call everything that comes back a =E2=80=9Cclaim=E2=80=9D.

=

I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean what=
 it already means and come up with a new word to mean =E2=80=9Cthings that =
come back directly from the AS=E2=80=9D. These aren=E2=80=99t meant to repl=
ace Francis=E2=80=99s more complete definitions, but to simplify:

Claims:
	- information about the user
	- can come back directly from the AS
	- can come back in a resource from the RS

Resource:
	- Returned from an RS
	- Protected by access token
	- Could contain claims about the user

<=
/div>
Direct data (or some better name):
	- Returned directly from AS
	- Could contain claims about the user

I think the problem is that some people are using =E2=
=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. It=E2=80=99s clearly =
#1 in OIDC. But: It=E2=80=99s important to remember, when talking about OID=
C, that an IdP in OIDC combines an AS and an RS into one entity for identit=
y information. There can be other RS=E2=80=99s as well, and there usually a=
re in the wild, but the one defined by OIDC is the UserInfo Endpoint. The f=
act that it returns user data doesn=E2=80=99t make it any less of an RS.
=C2=A0=E2=80=94 Justin

* In the w=
ider context of things like the information claims inside a JWT, the claims=
 could be about literally anything, but that=E2=80=99s not what we=E2=80=99=
re discussing here and it=E2=80=99s not how it=E2=80=99s being used.
<=
div>

On Jul 24, 2020, at 1:24 PM=
, Dick Hardt <=
dick.hardt@gmail.com> wrote:

In OpenI=
D Connect (OIDC), the Client can obtain Claims directly from the OP in an I=
D Token, or the Client can obtain Claims using an access token to call the =
UserInfo endpoint, a Protected Resource[1].

The Claims a=
re about the User (not a RO).

In XAuth, I'm pr=
oposing the Client may obtain bare claims from the GS directly in addition =
to the mechanisms in ODIC.

So I don't think we=
 are changing the definition of Claim from how it has been used in OIDC, an=
d I fail to see any reason to NOT use Claim.

Justi=
n: you allude to Claims being about a party other than the User. Would you =
provide an example?

/Dick

[1]
UserInfo Endpoint
Protected Resource that, when present=
ed with an Access Token by the Client, returns authorized information about=
 the End-User represented by the corresponding Authorization Grant. The Use=
rInfo Endpoint URL MUST use the https scheme and MAY contain port, path, an=
d query parameter components.



3D""=E1=90=A7

On Fri, Jul 24, 2020=
 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspect here:

<=
br>
A Claim is a well understood term in the field. We should use=
 it. It is still a Claim if it comes directly from the GS or from an RS.=C2=
=A0
I do not understand why a Resource release=
 by an RS shall be h to as a claim, even if the content of the Resource is =
an assertion. It will lead to confusion. If we limit claims to information =
GS releases into Token, User Info, and other objects it returns, this will =
help separate responsibilities between GS and RS. As soon as RS services an=
d information, this is called a Resource, no matter the nature of the conte=
nt of that information.

=
This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=E2=
=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=
=9D could come back through an RS =E2=80=94 but in the context of GNAP, tha=
t makes it a resource. So we need a different word for data coming back dir=
ectly from the AS to the client. Sometimes it=E2=80=99s going to be about t=
he user, and that=E2=80=99s what we=E2=80=99re going to focus on here, but =
since you can also get information about the user from a resource we can=E2=
=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at th=
e heart of a lot of confusion in recent threads, as well as confusion about=
 the scope of the inclusion of identity in the GNAP protocol.
So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it alrea=
dy does, and let=E2=80=99s find a way to differentiate between when an item=
, claim or otherwise,=C2=A0=C2=A0comes as part of a resource and when it co=
mes back directly. This is an important differentiating feature for GNAP.

Some straw man ideas, none of which I=E2=80=99m par=
ticularly in love with:

=C2=A0- direct data
<=
div>=C2=A0- properties
=C2=A0- details
=C2=A0- statemen=
ts

The important thing here is that it=E2=80=99s n=
ot necessarily :about: the RO, and that it is :not: in a resource.

Any other thoughts?

=C2=A0=E2=80=94 Ju=
stin












-- 
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/


--000000000000f7817405ab698fe4--


From nobody Mon Jul 27 04:17: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 B0D7A3A0D8A for ; Mon, 27 Jul 2020 04:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 KBP4aRy0KVEd for ; Mon, 27 Jul 2020 04:16:52 -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 27FBA3A18AB for ; Mon, 27 Jul 2020 04:16:52 -0700 (PDT)
Received: from [192.168.1.3] (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 06RBGlvw016782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 07:16:47 -0400
From: Justin Richer 
Message-Id: <104C5755-2EF0-4295-879C-1499D1139160@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_472AFC6C-C496-4B80-82C2-BEBC31783399"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 27 Jul 2020 07:16:47 -0400
In-Reply-To: 
Cc: Francis Pouatcha , Dick Hardt , Mike Jones , Fabien Imbault , Mike Varley , "txauth@ietf.org" 
To: Tom Jones 
References: <29AAF03B-12B6-4E61-9BF4-EF951506931B@securekey.com> <4F48268B-D011-42E5-A2D2-F39CF3E4AB5E@mit.edu>    <325BC9ED-06AF-4E00-9BC7-195FAE1A9646@mit.edu>        
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Key handle vs client id & handle
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, 27 Jul 2020 11:16:58 -0000

--Apple-Mail=_472AFC6C-C496-4B80-82C2-BEBC31783399
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1. There are a lot of use cases where the client isn=E2=80=99t =
identified using an identifier known to the AS. OAuth/OIDC don=E2=80=99t =
fit very well in those use cases because the protocol :requires: a =
client_id. That=E2=80=99s why we get things like the OIDC Federation =
clever =E2=80=9Cinline registration=E2=80=9D and SIOP that both add =
semantics to a required field that they don=E2=80=99t need for its =
original purpose.

What I=E2=80=99m arguing is that we shouldn=E2=80=99t :require: a =
client_id, but we can :allow: its equivalent for an AS that supports it. =
If you have an identifier known to the AS and that identifier is =
presented along with some trusted material (like the proof of a key via =
signature, for instance), then that is a subset of what can be trusted =
and why. And what you=E2=80=99re identifying, ultimately, is the key =
being presented. All other cases of identifying the =E2=80=9Cclient=E2=80=9D=
 separate from its key material are actually presenting other forms of =
trust and shouldn=E2=80=99t be conflated with an all-present client =
identifier.=20

I agree that fundamentally a trust framework is the way to look at it: =
the AS needs to decide if it trusts the entity making the call to start =
a request, and what it trusts that entity to do. Identification of that =
entity by some known value is a subset of what is possible by trust =
frameworks.

 =E2=80=94 Justin

> On Jul 26, 2020, at 10:15 PM, Tom Jones  =
wrote:
>=20
> one other tf could be "I am bound the terms of the GDPR".
> If we go that way at all, I would also recommend a MUST or at least a =
SHOULD "jurisdiction" field.
> GNAP may as well take the moral high ground, it is pretty much empty =
space right now.
> Peace ..tom
>=20
>=20
> On Sun, Jul 26, 2020 at 6:55 PM Francis Pouatcha > wrote:
> +1 Tom's input.
>=20
> This discussion about Key Handle vs. client id & handle wouldn't exist =
if GNAP had the notion of TF defining how the GS/RS/Clients identify and =
authenticate each other.
>=20
> A simple TF can describe the standard case (happy path) without having =
to foresee all eventualities.
>=20
> A GNAP profile will also be simple as it will keep out everything else =
(e.g. US Healthcare, PSD2).
>=20
> BR=20
> /Francis
>=20
>=20
> On Sun, Jul 26, 2020 at 9:43 PM Tom Jones =
> =
wrote:
> You should consider a trust framework to be first of all a set of =
qualifying criteria above and beyond the literal meaning of the =
standard.
> Ours is focused on US Healthcare, but lots of others make sense. The =
international R&E org is the basis for the openid federation doc.
> Secondarily the trust framework could vet members so that they made =
affirmative statements about their compliance.
> Tertiary they tf could mandate testing of the members. That is the =
case for US Healthcare.
> the tf could be blank for sites with no moral scruples whatsoever. =
(the majority of sites i am sure.)
> Peace ..tom
>=20
>=20
> On Sun, Jul 26, 2020 at 6:18 PM Dick Hardt > wrote:
> Hi Francis
>=20
> While a Trust Framework concept looks to make sense for PSD2 use =
cases, there are lots of other use cases.
>=20
> How would you see existing OAuth 2 and OIDC concepts fitting into a =
Trust Framework concept?
>=20
> /Dick
>=20
> =E1=90=A7
>=20
> On Sat, Jul 25, 2020 at 8:41 PM Francis Pouatcha > wrote:
> I just read through some work being done by Tom at the FIRE (Federated =
Identifiers for Resilient Ecosystems) working group and it confirms my =
intention of suggesting the consideration of a "Trust Framework" as a =
context defining how to handle the client_id.
>=20
> The procedure the GS applies to trust a client is derived from the =
"Trust Framework" that governs the environment in which GS and Client =
are operating.
>=20
> In the European PSD2 ecosystem, National Country Authorities (a.k.a =
Market Authorities or Regulators):
> - delegate the production of client certificates to Trust Service =
Providers (TSPs). TSPs are known certification authorities (CAs) in the =
corresponding countries.
> - maintain a register of Certified Third Party Providers (TPPs) at the =
European Banking Association (EBA), where the validity of the TPP =
license can be verified, in addition to the client certificate.
>=20
> Designing an authorization framework around the PSD2 ecosystem, there =
is no need to maintain any static or dynamic client_id. Each request is =
associated with an SSL client certificate called QWAC (Qualified Website =
Assertion Certificate).=20
> - This certificate can be verified as the GS maintains a list of all =
known TSP's CA authorized to release PSD2 client certificates.
> - This certificate also contains the list of roles assigned to the TPP =
by the regulator PSP_AS (bank), PSP_PI (payment initiation), PSP_AI =
(account information), PSP_IC (card) sufficient for the client access =
control in the PSD2 trust framework.
> - This certificate contains a permanent "Competent Authority" that =
uniquely identifies the NCA issuing the TPP license.
> - This certificate contains a permanent "Authorization Number" that is =
unique in the context of the NCA.
> - so AuthorizationNumber@CompetentAuthority is globally unique in the =
context of the PSD2 trust framework.
>=20
> Given these facts, GS implementing PSD2 do not need to register =
clients.=20
> - Each request of the client to the GS can be mTLS secured using the =
QWAC.
> - GS can extract all information needed to perform authorization from =
that certificate.
>=20
> This use case does not need an extra client_id at the protocol level.=20=

>=20
> This is:
> - based on the experience we are making implementing PSD2,
> - based on my reading Tom's FIRE use case in the health sector on the =
sharing of Patient Health Information (PHI) among health care providers,
>=20
> I suggest GNAP introduces the notion of "Trust framework" that governs =
the environment in which RS, GS and Client interoperate. We can then =
delegate the decision on specifying the necessity and functions of a =
client_id to the trust framework.
>=20
>=20
> On Thu, Jul 16, 2020 at 7:58 PM Tom Jones =
> =
wrote:
> I have been working on different level s of identifier, but from the =
mobile app perspective. That's the hardest case as you need to boot =
strap trust. I suspect that in the web site case you will need these =
levels. Transport, application, real world.
>=20
> If anyone wants to work on these, let me know and I'll get you the =
links in Kantara.
>=20
> thx ..Tom (mobile)
>=20
> On Thu, Jul 16, 2020, 2:47 PM Justin Richer > wrote:
> For all of these, I still say we should have different levels of =
identifier. A =E2=80=9Cclient ID=E2=80=9D should identify the client, =
and not be used as a stand-in for other things.=20
>=20
> Off the top of my head I think we might want to have identifiers, =
assertions, proofs, and other trust-binding items for:
>=20
>  - Organizations
>  - Devices
>  - Software applications
>  - Software instances
>  - Software versions
>=20
> So if we=E2=80=99re going to talk about identifying these aspects, we =
should tackle each as its own thing and not mush it all into =
=E2=80=9Cclient_id=E2=80=9D. That way, hopefully, GNAP can have a much =
better idea what a =E2=80=9Cclient=E2=80=9D is than OAuth 2 currently =
does.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 16, 2020, at 4:34 PM, Dick Hardt > wrote:
>>=20
>> One client identifier was a simplistic example. Org A may have =
numerous clients, perhaps in different teams, perhaps in different =
services, each with their own policy at Org B.
>>=20
>> When one of the Org A clients makes a call to the Org B AS, it needs =
to identify itself with some identifier so that Org B knows which policy =
to enforce. Why not the Client ID?
>>=20
>> I also agree with your comments that other client identification =
situations are different, and forcing the same identification model on =
them does not make sense, but I fail to see the value throwing out a =
concept (client_id) that has worked well for the use cases it was =
designed for.=20
>>=20
>>=20
>> =E1=90=A7
>>=20
>> On Thu, Jul 16, 2020 at 1:08 PM Justin Richer > wrote:
>> I think that the cross-organizational trust model is an interesting =
one, and in fact it=E2=80=99s one of the things that=E2=80=99s pushed me =
away from a client_id. In the scenario that you describe, =
=E2=80=9Cclient_id=E2=80=9D is used to represent something that it was =
never meant to represent: the organization running the software, not the =
software itself. It isn=E2=80=99t a client_id, and while in OAuth 2 the =
client_id could be co-opted to carry that information, it=E2=80=99s =
considered bad practice to share client_ids between multiple pieces of =
software.=20
>>=20
>> I would argue that to address this use case properly, there should be =
another level of identifier to bridge that trust that the software can =
present, showing that it is a part of Organization A, and not =
Organization C. This isn=E2=80=99t a client identifier, it=E2=80=99s an =
organization identifier, and it should be separate. You might want to =
identify both the client instance as well as the organization it=E2=80=99s=
 a part of, for example. This is part of the motivation behind putting =
=E2=80=9Corganizational data=E2=80=9D within scope for the client to =
send to the AS, after all.
>>=20
>> Therefore, I strongly disagree that this scenario =E2=80=9Crequires=E2=80=
=9D a client_id to be solved. In fact, I think that solving this =
scenario with a client_id is an anti-pattern that stems from OAuth 2=E2=80=
=99s over-reliance on client_id as a persistent identifier within the =
protocol, and we can and should do better with GNAP. It=E2=80=99s very =
similar to Mike Jones=E2=80=99s referenced federation document, where =
the client_id is co-opted as a means of bootstrapping client =
registration and discovery, or in the Solid Authentication specification =
which stuffs a WebID into the client_id field.
>>=20
>> With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the tools that =
we had to solve our problems, and come up with some very clever =
solutions. What I=E2=80=99m trying to argue to this community is that we =
are in a position to create our own, better tools.=20
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 16, 2020, at 2:00 PM, Dick Hardt > wrote:
>>>=20
>>> Justin,=20
>>>=20
>>> While I agree that the assumption in OAuth 2 that all Clients have a =
client_id is problematic, the requirement for a client_id in many use =
cases is still there, and it does not represent a piece of software, but =
a relationship between parties.
>>>=20
>>> Organization A writes client software that calls resources managed =
by the AS in Organization B. The client_id represents Organization A to =
Organization B. Organization B does not care what software Organization =
A is running, and there may be numerous pieces of software at =
Organization A that use the same client_id. The access granted by =
Organization B to Organization A needs to be able to be different than =
the rights granted to Organization C.=20
>>>=20
>>> I agree that we don't want to force all clients to have a client_id, =
and as discussed, there are a variety of inputs for an AS to accept =
calls from a piece of software, and often, that will be a particular =
instance of the software, but we also don't want to force clients to all =
be treated the same, because they are not..=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> On Thu, Jul 16, 2020 at 8:24 AM Justin Richer > wrote:
>>> Exactly =E2=80=94 when we start to look at it as managing the =
lifecycle of a piece of software, instead of a registration at the AS, =
we can start thinking in different terms what =E2=80=9Ctrusting=E2=80=9D =
the client means in the context of what the client is doing. That trust =
could come from some kind of signed attestation about the software (like =
the OAuth 2 DynReg software statement), or it could come from some =
externally fetchable item (like a Solid WebID, a DID, or the OIDC =
Federation extension), or it could come from someone sitting at a =
console and typing in information and getting back an identifier. And =
none of these need to pretend to be a global =E2=80=9Cclient id=E2=80=9D =
for it to work. The world of clients is much more diverse than OAuth 2 =
likes to admit, and we see that with trying to nail down a =
=E2=80=9Cconfidential=E2=80=9D vs. =E2=80=9Cpublic=E2=80=9D vs. =
=E2=80=9Cdynamic=E2=80=9D vs. =E2=80=9Cstatic=E2=80=9D vs. =
=E2=80=9Cautomatic=E2=80=9D vs. =E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 =
any number of other things.=20
>>>=20
>>> OAuth 2 only needs client IDs because the front channel needs a way =
to pass client identifiers when the client can=E2=80=99t authenticate =
itself directly. We tried to get rid of this restriction with PAR and =
JAR together, but there turned out to be corner cases in OAuth 2=E2=80=99s=
 world that still needed client_id, and implementations assumed it would =
be there anyway.=20
>>>=20
>>> In GNAP, we can avoid that problem from the beginning by looking at =
the model differently and understanding where we=E2=80=99re coming from, =
and why.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>> On Jul 16, 2020, at 3:49 AM, Fabien Imbault =
> wrote:
>>>>=20
>>>> +1 on that.
>>>>=20
>>>> We can then see it more as life cycle management of the client than =
registration per say, and this comes with many benefits compared to the =
current client_id.
>>>>=20
>>>> Fabien
>>>>=20
>>>> On Tue, Jul 14, 2020 at 9:32 PM Justin Richer > wrote:
>>>> I not only agree with Mike Jones that =E2=80=9Cautomatic =
registration=E2=80=9D should be part of the process, but I would argue =
that that kind of model should be a default mode of operation. If you =
have an identifier that you can send to short-circuit that, great! But =
we should focus on having the capability of inlining a lot of this =
information wherever possible. This is already the direction that the =
input proposals are heading.
>>>>=20
>>>> So I kind-of agree that =E2=80=9Cregistration=E2=80=9D is in scope =
for the protocol in general, and since both XYZ and Xauth have =
mechanisms that allow the client to present a key and get back an =
identifier that it can use in the future we have something equivalent.=20=

>>>>=20
>>>> But I think there=E2=80=99s a little more to it than that: =
Ultimately, I think we should question thinking in terms of =
=E2=80=9Cregistration=E2=80=9D, a model which has hampered the OAuth 2 =
model in a lot of use cases. For example, the federation draft Mike =
Jones references below hacks the =E2=80=9Cclient_id=E2=80=9D parameter =
and makes it point to a document that the AS has to fetch. This =
construct is done for two reasons: (1) Oauth requires a =E2=80=9Cclient_id=
=E2=80=9D in the request and (2) it=E2=80=99s difficult to pass =
information by value to the AS due to front-channel restrictions. Since =
we=E2=80=99re defining a new protocol, we don=E2=80=99t need to hack =
that functionality into a =E2=80=9Cclient ID=E2=80=9D or equivalent and =
instead we can pass that information directly in the protocol. If we =
don=E2=80=99t assume that the client *has* to have a client ID =
equivalent, but it *can* have one in a set of defined circumstances, =
then I think we are in a much better spot. This is the reasoning for =
XYZ=E2=80=99s model of having clients identified by the key, and that =
key can potentially be passed by a reference identifier.
>>>>=20
>>>> I think all of the use cases that Mike Varley presents below are =
all valid directions, with the caveat that we shouldn=E2=80=99t assume a =
client should be presenting an ID at all steps. Mechanisms like software =
statements should be presentable apart from a client ID, as should =
on-device keys. We=E2=80=99re probably going to want extensions for =
device posture and other forms of attestation as well.
>>>>=20
>>>> This is one of the domains that I think we can clearly surpass =
OAuth 2=E2=80=99s flexibility and capabilities if we are willing to look =
past OAuth 2=E2=80=99s assumptions of what=E2=80=99s needed inline in =
the protocol.=20
>>>>=20
>>>>  =E2=80=94 Justin
>>>>=20
>>>>> On Jul 14, 2020, at 1:54 PM, Mike Varley =
> wrote:
>>>>>=20
>>>>> Is client registration in scope for the protocol?
>>>>> =20
>>>>> A generic way of handling clients (via ID or Handle or Key or =
whatever) is to have processing rule on the AS such as =E2=80=9Cif the =
AS recognizes the client ID (and authentication of that client ID) then =
it may process the request on behalf of that client. If the AS does not =
recognize the client ID, it must treat this as a new client registration =
and evaluate any authorization evidence the client provides before =
enabling the client and mapping policies to that client=E2=80=9D (this =
means dynamic or automatic clients need to provide additional assertions =
/ software statements whatever to register their ID.
>>>>> =20
>>>>> Something like this allows for very flexible systems:
>>>>> System A can be unknown to the AS but can dynamically registered =
each time with an appropriate software statement
>>>>> System B can have a fairly stable client ID at the AS, but rotate =
that ID every month through automatic registration (with an assertion it =
got from the AS during a pre-registration for example)
>>>>> System C can pre-register with the AS for a client ID because it =
doesn=E2=80=99t deal with software statements etc=E2=80=A6
>>>>> =E2=80=A6
>>>>> And even =E2=80=98StatelessAS=E2=80=99 can operate by never =
storing client IDs because it will always just rely on the software =
statements.
>>>>> =20
>>>>> I think a client registration protocol that allows these scenarios =
would be very useful in GNAP, but hopefully avoiding having to define =
what =E2=80=98evidence=E2=80=99 the AS needs to accept for each =
scenario.
>>>>> =20
>>>>> Thanks,
>>>>> =20
>>>>> MV
>>>>> =20
>>>>> From: Txauth > on behalf of Mike Jones =
>
>>>>> Date: Tuesday, July 14, 2020 at 12:18 PM
>>>>> To: Dick Hardt >, "txauth@ietf.org =
" >, =
Justin Richer >
>>>>> Subject: Re: [Txauth] Key handle vs client id & handle
>>>>> =20
>>>>> I agree that there are significant differences between statically =
and dynamically registered clients and that=E2=80=99s appropriate to be =
able to syntactically differentiate between them at runtime.  For one =
thing, the resource requirements at the authorization server can be very =
different.
>>>>> =20
>>>>> We should also be thinking about how to include what the OpenID =
Connect Federation spec =
https://openid.net/specs/openid-connect-federation-1_0.html =
 calls =
=E2=80=9CAutomatic Registration=E2=80=9D.  This lets the client encode a =
registration request reference in the client ID, so no static or dynamic =
registration even occurs.  See =
https://openid.net/specs/openid-connect-federation-1_0-12.html#rfc.section=
.9.1 =
.
>>>>> =20
>>>>>                                                        -- Mike
>>>>> =20
>>>>> From: Dick Hardt >=20
>>>>> Sent: Friday, July 10, 2020 1:17 PM
>>>>> To: txauth@ietf.org ; Justin Richer =
>; Mike Jones =
>
>>>>> Subject: Key handle vs client id & handle
>>>>> =20
>>>>> + Mike as he had interest in this topic
>>>>> =20
>>>>> My understanding is that an existing OAuth 2 client would use =
their current client id as their key handle, and a dynamic client (one =
that was not pre-registered) would be given a key handle by the AS.
>>>>> =20
>>>>> There are potentially some significant differences between a =
registered client, and a dynamic client to an AS.
>>>>> =20
>>>>> The AS is likely to know the identity of a registered client, and =
have different policies between the two types of clients. For example, a =
registered client may have access to a 'write" scope, while a dynamic =
client does not.
>>>>> =20
>>>>> The AS may have 100s or 1000s of registered clients, but a dynamic =
client may have 10Ms or 100Ms of instances, which may dictate separate =
storage services. Additionally, internal to the AS, which systems can =
write to the registered client store is going to be different than the =
dynamic client store.
>>>>> =20
>>>>> In XYZ, subsequent calls to the AS, both registered clients and =
dynamic clients pass a key handle, so there is no easy way to =
differentiate between the two.
>>>>> =20
>>>>> While the AS could embed semantics in the key handle identifier to =
indicate which identifiers are pre-registered vs dynamic, there are many =
cases where the AS does need to know the difference, so making the =
difference a feature of GNAP seems like a better path.
>>>>> =20
>>>>> =20
>>>>> 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.
>>>>>=20
>>>>=20
>>>> --=20
>>>> Txauth mailing list
>>>> Txauth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/txauth =

>>>=20
>>=20
>=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=_472AFC6C-C496-4B80-82C2-BEBC31783399
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1. =
There are a lot of use cases where the client isn=E2=80=99t identified =
using an identifier known to the AS. OAuth/OIDC don=E2=80=99t fit very =
well in those use cases because the protocol :requires: a client_id. =
That=E2=80=99s why we get things like the OIDC Federation clever =
=E2=80=9Cinline registration=E2=80=9D and SIOP that both add semantics =
to a required field that they don=E2=80=99t need for its original =
purpose.

What I=E2=80=99=
m arguing is that we shouldn=E2=80=99t :require: a client_id, but we can =
:allow: its equivalent for an AS that supports it. If you have an =
identifier known to the AS and that identifier is presented along with =
some trusted material (like the proof of a key via signature, for =
instance), then that is a subset of what can be trusted and why. And =
what you=E2=80=99re identifying, ultimately, is the key being presented. =
All other cases of identifying the =E2=80=9Cclient=E2=80=9D separate =
from its key material are actually presenting other forms of trust and =
shouldn=E2=80=99t be conflated with an all-present client =
identifier. 

I =
agree that fundamentally a trust framework is the way to look at it: the =
AS needs to decide if it trusts the entity making the call to start a =
request, and what it trusts that entity to do. Identification of that =
entity by some known value is a subset of what is possible by trust =
frameworks.

 =E2=80=94 =
Justin

On Jul 26, 2020, at 10:15 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

one other tf could be "I am =
bound the terms of the GDPR".
If we go that way at =
all, I would also recommend a MUST or at least a SHOULD "jurisdiction" =
field.
GNAP may as well take the moral high ground, =
it is pretty much empty space right now.
Peace ..tom


On Sun, Jul 26, 2020 at 6:55 PM Francis =
Pouatcha <fpo@adorsys.de> wrote:
+1 =
Tom's input.

This discussion about Key Handle vs. client id & handle =
wouldn't exist if GNAP had the notion of TF defining how the =
GS/RS/Clients identify and authenticate each other.

A simple TF =
can describe the standard case (happy path) without having to =
foresee all eventualities.

A GNAP profile will also be simple as it will keep out =
everything else (e.g. US Healthcare, PSD2).

BR 
/Francis


On Sun, Jul 26, 2020 at 9:43 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
You should consider a trust framework to be first =
of all a set of qualifying criteria above and beyond the literal =
meaning of the standard.
Ours is focused on US =
Healthcare, but lots of others make sense. The international R&E org =
is the basis for the openid federation doc.
Secondarily the trust framework could vet members so that =
they made affirmative statements about their compliance.
Tertiary they tf could mandate testing of the members. That =
is the case for US Healthcare.
the tf could be =
blank for sites with no moral scruples whatsoever. (the majority of =
sites i am sure.)
Peace =
..tom


On Sun, Jul 26, 2020 at 6:18 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi =
Francis

While a =
Trust Framework concept looks to make sense for PSD2 use cases, there =
are lots of other use cases.

How would you see existing OAuth 2 and OIDC concepts fitting =
into a Trust Framework concept?

/Dick

3D""=E1=90=A7

On Sat, Jul =
25, 2020 at 8:41 PM Francis Pouatcha <fpo@adorsys.de> wrote:
I just =
read through some work being done by Tom at the FIRE (Federated =
Identifiers for Resilient Ecosystems) working group and it confirms =
my intention of suggesting the consideration of a "Trust Framework" as a =
context defining how to handle the client_id.

The procedure the GS applies to trust a =
client is derived from the "Trust Framework" that governs the =
environment in which GS and Client are operating.

In the European =
PSD2 ecosystem, National Country Authorities (a.k.a Market Authorities =
or Regulators):
- delegate the production of client =
certificates to Trust Service Providers (TSPs). TSPs are known =
certification authorities (CAs) in the corresponding =
countries.
- maintain a register of Certified Third =
Party Providers (TPPs) at the European Banking Association (EBA), where =
the validity of the TPP license can be verified, in =
addition to the client certificate.

Designing an authorization framework =
around the PSD2 ecosystem, there is no need to maintain any static =
or dynamic client_id. Each request is associated with an SSL client =
certificate called QWAC (Qualified Website Assertion =
Certificate). 
- This certificate can be =
verified as the GS maintains a list of all known TSP's CA authorized to =
release PSD2 client certificates.
- This =
certificate also contains the list of roles assigned to the TPP by the =
regulator PSP_AS (bank), PSP_PI (payment initiation), PSP_AI =
(account information), PSP_IC (card) sufficient for the client access =
control in the PSD2 trust framework.
- This =
certificate contains a permanent "Competent Authority" that =
uniquely identifies the NCA issuing the TPP license.
- This certificate contains a permanent "Authorization =
Number" that is unique in the context of the NCA.
- =
so AuthorizationNumber@CompetentAuthority is globally unique =
in the context of the PSD2 trust framework.

Given these facts, GS implementing PSD2 =
do not need to register clients. 
- Each =
request of the client to the GS can be mTLS secured using the =
QWAC.
- GS can extract all information needed to =
perform authorization from that certificate.
This use case does not need an extra =
client_id at the protocol level. 

This is:
- based =
on the experience we are making implementing PSD2,
- =
based on my reading Tom's FIRE use case in the health sector on the =
sharing of Patient Health Information (PHI) among health care =
providers,

I =
suggest GNAP introduces the notion of "Trust framework" that governs the =
environment in which RS, GS and Client interoperate. We can then =
delegate the decision on specifying the necessity and functions of a =
client_id to the trust framework.


On Thu, Jul 16, 2020 at 7:58 PM Tom =
Jones <thomasclinganjones@gmail.com> =
wrote:
I have =
been working on different level s of identifier, but from the mobile app =
perspective. That's the hardest case as you need to boot strap trust. I =
suspect that in the web site case you will need these levels. Transport, =
application, real world.

If anyone wants to work on =
these, let me know and I'll get you the links in Kantara.

thx ..Tom =
(mobile)

On Thu, Jul 16, 2020, 2:47 PM Justin =
Richer <jricher@mit.edu> wrote:
For all of these, I still say we =
should have different levels of identifier. A =E2=80=9Cclient ID=E2=80=9D =
should identify the client, and not be used as a stand-in for other =
things. 

Off =
the top of my head I think we might want to have identifiers, =
assertions, proofs, and other trust-binding items for:

 - =
Organizations
 - Devices
 - Software applications
 - =
Software instances
 - Software =
versions

So if =
we=E2=80=99re going to talk about identifying these aspects, we should =
tackle each as its own thing and not mush it all into =E2=80=9Cclient_id=E2=
=80=9D. That way, hopefully, GNAP can have a much better idea what a =
=E2=80=9Cclient=E2=80=9D is than OAuth 2 currently does.

 =E2=80=94 =
Justin

On Jul 16, 2020, at 4:34 PM, =
Dick Hardt <dick.hardt@gmail.com> =
wrote:

One=
 client identifier was a simplistic example. Org A may have numerous =
clients, perhaps in different teams, perhaps in different services, each =
with their own policy at Org B.

When one of the Org A clients makes a =
call to the Org B AS, it needs to identify itself with some identifier =
so that Org B knows which policy to enforce. Why not the Client =
ID?

I also =
agree with your comments that other client identification situations are =
different, and forcing the same identification model on them does not =
make sense, but I fail to see the value throwing out a concept =
(client_id) that has worked well for the use cases it was designed =
for. 


3D""=E1=90=A7

On Thu, Jul =
16, 2020 at 1:08 PM Justin Richer <jricher@mit.edu> =
wrote:
I think that the =
cross-organizational trust model is an interesting one, and in fact =
it=E2=80=99s one of the things that=E2=80=99s pushed me away from a =
client_id. In the scenario that you describe, =E2=80=9Cclient_id=E2=80=9D =
is used to represent something that it was never meant to represent: the =
organization running the software, not the software itself. It isn=E2=80=99=
t a client_id, and while in OAuth 2 the client_id could be co-opted to =
carry that information, it=E2=80=99s considered bad practice to share =
client_ids between multiple pieces of software. 

I would argue that to address this use =
case properly, there should be another level of identifier to bridge =
that trust that the software can present, showing that it is a part of =
Organization A, and not Organization C. This isn=E2=80=99t a client =
identifier, it=E2=80=99s an organization identifier, and it should be =
separate. You might want to identify both the client instance as well as =
the organization it=E2=80=99s a part of, for example. This is part of =
the motivation behind putting =E2=80=9Corganizational data=E2=80=9D =
within scope for the client to send to the AS, after all.

Therefore, I strongly =
disagree that this scenario =E2=80=9Crequires=E2=80=9D a client_id to be =
solved. In fact, I think that solving this scenario with a client_id is =
an anti-pattern that stems from OAuth 2=E2=80=99s over-reliance on =
client_id as a persistent identifier within the protocol, and we can and =
should do better with GNAP. It=E2=80=99s very similar to Mike Jones=E2=80=99=
s referenced federation document, where the client_id is co-opted as a =
means of bootstrapping client registration and discovery, or in the =
Solid Authentication specification which stuffs a WebID into the =
client_id field.

With OAuth 2=E2=80=99s ecosystem, we=E2=80=99ve used the =
tools that we had to solve our problems, and come up with some very =
clever solutions. What I=E2=80=99m trying to argue to this community is =
that we are in a position to create our own, better =
tools. 

 =E2=80=94 Justin

On Jul =
16, 2020, at 2:00 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, 

While I agree that the assumption in =
OAuth 2 that all Clients have a client_id is problematic, the =
requirement for a client_id in many use cases is still there, and it =
does not represent a piece of software, but a relationship between =
parties.

Organization A writes client software that calls resources =
managed by the AS in Organization B. The client_id represents =
Organization A to Organization B. Organization B does not care what =
software Organization A is running, and there may be =
numerous pieces of software at Organization A that use the same =
client_id. The access granted by Organization B to Organization A needs =
to be able to be different than the rights granted to Organization =
C. 

I=
 agree that we don't want to force all clients to have a client_id, and =
as discussed, there are a variety of inputs for an AS to accept calls =
from a piece of software, and often, that will be a particular instance of the software, but we also don't want to force =
clients to all be treated the same, because they are =
not.. 






On Thu, Jul 16, 2020 at 8:24 AM Justin Richer =
<jricher@mit.edu> wrote:
Exactly =E2=80=94 =
when we start to look at it as managing the lifecycle of a piece of =
software, instead of a registration at the AS, we can start thinking in =
different terms what =E2=80=9Ctrusting=E2=80=9D the client means in the =
context of what the client is doing. That trust could come from some =
kind of signed attestation about the software (like the OAuth 2 DynReg =
software statement), or it could come from some externally fetchable =
item (like a Solid WebID, a DID, or the OIDC Federation extension), or =
it could come from someone sitting at a console and typing in =
information and getting back an identifier. And none of these need to =
pretend to be a global =E2=80=9Cclient id=E2=80=9D for it to work. The =
world of clients is much more diverse than OAuth 2 likes to admit, and =
we see that with trying to nail down a =E2=80=9Cconfidential=E2=80=9D =
vs. =E2=80=9Cpublic=E2=80=9D vs. =E2=80=9Cdynamic=E2=80=9D vs. =
=E2=80=9Cstatic=E2=80=9D vs. =E2=80=9Cautomatic=E2=80=9D vs. =
=E2=80=9Cephemeral=E2=80=9D vs. =E2=80=A6 any number of other =
things. 

OAuth 2 only needs client IDs because the front channel needs =
a way to pass client identifiers when the client can=E2=80=99t =
authenticate itself directly. We tried to get rid of this restriction =
with PAR and JAR together, but there turned out to be corner cases in =
OAuth 2=E2=80=99s world that still needed client_id, and implementations =
assumed it would be there anyway. 

In GNAP, we can avoid that problem from =
the beginning by looking at the model differently and understanding =
where we=E2=80=99re coming from, and why.

 =E2=80=94 Justin

On Jul 16, 2020, at 3:49 AM, Fabien Imbault <fabien.imbault@gmail.com> =
wrote:

+1 =
on that.

We can then =
see it more as life cycle management of the client than registration per =
say, and this comes with many benefits compared to the current =
client_id.

Fabien

On Tue, Jul =
14, 2020 at 9:32 PM Justin Richer <jricher@mit.edu> =
wrote:
I not only agree with =
Mike Jones that =E2=80=9Cautomatic registration=E2=80=9D should be part =
of the process, but I would argue that that kind of model should be a =
default mode of operation. If you have an identifier that you can send =
to short-circuit that, great! But we should focus on having the =
capability of inlining a lot of this information wherever possible. This =
is already the direction that the input proposals are heading.

So I kind-of agree that =
=E2=80=9Cregistration=E2=80=9D is in scope for the protocol in general, =
and since both XYZ and Xauth have mechanisms that allow the client to =
present a key and get back an identifier that it can use in the future =
we have something equivalent. 

But I think there=E2=80=99s a little =
more to it than that: Ultimately, I think we should question thinking in =
terms of =E2=80=9Cregistration=E2=80=9D, a model which has hampered the =
OAuth 2 model in a lot of use cases. For example, the federation draft =
Mike Jones references below hacks the =E2=80=9Cclient_id=E2=80=9D =
parameter and makes it point to a document that the AS has to fetch. =
This construct is done for two reasons: (1) Oauth requires a =
=E2=80=9Cclient_id=E2=80=9D in the request and (2) it=E2=80=99s =
difficult to pass information by value to the AS due to front-channel =
restrictions. Since we=E2=80=99re defining a new protocol, we don=E2=80=99=
t need to hack that functionality into a =E2=80=9Cclient ID=E2=80=9D or =
equivalent and instead we can pass that information directly in the =
protocol. If we don=E2=80=99t assume that the client *has* to have a =
client ID equivalent, but it *can* have one in a set of defined =
circumstances, then I think we are in a much better spot. This is the =
reasoning for XYZ=E2=80=99s model of having clients identified by the =
key, and that key can potentially be passed by a reference =
identifier.

I =
think all of the use cases that Mike Varley presents below are all valid =
directions, with the caveat that we shouldn=E2=80=99t assume a client =
should be presenting an ID at all steps. Mechanisms like software =
statements should be presentable apart from a client ID, as should =
on-device keys. We=E2=80=99re probably going to want extensions for =
device posture and other forms of attestation as well.

This is one of the =
domains that I think we can clearly surpass OAuth 2=E2=80=99s =
flexibility and capabilities if we are willing to look past OAuth 2=E2=80=99=
s assumptions of what=E2=80=99s needed inline in the =
protocol. 

 =E2=80=94 Justin
On Jul =
14, 2020, at 1:54 PM, Mike Varley <mike.varley@securekey.com> =
wrote:

Is =
client registration in scope for the protocol?
 
A =
generic way of handling clients (via ID or Handle or Key or whatever) is =
to have processing rule on the AS such as =E2=80=9Cif the AS recognizes =
the client ID (and authentication of that client ID) then it may process =
the request on behalf of that client. If the AS does not recognize the =
client ID, it must treat this as a new client registration and evaluate =
any authorization evidence the client provides before enabling the =
client and mapping policies to that client=E2=80=9D (this means dynamic =
or automatic clients need to provide additional assertions / software =
statements whatever to register their ID.
 
Something like this allows for very flexible systems:
System =
A can be unknown to the AS but can dynamically registered each time with =
an appropriate software statement
System =
B can have a fairly stable client ID at the AS, but rotate that ID every =
month through automatic registration (with an assertion it got from the =
AS during a pre-registration for example)
System =
C can pre-register with the AS for a client ID because it doesn=E2=80=99t =
deal with software statements etc=E2=80=A6
=E2=80=A6=

And =
even =E2=80=98StatelessAS=E2=80=99 can operate by never storing client =
IDs because it will always just rely on the software statements.
 
I =
think a client registration protocol that allows these scenarios would =
be very useful in GNAP, but hopefully avoiding having to define what =
=E2=80=98evidence=E2=80=99 the AS needs to accept for each scenario.
 
Thanks,
 
MV
 
From: Txauth <txauth-bounces@ietf.org> on behalf =
of Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org>
Date: Tuesday, =
July 14, 2020 at 12:18 PM
To: Dick Hardt <dick.hardt@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer =
<jricher@mit.edu>
Subject: Re: [Txauth] Key =
handle vs client id & handle
 
I agree that there are =
significant differences between statically and dynamically registered =
clients and that=E2=80=99s appropriate to be able to syntactically =
differentiate between them at runtime.  For one thing, the resource =
requirements at the authorization server can be very different.
 
We should also =
be thinking about how to include what the OpenID Connect Federation =
spec https://openid.net/specs/openid-connect-federation-1_0.html=
 calls =E2=80=9CAutomatic =
Registration=E2=80=9D.  This lets the client encode a registration =
request reference in the client ID, so no static or dynamic registration =
even occurs.  See https://openid.net/specs/openid-connect-federation-1_0-12.html#=
rfc.section.9.1.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 
From: Dick Hardt <dick.hardt@gmail.com> 
Sent: Friday, July 10, 2020 1:17 PM
To: txauth@ietf.org; Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Subject: Key =
handle vs client id & handle
 
+ Mike as =
he had interest in this topic
 
My =
understanding is that an existing OAuth 2 client would use their current =
client id as their key handle, and a dynamic client (one that was not =
pre-registered) would be given a key handle by the AS.
 
There are =
potentially some significant differences between a registered client, =
and a dynamic client to an AS.
 
The AS is =
likely to know the identity of a registered client, and have different =
policies between the two types of clients. For example, a registered =
client may have access to a 'write" scope, while a dynamic client does =
not.
 
The AS =
may have 100s or 1000s of registered clients, but a dynamic client may =
have 10Ms or 100Ms of instances, which may dictate separate storage =
services. Additionally, internal to the AS, which systems can write to =
the registered client store is going to be different than the =
dynamic client store.
 
In XYZ, =
subsequent calls to the AS, both registered clients and dynamic clients =
pass a key handle, so there is no easy way to differentiate between the =
two.
 
While the =
AS could embed semantics in the key handle identifier to indicate which =
identifiers are pre-registered vs dynamic, there are many cases where =
the AS does need to know the difference, so making the difference a =
feature of GNAP seems like a better path.
 
 
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.

-- 

Txauth mailing 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=_472AFC6C-C496-4B80-82C2-BEBC31783399--


From nobody Mon Jul 27 04:23: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 1FBC13A18FB for ; Mon, 27 Jul 2020 04:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kfToDRmCq3OH for ; Mon, 27 Jul 2020 04:23:13 -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 621BD3A18F5 for ; Mon, 27 Jul 2020 04:23:13 -0700 (PDT)
Received: from [192.168.1.3] (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 06RBN7Rt018259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 07:23:08 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_42D4BF57-5657-40B6-ADA1-8C47AF4B5879"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 27 Jul 2020 07:23:07 -0400
In-Reply-To: 
Cc: Francis Pouatcha , txauth@ietf.org, Tom Jones , Denis 
To: Dick Hardt 
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu> 
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 11:23:21 -0000

--Apple-Mail=_42D4BF57-5657-40B6-ADA1-8C47AF4B5879
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Since you focused on the individual elements of the straw man examples =
you requested instead of the overall problem, I think you=E2=80=99re =
missing the core point. Let me bring it back to a concrete example:

In Xauth currently, you can use the =E2=80=9Cclaims=E2=80=9D query =
syntax from OIDC to request user claims inside the =E2=80=9Cclaims.oidc=E2=
=80=9D object on request. However, Xauth currently uses =E2=80=9Cuserinfo=E2=
=80=9D to mark information coming back directly to the client as JSON. =
Since =E2=80=9Cuserinfo=E2=80=9D is already defined by OIDC in this =
context to indicate information that should come back from the UserInfo =
Endpoint (and therefore as a resource, with rights tied to an access =
token), the Xauth approach would need a name other than =E2=80=9Cuserinfo=E2=
=80=9D here to indicate such claims coming back directly as JSON.=20

What would you call that field?

Because whatever that field would be called is exactly the kind of data =
differentiation that I=E2=80=99m talking about here. And considering =
that Xauth already does differentiate between claims coming back as =
resources, as assertions, and direct JSON, I think it=E2=80=99s clear =
that it does matter.

 =E2=80=94 Justin


> On Jul 24, 2020, at 4:57 PM, Dick Hardt  wrote:
>=20
> It is not clear to me what it matters if a Claim comes from an RS, or =
from the GS, so I don't see a need to differentiate them.
>=20
> I would include verifiable credentials and user-bound keys as Claims.
>=20
> All the payment processing information I have seen has been in RAR. =
When would the Client get payment processing directly from the GS?
>=20
> What is your example for distributed networks storage locations? If =
what is stored is a statement about the user, then I would consider that =
a Claim as well.
>=20
> We disagree on how to map OIDC to GNAP.  The direct data is a claims =
request, the data coming indirectly is an access token request.
>=20
>=20
>=20
> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer > wrote:
> Since we=E2=80=99re already talking about returning claims as direct =
data as well as a part of the resource API being protected, so we =
already need a way to differentiate the two kinds of items. Just calling =
it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, because as you=E2=80=99v=
e pointed out they could show up in both places. So yes, defining that =
difference is something we should worry about now, even if the core =
protocol only uses it for claims.
>=20
> The two forms of direct data that XYZ returns are subject identifiers =
(a subset of identity claims) and assertions =E2=80=94 the latter being =
a container not just for identity claims but also authentication =
information and other elements. Assertions are not claims themselves.=20
>=20
> Other use cases that have been brought up include verifiable =
credentials and proofs, user-bound keys, payment processing information, =
and distributed network storage locations. I=E2=80=99m sure there are a =
lot more. To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D =
but not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be =
defining what all of these look like, but it should define a way to talk =
about them.
>=20
> I think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=
=9D request, which allows targeting of its claims information into =
different return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D=
 request at the very least. I don=E2=80=99t think GNAP should define how =
to do this specific combination, that should be for OIDF to debate and =
apply. The same with a DID service based query, or Presentation Exchange =
[1], or anything else that people want to come up with.
>=20
> In my view, GNAP should define query structures for two things: rights =
that get tied to an access token and data that comes back directly to =
the client. For the latter, I think we can do some very limited and very =
useful specific items, which is what I=E2=80=99ve put into XYZ.
>=20
>  =E2=80=94 Justin
>=20
> [1] https://identity.foundation/presentation-exchange/ =

>=20
>> On Jul 24, 2020, at 3:58 PM, Dick Hardt > wrote:
>>=20
>> I agree we want GNAP to be a strong foundation.=20
>>=20
>> Do you have an example of other "direct data"? If so, do you expect =
it to be defined in the core protocol?
>>=20
>> I would expect an extension for other "direct data" to define top =
level objects, and an appropriate definition for that "direct data".
>>=20
>> My "do we need to worry about it now" comment was on creating a =
generic term for "direct data". Unless we are solving those now, we can =
let further work define that "direct data" explicitly.
>>=20
>>=20
>>=20
>>=20
>> =E1=90=A7
>>=20
>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer > wrote:
>> Yes, I do think we need to worry about it to the extent that we are =
not creating something that is over-fit to a limited set of use cases.=20=

>>=20
>> GNAP should be a foundation that many amazing new things can be built =
on top of.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt > wrote:
>>>=20
>>> Justin, thanks for clarifying.
>>>=20
>>> What are some examples of other "direct data" that the GS may =
return? If it is not in core GNAP, do we need to worry about now? We can =
then give the direct data from the GS that is not a claim, an =
appropriate name in that document.
>>>=20
>>>=20
>>>=20
>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer > wrote:
>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m =
saying. I agree that =E2=80=9Cclaims=E2=80=9D are about the user, in =
this context*. But the AS could return other data directly to the client =
that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=
=80=9D by the classical definition. Also since =E2=80=9Cclaims=E2=80=9D =
can come back from places other than directly, then we shouldn=E2=80=99t =
call everything that comes back a =E2=80=9Cclaim=E2=80=9D.
>>>=20
>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean =
what it already means and come up with a new word to mean =E2=80=9Cthings =
that come back directly from the AS=E2=80=9D. These aren=E2=80=99t meant =
to replace Francis=E2=80=99s more complete definitions, but to simplify:
>>>=20
>>> Claims:
>>> 	- information about the user
>>> 	- can come back directly from the AS
>>> 	- can come back in a resource from the RS
>>>=20
>>> Resource:
>>> 	- Returned from an RS
>>> 	- Protected by access token
>>> 	- Could contain claims about the user
>>>=20
>>> Direct data (or some better name):
>>> 	- Returned directly from AS
>>> 	- Could contain claims about the user
>>>=20
>>> I think the problem is that some people are using =E2=80=9Cclaims=E2=80=
=9D to mean #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. =
But: It=E2=80=99s important to remember, when talking about OIDC, that =
an IdP in OIDC combines an AS and an RS into one entity for identity =
information. There can be other RS=E2=80=99s as well, and there usually =
are in the wild, but the one defined by OIDC is the UserInfo Endpoint. =
The fact that it returns user data doesn=E2=80=99t make it any less of =
an RS.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>> * In the wider context of things like the information claims inside =
a JWT, the claims could be about literally anything, but that=E2=80=99s =
not what we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99=
s being used.
>>>=20
>>>=20
>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt > wrote:
>>>>=20
>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly =
from the OP in an ID Token, or the Client can obtain Claims using an =
access token to call the UserInfo endpoint, a Protected Resource[1].
>>>>=20
>>>> The Claims are about the User (not a RO).
>>>>=20
>>>> In XAuth, I'm proposing the Client may obtain bare claims from the =
GS directly in addition to the mechanisms in ODIC.
>>>>=20
>>>> So I don't think we are changing the definition of Claim from how =
it has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>=20
>>>> Justin: you allude to Claims being about a party other than the =
User. Would you provide an example?
>>>>=20
>>>> /Dick
>>>>=20
>>>> [1]
>>>> UserInfo Endpoint
>>>> Protected Resource that, when presented with an Access Token by the =
Client, returns authorized information about the End-User represented by =
the corresponding Authorization Grant. The UserInfo Endpoint URL MUST =
use the https scheme and MAY contain port, path, and query parameter =
components.
>>>>=20
>>>>=20
>>>>=20
>>>> =E1=90=A7
>>>>=20
>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer > wrote:
>>>> I want to focus on one aspect here:
>>>>=20
>>>>>=20
>>>>> A Claim is a well understood term in the field. We should use it. =
It is still a Claim if it comes directly from the GS or from an RS.=20
>>>>> I do not understand why a Resource release by an RS shall be h to =
as a claim, even if the content of the Resource is an assertion. It will =
lead to confusion. If we limit claims to information GS releases into =
Token, User Info, and other objects it returns, this will help separate =
responsibilities between GS and RS. As soon as RS services and =
information, this is called a Resource, no matter the nature of the =
content of that information.
>>>>=20
>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclai=
m=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=
=80=9D could come back through an RS =E2=80=94 but in the context of =
GNAP, that makes it a resource. So we need a different word for data =
coming back directly from the AS to the client. Sometimes it=E2=80=99s =
going to be about the user, and that=E2=80=99s what we=E2=80=99re going =
to focus on here, but since you can also get information about the user =
from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. =
I think this has been at the heart of a lot of confusion in recent =
threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.
>>>>=20
>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already =
does, and let=E2=80=99s find a way to differentiate between when an =
item, claim or otherwise,  comes as part of a resource and when it comes =
back directly. This is an important differentiating feature for GNAP.
>>>>=20
>>>> Some straw man ideas, none of which I=E2=80=99m particularly in =
love with:
>>>>=20
>>>>  - direct data
>>>>  - properties
>>>>  - details
>>>>  - statements
>>>>=20
>>>> The important thing here is that it=E2=80=99s not necessarily =
:about: the RO, and that it is :not: in a resource.
>>>>=20
>>>> Any other thoughts?
>>>>=20
>>>>  =E2=80=94 Justin
>>>=20
>>=20
>=20


--Apple-Mail=_42D4BF57-5657-40B6-ADA1-8C47AF4B5879
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Since=
 you focused on the individual elements of the straw man examples you =
requested instead of the overall problem, I think you=E2=80=99re missing =
the core point. Let me bring it back to a concrete example:

In Xauth currently, you =
can use the =E2=80=9Cclaims=E2=80=9D query syntax from OIDC to request =
user claims inside the =E2=80=9Cclaims.oidc=E2=80=9D object on request. =
However, Xauth currently uses =E2=80=9Cuserinfo=E2=80=9D to mark =
information coming back directly to the client as JSON. Since =
=E2=80=9Cuserinfo=E2=80=9D is already defined by OIDC in this context to =
indicate information that should come back from the UserInfo Endpoint =
(and therefore as a resource, with rights tied to an access token), the =
Xauth approach would need a name other than =E2=80=9Cuserinfo=E2=80=9D =
here to indicate such claims coming back directly as =
JSON. 

What=
 would you call that field?

Because whatever that field would be called is exactly the =
kind of data differentiation that I=E2=80=99m talking about here. And =
considering that Xauth already does differentiate between claims coming =
back as resources, as assertions, and direct JSON, I think it=E2=80=99s =
clear that it does matter.

 =E2=80=94 Justin


On Jul 24, 2020, at 4:57 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It is not clear =
to me what it matters if a Claim comes from an RS, or from the GS, so I =
don't see a need to differentiate them.

I would include verifiable credentials =
and user-bound keys as Claims.

All the payment processing information =
I have seen has been in RAR. When would the Client get payment =
processing directly from the GS?

What is your example for distributed =
networks storage locations? If what is stored is a statement about the =
user, then I would consider that a Claim as well.
We disagree on how to map OIDC to =
GNAP.  The direct data is a claims request, the data coming =
indirectly is an access token request.



On Fri, Jul 24, 2020 at 1:39 PM Justin Richer =
<jricher@mit.edu> =
wrote:
Since we=E2=80=99re already talking about =
returning claims as direct data as well as a part of the resource API =
being protected, so we already need a way to differentiate the two kinds =
of items. Just calling it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, =
because as you=E2=80=99ve pointed out they could show up in both places. =
So yes, defining that difference is something we should worry about now, =
even if the core protocol only uses it for claims.

The two forms of direct data that XYZ =
returns are subject identifiers (a subset of identity claims) and =
assertions =E2=80=94 the latter being a container not just for identity =
claims but also authentication information and other elements. =
Assertions are not claims themselves. 

Other use cases that have been brought =
up include verifiable credentials and proofs, user-bound keys, payment =
processing information, and distributed network storage locations. I=E2=80=
=99m sure there are a lot more. To me, these are subsets of the =
=E2=80=9Cdirect data=E2=80=9D but not subsets of =E2=80=9Cclaims=E2=80=9D.=
 GNAP shouldn=E2=80=99t be defining what all of these look like, but it =
should define a way to talk about them.

I think different top-level request =
objects are better suited for different query semantics. Like, for =
example, the OIDC =E2=80=9Cclaims=E2=80=9D request, which allows =
targeting of its claims information into different return buckets. This =
overlaps with the =E2=80=9Cresources=E2=80=9D request at the very least. =
I don=E2=80=99t think GNAP should define how to do this specific =
combination, that should be for OIDF to debate and apply. The same with =
a DID service based query, or Presentation Exchange [1], or anything =
else that people want to come up with.

In my view, GNAP should define query =
structures for two things: rights that get tied to an access token and =
data that comes back directly to the client. For the latter, I think we =
can do some very limited and very useful specific items, which is what =
I=E2=80=99ve put into XYZ.

 =E2=80=94 =
Justin

[1] https://identity.foundation/presentation-exchange/

On Jul 24, 2020, at 3:58 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

I agree we want GNAP to be a =
strong foundation. 

Do you have an example of other "direct data"? If so, do you =
expect it to be defined in the core protocol?

I would expect an extension for other =
"direct data" to define top level objects, and an appropriate definition =
for that "direct data".

My "do we need to worry about it now" comment was on creating =
a generic term for "direct data". Unless we are solving those now, we =
can let further work define that "direct data" explicitly.




3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
Yes, I do think we =
need to worry about it to the extent that we are not creating something =
that is over-fit to a limited set of use cases. 

GNAP should be a foundation that many =
amazing new things can be built on top of.

 =E2=80=94 =
Justin

On Jul 24, 2020, at 3:06 PM, =
Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, thanks for =
clarifying.

What are =
some examples of other "direct data" that the GS may return? If it is =
not in core GNAP, do we need to worry about now? We can then give the =
direct data from the GS that is not a claim, an appropriate name in that =
document.



On Fri, Jul 24, 2020 at 11:46 AM Justin =
Richer <jricher@mit.edu> wrote:
Dick: No, I =
think you=E2=80=99re misunderstanding what I=E2=80=99m saying. I agree =
that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But =
the AS could return other data directly to the client that isn=E2=80=99t =
about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=80=9D by the =
classical definition. Also since =E2=80=9Cclaims=E2=80=9D can come back =
from places other than directly, then we shouldn=E2=80=99t call =
everything that comes back a =E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m arguing that we keep =
=E2=80=9Cclaims=E2=80=9D to mean what it already means and come up with =
a new word to mean =E2=80=9Cthings that come back directly from the =
AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s =
more complete definitions, but to simplify:

Claims:
	- information =
about the user
	- can come back directly from the AS
	- =
can come back in a resource from the RS

Resource:
	- Returned from =
an RS
	- Protected by access token
	- =
Could contain claims about the user

Direct data (or some better =
name):
	- Returned directly from AS
	- =
Could contain claims about the user

I think the problem is that some people =
are using =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. =
It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s important to =
remember, when talking about OIDC, that an IdP in OIDC combines an AS =
and an RS into one entity for identity information. There can be other =
RS=E2=80=99s as well, and there usually are in the wild, but the one =
defined by OIDC is the UserInfo Endpoint. The fact that it returns user =
data doesn=E2=80=99t make it any less of an RS.

 =E2=80=94 Justin

* In the wider context =
of things like the information claims inside a JWT, the claims could be =
about literally anything, but that=E2=80=99s not what we=E2=80=99re =
discussing here and it=E2=80=99s not how it=E2=80=99s being =
used.


On Jul =
24, 2020, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

In OpenID Connect (OIDC), the =
Client can obtain Claims directly from the OP in an ID Token, or the =
Client can obtain Claims using an access token to call the UserInfo =
endpoint, a Protected Resource[1].

The Claims are about the User (not a =
RO).

In XAuth, =
I'm proposing the Client may obtain bare claims from the GS directly in =
addition to the mechanisms in ODIC.

So I don't think we are changing the =
definition of Claim from how it has been used in OIDC, and I fail to see =
any reason to NOT use Claim.

Justin: you allude to Claims being =
about a party other than the User. Would you provide an =
example?

/Dick

[1]
UserInfo =
Endpoint
Protected Resource that, when presented =
with an Access Token by the Client, returns authorized information about =
the End-User represented by the corresponding Authorization Grant. The =
UserInfo Endpoint URL MUST use the https scheme and MAY contain port, =
path, and query parameter components.



3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on =
one aspect here:


A Claim is a well =
understood term in the field. We should use it. It is still a Claim if =
it comes directly from the GS or from an =
RS. 
I do not understand =
why a Resource release by an RS shall be h to as a claim, even if the =
content of the Resource is an assertion. It will lead to confusion. If =
we limit claims to information GS releases into Token, User Info, and =
other objects it returns, this will help separate responsibilities =
between GS and RS. As soon as RS services and information, this is =
called a Resource, no matter the nature of the content of that =
information.

This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =
=E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in =
the context of GNAP, that makes it a resource. So we need a different =
word for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s going to be about the user, and that=E2=80=99s what we=E2=80=99=
re going to focus on here, but since you can also get information about =
the user from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=
=80=9D. I think this has been at the heart of a lot of confusion in =
recent threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=
=9D mean what it already does, and let=E2=80=99s find a way to =
differentiate between when an item, claim or otherwise,  comes =
as part of a resource and when it comes back directly. This is an =
important differentiating feature for GNAP.

Some straw man ideas, none of which =
I=E2=80=99m particularly in love with:

 - direct data
 - properties
 - =
details
 - statements

The important thing here is that it=E2=80=
=99s not necessarily :about: the RO, and that it is :not: in a =
resource.

Any other =
thoughts?

 =E2=80=94 Justin











=

--Apple-Mail=_42D4BF57-5657-40B6-ADA1-8C47AF4B5879--


From nobody Mon Jul 27 05:15: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 E1F6F3A184A for ; Mon, 27 Jul 2020 05:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 CBE6RX7mrEU9 for ; Mon, 27 Jul 2020 05:15: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 AACC13A1906 for ; Mon, 27 Jul 2020 05:14:59 -0700 (PDT)
Received: from [192.168.1.3] (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 06RCEq48032514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 08:14:53 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_7B72B520-CF98-4434-BB23-1657A65EE6D5"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 27 Jul 2020 08:14:52 -0400
In-Reply-To: 
Cc: Dick Hardt , txauth@ietf.org, Tom Jones , Denis , Fabien Imbault 
To: Francis Pouatcha 
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>      
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 12:15:07 -0000

--Apple-Mail=_7B72B520-CF98-4434-BB23-1657A65EE6D5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree with the separation between =E2=80=9Croles=E2=80=9D and =
=E2=80=9Centities=E2=80=9D. It=E2=80=99s exactly that kind of separation =
into roles that helped OAuth 2 succeed with the AS and RS roles possibly =
being the same entity, or not, depending on use case.

This is one of the reasons that I think =E2=80=9Cuser=E2=80=9D is an =
overloaded term. The user is an entity, not a role, and in spite of it =
being =E2=80=9Cunderstood=E2=80=9D in the OAuth 2 world, it means a wide =
variety of other things outside that world. The same with =E2=80=9Cclient=E2=
=80=9D, I can=E2=80=99t tell you how many times I=E2=80=99ve had to =
explain what exactly an OAuth =E2=80=9Cclient=E2=80=9D is when I=E2=80=99m=
 teaching a class.

As for specific recommendations: I=E2=80=99m in favor of the role =
=E2=80=9CRequester=E2=80=9D or =E2=80=9CRequesting Party=E2=80=9D. =
=E2=80=9CClient=E2=80=9D is arguably more confusing and harder to =
replace: I had tried to use =E2=80=9CResource Client=E2=80=9D to make =
=E2=80=9Cclient=E2=80=9D more specific in XYZ but that turned out to be =
more confusing than helpful.

 =E2=80=94 Justin

> On Jul 27, 2020, at 6:12 AM, Francis Pouatcha  wrote:
>=20
>=20
>=20
> On Sun, Jul 26, 2020 at 11:58 PM Dick Hardt > wrote:
>=20
>=20
> On Sun, Jul 26, 2020 at 6:45 PM Francis Pouatcha > wrote:
> Hello Dick,
>=20
> On Sun, Jul 26, 2020 at 9:14 PM Dick Hardt > wrote:
> Hi Francis
>=20
> User is a well understood term in OIDC and OAuth -- and User means the =
same in both.=20
>=20
> Resource Owner is who owns the resource, and the term is introduced =
for when the User is NOT the Resource Owner.=20
> This distinction is what makes it confusing as we are comparing an =
Entity (the User) to a Role (the RO). We need two roles.
>=20
> Or we could think of them all as entities. The RO is the entity that =
owns the resource. The User is the human that is using the Client.=20
> When we think of them as entities, we run into conflicts when =
Entity-User eq. Entity-RO.
> When we think of them as roles, Role-User is always !=3D Role-RO=20
> =20
> =20
>=20
> I also think that Client and Resource Server are well understood =
terms.
> Looks like contributors on the list still need clarification on the =
"orchestration" role of a client.
>=20
> When I think of orchestration, I think of coordinating, which is not =
what I think the Client is doing. The Client wants to consume the Claims =
and the Resources (combined are a Grant). The Client requests the Grant =
from the Grant Server. Where is the orchestration?
> Look at the client. It is the center of interaction between User, GS =
and RS.
> =20
>=20
> It is not clear to me why we would want to reinvent these terms. =
Reading over your flows, I think it would be useful to understand the =
requirements you have for your use case, otherwise I fear we will be =
talking past each other.
> The oAuth flow is there as a memo. The other flow is what I proposed =
before. Is there to emphasize we need to work on roles and not on =
entities. It is not a suggestion to rename well known idioms. It is an =
attempt to give them a proper definition in the context of this =
protocol. Definition based on their roles in the protocol flows.
>=20
> I'd like to take a step back and understand the requirements. We are =
deep into solutions.
> No, we are at the fundamental level. We Have to decide on whether to =
build a model based on roles oron entities... Then we use the result =
[ENTITY XOR ROLES] to define the use cases.
> /Francis
> =20
>=20
> Best regards.
> /Francis
>=20
> /Dick
>=20
> =E1=90=A7
>=20
> On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha > wrote:
> Below my opinion on the term Claim:
>=20
> Starting with illustration of parties/roles:
>=20
> User:=20
> This word is misleading because of its double role in oAuth2 and OIDC =
(see below). In GNAP let us have the User play only the role of a =
requestor. (from Justin reference to "Requesting Party").
>=20
> Client:
> This is also tightly bound to the oAuth2 and OIDC. The real purpose of =
this role is to orchestrate resource access on behalf of the =
"Requestor". Let us call this for now the "Orchestrator"
>=20
> Resource Owner (RO):
> This is IMO the most correct word in the entire protocol. =
Authorisation is always about the owner of something granting access to =
a requestor. It really does not matter if a human interaction is =
involved. We will have to forget oAuth2 and OIDC of also calling this a =
User.
>=20
> Grant Server:=20
> Even though the definition of the UserInfo endpoint in OIDC as a =
protected resource hazardously makes an OP an RS, we shall not repeat =
the same mistake here. We need a clear separation between roles of GS =
and RS without overlapping.
>=20
> Resource Server: services resources.
>=20
> Unless I got it wrong, GNAP is about grant negotiation and =
authorization. This means:
>=20
> GNAP is about some party requesting access to some resources.
> GNAP is about the resource owner consenting access to that resource.
> GNAP is about defining the infrastructure that allows the requesting =
party to access a resource.=20
>=20
> GNAP designs this infrastructure around:
> - an orchestrator (what we refer to as a client)
> - an grant manager (what we refer to as a GS/AS)
> - the custodian of the resource (what we call a RS)
>=20
> As you see:
> - The word User does not appear here, and is not relevant as the focus =
is on authorizing access to a resource.
> - The word Claim is as well absent.
>=20
> Claim related to RO:
> The word Claim might start getting visible if the orchestrator (a.k.a. =
Client) or the custodian (a.k.a RS) needs some additional information on =
the RO to proceed with the access control decision. These claims refer =
to assertions of attributes or properties of the RO. These claims are =
issued by the GS as the GS manages interaction with the RO (see below). =
In this first place information about the requesting party =
(erroneously.k.a. User) is not relevant to the negotiation and =
provisioning framework. Let us call this sort of claim "RO-Attributes". =
A better name is welcome.
>=20
> Some advanced resource provisioning frameworks might require knowledge =
on attributes of the requesting party (e.k.a User). These attributes =
shall be collected by the orchestrator (a.k.a Client) and added to the =
resource request. There is no way the GS can collect these attributes as =
the GS role has no interaction with the requesting party (e.k.a User). =
Let us call this sort of claim "Requestor-Attributes". A better name =
will be welcome.
>=20
> Some assertions are even related to the orchestrator (a.k.a Client) =
itself. This is the case of the public key of an orchestrator used by =
the GS to "sender constrain" an access token. Let us call this type of =
claim "Orchestrator-Attributes".
>=20
> This is a sample mapping of OIDC.
>=20
> +----+    +---+   +---+  +---+
> |User|    |RP |   |OP |  |RS |
> +----+    +---+   +-+-+  +---+
>   |(1) ServiceRequest      |
>   |-------->|       |      |
>   |(2) redirect     |      |
>   |<--------|       |      |
> =3D=3D=3D User (requestor) passes control to User (RO) =3D=3D=3D
>   |(3) Auth + Consent      |
>   |---------------->|      |
>   |(4) redirect (code)     |
>   |<----------------|      |
> =3D=3D=3D User (RO) passes control back to User (requestor) =3D=3D=3D
>   |(5) get(code)    |      |
>   |-------->|       |      |
>   |         |(6) token (code)
>   |         |------>|      |
>   |         |(7) token     |
>   |         |<------|      |
>   |         |(8) ServiceRequest(token)
>   |         |------------->|
>   |         |(9) ServiceResponse
>   |         |<-------------|
>   |(10) ServiceResponse    |
>   |<--------|       |      |
>   +         +       +      +
>=20
> - RP orchestrates interaction between User and OP to enable the user =
to obtain the protected resource.
> - In step 1 & 10 User plays the role of the requestor of the resource.
> - In step 2 User-Browser is used to pass control from User (in his =
role as the requestor) to User (in his role as the RO)
> - In step 4 User-Browser is used to pass control from User (in his =
role as the RO) back to User (in his role as the requestor)
>=20
> When we are talking claims here, we are talking claims on the User (in =
his role as the RO). The OP does not have any interaction with the User =
(in his role as the requestor). In the case of an App2App redirection, =
the OP can not even assert about the user agent of the User (requestor).
>=20
> If there is any claim the OP can provide, it is a claim on the User =
(RO).
>=20
> I hope this example clarifies the misunderstanding. Any attempt of =
bringing this double role of the User into GNAP will also bring this =
confusion. In order to keep this out of GNAP let us look for the right =
term for User (as a requestor) using the diagram displayed below.
>=20
> +----+  +------+  +---+  +---+  +---+
> |Reqs|  |Orchst|  |RS |  |GS |  |RO |
> +----+  +------+  +---+  +-+-+  +-+-+
>   |(1) ServiceRequest      |      |
>   |-------->|       |      |      |
>   |         |(2) ServiceIntent:AuthZChallenge=20
>   |         |<----->|      |      |
>   |         |       |      |      |
>   |         |(3) AuthZRequest(AuthZChallenge)
>   |         |------------->|      |
>   |         |       |      |(4) ConsentRequest:Grant
>   |         |       |      |<---->|
>   |         |(5) GrantAccess(AuthZ)
>   |         |<-------------|      |
>   |         |       |      |      |
>   |         |(6) ServiceRequest(AuthZ):ServiceResponse
>   |         |<----->|      |      |
>   |(7) ServiceResponse     |      |
>   |<--------|       |      |      |
>   +         +       +      +      +
>=20
> - Replacing the word User helps clarify the difference between both =
roles "Requestor" and "Resource Owner"
> - Renaming claim by attaching the Object/target of the claim (e.g.: =
RO-attributes, Requestor-Attributes, Orchestrator-Attributes) also helps =
identify the source of those attributes (GS, RS, Client):
>=20
> Best regards.
> /Francis
>=20
> On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt > wrote:
> It is not clear to me what it matters if a Claim comes from an RS, or =
from the GS, so I don't see a need to differentiate them.
>=20
> I would include verifiable credentials and user-bound keys as Claims.
>=20
> All the payment processing information I have seen has been in RAR. =
When would the Client get payment processing directly from the GS?
>=20
> What is your example for distributed networks storage locations? If =
what is stored is a statement about the user, then I would consider that =
a Claim as well.
>=20
> We disagree on how to map OIDC to GNAP.  The direct data is a claims =
request, the data coming indirectly is an access token request.
>=20
>=20
>=20
> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer > wrote:
> Since we=E2=80=99re already talking about returning claims as direct =
data as well as a part of the resource API being protected, so we =
already need a way to differentiate the two kinds of items. Just calling =
it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, because as you=E2=80=99v=
e pointed out they could show up in both places. So yes, defining that =
difference is something we should worry about now, even if the core =
protocol only uses it for claims.
>=20
> The two forms of direct data that XYZ returns are subject identifiers =
(a subset of identity claims) and assertions =E2=80=94 the latter being =
a container not just for identity claims but also authentication =
information and other elements. Assertions are not claims themselves.=20
>=20
> Other use cases that have been brought up include verifiable =
credentials and proofs, user-bound keys, payment processing information, =
and distributed network storage locations. I=E2=80=99m sure there are a =
lot more. To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D =
but not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be =
defining what all of these look like, but it should define a way to talk =
about them.
>=20
> I think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=
=9D request, which allows targeting of its claims information into =
different return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D=
 request at the very least. I don=E2=80=99t think GNAP should define how =
to do this specific combination, that should be for OIDF to debate and =
apply. The same with a DID service based query, or Presentation Exchange =
[1], or anything else that people want to come up with.
>=20
> In my view, GNAP should define query structures for two things: rights =
that get tied to an access token and data that comes back directly to =
the client. For the latter, I think we can do some very limited and very =
useful specific items, which is what I=E2=80=99ve put into XYZ.
>=20
>  =E2=80=94 Justin
>=20
> [1] https://identity.foundation/presentation-exchange/ =

>=20
>> On Jul 24, 2020, at 3:58 PM, Dick Hardt > wrote:
>>=20
>> I agree we want GNAP to be a strong foundation.=20
>>=20
>> Do you have an example of other "direct data"? If so, do you expect =
it to be defined in the core protocol?
>>=20
>> I would expect an extension for other "direct data" to define top =
level objects, and an appropriate definition for that "direct data".
>>=20
>> My "do we need to worry about it now" comment was on creating a =
generic term for "direct data". Unless we are solving those now, we can =
let further work define that "direct data" explicitly.
>>=20
>>=20
>>=20
>>=20
>> =E1=90=A7
>>=20
>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer > wrote:
>> Yes, I do think we need to worry about it to the extent that we are =
not creating something that is over-fit to a limited set of use cases.=20=

>>=20
>> GNAP should be a foundation that many amazing new things can be built =
on top of.
>>=20
>>  =E2=80=94 Justin
>>=20
>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt > wrote:
>>>=20
>>> Justin, thanks for clarifying.
>>>=20
>>> What are some examples of other "direct data" that the GS may =
return? If it is not in core GNAP, do we need to worry about now? We can =
then give the direct data from the GS that is not a claim, an =
appropriate name in that document.
>>>=20
>>>=20
>>>=20
>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer > wrote:
>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m =
saying. I agree that =E2=80=9Cclaims=E2=80=9D are about the user, in =
this context*. But the AS could return other data directly to the client =
that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=
=80=9D by the classical definition. Also since =E2=80=9Cclaims=E2=80=9D =
can come back from places other than directly, then we shouldn=E2=80=99t =
call everything that comes back a =E2=80=9Cclaim=E2=80=9D.
>>>=20
>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean =
what it already means and come up with a new word to mean =E2=80=9Cthings =
that come back directly from the AS=E2=80=9D. These aren=E2=80=99t meant =
to replace Francis=E2=80=99s more complete definitions, but to simplify:
>>>=20
>>> Claims:
>>> 	- information about the user
>>> 	- can come back directly from the AS
>>> 	- can come back in a resource from the RS
>>>=20
>>> Resource:
>>> 	- Returned from an RS
>>> 	- Protected by access token
>>> 	- Could contain claims about the user
>>>=20
>>> Direct data (or some better name):
>>> 	- Returned directly from AS
>>> 	- Could contain claims about the user
>>>=20
>>> I think the problem is that some people are using =E2=80=9Cclaims=E2=80=
=9D to mean #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. =
But: It=E2=80=99s important to remember, when talking about OIDC, that =
an IdP in OIDC combines an AS and an RS into one entity for identity =
information. There can be other RS=E2=80=99s as well, and there usually =
are in the wild, but the one defined by OIDC is the UserInfo Endpoint. =
The fact that it returns user data doesn=E2=80=99t make it any less of =
an RS.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>> * In the wider context of things like the information claims inside =
a JWT, the claims could be about literally anything, but that=E2=80=99s =
not what we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99=
s being used.
>>>=20
>>>=20
>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt > wrote:
>>>>=20
>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly =
from the OP in an ID Token, or the Client can obtain Claims using an =
access token to call the UserInfo endpoint, a Protected Resource[1].
>>>>=20
>>>> The Claims are about the User (not a RO).
>>>>=20
>>>> In XAuth, I'm proposing the Client may obtain bare claims from the =
GS directly in addition to the mechanisms in ODIC.
>>>>=20
>>>> So I don't think we are changing the definition of Claim from how =
it has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>=20
>>>> Justin: you allude to Claims being about a party other than the =
User. Would you provide an example?
>>>>=20
>>>> /Dick
>>>>=20
>>>> [1]
>>>> UserInfo Endpoint
>>>> Protected Resource that, when presented with an Access Token by the =
Client, returns authorized information about the End-User represented by =
the corresponding Authorization Grant. The UserInfo Endpoint URL MUST =
use the https scheme and MAY contain port, path, and query parameter =
components.
>>>>=20
>>>>=20
>>>>=20
>>>> =E1=90=A7
>>>>=20
>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer > wrote:
>>>> I want to focus on one aspect here:
>>>>=20
>>>>>=20
>>>>> A Claim is a well understood term in the field. We should use it. =
It is still a Claim if it comes directly from the GS or from an RS.=20
>>>>> I do not understand why a Resource release by an RS shall be h to =
as a claim, even if the content of the Resource is an assertion. It will =
lead to confusion. If we limit claims to information GS releases into =
Token, User Info, and other objects it returns, this will help separate =
responsibilities between GS and RS. As soon as RS services and =
information, this is called a Resource, no matter the nature of the =
content of that information.
>>>>=20
>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclai=
m=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=
=80=9D could come back through an RS =E2=80=94 but in the context of =
GNAP, that makes it a resource. So we need a different word for data =
coming back directly from the AS to the client. Sometimes it=E2=80=99s =
going to be about the user, and that=E2=80=99s what we=E2=80=99re going =
to focus on here, but since you can also get information about the user =
from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. =
I think this has been at the heart of a lot of confusion in recent =
threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.
>>>>=20
>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already =
does, and let=E2=80=99s find a way to differentiate between when an =
item, claim or otherwise,  comes as part of a resource and when it comes =
back directly. This is an important differentiating feature for GNAP.
>>>>=20
>>>> Some straw man ideas, none of which I=E2=80=99m particularly in =
love with:
>>>>=20
>>>>  - direct data
>>>>  - properties
>>>>  - details
>>>>  - statements
>>>>=20
>>>> The important thing here is that it=E2=80=99s not necessarily =
:about: the RO, and that it is :not: in a resource.
>>>>=20
>>>> Any other thoughts?
>>>>=20
>>>>  =E2=80=94 Justin
>>>=20
>>=20
>=20
>=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
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/ =


--Apple-Mail=_7B72B520-CF98-4434-BB23-1657A65EE6D5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
agree with the separation between =E2=80=9Croles=E2=80=9D and =
=E2=80=9Centities=E2=80=9D. It=E2=80=99s exactly that kind of separation =
into roles that helped OAuth 2 succeed with the AS and RS roles possibly =
being the same entity, or not, depending on use case.

This is one of the reasons that I think =
=E2=80=9Cuser=E2=80=9D is an overloaded term. The user is an entity, not =
a role, and in spite of it being =E2=80=9Cunderstood=E2=80=9D in the =
OAuth 2 world, it means a wide variety of other things outside that =
world. The same with =E2=80=9Cclient=E2=80=9D, I can=E2=80=99t tell you =
how many times I=E2=80=99ve had to explain what exactly an OAuth =
=E2=80=9Cclient=E2=80=9D is when I=E2=80=99m teaching a class.

As for specific =
recommendations: I=E2=80=99m in favor of the role =E2=80=9CRequester=E2=80=
=9D or =E2=80=9CRequesting Party=E2=80=9D. =E2=80=9CClient=E2=80=9D is =
arguably more confusing and harder to replace: I had tried to use =
=E2=80=9CResource Client=E2=80=9D to make =E2=80=9Cclient=E2=80=9D more =
specific in XYZ but that turned out to be more confusing than =
helpful.

 =E2=80=94 Justin

On Jul =
27, 2020, at 6:12 AM, Francis Pouatcha <fpo@adorsys.de> =
wrote:



On Sun, Jul 26, 2020 at 11:58 PM Dick Hardt <dick.hardt@gmail.com> wrote:


On Sun, Jul 26, 2020 at 6:45 PM Francis =
Pouatcha <fpo@adorsys.de> wrote:
Hello Dick,

On Sun, Jul =
26, 2020 at 9:14 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Francis

User is a well understood term in OIDC and OAuth -- and User =
means the same in both. 

Resource Owner is who =
owns the resource, and the term is introduced for when the User is NOT =
the Resource Owner. 
This =
distinction is what makes it confusing as we are comparing an Entity =
(the User) to a Role (the RO). We need two =
roles.

Or we could think of them all as =
entities. The RO is the entity that owns the resource. The User is the =
human that is using the Client. 
When we think of them as entities, we run into conflicts when =
Entity-User eq. Entity-RO.
When we think of them as =
roles, Role-User is always !=3D Role-RO 
 
 

I also think that Client =
and Resource Server are well understood =
terms.
Looks like contributors =
on the list still need clarification on the "orchestration" role of =
a client.

When I think of orchestration, I think =
of coordinating, which is not what I think the Client is =
doing. The Client wants to consume the Claims and the Resources =
(combined are a Grant). The Client requests the Grant from the Grant =
Server. Where is the orchestration?
Look at the client. It is the center of interaction between =
User, GS and RS.
 

It is not clear to me =
why we would want to reinvent these terms. Reading over your flows, I =
think it would be useful to understand the requirements you have =
for your use case, otherwise I fear we will be talking past each =
other.
The oAuth flow is there =
as a memo. The other flow is what I proposed before. Is there to =
emphasize we need to work on roles and not on entities. It is not a =
suggestion to rename well known idioms. It is an =
attempt to give them a proper definition in the context of =
this protocol. Definition based on their roles in the protocol =
flows.

I'd like to take a step back and =
understand the requirements. We are deep into =
solutions.
No, we are at =
the fundamental level. We Have to decide on whether to build a =
model based on roles oron entities... Then we use the result [ENTITY XOR =
ROLES] to define the use cases.
/Francis
 

Best regards.
/Francis

/Dick

3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 7:21 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Below my =
opinion on the term Claim:

Starting with =
illustration of parties/roles:

User: 
This word is misleading because of its =
double role in oAuth2 and OIDC (see below). In GNAP let us have the User =
play only the role of a requestor. (from Justin reference to "Requesting =
Party").

Client:
This is also tightly bound to the =
oAuth2 and OIDC. The real purpose of this role is to orchestrate =
resource access on behalf of the "Requestor". Let us call this for now =
the "Orchestrator"

Resource Owner (RO):
This is IMO the most =
correct word in the entire protocol. Authorisation is always about the =
owner of something granting access to a requestor. It really does =
not matter if a human interaction is involved. We will have to forget =
oAuth2 and OIDC of also calling this a User.

Grant Server: 
Even though the definition of the UserInfo =
endpoint in OIDC as a protected resource hazardously makes an OP an RS, =
we shall not repeat the same mistake here. We need a clear separation =
between roles of GS and RS without overlapping.

Resource Server: services resources.

Unless I got it wrong, GNAP is about grant negotiation =
and authorization. This means:

GNAP =
is about some party requesting access to some =
resources.
GNAP is about the resource owner consenting access to that =
resource.
GNAP is about defining the infrastructure that allows the =
requesting party to access a resource. 

GNAP designs this infrastructure around:
- an orchestrator (what =
we refer to as a client)
- an grant manager (what we refer to as a =
GS/AS)
- =
the custodian of the resource (what we call a RS)

As you see:
- The word User does not appear here, and =
is not relevant as the focus is on authorizing access to a =
resource.
- The word Claim is as well absent.

Claim related to RO:
The word Claim might start getting visible =
if the orchestrator (a.k.a. Client) or the custodian (a.k.a RS) needs =
some additional information on the RO to proceed with the access control =
decision. These claims refer to assertions of attributes or properties =
of the RO. These claims are issued by the GS as the GS manages =
interaction with the RO (see below). In this first place information =
about the requesting party (erroneously.k.a. User) is not relevant to the negotiation and =
provisioning framework. Let us call this sort of claim "RO-Attributes". =
A better name is welcome.

Some advanced resource =
provisioning frameworks might require knowledge on attributes of the =
requesting party (e.k.a User). These attributes shall be collected by =
the orchestrator (a.k.a Client) and added to the resource request. =
There is no way the GS can collect these attributes as the GS role has =
no interaction with the requesting party (e.k.a User). Let us call =
this sort of claim "Requestor-Attributes". A better name will be =
welcome.

Some assertions are even related to the =
orchestrator (a.k.a Client) itself. This is the case of the public =
key of an orchestrator used by the GS to "sender constrain" an =
access token. Let us call this type of claim =
"Orchestrator-Attributes".

This is a sample mapping =
of OIDC.

+----+    +---+   +---+ =
 +---+
|User|    |RP |   |OP | =
 |RS |
+----+    +---+   +-+-+ =
 +---+
  |(1) ServiceRequest     =
 |
  |-------->|       | =
     |
  |(2) redirect    =
 |      |
  |<--------|   =
    |      |
=3D=3D=3D User (requestor) passes control =
to User (RO) =3D=3D=3D
  |(3) Auth + Consent     =
 |
  |---------------->|     =
 |
  |(4) redirect (code)     |
  |<----------------|     =
 |
=3D=3D=3D User (RO) passes control back to User (requestor) =
=3D=3D=3D
  |(5) get(code)    |   =
   |
  |-------->|      =
 |      |
  |     =
    |(6) token (code)
  |     =
    |------>|      |
  | =
        |(7) token     |
  |         |<------|   =
   |
  |         |(8) =
ServiceRequest(token)
  |         =
|------------->|
  |         =
|(9) ServiceResponse
  |         =
|<-------------|
  |(10) ServiceResponse   =
 |
  |<--------|       | =
     |
  +         =
+       +      +

- RP orchestrates interaction between User =
and OP to enable the user to obtain the protected =
resource.
- In step 1 & 10 User plays the role of the requestor of =
the resource.
- In step 2 User-Browser is used to pass control from User =
(in his role as the requestor) to User (in his role as the =
RO)
- In =
step 4 User-Browser is used to pass control from User (in his role =
as the RO) back to User (in his role as the =
requestor)

When we are talking claims here, we are =
talking claims on the User (in his role as the RO). The OP does not have =
any interaction with the User (in his role as the requestor). In the =
case of an App2App redirection, the OP can not even assert about the =
user agent of the User (requestor).

If there is any claim the =
OP can provide, it is a claim on the User (RO).

I hope this example clarifies the misunderstanding. Any =
attempt of bringing this double role of the User into GNAP will also =
bring this confusion. In order to keep this out of GNAP let us look for =
the right term for User (as a requestor) using the diagram displayed =
below.
+----+  +------+  +---+  +---+  +---+
|Reqs|  |Orchst|  |RS |  |GS |  |RO |
+----+  +------+  +---+  +-+-+  +-+-+
  |(1) ServiceRequest      |   =
   |
  |-------->|       =
|      |      |
  | =
        |(2) ServiceIntent:AuthZChallenge 
  |         |<----->|   =
   |      |
  |   =
      |       |      | =
     |
  |         =
|(3) AuthZRequest(AuthZChallenge)
  |     =
    |------------->|      |
  |         |       | =
     |(4) ConsentRequest:Grant
  | =
        |       |     =
 |<---->|
  |         =
|(5) GrantAccess(AuthZ)
  |       =
  |<-------------|      |
  | =
        |       |     =
 |      |
  |     =
    |(6) ServiceRequest(AuthZ):ServiceResponse
  |         |<----->|   =
   |      |
  |(7) =
ServiceResponse     |      |
 =
 |<--------|       |      |   =
   |
  +         + =
      +      +      +

- Replacing the word User helps clarify =
the difference between both roles "Requestor" and "Resource =
Owner"
- =
Renaming claim by attaching the Object/target of the claim (e.g.: =
RO-attributes, Requestor-Attributes, Orchestrator-Attributes) also helps =
identify the source of those attributes (GS, RS, =
Client):

Best regards.
/Francis

On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt <dick.hardt@gmail.com> wrote:
It is not clear to me what it =
matters if a Claim comes from an RS, or from the GS, so I don't see a =
need to differentiate them.

I would include verifiable credentials and user-bound keys =
as Claims.

All =
the payment processing information I have seen has been in RAR. =
When would the Client get payment processing directly from the =
GS?

What is =
your example for distributed networks storage locations? If what is =
stored is a statement about the user, then I would consider that a Claim =
as well.

We =
disagree on how to map OIDC to GNAP.  The direct data is a claims =
request, the data coming indirectly is an access token =
request.



On Fri, Jul 24, 2020 at 1:39 PM Justin =
Richer <jricher@mit.edu> wrote:
Since we=E2=80=99r=
e already talking about returning claims as direct data as well as a =
part of the resource API being protected, so we already need a way to =
differentiate the two kinds of items. Just calling it =E2=80=9Cclaims=E2=80=
=9D doesn=E2=80=99t help, because as you=E2=80=99ve pointed out they =
could show up in both places. So yes, defining that difference is =
something we should worry about now, even if the core protocol only uses =
it for claims.

The =
two forms of direct data that XYZ returns are subject identifiers (a =
subset of identity claims) and assertions =E2=80=94 the latter being a =
container not just for identity claims but also authentication =
information and other elements. Assertions are not claims =
themselves. 

Other use cases that have been brought up include verifiable =
credentials and proofs, user-bound keys, payment processing information, =
and distributed network storage locations. I=E2=80=99m sure there are a =
lot more. To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D =
but not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be =
defining what all of these look like, but it should define a way to talk =
about them.

I =
think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=
=9D request, which allows targeting of its claims information into =
different return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D=
 request at the very least. I don=E2=80=99t think GNAP should define how =
to do this specific combination, that should be for OIDF to debate and =
apply. The same with a DID service based query, or Presentation Exchange =
[1], or anything else that people want to come up with.

In my view, GNAP should =
define query structures for two things: rights that get tied to an =
access token and data that comes back directly to the client. For the =
latter, I think we can do some very limited and very useful specific =
items, which is what I=E2=80=99ve put into XYZ.

 =E2=80=
=94 Justin

[1] https://identity.foundation/presentation-exchange/

On Jul 24, 2020, at 3:58 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

I agree we want GNAP to be a =
strong foundation. 

Do you have an example of other "direct data"? If so, do you =
expect it to be defined in the core protocol?

I would expect an extension for other =
"direct data" to define top level objects, and an appropriate definition =
for that "direct data".

My "do we need to worry about it now" comment was on creating =
a generic term for "direct data". Unless we are solving those now, we =
can let further work define that "direct data" explicitly.




3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
Yes, I do think we need to worry about it to the extent that =
we are not creating something that is over-fit to a limited set of use =
cases. 

GNAP =
should be a foundation that many amazing new things can be built on top =
of.

 =E2=80=94 Justin

On Jul =
24, 2020, at 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, thanks for =
clarifying.

What are =
some examples of other "direct data" that the GS may return? If it is =
not in core GNAP, do we need to worry about now? We can then give the =
direct data from the GS that is not a claim, an appropriate name in that =
document.



On Fri, Jul 24, 2020 at 11:46 AM Justin =
Richer <jricher@mit.edu> wrote:
Dick: No, I =
think you=E2=80=99re misunderstanding what I=E2=80=99m saying. I agree =
that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But =
the AS could return other data directly to the client that isn=E2=80=99t =
about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=80=9D by the =
classical definition. Also since =E2=80=9Cclaims=E2=80=9D can come back =
from places other than directly, then we shouldn=E2=80=99t call =
everything that comes back a =E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m arguing that we keep =
=E2=80=9Cclaims=E2=80=9D to mean what it already means and come up with =
a new word to mean =E2=80=9Cthings that come back directly from the =
AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s =
more complete definitions, but to simplify:

Claims:
	- information =
about the user
	- can come back directly from the =
AS
=
	- can come back in a resource from the RS

Resource:
	- =
Returned from an RS
	- Protected by access token
	- =
Could contain claims about the user

Direct data (or some better =
name):
	- Returned directly from AS
	- =
Could contain claims about the user

I think the problem is that some people =
are using =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. =
It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s important to =
remember, when talking about OIDC, that an IdP in OIDC combines an AS =
and an RS into one entity for identity information. There can be other =
RS=E2=80=99s as well, and there usually are in the wild, but the one =
defined by OIDC is the UserInfo Endpoint. The fact that it returns user =
data doesn=E2=80=99t make it any less of an RS.

 =E2=80=94 Justin

* In the wider context =
of things like the information claims inside a JWT, the claims could be =
about literally anything, but that=E2=80=99s not what we=E2=80=99re =
discussing here and it=E2=80=99s not how it=E2=80=99s being =
used.


On Jul =
24, 2020, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

In OpenID Connect (OIDC), the =
Client can obtain Claims directly from the OP in an ID Token, or the =
Client can obtain Claims using an access token to call the UserInfo =
endpoint, a Protected Resource[1].

The Claims are about the User (not a =
RO).

In XAuth, =
I'm proposing the Client may obtain bare claims from the GS directly in =
addition to the mechanisms in ODIC.

So I don't think we are changing the =
definition of Claim from how it has been used in OIDC, and I fail to see =
any reason to NOT use Claim.

Justin: you allude to Claims being =
about a party other than the User. Would you provide an =
example?

/Dick

[1]
UserInfo =
Endpoint
Protected Resource that, when presented =
with an Access Token by the Client, returns authorized information about =
the End-User represented by the corresponding Authorization Grant. The =
UserInfo Endpoint URL MUST use the https scheme and MAY contain port, =
path, and query parameter components.



3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspect here:


A Claim is a well understood term in the field. We should use =
it. It is still a Claim if it comes directly from the GS or from an =
RS. 
I do not understand =
why a Resource release by an RS shall be h to as a claim, even if the =
content of the Resource is an assertion. It will lead to confusion. If =
we limit claims to information GS releases into Token, User Info, and =
other objects it returns, this will help separate responsibilities =
between GS and RS. As soon as RS services and information, this is =
called a Resource, no matter the nature of the content of that =
information.

This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =
=E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in =
the context of GNAP, that makes it a resource. So we need a different =
word for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s going to be about the user, and that=E2=80=99s what we=E2=80=99=
re going to focus on here, but since you can also get information about =
the user from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=
=80=9D. I think this has been at the heart of a lot of confusion in =
recent threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=
=9D mean what it already does, and let=E2=80=99s find a way to =
differentiate between when an item, claim or otherwise,  comes =
as part of a resource and when it comes back directly. This is an =
important differentiating feature for GNAP.

Some straw man ideas, none of which =
I=E2=80=99m particularly in love with:

 - direct data
 - properties
 - =
details
 - statements

The important thing here is that it=E2=80=
=99s not necessarily :about: the RO, and that it is :not: in a =
resource.

Any other =
thoughts?

 =E2=80=94 =
Justin

<=
br =
class=3D"">
<=
br =
class=3D"">
<=
br clear=3D"all" class=3D"">

-- 
Francis Pouatcha
Co-Founder and =
Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/
Hello Dick,

On Sun, Jul 26, 2020 at 9:14 P=
M Dick Hardt <dick.hardt@gmail.c=
om> wrote:
Hi Francis

User is a well understood =
term in OIDC and OAuth -- and User means the same in both.=C2=A0

Resource Owner is who owns the resource, and the =
term is introduced for when the User is NOT the Resource Owner.=C2=A0
=

This distinction is what makes it confusing as we a=
re comparing an Entity (the User) to a Role (the RO). We need two roles.
=C2=A0

I also think that Client and Resource Serve=
r are well understood terms.
Looks like contri=
butors on the list still need clarification on=C2=A0the "orchestration=
" role of a client.

It is not clear to me why we woul=
d want to reinvent these terms. Reading over your flows, I think it would b=
e useful=C2=A0to understand the requirements you have for your use case, ot=
herwise I fear we will be talking past each other.
=

The oAuth flow is there as a memo. The other flow is what I proposed b=
efore. Is there to emphasize we need to work on roles and not on entities. =
It is not a suggestion=C2=A0to rename=C2=A0well known idioms. It is an atte=
mpt=C2=A0to give=C2=A0them a proper definition in the context of this proto=
col. Definition based on their roles in the protocol flows.

<=
/div>
Best regards.
/Francis

/Dick

=E1=90=A7

On Fri, Jul 24, 2020 at 7:2=
1 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Below my opinion=
=C2=A0on the term Claim:

Starting with illustration of parties/role=
s:

User:=C2=A0
This=
 word is misleading because of its double role in oAuth2 and OIDC (see belo=
w). In GNAP let us have the User play only the role of a requestor. (from J=
ustin reference to "Requesting Party").

Client:
This is also tightly=C2=A0bound to t=
he oAuth2 and OIDC. The real purpose of this role is to orchestrate resourc=
e access on behalf of the "Requestor". Let us call this for now t=
he "Orchestrator"

<=
/font>
Resource Owner (RO):
=

This is IMO the most correct word in the enti=
re protocol. Authorisation is always about the owner of something granting =
access to a requestor. It really=C2=A0does not matter if a human interactio=
n is involved. We will have to forget oAuth2 and OIDC of also calling this =
a User.

Grant Server:=C2=A0
Even though the definition of the UserInfo endpoint in OIDC as a p=
rotected resource hazardously makes an OP an RS, we shall not repeat the sa=
me mistake here. We need a clear separation between roles of GS and RS with=
out overlapping.

Resource Server: services resources.<=
/div>

Unless I got=C2=A0it wrong, GNAP is about grant negotiation and auth=
orization. This means:

GNAP is about some party re=
questing access to some resources.
GNAP is about the resource owner consenting access to that resource.
GNAP is about defining the infrastruc=
ture that allows the requesting party to access a resource.=C2=A0

GNAP designs this infrastructure around:
- an orchestrator (what we refer to as a client)
- an grant manager (what we refer to as a GS=
/AS)
- the custodian of the resou=
rce (what we call a RS)

As you see:
- The word User does not appear here, and is not relevant =
as the focus=C2=A0is on authorizing access to a resource.
=
- The word Claim is as well absent.

=
Claim related to RO:
The word Cla=
im might start getting visible if the orchestrator (a.k.a. Client) or the c=
ustodian (a.k.a RS) needs some additional information on the RO to proceed =
with the access control decision. These claims refer to assertions of attri=
butes or properties of the RO. These claims are issued by the GS as the GS =
manages interaction with the RO (see below). In this first place informatio=
n about the requesting party (erroneously.k=
.a. User) is not relevant to the negotiation and provisioning framework. Le=
t us call this sort of claim "RO-Attributes". A better name is we=
lcome.

Some advanced resource provisioning frameworks might r=
equire knowledge on attributes of the requesting party (e.k.a User). These =
attributes shall be collected by the=C2=A0orchestrator (a.k.a Client) and a=
dded to the resource request. There is no way the GS can collect these attr=
ibutes as the GS role has no interaction with the requesting party (e.k.a U=
ser).=C2=A0Let us call this sort of claim "Requestor-Attributes".=
 A better name will be welcome.
<=
br>
Some assertions are even rela=
ted to the orchestrator=C2=A0(a.k.a Client) itself. This is the case of the=
 public key of an orchestrator=C2=A0used by the GS to "sender constrai=
n" an access token. Let us call this type of claim "Orchestrator-=
Attributes".

This is a sample mapping of OIDC.

+----+ =C2=A0 =C2=A0+---+ =C2=A0 +---+ =C2=A0+---+
|User| =C2=A0 =
=C2=A0|RP | =C2=A0 |OP | =C2=A0|RS |
+----+ =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 |=
(2) redirect=C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |<----=
----| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=3D=3D=3D User (requestor) passes control to User (RO) =
=3D=3D=3D
=C2=A0 |(3) Auth + Cons=
ent =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |---------------->| =C2=A0 =C2=A0 =
=C2=A0|
=C2=A0 |(4) redirect (code) =C2=A0 =C2=A0 |
=C2=A0 |<-----=
-----------| =C2=A0 =C2=A0 =C2=A0|
=3D=3D=3D User (RO) passes control back to User (requestor) =3D=3D=3D
=
=C2=A0 |(5) get(code) =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |-----=
--->| =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) token (code)
=C2=A0 | =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) token =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
|<------| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
|(8) ServiceRequest(token)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |-------=
------>|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(9) ServiceResponse=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<-------------|
=C2=A0 |(10) S=
erviceResponse =C2=A0 =C2=A0|
=C2=A0 |<--------| =C2=A0 =C2=A0 =C2=A0=
 | =C2=A0 =C2=A0 =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 orchestrates i=
nteraction between User and OP to enable the user to obtain the protected r=
esource.
- In step 1 & 10 Use=
r plays the role of the requestor of the resource.
- In step 2 User-Browser is used to pass control from Use=
r (in his role as the requestor) to User (in his role as the RO)
- In step 4=C2=A0User-Browser is used to pa=
ss control from User (in his role as the RO) back to=C2=A0User (in his role=
 as the requestor)

When we are talking claims here, we are ta=
lking claims on the User (in his role as the RO). The OP does not have any =
interaction with the User (in his role as the requestor). In the case of an=
 App2App redirection, the OP can not even assert about the user agent of th=
e User (requestor).

If there is any claim the OP can provide,=
 it is a claim on the User (RO).
=

I hope this example clarifie=
s the misunderstanding. Any attempt of bringing this double role of the Use=
r into GNAP will also bring this confusion. In order to keep this out of GN=
AP let us look for the right term for User (as a requestor) using the diagr=
am displayed below.

+----+ =C2=A0+------+ =C2=A0+---+ =C2=A0+=
---+ =C2=A0+---+
|Reqs| =C2=A0|Orchst| =C2=A0|RS | =C2=A0|GS | =C2=A0|RO=
 |
+----+ =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 |(2) ServiceIntent:AuthZChalle=
nge=C2=A0
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<----->| =C2=A0 =
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0 =C2=A0 =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|(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 |(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 |(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 |=
(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|<=
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+

- Replacing the word Us=
er helps clarify the difference between both roles "Requestor" an=
d "Resource Owner"
- Re=
naming claim by attaching the Object/target of the claim (e.g.: RO-attribut=
es, Requestor-Attributes, Orchestrator-Attributes) also helps identify the =
source of those attributes (GS, RS, Client):

Best regards.
/Francis

On Fri, Jul 24, 2020 at 4:58 PM Dic=
k Hardt <dick.=
hardt@gmail.com> wrote:
It is not clear to me what it matters =
if a Claim comes from an RS, or from the GS, so I don't see a need to d=
ifferentiate them.

I would include verifiable cred=
entials and user-bound keys as Claims.

All the pay=
ment processing information I have=C2=A0seen has been in RAR. When would=C2=
=A0the Client get payment processing directly from the GS?

What is your example for distributed networks storage locations? I=
f what is stored is a statement about the user, then I would consider that =
a Claim as well.

We disagree on how to map OIDC to=
 GNAP.=C2=A0 The direct data is a claims request, the data coming indirectl=
y is an access token request.



=

On Fri, Ju=
l 24, 2020 at 1:39 PM Justin Richer <jricher@mit.edu> wrote:
Since we=E2=80=99re already talking a=
bout returning claims as direct data as well as a part of the resource API =
being protected, so we already need a way to differentiate the two kinds of=
 items. Just calling it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, beca=
use as you=E2=80=99ve pointed out they could show up in both places. So yes=
, defining that difference is something we should worry about now, even if =
the core protocol only uses it for claims.

The two forms=
 of direct data that XYZ returns are subject identifiers (a subset of ident=
ity claims) and assertions =E2=80=94 the latter being a container not just =
for identity claims but also authentication information and other elements.=
 Assertions are not claims themselves.=C2=A0

Other=
 use cases that have been brought up include verifiable credentials and pro=
ofs, user-bound keys, payment processing information, and distributed netwo=
rk storage locations. I=E2=80=99m sure there are a lot more. To me, these a=
re subsets of the =E2=80=9Cdirect data=E2=80=9D but not subsets of =E2=80=
=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be defining what all of these lo=
ok like, but it should define a way to talk about them.

I think different top-level request objects are better suited for dif=
ferent query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=
=9D request, which allows targeting of its claims information into differen=
t return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D reques=
t at the very least. I don=E2=80=99t think GNAP should define how to do thi=
s specific combination, that should be for OIDF to debate and apply. The sa=
me with a DID service based query, or Presentation Exchange [1], or anythin=
g else that people want to come up with.

In my vie=
w, GNAP should define query structures for two things: rights that get tied=
 to an access token and data that comes back directly to the client. For th=
e latter, I think we can do some very limited and very useful specific item=
s, which is what I=E2=80=99ve put into XYZ.

<=
div>=C2=A0=E2=80=94 Justin

[1]=C2=A0https://=
identity.foundation/presentation-exchange/

On Jul 24, 2020, at 3:58 PM, Dick Hardt <dick.hardt@gmail.com> wrot=
e:

I agree we want GNAP to be a strong found=
ation.=C2=A0

Do you have an example of other "direc=
t data"? If so, do you expect it to be defined in the core protocol?

I would expect an extension for other "direct =
data" to define top level objects, and an appropriate definition for t=
hat "direct data".

My "do we need t=
o worry about it now" comment was on creating a generic term for "=
;direct data". Unless we are solving those now, we can let further wor=
k define that "direct data" explicitly.

=



3D""=E1=90=A7

On Fri, Jul 24, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
Yes, I do think we need =
to worry about it to the extent that we are not creating something that is =
over-fit to a limited set of use cases.=C2=A0

GNAP shoul=
d be a foundation that many amazing new things can be built on top of.
<=
div>
=C2=A0=E2=80=94 Justin

On Jul 24, 2020, at 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
Justin, thanks for clarifying.

<=
div>What are some examples of other "direct data" that the GS may=
 return? If it is not in core GNAP, do we need to worry about now? We can t=
hen give the direct data from the GS that is not a claim, an appropriate na=
me in that document.



On Fri, Jul 24, 202=
0 at 11:46 AM Justin Richer <jricher@mit.edu> wrote:
Dick: No, I think you=E2=80=99re misunderst=
anding what I=E2=80=99m saying. I agree that =E2=80=9Cclaims=E2=80=9D are a=
bout the user, in this context*. But the AS could return other data directl=
y to the client that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=
=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=80=9Cclai=
ms=E2=80=9D can come back from places other than directly, then we shouldn=
=E2=80=99t call everything that comes back a =E2=80=9Cclaim=E2=80=9D.
<=
br>
I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to =
mean what it already means and come up with a new word to mean =E2=80=9Cthi=
ngs that come back directly from the AS=E2=80=9D. These aren=E2=80=99t mean=
t to replace Francis=E2=80=99s more complete definitions, but to simplify:<=
/div>

Claims:
	- information about the user
	- can come back directly from the AS
	- can come back in a resource from t=
he RS

Resource:
	- Returned from an RS
	- Protected by access token
	- Could contain claims about the user
<=
div>
Direct data (or some better name):
	- Returned directly from AS
	- Could contain claims about the =
user

I think the problem is that some people are u=
sing =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. It=E2=80=99s =
clearly #1 in OIDC. But: It=E2=80=99s important to remember, when talking a=
bout OIDC, that an IdP in OIDC combines an AS and an RS into one entity for=
 identity information. There can be other RS=E2=80=99s as well, and there u=
sually are in the wild, but the one defined by OIDC is the UserInfo Endpoin=
t. The fact that it returns user data doesn=E2=80=99t make it any less of a=
n RS.

=C2=A0=E2=80=94 Justin

* =
In the wider context of things like the information claims inside a JWT, th=
e claims could be about literally anything, but that=E2=80=99s not what we=
=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s being use=
d.


On Jul 24, 2020, a=
t 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

In OpenID Connect (OIDC), the Client can obtain Claims directly from the O=
P in an ID Token, or the Client can obtain Claims using an access token to =
call the UserInfo endpoint, a Protected Resource[1].

The=
 Claims are about the User (not a RO).

In XAuth, I=
'm proposing the Client may obtain bare claims from the GS directly in =
addition to the mechanisms in ODIC.

So I don't=
 think we are changing the definition of Claim from how it has been used in=
 OIDC, and I fail to see any reason to NOT use Claim.

<=
div>Justin: you allude to Claims being about a party other than the User. W=
ould you provide an example?

/Dick

<=
/div>
[1]
UserInfo Endpoint
Protected Resource that, whe=
n presented with an Access Token by the Client, returns authorized informat=
ion about the End-User represented by the corresponding Authorization Grant=
. The UserInfo Endpoint URL MUST use the https scheme and MAY contain port,=
 path, and query parameter components.



3D""=E1=90=A7

<=
div class=3D"gmail_quote">
On Fri, Jul=
 24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspect here:

A Claim is a well understood term in the field. We =
should use it. It is still a Claim if it comes directly from the GS or from=
 an RS.=C2=A0
I do not understand why a Resour=
ce release by an RS shall be h to as a claim, even if the content of the Re=
source is an assertion. It will lead to confusion. If we limit claims to in=
formation GS releases into Token, User Info, and other objects it returns, =
this will help separate responsibilities between GS and RS. As soon as RS s=
ervices and information, this is called a Resource, no matter the nature of=
 the content of that information.

<=
/div>
This is exactly why I don=E2=80=99t think we should use =E2=80=9C=
claim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclai=
m=E2=80=9D could come back through an RS =E2=80=94 but in the context of GN=
AP, that makes it a resource. So we need a different word for data coming b=
ack directly from the AS to the client. Sometimes it=E2=80=99s going to be =
about the user, and that=E2=80=99s what we=E2=80=99re going to focus on her=
e, but since you can also get information about the user from a resource we=
 can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this has bee=
n at the heart of a lot of confusion in recent threads, as well as confusio=
n about the scope of the inclusion of identity in the GNAP protocol.
<=
div>
So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what i=
t already does, and let=E2=80=99s find a way to differentiate between when =
an item, claim or otherwise,=C2=A0=C2=A0comes as part of a resource and whe=
n it comes back directly. This is an important differentiating feature for =
GNAP.

Some straw man ideas, none of which I=E2=80=
=99m particularly in love with:

=C2=A0- direct dat=
a
=C2=A0- properties
=C2=A0- details
=C2=A0- =
statements

The important thing here is that it=E2=
=80=99s not necessarily :about: the RO, and that it is :not: in a resource.=


Any other thoughts?

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











-- 
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=_7B72B520-CF98-4434-BB23-1657A65EE6D5--


From nobody Mon Jul 27 05:17: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 08F823A1914 for ; Mon, 27 Jul 2020 05:17: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=[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 yLFlDOlA4Yzp for ; Mon, 27 Jul 2020 05:17:48 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650090.outbound.protection.outlook.com [40.107.65.90]) (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 361573A1912 for ; Mon, 27 Jul 2020 05:17:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NIsYPxUO0wrhpgf5vl88h0qI/HOUH3MPH7kKQM4QmTAXA4M4vy6tn0aQZUhnran4xfOm264GL895qC6bceXYuWhWr8ptilVi9Ffhewe13A/feV5sdrRZlXeYHxS+ryt6XGGeDSlJOK3WirtWDxnOvKmiQBpkD8dHiKDorLUuGqUmtXWZYgi/k45UtKEFJ5/+1+y+EbYI4Nz5HKRCp1FvoTR4RSKNkty37cnVaw3qG+sAOzYKaDJ0juYE9W20+XIO8BQoajyNEBgx9mliBw+Iols3BJdfvYSuaCbOvfKRBEjk5/znDC2Md6EpIv8Cgcq9P6gze41tZ9ebU1tiDB3yGw==
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=wCpU/7xCwrxOAjhTH9elMsKP3ezByola8dakU76wzWg=; b=l9ceH8F08L3Eq8XA15YuFMFG583ISgRUwny503eezeVupNUVgL+RMQETlUXj6cmj5Yma9sXUv0yXR9GC6zlOSlSRrjtM+QImv8cgFbZ8kxwtFRilLFUjKsF3TJ+SISivQksQdCqFz3mwqc4fECDXNnmI4PgsErZ++F9pJFybn2VW8ZEFnXOQ/UjG99u0bP/V656M7sjHEzlMWDKq5WfHHLVINy7J09A6AcSke+QGY7plhJmvdLIG3TZ0vxkc9yeAfQ9jYfFfzs8Bm6s+6fNk6f9GtvQFpUSSl4/FJ5hDS3uRDbGk3B8k1hPajG3wLiYu4JSTrX5PAcP1jODVfQSFsQ==
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=wCpU/7xCwrxOAjhTH9elMsKP3ezByola8dakU76wzWg=; b=GIDsti6TNo2zNx3E0KKUTNrinL24cDoEj97L74LNSMRjTsg9itCkMwk0JmkhMYRUtIaH86YgNpQ8KOW/fdw/i+vWHwFR8/oiNXHpP8znV1QEbrB1igMDPUyFAru2kSi+qO8ciyFewy6Ffyh2FRd7TJ8FVgDNBMnBIjmWyvU+51I=
Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0746.namprd00.prod.outlook.com (2603:10b6:610:6e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3264.0; Mon, 27 Jul 2020 12:17:45 +0000
Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::e478:40a9:9e0b:641c]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::e478:40a9:9e0b:641c%7]) with mapi id 15.20.3273.000; Mon, 27 Jul 2020 12:17:45 +0000
From: Mike Jones 
To: Justin Richer , Francis Pouatcha 
CC: Tom Jones , Fabien Imbault , Denis , "txauth@ietf.org" , Dick Hardt 
Thread-Topic: [Txauth] Claims [was: - Dictionary]
Thread-Index: AdZkD+riq0GJ5lcCRnq7sXrv7U5Heg==
Date: Mon, 27 Jul 2020 12:17:45 +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_ActionId=f10c6cb4-8ab3-4ea7-b2fa-6237a9b0a71e; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; 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_SetDate=2020-07-27T12:17:06Z;  MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.89.111]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 1ae8d08c-47ca-4a04-8b3c-08d8322711cb
x-ms-traffictypediagnostic: CH2PR00MB0746:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bbyO+Yjl30rMxQxs/L71I1lKYFh4cQErahUKISWDxxKyUFg4U8mDMAQYqDr9w0ssHt2KUYU3tGGJ8TCyefJqtJjqlkwzOz9yzjcXG2ZIsHIoeLornHalSu494uN5ZR9x0EmEFMh0bI6iQ1mX+vFJPTl+R65me76X22XPnrKWcxf0ZwlIm38nTGnz4whlakJcXB4Kt8OCvil/Iip5LXzFOF6VKBy2cpTJOichFoUmZyOS15kHMVMExsuRxLrn2v38LxVxKCYwMmsVomNsJlN/tTqEKiZ5pZa9E8efcf87zy7n6u8wrqZGuVK/1fuuijc5SZljgsw01FNgEF1ZkN/w3f3A3J0w2mqxXSuOGrAClhgK1xKdwOkEbIpBtvX3fNJ9k53jNgL6lj4Ix0j2eb0yPqmcPVUWryprKJU7hWMYLtf04gITTuiikyGfUE8dZoMcrYxbattljHgeuSYiQsn+Jy1q5b43ykGJkn8R957fDTs=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE;  SFTY:; SFS:(4636009)(346002)(376002)(136003)(396003)(366004)(39860400002)(6506007)(53546011)(26005)(8990500004)(66946007)(66556008)(66476007)(30864003)(66446008)(76116006)(52536014)(7696005)(478600001)(64756008)(10290500003)(186003)(71200400001)(5660300002)(966005)(2906002)(83080400001)(86362001)(166002)(55016002)(33656002)(8936002)(110136005)(316002)(82950400001)(4326008)(83380400001)(66574015)(8676002)(54906003)(9686003)(82960400001)(99710200001)(15866825006)(559001)(579004); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata: QJbcZSjeCm73oNd6XZGXG7KPgBZbnFl63aBmQtaNdHlzGCkNKbmUXGoNw8mggPJmUDU8wPl4ceWik+NBnEYiUp+jBWThxBDJ5CssTOMx6F0mJo76FTgUk6fHVCZKZxP3K6ngxrUjuujK3nVBzNyuEtmdNsuVTW3PLrx9tsto5Npr35jevztqjAOOm3xOQeOSFGitYqBT0/oUnZ93himjPo5qeACdwGrkfyMDvvAQq7QVePsF/A80be3CjlfbMBC+izipxNAjUQ8xEI9OUofZAjPw8x9BN1Grw8qba5n3UsJPzbDoIWvI1LVDQ8AmCq5zqJklt9GklTUHybTWnWcQ7wcqE8b+ozIPceS2Qvewf48IQyxSB3KNvh9r3xHjjMJiIa/agbstJvviy7423uL4hzxgtx3alfYJyd+axaDM6GGHP2MwI3t9ZqWrPZNm+jMoLy04FCdmKz72N4ohsBF4WTUfSwgFex+nKDBt9AsYPEkUW24MkrfTuV+0LDKirYpozKyYjcerEtruHMmphjAoeao7BA1I+DRF18fjv+zAaa8gWGN1oucZGvsMzOV0CaScL1lrPWUae/LJhK5nRxnAQoLJU6/VSV1BAnLu+4HYvEVJ2Uv1koVwvLWw2Xib8aKAuqLRtvJrDYqm4p5dVv1n+g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679BFFBE4251753CCECA430F5720CH2PR00MB0679namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ae8d08c-47ca-4a04-8b3c-08d8322711cb
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 12:17:45.4728 (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: 4AN1QlgQd0ZLfWfpNZi3gQGKiT+YwDYL2zK57YkLxdeAh1ACbw16lFv6h9QPgNIyVsed7Jmvuc4LaXD5Hby2AA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0746
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 12:17:53 -0000

--_000_CH2PR00MB0679BFFBE4251753CCECA430F5720CH2PR00MB0679namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UmVzcG9uZGluZyB0byBhIGZldyB0ZXJtaW5vbG9neSBwb2ludHMgYWZ0ZXIgY2F0Y2hpbmcgdXAg
dGhpcyB0aHJlYWQuDQoNClF1b3RpbmcgZnJvbSBSRkMgNzUxOToNCg0KICAgQ2xhaW0NCiAgICAg
IEEgcGllY2Ugb2YgaW5mb3JtYXRpb24gYXNzZXJ0ZWQgYWJvdXQgYSBzdWJqZWN0LiAgQSBjbGFp
bSBpcw0KICAgICAgcmVwcmVzZW50ZWQgYXMgYSBuYW1lL3ZhbHVlIHBhaXIgY29uc2lzdGluZyBv
ZiBhIENsYWltIE5hbWUgYW5kIGENCiAgICAgIENsYWltIFZhbHVlLg0KDQpJIGJlbGlldmUgdGhh
dCB0aGlzIGRlZmluaXRpb24gcmVtYWlucyBzdWl0YWJsZSBhbmQgYXBwbGljYWJsZSBhbmQgd2Ug
c2hvdWxkIGtlZXAgdXNpbmcgaXQuICBUaGUgZGVmaW5pdGlvbiBpcyBub3Qgc3BlY2lmaWMgdG8g
cGFydGljdWxhciBraW5kcyBvZiBzdWJqZWN0cy4gIE9wZW5JRCBDb25uZWN0IElEIFRva2VuIGNs
YWltcyBhcmUgYWJvdXQgdGhlIGF1dGhlbnRpY2F0aW9uIHRoYXQgd2FzIHBlcmZvcm1lZC4gIFVz
ZXJJbmZvIGNsYWltcyBhcmUgYWJvdXQgdGhlIEVuZC1Vc2VyLiAgU1RJUiBjbGFpbXMgZW5hYmxl
IHZlcmlmeWluZyB0aGUgb3duZXJzaGlwIG9mIHRlbGVwaG9uZSBudW1iZXJzLiAgQ2xhaW1zIGFi
b3V0IGFueSBraW5kcyBvZiBzdWJqZWN0cyBhcmUgcG9zc2libGUuDQoNClF1b3RpbmcgZnJvbSBP
cGVuSUQgQ29ubmVjdCBDb3JlOg0KDQpFbmQtVXNlcg0KSHVtYW4gcGFydGljaXBhbnQuDQoNCkni
gJlkIGFkdm9jYXRlIHVzaW5nIOKAnEVuZC1Vc2Vy4oCdIGluIHRoaXMgbWFubmVyLiAgVGhlIHRl
cm0g4oCcdXNlcuKAnSBjYW4gbWVhbiB0b28gbWFueSBvdGhlciB0aGluZ3MgdG8gcGVvcGxlLCBh
cyBkb2N1bWVudGVkIGluIHRoaXMgdGhyZWFkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBUeGF1dGggPHR4
YXV0aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSnVzdGluIFJpY2hlcg0KU2VudDog
TW9uZGF5LCBKdWx5IDI3LCAyMDIwIDU6MTUgQU0NClRvOiBGcmFuY2lzIFBvdWF0Y2hhIDxmcG9A
YWRvcnN5cy5kZT4NCkNjOiBUb20gSm9uZXMgPHRob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb20+
OyBGYWJpZW4gSW1iYXVsdCA8ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPjsgRGVuaXMgPGRlbmlz
LmlldGZAZnJlZS5mcj47IHR4YXV0aEBpZXRmLm9yZzsgRGljayBIYXJkdCA8ZGljay5oYXJkdEBn
bWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0gQ2xhaW1zIFt3YXM6IC0gRGljdGlvbmFy
eV0NCg0KSSBhZ3JlZSB3aXRoIHRoZSBzZXBhcmF0aW9uIGJldHdlZW4g4oCccm9sZXPigJ0gYW5k
IOKAnGVudGl0aWVz4oCdLiBJdOKAmXMgZXhhY3RseSB0aGF0IGtpbmQgb2Ygc2VwYXJhdGlvbiBp
bnRvIHJvbGVzIHRoYXQgaGVscGVkIE9BdXRoIDIgc3VjY2VlZCB3aXRoIHRoZSBBUyBhbmQgUlMg
cm9sZXMgcG9zc2libHkgYmVpbmcgdGhlIHNhbWUgZW50aXR5LCBvciBub3QsIGRlcGVuZGluZyBv
biB1c2UgY2FzZS4NCg0KVGhpcyBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgdGhhdCBJIHRoaW5rIOKA
nHVzZXLigJ0gaXMgYW4gb3ZlcmxvYWRlZCB0ZXJtLiBUaGUgdXNlciBpcyBhbiBlbnRpdHksIG5v
dCBhIHJvbGUsIGFuZCBpbiBzcGl0ZSBvZiBpdCBiZWluZyDigJx1bmRlcnN0b29k4oCdIGluIHRo
ZSBPQXV0aCAyIHdvcmxkLCBpdCBtZWFucyBhIHdpZGUgdmFyaWV0eSBvZiBvdGhlciB0aGluZ3Mg
b3V0c2lkZSB0aGF0IHdvcmxkLiBUaGUgc2FtZSB3aXRoIOKAnGNsaWVudOKAnSwgSSBjYW7igJl0
IHRlbGwgeW91IGhvdyBtYW55IHRpbWVzIEnigJl2ZSBoYWQgdG8gZXhwbGFpbiB3aGF0IGV4YWN0
bHkgYW4gT0F1dGgg4oCcY2xpZW504oCdIGlzIHdoZW4gSeKAmW0gdGVhY2hpbmcgYSBjbGFzcy4N
Cg0KQXMgZm9yIHNwZWNpZmljIHJlY29tbWVuZGF0aW9uczogSeKAmW0gaW4gZmF2b3Igb2YgdGhl
IHJvbGUg4oCcUmVxdWVzdGVy4oCdIG9yIOKAnFJlcXVlc3RpbmcgUGFydHnigJ0uIOKAnENsaWVu
dOKAnSBpcyBhcmd1YWJseSBtb3JlIGNvbmZ1c2luZyBhbmQgaGFyZGVyIHRvIHJlcGxhY2U6IEkg
aGFkIHRyaWVkIHRvIHVzZSDigJxSZXNvdXJjZSBDbGllbnTigJ0gdG8gbWFrZSDigJxjbGllbnTi
gJ0gbW9yZSBzcGVjaWZpYyBpbiBYWVogYnV0IHRoYXQgdHVybmVkIG91dCB0byBiZSBtb3JlIGNv
bmZ1c2luZyB0aGFuIGhlbHBmdWwuDQoNCiDigJQgSnVzdGluDQoNCg0KT24gSnVsIDI3LCAyMDIw
LCBhdCA2OjEyIEFNLCBGcmFuY2lzIFBvdWF0Y2hhIDxmcG9AYWRvcnN5cy5kZTxtYWlsdG86ZnBv
QGFkb3JzeXMuZGU+PiB3cm90ZToNCg0KDQoNCk9uIFN1biwgSnVsIDI2LCAyMDIwIGF0IDExOjU4
IFBNIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdt
YWlsLmNvbT4+IHdyb3RlOg0KDQoNCk9uIFN1biwgSnVsIDI2LCAyMDIwIGF0IDY6NDUgUE0gRnJh
bmNpcyBQb3VhdGNoYSA8ZnBvQGFkb3JzeXMuZGU8bWFpbHRvOmZwb0BhZG9yc3lzLmRlPj4gd3Jv
dGU6DQpIZWxsbyBEaWNrLA0KDQpPbiBTdW4sIEp1bCAyNiwgMjAyMCBhdCA5OjE0IFBNIERpY2sg
SGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+
IHdyb3RlOg0KSGkgRnJhbmNpcw0KDQpVc2VyIGlzIGEgd2VsbCB1bmRlcnN0b29kIHRlcm0gaW4g
T0lEQyBhbmQgT0F1dGggLS0gYW5kIFVzZXIgbWVhbnMgdGhlIHNhbWUgaW4gYm90aC4NCg0KUmVz
b3VyY2UgT3duZXIgaXMgd2hvIG93bnMgdGhlIHJlc291cmNlLCBhbmQgdGhlIHRlcm0gaXMgaW50
cm9kdWNlZCBmb3Igd2hlbiB0aGUgVXNlciBpcyBOT1QgdGhlIFJlc291cmNlIE93bmVyLg0KVGhp
cyBkaXN0aW5jdGlvbiBpcyB3aGF0IG1ha2VzIGl0IGNvbmZ1c2luZyBhcyB3ZSBhcmUgY29tcGFy
aW5nIGFuIEVudGl0eSAodGhlIFVzZXIpIHRvIGEgUm9sZSAodGhlIFJPKS4gV2UgbmVlZCB0d28g
cm9sZXMuDQoNCk9yIHdlIGNvdWxkIHRoaW5rIG9mIHRoZW0gYWxsIGFzIGVudGl0aWVzLiBUaGUg
Uk8gaXMgdGhlIGVudGl0eSB0aGF0IG93bnMgdGhlIHJlc291cmNlLiBUaGUgVXNlciBpcyB0aGUg
aHVtYW4gdGhhdCBpcyB1c2luZyB0aGUgQ2xpZW50Lg0KV2hlbiB3ZSB0aGluayBvZiB0aGVtIGFz
IGVudGl0aWVzLCB3ZSBydW4gaW50byBjb25mbGljdHMgd2hlbiBFbnRpdHktVXNlciBlcS4gRW50
aXR5LVJPLg0KV2hlbiB3ZSB0aGluayBvZiB0aGVtIGFzIHJvbGVzLCBSb2xlLVVzZXIgaXMgYWx3
YXlzICE9IFJvbGUtUk8NCg0KDQoNCkkgYWxzbyB0aGluayB0aGF0IENsaWVudCBhbmQgUmVzb3Vy
Y2UgU2VydmVyIGFyZSB3ZWxsIHVuZGVyc3Rvb2QgdGVybXMuDQpMb29rcyBsaWtlIGNvbnRyaWJ1
dG9ycyBvbiB0aGUgbGlzdCBzdGlsbCBuZWVkIGNsYXJpZmljYXRpb24gb24gdGhlICJvcmNoZXN0
cmF0aW9uIiByb2xlIG9mIGEgY2xpZW50Lg0KDQpXaGVuIEkgdGhpbmsgb2Ygb3JjaGVzdHJhdGlv
biwgSSB0aGluayBvZiBjb29yZGluYXRpbmcsIHdoaWNoIGlzIG5vdCB3aGF0IEkgdGhpbmsgdGhl
IENsaWVudCBpcyBkb2luZy4gVGhlIENsaWVudCB3YW50cyB0byBjb25zdW1lIHRoZSBDbGFpbXMg
YW5kIHRoZSBSZXNvdXJjZXMgKGNvbWJpbmVkIGFyZSBhIEdyYW50KS4gVGhlIENsaWVudCByZXF1
ZXN0cyB0aGUgR3JhbnQgZnJvbSB0aGUgR3JhbnQgU2VydmVyLiBXaGVyZSBpcyB0aGUgb3JjaGVz
dHJhdGlvbj8NCkxvb2sgYXQgdGhlIGNsaWVudC4gSXQgaXMgdGhlIGNlbnRlciBvZiBpbnRlcmFj
dGlvbiBiZXR3ZWVuIFVzZXIsIEdTIGFuZCBSUy4NCg0KDQpJdCBpcyBub3QgY2xlYXIgdG8gbWUg
d2h5IHdlIHdvdWxkIHdhbnQgdG8gcmVpbnZlbnQgdGhlc2UgdGVybXMuIFJlYWRpbmcgb3ZlciB5
b3VyIGZsb3dzLCBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byB1bmRlcnN0YW5kIHRoZSBy
ZXF1aXJlbWVudHMgeW91IGhhdmUgZm9yIHlvdXIgdXNlIGNhc2UsIG90aGVyd2lzZSBJIGZlYXIg
d2Ugd2lsbCBiZSB0YWxraW5nIHBhc3QgZWFjaCBvdGhlci4NClRoZSBvQXV0aCBmbG93IGlzIHRo
ZXJlIGFzIGEgbWVtby4gVGhlIG90aGVyIGZsb3cgaXMgd2hhdCBJIHByb3Bvc2VkIGJlZm9yZS4g
SXMgdGhlcmUgdG8gZW1waGFzaXplIHdlIG5lZWQgdG8gd29yayBvbiByb2xlcyBhbmQgbm90IG9u
IGVudGl0aWVzLiBJdCBpcyBub3QgYSBzdWdnZXN0aW9uIHRvIHJlbmFtZSB3ZWxsIGtub3duIGlk
aW9tcy4gSXQgaXMgYW4gYXR0ZW1wdCB0byBnaXZlIHRoZW0gYSBwcm9wZXIgZGVmaW5pdGlvbiBp
biB0aGUgY29udGV4dCBvZiB0aGlzIHByb3RvY29sLiBEZWZpbml0aW9uIGJhc2VkIG9uIHRoZWly
IHJvbGVzIGluIHRoZSBwcm90b2NvbCBmbG93cy4NCg0KSSdkIGxpa2UgdG8gdGFrZSBhIHN0ZXAg
YmFjayBhbmQgdW5kZXJzdGFuZCB0aGUgcmVxdWlyZW1lbnRzLiBXZSBhcmUgZGVlcCBpbnRvIHNv
bHV0aW9ucy4NCk5vLCB3ZSBhcmUgYXQgdGhlIGZ1bmRhbWVudGFsIGxldmVsLiBXZSBIYXZlIHRv
IGRlY2lkZSBvbiB3aGV0aGVyIHRvIGJ1aWxkIGEgbW9kZWwgYmFzZWQgb24gcm9sZXMgb3JvbiBl
bnRpdGllcy4uLiBUaGVuIHdlIHVzZSB0aGUgcmVzdWx0IFtFTlRJVFkgWE9SIFJPTEVTXSB0byBk
ZWZpbmUgdGhlIHVzZSBjYXNlcy4NCi9GcmFuY2lzDQoNCg0KQmVzdCByZWdhcmRzLg0KL0ZyYW5j
aXMNCg0KL0RpY2sNCg0KW2h0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1h
WkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJnR5cGU9emVyb2NvbnRlbnQmZ3VpZD03MzQx
OWIzMi1hOGUwLTQzY2QtYjkxYi05MzMwYTQzYTRjZjhd4ZCnDQoNCk9uIEZyaSwgSnVsIDI0LCAy
MDIwIGF0IDc6MjEgUE0gRnJhbmNpcyBQb3VhdGNoYSA8ZnBvQGFkb3JzeXMuZGU8bWFpbHRvOmZw
b0BhZG9yc3lzLmRlPj4gd3JvdGU6DQpCZWxvdyBteSBvcGluaW9uIG9uIHRoZSB0ZXJtIENsYWlt
Og0KDQpTdGFydGluZyB3aXRoIGlsbHVzdHJhdGlvbiBvZiBwYXJ0aWVzL3JvbGVzOg0KDQpVc2Vy
Og0KVGhpcyB3b3JkIGlzIG1pc2xlYWRpbmcgYmVjYXVzZSBvZiBpdHMgZG91YmxlIHJvbGUgaW4g
b0F1dGgyIGFuZCBPSURDIChzZWUgYmVsb3cpLiBJbiBHTkFQIGxldCB1cyBoYXZlIHRoZSBVc2Vy
IHBsYXkgb25seSB0aGUgcm9sZSBvZiBhIHJlcXVlc3Rvci4gKGZyb20gSnVzdGluIHJlZmVyZW5j
ZSB0byAiUmVxdWVzdGluZyBQYXJ0eSIpLg0KDQpDbGllbnQ6DQpUaGlzIGlzIGFsc28gdGlnaHRs
eSBib3VuZCB0byB0aGUgb0F1dGgyIGFuZCBPSURDLiBUaGUgcmVhbCBwdXJwb3NlIG9mIHRoaXMg
cm9sZSBpcyB0byBvcmNoZXN0cmF0ZSByZXNvdXJjZSBhY2Nlc3Mgb24gYmVoYWxmIG9mIHRoZSAi
UmVxdWVzdG9yIi4gTGV0IHVzIGNhbGwgdGhpcyBmb3Igbm93IHRoZSAiT3JjaGVzdHJhdG9yIg0K
DQpSZXNvdXJjZSBPd25lciAoUk8pOg0KVGhpcyBpcyBJTU8gdGhlIG1vc3QgY29ycmVjdCB3b3Jk
IGluIHRoZSBlbnRpcmUgcHJvdG9jb2wuIEF1dGhvcmlzYXRpb24gaXMgYWx3YXlzIGFib3V0IHRo
ZSBvd25lciBvZiBzb21ldGhpbmcgZ3JhbnRpbmcgYWNjZXNzIHRvIGEgcmVxdWVzdG9yLiBJdCBy
ZWFsbHkgZG9lcyBub3QgbWF0dGVyIGlmIGEgaHVtYW4gaW50ZXJhY3Rpb24gaXMgaW52b2x2ZWQu
IFdlIHdpbGwgaGF2ZSB0byBmb3JnZXQgb0F1dGgyIGFuZCBPSURDIG9mIGFsc28gY2FsbGluZyB0
aGlzIGEgVXNlci4NCg0KR3JhbnQgU2VydmVyOg0KRXZlbiB0aG91Z2ggdGhlIGRlZmluaXRpb24g
b2YgdGhlIFVzZXJJbmZvIGVuZHBvaW50IGluIE9JREMgYXMgYSBwcm90ZWN0ZWQgcmVzb3VyY2Ug
aGF6YXJkb3VzbHkgbWFrZXMgYW4gT1AgYW4gUlMsIHdlIHNoYWxsIG5vdCByZXBlYXQgdGhlIHNh
bWUgbWlzdGFrZSBoZXJlLiBXZSBuZWVkIGEgY2xlYXIgc2VwYXJhdGlvbiBiZXR3ZWVuIHJvbGVz
IG9mIEdTIGFuZCBSUyB3aXRob3V0IG92ZXJsYXBwaW5nLg0KDQpSZXNvdXJjZSBTZXJ2ZXI6IHNl
cnZpY2VzIHJlc291cmNlcy4NCg0KVW5sZXNzIEkgZ290IGl0IHdyb25nLCBHTkFQIGlzIGFib3V0
IGdyYW50IG5lZ290aWF0aW9uIGFuZCBhdXRob3JpemF0aW9uLiBUaGlzIG1lYW5zOg0KDQpHTkFQ
IGlzIGFib3V0IHNvbWUgcGFydHkgcmVxdWVzdGluZyBhY2Nlc3MgdG8gc29tZSByZXNvdXJjZXMu
DQpHTkFQIGlzIGFib3V0IHRoZSByZXNvdXJjZSBvd25lciBjb25zZW50aW5nIGFjY2VzcyB0byB0
aGF0IHJlc291cmNlLg0KR05BUCBpcyBhYm91dCBkZWZpbmluZyB0aGUgaW5mcmFzdHJ1Y3R1cmUg
dGhhdCBhbGxvd3MgdGhlIHJlcXVlc3RpbmcgcGFydHkgdG8gYWNjZXNzIGEgcmVzb3VyY2UuDQoN
CkdOQVAgZGVzaWducyB0aGlzIGluZnJhc3RydWN0dXJlIGFyb3VuZDoNCi0gYW4gb3JjaGVzdHJh
dG9yICh3aGF0IHdlIHJlZmVyIHRvIGFzIGEgY2xpZW50KQ0KLSBhbiBncmFudCBtYW5hZ2VyICh3
aGF0IHdlIHJlZmVyIHRvIGFzIGEgR1MvQVMpDQotIHRoZSBjdXN0b2RpYW4gb2YgdGhlIHJlc291
cmNlICh3aGF0IHdlIGNhbGwgYSBSUykNCg0KQXMgeW91IHNlZToNCi0gVGhlIHdvcmQgVXNlciBk
b2VzIG5vdCBhcHBlYXIgaGVyZSwgYW5kIGlzIG5vdCByZWxldmFudCBhcyB0aGUgZm9jdXMgaXMg
b24gYXV0aG9yaXppbmcgYWNjZXNzIHRvIGEgcmVzb3VyY2UuDQotIFRoZSB3b3JkIENsYWltIGlz
IGFzIHdlbGwgYWJzZW50Lg0KDQpDbGFpbSByZWxhdGVkIHRvIFJPOg0KVGhlIHdvcmQgQ2xhaW0g
bWlnaHQgc3RhcnQgZ2V0dGluZyB2aXNpYmxlIGlmIHRoZSBvcmNoZXN0cmF0b3IgKGEuay5hLiBD
bGllbnQpIG9yIHRoZSBjdXN0b2RpYW4gKGEuay5hIFJTKSBuZWVkcyBzb21lIGFkZGl0aW9uYWwg
aW5mb3JtYXRpb24gb24gdGhlIFJPIHRvIHByb2NlZWQgd2l0aCB0aGUgYWNjZXNzIGNvbnRyb2wg
ZGVjaXNpb24uIFRoZXNlIGNsYWltcyByZWZlciB0byBhc3NlcnRpb25zIG9mIGF0dHJpYnV0ZXMg
b3IgcHJvcGVydGllcyBvZiB0aGUgUk8uIFRoZXNlIGNsYWltcyBhcmUgaXNzdWVkIGJ5IHRoZSBH
UyBhcyB0aGUgR1MgbWFuYWdlcyBpbnRlcmFjdGlvbiB3aXRoIHRoZSBSTyAoc2VlIGJlbG93KS4g
SW4gdGhpcyBmaXJzdCBwbGFjZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgcmVxdWVzdGluZyBwYXJ0
eSAoZXJyb25lb3VzbHkuay5hLiBVc2VyKSBpcyBub3QgcmVsZXZhbnQgdG8gdGhlIG5lZ290aWF0
aW9uIGFuZCBwcm92aXNpb25pbmcgZnJhbWV3b3JrLiBMZXQgdXMgY2FsbCB0aGlzIHNvcnQgb2Yg
Y2xhaW0gIlJPLUF0dHJpYnV0ZXMiLiBBIGJldHRlciBuYW1lIGlzIHdlbGNvbWUuDQoNClNvbWUg
YWR2YW5jZWQgcmVzb3VyY2UgcHJvdmlzaW9uaW5nIGZyYW1ld29ya3MgbWlnaHQgcmVxdWlyZSBr
bm93bGVkZ2Ugb24gYXR0cmlidXRlcyBvZiB0aGUgcmVxdWVzdGluZyBwYXJ0eSAoZS5rLmEgVXNl
cikuIFRoZXNlIGF0dHJpYnV0ZXMgc2hhbGwgYmUgY29sbGVjdGVkIGJ5IHRoZSBvcmNoZXN0cmF0
b3IgKGEuay5hIENsaWVudCkgYW5kIGFkZGVkIHRvIHRoZSByZXNvdXJjZSByZXF1ZXN0LiBUaGVy
ZSBpcyBubyB3YXkgdGhlIEdTIGNhbiBjb2xsZWN0IHRoZXNlIGF0dHJpYnV0ZXMgYXMgdGhlIEdT
IHJvbGUgaGFzIG5vIGludGVyYWN0aW9uIHdpdGggdGhlIHJlcXVlc3RpbmcgcGFydHkgKGUuay5h
IFVzZXIpLiBMZXQgdXMgY2FsbCB0aGlzIHNvcnQgb2YgY2xhaW0gIlJlcXVlc3Rvci1BdHRyaWJ1
dGVzIi4gQSBiZXR0ZXIgbmFtZSB3aWxsIGJlIHdlbGNvbWUuDQoNClNvbWUgYXNzZXJ0aW9ucyBh
cmUgZXZlbiByZWxhdGVkIHRvIHRoZSBvcmNoZXN0cmF0b3IgKGEuay5hIENsaWVudCkgaXRzZWxm
LiBUaGlzIGlzIHRoZSBjYXNlIG9mIHRoZSBwdWJsaWMga2V5IG9mIGFuIG9yY2hlc3RyYXRvciB1
c2VkIGJ5IHRoZSBHUyB0byAic2VuZGVyIGNvbnN0cmFpbiIgYW4gYWNjZXNzIHRva2VuLiBMZXQg
dXMgY2FsbCB0aGlzIHR5cGUgb2YgY2xhaW0gIk9yY2hlc3RyYXRvci1BdHRyaWJ1dGVzIi4NCg0K
VGhpcyBpcyBhIHNhbXBsZSBtYXBwaW5nIG9mIE9JREMuDQoNCistLS0tKyAgICArLS0tKyAgICst
LS0rICArLS0tKw0KfFVzZXJ8ICAgIHxSUCB8ICAgfE9QIHwgIHxSUyB8DQorLS0tLSsgICAgKy0t
LSsgICArLSstKyAgKy0tLSsNCiAgfCgxKSBTZXJ2aWNlUmVxdWVzdCAgICAgIHwNCiAgfC0tLS0t
LS0tPnwgICAgICAgfCAgICAgIHwNCiAgfCgyKSByZWRpcmVjdCAgICAgfCAgICAgIHwNCiAgfDwt
LS0tLS0tLXwgICAgICAgfCAgICAgIHwNCj09PSBVc2VyIChyZXF1ZXN0b3IpIHBhc3NlcyBjb250
cm9sIHRvIFVzZXIgKFJPKSA9PT0NCiAgfCgzKSBBdXRoICsgQ29uc2VudCAgICAgIHwNCiAgfC0t
LS0tLS0tLS0tLS0tLS0+fCAgICAgIHwNCiAgfCg0KSByZWRpcmVjdCAoY29kZSkgICAgIHwNCiAg
fDwtLS0tLS0tLS0tLS0tLS0tfCAgICAgIHwNCj09PSBVc2VyIChSTykgcGFzc2VzIGNvbnRyb2wg
YmFjayB0byBVc2VyIChyZXF1ZXN0b3IpID09PQ0KICB8KDUpIGdldChjb2RlKSAgICB8ICAgICAg
fA0KICB8LS0tLS0tLS0+fCAgICAgICB8ICAgICAgfA0KICB8ICAgICAgICAgfCg2KSB0b2tlbiAo
Y29kZSkNCiAgfCAgICAgICAgIHwtLS0tLS0+fCAgICAgIHwNCiAgfCAgICAgICAgIHwoNykgdG9r
ZW4gICAgIHwNCiAgfCAgICAgICAgIHw8LS0tLS0tfCAgICAgIHwNCiAgfCAgICAgICAgIHwoOCkg
U2VydmljZVJlcXVlc3QodG9rZW4pDQogIHwgICAgICAgICB8LS0tLS0tLS0tLS0tLT58DQogIHwg
ICAgICAgICB8KDkpIFNlcnZpY2VSZXNwb25zZQ0KICB8ICAgICAgICAgfDwtLS0tLS0tLS0tLS0t
fA0KICB8KDEwKSBTZXJ2aWNlUmVzcG9uc2UgICAgfA0KICB8PC0tLS0tLS0tfCAgICAgICB8ICAg
ICAgfA0KICArICAgICAgICAgKyAgICAgICArICAgICAgKw0KDQotIFJQIG9yY2hlc3RyYXRlcyBp
bnRlcmFjdGlvbiBiZXR3ZWVuIFVzZXIgYW5kIE9QIHRvIGVuYWJsZSB0aGUgdXNlciB0byBvYnRh
aW4gdGhlIHByb3RlY3RlZCByZXNvdXJjZS4NCi0gSW4gc3RlcCAxICYgMTAgVXNlciBwbGF5cyB0
aGUgcm9sZSBvZiB0aGUgcmVxdWVzdG9yIG9mIHRoZSByZXNvdXJjZS4NCi0gSW4gc3RlcCAyIFVz
ZXItQnJvd3NlciBpcyB1c2VkIHRvIHBhc3MgY29udHJvbCBmcm9tIFVzZXIgKGluIGhpcyByb2xl
IGFzIHRoZSByZXF1ZXN0b3IpIHRvIFVzZXIgKGluIGhpcyByb2xlIGFzIHRoZSBSTykNCi0gSW4g
c3RlcCA0IFVzZXItQnJvd3NlciBpcyB1c2VkIHRvIHBhc3MgY29udHJvbCBmcm9tIFVzZXIgKGlu
IGhpcyByb2xlIGFzIHRoZSBSTykgYmFjayB0byBVc2VyIChpbiBoaXMgcm9sZSBhcyB0aGUgcmVx
dWVzdG9yKQ0KDQpXaGVuIHdlIGFyZSB0YWxraW5nIGNsYWltcyBoZXJlLCB3ZSBhcmUgdGFsa2lu
ZyBjbGFpbXMgb24gdGhlIFVzZXIgKGluIGhpcyByb2xlIGFzIHRoZSBSTykuIFRoZSBPUCBkb2Vz
IG5vdCBoYXZlIGFueSBpbnRlcmFjdGlvbiB3aXRoIHRoZSBVc2VyIChpbiBoaXMgcm9sZSBhcyB0
aGUgcmVxdWVzdG9yKS4gSW4gdGhlIGNhc2Ugb2YgYW4gQXBwMkFwcCByZWRpcmVjdGlvbiwgdGhl
IE9QIGNhbiBub3QgZXZlbiBhc3NlcnQgYWJvdXQgdGhlIHVzZXIgYWdlbnQgb2YgdGhlIFVzZXIg
KHJlcXVlc3RvcikuDQoNCklmIHRoZXJlIGlzIGFueSBjbGFpbSB0aGUgT1AgY2FuIHByb3ZpZGUs
IGl0IGlzIGEgY2xhaW0gb24gdGhlIFVzZXIgKFJPKS4NCg0KSSBob3BlIHRoaXMgZXhhbXBsZSBj
bGFyaWZpZXMgdGhlIG1pc3VuZGVyc3RhbmRpbmcuIEFueSBhdHRlbXB0IG9mIGJyaW5naW5nIHRo
aXMgZG91YmxlIHJvbGUgb2YgdGhlIFVzZXIgaW50byBHTkFQIHdpbGwgYWxzbyBicmluZyB0aGlz
IGNvbmZ1c2lvbi4gSW4gb3JkZXIgdG8ga2VlcCB0aGlzIG91dCBvZiBHTkFQIGxldCB1cyBsb29r
IGZvciB0aGUgcmlnaHQgdGVybSBmb3IgVXNlciAoYXMgYSByZXF1ZXN0b3IpIHVzaW5nIHRoZSBk
aWFncmFtIGRpc3BsYXllZCBiZWxvdy4NCg0KKy0tLS0rICArLS0tLS0tKyAgKy0tLSsgICstLS0r
ICArLS0tKw0KfFJlcXN8ICB8T3JjaHN0fCAgfFJTIHwgIHxHUyB8ICB8Uk8gfA0KKy0tLS0rICAr
LS0tLS0tKyAgKy0tLSsgICstKy0rICArLSstKw0KICB8KDEpIFNlcnZpY2VSZXF1ZXN0ICAgICAg
fCAgICAgIHwNCiAgfC0tLS0tLS0tPnwgICAgICAgfCAgICAgIHwgICAgICB8DQogIHwgICAgICAg
ICB8KDIpIFNlcnZpY2VJbnRlbnQ6QXV0aFpDaGFsbGVuZ2UNCiAgfCAgICAgICAgIHw8LS0tLS0+
fCAgICAgIHwgICAgICB8DQogIHwgICAgICAgICB8ICAgICAgIHwgICAgICB8ICAgICAgfA0KICB8
ICAgICAgICAgfCgzKSBBdXRoWlJlcXVlc3QoQXV0aFpDaGFsbGVuZ2UpDQogIHwgICAgICAgICB8
LS0tLS0tLS0tLS0tLT58ICAgICAgfA0KICB8ICAgICAgICAgfCAgICAgICB8ICAgICAgfCg0KSBD
b25zZW50UmVxdWVzdDpHcmFudA0KICB8ICAgICAgICAgfCAgICAgICB8ICAgICAgfDwtLS0tPnwN
CiAgfCAgICAgICAgIHwoNSkgR3JhbnRBY2Nlc3MoQXV0aFopDQogIHwgICAgICAgICB8PC0tLS0t
LS0tLS0tLS18ICAgICAgfA0KICB8ICAgICAgICAgfCAgICAgICB8ICAgICAgfCAgICAgIHwNCiAg
fCAgICAgICAgIHwoNikgU2VydmljZVJlcXVlc3QoQXV0aFopOlNlcnZpY2VSZXNwb25zZQ0KICB8
ICAgICAgICAgfDwtLS0tLT58ICAgICAgfCAgICAgIHwNCiAgfCg3KSBTZXJ2aWNlUmVzcG9uc2Ug
ICAgIHwgICAgICB8DQogIHw8LS0tLS0tLS18ICAgICAgIHwgICAgICB8ICAgICAgfA0KICArICAg
ICAgICAgKyAgICAgICArICAgICAgKyAgICAgICsNCg0KLSBSZXBsYWNpbmcgdGhlIHdvcmQgVXNl
ciBoZWxwcyBjbGFyaWZ5IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYm90aCByb2xlcyAiUmVxdWVz
dG9yIiBhbmQgIlJlc291cmNlIE93bmVyIg0KLSBSZW5hbWluZyBjbGFpbSBieSBhdHRhY2hpbmcg
dGhlIE9iamVjdC90YXJnZXQgb2YgdGhlIGNsYWltIChlLmcuOiBSTy1hdHRyaWJ1dGVzLCBSZXF1
ZXN0b3ItQXR0cmlidXRlcywgT3JjaGVzdHJhdG9yLUF0dHJpYnV0ZXMpIGFsc28gaGVscHMgaWRl
bnRpZnkgdGhlIHNvdXJjZSBvZiB0aG9zZSBhdHRyaWJ1dGVzIChHUywgUlMsIENsaWVudCk6DQoN
CkJlc3QgcmVnYXJkcy4NCi9GcmFuY2lzDQoNCk9uIEZyaSwgSnVsIDI0LCAyMDIwIGF0IDQ6NTgg
UE0gRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21h
aWwuY29tPj4gd3JvdGU6DQpJdCBpcyBub3QgY2xlYXIgdG8gbWUgd2hhdCBpdCBtYXR0ZXJzIGlm
IGEgQ2xhaW0gY29tZXMgZnJvbSBhbiBSUywgb3IgZnJvbSB0aGUgR1MsIHNvIEkgZG9uJ3Qgc2Vl
IGEgbmVlZCB0byBkaWZmZXJlbnRpYXRlIHRoZW0uDQoNCkkgd291bGQgaW5jbHVkZSB2ZXJpZmlh
YmxlIGNyZWRlbnRpYWxzIGFuZCB1c2VyLWJvdW5kIGtleXMgYXMgQ2xhaW1zLg0KDQpBbGwgdGhl
IHBheW1lbnQgcHJvY2Vzc2luZyBpbmZvcm1hdGlvbiBJIGhhdmUgc2VlbiBoYXMgYmVlbiBpbiBS
QVIuIFdoZW4gd291bGQgdGhlIENsaWVudCBnZXQgcGF5bWVudCBwcm9jZXNzaW5nIGRpcmVjdGx5
IGZyb20gdGhlIEdTPw0KDQpXaGF0IGlzIHlvdXIgZXhhbXBsZSBmb3IgZGlzdHJpYnV0ZWQgbmV0
d29ya3Mgc3RvcmFnZSBsb2NhdGlvbnM/IElmIHdoYXQgaXMgc3RvcmVkIGlzIGEgc3RhdGVtZW50
IGFib3V0IHRoZSB1c2VyLCB0aGVuIEkgd291bGQgY29uc2lkZXIgdGhhdCBhIENsYWltIGFzIHdl
bGwuDQoNCldlIGRpc2FncmVlIG9uIGhvdyB0byBtYXAgT0lEQyB0byBHTkFQLiAgVGhlIGRpcmVj
dCBkYXRhIGlzIGEgY2xhaW1zIHJlcXVlc3QsIHRoZSBkYXRhIGNvbWluZyBpbmRpcmVjdGx5IGlz
IGFuIGFjY2VzcyB0b2tlbiByZXF1ZXN0Lg0KDQoNCg0KT24gRnJpLCBKdWwgMjQsIDIwMjAgYXQg
MTozOSBQTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0
LmVkdT4+IHdyb3RlOg0KU2luY2Ugd2XigJlyZSBhbHJlYWR5IHRhbGtpbmcgYWJvdXQgcmV0dXJu
aW5nIGNsYWltcyBhcyBkaXJlY3QgZGF0YSBhcyB3ZWxsIGFzIGEgcGFydCBvZiB0aGUgcmVzb3Vy
Y2UgQVBJIGJlaW5nIHByb3RlY3RlZCwgc28gd2UgYWxyZWFkeSBuZWVkIGEgd2F5IHRvIGRpZmZl
cmVudGlhdGUgdGhlIHR3byBraW5kcyBvZiBpdGVtcy4gSnVzdCBjYWxsaW5nIGl0IOKAnGNsYWlt
c+KAnSBkb2VzbuKAmXQgaGVscCwgYmVjYXVzZSBhcyB5b3XigJl2ZSBwb2ludGVkIG91dCB0aGV5
IGNvdWxkIHNob3cgdXAgaW4gYm90aCBwbGFjZXMuIFNvIHllcywgZGVmaW5pbmcgdGhhdCBkaWZm
ZXJlbmNlIGlzIHNvbWV0aGluZyB3ZSBzaG91bGQgd29ycnkgYWJvdXQgbm93LCBldmVuIGlmIHRo
ZSBjb3JlIHByb3RvY29sIG9ubHkgdXNlcyBpdCBmb3IgY2xhaW1zLg0KDQpUaGUgdHdvIGZvcm1z
IG9mIGRpcmVjdCBkYXRhIHRoYXQgWFlaIHJldHVybnMgYXJlIHN1YmplY3QgaWRlbnRpZmllcnMg
KGEgc3Vic2V0IG9mIGlkZW50aXR5IGNsYWltcykgYW5kIGFzc2VydGlvbnMg4oCUIHRoZSBsYXR0
ZXIgYmVpbmcgYSBjb250YWluZXIgbm90IGp1c3QgZm9yIGlkZW50aXR5IGNsYWltcyBidXQgYWxz
byBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlvbiBhbmQgb3RoZXIgZWxlbWVudHMuIEFzc2VydGlv
bnMgYXJlIG5vdCBjbGFpbXMgdGhlbXNlbHZlcy4NCg0KT3RoZXIgdXNlIGNhc2VzIHRoYXQgaGF2
ZSBiZWVuIGJyb3VnaHQgdXAgaW5jbHVkZSB2ZXJpZmlhYmxlIGNyZWRlbnRpYWxzIGFuZCBwcm9v
ZnMsIHVzZXItYm91bmQga2V5cywgcGF5bWVudCBwcm9jZXNzaW5nIGluZm9ybWF0aW9uLCBhbmQg
ZGlzdHJpYnV0ZWQgbmV0d29yayBzdG9yYWdlIGxvY2F0aW9ucy4gSeKAmW0gc3VyZSB0aGVyZSBh
cmUgYSBsb3QgbW9yZS4gVG8gbWUsIHRoZXNlIGFyZSBzdWJzZXRzIG9mIHRoZSDigJxkaXJlY3Qg
ZGF0YeKAnSBidXQgbm90IHN1YnNldHMgb2Yg4oCcY2xhaW1z4oCdLiBHTkFQIHNob3VsZG7igJl0
IGJlIGRlZmluaW5nIHdoYXQgYWxsIG9mIHRoZXNlIGxvb2sgbGlrZSwgYnV0IGl0IHNob3VsZCBk
ZWZpbmUgYSB3YXkgdG8gdGFsayBhYm91dCB0aGVtLg0KDQpJIHRoaW5rIGRpZmZlcmVudCB0b3At
bGV2ZWwgcmVxdWVzdCBvYmplY3RzIGFyZSBiZXR0ZXIgc3VpdGVkIGZvciBkaWZmZXJlbnQgcXVl
cnkgc2VtYW50aWNzLiBMaWtlLCBmb3IgZXhhbXBsZSwgdGhlIE9JREMg4oCcY2xhaW1z4oCdIHJl
cXVlc3QsIHdoaWNoIGFsbG93cyB0YXJnZXRpbmcgb2YgaXRzIGNsYWltcyBpbmZvcm1hdGlvbiBp
bnRvIGRpZmZlcmVudCByZXR1cm4gYnVja2V0cy4gVGhpcyBvdmVybGFwcyB3aXRoIHRoZSDigJxy
ZXNvdXJjZXPigJ0gcmVxdWVzdCBhdCB0aGUgdmVyeSBsZWFzdC4gSSBkb27igJl0IHRoaW5rIEdO
QVAgc2hvdWxkIGRlZmluZSBob3cgdG8gZG8gdGhpcyBzcGVjaWZpYyBjb21iaW5hdGlvbiwgdGhh
dCBzaG91bGQgYmUgZm9yIE9JREYgdG8gZGViYXRlIGFuZCBhcHBseS4gVGhlIHNhbWUgd2l0aCBh
IERJRCBzZXJ2aWNlIGJhc2VkIHF1ZXJ5LCBvciBQcmVzZW50YXRpb24gRXhjaGFuZ2UgWzFdLCBv
ciBhbnl0aGluZyBlbHNlIHRoYXQgcGVvcGxlIHdhbnQgdG8gY29tZSB1cCB3aXRoLg0KDQpJbiBt
eSB2aWV3LCBHTkFQIHNob3VsZCBkZWZpbmUgcXVlcnkgc3RydWN0dXJlcyBmb3IgdHdvIHRoaW5n
czogcmlnaHRzIHRoYXQgZ2V0IHRpZWQgdG8gYW4gYWNjZXNzIHRva2VuIGFuZCBkYXRhIHRoYXQg
Y29tZXMgYmFjayBkaXJlY3RseSB0byB0aGUgY2xpZW50LiBGb3IgdGhlIGxhdHRlciwgSSB0aGlu
ayB3ZSBjYW4gZG8gc29tZSB2ZXJ5IGxpbWl0ZWQgYW5kIHZlcnkgdXNlZnVsIHNwZWNpZmljIGl0
ZW1zLCB3aGljaCBpcyB3aGF0IEnigJl2ZSBwdXQgaW50byBYWVouDQoNCiDigJQgSnVzdGluDQoN
ClsxXSBodHRwczovL2lkZW50aXR5LmZvdW5kYXRpb24vcHJlc2VudGF0aW9uLWV4Y2hhbmdlLw0K
DQoNCk9uIEp1bCAyNCwgMjAyMCwgYXQgMzo1OCBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBn
bWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQoNCkkgYWdyZWUg
d2Ugd2FudCBHTkFQIHRvIGJlIGEgc3Ryb25nIGZvdW5kYXRpb24uDQoNCkRvIHlvdSBoYXZlIGFu
IGV4YW1wbGUgb2Ygb3RoZXIgImRpcmVjdCBkYXRhIj8gSWYgc28sIGRvIHlvdSBleHBlY3QgaXQg
dG8gYmUgZGVmaW5lZCBpbiB0aGUgY29yZSBwcm90b2NvbD8NCg0KSSB3b3VsZCBleHBlY3QgYW4g
ZXh0ZW5zaW9uIGZvciBvdGhlciAiZGlyZWN0IGRhdGEiIHRvIGRlZmluZSB0b3AgbGV2ZWwgb2Jq
ZWN0cywgYW5kIGFuIGFwcHJvcHJpYXRlIGRlZmluaXRpb24gZm9yIHRoYXQgImRpcmVjdCBkYXRh
Ii4NCg0KTXkgImRvIHdlIG5lZWQgdG8gd29ycnkgYWJvdXQgaXQgbm93IiBjb21tZW50IHdhcyBv
biBjcmVhdGluZyBhIGdlbmVyaWMgdGVybSBmb3IgImRpcmVjdCBkYXRhIi4gVW5sZXNzIHdlIGFy
ZSBzb2x2aW5nIHRob3NlIG5vdywgd2UgY2FuIGxldCBmdXJ0aGVyIHdvcmsgZGVmaW5lIHRoYXQg
ImRpcmVjdCBkYXRhIiBleHBsaWNpdGx5Lg0KDQoNCg0KDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFw
cHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16
ZXJvY29udGVudCZndWlkPWU0ZGYyM2JlLTE3MjAtNGI4NS05Yzk3LWExNzU3OTFlZjgzY13hkKcN
Cg0KT24gRnJpLCBKdWwgMjQsIDIwMjAgYXQgMTI6NDIgUE0gSnVzdGluIFJpY2hlciA8anJpY2hl
ckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNClllcywgSSBkbyB0aGlu
ayB3ZSBuZWVkIHRvIHdvcnJ5IGFib3V0IGl0IHRvIHRoZSBleHRlbnQgdGhhdCB3ZSBhcmUgbm90
IGNyZWF0aW5nIHNvbWV0aGluZyB0aGF0IGlzIG92ZXItZml0IHRvIGEgbGltaXRlZCBzZXQgb2Yg
dXNlIGNhc2VzLg0KDQpHTkFQIHNob3VsZCBiZSBhIGZvdW5kYXRpb24gdGhhdCBtYW55IGFtYXpp
bmcgbmV3IHRoaW5ncyBjYW4gYmUgYnVpbHQgb24gdG9wIG9mLg0KDQog4oCUIEp1c3Rpbg0KDQoN
Ck9uIEp1bCAyNCwgMjAyMCwgYXQgMzowNiBQTSwgRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFp
bC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4gd3JvdGU6DQoNCkp1c3RpbiwgdGhh
bmtzIGZvciBjbGFyaWZ5aW5nLg0KDQpXaGF0IGFyZSBzb21lIGV4YW1wbGVzIG9mIG90aGVyICJk
aXJlY3QgZGF0YSIgdGhhdCB0aGUgR1MgbWF5IHJldHVybj8gSWYgaXQgaXMgbm90IGluIGNvcmUg
R05BUCwgZG8gd2UgbmVlZCB0byB3b3JyeSBhYm91dCBub3c/IFdlIGNhbiB0aGVuIGdpdmUgdGhl
IGRpcmVjdCBkYXRhIGZyb20gdGhlIEdTIHRoYXQgaXMgbm90IGEgY2xhaW0sIGFuIGFwcHJvcHJp
YXRlIG5hbWUgaW4gdGhhdCBkb2N1bWVudC4NCg0KDQoNCk9uIEZyaSwgSnVsIDI0LCAyMDIwIGF0
IDExOjQ2IEFNIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBt
aXQuZWR1Pj4gd3JvdGU6DQpEaWNrOiBObywgSSB0aGluayB5b3XigJlyZSBtaXN1bmRlcnN0YW5k
aW5nIHdoYXQgSeKAmW0gc2F5aW5nLiBJIGFncmVlIHRoYXQg4oCcY2xhaW1z4oCdIGFyZSBhYm91
dCB0aGUgdXNlciwgaW4gdGhpcyBjb250ZXh0Ki4gQnV0IHRoZSBBUyBjb3VsZCByZXR1cm4gb3Ro
ZXIgZGF0YSBkaXJlY3RseSB0byB0aGUgY2xpZW50IHRoYXQgaXNu4oCZdCBhYm91dCB0aGUgdXNl
ci4gVGhvc2UgYXJlbuKAmXQg4oCcY2xhaW1z4oCdIGJ5IHRoZSBjbGFzc2ljYWwgZGVmaW5pdGlv
bi4gQWxzbyBzaW5jZSDigJxjbGFpbXPigJ0gY2FuIGNvbWUgYmFjayBmcm9tIHBsYWNlcyBvdGhl
ciB0aGFuIGRpcmVjdGx5LCB0aGVuIHdlIHNob3VsZG7igJl0IGNhbGwgZXZlcnl0aGluZyB0aGF0
IGNvbWVzIGJhY2sgYSDigJxjbGFpbeKAnS4NCg0KSeKAmW0gYXJndWluZyB0aGF0IHdlIGtlZXAg
4oCcY2xhaW1z4oCdIHRvIG1lYW4gd2hhdCBpdCBhbHJlYWR5IG1lYW5zIGFuZCBjb21lIHVwIHdp
dGggYSBuZXcgd29yZCB0byBtZWFuIOKAnHRoaW5ncyB0aGF0IGNvbWUgYmFjayBkaXJlY3RseSBm
cm9tIHRoZSBBU+KAnS4gVGhlc2UgYXJlbuKAmXQgbWVhbnQgdG8gcmVwbGFjZSBGcmFuY2lz4oCZ
cyBtb3JlIGNvbXBsZXRlIGRlZmluaXRpb25zLCBidXQgdG8gc2ltcGxpZnk6DQoNCkNsYWltczoN
Ci0gaW5mb3JtYXRpb24gYWJvdXQgdGhlIHVzZXINCi0gY2FuIGNvbWUgYmFjayBkaXJlY3RseSBm
cm9tIHRoZSBBUw0KLSBjYW4gY29tZSBiYWNrIGluIGEgcmVzb3VyY2UgZnJvbSB0aGUgUlMNCg0K
UmVzb3VyY2U6DQotIFJldHVybmVkIGZyb20gYW4gUlMNCi0gUHJvdGVjdGVkIGJ5IGFjY2VzcyB0
b2tlbg0KLSBDb3VsZCBjb250YWluIGNsYWltcyBhYm91dCB0aGUgdXNlcg0KDQpEaXJlY3QgZGF0
YSAob3Igc29tZSBiZXR0ZXIgbmFtZSk6DQotIFJldHVybmVkIGRpcmVjdGx5IGZyb20gQVMNCi0g
Q291bGQgY29udGFpbiBjbGFpbXMgYWJvdXQgdGhlIHVzZXINCg0KSSB0aGluayB0aGUgcHJvYmxl
bSBpcyB0aGF0IHNvbWUgcGVvcGxlIGFyZSB1c2luZyDigJxjbGFpbXPigJ0gdG8gbWVhbiAjMSBh
bmQgc29tZSB0byBtZWFuICMzLiBJdOKAmXMgY2xlYXJseSAjMSBpbiBPSURDLiBCdXQ6IEl04oCZ
cyBpbXBvcnRhbnQgdG8gcmVtZW1iZXIsIHdoZW4gdGFsa2luZyBhYm91dCBPSURDLCB0aGF0IGFu
IElkUCBpbiBPSURDIGNvbWJpbmVzIGFuIEFTIGFuZCBhbiBSUyBpbnRvIG9uZSBlbnRpdHkgZm9y
IGlkZW50aXR5IGluZm9ybWF0aW9uLiBUaGVyZSBjYW4gYmUgb3RoZXIgUlPigJlzIGFzIHdlbGws
IGFuZCB0aGVyZSB1c3VhbGx5IGFyZSBpbiB0aGUgd2lsZCwgYnV0IHRoZSBvbmUgZGVmaW5lZCBi
eSBPSURDIGlzIHRoZSBVc2VySW5mbyBFbmRwb2ludC4gVGhlIGZhY3QgdGhhdCBpdCByZXR1cm5z
IHVzZXIgZGF0YSBkb2VzbuKAmXQgbWFrZSBpdCBhbnkgbGVzcyBvZiBhbiBSUy4NCg0KIOKAlCBK
dXN0aW4NCg0KKiBJbiB0aGUgd2lkZXIgY29udGV4dCBvZiB0aGluZ3MgbGlrZSB0aGUgaW5mb3Jt
YXRpb24gY2xhaW1zIGluc2lkZSBhIEpXVCwgdGhlIGNsYWltcyBjb3VsZCBiZSBhYm91dCBsaXRl
cmFsbHkgYW55dGhpbmcsIGJ1dCB0aGF04oCZcyBub3Qgd2hhdCB3ZeKAmXJlIGRpc2N1c3Npbmcg
aGVyZSBhbmQgaXTigJlzIG5vdCBob3cgaXTigJlzIGJlaW5nIHVzZWQuDQoNCg0KDQpPbiBKdWwg
MjQsIDIwMjAsIGF0IDE6MjQgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1h
aWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpJbiBPcGVuSUQgQ29ubmVjdCAo
T0lEQyksIHRoZSBDbGllbnQgY2FuIG9idGFpbiBDbGFpbXMgZGlyZWN0bHkgZnJvbSB0aGUgT1Ag
aW4gYW4gSUQgVG9rZW4sIG9yIHRoZSBDbGllbnQgY2FuIG9idGFpbiBDbGFpbXMgdXNpbmcgYW4g
YWNjZXNzIHRva2VuIHRvIGNhbGwgdGhlIFVzZXJJbmZvIGVuZHBvaW50LCBhIFByb3RlY3RlZCBS
ZXNvdXJjZVsxXS4NCg0KVGhlIENsYWltcyBhcmUgYWJvdXQgdGhlIFVzZXIgKG5vdCBhIFJPKS4N
Cg0KSW4gWEF1dGgsIEknbSBwcm9wb3NpbmcgdGhlIENsaWVudCBtYXkgb2J0YWluIGJhcmUgY2xh
aW1zIGZyb20gdGhlIEdTIGRpcmVjdGx5IGluIGFkZGl0aW9uIHRvIHRoZSBtZWNoYW5pc21zIGlu
IE9ESUMuDQoNClNvIEkgZG9uJ3QgdGhpbmsgd2UgYXJlIGNoYW5naW5nIHRoZSBkZWZpbml0aW9u
IG9mIENsYWltIGZyb20gaG93IGl0IGhhcyBiZWVuIHVzZWQgaW4gT0lEQywgYW5kIEkgZmFpbCB0
byBzZWUgYW55IHJlYXNvbiB0byBOT1QgdXNlIENsYWltLg0KDQpKdXN0aW46IHlvdSBhbGx1ZGUg
dG8gQ2xhaW1zIGJlaW5nIGFib3V0IGEgcGFydHkgb3RoZXIgdGhhbiB0aGUgVXNlci4gV291bGQg
eW91IHByb3ZpZGUgYW4gZXhhbXBsZT8NCg0KL0RpY2sNCg0KWzFdDQpVc2VySW5mbyBFbmRwb2lu
dA0KUHJvdGVjdGVkIFJlc291cmNlIHRoYXQsIHdoZW4gcHJlc2VudGVkIHdpdGggYW4gQWNjZXNz
IFRva2VuIGJ5IHRoZSBDbGllbnQsIHJldHVybnMgYXV0aG9yaXplZCBpbmZvcm1hdGlvbiBhYm91
dCB0aGUgRW5kLVVzZXIgcmVwcmVzZW50ZWQgYnkgdGhlIGNvcnJlc3BvbmRpbmcgQXV0aG9yaXph
dGlvbiBHcmFudC4gVGhlIFVzZXJJbmZvIEVuZHBvaW50IFVSTCBNVVNUIHVzZSB0aGUgaHR0cHMg
c2NoZW1lIGFuZCBNQVkgY29udGFpbiBwb3J0LCBwYXRoLCBhbmQgcXVlcnkgcGFyYW1ldGVyIGNv
bXBvbmVudHMuDQoNCg0KDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVy
PWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPTQy
M2FmNzZiLTQwZjUtNGJhYi1hYzU5LTJiNjQwOTQ0ZTVjZF3hkKcNCg0KT24gRnJpLCBKdWwgMjQs
IDIwMjAgYXQgNTo1OCBBTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpy
aWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KSSB3YW50IHRvIGZvY3VzIG9uIG9uZSBhc3BlY3QgaGVy
ZToNCg0KDQpBIENsYWltIGlzIGEgd2VsbCB1bmRlcnN0b29kIHRlcm0gaW4gdGhlIGZpZWxkLiBX
ZSBzaG91bGQgdXNlIGl0LiBJdCBpcyBzdGlsbCBhIENsYWltIGlmIGl0IGNvbWVzIGRpcmVjdGx5
IGZyb20gdGhlIEdTIG9yIGZyb20gYW4gUlMuDQpJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSBhIFJl
c291cmNlIHJlbGVhc2UgYnkgYW4gUlMgc2hhbGwgYmUgaCB0byBhcyBhIGNsYWltLCBldmVuIGlm
IHRoZSBjb250ZW50IG9mIHRoZSBSZXNvdXJjZSBpcyBhbiBhc3NlcnRpb24uIEl0IHdpbGwgbGVh
ZCB0byBjb25mdXNpb24uIElmIHdlIGxpbWl0IGNsYWltcyB0byBpbmZvcm1hdGlvbiBHUyByZWxl
YXNlcyBpbnRvIFRva2VuLCBVc2VyIEluZm8sIGFuZCBvdGhlciBvYmplY3RzIGl0IHJldHVybnMs
IHRoaXMgd2lsbCBoZWxwIHNlcGFyYXRlIHJlc3BvbnNpYmlsaXRpZXMgYmV0d2VlbiBHUyBhbmQg
UlMuIEFzIHNvb24gYXMgUlMgc2VydmljZXMgYW5kIGluZm9ybWF0aW9uLCB0aGlzIGlzIGNhbGxl
ZCBhIFJlc291cmNlLCBubyBtYXR0ZXIgdGhlIG5hdHVyZSBvZiB0aGUgY29udGVudCBvZiB0aGF0
IGluZm9ybWF0aW9uLg0KDQpUaGlzIGlzIGV4YWN0bHkgd2h5IEkgZG9u4oCZdCB0aGluayB3ZSBz
aG91bGQgdXNlIOKAnGNsYWlt4oCdIGluIHRoZSB3YXkgdGhhdCB3ZeKAmXJlIHVzaW5nIGl0LiBZ
ZXMsIGEg4oCcY2xhaW3igJ0gY291bGQgY29tZSBiYWNrIHRocm91Z2ggYW4gUlMg4oCUIGJ1dCBp
biB0aGUgY29udGV4dCBvZiBHTkFQLCB0aGF0IG1ha2VzIGl0IGEgcmVzb3VyY2UuIFNvIHdlIG5l
ZWQgYSBkaWZmZXJlbnQgd29yZCBmb3IgZGF0YSBjb21pbmcgYmFjayBkaXJlY3RseSBmcm9tIHRo
ZSBBUyB0byB0aGUgY2xpZW50LiBTb21ldGltZXMgaXTigJlzIGdvaW5nIHRvIGJlIGFib3V0IHRo
ZSB1c2VyLCBhbmQgdGhhdOKAmXMgd2hhdCB3ZeKAmXJlIGdvaW5nIHRvIGZvY3VzIG9uIGhlcmUs
IGJ1dCBzaW5jZSB5b3UgY2FuIGFsc28gZ2V0IGluZm9ybWF0aW9uIGFib3V0IHRoZSB1c2VyIGZy
b20gYSByZXNvdXJjZSB3ZSBjYW7igJl0IGp1c3QgY2FsbCBpdCBhIOKAnGNsYWlt4oCdLiBJIHRo
aW5rIHRoaXMgaGFzIGJlZW4gYXQgdGhlIGhlYXJ0IG9mIGEgbG90IG9mIGNvbmZ1c2lvbiBpbiBy
ZWNlbnQgdGhyZWFkcywgYXMgd2VsbCBhcyBjb25mdXNpb24gYWJvdXQgdGhlIHNjb3BlIG9mIHRo
ZSBpbmNsdXNpb24gb2YgaWRlbnRpdHkgaW4gdGhlIEdOQVAgcHJvdG9jb2wuDQoNClNvIGxldOKA
mXMgbGV0IOKAnGNsYWlt4oCdIG1lYW4gd2hhdCBpdCBhbHJlYWR5IGRvZXMsIGFuZCBsZXTigJlz
IGZpbmQgYSB3YXkgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHdoZW4gYW4gaXRlbSwgY2xhaW0g
b3Igb3RoZXJ3aXNlLCAgY29tZXMgYXMgcGFydCBvZiBhIHJlc291cmNlIGFuZCB3aGVuIGl0IGNv
bWVzIGJhY2sgZGlyZWN0bHkuIFRoaXMgaXMgYW4gaW1wb3J0YW50IGRpZmZlcmVudGlhdGluZyBm
ZWF0dXJlIGZvciBHTkFQLg0KDQpTb21lIHN0cmF3IG1hbiBpZGVhcywgbm9uZSBvZiB3aGljaCBJ
4oCZbSBwYXJ0aWN1bGFybHkgaW4gbG92ZSB3aXRoOg0KDQogLSBkaXJlY3QgZGF0YQ0KIC0gcHJv
cGVydGllcw0KIC0gZGV0YWlscw0KIC0gc3RhdGVtZW50cw0KDQpUaGUgaW1wb3J0YW50IHRoaW5n
IGhlcmUgaXMgdGhhdCBpdOKAmXMgbm90IG5lY2Vzc2FyaWx5IDphYm91dDogdGhlIFJPLCBhbmQg
dGhhdCBpdCBpcyA6bm90OiBpbiBhIHJlc291cmNlLg0KDQpBbnkgb3RoZXIgdGhvdWdodHM/DQoN
CiDigJQgSnVzdGluDQoNCg0KDQoNCg0KLS0NCkZyYW5jaXMgUG91YXRjaGENCkNvLUZvdW5kZXIg
YW5kIFRlY2huaWNhbCBMZWFkDQphZG9yc3lzIEdtYkggJiBDby4gS0cNCmh0dHBzOi8vYWRvcnN5
cy1wbGF0Zm9ybS5kZS9zb2x1dGlvbnMvDQoNCg0KLS0NCkZyYW5jaXMgUG91YXRjaGENCkNvLUZv
dW5kZXIgYW5kIFRlY2huaWNhbCBMZWFkDQphZG9yc3lzIEdtYkggJiBDby4gS0cNCmh0dHBzOi8v
YWRvcnN5cy1wbGF0Zm9ybS5kZS9zb2x1dGlvbnMvDQoNCg0KLS0NCkZyYW5jaXMgUG91YXRjaGEN
CkNvLUZvdW5kZXIgYW5kIFRlY2huaWNhbCBMZWFkDQphZG9yc3lzIEdtYkggJiBDby4gS0cNCmh0
dHBzOi8vYWRvcnN5cy1wbGF0Zm9ybS5kZS9zb2x1dGlvbnMvDQoNCg==

--_000_CH2PR00MB0679BFFBE4251753CCECA430F5720CH2PR00MB0679namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6VmVyZGFuYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkdhZHVnaTsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIg
Mzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg
ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l
OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN
Cgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y
dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
UmVzcG9uZGluZyB0byBhIGZldyB0ZXJtaW5vbG9neSBwb2ludHMgYWZ0ZXIgY2F0Y2hpbmcgdXAg
dGhpcyB0aHJlYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5RdW90aW5n
IGZyb20gUkZDIDc1MTk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQ2xh
aW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj
b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEgcGllY2Ugb2YgaW5m
b3JtYXRpb24gYXNzZXJ0ZWQgYWJvdXQgYSBzdWJqZWN0LiZuYnNwOyBBIGNsYWltIGlzPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh
Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXByZXNlbnRlZCBhcyBhIG5hbWUv
dmFsdWUgcGFpciBjb25zaXN0aW5nIG9mIGEgQ2xhaW0gTmFtZSBhbmQgYTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2xhaW0gVmFsdWUuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGJlbGlldmUgdGhhdCB0aGlzIGRlZmluaXRpb24gcmVt
YWlucyBzdWl0YWJsZSBhbmQgYXBwbGljYWJsZSBhbmQgd2Ugc2hvdWxkIGtlZXAgdXNpbmcgaXQu
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7IFRoZSBkZWZpbml0
aW9uIGlzIG5vdCBzcGVjaWZpYyB0byBwYXJ0aWN1bGFyIGtpbmRzIG9mIHN1YmplY3RzLiZuYnNw
OyBPcGVuSUQgQ29ubmVjdA0KIElEIFRva2VuIGNsYWltcyBhcmUgYWJvdXQgdGhlIGF1dGhlbnRp
Y2F0aW9uIHRoYXQgd2FzIHBlcmZvcm1lZC4mbmJzcDsgVXNlckluZm8gY2xhaW1zIGFyZSBhYm91
dCB0aGUgRW5kLVVzZXIuJm5ic3A7IFNUSVIgY2xhaW1zIGVuYWJsZSB2ZXJpZnlpbmcgdGhlIG93
bmVyc2hpcCBvZiB0ZWxlcGhvbmUgbnVtYmVycy4mbmJzcDsgQ2xhaW1zIGFib3V0IGFueSBraW5k
cyBvZiBzdWJqZWN0cyBhcmUgcG9zc2libGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MDAyMDYwIj5RdW90aW5nIGZyb20gT3BlbklEIENvbm5lY3QgQ29yZTo8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RW5kLVVzZXI8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbjtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw
dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si
Pkh1bWFuIHBhcnRpY2lwYW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+
SeKAmWQgYWR2b2NhdGUgdXNpbmcg4oCcRW5kLVVzZXLigJ0gaW4gdGhpcyBtYW5uZXIuJm5ic3A7
IFRoZSB0ZXJtIOKAnHVzZXLigJ0gY2FuIG1lYW4gdG9vIG1hbnkgb3RoZXIgdGhpbmdzIHRvIHBl
b3BsZSwgYXMgZG9jdW1lbnRlZCBpbiB0aGlzIHRocmVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt
LSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t
OjwvYj4gVHhhdXRoICZsdDt0eGF1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxm
IE9mDQo8L2I+SnVzdGluIFJpY2hlcjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgMjcs
IDIwMjAgNToxNSBBTTxicj4NCjxiPlRvOjwvYj4gRnJhbmNpcyBQb3VhdGNoYSAmbHQ7ZnBvQGFk
b3JzeXMuZGUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBUb20gSm9uZXMgJmx0O3Rob21hc2NsaW5nYW5q
b25lc0BnbWFpbC5jb20mZ3Q7OyBGYWJpZW4gSW1iYXVsdCAmbHQ7ZmFiaWVuLmltYmF1bHRAZ21h
aWwuY29tJmd0OzsgRGVuaXMgJmx0O2RlbmlzLmlldGZAZnJlZS5mciZndDs7IHR4YXV0aEBpZXRm
Lm9yZzsgRGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJlOiBbVHhhdXRoXSBDbGFpbXMgW3dhczogLSBEaWN0aW9uYXJ5XTxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIHRoZSBzZXBhcmF0
aW9uIGJldHdlZW4g4oCccm9sZXPigJ0gYW5kIOKAnGVudGl0aWVz4oCdLiBJdOKAmXMgZXhhY3Rs
eSB0aGF0IGtpbmQgb2Ygc2VwYXJhdGlvbiBpbnRvIHJvbGVzIHRoYXQgaGVscGVkIE9BdXRoIDIg
c3VjY2VlZCB3aXRoIHRoZSBBUyBhbmQgUlMgcm9sZXMgcG9zc2libHkgYmVpbmcgdGhlIHNhbWUg
ZW50aXR5LCBvciBub3QsIGRlcGVuZGluZyBvbiB1c2UgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgb25lIG9mIHRoZSByZWFzb25zIHRo
YXQgSSB0aGluayDigJx1c2Vy4oCdIGlzIGFuIG92ZXJsb2FkZWQgdGVybS4gVGhlIHVzZXIgaXMg
YW4gZW50aXR5LCBub3QgYSByb2xlLCBhbmQgaW4gc3BpdGUgb2YgaXQgYmVpbmcg4oCcdW5kZXJz
dG9vZOKAnSBpbiB0aGUgT0F1dGggMiB3b3JsZCwgaXQgbWVhbnMgYSB3aWRlIHZhcmlldHkgb2Yg
b3RoZXIgdGhpbmdzIG91dHNpZGUgdGhhdCB3b3JsZC4gVGhlIHNhbWUgd2l0aA0KIOKAnGNsaWVu
dOKAnSwgSSBjYW7igJl0IHRlbGwgeW91IGhvdyBtYW55IHRpbWVzIEnigJl2ZSBoYWQgdG8gZXhw
bGFpbiB3aGF0IGV4YWN0bHkgYW4gT0F1dGgg4oCcY2xpZW504oCdIGlzIHdoZW4gSeKAmW0gdGVh
Y2hpbmcgYSBjbGFzcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+QXMgZm9yIHNwZWNpZmljIHJlY29tbWVuZGF0aW9uczogSeKAmW0gaW4gZmF2
b3Igb2YgdGhlIHJvbGUg4oCcUmVxdWVzdGVy4oCdIG9yIOKAnFJlcXVlc3RpbmcgUGFydHnigJ0u
IOKAnENsaWVudOKAnSBpcyBhcmd1YWJseSBtb3JlIGNvbmZ1c2luZyBhbmQgaGFyZGVyIHRvIHJl
cGxhY2U6IEkgaGFkIHRyaWVkIHRvIHVzZSDigJxSZXNvdXJjZSBDbGllbnTigJ0gdG8gbWFrZSDi
gJxjbGllbnTigJ0gbW9yZSBzcGVjaWZpYyBpbiBYWVogYnV0IHRoYXQNCiB0dXJuZWQgb3V0IHRv
IGJlIG1vcmUgY29uZnVzaW5nIHRoYW4gaGVscGZ1bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+
PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVsIDI3LCAyMDIwLCBhdCA2
OjEyIEFNLCBGcmFuY2lzIFBvdWF0Y2hhICZsdDs8YSBocmVmPSJtYWlsdG86ZnBvQGFkb3JzeXMu
ZGUiPmZwb0BhZG9yc3lzLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBTdW4sIEp1bCAyNiwg
MjAyMCBhdCAxMTo1OCBQTSBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJk
dEBnbWFpbC5jb20iPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h
cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+T24gU3VuLCBKdWwgMjYsIDIwMjAgYXQgNjo0NSBQTSBGcmFu
Y2lzIFBvdWF0Y2hhICZsdDs8YSBocmVmPSJtYWlsdG86ZnBvQGFkb3JzeXMuZGUiIHRhcmdldD0i
X2JsYW5rIj5mcG9AYWRvcnN5cy5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+SGVsbG8gRGljayw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+T24gU3VuLCBKdWwgMjYsIDIwMjAgYXQgOToxNCBQTSBEaWNrIEhhcmR0
ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r
Ij5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj5IaSBGcmFuY2lzPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPlVzZXIgaXMgYSB3ZWxsIHVuZGVyc3Rvb2QgdGVybSBpbiBPSURDIGFuZCBPQXV0aCAt
LSBhbmQgVXNlciBtZWFucyB0aGUgc2FtZSBpbiBib3RoLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj5SZXNvdXJjZSBPd25lciBpcyB3aG8gb3ducyB0aGUgcmVzb3VyY2Us
IGFuZCB0aGUgdGVybSBpcyBpbnRyb2R1Y2VkIGZvciB3aGVuIHRoZSBVc2VyIGlzIE5PVCB0aGUg
UmVzb3VyY2UgT3duZXIuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj5UaGlzIGRpc3RpbmN0aW9uIGlzIHdoYXQgbWFrZXMgaXQgY29uZnVzaW5nIGFzIHdl
IGFyZSBjb21wYXJpbmcgYW4gRW50aXR5ICh0aGUgVXNlcikgdG8gYSBSb2xlICh0aGUgUk8pLiBX
ZSBuZWVkIHR3byByb2xlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T3Igd2UgY291bGQgdGhpbmsg
b2YgdGhlbSBhbGwgYXMgZW50aXRpZXMuIFRoZSBSTyBpcyB0aGUgZW50aXR5IHRoYXQgb3ducyB0
aGUgcmVzb3VyY2UuIFRoZSBVc2VyIGlzIHRoZSBodW1hbiB0aGF0IGlzIHVzaW5nIHRoZSBDbGll
bnQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPldoZW4gd2UgdGhpbmsgb2YgdGhlbSBhcyBlbnRpdGllcywgd2UgcnVuIGludG8gY29uZmxp
Y3RzIHdoZW4gRW50aXR5LVVzZXIgZXEuIEVudGl0eS1STy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5X
aGVuIHdlIHRoaW5rIG9mIHRoZW0gYXMgcm9sZXMsIFJvbGUtVXNlciBpcyBhbHdheXMgIT0gUm9s
ZS1STyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g
MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+SSBhbHNvIHRoaW5rIHRoYXQgQ2xpZW50IGFuZCBSZXNvdXJjZSBTZXJ2
ZXIgYXJlIHdlbGwgdW5kZXJzdG9vZCB0ZXJtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPkxvb2tzIGxpa2UgY29udHJpYnV0b3JzIG9uIHRoZSBsaXN0IHN0aWxs
IG5lZWQgY2xhcmlmaWNhdGlvbiBvbiZuYnNwO3RoZSAmcXVvdDtvcmNoZXN0cmF0aW9uJnF1b3Q7
IHJvbGUgb2YgYSBjbGllbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldoZW4gSSB0aGluayBvZiBv
cmNoZXN0cmF0aW9uLCBJIHRoaW5rIG9mIGNvb3JkaW5hdGluZywmbmJzcDt3aGljaCBpcyBub3Qg
d2hhdCBJIHRoaW5rIHRoZSZuYnNwO0NsaWVudCBpcyBkb2luZy4gVGhlIENsaWVudCB3YW50cyB0
byBjb25zdW1lIHRoZSBDbGFpbXMgYW5kIHRoZSBSZXNvdXJjZXMgKGNvbWJpbmVkIGFyZQ0KIGEg
R3JhbnQpLiBUaGUgQ2xpZW50IHJlcXVlc3RzIHRoZSBHcmFudCBmcm9tIHRoZSBHcmFudCBTZXJ2
ZXIuIFdoZXJlIGlzIHRoZSBvcmNoZXN0cmF0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Mb29rIGF0IHRoZSBjbGllbnQuIEl0IGlzIHRoZSBj
ZW50ZXIgb2YgaW50ZXJhY3Rpb24gYmV0d2VlbiBVc2VyLCBHUyBhbmQgUlMuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj5JdCBpcyBub3QgY2xlYXIgdG8gbWUgd2h5IHdlIHdvdWxk
IHdhbnQgdG8gcmVpbnZlbnQgdGhlc2UgdGVybXMuIFJlYWRpbmcgb3ZlciB5b3VyIGZsb3dzLCBJ
IHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCZuYnNwO3RvIHVuZGVyc3RhbmQgdGhlIHJlcXVpcmVt
ZW50cyB5b3UgaGF2ZSBmb3IgeW91ciB1c2UgY2FzZSwNCiBvdGhlcndpc2UgSSBmZWFyIHdlIHdp
bGwgYmUgdGFsa2luZyBwYXN0IGVhY2ggb3RoZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj5UaGUgb0F1dGggZmxvdyBpcyB0aGVyZSBhcyBhIG1lbW8uIFRoZSBv
dGhlciBmbG93IGlzIHdoYXQgSSBwcm9wb3NlZCBiZWZvcmUuIElzIHRoZXJlIHRvIGVtcGhhc2l6
ZSB3ZSBuZWVkIHRvIHdvcmsgb24gcm9sZXMgYW5kIG5vdCBvbiBlbnRpdGllcy4gSXQgaXMgbm90
IGEgc3VnZ2VzdGlvbiZuYnNwO3RvDQogcmVuYW1lJm5ic3A7d2VsbCBrbm93biBpZGlvbXMuIEl0
IGlzIGFuIGF0dGVtcHQmbmJzcDt0byBnaXZlJm5ic3A7dGhlbSBhIHByb3BlciBkZWZpbml0aW9u
IGluIHRoZSBjb250ZXh0IG9mIHRoaXMgcHJvdG9jb2wuIERlZmluaXRpb24gYmFzZWQgb24gdGhl
aXIgcm9sZXMgaW4gdGhlIHByb3RvY29sIGZsb3dzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JJ2Qg
bGlrZSB0byB0YWtlIGEgc3RlcCBiYWNrIGFuZCB1bmRlcnN0YW5kIHRoZSByZXF1aXJlbWVudHMu
IFdlIGFyZSBkZWVwIGludG8gc29sdXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj5Obywgd2UgYXJlIGF0IHRoZSBmdW5kYW1lbnRhbCBsZXZl
bC4gV2UgSGF2ZSB0byBkZWNpZGUgb24mbmJzcDt3aGV0aGVyJm5ic3A7dG8gYnVpbGQgYSBtb2Rl
bCBiYXNlZCBvbiByb2xlcyBvcm9uIGVudGl0aWVzLi4uIFRoZW4gd2UgdXNlIHRoZSByZXN1bHQg
W0VOVElUWSBYT1IgUk9MRVNdIHRvIGRlZmluZSB0aGUNCiB1c2UgY2FzZXMuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+L0ZyYW5jaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp
biI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5CZXN0IHJlZ2FyZHMuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+L0ZyYW5jaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp
biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPi9EaWNrPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48aW1nIGJvcmRlcj0iMCIgaWQ9Il94MDAw
MF9pMTAyNyIgc3JjPSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpH
bGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3Vp
ZD03MzQxOWIzMi1hOGUwLTQzY2QtYjkxYi05MzMwYTQzYTRjZjgiPjwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIEZyaSwgSnVsIDI0LCAyMDIwIGF0IDc6MjEg
UE0gRnJhbmNpcyBQb3VhdGNoYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZwb0BhZG9yc3lzLmRlIiB0
YXJnZXQ9Il9ibGFuayI+ZnBvQGFkb3JzeXMuZGU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+QmVsb3cgbXkgb3BpbmlvbiZuYnNwO29uIHRoZSB0ZXJtIENsYWltOjwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U3RhcnRp
bmcgd2l0aCBpbGx1c3RyYXRpb24gb2YgcGFydGllcy9yb2xlczo8L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VXNlcjombmJzcDs8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhpcyB3b3JkIGlzIG1pc2xlYWRp
bmcgYmVjYXVzZSBvZiBpdHMgZG91YmxlIHJvbGUgaW4gb0F1dGgyIGFuZCBPSURDIChzZWUgYmVs
b3cpLiBJbiBHTkFQIGxldCB1cyBoYXZlIHRoZSBVc2VyIHBsYXkgb25seSB0aGUgcm9sZSBvZiBh
IHJlcXVlc3Rvci4gKGZyb20gSnVzdGluIHJlZmVyZW5jZSB0byAmcXVvdDtSZXF1ZXN0aW5nDQog
UGFydHkmcXVvdDspLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DbGllbnQ6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPlRoaXMgaXMgYWxzbyB0aWdodGx5Jm5ic3A7Ym91bmQgdG8gdGhlIG9BdXRoMiBhbmQg
T0lEQy4gVGhlIHJlYWwgcHVycG9zZSBvZiB0aGlzIHJvbGUgaXMgdG8gb3JjaGVzdHJhdGUgcmVz
b3VyY2UgYWNjZXNzIG9uIGJlaGFsZiBvZiB0aGUgJnF1b3Q7UmVxdWVzdG9yJnF1b3Q7LiBMZXQg
dXMgY2FsbCB0aGlzIGZvciBub3cgdGhlICZxdW90O09yY2hlc3RyYXRvciZxdW90Ozwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5S
ZXNvdXJjZSBPd25lciAoUk8pOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5U
aGlzIGlzIElNTyB0aGUgbW9zdCBjb3JyZWN0IHdvcmQgaW4gdGhlIGVudGlyZSBwcm90b2NvbC4g
QXV0aG9yaXNhdGlvbiBpcyBhbHdheXMgYWJvdXQgdGhlIG93bmVyIG9mIHNvbWV0aGluZyBncmFu
dGluZyBhY2Nlc3MgdG8gYSByZXF1ZXN0b3IuIEl0IHJlYWxseSZuYnNwO2RvZXMgbm90IG1hdHRl
ciBpZiBhIGh1bWFuDQogaW50ZXJhY3Rpb24gaXMgaW52b2x2ZWQuIFdlIHdpbGwgaGF2ZSB0byBm
b3JnZXQgb0F1dGgyIGFuZCBPSURDIG9mIGFsc28gY2FsbGluZyB0aGlzIGEgVXNlci48L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
R3JhbnQgU2VydmVyOiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5F
dmVuIHRob3VnaCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgVXNlckluZm8gZW5kcG9pbnQgaW4gT0lE
QyBhcyBhIHByb3RlY3RlZCByZXNvdXJjZSBoYXphcmRvdXNseSBtYWtlcyBhbiBPUCBhbiBSUywg
d2Ugc2hhbGwgbm90IHJlcGVhdCB0aGUgc2FtZSBtaXN0YWtlIGhlcmUuIFdlIG5lZWQgYSBjbGVh
ciBzZXBhcmF0aW9uDQogYmV0d2VlbiByb2xlcyBvZiBHUyBhbmQgUlMgd2l0aG91dCBvdmVybGFw
cGluZy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+UmVzb3VyY2UgU2VydmVyOiBzZXJ2aWNlcyByZXNvdXJjZXMuPC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlVu
bGVzcyBJIGdvdCZuYnNwO2l0IHdyb25nLCBHTkFQIGlzIGFib3V0IGdyYW50IG5lZ290aWF0aW9u
IGFuZCBhdXRob3JpemF0aW9uLiBUaGlzIG1lYW5zOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5HTkFQIGlzIGFib3V0IHNvbWUg
cGFydHkgcmVxdWVzdGluZyBhY2Nlc3MgdG8gc29tZSByZXNvdXJjZXMuPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPkdOQVAgaXMgYWJvdXQgdGhlIHJlc291cmNlIG93bmVyIGNv
bnNlbnRpbmcgYWNjZXNzIHRvIHRoYXQgcmVzb3VyY2UuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPkdOQVAgaXMgYWJvdXQgZGVmaW5pbmcgdGhlIGluZnJhc3RydWN0dXJlIHRo
YXQgYWxsb3dzIHRoZSByZXF1ZXN0aW5nIHBhcnR5IHRvIGFjY2VzcyBhIHJlc291cmNlLiZuYnNw
Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij5HTkFQIGRlc2lnbnMgdGhpcyBpbmZyYXN0cnVjdHVyZSBhcm91bmQ6PC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0gYW4gb3JjaGVzdHJhdG9yICh3aGF0IHdlIHJl
ZmVyIHRvIGFzIGEgY2xpZW50KTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4t
IGFuIGdyYW50IG1hbmFnZXIgKHdoYXQgd2UgcmVmZXIgdG8gYXMgYSBHUy9BUyk8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSB0aGUgY3VzdG9kaWFuIG9mIHRoZSByZXNvdXJj
ZSAod2hhdCB3ZSBjYWxsIGEgUlMpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFzIHlvdSBzZWU6PC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPi0gVGhlIHdvcmQgVXNlciBkb2VzIG5vdCBhcHBlYXIgaGVyZSwg
YW5kIGlzIG5vdCByZWxldmFudCBhcyB0aGUgZm9jdXMmbmJzcDtpcyBvbiBhdXRob3JpemluZyBh
Y2Nlc3MgdG8gYSByZXNvdXJjZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
LSBUaGUgd29yZCBDbGFpbSBpcyBhcyB3ZWxsIGFic2VudC48L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2xhaW0gcmVsYXRlZCB0
byBSTzo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIHdvcmQgQ2xhaW0g
bWlnaHQgc3RhcnQgZ2V0dGluZyB2aXNpYmxlIGlmIHRoZSBvcmNoZXN0cmF0b3IgKGEuay5hLiBD
bGllbnQpIG9yIHRoZSBjdXN0b2RpYW4gKGEuay5hIFJTKSBuZWVkcyBzb21lIGFkZGl0aW9uYWwg
aW5mb3JtYXRpb24gb24gdGhlIFJPIHRvIHByb2NlZWQgd2l0aCB0aGUgYWNjZXNzIGNvbnRyb2wN
CiBkZWNpc2lvbi4gVGhlc2UgY2xhaW1zIHJlZmVyIHRvIGFzc2VydGlvbnMgb2YgYXR0cmlidXRl
cyBvciBwcm9wZXJ0aWVzIG9mIHRoZSBSTy4gVGhlc2UgY2xhaW1zIGFyZSBpc3N1ZWQgYnkgdGhl
IEdTIGFzIHRoZSBHUyBtYW5hZ2VzIGludGVyYWN0aW9uIHdpdGggdGhlIFJPIChzZWUgYmVsb3cp
LiBJbiB0aGlzIGZpcnN0IHBsYWNlIGluZm9ybWF0aW9uIGFib3V0IHRoZSByZXF1ZXN0aW5nIHBh
cnR5IChlcnJvbmVvdXNseS5rLmEuIFVzZXIpIGlzDQogbm90IHJlbGV2YW50IHRvIHRoZSBuZWdv
dGlhdGlvbiBhbmQgcHJvdmlzaW9uaW5nIGZyYW1ld29yay4gTGV0IHVzIGNhbGwgdGhpcyBzb3J0
IG9mIGNsYWltICZxdW90O1JPLUF0dHJpYnV0ZXMmcXVvdDsuIEEgYmV0dGVyIG5hbWUgaXMgd2Vs
Y29tZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+U29tZSBhZHZhbmNlZCByZXNvdXJjZSBwcm92aXNpb25pbmcgZnJhbWV3b3Jr
cyBtaWdodCByZXF1aXJlIGtub3dsZWRnZSBvbiBhdHRyaWJ1dGVzIG9mIHRoZSByZXF1ZXN0aW5n
IHBhcnR5IChlLmsuYSBVc2VyKS4gVGhlc2UgYXR0cmlidXRlcyBzaGFsbCBiZSBjb2xsZWN0ZWQg
YnkgdGhlJm5ic3A7b3JjaGVzdHJhdG9yIChhLmsuYQ0KIENsaWVudCkgYW5kIGFkZGVkIHRvIHRo
ZSByZXNvdXJjZSByZXF1ZXN0LiBUaGVyZSBpcyBubyB3YXkgdGhlIEdTIGNhbiBjb2xsZWN0IHRo
ZXNlIGF0dHJpYnV0ZXMgYXMgdGhlIEdTIHJvbGUgaGFzIG5vIGludGVyYWN0aW9uIHdpdGggdGhl
IHJlcXVlc3RpbmcgcGFydHkgKGUuay5hIFVzZXIpLiZuYnNwO0xldCB1cyBjYWxsIHRoaXMgc29y
dCBvZiBjbGFpbSAmcXVvdDtSZXF1ZXN0b3ItQXR0cmlidXRlcyZxdW90Oy4gQSBiZXR0ZXIgbmFt
ZSB3aWxsIGJlIHdlbGNvbWUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNvbWUgYXNzZXJ0aW9ucyBhcmUgZXZlbiByZWxhdGVk
IHRvIHRoZSBvcmNoZXN0cmF0b3ImbmJzcDsoYS5rLmEgQ2xpZW50KSBpdHNlbGYuIFRoaXMgaXMg
dGhlIGNhc2Ugb2YgdGhlIHB1YmxpYyBrZXkgb2YgYW4gb3JjaGVzdHJhdG9yJm5ic3A7dXNlZCBi
eSB0aGUgR1MgdG8gJnF1b3Q7c2VuZGVyIGNvbnN0cmFpbiZxdW90OyBhbiBhY2Nlc3MgdG9rZW4u
DQogTGV0IHVzIGNhbGwgdGhpcyB0eXBlIG9mIGNsYWltICZxdW90O09yY2hlc3RyYXRvci1BdHRy
aWJ1dGVzJnF1b3Q7Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGlzIGlzIGEgc2FtcGxlIG1hcHBpbmcgb2YgT0lEQy48L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+Ky0tLS0rICZuYnNwOyAmbmJzcDsrLS0tKyAmbmJzcDsgKy0tLSsgJm5ic3A7Ky0tLSs8YnI+
DQp8VXNlcnwgJm5ic3A7ICZuYnNwO3xSUCB8ICZuYnNwOyB8T1AgfCAmbmJzcDt8UlMgfDxicj4N
CistLS0tKyAmbmJzcDsgJm5ic3A7Ky0tLSsgJm5ic3A7ICstKy0rICZuYnNwOystLS0rPGJyPg0K
Jm5ic3A7IHwoMSkgU2VydmljZVJlcXVlc3QgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5i
c3A7IHwtLS0tLS0tLSZndDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm
bmJzcDt8PGJyPg0KJm5ic3A7IHwoMikgcmVkaXJlY3QmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5i
c3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7IHwmbHQ7LS0tLS0tLS18ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPj09PSBVc2VyIChyZXF1ZXN0b3IpIHBhc3NlcyBjb250cm9sIHRvIFVzZXIg
KFJPKSA9PT08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IHwoMykg
QXV0aCArIENvbnNlbnQgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7IHwtLS0tLS0t
LS0tLS0tLS0tJmd0O3wgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7IHwoNCkgcmVk
aXJlY3QgKGNvZGUpICZuYnNwOyAmbmJzcDsgfDxicj4NCiZuYnNwOyB8Jmx0Oy0tLS0tLS0tLS0t
LS0tLS18ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij49PT0gVXNlciAoUk8pIHBhc3NlcyBjb250cm9sIGJhY2sgdG8gVXNlciAocmVxdWVz
dG9yKSA9PT08YnI+DQombmJzcDsgfCg1KSBnZXQoY29kZSkgJm5ic3A7ICZuYnNwO3wgJm5ic3A7
ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7IHwtLS0tLS0tLSZndDt8ICZuYnNwOyZuYnNwOyAm
bmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQombmJzcDsgfCAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCg2KSB0b2tlbiAoY29kZSk8YnI+DQombmJzcDsgfCAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfC0tLS0tLSZndDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7
fDxicj4NCiZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8KDcpIHRva2VuICZu
YnNwOyAmbmJzcDsgfDxicj4NCiZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8
Jmx0Oy0tLS0tLXwgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7IHwgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7IHwoOCkgU2VydmljZVJlcXVlc3QodG9rZW4pPGJyPg0KJm5ic3A7
IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0tJmd0O3w8YnI+DQom
bmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCg5KSBTZXJ2aWNlUmVzcG9uc2U8
YnI+DQombmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZsdDstLS0tLS0tLS0t
LS0tfDxicj4NCiZuYnNwOyB8KDEwKSBTZXJ2aWNlUmVzcG9uc2UgJm5ic3A7ICZuYnNwO3w8YnI+
DQombmJzcDsgfCZsdDstLS0tLS0tLXwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5i
c3A7ICZuYnNwO3w8YnI+DQombmJzcDsgKyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyArICZuYnNwOyAmbmJzcDsgJm5ic3A7Kzwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIFJQIG9y
Y2hlc3RyYXRlcyBpbnRlcmFjdGlvbiBiZXR3ZWVuIFVzZXIgYW5kIE9QIHRvIGVuYWJsZSB0aGUg
dXNlciB0byBvYnRhaW4gdGhlIHByb3RlY3RlZCByZXNvdXJjZS48L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+LSBJbiBzdGVwIDEgJmFtcDsgMTAgVXNlciBwbGF5cyB0aGUgcm9s
ZSBvZiB0aGUgcmVxdWVzdG9yIG9mIHRoZSByZXNvdXJjZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OyI+LSBJbiBzdGVwIDIgVXNlci1Ccm93c2VyIGlzIHVzZWQgdG8gcGFzcyBj
b250cm9sIGZyb20gVXNlciAoaW4gaGlzIHJvbGUgYXMgdGhlIHJlcXVlc3RvcikgdG8gVXNlciAo
aW4gaGlzIHJvbGUgYXMgdGhlIFJPKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
Ij4tIEluIHN0ZXAgNCZuYnNwO1VzZXItQnJvd3NlciBpcyB1c2VkIHRvIHBhc3MgY29udHJvbCBm
cm9tIFVzZXIgKGluIGhpcyByb2xlIGFzIHRoZSBSTykgYmFjayB0byZuYnNwO1VzZXIgKGluIGhp
cyByb2xlIGFzIHRoZSByZXF1ZXN0b3IpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldoZW4gd2UgYXJlIHRhbGtpbmcgY2xhaW1z
IGhlcmUsIHdlIGFyZSB0YWxraW5nIGNsYWltcyBvbiB0aGUgVXNlciAoaW4gaGlzIHJvbGUgYXMg
dGhlIFJPKS4gVGhlIE9QIGRvZXMgbm90IGhhdmUgYW55IGludGVyYWN0aW9uIHdpdGggdGhlIFVz
ZXIgKGluIGhpcyByb2xlIGFzIHRoZSByZXF1ZXN0b3IpLiBJbiB0aGUNCiBjYXNlIG9mIGFuIEFw
cDJBcHAgcmVkaXJlY3Rpb24sIHRoZSBPUCBjYW4gbm90IGV2ZW4gYXNzZXJ0IGFib3V0IHRoZSB1
c2VyIGFnZW50IG9mIHRoZSBVc2VyIChyZXF1ZXN0b3IpLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JZiB0aGVyZSBpcyBhbnkg
Y2xhaW0gdGhlIE9QIGNhbiBwcm92aWRlLCBpdCBpcyBhIGNsYWltIG9uIHRoZSBVc2VyIChSTyku
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPkkgaG9wZSB0aGlzIGV4YW1wbGUgY2xhcmlmaWVzIHRoZSBtaXN1bmRlcnN0YW5kaW5n
LiBBbnkgYXR0ZW1wdCBvZiBicmluZ2luZyB0aGlzIGRvdWJsZSByb2xlIG9mIHRoZSBVc2VyIGlu
dG8gR05BUCB3aWxsIGFsc28gYnJpbmcgdGhpcyBjb25mdXNpb24uIEluIG9yZGVyIHRvIGtlZXAg
dGhpcyBvdXQgb2YgR05BUA0KIGxldCB1cyBsb29rIGZvciB0aGUgcmlnaHQgdGVybSBmb3IgVXNl
ciAoYXMgYSByZXF1ZXN0b3IpIHVzaW5nIHRoZSBkaWFncmFtIGRpc3BsYXllZCBiZWxvdy48L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyI+Ky0tLS0rICZuYnNwOystLS0tLS0rICZuYnNwOystLS0rICZuYnNwOystLS0rICZuYnNwOyst
LS0rPGJyPg0KfFJlcXN8ICZuYnNwO3xPcmNoc3R8ICZuYnNwO3xSUyB8ICZuYnNwO3xHUyB8ICZu
YnNwO3xSTyB8PGJyPg0KKy0tLS0rICZuYnNwOystLS0tLS0rICZuYnNwOystLS0rICZuYnNwOyst
Ky0rICZuYnNwOystKy0rPGJyPg0KJm5ic3A7IHwoMSkgU2VydmljZVJlcXVlc3QgJm5ic3A7Jm5i
c3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyB8LS0tLS0tLS0m
Z3Q7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsg
Jm5ic3A7ICZuYnNwO3w8YnI+DQombmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
fCgyKSBTZXJ2aWNlSW50ZW50OkF1dGhaQ2hhbGxlbmdlJm5ic3A7PGJyPg0KJm5ic3A7IHwgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbHQ7LS0tLS0mZ3Q7fCAmbmJzcDsgJm5ic3A7ICZu
YnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNw
O3wgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IHwoMykgQXV0aFpSZXF1ZXN0KEF1dGhaQ2hhbGxlbmdlKTxicj4NCiZuYnNwOyB8
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8LS0tLS0tLS0tLS0tLSZndDt8ICZuYnNwOyAm
bmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDt8KDQpIENvbnNlbnRS
ZXF1ZXN0OkdyYW50PGJyPg0KJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbHQ7LS0tLSZndDt8
PGJyPg0KJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwoNSkgR3JhbnRBY2Nl
c3MoQXV0aFopPGJyPg0KJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbHQ7
LS0tLS0tLS0tLS0tLXwgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7IHwgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5i
c3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJm5ic3A7IHwgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7IHwoNikgU2VydmljZVJlcXVlc3QoQXV0aFopOlNlcnZpY2VSZXNw
b25zZTxicj4NCiZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jmx0Oy0tLS0t
Jmd0O3wgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZu
YnNwOyB8KDcpIFNlcnZpY2VSZXNwb25zZSAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAm
bmJzcDt8PGJyPg0KJm5ic3A7IHwmbHQ7LS0tLS0tLS18ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwg
Jm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZuYnNwOyAr
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyArICZuYnNwOyAmbmJzcDsgJm5ic3A7ICsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsrICZuYnNwOyAmbmJzcDsgJm5ic3A7Kzwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tIFJlcGxhY2lu
ZyB0aGUgd29yZCBVc2VyIGhlbHBzIGNsYXJpZnkgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBib3Ro
IHJvbGVzICZxdW90O1JlcXVlc3RvciZxdW90OyBhbmQgJnF1b3Q7UmVzb3VyY2UgT3duZXImcXVv
dDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LSBSZW5hbWluZyBjbGFpbSBi
eSBhdHRhY2hpbmcgdGhlIE9iamVjdC90YXJnZXQgb2YgdGhlIGNsYWltIChlLmcuOiBSTy1hdHRy
aWJ1dGVzLCBSZXF1ZXN0b3ItQXR0cmlidXRlcywgT3JjaGVzdHJhdG9yLUF0dHJpYnV0ZXMpIGFs
c28gaGVscHMgaWRlbnRpZnkgdGhlIHNvdXJjZSBvZiB0aG9zZSBhdHRyaWJ1dGVzDQogKEdTLCBS
UywgQ2xpZW50KTo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QmVzdCByZWdhcmRzLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPi9GcmFuY2lzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+T24gRnJpLCBKdWwgMjQsIDIwMjAgYXQgNDo1OCBQTSBEaWNrIEhhcmR0ICZsdDs8YSBocmVm
PSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0
QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg
MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t
cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+SXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoYXQgaXQgbWF0dGVycyBpZiBhIENsYWlt
IGNvbWVzIGZyb20gYW4gUlMsIG9yIGZyb20gdGhlIEdTLCBzbyBJIGRvbid0IHNlZSBhIG5lZWQg
dG8gZGlmZmVyZW50aWF0ZSB0aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPkkgd291bGQgaW5jbHVkZSB2ZXJpZmlhYmxlIGNyZWRlbnRpYWxzIGFuZCB1
c2VyLWJvdW5kIGtleXMgYXMgQ2xhaW1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPkFsbCB0aGUgcGF5bWVudCBwcm9jZXNzaW5nIGluZm9ybWF0aW9uIEkg
aGF2ZSZuYnNwO3NlZW4gaGFzIGJlZW4gaW4gUkFSLiBXaGVuIHdvdWxkJm5ic3A7dGhlIENsaWVu
dCBnZXQgcGF5bWVudCBwcm9jZXNzaW5nIGRpcmVjdGx5IGZyb20gdGhlIEdTPzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgaXMgeW91ciBleGFtcGxl
IGZvciBkaXN0cmlidXRlZCBuZXR3b3JrcyBzdG9yYWdlIGxvY2F0aW9ucz8gSWYgd2hhdCBpcyBz
dG9yZWQgaXMgYSBzdGF0ZW1lbnQgYWJvdXQgdGhlIHVzZXIsIHRoZW4gSSB3b3VsZCBjb25zaWRl
ciB0aGF0IGEgQ2xhaW0gYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj5XZSBkaXNhZ3JlZSBvbiBob3cgdG8gbWFwIE9JREMgdG8gR05BUC4mbmJz
cDsgVGhlIGRpcmVjdCBkYXRhIGlzIGEgY2xhaW1zIHJlcXVlc3QsIHRoZSBkYXRhIGNvbWluZyBp
bmRpcmVjdGx5IGlzIGFuIGFjY2VzcyB0b2tlbiByZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIEZyaSwgSnVsIDI0LCAyMDIwIGF0IDE6MzkgUE0g
SnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0
PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm
dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj5TaW5jZSB3ZeKAmXJlIGFscmVhZHkgdGFsa2luZyBhYm91dCByZXR1
cm5pbmcgY2xhaW1zIGFzIGRpcmVjdCBkYXRhIGFzIHdlbGwgYXMgYSBwYXJ0IG9mIHRoZSByZXNv
dXJjZSBBUEkgYmVpbmcgcHJvdGVjdGVkLCBzbyB3ZSBhbHJlYWR5IG5lZWQgYSB3YXkgdG8gZGlm
ZmVyZW50aWF0ZSB0aGUgdHdvDQoga2luZHMgb2YgaXRlbXMuIEp1c3QgY2FsbGluZyBpdCDigJxj
bGFpbXPigJ0gZG9lc27igJl0IGhlbHAsIGJlY2F1c2UgYXMgeW914oCZdmUgcG9pbnRlZCBvdXQg
dGhleSBjb3VsZCBzaG93IHVwIGluIGJvdGggcGxhY2VzLiBTbyB5ZXMsIGRlZmluaW5nIHRoYXQg
ZGlmZmVyZW5jZSBpcyBzb21ldGhpbmcgd2Ugc2hvdWxkIHdvcnJ5IGFib3V0IG5vdywgZXZlbiBp
ZiB0aGUgY29yZSBwcm90b2NvbCBvbmx5IHVzZXMgaXQgZm9yIGNsYWltcy48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHR3byBmb3JtcyBvZiBkaXJlY3QgZGF0YSB0
aGF0IFhZWiByZXR1cm5zIGFyZSBzdWJqZWN0IGlkZW50aWZpZXJzIChhIHN1YnNldCBvZiBpZGVu
dGl0eSBjbGFpbXMpIGFuZCBhc3NlcnRpb25zIOKAlCB0aGUgbGF0dGVyIGJlaW5nIGEgY29udGFp
bmVyIG5vdCBqdXN0IGZvciBpZGVudGl0eSBjbGFpbXMNCiBidXQgYWxzbyBhdXRoZW50aWNhdGlv
biBpbmZvcm1hdGlvbiBhbmQgb3RoZXIgZWxlbWVudHMuIEFzc2VydGlvbnMgYXJlIG5vdCBjbGFp
bXMgdGhlbXNlbHZlcy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5PdGhlciB1c2UgY2FzZXMgdGhhdCBoYXZlIGJlZW4gYnJvdWdodCB1cCBpbmNs
dWRlIHZlcmlmaWFibGUgY3JlZGVudGlhbHMgYW5kIHByb29mcywgdXNlci1ib3VuZCBrZXlzLCBw
YXltZW50IHByb2Nlc3NpbmcgaW5mb3JtYXRpb24sIGFuZCBkaXN0cmlidXRlZCBuZXR3b3JrIHN0
b3JhZ2UgbG9jYXRpb25zLg0KIEnigJltIHN1cmUgdGhlcmUgYXJlIGEgbG90IG1vcmUuIFRvIG1l
LCB0aGVzZSBhcmUgc3Vic2V0cyBvZiB0aGUg4oCcZGlyZWN0IGRhdGHigJ0gYnV0IG5vdCBzdWJz
ZXRzIG9mIOKAnGNsYWltc+KAnS4gR05BUCBzaG91bGRu4oCZdCBiZSBkZWZpbmluZyB3aGF0IGFs
bCBvZiB0aGVzZSBsb29rIGxpa2UsIGJ1dCBpdCBzaG91bGQgZGVmaW5lIGEgd2F5IHRvIHRhbGsg
YWJvdXQgdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij5JIHRoaW5rIGRpZmZlcmVudCB0b3AtbGV2ZWwgcmVxdWVzdCBvYmplY3RzIGFyZSBiZXR0ZXIg
c3VpdGVkIGZvciBkaWZmZXJlbnQgcXVlcnkgc2VtYW50aWNzLiBMaWtlLCBmb3IgZXhhbXBsZSwg
dGhlIE9JREMg4oCcY2xhaW1z4oCdIHJlcXVlc3QsIHdoaWNoIGFsbG93cyB0YXJnZXRpbmcgb2Yg
aXRzIGNsYWltcw0KIGluZm9ybWF0aW9uIGludG8gZGlmZmVyZW50IHJldHVybiBidWNrZXRzLiBU
aGlzIG92ZXJsYXBzIHdpdGggdGhlIOKAnHJlc291cmNlc+KAnSByZXF1ZXN0IGF0IHRoZSB2ZXJ5
IGxlYXN0LiBJIGRvbuKAmXQgdGhpbmsgR05BUCBzaG91bGQgZGVmaW5lIGhvdyB0byBkbyB0aGlz
IHNwZWNpZmljIGNvbWJpbmF0aW9uLCB0aGF0IHNob3VsZCBiZSBmb3IgT0lERiB0byBkZWJhdGUg
YW5kIGFwcGx5LiBUaGUgc2FtZSB3aXRoIGEgRElEIHNlcnZpY2UgYmFzZWQgcXVlcnksDQogb3Ig
UHJlc2VudGF0aW9uIEV4Y2hhbmdlIFsxXSwgb3IgYW55dGhpbmcgZWxzZSB0aGF0IHBlb3BsZSB3
YW50IHRvIGNvbWUgdXAgd2l0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5JbiBteSB2aWV3LCBHTkFQIHNob3VsZCBkZWZpbmUgcXVlcnkgc3RydWN0dXJl
cyBmb3IgdHdvIHRoaW5nczogcmlnaHRzIHRoYXQgZ2V0IHRpZWQgdG8gYW4gYWNjZXNzIHRva2Vu
IGFuZCBkYXRhIHRoYXQgY29tZXMgYmFjayBkaXJlY3RseSB0byB0aGUgY2xpZW50LiBGb3IgdGhl
IGxhdHRlciwgSQ0KIHRoaW5rIHdlIGNhbiBkbyBzb21lIHZlcnkgbGltaXRlZCBhbmQgdmVyeSB1
c2VmdWwgc3BlY2lmaWMgaXRlbXMsIHdoaWNoIGlzIHdoYXQgSeKAmXZlIHB1dCBpbnRvIFhZWi48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj5bMV0mbmJzcDs8YSBocmVmPSJodHRwczovL2lkZW50aXR5LmZvdW5kYXRpb24v
cHJlc2VudGF0aW9uLWV4Y2hhbmdlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vaWRlbnRpdHku
Zm91bmRhdGlvbi9wcmVzZW50YXRpb24tZXhjaGFuZ2UvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8
YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5PbiBKdWwgMjQsIDIwMjAsIGF0IDM6NTggUE0sIERpY2sgSGFy
ZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh
bmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYWdyZWUgd2Ugd2FudCBHTkFQIHRvIGJlIGEgc3Ryb25n
IGZvdW5kYXRpb24uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PkRvIHlvdSBoYXZlIGFuIGV4YW1wbGUgb2Ygb3RoZXIgJnF1b3Q7ZGlyZWN0IGRhdGEmcXVvdDs/
IElmIHNvLCBkbyB5b3UgZXhwZWN0IGl0IHRvIGJlIGRlZmluZWQgaW4gdGhlIGNvcmUgcHJvdG9j
b2w/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSB3b3Vs
ZCBleHBlY3QgYW4gZXh0ZW5zaW9uIGZvciBvdGhlciAmcXVvdDtkaXJlY3QgZGF0YSZxdW90OyB0
byBkZWZpbmUgdG9wIGxldmVsIG9iamVjdHMsIGFuZCBhbiBhcHByb3ByaWF0ZSBkZWZpbml0aW9u
IGZvciB0aGF0ICZxdW90O2RpcmVjdCBkYXRhJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk15ICZxdW90O2RvIHdlIG5lZWQgdG8gd29ycnkgYWJv
dXQgaXQgbm93JnF1b3Q7IGNvbW1lbnQgd2FzIG9uIGNyZWF0aW5nIGEgZ2VuZXJpYyB0ZXJtIGZv
ciAmcXVvdDtkaXJlY3QgZGF0YSZxdW90Oy4gVW5sZXNzIHdlIGFyZSBzb2x2aW5nIHRob3NlIG5v
dywgd2UgY2FuIGxldCBmdXJ0aGVyIHdvcmsgZGVmaW5lIHRoYXQgJnF1b3Q7ZGlyZWN0DQogZGF0
YSZxdW90OyBleHBsaWNpdGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGltZyBib3JkZXI9IjAi
IGlkPSJfeDAwMDBfaTEwMjYiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/
c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRl
bnQmYW1wO2d1aWQ9ZTRkZjIzYmUtMTcyMC00Yjg1LTljOTctYTE3NTc5MWVmODNjIj48L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBGcmksIEp1bCAyNCwgMjAy
MCBhdCAxMjo0MiBQTSBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBt
aXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu
MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlllcywgSSBkbyB0aGluayB3ZSBuZWVkIHRv
IHdvcnJ5IGFib3V0IGl0IHRvIHRoZSBleHRlbnQgdGhhdCB3ZSBhcmUgbm90IGNyZWF0aW5nIHNv
bWV0aGluZyB0aGF0IGlzIG92ZXItZml0IHRvIGEgbGltaXRlZCBzZXQgb2YgdXNlIGNhc2VzLiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5HTkFQIHNob3VsZCBi
ZSBhIGZvdW5kYXRpb24gdGhhdCBtYW55IGFtYXppbmcgbmV3IHRoaW5ncyBjYW4gYmUgYnVpbHQg
b24gdG9wIG9mLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDvi
gJQgSnVzdGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIEp1bCAy
NCwgMjAyMCwgYXQgMzowNiBQTSwgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2su
aGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SnVzdGlu
LCB0aGFua3MgZm9yIGNsYXJpZnlpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPldoYXQgYXJlIHNvbWUgZXhhbXBsZXMgb2Ygb3RoZXIgJnF1b3Q7ZGlyZWN0IGRhdGEm
cXVvdDsgdGhhdCB0aGUgR1MgbWF5IHJldHVybj8gSWYgaXQgaXMgbm90IGluIGNvcmUgR05BUCwg
ZG8gd2UgbmVlZCB0byB3b3JyeSBhYm91dCBub3c/IFdlIGNhbiB0aGVuIGdpdmUgdGhlIGRpcmVj
dCBkYXRhIGZyb20gdGhlIEdTDQogdGhhdCBpcyBub3QgYSBjbGFpbSwgYW4gYXBwcm9wcmlhdGUg
bmFtZSBpbiB0aGF0IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh
bnMtc2VyaWYiPk9uIEZyaSwgSnVsIDI0LCAyMDIwIGF0IDExOjQ2IEFNIEp1c3RpbiBSaWNoZXIg
Jmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmlj
aGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+RGljazogTm8sIEkgdGhpbmsgeW914oCZcmUgbWlzdW5kZXJzdGFuZGluZyB3aGF0IEnigJlt
IHNheWluZy4gSSBhZ3JlZSB0aGF0IOKAnGNsYWltc+KAnSBhcmUgYWJvdXQgdGhlIHVzZXIsIGlu
IHRoaXMgY29udGV4dCouIEJ1dCB0aGUgQVMgY291bGQgcmV0dXJuIG90aGVyIGRhdGEgZGlyZWN0
bHkgdG8gdGhlIGNsaWVudA0KIHRoYXQgaXNu4oCZdCBhYm91dCB0aGUgdXNlci4gVGhvc2UgYXJl
buKAmXQg4oCcY2xhaW1z4oCdIGJ5IHRoZSBjbGFzc2ljYWwgZGVmaW5pdGlvbi4gQWxzbyBzaW5j
ZSDigJxjbGFpbXPigJ0gY2FuIGNvbWUgYmFjayBmcm9tIHBsYWNlcyBvdGhlciB0aGFuIGRpcmVj
dGx5LCB0aGVuIHdlIHNob3VsZG7igJl0IGNhbGwgZXZlcnl0aGluZyB0aGF0IGNvbWVzIGJhY2sg
YSDigJxjbGFpbeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SeKA
mW0gYXJndWluZyB0aGF0IHdlIGtlZXAg4oCcY2xhaW1z4oCdIHRvIG1lYW4gd2hhdCBpdCBhbHJl
YWR5IG1lYW5zIGFuZCBjb21lIHVwIHdpdGggYSBuZXcgd29yZCB0byBtZWFuIOKAnHRoaW5ncyB0
aGF0IGNvbWUgYmFjayBkaXJlY3RseSBmcm9tIHRoZSBBU+KAnS4gVGhlc2UgYXJlbuKAmXQgbWVh
bnQgdG8gcmVwbGFjZQ0KIEZyYW5jaXPigJlzIG1vcmUgY29tcGxldGUgZGVmaW5pdGlvbnMsIGJ1
dCB0byBzaW1wbGlmeTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl
cmlmIj5DbGFpbXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LSBpbmZvcm1hdGlvbiBhYm91dCB0aGUg
dXNlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPi0gY2FuIGNvbWUgYmFjayBkaXJlY3RseSBmcm9tIHRo
ZSBBUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPi0gY2FuIGNvbWUgYmFjayBpbiBhIHJlc291cmNlIGZy
b20gdGhlIFJTPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
UmVzb3VyY2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LSBSZXR1cm5lZCBmcm9tIGFuIFJTPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+LSBQcm90ZWN0ZWQgYnkgYWNjZXNzIHRva2VuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+LSBDb3VsZCBjb250YWluIGNsYWltcyBhYm91dCB0aGUgdXNlcjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkRpcmVjdCBkYXRhIChvciBzb21lIGJl
dHRlciBuYW1lKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4tIFJldHVybmVkIGRpcmVjdGx5IGZyb20g
QVM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl
dGljYSZxdW90OyxzYW5zLXNlcmlmIj4tIENvdWxkIGNvbnRhaW4gY2xhaW1zIGFib3V0IHRoZSB1
c2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGlu
ayB0aGUgcHJvYmxlbSBpcyB0aGF0IHNvbWUgcGVvcGxlIGFyZSB1c2luZyDigJxjbGFpbXPigJ0g
dG8gbWVhbiAjMSBhbmQgc29tZSB0byBtZWFuICMzLiBJdOKAmXMgY2xlYXJseSAjMSBpbiBPSURD
LiBCdXQ6IEl04oCZcyBpbXBvcnRhbnQgdG8gcmVtZW1iZXIsIHdoZW4gdGFsa2luZyBhYm91dCBP
SURDLA0KIHRoYXQgYW4gSWRQIGluIE9JREMgY29tYmluZXMgYW4gQVMgYW5kIGFuIFJTIGludG8g
b25lIGVudGl0eSBmb3IgaWRlbnRpdHkgaW5mb3JtYXRpb24uIFRoZXJlIGNhbiBiZSBvdGhlciBS
U+KAmXMgYXMgd2VsbCwgYW5kIHRoZXJlIHVzdWFsbHkgYXJlIGluIHRoZSB3aWxkLCBidXQgdGhl
IG9uZSBkZWZpbmVkIGJ5IE9JREMgaXMgdGhlIFVzZXJJbmZvIEVuZHBvaW50LiBUaGUgZmFjdCB0
aGF0IGl0IHJldHVybnMgdXNlciBkYXRhIGRvZXNu4oCZdCBtYWtlDQogaXQgYW55IGxlc3Mgb2Yg
YW4gUlMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwO+KAlCBK
dXN0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4qIElu
IHRoZSB3aWRlciBjb250ZXh0IG9mIHRoaW5ncyBsaWtlIHRoZSBpbmZvcm1hdGlvbiBjbGFpbXMg
aW5zaWRlIGEgSldULCB0aGUgY2xhaW1zIGNvdWxkIGJlIGFib3V0IGxpdGVyYWxseSBhbnl0aGlu
ZywgYnV0IHRoYXTigJlzIG5vdCB3aGF0IHdl4oCZcmUgZGlzY3Vzc2luZyBoZXJlIGFuZCBpdOKA
mXMNCiBub3QgaG93IGl04oCZcyBiZWluZyB1c2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBKdWwgMjQsIDIwMjAs
IGF0IDE6MjQgUE0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdt
YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIE9wZW5JRCBDb25u
ZWN0IChPSURDKSwgdGhlIENsaWVudCBjYW4gb2J0YWluIENsYWltcyBkaXJlY3RseSBmcm9tIHRo
ZSBPUCBpbiBhbiBJRCBUb2tlbiwgb3IgdGhlIENsaWVudCBjYW4gb2J0YWluIENsYWltcyB1c2lu
ZyBhbiBhY2Nlc3MgdG9rZW4gdG8gY2FsbCB0aGUgVXNlckluZm8gZW5kcG9pbnQsDQogYSBQcm90
ZWN0ZWQgUmVzb3VyY2VbMV0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi
PlRoZSBDbGFpbXMgYXJlIGFib3V0IHRoZSBVc2VyIChub3QgYSBSTykuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z
ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gWEF1dGgsIEknbSBwcm9wb3Npbmcg
dGhlIENsaWVudCBtYXkgb2J0YWluIGJhcmUgY2xhaW1zIGZyb20gdGhlIEdTIGRpcmVjdGx5IGlu
IGFkZGl0aW9uIHRvIHRoZSBtZWNoYW5pc21zIGluIE9ESUMuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U28gSSBkb24ndCB0aGluayB3ZSBhcmUgY2hhbmdp
bmcgdGhlIGRlZmluaXRpb24gb2YgQ2xhaW0gZnJvbSBob3cgaXQgaGFzIGJlZW4gdXNlZCBpbiBP
SURDLCBhbmQgSSBmYWlsIHRvIHNlZSBhbnkgcmVhc29uIHRvIE5PVCB1c2UgQ2xhaW0uPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv
dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SnVzdGluOiB5b3UgYWxs
dWRlIHRvIENsYWltcyBiZWluZyBhYm91dCBhIHBhcnR5IG90aGVyIHRoYW4gdGhlIFVzZXIuIFdv
dWxkIHlvdSBwcm92aWRlIGFuIGV4YW1wbGU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+L0RpY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj5bMV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VXNlckluZm8gRW5kcG9pbnQ8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5Qcm90ZWN0ZWQgUmVzb3VyY2UgdGhhdCwgd2hlbiBwcmVzZW50
ZWQgd2l0aCBhbiBBY2Nlc3MgVG9rZW4gYnkgdGhlIENsaWVudCwgcmV0dXJucyBhdXRob3JpemVk
IGluZm9ybWF0aW9uIGFib3V0IHRoZSBFbmQtVXNlciByZXByZXNlbnRlZCBieSB0aGUgY29ycmVz
cG9uZGluZyBBdXRob3JpemF0aW9uDQogR3JhbnQuIFRoZSBVc2VySW5mbyBFbmRwb2ludCBVUkwg
TVVTVCB1c2UgdGhlIGh0dHBzIHNjaGVtZSBhbmQgTUFZIGNvbnRhaW4gcG9ydCwgcGF0aCwgYW5k
IHF1ZXJ5IHBhcmFtZXRlciBjb21wb25lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGltZyBib3JkZXI9IjAiIGlk
PSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2Vu
ZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRlbnQm
YW1wO2d1aWQ9NDIzYWY3NmItNDBmNS00YmFiLWFjNTktMmI2NDA5NDRlNWNkIj48L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBGcmksIEp1bCAyNCwgMjAyMCBh
dCA1OjU4IEFNIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5l
ZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7
bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSB3YW50IHRvIGZvY3VzIG9uIG9uZSBhc3BlY3Qg
aGVyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn
aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
QSBDbGFpbSBpcyBhIHdlbGwgdW5kZXJzdG9vZCB0ZXJtIGluIHRoZSBmaWVsZC4gV2Ugc2hvdWxk
IHVzZSBpdC4gSXQgaXMgc3RpbGwgYSBDbGFpbSBpZiBpdCBjb21lcyBkaXJlY3RseSBmcm9tIHRo
ZSBHUyBvciBmcm9tIGFuIFJTLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZiI+SSBkbyBub3QgdW5kZXJzdGFuZCB3aHkgYSBSZXNvdXJjZSByZWxlYXNlIGJ5
IGFuIFJTIHNoYWxsIGJlIGggdG8gYXMgYSBjbGFpbSwgZXZlbiBpZiB0aGUgY29udGVudCBvZiB0
aGUgUmVzb3VyY2UgaXMgYW4gYXNzZXJ0aW9uLiBJdCB3aWxsIGxlYWQgdG8gY29uZnVzaW9uLiBJ
ZiB3ZSBsaW1pdCBjbGFpbXMNCiB0byBpbmZvcm1hdGlvbiBHUyByZWxlYXNlcyBpbnRvIFRva2Vu
LCBVc2VyIEluZm8sIGFuZCBvdGhlciBvYmplY3RzIGl0IHJldHVybnMsIHRoaXMgd2lsbCBoZWxw
IHNlcGFyYXRlIHJlc3BvbnNpYmlsaXRpZXMgYmV0d2VlbiBHUyBhbmQgUlMuIEFzIHNvb24gYXMg
UlMgc2VydmljZXMgYW5kIGluZm9ybWF0aW9uLCB0aGlzIGlzIGNhbGxlZCBhIFJlc291cmNlLCBu
byBtYXR0ZXIgdGhlIG5hdHVyZSBvZiB0aGUgY29udGVudCBvZiB0aGF0IGluZm9ybWF0aW9uLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBpcyBleGFjdGx5IHdoeSBJIGRvbuKAmXQgdGhpbmsg
d2Ugc2hvdWxkIHVzZSDigJxjbGFpbeKAnSBpbiB0aGUgd2F5IHRoYXQgd2XigJlyZSB1c2luZyBp
dC4gWWVzLCBhIOKAnGNsYWlt4oCdIGNvdWxkIGNvbWUgYmFjayB0aHJvdWdoIGFuIFJTIOKAlCBi
dXQgaW4gdGhlIGNvbnRleHQgb2YgR05BUCwgdGhhdCBtYWtlcw0KIGl0IGEgcmVzb3VyY2UuIFNv
IHdlIG5lZWQgYSBkaWZmZXJlbnQgd29yZCBmb3IgZGF0YSBjb21pbmcgYmFjayBkaXJlY3RseSBm
cm9tIHRoZSBBUyB0byB0aGUgY2xpZW50LiBTb21ldGltZXMgaXTigJlzIGdvaW5nIHRvIGJlIGFi
b3V0IHRoZSB1c2VyLCBhbmQgdGhhdOKAmXMgd2hhdCB3ZeKAmXJlIGdvaW5nIHRvIGZvY3VzIG9u
IGhlcmUsIGJ1dCBzaW5jZSB5b3UgY2FuIGFsc28gZ2V0IGluZm9ybWF0aW9uIGFib3V0IHRoZSB1
c2VyIGZyb20gYSByZXNvdXJjZQ0KIHdlIGNhbuKAmXQganVzdCBjYWxsIGl0IGEg4oCcY2xhaW3i
gJ0uIEkgdGhpbmsgdGhpcyBoYXMgYmVlbiBhdCB0aGUgaGVhcnQgb2YgYSBsb3Qgb2YgY29uZnVz
aW9uIGluIHJlY2VudCB0aHJlYWRzLCBhcyB3ZWxsIGFzIGNvbmZ1c2lvbiBhYm91dCB0aGUgc2Nv
cGUgb2YgdGhlIGluY2x1c2lvbiBvZiBpZGVudGl0eSBpbiB0aGUgR05BUCBwcm90b2NvbC48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5TbyBsZXTigJlzIGxl
dCDigJxjbGFpbeKAnSBtZWFuIHdoYXQgaXQgYWxyZWFkeSBkb2VzLCBhbmQgbGV04oCZcyBmaW5k
IGEgd2F5IHRvIGRpZmZlcmVudGlhdGUgYmV0d2VlbiB3aGVuIGFuIGl0ZW0sIGNsYWltIG9yIG90
aGVyd2lzZSwmbmJzcDsmbmJzcDtjb21lcyBhcyBwYXJ0IG9mIGEgcmVzb3VyY2UgYW5kIHdoZW4g
aXQgY29tZXMNCiBiYWNrIGRpcmVjdGx5LiBUaGlzIGlzIGFuIGltcG9ydGFudCBkaWZmZXJlbnRp
YXRpbmcgZmVhdHVyZSBmb3IgR05BUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj5Tb21lIHN0cmF3IG1hbiBpZGVhcywgbm9uZSBvZiB3aGljaCBJ4oCZbSBw
YXJ0aWN1bGFybHkgaW4gbG92ZSB3aXRoOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOy0gZGlyZWN0IGRhdGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m
bmJzcDstIHByb3BlcnRpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDstIGRldGFpbHM8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmIj4mbmJzcDstIHN0YXRlbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl
bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgaW1wb3J0YW50IHRoaW5nIGhlcmUgaXMgdGhh
dCBpdOKAmXMgbm90IG5lY2Vzc2FyaWx5IDphYm91dDogdGhlIFJPLCBhbmQgdGhhdCBpdCBpcyA6
bm90OiBpbiBhIHJlc291cmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
ZiI+QW55IG90aGVyIHRob3VnaHRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPiZuYnNwO+KAlCBKdXN0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48
L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LS08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkZyYW5jaXMgUG91YXRjaGE8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5Dby1Gb3VuZGVyIGFuZCBUZWNobmljYWwgTGVhZDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPmFkb3JzeXMgR21iSCAmYW1wOyBDby4gS0c8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm
Ij48YSBocmVmPSJodHRwczovL2Fkb3JzeXMtcGxhdGZvcm0uZGUvc29sdXRpb25zLyIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vYWRvcnN5cy1wbGF0Zm9ybS5kZS9zb2x1dGlvbnMvPC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LHNhbnMtc2VyaWYiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPi0tPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5GcmFuY2lzIFBvdWF0Y2hhPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
Q28tRm91bmRlciBhbmQgVGVjaG5pY2FsIExlYWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5hZG9yc3lz
IEdtYkggJmFtcDsgQ28uIEtHPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly9h
ZG9yc3lzLXBsYXRmb3JtLmRlL3NvbHV0aW9ucy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Fk
b3JzeXMtcGxhdGZvcm0uZGUvc29sdXRpb25zLzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp
O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQt
c3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8L3NwYW4+PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OyxzYW5zLXNlcmlmIj4tLTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnJhbmNpcyBQb3VhdGNoYTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt
c2VyaWYiPkNvLUZvdW5kZXIgYW5kIFRlY2huaWNhbCBMZWFkPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+
YWRvcnN5cyBHbWJIICZhbXA7IENvLiBLRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0
dHBzOi8vYWRvcnN5cy1wbGF0Zm9ybS5kZS9zb2x1dGlvbnMvIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly9hZG9yc3lzLXBsYXRmb3JtLmRlL3NvbHV0aW9ucy88L2E+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CH2PR00MB0679BFFBE4251753CCECA430F5720CH2PR00MB0679namp_--


From nobody Mon Jul 27 05:51: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 0D0A93A1950 for ; Mon, 27 Jul 2020 05:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.981
X-Spam-Level: 
X-Spam-Status: No, score=-1.981 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, MALFORMED_FREEMAIL=0.116, MIME_QP_LONG_LINE=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 Gr38NQ0rVwo2 for ; Mon, 27 Jul 2020 05:51:44 -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 2CCB03A195F for ; Mon, 27 Jul 2020 05:51:27 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id c80so14060278wme.0 for ; Mon, 27 Jul 2020 05:51:26 -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 :mime-version; bh=XYUMxs9+01TDb+qUJTd/M6qeYK4PaTUKHnX3OR2cGjk=; b=rZVg0etIx2+dkfOOcoBWzPc4EWfhdVf1y6sEuwUnNGHHeOO+MAN//tWy0UYkeOF7+8 3p9/+/RnXS/++bPP8YL9qjp//IqkU5puhfUATQHObD4PtJ3OqfE4BqvN+scmuq9C2FWd oigCeu3LTAS4w+JbfpKO1uBdnrIr5xLaQ5DD9ZVHx+3ojVSGunDF5nP/fTlxXDs3cuMx brAVb6oCWq9U10MZTQfbwULC7hNeokyimhPYz0EOfJs4sOxyGP6H1y9wL1w+Aiu2Z/Ut W9JKiN9OxuyWn2oHF8uY1mOC1UXqzs91rSEEKd3B6DWbuVBylnDoN8Lwb5l/uu+Do6QC HHBA==
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:mime-version; bh=XYUMxs9+01TDb+qUJTd/M6qeYK4PaTUKHnX3OR2cGjk=; b=IEzRSrip7f6bwdJ7T7BJvKpF7ejHwUdYpjWRCX/4laK+ts/Mswspebdzjb16vf+1b6 vuB//5XC9fnlFwL7irF8xoYItllvSqWDn6APoPL5R1nuky5h+oCzRU1pKTlR7EAuxiGm huINSGKVAz+uUjIQPMNN7Q9UqZknbcrtaEpfKrWDBYvJ+SiBsK8q0NgVkwalpDOGUBiu 0GtlsxJ4CyoTEYrFYmpKgY4gHHpWsgiyfleql39RYBICZ+sl/JbMLTjBYx750AslcYFx gv1pFbllch8+IMbiVlSGPJlFuB9J8h0eUgLnSvyOKCEkvdvow3p7R6/J2In6UKcr7mO7 uklg==
X-Gm-Message-State: AOAM5302g8VxV4QKfnpLElYBxBMjmd305f9yGAGP6WOyHkkAvAgJrxlv kjmIMwuAa1oR26J5qRhOm1YYGvvQ
X-Google-Smtp-Source: ABdhPJwhdvvXlDrh0lZRglrCjvE309CEt92adswb61lyEYa1WitjmrNpcV6Yj4H+fe7VSRONT5TPjw==
X-Received: by 2002:a1c:c343:: with SMTP id t64mr15124887wmf.168.1595854285352;  Mon, 27 Jul 2020 05:51:25 -0700 (PDT)
Received: from [10.0.0.140] (bzq-109-66-125-13.red.bezeqint.net. [109.66.125.13]) by smtp.gmail.com with ESMTPSA id p6sm12751928wmg.0.2020.07.27.05.51.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2020 05:51:24 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.39.20071300
Date: Mon, 27 Jul 2020 15:51:23 +0300
From: Yaron Sheffer 
To: GNAP Mailing List 
CC: Leif Johansson 
Message-ID: <29223BBB-4FCF-4A98-85A9-EB1A144ABE48@gmail.com>
Thread-Topic: Help wanted!
X-Priority: 2
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3678709884_468145535"
Archived-At: 
Subject: [Txauth] Help wanted!
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, 27 Jul 2020 12:51:46 -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_3678709884_468145535
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

If you are willing to take minutes at the GNAP session or to be a Jabber sc=
ribe, please let me and Leif know.

=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


--B_3678709884_468145535
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


If you are =
willing to take minutes at the GNAP session or to be a Jabber scribe, please=
 let me and Leif know.
 
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


--B_3678709884_468145535--



From nobody Mon Jul 27 06:46:43 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 7A21B3A18B5 for ; Mon, 27 Jul 2020 06:46:40 -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 X7yIk8oz7bEo for ; Mon, 27 Jul 2020 06:46:35 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450: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 371053A0E69 for ; Mon, 27 Jul 2020 06:46:34 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id b30so9013901lfj.12 for ; Mon, 27 Jul 2020 06:46:34 -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=nru+EYUiebr7yDetxA968+SED1XNSKLwgJNXZ9A5Kt4=; b=GWMC2rSAVjcrXwbSbchQjXoQCqaoCSUIuh0dezS3JYhYukDbEzTphje67ynxUFZ6kE vIEgI5Jc4F3F1YWUts3+AhTQRAkf4xByUyjWun6vz98lnELKQZi2N+jqzXIhVAAJ/P/y 3mJCwNOonlABTk5sweziLW1z3dE0I0qbaTn7nfvOwC90zpEy8NKPCjs8qPvoPhbqQxNs 3GnwQ8I2XDGGOqRFJNGcOUQ7b9/b2sIhPdOna2CAmD2wUAzkea91gDbkZj0FriPRVKZZ DYy18bYryPLso1xFb1d8hmCWxpmrEq0foeyMaQo9izNKvHeXyDSte1xi3AEaAVpJrBjY CKug==
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=nru+EYUiebr7yDetxA968+SED1XNSKLwgJNXZ9A5Kt4=; b=WSlZYZIFq7Idp0cjRU5JfhIhb+DWk7jkM+GU252zr4LECAy3QMwk5a6T5HZHtJ127o ELP28emV5o6gJh4YozwPhaLlvU/JrIeoZTTcXwcx0HEo0h55j8yMuo0YQbp8YBts3Roo oitJkSE7d50iKjb3CyKkk7mxddzRdzDG4jAWbYjlck0WbkVbXIM0aUaTRqXohi5HufnE 2ggePYchDdunFfJn98j1NUKHCYj/sQXKRjKnYNt37OXqiAXgGStCVcdu0LGZiBj4GOpn /uVuwt2yPpOsNIctFo2A71RXKpAN/GM5fGz9sX25OgZnyu/9Fb7sKOrR1ix/gqzZzSz/ 0CZg==
X-Gm-Message-State: AOAM531o2aZ8sKIjHxjdBp2dqd29xSUb6HCmRfGxGyS1IgOGTnWH3tH6 VnJ+uM6y+KpYxm38PLTf5KCTCWyq9gjF/wuGB8Y=
X-Google-Smtp-Source: ABdhPJy9bnjxUqmypSr8IW+KNND7OEste2dimy4Ct1BM33cq+Bj915TK2UfnNpQEe2ALSO3YhMMCNhNJijx4+UAQ/to=
X-Received: by 2002:a19:fc14:: with SMTP id a20mr11887318lfi.0.1595857592073;  Mon, 27 Jul 2020 06:46:32 -0700 (PDT)
MIME-Version: 1.0
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>  
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 27 Jul 2020 06:45:55 -0700
Message-ID: 
To: Justin Richer 
Cc: Francis Pouatcha , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="000000000000e340fd05ab6c8c40"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 13:46:41 -0000

--000000000000e340fd05ab6c8c40
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

A slide in my presentation today may clarify how I am thinking about it.

On Mon, Jul 27, 2020 at 4:23 AM Justin Richer  wrote:

> Since you focused on the individual elements of the straw man examples yo=
u
> requested instead of the overall problem, I think you=E2=80=99re missing =
the core
> point. Let me bring it back to a concrete example:
>
> In Xauth currently, you can use the =E2=80=9Cclaims=E2=80=9D query syntax=
 from OIDC to
> request user claims inside the =E2=80=9Cclaims.oidc=E2=80=9D object on re=
quest. However,
> Xauth currently uses =E2=80=9Cuserinfo=E2=80=9D to mark information comin=
g back directly to
> the client as JSON. Since =E2=80=9Cuserinfo=E2=80=9D is already defined b=
y OIDC in this
> context to indicate information that should come back from the UserInfo
> Endpoint (and therefore as a resource, with rights tied to an access
> token), the Xauth approach would need a name other than =E2=80=9Cuserinfo=
=E2=80=9D here to
> indicate such claims coming back directly as JSON.
>
> What would you call that field?
>
> Because whatever that field would be called is exactly the kind of data
> differentiation that I=E2=80=99m talking about here. And considering that=
 Xauth
> already does differentiate between claims coming back as resources, as
> assertions, and direct JSON, I think it=E2=80=99s clear that it does matt=
er.
>
>  =E2=80=94 Justin
>
>
> On Jul 24, 2020, at 4:57 PM, Dick Hardt  wrote:
>
> It is not clear to me what it matters if a Claim comes from an RS, or fro=
m
> the GS, so I don't see a need to differentiate them.
>
> I would include verifiable credentials and user-bound keys as Claims.
>
> All the payment processing information I have seen has been in RAR. When
> would the Client get payment processing directly from the GS?
>
> What is your example for distributed networks storage locations? If what
> is stored is a statement about the user, then I would consider that a Cla=
im
> as well.
>
> We disagree on how to map OIDC to GNAP.  The direct data is a claims
> request, the data coming indirectly is an access token request.
>
>
>
> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer  wrote:
>
>> Since we=E2=80=99re already talking about returning claims as direct dat=
a as well
>> as a part of the resource API being protected, so we already need a way =
to
>> differentiate the two kinds of items. Just calling it =E2=80=9Cclaims=E2=
=80=9D doesn=E2=80=99t
>> help, because as you=E2=80=99ve pointed out they could show up in both p=
laces. So
>> yes, defining that difference is something we should worry about now, ev=
en
>> if the core protocol only uses it for claims.
>>
>> The two forms of direct data that XYZ returns are subject identifiers (a
>> subset of identity claims) and assertions =E2=80=94 the latter being a c=
ontainer
>> not just for identity claims but also authentication information and oth=
er
>> elements. Assertions are not claims themselves.
>>
>> Other use cases that have been brought up include verifiable credentials
>> and proofs, user-bound keys, payment processing information, and
>> distributed network storage locations. I=E2=80=99m sure there are a lot =
more. To
>> me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D but not subse=
ts of =E2=80=9Cclaims=E2=80=9D.
>> GNAP shouldn=E2=80=99t be defining what all of these look like, but it s=
hould
>> define a way to talk about them.
>>
>> I think different top-level request objects are better suited for
>> different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=
=E2=80=9D request,
>> which allows targeting of its claims information into different return
>> buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D request at t=
he very least. I
>> don=E2=80=99t think GNAP should define how to do this specific combinati=
on, that
>> should be for OIDF to debate and apply. The same with a DID service base=
d
>> query, or Presentation Exchange [1], or anything else that people want t=
o
>> come up with.
>>
>> In my view, GNAP should define query structures for two things: rights
>> that get tied to an access token and data that comes back directly to th=
e
>> client. For the latter, I think we can do some very limited and very use=
ful
>> specific items, which is what I=E2=80=99ve put into XYZ.
>>
>>  =E2=80=94 Justin
>>
>> [1] https://identity.foundation/presentation-exchange/
>>
>> On Jul 24, 2020, at 3:58 PM, Dick Hardt  wrote:
>>
>> I agree we want GNAP to be a strong foundation.
>>
>> Do you have an example of other "direct data"? If so, do you expect it t=
o
>> be defined in the core protocol?
>>
>> I would expect an extension for other "direct data" to define top level
>> objects, and an appropriate definition for that "direct data".
>>
>> My "do we need to worry about it now" comment was on creating a generic
>> term for "direct data". Unless we are solving those now, we can let furt=
her
>> work define that "direct data" explicitly.
>>
>>
>>
>>
>> =E1=90=A7
>>
>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer  wrote:
>>
>>> Yes, I do think we need to worry about it to the extent that we are not
>>> creating something that is over-fit to a limited set of use cases.
>>>
>>> GNAP should be a foundation that many amazing new things can be built o=
n
>>> top of.
>>>
>>>  =E2=80=94 Justin
>>>
>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt  wrote:
>>>
>>> Justin, thanks for clarifying.
>>>
>>> What are some examples of other "direct data" that the GS may return? I=
f
>>> it is not in core GNAP, do we need to worry about now? We can then give=
 the
>>> direct data from the GS that is not a claim, an appropriate name in tha=
t
>>> document.
>>>
>>>
>>>
>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer  wrote:
>>>
>>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m say=
ing. I agree that
>>>> =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But the=
 AS could return
>>>> other data directly to the client that isn=E2=80=99t about the user. T=
hose aren=E2=80=99t
>>>> =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=
=80=9Cclaims=E2=80=9D can come back
>>>> from places other than directly, then we shouldn=E2=80=99t call everyt=
hing that
>>>> comes back a =E2=80=9Cclaim=E2=80=9D.
>>>>
>>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean what=
 it already means and
>>>> come up with a new word to mean =E2=80=9Cthings that come back directl=
y from the
>>>> AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s m=
ore complete definitions, but
>>>> to simplify:
>>>>
>>>> Claims:
>>>> - information about the user
>>>> - can come back directly from the AS
>>>> - can come back in a resource from the RS
>>>>
>>>> Resource:
>>>> - Returned from an RS
>>>> - Protected by access token
>>>> - Could contain claims about the user
>>>>
>>>> Direct data (or some better name):
>>>> - Returned directly from AS
>>>> - Could contain claims about the user
>>>>
>>>> I think the problem is that some people are using =E2=80=9Cclaims=E2=
=80=9D to mean #1
>>>> and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99=
s important to
>>>> remember, when talking about OIDC, that an IdP in OIDC combines an AS =
and
>>>> an RS into one entity for identity information. There can be other RS=
=E2=80=99s as
>>>> well, and there usually are in the wild, but the one defined by OIDC i=
s the
>>>> UserInfo Endpoint. The fact that it returns user data doesn=E2=80=99t =
make it any
>>>> less of an RS.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> * In the wider context of things like the information claims inside a
>>>> JWT, the claims could be about literally anything, but that=E2=80=99s =
not what
>>>> we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s be=
ing used.
>>>>
>>>>
>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt  wrote:
>>>>
>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from
>>>> the OP in an ID Token, or the Client can obtain Claims using an access
>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>
>>>> The Claims are about the User (not a RO).
>>>>
>>>> In XAuth, I'm proposing the Client may obtain bare claims from the GS
>>>> directly in addition to the mechanisms in ODIC.
>>>>
>>>> So I don't think we are changing the definition of Claim from how it
>>>> has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>
>>>> Justin: you allude to Claims being about a party other than the User.
>>>> Would you provide an example?
>>>>
>>>> /Dick
>>>>
>>>> [1]
>>>>
>>>> UserInfo Endpoint
>>>> Protected Resource that, when presented with an Access Token by the
>>>> Client, returns authorized information about the End-User represented =
by
>>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST =
use
>>>> the https scheme and MAY contain port, path, and query parameter compo=
nents.
>>>>
>>>>
>>>>
>>>>
>>>> =E1=90=A7
>>>>
>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote:
>>>>
>>>>> I want to focus on one aspect here:
>>>>>
>>>>>
>>>>>> A Claim is a well understood term in the field. We should use it. It
>>>>>> is still a Claim if it comes directly from the GS or from an RS.
>>>>>>
>>>>> I do not understand why a Resource release by an RS shall be h to as =
a
>>>>> claim, even if the content of the Resource is an assertion. It will l=
ead to
>>>>> confusion. If we limit claims to information GS releases into Token, =
User
>>>>> Info, and other objects it returns, this will help separate
>>>>> responsibilities between GS and RS. As soon as RS services and inform=
ation,
>>>>> this is called a Resource, no matter the nature of the content of tha=
t
>>>>> information.
>>>>>
>>>>>
>>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Cclai=
m=E2=80=9D in the way
>>>>> that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could com=
e back through an RS =E2=80=94 but in
>>>>> the context of GNAP, that makes it a resource. So we need a different=
 word
>>>>> for data coming back directly from the AS to the client. Sometimes it=
=E2=80=99s
>>>>> going to be about the user, and that=E2=80=99s what we=E2=80=99re goi=
ng to focus on here,
>>>>> but since you can also get information about the user from a resource=
 we
>>>>> can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this ha=
s been at the heart of a lot
>>>>> of confusion in recent threads, as well as confusion about the scope =
of the
>>>>> inclusion of identity in the GNAP protocol.
>>>>>
>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already doe=
s, and let=E2=80=99s find a way
>>>>> to differentiate between when an item, claim or otherwise,  comes as =
part
>>>>> of a resource and when it comes back directly. This is an important
>>>>> differentiating feature for GNAP.
>>>>>
>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in love =
with:
>>>>>
>>>>>  - direct data
>>>>>  - properties
>>>>>  - details
>>>>>  - statements
>>>>>
>>>>> The important thing here is that it=E2=80=99s not necessarily :about:=
 the RO,
>>>>> and that it is :not: in a resource.
>>>>>
>>>>> Any other thoughts?
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>
>>>>
>>>
>>
>

--000000000000e340fd05ab6c8c40
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


A slide in my presentation today may clarify how I am thin=
king about it.

On Mon, Jul 27, 2020 at 4:23 AM Justin Richer <jricher@mit.edu> wrote:
Since you focused on the individual elements of the straw man exa=
mples you requested instead of the overall problem, I think you=E2=80=99re =
missing the core point. Let me bring it back to a concrete example:
In Xauth currently, you can use the =E2=80=9Cclaims=E2=80=9D qu=
ery syntax from OIDC to request user claims inside the =E2=80=9Cclaims.oidc=
=E2=80=9D object on request. However, Xauth currently uses =E2=80=9Cuserinf=
o=E2=80=9D to mark information coming back directly to the client as JSON. =
Since =E2=80=9Cuserinfo=E2=80=9D is already defined by OIDC in this context=
 to indicate information that should come back from the UserInfo Endpoint (=
and therefore as a resource, with rights tied to an access token), the Xaut=
h approach would need a name other than =E2=80=9Cuserinfo=E2=80=9D here to =
indicate such claims coming back directly as JSON.=C2=A0

What would you call that field?

Because wha=
tever that field would be called is exactly the kind of data differentiatio=
n that I=E2=80=99m talking about here. And considering that Xauth already d=
oes differentiate between claims coming back as resources, as assertions, a=
nd direct JSON, I think it=E2=80=99s clear that it does matter.
<=
br>
=C2=A0=E2=80=94 Justin


On Jul 24, 2020, at 4:57 PM, Dick Hardt <dick.hardt@gmail.com> wrot=
e:

It is not clear to me what it matter=
s if a Claim comes from an RS, or from the GS, so I don't see a need to=
 differentiate them.

I would include verifiable cr=
edentials and user-bound keys as Claims.

All the p=
ayment processing information I have=C2=A0seen has been in RAR. When would=
=C2=A0the Client get payment processing directly from the GS?
What is your example for distributed networks storage locations=
? If what is stored is a statement about the user, then I would consider th=
at a Claim as well.

We disagree on how to map OIDC=
 to GNAP.=C2=A0 The direct data is a claims request, the data coming indire=
ctly is an access token request.


<=
br>
On Fri,=
 Jul 24, 2020 at 1:39 PM Justin Richer <jricher@mit.edu> wrote:
Since we=E2=80=99re already talkin=
g about returning claims as direct data as well as a part of the resource A=
PI being protected, so we already need a way to differentiate the two kinds=
 of items. Just calling it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, b=
ecause as you=E2=80=99ve pointed out they could show up in both places. So =
yes, defining that difference is something we should worry about now, even =
if the core protocol only uses it for claims.

The two fo=
rms of direct data that XYZ returns are subject identifiers (a subset of id=
entity claims) and assertions =E2=80=94 the latter being a container not ju=
st for identity claims but also authentication information and other elemen=
ts. Assertions are not claims themselves.=C2=A0

Ot=
her use cases that have been brought up include verifiable credentials and =
proofs, user-bound keys, payment processing information, and distributed ne=
twork storage locations. I=E2=80=99m sure there are a lot more. To me, thes=
e are subsets of the =E2=80=9Cdirect data=E2=80=9D but not subsets of =E2=
=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be defining what all of these=
 look like, but it should define a way to talk about them.

I think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=
=80=9D request, which allows targeting of its claims information into diffe=
rent return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D req=
uest at the very least. I don=E2=80=99t think GNAP should define how to do =
this specific combination, that should be for OIDF to debate and apply. The=
 same with a DID service based query, or Presentation Exchange [1], or anyt=
hing else that people want to come up with.

In my =
view, GNAP should define query structures for two things: rights that get t=
ied to an access token and data that comes back directly to the client. For=
 the latter, I think we can do some very limited and very useful specific i=
tems, which is what I=E2=80=99ve put into XYZ.

=C2=A0=E2=80=94 Justin

[1]=C2=A0https=
://identity.foundation/presentation-exchange/

On Jul 24, 2020, at 3:58 PM, Dick Hardt <dick.hardt@gmail.com> w=
rote:

I agree we want GNAP to be a strong fo=
undation.=C2=A0

Do you have an example of other "di=
rect data"? If so, do you expect it to be defined in the core protocol=
?

I would expect an extension for other "dire=
ct data" to define top level objects, and an appropriate definition fo=
r that "direct data".

My "do we nee=
d to worry about it now" comment was on creating a generic term for &q=
uot;direct data". Unless we are solving those now, we can let further =
work define that "direct data" explicitly.




3D""=E1=90=A7

On Fri, Jul 24, 2020 at 12:42 PM Justin Richer <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">
Yes, I do think we ne=
ed to worry about it to the extent that we are not creating something that =
is over-fit to a limited set of use cases.=C2=A0

GNAP sh=
ould be a foundation that many amazing new things can be built on top of.

=C2=A0=E2=80=94 Justin

On Jul 24, 2020, at 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrot=
e:

Justin, thanks for clarifying.

What are some examples of other "direct data" that the G=
S may return? If it is not in core GNAP, do we need to worry about now? We =
can then give the direct data from the GS that is not a claim, an appropria=
te name in that document.



On Fri, Jul 24=
, 2020 at 11:46 AM Justin Richer <jricher@mit.edu> wrote:
Dick: No, I think you=E2=80=99re misunde=
rstanding what I=E2=80=99m saying. I agree that =E2=80=9Cclaims=E2=80=9D ar=
e about the user, in this context*. But the AS could return other data dire=
ctly to the client that isn=E2=80=99t about the user. Those aren=E2=80=99t =
=E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=80=9Cc=
laims=E2=80=9D can come back from places other than directly, then we shoul=
dn=E2=80=99t call everything that comes back a =E2=80=9Cclaim=E2=80=9D.
I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D t=
o mean what it already means and come up with a new word to mean =E2=80=9Ct=
hings that come back directly from the AS=E2=80=9D. These aren=E2=80=99t me=
ant to replace Francis=E2=80=99s more complete definitions, but to simplify=
:

Claims:
	- information about the user
	- can come back directly from the AS
	- can come back in a resource from=
 the RS

Resource:
	- Returned from an RS
	- Protected by access token
	- Could contain claims about the user

Direct data (or some better name):
	- Returned directly from AS
=
	- Could contain claims about t=
he user

I think the problem is that some people ar=
e using =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. It=E2=80=
=99s clearly #1 in OIDC. But: It=E2=80=99s important to remember, when talk=
ing about OIDC, that an IdP in OIDC combines an AS and an RS into one entit=
y for identity information. There can be other RS=E2=80=99s as well, and th=
ere usually are in the wild, but the one defined by OIDC is the UserInfo En=
dpoint. The fact that it returns user data doesn=E2=80=99t make it any less=
 of an RS.

=C2=A0=E2=80=94 Justin

* In the wider context of things like the information claims inside a JW=
T, the claims could be about literally anything, but that=E2=80=99s not wha=
t we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s being=
 used.


On Jul 24, 202=
0, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

In OpenID Connect (OIDC), the Client can obtain Claims directly from t=
he OP in an ID Token, or the Client can obtain Claims using an access token=
 to call the UserInfo endpoint, a Protected Resource[1].

The Claims are about the User (not a RO).

In XAut=
h, I'm proposing the Client may obtain bare claims from the GS directly=
 in addition to the mechanisms in ODIC.

So I don&#=
39;t think we are changing the definition of Claim from how it has been use=
d in OIDC, and I fail to see any reason to NOT use Claim.

Justin: you allude to Claims being about a party other than the Use=
r. Would you provide an example?

/Dick
<=
br>
[1]
UserInfo Endpoint
Protected Resource that,=
 when presented with an Access Token by the Client, returns authorized info=
rmation about the End-User represented by the corresponding Authorization G=
rant. The UserInfo Endpoint URL MUST use the https scheme and MAY contain p=
ort, path, and query parameter components.



3D""=E1=90=A7
On Fr=
i, Jul 24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspect he=
re:


A Claim is a well understood term in the field=
. We should use it. It is still a Claim if it comes directly from the GS or=
 from an RS.=C2=A0
I do not understand why a R=
esource release by an RS shall be h to as a claim, even if the content of t=
he Resource is an assertion. It will lead to confusion. If we limit claims =
to information GS releases into Token, User Info, and other objects it retu=
rns, this will help separate responsibilities between GS and RS. As soon as=
 RS services and information, this is called a Resource, no matter the natu=
re of the content of that information.
=

This is exactly why I don=E2=80=99t think we should use =E2=
=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =E2=80=
=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in the contex=
t of GNAP, that makes it a resource. So we need a different word for data c=
oming back directly from the AS to the client. Sometimes it=E2=80=99s going=
 to be about the user, and that=E2=80=99s what we=E2=80=99re going to focus=
 on here, but since you can also get information about the user from a reso=
urce we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this =
has been at the heart of a lot of confusion in recent threads, as well as c=
onfusion about the scope of the inclusion of identity in the GNAP protocol.=


So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean=
 what it already does, and let=E2=80=99s find a way to differentiate betwee=
n when an item, claim or otherwise,=C2=A0=C2=A0comes as part of a resource =
and when it comes back directly. This is an important differentiating featu=
re for GNAP.

Some straw man ideas, none of which I=
=E2=80=99m particularly in love with:

=C2=A0- dire=
ct data
=C2=A0- properties
=C2=A0- details
=
=C2=A0- statements

The important thing here is tha=
t it=E2=80=99s not necessarily :about: the RO, and that it is :not: in a re=
source.

Any other thoughts?

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













--000000000000e340fd05ab6c8c40--


From nobody Mon Jul 27 06:49: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 5CD4B3A1930 for ; Mon, 27 Jul 2020 06:49: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_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 A72Dy8sxBt8K for ; Mon, 27 Jul 2020 06:49:21 -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 C5D7B3A0E60 for ; Mon, 27 Jul 2020 06:49:20 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id d17so17304326ljl.3 for ; Mon, 27 Jul 2020 06:49:20 -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=1nWYFMXjR8/VUliuR5zBWyw33Ez2XVwtN9HhhoioEZw=; b=couUeUiua93XO/SkqY8DjTSWrazp9fjE/D7aaS01BTk6QExZUDSrI4tM3GFSWlWREr qx1LHqbe2Gcti+bim/mPEJpL9EMc4wbz+P7A9NSw5DtJm6hFyAGiSyZ4cF/7cmOUofZX AgQXMs+xAFtNDf83CW1abTmKR7DAdWw7/RK5dPg+MUMFK/xufUNvKZVK5Z5GZTSITcy2 yPmDDhCWxMKHkmvyQpVtgWsjcoVuXR1NF5iztYiU4zWHiA6QmbpNa2Y+iTBu692J2wDc j0pEzufpbGVvrxd+A93a4tGC9fzcPUJtTZ5uNpuKnoJZn6QICleAlJz91oNrkkjviLtJ avMQ==
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=1nWYFMXjR8/VUliuR5zBWyw33Ez2XVwtN9HhhoioEZw=; b=iqBrjg9dU78jZs7s8ITD6hKZm8virKDlDdUEuwkLBcLgfumj+dr0LexBvPdNS+Tv5q yquzrTGiYMSs9KJ8ClYatTSwpvg++aEP3M/U2Y9xorLLoIcmZMvIaIFTjBRfq1B1fIEk E4pKA1nyyOF9aYrVRKrnSlMZGA3ylgz9kGm0isNisKfXv5o8v3gD9h5Ea/SsAF0QTP+S 7c4dGR5xf4qm8XJddXc2MSCYfigLaRi3qdvt7chH3/+I6d+L1tpLkMZflzf20KuFYxBj viFmH7rE4864w9QBrS5nsSHnPdhrajFjqHIbnDADlVmAmmDeh9m7K516xrkIQyNOiLsZ 49yw==
X-Gm-Message-State: AOAM531dDYLdRMq+tyYp8rNnyTKKtXPUS4dKL1Wu/60nxjCrIhHu9dQq Lyo/BK66A6kY2sAQyOKf+Zg3SCQZD9NHF691Zic=
X-Google-Smtp-Source: ABdhPJxOc8r8htlKEWG4JEtIWfaFtyVg2/zXOdkdJdNTm78/RetXgarWeWDDYBUHZ3vYoe4p62wwxwDaZjrzJTsQ3l4=
X-Received: by 2002:a2e:9695:: with SMTP id q21mr2941243lji.437.1595857758698;  Mon, 27 Jul 2020 06:49:18 -0700 (PDT)
MIME-Version: 1.0
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>       
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 27 Jul 2020 06:48:41 -0700
Message-ID: 
To: Justin Richer 
Cc: Francis Pouatcha , txauth@ietf.org,  Tom Jones , Denis ,  Fabien Imbault 
Content-Type: multipart/alternative; boundary="000000000000d1c35805ab6c96b6"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 13:49:29 -0000

--000000000000d1c35805ab6c96b6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

What is Requester or Requesting Party replacing? User?

Is a Role software?

On Mon, Jul 27, 2020 at 5:14 AM Justin Richer  wrote:

> I agree with the separation between =E2=80=9Croles=E2=80=9D and =E2=80=9C=
entities=E2=80=9D. It=E2=80=99s exactly
> that kind of separation into roles that helped OAuth 2 succeed with the A=
S
> and RS roles possibly being the same entity, or not, depending on use cas=
e.
>
> This is one of the reasons that I think =E2=80=9Cuser=E2=80=9D is an over=
loaded term. The
> user is an entity, not a role, and in spite of it being =E2=80=9Cundersto=
od=E2=80=9D in the
> OAuth 2 world, it means a wide variety of other things outside that world=
.
> The same with =E2=80=9Cclient=E2=80=9D, I can=E2=80=99t tell you how many=
 times I=E2=80=99ve had to explain
> what exactly an OAuth =E2=80=9Cclient=E2=80=9D is when I=E2=80=99m teachi=
ng a class.
>
> As for specific recommendations: I=E2=80=99m in favor of the role =E2=80=
=9CRequester=E2=80=9D or
> =E2=80=9CRequesting Party=E2=80=9D. =E2=80=9CClient=E2=80=9D is arguably =
more confusing and harder to
> replace: I had tried to use =E2=80=9CResource Client=E2=80=9D to make =E2=
=80=9Cclient=E2=80=9D more
> specific in XYZ but that turned out to be more confusing than helpful.
>
>  =E2=80=94 Justin
>
> On Jul 27, 2020, at 6:12 AM, Francis Pouatcha  wrote:
>
>
>
> On Sun, Jul 26, 2020 at 11:58 PM Dick Hardt  wrote:
>
>>
>>
>> On Sun, Jul 26, 2020 at 6:45 PM Francis Pouatcha  wrote:
>>
>>> Hello Dick,
>>>
>>> On Sun, Jul 26, 2020 at 9:14 PM Dick Hardt  wrote=
:
>>>
>>>> Hi Francis
>>>>
>>>> User is a well understood term in OIDC and OAuth -- and User means the
>>>> same in both.
>>>>
>>>
>>>> Resource Owner is who owns the resource, and the term is introduced fo=
r
>>>> when the User is NOT the Resource Owner.
>>>>
>>> This distinction is what makes it confusing as we are comparing an
>>> Entity (the User) to a Role (the RO). We need two roles.
>>>
>>
>> Or we could think of them all as entities. The RO is the entity that own=
s
>> the resource. The User is the human that is using the Client.
>>
> When we think of them as entities, we run into conflicts when Entity-User
> eq. Entity-RO.
> When we think of them as roles, Role-User is always !=3D Role-RO
>
>>
>>
>>>
>>>
>>>>
>>>> I also think that Client and Resource Server are well understood terms=
.
>>>>
>>> Looks like contributors on the list still need clarification on the
>>> "orchestration" role of a client.
>>>
>>
>> When I think of orchestration, I think of coordinating, which is not wha=
t
>> I think the Client is doing. The Client wants to consume the Claims and =
the
>> Resources (combined are a Grant). The Client requests the Grant from the
>> Grant Server. Where is the orchestration?
>>
> Look at the client. It is the center of interaction between User, GS and
> RS.
>
>>
>>
>>>
>>>> It is not clear to me why we would want to reinvent these terms.
>>>> Reading over your flows, I think it would be useful to understand the
>>>> requirements you have for your use case, otherwise I fear we will be
>>>> talking past each other.
>>>>
>>> The oAuth flow is there as a memo. The other flow is what I proposed
>>> before. Is there to emphasize we need to work on roles and not on entit=
ies.
>>> It is not a suggestion to rename well known idioms. It is an attempt to
>>> give them a proper definition in the context of this protocol. Definiti=
on
>>> based on their roles in the protocol flows.
>>>
>>
>> I'd like to take a step back and understand the requirements. We are dee=
p
>> into solutions.
>>
> No, we are at the fundamental level. We Have to decide on whether to buil=
d
> a model based on roles oron entities... Then we use the result [ENTITY XO=
R
> ROLES] to define the use cases.
> /Francis
>
>>
>>
>>>
>>> Best regards.
>>> /Francis
>>>
>>>>
>>>> /Dick
>>>>
>>>> =E1=90=A7
>>>>
>>>> On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha 
>>>> wrote:
>>>>
>>>>> Below my opinion on the term Claim:
>>>>>
>>>>> Starting with illustration of parties/roles:
>>>>>
>>>>> User:
>>>>> This word is misleading because of its double role in oAuth2 and OIDC
>>>>> (see below). In GNAP let us have the User play only the role of a
>>>>> requestor. (from Justin reference to "Requesting Party").
>>>>>
>>>>> Client:
>>>>> This is also tightly bound to the oAuth2 and OIDC. The real purpose o=
f
>>>>> this role is to orchestrate resource access on behalf of the "Request=
or".
>>>>> Let us call this for now the "Orchestrator"
>>>>>
>>>>> Resource Owner (RO):
>>>>> This is IMO the most correct word in the entire protocol.
>>>>> Authorisation is always about the owner of something granting access =
to a
>>>>> requestor. It really does not matter if a human interaction is involv=
ed. We
>>>>> will have to forget oAuth2 and OIDC of also calling this a User.
>>>>>
>>>>> Grant Server:
>>>>> Even though the definition of the UserInfo endpoint in OIDC as a
>>>>> protected resource hazardously makes an OP an RS, we shall not repeat=
 the
>>>>> same mistake here. We need a clear separation between roles of GS and=
 RS
>>>>> without overlapping.
>>>>>
>>>>> Resource Server: services resources.
>>>>>
>>>>> Unless I got it wrong, GNAP is about grant negotiation and
>>>>> authorization. This means:
>>>>>
>>>>> GNAP is about some party requesting access to some resources.
>>>>> GNAP is about the resource owner consenting access to that resource.
>>>>> GNAP is about defining the infrastructure that allows the requesting
>>>>> party to access a resource.
>>>>>
>>>>> GNAP designs this infrastructure around:
>>>>> - an orchestrator (what we refer to as a client)
>>>>> - an grant manager (what we refer to as a GS/AS)
>>>>> - the custodian of the resource (what we call a RS)
>>>>>
>>>>> As you see:
>>>>> - The word User does not appear here, and is not relevant as the
>>>>> focus is on authorizing access to a resource.
>>>>> - The word Claim is as well absent.
>>>>>
>>>>> Claim related to RO:
>>>>> The word Claim might start getting visible if the orchestrator (a.k.a=
.
>>>>> Client) or the custodian (a.k.a RS) needs some additional information=
 on
>>>>> the RO to proceed with the access control decision. These claims refe=
r to
>>>>> assertions of attributes or properties of the RO. These claims are is=
sued
>>>>> by the GS as the GS manages interaction with the RO (see below). In t=
his
>>>>> first place information about the requesting party (erroneously.k.a.
>>>>> User) is not relevant to the negotiation and provisioning framework. =
Let us
>>>>> call this sort of claim "RO-Attributes". A better name is welcome.
>>>>>
>>>>> Some advanced resource provisioning frameworks might require knowledg=
e
>>>>> on attributes of the requesting party (e.k.a User). These attributes =
shall
>>>>> be collected by the orchestrator (a.k.a Client) and added to the reso=
urce
>>>>> request. There is no way the GS can collect these attributes as the G=
S role
>>>>> has no interaction with the requesting party (e.k.a User). Let us cal=
l this
>>>>> sort of claim "Requestor-Attributes". A better name will be welcome.
>>>>>
>>>>> Some assertions are even related to the orchestrator (a.k.a Client)
>>>>> itself. This is the case of the public key of an orchestrator used by=
 the
>>>>> GS to "sender constrain" an access token. Let us call this type of cl=
aim
>>>>> "Orchestrator-Attributes".
>>>>>
>>>>> This is a sample mapping of OIDC.
>>>>>
>>>>> +----+    +---+   +---+  +---+
>>>>> |User|    |RP |   |OP |  |RS |
>>>>> +----+    +---+   +-+-+  +---+
>>>>>   |(1) ServiceRequest      |
>>>>>   |-------->|       |      |
>>>>>   |(2) redirect     |      |
>>>>>   |<--------|       |      |
>>>>> =3D=3D=3D User (requestor) passes control to User (RO) =3D=3D=3D
>>>>>   |(3) Auth + Consent      |
>>>>>   |---------------->|      |
>>>>>   |(4) redirect (code)     |
>>>>>   |<----------------|      |
>>>>> =3D=3D=3D User (RO) passes control back to User (requestor) =3D=3D=3D
>>>>>   |(5) get(code)    |      |
>>>>>   |-------->|       |      |
>>>>>   |         |(6) token (code)
>>>>>   |         |------>|      |
>>>>>   |         |(7) token     |
>>>>>   |         |<------|      |
>>>>>   |         |(8) ServiceRequest(token)
>>>>>   |         |------------->|
>>>>>   |         |(9) ServiceResponse
>>>>>   |         |<-------------|
>>>>>   |(10) ServiceResponse    |
>>>>>   |<--------|       |      |
>>>>>   +         +       +      +
>>>>>
>>>>> - RP orchestrates interaction between User and OP to enable the user
>>>>> to obtain the protected resource.
>>>>> - In step 1 & 10 User plays the role of the requestor of the resource=
.
>>>>> - In step 2 User-Browser is used to pass control from User (in his
>>>>> role as the requestor) to User (in his role as the RO)
>>>>> - In step 4 User-Browser is used to pass control from User (in his
>>>>> role as the RO) back to User (in his role as the requestor)
>>>>>
>>>>> When we are talking claims here, we are talking claims on the User (i=
n
>>>>> his role as the RO). The OP does not have any interaction with the Us=
er (in
>>>>> his role as the requestor). In the case of an App2App redirection, th=
e OP
>>>>> can not even assert about the user agent of the User (requestor).
>>>>>
>>>>> If there is any claim the OP can provide, it is a claim on the User
>>>>> (RO).
>>>>>
>>>>> I hope this example clarifies the misunderstanding. Any attempt of
>>>>> bringing this double role of the User into GNAP will also bring this
>>>>> confusion. In order to keep this out of GNAP let us look for the righ=
t term
>>>>> for User (as a requestor) using the diagram displayed below.
>>>>>
>>>>> +----+  +------+  +---+  +---+  +---+
>>>>> |Reqs|  |Orchst|  |RS |  |GS |  |RO |
>>>>> +----+  +------+  +---+  +-+-+  +-+-+
>>>>>   |(1) ServiceRequest      |      |
>>>>>   |-------->|       |      |      |
>>>>>   |         |(2) ServiceIntent:AuthZChallenge
>>>>>   |         |<----->|      |      |
>>>>>   |         |       |      |      |
>>>>>   |         |(3) AuthZRequest(AuthZChallenge)
>>>>>   |         |------------->|      |
>>>>>   |         |       |      |(4) ConsentRequest:Grant
>>>>>   |         |       |      |<---->|
>>>>>   |         |(5) GrantAccess(AuthZ)
>>>>>   |         |<-------------|      |
>>>>>   |         |       |      |      |
>>>>>   |         |(6) ServiceRequest(AuthZ):ServiceResponse
>>>>>   |         |<----->|      |      |
>>>>>   |(7) ServiceResponse     |      |
>>>>>   |<--------|       |      |      |
>>>>>   +         +       +      +      +
>>>>>
>>>>> - Replacing the word User helps clarify the difference between both
>>>>> roles "Requestor" and "Resource Owner"
>>>>> - Renaming claim by attaching the Object/target of the claim (e.g.:
>>>>> RO-attributes, Requestor-Attributes, Orchestrator-Attributes) also he=
lps
>>>>> identify the source of those attributes (GS, RS, Client):
>>>>>
>>>>> Best regards.
>>>>> /Francis
>>>>>
>>>>> On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt 
>>>>> wrote:
>>>>>
>>>>>> It is not clear to me what it matters if a Claim comes from an RS, o=
r
>>>>>> from the GS, so I don't see a need to differentiate them.
>>>>>>
>>>>>> I would include verifiable credentials and user-bound keys as Claims=
.
>>>>>>
>>>>>> All the payment processing information I have seen has been in RAR.
>>>>>> When would the Client get payment processing directly from the GS?
>>>>>>
>>>>>> What is your example for distributed networks storage locations? If
>>>>>> what is stored is a statement about the user, then I would consider =
that a
>>>>>> Claim as well.
>>>>>>
>>>>>> We disagree on how to map OIDC to GNAP.  The direct data is a claims
>>>>>> request, the data coming indirectly is an access token request.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer 
>>>>>> wrote:
>>>>>>
>>>>>>> Since we=E2=80=99re already talking about returning claims as direc=
t data as
>>>>>>> well as a part of the resource API being protected, so we already n=
eed a
>>>>>>> way to differentiate the two kinds of items. Just calling it =E2=80=
=9Cclaims=E2=80=9D
>>>>>>> doesn=E2=80=99t help, because as you=E2=80=99ve pointed out they co=
uld show up in both
>>>>>>> places. So yes, defining that difference is something we should wor=
ry about
>>>>>>> now, even if the core protocol only uses it for claims.
>>>>>>>
>>>>>>> The two forms of direct data that XYZ returns are subject
>>>>>>> identifiers (a subset of identity claims) and assertions =E2=80=94 =
the latter being
>>>>>>> a container not just for identity claims but also authentication
>>>>>>> information and other elements. Assertions are not claims themselve=
s.
>>>>>>>
>>>>>>> Other use cases that have been brought up include verifiable
>>>>>>> credentials and proofs, user-bound keys, payment processing informa=
tion,
>>>>>>> and distributed network storage locations. I=E2=80=99m sure there a=
re a lot more.
>>>>>>> To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D but n=
ot subsets of =E2=80=9Cclaims=E2=80=9D.
>>>>>>> GNAP shouldn=E2=80=99t be defining what all of these look like, but=
 it should
>>>>>>> define a way to talk about them.
>>>>>>>
>>>>>>> I think different top-level request objects are better suited for
>>>>>>> different query semantics. Like, for example, the OIDC =E2=80=9Ccla=
ims=E2=80=9D request,
>>>>>>> which allows targeting of its claims information into different ret=
urn
>>>>>>> buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D request=
 at the very least. I
>>>>>>> don=E2=80=99t think GNAP should define how to do this specific comb=
ination, that
>>>>>>> should be for OIDF to debate and apply. The same with a DID service=
 based
>>>>>>> query, or Presentation Exchange [1], or anything else that people w=
ant to
>>>>>>> come up with.
>>>>>>>
>>>>>>> In my view, GNAP should define query structures for two things:
>>>>>>> rights that get tied to an access token and data that comes back di=
rectly
>>>>>>> to the client. For the latter, I think we can do some very limited =
and very
>>>>>>> useful specific items, which is what I=E2=80=99ve put into XYZ.
>>>>>>>
>>>>>>>  =E2=80=94 Justin
>>>>>>>
>>>>>>> [1] https://identity.foundation/presentation-exchange/
>>>>>>>
>>>>>>> On Jul 24, 2020, at 3:58 PM, Dick Hardt 
>>>>>>> wrote:
>>>>>>>
>>>>>>> I agree we want GNAP to be a strong foundation.
>>>>>>>
>>>>>>> Do you have an example of other "direct data"? If so, do you expect
>>>>>>> it to be defined in the core protocol?
>>>>>>>
>>>>>>> I would expect an extension for other "direct data" to define top
>>>>>>> level objects, and an appropriate definition for that "direct data"=
.
>>>>>>>
>>>>>>> My "do we need to worry about it now" comment was on creating a
>>>>>>> generic term for "direct data". Unless we are solving those now, we=
 can let
>>>>>>> further work define that "direct data" explicitly.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> =E1=90=A7
>>>>>>>
>>>>>>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Yes, I do think we need to worry about it to the extent that we ar=
e
>>>>>>>> not creating something that is over-fit to a limited set of use ca=
ses.
>>>>>>>>
>>>>>>>> GNAP should be a foundation that many amazing new things can be
>>>>>>>> built on top of.
>>>>>>>>
>>>>>>>>  =E2=80=94 Justin
>>>>>>>>
>>>>>>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Justin, thanks for clarifying.
>>>>>>>>
>>>>>>>> What are some examples of other "direct data" that the GS may
>>>>>>>> return? If it is not in core GNAP, do we need to worry about now? =
We can
>>>>>>>> then give the direct data from the GS that is not a claim, an appr=
opriate
>>>>>>>> name in that document.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99=
m saying. I agree
>>>>>>>>> that =E2=80=9Cclaims=E2=80=9D are about the user, in this context=
*. But the AS could return
>>>>>>>>> other data directly to the client that isn=E2=80=99t about the us=
er. Those aren=E2=80=99t
>>>>>>>>> =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =
=E2=80=9Cclaims=E2=80=9D can come back
>>>>>>>>> from places other than directly, then we shouldn=E2=80=99t call e=
verything that
>>>>>>>>> comes back a =E2=80=9Cclaim=E2=80=9D.
>>>>>>>>>
>>>>>>>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean=
 what it already means
>>>>>>>>> and come up with a new word to mean =E2=80=9Cthings that come bac=
k directly from
>>>>>>>>> the AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=
=80=99s more complete definitions,
>>>>>>>>> but to simplify:
>>>>>>>>>
>>>>>>>>> Claims:
>>>>>>>>> - information about the user
>>>>>>>>> - can come back directly from the AS
>>>>>>>>> - can come back in a resource from the RS
>>>>>>>>>
>>>>>>>>> Resource:
>>>>>>>>> - Returned from an RS
>>>>>>>>> - Protected by access token
>>>>>>>>> - Could contain claims about the user
>>>>>>>>>
>>>>>>>>> Direct data (or some better name):
>>>>>>>>> - Returned directly from AS
>>>>>>>>> - Could contain claims about the user
>>>>>>>>>
>>>>>>>>> I think the problem is that some people are using =E2=80=9Cclaims=
=E2=80=9D to mean
>>>>>>>>> #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=
=E2=80=99s important to
>>>>>>>>> remember, when talking about OIDC, that an IdP in OIDC combines a=
n AS and
>>>>>>>>> an RS into one entity for identity information. There can be othe=
r RS=E2=80=99s as
>>>>>>>>> well, and there usually are in the wild, but the one defined by O=
IDC is the
>>>>>>>>> UserInfo Endpoint. The fact that it returns user data doesn=E2=80=
=99t make it any
>>>>>>>>> less of an RS.
>>>>>>>>>
>>>>>>>>>  =E2=80=94 Justin
>>>>>>>>>
>>>>>>>>> * In the wider context of things like the information claims
>>>>>>>>> inside a JWT, the claims could be about literally anything, but t=
hat=E2=80=99s not
>>>>>>>>> what we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=
=80=99s being used.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly
>>>>>>>>> from the OP in an ID Token, or the Client can obtain Claims using=
 an access
>>>>>>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>>>>>>
>>>>>>>>> The Claims are about the User (not a RO).
>>>>>>>>>
>>>>>>>>> In XAuth, I'm proposing the Client may obtain bare claims from th=
e
>>>>>>>>> GS directly in addition to the mechanisms in ODIC.
>>>>>>>>>
>>>>>>>>> So I don't think we are changing the definition of Claim from how
>>>>>>>>> it has been used in OIDC, and I fail to see any reason to NOT use=
 Claim.
>>>>>>>>>
>>>>>>>>> Justin: you allude to Claims being about a party other than the
>>>>>>>>> User. Would you provide an example?
>>>>>>>>>
>>>>>>>>> /Dick
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>>
>>>>>>>>> UserInfo Endpoint
>>>>>>>>> Protected Resource that, when presented with an Access Token by
>>>>>>>>> the Client, returns authorized information about the End-User rep=
resented
>>>>>>>>> by the corresponding Authorization Grant. The UserInfo Endpoint U=
RL MUST
>>>>>>>>> use the https scheme and MAY contain port, path, and query parame=
ter
>>>>>>>>> components.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> =E1=90=A7
>>>>>>>>>
>>>>>>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I want to focus on one aspect here:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> A Claim is a well understood term in the field. We should use
>>>>>>>>>>> it. It is still a Claim if it comes directly from the GS or fro=
m an RS.
>>>>>>>>>>>
>>>>>>>>>> I do not understand why a Resource release by an RS shall be h t=
o
>>>>>>>>>> as a claim, even if the content of the Resource is an assertion.=
 It will
>>>>>>>>>> lead to confusion. If we limit claims to information GS releases=
 into
>>>>>>>>>> Token, User Info, and other objects it returns, this will help s=
eparate
>>>>>>>>>> responsibilities between GS and RS. As soon as RS services and i=
nformation,
>>>>>>>>>> this is called a Resource, no matter the nature of the content o=
f that
>>>>>>>>>> information.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=
=9Cclaim=E2=80=9D in the
>>>>>>>>>> way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D =
could come back through an RS =E2=80=94 but
>>>>>>>>>> in the context of GNAP, that makes it a resource. So we need a d=
ifferent
>>>>>>>>>> word for data coming back directly from the AS to the client. So=
metimes
>>>>>>>>>> it=E2=80=99s going to be about the user, and that=E2=80=99s what=
 we=E2=80=99re going to focus on
>>>>>>>>>> here, but since you can also get information about the user from=
 a resource
>>>>>>>>>> we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think=
 this has been at the heart of a
>>>>>>>>>> lot of confusion in recent threads, as well as confusion about t=
he scope of
>>>>>>>>>> the inclusion of identity in the GNAP protocol.
>>>>>>>>>>
>>>>>>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it alread=
y does, and let=E2=80=99s find a
>>>>>>>>>> way to differentiate between when an item, claim or otherwise,  =
comes as
>>>>>>>>>> part of a resource and when it comes back directly. This is an i=
mportant
>>>>>>>>>> differentiating feature for GNAP.
>>>>>>>>>>
>>>>>>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in =
love with:
>>>>>>>>>>
>>>>>>>>>>  - direct data
>>>>>>>>>>  - properties
>>>>>>>>>>  - details
>>>>>>>>>>  - statements
>>>>>>>>>>
>>>>>>>>>> The important thing here is that it=E2=80=99s not necessarily :a=
bout: the
>>>>>>>>>> RO, and that it is :not: in a resource.
>>>>>>>>>>
>>>>>>>>>> Any other thoughts?
>>>>>>>>>>
>>>>>>>>>>  =E2=80=94 Justin
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> 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/
>
>
>

--000000000000d1c35805ab6c96b6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


What is Requester or Requesting Party replacing? User?
Is a Role software?

On Mon, Jul 27, 2020 at 5:14 AM Ju=
stin Richer <jricher@mit.edu> =
wrote:
I agree with the separation between =E2=80=
=9Croles=E2=80=9D and =E2=80=9Centities=E2=80=9D. It=E2=80=99s exactly that=
 kind of separation into roles that helped OAuth 2 succeed with the AS and =
RS roles possibly being the same entity, or not, depending on use case.
This is one of the reasons that I think =E2=80=9Cuser=E2=80=
=9D is an overloaded term. The user is an entity, not a role, and in spite =
of it being =E2=80=9Cunderstood=E2=80=9D in the OAuth 2 world, it means a w=
ide variety of other things outside that world. The same with =E2=80=9Cclie=
nt=E2=80=9D, I can=E2=80=99t tell you how many times I=E2=80=99ve had to ex=
plain what exactly an OAuth =E2=80=9Cclient=E2=80=9D is when I=E2=80=99m te=
aching a class.

As for specific recommendations: I=
=E2=80=99m in favor of the role =E2=80=9CRequester=E2=80=9D or =E2=80=9CReq=
uesting Party=E2=80=9D. =E2=80=9CClient=E2=80=9D is arguably more confusing=
 and harder to replace: I had tried to use =E2=80=9CResource Client=E2=80=
=9D to make =E2=80=9Cclient=E2=80=9D more specific in XYZ but that turned o=
ut to be more confusing than helpful.

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

On Jul 27, 2020, at 6=
:12 AM, Francis Pouatcha <fpo@adorsys.de> wrote:



<=
div class=3D"gmail_quote" style=3D"font-family:Helvetica;font-size:12px;fon=
t-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:n=
ormal;text-align:start;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px;text-decoration:none">
On Sun, Jul 26, 2020 at 11:58 PM Dick Hardt <dick.hardt@gmail.com> wrote:
=



On Sun, Jul 26, 2020 at 6:45 PM Francis Pouatcha <fpo@adorsys.de> wro=
te:
Hello Dick,

On Sun, Jul 26, 2020 at 9:14 PM Dick Hardt=
 <dick.hardt@g=
mail.com> wrote:
Hi Francis

User is a well under=
stood term in OIDC and OAuth -- and User means the same in both.=C2=A0

Resource Owner is who owns the resource, an=
d the term is introduced for when the User is NOT the Resource Owner.=C2=A0=

This distinction is what makes it confusing a=
s we are comparing an Entity (the User) to a Role (the RO). We need two rol=
es.

Or we could think of =
them all as entities. The RO is the entity that owns the resource. The User=
 is the human that is using the Client.=C2=A0
When we think of them as entities, we run into conflicts when Entity-=
User eq. Entity-RO.
When we think of them as roles, Role-User is =
always !=3D Role-RO=C2=A0
=C2=A0
=C2=A0

I also think that Client and Resour=
ce Server are well understood terms.
Looks lik=
e contributors on the list still need clarification on=C2=A0the "orche=
stration" role of a client.

When I think of orchestration, I think of coordinating,=C2=A0which =
is not what I think the=C2=A0Client is doing. The Client wants to consume t=
he Claims and the Resources (combined are a Grant). The Client requests the=
 Grant from the Grant Server. Where is the orchestration?
=

Look at the client. It is the center of interaction betwe=
en User, GS and RS.
=

=C2=A0

It is not clear to me why we would want to reinvent these =
terms. Reading over your flows, I think it would be useful=C2=A0to understa=
nd the requirements you have for your use case, otherwise I fear we will be=
 talking past each other.
The oAuth flow is th=
ere as a memo. The other flow is what I proposed before. Is there to emphas=
ize we need to work on roles and not on entities. It is not a suggestion=C2=
=A0to rename=C2=A0well known idioms. It is an attempt=C2=A0to give=C2=A0the=
m a proper definition in the context of this protocol. Definition based on =
their roles in the protocol flows.

<=
/div>
I'd like to take a step back and understand the requirements.=
 We are deep into solutions.
No, we are =
at the fundamental level. We Have to decide on=C2=A0whether=C2=A0to build a=
 model based on roles oron entities... Then we use the result [ENTITY XOR R=
OLES] to define the use cases.
/Francis
<=
div>=C2=A0

Best regards.
=

/Francis

/Dick

3D""=E1=90=A7

On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha <=
;fpo@adorsys.de>=
 wrote:
Below my opinion=C2=A0on the term Claim:<=
/font>

Starting with illustration of parties/roles:

User:=C2=
=A0
This word is misleading becau=
se of its double role in oAuth2 and OIDC (see below). In GNAP let us have t=
he User play only the role of a requestor. (from Justin reference to "=
Requesting Party").

Client:
This is also tightly=C2=A0bound to the oAuth2 and OIDC. The =
real purpose of this role is to orchestrate resource access on behalf of th=
e "Requestor". Let us call this for now the "Orchestrator&qu=
ot;

Resource Owner (RO):
This is IMO the most correct word in the entire protocol. Authorisati=
on is always about the owner of something granting access to a requestor. I=
t really=C2=A0does not matter if a human interaction is involved. We will h=
ave to forget oAuth2 and OIDC of also calling this a User.

Gr=
ant Server:=C2=A0
Even though the=
 definition of the UserInfo endpoint in OIDC as a protected resource hazard=
ously makes an OP an RS, we shall not repeat the same mistake here. We need=
 a clear separation between roles of GS and RS without overlapping.<=
/div>

Resource Server: services resources.

Unless I got=C2=
=A0it wrong, GNAP is about grant negotiation and authorization. This means:=


GNAP is about some party requesting access to som=
e resources.
GNAP is about the re=
source owner consenting access to that resource.
GNAP is about defining the infrastructure that allows the r=
equesting party to access a resource.=C2=A0

GNAP designs this=
 infrastructure around:
- an orch=
estrator (what we refer to as a client)
- an grant manager (what we refer to as a GS/AS)
- the custodian of the resource (what we call a RS)<=
/font>

As you see:
- The =
word User does not appear here, and is not relevant as the focus=C2=A0is on=
 authorizing access to a resource.
- The word Claim is as well absent.

Claim related to RO:
The word Claim might start getting =
visible if the orchestrator (a.k.a. Client) or the custodian (a.k.a RS) nee=
ds some additional information on the RO to proceed with the access control=
 decision. These claims refer to assertions of attributes or properties of =
the RO. These claims are issued by the GS as the GS manages interaction wit=
h the RO (see below). In this first place information about the requesting =
party (erroneously.k.a. User) is not releva=
nt to the negotiation and provisioning framework. Let us call this sort of =
claim "RO-Attributes". A better name is welcome.

So=
me advanced resource provisioning frameworks might require knowledge on att=
ributes of the requesting party (e.k.a User). These attributes shall be col=
lected by the=C2=A0orchestrator (a.k.a Client) and added to the resource re=
quest. There is no way the GS can collect these attributes as the GS role h=
as no interaction with the requesting party (e.k.a User).=C2=A0Let us call =
this sort of claim "Requestor-Attributes". A better name will be =
welcome.

Some assertions are even related to the orchestrator=
=C2=A0(a.k.a Client) itself. This is the case of the public key of an orche=
strator=C2=A0used by the GS to "sender constrain" an access token=
. Let us call this type of claim "Orchestrator-Attributes".

This is a sample mapping of OIDC.

+----+ =C2=A0 =C2=
=A0+---+ =C2=A0 +---+ =C2=A0+---+
|User| =C2=A0 =C2=A0|RP | =C2=A0 |OP |=
 =C2=A0|RS |
+----+ =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 |(2) redirect=C2=A0 =C2=
=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |<--------| =C2=A0 =C2=A0 =
=C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=
=3D=3D=3D User (requestor) passes control to User (RO) =3D=3D=3D
=C2=A0 |(3) Auth + Consent =C2=A0 =C2=A0 =
=C2=A0|
=C2=A0 |---------------->| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |(=
4) redirect (code) =C2=A0 =C2=A0 |
=C2=A0 |<----------------| =C2=A0 =
=C2=A0 =C2=A0|
=3D=3D=3D User (RO=
) passes control back to User (requestor) =3D=3D=3D
=C2=A0 |(5) get(code=
) =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |-------->| =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) token (code)
=C2=A0 | =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) token=
 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<------| =C2=
=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(8) ServiceRequ=
est(token)
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |------------->|
=
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |(9) ServiceResponse
=C2=A0 | =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 |<-------------|
=C2=A0 |(10) ServiceRespons=
e =C2=A0 =C2=A0|
=C2=A0 |<--------| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=
=A0 =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>
- RP orchestrates interaction bet=
ween User and OP to enable the user to obtain the protected resource.
- In step 1 & 10 User plays the ro=
le of the requestor of the resource.
- In step 2 User-Browser is used to pass control from User (in his role=
 as the requestor) to User (in his role as the RO)
- In step 4=C2=A0User-Browser is used to pass control fro=
m User (in his role as the RO) back to=C2=A0User (in his role as the reques=
tor)

When we are talking claims here, we are talking claims o=
n the User (in his role as the RO). The OP does not have any interaction wi=
th the User (in his role as the requestor). In the case of an App2App redir=
ection, the OP can not even assert about the user agent of the User (reques=
tor).

If there is any claim the OP can provide, it is a claim=
 on the User (RO).

I hope this example clarifies the misunder=
standing. Any attempt of bringing this double role of the User into GNAP wi=
ll also bring this confusion. In order to keep this out of GNAP let us look=
 for the right term for User (as a requestor) using the diagram displayed b=
elow.

+----+ =C2=A0+------+ =C2=A0+---+ =C2=A0+---+ =C2=A0+--=
-+
|Reqs| =C2=A0|Orchst| =C2=A0|RS | =C2=A0|GS | =C2=A0|RO |
+----+ =
=C2=A0+------+ =C2=A0+---+ =C2=A0+-+-+ =C2=A0+-+-+
=C2=A0 |(1) ServiceRe=
quest =C2=A0=C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0|
=C2=A0 |-------->| =
=C2=A0 =C2=A0 =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 |(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|(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 |(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 |(6) ServiceRequest(=
AuthZ):ServiceResponse
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<-----&g=
t;| =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+

- Replacing the word User helps clarif=
y the difference between both roles "Requestor" and "Resourc=
e Owner"
- Renaming claim by=
 attaching the Object/target of the claim (e.g.: RO-attributes, Requestor-A=
ttributes, Orchestrator-Attributes) also helps identify the source of those=
 attributes (GS, RS, Client):

Best regards.=

/Francis

On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt <dick.hardt@gmail.com=
> wrote:
=

It is not clear to me what it matters if a Claim come=
s from an RS, or from the GS, so I don't see a need to differentiate th=
em.

I would include verifiable credentials and use=
r-bound keys as Claims.

All the payment processing=
 information I have=C2=A0seen has been in RAR. When would=C2=A0the Client g=
et payment processing directly from the GS?

What i=
s your example for distributed networks storage locations? If what is store=
d is a statement about the user, then I would consider that a Claim as well=
.

We disagree on how to map OIDC to GNAP.=C2=A0 Th=
e direct data is a claims request, the data coming indirectly is an access =
token request.



On Fri, Jul 24, 2020 at 1=
:39 PM Justin Richer <jricher@mit.edu> wrote:
Since we=E2=80=99re already talking about returning =
claims as direct data as well as a part of the resource API being protected=
, so we already need a way to differentiate the two kinds of items. Just ca=
lling it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, because as you=E2=
=80=99ve pointed out they could show up in both places. So yes, defining th=
at difference is something we should worry about now, even if the core prot=
ocol only uses it for claims.

The two forms of direct da=
ta that XYZ returns are subject identifiers (a subset of identity claims) a=
nd assertions =E2=80=94 the latter being a container not just for identity =
claims but also authentication information and other elements. Assertions a=
re not claims themselves.=C2=A0

Other use cases th=
at have been brought up include verifiable credentials and proofs, user-bou=
nd keys, payment processing information, and distributed network storage lo=
cations. I=E2=80=99m sure there are a lot more. To me, these are subsets of=
 the =E2=80=9Cdirect data=E2=80=9D but not subsets of =E2=80=9Cclaims=E2=80=
=9D. GNAP shouldn=E2=80=99t be defining what all of these look like, but it=
 should define a way to talk about them.

I think d=
ifferent top-level request objects are better suited for different query se=
mantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=9D request, whic=
h allows targeting of its claims information into different return buckets.=
 This overlaps with the =E2=80=9Cresources=E2=80=9D request at the very lea=
st. I don=E2=80=99t think GNAP should define how to do this specific combin=
ation, that should be for OIDF to debate and apply. The same with a DID ser=
vice based query, or Presentation Exchange [1], or anything else that peopl=
e want to come up with.

In my view, GNAP should de=
fine query structures for two things: rights that get tied to an access tok=
en and data that comes back directly to the client. For the latter, I think=
 we can do some very limited and very useful specific items, which is what =
I=E2=80=99ve put into XYZ.

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

[1]=C2=A0https://identity.foundat=
ion/presentation-exchange/

O=
n Jul 24, 2020, at 3:58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree we want GNAP to be a strong foundation.=C2=A0
Do you have an example of other "direct data"? If=
 so, do you expect it to be defined in the core protocol?

I would expect an extension for other "direct data" to de=
fine top level objects, and an appropriate definition for that "direct=
 data".

My "do we need to worry about it=
 now" comment was on creating a generic term for "direct data&quo=
t;. Unless we are solving those now, we can let further work define that &q=
uot;direct data" explicitly.


<=
br>

3D""=E1=90=A7

On Fri, Jul 24=
, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
Yes, I do think we need to worry about i=
t to the extent that we are not creating something that is over-fit to a li=
mited set of use cases.=C2=A0

GNAP should be a foundatio=
n that many amazing new things can be built on top of.

=C2=A0=E2=80=94 Justin

On Jul=
 24, 2020, at 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, thanks for clarifying.

What are som=
e examples of other "direct data" that the GS may return? If it i=
s not in core GNAP, do we need to worry about now? We can then give the dir=
ect data from the GS that is not a claim, an appropriate name in that docum=
ent.



On Fri, Jul 24, 2020 at 11:46 AM Ju=
stin Richer <jriche=
r@mit.edu> wrote:
Dick: No, I think you=E2=80=99re misunderstanding what I=E2=
=80=99m saying. I agree that =E2=80=9Cclaims=E2=80=9D are about the user, i=
n this context*. But the AS could return other data directly to the client =
that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=
=80=9D by the classical definition. Also since =E2=80=9Cclaims=E2=80=9D can=
 come back from places other than directly, then we shouldn=E2=80=99t call =
everything that comes back a =E2=80=9Cclaim=E2=80=9D.

I=
=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean what it al=
ready means and come up with a new word to mean =E2=80=9Cthings that come b=
ack directly from the AS=E2=80=9D. These aren=E2=80=99t meant to replace Fr=
ancis=E2=80=99s more complete definitions, but to simplify:

<=
/div>
Claims:
	- =
information about the user
	=
- can come back directly from the AS
	- can come back in a resource from the RS

Resource:
	<=
/span>- Returned from an RS
=
	- Protected by access token
	- Could contain claims about the user

<=
div>Direct data (or some better name):
	- Returned directly from AS
	- Could contain claims about the user
=

I think the problem is that some people are using =E2=80=9Cc=
laims=E2=80=9D to mean #1 and some to mean #3. It=E2=80=99s clearly #1 in O=
IDC. But: It=E2=80=99s important to remember, when talking about OIDC, that=
 an IdP in OIDC combines an AS and an RS into one entity for identity infor=
mation. There can be other RS=E2=80=99s as well, and there usually are in t=
he wild, but the one defined by OIDC is the UserInfo Endpoint. The fact tha=
t it returns user data doesn=E2=80=99t make it any less of an RS.

<=
/div>
=C2=A0=E2=80=94 Justin

* In the wider co=
ntext of things like the information claims inside a JWT, the claims could =
be about literally anything, but that=E2=80=99s not what we=E2=80=99re disc=
ussing here and it=E2=80=99s not how it=E2=80=99s being used.

On Jul 24, 2020, at 1:24 PM, Dick =
Hardt <dick.ha=
rdt@gmail.com> wrote:

In OpenID Conne=
ct (OIDC), the Client can obtain Claims directly from the OP in an ID Token=
, or the Client can obtain Claims using an access token to call the UserInf=
o endpoint, a Protected Resource[1].

The Claims are abou=
t the User (not a RO).

In XAuth, I'm proposing=
 the Client may obtain bare claims from the GS directly in addition to the =
mechanisms in ODIC.

So I don't think we are ch=
anging the definition of Claim from how it has been used in OIDC, and I fai=
l to see any reason to NOT use Claim.

Justin: you =
allude to Claims being about a party other than the User. Would you provide=
 an example?

/Dick

[1]
UserInfo Endpoint
Protected Resource that, when presented with=
 an Access Token by the Client, returns authorized information about the En=
d-User represented by the corresponding Authorization Grant. The UserInfo E=
ndpoint URL MUST use the https scheme and MAY contain port, path, and query=
 parameter components.



=E1=90=A7

On Fri, Jul 24, 2020 at 5:5=
8 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on one aspect here:


A Claim is a well understood term in the field. We should use it. It=
 is still a Claim if it comes directly from the GS or from an RS.=C2=A0
I do not understand why a Resource release by an =
RS shall be h to as a claim, even if the content of the Resource is an asse=
rtion. It will lead to confusion. If we limit claims to information GS rele=
ases into Token, User Info, and other objects it returns, this will help se=
parate responsibilities between GS and RS. As soon as RS services and infor=
mation, this is called a Resource, no matter the nature of the content of t=
hat information.

This is=
 exactly why I don=E2=80=99t think we should use =E2=80=9Cclaim=E2=80=9D in=
 the way that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could =
come back through an RS =E2=80=94 but in the context of GNAP, that makes it=
 a resource. So we need a different word for data coming back directly from=
 the AS to the client. Sometimes it=E2=80=99s going to be about the user, a=
nd that=E2=80=99s what we=E2=80=99re going to focus on here, but since you =
can also get information about the user from a resource we can=E2=80=99t ju=
st call it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the heart of=
 a lot of confusion in recent threads, as well as confusion about the scope=
 of the inclusion of identity in the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does, a=
nd let=E2=80=99s find a way to differentiate between when an item, claim or=
 otherwise,=C2=A0=C2=A0comes as part of a resource and when it comes back d=
irectly. This is an important differentiating feature for GNAP.
<=
br>
Some straw man ideas, none of which I=E2=80=99m particularly =
in love with:

=C2=A0- direct data
=C2=A0=
- properties
=C2=A0- details
=C2=A0- statements

The important thing here is that it=E2=80=99s not necessa=
rily :about: the RO, and that it is :not: in a resource.

Any other thoughts?

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






--=C2=A0
Francis Pouatcha
Co-Foun=
der and Technical Lead
adorsys GmbH & Co. KG


--=C2=A0
=

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

=

--=C2=A0
Francis Pouatcha
Co-Founder and Technical Lead
a=
dorsys GmbH & Co. KG
=



--000000000000d1c35805ab6c96b6--


From nobody Mon Jul 27 12:00: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 1CE393A0AEB for ; Mon, 27 Jul 2020 12:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 D2CRWKi46xEH for ; Mon, 27 Jul 2020 12:00:36 -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 00AF13A1DFF for ; Mon, 27 Jul 2020 12:00:21 -0700 (PDT)
Received: from [192.168.1.3] (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 06RJ0ERf031275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 15:00:15 -0400
From: Justin Richer 
Message-Id: <1209146B-7003-442E-A949-F553656A0091@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2E53A960-29F7-49D4-B2FE-38DB4F66E6D7"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 27 Jul 2020 15:00:14 -0400
In-Reply-To: 
Cc: Francis Pouatcha , txauth@ietf.org, Tom Jones , Denis , Fabien Imbault 
To: Dick Hardt 
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>        
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 19:00:48 -0000

--Apple-Mail=_2E53A960-29F7-49D4-B2FE-38DB4F66E6D7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes, the =E2=80=9CRequester=E2=80=9D would be replacing the =E2=80=9Cuser=E2=
=80=9D as the party operating the client software within the protocol. =
=E2=80=9CEnd-user=E2=80=9D also gets at this better than =E2=80=9Cuser=E2=80=
=9D as Mike Jones pointed out, but I think =E2=80=9CRequester=E2=80=9D =
or =E2=80=9CRequesting Party=E2=80=9D is even more specific.

A role isn=E2=80=99t software it=E2=80=99s =E2=80=A6 a role. It=E2=80=99s =
a set of actions and expectations that define relationships with other =
roles. A role could be fulfilled by a piece of software, though. The =
=E2=80=9CAS=E2=80=9D and =E2=80=9CRS=E2=80=9D roles would be fulfilled =
by software implementing those, and it might be the same piece of =
software (and therefore the same entity) in a particular instance.

 =E2=80=94 Justin

> On Jul 27, 2020, at 9:48 AM, Dick Hardt  wrote:
>=20
> What is Requester or Requesting Party replacing? User?
>=20
> Is a Role software?
>=20
> On Mon, Jul 27, 2020 at 5:14 AM Justin Richer > wrote:
> I agree with the separation between =E2=80=9Croles=E2=80=9D and =
=E2=80=9Centities=E2=80=9D. It=E2=80=99s exactly that kind of separation =
into roles that helped OAuth 2 succeed with the AS and RS roles possibly =
being the same entity, or not, depending on use case.
>=20
> This is one of the reasons that I think =E2=80=9Cuser=E2=80=9D is an =
overloaded term. The user is an entity, not a role, and in spite of it =
being =E2=80=9Cunderstood=E2=80=9D in the OAuth 2 world, it means a wide =
variety of other things outside that world. The same with =E2=80=9Cclient=E2=
=80=9D, I can=E2=80=99t tell you how many times I=E2=80=99ve had to =
explain what exactly an OAuth =E2=80=9Cclient=E2=80=9D is when I=E2=80=99m=
 teaching a class.
>=20
> As for specific recommendations: I=E2=80=99m in favor of the role =
=E2=80=9CRequester=E2=80=9D or =E2=80=9CRequesting Party=E2=80=9D. =
=E2=80=9CClient=E2=80=9D is arguably more confusing and harder to =
replace: I had tried to use =E2=80=9CResource Client=E2=80=9D to make =
=E2=80=9Cclient=E2=80=9D more specific in XYZ but that turned out to be =
more confusing than helpful.
>=20
>  =E2=80=94 Justin
>=20
>> On Jul 27, 2020, at 6:12 AM, Francis Pouatcha > wrote:
>>=20
>>=20
>>=20
>> On Sun, Jul 26, 2020 at 11:58 PM Dick Hardt > wrote:
>>=20
>>=20
>> On Sun, Jul 26, 2020 at 6:45 PM Francis Pouatcha > wrote:
>> Hello Dick,
>>=20
>> On Sun, Jul 26, 2020 at 9:14 PM Dick Hardt > wrote:
>> Hi Francis
>>=20
>> User is a well understood term in OIDC and OAuth -- and User means =
the same in both.=20
>>=20
>> Resource Owner is who owns the resource, and the term is introduced =
for when the User is NOT the Resource Owner.=20
>> This distinction is what makes it confusing as we are comparing an =
Entity (the User) to a Role (the RO). We need two roles.
>>=20
>> Or we could think of them all as entities. The RO is the entity that =
owns the resource. The User is the human that is using the Client.=20
>> When we think of them as entities, we run into conflicts when =
Entity-User eq. Entity-RO.
>> When we think of them as roles, Role-User is always !=3D Role-RO=20
>> =20
>> =20
>>=20
>> I also think that Client and Resource Server are well understood =
terms.
>> Looks like contributors on the list still need clarification on the =
"orchestration" role of a client.
>>=20
>> When I think of orchestration, I think of coordinating, which is not =
what I think the Client is doing. The Client wants to consume the Claims =
and the Resources (combined are a Grant). The Client requests the Grant =
from the Grant Server. Where is the orchestration?
>> Look at the client. It is the center of interaction between User, GS =
and RS.
>> =20
>>=20
>> It is not clear to me why we would want to reinvent these terms. =
Reading over your flows, I think it would be useful to understand the =
requirements you have for your use case, otherwise I fear we will be =
talking past each other.
>> The oAuth flow is there as a memo. The other flow is what I proposed =
before. Is there to emphasize we need to work on roles and not on =
entities. It is not a suggestion to rename well known idioms. It is an =
attempt to give them a proper definition in the context of this =
protocol. Definition based on their roles in the protocol flows.
>>=20
>> I'd like to take a step back and understand the requirements. We are =
deep into solutions.
>> No, we are at the fundamental level. We Have to decide on whether to =
build a model based on roles oron entities... Then we use the result =
[ENTITY XOR ROLES] to define the use cases.
>> /Francis
>> =20
>>=20
>> Best regards.
>> /Francis
>>=20
>> /Dick
>>=20
>> =E1=90=A7
>>=20
>> On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha > wrote:
>> Below my opinion on the term Claim:
>>=20
>> Starting with illustration of parties/roles:
>>=20
>> User:=20
>> This word is misleading because of its double role in oAuth2 and OIDC =
(see below). In GNAP let us have the User play only the role of a =
requestor. (from Justin reference to "Requesting Party").
>>=20
>> Client:
>> This is also tightly bound to the oAuth2 and OIDC. The real purpose =
of this role is to orchestrate resource access on behalf of the =
"Requestor". Let us call this for now the "Orchestrator"
>>=20
>> Resource Owner (RO):
>> This is IMO the most correct word in the entire protocol. =
Authorisation is always about the owner of something granting access to =
a requestor. It really does not matter if a human interaction is =
involved. We will have to forget oAuth2 and OIDC of also calling this a =
User.
>>=20
>> Grant Server:=20
>> Even though the definition of the UserInfo endpoint in OIDC as a =
protected resource hazardously makes an OP an RS, we shall not repeat =
the same mistake here. We need a clear separation between roles of GS =
and RS without overlapping.
>>=20
>> Resource Server: services resources.
>>=20
>> Unless I got it wrong, GNAP is about grant negotiation and =
authorization. This means:
>>=20
>> GNAP is about some party requesting access to some resources.
>> GNAP is about the resource owner consenting access to that resource.
>> GNAP is about defining the infrastructure that allows the requesting =
party to access a resource.=20
>>=20
>> GNAP designs this infrastructure around:
>> - an orchestrator (what we refer to as a client)
>> - an grant manager (what we refer to as a GS/AS)
>> - the custodian of the resource (what we call a RS)
>>=20
>> As you see:
>> - The word User does not appear here, and is not relevant as the =
focus is on authorizing access to a resource.
>> - The word Claim is as well absent.
>>=20
>> Claim related to RO:
>> The word Claim might start getting visible if the orchestrator =
(a.k.a. Client) or the custodian (a.k.a RS) needs some additional =
information on the RO to proceed with the access control decision. These =
claims refer to assertions of attributes or properties of the RO. These =
claims are issued by the GS as the GS manages interaction with the RO =
(see below). In this first place information about the requesting party =
(erroneously.k.a. User) is not relevant to the negotiation and =
provisioning framework. Let us call this sort of claim "RO-Attributes". =
A better name is welcome.
>>=20
>> Some advanced resource provisioning frameworks might require =
knowledge on attributes of the requesting party (e.k.a User). These =
attributes shall be collected by the orchestrator (a.k.a Client) and =
added to the resource request. There is no way the GS can collect these =
attributes as the GS role has no interaction with the requesting party =
(e.k.a User). Let us call this sort of claim "Requestor-Attributes". A =
better name will be welcome.
>>=20
>> Some assertions are even related to the orchestrator (a.k.a Client) =
itself. This is the case of the public key of an orchestrator used by =
the GS to "sender constrain" an access token. Let us call this type of =
claim "Orchestrator-Attributes".
>>=20
>> This is a sample mapping of OIDC.
>>=20
>> +----+    +---+   +---+  +---+
>> |User|    |RP |   |OP |  |RS |
>> +----+    +---+   +-+-+  +---+
>>   |(1) ServiceRequest      |
>>   |-------->|       |      |
>>   |(2) redirect     |      |
>>   |<--------|       |      |
>> =3D=3D=3D User (requestor) passes control to User (RO) =3D=3D=3D
>>   |(3) Auth + Consent      |
>>   |---------------->|      |
>>   |(4) redirect (code)     |
>>   |<----------------|      |
>> =3D=3D=3D User (RO) passes control back to User (requestor) =3D=3D=3D
>>   |(5) get(code)    |      |
>>   |-------->|       |      |
>>   |         |(6) token (code)
>>   |         |------>|      |
>>   |         |(7) token     |
>>   |         |<------|      |
>>   |         |(8) ServiceRequest(token)
>>   |         |------------->|
>>   |         |(9) ServiceResponse
>>   |         |<-------------|
>>   |(10) ServiceResponse    |
>>   |<--------|       |      |
>>   +         +       +      +
>>=20
>> - RP orchestrates interaction between User and OP to enable the user =
to obtain the protected resource.
>> - In step 1 & 10 User plays the role of the requestor of the =
resource.
>> - In step 2 User-Browser is used to pass control from User (in his =
role as the requestor) to User (in his role as the RO)
>> - In step 4 User-Browser is used to pass control from User (in his =
role as the RO) back to User (in his role as the requestor)
>>=20
>> When we are talking claims here, we are talking claims on the User =
(in his role as the RO). The OP does not have any interaction with the =
User (in his role as the requestor). In the case of an App2App =
redirection, the OP can not even assert about the user agent of the User =
(requestor).
>>=20
>> If there is any claim the OP can provide, it is a claim on the User =
(RO).
>>=20
>> I hope this example clarifies the misunderstanding. Any attempt of =
bringing this double role of the User into GNAP will also bring this =
confusion. In order to keep this out of GNAP let us look for the right =
term for User (as a requestor) using the diagram displayed below.
>>=20
>> +----+  +------+  +---+  +---+  +---+
>> |Reqs|  |Orchst|  |RS |  |GS |  |RO |
>> +----+  +------+  +---+  +-+-+  +-+-+
>>   |(1) ServiceRequest      |      |
>>   |-------->|       |      |      |
>>   |         |(2) ServiceIntent:AuthZChallenge=20
>>   |         |<----->|      |      |
>>   |         |       |      |      |
>>   |         |(3) AuthZRequest(AuthZChallenge)
>>   |         |------------->|      |
>>   |         |       |      |(4) ConsentRequest:Grant
>>   |         |       |      |<---->|
>>   |         |(5) GrantAccess(AuthZ)
>>   |         |<-------------|      |
>>   |         |       |      |      |
>>   |         |(6) ServiceRequest(AuthZ):ServiceResponse
>>   |         |<----->|      |      |
>>   |(7) ServiceResponse     |      |
>>   |<--------|       |      |      |
>>   +         +       +      +      +
>>=20
>> - Replacing the word User helps clarify the difference between both =
roles "Requestor" and "Resource Owner"
>> - Renaming claim by attaching the Object/target of the claim (e.g.: =
RO-attributes, Requestor-Attributes, Orchestrator-Attributes) also helps =
identify the source of those attributes (GS, RS, Client):
>>=20
>> Best regards.
>> /Francis
>>=20
>> On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt > wrote:
>> It is not clear to me what it matters if a Claim comes from an RS, or =
from the GS, so I don't see a need to differentiate them.
>>=20
>> I would include verifiable credentials and user-bound keys as Claims.
>>=20
>> All the payment processing information I have seen has been in RAR. =
When would the Client get payment processing directly from the GS?
>>=20
>> What is your example for distributed networks storage locations? If =
what is stored is a statement about the user, then I would consider that =
a Claim as well.
>>=20
>> We disagree on how to map OIDC to GNAP.  The direct data is a claims =
request, the data coming indirectly is an access token request.
>>=20
>>=20
>>=20
>> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer > wrote:
>> Since we=E2=80=99re already talking about returning claims as direct =
data as well as a part of the resource API being protected, so we =
already need a way to differentiate the two kinds of items. Just calling =
it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, because as you=E2=80=99v=
e pointed out they could show up in both places. So yes, defining that =
difference is something we should worry about now, even if the core =
protocol only uses it for claims.
>>=20
>> The two forms of direct data that XYZ returns are subject identifiers =
(a subset of identity claims) and assertions =E2=80=94 the latter being =
a container not just for identity claims but also authentication =
information and other elements. Assertions are not claims themselves.=20
>>=20
>> Other use cases that have been brought up include verifiable =
credentials and proofs, user-bound keys, payment processing information, =
and distributed network storage locations. I=E2=80=99m sure there are a =
lot more. To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D =
but not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be =
defining what all of these look like, but it should define a way to talk =
about them.
>>=20
>> I think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=
=9D request, which allows targeting of its claims information into =
different return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D=
 request at the very least. I don=E2=80=99t think GNAP should define how =
to do this specific combination, that should be for OIDF to debate and =
apply. The same with a DID service based query, or Presentation Exchange =
[1], or anything else that people want to come up with.
>>=20
>> In my view, GNAP should define query structures for two things: =
rights that get tied to an access token and data that comes back =
directly to the client. For the latter, I think we can do some very =
limited and very useful specific items, which is what I=E2=80=99ve put =
into XYZ.
>>=20
>>  =E2=80=94 Justin
>>=20
>> [1] https://identity.foundation/presentation-exchange/ =

>>=20
>>> On Jul 24, 2020, at 3:58 PM, Dick Hardt > wrote:
>>>=20
>>> I agree we want GNAP to be a strong foundation.=20
>>>=20
>>> Do you have an example of other "direct data"? If so, do you expect =
it to be defined in the core protocol?
>>>=20
>>> I would expect an extension for other "direct data" to define top =
level objects, and an appropriate definition for that "direct data".
>>>=20
>>> My "do we need to worry about it now" comment was on creating a =
generic term for "direct data". Unless we are solving those now, we can =
let further work define that "direct data" explicitly.
>>>=20
>>>=20
>>>=20
>>>=20
>>> =E1=90=A7
>>>=20
>>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer > wrote:
>>> Yes, I do think we need to worry about it to the extent that we are =
not creating something that is over-fit to a limited set of use cases.=20=

>>>=20
>>> GNAP should be a foundation that many amazing new things can be =
built on top of.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt > wrote:
>>>>=20
>>>> Justin, thanks for clarifying.
>>>>=20
>>>> What are some examples of other "direct data" that the GS may =
return? If it is not in core GNAP, do we need to worry about now? We can =
then give the direct data from the GS that is not a claim, an =
appropriate name in that document.
>>>>=20
>>>>=20
>>>>=20
>>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer > wrote:
>>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m =
saying. I agree that =E2=80=9Cclaims=E2=80=9D are about the user, in =
this context*. But the AS could return other data directly to the client =
that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=
=80=9D by the classical definition. Also since =E2=80=9Cclaims=E2=80=9D =
can come back from places other than directly, then we shouldn=E2=80=99t =
call everything that comes back a =E2=80=9Cclaim=E2=80=9D.
>>>>=20
>>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean =
what it already means and come up with a new word to mean =E2=80=9Cthings =
that come back directly from the AS=E2=80=9D. These aren=E2=80=99t meant =
to replace Francis=E2=80=99s more complete definitions, but to simplify:
>>>>=20
>>>> Claims:
>>>> 	- information about the user
>>>> 	- can come back directly from the AS
>>>> 	- can come back in a resource from the RS
>>>>=20
>>>> Resource:
>>>> 	- Returned from an RS
>>>> 	- Protected by access token
>>>> 	- Could contain claims about the user
>>>>=20
>>>> Direct data (or some better name):
>>>> 	- Returned directly from AS
>>>> 	- Could contain claims about the user
>>>>=20
>>>> I think the problem is that some people are using =E2=80=9Cclaims=E2=80=
=9D to mean #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. =
But: It=E2=80=99s important to remember, when talking about OIDC, that =
an IdP in OIDC combines an AS and an RS into one entity for identity =
information. There can be other RS=E2=80=99s as well, and there usually =
are in the wild, but the one defined by OIDC is the UserInfo Endpoint. =
The fact that it returns user data doesn=E2=80=99t make it any less of =
an RS.
>>>>=20
>>>>  =E2=80=94 Justin
>>>>=20
>>>> * In the wider context of things like the information claims inside =
a JWT, the claims could be about literally anything, but that=E2=80=99s =
not what we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99=
s being used.
>>>>=20
>>>>=20
>>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt > wrote:
>>>>>=20
>>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly =
from the OP in an ID Token, or the Client can obtain Claims using an =
access token to call the UserInfo endpoint, a Protected Resource[1].
>>>>>=20
>>>>> The Claims are about the User (not a RO).
>>>>>=20
>>>>> In XAuth, I'm proposing the Client may obtain bare claims from the =
GS directly in addition to the mechanisms in ODIC.
>>>>>=20
>>>>> So I don't think we are changing the definition of Claim from how =
it has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>>=20
>>>>> Justin: you allude to Claims being about a party other than the =
User. Would you provide an example?
>>>>>=20
>>>>> /Dick
>>>>>=20
>>>>> [1]
>>>>> UserInfo Endpoint
>>>>> Protected Resource that, when presented with an Access Token by =
the Client, returns authorized information about the End-User =
represented by the corresponding Authorization Grant. The UserInfo =
Endpoint URL MUST use the https scheme and MAY contain port, path, and =
query parameter components.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =E1=90=A7
>>>>>=20
>>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer > wrote:
>>>>> I want to focus on one aspect here:
>>>>>=20
>>>>>>=20
>>>>>> A Claim is a well understood term in the field. We should use it. =
It is still a Claim if it comes directly from the GS or from an RS.=20
>>>>>> I do not understand why a Resource release by an RS shall be h to =
as a claim, even if the content of the Resource is an assertion. It will =
lead to confusion. If we limit claims to information GS releases into =
Token, User Info, and other objects it returns, this will help separate =
responsibilities between GS and RS. As soon as RS services and =
information, this is called a Resource, no matter the nature of the =
content of that information.
>>>>>=20
>>>>> This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =
=E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in =
the context of GNAP, that makes it a resource. So we need a different =
word for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s going to be about the user, and that=E2=80=99s what we=E2=80=99=
re going to focus on here, but since you can also get information about =
the user from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=
=80=9D. I think this has been at the heart of a lot of confusion in =
recent threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.
>>>>>=20
>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already =
does, and let=E2=80=99s find a way to differentiate between when an =
item, claim or otherwise,  comes as part of a resource and when it comes =
back directly. This is an important differentiating feature for GNAP.
>>>>>=20
>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in =
love with:
>>>>>=20
>>>>>  - direct data
>>>>>  - properties
>>>>>  - details
>>>>>  - statements
>>>>>=20
>>>>> The important thing here is that it=E2=80=99s not necessarily =
:about: the RO, and that it is :not: in a resource.
>>>>>=20
>>>>> Any other thoughts?
>>>>>=20
>>>>>  =E2=80=94 Justin
>>>>=20
>>>=20
>>=20
>>=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
>> Francis Pouatcha
>> Co-Founder and Technical Lead
>> adorsys GmbH & Co. KG
>> https://adorsys-platform.de/solutions/ =



--Apple-Mail=_2E53A960-29F7-49D4-B2FE-38DB4F66E6D7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes, =
the =E2=80=9CRequester=E2=80=9D would be replacing the =E2=80=9Cuser=E2=80=
=9D as the party operating the client software within the protocol. =
=E2=80=9CEnd-user=E2=80=9D also gets at this better than =E2=80=9Cuser=E2=80=
=9D as Mike Jones pointed out, but I think =E2=80=9CRequester=E2=80=9D =
or =E2=80=9CRequesting Party=E2=80=9D is even more specific.

A role isn=E2=80=99t =
software it=E2=80=99s =E2=80=A6 a role. It=E2=80=99s a set of actions =
and expectations that define relationships with other roles. A role =
could be fulfilled by a piece of software, though. The =E2=80=9CAS=E2=80=9D=
 and =E2=80=9CRS=E2=80=9D roles would be fulfilled by software =
implementing those, and it might be the same piece of software (and =
therefore the same entity) in a particular instance.

 =E2=80=94 =
Justin

On Jul 27, 2020, at 9:48 AM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

What is Requester or Requesting =
Party replacing? User?

Is a Role software?

On Mon, Jul =
27, 2020 at 5:14 AM Justin Richer <jricher@mit.edu> wrote:
I agree with the separation between =E2=80=9Croles=
=E2=80=9D and =E2=80=9Centities=E2=80=9D. It=E2=80=99s exactly that kind =
of separation into roles that helped OAuth 2 succeed with the AS and RS =
roles possibly being the same entity, or not, depending on use case.

This is one of the =
reasons that I think =E2=80=9Cuser=E2=80=9D is an overloaded term. The =
user is an entity, not a role, and in spite of it being =E2=80=9Cunderstoo=
d=E2=80=9D in the OAuth 2 world, it means a wide variety of other things =
outside that world. The same with =E2=80=9Cclient=E2=80=9D, I can=E2=80=99=
t tell you how many times I=E2=80=99ve had to explain what exactly an =
OAuth =E2=80=9Cclient=E2=80=9D is when I=E2=80=99m teaching a =
class.

As for =
specific recommendations: I=E2=80=99m in favor of the role =
=E2=80=9CRequester=E2=80=9D or =E2=80=9CRequesting Party=E2=80=9D. =
=E2=80=9CClient=E2=80=9D is arguably more confusing and harder to =
replace: I had tried to use =E2=80=9CResource Client=E2=80=9D to make =
=E2=80=9Cclient=E2=80=9D more specific in XYZ but that turned out to be =
more confusing than helpful.

 =E2=80=94 Justin

On Jul 27, 2020, at 6:12 AM, Francis Pouatcha <fpo@adorsys.de> wrote:



On Sun, Jul 26, =
2020 at 11:58 PM Dick Hardt <dick.hardt@gmail.com> wrote:


On Sun, Jul =
26, 2020 at 6:45 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Hello Dick,

On Sun, Jul =
26, 2020 at 9:14 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi =
Francis

User is a =
well understood term in OIDC and OAuth -- and User means the same in =
both. 

Resource Owner is who =
owns the resource, and the term is introduced for when the User is NOT =
the Resource Owner. 
This =
distinction is what makes it confusing as we are comparing an Entity =
(the User) to a Role (the RO). We need two =
roles.

Or we could think of them all as =
entities. The RO is the entity that owns the resource. The User is the =
human that is using the Client. 
When we think of them as entities, we run into conflicts when =
Entity-User eq. Entity-RO.
When we think of them as =
roles, Role-User is always !=3D Role-RO 
 
 

I also think that Client =
and Resource Server are well understood =
terms.
Looks like contributors =
on the list still need clarification on the "orchestration" role of =
a client.

When I think of orchestration, I think =
of coordinating, which is not what I think the Client is =
doing. The Client wants to consume the Claims and the Resources =
(combined are a Grant). The Client requests the Grant from the Grant =
Server. Where is the orchestration?
Look at the client. It is the center of interaction between =
User, GS and RS.
 

It is not clear to me =
why we would want to reinvent these terms. Reading over your flows, I =
think it would be useful to understand the requirements you have =
for your use case, otherwise I fear we will be talking past each =
other.
The oAuth flow is there =
as a memo. The other flow is what I proposed before. Is there to =
emphasize we need to work on roles and not on entities. It is not a =
suggestion to rename well known idioms. It is an =
attempt to give them a proper definition in the context of =
this protocol. Definition based on their roles in the protocol =
flows.

I'd like to take a step back and =
understand the requirements. We are deep into =
solutions.
No, we are at =
the fundamental level. We Have to decide on whether to build a =
model based on roles oron entities... Then we use the result [ENTITY XOR =
ROLES] to define the use cases.
/Francis
 

Best regards.
/Francis

/Dick

3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 7:21 PM Francis Pouatcha <fpo@adorsys.de> wrote:
Below my opinion on the term =
Claim:

Starting with illustration of parties/roles:

User: 
This word is misleading because of its =
double role in oAuth2 and OIDC (see below). In GNAP let us have the User =
play only the role of a requestor. (from Justin reference to "Requesting =
Party").

Client:
This is also tightly bound to the =
oAuth2 and OIDC. The real purpose of this role is to orchestrate =
resource access on behalf of the "Requestor". Let us call this for now =
the "Orchestrator"

Resource Owner (RO):
This is IMO the most =
correct word in the entire protocol. Authorisation is always about the =
owner of something granting access to a requestor. It really does =
not matter if a human interaction is involved. We will have to forget =
oAuth2 and OIDC of also calling this a User.

Grant Server: 
Even though the definition of the UserInfo =
endpoint in OIDC as a protected resource hazardously makes an OP an RS, =
we shall not repeat the same mistake here. We need a clear separation =
between roles of GS and RS without overlapping.

Resource Server: services resources.

Unless I got it wrong, GNAP is about grant negotiation =
and authorization. This means:

GNAP =
is about some party requesting access to some =
resources.
GNAP is about the resource owner consenting access to that =
resource.
GNAP is about defining the infrastructure that allows the =
requesting party to access a resource. 

GNAP designs this infrastructure around:
- an orchestrator (what =
we refer to as a client)
- an grant manager (what we refer to as a =
GS/AS)
- =
the custodian of the resource (what we call a RS)

As you see:
- The word User does not appear here, and =
is not relevant as the focus is on authorizing access to a =
resource.
- The word Claim is as well absent.

Claim related to RO:
The word Claim might start getting visible =
if the orchestrator (a.k.a. Client) or the custodian (a.k.a RS) needs =
some additional information on the RO to proceed with the access control =
decision. These claims refer to assertions of attributes or properties =
of the RO. These claims are issued by the GS as the GS manages =
interaction with the RO (see below). In this first place information =
about the requesting party (erroneously.k.a. User) is not relevant to the negotiation and =
provisioning framework. Let us call this sort of claim "RO-Attributes". =
A better name is welcome.

Some advanced resource =
provisioning frameworks might require knowledge on attributes of the =
requesting party (e.k.a User). These attributes shall be collected by =
the orchestrator (a.k.a Client) and added to the resource request. =
There is no way the GS can collect these attributes as the GS role has =
no interaction with the requesting party (e.k.a User). Let us call =
this sort of claim "Requestor-Attributes". A better name will be =
welcome.

Some assertions are even related to the =
orchestrator (a.k.a Client) itself. This is the case of the public =
key of an orchestrator used by the GS to "sender constrain" an =
access token. Let us call this type of claim =
"Orchestrator-Attributes".

This is a sample mapping =
of OIDC.

+----+    +---+   +---+ =
 +---+
|User|    |RP |   |OP | =
 |RS |
+----+    +---+   +-+-+ =
 +---+
  |(1) ServiceRequest     =
 |
  |-------->|       | =
     |
  |(2) redirect    =
 |      |
  |<--------|   =
    |      |
=3D=3D=3D User (requestor) passes control =
to User (RO) =3D=3D=3D
  |(3) Auth + Consent     =
 |
  |---------------->|     =
 |
  |(4) redirect (code)     |
  |<----------------|     =
 |
=3D=3D=3D User (RO) passes control back to User (requestor) =
=3D=3D=3D
  |(5) get(code)    |   =
   |
  |-------->|      =
 |      |
  |     =
    |(6) token (code)
  |     =
    |------>|      |
  | =
        |(7) token     |
  |         |<------|   =
   |
  |         |(8) =
ServiceRequest(token)
  |         =
|------------->|
  |         =
|(9) ServiceResponse
  |         =
|<-------------|
  |(10) ServiceResponse   =
 |
  |<--------|       | =
     |
  +         =
+       +      +

- RP orchestrates interaction between User =
and OP to enable the user to obtain the protected =
resource.
- In step 1 & 10 User plays the role of the requestor of =
the resource.
- In step 2 User-Browser is used to pass control from User =
(in his role as the requestor) to User (in his role as the =
RO)
- In =
step 4 User-Browser is used to pass control from User (in his role =
as the RO) back to User (in his role as the =
requestor)

When we are talking claims here, we are =
talking claims on the User (in his role as the RO). The OP does not have =
any interaction with the User (in his role as the requestor). In the =
case of an App2App redirection, the OP can not even assert about the =
user agent of the User (requestor).

If there is any claim the =
OP can provide, it is a claim on the User (RO).

I hope this example clarifies the misunderstanding. Any =
attempt of bringing this double role of the User into GNAP will also =
bring this confusion. In order to keep this out of GNAP let us look for =
the right term for User (as a requestor) using the diagram displayed =
below.
+----+  +------+  +---+  +---+  +---+
|Reqs|  |Orchst|  |RS |  |GS |  |RO |
+----+  +------+  +---+  +-+-+  +-+-+
  |(1) ServiceRequest      |   =
   |
  |-------->|       =
|      |      |
  | =
        |(2) ServiceIntent:AuthZChallenge 
  |         |<----->|   =
   |      |
  |   =
      |       |      | =
     |
  |         =
|(3) AuthZRequest(AuthZChallenge)
  |     =
    |------------->|      |
  |         |       | =
     |(4) ConsentRequest:Grant
  | =
        |       |     =
 |<---->|
  |         =
|(5) GrantAccess(AuthZ)
  |       =
  |<-------------|      |
  | =
        |       |     =
 |      |
  |     =
    |(6) ServiceRequest(AuthZ):ServiceResponse
  |         |<----->|   =
   |      |
  |(7) =
ServiceResponse     |      |
 =
 |<--------|       |      |   =
   |
  +         + =
      +      +      +

- Replacing the word User helps clarify =
the difference between both roles "Requestor" and "Resource =
Owner"
- =
Renaming claim by attaching the Object/target of the claim (e.g.: =
RO-attributes, Requestor-Attributes, Orchestrator-Attributes) also helps =
identify the source of those attributes (GS, RS, =
Client):

Best regards.
/Francis

On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt <dick.hardt@gmail.com> wrote:
It is not clear to me what it matters if a Claim comes from =
an RS, or from the GS, so I don't see a need to differentiate =
them.

I would =
include verifiable credentials and user-bound keys as Claims.

All the payment =
processing information I have seen has been in RAR. When =
would the Client get payment processing directly from the =
GS?

What is =
your example for distributed networks storage locations? If what is =
stored is a statement about the user, then I would consider that a Claim =
as well.

We =
disagree on how to map OIDC to GNAP.  The direct data is a claims =
request, the data coming indirectly is an access token =
request.



On Fri, Jul 24, 2020 at 1:39 PM Justin =
Richer <jricher@mit.edu> wrote:
Since we=E2=80=99=
re already talking about returning claims as direct data as well as a =
part of the resource API being protected, so we already need a way to =
differentiate the two kinds of items. Just calling it =E2=80=9Cclaims=E2=80=
=9D doesn=E2=80=99t help, because as you=E2=80=99ve pointed out they =
could show up in both places. So yes, defining that difference is =
something we should worry about now, even if the core protocol only uses =
it for claims.

The =
two forms of direct data that XYZ returns are subject identifiers (a =
subset of identity claims) and assertions =E2=80=94 the latter being a =
container not just for identity claims but also authentication =
information and other elements. Assertions are not claims =
themselves. 

Other use cases that have been brought up include verifiable =
credentials and proofs, user-bound keys, payment processing information, =
and distributed network storage locations. I=E2=80=99m sure there are a =
lot more. To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D =
but not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be =
defining what all of these look like, but it should define a way to talk =
about them.

I =
think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=
=9D request, which allows targeting of its claims information into =
different return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D=
 request at the very least. I don=E2=80=99t think GNAP should define how =
to do this specific combination, that should be for OIDF to debate and =
apply. The same with a DID service based query, or Presentation Exchange =
[1], or anything else that people want to come up with.

In my view, GNAP should =
define query structures for two things: rights that get tied to an =
access token and data that comes back directly to the client. For the =
latter, I think we can do some very limited and very useful specific =
items, which is what I=E2=80=99ve put into XYZ.

 =E2=80=
=94 Justin

[1] https://identity.foundation/presentation-exchange/

On Jul 24, 2020, at 3:58 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

I agree we want GNAP to be a =
strong foundation. 

Do you have an example of other "direct data"? If so, do you =
expect it to be defined in the core protocol?

I would expect an extension for other =
"direct data" to define top level objects, and an appropriate definition =
for that "direct data".

My "do we need to worry about it now" comment was on creating =
a generic term for "direct data". Unless we are solving those now, we =
can let further work define that "direct data" explicitly.




3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
Yes, I do think we =
need to worry about it to the extent that we are not creating something =
that is over-fit to a limited set of use cases. 

GNAP should be a foundation that many =
amazing new things can be built on top of.

 =E2=80=94 =
Justin

On Jul 24, 2020, at 3:06 PM, =
Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, thanks for =
clarifying.

What are =
some examples of other "direct data" that the GS may return? If it is =
not in core GNAP, do we need to worry about now? We can then give the =
direct data from the GS that is not a claim, an appropriate name in that =
document.



On Fri, Jul 24, 2020 at 11:46 AM Justin =
Richer <jricher@mit.edu> wrote:
Dick: No, I =
think you=E2=80=99re misunderstanding what I=E2=80=99m saying. I agree =
that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But =
the AS could return other data directly to the client that isn=E2=80=99t =
about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=80=9D by the =
classical definition. Also since =E2=80=9Cclaims=E2=80=9D can come back =
from places other than directly, then we shouldn=E2=80=99t call =
everything that comes back a =E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m arguing that we keep =
=E2=80=9Cclaims=E2=80=9D to mean what it already means and come up with =
a new word to mean =E2=80=9Cthings that come back directly from the =
AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s =
more complete definitions, but to simplify:

Claims:
	- information =
about the user
	- can come back directly from the AS
	- =
can come back in a resource from the RS

Resource:
	- Returned from =
an RS
	- Protected by access token
	- =
Could contain claims about the user

Direct data (or some better =
name):
	- Returned directly from AS
	- =
Could contain claims about the user

I think the problem is that some people =
are using =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. =
It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s important to =
remember, when talking about OIDC, that an IdP in OIDC combines an AS =
and an RS into one entity for identity information. There can be other =
RS=E2=80=99s as well, and there usually are in the wild, but the one =
defined by OIDC is the UserInfo Endpoint. The fact that it returns user =
data doesn=E2=80=99t make it any less of an RS.

 =E2=80=94 Justin

* In the wider context =
of things like the information claims inside a JWT, the claims could be =
about literally anything, but that=E2=80=99s not what we=E2=80=99re =
discussing here and it=E2=80=99s not how it=E2=80=99s being =
used.


On Jul =
24, 2020, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

In OpenID Connect (OIDC), the =
Client can obtain Claims directly from the OP in an ID Token, or the =
Client can obtain Claims using an access token to call the UserInfo =
endpoint, a Protected Resource[1].

The Claims are about the User (not a =
RO).

In XAuth, =
I'm proposing the Client may obtain bare claims from the GS directly in =
addition to the mechanisms in ODIC.

So I don't think we are changing the =
definition of Claim from how it has been used in OIDC, and I fail to see =
any reason to NOT use Claim.

Justin: you allude to Claims being =
about a party other than the User. Would you provide an =
example?

/Dick

[1]
UserInfo =
Endpoint
Protected Resource that, when presented =
with an Access Token by the Client, returns authorized information about =
the End-User represented by the corresponding Authorization Grant. The =
UserInfo Endpoint URL MUST use the https scheme and MAY contain port, =
path, and query parameter components.



3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on =
one aspect here:


A Claim is a well =
understood term in the field. We should use it. It is still a Claim if =
it comes directly from the GS or from an =
RS. 
I do not understand =
why a Resource release by an RS shall be h to as a claim, even if the =
content of the Resource is an assertion. It will lead to confusion. If =
we limit claims to information GS releases into Token, User Info, and =
other objects it returns, this will help separate responsibilities =
between GS and RS. As soon as RS services and information, this is =
called a Resource, no matter the nature of the content of that =
information.

This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =
=E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in =
the context of GNAP, that makes it a resource. So we need a different =
word for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s going to be about the user, and that=E2=80=99s what we=E2=80=99=
re going to focus on here, but since you can also get information about =
the user from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=
=80=9D. I think this has been at the heart of a lot of confusion in =
recent threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=
=9D mean what it already does, and let=E2=80=99s find a way to =
differentiate between when an item, claim or otherwise,  comes =
as part of a resource and when it comes back directly. This is an =
important differentiating feature for GNAP.

Some straw man ideas, none of which =
I=E2=80=99m particularly in love with:

 - direct data
 - properties
 - =
details
 - statements

The important thing here is that it=E2=80=
=99s not necessarily :about: the RO, and that it is :not: in a =
resource.

Any other =
thoughts?

 =E2=80=94 =
Justin

<=
br =
class=3D"">
<=
br =
class=3D"">
<=
br clear=3D"all" 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/


-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys =
GmbH & Co. KG
https://adorsys-platform.de/solutions/



=

--Apple-Mail=_2E53A960-29F7-49D4-B2FE-38DB4F66E6D7--


From nobody Mon Jul 27 13:11: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 0A4243A0B86 for ; Mon, 27 Jul 2020 13:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 hpRhdOdIEV3k for ; Mon, 27 Jul 2020 13:11:26 -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 EB13E3A0B9C for ; Mon, 27 Jul 2020 13:11:25 -0700 (PDT)
Received: from [192.168.1.3] (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 06RKBKdK025991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 16:11:20 -0400
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_3C125852-586E-4D30-ACA2-EEB810C37313"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 27 Jul 2020 16:11:20 -0400
In-Reply-To: 
Cc: Francis Pouatcha , txauth@ietf.org, Tom Jones , Denis 
To: Dick Hardt 
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>   
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 20:11:29 -0000

--Apple-Mail=_3C125852-586E-4D30-ACA2-EEB810C37313
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I may have figured out a bit about how these approaches are actually =
different and why we might be talking past each other.

=46rom what I can see, the Xauth style query is basically saying =
=E2=80=9Chere=E2=80=99s a block asking for all the identity stuff in the =
protocol, and telling you where to put the identity stuff in the =
response no matter where that is=E2=80=9D. So this is why =E2=80=9Cclaims=E2=
=80=9D are the high-order element where things like query style and =
delivery are details of that.

XYZ takes a markedly different approach, basically saying =E2=80=9Chere=E2=
=80=99s a block that asks for stuff coming back from an RS and here=E2=80=99=
s a different block that asks for stuff coming back from the AS =
directly=E2=80=9D. Some of those things coming back, in either place, =
could be claims about the user. (Or really claims about anything else, =
if you want to use the wider definition of the term.)


So fundamentally the composition is different. Xauth lists the identity =
stuff all together, whereas XYZ splits identity stuff based on how =
it=E2=80=99s coming back. Xauth seems to prefer describing all the =
identity data to be returned regardless of how it=E2=80=99s returned. I =
prefer the XYZ approach, where resources are always resources regardless =
of what they=E2=80=99re about, and direct data is always direct data =
regardless of what it=E2=80=99s about.


Is that an accurate read?

 =E2=80=94 Justin



> On Jul 27, 2020, at 9:45 AM, Dick Hardt  wrote:
>=20
> A slide in my presentation today may clarify how I am thinking about =
it.
>=20
> On Mon, Jul 27, 2020 at 4:23 AM Justin Richer > wrote:
> Since you focused on the individual elements of the straw man examples =
you requested instead of the overall problem, I think you=E2=80=99re =
missing the core point. Let me bring it back to a concrete example:
>=20
> In Xauth currently, you can use the =E2=80=9Cclaims=E2=80=9D query =
syntax from OIDC to request user claims inside the =E2=80=9Cclaims.oidc=E2=
=80=9D object on request. However, Xauth currently uses =E2=80=9Cuserinfo=E2=
=80=9D to mark information coming back directly to the client as JSON. =
Since =E2=80=9Cuserinfo=E2=80=9D is already defined by OIDC in this =
context to indicate information that should come back from the UserInfo =
Endpoint (and therefore as a resource, with rights tied to an access =
token), the Xauth approach would need a name other than =E2=80=9Cuserinfo=E2=
=80=9D here to indicate such claims coming back directly as JSON.=20
>=20
> What would you call that field?
>=20
> Because whatever that field would be called is exactly the kind of =
data differentiation that I=E2=80=99m talking about here. And =
considering that Xauth already does differentiate between claims coming =
back as resources, as assertions, and direct JSON, I think it=E2=80=99s =
clear that it does matter.
>=20
>  =E2=80=94 Justin
>=20
>=20
>> On Jul 24, 2020, at 4:57 PM, Dick Hardt > wrote:
>>=20
>> It is not clear to me what it matters if a Claim comes from an RS, or =
from the GS, so I don't see a need to differentiate them.
>>=20
>> I would include verifiable credentials and user-bound keys as Claims.
>>=20
>> All the payment processing information I have seen has been in RAR. =
When would the Client get payment processing directly from the GS?
>>=20
>> What is your example for distributed networks storage locations? If =
what is stored is a statement about the user, then I would consider that =
a Claim as well.
>>=20
>> We disagree on how to map OIDC to GNAP.  The direct data is a claims =
request, the data coming indirectly is an access token request.
>>=20
>>=20
>>=20
>> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer > wrote:
>> Since we=E2=80=99re already talking about returning claims as direct =
data as well as a part of the resource API being protected, so we =
already need a way to differentiate the two kinds of items. Just calling =
it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, because as you=E2=80=99v=
e pointed out they could show up in both places. So yes, defining that =
difference is something we should worry about now, even if the core =
protocol only uses it for claims.
>>=20
>> The two forms of direct data that XYZ returns are subject identifiers =
(a subset of identity claims) and assertions =E2=80=94 the latter being =
a container not just for identity claims but also authentication =
information and other elements. Assertions are not claims themselves.=20
>>=20
>> Other use cases that have been brought up include verifiable =
credentials and proofs, user-bound keys, payment processing information, =
and distributed network storage locations. I=E2=80=99m sure there are a =
lot more. To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D =
but not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be =
defining what all of these look like, but it should define a way to talk =
about them.
>>=20
>> I think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=
=9D request, which allows targeting of its claims information into =
different return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D=
 request at the very least. I don=E2=80=99t think GNAP should define how =
to do this specific combination, that should be for OIDF to debate and =
apply. The same with a DID service based query, or Presentation Exchange =
[1], or anything else that people want to come up with.
>>=20
>> In my view, GNAP should define query structures for two things: =
rights that get tied to an access token and data that comes back =
directly to the client. For the latter, I think we can do some very =
limited and very useful specific items, which is what I=E2=80=99ve put =
into XYZ.
>>=20
>>  =E2=80=94 Justin
>>=20
>> [1] https://identity.foundation/presentation-exchange/ =

>>=20
>>> On Jul 24, 2020, at 3:58 PM, Dick Hardt > wrote:
>>>=20
>>> I agree we want GNAP to be a strong foundation.=20
>>>=20
>>> Do you have an example of other "direct data"? If so, do you expect =
it to be defined in the core protocol?
>>>=20
>>> I would expect an extension for other "direct data" to define top =
level objects, and an appropriate definition for that "direct data".
>>>=20
>>> My "do we need to worry about it now" comment was on creating a =
generic term for "direct data". Unless we are solving those now, we can =
let further work define that "direct data" explicitly.
>>>=20
>>>=20
>>>=20
>>>=20
>>> =E1=90=A7
>>>=20
>>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer > wrote:
>>> Yes, I do think we need to worry about it to the extent that we are =
not creating something that is over-fit to a limited set of use cases.=20=

>>>=20
>>> GNAP should be a foundation that many amazing new things can be =
built on top of.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt > wrote:
>>>>=20
>>>> Justin, thanks for clarifying.
>>>>=20
>>>> What are some examples of other "direct data" that the GS may =
return? If it is not in core GNAP, do we need to worry about now? We can =
then give the direct data from the GS that is not a claim, an =
appropriate name in that document.
>>>>=20
>>>>=20
>>>>=20
>>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer > wrote:
>>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m =
saying. I agree that =E2=80=9Cclaims=E2=80=9D are about the user, in =
this context*. But the AS could return other data directly to the client =
that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=
=80=9D by the classical definition. Also since =E2=80=9Cclaims=E2=80=9D =
can come back from places other than directly, then we shouldn=E2=80=99t =
call everything that comes back a =E2=80=9Cclaim=E2=80=9D.
>>>>=20
>>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean =
what it already means and come up with a new word to mean =E2=80=9Cthings =
that come back directly from the AS=E2=80=9D. These aren=E2=80=99t meant =
to replace Francis=E2=80=99s more complete definitions, but to simplify:
>>>>=20
>>>> Claims:
>>>> 	- information about the user
>>>> 	- can come back directly from the AS
>>>> 	- can come back in a resource from the RS
>>>>=20
>>>> Resource:
>>>> 	- Returned from an RS
>>>> 	- Protected by access token
>>>> 	- Could contain claims about the user
>>>>=20
>>>> Direct data (or some better name):
>>>> 	- Returned directly from AS
>>>> 	- Could contain claims about the user
>>>>=20
>>>> I think the problem is that some people are using =E2=80=9Cclaims=E2=80=
=9D to mean #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. =
But: It=E2=80=99s important to remember, when talking about OIDC, that =
an IdP in OIDC combines an AS and an RS into one entity for identity =
information. There can be other RS=E2=80=99s as well, and there usually =
are in the wild, but the one defined by OIDC is the UserInfo Endpoint. =
The fact that it returns user data doesn=E2=80=99t make it any less of =
an RS.
>>>>=20
>>>>  =E2=80=94 Justin
>>>>=20
>>>> * In the wider context of things like the information claims inside =
a JWT, the claims could be about literally anything, but that=E2=80=99s =
not what we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99=
s being used.
>>>>=20
>>>>=20
>>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt > wrote:
>>>>>=20
>>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly =
from the OP in an ID Token, or the Client can obtain Claims using an =
access token to call the UserInfo endpoint, a Protected Resource[1].
>>>>>=20
>>>>> The Claims are about the User (not a RO).
>>>>>=20
>>>>> In XAuth, I'm proposing the Client may obtain bare claims from the =
GS directly in addition to the mechanisms in ODIC.
>>>>>=20
>>>>> So I don't think we are changing the definition of Claim from how =
it has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>>=20
>>>>> Justin: you allude to Claims being about a party other than the =
User. Would you provide an example?
>>>>>=20
>>>>> /Dick
>>>>>=20
>>>>> [1]
>>>>> UserInfo Endpoint
>>>>> Protected Resource that, when presented with an Access Token by =
the Client, returns authorized information about the End-User =
represented by the corresponding Authorization Grant. The UserInfo =
Endpoint URL MUST use the https scheme and MAY contain port, path, and =
query parameter components.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> =E1=90=A7
>>>>>=20
>>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer > wrote:
>>>>> I want to focus on one aspect here:
>>>>>=20
>>>>>>=20
>>>>>> A Claim is a well understood term in the field. We should use it. =
It is still a Claim if it comes directly from the GS or from an RS.=20
>>>>>> I do not understand why a Resource release by an RS shall be h to =
as a claim, even if the content of the Resource is an assertion. It will =
lead to confusion. If we limit claims to information GS releases into =
Token, User Info, and other objects it returns, this will help separate =
responsibilities between GS and RS. As soon as RS services and =
information, this is called a Resource, no matter the nature of the =
content of that information.
>>>>>=20
>>>>> This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =
=E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in =
the context of GNAP, that makes it a resource. So we need a different =
word for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s going to be about the user, and that=E2=80=99s what we=E2=80=99=
re going to focus on here, but since you can also get information about =
the user from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=
=80=9D. I think this has been at the heart of a lot of confusion in =
recent threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.
>>>>>=20
>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already =
does, and let=E2=80=99s find a way to differentiate between when an =
item, claim or otherwise,  comes as part of a resource and when it comes =
back directly. This is an important differentiating feature for GNAP.
>>>>>=20
>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in =
love with:
>>>>>=20
>>>>>  - direct data
>>>>>  - properties
>>>>>  - details
>>>>>  - statements
>>>>>=20
>>>>> The important thing here is that it=E2=80=99s not necessarily =
:about: the RO, and that it is :not: in a resource.
>>>>>=20
>>>>> Any other thoughts?
>>>>>=20
>>>>>  =E2=80=94 Justin
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_3C125852-586E-4D30-ACA2-EEB810C37313
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I =
may have figured out a bit about how these approaches are actually =
different and why we might be talking past each other.

=46rom what I can see, the Xauth style =
query is basically saying =E2=80=9Chere=E2=80=99s a block asking for all =
the identity stuff in the protocol, and telling you where to put the =
identity stuff in the response no matter where that is=E2=80=9D. So this =
is why =E2=80=9Cclaims=E2=80=9D are the high-order element where things =
like query style and delivery are details of that.

XYZ takes a markedly =
different approach, basically saying =E2=80=9Chere=E2=80=99s a block =
that asks for stuff coming back from an RS and here=E2=80=99s a =
different block that asks for stuff coming back from the AS directly=E2=80=
=9D. Some of those things coming back, in either place, could be claims =
about the user. (Or really claims about anything else, if you want to =
use the wider definition of the term.)


So =
fundamentally the composition is different. Xauth lists the identity =
stuff all together, whereas XYZ splits identity stuff based on how =
it=E2=80=99s coming back. Xauth seems to prefer describing all the =
identity data to be returned regardless of how it=E2=80=99s returned. I =
prefer the XYZ approach, where resources are always resources regardless =
of what they=E2=80=99re about, and direct data is always direct data =
regardless of what it=E2=80=99s about.


Is =
that an accurate read?

 =E2=80=94 Justin



On Jul =
27, 2020, at 9:45 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

A slide in my presentation today =
may clarify how I am thinking about it.

On Mon, Jul =
27, 2020 at 4:23 AM Justin Richer <jricher@mit.edu> wrote:
Since you focused on the individual elements of =
the straw man examples you requested instead of the overall problem, I =
think you=E2=80=99re missing the core point. Let me bring it back to a =
concrete example:

In =
Xauth currently, you can use the =E2=80=9Cclaims=E2=80=9D query syntax =
from OIDC to request user claims inside the =E2=80=9Cclaims.oidc=E2=80=9D =
object on request. However, Xauth currently uses =E2=80=9Cuserinfo=E2=80=9D=
 to mark information coming back directly to the client as JSON. Since =
=E2=80=9Cuserinfo=E2=80=9D is already defined by OIDC in this context to =
indicate information that should come back from the UserInfo Endpoint =
(and therefore as a resource, with rights tied to an access token), the =
Xauth approach would need a name other than =E2=80=9Cuserinfo=E2=80=9D =
here to indicate such claims coming back directly as =
JSON. 

What=
 would you call that field?

Because whatever that field would be called is exactly the =
kind of data differentiation that I=E2=80=99m talking about here. And =
considering that Xauth already does differentiate between claims coming =
back as resources, as assertions, and direct JSON, I think it=E2=80=99s =
clear that it does matter.

 =E2=80=94 Justin


On Jul 24, 2020, at 4:57 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

It is not clear =
to me what it matters if a Claim comes from an RS, or from the GS, so I =
don't see a need to differentiate them.

I would include verifiable credentials =
and user-bound keys as Claims.

All the payment processing information =
I have seen has been in RAR. When would the Client get payment =
processing directly from the GS?

What is your example for distributed =
networks storage locations? If what is stored is a statement about the =
user, then I would consider that a Claim as well.
We disagree on how to map OIDC to =
GNAP.  The direct data is a claims request, the data coming =
indirectly is an access token request.



On Fri, Jul 24, 2020 at 1:39 PM Justin Richer =
<jricher@mit.edu> wrote:
Since we=E2=80=99=
re already talking about returning claims as direct data as well as a =
part of the resource API being protected, so we already need a way to =
differentiate the two kinds of items. Just calling it =E2=80=9Cclaims=E2=80=
=9D doesn=E2=80=99t help, because as you=E2=80=99ve pointed out they =
could show up in both places. So yes, defining that difference is =
something we should worry about now, even if the core protocol only uses =
it for claims.

The =
two forms of direct data that XYZ returns are subject identifiers (a =
subset of identity claims) and assertions =E2=80=94 the latter being a =
container not just for identity claims but also authentication =
information and other elements. Assertions are not claims =
themselves. 

Other use cases that have been brought up include verifiable =
credentials and proofs, user-bound keys, payment processing information, =
and distributed network storage locations. I=E2=80=99m sure there are a =
lot more. To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D =
but not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be =
defining what all of these look like, but it should define a way to talk =
about them.

I =
think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=
=9D request, which allows targeting of its claims information into =
different return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D=
 request at the very least. I don=E2=80=99t think GNAP should define how =
to do this specific combination, that should be for OIDF to debate and =
apply. The same with a DID service based query, or Presentation Exchange =
[1], or anything else that people want to come up with.

In my view, GNAP should =
define query structures for two things: rights that get tied to an =
access token and data that comes back directly to the client. For the =
latter, I think we can do some very limited and very useful specific =
items, which is what I=E2=80=99ve put into XYZ.

 =E2=80=
=94 Justin

[1] https://identity.foundation/presentation-exchange/

On Jul 24, 2020, at 3:58 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

I agree we want GNAP to be a =
strong foundation. 

Do you have an example of other "direct data"? If so, do you =
expect it to be defined in the core protocol?

I would expect an extension for other =
"direct data" to define top level objects, and an appropriate definition =
for that "direct data".

My "do we need to worry about it now" comment was on creating =
a generic term for "direct data". Unless we are solving those now, we =
can let further work define that "direct data" explicitly.




3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
Yes, I do think we =
need to worry about it to the extent that we are not creating something =
that is over-fit to a limited set of use cases. 

GNAP should be a foundation that many =
amazing new things can be built on top of.

 =E2=80=94 =
Justin

On Jul 24, 2020, at 3:06 PM, =
Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, thanks for =
clarifying.

What are =
some examples of other "direct data" that the GS may return? If it is =
not in core GNAP, do we need to worry about now? We can then give the =
direct data from the GS that is not a claim, an appropriate name in that =
document.



On Fri, Jul 24, 2020 at 11:46 AM Justin =
Richer <jricher@mit.edu> wrote:
Dick: No, I =
think you=E2=80=99re misunderstanding what I=E2=80=99m saying. I agree =
that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But =
the AS could return other data directly to the client that isn=E2=80=99t =
about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=80=9D by the =
classical definition. Also since =E2=80=9Cclaims=E2=80=9D can come back =
from places other than directly, then we shouldn=E2=80=99t call =
everything that comes back a =E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m arguing that we keep =
=E2=80=9Cclaims=E2=80=9D to mean what it already means and come up with =
a new word to mean =E2=80=9Cthings that come back directly from the =
AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s =
more complete definitions, but to simplify:

Claims:
	- information =
about the user
	- can come back directly from the AS
	- =
can come back in a resource from the RS

Resource:
	- Returned from =
an RS
	- Protected by access token
	- =
Could contain claims about the user

Direct data (or some better =
name):
	- Returned directly from AS
	- =
Could contain claims about the user

I think the problem is that some people =
are using =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. =
It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s important to =
remember, when talking about OIDC, that an IdP in OIDC combines an AS =
and an RS into one entity for identity information. There can be other =
RS=E2=80=99s as well, and there usually are in the wild, but the one =
defined by OIDC is the UserInfo Endpoint. The fact that it returns user =
data doesn=E2=80=99t make it any less of an RS.

 =E2=80=94 Justin

* In the wider context =
of things like the information claims inside a JWT, the claims could be =
about literally anything, but that=E2=80=99s not what we=E2=80=99re =
discussing here and it=E2=80=99s not how it=E2=80=99s being =
used.


On Jul =
24, 2020, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

In OpenID Connect (OIDC), the =
Client can obtain Claims directly from the OP in an ID Token, or the =
Client can obtain Claims using an access token to call the UserInfo =
endpoint, a Protected Resource[1].

The Claims are about the User (not a =
RO).

In XAuth, =
I'm proposing the Client may obtain bare claims from the GS directly in =
addition to the mechanisms in ODIC.

So I don't think we are changing the =
definition of Claim from how it has been used in OIDC, and I fail to see =
any reason to NOT use Claim.

Justin: you allude to Claims being =
about a party other than the User. Would you provide an =
example?

/Dick

[1]
UserInfo =
Endpoint
Protected Resource that, when presented =
with an Access Token by the Client, returns authorized information about =
the End-User represented by the corresponding Authorization Grant. The =
UserInfo Endpoint URL MUST use the https scheme and MAY contain port, =
path, and query parameter components.



3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on =
one aspect here:


A Claim is a well =
understood term in the field. We should use it. It is still a Claim if =
it comes directly from the GS or from an =
RS. 
I do not understand =
why a Resource release by an RS shall be h to as a claim, even if the =
content of the Resource is an assertion. It will lead to confusion. If =
we limit claims to information GS releases into Token, User Info, and =
other objects it returns, this will help separate responsibilities =
between GS and RS. As soon as RS services and information, this is =
called a Resource, no matter the nature of the content of that =
information.

This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =
=E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in =
the context of GNAP, that makes it a resource. So we need a different =
word for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s going to be about the user, and that=E2=80=99s what we=E2=80=99=
re going to focus on here, but since you can also get information about =
the user from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=
=80=9D. I think this has been at the heart of a lot of confusion in =
recent threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=
=9D mean what it already does, and let=E2=80=99s find a way to =
differentiate between when an item, claim or otherwise,  comes =
as part of a resource and when it comes back directly. This is an =
important differentiating feature for GNAP.

Some straw man ideas, none of which =
I=E2=80=99m particularly in love with:

 - direct data
 - properties
 - =
details
 - statements

The important thing here is that it=E2=80=
=99s not necessarily :about: the RO, and that it is :not: in a =
resource.

Any other =
thoughts?

 =E2=80=94 Justin














=

--Apple-Mail=_3C125852-586E-4D30-ACA2-EEB810C37313--


From nobody Mon Jul 27 15:49: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 250373A095F for ; Mon, 27 Jul 2020 15:49:38 -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_FILL_THIS_FORM_SHORT=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 pqJ_7FZgihgv for ; Mon, 27 Jul 2020 15:49:33 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450: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 BD2453A08F8 for ; Mon, 27 Jul 2020 15:49:32 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id v15so5371769lfg.6 for ; Mon, 27 Jul 2020 15:49: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=h6l3G+MPzm71BkXcEDslLmxBcL3YnDIQvI05JdSBqzE=; b=sx6BU4iaOxbYUUvl8/8/ZwjhJORfKCRN3pyTlpc38ly9aYedwrg9B53MfmqgXbH1/x DSTQ6XCaBpBU5rS5v6PgnXUwpaNyxI28scIY5iPep8EMCawdzTMNczslxKk9kSQdViOC 3vXcHJUaJdGkp9Zz7/grUBLF2paea9UrVnrk3q7ZiD1nC0x3oAXMpU7dvP+G4nVcqqtk HruY0f6+G2nLBaLBRiwB2/pqug/YPBRJNeP4Uh3tkhu91RLKLEgaIeqqJPXzGhLKrKQw IINA2f0ydL2lPLwOKm+oDBQ2Wv7f9DzVelgnod+VL01PiHdyB0KhUzpAdZYvLbB3l+p5 t6ww==
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=h6l3G+MPzm71BkXcEDslLmxBcL3YnDIQvI05JdSBqzE=; b=MPqWE3B2uTwq+igsq28DuUGMZaWQA6U0kceWLHJiArh2uRfhSmyxWWy7CCumoe7OTi QxhiFwK/KI3Ujtt8FsafbdQsKrNkbig7HGnJxQPj6lQfBF7GKvsSX3irqxx6AeYCYA0l 7QgfGHHtH61K941YRYK7D3twvtdvjEOFtW//wLME64npqoCxDUbr9sW6AVPS8cUTa3f2 MZ/Z6qahTHEtqD7P9u4fVLwCCu2RgOFrK+li0zzJOuExs4OsT27/Srcf2R4eFOocXQ/R 4PSs1k0d/btMe2cJZgjuvov+rpku4BxWWjgGRqw+KRNPcvlEItpfj0AR0YpsGAERfC27 UP/A==
X-Gm-Message-State: AOAM533WDT2PtoUf+EqOYDu6yLiaWseviXZz3nxWqakfBmo9v+v4f/au jgK+ft48oF0kx9VpZ3L/S2hioS7PvHFt2NI0HNw=
X-Google-Smtp-Source: ABdhPJwC7QH5JMKWe9hZOlSF1SgC6k5PtwgRVc6KB7QwCKWP/1Fi/z+cuMZkSak+zD561huCNGmjdsvzki0F3BtLaK8=
X-Received: by 2002:a19:fc14:: with SMTP id a20mr12841153lfi.0.1595890170430;  Mon, 27 Jul 2020 15:49:30 -0700 (PDT)
MIME-Version: 1.0
References:       <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>        <7b313658-f7f1-dad1-33aa-7d2107436856@free.fr>
In-Reply-To: <7b313658-f7f1-dad1-33aa-7d2107436856@free.fr>
From: Dick Hardt 
Date: Mon, 27 Jul 2020 15:48:53 -0700
Message-ID: 
To: Denis 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b5986605ab7422e0"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 27 Jul 2020 22:49:38 -0000

--000000000000b5986605ab7422e0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis

The student (User) goes to the registration page of the University (the
Client)

Similar to your example, the Client has a list of GS that it are
acceptable, or RS that may be acceptable.

If the User selects a GS, then the Client starts a GNAP flow with the GS.

If the User selects an RS, then the Client can call the RS to determine
which GSes to offer the User to use to get access to the RS.

In summary, the University wants to consume Claims about the User, so it is
the Client.

/Dick



On Mon, Jul 27, 2020 at 12:49 AM Denis  wrote:

> Hi Dick,
>
> The floor is yours.
>
> Would you explain how you would handle the use case of a student
> registering to a new University ?
>
> Would you also elaborate why in my explanations below, you think that "th=
e
> University's registration system is the Client, not a Resource Server" ?
>
> Denis
>
> Hi Denis
>
> I would think in your example below, that the University's registration
> system is the Client, not a Resource Server.
>
> Have a good night's sleep!
>
>
>
> On Fri, Jul 24, 2020 at 12:04 PM Denis  wrote:
>
>> Hi Dick,
>>
>> In order to send back a quick reply tonight, I will only respond to one
>> of your questions:
>>
>> [Denis] How would be the data flow when access tokens from two GSs are
>> needed by a RS ?
>>
>> [Dick] I don't know of a use case where two tokens would be needed by an
>> RS. Would you elaborate?
>>
>> I already described on the list the case of a student registering to a
>> new University.
>>
>> First, the student connects to the RS from the new University and opens
>> an account
>> (at this time the student is using a pseudo and a private key to
>> authenticate). He fills some forms
>> and indicate its citizenship, his home address and his graduation in his
>> current university.
>>
>> When he is finished, he indicates that he wants to perform a Registratio=
n
>> operation.
>>
>> From the information gathered in the forms, the RS informs the client
>> that it needs two access tokens:
>>
>>    - one to demonstrate that his name and current home address are
>>    correct,and
>>    - another one to demonstrate that he got a graduation from its
>>    current University.
>>
>> Depending upon the information captured in the forms, the RS also
>> indicates which ASs/GSs are acceptable
>> and which kind of attributes are requested.
>>
>> The user consent and choice is performed by the client and once approved
>> by the student, two access tokens are separately requested.
>> Finally, two access tokens are presented to the RS while invoking a
>> Registration operation.
>>
>> Note that the start of the story is to open an account, e.g. using FIDO.
>> The needs of the RS are only disclosed to the student once he has filled
>> some forms
>> and indicated that he wanted to perform a Registration operation. Thus,
>> the needs that are revealed by the RS are dependant both upon the operat=
ion
>> that the student is willing to perform and the information collected in
>> the forms.
>>
>> Denis
>>
>> Hi Denis, comments inserted ...
>>
>> On Fri, Jul 24, 2020 at 9:08 AM Denis  wrote:
>>
>>> Hi Dick,
>>>
>>> draft-hardt-xauth-protocol-13 describes a solution without clearly
>>> stating what the problem(s) to be solved is/are.
>>>
>>
>> I agree that the problem description is not as crisp as I would like it
>> to be. A challenge is that there is a broad spectrum of use cases solved=
 by
>> OAuth 2, and OpenID Connect, as well as the new use cases that are solve=
d
>> by GNAP.
>>
>> That is why I am suggesting we gather some use cases so we have a common
>> understanding of the problems that are in scope.
>>
>>
>>>
>>> At the moment, draft-hardt-xauth-protocol-13 includes a single figure o=
n
>>> page 4 and from previous discussions I understood that
>>> it is no more up-to-date since the first data flow is now a contact wit=
h
>>> a RS. The reason(s) for the GS to contact a RO has still not
>>> been explained (since the inputs and outputs are not described). The
>>> discovery information made available at various steps at the RS
>>> is not described.
>>>
>>
>> I have made no updates as we are in a quiet period prior to the WG
>> meeting next week when documents cannot be updated.
>>
>>
>>>
>>> Figure 4 shows only a single RS. Is the relaying of one operation by
>>> that RS to a second RS in the scope of this document ?
>>> If yes, how is it handled ?
>>>
>>
>> I view that as an advanced use case that would be covered in a separate
>> document.
>>
>>
>>>
>>> Figure 4 shows only a single GS. How would be the data flow when access
>>> tokens from two GSs are needed by a RS ?
>>>
>>
>> I don't know of a use case where two tokens would be needed by an RS.
>> Would you elaborate?
>> The RS being able to accept tokens from two different GSes is covered,
>> but the Client is only using a token from one GS at a time.
>>
>>
>>
>>>
>>> What we need first is not a set of "use cases" but a clear model with a
>>> data flows and a list of its properties/characteristics.
>>>
>>
>> I disagree. The use cases describe the problems we are looking to solve.
>> The data flows are part of the solution. For example, from my understand=
ing
>> of your use case, you don't want the GS to have visibility into the User=
's
>> activity. Am I correct that this is one of your requirements for your us=
e
>> case?
>>
>>
>>
>>> Then after, we can understand much better which use cases can/will be
>>> supported. For example, shall a RS (or its RO) have
>>> prior relationships with the GS ? What is the difference/implications
>>> when it has or it hasn't ?
>>>
>>> In order to have a fair comparison, we should try to list model
>>> properties/characteristics.
>>>
>>> At the moment, the model I have described including the data flows is
>>> clear. The discovery information made available by a RS is clear.
>>> I have not listed all its properties/characteristics of that model, but
>>> I am pretty sure that you already have a flavour of it.
>>>
>>> In the mean time, it would be nice if you could show using two figures:
>>>
>>>    - the case of the relaying of one operation by one RS to a second RS
>>>    (if it is in the scope of your document),
>>>    - the case where access tokens from two GSs are needed by one RS (if
>>>    it is in the scope of your document).
>>>
>>>
>> See above
>>
>>
>>>
>>>    -
>>>
>>> Denis
>>>
>>> Hi Denis
>>>
>>> I think it would be useful to take a step back and for you to describe
>>> your use case.
>>> After that, we can explore the different ways that your use case can be
>>> addressed.
>>>
>>> Looking at your previous communication, it describes the solution, and
>>> the justification,
>>> but it is not clear what use cases you are needing to solve.
>>>
>>> /Dick
>>>
>>>
>>> =E1=90=A7
>>>
>>> On Wed, Jul 22, 2020 at 9:34 AM Denis  wrote:
>>>
>>>> Hello Dick,
>>>>
>>>> I have identified the reason of the major difference between our two
>>>> approaches.
>>>>
>>>> Access control may be performed using either ACLs (Access Control
>>>> Lists) or Capabilities.
>>>>
>>>> *Note *: a capability identifies a resource and an allowed operation
>>>> that can be performed on that resource.
>>>>
>>>> You are advocating a Capabilities approach while I am advocating an AC=
L
>>>> approach.
>>>>
>>>> The capabilities approach allows the GS to trace every operation
>>>> performed by the users on any RS known by a GS.
>>>> The management of these capabilities is made via the GS or at the GS b=
y
>>>> the various ROs. If the management is made
>>>> via the GS, then a trusted communication channel needs to be
>>>> established with every RO. If the management is made
>>>> at the GS, then an authentication mechanism needs to be established
>>>> with every RO. In the last case, the GS has the
>>>> ability to know all the capabilities of the users whether they are use=
d
>>>> or not. The less that can be said is that this model
>>>> is not privacy friendly.
>>>>
>>>> With the ACL approach, a RO directly manages an ACL placed in front of
>>>> each RS. The Access Control Decision Function
>>>> (ADF) at the RS is able to keep track from prior decisions. The GS is
>>>> kept ignorant of the content of these ACLs and only
>>>> delivers to its clients attributes that are placed into access tokens.
>>>> Such a model may be privacy friendly.
>>>>
>>>> Other comments are between the lines prefixed with [Denis].
>>>>
>>>>
>>>> On Tue, Jul 21, 2020 at 11:26 AM Denis  wrote:
>>>>
>>>>> Hello Dick,
>>>>>
>>>>> Thank you for your feedback. Comments are between the lines.
>>>>>
>>>>> comments inserted ...
>>>>>
>>>>> On Tue, Jul 21, 2020 at 6:03 AM Denis  wrote:
>>>>>
>>>>>> Hello Dick,
>>>>>>
>>>>>> I duplicate the most important comment at the beginning of this emai=
l:
>>>>>>
>>>>>> You are considering using an access control model to build a workflo=
w
>>>>>> model.
>>>>>>
>>>>>> While it may be interesting to define a workflow model, this should
>>>>>> be considered
>>>>>> as a separate and different work item.
>>>>>>
>>>>>> See the other comments between the lines.
>>>>>>
>>>>>> On Mon, Jul 20, 2020 at 2:05 AM Denis  wrote:
>>>>>>
>>>>>>> Hi Dick,
>>>>>>>
>>>>>>> On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:
>>>>>>>
>>>>>>>> Hello Francis and Dick,
>>>>>>>>
>>>>>>>> The good news first: we are making some progress. We are now close
>>>>>>>> to an agreement with steps (1) up to (3),
>>>>>>>> ... except that the place where the user consent is captured is no=
t
>>>>>>>> mentioned/indicated.
>>>>>>>>
>>>>>>>
>>>>>>> This major question which is currently left unanswered is where,
>>>>>>> when and how the user consent is captured.
>>>>>>>
>>>>>>
>>>>>> When is covered, per the sequence. How and where are out of scope of
>>>>>> what I drafted.
>>>>>>
>>>>>> It is clear that the "User consent and choice" is not currently
>>>>>> addressed in the draft, but it should.
>>>>>> The support of the "User consent and choice" has strong implications
>>>>>> not only in the sequences of the exchanges
>>>>>> but also by which entity it should be performed.
>>>>>>
>>>>> "consent" is in the latest draft 7 times.
>>>>>
>>>>> "Consent" is present 5 times. The User consent is different from the
>>>>> RO consent (when/if it is required).
>>>>>
>>>>> The server acquires consent and authorization from the user *and/**or
>>>>> resource owner **if required.*
>>>>>
>>>>> User consent is *often required* at the GS. GNAP enables a Client
>>>>> and  GS to negotiate the interaction mode for the GS to obtain consen=
t.
>>>>>
>>>>> The GS *may *require explicit consent from the RO or User to provide
>>>>> these to the Client.
>>>>>
>>>>> The User consent is not an alternative to the RO consent. So using
>>>>> "and/or" in the first sentence is incorrect.
>>>>>
>>>>
>>>> My language is sloppy there. Consent is always from the RO. The User
>>>> may be the RO.
>>>>
>>>> [Denis] No. Once again: The "*User consent*" is different from what
>>>> you call the "*RO consent*" (when/if it is required).
>>>> The "RO consent" is not in fact a consent but the release of a
>>>> capability to a client by one of the many R0s with which
>>>> the GS has relationships.
>>>>
>>>> Since the second sentence is using the wording "often required" there
>>>>> is no requirement to get the User consent.
>>>>>
>>>> User consent may not be required. There may not be a User. The consent
>>>> may have been gathered previously.
>>>>
>>>> [Denis] In order to follow the privacy principles, a "User consent"
>>>> phase is required. The User is a natural person.
>>>> A Client is called either by a User (i.e. a natural person) or by a
>>>> Client application.
>>>>
>>>> The second sentence does not consider the possibility to get the User
>>>>> consent in a place different from the GS.
>>>>>
>>>> Agreed. But we do agree that the GS gets the consent, either directly
>>>> from the RO, or from the Client (in your example).
>>>>
>>>> [Denis] No. I disagree. In an ACL based systems, the GS does not need
>>>> to ask or receive any consent.
>>>> The client selects the set of attributes that it wants to be inserted
>>>> into an access token.
>>>> If the GS has the requested attributes, then it provides them,
>>>> otherwise it returns an error to the Client.
>>>>
>>>> IMO, the User consent should be captured by the Client, i.e. not by th=
e
>>>>> GS.
>>>>> The information used to obtain the User consent should be standardize=
d
>>>>> (... and it can be standardized).
>>>>>
>>>>> I think the abstract sequence as proposed by Francis is a great
>>>>> addition, and would clarify where consent is in the sequence.
>>>>>
>>>>> The current sketch does not illustrate the place the User Consent is
>>>>> captured, in particular by the Client.
>>>>>
>>>> It is an abstraction. The GS receives the consent. How consent is
>>>> gathered is a detail that is dependent on the use case.
>>>>
>>>> [Denis] I really wonder whether there is really a "consent" to be
>>>> received by the GS in both cases (i.e. ACLs or Capabilities).
>>>>
>>>>    - For ACLs, the consent needs to be done by the Client.
>>>>    - For Capabilities, the current description is not clear since the
>>>>    inputs and the outputs for this "consent" phase
>>>>    are not currently described in the draft.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>> Another important point to consider and to explain is related to the
>>>>>>> assurances that the user can obtain about
>>>>>>> the respect of his choices. This point is currently left unanswered
>>>>>>> in draft-hardt-xauth-protocol-13.
>>>>>>>
>>>>>> This point is equally important: such assurance can only be obtained
>>>>>> if the access token returned to the client
>>>>>> is not considered to be opaque to the client. This is a necessary
>>>>>> condition but not the single condition:
>>>>>> the Client must also be in a position to capture/memorize the "User
>>>>>> consent and choice" of the user in order to be able
>>>>>> to verify it afterwards using the content of the access token(s).
>>>>>>
>>>>>
>>>>> We disagree on this being a requirement for all use cases. It may be
>>>>> in some.
>>>>>
>>>>> OK. Then this means that there will be no sentence in the draft such
>>>>> as :
>>>>> "access tokens returned to the client are not considered to be opaque
>>>>> to the client".
>>>>>
>>>>
>>>> For OAuth use cases, which GNAP supports, the access token is opaque t=
o
>>>> the Client. As you have noted, there are use cases where the access to=
ken
>>>> is NOT opaque.
>>>>
>>>> [Denis] Wait a second. There is no requirement to support all OAuth us=
e
>>>> cases.
>>>> I believe that there is a requirement to support OAuth 2.0 ASs, while
>>>> the clients may be different
>>>> and hence GNAP clients do not need to inherit of the limitations of
>>>> OAuth 2.0 clients.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> If a RO needs to be involved and since a RO is directly associated
>>>>>>>> with a RS, why can't it be directly queried
>>>>>>>> by the appropriate RS after step (2) or later on ?
>>>>>>>>
>>>>>>>
>>>>>>> Good question. Perhaps you can expand on a use case where that woul=
d
>>>>>>> be useful?
>>>>>>>
>>>>>>> Before I expand, would you be able to explain first under which
>>>>>>> circumstances a RO needs to be queried by a GS ?
>>>>>>> How can the GS identify which RO to query ?
>>>>>>>
>>>>>> If the User is the RO, then the GS knows who to query.
>>>>>>
>>>>>> I still have difficulties to understand what you mean here.
>>>>>> How could a GS know that "the User is the RO" ?  If "the User is the
>>>>>> RO", why does the GS needs to query the User ?
>>>>>>
>>>>>
>>>>> To get consent?
>>>>>
>>>>> To get a "RO consent" to himself ???
>>>>>
>>>>
>>>> The GS needs consent from the RO. If the RO is the User, then consent
>>>> from the RO is equivalent to consent from the User.
>>>>
>>>> [Denis] See above.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>> If the RO is a separate entity, then the GS knows the RO from the RS
>>>>>> being queried.
>>>>>>
>>>>>>  ... and this gives the ability for the GS to log/trace all the RSs
>>>>>> accessed by a given User and at which instant of time the access tok=
en has
>>>>>> been granted.
>>>>>>
>>>>>> An example is a user would like access to an enterprise asset where =
a
>>>>>> workflow is started to gain approval, and an administrator or manage=
r
>>>>>> provides consent.
>>>>>>
>>>>>> Thanks for this example. I finally understand what you have in mind:
>>>>>> you are considering using an access control model to build a *workfl=
ow
>>>>>> model*.
>>>>>> While it may be interesting to define a workflow model, this should
>>>>>> be considered as a *separate and different work item*.
>>>>>>
>>>>>
>>>>> The actual workflow is out of scope.
>>>>>
>>>>> I am glad you agree with this. But this means that your example was
>>>>> not appropriate to illustrate your point.
>>>>>
>>>>
>>>> It illustrates a use case where the RO and User are not the same party=
,
>>>> and why the GS needs to query the RO, which was your question if I
>>>> understood it correctly.
>>>>
>>>> [Denis] Since the inputs and the outputs for this "RO consent" phase
>>>> are not currently described in the draft, the point is still unsolved.
>>>>
>>>> As soon as there is a RO consent obtained at the GS, the major problem
>>>>> is that the GS is able to act as Big Brother.
>>>>> If a RO consent is performed at the RS, then the GS will not know who
>>>>> the RS is: it is then unable to act as Big Brother,
>>>>> even if it would enjoy to play that role.
>>>>>
>>>> In an enterprise use case, the GS's knowledge of who is accessing whic=
h
>>>> RS is a feature.
>>>>
>>>> Do you mean that it is "normal" in an enterprise that a single point o=
f
>>>> control is able to trace all their actions ?
>>>> From a security point of view, a single point of failure will have
>>>> dramatic consequences.
>>>>
>>>> In your use cases, it seems that the RO is the User.
>>>>
>>>> I do hope that you have finally understood that, in my use case, the R=
O
>>>> is **not** the User.
>>>>
>>>> The GS knows the User is wanting to let a Client access something. If
>>>> the access token is generic, and could be presented to any RS that pro=
vides
>>>> a standardized function,
>>>> then the GS does not know which RS is being accessed by a Client for
>>>> the User. This seems to meet your privacy objectives. If not, what is =
wrong?
>>>>
>>>> For security reasons, an access token needs to be targeted (which does
>>>> not necessarily mean that an identifier of the RS shall be included in=
to
>>>> the access token).
>>>>
>>>> if the admin grants access, then the access granted to the client
>>>>> changes.
>>>>>
>>>>>> The model you propose may be suited for an enterprise environment bu=
t
>>>>>> is not scalable over the Internet.
>>>>>>
>>>>> It is one of the use cases we are working to address.
>>>>>
>>>>>> What is needed is an access control model usable over the Internet
>>>>>> with millions of RSs and thousands of ASs/GSs.
>>>>>>
>>>>> I agree the model should also scale to internet scale.
>>>>>
>>>>> Fine. Another point on which we are in agreement.
>>>>>
>>>>> The model can scale to the Internet based on the following assumption=
s:
>>>>>
>>>>> The flow starts with the steps (1) to (4) as illustrated by Francis,
>>>>> i.e. the flow starts with a contact with a RS.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS |
>>>>>  |RO | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Request  =
   |
>>>>>    |   |-------->|       |      |      |   |         |(2) Service Int=
ent
>>>>> |   |         |------>|      |      |   |         |(3) AuthZ Challeng=
e  |
>>>>> |         |<------|      |      |   |         |(4) AuthZ Request    |=
   |
>>>>>       |------------->|      |*
>>>>>
>>>>> The GS/AS does not need to have any prior relationship with ROs and/o=
r
>>>>> RSs.
>>>>>
>>>>> Furthermore, it is possible to prevent the GS to act as Big Brother
>>>>> when the identity of the RS is not disclosed to the GS.
>>>>>
>>>>
>>>> What happens after (4) above?
>>>>
>>>> [Denis] The key point is that we first need to agree on the first four
>>>> exchanges. Do we ?
>>>>
>>>> The fifth exchange is different whether ACLs or Capabilities are being
>>>> used.
>>>>
>>>>
>>>>
>>>>> Which information is supposed to be presented to the RO ?
>>>>>>>> Which information is supposed to be returned by the RO ?
>>>>>>>>
>>>>>>>
>>>>>>> Just like how the user authenticates to an AS, how the AS and RO
>>>>>>> communicate is out of scope.
>>>>>>>
>>>>>>> At the moment, the usefulness of a dialogue between a GS and a RO
>>>>>>> has not been explained, nor demonstrated.
>>>>>>> The question is about the functionality of that dialogue in terms o=
f
>>>>>>> input and output information (and not about
>>>>>>> the design of a protocol or of a user interface). Anyway, AFAIU a
>>>>>>> dialogue between a GS and a RO is optional.
>>>>>>>
>>>>>>
>>>>>> See enterprise example above.
>>>>>>
>>>>>> It is not an access control example, but a workflow example.
>>>>>>
>>>>>> Access  control has been defined a long time ago and the last editio=
n
>>>>>> of the model has been confirmed in year 1996: ISO/IEC 10181-3: 1996.
>>>>>> "Information technology =E2=80=94 Open Systems Interconnection =E2=
=80=94 Security
>>>>>> frameworks for open systems: Access control framework =E2=80=94 Part=
 3".
>>>>>>
>>>>>> Two major functions have ben defined: an Access Control Enforcement =
Function
>>>>>> (AEF) and an Access Control Decision Function(ADF).
>>>>>>
>>>>>> Access Control Enforcement Function (AEF):
>>>>>> A specialized function that is part of the access path between an
>>>>>> initiator and a target on each access request and enforces the decis=
ion
>>>>>> made by the ADF.
>>>>>> Access Control Decision Function (ADF) :
>>>>>> A specialized function that makes access control decisions by
>>>>>> applying access control policy rules to an access request, ADI (of
>>>>>> initiators, targets, access requests,
>>>>>> or that retained from prior decisions), and the context in which the
>>>>>> access request is made.
>>>>>>
>>>>>> The role of the RO is to define the "access control policy rules" at
>>>>>> the RS according to the context in which the access request is made.
>>>>>>
>>>>> I'm pretty familiar with access control systems. :)
>>>>>
>>>>> I would say that the access control is happening at the RS. The clien=
t
>>>>> presents a token when accessing an API.
>>>>> The RS uses the token, and any policy required, to make an access
>>>>> decision.
>>>>>
>>>>> Fine. It looks like we are in agreement. Unfortunately, this is not
>>>>> the case just below.
>>>>>
>>>>> Here is flow:
>>>>>
>>>>> 1) The Client requests access to an RS from the GS.
>>>>>
>>>>> No. We are no more in agreement. This is different from the flow draw=
n
>>>>> by Francis.
>>>>>
>>>> My bad. Typo. I meant RO.
>>>>
>>>>
>>>>> 2) The GS queries the RS if access should be granted.
>>>>>
>>>>>  No. The GS should not be forced to have a flow with the RS.
>>>>>
>>>> Same mistake as above, I meant RO.
>>>>
>>>>> 3) If access is granted, the GS creates an access token representing
>>>>> the granted access, and returns it to the Client.
>>>>>
>>>>> This model is by no way conformant to ISO/IEC 10181-3: 1996
>>>>>
>>>> I'm unclear on why, or why it is even relevant.
>>>>
>>>>> 4) The Client presents the access token to the RS to show it has been
>>>>> granted access.
>>>>>
>>>>> No. The client presents a token when accessing an API. The RS uses th=
e
>>>>> token, and any policy required, to make an access decision.
>>>>> The token never contains an information like "Please grant an access
>>>>> to the holder of this token".
>>>>>
>>>> Let me provide more clarity in the sentence:
>>>>
>>>> The Client presents the access token to the RS, to show the RS that th=
e
>>>> Client has been granted access to a resource at the RS by the GS.
>>>>
>>>> [Denis] This time, please consider both the ACLs approach and the
>>>> Capabilities approach.
>>>>
>>>>
>>>>
>>>>> A couple advantages of this model:
>>>>> - that the RS does not need to know much, if anything about the
>>>>> Client.
>>>>> - the access token MAY be self contained so that the Client does not
>>>>> need to query the GS on each access.
>>>>>
>>>>> There are so many disadvantages that I will not list them.
>>>>>
>>>> Darn: I clearly was not firing on all cylinders when I typed this out.
>>>> Let me correct:
>>>>
>>>> - the access token MAY be self contained so that the RS does not need
>>>> to query the GS on each access to the RS by the Client.
>>>>
>>>> [Denis] A few comments in the case of a capability approach:
>>>>
>>>> - for each GS, the RS needs to locally manage which operation(s) is/ar=
e
>>>> allowed to it.
>>>>
>>>> - the GS needs to establish a trusted communication channel or an
>>>> authentication mechanism with each RO
>>>>    (which is associated with an explicit RS identifier).
>>>>
>>>> - the GS could play the role of the RO and hence be in a position to
>>>> issue any capability for any RS (without a "RO consent").
>>>>
>>>>    The target of an attack will clearly be the GS.
>>>>
>>>> I would not say that GNAP is an access control protocol, as how the RS
>>>>> uses the token to determine access is out of scope.
>>>>>
>>>>> This is where we have a major discrepancy: how the RS uses the token
>>>>> to determine access is *within* the scope.
>>>>>
>>>> [Denis] Do you agree or disagree ?
>>>>
>>>> The RS announces in advance to the client what it needs so that the
>>>>> client can perform a a given operation and if the client supplies the
>>>>> requested attributes
>>>>> obtained from some GS/AS(s) trusted by the RS, then access to that RS
>>>>> is granted by the RS. If the RS cannot perform the requested operatio=
n on
>>>>> its own,
>>>>> then the client should be informed about some requested attributes
>>>>> that need to be obtained from some GS/AS(s) trusted by the next RS(s)=
 in a
>>>>> chain
>>>>> for subsequent operations. The User consent should also be obtained
>>>>> before performing the chaining operation.
>>>>>
>>>>> Chaining operations between RSs over the Internet is within the scope
>>>>> (... and may be achieved).
>>>>>
>>>> [Denis] Do you agree or disagree ?
>>>>
>>>> Denis
>>>>
>>>>
>>>>>>
>>>>>>> For many use cases, the User is the RO, and the interaction is
>>>>>>> through a user interface, not a machine protocol.
>>>>>>>
>>>>>>> Wait a second. You wrote "the User is the RO". The User is
>>>>>>> attempting to make an access to a RS by using a Client.
>>>>>>> *That* User is not the RO of the RS.
>>>>>>>
>>>>>> The user being the RO is the initial use case for OAuth.
>>>>>>
>>>>>> OAuth 2.0 is no more mandating such a case.
>>>>>>
>>>>>
>>>>> I don't know what you mean by that.
>>>>>
>>>>> Copy and paste from draft-ietf-oauth-security-topics:
>>>>>
>>>>> OAuth initially assumed a static relationship between client,
>>>>> authorization server and resource servers.  (...)
>>>>> With the increasing adoption of OAuth, this simple model dissolved
>>>>> and, in several scenarios, was replaced
>>>>> by a dynamic establishment of the relationship between clients on one
>>>>> side and the authorization and
>>>>> resource servers of a particular deployment on the other side.
>>>>>
>>>>> This way, the same client could be used to access services of
>>>>> different providers (in case of standard APIs,
>>>>> such as e-mail or OpenID Connect) or serve as a frontend to a
>>>>> particular tenant in a multi-tenancy environment.
>>>>>
>>>>>
>>>> This sentence does not mention the RO or the Client. I'm confused what
>>>> we are talking about
>>>>
>>>>>
>>>>>
>>>>>> A client application would like access to the user's photos at a
>>>>>> photo sharing site. The resource is the user's photos. The user is t=
he
>>>>>> owner of that resource.
>>>>>>
>>>>>> If the user has already pre established the access control policy
>>>>>> rules so that it can access to his own photos
>>>>>> then he does not need to grant in real time any additional
>>>>>> authorization.
>>>>>>
>>>>> I don't understand what you are trying to say. The photo sharing
>>>>> example was a driving use case for the creation of OAuth.
>>>>>
>>>>> We would need to revisit the original scenario and consider if it can
>>>>> be addressed in a different way than the original way.
>>>>>
>>>> The use case is the same. Is there a different solution you are
>>>> proposing?
>>>>
>>>>
>>>>
>>>> --
>>>> Txauth mailing 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
>>
>>
>>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000b5986605ab7422e0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis

The student (User) goes to the=
 registration page of the University (the Client)

=
Similar to your example, the Client has a list of GS that it are acceptable=
, or RS that may be acceptable.

If the User select=
s a GS, then the Client starts a GNAP flow with the GS.

If the User selects an RS, then the Client can call the RS to determi=
ne which GSes to offer the User to use to get access to the RS.
<=
br>
In summary, the University=C2=A0wants to consume Claims about=
 the User, so it is the Client.

/Dick

=



On Mon, Jul 27, 2020 at 12:49 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hi Dick,

    


    

    
The floor is yours.

    


    

    
Would you explain how you would handle
      the use case of a student registering to a new University ?

    


    

    
Would you also elaborate why in my
      explanations below, you think that "the University's=C2=A0re=
gistration
      system is the Client, not a Resource Server" ?
      


      

    

    
Denis

    

    

    

     =20
      
Hi Denis
        


        

        
I would think in your example below, that the
          University's=C2=A0registration system is the Client, not a Re=
source
          Server.

        


        

        
Have a good night's sleep!

        


        

        


        

      

      

      

        
On Fri, Jul 24, 2020 at 12:04
          PM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hi Dick,

              

            

            
In order to send back a quick reply tonight, I will
              only respond to one of your questions:

            

              
 [Denis] How would be the data flow when
                access tokens from two GSs are needed by a RS ?

                


                

                
[Dick] I don't know of a use case where two tokens
                  would be needed by an RS. Would you elaborate?

              

              
I already described on the list the case of a student
                registering to a new University.

              
 

              

              
First, the student connects to the RS from the new
                University and opens an account 

                (at this time the student is using a pseudo and a
                private key to authenticate). He fills some forms 

                and indicate its citizenship, his home address and his
                graduation in his current university. 

                

                When he is finished, he indicates that he wants to
                perform a Registration operation.

              


              

              
From the information gathered in the forms, the RS
                informs the client that it needs two access tokens:

              
    
                
  • one to demonstrate that his name and current home
                  address are correct,and
    • 
                
  • another one to demonstrate that he got a graduation
                  from its current University.
    • 
              

              
Depending upon the information captured in the forms,
                the RS also indicates which ASs/GSs are acceptable 

                and which kind of attributes are requested.

              
 

              

              
The user consent and choice is performed by the
                client and once approved by the student, two access
                tokens are separately requested.

                Finally, two access tokens are presented to the RS while
                invoking a Registration operation.

              


              

              
Note that the start of the story is to open an
                account, e.g. using FIDO. The needs of the RS are only
                disclosed to the student once he has filled some forms 

                and indicated that he wanted to perform a Registration
                operation. Thus, the needs that are revealed by the RS
                are dependant both upon the operation 

                that the student is willing to perform and the
                information collected in the forms.

              


              

              
Denis

            

            

            

              

                
Hi Denis, comments inserted ...=C2=A0

                

                

                  
On Fri, Jul 24, 202=
0
                    at 9:08 AM Denis <denis.ietf@free.fr>
                    wrote:

                  

                  

                    

                      

                        
Hi Dick,

                        


                        

                        
draft-hardt-xauth-protocol-13 describes a
                          solution without clearly stating what the
                          problem(s) to be solved is/are.

                      

                    

                  

                  


                  

                  
I agree that the problem description is not as
                    crisp as I would like it to be. A challenge is that
                    there is a broad spectrum of use cases solved by
                    OAuth 2, and OpenID Connect, as well as the new use
                    cases that are solved by GNAP.

                  


                  

                  
That is why I am suggesting we gather some use
                    cases so we have a common understanding of the
                    problems that are in scope.

                  
=C2=A0

                  

                    

                      

                        


                        

                        
At the moment,
                          draft-hardt-xauth-protocol-13 includes a
                          single figure on page 4 and from previous
                          discussions I understood that 

                          it is no more up-to-date since the first data
                          flow is now a contact with a RS. The reason(s)
                          for the GS to contact a RO has still not 

                          been explained (since the inputs and outputs
                          are not described). The discovery information
                          made available at various steps at the RS 

                          is not described.

                        

                      

                    

                  

                  


                  

                  
I have made no updates as we are in a quiet
                    period prior to the WG meeting next week when
                    documents cannot be updated.

                  
=C2=A0

                  

                    

                      

                        

                          


                          

                        

                        
Figure 4 shows only a single RS. Is the
                          relaying of one operation by that RS to a
                          second RS in the scope of this document ?

                          If yes, how is it handled ?

                        

                      

                    

                  

                  


                  

                  
I view that as an advanced use case that would be
                    covered in a separate document.

                  
=C2=A0

                  

                    

                      

                        
 

                        


                        

                        
Figure 4 shows only a single GS. How would
                          be the data flow when access tokens from two
                          GSs are needed by a RS ?

                        

                      

                    

                  

                  


                  

                  
I don't know of a use case where two tokens woul=
d
                    be needed by an RS. Would you elaborate?

                  
The RS being able to accept tokens from two
                    different GSes is covered, but the Client is only
                    using a token from one GS at a time.

                  


                  

                  
=C2=A0

                  

                    

                      

                        
 

                        

                        What we need first is not a set of "use cases&=
quot;
                        but a clear model with a data flows and a list
                        of its properties/characteristics. 

                      

                    

                  

                  


                  

                  
I disagree. The use cases describe the problems
                    we are looking to solve. The data flows are part of
                    the solution. For example, from my understanding of
                    your use case, you don't want the GS to have
                    visibility into the User's activity. Am I correct
                    that this is one of your requirements for your use
                    case?

                  


                  

                  
=C2=A0

                  

                    

                      
 

                      
Then after, we can understand much better
                        which use cases can/will be supported. For
                        example, shall a RS (or its RO) have 

                        prior relationships with the GS ? What is the
                        difference/implications when it has or it hasn'=
t
                        ?

                      

                      


                      

                      
In order to have a fair comparison, we should
                        try to list model properties/characteristics.

                      


                      

                      
At the moment, the model I have described
                        including the data flows is clear. The discovery
                        information made available by a RS is clear.

                      
I have not listed all its
                        properties/characteristics of that model, but I
                        am pretty sure that you already have a flavour
                        of it.

                      


                      

                      
In the mean time, it would be nice if you
                        could show using two figures:

                      
    
                        
  • the case of the relaying of one operation by
                          one RS to a second RS (if it is in the scope
                          of your document),
    • 
                        
  • the case where access tokens from two GSs
                          are needed by one RS (if it is in the scope of
                          your document).
    
                        
    • 
                      

                    

                  

                  


                  

                  
See above

                  
=C2=A0

                  

                    

                      
    
                        
  •  
    
                        
    • 
                      

                      

                        
Denis

                      

                      


                      

                      

                        
Hi Denis
                          


                          

                          
I think it would be useful to take a step
                            back and for you to describe your use case.
                            

                            After that, we can explore the different
                            ways that your use case can be addressed.=C2=A0=


                          


                          

                          
Looking at your previous communication,
                            it describes the solution, and the
                            justification, 

                            but it is not clear what use cases you are
                            needing to solve.

                          


                          

                          
/Dick

                          


                          

                          


                          

                        

                        
3D""=
=E1=90=A7

                        

                        

                          
On Wed, Jul
                            22, 2020 at 9:34 AM Denis <denis.ietf@free.fr>
                            wrote:

                          

                          

                            

                              
Hello Dick,

                              


                              

                              
I have identified the reason of the
                                major difference between our two
                                approaches.

                              


                              

                              
Access control may be performed using
                                either ACLs (Access Control Lists) or
                                Capabilities.

                              


                              

                              
Note : a capability
                                identifies a resource and an allowed
                                operation that can be performed on that
                                resource.

                              

                              


                              

                              
You are advocating a Capabilities
                                approach while I am advocating an ACL
                                approach.

                              
The capabilities approach allows the GS
                                to trace every operation performed by
                                the users on any RS known by a GS.

                                The management of these capabilities is
                                made via the GS or at the GS by the
                                various ROs. If the management is made 

                                via the GS, then a trusted communication
                                channel needs to be established with
                                every RO. If the management is made 

                                at the GS, then an authentication
                                mechanism needs to be established with
                                every RO. In the last case, the GS has
                                the 

                                ability to know all the capabilities of
                                the users whether they are used or not.
                                The less that can be said is that this
                                model 

                                is not privacy friendly.

                              
With the ACL approach, a RO directly
                                manages an ACL placed in front of each
                                RS. The Access Contr=
ol
                                  Decision Functi=
on
                                    

                                    (ADF) at
                                  the RS is able to keep track from
                                  prior decisions. The GS is
                                kept ignorant of the content of these
                                ACLs and only 

                                delivers to its clients attributes that
                                are placed into access tokens. Such a
                                model may be privacy friendly.

                              
Other comments are between the lines
                                prefixed with [Denis].

                              

                                

                                  


                                    

                                      
On
                                        Tue, Jul 21, 2020 at 11:26 AM
                                        Denis <denis.ietf@free.fr>
                                        wrote:

                                      

                                      

                                        

                                          
Hello Dick,

                                          


                                          

                                          
 Thank you for your
                                            feedback. Comments are
                                            between the lines.

                                          


                                          

                                          

                                            

                                              
comments
                                                inserted ...=C2=A0

                                              

                                              

                                                
On
                                                  Tue, Jul 21, 2020 at
                                                  6:03 AM Denis <denis.ietf@free.fr>
                                                  wrote:

                                                

                                                

                                                  

                                                    
Hello Dick,

                                                    


                                                    

                                                    
I duplicate the
                                                      most important
                                                      comment at the
                                                      beginning of this
                                                      email:

                                                    

                                                      
You are
                                                        considering
                                                        using an access
                                                        control model to
                                                        build a work=
flow
                                                        model.

                                                         

                                                        While it may be
                                                        interesting to
                                                        define a
                                                        workflow model,
                                                        this should be
                                                        considered 

                                                        as a separate
                                                        and different
                                                        work item.

                                                    

                                                    
See the other
                                                      comments between
                                                      the lines.

                                                    

                                                    


                                                    

                                                    

                                                      
On
                                                        Mon, Jul 20,
                                                        2020 at 2:05 AM
                                                        Denis <denis.ietf@free.fr>=
 wrote:

                                                        

                                                          

                                                          

                                                          
Hi Dick,
                                                          


                                                          

                                                          

                                                          
=
On
                                                          Fri, Jul 17,
                                                          2020 at 9:21
                                                          AM Denis <denis.ietf@free.fr&=
gt;
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Francis and
                                                          Dick,

                                                          


                                                          

                                                          
The good
                                                          news first: we
                                                          are making
                                                          some progress.
                                                          We are now
                                                          close to an
                                                          agreement with
                                                          steps (1) up
                                                          to (3), 

                                                          ... except
                                                          that the place
                                                          where the user
                                                          consent is
                                                          captured is
                                                          not
                                                          mentioned/indicat=
ed.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          This major
                                                          question which
                                                          is currently
                                                          left
                                                          unanswered is
                                                          where, when
                                                          and how the
                                                          user consent
                                                          is captured.

                                                          

                                                          

                                                          


                                                          

                                                          
When is
                                                          covered, per
                                                          the sequence.
                                                          How and where
                                                          are out of
                                                          scope of what
                                                          I drafted. 

                                                          

                                                        

                                                      

                                                    

                                                    
It is clear that
                                                      the "User consen=
t
                                                      and choice" is n=
ot
                                                      currently
                                                      addressed in the
                                                      draft, but it
                                                      should.

                                                      The support of the
                                                      "User consent an=
d
                                                      choice" has stro=
ng
                                                      implications not
                                                      only in the
                                                      sequences of the
                                                      exchanges 

                                                      but also by which
                                                      entity it should
                                                      be performed.

                                                  

                                                

                                                
"consent" is=
 in the
                                                  latest draft 7 times.
                                                  

                                                

                                              

                                            

                                          

                                          
"Consent" is present=
 5
                                            times. The User consent is
                                            different from the RO
                                            consent (when/if it is
                                            required). 

                                          

                                          

                                            
The server acquires
                                              consent and authorization
                                              from the user and/o=
r
                                                resource owner if
                                                required.

                                            

                                            
User consent is often
                                                required at the GS.
                                              GNAP enables a Client and=C2=
=A0
                                              GS to negotiate the
                                              interaction mode for the
                                              GS to obtain consent.

                                            

                                            
 The GS may require
                                              explicit consent from the
                                              RO or User to provide
                                              these to the Client.

                                            

                                          

                                          
The User consent is not an
                                            alternative to the RO
                                            consent. So using "and/or&=
quot;
                                            in the first sentence is
                                            incorrect.

                                        

                                      

                                      


                                      

                                      
My language is sloppy there.
                                        Consent is always from the RO.
                                        The User may be the RO.

                                    

                                  

                                

                              

                              
[Denis] No. Once again: The "User
                                  consent" is different from what
                                you call the "RO consent"
                                (when/if it is required). 

                                The "RO consent" is not in fact a
                                consent but the release of a capability
                                to a client by one of the many R0s with
                                which 

                                the GS has relationships. 

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
Since the second sentence
                                            is using the wording "ofte=
n
                                            required" there is no
                                            requirement to get the User
                                            consent.

                                          

                                        

                                      

                                      
User consent may not be
                                        required. There may not be a
                                        User. The consent may have been
                                        gathered previously.

                                    

                                  

                                

                              

                              
[Denis] In order to follow the privacy
                                principles, a "User consent" phas=
e is
                                required. The User is a natural person.

                                A Client is called either by a User
                                (i.e. a natural person) or by a Client
                                application. 

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
 

                                          
The second sentence does
                                            not consider the possibility
                                            to get the User consent in a
                                            place different from the GS.
                                        

                                      

                                      
Agreed. But we do agree that
                                        the GS gets the consent, either
                                        directly from the RO, or from
                                        the Client (in your example).

                                    

                                  

                                

                              

                              
[Denis] No. I disagree. In an ACL based
                                systems, the GS does not need to ask or
                                receive any consent.

                                The client selects the set of attributes
                                that it wants to be inserted into an
                                access token.

                                If the GS has the requested attributes,
                                then it provides them, otherwise it
                                returns an error to the Client.

                              

                                

                                  

                                    

                                      

                                        

                                          
IMO, the User consent
                                            should be captured by the
                                            Client, i.e. not by the GS.
                                            

                                            The information used to
                                            obtain the User consent
                                            should be standardized (...
                                            and it can be standardized).
                                          

                                          

                                            

                                              
I
                                                think the abstract
                                                sequence as proposed by
                                                Francis is a great
                                                addition, and would
                                                clarify where consent is
                                                in the sequence. 

                                            

                                          

                                          
The current sketch does not
                                            illustrate the place the
                                            User Consent is captured, in
                                            particular by the Client.

                                        

                                      

                                      
It is an abstraction. The GS
                                        receives the consent. How
                                        consent is gathered is a detail
                                        that is dependent on the use
                                        case.

                                    

                                  

                                

                              

                              
[Denis] I really wonder whether there
                                is really a "consent" to be recei=
ved by
                                the GS in both cases (i.e. ACLs or
                                Capabilities).

                              

                              
    
                                
  • For ACLs, the consent needs to be
                                  done by the Client.
    • 
                                
  • For Capabilities, the current
                                  description is not clear since the
                                  inputs and the outputs for this
                                  "consent" phase
    
                                  are not currently described in the
                                  draft.
    • 
                              

                              

                                

                                  

                                    

                                      
=C2=A0

                                      

                                        

                                          

                                            

                                              

                                                
=C2=A0

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
 Another
                                                          important
                                                          point to
                                                          consider and
                                                          to explain is
                                                          related to the
                                                          assurances
                                                          that the user
                                                          can obtain
                                                          about 

                                                          the respect of
                                                          his choices.
                                                          This point is
                                                          currently left
                                                          unanswered in
draft-hardt-xauth-protocol-13.

                                                          

                                                          

                                                        

                                                      

                                                    

                                                    
This point is
                                                      equally important:
                                                      such assurance can
                                                      only be obtained
                                                      if the access
                                                      token returned to
                                                      the client 

                                                      is not considered
                                                      to be opaque to
                                                      the client. This
                                                      is a necessary
                                                      condition but not
                                                      the single
                                                      condition: 

                                                      the Client must
                                                      also be in a
                                                      position to
                                                      capture/memorize
                                                      the "User consen=
t
                                                      and choice" of t=
he
                                                      user in order to
                                                      be able 

                                                      to verify it
                                                      afterwards using
                                                      the content of the
                                                      access token(s).

                                                  

                                                

                                                


                                                

                                                
We disagree on this
                                                  being a requirement
                                                  for all use cases. It
                                                  may be in some. 

                                                

                                              

                                            

                                          

                                          
OK. Then this means that
                                            there will be no sentence in
                                            the draft such as :

                                            "access tokens returned to
                                            the client are not
                                            considered to be opaque to
                                            the client".

                                        

                                      

                                      


                                      

                                      
For OAuth use cases, which
                                        GNAP supports, the access token
                                        is opaque to the Client. As you
                                        have noted, there are use cases
                                        where the access token is NOT
                                        opaque.

                                    

                                  

                                

                              

                              
[Denis] Wait a second. There is no
                                requirement to support all OAuth use
                                cases. 

                                I believe that there is a requirement to
                                support OAuth 2.0 ASs, while the clients
                                may be different 

                                and hence GNAP clients do not need to
                                inherit of the limitations of OAuth 2.0
                                clients.

                              

                                

                                  

                                    

                                      
=C2=A0

                                      

                                        

                                          

                                            

                                              

                                                
=C2=A0

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
If a RO
                                                          needs to be
                                                          involved and
                                                          since a RO is
                                                          directly
                                                          associated
                                                          with a RS, why
                                                          can't it be
                                                          directly
                                                          queried 

                                                          by the
                                                          appropriate RS
                                                          after step (2)
                                                          or later on ?
                                                          

                                                          

                                                          


                                                          

                                                          
Good
                                                          question.
                                                          Perhaps you
                                                          can expand on
                                                          a use case
                                                          where that
                                                          would be
                                                          useful?

                                                          

                                                          

                                                          

                                                          
Before I
                                                          expand, would
                                                          you be able to
                                                          explain first
                                                          under which
                                                          circumstances
                                                          a RO needs to
                                                          be queried by
                                                          a GS ?

                                                          How can the GS
                                                          identify which
                                                          RO to query ?

                                                          

                                                          

                                                          
If the
                                                          User is the
                                                          RO, then the
                                                          GS knows who
                                                          to query. 

                                                          

                                                        

                                                      

                                                    

                                                    
I still have
                                                      difficulties to
                                                      understand what
                                                      you mean here. 

                                                      How could a GS
                                                      know that "the
                                                      User is the RO" =
?=C2=A0
                                                      If "the User is
                                                      the RO", why doe=
s
                                                      the GS needs to
                                                      query the User ? 

                                                    

                                                  

                                                

                                                


                                                

                                                
To get consent?

                                              

                                            

                                          

                                          
To get a "RO consent"=
; to
                                            himself ???

                                        

                                      

                                      


                                      

                                      
The GS needs consent from the
                                        RO. If the RO is the User, then
                                        consent from the RO is
                                        equivalent to consent from the
                                        User.

                                    

                                  

                                

                              

                              
[Denis] See above.

                              

                              

                                

                                  

                                    

                                      
=C2=A0

                                      

                                      

                                        

                                          

                                            

                                              

                                                
=C2=A0

                                                

                                                  

                                                    

                                                      

                                                        

                                                          
If the RO
                                                          is a separate
                                                          entity, then
                                                          the GS knows
                                                          the RO from
                                                          the RS being
                                                          queried. 

                                                          

                                                        

                                                      

                                                    

                                                    
=C2=A0... and this
                                                      gives the ability
                                                      for the GS to
                                                      log/trace all the
                                                      RSs accessed by a
                                                      given User and at
                                                      which instant of
                                                      time the access
                                                      token has been
                                                      granted.

                                                    

                                                      

                                                        

                                                          
An
                                                          example=C2=A0is a
                                                          user would
                                                          like access to
                                                          an enterprise
                                                          asset where a
                                                          workflow is
                                                          started to
                                                          gain approval,
                                                          and an
                                                          administrator
                                                          or manager
                                                          provides
                                                          consent.

                                                        

                                                      

                                                    

                                                    
Thanks for this
                                                      example. I finally
                                                      understand what
                                                      you have in mind:
                                                      you are
                                                      considering using
                                                      an access control
                                                      model to build a w=
orkflow
                                                        model. 

                                                      While it may be
                                                      interesting to
                                                      define a workflow
                                                      model, this should
                                                      be considered as a
                                                      separate and
                                                        different work
                                                        item.

                                                  

                                                

                                                


                                                

                                                
The actual workflow
                                                  is out of scope. 

                                              

                                            

                                          

                                          
I am glad you agree with
                                            this. But this means that
                                            your example was not
                                            appropriate to illustrate
                                            your point.

                                          

                                        

                                      

                                      


                                      

                                      
It illustrates a use case
                                        where the RO and User are not
                                        the same party, and why the GS
                                        needs to query the RO, which was
                                        your question if I understood it
                                        correctly.

                                    

                                  

                                

                              

                              
[Denis] Since the inputs and the
                                outputs for this "RO consent" pha=
se are
                                not currently described in the draft,
                                the point is still unsolved.

                              

                              

                                

                                  

                                    

                                      

                                        

                                          
 As soon as there is a RO
                                            consent obtained at the GS,
                                            the major problem is that
                                            the GS is able to act as Big
                                            Brother.

                                            If a RO consent is performed
                                            at the RS, then the GS will
                                            not know who the RS is: it
                                            is then unable to act as Big
                                            Brother, 

                                            even if it would enjoy to
                                            play that role.

                                        

                                      

                                      
In an enterprise use case,
                                        the GS's knowledge of who is
                                        accessing which RS is a feature.
                                    

                                  

                                

                              

                              
Do you mean that it is "normal" =
in an
                                enterprise that a single point of
                                control is able to trace all their
                                actions ? 

                                From a security point of view, a single
                                point of failure will have dramatic
                                consequences.

                              

                                

                                  

                                    

                                      
In your use cases, it seems
                                        that the RO is the User. 

                                    

                                  

                                

                              

                              
I do hope that you have finally
                                understood that, in my use case, the RO
                                is **not** the User.

                              

                                

                                  

                                    

                                      
The GS knows the User is
                                        wanting to let a Client access
                                        something. If the access token
                                        is generic, and could be
                                        presented to any RS that
                                        provides a standardized
                                        function, 

                                        then the GS does not know which
                                        RS is being accessed by a Client
                                        for the User. This seems to meet
                                        your privacy objectives. If not,
                                        what is wrong?

                                    

                                  

                                

                              

                              
For security reasons, an access token
                                needs to be targeted (which does not
                                necessarily mean that an identifier of
                                the RS shall be included into the access
                                token).

                              

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                
if the admin grants
                                                  access, then the
                                                  access granted to the
                                                  client changes. 

                                                

                                                

                                                  

                                                    
 

                                                    
The model you
                                                      propose may be
                                                      suited for an
                                                      enterprise
                                                      environment but is
                                                      not scalable over
                                                      the Internet.

                                                  

                                                

                                                
It is one of the
                                                  use cases we are
                                                  working to address. 

                                                

                                                

                                                  

                                                    
 What is needed
                                                      is an access
                                                      control model
                                                      usable over the
                                                      Internet with
                                                      millions of RSs
                                                      and thousands of
                                                      ASs/GSs.=C2=A0 

                                                    

                                                  

                                                

                                                
I agree the model
                                                  should also scale to
                                                  internet scale. 

                                                

                                              

                                            

                                          

                                          
Fine. Another point on
                                            which we are in agreement. 

                                          

                                          
The model can scale to the
                                            Internet based on the
                                            following assumptions:

                                          

                                            
The flow starts with the
                                              steps (1) to (4) as
                                              illustrated by Francis,
                                              i.e. the flow starts with
                                              a contact with a RS.

                                          

                                          
+----+
                                                =C2=A0+------+ =C2=A0+---+ =
=C2=A0+---+
                                                =C2=A0+---+

                                                |User| =C2=A0|Client| =C2=
=A0|RS |
                                                =C2=A0|GS | =C2=A0|RO |

                                                +----+ =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 |(2) Service
                                                Intent =C2=A0 |

                                                =C2=A0 | =C2=A0 =C2=A0 =C2=
=A0 =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) AuthZ
                                                Challenge =C2=A0|

                                                =C2=A0 | =C2=A0 =C2=A0 =C2=
=A0 =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) AuthZ
                                                Request =C2=A0 =C2=A0|

                                                =C2=A0 | =C2=A0 =C2=A0 =C2=
=A0 =C2=A0
                                                |------------->| =C2=A0 =
=C2=A0
                                                =C2=A0|

                                          
The GS/AS does not need to
                                            have any prior relationship
                                            with ROs and/or RSs.

                                          
Furthermore, it is possible
                                            to prevent the GS to act as
                                            Big Brother when the
                                            identity of the RS is not
                                            disclosed to the GS.

                                          

                                        

                                      

                                      


                                      

                                      
What happens after (4) above?
                                        

                                      

                                    

                                  

                                

                              

                              
[Denis] The key point is that we first
                                need to agree on the first four
                                exchanges. Do we ?

                              

                              
The fifth exchange is different whether
                                ACLs or Capabilities are being used.

                              

                              

                                

                                  

                                    

                                      
=C2=A0

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
Which
                                                          information is
                                                          supposed to be
                                                          presented to
                                                          the RO ?

                                                          Which
                                                          information is
                                                          supposed to be
                                                          returned by
                                                          the RO ?

                                                          

                                                          

                                                          


                                                          

                                                          
Just like
                                                          how the user
                                                          authenticates
                                                          to an AS, how
                                                          the AS and RO
                                                          communicate is
                                                          out of scope.

                                                          

                                                          

                                                          

                                                          

                                                          
At the
                                                          moment, the
                                                          usefulness of
                                                          a dialogue
                                                          between a GS
                                                          and a RO has
                                                          not been
                                                          explained, nor
                                                          demonstrated.

                                                          The question
                                                          is about the
                                                          functionality
                                                          of that
                                                          dialogue in
                                                          terms of input
                                                          and output
                                                          information
                                                          (and not about
                                                          

                                                          the design of
                                                          a protocol or
                                                          of a user
                                                          interface).
                                                          Anyway, AFAIU
                                                          a dialogue
                                                          between a GS
                                                          and a RO is
                                                          optional.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
See
                                                          enterprise
                                                          example above.
                                                        

                                                      

                                                    

                                                    
It is not an
                                                      access control
                                                      example, but a
                                                      workflow example.

                                                    
=
Access=C2=A0
                                                      control has been
                                                      defined a long
                                                      time ago and the
                                                      last edition of
                                                      the model has been
                                                      confirmed in year
                                                      1996: ISO/IEC=C2=A010181-3: 1996.

                                                      "Information
                                                        technology=C2=A0=E2=
=80=94
                                                        Open Systems
                                                        Interconnection=C2=
=A0=E2=80=94
                                                        Security
                                                        frameworks for
                                                        open systems:
                                                        Access control
                                                        framework=C2=A0=E2=
=80=94
                                                        Part=C2=A03".<=
/span>

                                                    
=
Two major functions have ben defined: a=
n Access Contro=
l Enforcement Function
                                                          (AEF) and an Access
                                                        Control
                                                        Decision
                                                        Function(ADF).

                                                    

                                                      
Access
                                                          Control Enf=
orcement
                                                          Function
                                                          (AEF):

                                                          A specialized
                                                          function that
                                                          is part of the
                                                          access path
                                                          between an
                                                          initiator and
                                                          a target on
                                                          each access
                                                          request and
                                                          enforces the
                                                          decision made
                                                          by the ADF.

                                                      Access Control Decision
                                                        Function (ADF) :

                                                      A
                                                        specialized
                                                        function that
                                                        makes access
                                                        control
                                                        decisions by
                                                        applying access
                                                        control policy
                                                        rules to an
                                                        access request,
                                                        ADI (of
                                                        initiators,
                                                        targets, access
                                                        requests, 
                                                      or
                                                        that retained
                                                        from prior
                                                        decisions), and
                                                        the context in
                                                        which the access
                                                        request is made.

                                                    
The role of the
                                                      RO is to define
                                                      the "access
                                                        control policy
                                                        rules" at the =
RS
                                                        according to the context
                                                          in which the
                                                          access request
                                                          is made.

                                                  

                                                

                                                
I'm pretty familia=
r
                                                  with access control
                                                  systems. :)=C2=A0

                                                


                                                

                                                
I would say that
                                                  the access control is
                                                  happening at the RS.
                                                  The client presents a
                                                  token when accessing
                                                  an API. 

                                                  The RS uses the token,
                                                  and any policy
                                                  required, to make an
                                                  access decision.

                                              

                                            

                                          

                                          
Fine. It looks like we are
                                            in agreement. Unfortunately,
                                            this is not the case just
                                            below.

                                          

                                          

                                            

                                              

                                                
Here is flow:

                                                


                                                

                                                
1) The Client
                                                  requests access to an
                                                  RS from the GS. 

                                                

                                              

                                            

                                          

                                          
No. We are no more in
                                            agreement. This is different
                                            from the flow drawn by
                                            Francis.

                                        

                                      

                                      
My bad. Typo. I meant RO.

                                      
=C2=A0

                                      

                                        

                                          

                                            

                                              

                                                
2) The GS queries
                                                  the RS if access
                                                  should be granted. 

                                                

                                              

                                            

                                          

                                          
=C2=A0No. The GS should not be
                                            forced to have a flow with
                                            the RS.

                                        

                                      

                                      
Same mistake as above, I
                                        meant RO.=C2=A0

                                      

                                        

                                          
 

                                          

                                            

                                              

                                                
3) If access is
                                                  granted, the GS
                                                  creates an access
                                                  token representing the
                                                  granted access, and
                                                  returns it to the
                                                  Client. 

                                                

                                              

                                            

                                          

                                          
This model is by no way
                                            conformant to ISO/IEC=C2=A010181-3:
                                                1996 

                                              

                                        

                                      

                                      
I'm unclear on why, or why i=
t
                                        is even relevant. 

                                      

                                      

                                        

                                          

                                              

                                          

                                            

                                              

                                                
4) The Client
                                                  presents the access
                                                  token to the RS to
                                                  show it has been
                                                  granted access. 

                                                

                                              

                                            

                                          

                                          
No. The client presents a
                                            token when accessing an API.
                                            The RS uses the token, and
                                            any policy required, to make
                                            an access decision.

                                            The token never contains an
                                            information like "Please
                                            grant an access to the
                                            holder of this token".

                                        

                                      

                                      
Let me provide more clarity
                                        in the sentence:

                                      


                                      

                                      
The Client presents the
                                        access token to the RS, to show
                                        the RS that the Client has been
                                        granted access to a resource at
                                        the RS by the GS.

                                    

                                  

                                

                              

                              
[Denis] This time, please consider both
                                the ACLs approach and the Capabilities
                                approach.

                              

                                

                                  

                                    

                                      
=C2=A0

                                      

                                        

                                          

                                            

                                              

                                                
A couple advantages
                                                  of this model:

                                                
- that the RS does
                                                  not need to know much,
                                                  if anything about the
                                                  Client.=C2=A0

                                                
- the access token
                                                  MAY be self contained
                                                  so that the Client
                                                  does not need to query
                                                  the GS on each access.
                                                  

                                                

                                              

                                            

                                          

                                          
There are so many
                                            disadvantages that I will
                                            not list them.

                                        

                                      

                                      
Darn: I clearly was not
                                        firing on all cylinders when I
                                        typed this out. Let me correct:
                                      


                                      

                                      

                                        

                                          

                                            

                                              
- the access token
                                                MAY be self contained so
                                                that the RS does not
                                                need to query the GS on
                                                each access to the RS by
                                                the Client.

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                              
[Denis] A few comments in the case of a
                                capability approach:

                              

                                
- for each GS, the RS needs to
                                  locally manage which operation(s)
                                  is/are allowed to it.

                                  

                                  - the GS needs to establish a trusted
                                  communication channel or an
                                  authentication mechanism with each RO
                                  

                                  =C2=A0=C2=A0 (which is associated with an
                                  explicit RS identifier). 

                                

                                
- the GS could play the role of the
                                  RO and hence be in a position to issue
                                  any capability for any RS (without a
                                  "RO consent"). 

                                  

                                  =C2=A0=C2=A0 The target of an attack will
                                  clearly be the GS.

                                

                              

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                
I would not say
                                                  that GNAP is an access
                                                  control protocol, as
                                                  how the RS uses the
                                                  token to determine
                                                  access is out of
                                                  scope.

                                              

                                            

                                          

                                          
This is where we have a =
major
                                                discrepancy:
                                            how the RS uses the token to
                                            determine access is *within*
                                            the scope.

                                        

                                      

                                    

                                  

                                

                              

                              [Denis] Do you agree or disagree ?

                              

                                

                                  

                                    

                                      

                                        

                                          
The RS announces in advance
                                            to the client what it needs
                                            so that the client can
                                            perform a a given operation
                                            and if the client supplies
                                            the requested attributes 

                                            obtained from some GS/AS(s)
                                            trusted by the RS, then
                                            access to that RS is granted
                                            by the RS. If the RS cannot
                                            perform the requested
                                            operation on its own, 

                                            then the client should be
                                            informed about some
                                            requested attributes that
                                            need to be obtained from
                                            some GS/AS(s) trusted by the
                                            next RS(s) in a chain

                                            for subsequent operations.
                                            The User consent should also
                                            be obtained before
                                            performing the chaining
                                            operation.

                                          

                                          
Chaining operations between
                                            RSs over the Internet is
                                            within the scope (... and
                                            may be achieved).

                                        

                                      

                                    

                                  

                                

                              

                              
[Denis] Do you agree or disagree ?

                              
Denis

                              

                              

                                

                                  

                                    

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
For many
                                                          use cases, the
                                                          User is the
                                                          RO, and the
                                                          interaction is
                                                          through a user
                                                          interface, not
                                                          a machine
                                                          protocol. 

                                                          

                                                          

                                                          

                                                          

                                                          
Wait a
                                                          second. You
                                                          wrote "the
                                                          User is the
                                                          RO". The Use=
r
                                                          is attempting
                                                          to make an
                                                          access to a RS
                                                          by using a
                                                          Client. 

                                                          That
                                                          User is not
                                                          the RO of the
                                                          RS.=C2=A0=C2=A0 <=
br>
                                                          

                                                          

                                                          

                                                          
The user
                                                          being the RO
                                                          is the initial
                                                          use case for
                                                          OAuth. 

                                                        

                                                      

                                                    

                                                    
OAuth 2.0 is no
                                                      more mandating
                                                      such a case.

                                                    

                                                  

                                                

                                              

                                            

                                          

                                          

                                            

                                              

                                                
I don't know what
                                                  you mean by that.

                                              

                                            

                                          

                                          
Copy and paste from
                                            draft-ietf-oauth-security-topic=
s:

                                          

                                          

                                            
OAuth initially assumed a
                                              static relationship
                                              between client,
                                              authorization server and
                                              resource servers.=C2=A0 (...)=
=C2=A0
                                              

                                              With the increasing
                                              adoption of OAuth, this
                                              simple model dissolved
                                              and, in several scenarios,
                                              was replaced 

                                              by a dynamic establishment
                                              of the relationship
                                              between clients on one
                                              side and the authorization
                                              and 

                                              resource servers of a
                                              particular deployment on
                                              the other side.

                                              

                                              This way, the same client
                                              could be used to access
                                              services of different
                                              providers (in case of
                                              standard APIs, 

                                              such as e-mail or OpenID
                                              Connect) or serve as a
                                              frontend to a particular
                                              tenant in a multi-tenancy
                                              environment. 

                                            

                                          

                                        

                                      

                                      


                                      

                                      
This sentence does not
                                        mention the RO or the Client.
                                        I'm confused what we are talkin=
g
                                        about=C2=A0

                                      

                                        

                                          

                                            
 

                                          

                                          

                                            

                                              

                                                
=C2=A0

                                                

                                                  

                                                    

                                                      

                                                        

                                                          
A client
                                                          application
                                                          would like
                                                          access to the
                                                          user's photos
                                                          at a photo
                                                          sharing site.
                                                          The resource
                                                          is the user's
                                                          photos. The
                                                          user is the
                                                          owner of that
                                                          resource.

                                                        

                                                      

                                                    

                                                    
If the user has
                                                      already pre
                                                      established the
                                                      access control
                                                      policy rules so
                                                      that it can access
                                                      to his own photos
                                                      

                                                      then he does not
                                                      need to grant in
                                                      real time any
                                                      additional
                                                      authorization.

                                                  

                                                

                                                
I don't understand
                                                  what you are trying to
                                                  say. The photo sharing
                                                  example was a driving
                                                  use case for the
                                                  creation of OAuth.

                                              

                                            

                                          

                                          
We would need to revisit
                                            the original scenario and
                                            consider if it can be
                                            addressed in a different way
                                            than the original way.

                                        

                                      

                                      
The use case is the same. Is
                                        there a different solution you
                                        are proposing?

                                      
=C2=A0

                                    

                                  

                                

                              

                              


                              

                            

                            -- 

                            Txauth mailing list

                            Txauth@ietf.org

                            https://www.ietf.org/mailman=
/listinfo/txauth

                          

                        

                      

                      


                      

                    

                    -- 

                    Txauth mailing list

                    Tx=
auth@ietf.org

                    https://www.ietf.org/mailman/listinf=
o/txauth

                  

                

              

              
3D""=E1=90=A7

            

            


            

          

        

      

    

    


    

  


-- 

Txauth mailing list

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




--000000000000b5986605ab7422e0--


From nobody Mon Jul 27 15:59: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 C18EA3A0991 for ; Mon, 27 Jul 2020 15:59:47 -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 3AErsBa9GTv1 for ; Mon, 27 Jul 2020 15:59:43 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450: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 B7B563A0898 for ; Mon, 27 Jul 2020 15:59:42 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id m15so9250785lfp.7 for ; Mon, 27 Jul 2020 15:59: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=kPRebEUoE3a9BCTnXXOF05TqSb3sBP6eUoB3CSvZNiY=; b=rC681dHYFSBru1AmA6OTKoPdu5V4zRz7xr/XllbGH0hdOMC741UiIBPW2sNpMsRMER T83+bQ7JUB3tdQycIildzMShqUlKBqasvzQ93BUB5fJE9ClplDzpCxoQ0ru2n3Sue36V B+olYGYoTMkkTN2mN64Se/Ozux26YCOPlNJyTEnO8vCKoC3A2Xq/bC7/Nu4SerYgbbSO pTEF4rhSd5MLUSAzvurzQ+BJtTDq7XnBKsXC28zuR2ONtFx4V/oTEJJPUWgq3S3yjlvQ 9JioOXBejGOvgV7dq2oJHnr5aq3v1UmvLOktwNU84g25yKvzZLpO/luWW4px9CXx1UsR xopA==
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=kPRebEUoE3a9BCTnXXOF05TqSb3sBP6eUoB3CSvZNiY=; b=MHTq8bkNCDAh1LyKZEpSvQRsfz6ZVLUso+CBApri86GdgGi9sugdHyGFvh3UujZF3i pz5GS+yJRbIgPTemdBx66rqKjsDkcRnQzeYCZ1x9TV3T6k8IPp7kOMvJPunEKmF0Pser 9kdStsHkSOUA+niA+X6f1Tz1ZwomwI6ycZLKd0oSikO5kmHAEZW3wDEx1t1h9FNgmpUD TWbvBl+YoW24cGxVaptKsCDZXK0KfODQeyT5QB425QFiHF3iCSOguN1JTYm0IlSSxk2M PDbjhmjHKEo6Y7xprk7LNMs2jCmy9Vg8wrkvnxeP8XX5ojUbJBaTsevd9Z6Oinf78Ipe lElQ==
X-Gm-Message-State: AOAM530qg69xbO/6uNDNfyFwQB89ZlrUyBff1h/IOIz/CRWjWpkjiwMq 6c6bpSPO7WN1EgaxKn89jWXjoAxWQWWxVZQJHks=
X-Google-Smtp-Source: ABdhPJxTVFA666gO4egcEC7H969c4UgFTetxo5z9kIZNbcUNEnyYpKkbyVWZJx/Jl40D/0IDBh1S/c+KytQNIK/vZ84=
X-Received: by 2002:ac2:4a9d:: with SMTP id l29mr12671691lfp.23.1595890780297;  Mon, 27 Jul 2020 15:59:40 -0700 (PDT)
MIME-Version: 1.0
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>    
In-Reply-To: 
From: Dick Hardt 
Date: Mon, 27 Jul 2020 15:59:04 -0700
Message-ID: 
To: Justin Richer 
Cc: Francis Pouatcha , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="0000000000000f613b05ab7447ec"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 22:59:48 -0000

--0000000000000f613b05ab7447ec
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

No, that is not accurate. XAuth is a super set of XYZ (as currently
written) as XYZ does not allow the direct return of claims from the GS.

If the Client wants an access token to retrieve Claims (name and email), it
includes the following JSON in its Grant Request:

"authorizations":{
    "token_1": {
        "type": "oidc_userinfo",
        "claims": { "email": null, "name": null }
    }

note: "standard_name_space" is to have a standardized RAR type for
oidc_userinfo


If the Client wants to get bare claims for name and email directly from the
GS, it includes:

"claims": {
    "oidc_userinfo": { "email": null, "name": null }
}

If the Client wants to get an ID Token containing name and email, it
includes:

"claims": {
    "oidc_id_token": { "email": null, "name": null }
}


Access tokens are always requested and returned in the "authorizations"
object, including if the access token is to access claims at a userinfo
endpoint.

Claims are always requested and returned in the "claims" object.

/Dick


On Mon, Jul 27, 2020 at 1:11 PM Justin Richer  wrote:

> I may have figured out a bit about how these approaches are actually
> different and why we might be talking past each other.
>
> From what I can see, the Xauth style query is basically saying =E2=80=9Ch=
ere=E2=80=99s a
> block asking for all the identity stuff in the protocol, and telling you
> where to put the identity stuff in the response no matter where that is=
=E2=80=9D.
> So this is why =E2=80=9Cclaims=E2=80=9D are the high-order element where =
things like query
> style and delivery are details of that.
>
> XYZ takes a markedly different approach, basically saying =E2=80=9Chere=
=E2=80=99s a block
> that asks for stuff coming back from an RS and here=E2=80=99s a different=
 block
> that asks for stuff coming back from the AS directly=E2=80=9D. Some of th=
ose things
> coming back, in either place, could be claims about the user. (Or really
> claims about anything else, if you want to use the wider definition of th=
e
> term.)
>
>
> So fundamentally the composition is different. Xauth lists the identity
> stuff all together, whereas XYZ splits identity stuff based on how it=E2=
=80=99s
> coming back. Xauth seems to prefer describing all the identity data to be
> returned regardless of how it=E2=80=99s returned. I prefer the XYZ approa=
ch, where
> resources are always resources regardless of what they=E2=80=99re about, =
and direct
> data is always direct data regardless of what it=E2=80=99s about.
>
>
> Is that an accurate read?
>
>  =E2=80=94 Justin
>
>
>
> On Jul 27, 2020, at 9:45 AM, Dick Hardt  wrote:
>
> A slide in my presentation today may clarify how I am thinking about it.
>
> On Mon, Jul 27, 2020 at 4:23 AM Justin Richer  wrote:
>
>> Since you focused on the individual elements of the straw man examples
>> you requested instead of the overall problem, I think you=E2=80=99re mis=
sing the
>> core point. Let me bring it back to a concrete example:
>>
>> In Xauth currently, you can use the =E2=80=9Cclaims=E2=80=9D query synta=
x from OIDC to
>> request user claims inside the =E2=80=9Cclaims.oidc=E2=80=9D object on r=
equest. However,
>> Xauth currently uses =E2=80=9Cuserinfo=E2=80=9D to mark information comi=
ng back directly to
>> the client as JSON. Since =E2=80=9Cuserinfo=E2=80=9D is already defined =
by OIDC in this
>> context to indicate information that should come back from the UserInfo
>> Endpoint (and therefore as a resource, with rights tied to an access
>> token), the Xauth approach would need a name other than =E2=80=9Cuserinf=
o=E2=80=9D here to
>> indicate such claims coming back directly as JSON.
>>
>> What would you call that field?
>>
>> Because whatever that field would be called is exactly the kind of data
>> differentiation that I=E2=80=99m talking about here. And considering tha=
t Xauth
>> already does differentiate between claims coming back as resources, as
>> assertions, and direct JSON, I think it=E2=80=99s clear that it does mat=
ter.
>>
>>  =E2=80=94 Justin
>>
>>
>> On Jul 24, 2020, at 4:57 PM, Dick Hardt  wrote:
>>
>> It is not clear to me what it matters if a Claim comes from an RS, or
>> from the GS, so I don't see a need to differentiate them.
>>
>> I would include verifiable credentials and user-bound keys as Claims.
>>
>> All the payment processing information I have seen has been in RAR. When
>> would the Client get payment processing directly from the GS?
>>
>> What is your example for distributed networks storage locations? If what
>> is stored is a statement about the user, then I would consider that a Cl=
aim
>> as well.
>>
>> We disagree on how to map OIDC to GNAP.  The direct data is a claims
>> request, the data coming indirectly is an access token request.
>>
>>
>>
>> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer  wrote:
>>
>>> Since we=E2=80=99re already talking about returning claims as direct da=
ta as
>>> well as a part of the resource API being protected, so we already need =
a
>>> way to differentiate the two kinds of items. Just calling it =E2=80=9Cc=
laims=E2=80=9D
>>> doesn=E2=80=99t help, because as you=E2=80=99ve pointed out they could =
show up in both
>>> places. So yes, defining that difference is something we should worry a=
bout
>>> now, even if the core protocol only uses it for claims.
>>>
>>> The two forms of direct data that XYZ returns are subject identifiers (=
a
>>> subset of identity claims) and assertions =E2=80=94 the latter being a =
container
>>> not just for identity claims but also authentication information and ot=
her
>>> elements. Assertions are not claims themselves.
>>>
>>> Other use cases that have been brought up include verifiable credential=
s
>>> and proofs, user-bound keys, payment processing information, and
>>> distributed network storage locations. I=E2=80=99m sure there are a lot=
 more. To
>>> me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D but not subs=
ets of =E2=80=9Cclaims=E2=80=9D.
>>> GNAP shouldn=E2=80=99t be defining what all of these look like, but it =
should
>>> define a way to talk about them.
>>>
>>> I think different top-level request objects are better suited for
>>> different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=
=E2=80=9D request,
>>> which allows targeting of its claims information into different return
>>> buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D request at =
the very least. I
>>> don=E2=80=99t think GNAP should define how to do this specific combinat=
ion, that
>>> should be for OIDF to debate and apply. The same with a DID service bas=
ed
>>> query, or Presentation Exchange [1], or anything else that people want =
to
>>> come up with.
>>>
>>> In my view, GNAP should define query structures for two things: rights
>>> that get tied to an access token and data that comes back directly to t=
he
>>> client. For the latter, I think we can do some very limited and very us=
eful
>>> specific items, which is what I=E2=80=99ve put into XYZ.
>>>
>>>  =E2=80=94 Justin
>>>
>>> [1] https://identity.foundation/presentation-exchange/
>>>
>>> On Jul 24, 2020, at 3:58 PM, Dick Hardt  wrote:
>>>
>>> I agree we want GNAP to be a strong foundation.
>>>
>>> Do you have an example of other "direct data"? If so, do you expect it
>>> to be defined in the core protocol?
>>>
>>> I would expect an extension for other "direct data" to define top level
>>> objects, and an appropriate definition for that "direct data".
>>>
>>> My "do we need to worry about it now" comment was on creating a generic
>>> term for "direct data". Unless we are solving those now, we can let fur=
ther
>>> work define that "direct data" explicitly.
>>>
>>>
>>>
>>>
>>> =E1=90=A7
>>>
>>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer  wrote:
>>>
>>>> Yes, I do think we need to worry about it to the extent that we are no=
t
>>>> creating something that is over-fit to a limited set of use cases.
>>>>
>>>> GNAP should be a foundation that many amazing new things can be built
>>>> on top of.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt  wrote:
>>>>
>>>> Justin, thanks for clarifying.
>>>>
>>>> What are some examples of other "direct data" that the GS may return?
>>>> If it is not in core GNAP, do we need to worry about now? We can then =
give
>>>> the direct data from the GS that is not a claim, an appropriate name i=
n
>>>> that document.
>>>>
>>>>
>>>>
>>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer  wrote=
:
>>>>
>>>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m sa=
ying. I agree
>>>>> that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. B=
ut the AS could return
>>>>> other data directly to the client that isn=E2=80=99t about the user. =
Those aren=E2=80=99t
>>>>> =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=
=80=9Cclaims=E2=80=9D can come back
>>>>> from places other than directly, then we shouldn=E2=80=99t call every=
thing that
>>>>> comes back a =E2=80=9Cclaim=E2=80=9D.
>>>>>
>>>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean wha=
t it already means and
>>>>> come up with a new word to mean =E2=80=9Cthings that come back direct=
ly from the
>>>>> AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s =
more complete definitions, but
>>>>> to simplify:
>>>>>
>>>>> Claims:
>>>>> - information about the user
>>>>> - can come back directly from the AS
>>>>> - can come back in a resource from the RS
>>>>>
>>>>> Resource:
>>>>> - Returned from an RS
>>>>> - Protected by access token
>>>>> - Could contain claims about the user
>>>>>
>>>>> Direct data (or some better name):
>>>>> - Returned directly from AS
>>>>> - Could contain claims about the user
>>>>>
>>>>> I think the problem is that some people are using =E2=80=9Cclaims=E2=
=80=9D to mean #1
>>>>> and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=
=99s important to
>>>>> remember, when talking about OIDC, that an IdP in OIDC combines an AS=
 and
>>>>> an RS into one entity for identity information. There can be other RS=
=E2=80=99s as
>>>>> well, and there usually are in the wild, but the one defined by OIDC =
is the
>>>>> UserInfo Endpoint. The fact that it returns user data doesn=E2=80=99t=
 make it any
>>>>> less of an RS.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> * In the wider context of things like the information claims inside a
>>>>> JWT, the claims could be about literally anything, but that=E2=80=99s=
 not what
>>>>> we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s b=
eing used.
>>>>>
>>>>>
>>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt  wrote:
>>>>>
>>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from
>>>>> the OP in an ID Token, or the Client can obtain Claims using an acces=
s
>>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>>
>>>>> The Claims are about the User (not a RO).
>>>>>
>>>>> In XAuth, I'm proposing the Client may obtain bare claims from the GS
>>>>> directly in addition to the mechanisms in ODIC.
>>>>>
>>>>> So I don't think we are changing the definition of Claim from how it
>>>>> has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>>
>>>>> Justin: you allude to Claims being about a party other than the User.
>>>>> Would you provide an example?
>>>>>
>>>>> /Dick
>>>>>
>>>>> [1]
>>>>>
>>>>> UserInfo Endpoint
>>>>> Protected Resource that, when presented with an Access Token by the
>>>>> Client, returns authorized information about the End-User represented=
 by
>>>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST=
 use
>>>>> the https scheme and MAY contain port, path, and query parameter comp=
onents.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> =E1=90=A7
>>>>>
>>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer  wrote=
:
>>>>>
>>>>>> I want to focus on one aspect here:
>>>>>>
>>>>>>
>>>>>>> A Claim is a well understood term in the field. We should use it. I=
t
>>>>>>> is still a Claim if it comes directly from the GS or from an RS.
>>>>>>>
>>>>>> I do not understand why a Resource release by an RS shall be h to as
>>>>>> a claim, even if the content of the Resource is an assertion. It wil=
l lead
>>>>>> to confusion. If we limit claims to information GS releases into Tok=
en,
>>>>>> User Info, and other objects it returns, this will help separate
>>>>>> responsibilities between GS and RS. As soon as RS services and infor=
mation,
>>>>>> this is called a Resource, no matter the nature of the content of th=
at
>>>>>> information.
>>>>>>
>>>>>>
>>>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Ccla=
im=E2=80=9D in the way
>>>>>> that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could co=
me back through an RS =E2=80=94 but in
>>>>>> the context of GNAP, that makes it a resource. So we need a differen=
t word
>>>>>> for data coming back directly from the AS to the client. Sometimes i=
t=E2=80=99s
>>>>>> going to be about the user, and that=E2=80=99s what we=E2=80=99re go=
ing to focus on here,
>>>>>> but since you can also get information about the user from a resourc=
e we
>>>>>> can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this h=
as been at the heart of a lot
>>>>>> of confusion in recent threads, as well as confusion about the scope=
 of the
>>>>>> inclusion of identity in the GNAP protocol.
>>>>>>
>>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already do=
es, and let=E2=80=99s find a way
>>>>>> to differentiate between when an item, claim or otherwise,  comes as=
 part
>>>>>> of a resource and when it comes back directly. This is an important
>>>>>> differentiating feature for GNAP.
>>>>>>
>>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in love=
 with:
>>>>>>
>>>>>>  - direct data
>>>>>>  - properties
>>>>>>  - details
>>>>>>  - statements
>>>>>>
>>>>>> The important thing here is that it=E2=80=99s not necessarily :about=
: the RO,
>>>>>> and that it is :not: in a resource.
>>>>>>
>>>>>> Any other thoughts?
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

--0000000000000f613b05ab7447ec
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


No, tha=
t is not accurate. XAuth is a super set of XYZ (as currently written) as XY=
Z does not allow the direct return of claims from the GS.

If the Client wants an access token to retr=
ieve=C2=A0Claims (name and email), it includes the following JSON in its Gr=
ant Request:

"au=
thorizations":{=C2=A0
=C2=
=A0 =C2=A0 "token_1": {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type": "<standard_na=
me_space>oidc_userinfo",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "claims": { "email": null,=
 "name": null }
=C2=A0=
 =C2=A0 }

=

note: "standard_name_space" is to have =
a standardized RAR type for oidc_userinfo

=

If the Client wants to get bare claims for name and email direct=
ly from the GS, it includes:

"claims": {
=C2=A0 =
=C2=A0 "oidc_userinfo": { "email": null, "name&quo=
t;: null }
}

If the Cli=
ent wants to get an ID Token containing name and email, it includes:
"claims": {
=C2=A0 =C2=A0 "oidc_id_token": { "ema=
il": null, "name": null }
=

}

Access tok=
ens are always requested and returned=C2=A0in the "authorizations"=
; object, including if the access token is to access claims at a userinfo e=
ndpoint.

Claims are always requested and returned =
in the "claims" object.

/Dick
=


On Mon, Jul 27, 2020 at 1:11 PM Justin Richer <jricher@mit.edu> wrote:
On Jul 27, 20=
20, at 9:45 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

A slide in my presentation today may clarify how I am thinking about =
it.

On Mon, Jul 27, 2020 at 4:23 AM Justin Richer <jricher@mit.edu> wrote:
Since you focused on the=
 individual elements of the straw man examples you requested instead of the=
 overall problem, I think you=E2=80=99re missing the core point. Let me bri=
ng it back to a concrete example:

In Xauth currently, yo=
u can use the =E2=80=9Cclaims=E2=80=9D query syntax from OIDC to request us=
er claims inside the =E2=80=9Cclaims.oidc=E2=80=9D object on request. Howev=
er, Xauth currently uses =E2=80=9Cuserinfo=E2=80=9D to mark information com=
ing back directly to the client as JSON. Since =E2=80=9Cuserinfo=E2=80=9D i=
s already defined by OIDC in this context to indicate information that shou=
ld come back from the UserInfo Endpoint (and therefore as a resource, with =
rights tied to an access token), the Xauth approach would need a name other=
 than =E2=80=9Cuserinfo=E2=80=9D here to indicate such claims coming back d=
irectly as JSON.=C2=A0

What would you call that fi=
eld?

Because whatever that field would be called i=
s exactly the kind of data differentiation that I=E2=80=99m talking about h=
ere. And considering that Xauth already does differentiate between claims c=
oming back as resources, as assertions, and direct JSON, I think it=E2=80=
=99s clear that it does matter.

=C2=A0=E2=80=94 Ju=
stin


On Jul 24, 2020, a=
t 4:57 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It is not clear to me what it matters if a Claim comes from an RS, or=
 from the GS, so I don't see a need to differentiate them.
I would include verifiable credentials and user-bound keys as =
Claims.

All the payment processing information I h=
ave=C2=A0seen has been in RAR. When would=C2=A0the Client get payment proce=
ssing directly from the GS?

What is your example f=
or distributed networks storage locations? If what is stored is a statement=
 about the user, then I would consider that a Claim as well.

=

We disagree on how to map OIDC to GNAP.=C2=A0 The direct data is=
 a claims request, the data coming indirectly is an access token request.



On Fri, Jul 24, 2020 at 1:39 PM Justin Ri=
cher <jricher@mit.e=
du> wrote:
https://identity.foundation/presentation=
-exchange/

On Jul 24, 2020, =
at 3:58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree we want GNAP to be a strong foundation.=C2=A0

Do you have an example of other "direct data"? If so, do you ex=
pect it to be defined in the core protocol?

I woul=
d expect an extension for other "direct data" to define top level=
 objects, and an appropriate definition for that "direct data".

My "do we need to worry about it now" com=
ment was on creating a generic term for "direct data". Unless we =
are solving those now, we can let further work define that "direct dat=
a" explicitly.



=

=E1=90=A7

On Fri, Jul 24, 2020 at 12:4=
2 PM Justin Richer <jricher@mit.edu> wrote:
Yes, I do think we need to worry about it to the exten=
t that we are not creating something that is over-fit to a limited set of u=
se cases.=C2=A0

GNAP should be a foundation that many am=
azing new things can be built on top of.

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

On Jul 24, 2020, a=
t 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, thanks for clarifying.

What are some examples o=
f other "direct data" that the GS may return? If it is not in cor=
e GNAP, do we need to worry about now? We can then give the direct data fro=
m the GS that is not a claim, an appropriate name in that document.



On Fri, Jul 24, 2020 at 11:46 AM Justin Riche=
r <jricher@mit.edu<=
/a>> wrote:
<=
div>Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m sayi=
ng. I agree that =E2=80=9Cclaims=E2=80=9D are about the user, in this conte=
xt*. But the AS could return other data directly to the client that isn=E2=
=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=80=9D by th=
e classical definition. Also since =E2=80=9Cclaims=E2=80=9D can come back f=
rom places other than directly, then we shouldn=E2=80=99t call everything t=
hat comes back a =E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m ar=
guing that we keep =E2=80=9Cclaims=E2=80=9D to mean what it already means a=
nd come up with a new word to mean =E2=80=9Cthings that come back directly =
from the AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=
=99s more complete definitions, but to simplify:

C=
laims:
	- information=
 about the user
	- ca=
n come back directly from the AS
	- can come back in a resource from the RS

=

Resource:
	- Ret=
urned from an RS
	- P=
rotected by access token
	- Could contain claims about the user

Direct =
data (or some better name):
=
	- Returned directly from AS
	- Could contain claims about the user

<=
div>I think the problem is that some people are using =E2=80=9Cclaims=E2=80=
=9D to mean #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: I=
t=E2=80=99s important to remember, when talking about OIDC, that an IdP in =
OIDC combines an AS and an RS into one entity for identity information. The=
re can be other RS=E2=80=99s as well, and there usually are in the wild, bu=
t the one defined by OIDC is the UserInfo Endpoint. The fact that it return=
s user data doesn=E2=80=99t make it any less of an RS.

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

* In the wider context of t=
hings like the information claims inside a JWT, the claims could be about l=
iterally anything, but that=E2=80=99s not what we=E2=80=99re discussing her=
e and it=E2=80=99s not how it=E2=80=99s being used.


=


In OpenID Connect (OIDC),=
 the Client can obtain Claims directly from the OP in an ID Token, or the C=
lient can obtain Claims using an access token to call the UserInfo endpoint=
, a Protected Resource[1].

The Claims are about the User=
 (not a RO).

In XAuth, I'm proposing the Clien=
t may obtain bare claims from the GS directly in addition to the mechanisms=
 in ODIC.

So I don't think we are changing the=
 definition of Claim from how it has been used in OIDC, and I fail to see a=
ny reason to NOT use Claim.

Justin: you allude to =
Claims being about a party other than the User. Would you provide an exampl=
e?

/Dick

[1]
UserInf=
o Endpoint
Protected Resource that, when presented with an Access=
 Token by the Client, returns authorized information about the End-User rep=
resented by the corresponding Authorization Grant. The UserInfo Endpoint UR=
L MUST use the https scheme and MAY contain port, path, and query parameter=
 components.



3D"==E1=90=A7

On Fri, Jul 24, 2020 at 5:58 AM Jus=
tin Richer <jricher=
@mit.edu> wrote:
I want to focus on one aspect here:


A=
 Claim is a well understood term in the field. We should use it. It is stil=
l a Claim if it comes directly from the GS or from an RS.=C2=A0
=

I do not understand why a Resource release by an RS shall=
 be h to as a claim, even if the content of the Resource is an assertion. I=
t will lead to confusion. If we limit claims to information GS releases int=
o Token, User Info, and other objects it returns, this will help separate r=
esponsibilities between GS and RS. As soon as RS services and information, =
this is called a Resource, no matter the nature of the content of that info=
rmation.

This is exactly=
 why I don=E2=80=99t think we should use =E2=80=9Cclaim=E2=80=9D in the way=
 that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come bac=
k through an RS =E2=80=94 but in the context of GNAP, that makes it a resou=
rce. So we need a different word for data coming back directly from the AS =
to the client. Sometimes it=E2=80=99s going to be about the user, and that=
=E2=80=99s what we=E2=80=99re going to focus on here, but since you can als=
o get information about the user from a resource we can=E2=80=99t just call=
 it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the heart of a lot =
of confusion in recent threads, as well as confusion about the scope of the=
 inclusion of identity in the GNAP protocol.

So le=
t=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does, and let=
=E2=80=99s find a way to differentiate between when an item, claim or other=
wise,=C2=A0=C2=A0comes as part of a resource and when it comes back directl=
y. This is an important differentiating feature for GNAP.

Some straw man ideas, none of which I=E2=80=99m particularly in lov=
e with:

=C2=A0- direct data
=C2=A0- prop=
erties
=C2=A0- details
=C2=A0- statements
The important thing here is that it=E2=80=99s not necessarily :=
about: the RO, and that it is :not: in a resource.

Any =
other thoughts?

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
















--0000000000000f613b05ab7447ec--


From nobody Mon Jul 27 16:10: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 A997A3A09B1 for ; Mon, 27 Jul 2020 16:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 lpQVHmMjoM2s for ; Mon, 27 Jul 2020 16:09:55 -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 4982F3A09A8 for ; Mon, 27 Jul 2020 16:09:55 -0700 (PDT)
Received: from [192.168.1.3] (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 06RN9nb9018699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 19:09:50 -0400
From: Justin Richer 
Message-Id: <251CEF78-781F-4316-85DD-0930D2368074@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1CC77A43-3B44-4D16-8ABF-450FE8B72179"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 27 Jul 2020 19:09:49 -0400
In-Reply-To: 
Cc: Francis Pouatcha , txauth@ietf.org, Tom Jones , Denis 
To: Dick Hardt 
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>     
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 23:10:01 -0000

--Apple-Mail=_1CC77A43-3B44-4D16-8ABF-450FE8B72179
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Not really the point I was making here, and you can return claims =
directly from the AS in XYZ, but now we=E2=80=99re just talking in =
circles so I don=E2=80=99t think this is a productive thread anymore.

 =E2=80=94 Justin

> On Jul 27, 2020, at 6:59 PM, Dick Hardt  wrote:
>=20
> No, that is not accurate. XAuth is a super set of XYZ (as currently =
written) as XYZ does not allow the direct return of claims from the GS.
>=20
> If the Client wants an access token to retrieve Claims (name and =
email), it includes the following JSON in its Grant Request:
>=20
> "authorizations":{=20
>     "token_1": {=20
>         "type": "oidc_userinfo",
>         "claims": { "email": null, "name": null }
>     }
>=20
> note: "standard_name_space" is to have a standardized RAR type for =
oidc_userinfo
>=20
> If the Client wants to get bare claims for name and email directly =
from the GS, it includes:
>=20
> "claims": {
>     "oidc_userinfo": { "email": null, "name": null }
> }
>=20
> If the Client wants to get an ID Token containing name and email, it =
includes:
>=20
> "claims": {
>     "oidc_id_token": { "email": null, "name": null }
> }
>=20
> Access tokens are always requested and returned in the =
"authorizations" object, including if the access token is to access =
claims at a userinfo endpoint.
>=20
> Claims are always requested and returned in the "claims" object.
>=20
> /Dick
>=20
>=20
> On Mon, Jul 27, 2020 at 1:11 PM Justin Richer > wrote:
> I may have figured out a bit about how these approaches are actually =
different and why we might be talking past each other.
>=20
> =46rom what I can see, the Xauth style query is basically saying =
=E2=80=9Chere=E2=80=99s a block asking for all the identity stuff in the =
protocol, and telling you where to put the identity stuff in the =
response no matter where that is=E2=80=9D. So this is why =E2=80=9Cclaims=E2=
=80=9D are the high-order element where things like query style and =
delivery are details of that.
>=20
> XYZ takes a markedly different approach, basically saying =E2=80=9Chere=E2=
=80=99s a block that asks for stuff coming back from an RS and here=E2=80=99=
s a different block that asks for stuff coming back from the AS =
directly=E2=80=9D. Some of those things coming back, in either place, =
could be claims about the user. (Or really claims about anything else, =
if you want to use the wider definition of the term.)
>=20
>=20
> So fundamentally the composition is different. Xauth lists the =
identity stuff all together, whereas XYZ splits identity stuff based on =
how it=E2=80=99s coming back. Xauth seems to prefer describing all the =
identity data to be returned regardless of how it=E2=80=99s returned. I =
prefer the XYZ approach, where resources are always resources regardless =
of what they=E2=80=99re about, and direct data is always direct data =
regardless of what it=E2=80=99s about.
>=20
>=20
> Is that an accurate read?
>=20
>  =E2=80=94 Justin
>=20
>=20
>=20
>> On Jul 27, 2020, at 9:45 AM, Dick Hardt > wrote:
>>=20
>> A slide in my presentation today may clarify how I am thinking about =
it.
>>=20
>> On Mon, Jul 27, 2020 at 4:23 AM Justin Richer > wrote:
>> Since you focused on the individual elements of the straw man =
examples you requested instead of the overall problem, I think you=E2=80=99=
re missing the core point. Let me bring it back to a concrete example:
>>=20
>> In Xauth currently, you can use the =E2=80=9Cclaims=E2=80=9D query =
syntax from OIDC to request user claims inside the =E2=80=9Cclaims.oidc=E2=
=80=9D object on request. However, Xauth currently uses =E2=80=9Cuserinfo=E2=
=80=9D to mark information coming back directly to the client as JSON. =
Since =E2=80=9Cuserinfo=E2=80=9D is already defined by OIDC in this =
context to indicate information that should come back from the UserInfo =
Endpoint (and therefore as a resource, with rights tied to an access =
token), the Xauth approach would need a name other than =E2=80=9Cuserinfo=E2=
=80=9D here to indicate such claims coming back directly as JSON.=20
>>=20
>> What would you call that field?
>>=20
>> Because whatever that field would be called is exactly the kind of =
data differentiation that I=E2=80=99m talking about here. And =
considering that Xauth already does differentiate between claims coming =
back as resources, as assertions, and direct JSON, I think it=E2=80=99s =
clear that it does matter.
>>=20
>>  =E2=80=94 Justin
>>=20
>>=20
>>> On Jul 24, 2020, at 4:57 PM, Dick Hardt > wrote:
>>>=20
>>> It is not clear to me what it matters if a Claim comes from an RS, =
or from the GS, so I don't see a need to differentiate them.
>>>=20
>>> I would include verifiable credentials and user-bound keys as =
Claims.
>>>=20
>>> All the payment processing information I have seen has been in RAR. =
When would the Client get payment processing directly from the GS?
>>>=20
>>> What is your example for distributed networks storage locations? If =
what is stored is a statement about the user, then I would consider that =
a Claim as well.
>>>=20
>>> We disagree on how to map OIDC to GNAP.  The direct data is a claims =
request, the data coming indirectly is an access token request.
>>>=20
>>>=20
>>>=20
>>> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer > wrote:
>>> Since we=E2=80=99re already talking about returning claims as direct =
data as well as a part of the resource API being protected, so we =
already need a way to differentiate the two kinds of items. Just calling =
it =E2=80=9Cclaims=E2=80=9D doesn=E2=80=99t help, because as you=E2=80=99v=
e pointed out they could show up in both places. So yes, defining that =
difference is something we should worry about now, even if the core =
protocol only uses it for claims.
>>>=20
>>> The two forms of direct data that XYZ returns are subject =
identifiers (a subset of identity claims) and assertions =E2=80=94 the =
latter being a container not just for identity claims but also =
authentication information and other elements. Assertions are not claims =
themselves.=20
>>>=20
>>> Other use cases that have been brought up include verifiable =
credentials and proofs, user-bound keys, payment processing information, =
and distributed network storage locations. I=E2=80=99m sure there are a =
lot more. To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D =
but not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be =
defining what all of these look like, but it should define a way to talk =
about them.
>>>=20
>>> I think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=
=9D request, which allows targeting of its claims information into =
different return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D=
 request at the very least. I don=E2=80=99t think GNAP should define how =
to do this specific combination, that should be for OIDF to debate and =
apply. The same with a DID service based query, or Presentation Exchange =
[1], or anything else that people want to come up with.
>>>=20
>>> In my view, GNAP should define query structures for two things: =
rights that get tied to an access token and data that comes back =
directly to the client. For the latter, I think we can do some very =
limited and very useful specific items, which is what I=E2=80=99ve put =
into XYZ.
>>>=20
>>>  =E2=80=94 Justin
>>>=20
>>> [1] https://identity.foundation/presentation-exchange/ =

>>>=20
>>>> On Jul 24, 2020, at 3:58 PM, Dick Hardt > wrote:
>>>>=20
>>>> I agree we want GNAP to be a strong foundation.=20
>>>>=20
>>>> Do you have an example of other "direct data"? If so, do you expect =
it to be defined in the core protocol?
>>>>=20
>>>> I would expect an extension for other "direct data" to define top =
level objects, and an appropriate definition for that "direct data".
>>>>=20
>>>> My "do we need to worry about it now" comment was on creating a =
generic term for "direct data". Unless we are solving those now, we can =
let further work define that "direct data" explicitly.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> =E1=90=A7
>>>>=20
>>>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer > wrote:
>>>> Yes, I do think we need to worry about it to the extent that we are =
not creating something that is over-fit to a limited set of use cases.=20=

>>>>=20
>>>> GNAP should be a foundation that many amazing new things can be =
built on top of.
>>>>=20
>>>>  =E2=80=94 Justin
>>>>=20
>>>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt > wrote:
>>>>>=20
>>>>> Justin, thanks for clarifying.
>>>>>=20
>>>>> What are some examples of other "direct data" that the GS may =
return? If it is not in core GNAP, do we need to worry about now? We can =
then give the direct data from the GS that is not a claim, an =
appropriate name in that document.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer > wrote:
>>>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m =
saying. I agree that =E2=80=9Cclaims=E2=80=9D are about the user, in =
this context*. But the AS could return other data directly to the client =
that isn=E2=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=
=80=9D by the classical definition. Also since =E2=80=9Cclaims=E2=80=9D =
can come back from places other than directly, then we shouldn=E2=80=99t =
call everything that comes back a =E2=80=9Cclaim=E2=80=9D.
>>>>>=20
>>>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean =
what it already means and come up with a new word to mean =E2=80=9Cthings =
that come back directly from the AS=E2=80=9D. These aren=E2=80=99t meant =
to replace Francis=E2=80=99s more complete definitions, but to simplify:
>>>>>=20
>>>>> Claims:
>>>>> 	- information about the user
>>>>> 	- can come back directly from the AS
>>>>> 	- can come back in a resource from the RS
>>>>>=20
>>>>> Resource:
>>>>> 	- Returned from an RS
>>>>> 	- Protected by access token
>>>>> 	- Could contain claims about the user
>>>>>=20
>>>>> Direct data (or some better name):
>>>>> 	- Returned directly from AS
>>>>> 	- Could contain claims about the user
>>>>>=20
>>>>> I think the problem is that some people are using =E2=80=9Cclaims=E2=
=80=9D to mean #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. =
But: It=E2=80=99s important to remember, when talking about OIDC, that =
an IdP in OIDC combines an AS and an RS into one entity for identity =
information. There can be other RS=E2=80=99s as well, and there usually =
are in the wild, but the one defined by OIDC is the UserInfo Endpoint. =
The fact that it returns user data doesn=E2=80=99t make it any less of =
an RS.
>>>>>=20
>>>>>  =E2=80=94 Justin
>>>>>=20
>>>>> * In the wider context of things like the information claims =
inside a JWT, the claims could be about literally anything, but that=E2=80=
=99s not what we=E2=80=99re discussing here and it=E2=80=99s not how =
it=E2=80=99s being used.
>>>>>=20
>>>>>=20
>>>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt > wrote:
>>>>>>=20
>>>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly =
from the OP in an ID Token, or the Client can obtain Claims using an =
access token to call the UserInfo endpoint, a Protected Resource[1].
>>>>>>=20
>>>>>> The Claims are about the User (not a RO).
>>>>>>=20
>>>>>> In XAuth, I'm proposing the Client may obtain bare claims from =
the GS directly in addition to the mechanisms in ODIC.
>>>>>>=20
>>>>>> So I don't think we are changing the definition of Claim from how =
it has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>>>=20
>>>>>> Justin: you allude to Claims being about a party other than the =
User. Would you provide an example?
>>>>>>=20
>>>>>> /Dick
>>>>>>=20
>>>>>> [1]
>>>>>> UserInfo Endpoint
>>>>>> Protected Resource that, when presented with an Access Token by =
the Client, returns authorized information about the End-User =
represented by the corresponding Authorization Grant. The UserInfo =
Endpoint URL MUST use the https scheme and MAY contain port, path, and =
query parameter components.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> =E1=90=A7
>>>>>>=20
>>>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer > wrote:
>>>>>> I want to focus on one aspect here:
>>>>>>=20
>>>>>>>=20
>>>>>>> A Claim is a well understood term in the field. We should use =
it. It is still a Claim if it comes directly from the GS or from an RS.=20=

>>>>>>> I do not understand why a Resource release by an RS shall be h =
to as a claim, even if the content of the Resource is an assertion. It =
will lead to confusion. If we limit claims to information GS releases =
into Token, User Info, and other objects it returns, this will help =
separate responsibilities between GS and RS. As soon as RS services and =
information, this is called a Resource, no matter the nature of the =
content of that information.
>>>>>>=20
>>>>>> This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =
=E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in =
the context of GNAP, that makes it a resource. So we need a different =
word for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s going to be about the user, and that=E2=80=99s what we=E2=80=99=
re going to focus on here, but since you can also get information about =
the user from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=
=80=9D. I think this has been at the heart of a lot of confusion in =
recent threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.
>>>>>>=20
>>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already =
does, and let=E2=80=99s find a way to differentiate between when an =
item, claim or otherwise,  comes as part of a resource and when it comes =
back directly. This is an important differentiating feature for GNAP.
>>>>>>=20
>>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in =
love with:
>>>>>>=20
>>>>>>  - direct data
>>>>>>  - properties
>>>>>>  - details
>>>>>>  - statements
>>>>>>=20
>>>>>> The important thing here is that it=E2=80=99s not necessarily =
:about: the RO, and that it is :not: in a resource.
>>>>>>=20
>>>>>> Any other thoughts?
>>>>>>=20
>>>>>>  =E2=80=94 Justin
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20


--Apple-Mail=_1CC77A43-3B44-4D16-8ABF-450FE8B72179
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Not =
really the point I was making here, and you can return claims directly =
from the AS in XYZ, but now we=E2=80=99re just talking in circles so I =
don=E2=80=99t think this is a productive thread anymore.

 =E2=80=94 =
Justin

On Jul 27, 2020, at 6:59 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

No, that is not =
accurate. XAuth is a super set of XYZ (as currently written) as XYZ does =
not allow the direct return of claims from the GS.

If the =
Client wants an access token to retrieve Claims (name and email), =
it includes the following JSON in its Grant Request:

"authorizations":{ 
    =
"token_1": { 
        =
"type": =
"<standard_name_space>oidc_userinfo",
    =
    "claims": { "email": null, "name": null =
}
    }

note: "standard_name_space" is to have a =
standardized RAR type for =
oidc_userinfo

If the =
Client wants to get bare claims for name and email directly from the GS, =
it includes:

"claims": =
{
    "oidc_userinfo": { "email": =
null, "name": null }
}

If the Client wants to =
get an ID Token containing name and email, it includes:
"claims": =
{
    =
"oidc_id_token": { "email": null, "name": null =
}
}

Access tokens are always requested and returned in the =
"authorizations" object, including if the access token is to access =
claims at a userinfo endpoint.

Claims are always requested and =
returned in the "claims" object.

/Dick


On Mon, Jul 27, 2020 at 1:11 PM Justin =
Richer <jricher@mit.edu> wrote:
I may have figured out a bit about how these =
approaches are actually different and why we might be talking past each =
other.

=46rom what I =
can see, the Xauth style query is basically saying =E2=80=9Chere=E2=80=99s=
 a block asking for all the identity stuff in the protocol, and telling =
you where to put the identity stuff in the response no matter where that =
is=E2=80=9D. So this is why =E2=80=9Cclaims=E2=80=9D are the high-order =
element where things like query style and delivery are details of =
that.

XYZ =
takes a markedly different approach, basically saying =E2=80=9Chere=E2=80=99=
s a block that asks for stuff coming back from an RS and here=E2=80=99s =
a different block that asks for stuff coming back from the AS =
directly=E2=80=9D. Some of those things coming back, in either place, =
could be claims about the user. (Or really claims about anything else, =
if you want to use the wider definition of the term.)


So fundamentally the composition is different. Xauth lists =
the identity stuff all together, whereas XYZ splits identity stuff based =
on how it=E2=80=99s coming back. Xauth seems to prefer describing all =
the identity data to be returned regardless of how it=E2=80=99s =
returned. I prefer the XYZ approach, where resources are always =
resources regardless of what they=E2=80=99re about, and direct data is =
always direct data regardless of what it=E2=80=99s about.


Is that an accurate read?

 =E2=80=94 Justin



On Jul 27, 2020, at 9:45 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

A slide in my presentation today =
may clarify how I am thinking about it.

On Mon, Jul =
27, 2020 at 4:23 AM Justin Richer <jricher@mit.edu> wrote:
Since you focused on =
the individual elements of the straw man examples you requested instead =
of the overall problem, I think you=E2=80=99re missing the core point. =
Let me bring it back to a concrete example:

In Xauth currently, you can use the =
=E2=80=9Cclaims=E2=80=9D query syntax from OIDC to request user claims =
inside the =E2=80=9Cclaims.oidc=E2=80=9D object on request. However, =
Xauth currently uses =E2=80=9Cuserinfo=E2=80=9D to mark information =
coming back directly to the client as JSON. Since =E2=80=9Cuserinfo=E2=80=9D=
 is already defined by OIDC in this context to indicate information that =
should come back from the UserInfo Endpoint (and therefore as a =
resource, with rights tied to an access token), the Xauth approach would =
need a name other than =E2=80=9Cuserinfo=E2=80=9D here to indicate such =
claims coming back directly as JSON. 

What would you call that =
field?

Because =
whatever that field would be called is exactly the kind of data =
differentiation that I=E2=80=99m talking about here. And considering =
that Xauth already does differentiate between claims coming back as =
resources, as assertions, and direct JSON, I think it=E2=80=99s clear =
that it does matter.

 =E2=80=94 Justin


On Jul 24, 2020, at 4:57 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

It is not clear =
to me what it matters if a Claim comes from an RS, or from the GS, so I =
don't see a need to differentiate them.

I would include verifiable credentials =
and user-bound keys as Claims.

All the payment processing information =
I have seen has been in RAR. When would the Client get payment =
processing directly from the GS?

What is your example for distributed =
networks storage locations? If what is stored is a statement about the =
user, then I would consider that a Claim as well.
We disagree on how to map OIDC to =
GNAP.  The direct data is a claims request, the data coming =
indirectly is an access token request.



On Fri, Jul 24, 2020 at 1:39 PM Justin Richer =
<jricher@mit.edu> wrote:
Since we=E2=80=99=
re already talking about returning claims as direct data as well as a =
part of the resource API being protected, so we already need a way to =
differentiate the two kinds of items. Just calling it =E2=80=9Cclaims=E2=80=
=9D doesn=E2=80=99t help, because as you=E2=80=99ve pointed out they =
could show up in both places. So yes, defining that difference is =
something we should worry about now, even if the core protocol only uses =
it for claims.

The =
two forms of direct data that XYZ returns are subject identifiers (a =
subset of identity claims) and assertions =E2=80=94 the latter being a =
container not just for identity claims but also authentication =
information and other elements. Assertions are not claims =
themselves. 

Other use cases that have been brought up include verifiable =
credentials and proofs, user-bound keys, payment processing information, =
and distributed network storage locations. I=E2=80=99m sure there are a =
lot more. To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D =
but not subsets of =E2=80=9Cclaims=E2=80=9D. GNAP shouldn=E2=80=99t be =
defining what all of these look like, but it should define a way to talk =
about them.

I =
think different top-level request objects are better suited for =
different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=E2=80=
=9D request, which allows targeting of its claims information into =
different return buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D=
 request at the very least. I don=E2=80=99t think GNAP should define how =
to do this specific combination, that should be for OIDF to debate and =
apply. The same with a DID service based query, or Presentation Exchange =
[1], or anything else that people want to come up with.

In my view, GNAP should =
define query structures for two things: rights that get tied to an =
access token and data that comes back directly to the client. For the =
latter, I think we can do some very limited and very useful specific =
items, which is what I=E2=80=99ve put into XYZ.

 =E2=80=
=94 Justin

[1] https://identity.foundation/presentation-exchange/

On Jul 24, 2020, at 3:58 PM, Dick Hardt =
<dick.hardt@gmail.com> wrote:

I agree we want GNAP to be a =
strong foundation. 

Do you have an example of other "direct data"? If so, do you =
expect it to be defined in the core protocol?

I would expect an extension for other =
"direct data" to define top level objects, and an appropriate definition =
for that "direct data".

My "do we need to worry about it now" comment was on creating =
a generic term for "direct data". Unless we are solving those now, we =
can let further work define that "direct data" explicitly.




3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
Yes, I do think we =
need to worry about it to the extent that we are not creating something =
that is over-fit to a limited set of use cases. 

GNAP should be a foundation that many =
amazing new things can be built on top of.

 =E2=80=94 =
Justin

On Jul 24, 2020, at 3:06 PM, =
Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, thanks for =
clarifying.

What are =
some examples of other "direct data" that the GS may return? If it is =
not in core GNAP, do we need to worry about now? We can then give the =
direct data from the GS that is not a claim, an appropriate name in that =
document.



On Fri, Jul 24, 2020 at 11:46 AM Justin =
Richer <jricher@mit.edu> wrote:
Dick: No, I =
think you=E2=80=99re misunderstanding what I=E2=80=99m saying. I agree =
that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. But =
the AS could return other data directly to the client that isn=E2=80=99t =
about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=80=9D by the =
classical definition. Also since =E2=80=9Cclaims=E2=80=9D can come back =
from places other than directly, then we shouldn=E2=80=99t call =
everything that comes back a =E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m arguing that we keep =
=E2=80=9Cclaims=E2=80=9D to mean what it already means and come up with =
a new word to mean =E2=80=9Cthings that come back directly from the =
AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s =
more complete definitions, but to simplify:

Claims:
	- information =
about the user
	- can come back directly from the AS
	- =
can come back in a resource from the RS

Resource:
	- Returned from =
an RS
	- Protected by access token
	- =
Could contain claims about the user

Direct data (or some better =
name):
	- Returned directly from AS
	- =
Could contain claims about the user

I think the problem is that some people =
are using =E2=80=9Cclaims=E2=80=9D to mean #1 and some to mean #3. =
It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=99s important to =
remember, when talking about OIDC, that an IdP in OIDC combines an AS =
and an RS into one entity for identity information. There can be other =
RS=E2=80=99s as well, and there usually are in the wild, but the one =
defined by OIDC is the UserInfo Endpoint. The fact that it returns user =
data doesn=E2=80=99t make it any less of an RS.

 =E2=80=94 Justin

* In the wider context =
of things like the information claims inside a JWT, the claims could be =
about literally anything, but that=E2=80=99s not what we=E2=80=99re =
discussing here and it=E2=80=99s not how it=E2=80=99s being =
used.


On Jul =
24, 2020, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

In OpenID Connect (OIDC), the =
Client can obtain Claims directly from the OP in an ID Token, or the =
Client can obtain Claims using an access token to call the UserInfo =
endpoint, a Protected Resource[1].

The Claims are about the User (not a =
RO).

In XAuth, =
I'm proposing the Client may obtain bare claims from the GS directly in =
addition to the mechanisms in ODIC.

So I don't think we are changing the =
definition of Claim from how it has been used in OIDC, and I fail to see =
any reason to NOT use Claim.

Justin: you allude to Claims being =
about a party other than the User. Would you provide an =
example?

/Dick

[1]
UserInfo =
Endpoint
Protected Resource that, when presented =
with an Access Token by the Client, returns authorized information about =
the End-User represented by the corresponding Authorization Grant. The =
UserInfo Endpoint URL MUST use the https scheme and MAY contain port, =
path, and query parameter components.



3D""=E1=90=A7

On Fri, Jul =
24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu> wrote:
I want to focus on =
one aspect here:


A Claim is a well =
understood term in the field. We should use it. It is still a Claim if =
it comes directly from the GS or from an =
RS. 
I do not understand =
why a Resource release by an RS shall be h to as a claim, even if the =
content of the Resource is an assertion. It will lead to confusion. If =
we limit claims to information GS releases into Token, User Info, and =
other objects it returns, this will help separate responsibilities =
between GS and RS. As soon as RS services and information, this is =
called a Resource, no matter the nature of the content of that =
information.

This is exactly why I don=E2=80=99t think we should use =
=E2=80=9Cclaim=E2=80=9D in the way that we=E2=80=99re using it. Yes, a =
=E2=80=9Cclaim=E2=80=9D could come back through an RS =E2=80=94 but in =
the context of GNAP, that makes it a resource. So we need a different =
word for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s going to be about the user, and that=E2=80=99s what we=E2=80=99=
re going to focus on here, but since you can also get information about =
the user from a resource we can=E2=80=99t just call it a =E2=80=9Cclaim=E2=
=80=9D. I think this has been at the heart of a lot of confusion in =
recent threads, as well as confusion about the scope of the inclusion of =
identity in the GNAP protocol.

So let=E2=80=99s let =E2=80=9Cclaim=E2=80=
=9D mean what it already does, and let=E2=80=99s find a way to =
differentiate between when an item, claim or otherwise,  comes =
as part of a resource and when it comes back directly. This is an =
important differentiating feature for GNAP.

Some straw man ideas, none of which =
I=E2=80=99m particularly in love with:

 - direct data
 - properties
 - =
details
 - statements

The important thing here is that it=E2=80=
=99s not necessarily :about: the RO, and that it is :not: in a =
resource.

Any other =
thoughts?

 =E2=80=94 Justin

















=

--Apple-Mail=_1CC77A43-3B44-4D16-8ABF-450FE8B72179--


From nobody Mon Jul 27 16:17: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 D9F523A09EF for ; Mon, 27 Jul 2020 16:17: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_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 AoLwRXGBG1B0 for ; Mon, 27 Jul 2020 16:17:29 -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 675313A09E8 for ; Mon, 27 Jul 2020 16:17:29 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id h19so19077488ljg.13 for ; Mon, 27 Jul 2020 16:17: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=T0D0PYBPZxGTWUbvftE4ZWUxFcMqhcXGVIQPu5V/Dd0=; b=tpW8wpQLvWS0tJR9AubP6lrV9tG3l7RGdNGRAyHb6cVFhYGKg0zwaZjnZJCh+AimQp Atja4VnSUfLmx1LkXYVY6sBwp+uZ7kcimu1EM+nVbUvzswY4if0bT/Kw9gqGVE0oo9MJ AmpvE0BnBROLXSKjPRY8aLDb0K8KJSAKwkfNv+EhdmHaC6i0Xi3mlSkUQjXK5ENOWZJe zQ+xHJ6UdOCkUrONLjxCYQ8L7gv6awEtPYPniVE+o6g10imMoGZktePtfpQha/8uthIi CPE07cPw2EcXD1Y9Tmk6qXR5CoLJhjhfD6HMYGcW4lTvleq9dnFXg1ZKLiGIRYCjV57g /B2w==
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=T0D0PYBPZxGTWUbvftE4ZWUxFcMqhcXGVIQPu5V/Dd0=; b=mzVLlpD+48agj+njMkTP1OofiyNnN0gAVTTS9Pcb0rAxJlZOC5s7qnKKZnchKGw5RV Saob2AG/AGf/W1Zec59V6ieFDP8u29wIdwKrqiIOJvasE3BfVtz8mXlSZ3/Pv91yzaDg gfvTQKVeIVYCMse/sx/+Y/btIUgcKMfJ/X1G35ibI/JCYkcTmpSc4g/3l+8TaVtpFKb+ 3bgDMGIYhPGA6nKxnNtw8rFhmfvk58oNi+6ACJGUANmodwcO8x7cPfypDxoD6XH55G45 tkTm4JlJU2w+g4LGWnHaUL10hAplb4+KRVZjcum065Tu04s1AzkNqGWhVH9Flvc4nsi4 o5gQ==
X-Gm-Message-State: AOAM531k3fdyn6fB/kM4uRVZu92L/SwAgnIA9UmPRsE/UmmrLQjOp5CM nj7XiJYKOgoOC/crs71NSnIMXJkzLo3jxQULo4M=
X-Google-Smtp-Source: ABdhPJwoH4LBhETn8tX6wRPu4CJGTVcrtM2GaPn+0FPLlWX+Lvej9IcF60TC4TBCd/TiO95W4QinSBdlNgK2Ur4KY1w=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr11489200ljh.110.1595891847434;  Mon, 27 Jul 2020 16:17:27 -0700 (PDT)
MIME-Version: 1.0
References:                <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu>  <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu>      <251CEF78-781F-4316-85DD-0930D2368074@mit.edu>
In-Reply-To: <251CEF78-781F-4316-85DD-0930D2368074@mit.edu>
From: Dick Hardt 
Date: Mon, 27 Jul 2020 16:16:51 -0700
Message-ID: 
To: Justin Richer 
Cc: Francis Pouatcha , txauth@ietf.org,  Tom Jones , Denis 
Content-Type: multipart/alternative; boundary="000000000000aa97af05ab74868c"
Archived-At: 
Subject: Re: [Txauth] Claims [was: - Dictionary]
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, 27 Jul 2020 23:17:33 -0000

--000000000000aa97af05ab74868c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

If I missed the point, please clarify.

This description of XYZ, is also a description of XAuth:

"here=E2=80=99s a block that asks for stuff coming back from an RS and here=
=E2=80=99s a
different block that asks for stuff coming back from the AS directly=E2=80=
=9D. Some
of those things coming back, in either place, could be claims about the
user. (Or really claims about anything else, if you want to use the wider
definition of the term.)"


And the last I checked XYZ, it only supported identifier claims coming back
from the GS. If it now supports any claims, then XYZ and XAuth are pretty
much the same.


On Mon, Jul 27, 2020 at 4:09 PM Justin Richer  wrote:

> Not really the point I was making here, and you can return claims directl=
y
> from the AS in XYZ, but now we=E2=80=99re just talking in circles so I do=
n=E2=80=99t think
> this is a productive thread anymore.
>
>  =E2=80=94 Justin
>
> On Jul 27, 2020, at 6:59 PM, Dick Hardt  wrote:
>
> No, that is not accurate. XAuth is a super set of XYZ (as currently
> written) as XYZ does not allow the direct return of claims from the GS.
>
> If the Client wants an access token to retrieve Claims (name and email),
> it includes the following JSON in its Grant Request:
>
> "authorizations":{
>     "token_1": {
>         "type": "oidc_userinfo",
>         "claims": { "email": null, "name": null }
>     }
>
> note: "standard_name_space" is to have a standardized RAR type for
> oidc_userinfo
>
>
> If the Client wants to get bare claims for name and email directly from
> the GS, it includes:
>
> "claims": {
>     "oidc_userinfo": { "email": null, "name": null }
> }
>
> If the Client wants to get an ID Token containing name and email, it
> includes:
>
> "claims": {
>     "oidc_id_token": { "email": null, "name": null }
> }
>
>
> Access tokens are always requested and returned in the "authorizations"
> object, including if the access token is to access claims at a userinfo
> endpoint.
>
> Claims are always requested and returned in the "claims" object.
>
> /Dick
>
>
> On Mon, Jul 27, 2020 at 1:11 PM Justin Richer  wrote:
>
>> I may have figured out a bit about how these approaches are actually
>> different and why we might be talking past each other.
>>
>> From what I can see, the Xauth style query is basically saying =E2=80=9C=
here=E2=80=99s a
>> block asking for all the identity stuff in the protocol, and telling you
>> where to put the identity stuff in the response no matter where that is=
=E2=80=9D.
>> So this is why =E2=80=9Cclaims=E2=80=9D are the high-order element where=
 things like query
>> style and delivery are details of that.
>>
>> XYZ takes a markedly different approach, basically saying =E2=80=9Chere=
=E2=80=99s a block
>> that asks for stuff coming back from an RS and here=E2=80=99s a differen=
t block
>> that asks for stuff coming back from the AS directly=E2=80=9D. Some of t=
hose things
>> coming back, in either place, could be claims about the user. (Or really
>> claims about anything else, if you want to use the wider definition of t=
he
>> term.)
>>
>>
>> So fundamentally the composition is different. Xauth lists the identity
>> stuff all together, whereas XYZ splits identity stuff based on how it=E2=
=80=99s
>> coming back. Xauth seems to prefer describing all the identity data to b=
e
>> returned regardless of how it=E2=80=99s returned. I prefer the XYZ appro=
ach, where
>> resources are always resources regardless of what they=E2=80=99re about,=
 and direct
>> data is always direct data regardless of what it=E2=80=99s about.
>>
>>
>> Is that an accurate read?
>>
>>  =E2=80=94 Justin
>>
>>
>>
>> On Jul 27, 2020, at 9:45 AM, Dick Hardt  wrote:
>>
>> A slide in my presentation today may clarify how I am thinking about it.
>>
>> On Mon, Jul 27, 2020 at 4:23 AM Justin Richer  wrote:
>>
>>> Since you focused on the individual elements of the straw man examples
>>> you requested instead of the overall problem, I think you=E2=80=99re mi=
ssing the
>>> core point. Let me bring it back to a concrete example:
>>>
>>> In Xauth currently, you can use the =E2=80=9Cclaims=E2=80=9D query synt=
ax from OIDC to
>>> request user claims inside the =E2=80=9Cclaims.oidc=E2=80=9D object on =
request. However,
>>> Xauth currently uses =E2=80=9Cuserinfo=E2=80=9D to mark information com=
ing back directly to
>>> the client as JSON. Since =E2=80=9Cuserinfo=E2=80=9D is already defined=
 by OIDC in this
>>> context to indicate information that should come back from the UserInfo
>>> Endpoint (and therefore as a resource, with rights tied to an access
>>> token), the Xauth approach would need a name other than =E2=80=9Cuserin=
fo=E2=80=9D here to
>>> indicate such claims coming back directly as JSON.
>>>
>>> What would you call that field?
>>>
>>> Because whatever that field would be called is exactly the kind of data
>>> differentiation that I=E2=80=99m talking about here. And considering th=
at Xauth
>>> already does differentiate between claims coming back as resources, as
>>> assertions, and direct JSON, I think it=E2=80=99s clear that it does ma=
tter.
>>>
>>>  =E2=80=94 Justin
>>>
>>>
>>> On Jul 24, 2020, at 4:57 PM, Dick Hardt  wrote:
>>>
>>> It is not clear to me what it matters if a Claim comes from an RS, or
>>> from the GS, so I don't see a need to differentiate them.
>>>
>>> I would include verifiable credentials and user-bound keys as Claims.
>>>
>>> All the payment processing information I have seen has been in RAR. Whe=
n
>>> would the Client get payment processing directly from the GS?
>>>
>>> What is your example for distributed networks storage locations? If wha=
t
>>> is stored is a statement about the user, then I would consider that a C=
laim
>>> as well.
>>>
>>> We disagree on how to map OIDC to GNAP.  The direct data is a claims
>>> request, the data coming indirectly is an access token request.
>>>
>>>
>>>
>>> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer  wrote:
>>>
>>>> Since we=E2=80=99re already talking about returning claims as direct d=
ata as
>>>> well as a part of the resource API being protected, so we already need=
 a
>>>> way to differentiate the two kinds of items. Just calling it =E2=80=9C=
claims=E2=80=9D
>>>> doesn=E2=80=99t help, because as you=E2=80=99ve pointed out they could=
 show up in both
>>>> places. So yes, defining that difference is something we should worry =
about
>>>> now, even if the core protocol only uses it for claims.
>>>>
>>>> The two forms of direct data that XYZ returns are subject identifiers
>>>> (a subset of identity claims) and assertions =E2=80=94 the latter bein=
g a container
>>>> not just for identity claims but also authentication information and o=
ther
>>>> elements. Assertions are not claims themselves.
>>>>
>>>> Other use cases that have been brought up include verifiable
>>>> credentials and proofs, user-bound keys, payment processing informatio=
n,
>>>> and distributed network storage locations. I=E2=80=99m sure there are =
a lot more.
>>>> To me, these are subsets of the =E2=80=9Cdirect data=E2=80=9D but not =
subsets of =E2=80=9Cclaims=E2=80=9D.
>>>> GNAP shouldn=E2=80=99t be defining what all of these look like, but it=
 should
>>>> define a way to talk about them.
>>>>
>>>> I think different top-level request objects are better suited for
>>>> different query semantics. Like, for example, the OIDC =E2=80=9Cclaims=
=E2=80=9D request,
>>>> which allows targeting of its claims information into different return
>>>> buckets. This overlaps with the =E2=80=9Cresources=E2=80=9D request at=
 the very least. I
>>>> don=E2=80=99t think GNAP should define how to do this specific combina=
tion, that
>>>> should be for OIDF to debate and apply. The same with a DID service ba=
sed
>>>> query, or Presentation Exchange [1], or anything else that people want=
 to
>>>> come up with.
>>>>
>>>> In my view, GNAP should define query structures for two things: rights
>>>> that get tied to an access token and data that comes back directly to =
the
>>>> client. For the latter, I think we can do some very limited and very u=
seful
>>>> specific items, which is what I=E2=80=99ve put into XYZ.
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>> [1] https://identity.foundation/presentation-exchange/
>>>>
>>>> On Jul 24, 2020, at 3:58 PM, Dick Hardt  wrote:
>>>>
>>>> I agree we want GNAP to be a strong foundation.
>>>>
>>>> Do you have an example of other "direct data"? If so, do you expect it
>>>> to be defined in the core protocol?
>>>>
>>>> I would expect an extension for other "direct data" to define top leve=
l
>>>> objects, and an appropriate definition for that "direct data".
>>>>
>>>> My "do we need to worry about it now" comment was on creating a generi=
c
>>>> term for "direct data". Unless we are solving those now, we can let fu=
rther
>>>> work define that "direct data" explicitly.
>>>>
>>>>
>>>>
>>>>
>>>> =E1=90=A7
>>>>
>>>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer  wrote=
:
>>>>
>>>>> Yes, I do think we need to worry about it to the extent that we are
>>>>> not creating something that is over-fit to a limited set of use cases=
.
>>>>>
>>>>> GNAP should be a foundation that many amazing new things can be built
>>>>> on top of.
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt  wrote:
>>>>>
>>>>> Justin, thanks for clarifying.
>>>>>
>>>>> What are some examples of other "direct data" that the GS may return?
>>>>> If it is not in core GNAP, do we need to worry about now? We can then=
 give
>>>>> the direct data from the GS that is not a claim, an appropriate name =
in
>>>>> that document.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer 
>>>>> wrote:
>>>>>
>>>>>> Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m s=
aying. I agree
>>>>>> that =E2=80=9Cclaims=E2=80=9D are about the user, in this context*. =
But the AS could return
>>>>>> other data directly to the client that isn=E2=80=99t about the user.=
 Those aren=E2=80=99t
>>>>>> =E2=80=9Cclaims=E2=80=9D by the classical definition. Also since =E2=
=80=9Cclaims=E2=80=9D can come back
>>>>>> from places other than directly, then we shouldn=E2=80=99t call ever=
ything that
>>>>>> comes back a =E2=80=9Cclaim=E2=80=9D.
>>>>>>
>>>>>> I=E2=80=99m arguing that we keep =E2=80=9Cclaims=E2=80=9D to mean wh=
at it already means and
>>>>>> come up with a new word to mean =E2=80=9Cthings that come back direc=
tly from the
>>>>>> AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=99s=
 more complete definitions, but
>>>>>> to simplify:
>>>>>>
>>>>>> Claims:
>>>>>> - information about the user
>>>>>> - can come back directly from the AS
>>>>>> - can come back in a resource from the RS
>>>>>>
>>>>>> Resource:
>>>>>> - Returned from an RS
>>>>>> - Protected by access token
>>>>>> - Could contain claims about the user
>>>>>>
>>>>>> Direct data (or some better name):
>>>>>> - Returned directly from AS
>>>>>> - Could contain claims about the user
>>>>>>
>>>>>> I think the problem is that some people are using =E2=80=9Cclaims=E2=
=80=9D to mean #1
>>>>>> and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: It=E2=80=
=99s important to
>>>>>> remember, when talking about OIDC, that an IdP in OIDC combines an A=
S and
>>>>>> an RS into one entity for identity information. There can be other R=
S=E2=80=99s as
>>>>>> well, and there usually are in the wild, but the one defined by OIDC=
 is the
>>>>>> UserInfo Endpoint. The fact that it returns user data doesn=E2=80=99=
t make it any
>>>>>> less of an RS.
>>>>>>
>>>>>>  =E2=80=94 Justin
>>>>>>
>>>>>> * In the wider context of things like the information claims inside =
a
>>>>>> JWT, the claims could be about literally anything, but that=E2=80=99=
s not what
>>>>>> we=E2=80=99re discussing here and it=E2=80=99s not how it=E2=80=99s =
being used.
>>>>>>
>>>>>>
>>>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt  wrote=
:
>>>>>>
>>>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from
>>>>>> the OP in an ID Token, or the Client can obtain Claims using an acce=
ss
>>>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>>>
>>>>>> The Claims are about the User (not a RO).
>>>>>>
>>>>>> In XAuth, I'm proposing the Client may obtain bare claims from the G=
S
>>>>>> directly in addition to the mechanisms in ODIC.
>>>>>>
>>>>>> So I don't think we are changing the definition of Claim from how it
>>>>>> has been used in OIDC, and I fail to see any reason to NOT use Claim=
.
>>>>>>
>>>>>> Justin: you allude to Claims being about a party other than the User=
.
>>>>>> Would you provide an example?
>>>>>>
>>>>>> /Dick
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>> UserInfo Endpoint
>>>>>> Protected Resource that, when presented with an Access Token by the
>>>>>> Client, returns authorized information about the End-User represente=
d by
>>>>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUS=
T use
>>>>>> the https scheme and MAY contain port, path, and query parameter com=
ponents.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> =E1=90=A7
>>>>>>
>>>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer 
>>>>>> wrote:
>>>>>>
>>>>>>> I want to focus on one aspect here:
>>>>>>>
>>>>>>>
>>>>>>>> A Claim is a well understood term in the field. We should use it.
>>>>>>>> It is still a Claim if it comes directly from the GS or from an RS=
.
>>>>>>>>
>>>>>>> I do not understand why a Resource release by an RS shall be h to a=
s
>>>>>>> a claim, even if the content of the Resource is an assertion. It wi=
ll lead
>>>>>>> to confusion. If we limit claims to information GS releases into To=
ken,
>>>>>>> User Info, and other objects it returns, this will help separate
>>>>>>> responsibilities between GS and RS. As soon as RS services and info=
rmation,
>>>>>>> this is called a Resource, no matter the nature of the content of t=
hat
>>>>>>> information.
>>>>>>>
>>>>>>>
>>>>>>> This is exactly why I don=E2=80=99t think we should use =E2=80=9Ccl=
aim=E2=80=9D in the way
>>>>>>> that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could c=
ome back through an RS =E2=80=94 but in
>>>>>>> the context of GNAP, that makes it a resource. So we need a differe=
nt word
>>>>>>> for data coming back directly from the AS to the client. Sometimes =
it=E2=80=99s
>>>>>>> going to be about the user, and that=E2=80=99s what we=E2=80=99re g=
oing to focus on here,
>>>>>>> but since you can also get information about the user from a resour=
ce we
>>>>>>> can=E2=80=99t just call it a =E2=80=9Cclaim=E2=80=9D. I think this =
has been at the heart of a lot
>>>>>>> of confusion in recent threads, as well as confusion about the scop=
e of the
>>>>>>> inclusion of identity in the GNAP protocol.
>>>>>>>
>>>>>>> So let=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already d=
oes, and let=E2=80=99s find a way
>>>>>>> to differentiate between when an item, claim or otherwise,  comes a=
s part
>>>>>>> of a resource and when it comes back directly. This is an important
>>>>>>> differentiating feature for GNAP.
>>>>>>>
>>>>>>> Some straw man ideas, none of which I=E2=80=99m particularly in lov=
e with:
>>>>>>>
>>>>>>>  - direct data
>>>>>>>  - properties
>>>>>>>  - details
>>>>>>>  - statements
>>>>>>>
>>>>>>> The important thing here is that it=E2=80=99s not necessarily :abou=
t: the
>>>>>>> RO, and that it is :not: in a resource.
>>>>>>>
>>>>>>> Any other thoughts?
>>>>>>>
>>>>>>>  =E2=80=94 Justin
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> =E1=90=A7

--000000000000aa97af05ab74868c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


If I missed the point, please clarif=
y.

This description of XYZ, is also a description =
of XAuth:

"here=E2=80=99s a block that a=
sks for stuff coming back from an RS and here=E2=80=99s a different block t=
hat asks for stuff coming back from the AS directly=E2=80=9D. Some of those=
 things coming back, in either place, could be claims about the user. (Or r=
eally claims about anything else, if you want to use the wider definition o=
f the term.)"


And the last I c=
hecked XYZ, it only supported identifier claims coming back from the GS. If=
 it now supports any claims, then XYZ and XAuth are pretty much the same.


On Mon, Jul 27, 2020 at 4:09 PM Justin Richer <=
jricher@mit.edu> wrote:
=

Not really the point I was making here, and you can return=
 claims directly from the AS in XYZ, but now we=E2=80=99re just talking in =
circles so I don=E2=80=99t think this is a productive thread anymore.
<=
br>
=C2=A0=E2=80=94 Justin

=

On Jul 27, 2020, at 6:59 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
=
No, that is not accurate. XAuth is a super set of XYZ (as currently written=
) as XYZ does not allow the direct return of claims from the GS.

If the Client wants an access token =
to retrieve=C2=A0Claims (name and email), it includes the following JSON in=
 its Grant Request:

<=
div>"authorizations":{=C2=A0
=C2=A0 =C2=A0 "token_1": {=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "type": "<s=
tandard_name_space>oidc_userinfo",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "claims": { "email&qu=
ot;: null, "name": null }
<=
div>=C2=A0 =C2=A0 }

note: "standard_name_space" i=
s to have a standardized RAR type for oidc_userinfo
=


If the Client wants to get bare claims for name and em=
ail directly from the GS, it includes:

"claims": {
=C2=A0 =C2=A0 "oidc_userinfo": { "email": null, =
"name": null }
}
=


If the Client wants to get an ID Token containing name and email, it in=
cludes:

"claims": {
=

=C2=A0 =C2=A0 "oidc_id_toke=
n": { "email": null, "name": null }
}

<=
/div>
Access tokens are always requested and returned=C2=A0in the "=
;authorizations" object, including if the access token is to access cl=
aims at a userinfo endpoint.

Claims are always req=
uested and returned in the "claims" object.

<=
div>/Dick


On Mon, Jul 27, 2020 at 1:11 PM Justin Richer=
 <jricher@mit.edu> wrote:
I may have figured out a bit about how these approaches are actually dif=
ferent and why we might be talking past each other.

From=
 what I can see, the Xauth style query is basically saying =E2=80=9Chere=E2=
=80=99s a block asking for all the identity stuff in the protocol, and tell=
ing you where to put the identity stuff in the response no matter where tha=
t is=E2=80=9D. So this is why =E2=80=9Cclaims=E2=80=9D are the high-order e=
lement where things like query style and delivery are details of that.

XYZ takes a markedly different approach, basically say=
ing =E2=80=9Chere=E2=80=99s a block that asks for stuff coming back from an=
 RS and here=E2=80=99s a different block that asks for stuff coming back fr=
om the AS directly=E2=80=9D. Some of those things coming back, in either pl=
ace, could be claims about the user. (Or really claims about anything else,=
 if you want to use the wider definition of the term.)

=


So fundamentally the composition is different. Xauth li=
sts the identity stuff all together, whereas XYZ splits identity stuff base=
d on how it=E2=80=99s coming back. Xauth seems to prefer describing all the=
 identity data to be returned regardless of how it=E2=80=99s returned. I pr=
efer the XYZ approach, where resources are always resources regardless of w=
hat they=E2=80=99re about, and direct data is always direct data regardless=
 of what it=E2=80=99s about.


Is tha=
t an accurate read?

=C2=A0=E2=80=94 Justin




A slide in my presentation today may clarify how I am thinking about =
it.

On Mon, Jul 27, 2020 at 4:23 AM Justin Richer <jricher@mit.edu> wrote:
Since you focused on the=
 individual elements of the straw man examples you requested instead of the=
 overall problem, I think you=E2=80=99re missing the core point. Let me bri=
ng it back to a concrete example:

In Xauth currently, yo=
u can use the =E2=80=9Cclaims=E2=80=9D query syntax from OIDC to request us=
er claims inside the =E2=80=9Cclaims.oidc=E2=80=9D object on request. Howev=
er, Xauth currently uses =E2=80=9Cuserinfo=E2=80=9D to mark information com=
ing back directly to the client as JSON. Since =E2=80=9Cuserinfo=E2=80=9D i=
s already defined by OIDC in this context to indicate information that shou=
ld come back from the UserInfo Endpoint (and therefore as a resource, with =
rights tied to an access token), the Xauth approach would need a name other=
 than =E2=80=9Cuserinfo=E2=80=9D here to indicate such claims coming back d=
irectly as JSON.=C2=A0

What would you call that fi=
eld?

Because whatever that field would be called i=
s exactly the kind of data differentiation that I=E2=80=99m talking about h=
ere. And considering that Xauth already does differentiate between claims c=
oming back as resources, as assertions, and direct JSON, I think it=E2=80=
=99s clear that it does matter.

=C2=A0=E2=80=94 Ju=
stin


On Jul 24, 2020, a=
t 4:57 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It is not clear to me what it matters if a Claim comes from an RS, or=
 from the GS, so I don't see a need to differentiate them.
I would include verifiable credentials and user-bound keys as =
Claims.

All the payment processing information I h=
ave=C2=A0seen has been in RAR. When would=C2=A0the Client get payment proce=
ssing directly from the GS?

What is your example f=
or distributed networks storage locations? If what is stored is a statement=
 about the user, then I would consider that a Claim as well.

=

We disagree on how to map OIDC to GNAP.=C2=A0 The direct data is=
 a claims request, the data coming indirectly is an access token request.



On Fri, Jul 24, 2020 at 1:39 PM Justin Ri=
cher <jricher@mit.e=
du> wrote:
https://identity.foundation/presentation=
-exchange/

On Jul 24, 2020, =
at 3:58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree we want GNAP to be a strong foundation.=C2=A0

Do you have an example of other "direct data"? If so, do you ex=
pect it to be defined in the core protocol?

I woul=
d expect an extension for other "direct data" to define top level=
 objects, and an appropriate definition for that "direct data".

My "do we need to worry about it now" com=
ment was on creating a generic term for "direct data". Unless we =
are solving those now, we can let further work define that "direct dat=
a" explicitly.



=

=E1=90=A7

On Fri, Jul 24, 2020 at 12:4=
2 PM Justin Richer <jricher@mit.edu> wrote:
Yes, I do think we need to worry about it to the exten=
t that we are not creating something that is over-fit to a limited set of u=
se cases.=C2=A0

GNAP should be a foundation that many am=
azing new things can be built on top of.

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

On Jul 24, 2020, a=
t 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin, thanks for clarifying.

What are some examples o=
f other "direct data" that the GS may return? If it is not in cor=
e GNAP, do we need to worry about now? We can then give the direct data fro=
m the GS that is not a claim, an appropriate name in that document.



On Fri, Jul 24, 2020 at 11:46 AM Justin Riche=
r <jricher@mit.edu<=
/a>> wrote:
<=
div>Dick: No, I think you=E2=80=99re misunderstanding what I=E2=80=99m sayi=
ng. I agree that =E2=80=9Cclaims=E2=80=9D are about the user, in this conte=
xt*. But the AS could return other data directly to the client that isn=E2=
=80=99t about the user. Those aren=E2=80=99t =E2=80=9Cclaims=E2=80=9D by th=
e classical definition. Also since =E2=80=9Cclaims=E2=80=9D can come back f=
rom places other than directly, then we shouldn=E2=80=99t call everything t=
hat comes back a =E2=80=9Cclaim=E2=80=9D.

I=E2=80=99m ar=
guing that we keep =E2=80=9Cclaims=E2=80=9D to mean what it already means a=
nd come up with a new word to mean =E2=80=9Cthings that come back directly =
from the AS=E2=80=9D. These aren=E2=80=99t meant to replace Francis=E2=80=
=99s more complete definitions, but to simplify:

C=
laims:
	- information=
 about the user
	- ca=
n come back directly from the AS
	- can come back in a resource from the RS

=

Resource:
	- Ret=
urned from an RS
	- P=
rotected by access token
	- Could contain claims about the user

Direct =
data (or some better name):
=
	- Returned directly from AS
	- Could contain claims about the user

<=
div>I think the problem is that some people are using =E2=80=9Cclaims=E2=80=
=9D to mean #1 and some to mean #3. It=E2=80=99s clearly #1 in OIDC. But: I=
t=E2=80=99s important to remember, when talking about OIDC, that an IdP in =
OIDC combines an AS and an RS into one entity for identity information. The=
re can be other RS=E2=80=99s as well, and there usually are in the wild, bu=
t the one defined by OIDC is the UserInfo Endpoint. The fact that it return=
s user data doesn=E2=80=99t make it any less of an RS.

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

* In the wider context of t=
hings like the information claims inside a JWT, the claims could be about l=
iterally anything, but that=E2=80=99s not what we=E2=80=99re discussing her=
e and it=E2=80=99s not how it=E2=80=99s being used.


=


In OpenID Connect (OIDC),=
 the Client can obtain Claims directly from the OP in an ID Token, or the C=
lient can obtain Claims using an access token to call the UserInfo endpoint=
, a Protected Resource[1].

The Claims are about the User=
 (not a RO).

In XAuth, I'm proposing the Clien=
t may obtain bare claims from the GS directly in addition to the mechanisms=
 in ODIC.

So I don't think we are changing the=
 definition of Claim from how it has been used in OIDC, and I fail to see a=
ny reason to NOT use Claim.

Justin: you allude to =
Claims being about a party other than the User. Would you provide an exampl=
e?

/Dick

[1]
UserInf=
o Endpoint
Protected Resource that, when presented with an Access=
 Token by the Client, returns authorized information about the End-User rep=
resented by the corresponding Authorization Grant. The UserInfo Endpoint UR=
L MUST use the https scheme and MAY contain port, path, and query parameter=
 components.



3D"==E1=90=A7

On Fri, Jul 24, 2020 at 5:58 AM Jus=
tin Richer <jricher=
@mit.edu> wrote:
I want to focus on one aspect here:


A=
 Claim is a well understood term in the field. We should use it. It is stil=
l a Claim if it comes directly from the GS or from an RS.=C2=A0
=

I do not understand why a Resource release by an RS shall=
 be h to as a claim, even if the content of the Resource is an assertion. I=
t will lead to confusion. If we limit claims to information GS releases int=
o Token, User Info, and other objects it returns, this will help separate r=
esponsibilities between GS and RS. As soon as RS services and information, =
this is called a Resource, no matter the nature of the content of that info=
rmation.

This is exactly=
 why I don=E2=80=99t think we should use =E2=80=9Cclaim=E2=80=9D in the way=
 that we=E2=80=99re using it. Yes, a =E2=80=9Cclaim=E2=80=9D could come bac=
k through an RS =E2=80=94 but in the context of GNAP, that makes it a resou=
rce. So we need a different word for data coming back directly from the AS =
to the client. Sometimes it=E2=80=99s going to be about the user, and that=
=E2=80=99s what we=E2=80=99re going to focus on here, but since you can als=
o get information about the user from a resource we can=E2=80=99t just call=
 it a =E2=80=9Cclaim=E2=80=9D. I think this has been at the heart of a lot =
of confusion in recent threads, as well as confusion about the scope of the=
 inclusion of identity in the GNAP protocol.

So le=
t=E2=80=99s let =E2=80=9Cclaim=E2=80=9D mean what it already does, and let=
=E2=80=99s find a way to differentiate between when an item, claim or other=
wise,=C2=A0=C2=A0comes as part of a resource and when it comes back directl=
y. This is an important differentiating feature for GNAP.

Some straw man ideas, none of which I=E2=80=99m particularly in lov=
e with:

=C2=A0- direct data
=C2=A0- prop=
erties
=C2=A0- details
=C2=A0- statements
The important thing here is that it=E2=80=99s not necessarily :=
about: the RO, and that it is :not: in a resource.

Any =
other thoughts?

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

















3D""=E1=90=A7


--000000000000aa97af05ab74868c--


From nobody Tue Jul 28 04: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 E04E03A0B28 for ; Tue, 28 Jul 2020 04:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.981
X-Spam-Level: 
X-Spam-Status: No, score=-1.981 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, MALFORMED_FREEMAIL=0.116, MIME_QP_LONG_LINE=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 JP0G1CoKmEED for ; Tue, 28 Jul 2020 04:27:08 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 F38843A0B27 for ; Tue, 28 Jul 2020 04:27:07 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id z18so14365526wrm.12 for ; Tue, 28 Jul 2020 04:27:07 -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; bh=lzZrjty7zPvzB8fIk0nMbLBcJywVtOQpzbk6694Spus=; b=DFYwZVZwcYi2zYlAaPxKg86B3woi0Rf8p1+EXINdmJweds3Kaa8SyDReLmYJI6krIJ OOOpf7/pKjQjrokTVQBdv624gQTnuosh6OUBTcLL+KXT00+q3wL5KmSZNGunYyjJaGzd P10jd8Rvq3pSXSuievDRygbni1HGb8uC7v8o8u5w1VrE79ci9MSufjla4gOBmMyuwAzk QJbmSfxx9u6EkktBDWzweEt+DimYISYW7e4fvVCTrRWtSdZ0/j1XDpCEv21RjQW71Y/5 5S0ZRJxO37UER4UWwQksPxA3/Md4nT61Ax5LfUUg1sR3ZXEDpE5QuTz4J4/P5N6fORgJ HC0w==
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; bh=lzZrjty7zPvzB8fIk0nMbLBcJywVtOQpzbk6694Spus=; b=noB7n7YQ5tFWwJodh3iZJCWywysPIiB286jXg//I7xRsLkWFYyn4gPJ5icdsxO5twO waeLUSZmd/F2T93SC+HfDVei2lfYW772G/oTePUdnqzKCPfqaj7YzvX4GxWkz6w6Ig8u ZNLBQOqoS8+v5KWEFkcIxwbxU6hLOOQ4qNhPLQXZPS0miUxj9qQzJymlse5Yqlmqk0Nj pIgZhD6JXXK9CMxovSbjaN0e1YyArSgf/KJ/tw2YdGG0HPrMATVGpxPA19yhffqKUoSG wmf8c4EVqlvQDkBa7q+RvFnCOtA9yF3RQ/WFUH78sdeJC6OGRed4TW1OANxJ8Z7DlsPS v82w==
X-Gm-Message-State: AOAM532t1iVAWAf4JlmBoHS3pHfvrwkcH/kEPXXU99hZGGaasuB18vVS vVfDi4r/IwGxv0BSyGDobq2aijJX
X-Google-Smtp-Source: ABdhPJxAWPOwNJM5sBMbm7+qB7XRH0zKU/CuOhL6PPqq4joXEDQH8tw8+ZEdPRQPdBtOcf2s+jVI7Q==
X-Received: by 2002:adf:cd8f:: with SMTP id q15mr27227886wrj.347.1595935626295;  Tue, 28 Jul 2020 04:27:06 -0700 (PDT)
Received: from [10.0.0.140] (bzq-109-66-125-13.red.bezeqint.net. [109.66.125.13]) by smtp.gmail.com with ESMTPSA id u66sm3670967wmu.37.2020.07.28.04.27.05 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 04:27:05 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.39.20071300
Date: Tue, 28 Jul 2020 14:27:04 +0300
From: Yaron Sheffer 
To: GNAP Mailing List 
Message-ID: <13FF683A-AF95-4769-97FA-C1A594A9F4CB@gmail.com>
Thread-Topic: Collecting use cases
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3678791225_679809245"
Archived-At: 
Subject: [Txauth] Collecting 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, 28 Jul 2020 11:27:10 -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_3678791225_679809245
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

Hi everyone,

=20

Several people mentioned that we would like to collect use cases for the pr=
ospective GNAP protocol.

=20

We have set up a wiki [1] on the working group=E2=80=99s GitHub area, and people =
are welcome to enter their favorite use cases. We will not impose any editor=
ial standards or content conventions, this is completely up to contributors.=
 Note that you need to have a GitHub account to edit the wiki.

=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 Leif and Yaron

=20

[1] https://github.com/ietf-wg-gnap/general/wiki/IETF-GNAP-Working-Group


--B_3678791225_679809245
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


Hi everyone=
,
 
S=
everal people mentioned that we would like to collect use cases for the pros=
pective GNAP protocol.
 
We have set up a wiki [1] on the working group=E2=80=99s GitHu=
b area, and people are welcome to enter their favorite use cases. We will no=
t impose any editorial standards or content conventions, this is completely =
up to contributors. Note that you need to have a GitHub account to edit the =
wiki.
 
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 Leif and Yaron
 
<=
p class=3DMsoNormal>[1] https://github.com/ietf=
-wg-gnap/general/wiki/IETF-GNAP-Working-Group


--B_3678791225_679809245--



From nobody Tue Jul 28 04:30: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 52CCE3A0B2B for ; Tue, 28 Jul 2020 04:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.982
X-Spam-Level: 
X-Spam-Status: No, score=-1.982 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=0.116, MIME_QP_LONG_LINE=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 dZ5jiR2ju-yH for ; Tue, 28 Jul 2020 04:30:13 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 8AFED3A0B3A for ; Tue, 28 Jul 2020 04:30:10 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id r12so17887301wrj.13 for ; Tue, 28 Jul 2020 04:30:10 -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=p5RShzrSq35ieCGZYk9H1kSzkcvVJM7dpwXB0AsjZ/M=; b=BY1aWhIVi6Wtz+C+3k/cz4n8MwrQDuZK1x5w5IUK+Jf4jj8hiUTVZnfdoWvC4OSz9k S/X/OjlHL8xTOqfRybK5aT8ge3L7DTH7yN4j/RCOAUqxm0BHmrISuqFBAEEnpntfn6s5 Aes6WQQlIzuByecJSO+2gNG9FeYtSDVWD13UzRb+zz8PU0yKgQskBPhbOZk73DwhS8bW JE48c6zxP7HeuF70fXElXwNlUCv0+rNoQmnl49WdHgqpX0XY4jJc5IjpiULVckjmWCbZ dkOhlm7C1uoU87oHkyqwJI0t+MQfKCahwi7qD/KC2+nHyam+EE70rX3m6t4stUZED5m2 OFwA==
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=p5RShzrSq35ieCGZYk9H1kSzkcvVJM7dpwXB0AsjZ/M=; b=Tg8Z64st3Hhk59vdnxwh3vX29vjy8t0GdLSIulLTRdpFp7Ti5ENp+vVOmnBM9pAbqH /cfUewWd1btQJ6Wlq1DLXJlYuTBjqwCdITapk11ovnHYYBD/EjehnaDdx0hW036LRpoI alYxgMR/EvX1znHil6NONvukmUkp5avDLgt1waqMonzAAvm3YIzbtgeb4cyw4Yk/2fAz vh4JSutCikXyMj7Ssc8G7csj0/D2YJRQtWYdD2ljSSZ4GdIbpHOYtFfbglKaEcXxs3pv yjbQK9J8FQmswk6WI0Co4VY/wdYyUAHkpyhEpr3OP8fM9U6Cm7KznsKaDVY9wCRo84eQ dGzg==
X-Gm-Message-State: AOAM533zRD89aw0hCaZpNoi3y0DX4xPJUZh8FEsPJ36x0a3M4PL8Q8XN Mx/qO2vmTQH07FqS2zngf45CRY/Z
X-Google-Smtp-Source: ABdhPJyL3sLunDK/Z4L5EVX5bN01vbyPGfyN9U07Y7rYDVwyCFldB3n6N79SmghBMTfs5R+nnfQy1w==
X-Received: by 2002:adf:ef08:: with SMTP id e8mr20656507wro.164.1595935808661;  Tue, 28 Jul 2020 04:30:08 -0700 (PDT)
Received: from [10.0.0.140] (bzq-109-66-125-13.red.bezeqint.net. [109.66.125.13]) by smtp.gmail.com with ESMTPSA id h199sm3891370wme.42.2020.07.28.04.30.07 for  (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 04:30:08 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.39.20071300
Date: Tue, 28 Jul 2020 14:30:07 +0300
From: Yaron Sheffer 
To: GNAP Mailing List 
Message-ID: 
Thread-Topic: GNAP core document design team
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: [Txauth] GNAP core document design team
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, 28 Jul 2020 11:30:16 -0000

Hi everyone,
=C2=A0
Following our discussion yesterday, we are looking for volunteers for a sho=
rt-term design team. The team=E2=80=99s goal will be to come up with an outline of=
 a document combining the best features of XYZ and XAuth. The timeframe will=
 be short =E2=80=93 a few weeks. If you would like to join, please send the chairs=
 a private email by Friday.
=C2=A0
Based on the expressed interest we will=C2=A0pick a small number of individuals=
 for the team. We apologize in advance that we will not offer everyone a spo=
t on the design team.
=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 Leif and Yaron




From nobody Tue Jul 28 07:01: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 516DB3A0C79 for ; Tue, 28 Jul 2020 07:01:27 -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 (2048-bit key) header.d=verisign.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 InZddhbptDUx for ; Tue, 28 Jul 2020 07:01:24 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 ADDCC3A0C78 for ; Tue, 28 Jul 2020 07:01:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=6488; q=dns/txt; s=VRSN; t=1595944886; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=iYIOk8xT7DLrySy7wZeENLxHJhdDLkFL9qHfCFwON3g=; b=PKqGoRi+xlwwAr8eB7SbjVzs8VBsEdp2WLI7eW9WU2clOKTKA1bQAHfC aTH0EQTlWKRJL8MEtXEGEblT4HtV+F/n4j0fopim+WrPxokkJBZC0BcGD ePTAOgQ5cF3nahT/mavwYG4cam9ZU5YDqLSZ98+gEVLBTAJ++e6bw+/Dv bfvlWBrXCmEY4qzVrA+CbCinuIlv/+/5NPuW3oCSXw/wjeX90W3qn0LUY 27uB8Uo6816UgxFZaMOw7W4Ab6v0UQRUUi5188psaXy9/uowHj0uP1Wcn SYRifx4oO0kWhLfLHmGAj5GjSda7M41gPB31p3pKTO/bOU+ns4XPedGFf A==;
IronPort-SDR: 8NDyHHBzMTa0ueWJevAKqgdcOFp4st7aydADRTtEfxDUV6McGCzhIZX86Ln9vnGvq3PXUxQBpW 3t1Zq1d1zhMYCljzIVfNvsDOR4rOag0mMtEeV91Uf7v0nQw8x5Uf5+/Rk8wlAuYO3R6ZmVkHH7 E3Bbpio0K4SUV9/4EAVWmGtn2vGzToitbkouq8cheMsv67Kr+b9OolBCfX8peKr78J1HLLiLAC a+ga5Hn4lLI8StcX37x027d+x76rfkyNvYK3ljBKyN7+XWQVIS+VD4ky0RAh/ZMPOrng5ZA1K8 9yY=
X-IronPort-AV: E=Sophos;i="5.75,406,1589241600"; d="scan'208,217";a="2441502"
IronPort-PHdr: =?us-ascii?q?9a23=3AbuTtAhR58eQVaPxjcxC85w18o9psv+yvbD5Q0Y?= =?us-ascii?q?Iujvd0So/mwa67ZBCBt8tkgFKBZ4jH8fUM07OQ7/m+HzJaqsjd+Fk5M7V0Hy?= =?us-ascii?q?cfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFR?= =?us-ascii?q?rwLxd6KfroEYDOkcu3y/qy+5rOaAlUmTaxe7x/IAi3oAnLt8Qan4RuJ6c+xx?= =?us-ascii?q?DUvnZGZuNayH9yK1mOhRj8/MCw/JBi8yRUpf0s8tNLXLv5caolU7FWFSwqPG?= =?us-ascii?q?8p6sLlsxnDVhaP6WAHUmoKiBpIAhPK4w/8U5zsryb1rOt92C2dPc3rUbA5XC?= =?us-ascii?q?mp4ql3RBP0jioMKjg0+3zVhMNtlqJWuBKvqQJizY7Ibo+bN/R+caHcfdwGSm?= =?us-ascii?q?VMRdxeWzBDAo6mc4cDE+gMMOBFpIf9vVsOqh6+CBGiCO3tzT9Ignv20rM80+?= =?us-ascii?q?s6Dw7JwA8gE8oTu3rJsNr1M7sSUfy7wKLVyjjDdPNW2TD56IjMbB8hp+qDUq?= =?us-ascii?q?xsfsrS0kQvCR3Kjk+RqYz+PjOV2eINv3KH4OpnUOKikmgqoBx+rTaz3MkjkJ?= =?us-ascii?q?XJhp4LxVDe8yV02Ic4K9K3RkN7YdOoDJlduz+aOYdrX84sTW5mtSUmxrEYpZ?= =?us-ascii?q?K1cywHxIklyhPQZfKLboeF7BztWuifLzl1mXJodK+5ih2v/0agzej8WdO10F?= =?us-ascii?q?ZMtidFndjMtmwN1xzO8ceLUOdy/kCk2TuJygvd6flELFgpmabHMZIt37w9m5?= =?us-ascii?q?QJvUjeHiL7ll/6gaCSe0k85+Sk9/7rbqjkq5OALYN4lw7zP6c0lsCiAuk1NB?= =?us-ascii?q?UFUXKB9uSmzrLj+FX0QLBNjvIrjKbUqIvaJcEHpq6hBA9Vz5oj5w6/Dzi41N?= =?us-ascii?q?QYmmEKIU9ZdhyfkoTmO0nALv/5AvujnVigiilryOzBPr37GpXBNGLMn6r7cb?= =?us-ascii?q?Zj8U5c0wwzwcpD6JJTD7ENOPPzWknvu9zEFhI1LhC4z/z6BNh/2I4SQ3+DD6?= =?us-ascii?q?+XPa/IvlKF4vojI+yWa48UvDb9JeIl5/nrjXIhgl8dfa6p3Z8TaH+mGPRpOF?= =?us-ascii?q?uWbmbvgtoaD2cFoBA+TO3xiF2DXj5TYWy+UL475jE+EI6mF5vMRpixgLyd2y?= =?us-ascii?q?e2Bp1XaXpcClCLF3foeZ+IW/YSZyKOLM9siTMEVb27RI8g0RGirhP1y71iLu?= =?us-ascii?q?DM4C0XqYrj1MRp5+3UjRwy6TN1AN6A02GRT2F5hWIISCEq3KBxu0B9zU2D0a?= =?us-ascii?q?cry8BfQJZC7ulOVAl8NJPAwcR1DtnzXkTKedLDAAK3S8+hBz93T98tzfcBZk?= =?us-ascii?q?98H5OpiRWVm2LgH68ciqCLLJ057qya2GL+bY4p12bPybUhp1grXsUJMnep0P?= =?us-ascii?q?1R7Q/WUsTplEGdmqCgeK8fmGb2/2Cf0SDG6FpYVwp0XKPPUHscTlXbt9Xi50?= =?us-ascii?q?zECbSpDOJ0YUN61ceeJ/4SOZXShlJcSaK7NQ=3D=3D?=
X-IPAS-Result: =?us-ascii?q?A2H0BACMLiBf/zGZrQpgg3aBdoEzCoQqkSCaI4EsPQsBA?= =?us-ascii?q?QEBAQEBAQEHASUKBAEBAoRKAheCCyU4EwIDAQELAQEBBQEBAQEBBgMBAQECh?= =?us-ascii?q?kUMgjciGWGBAwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBEgINVGgBAQEBAyMKQ?= =?us-ascii?q?RsCAQgRBAEBFhUCAgIwHQgCBAESCIMfgX6BDa4YdoEyhFIPcYUOBoE4hkaGU?= =?us-ascii?q?YFCPoERgxA+glwCgRiBBoJXgmAEkmKGWpw3AweCX4hYkQ8qn2mSF4oulGwCB?= =?us-ascii?q?AIEBQIVgWqBe3BQgmlQFwINkg+KVnQ3AgYBBwEBAwmPZ4ERAQE?=
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 28 Jul 2020 10:01:22 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1913.005; Tue, 28 Jul 2020 10:01:22 -0400
From: "Hollenbeck, Scott" 
To: "yaronf.ietf@gmail.com" , "txauth@ietf.org" 
Thread-Topic: Collecting use cases
Thread-Index: AQHWZNIOi8L/95oFdUWolAlEW//ZDakdBUZA
Date: Tue, 28 Jul 2020 14:01:22 +0000
Message-ID: 
References: <13FF683A-AF95-4769-97FA-C1A594A9F4CB@gmail.com>
In-Reply-To: <13FF683A-AF95-4769-97FA-C1A594A9F4CB@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_ab0f7895d1e24eea98fd6ebba7d4e7beverisigncom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Txauth] Collecting 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, 28 Jul 2020 14:01:28 -0000

--_000_ab0f7895d1e24eea98fd6ebba7d4e7beverisigncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFlhcm9u
IFNoZWZmZXINClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjgsIDIwMjAgNzoyNyBBTQ0KVG86IEdOQVAg
TWFpbGluZyBMaXN0IDx0eGF1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFtUeGF1
dGhdIENvbGxlY3RpbmcgdXNlIGNhc2VzDQoNCg0KDQpIaSBldmVyeW9uZSwNCg0KDQoNClNldmVy
YWwgcGVvcGxlIG1lbnRpb25lZCB0aGF0IHdlIHdvdWxkIGxpa2UgdG8gY29sbGVjdCB1c2UgY2Fz
ZXMgZm9yIHRoZSBwcm9zcGVjdGl2ZSBHTkFQIHByb3RvY29sLg0KDQoNCg0KV2UgaGF2ZSBzZXQg
dXAgYSB3aWtpIFsxXSBvbiB0aGUgd29ya2luZyBncm91cOKAmXMgR2l0SHViIGFyZWEsIGFuZCBw
ZW9wbGUgYXJlIHdlbGNvbWUgdG8gZW50ZXIgdGhlaXIgZmF2b3JpdGUgdXNlIGNhc2VzLiBXZSB3
aWxsIG5vdCBpbXBvc2UgYW55IGVkaXRvcmlhbCBzdGFuZGFyZHMgb3IgY29udGVudCBjb252ZW50
aW9ucywgdGhpcyBpcyBjb21wbGV0ZWx5IHVwIHRvIGNvbnRyaWJ1dG9ycy4gTm90ZSB0aGF0IHlv
dSBuZWVkIHRvIGhhdmUgYSBHaXRIdWIgYWNjb3VudCB0byBlZGl0IHRoZSB3aWtpLg0KDQoNCg0K
VGhhbmtzLA0KDQogICAgICAgICAgICAgICAgTGVpZiBhbmQgWWFyb24NCg0KDQoNClsxXSBodHRw
czovL2dpdGh1Yi5jb20vaWV0Zi13Zy1nbmFwL2dlbmVyYWwvd2lraS9JRVRGLUdOQVAtV29ya2lu
Zy1Hcm91cA0KDQoNCg0KW1NBSF0gSSBqdXN0IGFkZGVkIG9uZTogaHR0cHM6Ly9naXRodWIuY29t
L2lldGYtd2ctZ25hcC9nZW5lcmFsL3dpa2kvRmVkZXJhdGVkLUF1dGhlbnRpY2F0aW9uLWZvci1S
REFQDQoNCg==

--_000_ab0f7895d1e24eea98fd6ebba7d4e7beverisigncom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w
aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48
L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i
ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9
ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8
L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi
Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPiBUeGF1dGggJmx0O3R4YXV0aC1ib3VuY2VzQGlldGYub3JnJmd0
Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5ZYXJvbiBTaGVmZmVyPGJyPg0KPGI+U2VudDo8L2I+IFR1
ZXNkYXksIEp1bHkgMjgsIDIwMjAgNzoyNyBBTTxicj4NCjxiPlRvOjwvYj4gR05BUCBNYWlsaW5n
IExpc3QgJmx0O3R4YXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVS
TkFMXSBbVHhhdXRoXSBDb2xsZWN0aW5nIHVzZSBjYXNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpIGV2ZXJ5b25lLDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2V2ZXJhbCBwZW9wbGUgbWVu
dGlvbmVkIHRoYXQgd2Ugd291bGQgbGlrZSB0byBjb2xsZWN0IHVzZSBjYXNlcyBmb3IgdGhlIHBy
b3NwZWN0aXZlIEdOQVAgcHJvdG9jb2wuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij5XZSBoYXZlIHNldCB1cCBhIHdpa2kgWzFdIG9uIHRoZSB3b3JraW5nIGdyb3Vw
4oCZcyBHaXRIdWIgYXJlYSwgYW5kIHBlb3BsZSBhcmUgd2VsY29tZSB0byBlbnRlciB0aGVpciBm
YXZvcml0ZSB1c2UgY2FzZXMuIFdlIHdpbGwgbm90IGltcG9zZSBhbnkgZWRpdG9yaWFsIHN0YW5k
YXJkcyBvciBjb250ZW50IGNvbnZlbnRpb25zLCB0aGlzIGlzIGNvbXBsZXRlbHkNCiB1cCB0byBj
b250cmlidXRvcnMuIE5vdGUgdGhhdCB5b3UgbmVlZCB0byBoYXZlIGEgR2l0SHViIGFjY291bnQg
dG8gZWRpdCB0aGUgd2lraS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGVpZiBhbmQgWWFyb248bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv
bS9pZXRmLXdnLWduYXAvZ2VuZXJhbC93aWtpL0lFVEYtR05BUC1Xb3JraW5nLUdyb3VwIj4NCmh0
dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWduYXAvZ2VuZXJhbC93aWtpL0lFVEYtR05BUC1Xb3Jr
aW5nLUdyb3VwPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij5bU0FIXSBJIGp1c3QgYWRkZWQgb25lOiBodHRwczovL2dpdGh1
Yi5jb20vaWV0Zi13Zy1nbmFwL2dlbmVyYWwvd2lraS9GZWRlcmF0ZWQtQXV0aGVudGljYXRpb24t
Zm9yLVJEQVA8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_ab0f7895d1e24eea98fd6ebba7d4e7beverisigncom_--


From nobody Tue Jul 28 07:12: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 F2CA13A0CB2 for ; Tue, 28 Jul 2020 07:12:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level: 
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=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 0bOlcWaSeXAI for ; Tue, 28 Jul 2020 07:12:30 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EBB3A0CB1 for ; Tue, 28 Jul 2020 07:12:28 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d44 with ME id 8eCR230082bcEcA03eCS8w; Tue, 28 Jul 2020 16:12:26 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 28 Jul 2020 16:12:26 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt 
Cc: txauth@ietf.org
References:     <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>        <7b313658-f7f1-dad1-33aa-7d2107436856@free.fr> 
From: Denis 
Message-ID: <18b6aa1e-49bf-a7bc-c1a6-5f2b77355434@free.fr>
Date: Tue, 28 Jul 2020 16:12:23 +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="------------02875C1546CA560E6BB0B0A3"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 28 Jul 2020 14:12:34 -0000

This is a multi-part message in MIME format.
--------------02875C1546CA560E6BB0B0A3
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Dick,

I am puzzled by your response. Your are the editor and a co-editor of 
the two following RFCs which state:

RFC 6749:    In the traditional client-server authentication model, the 
client requests an access-restricted resource
                      (protected resource) on the server by 
authenticating with the server (...)

RFC 6750 : The client uses the access token to access the protected 
resources hosted by the resource server.

                     The following two steps are specified within this 
document:

                                (E)  The client requests the protected 
resource from the resource server and authenticates
                                        by presenting the access token.

                               (F)  The resource server validates the 
access token, and if valid, serves the request.

In my use case, the student connects to the University server (i.e. a 
RS) as a client. The University server cannot be a Client.
If you change/twist that basic vocabulary, we will not be able to 
understand each other any more.

BTW, my first question still remains: Would you explain how you would 
handle the use case of a student registering to a new University ?

Denis

> Hi Denis
>
> The student (User) goes to the registration page of the University 
> (the Client)
>
> Similar to your example, the Client has a list of GS that it are 
> acceptable, or RS that may be acceptable.
>
> If the User selects a GS, then the Client starts a GNAP flow with the GS.
>
> If the User selects an RS, then the Client can call the RS to 
> determine which GSes to offer the User to use to get access to the RS.
>
> In summary, the University wants to consume Claims about the User, so 
> it is the Client.
>
> /Dick
>
>
>
> On Mon, Jul 27, 2020 at 12:49 AM Denis  > wrote:
>
>     Hi Dick,
>
>     The floor is yours.
>
>     Would you explain how you would handle the use case of a student
>     registering to a new University ?
>
>     Would you also elaborate why in my explanations below, you think
>     that "the University's registration system is the Client, not a
>     Resource Server" ?
>
>     Denis
>
>>     Hi Denis
>>
>>     I would think in your example below, that the
>>     University's registration system is the Client, not a Resource
>>     Server.
>>
>>     Have a good night's sleep!
>>
>>
>>
>>     On Fri, Jul 24, 2020 at 12:04 PM Denis >     > wrote:
>>
>>         Hi Dick,
>>
>>         In order to send back a quick reply tonight, I will only
>>         respond to one of your questions:
>>
>>             [Denis] How would be the data flow when access tokens
>>             from two GSs are needed by a RS ?
>>
>>             [Dick] I don't know of a use case where two tokens would
>>             be needed by an RS. Would you elaborate?
>>
>>         I already described on the list the case of a student
>>         registering to a new University.
>>
>>         First, the student connects to the RS from the new University
>>         and opens an account
>>         (at this time the student is using a pseudo and a private key
>>         to authenticate). He fills some forms
>>         and indicate its citizenship, his home address and his
>>         graduation in his current university.
>>
>>         When he is finished, he indicates that he wants to perform a
>>         Registration operation.
>>
>>         From the information gathered in the forms, the RS informs
>>         the client that it needs two access tokens:
>>
>>           * one to demonstrate that his name and current home address
>>             are correct,and
>>           * another one to demonstrate that he got a graduation from
>>             its current University.
>>
>>         Depending upon the information captured in the forms, the RS
>>         also indicates which ASs/GSs are acceptable
>>         and which kind of attributes are requested.
>>
>>         The user consent and choice is performed by the client and
>>         once approved by the student, two access tokens are
>>         separately requested.
>>         Finally, two access tokens are presented to the RS while
>>         invoking a Registration operation.
>>
>>         Note that the start of the story is to open an account, e.g.
>>         using FIDO. The needs of the RS are only disclosed to the
>>         student once he has filled some forms
>>         and indicated that he wanted to perform a Registration
>>         operation. Thus, the needs that are revealed by the RS are
>>         dependant both upon the operation
>>         that the student is willing to perform and the information
>>         collected in the forms.
>>
>>         Denis
>>
>>>         Hi Denis, comments inserted ...
>>>
>>>         On Fri, Jul 24, 2020 at 9:08 AM Denis >>         > wrote:
>>>
>>>             Hi Dick,
>>>
>>>             draft-hardt-xauth-protocol-13 describes a solution
>>>             without clearly stating what the problem(s) to be solved
>>>             is/are.
>>>
>>>
>>>         I agree that the problem description is not as crisp as I
>>>         would like it to be. A challenge is that there is a broad
>>>         spectrum of use cases solved by OAuth 2, and OpenID Connect,
>>>         as well as the new use cases that are solved by GNAP.
>>>
>>>         That is why I am suggesting we gather some use cases so we
>>>         have a common understanding of the problems that are in scope.
>>>
>>>
>>>             At the moment, draft-hardt-xauth-protocol-13 includes a
>>>             single figure on page 4 and from previous discussions I
>>>             understood that
>>>             it is no more up-to-date since the first data flow is
>>>             now a contact with a RS. The reason(s) for the GS to
>>>             contact a RO has still not
>>>             been explained (since the inputs and outputs are not
>>>             described). The discovery information made available at
>>>             various steps at the RS
>>>             is not described.
>>>
>>>
>>>         I have made no updates as we are in a quiet period prior to
>>>         the WG meeting next week when documents cannot be updated.
>>>
>>>
>>>             Figure 4 shows only a single RS. Is the relaying of one
>>>             operation by that RS to a second RS in the scope of this
>>>             document ?
>>>             If yes, how is it handled ?
>>>
>>>
>>>         I view that as an advanced use case that would be covered in
>>>         a separate document.
>>>
>>>
>>>             Figure 4 shows only a single GS. How would be the data
>>>             flow when access tokens from two GSs are needed by a RS ?
>>>
>>>
>>>         I don't know of a use case where two tokens would be needed
>>>         by an RS. Would you elaborate?
>>>         The RS being able to accept tokens from two different GSes
>>>         is covered, but the Client is only using a token from one GS
>>>         at a time.
>>>
>>>
>>>             What we need first is not a set of "use cases" but a
>>>             clear model with a data flows and a list of its
>>>             properties/characteristics.
>>>
>>>
>>>         I disagree. The use cases describe the problems we are
>>>         looking to solve. The data flows are part of the solution.
>>>         For example, from my understanding of your use case, you
>>>         don't want the GS to have visibility into the User's
>>>         activity. Am I correct that this is one of your requirements
>>>         for your use case?
>>>
>>>             Then after, we can understand much better which use
>>>             cases can/will be supported. For example, shall a RS (or
>>>             its RO) have
>>>             prior relationships with the GS ? What is the
>>>             difference/implications when it has or it hasn't ?
>>>
>>>             In order to have a fair comparison, we should try to
>>>             list model properties/characteristics.
>>>
>>>             At the moment, the model I have described including the
>>>             data flows is clear. The discovery information made
>>>             available by a RS is clear.
>>>             I have not listed all its properties/characteristics of
>>>             that model, but I am pretty sure that you already have a
>>>             flavour of it.
>>>
>>>             In the mean time, it would be nice if you could show
>>>             using two figures:
>>>
>>>               * the case of the relaying of one operation by one RS
>>>                 to a second RS (if it is in the scope of your document),
>>>               * the case where access tokens from two GSs are needed
>>>                 by one RS (if it is in the scope of your document).
>>>
>>>
>>>         See above
>>>
>>>              *
>>>
>>>
>>>             Denis
>>>
>>>>             Hi Denis
>>>>
>>>>             I think it would be useful to take a step back and for
>>>>             you to describe your use case.
>>>>             After that, we can explore the different ways that your
>>>>             use case can be addressed.
>>>>
>>>>             Looking at your previous communication, it describes
>>>>             the solution, and the justification,
>>>>             but it is not clear what use cases you are needing to
>>>>             solve.
>>>>
>>>>             /Dick
>>>>
>>>>
>>>>             ᐧ
>>>>
>>>>             On Wed, Jul 22, 2020 at 9:34 AM Denis
>>>>             > wrote:
>>>>
>>>>                 Hello Dick,
>>>>
>>>>                 I have identified the reason of the major
>>>>                 difference between our two approaches.
>>>>
>>>>                 Access control may be performed using either ACLs
>>>>                 (Access Control Lists) or Capabilities.
>>>>
>>>>                 _Note _: a capability identifies a resource and an
>>>>                 allowed operation that can be performed on that
>>>>                 resource.
>>>>
>>>>                 You are advocating a Capabilities approach while I
>>>>                 am advocating an ACL approach.
>>>>
>>>>                 The capabilities approach allows the GS to trace
>>>>                 every operation performed by the users on any RS
>>>>                 known by a GS.
>>>>                 The management of these capabilities is made via
>>>>                 the GS or at the GS by the various ROs. If the
>>>>                 management is made
>>>>                 via the GS, then a trusted communication channel
>>>>                 needs to be established with every RO. If the
>>>>                 management is made
>>>>                 at the GS, then an authentication mechanism needs
>>>>                 to be established with every RO. In the last case,
>>>>                 the GS has the
>>>>                 ability to know all the capabilities of the users
>>>>                 whether they are used or not. The less that can be
>>>>                 said is that this model
>>>>                 is not privacy friendly.
>>>>
>>>>                 With the ACL approach, a RO directly manages an ACL
>>>>                 placed in front of each RS. The AccessControl
>>>>                 Decision Function
>>>>                 (ADF) at the RS is able to keep track from prior
>>>>                 decisions. The GS is kept ignorant of the content
>>>>                 of these ACLs and only
>>>>                 delivers to its clients attributes that are placed
>>>>                 into access tokens. Such a model may be privacy
>>>>                 friendly.
>>>>
>>>>                 Other comments are between the lines prefixed with
>>>>                 [Denis].
>>>>
>>>>>
>>>>>                 On Tue, Jul 21, 2020 at 11:26 AM Denis
>>>>>                 >
>>>>>                 wrote:
>>>>>
>>>>>                     Hello Dick,
>>>>>
>>>>>                     Thank you for your feedback. Comments are
>>>>>                     between the lines.
>>>>>
>>>>>>                     comments inserted ...
>>>>>>
>>>>>>                     On Tue, Jul 21, 2020 at 6:03 AM Denis
>>>>>>                     >>>>>                     > wrote:
>>>>>>
>>>>>>                         Hello Dick,
>>>>>>
>>>>>>                         I duplicate the most important comment at
>>>>>>                         the beginning of this email:
>>>>>>
>>>>>>                             You are considering using an access
>>>>>>                             control model to build a**workflow model.
>>>>>>                             **
>>>>>>                             While it may be interesting to define
>>>>>>                             a workflow model, this should be
>>>>>>                             considered
>>>>>>                             as a separate and different work item.
>>>>>>
>>>>>>                         See the other comments between the lines.
>>>>>>
>>>>>>>                         On Mon, Jul 20, 2020 at 2:05 AM Denis
>>>>>>>                         >>>>>>                         > wrote:
>>>>>>>
>>>>>>>                             Hi Dick,
>>>>>>>
>>>>>>>>                             On Fri, Jul 17, 2020 at 9:21 AM
>>>>>>>>                             Denis >>>>>>>                             > wrote:
>>>>>>>>
>>>>>>>>                                 Hello Francis and Dick,
>>>>>>>>
>>>>>>>>                                 The good news first: we are
>>>>>>>>                                 making some progress. We are
>>>>>>>>                                 now close to an agreement with
>>>>>>>>                                 steps (1) up to (3),
>>>>>>>>                                 ... except that the place where
>>>>>>>>                                 the user consent is captured is
>>>>>>>>                                 not mentioned/indicated.
>>>>>>>>
>>>>>>>
>>>>>>>                             This major question which is
>>>>>>>                             currently left unanswered is where,
>>>>>>>                             when and how the user consent is
>>>>>>>                             captured.
>>>>>>>
>>>>>>>
>>>>>>>                         When is covered, per the sequence. How
>>>>>>>                         and where are out of scope of what I
>>>>>>>                         drafted.
>>>>>>
>>>>>>                         It is clear that the "User consent and
>>>>>>                         choice" is not currently addressed in the
>>>>>>                         draft, but it should.
>>>>>>                         The support of the "User consent and
>>>>>>                         choice" has strong implications not only
>>>>>>                         in the sequences of the exchanges
>>>>>>                         but also by which entity it should be
>>>>>>                         performed.
>>>>>>
>>>>>>                     "consent" is in the latest draft 7 times.
>>>>>
>>>>>                     "Consent" is present 5 times. The User consent
>>>>>                     is different from the RO consent (when/if it
>>>>>                     is required).
>>>>>
>>>>>                         The server acquires consent and
>>>>>                         authorization from the user *and/**or
>>>>>                         resource owner **if required.*
>>>>>
>>>>>                         User consent is *often required* at the
>>>>>                         GS. GNAP enables a Client and  GS to
>>>>>                         negotiate the interaction mode for the GS
>>>>>                         to obtain consent.
>>>>>
>>>>>                         The GS *may *require explicit consent from
>>>>>                         the RO or User to provide these to the Client.
>>>>>
>>>>>                     The User consent is not an alternative to the
>>>>>                     RO consent. So using "and/or" in the first
>>>>>                     sentence is incorrect.
>>>>>
>>>>>
>>>>>                 My language is sloppy there. Consent is always
>>>>>                 from the RO. The User may be the RO.
>>>>
>>>>                 [Denis] No. Once again: The "/User consent/" is
>>>>                 different from what you call the "/RO consent/"
>>>>                 (when/if it is required).
>>>>                 The "RO consent" is not in fact a consent but the
>>>>                 release of a capability to a client by one of the
>>>>                 many R0s with which
>>>>                 the GS has relationships.
>>>>
>>>>>                     Since the second sentence is using the wording
>>>>>                     "often required" there is no requirement to
>>>>>                     get the User consent.
>>>>>
>>>>>                 User consent may not be required. There may not be
>>>>>                 a User. The consent may have been gathered previously.
>>>>
>>>>                 [Denis] In order to follow the privacy principles,
>>>>                 a "User consent" phase is required. The User is a
>>>>                 natural person.
>>>>                 A Client is called either by a User (i.e. a natural
>>>>                 person) or by a Client application.
>>>>
>>>>>                     The second sentence does not consider the
>>>>>                     possibility to get the User consent in a place
>>>>>                     different from the GS.
>>>>>
>>>>>                 Agreed. But we do agree that the GS gets the
>>>>>                 consent, either directly from the RO, or from the
>>>>>                 Client (in your example).
>>>>
>>>>                 [Denis] No. I disagree. In an ACL based systems,
>>>>                 the GS does not need to ask or receive any consent.
>>>>                 The client selects the set of attributes that it
>>>>                 wants to be inserted into an access token.
>>>>                 If the GS has the requested attributes, then it
>>>>                 provides them, otherwise it returns an error to the
>>>>                 Client.
>>>>
>>>>>                     IMO, the User consent should be captured by
>>>>>                     the Client, i.e. not by the GS.
>>>>>                     The information used to obtain the User
>>>>>                     consent should be standardized (... and it can
>>>>>                     be standardized).
>>>>>
>>>>>>                     I think the abstract sequence as proposed by
>>>>>>                     Francis is a great addition, and would
>>>>>>                     clarify where consent is in the sequence.
>>>>>
>>>>>                     The current sketch does not illustrate the
>>>>>                     place the User Consent is captured, in
>>>>>                     particular by the Client.
>>>>>
>>>>>                 It is an abstraction. The GS receives the consent.
>>>>>                 How consent is gathered is a detail that is
>>>>>                 dependent on the use case.
>>>>
>>>>                 [Denis] I really wonder whether there is really a
>>>>                 "consent" to be received by the GS in both cases
>>>>                 (i.e. ACLs or Capabilities).
>>>>
>>>>                   * For ACLs, the consent needs to be done by the
>>>>                     Client.
>>>>                   * For Capabilities, the current description is
>>>>                     not clear since the inputs and the outputs for
>>>>                     this "consent" phase
>>>>                     are not currently described in the draft.
>>>>
>>>>>>>                             Another important point to consider
>>>>>>>                             and to explain is related to the
>>>>>>>                             assurances that the user can obtain
>>>>>>>                             about
>>>>>>>                             the respect of his choices. This
>>>>>>>                             point is currently left unanswered
>>>>>>>                             in draft-hardt-xauth-protocol-13.
>>>>>>>
>>>>>>                         This point is equally important: such
>>>>>>                         assurance can only be obtained if the
>>>>>>                         access token returned to the client
>>>>>>                         is not considered to be opaque to the
>>>>>>                         client. This is a necessary condition but
>>>>>>                         not the single condition:
>>>>>>                         the Client must also be in a position to
>>>>>>                         capture/memorize the "User consent and
>>>>>>                         choice" of the user in order to be able
>>>>>>                         to verify it afterwards using the content
>>>>>>                         of the access token(s).
>>>>>>
>>>>>>
>>>>>>                     We disagree on this being a requirement for
>>>>>>                     all use cases. It may be in some.
>>>>>
>>>>>                     OK. Then this means that there will be no
>>>>>                     sentence in the draft such as :
>>>>>                     "access tokens returned to the client are not
>>>>>                     considered to be opaque to the client".
>>>>>
>>>>>
>>>>>                 For OAuth use cases, which GNAP supports, the
>>>>>                 access token is opaque to the Client. As you have
>>>>>                 noted, there are use cases where the access token
>>>>>                 is NOT opaque.
>>>>
>>>>                 [Denis] Wait a second. There is no requirement to
>>>>                 support all OAuth use cases.
>>>>                 I believe that there is a requirement to support
>>>>                 OAuth 2.0 ASs, while the clients may be different
>>>>                 and hence GNAP clients do not need to inherit of
>>>>                 the limitations of OAuth 2.0 clients.
>>>>
>>>>>>>
>>>>>>>>                                 If a RO needs to be involved
>>>>>>>>                                 and since a RO is directly
>>>>>>>>                                 associated with a RS, why can't
>>>>>>>>                                 it be directly queried
>>>>>>>>                                 by the appropriate RS after
>>>>>>>>                                 step (2) or later on ?
>>>>>>>>
>>>>>>>>
>>>>>>>>                             Good question. Perhaps you can
>>>>>>>>                             expand on a use case where that
>>>>>>>>                             would be useful?
>>>>>>>
>>>>>>>                             Before I expand, would you be able
>>>>>>>                             to explain first under which
>>>>>>>                             circumstances a RO needs to be
>>>>>>>                             queried by a GS ?
>>>>>>>                             How can the GS identify which RO to
>>>>>>>                             query ?
>>>>>>>
>>>>>>>                         If the User is the RO, then the GS knows
>>>>>>>                         who to query.
>>>>>>
>>>>>>                         I still have difficulties to understand
>>>>>>                         what you mean here.
>>>>>>                         How could a GS know that "the User is the
>>>>>>                         RO" ?  If "the User is the RO", why does
>>>>>>                         the GS needs to query the User ?
>>>>>>
>>>>>>
>>>>>>                     To get consent?
>>>>>
>>>>>                     To get a "RO consent" to himself ???
>>>>>
>>>>>
>>>>>                 The GS needs consent from the RO. If the RO is the
>>>>>                 User, then consent from the RO is equivalent to
>>>>>                 consent from the User.
>>>>
>>>>                 [Denis] See above.
>>>>
>>>>>
>>>>>>>                         If the RO is a separate entity, then the
>>>>>>>                         GS knows the RO from the RS being queried.
>>>>>>
>>>>>>                          ... and this gives the ability for the
>>>>>>                         GS to log/trace all the RSs accessed by a
>>>>>>                         given User and at which instant of time
>>>>>>                         the access token has been granted.
>>>>>>
>>>>>>>                         An example is a user would like access
>>>>>>>                         to an enterprise asset where a workflow
>>>>>>>                         is started to gain approval, and an
>>>>>>>                         administrator or manager provides consent.
>>>>>>
>>>>>>                         Thanks for this example. I finally
>>>>>>                         understand what you have in mind: you are
>>>>>>                         considering using an access control model
>>>>>>                         to build a *workflow model*.
>>>>>>                         While it may be interesting to define a
>>>>>>                         workflow model, this should be considered
>>>>>>                         as a *separate and different work item*.
>>>>>>
>>>>>>
>>>>>>                     The actual workflow is out of scope.
>>>>>
>>>>>                     I am glad you agree with this. But this means
>>>>>                     that your example was not appropriate to
>>>>>                     illustrate your point.
>>>>>
>>>>>
>>>>>                 It illustrates a use case where the RO and User
>>>>>                 are not the same party, and why the GS needs to
>>>>>                 query the RO, which was your question if I
>>>>>                 understood it correctly.
>>>>
>>>>                 [Denis] Since the inputs and the outputs for this
>>>>                 "RO consent" phase are not currently described in
>>>>                 the draft, the point is still unsolved.
>>>>
>>>>>                     As soon as there is a RO consent obtained at
>>>>>                     the GS, the major problem is that the GS is
>>>>>                     able to act as Big Brother.
>>>>>                     If a RO consent is performed at the RS, then
>>>>>                     the GS will not know who the RS is: it is then
>>>>>                     unable to act as Big Brother,
>>>>>                     even if it would enjoy to play that role.
>>>>>
>>>>>                 In an enterprise use case, the GS's knowledge of
>>>>>                 who is accessing which RS is a feature.
>>>>
>>>>                 Do you mean that it is "normal" in an enterprise
>>>>                 that a single point of control is able to trace all
>>>>                 their actions ?
>>>>                 From a security point of view, a single point of
>>>>                 failure will have dramatic consequences.
>>>>
>>>>>                 In your use cases, it seems that the RO is the User.
>>>>
>>>>                 I do hope that you have finally understood that, in
>>>>                 my use case, the RO is **not** the User.
>>>>
>>>>>                 The GS knows the User is wanting to let a Client
>>>>>                 access something. If the access token is generic,
>>>>>                 and could be presented to any RS that provides a
>>>>>                 standardized function,
>>>>>                 then the GS does not know which RS is being
>>>>>                 accessed by a Client for the User. This seems to
>>>>>                 meet your privacy objectives. If not, what is wrong?
>>>>
>>>>                 For security reasons, an access token needs to be
>>>>                 targeted (which does not necessarily mean that an
>>>>                 identifier of the RS shall be included into the
>>>>                 access token).
>>>>
>>>>>>                     if the admin grants access, then the access
>>>>>>                     granted to the client changes.
>>>>>>
>>>>>>                         The model you propose may be suited for
>>>>>>                         an enterprise environment but is not
>>>>>>                         scalable over the Internet.
>>>>>>
>>>>>>                     It is one of the use cases we are working to
>>>>>>                     address.
>>>>>>
>>>>>>                         What is needed is an access control model
>>>>>>                         usable over the Internet with millions of
>>>>>>                         RSs and thousands of ASs/GSs.
>>>>>>
>>>>>>                     I agree the model should also scale to
>>>>>>                     internet scale.
>>>>>
>>>>>                     Fine. Another point on which we are in agreement.
>>>>>
>>>>>                     The model can scale to the Internet based on
>>>>>                     the following assumptions:
>>>>>
>>>>>                         The flow starts with the steps (1) to (4)
>>>>>                         as illustrated by Francis, i.e. the flow
>>>>>                         starts with a contact with a RS.
>>>>>
>>>>>                     *+----+  +------+  +---+  +---+  +---+
>>>>>                     |User|  |Client|  |RS |  |GS |  |RO |
>>>>>                     +----+  +------+  +---+  +-+-+  +-+-+
>>>>>                       |(1) Service Request     |      |
>>>>>                     |-------->|       |      |      |
>>>>>                       | |(2) Service Intent   |
>>>>>                       | |------>|    |      |
>>>>>                       | |(3) AuthZ Challenge  |
>>>>>                       | |<------|    |      |
>>>>>                       | |(4) AuthZ Request    |
>>>>>                       | |------------->|      |*
>>>>>
>>>>>                     The GS/AS does not need to have any prior
>>>>>                     relationship with ROs and/or RSs.
>>>>>
>>>>>                     Furthermore, it is possible to prevent the GS
>>>>>                     to act as Big Brother when the identity of the
>>>>>                     RS is not disclosed to the GS.
>>>>>
>>>>>
>>>>>                 What happens after (4) above?
>>>>
>>>>                 [Denis] The key point is that we first need to
>>>>                 agree on the first four exchanges. Do we ?
>>>>
>>>>                 The fifth exchange is different whether ACLs or
>>>>                 Capabilities are being used.
>>>>
>>>>>>>>                                 Which information is supposed
>>>>>>>>                                 to be presented to the RO ?
>>>>>>>>                                 Which information is supposed
>>>>>>>>                                 to be returned by the RO ?
>>>>>>>>
>>>>>>>>
>>>>>>>>                             Just like how the user
>>>>>>>>                             authenticates to an AS, how the AS
>>>>>>>>                             and RO communicate is out of scope.
>>>>>>>
>>>>>>>                             At the moment, the usefulness of a
>>>>>>>                             dialogue between a GS and a RO has
>>>>>>>                             not been explained, nor demonstrated.
>>>>>>>                             The question is about the
>>>>>>>                             functionality of that dialogue in
>>>>>>>                             terms of input and output
>>>>>>>                             information (and not about
>>>>>>>                             the design of a protocol or of a
>>>>>>>                             user interface). Anyway, AFAIU a
>>>>>>>                             dialogue between a GS and a RO is
>>>>>>>                             optional.
>>>>>>>
>>>>>>>
>>>>>>>                         See enterprise example above.
>>>>>>
>>>>>>                         It is not an access control example, but
>>>>>>                         a workflow example.
>>>>>>
>>>>>>                         Access control has been defined a long
>>>>>>                         time ago and the last edition of the
>>>>>>                         model has been confirmed in year 1996:
>>>>>>                         ISO/IEC 10181-3: 1996.
>>>>>>                         "Information technology — Open Systems
>>>>>>                         Interconnection — Security frameworks for
>>>>>>                         open systems: Access control framework —
>>>>>>                         Part 3".
>>>>>>
>>>>>>                         Two major functions have ben defined: an
>>>>>>                         AccessControl Enforcement Function (AEF)
>>>>>>                         and an AccessControl Decision Function(ADF).
>>>>>>
>>>>>>                             AccessControl Enforcement Function (AEF):
>>>>>>                             A specialized function that is part
>>>>>>                             of the access path between an
>>>>>>                             initiator and a target on each access
>>>>>>                             request and enforces the decision
>>>>>>                             made by the ADF.
>>>>>>
>>>>>>                             AccessControl Decision Function (ADF) :
>>>>>>                             A specialized function that makes
>>>>>>                             access control decisions by applying
>>>>>>                             access control policy rules to an
>>>>>>                             access request, ADI (of initiators,
>>>>>>                             targets, access requests,
>>>>>>                             or that retained from prior
>>>>>>                             decisions), and the context in which
>>>>>>                             the access request is made.
>>>>>>
>>>>>>                         The role of the RO is to define the
>>>>>>                         "access control policy rules" at the RS
>>>>>>                         according to thecontext in which the
>>>>>>                         access request is made.
>>>>>>
>>>>>>                     I'm pretty familiar with access control
>>>>>>                     systems. :)
>>>>>>
>>>>>>                     I would say that the access control is
>>>>>>                     happening at the RS. The client presents a
>>>>>>                     token when accessing an API.
>>>>>>                     The RS uses the token, and any policy
>>>>>>                     required, to make an access decision.
>>>>>
>>>>>                     Fine. It looks like we are in agreement.
>>>>>                     Unfortunately, this is not the case just below.
>>>>>
>>>>>>                     Here is flow:
>>>>>>
>>>>>>                     1) The Client requests access to an RS from
>>>>>>                     the GS.
>>>>>
>>>>>                     No. We are no more in agreement. This is
>>>>>                     different from the flow drawn by Francis.
>>>>>
>>>>>                 My bad. Typo. I meant RO.
>>>>>
>>>>>>                     2) The GS queries the RS if access should be
>>>>>>                     granted.
>>>>>
>>>>>                      No. The GS should not be forced to have a
>>>>>                     flow with the RS.
>>>>>
>>>>>                 Same mistake as above, I meant RO.
>>>>>
>>>>>>                     3) If access is granted, the GS creates an
>>>>>>                     access token representing the granted access,
>>>>>>                     and returns it to the Client.
>>>>>
>>>>>                     This model is by no way conformant to
>>>>>                     ISO/IEC 10181-3: 1996
>>>>>
>>>>>                 I'm unclear on why, or why it is even relevant.
>>>>>
>>>>>>                     4) The Client presents the access token to
>>>>>>                     the RS to show it has been granted access.
>>>>>
>>>>>                     No. The client presents a token when accessing
>>>>>                     an API. The RS uses the token, and any policy
>>>>>                     required, to make an access decision.
>>>>>                     The token never contains an information like
>>>>>                     "Please grant an access to the holder of this
>>>>>                     token".
>>>>>
>>>>>                 Let me provide more clarity in the sentence:
>>>>>
>>>>>                 The Client presents the access token to the RS, to
>>>>>                 show the RS that the Client has been granted
>>>>>                 access to a resource at the RS by the GS.
>>>>
>>>>                 [Denis] This time, please consider both the ACLs
>>>>                 approach and the Capabilities approach.
>>>>
>>>>>>                     A couple advantages of this model:
>>>>>>                     - that the RS does not need to know much, if
>>>>>>                     anything about the Client.
>>>>>>                     - the access token MAY be self contained so
>>>>>>                     that the Client does not need to query the GS
>>>>>>                     on each access.
>>>>>
>>>>>                     There are so many disadvantages that I will
>>>>>                     not list them.
>>>>>
>>>>>                 Darn: I clearly was not firing on all cylinders
>>>>>                 when I typed this out. Let me correct:
>>>>>
>>>>>>                 - the access token MAY be self contained so that
>>>>>>                 the RS does not need to query the GS on each
>>>>>>                 access to the RS by the Client.
>>>>
>>>>                 [Denis] A few comments in the case of a capability
>>>>                 approach:
>>>>
>>>>                     - for each GS, the RS needs to locally manage
>>>>                     which operation(s) is/are allowed to it.
>>>>
>>>>                     - the GS needs to establish a trusted
>>>>                     communication channel or an authentication
>>>>                     mechanism with each RO
>>>>                        (which is associated with an explicit RS
>>>>                     identifier).
>>>>
>>>>                     - the GS could play the role of the RO and
>>>>                     hence be in a position to issue any capability
>>>>                     for any RS (without a "RO consent").
>>>>
>>>>                        The target of an attack will clearly be the GS.
>>>>
>>>>>>                     I would not say that GNAP is an access
>>>>>>                     control protocol, as how the RS uses the
>>>>>>                     token to determine access is out of scope.
>>>>>
>>>>>                     This is where we have a major discrepancy: how
>>>>>                     the RS uses the token to determine access is
>>>>>                     *within* the scope.
>>>>>
>>>>                 [Denis] Do you agree or disagree ?
>>>>>
>>>>>                     The RS announces in advance to the client what
>>>>>                     it needs so that the client can perform a a
>>>>>                     given operation and if the client supplies the
>>>>>                     requested attributes
>>>>>                     obtained from some GS/AS(s) trusted by the RS,
>>>>>                     then access to that RS is granted by the RS.
>>>>>                     If the RS cannot perform the requested
>>>>>                     operation on its own,
>>>>>                     then the client should be informed about some
>>>>>                     requested attributes that need to be obtained
>>>>>                     from some GS/AS(s) trusted by the next RS(s)
>>>>>                     in a chain
>>>>>                     for subsequent operations. The User consent
>>>>>                     should also be obtained before performing the
>>>>>                     chaining operation.
>>>>>
>>>>>                     Chaining operations between RSs over the
>>>>>                     Internet is within the scope (... and may be
>>>>>                     achieved).
>>>>>
>>>>                 [Denis] Do you agree or disagree ?
>>>>
>>>>                 Denis
>>>>
>>>>>>>>                             For many use cases, the User is the
>>>>>>>>                             RO, and the interaction is through
>>>>>>>>                             a user interface, not a machine
>>>>>>>>                             protocol.
>>>>>>>
>>>>>>>                             Wait a second. You wrote "the User
>>>>>>>                             is the RO". The User is attempting
>>>>>>>                             to make an access to a RS by using a
>>>>>>>                             Client.
>>>>>>>                             _That_ User is not the RO of the RS.
>>>>>>>
>>>>>>>                         The user being the RO is the initial use
>>>>>>>                         case for OAuth.
>>>>>>
>>>>>>                         OAuth 2.0 is no more mandating such a case.
>>>>>>
>>>>>>
>>>>>>                     I don't know what you mean by that.
>>>>>
>>>>>                     Copy and paste from
>>>>>                     draft-ietf-oauth-security-topics:
>>>>>
>>>>>                         OAuth initially assumed a static
>>>>>                         relationship between client, authorization
>>>>>                         server and resource servers. (...)
>>>>>                         With the increasing adoption of OAuth,
>>>>>                         this simple model dissolved and, in
>>>>>                         several scenarios, was replaced
>>>>>                         by a dynamic establishment of the
>>>>>                         relationship between clients on one side
>>>>>                         and the authorization and
>>>>>                         resource servers of a particular
>>>>>                         deployment on the other side.
>>>>>
>>>>>                         This way, the same client could be used to
>>>>>                         access services of different providers (in
>>>>>                         case of standard APIs,
>>>>>                         such as e-mail or OpenID Connect) or serve
>>>>>                         as a frontend to a particular tenant in a
>>>>>                         multi-tenancy environment.
>>>>>
>>>>>
>>>>>                 This sentence does not mention the RO or the
>>>>>                 Client. I'm confused what we are talking about
>>>>>
>>>>>>>                         A client application would like access
>>>>>>>                         to the user's photos at a photo sharing
>>>>>>>                         site. The resource is the user's photos.
>>>>>>>                         The user is the owner of that resource.
>>>>>>
>>>>>>                         If the user has already pre established
>>>>>>                         the access control policy rules so that
>>>>>>                         it can access to his own photos
>>>>>>                         then he does not need to grant in real
>>>>>>                         time any additional authorization.
>>>>>>
>>>>>>                     I don't understand what you are trying to
>>>>>>                     say. The photo sharing example was a driving
>>>>>>                     use case for the creation of OAuth.
>>>>>
>>>>>                     We would need to revisit the original scenario
>>>>>                     and consider if it can be addressed in a
>>>>>                     different way than the original way.
>>>>>
>>>>>                 The use case is the same. Is there a different
>>>>>                 solution you are proposing?
>>>>
>>>>
>>>>                 -- 
>>>>                 Txauth mailing 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
>


--------------02875C1546CA560E6BB0B0A3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Dick,

    


    

    
I am puzzled by your response. Your are
      the editor and a co-editor of the two following RFCs which state:

    


    

    
RFC 6749:    In the traditional
      client-server authentication model, the client requests an
      access-restricted resource 

                           (protected resource) on the server by
      authenticating with the server (...) 

      

      RFC 6750 : The client uses the access token to access the
      protected resources hosted by the resource server. 

      

                          The following two steps are specified within
      this document:

      

                                     (E)  The client requests the
      protected resource from the resource server and authenticates 

                                             by presenting the access
      token.

      

                                    (F)  The resource server validates
      the access token, and if valid, serves the request.

    

    


    

    
In my use case, the student connects to
      the University server (i.e. a RS) as a client. The University
      server cannot be a Client.

      If you change/twist that basic vocabulary, we will not be able to
      understand each other any more.

    


    

    
BTW, my first question still remains:
      Would you explain how you would handle the use case of a student
      registering to a new University ?

    


    

    
Denis

    
  

    

    

      
      
Hi Denis
        


        

        
The student (User) goes to the registration page of the
          University (the Client)

        


        

        
Similar to your example, the Client has a list of GS that
          it are acceptable, or RS that may be acceptable.

        


        

        
If the User selects a GS, then the Client starts a GNAP
          flow with the GS.

        


        

        
If the User selects an RS, then the Client can call the RS
          to determine which GSes to offer the User to use to get access
          to the RS.

        


        

        
In summary, the University wants to consume Claims about
          the User, so it is the Client.

          


          

          
/Dick

          


          

          


          

          

          

            
On Mon, Jul 27, 2020 at
              12:49 AM Denis <denis.ietf@free.fr>
              wrote:

            

            

              

                
Hi Dick,

                


                

                
The floor is yours.

                


                

                
Would you explain how you would handle the use case
                  of a student registering to a new University ?

                


                

                
Would you also elaborate why in my explanations
                  below, you think that "the University's registration
                  system is the Client, not a Resource Server" ?
                  


                  

                

                
Denis

                

                

                

                  
Hi Denis
                    


                    

                    
I would think in your example below, that the
                      University's registration system is the Client,
                      not a Resource Server.

                    


                    

                    
Have a good night's sleep!

                    


                    

                    


                    

                  

                  

                  

                    
On Fri, Jul 24,
                      2020 at 12:04 PM Denis <denis.ietf@free.fr>
                      wrote:

                    

                    

                      

                        
Hi Dick,

                          

                        

                        
In order to send back a quick reply
                          tonight, I will only respond to one of your
                          questions:

                        

                          
 [Denis] How would be the data
                            flow when access tokens from two GSs are
                            needed by a RS ?

                            


                            

                            
[Dick] I don't know of a use case where
                              two tokens would be needed by an RS. Would
                              you elaborate?

                          

                          
I already described on the list the case
                            of a student registering to a new
                            University.

                          
 

                          

                          
First, the student connects to the RS
                            from the new University and opens an account
                            

                            (at this time the student is using a pseudo
                            and a private key to authenticate). He fills
                            some forms 

                            and indicate its citizenship, his home
                            address and his graduation in his current
                            university. 

                            

                            When he is finished, he indicates that he
                            wants to perform a Registration operation.

                          


                          

                          
From the information gathered in the
                            forms, the RS informs the client that it
                            needs two access tokens:

                          
    
                            
  • one to demonstrate that his name and
                              current home address are correct,and
    • 
                            
  • another one to demonstrate that he got a
                              graduation from its current University.
    • 
                          

                          
Depending upon the information captured
                            in the forms, the RS also indicates which
                            ASs/GSs are acceptable 

                            and which kind of attributes are requested.

                          
 

                          

                          
The user consent and choice is performed
                            by the client and once approved by the
                            student, two access tokens are separately
                            requested.

                            Finally, two access tokens are presented to
                            the RS while invoking a Registration
                            operation.

                          


                          

                          
Note that the start of the story is to
                            open an account, e.g. using FIDO. The needs
                            of the RS are only disclosed to the student
                            once he has filled some forms 

                            and indicated that he wanted to perform a
                            Registration operation. Thus, the needs that
                            are revealed by the RS are dependant both
                            upon the operation 

                            that the student is willing to perform and
                            the information collected in the forms.

                          


                          

                          
Denis

                        

                        

                        

                          

                            
Hi Denis, comments inserted ... 

                            

                            

                              
On Fri,
                                Jul 24, 2020 at 9:08 AM Denis <denis.ietf@free.fr>
                                wrote:

                              

                              

                                

                                  

                                    
Hi Dick,

                                    


                                    

                                    
draft-hardt-xauth-protocol-13
                                      describes a solution without
                                      clearly stating what the
                                      problem(s) to be solved is/are.

                                  

                                

                              

                              


                              

                              
I agree that the problem description
                                is not as crisp as I would like it to
                                be. A challenge is that there is a broad
                                spectrum of use cases solved by OAuth 2,
                                and OpenID Connect, as well as the new
                                use cases that are solved by GNAP.

                              


                              

                              
That is why I am suggesting we gather
                                some use cases so we have a common
                                understanding of the problems that are
                                in scope.

                              
 

                              

                                

                                  

                                    


                                    

                                    
At the moment,
                                      draft-hardt-xauth-protocol-13
                                      includes a single figure on page 4
                                      and from previous discussions I
                                      understood that 

                                      it is no more up-to-date since the
                                      first data flow is now a contact
                                      with a RS. The reason(s) for the
                                      GS to contact a RO has still not 

                                      been explained (since the inputs
                                      and outputs are not described).
                                      The discovery information made
                                      available at various steps at the
                                      RS 

                                      is not described.

                                    

                                  

                                

                              

                              


                              

                              
I have made no updates as we are in a
                                quiet period prior to the WG meeting
                                next week when documents cannot be
                                updated.

                              
 

                              

                                

                                  

                                    

                                      


                                      

                                    

                                    
Figure 4 shows only a single
                                      RS. Is the relaying of one
                                      operation by that RS to a second
                                      RS in the scope of this document ?

                                      If yes, how is it handled ?

                                    

                                  

                                

                              

                              


                              

                              
I view that as an advanced use case
                                that would be covered in a separate
                                document.

                              
 

                              

                                

                                  

                                    
 

                                    


                                    

                                    
Figure 4 shows only a single
                                      GS. How would be the data flow
                                      when access tokens from two GSs
                                      are needed by a RS ?

                                    

                                  

                                

                              

                              


                              

                              
I don't know of a use case where two
                                tokens would be needed by an RS. Would
                                you elaborate?

                              
The RS being able to accept tokens
                                from two different GSes is covered, but
                                the Client is only using a token from
                                one GS at a time.

                              


                              

                              
 

                              

                                

                                  

                                    
 

                                    

                                    What we need first is not a set of
                                    "use cases" but a clear model with a
                                    data flows and a list of its
                                    properties/characteristics. 

                                  

                                

                              

                              


                              

                              
I disagree. The use cases describe
                                the problems we are looking to solve.
                                The data flows are part of the solution.
                                For example, from my understanding of
                                your use case, you don't want the GS to
                                have visibility into the User's
                                activity. Am I correct that this is one
                                of your requirements for your use case?

                              


                              

                              
 

                              

                                

                                  
 

                                  
Then after, we can understand
                                    much better which use cases can/will
                                    be supported. For example, shall a
                                    RS (or its RO) have 

                                    prior relationships with the GS ?
                                    What is the difference/implications
                                    when it has or it hasn't ?

                                  

                                  


                                  

                                  
In order to have a fair
                                    comparison, we should try to list
                                    model properties/characteristics.

                                  


                                  

                                  
At the moment, the model I have
                                    described including the data flows
                                    is clear. The discovery information
                                    made available by a RS is clear.

                                  
I have not listed all its
                                    properties/characteristics of that
                                    model, but I am pretty sure that you
                                    already have a flavour of it.

                                  


                                  

                                  
In the mean time, it would be
                                    nice if you could show using two
                                    figures:

                                  
    
                                    
  • the case of the relaying of one
                                      operation by one RS to a second RS
                                      (if it is in the scope of your
                                      document),
    • 
                                    
  • the case where access tokens
                                      from two GSs are needed by one RS
                                      (if it is in the scope of your
                                      document).
    
                                    
    • 
                                  

                                

                              

                              


                              

                              
See above

                              
 

                              

                                

                                  
    
                                    
  •  
    
                                    
    • 
                                  

                                  

                                    
Denis

                                  

                                  


                                  

                                  

                                    
Hi Denis
                                      


                                      

                                      
I think it would be useful to
                                        take a step back and for you to
                                        describe your use case. 

                                        After that, we can explore the
                                        different ways that your use
                                        case can be addressed. 

                                      


                                      

                                      
Looking at your previous
                                        communication, it describes the
                                        solution, and the justification,
                                        

                                        but it is not clear what use
                                        cases you are needing to solve.

                                      


                                      

                                      
/Dick

                                      


                                      

                                      


                                      

                                    

                                    
ᐧ

                                    

                                    

                                      
On
                                        Wed, Jul 22, 2020 at 9:34 AM
                                        Denis <denis.ietf@free.fr>
                                        wrote:

                                      

                                      

                                        

                                          
Hello Dick,

                                          


                                          

                                          
I have identified the
                                            reason of the major
                                            difference between our two
                                            approaches.

                                          


                                          

                                          
Access control may be
                                            performed using either ACLs
                                            (Access Control Lists) or
                                            Capabilities.

                                          


                                          

                                          
Note : a
                                            capability identifies a
                                            resource and an allowed
                                            operation that can be
                                            performed on that resource.

                                          

                                          


                                          

                                          
You are advocating a
                                            Capabilities approach while
                                            I am advocating an ACL
                                            approach.

                                          
The capabilities approach
                                            allows the GS to trace every
                                            operation performed by the
                                            users on any RS known by a
                                            GS.

                                            The management of these
                                            capabilities is made via the
                                            GS or at the GS by the
                                            various ROs. If the
                                            management is made 

                                            via the GS, then a trusted
                                            communication channel needs
                                            to be established with every
                                            RO. If the management is
                                            made 

                                            at the GS, then an
                                            authentication mechanism
                                            needs to be established with
                                            every RO. In the last case,
                                            the GS has the 

                                            ability to know all the
                                            capabilities of the users
                                            whether they are used or
                                            not. The less that can be
                                            said is that this model 

                                            is not privacy friendly.

                                          
With the ACL approach, a RO
                                            directly manages an ACL
                                            placed in front of each RS.
                                            The Access Control Decision
                                              Function 

                                                (ADF)
                                              at the RS is able to keep
                                              track from prior
                                              decisions. The GS
                                            is kept ignorant of the
                                            content of these ACLs and
                                            only 

                                            delivers to its clients
                                            attributes that are placed
                                            into access tokens. Such a
                                            model may be privacy
                                            friendly.

                                          
Other comments are between
                                            the lines prefixed with
                                            [Denis].

                                          

                                            

                                              


                                                

                                                  
On
                                                    Tue, Jul 21, 2020 at
                                                    11:26 AM Denis <denis.ietf@free.fr>
                                                    wrote:

                                                  

                                                  

                                                    

                                                      
Hello Dick,

                                                      


                                                      

                                                      
 Thank you
                                                        for your
                                                        feedback.
                                                        Comments are
                                                        between the
                                                        lines.

                                                      


                                                      

                                                      

                                                        

                                                          
comments
                                                          inserted ... 

                                                          

                                                          

                                                          
On Tue, Jul 21, 2020 at 6:03 AM Denis <denis.ietf@free.fr> wrote:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Dick,

                                                          


                                                          

                                                          
I
                                                          duplicate the
                                                          most important
                                                          comment at the
                                                          beginning of
                                                          this email:

                                                          

                                                          
You are
                                                          considering
                                                          using an
                                                          access control
                                                          model to build
                                                          a workflow
                                                          model.

                                                           

                                                          While it may
                                                          be interesting
                                                          to define a
                                                          workflow
                                                          model, this
                                                          should be
                                                          considered 

                                                          as a separate
                                                          and different
                                                          work item.

                                                          

                                                          
See the
                                                          other comments
                                                          between the
                                                          lines.

                                                          

                                                          


                                                          

                                                          

                                                          
On
                                                          Mon, Jul 20,
                                                          2020 at 2:05
                                                          AM Denis <denis.ietf@free.fr>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hi Dick,

                                                          


                                                          

                                                          

                                                          
On
                                                          Fri, Jul 17,
                                                          2020 at 9:21
                                                          AM Denis <denis.ietf@free.fr>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Francis and
                                                          Dick,

                                                          


                                                          

                                                          
The good
                                                          news first: we
                                                          are making
                                                          some progress.
                                                          We are now
                                                          close to an
                                                          agreement with
                                                          steps (1) up
                                                          to (3), 

                                                          ... except
                                                          that the place
                                                          where the user
                                                          consent is
                                                          captured is
                                                          not
                                                          mentioned/indicated.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          This major
                                                          question which
                                                          is currently
                                                          left
                                                          unanswered is
                                                          where, when
                                                          and how the
                                                          user consent
                                                          is captured.

                                                          

                                                          

                                                          


                                                          

                                                          
When is
                                                          covered, per
                                                          the sequence.
                                                          How and where
                                                          are out of
                                                          scope of what
                                                          I drafted. 

                                                          

                                                          

                                                          

                                                          

                                                          
It is clear
                                                          that the "User
                                                          consent and
                                                          choice" is not
                                                          currently
                                                          addressed in
                                                          the draft, but
                                                          it should.

                                                          The support of
                                                          the "User
                                                          consent and
                                                          choice" has
                                                          strong
                                                          implications
                                                          not only in
                                                          the sequences
                                                          of the
                                                          exchanges 

                                                          but also by
                                                          which entity
                                                          it should be
                                                          performed.

                                                          

                                                          

                                                          
"consent"
                                                          is in the
                                                          latest draft 7
                                                          times. 

                                                          

                                                          

                                                        

                                                      

                                                      
"Consent" is
                                                        present 5 times.
                                                        The User consent
                                                        is different
                                                        from the RO
                                                        consent (when/if
                                                        it is required).
                                                        

                                                      

                                                      

                                                        
The server
                                                          acquires
                                                          consent and
                                                          authorization
                                                          from the user
                                                          and/or
                                                          resource owner
                                                          if
                                                          required.

                                                        

                                                        
User consent
                                                          is often
                                                          required
                                                          at the GS.
                                                          GNAP enables a
                                                          Client and  GS
                                                          to negotiate
                                                          the
                                                          interaction
                                                          mode for the
                                                          GS to obtain
                                                          consent.

                                                        

                                                        
 The GS may
                                                          require
                                                          explicit
                                                          consent from
                                                          the RO or User
                                                          to provide
                                                          these to the
                                                          Client.

                                                        

                                                      

                                                      
The User
                                                        consent is not
                                                        an alternative
                                                        to the RO
                                                        consent. So
                                                        using "and/or"
                                                        in the first
                                                        sentence is
                                                        incorrect.

                                                    

                                                  

                                                  


                                                  

                                                  
My language is
                                                    sloppy there.
                                                    Consent is always
                                                    from the RO. The
                                                    User may be the RO.

                                                

                                              

                                            

                                          

                                          
[Denis] No. Once again: The
                                            "User consent" is
                                            different from what you call
                                            the "RO consent"
                                            (when/if it is required). 

                                            The "RO consent" is not in
                                            fact a consent but the
                                            release of a capability to a
                                            client by one of the many
                                            R0s with which 

                                            the GS has relationships. 

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
Since the
                                                        second sentence
                                                        is using the
                                                        wording "often
                                                        required" there
                                                        is no
                                                        requirement to
                                                        get the User
                                                        consent.

                                                      

                                                    

                                                  

                                                  
User consent may
                                                    not be required.
                                                    There may not be a
                                                    User. The consent
                                                    may have been
                                                    gathered previously.

                                                

                                              

                                            

                                          

                                          
[Denis] In order to follow
                                            the privacy principles, a
                                            "User consent" phase is
                                            required. The User is a
                                            natural person.

                                            A Client is called either by
                                            a User (i.e. a natural
                                            person) or by a Client
                                            application. 

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
 

                                                      
The second
                                                        sentence does
                                                        not consider the
                                                        possibility to
                                                        get the User
                                                        consent in a
                                                        place different
                                                        from the GS.

                                                    

                                                  

                                                  
Agreed. But we do
                                                    agree that the GS
                                                    gets the consent,
                                                    either directly from
                                                    the RO, or from the
                                                    Client (in your
                                                    example).

                                                

                                              

                                            

                                          

                                          
[Denis] No. I disagree. In
                                            an ACL based systems, the GS
                                            does not need to ask or
                                            receive any consent.

                                            The client selects the set
                                            of attributes that it wants
                                            to be inserted into an
                                            access token.

                                            If the GS has the requested
                                            attributes, then it provides
                                            them, otherwise it returns
                                            an error to the Client.

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
IMO, the User
                                                        consent should
                                                        be captured by
                                                        the Client, i.e.
                                                        not by the GS. 

                                                        The information
                                                        used to obtain
                                                        the User consent
                                                        should be
                                                        standardized
                                                        (... and it can
                                                        be
                                                        standardized).

                                                      

                                                      

                                                        

                                                          
I
                                                          think the
                                                          abstract
                                                          sequence as
                                                          proposed by
                                                          Francis is a
                                                          great
                                                          addition, and
                                                          would clarify
                                                          where consent
                                                          is in the
                                                          sequence. 

                                                        

                                                      

                                                      
The current
                                                        sketch does not
                                                        illustrate the
                                                        place the User
                                                        Consent is
                                                        captured, in
                                                        particular by
                                                        the Client.

                                                    

                                                  

                                                  
It is an
                                                    abstraction. The GS
                                                    receives the
                                                    consent. How consent
                                                    is gathered is a
                                                    detail that is
                                                    dependent on the use
                                                    case.

                                                

                                              

                                            

                                          

                                          
[Denis] I really wonder
                                            whether there is really a
                                            "consent" to be received by
                                            the GS in both cases (i.e.
                                            ACLs or Capabilities).

                                          

                                          
    
                                            
  • For ACLs, the consent
                                              needs to be done by the
                                              Client.
    • 
                                            
  • For Capabilities, the
                                              current description is not
                                              clear since the inputs and
                                              the outputs for this
                                              "consent" phase
    
                                              are not currently
                                              described in the draft.
    • 
                                          

                                          

                                            

                                              

                                                

                                                  
 

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 Another
                                                          important
                                                          point to
                                                          consider and
                                                          to explain is
                                                          related to the
                                                          assurances
                                                          that the user
                                                          can obtain
                                                          about 

                                                          the respect of
                                                          his choices.
                                                          This point is
                                                          currently left
                                                          unanswered in
draft-hardt-xauth-protocol-13.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
This point
                                                          is equally
                                                          important:
                                                          such assurance
                                                          can only be
                                                          obtained if
                                                          the access
                                                          token returned
                                                          to the client
                                                          

                                                          is not
                                                          considered to
                                                          be opaque to
                                                          the client.
                                                          This is a
                                                          necessary
                                                          condition but
                                                          not the single
                                                          condition: 

                                                          the Client
                                                          must also be
                                                          in a position
                                                          to
                                                          capture/memorize
                                                          the "User
                                                          consent and
                                                          choice" of the
                                                          user in order
                                                          to be able 

                                                          to verify it
                                                          afterwards
                                                          using the
                                                          content of the
                                                          access
                                                          token(s).

                                                          

                                                          

                                                          


                                                          

                                                          
We
                                                          disagree on
                                                          this being a
                                                          requirement
                                                          for all use
                                                          cases. It may
                                                          be in some. 

                                                          

                                                          

                                                        

                                                      

                                                      
OK. Then this
                                                        means that there
                                                        will be no
                                                        sentence in the
                                                        draft such as :

                                                        "access tokens
                                                        returned to the
                                                        client are not
                                                        considered to be
                                                        opaque to the
                                                        client".

                                                    

                                                  

                                                  


                                                  

                                                  
For OAuth use
                                                    cases, which GNAP
                                                    supports, the access
                                                    token is opaque to
                                                    the Client. As you
                                                    have noted, there
                                                    are use cases where
                                                    the access token is
                                                    NOT opaque.

                                                

                                              

                                            

                                          

                                          
[Denis] Wait a second.
                                            There is no requirement to
                                            support all OAuth use cases.
                                            

                                            I believe that there is a
                                            requirement to support OAuth
                                            2.0 ASs, while the clients
                                            may be different 

                                            and hence GNAP clients do
                                            not need to inherit of the
                                            limitations of OAuth 2.0
                                            clients.

                                          

                                            

                                              

                                                

                                                  
 

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
If a RO
                                                          needs to be
                                                          involved and
                                                          since a RO is
                                                          directly
                                                          associated
                                                          with a RS, why
                                                          can't it be
                                                          directly
                                                          queried 

                                                          by the
                                                          appropriate RS
                                                          after step (2)
                                                          or later on ?

                                                          

                                                          

                                                          


                                                          

                                                          
Good
                                                          question.
                                                          Perhaps you
                                                          can expand on
                                                          a use case
                                                          where that
                                                          would be
                                                          useful?

                                                          

                                                          

                                                          

                                                          
Before I
                                                          expand, would
                                                          you be able to
                                                          explain first
                                                          under which
                                                          circumstances
                                                          a RO needs to
                                                          be queried by
                                                          a GS ?

                                                          How can the GS
                                                          identify which
                                                          RO to query ?

                                                          

                                                          

                                                          
If the
                                                          User is the
                                                          RO, then the
                                                          GS knows who
                                                          to query. 

                                                          

                                                          

                                                          

                                                          

                                                          
I still
                                                          have
                                                          difficulties
                                                          to understand
                                                          what you mean
                                                          here. 

                                                          How could a GS
                                                          know that "the
                                                          User is the
                                                          RO" ?  If "the
                                                          User is the
                                                          RO", why does
                                                          the GS needs
                                                          to query the
                                                          User ? 

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
To get
                                                          consent?

                                                          

                                                        

                                                      

                                                      
To get a "RO
                                                        consent" to
                                                        himself ???

                                                    

                                                  

                                                  


                                                  

                                                  
The GS needs
                                                    consent from the RO.
                                                    If the RO is the
                                                    User, then consent
                                                    from the RO is
                                                    equivalent to
                                                    consent from the
                                                    User.

                                                

                                              

                                            

                                          

                                          
[Denis] See above.

                                          

                                          

                                            

                                              

                                                

                                                  
 

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
If the RO
                                                          is a separate
                                                          entity, then
                                                          the GS knows
                                                          the RO from
                                                          the RS being
                                                          queried. 

                                                          

                                                          

                                                          

                                                          

                                                          
 ... and
                                                          this gives the
                                                          ability for
                                                          the GS to
                                                          log/trace all
                                                          the RSs
                                                          accessed by a
                                                          given User and
                                                          at which
                                                          instant of
                                                          time the
                                                          access token
                                                          has been
                                                          granted.

                                                          

                                                          

                                                          

                                                          
An
                                                          example is a
                                                          user would
                                                          like access to
                                                          an enterprise
                                                          asset where a
                                                          workflow is
                                                          started to
                                                          gain approval,
                                                          and an
                                                          administrator
                                                          or manager
                                                          provides
                                                          consent.

                                                          

                                                          

                                                          

                                                          
Thanks for
                                                          this example.
                                                          I finally
                                                          understand
                                                          what you have
                                                          in mind: you
                                                          are
                                                          considering
                                                          using an
                                                          access control
                                                          model to build
                                                          a workflow
                                                          model. 

                                                          While it may
                                                          be interesting
                                                          to define a
                                                          workflow
                                                          model, this
                                                          should be
                                                          considered as
                                                          a separate
                                                          and different
                                                          work item.

                                                          

                                                          

                                                          


                                                          

                                                          
The
                                                          actual
                                                          workflow is
                                                          out of scope.
                                                          

                                                          

                                                        

                                                      

                                                      
I am glad you
                                                        agree with this.
                                                        But this means
                                                        that your
                                                        example was not
                                                        appropriate to
                                                        illustrate your
                                                        point.

                                                      

                                                    

                                                  

                                                  


                                                  

                                                  
It illustrates a
                                                    use case where the
                                                    RO and User are not
                                                    the same party, and
                                                    why the GS needs to
                                                    query the RO, which
                                                    was your question if
                                                    I understood it
                                                    correctly.

                                                

                                              

                                            

                                          

                                          
[Denis] Since the inputs
                                            and the outputs for this "RO
                                            consent" phase are not
                                            currently described in the
                                            draft, the point is still
                                            unsolved.

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
 As soon as
                                                        there is a RO
                                                        consent obtained
                                                        at the GS, the
                                                        major problem is
                                                        that the GS is
                                                        able to act as
                                                        Big Brother.

                                                        If a RO consent
                                                        is performed at
                                                        the RS, then the
                                                        GS will not know
                                                        who the RS is:
                                                        it is then
                                                        unable to act as
                                                        Big Brother, 

                                                        even if it would
                                                        enjoy to play
                                                        that role.

                                                    

                                                  

                                                  
In an enterprise
                                                    use case, the GS's
                                                    knowledge of who is
                                                    accessing which RS
                                                    is a feature.

                                                

                                              

                                            

                                          

                                          
Do you mean that it is
                                            "normal" in an enterprise
                                            that a single point of
                                            control is able to trace all
                                            their actions ? 

                                            From a security point of
                                            view, a single point of
                                            failure will have dramatic
                                            consequences.

                                          

                                            

                                              

                                                

                                                  
In your use
                                                    cases, it seems that
                                                    the RO is the User.
                                                  

                                                

                                              

                                            

                                          

                                          
I do hope that you have
                                            finally understood that, in
                                            my use case, the RO is
                                            **not** the User.

                                          

                                            

                                              

                                                

                                                  
The GS knows the
                                                    User is wanting to
                                                    let a Client access
                                                    something. If the
                                                    access token is
                                                    generic, and could
                                                    be presented to any
                                                    RS that provides a
                                                    standardized
                                                    function, 

                                                    then the GS does not
                                                    know which RS is
                                                    being accessed by a
                                                    Client for the User.
                                                    This seems to meet
                                                    your privacy
                                                    objectives. If not,
                                                    what is wrong?

                                                

                                              

                                            

                                          

                                          
For security reasons, an
                                            access token needs to be
                                            targeted (which does not
                                            necessarily mean that an
                                            identifier of the RS shall
                                            be included into the access
                                            token).

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
if the
                                                          admin grants
                                                          access, then
                                                          the access
                                                          granted to the
                                                          client
                                                          changes. 

                                                          

                                                          

                                                          

                                                          
 

                                                          
The model
                                                          you propose
                                                          may be suited
                                                          for an
                                                          enterprise
                                                          environment
                                                          but is not
                                                          scalable over
                                                          the Internet.

                                                          

                                                          

                                                          
It is one
                                                          of the use
                                                          cases we are
                                                          working to
                                                          address. 

                                                          

                                                          

                                                          

                                                          
 What is
                                                          needed is an
                                                          access control
                                                          model usable
                                                          over the
                                                          Internet with
                                                          millions of
                                                          RSs and
                                                          thousands of
                                                          ASs/GSs.  

                                                          

                                                          

                                                          

                                                          
I agree
                                                          the model
                                                          should also
                                                          scale to
                                                          internet
                                                          scale. 

                                                          

                                                          

                                                        

                                                      

                                                      
Fine. Another
                                                        point on which
                                                        we are in
                                                        agreement. 

                                                      

                                                      
The model can
                                                        scale to the
                                                        Internet based
                                                        on the following
                                                        assumptions:

                                                      

                                                        
The flow
                                                          starts with
                                                          the steps (1)
                                                          to (4) as
                                                          illustrated by
                                                          Francis, i.e.
                                                          the flow
                                                          starts with a
                                                          contact with a
                                                          RS.

                                                      

                                                      
+----+
                                                           +------+
                                                           +---+  +---+
                                                           +---+

                                                          |User|
                                                           |Client|  |RS
                                                          |  |GS |  |RO
                                                          |

                                                          +----+
                                                           +------+
                                                           +---+  +-+-+
                                                           +-+-+

                                                            |(1) Service
                                                          Request     |
                                                               |

                                                           
                                                          |-------->|
                                                                |      |
                                                               |

                                                            |        
                                                          |(2) Service
                                                          Intent   |

                                                            |        
                                                          |------>|  
                                                             |      |

                                                            |        
                                                          |(3) AuthZ
                                                          Challenge  |

                                                            |        
                                                          |<------|  
                                                             |      |

                                                            |        
                                                          |(4) AuthZ
                                                          Request    |

                                                            |        
                                                          |------------->|
                                                               |

                                                      
The GS/AS does
                                                        not need to have
                                                        any prior
                                                        relationship
                                                        with ROs and/or
                                                        RSs.

                                                      
Furthermore, it
                                                        is possible to
                                                        prevent the GS
                                                        to act as Big
                                                        Brother when the
                                                        identity of the
                                                        RS is not
                                                        disclosed to the
                                                        GS.

                                                      

                                                    

                                                  

                                                  


                                                  

                                                  
What happens
                                                    after (4) above? 

                                                  

                                                

                                              

                                            

                                          

                                          
[Denis] The key point is
                                            that we first need to agree
                                            on the first four exchanges.
                                            Do we ?

                                          

                                          
The fifth exchange is
                                            different whether ACLs or
                                            Capabilities are being used.

                                          

                                          

                                            

                                              

                                                

                                                  
 

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
Which
                                                          information is
                                                          supposed to be
                                                          presented to
                                                          the RO ?

                                                          Which
                                                          information is
                                                          supposed to be
                                                          returned by
                                                          the RO ?

                                                          

                                                          

                                                          


                                                          

                                                          
Just like
                                                          how the user
                                                          authenticates
                                                          to an AS, how
                                                          the AS and RO
                                                          communicate is
                                                          out of scope.

                                                          

                                                          

                                                          

                                                          

                                                          
At the
                                                          moment, the
                                                          usefulness of
                                                          a dialogue
                                                          between a GS
                                                          and a RO has
                                                          not been
                                                          explained, nor
                                                          demonstrated.

                                                          The question
                                                          is about the
                                                          functionality
                                                          of that
                                                          dialogue in
                                                          terms of input
                                                          and output
                                                          information
                                                          (and not about
                                                          

                                                          the design of
                                                          a protocol or
                                                          of a user
                                                          interface).
                                                          Anyway, AFAIU
                                                          a dialogue
                                                          between a GS
                                                          and a RO is
                                                          optional.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
See
                                                          enterprise
                                                          example above.

                                                          

                                                          

                                                          

                                                          
It is not
                                                          an access
                                                          control
                                                          example, but a
                                                          workflow
                                                          example.

                                                          
Access 
                                                          control has
                                                          been defined a
                                                          long time ago
                                                          and the last
                                                          edition of the
                                                          model has been
                                                          confirmed in
                                                          year 1996: ISO/IEC 10181-3: 1996.

                                                          "Information
                                                          technology —
                                                          Open Systems
                                                          Interconnection —
                                                          Security
                                                          frameworks for
                                                          open systems:
                                                          Access control
                                                          framework —
                                                          Part 3".

                                                          
Two major functions have ben defined: an Access Control Enforcement Function
                                                          (AEF) and an Access
                                                          Control
                                                          Decision
                                                          Function(ADF).

                                                          

                                                          
Access
                                                          Control Enforcement
                                                          Function
                                                          (AEF):

                                                          A specialized
                                                          function that
                                                          is part of the
                                                          access path
                                                          between an
                                                          initiator and
                                                          a target on
                                                          each access
                                                          request and
                                                          enforces the
                                                          decision made
                                                          by the ADF.

                                                          Access Control Decision
                                                          Function
                                                          (ADF) :

                                                          A
                                                          specialized
                                                          function that
                                                          makes access
                                                          control
                                                          decisions by
                                                          applying
                                                          access control
                                                          policy rules
                                                          to an access
                                                          request, ADI
                                                          (of
                                                          initiators,
                                                          targets,
                                                          access
                                                          requests, 

                                                          or
                                                          that retained
                                                          from prior
                                                          decisions),
                                                          and the
                                                          context in
                                                          which the
                                                          access request
                                                          is made.

                                                          
The role of
                                                          the RO is to
                                                          define the "access control policy rules" at the RS
                                                          according to
                                                          the context
                                                          in which the
                                                          access request
                                                          is made.

                                                          

                                                          

                                                          
I'm
                                                          pretty
                                                          familiar with
                                                          access control
                                                          systems. :) 

                                                          


                                                          

                                                          
I would
                                                          say that the
                                                          access control
                                                          is happening
                                                          at the RS. The
                                                          client
                                                          presents a
                                                          token when
                                                          accessing an
                                                          API. 

                                                          The RS uses
                                                          the token, and
                                                          any policy
                                                          required, to
                                                          make an access
                                                          decision.

                                                          

                                                        

                                                      

                                                      
Fine. It looks
                                                        like we are in
                                                        agreement.
                                                        Unfortunately,
                                                        this is not the
                                                        case just below.

                                                      

                                                      

                                                        

                                                          

                                                          
Here is
                                                          flow:

                                                          


                                                          

                                                          
1) The
                                                          Client
                                                          requests
                                                          access to an
                                                          RS from the
                                                          GS. 

                                                          

                                                          

                                                        

                                                      

                                                      
No. We are no
                                                        more in
                                                        agreement. This
                                                        is different
                                                        from the flow
                                                        drawn by
                                                        Francis.

                                                    

                                                  

                                                  
My bad. Typo. I
                                                    meant RO.

                                                  
 

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
2) The GS
                                                          queries the RS
                                                          if access
                                                          should be
                                                          granted. 

                                                          

                                                          

                                                        

                                                      

                                                      
 No. The GS
                                                        should not be
                                                        forced to have a
                                                        flow with the
                                                        RS.

                                                    

                                                  

                                                  
Same mistake as
                                                    above, I meant RO. 

                                                  

                                                    

                                                      
 

                                                      

                                                        

                                                          

                                                          
3) If
                                                          access is
                                                          granted, the
                                                          GS creates an
                                                          access token
                                                          representing
                                                          the granted
                                                          access, and
                                                          returns it to
                                                          the Client. 

                                                          

                                                          

                                                        

                                                      

                                                      
This model is
                                                        by no way
                                                        conformant to ISO/IEC 10181-3: 1996 

                                                          

                                                    

                                                  

                                                  
I'm unclear on
                                                    why, or why it is
                                                    even relevant. 

                                                  

                                                  

                                                    

                                                      

                                                          

                                                      

                                                        

                                                          

                                                          
4) The
                                                          Client
                                                          presents the
                                                          access token
                                                          to the RS to
                                                          show it has
                                                          been granted
                                                          access. 

                                                          

                                                          

                                                        

                                                      

                                                      
No. The client
                                                        presents a token
                                                        when accessing
                                                        an API. The RS
                                                        uses the token,
                                                        and any policy
                                                        required, to
                                                        make an access
                                                        decision.

                                                        The token never
                                                        contains an
                                                        information like
                                                        "Please grant an
                                                        access to the
                                                        holder of this
                                                        token".

                                                    

                                                  

                                                  
Let me provide
                                                    more clarity in the
                                                    sentence:

                                                  


                                                  

                                                  
The Client
                                                    presents the access
                                                    token to the RS, to
                                                    show the RS that the
                                                    Client has been
                                                    granted access to a
                                                    resource at the RS
                                                    by the GS.

                                                

                                              

                                            

                                          

                                          
[Denis] This time, please
                                            consider both the ACLs
                                            approach and the
                                            Capabilities approach.

                                          

                                            

                                              

                                                

                                                  
 

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
A couple
                                                          advantages of
                                                          this model:

                                                          
- that
                                                          the RS does
                                                          not need to
                                                          know much, if
                                                          anything about
                                                          the Client. 

                                                          
- the
                                                          access token
                                                          MAY be self
                                                          contained so
                                                          that the
                                                          Client does
                                                          not need to
                                                          query the GS
                                                          on each
                                                          access. 

                                                          

                                                          

                                                        

                                                      

                                                      
There are so
                                                        many
                                                        disadvantages
                                                        that I will not
                                                        list them.

                                                    

                                                  

                                                  
Darn: I clearly
                                                    was not firing on
                                                    all cylinders when I
                                                    typed this out. Let
                                                    me correct:

                                                  


                                                  

                                                  

                                                    

                                                      

                                                        

                                                          
- the
                                                          access token
                                                          MAY be self
                                                          contained so
                                                          that the RS
                                                          does not need
                                                          to query the
                                                          GS on each
                                                          access to the
                                                          RS by the
                                                          Client.

                                                        

                                                      

                                                    

                                                  

                                                

                                              

                                            

                                          

                                          
[Denis] A few comments in
                                            the case of a capability
                                            approach:

                                          

                                            
- for each GS, the RS
                                              needs to locally manage
                                              which operation(s) is/are
                                              allowed to it.

                                              

                                              - the GS needs to
                                              establish a trusted
                                              communication channel or
                                              an authentication
                                              mechanism with each RO 

                                                 (which is associated
                                              with an explicit RS
                                              identifier). 

                                            

                                            
- the GS could play the
                                              role of the RO and hence
                                              be in a position to issue
                                              any capability for any RS
                                              (without a "RO consent").
                                              

                                              

                                                 The target of an attack
                                              will clearly be the GS.

                                            

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
I would
                                                          not say that
                                                          GNAP is an
                                                          access control
                                                          protocol, as
                                                          how the RS
                                                          uses the token
                                                          to determine
                                                          access is out
                                                          of scope.

                                                          

                                                        

                                                      

                                                      
This is where
                                                        we have a major
                                                          discrepancy:
                                                        how the RS uses
                                                        the token to
                                                        determine access
                                                        is *within* the
                                                        scope.

                                                    

                                                  

                                                

                                              

                                            

                                          

                                          [Denis] Do you agree or
                                          disagree ?

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
The RS
                                                        announces in
                                                        advance to the
                                                        client what it
                                                        needs so that
                                                        the client can
                                                        perform a a
                                                        given operation
                                                        and if the
                                                        client supplies
                                                        the requested
                                                        attributes 

                                                        obtained from
                                                        some GS/AS(s)
                                                        trusted by the
                                                        RS, then access
                                                        to that RS is
                                                        granted by the
                                                        RS. If the RS
                                                        cannot perform
                                                        the requested
                                                        operation on its
                                                        own, 

                                                        then the client
                                                        should be
                                                        informed about
                                                        some requested
                                                        attributes that
                                                        need to be
                                                        obtained from
                                                        some GS/AS(s)
                                                        trusted by the
                                                        next RS(s) in a
                                                        chain

                                                        for subsequent
                                                        operations. The
                                                        User consent
                                                        should also be
                                                        obtained before
                                                        performing the
                                                        chaining
                                                        operation.

                                                      

                                                      
Chaining
                                                        operations
                                                        between RSs over
                                                        the Internet is
                                                        within the scope
                                                        (... and may be
                                                        achieved).

                                                    

                                                  

                                                

                                              

                                            

                                          

                                          
[Denis] Do you agree or
                                            disagree ?

                                          
Denis

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
For many
                                                          use cases, the
                                                          User is the
                                                          RO, and the
                                                          interaction is
                                                          through a user
                                                          interface, not
                                                          a machine
                                                          protocol. 

                                                          

                                                          

                                                          

                                                          

                                                          
Wait a
                                                          second. You
                                                          wrote "the
                                                          User is the
                                                          RO". The User
                                                          is attempting
                                                          to make an
                                                          access to a RS
                                                          by using a
                                                          Client. 

                                                          That
                                                          User is not
                                                          the RO of the
                                                          RS.   

                                                          

                                                          

                                                          

                                                          
The user
                                                          being the RO
                                                          is the initial
                                                          use case for
                                                          OAuth. 

                                                          

                                                          

                                                          

                                                          
OAuth 2.0
                                                          is no more
                                                          mandating such
                                                          a case.

                                                          

                                                          

                                                          

                                                          

                                                        

                                                      

                                                      

                                                        

                                                          


                                                          
I don't
                                                          know what you
                                                          mean by that.

                                                          

                                                        

                                                      

                                                      
Copy and paste
                                                        from
                                                        draft-ietf-oauth-security-topics:

                                                      

                                                      

                                                        
OAuth
                                                          initially
                                                          assumed a
                                                          static
                                                          relationship
                                                          between
                                                          client,
                                                          authorization
                                                          server and
                                                          resource
                                                          servers. 
                                                          (...)  

                                                          With the
                                                          increasing
                                                          adoption of
                                                          OAuth, this
                                                          simple model
                                                          dissolved and,
                                                          in several
                                                          scenarios, was
                                                          replaced 

                                                          by a dynamic
                                                          establishment
                                                          of the
                                                          relationship
                                                          between
                                                          clients on one
                                                          side and the
                                                          authorization
                                                          and 

                                                          resource
                                                          servers of a
                                                          particular
                                                          deployment on
                                                          the other
                                                          side.

                                                          

                                                          This way, the
                                                          same client
                                                          could be used
                                                          to access
                                                          services of
                                                          different
                                                          providers (in
                                                          case of
                                                          standard APIs,
                                                          

                                                          such as e-mail
                                                          or OpenID
                                                          Connect) or
                                                          serve as a
                                                          frontend to a
                                                          particular
                                                          tenant in a
                                                          multi-tenancy
                                                          environment. 

                                                        

                                                      

                                                    

                                                  

                                                  


                                                  

                                                  
This sentence
                                                    does not mention the
                                                    RO or the Client.
                                                    I'm confused what we
                                                    are talking about 

                                                  

                                                    

                                                      

                                                        
 

                                                      

                                                      

                                                        

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
A client
                                                          application
                                                          would like
                                                          access to the
                                                          user's photos
                                                          at a photo
                                                          sharing site.
                                                          The resource
                                                          is the user's
                                                          photos. The
                                                          user is the
                                                          owner of that
                                                          resource.

                                                          

                                                          

                                                          

                                                          
If the user
                                                          has already
                                                          pre
                                                          established
                                                          the access
                                                          control policy
                                                          rules so that
                                                          it can access
                                                          to his own
                                                          photos 

                                                          then he does
                                                          not need to
                                                          grant in real
                                                          time any
                                                          additional
                                                          authorization.

                                                          

                                                          

                                                          
I don't
                                                          understand
                                                          what you are
                                                          trying to say.
                                                          The photo
                                                          sharing
                                                          example was a
                                                          driving use
                                                          case for the
                                                          creation of
                                                          OAuth.

                                                          

                                                        

                                                      

                                                      
We would need
                                                        to revisit the
                                                        original
                                                        scenario and
                                                        consider if it
                                                        can be addressed
                                                        in a different
                                                        way than the
                                                        original way.

                                                    

                                                  

                                                  
The use case is
                                                    the same. Is there a
                                                    different solution
                                                    you are proposing?

                                                  
 

                                                

                                              

                                            

                                          

                                          


                                          

                                        

                                        -- 

                                        Txauth mailing 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

            

          

        

      

    

    


    

  


--------------02875C1546CA560E6BB0B0A3--


From nobody Tue Jul 28 09:58: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 AE8A93A0D34 for ; Tue, 28 Jul 2020 09:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.682
X-Spam-Level: 
X-Spam-Status: No, score=-0.682 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_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 Z6WOOMRSRXgX for ; Tue, 28 Jul 2020 09:58:28 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 DFA513A0CDF for ; Tue, 28 Jul 2020 09:58:27 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id f5so21911342ljj.10 for ; Tue, 28 Jul 2020 09:58: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=Lt9/YG3m27GpRgUOsL3ibtZVap7HHbmebpTTGIURJWs=; b=Pz10vioHjIIhyjs9IArD0ud5XxsszvKZdfV6bO1cy+K0Z4KYYd3LHV11arDyxii4FQ RRYgwBUWyihPqBhJCHdHaWPYmpenbsSiqYiEGTbRqWZ2VXHP0Ir/stAJ4bADq8tHmJle M7mMqNpx07FilrGrhvHEC27kE2OkeQaOFaWUyMd1yNrpLIbS9f5nLF8Q4W5dcJGGKe8z 7/XAYwmXjOfVoL/sMTSyUhNCSkiSEGFyfJirPJwL1NvoJtyq7u/PyvXpIpC42gg4YUMe O9icKMzWqQSJfcPnJargpUZ6EOC7f9ClTnQ+CHFn4ShT81SNQniNo9JXBDLcJGdT5KaU jPpA==
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=Lt9/YG3m27GpRgUOsL3ibtZVap7HHbmebpTTGIURJWs=; b=TZntMhMc6px0Ai91ZrdzkWCIiEbGKwtST1ylh+zxmpk3QHSrMyItqsH5K7GCze3O9Y EdPm/k7XBXKweFm9NlAJO3mL/5pSG/BklLMhiP9R76a+8Dm2+at07g9Jy40i40vFFeOd d2ttl4RQOq/LbU0Yy3aISIyK5ndS0xMd5xSPQUyNoZd9hQt9XMIh8AAEr9mtK6FKEFHh wK/C4jBiB8bloKCVHFxiL8l7A1LyV/ftX6YQOFS5ItiJ3ksjg4TbbP8HmK8MtCt8jssB AQIIkO11dKssExT5HQvBnfwyMnnUSsT36VwE6hoabVWF3fq2LUAx0Pckxdid9ANk0maP pqWA==
X-Gm-Message-State: AOAM5318xG46mKCERj9RPdgS8OxbhYPYf7kduEwsvf3Kv5J38VIfNtm/ fEWb+BYlpxmorPqbXI9cmAuG8hBEloQqe9QECv0=
X-Google-Smtp-Source: ABdhPJyBlpMIKaZeb2KyxrzUP7H0P8nLHj82NJKUIiZOveM/dLTvNDtSy0TbNuDaSS6LJryEy2/ceqpe2MIlL0BH8RI=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr13357544ljh.110.1595955505824;  Tue, 28 Jul 2020 09:58:25 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Dick Hardt 
Date: Tue, 28 Jul 2020 09:57:49 -0700
Message-ID: 
To: Yaron Sheffer 
Cc: GNAP Mailing List 
Content-Type: multipart/alternative; boundary="000000000000008a0b05ab8359d4"
Archived-At: 
Subject: Re: [Txauth] GNAP core document design team
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, 28 Jul 2020 16:58:30 -0000

--000000000000008a0b05ab8359d4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I have some concerns that a goal of a document with the "best features" of
XYZ and XAuth may be a challenge.

As I see it, Justin and I have different perspectives on the "best" way to
do certain features. While it is possible that Justin and I with help from
other members on the design team may align on the "best" way, another
outcome is that the design team will need to get feedback from the full WG
on the different approaches. In this case, the near term goal would be a
mail list discussion of the different approaches, and consensus be
obtained. A document would then be able to be presented by the design team
for WG adoption.

I think the approach taken with the OAuth 2.1 document in the OAuth WG is a
good example of how to get consensus. The OAuth 2.1 document was somewhat
contentious. Before asking for WG adoption, myself and the other authors
led discussions on potentially contentious topics and then got consensus on
each topic and generally agreed wording. The WG call for adoption for the
proposed document has not received any concerns.

/Dick



=E1=90=A7

On Tue, Jul 28, 2020 at 4:30 AM Yaron Sheffer  wrote=
:

> Hi everyone,
>
> Following our discussion yesterday, we are looking for volunteers for a
> short-term design team. The team=E2=80=99s goal will be to come up with a=
n outline
> of a document combining the best features of XYZ and XAuth. The timeframe
> will be short =E2=80=93 a few weeks. If you would like to join, please se=
nd the
> chairs a private email by Friday.
>
> Based on the expressed interest we will pick a small number of individual=
s
> for the team. We apologize in advance that we will not offer everyone a
> spot on the design team.
>
> Thanks,
>                 Leif and Yaron
>
>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--000000000000008a0b05ab8359d4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I have some concerns that a goal of a document with the &q=
uot;best features" of XYZ and XAuth may be a challenge.

As I see it, Justin and I have different perspectives on the "=
;best" way to do certain features. While it is possible that Justin an=
d I with help from other members on the design team may align on the "=
best" way, another outcome is that the design team will need to get fe=
edback from the full WG on the different approaches. In this case, the near=
 term goal would be a mail list discussion of the different approaches, and=
 consensus be obtained. A document would then be able to be presented by th=
e design team for WG adoption.

I think the approac=
h taken with the OAuth 2.1 document in the OAuth WG is a good example of ho=
w to get consensus. The OAuth 2.1 document was somewhat contentious. Before=
 asking for WG adoption, myself and the other authors led discussions on po=
tentially contentious topics and then got consensus on each topic and gener=
ally agreed wording. The WG call for adoption for the proposed document has=
 not received=C2=A0any concerns.

/Dick
<=
br>


3D""=E1=90=A7
On Tu=
e, Jul 28, 2020 at 4:30 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Hi everyone,

=C2=A0

Following our discussion yesterday, we are looking for volunteers for a sho=
rt-term design team. The team=E2=80=99s goal will be to come up with an out=
line of a document combining the best features of XYZ and XAuth. The timefr=
ame will be short =E2=80=93 a few weeks. If you would like to join, please =
send the chairs a private email by Friday.

=C2=A0

Based on the expressed interest we will=C2=A0pick a small number of individ=
uals for the team. We apologize in advance that we will not offer everyone =
a spot on the design team.

=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 Leif and Yaron







-- 

Txauth mailing list

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




--000000000000008a0b05ab8359d4--


From nobody Tue Jul 28 10:00: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 84A313A0E0F for ; Tue, 28 Jul 2020 10:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level: 
X-Spam-Status: No, score=-2.085 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 D_IWd10M5TaB for ; Tue, 28 Jul 2020 10:00:32 -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 E48D53A0CF4 for ; Tue, 28 Jul 2020 10:00:31 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id q4so21959676lji.2 for ; Tue, 28 Jul 2020 10:00:31 -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=tgzDYSUzJXfJmfxCEhEGSaAv/26uS2WdTwVsven8tVE=; b=HIbIuf88FQ5nH2F5hakDxuTLkCr+mitgeQNwzQgCzcQsrxJ5aT4u9zkd3n/lSsBjqo ka98/9mt1d35G/Z4fFFbysq2iirNtg7Z55V/h4CbodYmYohr0v1DzjBXGkuyvzVjruDP CNHm+Ea7vl/pqpbV7ykdEMNm3FBxbe9giJrW108NyzuoCu7pHCJJjn1bAkJKnkIp8+C4 HW166Qz+zvsixxwqiYPIUOWIxkSLisfbT7by+k0njGALwDyUfGA2vutLv5mrtFJyTG9L MJR3gs4Ijg/reZqaZQkfRDE2no4ffNDXtzeiLG9Fwu0LqRzPjFEkpZfpEnMEfEGFxLmm oSew==
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=tgzDYSUzJXfJmfxCEhEGSaAv/26uS2WdTwVsven8tVE=; b=oukPAk5wrqiFoG9bN489O/9DCtyOWZrmjt919FmWAEKMeJh0yXVKGWO9Wx9s7nayV9 oc9KztmSjRXceXG19qBPwRA+t2GC6XJjQZ76OgOcGebphn+Qv9g9DeeE8dPUJqDTy/oc xP56gCc+AZtbo0r9yEzzJXLd+J61Ndji/yx7uEobEUwmdo8GGarI8hvfgbXu9VcHY4AV ITScV/Rw03iJdPPlfvjZeMPP0+XVc04b+JV2TfF0i5txs5IAS0kZn314oS4CPYmI3t5l uT/iO41f3cu2qPOdwCeSYUa1XP7Qk8Ar/6d+/PgyfR9I/NZ7QSzWt+OfAj0EU3J4igDm 9u8A==
X-Gm-Message-State: AOAM530D8q57pfkIuTCvTPqkc71KQgQX+RPIiJXaimE1tbfedId7gROV o7PVfRSh7zHrA8EAuWUb9+OhrFsY4GoNyKuYV780JoIk
X-Google-Smtp-Source: ABdhPJwFKi9CReNMORMCKOR6A1+aVo6orb0MNnyYL8xhsSRJBUpU+YPDU+ZjmHKO5Gmu6W+MEtVmnzNYn07lOhUcOhc=
X-Received: by 2002:a2e:999a:: with SMTP id w26mr7900319lji.242.1595955629772;  Tue, 28 Jul 2020 10:00:29 -0700 (PDT)
MIME-Version: 1.0
References:     <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>        <7b313658-f7f1-dad1-33aa-7d2107436856@free.fr>  <18b6aa1e-49bf-a7bc-c1a6-5f2b77355434@free.fr>
In-Reply-To: <18b6aa1e-49bf-a7bc-c1a6-5f2b77355434@free.fr>
From: Dick Hardt 
Date: Tue, 28 Jul 2020 09:59:51 -0700
Message-ID: 
To: Denis 
Cc: txauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000063d42905ab8360be"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 28 Jul 2020 17:00:40 -0000

--00000000000063d42905ab8360be
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis

I did answer your question. The student is the User. The student is not the
Client.

=E1=90=A7

On Tue, Jul 28, 2020 at 7:12 AM Denis  wrote:

> Hi Dick,
>
> I am puzzled by your response. Your are the editor and a co-editor of the
> two following RFCs which state:
>
> RFC 6749:    In the traditional client-server authentication model, the
> client requests an access-restricted resource
>                      (protected resource) on the server by authenticating
> with the server (...)
>
> RFC 6750 : The client uses the access token to access the protected
> resources hosted by the resource server.
>
>                     The following two steps are specified within this
> document:
>
>                                (E)  The client requests the protected
> resource from the resource server and authenticates
>                                        by presenting the access token.
>
>                               (F)  The resource server validates the
> access token, and if valid, serves the request.
>
> In my use case, the student connects to the University server (i.e. a RS)
> as a client. The University server cannot be a Client.
> If you change/twist that basic vocabulary, we will not be able to
> understand each other any more.
>
> BTW, my first question still remains: Would you explain how you would
> handle the use case of a student registering to a new University ?
>
> Denis
>
>
> Hi Denis
>
> The student (User) goes to the registration page of the University (the
> Client)
>
> Similar to your example, the Client has a list of GS that it are
> acceptable, or RS that may be acceptable.
>
> If the User selects a GS, then the Client starts a GNAP flow with the GS.
>
> If the User selects an RS, then the Client can call the RS to determine
> which GSes to offer the User to use to get access to the RS.
>
> In summary, the University wants to consume Claims about the User, so it
> is the Client.
>
> /Dick
>
>
>
> On Mon, Jul 27, 2020 at 12:49 AM Denis  wrote:
>
>> Hi Dick,
>>
>> The floor is yours.
>>
>> Would you explain how you would handle the use case of a student
>> registering to a new University ?
>>
>> Would you also elaborate why in my explanations below, you think that
>> "the University's registration system is the Client, not a Resource Serv=
er"
>> ?
>>
>> Denis
>>
>> Hi Denis
>>
>> I would think in your example below, that the University's registration
>> system is the Client, not a Resource Server.
>>
>> Have a good night's sleep!
>>
>>
>>
>> On Fri, Jul 24, 2020 at 12:04 PM Denis  wrote:
>>
>>> Hi Dick,
>>>
>>> In order to send back a quick reply tonight, I will only respond to one
>>> of your questions:
>>>
>>> [Denis] How would be the data flow when access tokens from two GSs are
>>> needed by a RS ?
>>>
>>> [Dick] I don't know of a use case where two tokens would be needed by a=
n
>>> RS. Would you elaborate?
>>>
>>> I already described on the list the case of a student registering to a
>>> new University.
>>>
>>> First, the student connects to the RS from the new University and opens
>>> an account
>>> (at this time the student is using a pseudo and a private key to
>>> authenticate). He fills some forms
>>> and indicate its citizenship, his home address and his graduation in hi=
s
>>> current university.
>>>
>>> When he is finished, he indicates that he wants to perform a
>>> Registration operation.
>>>
>>> From the information gathered in the forms, the RS informs the client
>>> that it needs two access tokens:
>>>
>>>    - one to demonstrate that his name and current home address are
>>>    correct,and
>>>    - another one to demonstrate that he got a graduation from its
>>>    current University.
>>>
>>> Depending upon the information captured in the forms, the RS also
>>> indicates which ASs/GSs are acceptable
>>> and which kind of attributes are requested.
>>>
>>> The user consent and choice is performed by the client and once approve=
d
>>> by the student, two access tokens are separately requested.
>>> Finally, two access tokens are presented to the RS while invoking a
>>> Registration operation.
>>>
>>> Note that the start of the story is to open an account, e.g. using FIDO=
.
>>> The needs of the RS are only disclosed to the student once he has fille=
d
>>> some forms
>>> and indicated that he wanted to perform a Registration operation. Thus,
>>> the needs that are revealed by the RS are dependant both upon the opera=
tion
>>> that the student is willing to perform and the information collected in
>>> the forms.
>>>
>>> Denis
>>>
>>> Hi Denis, comments inserted ...
>>>
>>> On Fri, Jul 24, 2020 at 9:08 AM Denis  wrote:
>>>
>>>> Hi Dick,
>>>>
>>>> draft-hardt-xauth-protocol-13 describes a solution without clearly
>>>> stating what the problem(s) to be solved is/are.
>>>>
>>>
>>> I agree that the problem description is not as crisp as I would like it
>>> to be. A challenge is that there is a broad spectrum of use cases solve=
d by
>>> OAuth 2, and OpenID Connect, as well as the new use cases that are solv=
ed
>>> by GNAP.
>>>
>>> That is why I am suggesting we gather some use cases so we have a commo=
n
>>> understanding of the problems that are in scope.
>>>
>>>
>>>>
>>>> At the moment, draft-hardt-xauth-protocol-13 includes a single figure
>>>> on page 4 and from previous discussions I understood that
>>>> it is no more up-to-date since the first data flow is now a contact
>>>> with a RS. The reason(s) for the GS to contact a RO has still not
>>>> been explained (since the inputs and outputs are not described). The
>>>> discovery information made available at various steps at the RS
>>>> is not described.
>>>>
>>>
>>> I have made no updates as we are in a quiet period prior to the WG
>>> meeting next week when documents cannot be updated.
>>>
>>>
>>>>
>>>> Figure 4 shows only a single RS. Is the relaying of one operation by
>>>> that RS to a second RS in the scope of this document ?
>>>> If yes, how is it handled ?
>>>>
>>>
>>> I view that as an advanced use case that would be covered in a separate
>>> document.
>>>
>>>
>>>>
>>>> Figure 4 shows only a single GS. How would be the data flow when acces=
s
>>>> tokens from two GSs are needed by a RS ?
>>>>
>>>
>>> I don't know of a use case where two tokens would be needed by an RS.
>>> Would you elaborate?
>>> The RS being able to accept tokens from two different GSes is covered,
>>> but the Client is only using a token from one GS at a time.
>>>
>>>
>>>
>>>>
>>>> What we need first is not a set of "use cases" but a clear model with =
a
>>>> data flows and a list of its properties/characteristics.
>>>>
>>>
>>> I disagree. The use cases describe the problems we are looking to solve=
.
>>> The data flows are part of the solution. For example, from my understan=
ding
>>> of your use case, you don't want the GS to have visibility into the Use=
r's
>>> activity. Am I correct that this is one of your requirements for your u=
se
>>> case?
>>>
>>>
>>>
>>>> Then after, we can understand much better which use cases can/will be
>>>> supported. For example, shall a RS (or its RO) have
>>>> prior relationships with the GS ? What is the difference/implications
>>>> when it has or it hasn't ?
>>>>
>>>> In order to have a fair comparison, we should try to list model
>>>> properties/characteristics.
>>>>
>>>> At the moment, the model I have described including the data flows is
>>>> clear. The discovery information made available by a RS is clear.
>>>> I have not listed all its properties/characteristics of that model, bu=
t
>>>> I am pretty sure that you already have a flavour of it.
>>>>
>>>> In the mean time, it would be nice if you could show using two figures=
:
>>>>
>>>>    - the case of the relaying of one operation by one RS to a second
>>>>    RS (if it is in the scope of your document),
>>>>    - the case where access tokens from two GSs are needed by one RS
>>>>    (if it is in the scope of your document).
>>>>
>>>>
>>> See above
>>>
>>>
>>>>
>>>>    -
>>>>
>>>> Denis
>>>>
>>>> Hi Denis
>>>>
>>>> I think it would be useful to take a step back and for you to describe
>>>> your use case.
>>>> After that, we can explore the different ways that your use case can b=
e
>>>> addressed.
>>>>
>>>> Looking at your previous communication, it describes the solution, and
>>>> the justification,
>>>> but it is not clear what use cases you are needing to solve.
>>>>
>>>> /Dick
>>>>
>>>>
>>>> =E1=90=A7
>>>>
>>>> On Wed, Jul 22, 2020 at 9:34 AM Denis  wrote:
>>>>
>>>>> Hello Dick,
>>>>>
>>>>> I have identified the reason of the major difference between our two
>>>>> approaches.
>>>>>
>>>>> Access control may be performed using either ACLs (Access Control
>>>>> Lists) or Capabilities.
>>>>>
>>>>> *Note *: a capability identifies a resource and an allowed operation
>>>>> that can be performed on that resource.
>>>>>
>>>>> You are advocating a Capabilities approach while I am advocating an
>>>>> ACL approach.
>>>>>
>>>>> The capabilities approach allows the GS to trace every operation
>>>>> performed by the users on any RS known by a GS.
>>>>> The management of these capabilities is made via the GS or at the GS
>>>>> by the various ROs. If the management is made
>>>>> via the GS, then a trusted communication channel needs to be
>>>>> established with every RO. If the management is made
>>>>> at the GS, then an authentication mechanism needs to be established
>>>>> with every RO. In the last case, the GS has the
>>>>> ability to know all the capabilities of the users whether they are
>>>>> used or not. The less that can be said is that this model
>>>>> is not privacy friendly.
>>>>>
>>>>> With the ACL approach, a RO directly manages an ACL placed in front o=
f
>>>>> each RS. The Access Control Decision Function
>>>>> (ADF) at the RS is able to keep track from prior decisions. The GS is
>>>>> kept ignorant of the content of these ACLs and only
>>>>> delivers to its clients attributes that are placed into access tokens=
.
>>>>> Such a model may be privacy friendly.
>>>>>
>>>>> Other comments are between the lines prefixed with [Denis].
>>>>>
>>>>>
>>>>> On Tue, Jul 21, 2020 at 11:26 AM Denis  wrote:
>>>>>
>>>>>> Hello Dick,
>>>>>>
>>>>>> Thank you for your feedback. Comments are between the lines.
>>>>>>
>>>>>> comments inserted ...
>>>>>>
>>>>>> On Tue, Jul 21, 2020 at 6:03 AM Denis  wrote:
>>>>>>
>>>>>>> Hello Dick,
>>>>>>>
>>>>>>> I duplicate the most important comment at the beginning of this
>>>>>>> email:
>>>>>>>
>>>>>>> You are considering using an access control model to build a workfl=
ow
>>>>>>> model.
>>>>>>>
>>>>>>> While it may be interesting to define a workflow model, this should
>>>>>>> be considered
>>>>>>> as a separate and different work item.
>>>>>>>
>>>>>>> See the other comments between the lines.
>>>>>>>
>>>>>>> On Mon, Jul 20, 2020 at 2:05 AM Denis  wrote:
>>>>>>>
>>>>>>>> Hi Dick,
>>>>>>>>
>>>>>>>> On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:
>>>>>>>>
>>>>>>>>> Hello Francis and Dick,
>>>>>>>>>
>>>>>>>>> The good news first: we are making some progress. We are now clos=
e
>>>>>>>>> to an agreement with steps (1) up to (3),
>>>>>>>>> ... except that the place where the user consent is captured is
>>>>>>>>> not mentioned/indicated.
>>>>>>>>>
>>>>>>>>
>>>>>>>> This major question which is currently left unanswered is where,
>>>>>>>> when and how the user consent is captured.
>>>>>>>>
>>>>>>>
>>>>>>> When is covered, per the sequence. How and where are out of scope o=
f
>>>>>>> what I drafted.
>>>>>>>
>>>>>>> It is clear that the "User consent and choice" is not currently
>>>>>>> addressed in the draft, but it should.
>>>>>>> The support of the "User consent and choice" has strong implication=
s
>>>>>>> not only in the sequences of the exchanges
>>>>>>> but also by which entity it should be performed.
>>>>>>>
>>>>>> "consent" is in the latest draft 7 times.
>>>>>>
>>>>>> "Consent" is present 5 times. The User consent is different from the
>>>>>> RO consent (when/if it is required).
>>>>>>
>>>>>> The server acquires consent and authorization from the user *and/**o=
r
>>>>>> resource owner **if required.*
>>>>>>
>>>>>> User consent is *often required* at the GS. GNAP enables a Client
>>>>>> and  GS to negotiate the interaction mode for the GS to obtain conse=
nt.
>>>>>>
>>>>>> The GS *may *require explicit consent from the RO or User to provide
>>>>>> these to the Client.
>>>>>>
>>>>>> The User consent is not an alternative to the RO consent. So using
>>>>>> "and/or" in the first sentence is incorrect.
>>>>>>
>>>>>
>>>>> My language is sloppy there. Consent is always from the RO. The User
>>>>> may be the RO.
>>>>>
>>>>> [Denis] No. Once again: The "*User consent*" is different from what
>>>>> you call the "*RO consent*" (when/if it is required).
>>>>> The "RO consent" is not in fact a consent but the release of a
>>>>> capability to a client by one of the many R0s with which
>>>>> the GS has relationships.
>>>>>
>>>>> Since the second sentence is using the wording "often required" there
>>>>>> is no requirement to get the User consent.
>>>>>>
>>>>> User consent may not be required. There may not be a User. The consen=
t
>>>>> may have been gathered previously.
>>>>>
>>>>> [Denis] In order to follow the privacy principles, a "User consent"
>>>>> phase is required. The User is a natural person.
>>>>> A Client is called either by a User (i.e. a natural person) or by a
>>>>> Client application.
>>>>>
>>>>> The second sentence does not consider the possibility to get the User
>>>>>> consent in a place different from the GS.
>>>>>>
>>>>> Agreed. But we do agree that the GS gets the consent, either directly
>>>>> from the RO, or from the Client (in your example).
>>>>>
>>>>> [Denis] No. I disagree. In an ACL based systems, the GS does not need
>>>>> to ask or receive any consent.
>>>>> The client selects the set of attributes that it wants to be inserted
>>>>> into an access token.
>>>>> If the GS has the requested attributes, then it provides them,
>>>>> otherwise it returns an error to the Client.
>>>>>
>>>>> IMO, the User consent should be captured by the Client, i.e. not by
>>>>>> the GS.
>>>>>> The information used to obtain the User consent should be
>>>>>> standardized (... and it can be standardized).
>>>>>>
>>>>>> I think the abstract sequence as proposed by Francis is a great
>>>>>> addition, and would clarify where consent is in the sequence.
>>>>>>
>>>>>> The current sketch does not illustrate the place the User Consent is
>>>>>> captured, in particular by the Client.
>>>>>>
>>>>> It is an abstraction. The GS receives the consent. How consent is
>>>>> gathered is a detail that is dependent on the use case.
>>>>>
>>>>> [Denis] I really wonder whether there is really a "consent" to be
>>>>> received by the GS in both cases (i.e. ACLs or Capabilities).
>>>>>
>>>>>    - For ACLs, the consent needs to be done by the Client.
>>>>>    - For Capabilities, the current description is not clear since the
>>>>>    inputs and the outputs for this "consent" phase
>>>>>    are not currently described in the draft.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> Another important point to consider and to explain is related to th=
e
>>>>>>>> assurances that the user can obtain about
>>>>>>>> the respect of his choices. This point is currently left unanswere=
d
>>>>>>>> in draft-hardt-xauth-protocol-13.
>>>>>>>>
>>>>>>> This point is equally important: such assurance can only be obtaine=
d
>>>>>>> if the access token returned to the client
>>>>>>> is not considered to be opaque to the client. This is a necessary
>>>>>>> condition but not the single condition:
>>>>>>> the Client must also be in a position to capture/memorize the "User
>>>>>>> consent and choice" of the user in order to be able
>>>>>>> to verify it afterwards using the content of the access token(s).
>>>>>>>
>>>>>>
>>>>>> We disagree on this being a requirement for all use cases. It may be
>>>>>> in some.
>>>>>>
>>>>>> OK. Then this means that there will be no sentence in the draft such
>>>>>> as :
>>>>>> "access tokens returned to the client are not considered to be opaqu=
e
>>>>>> to the client".
>>>>>>
>>>>>
>>>>> For OAuth use cases, which GNAP supports, the access token is opaque
>>>>> to the Client. As you have noted, there are use cases where the acces=
s
>>>>> token is NOT opaque.
>>>>>
>>>>> [Denis] Wait a second. There is no requirement to support all OAuth
>>>>> use cases.
>>>>> I believe that there is a requirement to support OAuth 2.0 ASs, while
>>>>> the clients may be different
>>>>> and hence GNAP clients do not need to inherit of the limitations of
>>>>> OAuth 2.0 clients.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> If a RO needs to be involved and since a RO is directly associated
>>>>>>>>> with a RS, why can't it be directly queried
>>>>>>>>> by the appropriate RS after step (2) or later on ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Good question. Perhaps you can expand on a use case where that
>>>>>>>> would be useful?
>>>>>>>>
>>>>>>>> Before I expand, would you be able to explain first under which
>>>>>>>> circumstances a RO needs to be queried by a GS ?
>>>>>>>> How can the GS identify which RO to query ?
>>>>>>>>
>>>>>>> If the User is the RO, then the GS knows who to query.
>>>>>>>
>>>>>>> I still have difficulties to understand what you mean here.
>>>>>>> How could a GS know that "the User is the RO" ?  If "the User is th=
e
>>>>>>> RO", why does the GS needs to query the User ?
>>>>>>>
>>>>>>
>>>>>> To get consent?
>>>>>>
>>>>>> To get a "RO consent" to himself ???
>>>>>>
>>>>>
>>>>> The GS needs consent from the RO. If the RO is the User, then consent
>>>>> from the RO is equivalent to consent from the User.
>>>>>
>>>>> [Denis] See above.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> If the RO is a separate entity, then the GS knows the RO from the R=
S
>>>>>>> being queried.
>>>>>>>
>>>>>>>  ... and this gives the ability for the GS to log/trace all the RSs
>>>>>>> accessed by a given User and at which instant of time the access to=
ken has
>>>>>>> been granted.
>>>>>>>
>>>>>>> An example is a user would like access to an enterprise asset where
>>>>>>> a workflow is started to gain approval, and an administrator or man=
ager
>>>>>>> provides consent.
>>>>>>>
>>>>>>> Thanks for this example. I finally understand what you have in mind=
:
>>>>>>> you are considering using an access control model to build a *workf=
low
>>>>>>> model*.
>>>>>>> While it may be interesting to define a workflow model, this should
>>>>>>> be considered as a *separate and different work item*.
>>>>>>>
>>>>>>
>>>>>> The actual workflow is out of scope.
>>>>>>
>>>>>> I am glad you agree with this. But this means that your example was
>>>>>> not appropriate to illustrate your point.
>>>>>>
>>>>>
>>>>> It illustrates a use case where the RO and User are not the same
>>>>> party, and why the GS needs to query the RO, which was your question =
if I
>>>>> understood it correctly.
>>>>>
>>>>> [Denis] Since the inputs and the outputs for this "RO consent" phase
>>>>> are not currently described in the draft, the point is still unsolved=
.
>>>>>
>>>>> As soon as there is a RO consent obtained at the GS, the major proble=
m
>>>>>> is that the GS is able to act as Big Brother.
>>>>>> If a RO consent is performed at the RS, then the GS will not know wh=
o
>>>>>> the RS is: it is then unable to act as Big Brother,
>>>>>> even if it would enjoy to play that role.
>>>>>>
>>>>> In an enterprise use case, the GS's knowledge of who is accessing
>>>>> which RS is a feature.
>>>>>
>>>>> Do you mean that it is "normal" in an enterprise that a single point
>>>>> of control is able to trace all their actions ?
>>>>> From a security point of view, a single point of failure will have
>>>>> dramatic consequences.
>>>>>
>>>>> In your use cases, it seems that the RO is the User.
>>>>>
>>>>> I do hope that you have finally understood that, in my use case, the
>>>>> RO is **not** the User.
>>>>>
>>>>> The GS knows the User is wanting to let a Client access something. If
>>>>> the access token is generic, and could be presented to any RS that pr=
ovides
>>>>> a standardized function,
>>>>> then the GS does not know which RS is being accessed by a Client for
>>>>> the User. This seems to meet your privacy objectives. If not, what is=
 wrong?
>>>>>
>>>>> For security reasons, an access token needs to be targeted (which doe=
s
>>>>> not necessarily mean that an identifier of the RS shall be included i=
nto
>>>>> the access token).
>>>>>
>>>>> if the admin grants access, then the access granted to the client
>>>>>> changes.
>>>>>>
>>>>>>> The model you propose may be suited for an enterprise environment
>>>>>>> but is not scalable over the Internet.
>>>>>>>
>>>>>> It is one of the use cases we are working to address.
>>>>>>
>>>>>>> What is needed is an access control model usable over the Internet
>>>>>>> with millions of RSs and thousands of ASs/GSs.
>>>>>>>
>>>>>> I agree the model should also scale to internet scale.
>>>>>>
>>>>>> Fine. Another point on which we are in agreement.
>>>>>>
>>>>>> The model can scale to the Internet based on the following
>>>>>> assumptions:
>>>>>>
>>>>>> The flow starts with the steps (1) to (4) as illustrated by Francis,
>>>>>> i.e. the flow starts with a contact with a RS.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS =
|
>>>>>>  |RO | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Request =
    |
>>>>>>    |   |-------->|       |      |      |   |         |(2) Service In=
tent
>>>>>> |   |         |------>|      |      |   |         |(3) AuthZ Challen=
ge  |
>>>>>> |         |<------|      |      |   |         |(4) AuthZ Request    =
|   |
>>>>>>       |------------->|      |*
>>>>>>
>>>>>> The GS/AS does not need to have any prior relationship with ROs
>>>>>> and/or RSs.
>>>>>>
>>>>>> Furthermore, it is possible to prevent the GS to act as Big Brother
>>>>>> when the identity of the RS is not disclosed to the GS.
>>>>>>
>>>>>
>>>>> What happens after (4) above?
>>>>>
>>>>> [Denis] The key point is that we first need to agree on the first fou=
r
>>>>> exchanges. Do we ?
>>>>>
>>>>> The fifth exchange is different whether ACLs or Capabilities are bein=
g
>>>>> used.
>>>>>
>>>>>
>>>>>
>>>>>> Which information is supposed to be presented to the RO ?
>>>>>>>>> Which information is supposed to be returned by the RO ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Just like how the user authenticates to an AS, how the AS and RO
>>>>>>>> communicate is out of scope.
>>>>>>>>
>>>>>>>> At the moment, the usefulness of a dialogue between a GS and a RO
>>>>>>>> has not been explained, nor demonstrated.
>>>>>>>> The question is about the functionality of that dialogue in terms
>>>>>>>> of input and output information (and not about
>>>>>>>> the design of a protocol or of a user interface). Anyway, AFAIU a
>>>>>>>> dialogue between a GS and a RO is optional.
>>>>>>>>
>>>>>>>
>>>>>>> See enterprise example above.
>>>>>>>
>>>>>>> It is not an access control example, but a workflow example.
>>>>>>>
>>>>>>> Access  control has been defined a long time ago and the last
>>>>>>> edition of the model has been confirmed in year 1996: ISO/IEC 10181=
-3:
>>>>>>> 1996.
>>>>>>> "Information technology =E2=80=94 Open Systems Interconnection =E2=
=80=94 Security
>>>>>>> frameworks for open systems: Access control framework =E2=80=94 Par=
t 3".
>>>>>>>
>>>>>>> Two major functions have ben defined: an Access Control Enforcement=
 Function
>>>>>>> (AEF) and an Access Control Decision Function(ADF).
>>>>>>>
>>>>>>> Access Control Enforcement Function (AEF):
>>>>>>> A specialized function that is part of the access path between an
>>>>>>> initiator and a target on each access request and enforces the deci=
sion
>>>>>>> made by the ADF.
>>>>>>> Access Control Decision Function (ADF) :
>>>>>>> A specialized function that makes access control decisions by
>>>>>>> applying access control policy rules to an access request, ADI (of
>>>>>>> initiators, targets, access requests,
>>>>>>> or that retained from prior decisions), and the context in which th=
e
>>>>>>> access request is made.
>>>>>>>
>>>>>>> The role of the RO is to define the "access control policy rules"
>>>>>>> at the RS according to the context in which the access request is
>>>>>>> made.
>>>>>>>
>>>>>> I'm pretty familiar with access control systems. :)
>>>>>>
>>>>>> I would say that the access control is happening at the RS. The
>>>>>> client presents a token when accessing an API.
>>>>>> The RS uses the token, and any policy required, to make an access
>>>>>> decision.
>>>>>>
>>>>>> Fine. It looks like we are in agreement. Unfortunately, this is not
>>>>>> the case just below.
>>>>>>
>>>>>> Here is flow:
>>>>>>
>>>>>> 1) The Client requests access to an RS from the GS.
>>>>>>
>>>>>> No. We are no more in agreement. This is different from the flow
>>>>>> drawn by Francis.
>>>>>>
>>>>> My bad. Typo. I meant RO.
>>>>>
>>>>>
>>>>>> 2) The GS queries the RS if access should be granted.
>>>>>>
>>>>>>  No. The GS should not be forced to have a flow with the RS.
>>>>>>
>>>>> Same mistake as above, I meant RO.
>>>>>
>>>>>> 3) If access is granted, the GS creates an access token representing
>>>>>> the granted access, and returns it to the Client.
>>>>>>
>>>>>> This model is by no way conformant to ISO/IEC 10181-3: 1996
>>>>>>
>>>>> I'm unclear on why, or why it is even relevant.
>>>>>
>>>>>> 4) The Client presents the access token to the RS to show it has bee=
n
>>>>>> granted access.
>>>>>>
>>>>>> No. The client presents a token when accessing an API. The RS uses
>>>>>> the token, and any policy required, to make an access decision.
>>>>>> The token never contains an information like "Please grant an access
>>>>>> to the holder of this token".
>>>>>>
>>>>> Let me provide more clarity in the sentence:
>>>>>
>>>>> The Client presents the access token to the RS, to show the RS that
>>>>> the Client has been granted access to a resource at the RS by the GS.
>>>>>
>>>>> [Denis] This time, please consider both the ACLs approach and the
>>>>> Capabilities approach.
>>>>>
>>>>>
>>>>>
>>>>>> A couple advantages of this model:
>>>>>> - that the RS does not need to know much, if anything about the
>>>>>> Client.
>>>>>> - the access token MAY be self contained so that the Client does not
>>>>>> need to query the GS on each access.
>>>>>>
>>>>>> There are so many disadvantages that I will not list them.
>>>>>>
>>>>> Darn: I clearly was not firing on all cylinders when I typed this out=
.
>>>>> Let me correct:
>>>>>
>>>>> - the access token MAY be self contained so that the RS does not need
>>>>> to query the GS on each access to the RS by the Client.
>>>>>
>>>>> [Denis] A few comments in the case of a capability approach:
>>>>>
>>>>> - for each GS, the RS needs to locally manage which operation(s)
>>>>> is/are allowed to it.
>>>>>
>>>>> - the GS needs to establish a trusted communication channel or an
>>>>> authentication mechanism with each RO
>>>>>    (which is associated with an explicit RS identifier).
>>>>>
>>>>> - the GS could play the role of the RO and hence be in a position to
>>>>> issue any capability for any RS (without a "RO consent").
>>>>>
>>>>>    The target of an attack will clearly be the GS.
>>>>>
>>>>> I would not say that GNAP is an access control protocol, as how the R=
S
>>>>>> uses the token to determine access is out of scope.
>>>>>>
>>>>>> This is where we have a major discrepancy: how the RS uses the token
>>>>>> to determine access is *within* the scope.
>>>>>>
>>>>> [Denis] Do you agree or disagree ?
>>>>>
>>>>> The RS announces in advance to the client what it needs so that the
>>>>>> client can perform a a given operation and if the client supplies th=
e
>>>>>> requested attributes
>>>>>> obtained from some GS/AS(s) trusted by the RS, then access to that R=
S
>>>>>> is granted by the RS. If the RS cannot perform the requested operati=
on on
>>>>>> its own,
>>>>>> then the client should be informed about some requested attributes
>>>>>> that need to be obtained from some GS/AS(s) trusted by the next RS(s=
) in a
>>>>>> chain
>>>>>> for subsequent operations. The User consent should also be obtained
>>>>>> before performing the chaining operation.
>>>>>>
>>>>>> Chaining operations between RSs over the Internet is within the scop=
e
>>>>>> (... and may be achieved).
>>>>>>
>>>>> [Denis] Do you agree or disagree ?
>>>>>
>>>>> Denis
>>>>>
>>>>>
>>>>>>>
>>>>>>>> For many use cases, the User is the RO, and the interaction is
>>>>>>>> through a user interface, not a machine protocol.
>>>>>>>>
>>>>>>>> Wait a second. You wrote "the User is the RO". The User is
>>>>>>>> attempting to make an access to a RS by using a Client.
>>>>>>>> *That* User is not the RO of the RS.
>>>>>>>>
>>>>>>> The user being the RO is the initial use case for OAuth.
>>>>>>>
>>>>>>> OAuth 2.0 is no more mandating such a case.
>>>>>>>
>>>>>>
>>>>>> I don't know what you mean by that.
>>>>>>
>>>>>> Copy and paste from draft-ietf-oauth-security-topics:
>>>>>>
>>>>>> OAuth initially assumed a static relationship between client,
>>>>>> authorization server and resource servers.  (...)
>>>>>> With the increasing adoption of OAuth, this simple model dissolved
>>>>>> and, in several scenarios, was replaced
>>>>>> by a dynamic establishment of the relationship between clients on on=
e
>>>>>> side and the authorization and
>>>>>> resource servers of a particular deployment on the other side.
>>>>>>
>>>>>> This way, the same client could be used to access services of
>>>>>> different providers (in case of standard APIs,
>>>>>> such as e-mail or OpenID Connect) or serve as a frontend to a
>>>>>> particular tenant in a multi-tenancy environment.
>>>>>>
>>>>>>
>>>>> This sentence does not mention the RO or the Client. I'm confused wha=
t
>>>>> we are talking about
>>>>>
>>>>>>
>>>>>>
>>>>>>> A client application would like access to the user's photos at a
>>>>>>> photo sharing site. The resource is the user's photos. The user is =
the
>>>>>>> owner of that resource.
>>>>>>>
>>>>>>> If the user has already pre established the access control policy
>>>>>>> rules so that it can access to his own photos
>>>>>>> then he does not need to grant in real time any additional
>>>>>>> authorization.
>>>>>>>
>>>>>> I don't understand what you are trying to say. The photo sharing
>>>>>> example was a driving use case for the creation of OAuth.
>>>>>>
>>>>>> We would need to revisit the original scenario and consider if it ca=
n
>>>>>> be addressed in a different way than the original way.
>>>>>>
>>>>> The use case is the same. Is there a different solution you are
>>>>> proposing?
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Txauth mailing 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
>>>
>>>
>>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>

--00000000000063d42905ab8360be
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis

I did answer your question. Th=
e student is the User. The student is not the Client.

<=
/div>
3D""=E1=90=A7

On Tue, Jul 28, 2020 at 7:12 AM Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    
Hi Dick,

    


    

    
I am puzzled by your response. Your are
      the editor and a co-editor of the two following RFCs which state:
    


    

    
RFC 6749:=C2=A0=C2=A0=C2=A0 In the traditional
      client-server authentication model, the client requests an
      access-restricted 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 (protected resource) on=
 the server by
      authenticating with the server (...) 

      

      RFC 6750 : The client uses the access token to access the
      protected resources hosted by the resource server. 

      

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 following two steps are s=
pecified within
      this document:

      

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (E)=C2=A0 The client requests the
      protected resource from the resource server and authenticates 

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 by presenting the access
      token.

      

      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (F)=C2=A0 The resource server validates
      the access token, and if valid, serves the request.

    

    


    

    
In my use case, the student connects to
      the University server (i.e. a RS) as a client. The University
      server cannot be a Client.

      If you change/twist that basic vocabulary, we will not be able to
      understand each other any more.

    


    

    
BTW, my first question still remains:
      Would you explain how you would handle the use case of a student
      registering to a new University ?

    


    

    
Denis

    
=C2=A0 

    

    

     =20
      
Hi Denis
        


        

        
The student (User) goes to the registration page of the
          University (the Client)

        


        

        
Similar to your example, the Client has a list of GS that
          it are acceptable, or RS that may be acceptable.

        


        

        
If the User selects a GS, then the Client starts a GNAP
          flow with the GS.

        


        

        
If the User selects an RS, then the Client can call the RS
          to determine which GSes to offer the User to use to get access
          to the RS.

        


        

        
In summary, the University=C2=A0wants to consume Claims about
          the User, so it is the Client.

          


          

          
/Dick

          


          

          


          

          

          

            
On Mon, Jul 27, 2020 at
              12:49 AM Denis <denis.ietf@free.fr>
              wrote:

            

            

              

                
Hi Dick,

                


                

                
The floor is yours.

                


                

                
Would you explain how you would handle the use case
                  of a student registering to a new University ?

                


                

                
Would you also elaborate why in my explanations
                  below, you think that "the University's=C2=A0reg=
istration
                  system is the Client, not a Resource Server" ?
                  


                  

                

                
Denis

                

                

                

                  
Hi Denis
                    


                    

                    
I would think in your example below, that the
                      University's=C2=A0registration system is the Clie=
nt,
                      not a Resource Server.

                    


                    

                    
Have a good night's sleep!

                    


                    

                    


                    

                  

                  

                  

                    
On Fri, Jul 24,
                      2020 at 12:04 PM Denis <denis.ietf@free.fr>
                      wrote:

                    

                    

                      

                        
Hi Dick,

                          

                        

                        
In order to send back a quick reply
                          tonight, I will only respond to one of your
                          questions:

                        

                          
 [Denis] How would be the data
                            flow when access tokens from two GSs are
                            needed by a RS ?

                            


                            

                            
[Dick] I don't know of a use case wher=
e
                              two tokens would be needed by an RS. Would
                              you elaborate?

                          

                          
I already described on the list the case
                            of a student registering to a new
                            University.

                          
 

                          

                          
First, the student connects to the RS
                            from the new University and opens an account
                            

                            (at this time the student is using a pseudo
                            and a private key to authenticate). He fills
                            some forms 

                            and indicate its citizenship, his home
                            address and his graduation in his current
                            university. 

                            

                            When he is finished, he indicates that he
                            wants to perform a Registration operation.
                          


                          

                          
From the information gathered in the
                            forms, the RS informs the client that it
                            needs two access tokens:

                          
    
                            
  • one to demonstrate that his name and
                              current home address are correct,and
    • 
                            
  • another one to demonstrate that he got a
                              graduation from its current University.
    • 
                          

                          
Depending upon the information captured
                            in the forms, the RS also indicates which
                            ASs/GSs are acceptable 

                            and which kind of attributes are requested.
                          
 

                          

                          
The user consent and choice is performed
                            by the client and once approved by the
                            student, two access tokens are separately
                            requested.

                            Finally, two access tokens are presented to
                            the RS while invoking a Registration
                            operation.

                          


                          

                          
Note that the start of the story is to
                            open an account, e.g. using FIDO. The needs
                            of the RS are only disclosed to the student
                            once he has filled some forms 

                            and indicated that he wanted to perform a
                            Registration operation. Thus, the needs that
                            are revealed by the RS are dependant both
                            upon the operation 

                            that the student is willing to perform and
                            the information collected in the forms.

                          


                          

                          
Denis

                        

                        

                        

                          

                            
Hi Denis, comments inserted ...=C2=A0
                            

                            

                              
On Fri,
                                Jul 24, 2020 at 9:08 AM Denis <denis.ietf@free.fr>
                                wrote:

                              

                              

                                

                                  

                                    
Hi Dick,

                                    


                                    

                                    
draft-hardt-xauth-protocol-13
                                      describes a solution without
                                      clearly stating what the
                                      problem(s) to be solved is/are.

                                  

                                

                              

                              


                              

                              
I agree that the problem description
                                is not as crisp as I would like it to
                                be. A challenge is that there is a broad
                                spectrum of use cases solved by OAuth 2,
                                and OpenID Connect, as well as the new
                                use cases that are solved by GNAP.

                              


                              

                              
That is why I am suggesting we gather
                                some use cases so we have a common
                                understanding of the problems that are
                                in scope.

                              
=C2=A0

                              

                                

                                  

                                    


                                    

                                    
At the moment,
                                      draft-hardt-xauth-protocol-13
                                      includes a single figure on page 4
                                      and from previous discussions I
                                      understood that 

                                      it is no more up-to-date since the
                                      first data flow is now a contact
                                      with a RS. The reason(s) for the
                                      GS to contact a RO has still not 

                                      been explained (since the inputs
                                      and outputs are not described).
                                      The discovery information made
                                      available at various steps at the
                                      RS 

                                      is not described.

                                    

                                  

                                

                              

                              


                              

                              
I have made no updates as we are in a
                                quiet period prior to the WG meeting
                                next week when documents cannot be
                                updated.

                              
=C2=A0

                              

                                

                                  

                                    

                                      


                                      

                                    

                                    
Figure 4 shows only a single
                                      RS. Is the relaying of one
                                      operation by that RS to a second
                                      RS in the scope of this document ?
                                      If yes, how is it handled ?

                                    

                                  

                                

                              

                              


                              

                              
I view that as an advanced use case
                                that would be covered in a separate
                                document.

                              
=C2=A0

                              

                                

                                  

                                    
 

                                    


                                    

                                    
Figure 4 shows only a single
                                      GS. How would be the data flow
                                      when access tokens from two GSs
                                      are needed by a RS ?

                                    

                                  

                                

                              

                              


                              

                              
I don't know of a use case where two
                                tokens would be needed by an RS. Would
                                you elaborate?

                              
The RS being able to accept tokens
                                from two different GSes is covered, but
                                the Client is only using a token from
                                one GS at a time.

                              


                              

                              
=C2=A0

                              

                                

                                  

                                    
 

                                    

                                    What we need first is not a set of
                                    "use cases" but a clear model=
 with a
                                    data flows and a list of its
                                    properties/characteristics. 

                                  

                                

                              

                              


                              

                              
I disagree. The use cases describe
                                the problems we are looking to solve.
                                The data flows are part of the solution.
                                For example, from my understanding of
                                your use case, you don't want the GS to
                                have visibility into the User's
                                activity. Am I correct that this is one
                                of your requirements for your use case?
                              


                              

                              
=C2=A0

                              

                                

                                  
 

                                  
Then after, we can understand
                                    much better which use cases can/will
                                    be supported. For example, shall a
                                    RS (or its RO) have 

                                    prior relationships with the GS ?
                                    What is the difference/implications
                                    when it has or it hasn't ?

                                  

                                  


                                  

                                  
In order to have a fair
                                    comparison, we should try to list
                                    model properties/characteristics.

                                  


                                  

                                  
At the moment, the model I have
                                    described including the data flows
                                    is clear. The discovery information
                                    made available by a RS is clear.

                                  
I have not listed all its
                                    properties/characteristics of that
                                    model, but I am pretty sure that you
                                    already have a flavour of it.

                                  


                                  

                                  
In the mean time, it would be
                                    nice if you could show using two
                                    figures:

                                  
    
                                    
  • the case of the relaying of one
                                      operation by one RS to a second RS
                                      (if it is in the scope of your
                                      document),
    • 
                                    
  • the case where access tokens
                                      from two GSs are needed by one RS
                                      (if it is in the scope of your
                                      document).
    
                                    
    • 
                                  

                                

                              

                              


                              

                              
See above

                              
=C2=A0

                              

                                

                                  
    
                                    
  •  
    
                                    
    • 
                                  

                                  

                                    
Denis

                                  

                                  


                                  

                                  

                                    
Hi Denis
                                      


                                      

                                      
I think it would be useful to
                                        take a step back and for you to
                                        describe your use case. 

                                        After that, we can explore the
                                        different ways that your use
                                        case can be addressed.=C2=A0

                                      


                                      

                                      
Looking at your previous
                                        communication, it describes the
                                        solution, and the justification,
                                        

                                        but it is not clear what use
                                        cases you are needing to solve.
                                      


                                      

                                      
/Dick

                                      


                                      

                                      


                                      

                                    

                                    
3D""=E1=90=A7

                                    

                                    

                                      
On
                                        Wed, Jul 22, 2020 at 9:34 AM
                                        Denis <denis.ietf@free.fr>
                                        wrote:

                                      

                                      

                                        

                                          
Hello Dick,

                                          


                                          

                                          
I have identified the
                                            reason of the major
                                            difference between our two
                                            approaches.

                                          


                                          

                                          
Access control may be
                                            performed using either ACLs
                                            (Access Control Lists) or
                                            Capabilities.

                                          


                                          

                                          
Note : a
                                            capability identifies a
                                            resource and an allowed
                                            operation that can be
                                            performed on that resource.

                                          

                                          


                                          

                                          
You are advocating a
                                            Capabilities approach while
                                            I am advocating an ACL
                                            approach.

                                          
The capabilities approach
                                            allows the GS to trace every
                                            operation performed by the
                                            users on any RS known by a
                                            GS.

                                            The management of these
                                            capabilities is made via the
                                            GS or at the GS by the
                                            various ROs. If the
                                            management is made 

                                            via the GS, then a trusted
                                            communication channel needs
                                            to be established with every
                                            RO. If the management is
                                            made 

                                            at the GS, then an
                                            authentication mechanism
                                            needs to be established with
                                            every RO. In the last case,
                                            the GS has the 

                                            ability to know all the
                                            capabilities of the users
                                            whether they are used or
                                            not. The less that can be
                                            said is that this model 

                                            is not privacy friendly.

                                          
With the ACL approach, a RO
                                            directly manages an ACL
                                            placed in front of each RS.
                                            The Access Control Decision
                                              Function 

                                                (ADF)
                                              at the RS is able to keep
                                              track from prior
                                              decisions. The GS
                                            is kept ignorant of the
                                            content of these ACLs and
                                            only 

                                            delivers to its clients
                                            attributes that are placed
                                            into access tokens. Such a
                                            model may be privacy
                                            friendly.

                                          
Other comments are between
                                            the lines prefixed with
                                            [Denis].

                                          

                                            

                                              


                                                

                                                  
On
                                                    Tue, Jul 21, 2020 at
                                                    11:26 AM Denis <denis.ietf@free.fr&=
gt;
                                                    wrote:

                                                  

                                                  

                                                    

                                                      
Hello Dick,
                                                      


                                                      

                                                      
 Thank you
                                                        for your
                                                        feedback.
                                                        Comments are
                                                        between the
                                                        lines.

                                                      


                                                      

                                                      

                                                        

                                                          
=
comments
                                                          inserted ...=C2=
=A0

                                                          

                                                          

                                                          
On Tue, Jul 21, 2020 at 6:03 AM Denis <denis.ietf@free.fr> wrot=
e:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Dick,

                                                          


                                                          

                                                          
I
                                                          duplicate the
                                                          most important
                                                          comment at the
                                                          beginning of
                                                          this email:

                                                          

                                                          
You are
                                                          considering
                                                          using an
                                                          access control
                                                          model to build
                                                          a workflow
                                                          model.

                                                           

                                                          While it may
                                                          be interesting
                                                          to define a
                                                          workflow
                                                          model, this
                                                          should be
                                                          considered 

                                                          as a separate
                                                          and different
                                                          work item.

                                                          

                                                          
See the
                                                          other comments
                                                          between the
                                                          lines.

                                                          

                                                          


                                                          

                                                          

                                                          
=
On
                                                          Mon, Jul 20,
                                                          2020 at 2:05
                                                          AM Denis <denis.ietf@free.fr&=
gt;
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hi Dick,
                                                          


                                                          

                                                          

                                                          
=
On
                                                          Fri, Jul 17,
                                                          2020 at 9:21
                                                          AM Denis <denis.ietf@free.fr&=
gt;
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Francis and
                                                          Dick,

                                                          


                                                          

                                                          
The good
                                                          news first: we
                                                          are making
                                                          some progress.
                                                          We are now
                                                          close to an
                                                          agreement with
                                                          steps (1) up
                                                          to (3), 

                                                          ... except
                                                          that the place
                                                          where the user
                                                          consent is
                                                          captured is
                                                          not
                                                          mentioned/indicat=
ed.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          This major
                                                          question which
                                                          is currently
                                                          left
                                                          unanswered is
                                                          where, when
                                                          and how the
                                                          user consent
                                                          is captured.

                                                          

                                                          

                                                          


                                                          

                                                          
When is
                                                          covered, per
                                                          the sequence.
                                                          How and where
                                                          are out of
                                                          scope of what
                                                          I drafted. 

                                                          

                                                          

                                                          

                                                          

                                                          
It is clear
                                                          that the "Us=
er
                                                          consent and
                                                          choice" is n=
ot
                                                          currently
                                                          addressed in
                                                          the draft, but
                                                          it should.

                                                          The support of
                                                          the "User
                                                          consent and
                                                          choice" has
                                                          strong
                                                          implications
                                                          not only in
                                                          the sequences
                                                          of the
                                                          exchanges 

                                                          but also by
                                                          which entity
                                                          it should be
                                                          performed.

                                                          

                                                          

                                                          
"consen=
t"
                                                          is in the
                                                          latest draft 7
                                                          times. 

                                                          

                                                          

                                                        

                                                      

                                                      
"Consent"=
; is
                                                        present 5 times.
                                                        The User consent
                                                        is different
                                                        from the RO
                                                        consent (when/if
                                                        it is required).
                                                        

                                                      

                                                      

                                                        
The server
                                                          acquires
                                                          consent and
                                                          authorization
                                                          from the user
                                                          and/or
                                                          resource owner
                                                          if
                                                          required.

                                                        

                                                        
User consent
                                                          is often
                                                          required
                                                          at the GS.
                                                          GNAP enables a
                                                          Client and=C2=A0 =
GS
                                                          to negotiate
                                                          the
                                                          interaction
                                                          mode for the
                                                          GS to obtain
                                                          consent.

                                                        

                                                        
 The GS may
                                                          require
                                                          explicit
                                                          consent from
                                                          the RO or User
                                                          to provide
                                                          these to the
                                                          Client.

                                                        

                                                      

                                                      
The User
                                                        consent is not
                                                        an alternative
                                                        to the RO
                                                        consent. So
                                                        using "and/or&=
quot;
                                                        in the first
                                                        sentence is
                                                        incorrect.

                                                    

                                                  

                                                  


                                                  

                                                  
My language is
                                                    sloppy there.
                                                    Consent is always
                                                    from the RO. The
                                                    User may be the RO.
                                                

                                              

                                            

                                          

                                          
[Denis] No. Once again: The
                                            "User consent"=
 is
                                            different from what you call
                                            the "RO consent&quo=
t;
                                            (when/if it is required). 

                                            The "RO consent" is n=
ot in
                                            fact a consent but the
                                            release of a capability to a
                                            client by one of the many
                                            R0s with which 

                                            the GS has relationships. 

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
Since the
                                                        second sentence
                                                        is using the
                                                        wording "often
                                                        required" ther=
e
                                                        is no
                                                        requirement to
                                                        get the User
                                                        consent.

                                                      

                                                    

                                                  

                                                  
User consent may
                                                    not be required.
                                                    There may not be a
                                                    User. The consent
                                                    may have been
                                                    gathered previously.
                                                

                                              

                                            

                                          

                                          
[Denis] In order to follow
                                            the privacy principles, a
                                            "User consent" phase =
is
                                            required. The User is a
                                            natural person.

                                            A Client is called either by
                                            a User (i.e. a natural
                                            person) or by a Client
                                            application. 

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
 

                                                      
The second
                                                        sentence does
                                                        not consider the
                                                        possibility to
                                                        get the User
                                                        consent in a
                                                        place different
                                                        from the GS.

                                                    

                                                  

                                                  
Agreed. But we do
                                                    agree that the GS
                                                    gets the consent,
                                                    either directly from
                                                    the RO, or from the
                                                    Client (in your
                                                    example).

                                                

                                              

                                            

                                          

                                          
[Denis] No. I disagree. In
                                            an ACL based systems, the GS
                                            does not need to ask or
                                            receive any consent.

                                            The client selects the set
                                            of attributes that it wants
                                            to be inserted into an
                                            access token.

                                            If the GS has the requested
                                            attributes, then it provides
                                            them, otherwise it returns
                                            an error to the Client.

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
IMO, the User
                                                        consent should
                                                        be captured by
                                                        the Client, i.e.
                                                        not by the GS. 

                                                        The information
                                                        used to obtain
                                                        the User consent
                                                        should be
                                                        standardized
                                                        (... and it can
                                                        be
                                                        standardized).

                                                      

                                                      

                                                        

                                                          
I
                                                          think the
                                                          abstract
                                                          sequence as
                                                          proposed by
                                                          Francis is a
                                                          great
                                                          addition, and
                                                          would clarify
                                                          where consent
                                                          is in the
                                                          sequence. 

                                                        

                                                      

                                                      
The current
                                                        sketch does not
                                                        illustrate the
                                                        place the User
                                                        Consent is
                                                        captured, in
                                                        particular by
                                                        the Client.

                                                    

                                                  

                                                  
It is an
                                                    abstraction. The GS
                                                    receives the
                                                    consent. How consent
                                                    is gathered is a
                                                    detail that is
                                                    dependent on the use
                                                    case.

                                                

                                              

                                            

                                          

                                          
[Denis] I really wonder
                                            whether there is really a
                                            "consent" to be recei=
ved by
                                            the GS in both cases (i.e.
                                            ACLs or Capabilities).

                                          

                                          
    
                                            
  • For ACLs, the consent
                                              needs to be done by the
                                              Client.
    • 
                                            
  • For Capabilities, the
                                              current description is not
                                              clear since the inputs and
                                              the outputs for this
                                              "consent" phase
    
                                              are not currently
                                              described in the draft.
    • 
                                          

                                          

                                            

                                              

                                                

                                                  
=C2=A0

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 Another
                                                          important
                                                          point to
                                                          consider and
                                                          to explain is
                                                          related to the
                                                          assurances
                                                          that the user
                                                          can obtain
                                                          about 

                                                          the respect of
                                                          his choices.
                                                          This point is
                                                          currently left
                                                          unanswered in
draft-hardt-xauth-protocol-13.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
This point
                                                          is equally
                                                          important:
                                                          such assurance
                                                          can only be
                                                          obtained if
                                                          the access
                                                          token returned
                                                          to the client
                                                          

                                                          is not
                                                          considered to
                                                          be opaque to
                                                          the client.
                                                          This is a
                                                          necessary
                                                          condition but
                                                          not the single
                                                          condition: 

                                                          the Client
                                                          must also be
                                                          in a position
                                                          to
                                                          capture/memorize
                                                          the "User
                                                          consent and
                                                          choice" of t=
he
                                                          user in order
                                                          to be able 

                                                          to verify it
                                                          afterwards
                                                          using the
                                                          content of the
                                                          access
                                                          token(s).

                                                          

                                                          

                                                          


                                                          

                                                          
We
                                                          disagree on
                                                          this being a
                                                          requirement
                                                          for all use
                                                          cases. It may
                                                          be in some. 

                                                          

                                                          

                                                        

                                                      

                                                      
OK. Then this
                                                        means that there
                                                        will be no
                                                        sentence in the
                                                        draft such as :

                                                        "access tokens
                                                        returned to the
                                                        client are not
                                                        considered to be
                                                        opaque to the
                                                        client".

                                                    

                                                  

                                                  


                                                  

                                                  
For OAuth use
                                                    cases, which GNAP
                                                    supports, the access
                                                    token is opaque to
                                                    the Client. As you
                                                    have noted, there
                                                    are use cases where
                                                    the access token is
                                                    NOT opaque.

                                                

                                              

                                            

                                          

                                          
[Denis] Wait a second.
                                            There is no requirement to
                                            support all OAuth use cases.
                                            

                                            I believe that there is a
                                            requirement to support OAuth
                                            2.0 ASs, while the clients
                                            may be different 

                                            and hence GNAP clients do
                                            not need to inherit of the
                                            limitations of OAuth 2.0
                                            clients.

                                          

                                            

                                              

                                                

                                                  
=C2=A0

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
If a RO
                                                          needs to be
                                                          involved and
                                                          since a RO is
                                                          directly
                                                          associated
                                                          with a RS, why
                                                          can't it be
                                                          directly
                                                          queried 

                                                          by the
                                                          appropriate RS
                                                          after step (2)
                                                          or later on ?
                                                          

                                                          

                                                          


                                                          

                                                          
Good
                                                          question.
                                                          Perhaps you
                                                          can expand on
                                                          a use case
                                                          where that
                                                          would be
                                                          useful?

                                                          

                                                          

                                                          

                                                          
Before I
                                                          expand, would
                                                          you be able to
                                                          explain first
                                                          under which
                                                          circumstances
                                                          a RO needs to
                                                          be queried by
                                                          a GS ?

                                                          How can the GS
                                                          identify which
                                                          RO to query ?

                                                          

                                                          

                                                          
If the
                                                          User is the
                                                          RO, then the
                                                          GS knows who
                                                          to query. 

                                                          

                                                          

                                                          

                                                          

                                                          
I still
                                                          have
                                                          difficulties
                                                          to understand
                                                          what you mean
                                                          here. 

                                                          How could a GS
                                                          know that "t=
he
                                                          User is the
                                                          RO" ?=C2=A0 =
If "the
                                                          User is the
                                                          RO", why doe=
s
                                                          the GS needs
                                                          to query the
                                                          User ? 

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
To get
                                                          consent?

                                                          

                                                        

                                                      

                                                      
To get a "RO
                                                        consent" to
                                                        himself ???

                                                    

                                                  

                                                  


                                                  

                                                  
The GS needs
                                                    consent from the RO.
                                                    If the RO is the
                                                    User, then consent
                                                    from the RO is
                                                    equivalent to
                                                    consent from the
                                                    User.

                                                

                                              

                                            

                                          

                                          
[Denis] See above.

                                          

                                          

                                            

                                              

                                                

                                                  
=C2=A0

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
If the RO
                                                          is a separate
                                                          entity, then
                                                          the GS knows
                                                          the RO from
                                                          the RS being
                                                          queried. 

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0... and
                                                          this gives the
                                                          ability for
                                                          the GS to
                                                          log/trace all
                                                          the RSs
                                                          accessed by a
                                                          given User and
                                                          at which
                                                          instant of
                                                          time the
                                                          access token
                                                          has been
                                                          granted.

                                                          

                                                          

                                                          

                                                          
An
                                                          example=C2=A0is a
                                                          user would
                                                          like access to
                                                          an enterprise
                                                          asset where a
                                                          workflow is
                                                          started to
                                                          gain approval,
                                                          and an
                                                          administrator
                                                          or manager
                                                          provides
                                                          consent.

                                                          

                                                          

                                                          

                                                          
Thanks for
                                                          this example.
                                                          I finally
                                                          understand
                                                          what you have
                                                          in mind: you
                                                          are
                                                          considering
                                                          using an
                                                          access control
                                                          model to build
                                                          a workflow
                                                          model. 

                                                          While it may
                                                          be interesting
                                                          to define a
                                                          workflow
                                                          model, this
                                                          should be
                                                          considered as
                                                          a separate
                                                          and different
                                                          work item.
                                                          

                                                          

                                                          


                                                          

                                                          
The
                                                          actual
                                                          workflow is
                                                          out of scope.
                                                          

                                                          

                                                        

                                                      

                                                      
I am glad you
                                                        agree with this.
                                                        But this means
                                                        that your
                                                        example was not
                                                        appropriate to
                                                        illustrate your
                                                        point.

                                                      

                                                    

                                                  

                                                  


                                                  

                                                  
It illustrates a
                                                    use case where the
                                                    RO and User are not
                                                    the same party, and
                                                    why the GS needs to
                                                    query the RO, which
                                                    was your question if
                                                    I understood it
                                                    correctly.

                                                

                                              

                                            

                                          

                                          
[Denis] Since the inputs
                                            and the outputs for this "=
RO
                                            consent" phase are not
                                            currently described in the
                                            draft, the point is still
                                            unsolved.

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
 As soon as
                                                        there is a RO
                                                        consent obtained
                                                        at the GS, the
                                                        major problem is
                                                        that the GS is
                                                        able to act as
                                                        Big Brother.

                                                        If a RO consent
                                                        is performed at
                                                        the RS, then the
                                                        GS will not know
                                                        who the RS is:
                                                        it is then
                                                        unable to act as
                                                        Big Brother, 

                                                        even if it would
                                                        enjoy to play
                                                        that role.

                                                    

                                                  

                                                  
In an enterprise
                                                    use case, the GS's
                                                    knowledge of who is
                                                    accessing which RS
                                                    is a feature.

                                                

                                              

                                            

                                          

                                          
Do you mean that it is
                                            "normal" in an enterp=
rise
                                            that a single point of
                                            control is able to trace all
                                            their actions ? 

                                            From a security point of
                                            view, a single point of
                                            failure will have dramatic
                                            consequences.

                                          

                                            

                                              

                                                

                                                  
In your use
                                                    cases, it seems that
                                                    the RO is the User.
                                                  

                                                

                                              

                                            

                                          

                                          
I do hope that you have
                                            finally understood that, in
                                            my use case, the RO is
                                            **not** the User.

                                          

                                            

                                              

                                                

                                                  
The GS knows the
                                                    User is wanting to
                                                    let a Client access
                                                    something. If the
                                                    access token is
                                                    generic, and could
                                                    be presented to any
                                                    RS that provides a
                                                    standardized
                                                    function, 

                                                    then the GS does not
                                                    know which RS is
                                                    being accessed by a
                                                    Client for the User.
                                                    This seems to meet
                                                    your privacy
                                                    objectives. If not,
                                                    what is wrong?

                                                

                                              

                                            

                                          

                                          
For security reasons, an
                                            access token needs to be
                                            targeted (which does not
                                            necessarily mean that an
                                            identifier of the RS shall
                                            be included into the access
                                            token).

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
if the
                                                          admin grants
                                                          access, then
                                                          the access
                                                          granted to the
                                                          client
                                                          changes. 

                                                          

                                                          

                                                          

                                                          
 

                                                          
The model
                                                          you propose
                                                          may be suited
                                                          for an
                                                          enterprise
                                                          environment
                                                          but is not
                                                          scalable over
                                                          the Internet.

                                                          

                                                          

                                                          
It is one
                                                          of the use
                                                          cases we are
                                                          working to
                                                          address. 

                                                          

                                                          

                                                          

                                                          
 What is
                                                          needed is an
                                                          access control
                                                          model usable
                                                          over the
                                                          Internet with
                                                          millions of
                                                          RSs and
                                                          thousands of
                                                          ASs/GSs.=C2=A0 
                                                          

                                                          

                                                          

                                                          
I agree
                                                          the model
                                                          should also
                                                          scale to
                                                          internet
                                                          scale. 

                                                          

                                                          

                                                        

                                                      

                                                      
Fine. Another
                                                        point on which
                                                        we are in
                                                        agreement. 

                                                      

                                                      
The model can
                                                        scale to the
                                                        Internet based
                                                        on the following
                                                        assumptions:

                                                      

                                                        
The flow
                                                          starts with
                                                          the steps (1)
                                                          to (4) as
                                                          illustrated by
                                                          Francis, i.e.
                                                          the flow
                                                          starts with a
                                                          contact with a
                                                          RS.

                                                      

                                                      
+----+
                                                          =C2=A0+------+
                                                          =C2=A0+---+ =C2=
=A0+---+
                                                          =C2=A0+---+

                                                          |User|
                                                          =C2=A0|Client| =
=C2=A0|RS
                                                          | =C2=A0|GS | =C2=
=A0|RO
                                                          |

                                                          +----+
                                                          =C2=A0+------+
                                                          =C2=A0+---+ =C2=
=A0+-+-+
                                                          =C2=A0+-+-+

                                                          =C2=A0 |(1) Servi=
ce
                                                          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
                                                          |(2) Service
                                                          Intent =C2=A0 |
                                                          =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =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) AuthZ
                                                          Challenge =C2=A0|=


                                                          =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =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) AuthZ
                                                          Request =C2=A0 =
=C2=A0|

                                                          =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =C2=A0
                                                          |------------->=
;|
                                                          =C2=A0 =C2=A0 =C2=
=A0|

                                                      
The GS/AS does
                                                        not need to have
                                                        any prior
                                                        relationship
                                                        with ROs and/or
                                                        RSs.

                                                      
Furthermore, it
                                                        is possible to
                                                        prevent the GS
                                                        to act as Big
                                                        Brother when the
                                                        identity of the
                                                        RS is not
                                                        disclosed to the
                                                        GS.

                                                      

                                                    

                                                  

                                                  


                                                  

                                                  
What happens
                                                    after (4) above? 

                                                  

                                                

                                              

                                            

                                          

                                          
[Denis] The key point is
                                            that we first need to agree
                                            on the first four exchanges.
                                            Do we ?

                                          

                                          
The fifth exchange is
                                            different whether ACLs or
                                            Capabilities are being used.
                                          

                                          

                                            

                                              

                                                

                                                  
=C2=A0

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
Which
                                                          information is
                                                          supposed to be
                                                          presented to
                                                          the RO ?

                                                          Which
                                                          information is
                                                          supposed to be
                                                          returned by
                                                          the RO ?

                                                          

                                                          

                                                          


                                                          

                                                          
Just like
                                                          how the user
                                                          authenticates
                                                          to an AS, how
                                                          the AS and RO
                                                          communicate is
                                                          out of scope.

                                                          

                                                          

                                                          

                                                          

                                                          
At the
                                                          moment, the
                                                          usefulness of
                                                          a dialogue
                                                          between a GS
                                                          and a RO has
                                                          not been
                                                          explained, nor
                                                          demonstrated.

                                                          The question
                                                          is about the
                                                          functionality
                                                          of that
                                                          dialogue in
                                                          terms of input
                                                          and output
                                                          information
                                                          (and not about
                                                          

                                                          the design of
                                                          a protocol or
                                                          of a user
                                                          interface).
                                                          Anyway, AFAIU
                                                          a dialogue
                                                          between a GS
                                                          and a RO is
                                                          optional.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
See
                                                          enterprise
                                                          example above.
                                                          

                                                          

                                                          

                                                          
It is not
                                                          an access
                                                          control
                                                          example, but a
                                                          workflow
                                                          example.

                                                          
Access=C2=A0
                                                          control has
                                                          been defined a
                                                          long time ago
                                                          and the last
                                                          edition of the
                                                          model has been
                                                          confirmed in
                                                          year 1996: =
ISO/IEC=C2=A010181-3: 1996.

                                                          "Information
                                                          technology=C2=A0=
=E2=80=94
                                                          Open Systems
                                                          Interconnection=
=C2=A0=E2=80=94
                                                          Security
                                                          frameworks for
                                                          open systems:
                                                          Access control
                                                          framework=C2=A0=
=E2=80=94
                                                          Part=C2=A03"=
.

                                                          
Two major functions have ben defi=
ned: an Access =
Control Enforcement Function
                                                          (AEF) and an Access
                                                          Control
                                                          Decision
                                                          Function(ADF).

                                                          

                                                          
Access
                                                          Control Enf=
orcement
                                                          Function
                                                          (AEF):

                                                          A specialized
                                                          function that
                                                          is part of the
                                                          access path
                                                          between an
                                                          initiator and
                                                          a target on
                                                          each access
                                                          request and
                                                          enforces the
                                                          decision made
                                                          by the ADF.

                                                          Access Control Decision
                                                          Function
                                                          (ADF) :

                                                          A
                                                          specialized
                                                          function that
                                                          makes access
                                                          control
                                                          decisions by
                                                          applying
                                                          access control
                                                          policy rules
                                                          to an access
                                                          request, ADI
                                                          (of
                                                          initiators,
                                                          targets,
                                                          access
                                                          requests, =


                                                          or
                                                          that retained
                                                          from prior
                                                          decisions),
                                                          and the
                                                          context in
                                                          which the
                                                          access request
                                                          is made.
                                                          
The role of
                                                          the RO is to
                                                          define the "=
access control policy rules" at th=
e RS
                                                          according to
                                                          the context
                                                          in which the
                                                          access request
                                                          is made.

                                                          

                                                          

                                                          
I'm
                                                          pretty
                                                          familiar with
                                                          access control
                                                          systems. :)=C2=A0=


                                                          


                                                          

                                                          
I would
                                                          say that the
                                                          access control
                                                          is happening
                                                          at the RS. The
                                                          client
                                                          presents a
                                                          token when
                                                          accessing an
                                                          API. 

                                                          The RS uses
                                                          the token, and
                                                          any policy
                                                          required, to
                                                          make an access
                                                          decision.

                                                          

                                                        

                                                      

                                                      
Fine. It looks
                                                        like we are in
                                                        agreement.
                                                        Unfortunately,
                                                        this is not the
                                                        case just below.
                                                      

                                                      

                                                        

                                                          

                                                          
Here is
                                                          flow:

                                                          


                                                          

                                                          
1) The
                                                          Client
                                                          requests
                                                          access to an
                                                          RS from the
                                                          GS. 

                                                          

                                                          

                                                        

                                                      

                                                      
No. We are no
                                                        more in
                                                        agreement. This
                                                        is different
                                                        from the flow
                                                        drawn by
                                                        Francis.

                                                    

                                                  

                                                  
My bad. Typo. I
                                                    meant RO.

                                                  
=C2=A0

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
2) The GS
                                                          queries the RS
                                                          if access
                                                          should be
                                                          granted. 

                                                          

                                                          

                                                        

                                                      

                                                      
=C2=A0No. The GS
                                                        should not be
                                                        forced to have a
                                                        flow with the
                                                        RS.

                                                    

                                                  

                                                  
Same mistake as
                                                    above, I meant RO.=C2=
=A0

                                                  

                                                    

                                                      
 

                                                      

                                                        

                                                          

                                                          
3) If
                                                          access is
                                                          granted, the
                                                          GS creates an
                                                          access token
                                                          representing
                                                          the granted
                                                          access, and
                                                          returns it to
                                                          the Client. 

                                                          

                                                          

                                                        

                                                      

                                                      
This model is
                                                        by no way
                                                        conformant to ISO/IEC=C2=A010181-3: 1996 

                                                          
                                                    

                                                  

                                                  
I'm unclear on
                                                    why, or why it is
                                                    even relevant. 

                                                  

                                                  

                                                    

                                                      

                                                          
                                                      

                                                        

                                                          

                                                          
4) The
                                                          Client
                                                          presents the
                                                          access token
                                                          to the RS to
                                                          show it has
                                                          been granted
                                                          access. 

                                                          

                                                          

                                                        

                                                      

                                                      
No. The client
                                                        presents a token
                                                        when accessing
                                                        an API. The RS
                                                        uses the token,
                                                        and any policy
                                                        required, to
                                                        make an access
                                                        decision.

                                                        The token never
                                                        contains an
                                                        information like
                                                        "Please grant =
an
                                                        access to the
                                                        holder of this
                                                        token".

                                                    

                                                  

                                                  
Let me provide
                                                    more clarity in the
                                                    sentence:

                                                  


                                                  

                                                  
The Client
                                                    presents the access
                                                    token to the RS, to
                                                    show the RS that the
                                                    Client has been
                                                    granted access to a
                                                    resource at the RS
                                                    by the GS.

                                                

                                              

                                            

                                          

                                          
[Denis] This time, please
                                            consider both the ACLs
                                            approach and the
                                            Capabilities approach.

                                          

                                            

                                              

                                                

                                                  
=C2=A0

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
A couple
                                                          advantages of
                                                          this model:

                                                          
- that
                                                          the RS does
                                                          not need to
                                                          know much, if
                                                          anything about
                                                          the Client.=C2=A0=


                                                          
- the
                                                          access token
                                                          MAY be self
                                                          contained so
                                                          that the
                                                          Client does
                                                          not need to
                                                          query the GS
                                                          on each
                                                          access. 

                                                          

                                                          

                                                        

                                                      

                                                      
There are so
                                                        many
                                                        disadvantages
                                                        that I will not
                                                        list them.

                                                    

                                                  

                                                  
Darn: I clearly
                                                    was not firing on
                                                    all cylinders when I
                                                    typed this out. Let
                                                    me correct:

                                                  


                                                  

                                                  

                                                    

                                                      

                                                        

                                                          
- the
                                                          access token
                                                          MAY be self
                                                          contained so
                                                          that the RS
                                                          does not need
                                                          to query the
                                                          GS on each
                                                          access to the
                                                          RS by the
                                                          Client.

                                                        

                                                      

                                                    

                                                  

                                                

                                              

                                            

                                          

                                          
[Denis] A few comments in
                                            the case of a capability
                                            approach:

                                          

                                            
- for each GS, the RS
                                              needs to locally manage
                                              which operation(s) is/are
                                              allowed to it.

                                              

                                              - the GS needs to
                                              establish a trusted
                                              communication channel or
                                              an authentication
                                              mechanism with each RO 

                                              =C2=A0=C2=A0 (which is associ=
ated
                                              with an explicit RS
                                              identifier). 

                                            

                                            
- the GS could play the
                                              role of the RO and hence
                                              be in a position to issue
                                              any capability for any RS
                                              (without a "RO consent&q=
uot;).
                                              

                                              

                                              =C2=A0=C2=A0 The target of an=
 attack
                                              will clearly be the GS.

                                            

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          
I would
                                                          not say that
                                                          GNAP is an
                                                          access control
                                                          protocol, as
                                                          how the RS
                                                          uses the token
                                                          to determine
                                                          access is out
                                                          of scope.

                                                          

                                                        

                                                      

                                                      
This is where
                                                        we have a major
                                                          discrepancy:
                                                        how the RS uses
                                                        the token to
                                                        determine access
                                                        is *within* the
                                                        scope.

                                                    

                                                  

                                                

                                              

                                            

                                          

                                          [Denis] Do you agree or
                                          disagree ?

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
The RS
                                                        announces in
                                                        advance to the
                                                        client what it
                                                        needs so that
                                                        the client can
                                                        perform a a
                                                        given operation
                                                        and if the
                                                        client supplies
                                                        the requested
                                                        attributes 

                                                        obtained from
                                                        some GS/AS(s)
                                                        trusted by the
                                                        RS, then access
                                                        to that RS is
                                                        granted by the
                                                        RS. If the RS
                                                        cannot perform
                                                        the requested
                                                        operation on its
                                                        own, 

                                                        then the client
                                                        should be
                                                        informed about
                                                        some requested
                                                        attributes that
                                                        need to be
                                                        obtained from
                                                        some GS/AS(s)
                                                        trusted by the
                                                        next RS(s) in a
                                                        chain

                                                        for subsequent
                                                        operations. The
                                                        User consent
                                                        should also be
                                                        obtained before
                                                        performing the
                                                        chaining
                                                        operation.

                                                      

                                                      
Chaining
                                                        operations
                                                        between RSs over
                                                        the Internet is
                                                        within the scope
                                                        (... and may be
                                                        achieved).

                                                    

                                                  

                                                

                                              

                                            

                                          

                                          
[Denis] Do you agree or
                                            disagree ?

                                          
Denis

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
For many
                                                          use cases, the
                                                          User is the
                                                          RO, and the
                                                          interaction is
                                                          through a user
                                                          interface, not
                                                          a machine
                                                          protocol. 

                                                          

                                                          

                                                          

                                                          

                                                          
Wait a
                                                          second. You
                                                          wrote "the
                                                          User is the
                                                          RO". The Use=
r
                                                          is attempting
                                                          to make an
                                                          access to a RS
                                                          by using a
                                                          Client. 

                                                          That
                                                          User is not
                                                          the RO of the
                                                          RS.=C2=A0=C2=A0 <=
br>
                                                          

                                                          

                                                          

                                                          
The user
                                                          being the RO
                                                          is the initial
                                                          use case for
                                                          OAuth. 

                                                          

                                                          

                                                          

                                                          
OAuth 2.0
                                                          is no more
                                                          mandating such
                                                          a case.

                                                          

                                                          

                                                          

                                                          

                                                        

                                                      

                                                      

                                                        

                                                          


                                                          
I don't
                                                          know what you
                                                          mean by that.
                                                          

                                                        

                                                      

                                                      
Copy and paste
                                                        from
                                                        draft-ietf-oauth-se=
curity-topics:

                                                      

                                                      

                                                        
OAuth
                                                          initially
                                                          assumed a
                                                          static
                                                          relationship
                                                          between
                                                          client,
                                                          authorization
                                                          server and
                                                          resource
                                                          servers.=C2=A0
                                                          (...)=C2=A0 

                                                          With the
                                                          increasing
                                                          adoption of
                                                          OAuth, this
                                                          simple model
                                                          dissolved and,
                                                          in several
                                                          scenarios, was
                                                          replaced 

                                                          by a dynamic
                                                          establishment
                                                          of the
                                                          relationship
                                                          between
                                                          clients on one
                                                          side and the
                                                          authorization
                                                          and 

                                                          resource
                                                          servers of a
                                                          particular
                                                          deployment on
                                                          the other
                                                          side.

                                                          

                                                          This way, the
                                                          same client
                                                          could be used
                                                          to access
                                                          services of
                                                          different
                                                          providers (in
                                                          case of
                                                          standard APIs,
                                                          

                                                          such as e-mail
                                                          or OpenID
                                                          Connect) or
                                                          serve as a
                                                          frontend to a
                                                          particular
                                                          tenant in a
                                                          multi-tenancy
                                                          environment. 

                                                        

                                                      

                                                    

                                                  

                                                  


                                                  

                                                  
This sentence
                                                    does not mention the
                                                    RO or the Client.
                                                    I'm confused what w=
e
                                                    are talking about=C2=A0=


                                                  

                                                    

                                                      

                                                        
 

                                                      

                                                      

                                                        

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
A client
                                                          application
                                                          would like
                                                          access to the
                                                          user's photos
                                                          at a photo
                                                          sharing site.
                                                          The resource
                                                          is the user's
                                                          photos. The
                                                          user is the
                                                          owner of that
                                                          resource.

                                                          

                                                          

                                                          

                                                          
If the user
                                                          has already
                                                          pre
                                                          established
                                                          the access
                                                          control policy
                                                          rules so that
                                                          it can access
                                                          to his own
                                                          photos 

                                                          then he does
                                                          not need to
                                                          grant in real
                                                          time any
                                                          additional
                                                          authorization.
                                                          

                                                          

                                                          
I don't
                                                          understand
                                                          what you are
                                                          trying to say.
                                                          The photo
                                                          sharing
                                                          example was a
                                                          driving use
                                                          case for the
                                                          creation of
                                                          OAuth.

                                                          

                                                        

                                                      

                                                      
We would need
                                                        to revisit the
                                                        original
                                                        scenario and
                                                        consider if it
                                                        can be addressed
                                                        in a different
                                                        way than the
                                                        original way.

                                                    

                                                  

                                                  
The use case is
                                                    the same. Is there a
                                                    different solution
                                                    you are proposing?
                                                  
=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/mai=
lman/listinfo/txauth

                              

                            

                          

                          
=E1=90=A7

                        

                        


                        

                      

                    

                  

                

                


                

              

              -- 

              Txauth mailing list

              Txauth@i=
etf.org

              https://www.ietf.org/mailman/listinfo/txa=
uth

            

          

        

      

    

    


    

  


-- 

Txauth mailing list

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




--00000000000063d42905ab8360be--


From nobody Tue Jul 28 10:09: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 8A5753A0AA2 for ; Tue, 28 Jul 2020 10:09:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level: 
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.267, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_FILL_THIS_FORM_SHORT=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 ULX-58CNJH9R for ; Tue, 28 Jul 2020 10:09:15 -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 25A733A0EC9 for ; Tue, 28 Jul 2020 10:09:13 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.51.120]) by mwinf5d51 with ME id 8h9A2300H2bcEcA03h9AZ1; Tue, 28 Jul 2020 19:09:12 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Tue, 28 Jul 2020 19:09:12 +0200
X-ME-IP: 90.79.51.120
To: Dick Hardt 
Cc: txauth@ietf.org
References:   <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>        <7b313658-f7f1-dad1-33aa-7d2107436856@free.fr>  <18b6aa1e-49bf-a7bc-c1a6-5f2b77355434@free.fr> 
From: Denis 
Message-ID: 
Date: Tue, 28 Jul 2020 19:09:08 +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="------------CB29C92AB4BBAAEE02AA5F36"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 28 Jul 2020 17:09:21 -0000

This is a multi-part message in MIME format.
--------------CB29C92AB4BBAAEE02AA5F36
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Dick,

OK. I should have written that in my example: the student connects to 
the University server (i.e. a RS) *using* a client.

A client is a piece of software (supported by some hardware) that the 
user uses to interact with RS(s) and AS(s).

In a Client / Server model, the University Server cannot be a client: it 
is a server.

Nevertheless, my first question still remains: Would you explain how 
*you* would handle the use case of a student registering to a new 
University ?

Denis

> Hi Denis
>
> I did answer your question. The student is the User. The student is 
> not the Client.
>
> ᐧ
>
> On Tue, Jul 28, 2020 at 7:12 AM Denis  > wrote:
>
>     Hi Dick,
>
>     I am puzzled by your response. Your are the editor and a co-editor
>     of the two following RFCs which state:
>
>     RFC 6749:    In the traditional client-server authentication
>     model, the client requests an access-restricted resource
>                          (protected resource) on the server by
>     authenticating with the server (...)
>
>     RFC 6750 : The client uses the access token to access the
>     protected resources hosted by the resource server.
>
>                         The following two steps are specified within
>     this document:
>
>                                    (E)  The client requests the
>     protected resource from the resource server and authenticates
>                                            by presenting the access token.
>
>                                   (F)  The resource server validates
>     the access token, and if valid, serves the request.
>
>     In my use case, the student connects to the University server
>     (i.e. a RS) as a client. The University server cannot be a Client.
>     If you change/twist that basic vocabulary, we will not be able to
>     understand each other any more.
>
>     BTW, my first question still remains: Would you explain how you
>     would handle the use case of a student registering to a new
>     University ?
>
>     Denis
>
>>     Hi Denis
>>
>>     The student (User) goes to the registration page of the
>>     University (the Client)
>>
>>     Similar to your example, the Client has a list of GS that it are
>>     acceptable, or RS that may be acceptable.
>>
>>     If the User selects a GS, then the Client starts a GNAP flow with
>>     the GS.
>>
>>     If the User selects an RS, then the Client can call the RS to
>>     determine which GSes to offer the User to use to get access to
>>     the RS.
>>
>>     In summary, the University wants to consume Claims about the
>>     User, so it is the Client.
>>
>>     /Dick
>>
>>
>>
>>     On Mon, Jul 27, 2020 at 12:49 AM Denis >     > wrote:
>>
>>         Hi Dick,
>>
>>         The floor is yours.
>>
>>         Would you explain how you would handle the use case of a
>>         student registering to a new University ?
>>
>>         Would you also elaborate why in my explanations below, you
>>         think that "the University's registration system is the
>>         Client, not a Resource Server" ?
>>
>>         Denis
>>
>>>         Hi Denis
>>>
>>>         I would think in your example below, that the
>>>         University's registration system is the Client, not a
>>>         Resource Server.
>>>
>>>         Have a good night's sleep!
>>>
>>>
>>>
>>>         On Fri, Jul 24, 2020 at 12:04 PM Denis >>         > wrote:
>>>
>>>             Hi Dick,
>>>
>>>             In order to send back a quick reply tonight, I will only
>>>             respond to one of your questions:
>>>
>>>                 [Denis] How would be the data flow when access
>>>                 tokens from two GSs are needed by a RS ?
>>>
>>>                 [Dick] I don't know of a use case where two tokens
>>>                 would be needed by an RS. Would you elaborate?
>>>
>>>             I already described on the list the case of a student
>>>             registering to a new University.
>>>
>>>             First, the student connects to the RS from the new
>>>             University and opens an account
>>>             (at this time the student is using a pseudo and a
>>>             private key to authenticate). He fills some forms
>>>             and indicate its citizenship, his home address and his
>>>             graduation in his current university.
>>>
>>>             When he is finished, he indicates that he wants to
>>>             perform a Registration operation.
>>>
>>>             From the information gathered in the forms, the RS
>>>             informs the client that it needs two access tokens:
>>>
>>>               * one to demonstrate that his name and current home
>>>                 address are correct,and
>>>               * another one to demonstrate that he got a graduation
>>>                 from its current University.
>>>
>>>             Depending upon the information captured in the forms,
>>>             the RS also indicates which ASs/GSs are acceptable
>>>             and which kind of attributes are requested.
>>>
>>>             The user consent and choice is performed by the client
>>>             and once approved by the student, two access tokens are
>>>             separately requested.
>>>             Finally, two access tokens are presented to the RS while
>>>             invoking a Registration operation.
>>>
>>>             Note that the start of the story is to open an account,
>>>             e.g. using FIDO. The needs of the RS are only disclosed
>>>             to the student once he has filled some forms
>>>             and indicated that he wanted to perform a Registration
>>>             operation. Thus, the needs that are revealed by the RS
>>>             are dependant both upon the operation
>>>             that the student is willing to perform and the
>>>             information collected in the forms.
>>>
>>>             Denis
>>>
>>>>             Hi Denis, comments inserted ...
>>>>
>>>>             On Fri, Jul 24, 2020 at 9:08 AM Denis
>>>>             > wrote:
>>>>
>>>>                 Hi Dick,
>>>>
>>>>                 draft-hardt-xauth-protocol-13 describes a solution
>>>>                 without clearly stating what the problem(s) to be
>>>>                 solved is/are.
>>>>
>>>>
>>>>             I agree that the problem description is not as crisp as
>>>>             I would like it to be. A challenge is that there is a
>>>>             broad spectrum of use cases solved by OAuth 2, and
>>>>             OpenID Connect, as well as the new use cases that are
>>>>             solved by GNAP.
>>>>
>>>>             That is why I am suggesting we gather some use cases so
>>>>             we have a common understanding of the problems that are
>>>>             in scope.
>>>>
>>>>
>>>>                 At the moment, draft-hardt-xauth-protocol-13
>>>>                 includes a single figure on page 4 and from
>>>>                 previous discussions I understood that
>>>>                 it is no more up-to-date since the first data flow
>>>>                 is now a contact with a RS. The reason(s) for the
>>>>                 GS to contact a RO has still not
>>>>                 been explained (since the inputs and outputs are
>>>>                 not described). The discovery information made
>>>>                 available at various steps at the RS
>>>>                 is not described.
>>>>
>>>>
>>>>             I have made no updates as we are in a quiet period
>>>>             prior to the WG meeting next week when documents cannot
>>>>             be updated.
>>>>
>>>>
>>>>                 Figure 4 shows only a single RS. Is the relaying of
>>>>                 one operation by that RS to a second RS in the
>>>>                 scope of this document ?
>>>>                 If yes, how is it handled ?
>>>>
>>>>
>>>>             I view that as an advanced use case that would be
>>>>             covered in a separate document.
>>>>
>>>>
>>>>                 Figure 4 shows only a single GS. How would be the
>>>>                 data flow when access tokens from two GSs are
>>>>                 needed by a RS ?
>>>>
>>>>
>>>>             I don't know of a use case where two tokens would be
>>>>             needed by an RS. Would you elaborate?
>>>>             The RS being able to accept tokens from two different
>>>>             GSes is covered, but the Client is only using a token
>>>>             from one GS at a time.
>>>>
>>>>
>>>>                 What we need first is not a set of "use cases" but
>>>>                 a clear model with a data flows and a list of its
>>>>                 properties/characteristics.
>>>>
>>>>
>>>>             I disagree. The use cases describe the problems we are
>>>>             looking to solve. The data flows are part of the
>>>>             solution. For example, from my understanding of your
>>>>             use case, you don't want the GS to have visibility into
>>>>             the User's activity. Am I correct that this is one of
>>>>             your requirements for your use case?
>>>>
>>>>                 Then after, we can understand much better which use
>>>>                 cases can/will be supported. For example, shall a
>>>>                 RS (or its RO) have
>>>>                 prior relationships with the GS ? What is the
>>>>                 difference/implications when it has or it hasn't ?
>>>>
>>>>                 In order to have a fair comparison, we should try
>>>>                 to list model properties/characteristics.
>>>>
>>>>                 At the moment, the model I have described including
>>>>                 the data flows is clear. The discovery information
>>>>                 made available by a RS is clear.
>>>>                 I have not listed all its
>>>>                 properties/characteristics of that model, but I am
>>>>                 pretty sure that you already have a flavour of it.
>>>>
>>>>                 In the mean time, it would be nice if you could
>>>>                 show using two figures:
>>>>
>>>>                   * the case of the relaying of one operation by
>>>>                     one RS to a second RS (if it is in the scope of
>>>>                     your document),
>>>>                   * the case where access tokens from two GSs are
>>>>                     needed by one RS (if it is in the scope of your
>>>>                     document).
>>>>
>>>>
>>>>             See above
>>>>
>>>>                  *
>>>>
>>>>
>>>>                 Denis
>>>>
>>>>>                 Hi Denis
>>>>>
>>>>>                 I think it would be useful to take a step back and
>>>>>                 for you to describe your use case.
>>>>>                 After that, we can explore the different ways that
>>>>>                 your use case can be addressed.
>>>>>
>>>>>                 Looking at your previous communication, it
>>>>>                 describes the solution, and the justification,
>>>>>                 but it is not clear what use cases you are needing
>>>>>                 to solve.
>>>>>
>>>>>                 /Dick
>>>>>
>>>>>
>>>>>                 ᐧ
>>>>>
>>>>>                 On Wed, Jul 22, 2020 at 9:34 AM Denis
>>>>>                 >
>>>>>                 wrote:
>>>>>
>>>>>                     Hello Dick,
>>>>>
>>>>>                     I have identified the reason of the major
>>>>>                     difference between our two approaches.
>>>>>
>>>>>                     Access control may be performed using either
>>>>>                     ACLs (Access Control Lists) or Capabilities.
>>>>>
>>>>>                     _Note _: a capability identifies a resource
>>>>>                     and an allowed operation that can be performed
>>>>>                     on that resource.
>>>>>
>>>>>                     You are advocating a Capabilities approach
>>>>>                     while I am advocating an ACL approach.
>>>>>
>>>>>                     The capabilities approach allows the GS to
>>>>>                     trace every operation performed by the users
>>>>>                     on any RS known by a GS.
>>>>>                     The management of these capabilities is made
>>>>>                     via the GS or at the GS by the various ROs. If
>>>>>                     the management is made
>>>>>                     via the GS, then a trusted communication
>>>>>                     channel needs to be established with every RO.
>>>>>                     If the management is made
>>>>>                     at the GS, then an authentication mechanism
>>>>>                     needs to be established with every RO. In the
>>>>>                     last case, the GS has the
>>>>>                     ability to know all the capabilities of the
>>>>>                     users whether they are used or not. The less
>>>>>                     that can be said is that this model
>>>>>                     is not privacy friendly.
>>>>>
>>>>>                     With the ACL approach, a RO directly manages
>>>>>                     an ACL placed in front of each RS. The
>>>>>                     AccessControl Decision Function
>>>>>                     (ADF) at the RS is able to keep track from
>>>>>                     prior decisions. The GS is kept ignorant of
>>>>>                     the content of these ACLs and only
>>>>>                     delivers to its clients attributes that are
>>>>>                     placed into access tokens. Such a model may be
>>>>>                     privacy friendly.
>>>>>
>>>>>                     Other comments are between the lines prefixed
>>>>>                     with [Denis].
>>>>>
>>>>>>
>>>>>>                     On Tue, Jul 21, 2020 at 11:26 AM Denis
>>>>>>                     >>>>>                     > wrote:
>>>>>>
>>>>>>                         Hello Dick,
>>>>>>
>>>>>>                         Thank you for your feedback. Comments are
>>>>>>                         between the lines.
>>>>>>
>>>>>>>                         comments inserted ...
>>>>>>>
>>>>>>>                         On Tue, Jul 21, 2020 at 6:03 AM Denis
>>>>>>>                         >>>>>>                         > wrote:
>>>>>>>
>>>>>>>                             Hello Dick,
>>>>>>>
>>>>>>>                             I duplicate the most important
>>>>>>>                             comment at the beginning of this email:
>>>>>>>
>>>>>>>                                 You are considering using an
>>>>>>>                                 access control model to build
>>>>>>>                                 a**workflow model.
>>>>>>>                                 **
>>>>>>>                                 While it may be interesting to
>>>>>>>                                 define a workflow model, this
>>>>>>>                                 should be considered
>>>>>>>                                 as a separate and different work
>>>>>>>                                 item.
>>>>>>>
>>>>>>>                             See the other comments between the
>>>>>>>                             lines.
>>>>>>>
>>>>>>>>                             On Mon, Jul 20, 2020 at 2:05 AM
>>>>>>>>                             Denis >>>>>>>                             > wrote:
>>>>>>>>
>>>>>>>>                                 Hi Dick,
>>>>>>>>
>>>>>>>>>                                 On Fri, Jul 17, 2020 at 9:21
>>>>>>>>>                                 AM Denis >>>>>>>>                                 >
>>>>>>>>>                                 wrote:
>>>>>>>>>
>>>>>>>>>                                     Hello Francis and Dick,
>>>>>>>>>
>>>>>>>>>                                     The good news first: we
>>>>>>>>>                                     are making some progress.
>>>>>>>>>                                     We are now close to an
>>>>>>>>>                                     agreement with steps (1)
>>>>>>>>>                                     up to (3),
>>>>>>>>>                                     ... except that the place
>>>>>>>>>                                     where the user consent is
>>>>>>>>>                                     captured is not
>>>>>>>>>                                     mentioned/indicated.
>>>>>>>>>
>>>>>>>>
>>>>>>>>                                 This major question which is
>>>>>>>>                                 currently left unanswered is
>>>>>>>>                                 where, when and how the user
>>>>>>>>                                 consent is captured.
>>>>>>>>
>>>>>>>>
>>>>>>>>                             When is covered, per the sequence.
>>>>>>>>                             How and where are out of scope of
>>>>>>>>                             what I drafted.
>>>>>>>
>>>>>>>                             It is clear that the "User consent
>>>>>>>                             and choice" is not currently
>>>>>>>                             addressed in the draft, but it should.
>>>>>>>                             The support of the "User consent and
>>>>>>>                             choice" has strong implications not
>>>>>>>                             only in the sequences of the exchanges
>>>>>>>                             but also by which entity it should
>>>>>>>                             be performed.
>>>>>>>
>>>>>>>                         "consent" is in the latest draft 7 times.
>>>>>>
>>>>>>                         "Consent" is present 5 times. The User
>>>>>>                         consent is different from the RO consent
>>>>>>                         (when/if it is required).
>>>>>>
>>>>>>                             The server acquires consent and
>>>>>>                             authorization from the user *and/**or
>>>>>>                             resource owner **if required.*
>>>>>>
>>>>>>                             User consent is *often required* at
>>>>>>                             the GS. GNAP enables a Client and  GS
>>>>>>                             to negotiate the interaction mode for
>>>>>>                             the GS to obtain consent.
>>>>>>
>>>>>>                             The GS *may *require explicit consent
>>>>>>                             from the RO or User to provide these
>>>>>>                             to the Client.
>>>>>>
>>>>>>                         The User consent is not an alternative to
>>>>>>                         the RO consent. So using "and/or" in the
>>>>>>                         first sentence is incorrect.
>>>>>>
>>>>>>
>>>>>>                     My language is sloppy there. Consent is
>>>>>>                     always from the RO. The User may be the RO.
>>>>>
>>>>>                     [Denis] No. Once again: The "/User consent/"
>>>>>                     is different from what you call the "/RO
>>>>>                     consent/" (when/if it is required).
>>>>>                     The "RO consent" is not in fact a consent but
>>>>>                     the release of a capability to a client by one
>>>>>                     of the many R0s with which
>>>>>                     the GS has relationships.
>>>>>
>>>>>>                         Since the second sentence is using the
>>>>>>                         wording "often required" there is no
>>>>>>                         requirement to get the User consent.
>>>>>>
>>>>>>                     User consent may not be required. There may
>>>>>>                     not be a User. The consent may have been
>>>>>>                     gathered previously.
>>>>>
>>>>>                     [Denis] In order to follow the privacy
>>>>>                     principles, a "User consent" phase is
>>>>>                     required. The User is a natural person.
>>>>>                     A Client is called either by a User (i.e. a
>>>>>                     natural person) or by a Client application.
>>>>>
>>>>>>                         The second sentence does not consider the
>>>>>>                         possibility to get the User consent in a
>>>>>>                         place different from the GS.
>>>>>>
>>>>>>                     Agreed. But we do agree that the GS gets the
>>>>>>                     consent, either directly from the RO, or from
>>>>>>                     the Client (in your example).
>>>>>
>>>>>                     [Denis] No. I disagree. In an ACL based
>>>>>                     systems, the GS does not need to ask or
>>>>>                     receive any consent.
>>>>>                     The client selects the set of attributes that
>>>>>                     it wants to be inserted into an access token.
>>>>>                     If the GS has the requested attributes, then
>>>>>                     it provides them, otherwise it returns an
>>>>>                     error to the Client.
>>>>>
>>>>>>                         IMO, the User consent should be captured
>>>>>>                         by the Client, i.e. not by the GS.
>>>>>>                         The information used to obtain the User
>>>>>>                         consent should be standardized (... and
>>>>>>                         it can be standardized).
>>>>>>
>>>>>>>                         I think the abstract sequence as
>>>>>>>                         proposed by Francis is a great addition,
>>>>>>>                         and would clarify where consent is in
>>>>>>>                         the sequence.
>>>>>>
>>>>>>                         The current sketch does not illustrate
>>>>>>                         the place the User Consent is captured,
>>>>>>                         in particular by the Client.
>>>>>>
>>>>>>                     It is an abstraction. The GS receives the
>>>>>>                     consent. How consent is gathered is a detail
>>>>>>                     that is dependent on the use case.
>>>>>
>>>>>                     [Denis] I really wonder whether there is
>>>>>                     really a "consent" to be received by the GS in
>>>>>                     both cases (i.e. ACLs or Capabilities).
>>>>>
>>>>>                       * For ACLs, the consent needs to be done by
>>>>>                         the Client.
>>>>>                       * For Capabilities, the current description
>>>>>                         is not clear since the inputs and the
>>>>>                         outputs for this "consent" phase
>>>>>                         are not currently described in the draft.
>>>>>
>>>>>>>>                                 Another important point to
>>>>>>>>                                 consider and to explain is
>>>>>>>>                                 related to the assurances that
>>>>>>>>                                 the user can obtain about
>>>>>>>>                                 the respect of his choices.
>>>>>>>>                                 This point is currently left
>>>>>>>>                                 unanswered in
>>>>>>>>                                 draft-hardt-xauth-protocol-13.
>>>>>>>>
>>>>>>>                             This point is equally important:
>>>>>>>                             such assurance can only be obtained
>>>>>>>                             if the access token returned to the
>>>>>>>                             client
>>>>>>>                             is not considered to be opaque to
>>>>>>>                             the client. This is a necessary
>>>>>>>                             condition but not the single condition:
>>>>>>>                             the Client must also be in a
>>>>>>>                             position to capture/memorize the
>>>>>>>                             "User consent and choice" of the
>>>>>>>                             user in order to be able
>>>>>>>                             to verify it afterwards using the
>>>>>>>                             content of the access token(s).
>>>>>>>
>>>>>>>
>>>>>>>                         We disagree on this being a requirement
>>>>>>>                         for all use cases. It may be in some.
>>>>>>
>>>>>>                         OK. Then this means that there will be no
>>>>>>                         sentence in the draft such as :
>>>>>>                         "access tokens returned to the client are
>>>>>>                         not considered to be opaque to the client".
>>>>>>
>>>>>>
>>>>>>                     For OAuth use cases, which GNAP supports, the
>>>>>>                     access token is opaque to the Client. As you
>>>>>>                     have noted, there are use cases where the
>>>>>>                     access token is NOT opaque.
>>>>>
>>>>>                     [Denis] Wait a second. There is no requirement
>>>>>                     to support all OAuth use cases.
>>>>>                     I believe that there is a requirement to
>>>>>                     support OAuth 2.0 ASs, while the clients may
>>>>>                     be different
>>>>>                     and hence GNAP clients do not need to inherit
>>>>>                     of the limitations of OAuth 2.0 clients.
>>>>>
>>>>>>>>
>>>>>>>>>                                     If a RO needs to be
>>>>>>>>>                                     involved and since a RO is
>>>>>>>>>                                     directly associated with a
>>>>>>>>>                                     RS, why can't it be
>>>>>>>>>                                     directly queried
>>>>>>>>>                                     by the appropriate RS
>>>>>>>>>                                     after step (2) or later on ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                 Good question. Perhaps you can
>>>>>>>>>                                 expand on a use case where
>>>>>>>>>                                 that would be useful?
>>>>>>>>
>>>>>>>>                                 Before I expand, would you be
>>>>>>>>                                 able to explain first under
>>>>>>>>                                 which circumstances a RO needs
>>>>>>>>                                 to be queried by a GS ?
>>>>>>>>                                 How can the GS identify which
>>>>>>>>                                 RO to query ?
>>>>>>>>
>>>>>>>>                             If the User is the RO, then the GS
>>>>>>>>                             knows who to query.
>>>>>>>
>>>>>>>                             I still have difficulties to
>>>>>>>                             understand what you mean here.
>>>>>>>                             How could a GS know that "the User
>>>>>>>                             is the RO" ?  If "the User is the
>>>>>>>                             RO", why does the GS needs to query
>>>>>>>                             the User ?
>>>>>>>
>>>>>>>
>>>>>>>                         To get consent?
>>>>>>
>>>>>>                         To get a "RO consent" to himself ???
>>>>>>
>>>>>>
>>>>>>                     The GS needs consent from the RO. If the RO
>>>>>>                     is the User, then consent from the RO is
>>>>>>                     equivalent to consent from the User.
>>>>>
>>>>>                     [Denis] See above.
>>>>>
>>>>>>
>>>>>>>>                             If the RO is a separate entity,
>>>>>>>>                             then the GS knows the RO from the
>>>>>>>>                             RS being queried.
>>>>>>>
>>>>>>>                              ... and this gives the ability for
>>>>>>>                             the GS to log/trace all the RSs
>>>>>>>                             accessed by a given User and at
>>>>>>>                             which instant of time the access
>>>>>>>                             token has been granted.
>>>>>>>
>>>>>>>>                             An example is a user would like
>>>>>>>>                             access to an enterprise asset where
>>>>>>>>                             a workflow is started to gain
>>>>>>>>                             approval, and an administrator or
>>>>>>>>                             manager provides consent.
>>>>>>>
>>>>>>>                             Thanks for this example. I finally
>>>>>>>                             understand what you have in mind:
>>>>>>>                             you are considering using an access
>>>>>>>                             control model to build a *workflow
>>>>>>>                             model*.
>>>>>>>                             While it may be interesting to
>>>>>>>                             define a workflow model, this should
>>>>>>>                             be considered as a *separate and
>>>>>>>                             different work item*.
>>>>>>>
>>>>>>>
>>>>>>>                         The actual workflow is out of scope.
>>>>>>
>>>>>>                         I am glad you agree with this. But this
>>>>>>                         means that your example was not
>>>>>>                         appropriate to illustrate your point.
>>>>>>
>>>>>>
>>>>>>                     It illustrates a use case where the RO and
>>>>>>                     User are not the same party, and why the GS
>>>>>>                     needs to query the RO, which was your
>>>>>>                     question if I understood it correctly.
>>>>>
>>>>>                     [Denis] Since the inputs and the outputs for
>>>>>                     this "RO consent" phase are not currently
>>>>>                     described in the draft, the point is still
>>>>>                     unsolved.
>>>>>
>>>>>>                         As soon as there is a RO consent obtained
>>>>>>                         at the GS, the major problem is that the
>>>>>>                         GS is able to act as Big Brother.
>>>>>>                         If a RO consent is performed at the RS,
>>>>>>                         then the GS will not know who the RS is:
>>>>>>                         it is then unable to act as Big Brother,
>>>>>>                         even if it would enjoy to play that role.
>>>>>>
>>>>>>                     In an enterprise use case, the GS's knowledge
>>>>>>                     of who is accessing which RS is a feature.
>>>>>
>>>>>                     Do you mean that it is "normal" in an
>>>>>                     enterprise that a single point of control is
>>>>>                     able to trace all their actions ?
>>>>>                     From a security point of view, a single point
>>>>>                     of failure will have dramatic consequences.
>>>>>
>>>>>>                     In your use cases, it seems that the RO is
>>>>>>                     the User.
>>>>>
>>>>>                     I do hope that you have finally understood
>>>>>                     that, in my use case, the RO is **not** the User.
>>>>>
>>>>>>                     The GS knows the User is wanting to let a
>>>>>>                     Client access something. If the access token
>>>>>>                     is generic, and could be presented to any RS
>>>>>>                     that provides a standardized function,
>>>>>>                     then the GS does not know which RS is being
>>>>>>                     accessed by a Client for the User. This seems
>>>>>>                     to meet your privacy objectives. If not, what
>>>>>>                     is wrong?
>>>>>
>>>>>                     For security reasons, an access token needs to
>>>>>                     be targeted (which does not necessarily mean
>>>>>                     that an identifier of the RS shall be included
>>>>>                     into the access token).
>>>>>
>>>>>>>                         if the admin grants access, then the
>>>>>>>                         access granted to the client changes.
>>>>>>>
>>>>>>>                             The model you propose may be suited
>>>>>>>                             for an enterprise environment but is
>>>>>>>                             not scalable over the Internet.
>>>>>>>
>>>>>>>                         It is one of the use cases we are
>>>>>>>                         working to address.
>>>>>>>
>>>>>>>                             What is needed is an access control
>>>>>>>                             model usable over the Internet with
>>>>>>>                             millions of RSs and thousands of
>>>>>>>                             ASs/GSs.
>>>>>>>
>>>>>>>                         I agree the model should also scale to
>>>>>>>                         internet scale.
>>>>>>
>>>>>>                         Fine. Another point on which we are in
>>>>>>                         agreement.
>>>>>>
>>>>>>                         The model can scale to the Internet based
>>>>>>                         on the following assumptions:
>>>>>>
>>>>>>                             The flow starts with the steps (1) to
>>>>>>                             (4) as illustrated by Francis, i.e.
>>>>>>                             the flow starts with a contact with a RS.
>>>>>>
>>>>>>                         *+----+  +------+  +---+  +---+  +---+
>>>>>>                         |User|  |Client|  |RS |  |GS |  |RO |
>>>>>>                         +----+  +------+  +---+  +-+-+  +-+-+
>>>>>>                           |(1) Service Request     |      |
>>>>>>                         |-------->|       |      |      |
>>>>>>                           | |(2) Service Intent   |
>>>>>>                           | |------>|    |      |
>>>>>>                           | |(3) AuthZ Challenge  |
>>>>>>                           | |<------|    |      |
>>>>>>                           | |(4) AuthZ Request    |
>>>>>>                           | |------------->|      |*
>>>>>>
>>>>>>                         The GS/AS does not need to have any prior
>>>>>>                         relationship with ROs and/or RSs.
>>>>>>
>>>>>>                         Furthermore, it is possible to prevent
>>>>>>                         the GS to act as Big Brother when the
>>>>>>                         identity of the RS is not disclosed to
>>>>>>                         the GS.
>>>>>>
>>>>>>
>>>>>>                     What happens after (4) above?
>>>>>
>>>>>                     [Denis] The key point is that we first need to
>>>>>                     agree on the first four exchanges. Do we ?
>>>>>
>>>>>                     The fifth exchange is different whether ACLs
>>>>>                     or Capabilities are being used.
>>>>>
>>>>>>>>>                                     Which information is
>>>>>>>>>                                     supposed to be presented
>>>>>>>>>                                     to the RO ?
>>>>>>>>>                                     Which information is
>>>>>>>>>                                     supposed to be returned by
>>>>>>>>>                                     the RO ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                                 Just like how the user
>>>>>>>>>                                 authenticates to an AS, how
>>>>>>>>>                                 the AS and RO communicate is
>>>>>>>>>                                 out of scope.
>>>>>>>>
>>>>>>>>                                 At the moment, the usefulness
>>>>>>>>                                 of a dialogue between a GS and
>>>>>>>>                                 a RO has not been explained,
>>>>>>>>                                 nor demonstrated.
>>>>>>>>                                 The question is about the
>>>>>>>>                                 functionality of that dialogue
>>>>>>>>                                 in terms of input and output
>>>>>>>>                                 information (and not about
>>>>>>>>                                 the design of a protocol or of
>>>>>>>>                                 a user interface). Anyway,
>>>>>>>>                                 AFAIU a dialogue between a GS
>>>>>>>>                                 and a RO is optional.
>>>>>>>>
>>>>>>>>
>>>>>>>>                             See enterprise example above.
>>>>>>>
>>>>>>>                             It is not an access control example,
>>>>>>>                             but a workflow example.
>>>>>>>
>>>>>>>                             Access control has been defined a
>>>>>>>                             long time ago and the last edition
>>>>>>>                             of the model has been confirmed in
>>>>>>>                             year 1996: ISO/IEC 10181-3: 1996.
>>>>>>>                             "Information technology — Open
>>>>>>>                             Systems Interconnection — Security
>>>>>>>                             frameworks for open systems: Access
>>>>>>>                             control framework — Part 3".
>>>>>>>
>>>>>>>                             Two major functions have ben
>>>>>>>                             defined: an AccessControl
>>>>>>>                             Enforcement Function (AEF) and an
>>>>>>>                             AccessControl Decision Function(ADF).
>>>>>>>
>>>>>>>                                 AccessControl Enforcement
>>>>>>>                                 Function (AEF):
>>>>>>>                                 A specialized function that is
>>>>>>>                                 part of the access path between
>>>>>>>                                 an initiator and a target on
>>>>>>>                                 each access request and enforces
>>>>>>>                                 the decision made by the ADF.
>>>>>>>
>>>>>>>                                 AccessControl Decision Function
>>>>>>>                                 (ADF) :
>>>>>>>                                 A specialized function that
>>>>>>>                                 makes access control decisions
>>>>>>>                                 by applying access control
>>>>>>>                                 policy rules to an access
>>>>>>>                                 request, ADI (of initiators,
>>>>>>>                                 targets, access requests,
>>>>>>>                                 or that retained from prior
>>>>>>>                                 decisions), and the context in
>>>>>>>                                 which the access request is made.
>>>>>>>
>>>>>>>                             The role of the RO is to define the
>>>>>>>                             "access control policy rules" at the
>>>>>>>                             RS according to thecontext in which
>>>>>>>                             the access request is made.
>>>>>>>
>>>>>>>                         I'm pretty familiar with access control
>>>>>>>                         systems. :)
>>>>>>>
>>>>>>>                         I would say that the access control is
>>>>>>>                         happening at the RS. The client presents
>>>>>>>                         a token when accessing an API.
>>>>>>>                         The RS uses the token, and any policy
>>>>>>>                         required, to make an access decision.
>>>>>>
>>>>>>                         Fine. It looks like we are in agreement.
>>>>>>                         Unfortunately, this is not the case just
>>>>>>                         below.
>>>>>>
>>>>>>>                         Here is flow:
>>>>>>>
>>>>>>>                         1) The Client requests access to an RS
>>>>>>>                         from the GS.
>>>>>>
>>>>>>                         No. We are no more in agreement. This is
>>>>>>                         different from the flow drawn by Francis.
>>>>>>
>>>>>>                     My bad. Typo. I meant RO.
>>>>>>
>>>>>>>                         2) The GS queries the RS if access
>>>>>>>                         should be granted.
>>>>>>
>>>>>>                          No. The GS should not be forced to have
>>>>>>                         a flow with the RS.
>>>>>>
>>>>>>                     Same mistake as above, I meant RO.
>>>>>>
>>>>>>>                         3) If access is granted, the GS creates
>>>>>>>                         an access token representing the granted
>>>>>>>                         access, and returns it to the Client.
>>>>>>
>>>>>>                         This model is by no way conformant to
>>>>>>                         ISO/IEC 10181-3: 1996
>>>>>>
>>>>>>                     I'm unclear on why, or why it is even relevant.
>>>>>>
>>>>>>>                         4) The Client presents the access token
>>>>>>>                         to the RS to show it has been granted
>>>>>>>                         access.
>>>>>>
>>>>>>                         No. The client presents a token when
>>>>>>                         accessing an API. The RS uses the token,
>>>>>>                         and any policy required, to make an
>>>>>>                         access decision.
>>>>>>                         The token never contains an information
>>>>>>                         like "Please grant an access to the
>>>>>>                         holder of this token".
>>>>>>
>>>>>>                     Let me provide more clarity in the sentence:
>>>>>>
>>>>>>                     The Client presents the access token to the
>>>>>>                     RS, to show the RS that the Client has been
>>>>>>                     granted access to a resource at the RS by the GS.
>>>>>
>>>>>                     [Denis] This time, please consider both the
>>>>>                     ACLs approach and the Capabilities approach.
>>>>>
>>>>>>>                         A couple advantages of this model:
>>>>>>>                         - that the RS does not need to know
>>>>>>>                         much, if anything about the Client.
>>>>>>>                         - the access token MAY be self contained
>>>>>>>                         so that the Client does not need to
>>>>>>>                         query the GS on each access.
>>>>>>
>>>>>>                         There are so many disadvantages that I
>>>>>>                         will not list them.
>>>>>>
>>>>>>                     Darn: I clearly was not firing on all
>>>>>>                     cylinders when I typed this out. Let me correct:
>>>>>>
>>>>>>>                     - the access token MAY be self contained so
>>>>>>>                     that the RS does not need to query the GS on
>>>>>>>                     each access to the RS by the Client.
>>>>>
>>>>>                     [Denis] A few comments in the case of a
>>>>>                     capability approach:
>>>>>
>>>>>                         - for each GS, the RS needs to locally
>>>>>                         manage which operation(s) is/are allowed
>>>>>                         to it.
>>>>>
>>>>>                         - the GS needs to establish a trusted
>>>>>                         communication channel or an authentication
>>>>>                         mechanism with each RO
>>>>>                            (which is associated with an explicit
>>>>>                         RS identifier).
>>>>>
>>>>>                         - the GS could play the role of the RO and
>>>>>                         hence be in a position to issue any
>>>>>                         capability for any RS (without a "RO
>>>>>                         consent").
>>>>>
>>>>>                            The target of an attack will clearly be
>>>>>                         the GS.
>>>>>
>>>>>>>                         I would not say that GNAP is an access
>>>>>>>                         control protocol, as how the RS uses the
>>>>>>>                         token to determine access is out of scope.
>>>>>>
>>>>>>                         This is where we have a major
>>>>>>                         discrepancy: how the RS uses the token to
>>>>>>                         determine access is *within* the scope.
>>>>>>
>>>>>                     [Denis] Do you agree or disagree ?
>>>>>>
>>>>>>                         The RS announces in advance to the client
>>>>>>                         what it needs so that the client can
>>>>>>                         perform a a given operation and if the
>>>>>>                         client supplies the requested attributes
>>>>>>                         obtained from some GS/AS(s) trusted by
>>>>>>                         the RS, then access to that RS is granted
>>>>>>                         by the RS. If the RS cannot perform the
>>>>>>                         requested operation on its own,
>>>>>>                         then the client should be informed about
>>>>>>                         some requested attributes that need to be
>>>>>>                         obtained from some GS/AS(s) trusted by
>>>>>>                         the next RS(s) in a chain
>>>>>>                         for subsequent operations. The User
>>>>>>                         consent should also be obtained before
>>>>>>                         performing the chaining operation.
>>>>>>
>>>>>>                         Chaining operations between RSs over the
>>>>>>                         Internet is within the scope (... and may
>>>>>>                         be achieved).
>>>>>>
>>>>>                     [Denis] Do you agree or disagree ?
>>>>>
>>>>>                     Denis
>>>>>
>>>>>>>>>                                 For many use cases, the User
>>>>>>>>>                                 is the RO, and the interaction
>>>>>>>>>                                 is through a user interface,
>>>>>>>>>                                 not a machine protocol.
>>>>>>>>
>>>>>>>>                                 Wait a second. You wrote "the
>>>>>>>>                                 User is the RO". The User is
>>>>>>>>                                 attempting to make an access to
>>>>>>>>                                 a RS by using a Client.
>>>>>>>>                                 _That_ User is not the RO of
>>>>>>>>                                 the RS.
>>>>>>>>
>>>>>>>>                             The user being the RO is the
>>>>>>>>                             initial use case for OAuth.
>>>>>>>
>>>>>>>                             OAuth 2.0 is no more mandating such
>>>>>>>                             a case.
>>>>>>>
>>>>>>>
>>>>>>>                         I don't know what you mean by that.
>>>>>>
>>>>>>                         Copy and paste from
>>>>>>                         draft-ietf-oauth-security-topics:
>>>>>>
>>>>>>                             OAuth initially assumed a static
>>>>>>                             relationship between client,
>>>>>>                             authorization server and resource
>>>>>>                             servers. (...)
>>>>>>                             With the increasing adoption of
>>>>>>                             OAuth, this simple model dissolved
>>>>>>                             and, in several scenarios, was replaced
>>>>>>                             by a dynamic establishment of the
>>>>>>                             relationship between clients on one
>>>>>>                             side and the authorization and
>>>>>>                             resource servers of a particular
>>>>>>                             deployment on the other side.
>>>>>>
>>>>>>                             This way, the same client could be
>>>>>>                             used to access services of different
>>>>>>                             providers (in case of standard APIs,
>>>>>>                             such as e-mail or OpenID Connect) or
>>>>>>                             serve as a frontend to a particular
>>>>>>                             tenant in a multi-tenancy environment.
>>>>>>
>>>>>>
>>>>>>                     This sentence does not mention the RO or the
>>>>>>                     Client. I'm confused what we are talking about
>>>>>>
>>>>>>>>                             A client application would like
>>>>>>>>                             access to the user's photos at a
>>>>>>>>                             photo sharing site. The resource is
>>>>>>>>                             the user's photos. The user is the
>>>>>>>>                             owner of that resource.
>>>>>>>
>>>>>>>                             If the user has already pre
>>>>>>>                             established the access control
>>>>>>>                             policy rules so that it can access
>>>>>>>                             to his own photos
>>>>>>>                             then he does not need to grant in
>>>>>>>                             real time any additional authorization.
>>>>>>>
>>>>>>>                         I don't understand what you are trying
>>>>>>>                         to say. The photo sharing example was a
>>>>>>>                         driving use case for the creation of OAuth.
>>>>>>
>>>>>>                         We would need to revisit the original
>>>>>>                         scenario and consider if it can be
>>>>>>                         addressed in a different way than the
>>>>>>                         original way.
>>>>>>
>>>>>>                     The use case is the same. Is there a
>>>>>>                     different solution you are proposing?
>>>>>
>>>>>
>>>>>                     -- 
>>>>>                     Txauth mailing 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
>


--------------CB29C92AB4BBAAEE02AA5F36
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Dick,

    


    

    
OK. I should have written that in my
      example: the student connects to the University server (i.e. a RS)
      *using* a client.

    


    

    
A client is a piece of software
      (supported by some hardware) that the user uses to interact with
      RS(s) and AS(s). 

    

    


    

    
In a Client / Server model, the
      University Server cannot be a client: it is a server.

    

    


    

    
Nevertheless, my first question still
      remains: Would you explain how *you* would handle the use case of
      a student registering to a new University ?

    


    

    
Denis

    

    

    

      
      
Hi Denis
        


        

        
I did answer your question. The student is the User. The
          student is not the Client.

        


        

      

      
ᐧ

      

      

        
On Tue, Jul 28, 2020 at 7:12
          AM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hi Dick,

            


            

            
I am puzzled by your response. Your are the editor and
              a co-editor of the two following RFCs which state:

            


            

            
RFC 6749:    In the traditional client-server
              authentication model, the client requests an
              access-restricted resource 

                                   (protected resource) on the server by
              authenticating with the server (...) 

              

              RFC 6750 : The client uses the access token to access the
              protected resources hosted by the resource server. 

              

                                  The following two steps are specified
              within this document:

              

                                             (E)  The client requests
              the protected resource from the resource server and
              authenticates 

                                                     by presenting the
              access token.

              

                                            (F)  The resource server
              validates the access token, and if valid, serves the
              request.

            

            


            

            
In my use case, the student connects to the University
              server (i.e. a RS) as a client. The University server
              cannot be a Client.

              If you change/twist that basic vocabulary, we will not be
              able to understand each other any more.

            


            

            
BTW, my first question still remains: Would you explain
              how you would handle the use case of a student registering
              to a new University ?

            


            

            
Denis

            
  

            

            

              
Hi Denis
                


                

                
The student (User) goes to the registration page of
                  the University (the Client)

                


                

                
Similar to your example, the Client has a list of
                  GS that it are acceptable, or RS that may be
                  acceptable.

                


                

                
If the User selects a GS, then the Client starts a
                  GNAP flow with the GS.

                


                

                
If the User selects an RS, then the Client can call
                  the RS to determine which GSes to offer the User to
                  use to get access to the RS.

                


                

                
In summary, the University wants to consume Claims
                  about the User, so it is the Client.

                  


                  

                  
/Dick

                  


                  

                  


                  

                  

                  

                    
On Mon, Jul 27,
                      2020 at 12:49 AM Denis <denis.ietf@free.fr>
                      wrote:

                    

                    

                      

                        
Hi Dick,

                        


                        

                        
The floor is yours.

                        


                        

                        
Would you explain how you would handle the
                          use case of a student registering to a new
                          University ?

                        


                        

                        
Would you also elaborate why in my
                          explanations below, you think that "the
                          University's registration system is the
                          Client, not a Resource Server" ?
                          


                          

                        

                        
Denis

                        

                        

                        

                          
Hi Denis
                            


                            

                            
I would think in your example below,
                              that the University's registration system
                              is the Client, not a Resource Server.

                            


                            

                            
Have a good night's sleep!

                            


                            

                            


                            

                          

                          

                          

                            
On Fri,
                              Jul 24, 2020 at 12:04 PM Denis <denis.ietf@free.fr>
                              wrote:

                            

                            

                              

                                
Hi Dick,

                                  

                                

                                
In order to send back a quick reply
                                  tonight, I will only respond to one of
                                  your questions:

                                

                                  
 [Denis] How would be the
                                    data flow when access tokens from
                                    two GSs are needed by a RS ?

                                    


                                    

                                    
[Dick] I don't know of a use
                                      case where two tokens would be
                                      needed by an RS. Would you
                                      elaborate?

                                  

                                  
I already described on the list
                                    the case of a student registering to
                                    a new University.

                                  
 

                                  

                                  
First, the student connects to
                                    the RS from the new University and
                                    opens an account 

                                    (at this time the student is using a
                                    pseudo and a private key to
                                    authenticate). He fills some forms 

                                    and indicate its citizenship, his
                                    home address and his graduation in
                                    his current university. 

                                    

                                    When he is finished, he indicates
                                    that he wants to perform a
                                    Registration operation.

                                  


                                  

                                  
From the information gathered in
                                    the forms, the RS informs the client
                                    that it needs two access tokens:

                                  
    
                                    
  • one to demonstrate that his name
                                      and current home address are
                                      correct,and
    • 
                                    
  • another one to demonstrate that
                                      he got a graduation from its
                                      current University.
    • 
                                  

                                  
Depending upon the information
                                    captured in the forms, the RS also
                                    indicates which ASs/GSs are
                                    acceptable 

                                    and which kind of attributes are
                                    requested.

                                  
 

                                  

                                  
The user consent and choice is
                                    performed by the client and once
                                    approved by the student, two access
                                    tokens are separately requested.

                                    Finally, two access tokens are
                                    presented to the RS while invoking a
                                    Registration operation.

                                  


                                  

                                  
Note that the start of the story
                                    is to open an account, e.g. using
                                    FIDO. The needs of the RS are only
                                    disclosed to the student once he has
                                    filled some forms 

                                    and indicated that he wanted to
                                    perform a Registration operation.
                                    Thus, the needs that are revealed by
                                    the RS are dependant both upon the
                                    operation 

                                    that the student is willing to
                                    perform and the information
                                    collected in the forms.

                                  


                                  

                                  
Denis

                                

                                

                                

                                  

                                    
Hi Denis, comments inserted
                                      ... 

                                    

                                    

                                      
On
                                        Fri, Jul 24, 2020 at 9:08 AM
                                        Denis <denis.ietf@free.fr>
                                        wrote:

                                      

                                      

                                        

                                          

                                            
Hi Dick,

                                            


                                            

                                            
draft-hardt-xauth-protocol-13
                                              describes a solution
                                              without clearly stating
                                              what the problem(s) to be
                                              solved is/are.

                                          

                                        

                                      

                                      


                                      

                                      
I agree that the problem
                                        description is not as crisp as I
                                        would like it to be. A challenge
                                        is that there is a broad
                                        spectrum of use cases solved by
                                        OAuth 2, and OpenID Connect, as
                                        well as the new use cases that
                                        are solved by GNAP.

                                      


                                      

                                      
That is why I am suggesting
                                        we gather some use cases so we
                                        have a common understanding of
                                        the problems that are in scope.

                                      
 

                                      

                                        

                                          

                                            


                                            

                                            
At the moment,
                                              draft-hardt-xauth-protocol-13
                                              includes a single figure
                                              on page 4 and from
                                              previous discussions I
                                              understood that 

                                              it is no more up-to-date
                                              since the first data flow
                                              is now a contact with a
                                              RS. The reason(s) for the
                                              GS to contact a RO has
                                              still not 

                                              been explained (since the
                                              inputs and outputs are not
                                              described). The discovery
                                              information made available
                                              at various steps at the RS
                                              

                                              is not described.

                                            

                                          

                                        

                                      

                                      


                                      

                                      
I have made no updates as we
                                        are in a quiet period prior to
                                        the WG meeting next week when
                                        documents cannot be updated.

                                      
 

                                      

                                        

                                          

                                            

                                              


                                              

                                            

                                            
Figure 4 shows only a
                                              single RS. Is the relaying
                                              of one operation by that
                                              RS to a second RS in the
                                              scope of this document ?

                                              If yes, how is it handled
                                              ?

                                            

                                          

                                        

                                      

                                      


                                      

                                      
I view that as an advanced
                                        use case that would be covered
                                        in a separate document.

                                      
 

                                      

                                        

                                          

                                            
 

                                            


                                            

                                            
Figure 4 shows only a
                                              single GS. How would be
                                              the data flow when access
                                              tokens from two GSs are
                                              needed by a RS ?

                                            

                                          

                                        

                                      

                                      


                                      

                                      
I don't know of a use case
                                        where two tokens would be needed
                                        by an RS. Would you elaborate?

                                      
The RS being able to accept
                                        tokens from two different GSes
                                        is covered, but the Client is
                                        only using a token from one GS
                                        at a time.

                                      


                                      

                                      
 

                                      

                                        

                                          

                                            
 

                                            

                                            What we need first is not a
                                            set of "use cases" but a
                                            clear model with a data
                                            flows and a list of its
                                            properties/characteristics.
                                            

                                          

                                        

                                      

                                      


                                      

                                      
I disagree. The use cases
                                        describe the problems we are
                                        looking to solve. The data flows
                                        are part of the solution. For
                                        example, from my understanding
                                        of your use case, you don't want
                                        the GS to have visibility into
                                        the User's activity. Am I
                                        correct that this is one of your
                                        requirements for your use case?

                                      


                                      

                                      
 

                                      

                                        

                                          
 

                                          
Then after, we can
                                            understand much better which
                                            use cases can/will be
                                            supported. For example,
                                            shall a RS (or its RO) have
                                            

                                            prior relationships with the
                                            GS ? What is the
                                            difference/implications when
                                            it has or it hasn't ?

                                          

                                          


                                          

                                          
In order to have a fair
                                            comparison, we should try to
                                            list model
                                            properties/characteristics.

                                          


                                          

                                          
At the moment, the model
                                            I have described including
                                            the data flows is clear. The
                                            discovery information made
                                            available by a RS is clear.

                                          
I have not listed all its
                                            properties/characteristics
                                            of that model, but I am
                                            pretty sure that you already
                                            have a flavour of it.

                                          


                                          

                                          
In the mean time, it
                                            would be nice if you could
                                            show using two figures:

                                          
    
                                            
  • the case of the relaying
                                              of one operation by one RS
                                              to a second RS (if it is
                                              in the scope of your
                                              document),
    • 
                                            
  • the case where access
                                              tokens from two GSs are
                                              needed by one RS (if it is
                                              in the scope of your
                                              document).
    
                                            
    • 
                                          

                                        

                                      

                                      


                                      

                                      
See above

                                      
 

                                      

                                        

                                          
    
                                            
  •  
    
                                            
    • 
                                          

                                          

                                            
Denis

                                          

                                          


                                          

                                          

                                            
Hi Denis
                                              


                                              

                                              
I think it would be
                                                useful to take a step
                                                back and for you to
                                                describe your use case.
                                                

                                                After that, we can
                                                explore the different
                                                ways that your use case
                                                can be addressed. 

                                              


                                              

                                              
Looking at your
                                                previous communication,
                                                it describes the
                                                solution, and the
                                                justification, 

                                                but it is not clear what
                                                use cases you are
                                                needing to solve.

                                              


                                              

                                              
/Dick

                                              


                                              

                                              


                                              

                                            

                                            
ᐧ

                                            

                                            

                                              
On
                                                Wed, Jul 22, 2020 at
                                                9:34 AM Denis <denis.ietf@free.fr>
                                                wrote:

                                              

                                              

                                                

                                                  
Hello Dick,

                                                  


                                                  

                                                  
I have identified
                                                    the reason of the
                                                    major difference
                                                    between our two
                                                    approaches.

                                                  


                                                  

                                                  
Access control
                                                    may be performed
                                                    using either ACLs
                                                    (Access Control
                                                    Lists) or
                                                    Capabilities.

                                                  


                                                  

                                                  
Note : a
                                                    capability
                                                    identifies a
                                                    resource and an
                                                    allowed operation
                                                    that can be
                                                    performed on that
                                                    resource.

                                                  

                                                  


                                                  

                                                  
You are
                                                    advocating a
                                                    Capabilities
                                                    approach while I am
                                                    advocating an ACL
                                                    approach.

                                                  
The capabilities
                                                    approach allows the
                                                    GS to trace every
                                                    operation performed
                                                    by the users on any
                                                    RS known by a GS.

                                                    The management of
                                                    these capabilities
                                                    is made via the GS
                                                    or at the GS by the
                                                    various ROs. If the
                                                    management is made 

                                                    via the GS, then a
                                                    trusted
                                                    communication
                                                    channel needs to be
                                                    established with
                                                    every RO. If the
                                                    management is made 

                                                    at the GS, then an
                                                    authentication
                                                    mechanism needs to
                                                    be established with
                                                    every RO. In the
                                                    last case, the GS
                                                    has the 

                                                    ability to know all
                                                    the capabilities of
                                                    the users whether
                                                    they are used or
                                                    not. The less that
                                                    can be said is that
                                                    this model 

                                                    is not privacy
                                                    friendly.

                                                  
With the ACL
                                                    approach, a RO
                                                    directly manages an
                                                    ACL placed in front
                                                    of each RS. The Access
                                                      Control Decision
                                                      Function 

                                                        (ADF) at the RS is able to keep track from
                                                      prior decisions. The
                                                    GS is kept ignorant
                                                    of the content of
                                                    these ACLs and only
                                                    

                                                    delivers to its
                                                    clients attributes
                                                    that are placed into
                                                    access tokens. Such
                                                    a model may be
                                                    privacy friendly.

                                                  
Other comments are
                                                    between the lines
                                                    prefixed with
                                                    [Denis].

                                                  

                                                    

                                                      


                                                        

                                                          
On Tue, Jul 21, 2020 at 11:26 AM Denis <denis.ietf@free.fr> wrote:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Dick,

                                                          


                                                          

                                                          
 Thank
                                                          you for your
                                                          feedback.
                                                          Comments are
                                                          between the
                                                          lines.

                                                          


                                                          

                                                          

                                                          

                                                          
comments
                                                          inserted ... 

                                                          

                                                          

                                                          
On Tue, Jul 21, 2020 at 6:03 AM Denis <denis.ietf@free.fr> wrote:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Dick,

                                                          


                                                          

                                                          
I
                                                          duplicate the
                                                          most important
                                                          comment at the
                                                          beginning of
                                                          this email:

                                                          

                                                          
You are
                                                          considering
                                                          using an
                                                          access control
                                                          model to build
                                                          a workflow
                                                          model.

                                                           

                                                          While it may
                                                          be interesting
                                                          to define a
                                                          workflow
                                                          model, this
                                                          should be
                                                          considered 

                                                          as a separate
                                                          and different
                                                          work item.

                                                          

                                                          
See the
                                                          other comments
                                                          between the
                                                          lines.

                                                          

                                                          


                                                          

                                                          

                                                          
On
                                                          Mon, Jul 20,
                                                          2020 at 2:05
                                                          AM Denis <denis.ietf@free.fr>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hi Dick,

                                                          


                                                          

                                                          

                                                          
On
                                                          Fri, Jul 17,
                                                          2020 at 9:21
                                                          AM Denis <denis.ietf@free.fr>
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Francis and
                                                          Dick,

                                                          


                                                          

                                                          
The good
                                                          news first: we
                                                          are making
                                                          some progress.
                                                          We are now
                                                          close to an
                                                          agreement with
                                                          steps (1) up
                                                          to (3), 

                                                          ... except
                                                          that the place
                                                          where the user
                                                          consent is
                                                          captured is
                                                          not
                                                          mentioned/indicated.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          This major
                                                          question which
                                                          is currently
                                                          left
                                                          unanswered is
                                                          where, when
                                                          and how the
                                                          user consent
                                                          is captured.

                                                          

                                                          

                                                          


                                                          

                                                          
When is
                                                          covered, per
                                                          the sequence.
                                                          How and where
                                                          are out of
                                                          scope of what
                                                          I drafted. 

                                                          

                                                          

                                                          

                                                          

                                                          
It is clear
                                                          that the "User
                                                          consent and
                                                          choice" is not
                                                          currently
                                                          addressed in
                                                          the draft, but
                                                          it should.

                                                          The support of
                                                          the "User
                                                          consent and
                                                          choice" has
                                                          strong
                                                          implications
                                                          not only in
                                                          the sequences
                                                          of the
                                                          exchanges 

                                                          but also by
                                                          which entity
                                                          it should be
                                                          performed.

                                                          

                                                          

                                                          
"consent"
                                                          is in the
                                                          latest draft 7
                                                          times. 

                                                          

                                                          

                                                          

                                                          

                                                          
"Consent"
                                                          is present 5
                                                          times. The
                                                          User consent
                                                          is different
                                                          from the RO
                                                          consent
                                                          (when/if it is
                                                          required). 

                                                          

                                                          

                                                          
The server
                                                          acquires
                                                          consent and
                                                          authorization
                                                          from the user
                                                          and/or
                                                          resource owner
                                                          if
                                                          required.

                                                          

                                                          
User
                                                          consent is often
                                                          required
                                                          at the GS.
                                                          GNAP enables a
                                                          Client and  GS
                                                          to negotiate
                                                          the
                                                          interaction
                                                          mode for the
                                                          GS to obtain
                                                          consent.

                                                          

                                                          
 The GS may
                                                          require
                                                          explicit
                                                          consent from
                                                          the RO or User
                                                          to provide
                                                          these to the
                                                          Client.

                                                          

                                                          

                                                          
The User
                                                          consent is not
                                                          an alternative
                                                          to the RO
                                                          consent. So
                                                          using "and/or"
                                                          in the first
                                                          sentence is
                                                          incorrect.

                                                          

                                                          

                                                          


                                                          

                                                          
My
                                                          language is
                                                          sloppy there.
                                                          Consent is
                                                          always from
                                                          the RO. The
                                                          User may be
                                                          the RO.

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] No. Once
                                                    again: The "User
                                                      consent" is
                                                    different from what
                                                    you call the "RO
                                                      consent"
                                                    (when/if it is
                                                    required). 

                                                    The "RO consent" is
                                                    not in fact a
                                                    consent but the
                                                    release of a
                                                    capability to a
                                                    client by one of the
                                                    many R0s with which
                                                    

                                                    the GS has
                                                    relationships. 

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          
Since the
                                                          second
                                                          sentence is
                                                          using the
                                                          wording "often
                                                          required"
                                                          there is no
                                                          requirement to
                                                          get the User
                                                          consent.

                                                          

                                                          

                                                          

                                                          
User
                                                          consent may
                                                          not be
                                                          required.
                                                          There may not
                                                          be a User. The
                                                          consent may
                                                          have been
                                                          gathered
                                                          previously.

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] In order to
                                                    follow the privacy
                                                    principles, a "User
                                                    consent" phase is
                                                    required. The User
                                                    is a natural person.

                                                    A Client is called
                                                    either by a User
                                                    (i.e. a natural
                                                    person) or by a
                                                    Client application.
                                                    

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          
 

                                                          
The second
                                                          sentence does
                                                          not consider
                                                          the
                                                          possibility to
                                                          get the User
                                                          consent in a
                                                          place
                                                          different from
                                                          the GS.

                                                          

                                                          

                                                          
Agreed.
                                                          But we do
                                                          agree that the
                                                          GS gets the
                                                          consent,
                                                          either
                                                          directly from
                                                          the RO, or
                                                          from the
                                                          Client (in
                                                          your example).

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] No. I
                                                    disagree. In an ACL
                                                    based systems, the
                                                    GS does not need to
                                                    ask or receive any
                                                    consent.

                                                    The client selects
                                                    the set of
                                                    attributes that it
                                                    wants to be inserted
                                                    into an access
                                                    token.

                                                    If the GS has the
                                                    requested
                                                    attributes, then it
                                                    provides them,
                                                    otherwise it returns
                                                    an error to the
                                                    Client.

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          
IMO, the
                                                          User consent
                                                          should be
                                                          captured by
                                                          the Client,
                                                          i.e. not by
                                                          the GS. 

                                                          The
                                                          information
                                                          used to obtain
                                                          the User
                                                          consent should
                                                          be
                                                          standardized
                                                          (... and it
                                                          can be
                                                          standardized).

                                                          

                                                          

                                                          

                                                          
I
                                                          think the
                                                          abstract
                                                          sequence as
                                                          proposed by
                                                          Francis is a
                                                          great
                                                          addition, and
                                                          would clarify
                                                          where consent
                                                          is in the
                                                          sequence. 

                                                          

                                                          

                                                          
The current
                                                          sketch does
                                                          not illustrate
                                                          the place the
                                                          User Consent
                                                          is captured,
                                                          in particular
                                                          by the Client.

                                                          

                                                          

                                                          
It is an
                                                          abstraction.
                                                          The GS
                                                          receives the
                                                          consent. How
                                                          consent is
                                                          gathered is a
                                                          detail that is
                                                          dependent on
                                                          the use case.

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] I really
                                                    wonder whether there
                                                    is really a
                                                    "consent" to be
                                                    received by the GS
                                                    in both cases (i.e.
                                                    ACLs or
                                                    Capabilities).

                                                  

                                                  
    
                                                    
  • For ACLs, the
                                                      consent needs to
                                                      be done by the
                                                      Client.
    • 
                                                    
  • For
                                                      Capabilities, the
                                                      current
                                                      description is not
                                                      clear since the
                                                      inputs and the
                                                      outputs for this
                                                      "consent" phase
    
                                                      are not currently
                                                      described in the
                                                      draft.
    • 
                                                  

                                                  

                                                    

                                                      

                                                        

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 Another
                                                          important
                                                          point to
                                                          consider and
                                                          to explain is
                                                          related to the
                                                          assurances
                                                          that the user
                                                          can obtain
                                                          about 

                                                          the respect of
                                                          his choices.
                                                          This point is
                                                          currently left
                                                          unanswered in
draft-hardt-xauth-protocol-13.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
This point
                                                          is equally
                                                          important:
                                                          such assurance
                                                          can only be
                                                          obtained if
                                                          the access
                                                          token returned
                                                          to the client
                                                          

                                                          is not
                                                          considered to
                                                          be opaque to
                                                          the client.
                                                          This is a
                                                          necessary
                                                          condition but
                                                          not the single
                                                          condition: 

                                                          the Client
                                                          must also be
                                                          in a position
                                                          to
                                                          capture/memorize
                                                          the "User
                                                          consent and
                                                          choice" of the
                                                          user in order
                                                          to be able 

                                                          to verify it
                                                          afterwards
                                                          using the
                                                          content of the
                                                          access
                                                          token(s).

                                                          

                                                          

                                                          


                                                          

                                                          
We
                                                          disagree on
                                                          this being a
                                                          requirement
                                                          for all use
                                                          cases. It may
                                                          be in some. 

                                                          

                                                          

                                                          

                                                          

                                                          
OK. Then
                                                          this means
                                                          that there
                                                          will be no
                                                          sentence in
                                                          the draft such
                                                          as :

                                                          "access tokens
                                                          returned to
                                                          the client are
                                                          not considered
                                                          to be opaque
                                                          to the
                                                          client".

                                                          

                                                          

                                                          


                                                          

                                                          
For OAuth
                                                          use cases,
                                                          which GNAP
                                                          supports, the
                                                          access token
                                                          is opaque to
                                                          the Client. As
                                                          you have
                                                          noted, there
                                                          are use cases
                                                          where the
                                                          access token
                                                          is NOT opaque.

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] Wait a
                                                    second. There is no
                                                    requirement to
                                                    support all OAuth
                                                    use cases. 

                                                    I believe that there
                                                    is a requirement to
                                                    support OAuth 2.0
                                                    ASs, while the
                                                    clients may be
                                                    different 

                                                    and hence GNAP
                                                    clients do not need
                                                    to inherit of the
                                                    limitations of OAuth
                                                    2.0 clients.

                                                  

                                                    

                                                      

                                                        

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
If a RO
                                                          needs to be
                                                          involved and
                                                          since a RO is
                                                          directly
                                                          associated
                                                          with a RS, why
                                                          can't it be
                                                          directly
                                                          queried 

                                                          by the
                                                          appropriate RS
                                                          after step (2)
                                                          or later on ?

                                                          

                                                          

                                                          


                                                          

                                                          
Good
                                                          question.
                                                          Perhaps you
                                                          can expand on
                                                          a use case
                                                          where that
                                                          would be
                                                          useful?

                                                          

                                                          

                                                          

                                                          
Before I
                                                          expand, would
                                                          you be able to
                                                          explain first
                                                          under which
                                                          circumstances
                                                          a RO needs to
                                                          be queried by
                                                          a GS ?

                                                          How can the GS
                                                          identify which
                                                          RO to query ?

                                                          

                                                          

                                                          
If the
                                                          User is the
                                                          RO, then the
                                                          GS knows who
                                                          to query. 

                                                          

                                                          

                                                          

                                                          

                                                          
I still
                                                          have
                                                          difficulties
                                                          to understand
                                                          what you mean
                                                          here. 

                                                          How could a GS
                                                          know that "the
                                                          User is the
                                                          RO" ?  If "the
                                                          User is the
                                                          RO", why does
                                                          the GS needs
                                                          to query the
                                                          User ? 

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
To get
                                                          consent?

                                                          

                                                          

                                                          

                                                          
To get a
                                                          "RO consent"
                                                          to himself ???

                                                          

                                                          

                                                          


                                                          

                                                          
The GS
                                                          needs consent
                                                          from the RO.
                                                          If the RO is
                                                          the User, then
                                                          consent from
                                                          the RO is
                                                          equivalent to
                                                          consent from
                                                          the User.

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] See above.

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
If the RO
                                                          is a separate
                                                          entity, then
                                                          the GS knows
                                                          the RO from
                                                          the RS being
                                                          queried. 

                                                          

                                                          

                                                          

                                                          

                                                          
 ... and
                                                          this gives the
                                                          ability for
                                                          the GS to
                                                          log/trace all
                                                          the RSs
                                                          accessed by a
                                                          given User and
                                                          at which
                                                          instant of
                                                          time the
                                                          access token
                                                          has been
                                                          granted.

                                                          

                                                          

                                                          

                                                          
An
                                                          example is a
                                                          user would
                                                          like access to
                                                          an enterprise
                                                          asset where a
                                                          workflow is
                                                          started to
                                                          gain approval,
                                                          and an
                                                          administrator
                                                          or manager
                                                          provides
                                                          consent.

                                                          

                                                          

                                                          

                                                          
Thanks for
                                                          this example.
                                                          I finally
                                                          understand
                                                          what you have
                                                          in mind: you
                                                          are
                                                          considering
                                                          using an
                                                          access control
                                                          model to build
                                                          a workflow
                                                          model. 

                                                          While it may
                                                          be interesting
                                                          to define a
                                                          workflow
                                                          model, this
                                                          should be
                                                          considered as
                                                          a separate
                                                          and different
                                                          work item.

                                                          

                                                          

                                                          


                                                          

                                                          
The
                                                          actual
                                                          workflow is
                                                          out of scope.
                                                          

                                                          

                                                          

                                                          

                                                          
I am glad
                                                          you agree with
                                                          this. But this
                                                          means that
                                                          your example
                                                          was not
                                                          appropriate to
                                                          illustrate
                                                          your point.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
It
                                                          illustrates a
                                                          use case where
                                                          the RO and
                                                          User are not
                                                          the same
                                                          party, and why
                                                          the GS needs
                                                          to query the
                                                          RO, which was
                                                          your question
                                                          if I
                                                          understood it
                                                          correctly.

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] Since the
                                                    inputs and the
                                                    outputs for this "RO
                                                    consent" phase are
                                                    not currently
                                                    described in the
                                                    draft, the point is
                                                    still unsolved.

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          
 As soon as
                                                          there is a RO
                                                          consent
                                                          obtained at
                                                          the GS, the
                                                          major problem
                                                          is that the GS
                                                          is able to act
                                                          as Big
                                                          Brother.

                                                          If a RO
                                                          consent is
                                                          performed at
                                                          the RS, then
                                                          the GS will
                                                          not know who
                                                          the RS is: it
                                                          is then unable
                                                          to act as Big
                                                          Brother, 

                                                          even if it
                                                          would enjoy to
                                                          play that
                                                          role.

                                                          

                                                          

                                                          
In an
                                                          enterprise use
                                                          case, the GS's
                                                          knowledge of
                                                          who is
                                                          accessing
                                                          which RS is a
                                                          feature.

                                                        

                                                      

                                                    

                                                  

                                                  
Do you mean that it
                                                    is "normal" in an
                                                    enterprise that a
                                                    single point of
                                                    control is able to
                                                    trace all their
                                                    actions ? 

                                                    From a security
                                                    point of view, a
                                                    single point of
                                                    failure will have
                                                    dramatic
                                                    consequences.

                                                  

                                                    

                                                      

                                                        

                                                          
In your
                                                          use cases, it
                                                          seems that the
                                                          RO is the
                                                          User. 

                                                        

                                                      

                                                    

                                                  

                                                  
I do hope that you
                                                    have finally
                                                    understood that, in
                                                    my use case, the RO
                                                    is **not** the User.

                                                  

                                                    

                                                      

                                                        

                                                          
The GS
                                                          knows the User
                                                          is wanting to
                                                          let a Client
                                                          access
                                                          something. If
                                                          the access
                                                          token is
                                                          generic, and
                                                          could be
                                                          presented to
                                                          any RS that
                                                          provides a
                                                          standardized
                                                          function, 

                                                          then the GS
                                                          does not know
                                                          which RS is
                                                          being accessed
                                                          by a Client
                                                          for the User.
                                                          This seems to
                                                          meet your
                                                          privacy
                                                          objectives. If
                                                          not, what is
                                                          wrong?

                                                        

                                                      

                                                    

                                                  

                                                  
For security
                                                    reasons, an access
                                                    token needs to be
                                                    targeted (which does
                                                    not necessarily mean
                                                    that an identifier
                                                    of the RS shall be
                                                    included into the
                                                    access token).

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
if the
                                                          admin grants
                                                          access, then
                                                          the access
                                                          granted to the
                                                          client
                                                          changes. 

                                                          

                                                          

                                                          

                                                          
 

                                                          
The model
                                                          you propose
                                                          may be suited
                                                          for an
                                                          enterprise
                                                          environment
                                                          but is not
                                                          scalable over
                                                          the Internet.

                                                          

                                                          

                                                          
It is one
                                                          of the use
                                                          cases we are
                                                          working to
                                                          address. 

                                                          

                                                          

                                                          

                                                          
 What is
                                                          needed is an
                                                          access control
                                                          model usable
                                                          over the
                                                          Internet with
                                                          millions of
                                                          RSs and
                                                          thousands of
                                                          ASs/GSs.  

                                                          

                                                          

                                                          

                                                          
I agree
                                                          the model
                                                          should also
                                                          scale to
                                                          internet
                                                          scale. 

                                                          

                                                          

                                                          

                                                          

                                                          
Fine.
                                                          Another point
                                                          on which we
                                                          are in
                                                          agreement. 

                                                          

                                                          
The model
                                                          can scale to
                                                          the Internet
                                                          based on the
                                                          following
                                                          assumptions:

                                                          

                                                          
The flow
                                                          starts with
                                                          the steps (1)
                                                          to (4) as
                                                          illustrated by
                                                          Francis, i.e.
                                                          the flow
                                                          starts with a
                                                          contact with a
                                                          RS.

                                                          

                                                          
+----+
                                                           +------+
                                                           +---+  +---+
                                                           +---+

                                                          |User|
                                                           |Client|  |RS
                                                          |  |GS |  |RO
                                                          |

                                                          +----+
                                                           +------+
                                                           +---+  +-+-+
                                                           +-+-+

                                                            |(1) Service
                                                          Request     |
                                                               |

                                                           
                                                          |-------->|
                                                                |      |
                                                               |

                                                            |        
                                                          |(2) Service
                                                          Intent   |

                                                            |        
                                                          |------>|  
                                                             |      |

                                                            |        
                                                          |(3) AuthZ
                                                          Challenge  |

                                                            |        
                                                          |<------|  
                                                             |      |

                                                            |        
                                                          |(4) AuthZ
                                                          Request    |

                                                            |        
                                                          |------------->|
                                                               |

                                                          
The GS/AS
                                                          does not need
                                                          to have any
                                                          prior
                                                          relationship
                                                          with ROs
                                                          and/or RSs.

                                                          
Furthermore,
                                                          it is possible
                                                          to prevent the
                                                          GS to act as
                                                          Big Brother
                                                          when the
                                                          identity of
                                                          the RS is not
                                                          disclosed to
                                                          the GS.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
What
                                                          happens after
                                                          (4) above? 

                                                          

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] The key
                                                    point is that we
                                                    first need to agree
                                                    on the first four
                                                    exchanges. Do we ?

                                                  

                                                  
The fifth exchange
                                                    is different whether
                                                    ACLs or Capabilities
                                                    are being used.

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
Which
                                                          information is
                                                          supposed to be
                                                          presented to
                                                          the RO ?

                                                          Which
                                                          information is
                                                          supposed to be
                                                          returned by
                                                          the RO ?

                                                          

                                                          

                                                          


                                                          

                                                          
Just like
                                                          how the user
                                                          authenticates
                                                          to an AS, how
                                                          the AS and RO
                                                          communicate is
                                                          out of scope.

                                                          

                                                          

                                                          

                                                          

                                                          
At the
                                                          moment, the
                                                          usefulness of
                                                          a dialogue
                                                          between a GS
                                                          and a RO has
                                                          not been
                                                          explained, nor
                                                          demonstrated.

                                                          The question
                                                          is about the
                                                          functionality
                                                          of that
                                                          dialogue in
                                                          terms of input
                                                          and output
                                                          information
                                                          (and not about
                                                          

                                                          the design of
                                                          a protocol or
                                                          of a user
                                                          interface).
                                                          Anyway, AFAIU
                                                          a dialogue
                                                          between a GS
                                                          and a RO is
                                                          optional.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
See
                                                          enterprise
                                                          example above.

                                                          

                                                          

                                                          

                                                          
It is not
                                                          an access
                                                          control
                                                          example, but a
                                                          workflow
                                                          example.

                                                          
Access 
                                                          control has
                                                          been defined a
                                                          long time ago
                                                          and the last
                                                          edition of the
                                                          model has been
                                                          confirmed in
                                                          year 1996: ISO/IEC 10181-3: 1996.

                                                          "Information
                                                          technology —
                                                          Open Systems
                                                          Interconnection —
                                                          Security
                                                          frameworks for
                                                          open systems:
                                                          Access control
                                                          framework —
                                                          Part 3".

                                                          
Two major functions have ben defined: an Access Control Enforcement Function
                                                          (AEF) and an Access
                                                          Control
                                                          Decision
                                                          Function(ADF).

                                                          

                                                          
Access
                                                          Control Enforcement
                                                          Function
                                                          (AEF):

                                                          A specialized
                                                          function that
                                                          is part of the
                                                          access path
                                                          between an
                                                          initiator and
                                                          a target on
                                                          each access
                                                          request and
                                                          enforces the
                                                          decision made
                                                          by the ADF.

                                                          Access Control Decision
                                                          Function
                                                          (ADF) :

                                                          A
                                                          specialized
                                                          function that
                                                          makes access
                                                          control
                                                          decisions by
                                                          applying
                                                          access control
                                                          policy rules
                                                          to an access
                                                          request, ADI
                                                          (of
                                                          initiators,
                                                          targets,
                                                          access
                                                          requests, 

                                                          or
                                                          that retained
                                                          from prior
                                                          decisions),
                                                          and the
                                                          context in
                                                          which the
                                                          access request
                                                          is made.

                                                          
The role of
                                                          the RO is to
                                                          define the "access control policy rules" at the RS
                                                          according to
                                                          the context
                                                          in which the
                                                          access request
                                                          is made.

                                                          

                                                          

                                                          
I'm
                                                          pretty
                                                          familiar with
                                                          access control
                                                          systems. :) 

                                                          


                                                          

                                                          
I would
                                                          say that the
                                                          access control
                                                          is happening
                                                          at the RS. The
                                                          client
                                                          presents a
                                                          token when
                                                          accessing an
                                                          API. 

                                                          The RS uses
                                                          the token, and
                                                          any policy
                                                          required, to
                                                          make an access
                                                          decision.

                                                          

                                                          

                                                          

                                                          
Fine. It
                                                          looks like we
                                                          are in
                                                          agreement.
                                                          Unfortunately,
                                                          this is not
                                                          the case just
                                                          below.

                                                          

                                                          

                                                          

                                                          

                                                          
Here is
                                                          flow:

                                                          


                                                          

                                                          
1) The
                                                          Client
                                                          requests
                                                          access to an
                                                          RS from the
                                                          GS. 

                                                          

                                                          

                                                          

                                                          

                                                          
No. We are
                                                          no more in
                                                          agreement.
                                                          This is
                                                          different from
                                                          the flow drawn
                                                          by Francis.

                                                          

                                                          

                                                          
My bad.
                                                          Typo. I meant
                                                          RO.

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
2) The GS
                                                          queries the RS
                                                          if access
                                                          should be
                                                          granted. 

                                                          

                                                          

                                                          

                                                          

                                                          
 No. The GS
                                                          should not be
                                                          forced to have
                                                          a flow with
                                                          the RS.

                                                          

                                                          

                                                          
Same
                                                          mistake as
                                                          above, I meant
                                                          RO. 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          
3) If
                                                          access is
                                                          granted, the
                                                          GS creates an
                                                          access token
                                                          representing
                                                          the granted
                                                          access, and
                                                          returns it to
                                                          the Client. 

                                                          

                                                          

                                                          

                                                          

                                                          
This model
                                                          is by no way
                                                          conformant to
                                                          ISO/IEC 10181-3:
                                                          1996 

                                                          

                                                          

                                                          

                                                          
I'm
                                                          unclear on
                                                          why, or why it
                                                          is even
                                                          relevant. 

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          
4) The
                                                          Client
                                                          presents the
                                                          access token
                                                          to the RS to
                                                          show it has
                                                          been granted
                                                          access. 

                                                          

                                                          

                                                          

                                                          

                                                          
No. The
                                                          client
                                                          presents a
                                                          token when
                                                          accessing an
                                                          API. The RS
                                                          uses the
                                                          token, and any
                                                          policy
                                                          required, to
                                                          make an access
                                                          decision.

                                                          The token
                                                          never contains
                                                          an information
                                                          like "Please
                                                          grant an
                                                          access to the
                                                          holder of this
                                                          token".

                                                          

                                                          

                                                          
Let me
                                                          provide more
                                                          clarity in the
                                                          sentence:

                                                          


                                                          

                                                          
The
                                                          Client
                                                          presents the
                                                          access token
                                                          to the RS, to
                                                          show the RS
                                                          that the
                                                          Client has
                                                          been granted
                                                          access to a
                                                          resource at
                                                          the RS by the
                                                          GS.

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] This time,
                                                    please consider both
                                                    the ACLs approach
                                                    and the Capabilities
                                                    approach.

                                                  

                                                    

                                                      

                                                        

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
A couple
                                                          advantages of
                                                          this model:

                                                          
- that
                                                          the RS does
                                                          not need to
                                                          know much, if
                                                          anything about
                                                          the Client. 

                                                          
- the
                                                          access token
                                                          MAY be self
                                                          contained so
                                                          that the
                                                          Client does
                                                          not need to
                                                          query the GS
                                                          on each
                                                          access. 

                                                          

                                                          

                                                          

                                                          

                                                          
There are
                                                          so many
                                                          disadvantages
                                                          that I will
                                                          not list them.

                                                          

                                                          

                                                          
Darn: I
                                                          clearly was
                                                          not firing on
                                                          all cylinders
                                                          when I typed
                                                          this out. Let
                                                          me correct:

                                                          


                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
- the
                                                          access token
                                                          MAY be self
                                                          contained so
                                                          that the RS
                                                          does not need
                                                          to query the
                                                          GS on each
                                                          access to the
                                                          RS by the
                                                          Client.

                                                          

                                                          

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] A few
                                                    comments in the case
                                                    of a capability
                                                    approach:

                                                  

                                                    
- for each GS,
                                                      the RS needs to
                                                      locally manage
                                                      which operation(s)
                                                      is/are allowed to
                                                      it.

                                                      

                                                      - the GS needs to
                                                      establish a
                                                      trusted
                                                      communication
                                                      channel or an
                                                      authentication
                                                      mechanism with
                                                      each RO 

                                                         (which is
                                                      associated with an
                                                      explicit RS
                                                      identifier). 

                                                    

                                                    
- the GS could
                                                      play the role of
                                                      the RO and hence
                                                      be in a position
                                                      to issue any
                                                      capability for any
                                                      RS (without a "RO
                                                      consent"). 

                                                      

                                                         The target of
                                                      an attack will
                                                      clearly be the GS.

                                                    

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
I would
                                                          not say that
                                                          GNAP is an
                                                          access control
                                                          protocol, as
                                                          how the RS
                                                          uses the token
                                                          to determine
                                                          access is out
                                                          of scope.

                                                          

                                                          

                                                          

                                                          
This is
                                                          where we have
                                                          a major
                                                          discrepancy:
                                                          how the RS
                                                          uses the token
                                                          to determine
                                                          access is
                                                          *within* the
                                                          scope.

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                  [Denis] Do you agree
                                                  or disagree ?

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          
The RS
                                                          announces in
                                                          advance to the
                                                          client what it
                                                          needs so that
                                                          the client can
                                                          perform a a
                                                          given
                                                          operation and
                                                          if the client
                                                          supplies the
                                                          requested
                                                          attributes 

                                                          obtained from
                                                          some GS/AS(s)
                                                          trusted by the
                                                          RS, then
                                                          access to that
                                                          RS is granted
                                                          by the RS. If
                                                          the RS cannot
                                                          perform the
                                                          requested
                                                          operation on
                                                          its own, 

                                                          then the
                                                          client should
                                                          be informed
                                                          about some
                                                          requested
                                                          attributes
                                                          that need to
                                                          be obtained
                                                          from some
                                                          GS/AS(s)
                                                          trusted by the
                                                          next RS(s) in
                                                          a chain

                                                          for subsequent
                                                          operations.
                                                          The User
                                                          consent should
                                                          also be
                                                          obtained
                                                          before
                                                          performing the
                                                          chaining
                                                          operation.

                                                          

                                                          
Chaining
                                                          operations
                                                          between RSs
                                                          over the
                                                          Internet is
                                                          within the
                                                          scope (... and
                                                          may be
                                                          achieved).

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] Do you
                                                    agree or disagree ?

                                                  
Denis

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
For many
                                                          use cases, the
                                                          User is the
                                                          RO, and the
                                                          interaction is
                                                          through a user
                                                          interface, not
                                                          a machine
                                                          protocol. 

                                                          

                                                          

                                                          

                                                          

                                                          
Wait a
                                                          second. You
                                                          wrote "the
                                                          User is the
                                                          RO". The User
                                                          is attempting
                                                          to make an
                                                          access to a RS
                                                          by using a
                                                          Client. 

                                                          That
                                                          User is not
                                                          the RO of the
                                                          RS.   

                                                          

                                                          

                                                          

                                                          
The user
                                                          being the RO
                                                          is the initial
                                                          use case for
                                                          OAuth. 

                                                          

                                                          

                                                          

                                                          
OAuth 2.0
                                                          is no more
                                                          mandating such
                                                          a case.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          


                                                          
I don't
                                                          know what you
                                                          mean by that.

                                                          

                                                          

                                                          

                                                          
Copy and
                                                          paste from
                                                          draft-ietf-oauth-security-topics:

                                                          

                                                          

                                                          
OAuth
                                                          initially
                                                          assumed a
                                                          static
                                                          relationship
                                                          between
                                                          client,
                                                          authorization
                                                          server and
                                                          resource
                                                          servers. 
                                                          (...)  

                                                          With the
                                                          increasing
                                                          adoption of
                                                          OAuth, this
                                                          simple model
                                                          dissolved and,
                                                          in several
                                                          scenarios, was
                                                          replaced 

                                                          by a dynamic
                                                          establishment
                                                          of the
                                                          relationship
                                                          between
                                                          clients on one
                                                          side and the
                                                          authorization
                                                          and 

                                                          resource
                                                          servers of a
                                                          particular
                                                          deployment on
                                                          the other
                                                          side.

                                                          

                                                          This way, the
                                                          same client
                                                          could be used
                                                          to access
                                                          services of
                                                          different
                                                          providers (in
                                                          case of
                                                          standard APIs,
                                                          

                                                          such as e-mail
                                                          or OpenID
                                                          Connect) or
                                                          serve as a
                                                          frontend to a
                                                          particular
                                                          tenant in a
                                                          multi-tenancy
                                                          environment. 

                                                          

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
This
                                                          sentence does
                                                          not mention
                                                          the RO or the
                                                          Client. I'm
                                                          confused what
                                                          we are talking
                                                          about 

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
A client
                                                          application
                                                          would like
                                                          access to the
                                                          user's photos
                                                          at a photo
                                                          sharing site.
                                                          The resource
                                                          is the user's
                                                          photos. The
                                                          user is the
                                                          owner of that
                                                          resource.

                                                          

                                                          

                                                          

                                                          
If the user
                                                          has already
                                                          pre
                                                          established
                                                          the access
                                                          control policy
                                                          rules so that
                                                          it can access
                                                          to his own
                                                          photos 

                                                          then he does
                                                          not need to
                                                          grant in real
                                                          time any
                                                          additional
                                                          authorization.

                                                          

                                                          

                                                          
I don't
                                                          understand
                                                          what you are
                                                          trying to say.
                                                          The photo
                                                          sharing
                                                          example was a
                                                          driving use
                                                          case for the
                                                          creation of
                                                          OAuth.

                                                          

                                                          

                                                          

                                                          
We would
                                                          need to
                                                          revisit the
                                                          original
                                                          scenario and
                                                          consider if it
                                                          can be
                                                          addressed in a
                                                          different way
                                                          than the
                                                          original way.

                                                          

                                                          

                                                          
The use
                                                          case is the
                                                          same. Is there
                                                          a different
                                                          solution you
                                                          are proposing?

                                                          
 

                                                        

                                                      

                                                    

                                                  

                                                  


                                                  

                                                

                                                -- 

                                                Txauth mailing 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

        

      

    

    


    

  


--------------CB29C92AB4BBAAEE02AA5F36--


From nobody Tue Jul 28 11:31: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 4024C3A0AC2 for ; Tue, 28 Jul 2020 11:31:47 -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, RCVD_IN_MSPIKE_H2=-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 PfEa4PmLuZST for ; Tue, 28 Jul 2020 11:31:45 -0700 (PDT)
Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (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 89F7C3A0AC3 for ; Tue, 28 Jul 2020 11:31:42 -0700 (PDT)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id 06SIXdc2032450; Tue, 28 Jul 2020 14:33:40 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 28 Jul 2020 14:31:17 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by oc11expo18.exchange.mit.edu (18.9.4.49) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 28 Jul 2020 14:31:29 -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, 28 Jul 2020 14:31:29 -0400
From: Justin Richer 
To: Yaron Sheffer , GNAP Mailing List 
Thread-Topic: GNAP core document design team
Thread-Index: AQHWZNJ630HN/nF4qEqjWeaWWJysZakdT+Am
Date: Tue, 28 Jul 2020 18:31:29 +0000
Message-ID: <7bd4aa8425714c8f857610d679234e57@oc11expo18.exchange.mit.edu>
References: 
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: [172.58.221.100]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Txauth] GNAP core document design team
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, 28 Jul 2020 18:31:48 -0000

Thanks for starting this off, Yaron. While I expressed hesitation about a d=
esign team on the call yesterday, I can appreciate that this is a good way =
forward. Months of public discussion on the list haven't gotten us to a sin=
gle starting point yet, and so it's time to try a new approach. I can get b=
ehind that, and I'll put in my work to help get us unstuck.=20

And it's deeply important to remember that this process is just getting us =
a starting point, not a finished product. Everything in the design team doc=
ument will be up for discussion and consensus-driven decisions once adopted=
.=20

- Justin
________________________________________
From: Txauth [txauth-bounces@ietf.org] on behalf of Yaron Sheffer [yaronf.i=
etf@gmail.com]
Sent: Tuesday, July 28, 2020 7:30 AM
To: GNAP Mailing List
Subject: [Txauth] GNAP core document design team

Hi everyone,

Following our discussion yesterday, we are looking for volunteers for a sho=
rt-term design team. The team=92s goal will be to come up with an outline o=
f a document combining the best features of XYZ and XAuth. The timeframe wi=
ll be short =96 a few weeks. If you would like to join, please send the cha=
irs a private email by Friday.

Based on the expressed interest we will pick a small number of individuals =
for the team. We apologize in advance that we will not offer everyone a spo=
t on the design team.

Thanks,
                Leif and Yaron



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


From nobody Tue Jul 28 14:09: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 0F7863A08CD for ; Tue, 28 Jul 2020 14:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level: 
X-Spam-Status: No, score=-2.085 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 mx7oiRM-9qCq for ; Tue, 28 Jul 2020 14:08:51 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 570BD3A087B for ; Tue, 28 Jul 2020 14:08:50 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id j22so5890433lfm.2 for ; Tue, 28 Jul 2020 14:08: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=vK6iLBX33ppA9KStwSvX6Aqs5JN+pa2F/hgFknqVl3g=; b=qHDIUD66ic6Z8GX2W0/SmoqXxsEBtruCReuImF+vuHTJQMge4vJ6KfOnP4pNnfY9ON K9ocWXMrMoTLcvt5/b73owowpyRT9WAXy+wU9ZUR95pPZS8oIIVloGsnuMza05ktiCly 1j4tIlRxQZ/tN5Mvd4Di8pc1X9t6uFx/3NPH5EVJavl6Ug4M1cVLlsqr+0RxZoBvvIf4 mfDgj6WGVmrCuWeFvZ0UTeEsnr9sOgmnqJ2L+0GuUOvPwA0Hb9BMBqilSO3YbHF4dEPo cmMaPRZZDYnoHMSDjaSWgmyaXAn3I7wIt6xDAkvZUgKXUbFTr+TSs5zKHm8ghReJkGJk FwYA==
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=vK6iLBX33ppA9KStwSvX6Aqs5JN+pa2F/hgFknqVl3g=; b=Y1hfoWmjEIKsgO0EPfLClNwZ8J0+WCJvSw3NE4guwGaMtsooVTRbemImmNDlT0CFQi hTWeqKUswet6auH4xed1dxfW5VVvEaKecU1/wbTaajcR4O+KylXvUh28pmK+agia3kdA naCQYTJX13uyxiS4Q3mFGd2GA936tWp7uUVO/TPL2GFEBI2nePr4yWQITYH29n6As+p1 rvFjUi95FihORWW9cKXvu2WGGRgxum638NyohhIoRDLs7L9wzrOv/V0GqmrUg6raxY7W VUAjtc2JpL9tql76jAOd84tu6F9cIoQdwFOdXXry27xLnc9JxGyYMY/4vm4XWkZZHwja dBuQ==
X-Gm-Message-State: AOAM530MnRZgFBK1qImfmvFXqrp4sftQCSRexbVWL471SM/a8shCVgAS bTKW3im13OpPi7OTEHgCDZ5jLVPzB3pQ75BMd1E=
X-Google-Smtp-Source: ABdhPJz0JCkYwFVu5ZuMlXWoN22c7ZV7U1dXToyvG6a07uvHBo4k8Hf1ZRD+NCWs1j8Rqx646xsIVR2eyrV6jB8H9LE=
X-Received: by 2002:a19:74f:: with SMTP id 76mr652170lfh.164.1595970527999; Tue, 28 Jul 2020 14:08:47 -0700 (PDT)
MIME-Version: 1.0
References:   <37645bac-6769-a4dd-9e4f-d3f1afdb7a4e@free.fr>  <60671fa0-7f41-0ba2-4f44-f9db7004b7d3@free.fr>        <7b313658-f7f1-dad1-33aa-7d2107436856@free.fr>  <18b6aa1e-49bf-a7bc-c1a6-5f2b77355434@free.fr>  
In-Reply-To: 
From: Dick Hardt 
Date: Tue, 28 Jul 2020 14:08:10 -0700
Message-ID: 
To: Denis 
Cc: GNAP Mailing List 
Content-Type: multipart/alternative; boundary="00000000000064bd7e05ab86d86a"
Archived-At: 
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11
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, 28 Jul 2020 21:09:02 -0000

--00000000000064bd7e05ab86d86a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Denis

The Client / Server concept in GNAP (which it inherits from OAuth) is that
the Client is the thing that wants a resource, and the Server is the thing
that has the resource. Access to the resource is managed by the GS/AS.

So a web server that wants data from another server, is a Client.

*I* would solve the use case as I described (details on the RS / GS are
vague in the problem, so are vague in my solution)



On Tue, Jul 28, 2020 at 10:09 AM Denis  wrote:

> Hi Dick,
>
> OK. I should have written that in my example: the student connects to the
> University server (i.e. a RS) *using* a client.
>
> A client is a piece of software (supported by some hardware) that the use=
r
> uses to interact with RS(s) and AS(s).
>
> In a Client / Server model, the University Server cannot be a client: it
> is a server.
>
> Nevertheless, my first question still remains: Would you explain how *you=
*
> would handle the use case of a student registering to a new University ?
>
> Denis
>
> Hi Denis
>
> I did answer your question. The student is the User. The student is not
> the Client.
>
> =E1=90=A7
>
> On Tue, Jul 28, 2020 at 7:12 AM Denis  wrote:
>
>> Hi Dick,
>>
>> I am puzzled by your response. Your are the editor and a co-editor of th=
e
>> two following RFCs which state:
>>
>> RFC 6749:    In the traditional client-server authentication model, the
>> client requests an access-restricted resource
>>                      (protected resource) on the server by authenticatin=
g
>> with the server (...)
>>
>> RFC 6750 : The client uses the access token to access the protected
>> resources hosted by the resource server.
>>
>>                     The following two steps are specified within this
>> document:
>>
>>                                (E)  The client requests the protected
>> resource from the resource server and authenticates
>>                                        by presenting the access token.
>>
>>                               (F)  The resource server validates the
>> access token, and if valid, serves the request.
>>
>> In my use case, the student connects to the University server (i.e. a RS=
)
>> as a client. The University server cannot be a Client.
>> If you change/twist that basic vocabulary, we will not be able to
>> understand each other any more.
>>
>> BTW, my first question still remains: Would you explain how you would
>> handle the use case of a student registering to a new University ?
>>
>> Denis
>>
>>
>> Hi Denis
>>
>> The student (User) goes to the registration page of the University (the
>> Client)
>>
>> Similar to your example, the Client has a list of GS that it are
>> acceptable, or RS that may be acceptable.
>>
>> If the User selects a GS, then the Client starts a GNAP flow with the GS=
.
>>
>> If the User selects an RS, then the Client can call the RS to determine
>> which GSes to offer the User to use to get access to the RS.
>>
>> In summary, the University wants to consume Claims about the User, so it
>> is the Client.
>>
>> /Dick
>>
>>
>>
>> On Mon, Jul 27, 2020 at 12:49 AM Denis  wrote:
>>
>>> Hi Dick,
>>>
>>> The floor is yours.
>>>
>>> Would you explain how you would handle the use case of a student
>>> registering to a new University ?
>>>
>>> Would you also elaborate why in my explanations below, you think that
>>> "the University's registration system is the Client, not a Resource Ser=
ver"
>>> ?
>>>
>>> Denis
>>>
>>> Hi Denis
>>>
>>> I would think in your example below, that the University's registration
>>> system is the Client, not a Resource Server.
>>>
>>> Have a good night's sleep!
>>>
>>>
>>>
>>> On Fri, Jul 24, 2020 at 12:04 PM Denis  wrote:
>>>
>>>> Hi Dick,
>>>>
>>>> In order to send back a quick reply tonight, I will only respond to on=
e
>>>> of your questions:
>>>>
>>>> [Denis] How would be the data flow when access tokens from two GSs are
>>>> needed by a RS ?
>>>>
>>>> [Dick] I don't know of a use case where two tokens would be needed by
>>>> an RS. Would you elaborate?
>>>>
>>>> I already described on the list the case of a student registering to a
>>>> new University.
>>>>
>>>> First, the student connects to the RS from the new University and open=
s
>>>> an account
>>>> (at this time the student is using a pseudo and a private key to
>>>> authenticate). He fills some forms
>>>> and indicate its citizenship, his home address and his graduation in
>>>> his current university.
>>>>
>>>> When he is finished, he indicates that he wants to perform a
>>>> Registration operation.
>>>>
>>>> From the information gathered in the forms, the RS informs the client
>>>> that it needs two access tokens:
>>>>
>>>>    - one to demonstrate that his name and current home address are
>>>>    correct,and
>>>>    - another one to demonstrate that he got a graduation from its
>>>>    current University.
>>>>
>>>> Depending upon the information captured in the forms, the RS also
>>>> indicates which ASs/GSs are acceptable
>>>> and which kind of attributes are requested.
>>>>
>>>> The user consent and choice is performed by the client and once
>>>> approved by the student, two access tokens are separately requested.
>>>> Finally, two access tokens are presented to the RS while invoking a
>>>> Registration operation.
>>>>
>>>> Note that the start of the story is to open an account, e.g. using
>>>> FIDO. The needs of the RS are only disclosed to the student once he ha=
s
>>>> filled some forms
>>>> and indicated that he wanted to perform a Registration operation. Thus=
,
>>>> the needs that are revealed by the RS are dependant both upon the oper=
ation
>>>> that the student is willing to perform and the information collected i=
n
>>>> the forms.
>>>>
>>>> Denis
>>>>
>>>> Hi Denis, comments inserted ...
>>>>
>>>> On Fri, Jul 24, 2020 at 9:08 AM Denis  wrote:
>>>>
>>>>> Hi Dick,
>>>>>
>>>>> draft-hardt-xauth-protocol-13 describes a solution without clearly
>>>>> stating what the problem(s) to be solved is/are.
>>>>>
>>>>
>>>> I agree that the problem description is not as crisp as I would like i=
t
>>>> to be. A challenge is that there is a broad spectrum of use cases solv=
ed by
>>>> OAuth 2, and OpenID Connect, as well as the new use cases that are sol=
ved
>>>> by GNAP.
>>>>
>>>> That is why I am suggesting we gather some use cases so we have a
>>>> common understanding of the problems that are in scope.
>>>>
>>>>
>>>>>
>>>>> At the moment, draft-hardt-xauth-protocol-13 includes a single figure
>>>>> on page 4 and from previous discussions I understood that
>>>>> it is no more up-to-date since the first data flow is now a contact
>>>>> with a RS. The reason(s) for the GS to contact a RO has still not
>>>>> been explained (since the inputs and outputs are not described). The
>>>>> discovery information made available at various steps at the RS
>>>>> is not described.
>>>>>
>>>>
>>>> I have made no updates as we are in a quiet period prior to the WG
>>>> meeting next week when documents cannot be updated.
>>>>
>>>>
>>>>>
>>>>> Figure 4 shows only a single RS. Is the relaying of one operation by
>>>>> that RS to a second RS in the scope of this document ?
>>>>> If yes, how is it handled ?
>>>>>
>>>>
>>>> I view that as an advanced use case that would be covered in a separat=
e
>>>> document.
>>>>
>>>>
>>>>>
>>>>> Figure 4 shows only a single GS. How would be the data flow when
>>>>> access tokens from two GSs are needed by a RS ?
>>>>>
>>>>
>>>> I don't know of a use case where two tokens would be needed by an RS.
>>>> Would you elaborate?
>>>> The RS being able to accept tokens from two different GSes is covered,
>>>> but the Client is only using a token from one GS at a time.
>>>>
>>>>
>>>>
>>>>>
>>>>> What we need first is not a set of "use cases" but a clear model with
>>>>> a data flows and a list of its properties/characteristics.
>>>>>
>>>>
>>>> I disagree. The use cases describe the problems we are looking to
>>>> solve. The data flows are part of the solution. For example, from my
>>>> understanding of your use case, you don't want the GS to have visibili=
ty
>>>> into the User's activity. Am I correct that this is one of your
>>>> requirements for your use case?
>>>>
>>>>
>>>>
>>>>> Then after, we can understand much better which use cases can/will be
>>>>> supported. For example, shall a RS (or its RO) have
>>>>> prior relationships with the GS ? What is the difference/implications
>>>>> when it has or it hasn't ?
>>>>>
>>>>> In order to have a fair comparison, we should try to list model
>>>>> properties/characteristics.
>>>>>
>>>>> At the moment, the model I have described including the data flows is
>>>>> clear. The discovery information made available by a RS is clear.
>>>>> I have not listed all its properties/characteristics of that model,
>>>>> but I am pretty sure that you already have a flavour of it.
>>>>>
>>>>> In the mean time, it would be nice if you could show using two figure=
s:
>>>>>
>>>>>    - the case of the relaying of one operation by one RS to a second
>>>>>    RS (if it is in the scope of your document),
>>>>>    - the case where access tokens from two GSs are needed by one RS
>>>>>    (if it is in the scope of your document).
>>>>>
>>>>>
>>>> See above
>>>>
>>>>
>>>>>
>>>>>    -
>>>>>
>>>>> Denis
>>>>>
>>>>> Hi Denis
>>>>>
>>>>> I think it would be useful to take a step back and for you to describ=
e
>>>>> your use case.
>>>>> After that, we can explore the different ways that your use case can
>>>>> be addressed.
>>>>>
>>>>> Looking at your previous communication, it describes the solution, an=
d
>>>>> the justification,
>>>>> but it is not clear what use cases you are needing to solve.
>>>>>
>>>>> /Dick
>>>>>
>>>>>
>>>>> =E1=90=A7
>>>>>
>>>>> On Wed, Jul 22, 2020 at 9:34 AM Denis  wrote:
>>>>>
>>>>>> Hello Dick,
>>>>>>
>>>>>> I have identified the reason of the major difference between our two
>>>>>> approaches.
>>>>>>
>>>>>> Access control may be performed using either ACLs (Access Control
>>>>>> Lists) or Capabilities.
>>>>>>
>>>>>> *Note *: a capability identifies a resource and an allowed operation
>>>>>> that can be performed on that resource.
>>>>>>
>>>>>> You are advocating a Capabilities approach while I am advocating an
>>>>>> ACL approach.
>>>>>>
>>>>>> The capabilities approach allows the GS to trace every operation
>>>>>> performed by the users on any RS known by a GS.
>>>>>> The management of these capabilities is made via the GS or at the GS
>>>>>> by the various ROs. If the management is made
>>>>>> via the GS, then a trusted communication channel needs to be
>>>>>> established with every RO. If the management is made
>>>>>> at the GS, then an authentication mechanism needs to be established
>>>>>> with every RO. In the last case, the GS has the
>>>>>> ability to know all the capabilities of the users whether they are
>>>>>> used or not. The less that can be said is that this model
>>>>>> is not privacy friendly.
>>>>>>
>>>>>> With the ACL approach, a RO directly manages an ACL placed in front
>>>>>> of each RS. The Access Control Decision Function
>>>>>> (ADF) at the RS is able to keep track from prior decisions. The GS
>>>>>> is kept ignorant of the content of these ACLs and only
>>>>>> delivers to its clients attributes that are placed into access
>>>>>> tokens. Such a model may be privacy friendly.
>>>>>>
>>>>>> Other comments are between the lines prefixed with [Denis].
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 21, 2020 at 11:26 AM Denis  wrote:
>>>>>>
>>>>>>> Hello Dick,
>>>>>>>
>>>>>>> Thank you for your feedback. Comments are between the lines.
>>>>>>>
>>>>>>> comments inserted ...
>>>>>>>
>>>>>>> On Tue, Jul 21, 2020 at 6:03 AM Denis  wrote:
>>>>>>>
>>>>>>>> Hello Dick,
>>>>>>>>
>>>>>>>> I duplicate the most important comment at the beginning of this
>>>>>>>> email:
>>>>>>>>
>>>>>>>> You are considering using an access control model to build a workf=
low
>>>>>>>> model.
>>>>>>>>
>>>>>>>> While it may be interesting to define a workflow model, this shoul=
d
>>>>>>>> be considered
>>>>>>>> as a separate and different work item.
>>>>>>>>
>>>>>>>> See the other comments between the lines.
>>>>>>>>
>>>>>>>> On Mon, Jul 20, 2020 at 2:05 AM Denis  wrote:
>>>>>>>>
>>>>>>>>> Hi Dick,
>>>>>>>>>
>>>>>>>>> On Fri, Jul 17, 2020 at 9:21 AM Denis  wrote:
>>>>>>>>>
>>>>>>>>>> Hello Francis and Dick,
>>>>>>>>>>
>>>>>>>>>> The good news first: we are making some progress. We are now
>>>>>>>>>> close to an agreement with steps (1) up to (3),
>>>>>>>>>> ... except that the place where the user consent is captured is
>>>>>>>>>> not mentioned/indicated.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This major question which is currently left unanswered is where,
>>>>>>>>> when and how the user consent is captured.
>>>>>>>>>
>>>>>>>>
>>>>>>>> When is covered, per the sequence. How and where are out of scope
>>>>>>>> of what I drafted.
>>>>>>>>
>>>>>>>> It is clear that the "User consent and choice" is not currently
>>>>>>>> addressed in the draft, but it should.
>>>>>>>> The support of the "User consent and choice" has strong
>>>>>>>> implications not only in the sequences of the exchanges
>>>>>>>> but also by which entity it should be performed.
>>>>>>>>
>>>>>>> "consent" is in the latest draft 7 times.
>>>>>>>
>>>>>>> "Consent" is present 5 times. The User consent is different from th=
e
>>>>>>> RO consent (when/if it is required).
>>>>>>>
>>>>>>> The server acquires consent and authorization from the user *and/**=
or
>>>>>>> resource owner **if required.*
>>>>>>>
>>>>>>> User consent is *often required* at the GS. GNAP enables a Client
>>>>>>> and  GS to negotiate the interaction mode for the GS to obtain cons=
ent.
>>>>>>>
>>>>>>> The GS *may *require explicit consent from the RO or User to
>>>>>>> provide these to the Client.
>>>>>>>
>>>>>>> The User consent is not an alternative to the RO consent. So using
>>>>>>> "and/or" in the first sentence is incorrect.
>>>>>>>
>>>>>>
>>>>>> My language is sloppy there. Consent is always from the RO. The User
>>>>>> may be the RO.
>>>>>>
>>>>>> [Denis] No. Once again: The "*User consent*" is different from what
>>>>>> you call the "*RO consent*" (when/if it is required).
>>>>>> The "RO consent" is not in fact a consent but the release of a
>>>>>> capability to a client by one of the many R0s with which
>>>>>> the GS has relationships.
>>>>>>
>>>>>> Since the second sentence is using the wording "often required" ther=
e
>>>>>>> is no requirement to get the User consent.
>>>>>>>
>>>>>> User consent may not be required. There may not be a User. The
>>>>>> consent may have been gathered previously.
>>>>>>
>>>>>> [Denis] In order to follow the privacy principles, a "User consent"
>>>>>> phase is required. The User is a natural person.
>>>>>> A Client is called either by a User (i.e. a natural person) or by a
>>>>>> Client application.
>>>>>>
>>>>>> The second sentence does not consider the possibility to get the Use=
r
>>>>>>> consent in a place different from the GS.
>>>>>>>
>>>>>> Agreed. But we do agree that the GS gets the consent, either directl=
y
>>>>>> from the RO, or from the Client (in your example).
>>>>>>
>>>>>> [Denis] No. I disagree. In an ACL based systems, the GS does not nee=
d
>>>>>> to ask or receive any consent.
>>>>>> The client selects the set of attributes that it wants to be inserte=
d
>>>>>> into an access token.
>>>>>> If the GS has the requested attributes, then it provides them,
>>>>>> otherwise it returns an error to the Client.
>>>>>>
>>>>>> IMO, the User consent should be captured by the Client, i.e. not by
>>>>>>> the GS.
>>>>>>> The information used to obtain the User consent should be
>>>>>>> standardized (... and it can be standardized).
>>>>>>>
>>>>>>> I think the abstract sequence as proposed by Francis is a great
>>>>>>> addition, and would clarify where consent is in the sequence.
>>>>>>>
>>>>>>> The current sketch does not illustrate the place the User Consent i=
s
>>>>>>> captured, in particular by the Client.
>>>>>>>
>>>>>> It is an abstraction. The GS receives the consent. How consent is
>>>>>> gathered is a detail that is dependent on the use case.
>>>>>>
>>>>>> [Denis] I really wonder whether there is really a "consent" to be
>>>>>> received by the GS in both cases (i.e. ACLs or Capabilities).
>>>>>>
>>>>>>    - For ACLs, the consent needs to be done by the Client.
>>>>>>    - For Capabilities, the current description is not clear since
>>>>>>    the inputs and the outputs for this "consent" phase
>>>>>>    are not currently described in the draft.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Another important point to consider and to explain is related to
>>>>>>>>> the assurances that the user can obtain about
>>>>>>>>> the respect of his choices. This point is currently left
>>>>>>>>> unanswered in draft-hardt-xauth-protocol-13.
>>>>>>>>>
>>>>>>>> This point is equally important: such assurance can only be
>>>>>>>> obtained if the access token returned to the client
>>>>>>>> is not considered to be opaque to the client. This is a necessary
>>>>>>>> condition but not the single condition:
>>>>>>>> the Client must also be in a position to capture/memorize the "Use=
r
>>>>>>>> consent and choice" of the user in order to be able
>>>>>>>> to verify it afterwards using the content of the access token(s).
>>>>>>>>
>>>>>>>
>>>>>>> We disagree on this being a requirement for all use cases. It may b=
e
>>>>>>> in some.
>>>>>>>
>>>>>>> OK. Then this means that there will be no sentence in the draft suc=
h
>>>>>>> as :
>>>>>>> "access tokens returned to the client are not considered to be
>>>>>>> opaque to the client".
>>>>>>>
>>>>>>
>>>>>> For OAuth use cases, which GNAP supports, the access token is opaque
>>>>>> to the Client. As you have noted, there are use cases where the acce=
ss
>>>>>> token is NOT opaque.
>>>>>>
>>>>>> [Denis] Wait a second. There is no requirement to support all OAuth
>>>>>> use cases.
>>>>>> I believe that there is a requirement to support OAuth 2.0 ASs, whil=
e
>>>>>> the clients may be different
>>>>>> and hence GNAP clients do not need to inherit of the limitations of
>>>>>> OAuth 2.0 clients.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> If a RO needs to be involved and since a RO is directly associate=
d
>>>>>>>>>> with a RS, why can't it be directly queried
>>>>>>>>>> by the appropriate RS after step (2) or later on ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Good question. Perhaps you can expand on a use case where that
>>>>>>>>> would be useful?
>>>>>>>>>
>>>>>>>>> Before I expand, would you be able to explain first under which
>>>>>>>>> circumstances a RO needs to be queried by a GS ?
>>>>>>>>> How can the GS identify which RO to query ?
>>>>>>>>>
>>>>>>>> If the User is the RO, then the GS knows who to query.
>>>>>>>>
>>>>>>>> I still have difficulties to understand what you mean here.
>>>>>>>> How could a GS know that "the User is the RO" ?  If "the User is
>>>>>>>> the RO", why does the GS needs to query the User ?
>>>>>>>>
>>>>>>>
>>>>>>> To get consent?
>>>>>>>
>>>>>>> To get a "RO consent" to himself ???
>>>>>>>
>>>>>>
>>>>>> The GS needs consent from the RO. If the RO is the User, then consen=
t
>>>>>> from the RO is equivalent to consent from the User.
>>>>>>
>>>>>> [Denis] See above.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> If the RO is a separate entity, then the GS knows the RO from the
>>>>>>>> RS being queried.
>>>>>>>>
>>>>>>>>  ... and this gives the ability for the GS to log/trace all the RS=
s
>>>>>>>> accessed by a given User and at which instant of time the access t=
oken has
>>>>>>>> been granted.
>>>>>>>>
>>>>>>>> An example is a user would like access to an enterprise asset wher=
e
>>>>>>>> a workflow is started to gain approval, and an administrator or ma=
nager
>>>>>>>> provides consent.
>>>>>>>>
>>>>>>>> Thanks for this example. I finally understand what you have in
>>>>>>>> mind: you are considering using an access control model to build a=
 *workflow
>>>>>>>> model*.
>>>>>>>> While it may be interesting to define a workflow model, this shoul=
d
>>>>>>>> be considered as a *separate and different work item*.
>>>>>>>>
>>>>>>>
>>>>>>> The actual workflow is out of scope.
>>>>>>>
>>>>>>> I am glad you agree with this. But this means that your example was
>>>>>>> not appropriate to illustrate your point.
>>>>>>>
>>>>>>
>>>>>> It illustrates a use case where the RO and User are not the same
>>>>>> party, and why the GS needs to query the RO, which was your question=
 if I
>>>>>> understood it correctly.
>>>>>>
>>>>>> [Denis] Since the inputs and the outputs for this "RO consent" phase
>>>>>> are not currently described in the draft, the point is still unsolve=
d.
>>>>>>
>>>>>> As soon as there is a RO consent obtained at the GS, the major
>>>>>>> problem is that the GS is able to act as Big Brother.
>>>>>>> If a RO consent is performed at the RS, then the GS will not know
>>>>>>> who the RS is: it is then unable to act as Big Brother,
>>>>>>> even if it would enjoy to play that role.
>>>>>>>
>>>>>> In an enterprise use case, the GS's knowledge of who is accessing
>>>>>> which RS is a feature.
>>>>>>
>>>>>> Do you mean that it is "normal" in an enterprise that a single point
>>>>>> of control is able to trace all their actions ?
>>>>>> From a security point of view, a single point of failure will have
>>>>>> dramatic consequences.
>>>>>>
>>>>>> In your use cases, it seems that the RO is the User.
>>>>>>
>>>>>> I do hope that you have finally understood that, in my use case, the
>>>>>> RO is **not** the User.
>>>>>>
>>>>>> The GS knows the User is wanting to let a Client access something. I=
f
>>>>>> the access token is generic, and could be presented to any RS that p=
rovides
>>>>>> a standardized function,
>>>>>> then the GS does not know which RS is being accessed by a Client for
>>>>>> the User. This seems to meet your privacy objectives. If not, what i=
s wrong?
>>>>>>
>>>>>> For security reasons, an access token needs to be targeted (which
>>>>>> does not necessarily mean that an identifier of the RS shall be incl=
uded
>>>>>> into the access token).
>>>>>>
>>>>>> if the admin grants access, then the access granted to the client
>>>>>>> changes.
>>>>>>>
>>>>>>>> The model you propose may be suited for an enterprise environment
>>>>>>>> but is not scalable over the Internet.
>>>>>>>>
>>>>>>> It is one of the use cases we are working to address.
>>>>>>>
>>>>>>>> What is needed is an access control model usable over the Internet
>>>>>>>> with millions of RSs and thousands of ASs/GSs.
>>>>>>>>
>>>>>>> I agree the model should also scale to internet scale.
>>>>>>>
>>>>>>> Fine. Another point on which we are in agreement.
>>>>>>>
>>>>>>> The model can scale to the Internet based on the following
>>>>>>> assumptions:
>>>>>>>
>>>>>>> The flow starts with the steps (1) to (4) as illustrated by Francis=
,
>>>>>>> i.e. the flow starts with a contact with a RS.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *+----+  +------+  +---+  +---+  +---+ |User|  |Client|  |RS |  |GS
>>>>>>> |  |RO | +----+  +------+  +---+  +-+-+  +-+-+   |(1) Service Reque=
st     |
>>>>>>>      |   |-------->|       |      |      |   |         |(2) Service=
 Intent
>>>>>>>   |   |         |------>|      |      |   |         |(3) AuthZ Chal=
lenge  |
>>>>>>>   |         |<------|      |      |   |         |(4) AuthZ Request =
   |   |
>>>>>>>         |------------->|      |*
>>>>>>>
>>>>>>> The GS/AS does not need to have any prior relationship with ROs
>>>>>>> and/or RSs.
>>>>>>>
>>>>>>> Furthermore, it is possible to prevent the GS to act as Big Brother
>>>>>>> when the identity of the RS is not disclosed to the GS.
>>>>>>>
>>>>>>
>>>>>> What happens after (4) above?
>>>>>>
>>>>>> [Denis] The key point is that we first need to agree on the first
>>>>>> four exchanges. Do we ?
>>>>>>
>>>>>> The fifth exchange is different whether ACLs or Capabilities are
>>>>>> being used.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Which information is supposed to be presented to the RO ?
>>>>>>>>>> Which information is supposed to be returned by the RO ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Just like how the user authenticates to an AS, how the AS and RO
>>>>>>>>> communicate is out of scope.
>>>>>>>>>
>>>>>>>>> At the moment, the usefulness of a dialogue between a GS and a RO
>>>>>>>>> has not been explained, nor demonstrated.
>>>>>>>>> The question is about the functionality of that dialogue in terms
>>>>>>>>> of input and output information (and not about
>>>>>>>>> the design of a protocol or of a user interface). Anyway, AFAIU a
>>>>>>>>> dialogue between a GS and a RO is optional.
>>>>>>>>>
>>>>>>>>
>>>>>>>> See enterprise example above.
>>>>>>>>
>>>>>>>> It is not an access control example, but a workflow example.
>>>>>>>>
>>>>>>>> Access  control has been defined a long time ago and the last
>>>>>>>> edition of the model has been confirmed in year 1996: ISO/IEC 1018=
1-3:
>>>>>>>> 1996.
>>>>>>>> "Information technology =E2=80=94 Open Systems Interconnection =E2=
=80=94 Security
>>>>>>>> frameworks for open systems: Access control framework =E2=80=94 Pa=
rt 3".
>>>>>>>>
>>>>>>>> Two major functions have ben defined: an Access Control Enforcemen=
t Function
>>>>>>>> (AEF) and an Access Control Decision Function(ADF).
>>>>>>>>
>>>>>>>> Access Control Enforcement Function (AEF):
>>>>>>>> A specialized function that is part of the access path between an
>>>>>>>> initiator and a target on each access request and enforces the dec=
ision
>>>>>>>> made by the ADF.
>>>>>>>> Access Control Decision Function (ADF) :
>>>>>>>> A specialized function that makes access control decisions by
>>>>>>>> applying access control policy rules to an access request, ADI (of
>>>>>>>> initiators, targets, access requests,
>>>>>>>> or that retained from prior decisions), and the context in which
>>>>>>>> the access request is made.
>>>>>>>>
>>>>>>>> The role of the RO is to define the "access control policy rules"
>>>>>>>> at the RS according to the context in which the access request is
>>>>>>>> made.
>>>>>>>>
>>>>>>> I'm pretty familiar with access control systems. :)
>>>>>>>
>>>>>>> I would say that the access control is happening at the RS. The
>>>>>>> client presents a token when accessing an API.
>>>>>>> The RS uses the token, and any policy required, to make an access
>>>>>>> decision.
>>>>>>>
>>>>>>> Fine. It looks like we are in agreement. Unfortunately, this is not
>>>>>>> the case just below.
>>>>>>>
>>>>>>> Here is flow:
>>>>>>>
>>>>>>> 1) The Client requests access to an RS from the GS.
>>>>>>>
>>>>>>> No. We are no more in agreement. This is different from the flow
>>>>>>> drawn by Francis.
>>>>>>>
>>>>>> My bad. Typo. I meant RO.
>>>>>>
>>>>>>
>>>>>>> 2) The GS queries the RS if access should be granted.
>>>>>>>
>>>>>>>  No. The GS should not be forced to have a flow with the RS.
>>>>>>>
>>>>>> Same mistake as above, I meant RO.
>>>>>>
>>>>>>> 3) If access is granted, the GS creates an access token representin=
g
>>>>>>> the granted access, and returns it to the Client.
>>>>>>>
>>>>>>> This model is by no way conformant to ISO/IEC 10181-3: 1996
>>>>>>>
>>>>>> I'm unclear on why, or why it is even relevant.
>>>>>>
>>>>>>> 4) The Client presents the access token to the RS to show it has
>>>>>>> been granted access.
>>>>>>>
>>>>>>> No. The client presents a token when accessing an API. The RS uses
>>>>>>> the token, and any policy required, to make an access decision.
>>>>>>> The token never contains an information like "Please grant an acces=
s
>>>>>>> to the holder of this token".
>>>>>>>
>>>>>> Let me provide more clarity in the sentence:
>>>>>>
>>>>>> The Client presents the access token to the RS, to show the RS that
>>>>>> the Client has been granted access to a resource at the RS by the GS=
.
>>>>>>
>>>>>> [Denis] This time, please consider both the ACLs approach and the
>>>>>> Capabilities approach.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> A couple advantages of this model:
>>>>>>> - that the RS does not need to know much, if anything about the
>>>>>>> Client.
>>>>>>> - the access token MAY be self contained so that the Client does no=
t
>>>>>>> need to query the GS on each access.
>>>>>>>
>>>>>>> There are so many disadvantages that I will not list them.
>>>>>>>
>>>>>> Darn: I clearly was not firing on all cylinders when I typed this
>>>>>> out. Let me correct:
>>>>>>
>>>>>> - the access token MAY be self contained so that the RS does not nee=
d
>>>>>> to query the GS on each access to the RS by the Client.
>>>>>>
>>>>>> [Denis] A few comments in the case of a capability approach:
>>>>>>
>>>>>> - for each GS, the RS needs to locally manage which operation(s)
>>>>>> is/are allowed to it.
>>>>>>
>>>>>> - the GS needs to establish a trusted communication channel or an
>>>>>> authentication mechanism with each RO
>>>>>>    (which is associated with an explicit RS identifier).
>>>>>>
>>>>>> - the GS could play the role of the RO and hence be in a position to
>>>>>> issue any capability for any RS (without a "RO consent").
>>>>>>
>>>>>>    The target of an attack will clearly be the GS.
>>>>>>
>>>>>> I would not say that GNAP is an access control protocol, as how the
>>>>>>> RS uses the token to determine access is out of scope.
>>>>>>>
>>>>>>> This is where we have a major discrepancy: how the RS uses the
>>>>>>> token to determine access is *within* the scope.
>>>>>>>
>>>>>> [Denis] Do you agree or disagree ?
>>>>>>
>>>>>> The RS announces in advance to the client what it needs so that the
>>>>>>> client can perform a a given operation and if the client supplies t=
he
>>>>>>> requested attributes
>>>>>>> obtained from some GS/AS(s) trusted by the RS, then access to that
>>>>>>> RS is granted by the RS. If the RS cannot perform the requested ope=
ration
>>>>>>> on its own,
>>>>>>> then the client should be informed about some requested attributes
>>>>>>> that need to be obtained from some GS/AS(s) trusted by the next RS(=
s) in a
>>>>>>> chain
>>>>>>> for subsequent operations. The User consent should also be obtained
>>>>>>> before performing the chaining operation.
>>>>>>>
>>>>>>> Chaining operations between RSs over the Internet is within the
>>>>>>> scope (... and may be achieved).
>>>>>>>
>>>>>> [Denis] Do you agree or disagree ?
>>>>>>
>>>>>> Denis
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>> For many use cases, the User is the RO, and the interaction is
>>>>>>>>> through a user interface, not a machine protocol.
>>>>>>>>>
>>>>>>>>> Wait a second. You wrote "the User is the RO". The User is
>>>>>>>>> attempting to make an access to a RS by using a Client.
>>>>>>>>> *That* User is not the RO of the RS.
>>>>>>>>>
>>>>>>>> The user being the RO is the initial use case for OAuth.
>>>>>>>>
>>>>>>>> OAuth 2.0 is no more mandating such a case.
>>>>>>>>
>>>>>>>
>>>>>>> I don't know what you mean by that.
>>>>>>>
>>>>>>> Copy and paste from draft-ietf-oauth-security-topics:
>>>>>>>
>>>>>>> OAuth initially assumed a static relationship between client,
>>>>>>> authorization server and resource servers.  (...)
>>>>>>> With the increasing adoption of OAuth, this simple model dissolved
>>>>>>> and, in several scenarios, was replaced
>>>>>>> by a dynamic establishment of the relationship between clients on
>>>>>>> one side and the authorization and
>>>>>>> resource servers of a particular deployment on the other side.
>>>>>>>
>>>>>>> This way, the same client could be used to access services of
>>>>>>> different providers (in case of standard APIs,
>>>>>>> such as e-mail or OpenID Connect) or serve as a frontend to a
>>>>>>> particular tenant in a multi-tenancy environment.
>>>>>>>
>>>>>>>
>>>>>> This sentence does not mention the RO or the Client. I'm confused
>>>>>> what we are talking about
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> A client application would like access to the user's photos at a
>>>>>>>> photo sharing site. The resource is the user's photos. The user is=
 the
>>>>>>>> owner of that resource.
>>>>>>>>
>>>>>>>> If the user has already pre established the access control policy
>>>>>>>> rules so that it can access to his own photos
>>>>>>>> then he does not need to grant in real time any additional
>>>>>>>> authorization.
>>>>>>>>
>>>>>>> I don't understand what you are trying to say. The photo sharing
>>>>>>> example was a driving use case for the creation of OAuth.
>>>>>>>
>>>>>>> We would need to revisit the original scenario and consider if it
>>>>>>> can be addressed in a different way than the original way.
>>>>>>>
>>>>>> The use case is the same. Is there a different solution you are
>>>>>> proposing?
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Txauth mailing 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
>>>>
>>>>
>>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>> --
>> Txauth mailing list
>> Txauth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
>

--00000000000064bd7e05ab86d86a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Denis

The Client / =
Server concept in GNAP (which it inherits from OAuth) is that the Client is=
 the thing that wants a resource, and the Server is the thing that has the =
resource. Access to the resource is managed by the GS/AS.

So a web server that wants data from another server, is a Client.

*I* would solve the use case as I described (detail=
s on the RS / GS are vague in the problem, so are vague in my solution)



On Tue, Jul 28, 2020 at 10:09 AM Denis <=
denis.ietf@free.fr> wrote:
=


 =20
   =20
 =20
  

    
Hi Dick,

    


    

    
OK. I should have written that in my
      example: the student connects to the University server (i.e. a RS)
      *using* a client.

    


    

    
A client is a piece of software
      (supported by some hardware) that the user uses to interact with
      RS(s) and AS(s). 

    

    


    

    
In a Client / Server model, the
      University Server cannot be a client: it is a server.

    

    


    

    
Nevertheless, my first question still
      remains: Would you explain how *you* would handle the use case of
      a student registering to a new University ?

    


    

    
Denis

    

    

    

     =20
      
Hi Denis
        


        

        
I did answer your question. The student is the User. The
          student is not the Client.

        


        

      

      
3D""==E1=90=A7

      

      

        
On Tue, Jul 28, 2020 at 7:12
          AM Denis <denis.ietf@free.fr> wrote:

        

        

          

            
Hi Dick,

            


            

            
I am puzzled by your response. Your are the editor and
              a co-editor of the two following RFCs which state:

            


            

            
RFC 6749:=C2=A0=C2=A0=C2=A0 In the traditional client-serv=
er
              authentication model, the client requests an
              access-restricted 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 (protected res=
ource) on the server by
              authenticating with the server (...) 

              

              RFC 6750 : The client uses the access token to access the
              protected resources hosted by the resource server. 

              

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 following two st=
eps are specified
              within this document:

              

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (E)=C2=A0 The client requests
              the protected resource from the resource server and
              authenticates 

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 by presenting the
              access token.

              

              =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (F)=C2=A0 The resource server
              validates the access token, and if valid, serves the
              request.

            

            


            

            
In my use case, the student connects to the University
              server (i.e. a RS) as a client. The University server
              cannot be a Client.

              If you change/twist that basic vocabulary, we will not be
              able to understand each other any more.

            


            

            
BTW, my first question still remains: Would you explain
              how you would handle the use case of a student registering
              to a new University ?

            


            

            
Denis

            
=C2=A0 

            

            

              
Hi Denis
                


                

                
The student (User) goes to the registration page of
                  the University (the Client)

                


                

                
Similar to your example, the Client has a list of
                  GS that it are acceptable, or RS that may be
                  acceptable.

                


                

                
If the User selects a GS, then the Client starts a
                  GNAP flow with the GS.

                


                

                
If the User selects an RS, then the Client can call
                  the RS to determine which GSes to offer the User to
                  use to get access to the RS.

                


                

                
In summary, the University=C2=A0wants to consume Claim=
s
                  about the User, so it is the Client.

                  


                  

                  
/Dick

                  


                  

                  


                  

                  

                  

                    
On Mon, Jul 27,
                      2020 at 12:49 AM Denis <denis.ietf@free.fr>
                      wrote:

                    

                    

                      

                        
Hi Dick,

                        


                        

                        
The floor is yours.

                        


                        

                        
Would you explain how you would handle the
                          use case of a student registering to a new
                          University ?

                        


                        

                        
Would you also elaborate why in my
                          explanations below, you think that "the
                          University's=C2=A0registration system is the
                          Client, not a Resource Server" ?
                          


                          

                        

                        
Denis

                        

                        

                        

                          
Hi Denis
                            


                            

                            
I would think in your example below,
                              that the University's=C2=A0registration s=
ystem
                              is the Client, not a Resource Server.

                            


                            

                            
Have a good night's sleep!

                            


                            

                            


                            

                          

                          

                          

                            
On Fri,
                              Jul 24, 2020 at 12:04 PM Denis <denis.ietf@free.fr>
                              wrote:

                            

                            

                              

                                
Hi Dick,

                                  

                                

                                
In order to send back a quick reply
                                  tonight, I will only respond to one of
                                  your questions:

                                

                                  
 [Denis] How would be the
                                    data flow when access tokens from
                                    two GSs are needed by a RS ?

                                    


                                    

                                    
[Dick] I don't know of a use
                                      case where two tokens would be
                                      needed by an RS. Would you
                                      elaborate?

                                  

                                  
I already described on the list
                                    the case of a student registering to
                                    a new University.

                                  
 

                                  

                                  
First, the student connects to
                                    the RS from the new University and
                                    opens an account 

                                    (at this time the student is using a
                                    pseudo and a private key to
                                    authenticate). He fills some forms 

                                    and indicate its citizenship, his
                                    home address and his graduation in
                                    his current university. 

                                    

                                    When he is finished, he indicates
                                    that he wants to perform a
                                    Registration operation.

                                  


                                  

                                  
From the information gathered in
                                    the forms, the RS informs the client
                                    that it needs two access tokens:

                                  
    
                                    
  • one to demonstrate that his name
                                      and current home address are
                                      correct,and
    • 
                                    
  • another one to demonstrate that
                                      he got a graduation from its
                                      current University.
    • 
                                  

                                  
Depending upon the information
                                    captured in the forms, the RS also
                                    indicates which ASs/GSs are
                                    acceptable 

                                    and which kind of attributes are
                                    requested.

                                  
 

                                  

                                  
The user consent and choice is
                                    performed by the client and once
                                    approved by the student, two access
                                    tokens are separately requested.

                                    Finally, two access tokens are
                                    presented to the RS while invoking a
                                    Registration operation.

                                  


                                  

                                  
Note that the start of the story
                                    is to open an account, e.g. using
                                    FIDO. The needs of the RS are only
                                    disclosed to the student once he has
                                    filled some forms 

                                    and indicated that he wanted to
                                    perform a Registration operation.
                                    Thus, the needs that are revealed by
                                    the RS are dependant both upon the
                                    operation 

                                    that the student is willing to
                                    perform and the information
                                    collected in the forms.

                                  


                                  

                                  
Denis

                                

                                

                                

                                  

                                    
Hi Denis, comments inserted
                                      ...=C2=A0

                                    

                                    

                                      
On
                                        Fri, Jul 24, 2020 at 9:08 AM
                                        Denis <denis.ietf@free.fr>
                                        wrote:

                                      

                                      

                                        

                                          

                                            
Hi Dick,

                                            


                                            

                                            
draft-hardt-xauth-protocol=
-13
                                              describes a solution
                                              without clearly stating
                                              what the problem(s) to be
                                              solved is/are.

                                          

                                        

                                      

                                      


                                      

                                      
I agree that the problem
                                        description is not as crisp as I
                                        would like it to be. A challenge
                                        is that there is a broad
                                        spectrum of use cases solved by
                                        OAuth 2, and OpenID Connect, as
                                        well as the new use cases that
                                        are solved by GNAP.

                                      


                                      

                                      
That is why I am suggesting
                                        we gather some use cases so we
                                        have a common understanding of
                                        the problems that are in scope.
                                      
=C2=A0

                                      

                                        

                                          

                                            


                                            

                                            
At the moment,
                                              draft-hardt-xauth-protocol-13
                                              includes a single figure
                                              on page 4 and from
                                              previous discussions I
                                              understood that 

                                              it is no more up-to-date
                                              since the first data flow
                                              is now a contact with a
                                              RS. The reason(s) for the
                                              GS to contact a RO has
                                              still not 

                                              been explained (since the
                                              inputs and outputs are not
                                              described). The discovery
                                              information made available
                                              at various steps at the RS
                                              

                                              is not described.

                                            

                                          

                                        

                                      

                                      


                                      

                                      
I have made no updates as we
                                        are in a quiet period prior to
                                        the WG meeting next week when
                                        documents cannot be updated.

                                      
=C2=A0

                                      

                                        

                                          

                                            

                                              


                                              

                                            

                                            
Figure 4 shows only a
                                              single RS. Is the relaying
                                              of one operation by that
                                              RS to a second RS in the
                                              scope of this document ?

                                              If yes, how is it handled
                                              ?

                                            

                                          

                                        

                                      

                                      


                                      

                                      
I view that as an advanced
                                        use case that would be covered
                                        in a separate document.

                                      
=C2=A0

                                      

                                        

                                          

                                            
 

                                            


                                            

                                            
Figure 4 shows only a
                                              single GS. How would be
                                              the data flow when access
                                              tokens from two GSs are
                                              needed by a RS ?

                                            

                                          

                                        

                                      

                                      


                                      

                                      
I don't know of a use case
                                        where two tokens would be needed
                                        by an RS. Would you elaborate?
                                      
The RS being able to accept
                                        tokens from two different GSes
                                        is covered, but the Client is
                                        only using a token from one GS
                                        at a time.

                                      


                                      

                                      
=C2=A0

                                      

                                        

                                          

                                            
 

                                            

                                            What we need first is not a
                                            set of "use cases" bu=
t a
                                            clear model with a data
                                            flows and a list of its
                                            properties/characteristics.
                                            

                                          

                                        

                                      

                                      


                                      

                                      
I disagree. The use cases
                                        describe the problems we are
                                        looking to solve. The data flows
                                        are part of the solution. For
                                        example, from my understanding
                                        of your use case, you don't wan=
t
                                        the GS to have visibility into
                                        the User's activity. Am I
                                        correct that this is one of your
                                        requirements for your use case?
                                      


                                      

                                      
=C2=A0

                                      

                                        

                                          
 

                                          
Then after, we can
                                            understand much better which
                                            use cases can/will be
                                            supported. For example,
                                            shall a RS (or its RO) have
                                            

                                            prior relationships with the
                                            GS ? What is the
                                            difference/implications when
                                            it has or it hasn't ?

                                          

                                          


                                          

                                          
In order to have a fair
                                            comparison, we should try to
                                            list model
                                            properties/characteristics.
                                          


                                          

                                          
At the moment, the model
                                            I have described including
                                            the data flows is clear. The
                                            discovery information made
                                            available by a RS is clear.
                                          
I have not listed all its
                                            properties/characteristics
                                            of that model, but I am
                                            pretty sure that you already
                                            have a flavour of it.

                                          


                                          

                                          
In the mean time, it
                                            would be nice if you could
                                            show using two figures:

                                          
    
                                            
  • the case of the relaying
                                              of one operation by one RS
                                              to a second RS (if it is
                                              in the scope of your
                                              document),
    • 
                                            
  • the case where access
                                              tokens from two GSs are
                                              needed by one RS (if it is
                                              in the scope of your
                                              document).
    
                                            
    • 
                                          

                                        

                                      

                                      


                                      

                                      
See above

                                      
=C2=A0

                                      

                                        

                                          
    
                                            
  •  
    
                                            
    • 
                                          

                                          

                                            
Denis

                                          

                                          


                                          

                                          

                                            
Hi Denis
                                              


                                              

                                              
I think it would be
                                                useful to take a step
                                                back and for you to
                                                describe your use case.
                                                

                                                After that, we can
                                                explore the different
                                                ways that your use case
                                                can be addressed.=C2=A0
                                              


                                              

                                              
Looking at your
                                                previous communication,
                                                it describes the
                                                solution, and the
                                                justification, 

                                                but it is not clear what
                                                use cases you are
                                                needing to solve.

                                              


                                              

                                              
/Dick

                                              


                                              

                                              


                                              

                                            

                                            
3D""=E1=90=A7=


                                            

                                            

                                              
On
                                                Wed, Jul 22, 2020 at
                                                9:34 AM Denis <denis.ietf@free.fr>
                                                wrote:

                                              

                                              

                                                

                                                  
Hello Dick,

                                                  


                                                  

                                                  
I have identified
                                                    the reason of the
                                                    major difference
                                                    between our two
                                                    approaches.

                                                  


                                                  

                                                  
Access control
                                                    may be performed
                                                    using either ACLs
                                                    (Access Control
                                                    Lists) or
                                                    Capabilities.

                                                  


                                                  

                                                  
Note : a
                                                    capability
                                                    identifies a
                                                    resource and an
                                                    allowed operation
                                                    that can be
                                                    performed on that
                                                    resource.

                                                  

                                                  


                                                  

                                                  
You are
                                                    advocating a
                                                    Capabilities
                                                    approach while I am
                                                    advocating an ACL
                                                    approach.

                                                  
The capabilities
                                                    approach allows the
                                                    GS to trace every
                                                    operation performed
                                                    by the users on any
                                                    RS known by a GS.

                                                    The management of
                                                    these capabilities
                                                    is made via the GS
                                                    or at the GS by the
                                                    various ROs. If the
                                                    management is made 

                                                    via the GS, then a
                                                    trusted
                                                    communication
                                                    channel needs to be
                                                    established with
                                                    every RO. If the
                                                    management is made 

                                                    at the GS, then an
                                                    authentication
                                                    mechanism needs to
                                                    be established with
                                                    every RO. In the
                                                    last case, the GS
                                                    has the 

                                                    ability to know all
                                                    the capabilities of
                                                    the users whether
                                                    they are used or
                                                    not. The less that
                                                    can be said is that
                                                    this model 

                                                    is not privacy
                                                    friendly.

                                                  
With the ACL
                                                    approach, a RO
                                                    directly manages an
                                                    ACL placed in front
                                                    of each RS. The <=
span style=3D"font-family:Calibri">Access
                                                      Control =
Decision
                                                      Function 

                                                        (ADF) at the RS is able to keep track from
                                                      prior decisions. The
                                                    GS is kept ignorant
                                                    of the content of
                                                    these ACLs and only
                                                    

                                                    delivers to its
                                                    clients attributes
                                                    that are placed into
                                                    access tokens. Such
                                                    a model may be
                                                    privacy friendly.

                                                  
Other comments are
                                                    between the lines
                                                    prefixed with
                                                    [Denis].

                                                  

                                                    

                                                      


                                                        

                                                          
On Tue, Jul 21, 2020 at 11:26 AM Denis <denis.ietf@free.fr> wro=
te:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Dick,

                                                          


                                                          

                                                          
 Thank
                                                          you for your
                                                          feedback.
                                                          Comments are
                                                          between the
                                                          lines.

                                                          


                                                          

                                                          

                                                          

                                                          
=
comments
                                                          inserted ...=C2=
=A0

                                                          

                                                          

                                                          
On Tue, Jul 21, 2020 at 6:03 AM Denis <denis.ietf@free.fr> wrot=
e:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Dick,

                                                          


                                                          

                                                          
I
                                                          duplicate the
                                                          most important
                                                          comment at the
                                                          beginning of
                                                          this email:

                                                          

                                                          
You are
                                                          considering
                                                          using an
                                                          access control
                                                          model to build
                                                          a workflow
                                                          model.

                                                           

                                                          While it may
                                                          be interesting
                                                          to define a
                                                          workflow
                                                          model, this
                                                          should be
                                                          considered 

                                                          as a separate
                                                          and different
                                                          work item.

                                                          

                                                          
See the
                                                          other comments
                                                          between the
                                                          lines.

                                                          

                                                          


                                                          

                                                          

                                                          
=
On
                                                          Mon, Jul 20,
                                                          2020 at 2:05
                                                          AM Denis <denis.ietf@free.fr&=
gt;
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hi Dick,
                                                          


                                                          

                                                          

                                                          
=
On
                                                          Fri, Jul 17,
                                                          2020 at 9:21
                                                          AM Denis <denis.ietf@free.fr&=
gt;
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Hello
                                                          Francis and
                                                          Dick,

                                                          


                                                          

                                                          
The good
                                                          news first: we
                                                          are making
                                                          some progress.
                                                          We are now
                                                          close to an
                                                          agreement with
                                                          steps (1) up
                                                          to (3), 

                                                          ... except
                                                          that the place
                                                          where the user
                                                          consent is
                                                          captured is
                                                          not
                                                          mentioned/indicat=
ed.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          This major
                                                          question which
                                                          is currently
                                                          left
                                                          unanswered is
                                                          where, when
                                                          and how the
                                                          user consent
                                                          is captured.

                                                          

                                                          

                                                          


                                                          

                                                          
When is
                                                          covered, per
                                                          the sequence.
                                                          How and where
                                                          are out of
                                                          scope of what
                                                          I drafted. 

                                                          

                                                          

                                                          

                                                          

                                                          
It is clear
                                                          that the "Us=
er
                                                          consent and
                                                          choice" is n=
ot
                                                          currently
                                                          addressed in
                                                          the draft, but
                                                          it should.

                                                          The support of
                                                          the "User
                                                          consent and
                                                          choice" has
                                                          strong
                                                          implications
                                                          not only in
                                                          the sequences
                                                          of the
                                                          exchanges 

                                                          but also by
                                                          which entity
                                                          it should be
                                                          performed.

                                                          

                                                          

                                                          
"consen=
t"
                                                          is in the
                                                          latest draft 7
                                                          times. 

                                                          

                                                          

                                                          

                                                          

                                                          
"Consent&=
quot;
                                                          is present 5
                                                          times. The
                                                          User consent
                                                          is different
                                                          from the RO
                                                          consent
                                                          (when/if it is
                                                          required). 

                                                          

                                                          

                                                          
The server
                                                          acquires
                                                          consent and
                                                          authorization
                                                          from the user
                                                          and/or
                                                          resource owner
                                                          if
                                                          required.

                                                          

                                                          
User
                                                          consent is oft=
en
                                                          required
                                                          at the GS.
                                                          GNAP enables a
                                                          Client and=C2=A0 =
GS
                                                          to negotiate
                                                          the
                                                          interaction
                                                          mode for the
                                                          GS to obtain
                                                          consent.

                                                          

                                                          
 The GS may
                                                          require
                                                          explicit
                                                          consent from
                                                          the RO or User
                                                          to provide
                                                          these to the
                                                          Client.

                                                          

                                                          

                                                          
The User
                                                          consent is not
                                                          an alternative
                                                          to the RO
                                                          consent. So
                                                          using "and/o=
r"
                                                          in the first
                                                          sentence is
                                                          incorrect.

                                                          

                                                          

                                                          


                                                          

                                                          
My
                                                          language is
                                                          sloppy there.
                                                          Consent is
                                                          always from
                                                          the RO. The
                                                          User may be
                                                          the RO.

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] No. Once
                                                    again: The "Use=
r
                                                      consent" is
                                                    different from what
                                                    you call the "R=
O
                                                      consent"
                                                    (when/if it is
                                                    required). 

                                                    The "RO consent&qu=
ot; is
                                                    not in fact a
                                                    consent but the
                                                    release of a
                                                    capability to a
                                                    client by one of the
                                                    many R0s with which
                                                    

                                                    the GS has
                                                    relationships. 

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          
Since the
                                                          second
                                                          sentence is
                                                          using the
                                                          wording "oft=
en
                                                          required"
                                                          there is no
                                                          requirement to
                                                          get the User
                                                          consent.

                                                          

                                                          

                                                          

                                                          
User
                                                          consent may
                                                          not be
                                                          required.
                                                          There may not
                                                          be a User. The
                                                          consent may
                                                          have been
                                                          gathered
                                                          previously.

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] In order to
                                                    follow the privacy
                                                    principles, a "Use=
r
                                                    consent" phase is
                                                    required. The User
                                                    is a natural person.
                                                    A Client is called
                                                    either by a User
                                                    (i.e. a natural
                                                    person) or by a
                                                    Client application.
                                                    

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          
 

                                                          
The second
                                                          sentence does
                                                          not consider
                                                          the
                                                          possibility to
                                                          get the User
                                                          consent in a
                                                          place
                                                          different from
                                                          the GS.

                                                          

                                                          

                                                          
Agreed.
                                                          But we do
                                                          agree that the
                                                          GS gets the
                                                          consent,
                                                          either
                                                          directly from
                                                          the RO, or
                                                          from the
                                                          Client (in
                                                          your example).
                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] No. I
                                                    disagree. In an ACL
                                                    based systems, the
                                                    GS does not need to
                                                    ask or receive any
                                                    consent.

                                                    The client selects
                                                    the set of
                                                    attributes that it
                                                    wants to be inserted
                                                    into an access
                                                    token.

                                                    If the GS has the
                                                    requested
                                                    attributes, then it
                                                    provides them,
                                                    otherwise it returns
                                                    an error to the
                                                    Client.

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          
IMO, the
                                                          User consent
                                                          should be
                                                          captured by
                                                          the Client,
                                                          i.e. not by
                                                          the GS. 

                                                          The
                                                          information
                                                          used to obtain
                                                          the User
                                                          consent should
                                                          be
                                                          standardized
                                                          (... and it
                                                          can be
                                                          standardized).
                                                          

                                                          

                                                          

                                                          
I
                                                          think the
                                                          abstract
                                                          sequence as
                                                          proposed by
                                                          Francis is a
                                                          great
                                                          addition, and
                                                          would clarify
                                                          where consent
                                                          is in the
                                                          sequence. 

                                                          

                                                          

                                                          
The current
                                                          sketch does
                                                          not illustrate
                                                          the place the
                                                          User Consent
                                                          is captured,
                                                          in particular
                                                          by the Client.
                                                          

                                                          

                                                          
It is an
                                                          abstraction.
                                                          The GS
                                                          receives the
                                                          consent. How
                                                          consent is
                                                          gathered is a
                                                          detail that is
                                                          dependent on
                                                          the use case.
                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] I really
                                                    wonder whether there
                                                    is really a
                                                    "consent" to =
be
                                                    received by the GS
                                                    in both cases (i.e.
                                                    ACLs or
                                                    Capabilities).

                                                  

                                                  
    
                                                    
  • For ACLs, the
                                                      consent needs to
                                                      be done by the
                                                      Client.
    • 
                                                    
  • For
                                                      Capabilities, the
                                                      current
                                                      description is not
                                                      clear since the
                                                      inputs and the
                                                      outputs for this
                                                      "consent" p=
hase
    
                                                      are not currently
                                                      described in the
                                                      draft.
    • 
                                                  

                                                  

                                                    

                                                      

                                                        

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 Another
                                                          important
                                                          point to
                                                          consider and
                                                          to explain is
                                                          related to the
                                                          assurances
                                                          that the user
                                                          can obtain
                                                          about 

                                                          the respect of
                                                          his choices.
                                                          This point is
                                                          currently left
                                                          unanswered in
draft-hardt-xauth-protocol-13.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
This point
                                                          is equally
                                                          important:
                                                          such assurance
                                                          can only be
                                                          obtained if
                                                          the access
                                                          token returned
                                                          to the client
                                                          

                                                          is not
                                                          considered to
                                                          be opaque to
                                                          the client.
                                                          This is a
                                                          necessary
                                                          condition but
                                                          not the single
                                                          condition: 

                                                          the Client
                                                          must also be
                                                          in a position
                                                          to
                                                          capture/memorize
                                                          the "User
                                                          consent and
                                                          choice" of t=
he
                                                          user in order
                                                          to be able 

                                                          to verify it
                                                          afterwards
                                                          using the
                                                          content of the
                                                          access
                                                          token(s).

                                                          

                                                          

                                                          


                                                          

                                                          
We
                                                          disagree on
                                                          this being a
                                                          requirement
                                                          for all use
                                                          cases. It may
                                                          be in some. 

                                                          

                                                          

                                                          

                                                          

                                                          
OK. Then
                                                          this means
                                                          that there
                                                          will be no
                                                          sentence in
                                                          the draft such
                                                          as :

                                                          "access toke=
ns
                                                          returned to
                                                          the client are
                                                          not considered
                                                          to be opaque
                                                          to the
                                                          client".

                                                          

                                                          

                                                          


                                                          

                                                          
For OAuth
                                                          use cases,
                                                          which GNAP
                                                          supports, the
                                                          access token
                                                          is opaque to
                                                          the Client. As
                                                          you have
                                                          noted, there
                                                          are use cases
                                                          where the
                                                          access token
                                                          is NOT opaque.
                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] Wait a
                                                    second. There is no
                                                    requirement to
                                                    support all OAuth
                                                    use cases. 

                                                    I believe that there
                                                    is a requirement to
                                                    support OAuth 2.0
                                                    ASs, while the
                                                    clients may be
                                                    different 

                                                    and hence GNAP
                                                    clients do not need
                                                    to inherit of the
                                                    limitations of OAuth
                                                    2.0 clients.

                                                  

                                                    

                                                      

                                                        

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
If a RO
                                                          needs to be
                                                          involved and
                                                          since a RO is
                                                          directly
                                                          associated
                                                          with a RS, why
                                                          can't it be
                                                          directly
                                                          queried 

                                                          by the
                                                          appropriate RS
                                                          after step (2)
                                                          or later on ?
                                                          

                                                          

                                                          


                                                          

                                                          
Good
                                                          question.
                                                          Perhaps you
                                                          can expand on
                                                          a use case
                                                          where that
                                                          would be
                                                          useful?

                                                          

                                                          

                                                          

                                                          
Before I
                                                          expand, would
                                                          you be able to
                                                          explain first
                                                          under which
                                                          circumstances
                                                          a RO needs to
                                                          be queried by
                                                          a GS ?

                                                          How can the GS
                                                          identify which
                                                          RO to query ?

                                                          

                                                          

                                                          
If the
                                                          User is the
                                                          RO, then the
                                                          GS knows who
                                                          to query. 

                                                          

                                                          

                                                          

                                                          

                                                          
I still
                                                          have
                                                          difficulties
                                                          to understand
                                                          what you mean
                                                          here. 

                                                          How could a GS
                                                          know that "t=
he
                                                          User is the
                                                          RO" ?=C2=A0 =
If "the
                                                          User is the
                                                          RO", why doe=
s
                                                          the GS needs
                                                          to query the
                                                          User ? 

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
To get
                                                          consent?

                                                          

                                                          

                                                          

                                                          
To get a
                                                          "RO consent&=
quot;
                                                          to himself ???
                                                          

                                                          

                                                          


                                                          

                                                          
The GS
                                                          needs consent
                                                          from the RO.
                                                          If the RO is
                                                          the User, then
                                                          consent from
                                                          the RO is
                                                          equivalent to
                                                          consent from
                                                          the User.

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] See above.

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
If the RO
                                                          is a separate
                                                          entity, then
                                                          the GS knows
                                                          the RO from
                                                          the RS being
                                                          queried. 

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0... and
                                                          this gives the
                                                          ability for
                                                          the GS to
                                                          log/trace all
                                                          the RSs
                                                          accessed by a
                                                          given User and
                                                          at which
                                                          instant of
                                                          time the
                                                          access token
                                                          has been
                                                          granted.

                                                          

                                                          

                                                          

                                                          
An
                                                          example=C2=A0is a
                                                          user would
                                                          like access to
                                                          an enterprise
                                                          asset where a
                                                          workflow is
                                                          started to
                                                          gain approval,
                                                          and an
                                                          administrator
                                                          or manager
                                                          provides
                                                          consent.

                                                          

                                                          

                                                          

                                                          
Thanks for
                                                          this example.
                                                          I finally
                                                          understand
                                                          what you have
                                                          in mind: you
                                                          are
                                                          considering
                                                          using an
                                                          access control
                                                          model to build
                                                          a workflow
                                                          model. 

                                                          While it may
                                                          be interesting
                                                          to define a
                                                          workflow
                                                          model, this
                                                          should be
                                                          considered as
                                                          a separate
                                                          and different
                                                          work item.
                                                          

                                                          

                                                          


                                                          

                                                          
The
                                                          actual
                                                          workflow is
                                                          out of scope.
                                                          

                                                          

                                                          

                                                          

                                                          
I am glad
                                                          you agree with
                                                          this. But this
                                                          means that
                                                          your example
                                                          was not
                                                          appropriate to
                                                          illustrate
                                                          your point.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
It
                                                          illustrates a
                                                          use case where
                                                          the RO and
                                                          User are not
                                                          the same
                                                          party, and why
                                                          the GS needs
                                                          to query the
                                                          RO, which was
                                                          your question
                                                          if I
                                                          understood it
                                                          correctly.

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] Since the
                                                    inputs and the
                                                    outputs for this "=
RO
                                                    consent" phase are
                                                    not currently
                                                    described in the
                                                    draft, the point is
                                                    still unsolved.

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          
 As soon as
                                                          there is a RO
                                                          consent
                                                          obtained at
                                                          the GS, the
                                                          major problem
                                                          is that the GS
                                                          is able to act
                                                          as Big
                                                          Brother.

                                                          If a RO
                                                          consent is
                                                          performed at
                                                          the RS, then
                                                          the GS will
                                                          not know who
                                                          the RS is: it
                                                          is then unable
                                                          to act as Big
                                                          Brother, 

                                                          even if it
                                                          would enjoy to
                                                          play that
                                                          role.

                                                          

                                                          

                                                          
In an
                                                          enterprise use
                                                          case, the GS'=
s
                                                          knowledge of
                                                          who is
                                                          accessing
                                                          which RS is a
                                                          feature.

                                                        

                                                      

                                                    

                                                  

                                                  
Do you mean that it
                                                    is "normal" i=
n an
                                                    enterprise that a
                                                    single point of
                                                    control is able to
                                                    trace all their
                                                    actions ? 

                                                    From a security
                                                    point of view, a
                                                    single point of
                                                    failure will have
                                                    dramatic
                                                    consequences.

                                                  

                                                    

                                                      

                                                        

                                                          
In your
                                                          use cases, it
                                                          seems that the
                                                          RO is the
                                                          User. 

                                                        

                                                      

                                                    

                                                  

                                                  
I do hope that you
                                                    have finally
                                                    understood that, in
                                                    my use case, the RO
                                                    is **not** the User.
                                                  

                                                    

                                                      

                                                        

                                                          
The GS
                                                          knows the User
                                                          is wanting to
                                                          let a Client
                                                          access
                                                          something. If
                                                          the access
                                                          token is
                                                          generic, and
                                                          could be
                                                          presented to
                                                          any RS that
                                                          provides a
                                                          standardized
                                                          function, 

                                                          then the GS
                                                          does not know
                                                          which RS is
                                                          being accessed
                                                          by a Client
                                                          for the User.
                                                          This seems to
                                                          meet your
                                                          privacy
                                                          objectives. If
                                                          not, what is
                                                          wrong?

                                                        

                                                      

                                                    

                                                  

                                                  
For security
                                                    reasons, an access
                                                    token needs to be
                                                    targeted (which does
                                                    not necessarily mean
                                                    that an identifier
                                                    of the RS shall be
                                                    included into the
                                                    access token).

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
if the
                                                          admin grants
                                                          access, then
                                                          the access
                                                          granted to the
                                                          client
                                                          changes. 

                                                          

                                                          

                                                          

                                                          
 

                                                          
The model
                                                          you propose
                                                          may be suited
                                                          for an
                                                          enterprise
                                                          environment
                                                          but is not
                                                          scalable over
                                                          the Internet.

                                                          

                                                          

                                                          
It is one
                                                          of the use
                                                          cases we are
                                                          working to
                                                          address. 

                                                          

                                                          

                                                          

                                                          
 What is
                                                          needed is an
                                                          access control
                                                          model usable
                                                          over the
                                                          Internet with
                                                          millions of
                                                          RSs and
                                                          thousands of
                                                          ASs/GSs.=C2=A0 
                                                          

                                                          

                                                          

                                                          
I agree
                                                          the model
                                                          should also
                                                          scale to
                                                          internet
                                                          scale. 

                                                          

                                                          

                                                          

                                                          

                                                          
Fine.
                                                          Another point
                                                          on which we
                                                          are in
                                                          agreement. 

                                                          

                                                          
The model
                                                          can scale to
                                                          the Internet
                                                          based on the
                                                          following
                                                          assumptions:

                                                          

                                                          
The flow
                                                          starts with
                                                          the steps (1)
                                                          to (4) as
                                                          illustrated by
                                                          Francis, i.e.
                                                          the flow
                                                          starts with a
                                                          contact with a
                                                          RS.

                                                          

                                                          
+----+
                                                          =C2=A0+------+
                                                          =C2=A0+---+ =C2=
=A0+---+
                                                          =C2=A0+---+

                                                          |User|
                                                          =C2=A0|Client| =
=C2=A0|RS
                                                          | =C2=A0|GS | =C2=
=A0|RO
                                                          |

                                                          +----+
                                                          =C2=A0+------+
                                                          =C2=A0+---+ =C2=
=A0+-+-+
                                                          =C2=A0+-+-+

                                                          =C2=A0 |(1) Servi=
ce
                                                          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
                                                          |(2) Service
                                                          Intent =C2=A0 |
                                                          =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =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) AuthZ
                                                          Challenge =C2=A0|=


                                                          =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =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) AuthZ
                                                          Request =C2=A0 =
=C2=A0|

                                                          =C2=A0 | =C2=A0 =
=C2=A0 =C2=A0 =C2=A0
                                                          |------------->=
;|
                                                          =C2=A0 =C2=A0 =C2=
=A0|

                                                          
The GS/AS
                                                          does not need
                                                          to have any
                                                          prior
                                                          relationship
                                                          with ROs
                                                          and/or RSs.

                                                          
Furthermore,
                                                          it is possible
                                                          to prevent the
                                                          GS to act as
                                                          Big Brother
                                                          when the
                                                          identity of
                                                          the RS is not
                                                          disclosed to
                                                          the GS.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
What
                                                          happens after
                                                          (4) above? 

                                                          

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] The key
                                                    point is that we
                                                    first need to agree
                                                    on the first four
                                                    exchanges. Do we ?

                                                  

                                                  
The fifth exchange
                                                    is different whether
                                                    ACLs or Capabilities
                                                    are being used.

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
Which
                                                          information is
                                                          supposed to be
                                                          presented to
                                                          the RO ?

                                                          Which
                                                          information is
                                                          supposed to be
                                                          returned by
                                                          the RO ?

                                                          

                                                          

                                                          


                                                          

                                                          
Just like
                                                          how the user
                                                          authenticates
                                                          to an AS, how
                                                          the AS and RO
                                                          communicate is
                                                          out of scope.

                                                          

                                                          

                                                          

                                                          

                                                          
At the
                                                          moment, the
                                                          usefulness of
                                                          a dialogue
                                                          between a GS
                                                          and a RO has
                                                          not been
                                                          explained, nor
                                                          demonstrated.

                                                          The question
                                                          is about the
                                                          functionality
                                                          of that
                                                          dialogue in
                                                          terms of input
                                                          and output
                                                          information
                                                          (and not about
                                                          

                                                          the design of
                                                          a protocol or
                                                          of a user
                                                          interface).
                                                          Anyway, AFAIU
                                                          a dialogue
                                                          between a GS
                                                          and a RO is
                                                          optional.

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
See
                                                          enterprise
                                                          example above.
                                                          

                                                          

                                                          

                                                          
It is not
                                                          an access
                                                          control
                                                          example, but a
                                                          workflow
                                                          example.

                                                          
Access=C2=A0
                                                          control has
                                                          been defined a
                                                          long time ago
                                                          and the last
                                                          edition of the
                                                          model has been
                                                          confirmed in
                                                          year 1996: =
ISO/IEC=C2=A010181-3: 1996.

                                                          "Information
                                                          technology=C2=A0=
=E2=80=94
                                                          Open Systems
                                                          Interconnection=
=C2=A0=E2=80=94
                                                          Security
                                                          frameworks for
                                                          open systems:
                                                          Access control
                                                          framework=C2=A0=
=E2=80=94
                                                          Part=C2=A03"=
.

                                                          
Two major functions have ben defi=
ned: an Access =
Control Enforcement Function
                                                          (AEF) and an Access
                                                          Control
                                                          Decision
                                                          Function(ADF).

                                                          

                                                          
Access
                                                          Control Enf=
orcement
                                                          Function
                                                          (AEF):

                                                          A specialized
                                                          function that
                                                          is part of the
                                                          access path
                                                          between an
                                                          initiator and
                                                          a target on
                                                          each access
                                                          request and
                                                          enforces the
                                                          decision made
                                                          by the ADF.

                                                          Access Control Decision
                                                          Function
                                                          (ADF) :

                                                          A
                                                          specialized
                                                          function that
                                                          makes access
                                                          control
                                                          decisions by
                                                          applying
                                                          access control
                                                          policy rules
                                                          to an access
                                                          request, ADI
                                                          (of
                                                          initiators,
                                                          targets,
                                                          access
                                                          requests, =


                                                          or
                                                          that retained
                                                          from prior
                                                          decisions),
                                                          and the
                                                          context in
                                                          which the
                                                          access request
                                                          is made.
                                                          
The role of
                                                          the RO is to
                                                          define the "=
access control policy rules" at th=
e RS
                                                          according to
                                                          the context
                                                          in which the
                                                          access request
                                                          is made.

                                                          

                                                          

                                                          
I'm
                                                          pretty
                                                          familiar with
                                                          access control
                                                          systems. :)=C2=A0=


                                                          


                                                          

                                                          
I would
                                                          say that the
                                                          access control
                                                          is happening
                                                          at the RS. The
                                                          client
                                                          presents a
                                                          token when
                                                          accessing an
                                                          API. 

                                                          The RS uses
                                                          the token, and
                                                          any policy
                                                          required, to
                                                          make an access
                                                          decision.

                                                          

                                                          

                                                          

                                                          
Fine. It
                                                          looks like we
                                                          are in
                                                          agreement.
                                                          Unfortunately,
                                                          this is not
                                                          the case just
                                                          below.

                                                          

                                                          

                                                          

                                                          

                                                          
Here is
                                                          flow:

                                                          


                                                          

                                                          
1) The
                                                          Client
                                                          requests
                                                          access to an
                                                          RS from the
                                                          GS. 

                                                          

                                                          

                                                          

                                                          

                                                          
No. We are
                                                          no more in
                                                          agreement.
                                                          This is
                                                          different from
                                                          the flow drawn
                                                          by Francis.

                                                          

                                                          

                                                          
My bad.
                                                          Typo. I meant
                                                          RO.

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
2) The GS
                                                          queries the RS
                                                          if access
                                                          should be
                                                          granted. 

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0No. The =
GS
                                                          should not be
                                                          forced to have
                                                          a flow with
                                                          the RS.

                                                          

                                                          

                                                          
Same
                                                          mistake as
                                                          above, I meant
                                                          RO.=C2=A0

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          
3) If
                                                          access is
                                                          granted, the
                                                          GS creates an
                                                          access token
                                                          representing
                                                          the granted
                                                          access, and
                                                          returns it to
                                                          the Client. 

                                                          

                                                          

                                                          

                                                          

                                                          
This model
                                                          is by no way
                                                          conformant to
                                                          ISO/IEC=C2=A010181-3:
                                                          1996 

                                                          
                                                          

                                                          

                                                          
I'm
                                                          unclear on
                                                          why, or why it
                                                          is even
                                                          relevant. 

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          
4) The
                                                          Client
                                                          presents the
                                                          access token
                                                          to the RS to
                                                          show it has
                                                          been granted
                                                          access. 

                                                          

                                                          

                                                          

                                                          

                                                          
No. The
                                                          client
                                                          presents a
                                                          token when
                                                          accessing an
                                                          API. The RS
                                                          uses the
                                                          token, and any
                                                          policy
                                                          required, to
                                                          make an access
                                                          decision.

                                                          The token
                                                          never contains
                                                          an information
                                                          like "Please
                                                          grant an
                                                          access to the
                                                          holder of this
                                                          token".

                                                          

                                                          

                                                          
Let me
                                                          provide more
                                                          clarity in the
                                                          sentence:

                                                          


                                                          

                                                          
The
                                                          Client
                                                          presents the
                                                          access token
                                                          to the RS, to
                                                          show the RS
                                                          that the
                                                          Client has
                                                          been granted
                                                          access to a
                                                          resource at
                                                          the RS by the
                                                          GS.

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] This time,
                                                    please consider both
                                                    the ACLs approach
                                                    and the Capabilities
                                                    approach.

                                                  

                                                    

                                                      

                                                        

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
A couple
                                                          advantages of
                                                          this model:

                                                          
- that
                                                          the RS does
                                                          not need to
                                                          know much, if
                                                          anything about
                                                          the Client.=C2=A0=


                                                          
- the
                                                          access token
                                                          MAY be self
                                                          contained so
                                                          that the
                                                          Client does
                                                          not need to
                                                          query the GS
                                                          on each
                                                          access. 

                                                          

                                                          

                                                          

                                                          

                                                          
There are
                                                          so many
                                                          disadvantages
                                                          that I will
                                                          not list them.
                                                          

                                                          

                                                          
Darn: I
                                                          clearly was
                                                          not firing on
                                                          all cylinders
                                                          when I typed
                                                          this out. Let
                                                          me correct:

                                                          


                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
- the
                                                          access token
                                                          MAY be self
                                                          contained so
                                                          that the RS
                                                          does not need
                                                          to query the
                                                          GS on each
                                                          access to the
                                                          RS by the
                                                          Client.

                                                          

                                                          

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] A few
                                                    comments in the case
                                                    of a capability
                                                    approach:

                                                  

                                                    
- for each GS,
                                                      the RS needs to
                                                      locally manage
                                                      which operation(s)
                                                      is/are allowed to
                                                      it.

                                                      

                                                      - the GS needs to
                                                      establish a
                                                      trusted
                                                      communication
                                                      channel or an
                                                      authentication
                                                      mechanism with
                                                      each RO 

                                                      =C2=A0=C2=A0 (which i=
s
                                                      associated with an
                                                      explicit RS
                                                      identifier). 

                                                    

                                                    
- the GS could
                                                      play the role of
                                                      the RO and hence
                                                      be in a position
                                                      to issue any
                                                      capability for any
                                                      RS (without a "R=
O
                                                      consent"). 

                                                      

                                                      =C2=A0=C2=A0 The targ=
et of
                                                      an attack will
                                                      clearly be the GS.
                                                    

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
I would
                                                          not say that
                                                          GNAP is an
                                                          access control
                                                          protocol, as
                                                          how the RS
                                                          uses the token
                                                          to determine
                                                          access is out
                                                          of scope.

                                                          

                                                          

                                                          

                                                          
This is
                                                          where we have
                                                          a maj=
or
                                                          discrepancy:
                                                          how the RS
                                                          uses the token
                                                          to determine
                                                          access is
                                                          *within* the
                                                          scope.

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                  [Denis] Do you agree
                                                  or disagree ?

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          
The RS
                                                          announces in
                                                          advance to the
                                                          client what it
                                                          needs so that
                                                          the client can
                                                          perform a a
                                                          given
                                                          operation and
                                                          if the client
                                                          supplies the
                                                          requested
                                                          attributes 

                                                          obtained from
                                                          some GS/AS(s)
                                                          trusted by the
                                                          RS, then
                                                          access to that
                                                          RS is granted
                                                          by the RS. If
                                                          the RS cannot
                                                          perform the
                                                          requested
                                                          operation on
                                                          its own, 

                                                          then the
                                                          client should
                                                          be informed
                                                          about some
                                                          requested
                                                          attributes
                                                          that need to
                                                          be obtained
                                                          from some
                                                          GS/AS(s)
                                                          trusted by the
                                                          next RS(s) in
                                                          a chain

                                                          for subsequent
                                                          operations.
                                                          The User
                                                          consent should
                                                          also be
                                                          obtained
                                                          before
                                                          performing the
                                                          chaining
                                                          operation.

                                                          

                                                          
Chaining
                                                          operations
                                                          between RSs
                                                          over the
                                                          Internet is
                                                          within the
                                                          scope (... and
                                                          may be
                                                          achieved).

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                  
[Denis] Do you
                                                    agree or disagree ?

                                                  
Denis

                                                  

                                                  

                                                    

                                                      

                                                        

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
For many
                                                          use cases, the
                                                          User is the
                                                          RO, and the
                                                          interaction is
                                                          through a user
                                                          interface, not
                                                          a machine
                                                          protocol. 

                                                          

                                                          

                                                          

                                                          

                                                          
Wait a
                                                          second. You
                                                          wrote "the
                                                          User is the
                                                          RO". The Use=
r
                                                          is attempting
                                                          to make an
                                                          access to a RS
                                                          by using a
                                                          Client. 

                                                          That
                                                          User is not
                                                          the RO of the
                                                          RS.=C2=A0=C2=A0 <=
br>
                                                          

                                                          

                                                          

                                                          
The user
                                                          being the RO
                                                          is the initial
                                                          use case for
                                                          OAuth. 

                                                          

                                                          

                                                          

                                                          
OAuth 2.0
                                                          is no more
                                                          mandating such
                                                          a case.

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          


                                                          
I don't
                                                          know what you
                                                          mean by that.
                                                          

                                                          

                                                          

                                                          
Copy and
                                                          paste from
                                                          draft-ietf-oauth-=
security-topics:

                                                          

                                                          

                                                          
OAuth
                                                          initially
                                                          assumed a
                                                          static
                                                          relationship
                                                          between
                                                          client,
                                                          authorization
                                                          server and
                                                          resource
                                                          servers.=C2=A0
                                                          (...)=C2=A0 

                                                          With the
                                                          increasing
                                                          adoption of
                                                          OAuth, this
                                                          simple model
                                                          dissolved and,
                                                          in several
                                                          scenarios, was
                                                          replaced 

                                                          by a dynamic
                                                          establishment
                                                          of the
                                                          relationship
                                                          between
                                                          clients on one
                                                          side and the
                                                          authorization
                                                          and 

                                                          resource
                                                          servers of a
                                                          particular
                                                          deployment on
                                                          the other
                                                          side.

                                                          

                                                          This way, the
                                                          same client
                                                          could be used
                                                          to access
                                                          services of
                                                          different
                                                          providers (in
                                                          case of
                                                          standard APIs,
                                                          

                                                          such as e-mail
                                                          or OpenID
                                                          Connect) or
                                                          serve as a
                                                          frontend to a
                                                          particular
                                                          tenant in a
                                                          multi-tenancy
                                                          environment. 

                                                          

                                                          

                                                          

                                                          

                                                          


                                                          

                                                          
This
                                                          sentence does
                                                          not mention
                                                          the RO or the
                                                          Client. I'm
                                                          confused what
                                                          we are talking
                                                          about=C2=A0

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
A client
                                                          application
                                                          would like
                                                          access to the
                                                          user's photos
                                                          at a photo
                                                          sharing site.
                                                          The resource
                                                          is the user's
                                                          photos. The
                                                          user is the
                                                          owner of that
                                                          resource.

                                                          

                                                          

                                                          

                                                          
If the user
                                                          has already
                                                          pre
                                                          established
                                                          the access
                                                          control policy
                                                          rules so that
                                                          it can access
                                                          to his own
                                                          photos 

                                                          then he does
                                                          not need to
                                                          grant in real
                                                          time any
                                                          additional
                                                          authorization.
                                                          

                                                          

                                                          
I don't
                                                          understand
                                                          what you are
                                                          trying to say.
                                                          The photo
                                                          sharing
                                                          example was a
                                                          driving use
                                                          case for the
                                                          creation of
                                                          OAuth.

                                                          

                                                          

                                                          

                                                          
We would
                                                          need to
                                                          revisit the
                                                          original
                                                          scenario and
                                                          consider if it
                                                          can be
                                                          addressed in a
                                                          different way
                                                          than the
                                                          original way.

                                                          

                                                          

                                                          
The use
                                                          case is the
                                                          same. Is there
                                                          a different
                                                          solution you
                                                          are proposing?
                                                          
=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

                                      

                                    

                                  

                                  
3D""=E1=90=A7

                                

                                


                                

                              

                            

                          

                        

                        


                        

                      

                      -- 

                      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

        

      

    

    


    

  





--00000000000064bd7e05ab86d86a--


From nobody Wed Jul 29 10:07: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 782163A0CF3 for ; Wed, 29 Jul 2020 10:07: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, 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 sMOXxOX2EZxD for ; Wed, 29 Jul 2020 10:07:26 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450: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 53CE83A0D20 for ; Wed, 29 Jul 2020 10:07:21 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id i19so13428140lfj.8 for ; Wed, 29 Jul 2020 10:07:21 -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:cc; bh=o3q9jFIbAvt+SpCdZ2zuB6x5ZEbkqPNI11YMVK+szeQ=; b=p5hxIGvE5Dj9ZdNOrqF1F3vt/Z78U5YGMQMGlnvKfeEuN9D0F2mq4tlOkCexKdJphQ OrwDF+f0TIP+77g673wIO0nhRA8+58RdVGJd5+dE279PxyzuI9AaO+vHeP/EHdjdcYnc 8xNQ1GJtJYpzi0InfyJ83fEV1pKwV3jCOp9/LDQ76h9GEQL1wavZeZhpl++m7VrLgNOr HE77THP7pn1YTTowgsLZolnwinMdNP0A32cnbAfQwCRoPrxMMAJOllT4Ngs6zgdVd3S+ A3A/Qs6W0ORsUB6xysA3L2O6c+yML6rlTwta1Z1bAIoVipcog1Fw6vfTDPSVYT0jaLof l9Xg==
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:cc; bh=o3q9jFIbAvt+SpCdZ2zuB6x5ZEbkqPNI11YMVK+szeQ=; b=ADwihpTzlbQERY6VYdrBjttXMX2hgrplaWKsc/YQdzuDMS87nhqSjnhAmMt2SeesNJ 4eysDKuuRSmOKTeC3iCpRbEVFaDor/STIFmOvPCCYyJuPdGJYp268iV03yDTdcDnbZfI kgoGAZwxOQNzeEk5YK9U99pDk89zrveDxnTkI2KMga3oX9rLzkOuwrA+/3Z084qJIp9p YHVgNvWpkCJ1KsWaUVljLG33lSWi60stfS8ikFAyYS1jTOfuUN0K+D1Tg1rrsLg9vQs7 mSUfX7UD63wqpSZ6B2I2klOhiVkLhvges45MXrU/gfPs2Tta7q+VOtqkCz7HjzhrLZNF 1YQQ==
X-Gm-Message-State: AOAM530g73Pu/BrKm12gEXie4H61VKvPFpbWMKay3oXyDkfyuAm1f8tg kpTUCiTyE8wYQTTXsbAP+VGmvv2d5WRso8t/LeY3l34H8tE=
X-Google-Smtp-Source: ABdhPJxJ8q5VOAhcRJOHPVRtFn/5hVBKo8BPr75EjbYwXjp+WP4t4ucwcWfc/Xcgd0fHpwnJLjHr0jTcyS9CaS871zc=
X-Received: by 2002:a19:8044:: with SMTP id b65mr17729539lfd.91.1596042439249;  Wed, 29 Jul 2020 10:07:19 -0700 (PDT)
MIME-Version: 1.0
From: Dick Hardt 
Date: Wed, 29 Jul 2020 10:06:42 -0700
Message-ID: 
To: Kathleen Moriarty 
Cc: GNAP Mailing List 
Content-Type: multipart/alternative; boundary="000000000000a3558705ab9796c6"
Archived-At: 
Subject: [Txauth] (no subject)
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, 29 Jul 2020 17:07:29 -0000

--000000000000a3558705ab9796c6
Content-Type: text/plain; charset="UTF-8"

Hey Kathleen

A couple questions on your presentation:

1) Which versions of the documents did you review?

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.

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)"?

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?

Thanks!

/Dick

--000000000000a3558705ab9796c6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey Kat=
hleen

A couple questions on your presentation:

1) Which versions of the documents did you review?

2) Would you elaborate on your security comparisons of XAu=
th and XYZ? I want to make sure I understand the=C2=A0work you put into you=
r review.=C2=A0 While reviewing your slides, I was not following a number o=
f your statements. For example:=C2=A0

In your firs=
t slide:

A) you stated that "XAuth Relies hea=
vily on OAuth2.0, using Bearer token and adding cryptographic (e.g.JOSE) fu=
nctions 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.

B) What parts of XYZ did you view as "Builds se=
curity into the protocol as
opposed to adding it in later (e.g. OAuth2.0
bearer token + JWT)"?=C2=A0

C) "Interact=
ion 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?

Thanks!

/Dick




=



--000000000000a3558705ab9796c6--


From nobody Thu Jul 30 08:11: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 1D6493A07D1 for ; Thu, 30 Jul 2020 08:11:56 -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 eVHxJlUSu5-t for ; Thu, 30 Jul 2020 08:11:53 -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 12F013A07EE for ; Thu, 30 Jul 2020 08:11:07 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id k23so28512704iom.10 for ; Thu, 30 Jul 2020 08:11: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=CmWyTwu01qOFcU8TwF5NC7uA8LIKoCXfqgpqV+/RD7A=; b=uxzQiRy35Xs54obZSL5bInTJKXPGvYHEqTIUbXXIj33ub4a1A9ZMhiKk+x2Pbr3jJG qBm89Zd1rcYm6YSzc4FJhhhfO8k/JW+CDkyGm/kB7FkJhJ6G9H5/QVfJWvvVxB0RhpoG eG+uvYOCP2HC+luO2UAj1oZLhfgV1ZFmPiOAJZ3ivwwMJcR2Ru7pIgg0F4ZUjDOO+A/D uPNZ4YGz1CpA9H1IYU5k0X9eWJX/RAKc0bkDjqfg11iGX2n7kK3drolKr58tCyflgzp3 Wzlu2J3dRqiVNJJV3lVJoUJG6ziC4839KIERJGULsWIBRtoBGP9hH/rwKiRfxk5J0CBo 7fYQ==
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=CmWyTwu01qOFcU8TwF5NC7uA8LIKoCXfqgpqV+/RD7A=; b=kuYZd0x5kyotLcbQo6CUxjJ5Ofu0Kr+gtFLVI5lIxysuLr9liItIcfJcnag0OwJ4QB i5b4N/Ymd0TzI4r5ZjpOTaWs5mDBzafhe/U84xzJwqSapV05V41OWv9oXNZmO49VxnqF iQ4UB3Yf6Xbr9v6lVhjRAyDIb7xLDlwYbJJF4MOqhnNUo17Xpb0nk8ph2WJNOZisbcty uDmiNadi5JciIEsPc/58OXLrWJsxCiiUO/44AsXsp3Xx8MgHvybIHki+WiQuY1g2zRhZ WLA+tNZHk8q8mz+ilxbnQGqzC+1+NGdCoeg0cCf3PQ/J7bPr2F88+q5fIzHoOI4u/oS9 w9SQ==
X-Gm-Message-State: AOAM530qNmrGt3HWuB7AxA+uTfHzCFbld5hT8aNdZdpY/OnI/LFTOWpy yb++AT6FMVJnaMnPA6YqE/SsN4WQxps2V7fTslM=
X-Google-Smtp-Source: ABdhPJwrtDtTbH/C18X3OsYa3FiTLX+UDZV3reN5ls4uDg2lmBcntmSdlFcq0GBp+ZDc1mSLr28ck7L1v+9YnuIvz6Y=
X-Received: by 2002:a02:5b83:: with SMTP id g125mr3856260jab.91.1596121866359;  Thu, 30 Jul 2020 08:11:06 -0700 (PDT)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Kathleen Moriarty 
Date: Thu, 30 Jul 2020 11:10:30 -0400
Message-ID: 
To: Dick Hardt 
Cc: GNAP Mailing List 
Content-Type: multipart/alternative; boundary="000000000000dcd4f005abaa1476"
Archived-At: 
Subject: Re: [Txauth] (no subject)
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, 30 Jul 2020 15:11:56 -0000

--000000000000dcd4f005abaa1476
Content-Type: text/plain; charset="UTF-8"

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

--000000000000dcd4f005abaa1476
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hey Dick,

Thanks for your qu=
estions 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 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.=C2=A0 Although my skim on the datatracker one had si=
milar impressions in terms of structure, ease of use, etc.
=C2=A0=


2) Wou=
ld you elaborate on your security comparisons of XAuth and XYZ? I want to m=
ake sure I understand the=C2=A0work you put into your review.=C2=A0 While r=
eviewing your slides, 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&=
quot;. 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.=C2=A0 That'=
;s how OAUth is now and it's something that really should be fixed.=C2=
=A0 Making it clear that security is an afterthought makes it an afterthoug=
ht for developer and implementers.=C2=A0 Industry is moving towards built-i=
n intrinsic security.

You can do this just as easi=
ly, but XYZ mentioned security in the flows/sequences as an inherent=C2=A0p=
art of each.=C2=A0 =C2=A0While it may not be perfect yet, the theme was the=
re.=C2=A0 The references to exchange of a key in section 2 and 3 with an ed=
itor note that this needs work are the first places the idea of embedding b=
egins.

The value generated in the=C2=A0access toke=
n doesn't explicitly 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 This 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.



<=
div dir=3D"ltr">

B) Wh=
at 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


--000000000000dcd4f005abaa1476--


From nobody Thu Jul 30 13:36: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 86FC53A0C86 for ; Thu, 30 Jul 2020 13:36:01 -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 ETqtJJFILgMI for ; Thu, 30 Jul 2020 13:35:59 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450: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 B39163A0C46 for ; Thu, 30 Jul 2020 13:35:58 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id v15so11143450lfg.6 for ; Thu, 30 Jul 2020 13:35:58 -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=lCek9M9K2FCyeVufJ8JZXesveybujmxO7gICdsF0bZw=; b=oR7fW89M0BQGi9EzBUYU+J8j2/9UE7PwLuMiIIqu9ptu/gHI7H7VHRGmP2OhA/3PWC tvWpcils535cTFfklHRIR9YK1XFdQN6koji75vKIBFrQMlYJGaSQfScJq0v0Oq66Lqj2 ybRVfK5PZRF2Ptm0Z9nA6jAu1Fu6J+rZX9JLv00vW/6WIHbFJzeLftbpkTe4b7xj0zYd e/CTmmxk5egtFnlDwrjtHmLrUrLvwE5hHFqJVA8x8pIeKiMEFcENdHL97OQ0knsy2ZJk qVYfoJswEcYyMIUuJF49N6d4Jh97hLVWXZzUxphTkhgroxLTYXgu4c6lBCBFenInNVr3 Hkxw==
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=lCek9M9K2FCyeVufJ8JZXesveybujmxO7gICdsF0bZw=; b=qttFSNw1K4v5Zb/pCqPnE3c0YeKpXnDn87yosIzA7VjSq7TXz48RIcBXMeY1H9uXR/ Wc+6QARLqH3BT8sZp6B/ERUWeS7s/n+7QR8M/div7GpdjzBB+ICr/yRk3/FU8hpQ4ZzG tHd3QZKiUxsJ8mYq7gAD1pDUQDUb7egyTPmJ1di51ox8oFYoo8bslubxI+sZuY2DxUEt oqDlyPmdztSPgWNWkKixPk3XhJwVOql4cfIeLE/u2YmPJl56cbY/CdNzKCEcMxdSuOsR mRmhRIJxBzkq3V3qxD6ke+Qz4PufpgPpcO9h6D1FOgPAz++CHkVQNvciUAT9Jg6xRpMr FuVA==
X-Gm-Message-State: AOAM533OLxMPALwn7FotXZSkOpE7wc7ZwiLf2uSjxBnKs8HQAW4FFpo8 TgUThr/YOQiFZOd3Fw1ZdC1n2Ky8uaXpxyhixQU=
X-Google-Smtp-Source: ABdhPJxBuufQ9BqWFXDY0Pirfq+Yt/k50qGEZ5zBnicGd4G9Z52JIhEoRLheOOdCkLFlmJ5sSqP6DGCUAu7sgAhepH8=
X-Received: by 2002:a19:8044:: with SMTP id b65mr194619lfd.91.1596141356502; Thu, 30 Jul 2020 13:35:56 -0700 (PDT)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Dick Hardt 
Date: Thu, 30 Jul 2020 13:35:20 -0700
Message-ID: 
To: Kathleen Moriarty 
Cc: GNAP Mailing List 
Content-Type: multipart/alternative; boundary="00000000000090d4b705abae9e09"
Archived-At: 
Subject: Re: [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, 30 Jul 2020 20:36:02 -0000

--00000000000090d4b705abae9e09
Content-Type: text/plain; charset="UTF-8"

(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
>

--00000000000090d4b705abae9e09
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


(adding in a subject)

=

Thanks for the clarification Kathleen!

I fully agree with you that we want developers to think of security w=
hen reviewing the document.

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

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

In the charter we have anticipated h=
aving numerous key presentation mechanisms, so separating the key presentat=
ion=C2=A0documents from the core protocol seemed the right choice.=C2=A0

Q: Are you suggesting we combine the documents? Or i=
s there a different recommendation to overcome what you saw as a security d=
eficiency in XAuth vs XYZ?=C2=A0

As you know, ther=
e is much more to security than cryptography,=C2=A0and I considered how to =
encourage best practices in the design. One of those is the separation of c=
oncerns, 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=
=C2=A0[2].=C2=A0

In contrast to XYZ, XAuth require=
s the=C2=A0Grant URI and AZ URI to start with the=C2=A0GS URI, so the=C2=A0=
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 datab=
ase 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 t=
hese improve security as more errors can be detected, and attack vectors ar=
e reduced.

btw: A GS could have just one entry poi=
nt if desired, the GS URI, and the Grant URI and AZ URI could be represente=
d by query parameters.

/Dick

<=
div>[1]=C2=A0htt=
ps://datatracker.ietf.org/group/gnap/about/



Woul=
d 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 n=
ot displayed)

In my first drafts that I shared off=
line with Justin, I had JOSE client authentication throughout
Put JOSE Client authentication into a separate document in vers=
ion -08.

WG deliverables -- authentication is a se=
parate document.



From a security=C2=A0perspective, I focussed on the protocol as=
pects rather than the security aspects.

interactio=
n 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 A=
M 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 questions on your p=
resentation:

1) Which versions of the documents di=
d you review?
Your last post=
ed version to the datatracker.
I had started with the latest in t=
he datatracker for Justin, but switched when he announced the update.=C2=A0=
 Although my skim on the datatracker one had similar impressions in terms o=
f structure, ease of use, etc.
=C2=A0

2) Would you elaborate on your sec=
urity comparisons of XAuth and XYZ? I want to make sure I understand the=C2=
=A0work you put into your review.=C2=A0 While reviewing your slides, I was =
not following a number of your statements. For example:=C2=A0
In your first slide:

A) you stated tha=
t "XAuth Relies heavily on OAuth2.0, using Bearer token and adding cry=
ptographic (e.g.JOSE) functions after-the-fact". Both XAuth and XYZ su=
pport bearer tokens for calling an RS. I'm not clear how this feature i=
s 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 now and it&#=
39;s something that really should be fixed.=C2=A0 Making it clear that secu=
rity is an afterthought makes it an afterthought for developer and implemen=
ters.=C2=A0 Industry is moving towards built-in intrinsic security.

You can do this just as easily, but XYZ mentioned securit=
y in the flows/sequences as an inherent=C2=A0part of each.=C2=A0 =C2=A0Whil=
e it may not be perfect yet, the theme was there.=C2=A0 The references to e=
xchange of a key in section 2 and 3 with an editor note that this needs wor=
k are the first places the idea of embedding begins.

The value generated in the=C2=A0access token doesn't explicitly 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 This is in th=
e feedback I will be posting.

Section 7 calls expl=
icitly=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




--00000000000090d4b705abae9e09--